[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [idn] host name vs. domain name



At 10:21 AM 3/21/00 -0500, John C Klensin wrote:
>The point I think Bill and I were circling around is that it is
>possible to believe that some applications need
>_internationalized_ DNS and others don't, or don't as much.

It is possible to believe this when first thinking about it, but I think 
there are strong social, security, and technical reasons against it. In my 
off-line discussions with some people who have proposed essentially what 
you have in this message, I have come up with two general themes for why I 
think this kind of split won't work.

- The main social problem with a split DNS is that companies want a single 
identity. Imagine that you get to a web site by entering www.dürst.com, and 
near the bottom of the main page it says "Contact us at info@duerst.com". 
That would look bad, sloppy, and/or confusing.

- The main security issue is PKIX certificates, which do not allow 
internationalized domain names. This means that www.dürst.com cannot be 
used with SSL/TLS because it cannot get a certificate whose identity 
matches its host name.

- The main technical problem is that it would make using 
non-internationalized system administration tools impossible to use for 
sites with internationalized names. If you are a sysadmin with a 
non-internationalized tool (such as SNMP), you can't include www.dürst.com 
in your scope of administration.

Fortunately, I don't believe that we need to split the protocols along 
internationalized/non-internationalized lines. Dan Oscarsson's proposal 
uses a new DNS query/response bit to identify internationalized names, with 
a fallback equivalent of every name that can be sent using 
uninternationalized DNS methods. Instead of using a new RR as John has 
tentatively suggested we think about, Dan uses a different query; one or 
the other protocol might be better, and that can be discussed later.

I foresee that we might even modify Dan's proposal to say "if you are a 
non-internationalized protocol and you are handed a downcased name that you 
want to look up, you must first upcase it and then query the same way that 
internationalized programs do". That is, the IDN might have just one 
query/response form (which would have the name parts as UTF-8 on the wire), 
and all protocols using internationalized names must use that one form. 
There would be a single canonical transcoding for protocols that cannot 
pass internationalized names within themselves can use to say "this is an 
internationalized name but you're seeing it in the old-DNS-compatible 
form". When those programs want to use the DNS, they have to upcase, and 
they have to downcase any responses they get from the DNS.

In this way, we can (hopefully) have a slightly-splt DNS but no protocol 
splits.

--Paul Hoffman, Director
--Internet Mail Consortium