On Mon, Apr 3, 2017 at 8:20 AM, George Kadianakis <desnac...@riseup.net> wrote: > Nick Mathewson <ni...@torproject.org> writes: >> Section 2.1 and elsewhere: >> >> I suggest that we require all address suffixes to end with .onion; >> other TLDs are not reserved like .onion is, and maybe we shouldn't >> squat any we haven't squatted already. I think we might also want to >> have all output addresses end with .onion too. >> >> I suggest also that we might want to reserve part of the namespace >> for standardized namespaces and some for experimental or local ones. >> Like, if we standardize on namecoin that could be .bit.onion, but if >> we don't, it could be .bit.x.onion. >> > > I have mixed feelings about keeping the .onion suffix. > > One one hand it seems like The Right Thing to do, since we managed to > get .onion standarized in the IETF which comes with various > benefits. Also, starting to squat other tlds arbitrarily seems like a > silly thing to do. > > However, I also dislike asking users to visit something.bit.onion > instead of something.bit, since people are not used to the second tld > having a semantic meaning, and I can imagine people getting very > confused about what it means.
Indeed. And I'm not only concerned about people becoming confused: I am also worried about confused programs. Right now, it is easy to answer the question "will Tor handle this address specially" -- the only special addresses are the ones ending with ".onion", and the legacy suffices ".exit" and ".noconnect" as documented as address-spec.txt. But if we allowed arbitrary TLDs in this proposal, then _any_ hostname would potentially be an address that Tor would handle specially. -- Nick _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
