Re: [idn] WG last call documents

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

"Adam M. Costello" wrote:
> 
> "Eric A. Hall" <ehall@ehsco.com> wrote:
> 
> > The problem with the current spec is that case-folding and
> > normalization will impose restrictions on these assignments.  This
> > is inappropriate for a generic i18n domain name label syntax.  On a
> > secondary note, normalization and lowercasing are problems having to
> > do with hostnames
> 
> The existing DNS requires *all* domain labels to be case-insensitive,
> not just host labels.  See RFC 1035.  So domain names are already
> inappropriate for any data types that are case-sensitive.

The rules that govern STD13 labels only apply to STD13 labels. This is
somewhat irrelevant to the subject at hand.

The rules for i18n domain names can say that a domain name contains
explicit character codes. If the app/user is in the ToASCII step then the
label is not an STD13 label. Different rules can apply for those labels.
Note that I am not saying that the rules should be enforced by ToASCII
(they should be enforced by the applications that generate the domain
names), but that if the label needs to go through ToASCII then it is an
i18n domain name, and not an STD13 domain name. Conversely, if the label
does not need to go through ToASCII or if it falls out of ToASCII
unmolested, then it is an STD13 domain name.

> > > The prohibited list in nameprep is pretty small, and they're all
> > > characters that you'd have to be somewhat crazy to want to use in
> > > domain names.
> >
> > I think you meant hostname here.  Remember that hostname rules apply
> > to delegations.  Domain name rules are a broader category which also
> > include things like SRV, email addresses, and so forth.
> 
> I understand that not all domain names are host names.  I meant domain
> names.  Have you actually looked at the prohibited list in Nameprep?  I
> think it will be extremely rare that someone wishes they could use one
> of those characters in a domain name (of any type).

It's the case-folding and normalization that I'm worried about. We should
not be enforcing this kind of reduction on every label that can be stored
in the namespace. And if we can make that distinction, why worry about
prohibitions? Even the issue with leading combining characters is
something that can be foisted onto the hostname subset rules, and simply
noted in the domain name rules as an issue that additional subset
specifications should be aware of.

If there are some codes that flat-out break IDNA which can be REASONABLY
withheld from the generic i18n domain name rules, then by all means, those
should be prohibited. But for the most part, everything that has
historically been described in nameprep should be in the i18n hostname
rules and enforced by the applications, protocols and data-formats. The
generic i18n domain name rules should be as flexible as possible, and IDNA
should only encode/decode the generic i18n domain names.

This model will allow additional subordinate profiles to be defined by any
other WG as needed (EG, mailbox names), and IDNA will still function as
expected. Too many restrictions and we will end up with label- and
data-specific codecs, which is absolutely not what we want.

> I was basically told not to discuss email local-parts on this mailing
> list.

We have talked about email local-parts several times. I'm not sure what
you are referring to here.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/