On Mon, Oct 24, 2022 at 7:18 AM Ben Schwartz <bemasc= 40google....@dmarc.ietf.org> wrote:
> > > 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 > As noted by Timothy Mcsweeney in the original thread, sub-delim characters are not permitted in the scheme. However, my view on potential parsing and encoding is something that the current URI specification already supports. I think the namespace indicator definitely is something that should be coupled with the "authority" portion of the URI. We're talking about how to resolve the host portion of a URI, and while that might be expanded outside of DNS, the URI spec already lists other non-DNS ways that a name might be resolved. In Seciton 3.2.2 (Host) of RFC 3986) and specifically and explicitly supports whatever is needed by resolution mechanisms in the "reg-name" syntax, with the expectation that parsing and resolving a "reg-name" is handled outside of the scope of URI parsing, so long as the extraction of the "reg-name" works (i.e. that "reg-name" complies with the URI specification). And "reg-name" is essentially the normal characters from DNS, plus "sub-delim" characters. That list of characters includes the "!" character, which I think would best enable encoding to indicate new name systems, e.g. using GNS as an example: gns!some.gns.name.gns.alt (The suffix gns.alt is to ensure that if for any reason leakage to DNS does happen by the GNS resolver, it won't get a real DNS answer. Yes, that is redundant, but by design.) Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
