> On 24. Aug 2022, at 18:46, Paul Wouters <p...@nohats.ca> wrote: > > On Aug 24, 2022, at 11:27, Schanzenbach, Martin <mschanzenb...@posteo.de> > wrote: >> >> GNS, as in the protocol, does *not* consider "Example.gns.Alt" and >> "Example.gns.alt" to be the same name. > > FYI, on many mobile phones, words at the start are automatically capitalized, > so you are going to experience many user problems if your protocol sticks > with this assumption. Punting this to the application to fix up or punting it > to the OS to configure duplicates with case differences is going to fragment > how well gns works on various OSes or applications. As Security AD, if this > was an IETF protocol I would put up a blocking DISCUSS to address before > allowing the document to proceed. > > A well known mistake in this area from within the IETF is that the SMTP > protocol considers the LHS of an email address case sensitive, so paul@ and > Paul@ are considered two different destinations by the protocol and the > entire world of SMTP servers ignore this and treats them as the same. > >> 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. > > The average enduser isn’t going to understand or able to change any of this. > >> 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! > > Whether I own a name now depends on the application developer? That will > result in endusers giving up on your application and/or protocol as well. > >> 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. > > Also if .alt is not reserved. > >> Again, applications are invited to mitigate such mistakes accordingly. > > See above. I am ….. perplexed. > > Anyway, we at the IETF are not here to tell you how to do your non-IETF > protocol, but this discussion does feel to me that this draft isn’t very > useful to your protocol and also doesn’t build up my confidence that later on > GNS application developers are told to “help” the user with names not ending > in .alt, eg they end up squatting the entire DNS namespace anyway.
Well, maybe we misinterpreted the advice or took it to an extreme, but why was Nameprep obsoleted and according to RFC 5891 Section 3.1. (2.) talking about specifically NOT case folding U-labels for comparison? I do not want to derail this conversation with this. We would theoretically still be convinced to change this. But that is not relevant to the original question. BR > > Paul > > _______________________________________________ > 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
