On Wed, Oct 19, 2022 at 9:31 PM Paul Hoffman <paul.hoff...@icann.org> wrote: ...
> On Oct 17, 2022, at 1:16 PM, Ben Schwartz <bemasc= > 40google....@dmarc.ietf.org> wrote: > > > > While we're talking about this draft, I would like to suggest that the > draft discuss the interpretation of URIs containing ".alt" hostnames. I > have great difficulty understanding what "https://example.foo.alt/"; means > ... but most of the interest in alternative naming systems seems to be > based on the idea that this sort of URI is meaningful. > > .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". Most URI schemes are pretty clear about what happens in this case: the resource cannot be accessed. > 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. 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". If .alt names are "not DNS names", then they are not subject to "name resolution". I conclude that they cannot be used in any existing URI scheme. 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. 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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
