WG Review: Internationalized Domain Name (idn)

[Paul Hoffman]

At 9:57 AM -0800 2/26/08, The IESG wrote:
>A new IETF working group has been proposed in the Applications Area.  The
>IESG has not made any determination as yet.  The following draft charter
>was submitted, and is provided for informational purposes only.  Please
>send your comments to the IESG mailing list (iesg at ietf.org) by March 4,
>2008.

First off, this WG should definitely be formed. It is difficult to 
judge consensus when making incompatible changes to deployed 
protocols, particularly when it is hard to determine who needs the 
changes. Having a WG with on-list consensus calls on specific topics 
will greatly improve the chance that the work finishes. We need to 
revise IDNA, and a WG at this time is an appropriate way to do it.

>Internationalized Domain Name (idn)

A better choice would be "Revision of Internationalizing Domain Names 
in Applications (idnabis). This new WG is *not* taking on all the 
topics of the original IDN WG (for example, changing the on-the-wire 
encoding is explicitly disallowed). The charter is clear that this is 
a revision to IDNA; the name should as well.

>IDNA is currently tied to an obsolete version of Unicode.

s/obsolete/old/. There is nothing on the Unicode Consortium web site 
that says that version 3.2 is "obsolete".

>The WG will work to ensure practical stability of the validity
>algorithms for IDNs (whether based on character properties or
>inclusion/exclusion lists).

This single sentence is not sufficient guidance to the WG, nor 
comfort to the IETF community, about stability. All of the current 
proposals for change have serious ramifications for transition of 
implementations. For example, excluding DNS labels that are currently 
allowed and are widely used needs to be weighed against the 
advantages of adding restrictions. Listing the changes in the 
standards themselves will help bring consensus in the WG and during 
IETF Last Call. The following sentence should be added to the charter:

All changes from the existing RFCs that will affect interoperability 
with currently-deployed software, and the transition implications of 
those changes, must be clearly described in the new standards,

>The work is currently organized into four deliverables, all
>Standards Track. The WG will verify that it has consensus
>to adopt the proposed documents as a starting point. The
>Overview document with explanation and rationale is intended
>for Standards Track status because it has definitions and
>other normative text required by the other documents. The
>protocol specification explains how to map non-ASCII
>characters into ASCII DNS labels. It relies normatively on
>two other documents that are separate for readability: the
>bidirectional algorithm specification and the character
>validity tables. The validity of characters in IDNs is
>almost exclusively based on Unicode properties but is
>organized as tables and categories for readability.

This paragraph sounds like the WG needs to keep the four documents 
separated. The previous IDN WG got a fair amount or criticism for our 
decision to split the protocol into four documents; this WG shouldn't 
be bound to do the same unless it really wants to. A proposed change 
would be to remove the second sentence ("The WG will..."), reword it, 
and move it to a separate paragraph that gives the WG more space to 
decide what it wants. For example:

The WG will start by finding consensus on the type of document or 
documents it wants as its output, most likely using the current work 
described above as a basis.

>Goals and milestones:
>
>Mar 08: WG Last Call for Overview/Rationale document
>Apr 08: Revised Overview/Rationale document
>Apr 08: WG Last Call for Protocol, Bidi and Tables documents
>May 08: Revised Protocol, Bidi and Tables documents
>May 08: Review Overview document again if needed
>Jul 08: Request for publication for all documents

Reading the design team mailing list shows that some of the documents 
have had repeated significant technical changes made to them on a 
regular basis. There is general agreement that we need a lot more 
input from language and character experts from outside the IETF to 
validate the proposed changes. We all know that tight milestones in 
the IETF are not serious, but outsiders will not know that. These 
dates will seem more like railroading than a call for input. Further, 
these milestones essentially force the WG to use the document 
structure of the current documents. And yet further, WGs that have 
their overview documents come out first often regret it later when 
they need to make changes to the protocol in WG Last Call.

A more reasonable list would be:

Mar 08: WG formation
Apr 08: Decision on form and structure of the WG document set
Aug 08: WG Last Call on WG document set
Oct 08: IETF Last Call on WG document set

I hope this helps. Getting the charter right will help as people who 
haven't been watching the design team come into the process.

--Paul Hoffman, Director
--VPN Consortium