> On 24. Aug 2022, at 22:13, Schanzenbach, Martin <mschanzenb...@posteo.de> > wrote: > > Signed PGP part > > >> On 24. Aug 2022, at 20:22, Joe Abley <jab...@hopcount.ca> wrote: >> >> On Aug 24, 2022, at 11:27, Schanzenbach, Martin <mschanzenb...@posteo.de> >> wrote: >> >>> 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. >> >> Fortunately (at least as far as understanding domain names and IDNA are >> concerned) you don't have to. A-Labels are case-insensitive in the manner >> that "Alt" and "alt" are the same domain name. There are no such >> expectations of U-labels. >> >>> 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: >> >> Sure, there are no protocol police. All applications are free to ignore user >> expectations and standards if they want. > > No, you misunderstand what I said. What I meant was: > > " > In principle, an application ought to take user input of a domain > name and convert it to the set of Unicode code points that represent > the domain name the user intends. As a practical matter, of course, > determining user intent is a tricky business, so an application needs > to choose a reasonable mapping from user input. That may differ > based on the particular circumstances of a user, depending on locale, > language, type of input method, etc. It is up to the application to > make a reasonable choice. > " -- RFC5894 >
And, to get back on topic, maybe what the alt-draft needs is a similar formulation with respect to handling of non-DNS .alt names for non-DNS-aware applications. >> >> >> Joe > > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
