John C Klensin wrote:
> The other is that true binary labels are permitted by the DNS There is no such thing as a true binary label as far as the DNS transfer protocol and/or storage subsystem is concerned. Where there is a mapping, it occurs within the realm of the application that is using DNS, and not within the DNS network service itself. That is the only way which allows *any* new usages to be defined. Otherwise, no systems could ever tell what format *any* domain name was stored in. Not only would this include interpretations of eight-bit characters, but it would also include any case-specific ASCII alphabetic mappings which might be required for a given RR. For example, NB that RFC 1035 defined case-specific owner names for MB, MG, etc, but even those are compared using the simple rules. If we had different storage rules for "binary" then those RRs would have to be treated special, but they are treated the same as every other RR. Furthermore, nothing like those RRs could _ever_ be defined and deployed again unless the entire Internet architecture were upgraded to support that specific RR. Also keep in mind that caches are not the only transparent boxes on the network. Many DNS servers also allow new opaque RRs to be defined as simple octet streams. Deployment of new RRs practically depends upon this feature. The notion that there is such a thing as a special "binary" label is partly the fault of the DNS community since this term is frequently used to describe names which are "not hostnames", but really there is no such thing. The "binary" name you describe is the default domain name, and hostnames are a special octet-restricted subset of those names. They all share the same storage/transfer/mapping rules, however, which is octet maps with case insensitive comparison for ASCII letters. The infrastructure would not function otherwise. > > I suppose you could argue that the ~standard RRs from STD13 > > are special and do not have any such meaning, although I would > > argue against it. > > And we would certainly continue to disagree, since I read "all I can't do this anymore. I would encourage you to take this to namedroppers where it can be debated to your satisfaction. IMO, the recommendations for hostname-compatible names are only suggestions, and not requirements. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
