Dear Cary,<br>
thank you for your clear answer. I try to maintain the page <a href="http://iucg.org/wiki/ICANN_position_regarding_IDNA2008_implementations">http://iucg.org/wiki/ICANN_position_regarding_IDNA2008_implementations</a> (you also can reached through the <a href="http://idna2010.org">http://idna2010.org</a>) portal. <br>
<br>
At 08:26 17/12/2009, Cary Karp wrote:<br>
<blockquote type="cite" class="cite" cite="">In this endeavor, I am one of a group of TLD administrators who meet as <br>
peers and have volunteered to be their scribe. (Only two of us regard <br>
ourselves as native Anglophones and the other guy keeps forgetting to <br>
bring a pencil.)</blockquote><br>
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? <br>
<br>
<blockquote type="cite" class="cite" cite="">The group has been active since IDNA2003 was finalized, and its mandated <br>
concern has been to provide a basis for the responsible implementation <br>
of that protocol in the SLD space. Beyond that, we make every endeavor <br>
to formulate the Guidelines in a manner that will have commonsense <br>
appeal to the operators of all zones on all levels of the DNS when <br>
formulating their own IDN policies. We also make every effort for the <br>
Guidelines to reflect the best wisdom about IDN generated in other fora.</blockquote><br>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite" class="cite" cite="">Our work has been in abeyance for an uncomfortably long time while <br>
waiting for IDNA2008, and my proposal was intended to hasten progress on <br>
both fronts. The transition between IDNA2203 and IDNA2008 is a glaringly <br>
obviously concern for the TLDs that have been accepting registration <br>
under the former. Since there are no IDN-labeled TLDs, those that will <br>
be established are unlikely to have legacy difficulties in this regard.</blockquote><br>
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?<br>
<br>
<blockquote type="cite" class="cite" cite="">The next version of the Guidelines will of necessity contain transition <br>
recommendations. It therefore seems rather obvious for them to reflect <br>
the massive amount of work done by the IETF WG and the organizations <br>
that have participated in it. If the IETF nonetheless opts to establish <br>
a separate instrument in which corresponding recommendations are <br>
expressed, the gTLDs -- which are contractually bound to implementing <br>
the ICANN Guidelines -- can easily end up in the awkward position of <br>
needing to reject anything proposed by the IETF (or in any other <br>
context) that is at odds with the ICANN Guidelines.</blockquote><br>
As an Internet Users Contributing Group engaged into an IDNA2010 BCP on implementation, transition and deployment of IDNA2008 RFCs, we have two ambitions:<br>
- 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)<br>
- 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.<br><br>
<blockquote type="cite" class="cite" cite="">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. </blockquote>
<br>
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).<br>
<br>
Best regards<br><br>
Portzamparc<br>