Re: [idn] One profile for domain names, or many?

["Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>]

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

> One clarification is that it isn't expectated that other profiles
> will be used for human input...  The principle intention is to allow
> applications to make use of the domain names they need to function in
> the namespace, and that these names probably won't be entered by users
> directly.
>
> Moreover, these examples work with the existing STD13 octets.  In that
> regard, the intention is to facilitate the migration of STD13 octets.
> This is especially important if that usage is going to be prohibited.

That's very interesting.  Maybe there's a middle ground here.

Suppose the IETF were to issue a clarification of the DNS spec stating
in no uncertain terms that bytes 80..FF in domain names must match
exactly, and that there is no standard interpretation of those bytes as
characters (not for any existing DNS services anyway).  Then I wouldn't
object if applications that don't like Nameprep were encouraged to use
8-bit names in DNS for non-human-oriented purposes.

IDNA with its single profile would govern the universe of textual domain
labels (labels composed entirely of well-defined characters, not just
opaque bytes).  These labels are intended for human users and are used
in a wide variety of protocols, not just DNS.  Applications that want to
use human-accessible domain names containing non-ASCII characters in a
standard representation would use IDNA (they would have nowhere else to
turn).

Outside the universe of textual domain labels are the STD-13 domain
labels that contain at least one byte in the range 80..FF.  I call such
labels non-textual because there is no standard interpretation of 80..FF
as characters (although applications can locally map them to characters,
at their own risk).  These labels are specifically DNS-things (I've
never heard of them being used in other protocols).  These labels are
already outside the scope of IDNA, because IDNA can only cope with
well-defined textual labels.  Applications that don't like Nameprep and
don't care whether their domain labels are easily accessible to humans
can ignore IDNA and stick with STD-13 and their own local interpretation
of the bytes, and prepare their labels in any way they like.

Eric, would you be satisfied with that?  What do other people think of
that idea?

Note that we can't stop applications from using 8-bit STD-13 domain
names.  The only question is under what circumstances we encourage or
discourage it.

> Where will the existing users of eight-bit domain names go if:
>
> 1) they can't stay in STD13 because it has been prohibited

We are not going to try to overturn STD-13.  Language in the IDNA spec
that appeared to be doing that was a mistake, and will be fixed.

AMC