[tor-dev] Comments on proposal 279 (Name API)

[Nick Mathewson]

On Mon, Apr 3, 2017 at 8:20 AM, George Kadianakis <desnacked at riseup.net> wrote:
> Nick Mathewson <nickm at 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