Sorry this response took so long. I've been kind of busy. On Sat, 01 Mar 2014 13:57:34 +0100 "Sebastian G. <bastik.tor>" <bastik.tor@xxxxxxxxxxxxxx> wrote: > To me it is clear that the two are messed up, but I'm not sure what's > the correct order. Indeed. Since there isn't a clear advantage to going one way or another for this, 0xE0 should be not found, 0xE1 should be not available. Looking at some of the stuff nickm added: * What should a client if it gets a value here it does not recognize? (wrt status code in the response from the server) All response codes that are not 0x00 are defined as a failure state, and the server is required to drop the connection after sending one. I'm not sure client behavior needs to be specified here. * What do these do? What is their behavior? Are they client-only? (wrt The USERNAME/PASSWD keys that are reserved) My intention was to reserve keys required to add support for doing RFC1929 style authentication if we desire in the future that is separate from whatever other keys we decide to use in the future. (As a "Yes, these actually for a username/password, don't abuse them for other things"). Client-only, unless reserving this isn't useful (It might not be, there was some grumbling about one day supporting authentication again). "PASSWD" should be "PASSWORD" instead here I guess (or "USERNAME" should be "UNAME" to be consistent with RFC1929). * What should a client if it gets a value here it does not recognize? (wrt Key/Value pairs from the server contained in the response) There's three options here, "ignore", "drop the connection" or, "client sends Version/Status after receiving the response". I believe that the 3rd option is the best. "Ignore" may cause problems if we send important things back in the response (nickm asked for this to be added so I did, but I'm not clear on what it will be used for). "Drop" is not forward compatible. * Should we recommend any namespace conventions for these? Yes, probably. I have no strong preference for what sort of convention is used. "tor.streamIsolation", "scramblesuit.password" etc? * Actually, should this perhaps be controlled by additional KEY? (re: Response codes). I don't think this is necessary. Explicitly specifying that after sending/receiving a status code that is not 0x00 (Defined as Success in RFC1928, the server/client MUST drop the connection should be sufficient? (I'm not sure either) Regards, -- Yawning Angel
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev