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

["Darcy Kevin (FCA)" <kevin.darcy@xxxxxxxxxxxx>]

True, different name-resolution methods could be defined at the Operating System level (I still remember writing code to work against NetInfo, for instance – how many people remember that?). RFC 3986 recognizes as much.

 

Perhaps it would have been sufficient for RFC 7230 to limit the acceptable name registries to those for which access is defined/enabled at the Operating System level. That’s a fairly limited, defined set. It’s when we allow *applications* to define their own name registries, that it becomes open-ended and “Authority” for any given URI then becomes *non-definitive*, which pretty much defeats its whole purpose.

 

(Yes, I realize that on some platforms, the distinction between application and OS can be somewhat blurry).

 

                                                                                                                                                                - Kevin

 

From: Roy T. Fielding [mailto:fielding@xxxxxxxx]
Sent: Wednesday, August 12, 2015 1:05 PM
To: Darcy Kevin (FCA)
Cc: Alec Muffett; Joe Hildebrand; Edward Lewis; Ted Hardie; ietf@xxxxxxxx; Richard Barnes; dnsop@xxxxxxxx; Mark Nottingham
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

 

On Aug 10, 2015, at 3:54 PM, Darcy Kevin (FCA) <kevin.darcy@xxxxxxxxxxxx> 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,

 

I generally try to avoid enumerating things that are known to be false. All URI schemes that use authority

intentionally refer to the local mechanism of name lookup, even if that name lookup only uses DNS as the last

in a long line of alternative registries.  The client is responsible for choosing a mechanism which produces

a correct mapping for any given authority, regardless of whether that is defined for them by /etc/host, WINS,

DNS, third-party https-based DNS lookup, etc. The folks referring to resources using those schemes are

responsible for making those references unambiguous, usually by naming convention rather than any

specific set of syntax rules.

 

....Roy