[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [idn] host name vs. domain name
- To: firstname.lastname@example.org
- Subject: RE: [idn] host name vs. domain name
- From: Paul Hoffman / IMC <email@example.com>
- Date: Tue, 21 Mar 2000 08:48:50 -0800
- Delivery-date: Tue, 21 Mar 2000 08:49:08 -0800
- Envelope-to: firstname.lastname@example.org
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 email@example.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
--Paul Hoffman, Director
--Internet Mail Consortium