Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

[Mark Nottingham <[e-mail]>]

Kevin,

On 11 Aug 2015, at 6:54 am, Darcy Kevin (FCA) <[e-mail]> wrote:
> 
> In retrospect, the definition of the “http” and “https” schemes (i.e. RFC 7230) should have probably enumerated clearly which name registries were acceptable for those schemes, so that the following language from RFC 7320 (a BCP) could be invoked against any attempt by an app – Onion or anyone else -- to inject their own unique brand of “specialness” into the interpretation of the Authority component of their URIs:
>  
> Scheme definitions define the presence, format and semantics of an
> authority component in URIs; all other specifications MUST NOT
> constrain, or define the structure or the semantics for URI
> authorities, unless they update the scheme registration itself.
>  
> 7230 casually mentions DNS and “network host table” as name registries that can potentially be used for “http” and/or “https”, but never implies that those 2 constitute the only members of the set.
>  
> If both injecting “specialness” into the URI, and updating the “https” scheme itself, were viewed as unavailable or unappealing options, then Onion – and anyone else who follows the same path – would be left with no other choice but to define their own scheme.

I think that would be a bad outcome indeed. 

Viewing this as "injecting specialness" into the URI is counter to the clear examples that Alec just gave of non-HTTP-based (and, indeed, non-URI-based) uses of .onion. So, I can't imagine what end such restrictions would serve, except as a (fairly artificial) way to frustrate the registration of .onion.

I'd also point out that such an approach might place procedural barriers in place of getting .onion or something similar recognised, it would not significantly hinder its deployment — as evidenced by .onion itself.

Regards,




--
Mark Nottingham   https://www.mnot.net/