Subject: Re: WG Review: Internationalized Domain Name (idn)

From: Ted Hardie <[email-masked]>
Date: Mon, 3 Mar 2008 09:05:54 -0800

Thanks to Stephane for pointing out the short fuse on this.  I personally
believe that a longer discussion and a cc to working groups like EAI
and DNSEXT would have gotten more adequate review.

Comments on the text below.

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 ([email-masked]) by March 4,
>2008.
>
>Internationalized Domain Name (idn)
>=============================
>Last modified: 2008-02-18
>
>Current Status: Proposed Working Group
>
>Chair(s):
>
>TBD
>
>Applications Area Directors:
>
>Lisa Dusseault ([email-masked])
>Chris Newman ([email-masked])
>
>Applications Area Advisor:
>
>Lisa Dusseault ([email-masked])
>
>Mailing List:
>
>General Discussion: [email-masked]
>To Subscribe:
>http://www.alvestrand.no/mailman/listinfo/idna-update
>Archive: http://www.alvestrand.no/pipermail/idna-update/
>
>Description:
>
>The original Internationalized Domain Name (IDN) WG set the
>requirements for international characters in domain names in
>RFC 3454, RFC3490, RFC3491 and RFC3492 in 2002. These documents
>were tied to Unicode version 3.2 and an update to the current
>version (5.x) is required to accommodate additional scripts.
>In addition, experience has shown a number of real or perceived
>defects or inadequacies with the protocol. Some of them are
>described in an IAB review (RFC4690), which also provides a good
>introduction to the subject matter.

>IDNA is currently tied to an obsolete version of Unicode. This WG
>is chartered to untie IDNA from specific versions of Unicode using
>algorithms that define validity based on Unicode properties. It is
>recognized that some explicit exceptions may be necessary in any
>case, but attempts would be made to minimize these exceptions.
>

First, the two paragraphs above repeat each other a bit (naming
specific versions in one and using characteristics in another).
Second, this going pretty far into solution space, without a discussion
of where the community agreed that this is the solution.  Note
that I am not saying I disagree with using Unicode properties
here, but pointers to both the discussion docs and how Unicode
is managing this property seem necessary to give this adequate
review.  It may be the input docs given below are the only
discussion, but I hope that at least some pointers to Unicode consortium
documents can be made here.

There is no liaison information given; is the WG expected to maintain
a liaison to the Unicode Consortium or is the IETF liaison expected to
take on any new work as a result of this?  (Obviously, there is a serious
difference between work we can do based on already published  or
otherwise agreed specifications and work which requires coordination).

>Additional goals:
>
>- Separate requirements for valid IDNs at registration time,
>vs. at resolution time

I think you need to define what "resolution time" means here.
For better or worse, IDNs now appear in authority sections of
URIs and not all of those are resolved at all.  If what you mean
is "Separate requirements for valid IDNs in registration contexts,
in identifiers, and in relation to the wire format of DNS", then I
think  you need three categories.

>- Revise bi-directional algorithms to produce a deterministic
>answer whether a label is allowed or not
>- Determine whether bi-directional algorithm should allow
>additional mnemonics labels

Can you unpack this?

>- Permit effective use of some scripts that were
>inadvertently excluded by the original protocols.
>
>The constraints of the original IDN WG still apply, namely to
>avoid disturbing the current use and operation of the domain
>name system, and for the DNS to continue to allow any system
>to resolve any domain name. The basic approach of the original
>IDN work will be maintained -- substantially new protocols or
>mechanisms are not in scope. In particular, IDNs continue to
>use the "xn--" prefix and the same ASCII-compatible encoding,
>and the bidirectional algorithm follows the same basic design.
>
>The WG will work to ensure practical stability of the validity
>algorithms for IDNs (whether based on character properties or
>inclusion/exclusion lists).

This is ambiguous.  If this is meant to say that the WG can decide
after starting its work that it must abandon the character properties
design direction and go to inclusion/exclusion lists, then the statement
above giving design direction needs to be changed.  If this is meant
to say "backwards compatibility with X" what X is is not clear here.

>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.
>
>Goals and milestones:

These milestones are either completely impractical or
indicate strong confidence on the part of the IESG that
very minimal work will be needed to transform the input
documents into output.   If it is the latter, why is a WG
being formed at all, rather than using independent submission?

				Ted Hardie

>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
>
>Documents:
>
>http://tools.ietf.org/html/draft-klensin-idnabis-issues
>http://tools.ietf.org/html/draft-klensin-idnabis-protocol
>http://tools.ietf.org/html/draft-faltstrom-idnabis-tables
>http://tools.ietf.org/html/draft-alvestrand-idna-bidi
>
>_______________________________________________
>IETF-Announce mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: LB <[email-masked]>
Date: Tue, 4 Mar 2008 14:34:53 +0100

I looked carefully at the proposal of a WG to address the lacks of the IDNA
solution. My evaluation of multilinguist (study regarding the parallel usage
of languages) suggests to me that:

-- The proposed working group does not concern the Multilingual Internet,
but the adaptation of the IDNA solution. This should be clearly stated in
the Charter (it is indirectly said by the fact that if the proposed updates
to IDNA are not accepted, the Working Group is dissolved).
-- This project should describe at first its starting position in the
framework of multilingual Internet - with regard to langtags and to their
register(s) and its position with regards to the ISO standard of the
administrative and normative multilingualism (ISO 3166). This would better
allow the members of the WG to decide of the aptness of its solutions.
-- I contribute within the framework of the MLTF to the study of alternative
solutions as regards what we call more generally the IDNS (Interoperable
DNS). The priority does not appear to us the support of an aimless
"internationalization" for its own sake, but interoperabilty based on a
universalization or a polynymy respecting the infrastructure of the DNS from
which can be built a homogeneous and convergent multilinguistic support (DN,
URN, e-mail addresses mail, what we call the semantic addressing,
repositories).
-- It seems to me that the responsibility taken in the name of the IETF is
too important. If this WG fails, this will mean that another SSDO will have
to resume the subject and build the Multilingual Internet, or that it will
be built in a disorganised manner. A CYA attitude would seem raisonable and
that this responsibility is not taken solely by the IESG, but by the
consensus of the concerned parties and stakeholders: ICANN, GAC, ccTLDs,
IAB, IRTF, ITU, IGF / WSIS, MINC, ISO, ICC, UNESCO, ALAC.

Respectfully.
LB
----

---

From: Ted Hardie <[email-masked]>
Date: Tue, 4 Mar 2008 21:01:41 -0800

At 5:05 PM -0800 3/4/08, Lisa Dusseault wrote:
>
>Unicode experts have been participating in the work already, so this
>is even closer cooperation than having a liaison.  If there turns out
>to be a need for a liaison, can IAB/liaisons/ADs/chairs do lazy
>evaluation then on whether the IETF liaison can/will handle it or if
>the WG needs to create one?

I think you're missing the bigger question, probably because I asked it
poorly.  As it stands now, the charter posted has a presumptive course
for its update, but appears to have significant wiggle room.  To succeed,
I believe the charter has to be either nailed down or the mechanisms
to handle the wiggles put in place.  The big question is which do you
want to do?  Nail it down or give it the time and wiggle room to go
in different directions as the work evolves?  If the answer is "nail it down"
and the input documents are this close to baked, why are you chartering
a working group at all? 

>That's quite possible.  Is that level of detail required in the
>charter?  I don't think there's consensus pre-WG about how to make
>requirements for IDNs in identifiers, but this is something a WG
>could reasonably tackle within the context of this charter -- in fact
>it's something that would be hard to decide how to approach before
>having a WG.

If a goal of the working group is to separate the requirements
for IDNs in different context, then setting out what contexts are
to be considered is needed.  If  you said "Separate requirements
for  IDNs in different contexts" the amount of the play in the
rope is way too high (people could argue that IDNs in specific
application protocols posed unique requirements, down
which path madness lies).

>I think you're suggesting removing the parenthetical from the charter
>sentence.  Question for others: does that lose something important?
>If so how can that be made compatible with the design direction  that
>the charter suggests the WG needs to verify?

No, that wasn't what I meant.  I mean that this charter isn't clear
about whether the WG must ensure 1) the practical stability of
the result of validity algorithms whether old (lists) or new (properties)
or 2) that the validity alogrithms it creates must be stable no matter
on what approach they are based.  Just removing the parenthetical phrase
leaves a larger ambiguity (the validity algorithms...which ones?).

I hope this second comment is clearer than first,
				regards,
					Ted

>thx,
>Lisa