On Fri, Oct 21, 2022 at 3:03 PM Wes Hardaker <wjh...@hardakers.net> wrote:
> Ben Schwartz <bemasc=40google....@dmarc.ietf.org> writes: > > > Rather than placing "alt" in the TLD position, I think it might be > better as a > > scheme modifier: https+alt://... This is a common pattern for > modifications to > > URI schemes (c.f. git+ssh://), and informs the software that this URI is > special > > without overloading the DNS namespace. > > I suspect many of us would agree that's the best ideal way forward, > except that the proponents of the alternate names want their names to be > as DNS-like as possible so it works with *all* applications. All new > ones may support extensions and URIs, etc. I'm not sure telnet, nntp > readers, etc do/will. I don't even know how to enumerate all the places > where a domain name is expected (endless GUIs) that don't have an > appropriate name space selector option. Certainly a "too bad for you" > approach for situations like that, but I suspect that's going against > what the alternate name space proponents want: minimal upgrades to > existing software [right or wrong as that may be -- no judgment here]. I think this mindset is based on what I'll call the "getaddrinfo assumption", that DNS provides a name->IP mapping interface whose implementation can be replaced. This assumption can fail on both ends: 1. Many altname schemes (e.g. .onion, IPFS) do not represent IP addresses at all. 2. Existing DNS-reliant applications increasingly rely on beyond-getaddrinfo capabilities (e.g. SRV, HTTPS-records, stub DNSSEC, etc.) or implement their own stub resolvers for performance reasons. The .alt draft seems to be based on this assumption, although it doesn't say so. If this assumption fails, it's hard for me to see how .alt helps. Conversely, I think an alternate URI-scheme is actually _more_ likely to have good compatibility with non-alt-aware software. For example, if a non-alt-aware web browser encounters an unknown URI scheme, it will generally defer to the operating system for how to handle it. This means a user can (today!) install a system-wide "https+alt://" handler, and expect to be able to open such URIs if they're encountered in the browser, mail client, etc.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
