WG Review: Internationalized Domain Name (idn)
Paul Hoffman
paul.hoffman at vpnc.org
Thu Feb 28 20:49:42 CET 2008
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
More information about the Idna-update
mailing list