In message <d11357c2.942b%[email protected]>, Edward Lewis writes: > I admit that this thread rolled off my screen before I noticed it. Iâm > going to pick on a few things said here that extend backwards in the > thread a bit. > > On 2/22/15, 15:53, "Mark Andrews" <[email protected]> wrote: > > >master files are ASCII files. > > Maybe they are supposed to be. But what got my goat recently was trying > to parse a zone file that had UTF-8 in it. There are zone master files > that are not purely ASCII in the wild.
There are files that people want to be master files with UTF8 in them but they are not master files. > Not saying that it is right. Saying that they deserve to be recognized. > I mean, thereâs every reason that the file can be put to use. I had > considered extending the parser I had to do so, then decided for my use > case the effort wasnât worth it. > > >If you have a file that contains u-labels it is not as master file. > > Walks like a duck, talks like a duck, smells like a duckâ¦but yes, > according to some dusty old documents - written before u-labels were > imagined [by the community producing the documents] - they arenât. And also that IDNA explicity does not require changes to nameservers. > >It can be converted to a master file by processing the labels and > >turning them into a-labels. > > Bingo! > > >Master files are supposed to be able to be processed by nameservers > >that are not IDNA aware. > > Thereâs no reason that we canât add an adjective to "master file.â Then > folks writing RFPs, contracts, work orders can specify what is best. If I > choose to run antiquated software Iâll ask for antiquated master file > s. If I choose software that reflect the native language of my staff, I might > want master files that have a different formatting. I repeat. They are not master files. They a 'u-files' or whatever name we decide to give them. That said non-ascii doesn't mean that the file contains UTF-8. Lots of "master files" contain ISP-LATIN-FOO or Windows-XXXXX. Making any assumption about the character set is plain fraught with danger. IDN goes native -> utf8 (u-labels) -> a-labels. > Orthogonal to my desire to document this is the desire to see how far we > can get away from assuming everyone has ASCII knowledge. NOCs shouldnât > have to list a particular (human) language as a requirement. > > >If you use master files extensions such as $TTL, $DATE and $GENERATE > >then you need to ensure that the nameserver can process them. A > >cannonical version of the master file contains none of these > >extensions. > > I know of name servers that do not read master files at all, so no, you > canât âensure." Master files are a zone transfer method. You only need a tool to convert them to whatever you are using internally to meet RFC 1034 requirements. i.e. here is a master files for zone example.net. Please load it into your nameserver. There is no requirement for a nameserver to read then directly though many do. If you "extend" the format you need to know apriori that the receiver can handle it. We started out with a request for a "canonical master file format". That is ascii and only ascii. Yes lowest common denominator. > >Additionally you need to be aware of what types the nameservers > >supports otherwise you should encode all non RFC 1034 records as > >unknown types. Unfortunately RFC 103[45] failed to specicify how > >to encode unknown types in master files which makes it impossible > >to have a master files that contains new types be readable by all > >nameservers in existence. > > Iâm well aware of this. RFC 1034/1035 didnât specify how youâd include > write an RRTYPE they didnât invent, not even the ones in "New DNS RR > Definitionsâ RFC 1183 (October 1990, Experimental - ok, outside of RP > non are in use and RP may or may not be). Itâs a shame RFC 1034/1035 > didnât cover this (but there were many omissions, so itâs not surprising) > but we deal with that. The printed form of unknown record types is no > different that the printed form of, say AAAA (in some use [wink], not in RFC > 1034/1035). > > The point is to define a way to print data into a file. And not even âaâ > way, but have a lowest common denominator and then more useful > âadjectives.â It doesnât matter if parsers today âbreakâ or > âfailâ to > consume a particular format - if that happens, operators can perform âtech > refreshâ if they need. > > PS - I want to emphasize that LDH is not a requirement for a domain name. > (I think that point was made already.) A label can have only LDH, it can > have punydode, it can have arbitrary binary code. Printing a label (as it > is seen in a file) isnât the same as converting a name for registration. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
