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

Re: [idn] Re: Just send UTF-8 with nameprep



"Eric A. Hall" <ehall@ehsco.com> wrote:

> Dual-mode servers would flag specific RRs as having legacy or IDN
> names, or having both flags. Some legacy domain names will look like
> UTF-8 names (any eight-bit binary label is legal), and so there must
> be a way to flag specific entries as being either a legacy name or an
> IDN (or both).

Okay, now I see what you meant by multiple namespaces.  On the one hand,
there's the world of ASCII names and IDNs.  On the other hand, there are
things that are neither:  8-bit names that predate any IDN standard.
Let's call such things "freaks".  :)

First, I question whether there really are any such names, and if there
are, whether we should care if we break them.

But assuming for the moment that we want to support these freak names,
we only need one flag, the freak flag.  An old-style DNS query can match
ASCII names (including ACEs) and freaks, but not IDNs.  A UTF-8 EDNS
query can match IDNs and ASCII names (including ACEs), but not freaks.
(I suppose you could also define another EDNS query for freaks, if you
wanted everything to be accessible via EDNS.)

There is no need for a second flag.  If a label contains only LDH
characters and conforms to ACE syntax, then it *is* an ACE, regardless
of whether it was obtained via an ASCII transport or a UTF-8 transport
or whatever.  There are no labels whose native (Unicode) form conforms
to ACE syntax.  To allow that would just confuse people.

> *hostnames* for POP3 servers are not specifed by the protocol. You
> have to tell your POP3 mailer where it should go to pickup mail; that
> hostname is what I'm referring to.

Okay, then this is a user-interface issue just like the ping example.

> This should be the general rule for all lookups (not just A RRs).  In
> the case of application-specific queries, the application must be
> sure to only use domain names which are legal for that application.
> IOW, if an application is presented with an IDN but the protocol
> specifications do not allow for the use of IDNs, then the application
> should down-convert the IDN and use that (or return an error, or
> whatever is appropriate).

I'm not sure what you mean here.  Let's take POP3 for example.  The
protocol doesn't allow for the use of IDNs, but that's unrelated to
the question of whether a POP3 client can connect to a server named by
an IDN.  If the client is IDN-aware, and has a UTF-8 resolver at its
disposal, there's no reason it shouldn't accept a UTF-8 server name from
the user and look it up.

AMC