Subject: [dns-dir] idnabis documents in the iesg

From: Jari Arkko <[email-masked]>
Date: Wed, 06 Jan 2010 09:39:51 +0100

Directorate,

These documents are on the IESG telechat tomorrow. I would like to get 
your assessment on whether they are ready to become RFCs or if there are 
some significant issues left.

http://tools.ietf.org/html/draft-ietf-idnabis-bidi-06
http://tools.ietf.org/html/draft-ietf-idnabis-defs-12
http://tools.ietf.org/html/draft-ietf-idnabis-protocol-17
http://tools.ietf.org/html/draft-ietf-idnabis-rationale-15
http://tools.ietf.org/html/draft-ietf-idnabis-tables-08

Jari

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Jan 2010 08:58:53 -0500

> http://tools.ietf.org/html/draft-ietf-idnabis-tables-08

I reviewed the documents during WGLC, and have been active in the
IDNABIS WG.  I haven't completely re-read the documents after the LC,
but I've followed the changes as they've happened.

The hold up with them since IETF LC has been, apparently, the
sponsoring AD's reluctance to proceed because of issues to do with the
fact that these introduce backwards-incompatible changes with
IDNA2003.

The resolution to that has, in the end, apparently been to say, "Yes,
they do," and to hope that sensible things will happen elsewhere.
There were some adjustments to the documents, but nothing that wasn't
there all along in my opinion.  The compromise appears to have been
that the issue of how to handle the transition has been kicked over to
ICANN.

The plain fact is that these introduce a backward-incompatible change
with IDNA2003, and that there will therefore be an overlap period
during which it will be possible for two different clients on the same
machine at the same time to resolve the same keyboard input
differently.  The most galvanizing but maybe not most likely example
of this is the ß (Eszett or SHARP S) character.

In order to avoid this eventuality, it will be necessary for
registries (or zone operators) to do something to map the characters
in question, and to arrange the zones they operate such that during
some transition period at least there is no difficulty.

Of course, there isn't anything in the protocol to enforce this, and
it would be impossible to require that there be.

In my opinion, given the aims that the IETF had when chartering the
IDNABIS work in the first place, the documents are as good as they're
ever going to be and should be published.  Remember that these are at
the beginning of the standards track, and there's already some talk of
opening them to revise and advance.

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 6 Jan 2010 15:56:53 +0100

> opening them to revise and advance.

I am biased as I am an editor of one of the documents, and of course influential in the wg, but let me add one thing to the excellent summary by Andrew...the other organisations that are specifically interested in this work (W3C, ICANN and Unicode Consortium) as well as other IETF wg's, can not really start working on what they have to work with before these documents are RFC's. They will (as Andrew imply) do their work, and come back with feedback for the next step in the IETF standards process.

I do not see any need for prolonging the delay before these documents are made available, as I think the discussions already a few months ago went from based on real facts be theoretical discussions, discussions that never can be put to rest without people actually doing something.

I.e. documents will not be (much) better than this without much more real world experience. Which we will not get without the documents as RFCs.

I want to emphasise that Andrew has not only been active in the wg all the time (and not given up like too many other good contributors), he has also come with excellent input during the whole time we have worked on this (compared with other comments that have been...hmm...time consuming at best).

    Patrik