Kevin,
On 11 Aug 2015, at 6:54 am, Darcy Kevin (FCA)
<kevin(_dot_)darcy(_at_)fcagroup(_dot_)com> 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/