>> .alt will be treated like any other pseudo-TLD regardless of the context. > > Sorry, I don't understand. I believe "pseudo-TLD" here means "a name that > resolves to NXDOMAIN".
It is defined in this very document as "A label that appears in a fully-qualified domain name in the position of a TLD, but which is not part of the global DNS." > Most URI schemes are pretty clear about what happens in this case: the > resource cannot be accessed. That seems like the right thing for them to specify. >> If you think that URIs that have names that are not part of the global DNS >> should be treated differently by URI consumers, by all means write a draft >> about it. > > This is not about "global DNS" vs. some view of the DNS. It really is. See the definition in the draft. > This is about "resolvable names" vs. "non-resolvable names". Every URI > scheme I'm aware of relies on "name resolution" of any hostname specified in > the authority section. But "name resolution" is not defined except within > "the DNS". Applications and APIs can sometimes invoke their own name resolution outside the DNS. > If .alt names are "not DNS names", then they are not subject to "name > resolution". Correct. > I conclude that they cannot be used in any existing URI scheme. Above, you said "Most URI schemes...". Yes, I know that some of this stems from the lack of a stable, widely-believed URI spec. > If you agree, that should go in the draft. If not ... personally I think > you'll need to add some text, and possibly update some RFCs. URIs are just one user of DNS names, albeit an important one. I'm not sure they should be called out separately, but a suggested addition to the new draft is welcome. > As a practical matter, I see three types of "pseudo-TLDs": > 1. Alt-root names: Those that actually _are_ DNS names, offering the same set > of RR types but resolving to an alternate DNS root. (Example: Handshake > "HNS") > 2. New class names: These come with their own new universe of URI schemes, > and cannot be used with existing schemes that assume name resolution. > (Example: dweb://) > 3. Retrofit names: These names reuse some existing scheme strings but > substantially modify the interpretation of the scheme. (Example: https: and > .onion). > > I would like the draft to be a lot clearer about which of these are in-scope > for .alt. The current text says it is up to the application and API. If we can be clearer, suggested text is definitely welcome. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
