Dear all, Here is a patch that removes crypto cruft from torspec.txt. It does make torspec unusable because we haven't written crypto.txt yet. In the process I noticed a few things I cleaned up, and also noticed that RELAY_EXTEND cells have to be understood by both ORs, which could be an impediment to migration. Sincerely, Watson Ladd
On Thu, Nov 3, 2011 at 6:30 PM, Watson Ladd watsonbladd@gmail.com wrote:
Dear all, Here is a patch that removes crypto cruft from torspec.txt. It does make torspec unusable because we haven't written crypto.txt yet. In the process I noticed a few things I cleaned up, and also noticed that RELAY_EXTEND cells have to be understood by both ORs, which could be an impediment to migration. Sincerely, Watson Ladd
It's an interesting exercise but I don't think I can apply this any time in the near future.
Trivial stuff that would be easy to fix:
a) It's an old-style diff. We're on unified diffs. (So are most open-source projects I know if.)
b) The clarity stuff is mixed in with the extract-crypto stuff. Like I said previously, "It's best to do stuff like this in multiple small steps if you want it merged upstream. That way, if we like 80% of what you're doing, we can merge the 8/10 pieces we like right away and keep talking about the remaining 2/10."
c) It removes info without adding it elsewhere. This would turn the tor spec into "tor spec plus references to stuff that doesn't exist." (I know you say "we haven't written it yet" -- but what's this "we"? We already wrote a specification for Tor's crypto: it's tor-spec.txt.)
Fundamental stuff:
d) It feels like premature generalization. The time to split off "here is how the crypto fits in", it seems to me, is after we have multiple crypto implementations. Otherwise we're likely to draw the boundaries wrong.
e) It adds confusing stuff in the name of clarity. It's odd to say that StreamIDs MUST NOT be zero and then go on to explain when they may.
If you're having a good time and learning about Tor here I don't want you to stop, but I don't think this is the right way to improve the clarity and organization of our specifications.
apologies,