Hi, > On 24. Aug 2022, at 16:28, Peter Thomassen <pe...@desec.io> wrote: > > Hi Joe, > > On 8/24/22 10:13, Joe Abley wrote: >> So the question is not whether to allow mixed capitalisation; the question >> is why we would intentionally change a fundamental expectation of domain >> names to accommodate names and resolution protocols that we largely don't >> have any requirements for because with one notable exception they don't >> exist? > > I would argue that > > - applications that understand a given non-DNS naming scheme under .alt do > not necessarily share those "fundamental expectations" (it hasn't been shown > that they do, it is being suspected); > > - as to why we would settle on one variant: it would reduce ambiguity of > naming for names in the .alt namespace. I don't see why we need to impose on > non-DNS protocol designers that they have to mess with case insensitivity > just because it's been like that historically. > > It would be interesting to hear an opinion of a non-DNS protocol designer > (e.g. GNS), so until that happens I'll stay shut. Soapy ;-)
(This is my third attempt for this mail. It has given me a lot to think about. Here is a first try) In GNS, the application decides what the current user expectation is. We (I) learned that this is a good approach after conversations with our reviewers in particular since it is very difficult to distinguish what "case" actually is with respect to i18n. GNS, as in the protocol, does *not* consider "Example.gns.Alt" and "Example.gns.alt" to be the same name. But, in GNS, we would never resolve ".alt" or ".gns.alt". Those are just "suffixes". GNS users (or implementors) will ship with Root Zone configurations. E.g. .com.gns.alt = <somePublicKey> .ch.gns.alt = <someOtherPubkicKey> and the user will be able to resolve "example.ch.gns.alt" They will NOT be able to resolve "example.ch.gns.Alt" But, they may configure .ch.gns.Alt = <aThirdPublicKey> and then it is resolvable. If the application decides that the user expectation is that "example.ch.Alt" IS "example.ch.alt", then the application is invited to make the user happy accordingly. The same is true for subtle differences in case handlings with respect to i18n. This is not the (GNS) protocol's business. Is ".Alt" the same as ".alt"? => Please figure it out application developer! Will a GNS-unaware application leak "example.ch.gns.alt" into DNS if "Example.ch.gns.Alt" was not found by GNS? Probably. But it will get a NXDOMAIN if the ".alt" TLD is reserved. Again, applications are invited to mitigate such mistakes accordingly. I would expect that some applications that ALSO use DNS as a fallback resolution mechanism will consider the name as <GNS-prefix><DNS-suffix> and check for the case-insensitive ".gns.alt" label. Possibly autocorrecting automatically or notifying the user. BR > > Best, > Peter > > -- > https://desec.io/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
