Re: [idn] IDN refocus, v4

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

James Seng/Personal wrote:

> It become more apparent that it is dangerous to into the discussion of
> internationalized domain names vs internationalized host names. Such
> discussion is half-technical and half-policy and this group may not have
> sufficient information to determined what is a considered a valid
> hostname, and that is subjective to registries.

I don't want to make a big deal out of this point, but I would like to say
that the distinction is required for basic functionality. For example, SRV
entries use underscore, which is not a permitted character in nameprep
(rightly) for use with host names, so domain names and host names have to
be defined individually if both are to function.

The distinction is not that fuzzy. Domain names are simply sequences of
octets, while host names are those domain names which identify connection
targets (either in part [relative] or in sum [FQDN]) and which conform to
the rules provided by RFC952, STD3 and STD13. We really need to define
i18n equivalents in order to meet the requirements of the DNS community.

> >   4) Provide proposals to DNSEXT for handling these label encodings
> >      in the DNS service.
> >
> >      [ ] yes
> >      [ ] no
> 
> Longer term goal maybe.

My understanding (which may be wrong) is that DNSEXT is leaving
specification to us but reserving the right of ratification. Some work is
likely to be required. If the IDN WG task list will be fluid this will
show up sooner or later so I'm not going to argue the point.

> >   5) Provide guidelines for the protocol and data-formatting groups
> >      to use when they extend their services to tag, store, decipher
> >      and/or display (as necessary) these encodings.
> >
> >      [ ] yes
> >      [ ] no
> 
> Care to explain a bit more?

Defer all display processing, but give guidance on basic elements such as
boundaries and illegal conditions. For example, we know that seven-bit
domain names cannot be encoded in ACE, are harmful when provided, and MUST
be discarded when discovered, and this information has to be relayed to
other working groups.

> Define an IDN label encoding that protocols and applcations can used to
> store and represent i18n domain names.

I see this as an opportunity to establish the consensus, which would
facilitate finite deliverables for the WG. We can cut the overall timeline
down if we go through the pain once and for all. Once we can agree on the
objectives, arguing over deployment mechanics is a lot less stressful
(hopefully). We really should come to terms with the objectives first, or
else this will remain a perpetual open issue.

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