Robert Elz wrote: > From: John C Klensin <klensin@jck.com> > | So I believe that the "future RRs" language with regard to > | binary labels in 1034 and 1035 must be taken seriously and as > | normative text: if new RRs (or new classes) are defined, they > | can be defined as binary and, > > Have you actually thought about what you have just said? That is, > the rules for naming the DNS tree depend upon the data that is stored > there? > > Do you seriously mean that? I had the same initial reaction a while ago. However, once you think about it some, its not really such a bad idea. I mean, DNS is the only major protocol which does not strictly define the allowable syntax for each data-type. The result is that we get things like user_name.example.com in homepage URLs, which further results in things like BIND 9's warning mechanisms. We can rant about idiots ignoring the rules all day long, but it seems to me that clearly defining the data-types in a way that software can enforce the allowable syntax is the only way out of this mess in the long term. BTW, I don't agree with John's insinuation that binary is an exception. Clearly binary labels are fully legitimate today (albeit very problematic). What this means however is that all RR types will have to be explicitly defined (TXT = anything, A = safe-set, CNAME = aliased-data, and so forth). There's a related problem here, which is that DNS specifies a way to escape characters locally (that "\65" equates to 0x41 and not "A"), but it doesn't specify a way to transfer this marking in the message. This is the counter-problem to the display problem mentioned in the other message, and it has equal ramifications. Defining data-types is one way to solve this problem, as John suggests. Extending the message structure to allow these markings to survive from end-to-end is another. I would prefer the former given that there are other issues which would be solved by that approach already (plus the fact that there's no reason why 0x41 should need to be used in A RRs). > One easy (though perhaps not desirable, I don't know) solution would be > to simply restrict the case insensitive part, as far as the DNS is > concerned, to ascii only, so that A==a but Á!=á. Eventually doing away > with case insensitive for all labels seems like a good idea to me. That's the direction things are heading. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/