PostWG IDNA2008 implementation, transition and deployment document preparation

Thu Dec 17 13:16:53 CET 2009

Dear Cary,
thank you for your clear answer. I try to maintain the page
http://iucg.org/wiki/ICANN_position_regarding_IDNA2008_implementations (you
also can reached through the http://idna2010.org) portal.

At 08:26 17/12/2009, Cary Karp wrote:

In this endeavor, I am one of a group of TLD administrators who meet as
peers and have volunteered to be their scribe. (Only two of us regard
ourselves as native Anglophones and the other guy keeps forgetting to
bring a pencil.)

I understand. I have however a question: .MUSEUM is an ASCII extension which
has no right to contribute to FAST TRACK. I also understand this is true for
ASCII ccTLDs and IDNgTLDs (existing ones or projected ones). This is
surprising to me as the basis for transition rules can only be in
conformance with RFC 5226?

The group has been active since IDNA2003 was finalized, and its mandated
concern has been to provide a basis for the responsible implementation
of that protocol in the SLD space. Beyond that, we make every endeavor
to formulate the Guidelines in a manner that will have commonsense
appeal to the operators of all zones on all levels of the DNS when
formulating their own IDN policies. We also make every effort for the
Guidelines to reflect the best wisdom about IDN generated in other fora.

We are certainly along the same line, provided IETF existing rules are
either respected, corrected or appealed. Our concern as Internet Users, and
not only IDNA users, is a total network and application protocol
consistency. This is why we need to know if you also commit to this and have
some fears regarding your legitimate (we share it) impatience. However, two
years ago we committed to fully respect (and so to wait for) IDNA2008 before
building on top of it. This is why we need to be sure that you will do the
same, so we have no risk of technical conflict.

Please also understand that IDNA2008 is standard track. So will be additions
we may add in order to permit operational conformance to IDNA2008. This
means that they can become full standard only once two different operational
implementations are successful. We consider that FAST TRACK will be one the
IETF will want to consider. This means that we have to deploy three others
ones. This is because we consider that among the IDNA2008 implementation
recommendations users will document there will be at least one substantial
addition enough to require its own two independent additions and
transitions. We would wish this is carried in full cooperation.

Our work has been in abeyance for an uncomfortably long time while
waiting for IDNA2008, and my proposal was intended to hasten progress on
both fronts. The transition between IDNA2203 and IDNA2008 is a glaringly
obviously concern for the TLDs that have been accepting registration
under the former. Since there are no IDN-labeled TLDs, those that will
be established are unlikely to have legacy difficulties in this regard.

We support a daily observation of the first level namespace and we observe
several IDN-labeled TLD with millions of users. The way we proceed consists
in interrogating the namesevers listed in the NTIA root file about the zone
they support. These IDNg/ccTLD will have transition issues. I understand
they will be addressed in accordance with RFC 5226?

The next version of the Guidelines will of necessity contain transition
recommendations. It therefore seems rather obvious for them to reflect
the massive amount of work done by the IETF WG and the organizations
that have participated in it. If the IETF nonetheless opts to establish
a separate instrument in which corresponding recommendations are
expressed, the gTLDs -- which are contractually bound to implementing
the ICANN Guidelines -- can easily end up in the awkward position of
needing to reject anything proposed by the IETF (or in any other
context) that is at odds with the ICANN Guidelines.

As an Internet Users Contributing Group engaged into an IDNA2010 BCP on
implementation, transition and deployment of IDNA2008 RFCs, we have two
ambitions:
- to see addressed the users needs (many of them are related on the way they
have to organise their applications, configuration and machines to better
use IDNA2008)
- to include all the existing possible recommendations from participants to
the IDNA2008 deployment, obviously starting with recommendations such as
yours, ITU, Unicode, ASWIG, MINC, etc.

PS. This will also apply to the IDN-labeled TLDs. This is hardly a minor
consideration and does underline the need for clear separation between the
documents that articulate the protocol itself, and recommendations about its
implementation.

As indicated above, I have some difficulty understanding this. This is why I
(personally) refer to RFC 5226 first come, first serve and
transition/conflict resolution principles. If I am correct in reading you,
the ICANN testing strategy consists in documenting guidelines and
restrictions for _every_ IDN TLD, but on the sole basis of the
experimentation of IDNccTLDs signing an agreement with ICANN and not being
operated by ccTLD Managers whose ISO 3166 administrative language do not
only use Roman scripts.  As you may know we do not make such a
discrimination in the planned test projects IUCG sponsors (Project.FRA on
semantic addressing and Multilinc on multilinguistics as the cybernetics of
the language diversity).

Best regards

Portzamparc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091217/a4b6a74b/attachment.htm 