Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt

["Eric A. Hall" <ehall@ehsco.com>]

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/