RFC7230 Section 2.7.1 says this about hostnames in HTTP URLs: """ If host is a registered name, the registered name is an indirect identifier for use with a name resolution service, such as DNS, to find an address for that origin server. """
... which builds on how RFC3986 Section 3.2.2 talks about hostnames in URLs and URIs: """ The presence of a host subcomponent within a URI does not imply that the scheme requires access to the given host on the Internet. In many cases, the host syntax is used only for the sake of reusing the existing registration process created and deployed for DNS, thus obtaining a globally unique name without the cost of deploying another registry. However, such use comes with its own costs: domain name ownership may change over time for reasons not anticipated by the URI producer. In other cases, the data within the host component identifies a registered name that has nothing to do with an Internet host. We use the name "host" for the ABNF rule because that is its most common purpose, not its only purpose. """ So, the Web architecture already has baked in a notion of multiple mechanisms for location within a single name space. Indeed, the flexibility of multiple location mechanisms might be required to address issues like domain name ownership changes. Given this context, I was disturbed to hear the design team presentation in Yokohama suggest that we "remove the value of a top-level domain" as a potential solution (around 49:30 in the meetecho recording). To me, this fundamentally misses the point; the value of a single naming root with flexible location is a community good, and cannot be removed just to make life easier for DNSOPS. The impact goes far beyond DNS. In the ensuing discussion, Andrew Sullivan's comments (at around 58:00) made the most sense to me. The problems that draft-adpkja-dnsop-special-names identifies (e.g., "what technical criteria should the evaluation body use to examine the merit of an application for such a reserved name/protocol switch", "With regard to the actual choice of name, [RFC6761] is silent") are already handled by our normal processes, where we invest technical authority to judge in bodies like the IESG, and document an appeals process. It's also far from clear that we *need* to have only one path to a new special-use name (as section 6.2.1 seems to desire). While I appreciate that the .onion discussion was a prolonged headache for DNSOP, and that perhaps in the future other venues should be used, deciding how to handle the general issue of naming based upon its impact on *one* location protocol community doesn't seem appropriate. If this effort is to do more than make modest clarifications to RFC6761, I'd suggest that we consider moving it elsewhere. Kind regards, P.S. The draft begins: """ In recent years, using the last label of a domain name (aka TLD) as switch to indicate how to treat name resolution has been experimented using the framework of [RFC6761]. """ This framing is incorrect. RFC6761 is a Proposed Standard, not Experimental. -- Mark Nottingham https://www.mnot.net/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
