On Sun, Oct 23, 2022 at 4:31 AM Eliot Lear <l...@lear.ch> wrote: > Hi Ben and Wes, > On 21.10.22 20:45, Ben Schwartz wrote: > > > 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. > > How would this work in practice? > Thinking about this more, I can imagine having both "+alt" and ".alt". In this world, ".alt" would be for "the system's alternate DNS root", providing DNS-equivalent functionality but not in IANA-controlled space. "+alt" would be for "the system's alternative interpretations of URI schemes", with no further requirement that the authority be domain-shaped at all.
> > - Would this require a re-registering of each and every URI scheme > with +alt, and monitoring the URI scheme registry for new ones? > > I don't think so. We could define it as a universal scheme modifier. > > - (I'll note that git+ssh isn't registered.) > > Unfortunately, most URI schemes outside of the RFC process are not registered. I think there's a general lack of awareness that registration is required or easy. > > - What is the value of +alt at this point? Why not use +gns or +onion > or +eliotsfavoritenamespace? > > That sounds like a very intriguing idea, and might be better than +alt. > > - How might or should this be reflected in the browser bar? > > Personally, I would treat an "x+y://" scheme as unrelated to "x://", and make the distinction clear to users >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
