> On 23. Aug 2022, at 13:02, Ray Bellis <r...@bellis.me.uk> wrote: > > > > On 23/08/2022 10:22, Andrew McConachie wrote: > >> The only restriction that seems reasonable to me is prohibiting zero length >> strings. This list convinced me other restrictions would be a bad idea. > > There will be a very long tail of systems out there that do not know about > ".alt". > > How would those systems respond when passed a domain-style name that does not > meet domain-style syntax rules (specifically those for total length and label > lengths) ? > > If the answer is that they return something other than EAI_NONAME (or > HOST_NOT_FOUND for gethostbyname) then this needs to be considered further. > > IMHO, if you want to be in a carve-out of the domain name space, you still > need to play by the domain name space's technical rules, in a way that's > backwards compatible with systems that don't know about the carve-out and > will assume that veryverylonglabel.foo.alt _is_ a domain name.
I think the notion that there is strict "format" of a name and that if it is not in that format is not actually part of the same namespace is already behind us. If that were the case then we do not need .alt at all. For example, GNS names are UTF-8. They are not LDH or any kind of DNS-compliant wire format. I think one way to look at is is that we try to solve a problem with the display/presentation of names in alternate name systems and how they can be confused by applications but also humans with DNS names. Applications (to some degree) have to deal with malformed names anyway as part of the user input handling. If they consider the given .alt-name malformed because they only expect DNS names, then that is within the expected behaviour. If the application crashes because of such a name, it would also crash because of data corruption or faulty user input. And that is a bug in the application, possibly even a security issue if it leads to a buffer overflow etc. BR Martin > > Ray > > _______________________________________________ > 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
