I pose human factor and UX questions: Do you think people expect to have to do things at url Point and Click time to select which namespace is resolved?
If I specified my.domain.gns.alt do I expect the entity behind my.domain to be the same in gns and in dns? If I am writing gns resolution code do I remove gns.alt before resolving? Steven's "what is in SubjectAlternateName and SNI" is a good one too. I keep harping on about the omnibar. Start at the omnibar and a URL and tell me what happens! G On Fri, 19 Aug 2022, 12:18 pm Ben Schwartz, <bemasc= 40google....@dmarc.ietf.org> wrote: > > > On Mon, Aug 15, 2022 at 7:36 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> > wrote: > >> >> Hiya, >> >> On 16/08/2022 00:22, Paul Wouters wrote: >> > it’s a whole new gold rush. >> I don't get that. The thought experiment(*) is a putative >> .alt setup with FCFS registration for 2LD equivalents and >> where recursives and all DNS servers are expected to barf >> on queries for such names one way or another. I don't see >> what'd attract many people to register names there myself >> but maybe I'm naive. What'd be the attraction? >> > > Perhaps you haven't been following the W3C DID process [1]? The > "registrable .alt" proposal closely resembles the functionality of the DID > "method" system, and you can see the registrations that have poured in > there [2]. I note that some of the registered names already raise some > notable potential for trademark collision or user confusion. > > I agree with Paul Wouters' analysis of this problem space. I would add > that the main functionality of "registrable .alt" is already available by > simply registering the desired names in any open, registrable TLD such as > ".net". I question whether any perceived benefits over the existing DNS > registry system would justify the Very Large Can of Worms that the IETF (or > IANA) would have to manage. > > I haven't fully grasped the DID system yet, but it seems to add a new > meta-namespacing point under a new URI scheme. This strikes me as far more > architecturally sound than trying to claim that a certain slice of domain > names are both unresolvable in the DNS and yet presumptively safe to use in > all the myriad URI schemes and other subsystems that make use of domain > names today. > > Also, I think the mental model of a "resolution plugin" needs more > attention, as it appears to presume the existence of an abstract interface > that does not exist. For example, apps that use DNS increasingly rely on > specific RR Types (e.g. SRV, HTTPS, SSHFP). Shall we demand that all .alt > registrations maintain the full semantics of every current and future DNS > RR Type? > > > [1] https://en.wikipedia.org/wiki/Decentralized_identifier > [2] https://w3c.github.io/did-spec-registries/#did-methods > > >> >> Ta, >> S. >> >> (*) To be clear, I'd have no objection to somewhat more >> onerous registration rules, like RFC required or whatever >> so the above is just trying to understand what makes you >> think there'd be enough registrations to be a problem in >> that particular setup. >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
