I think the changing of the prefix would have such negative impact that requiring a recharter for that case would be appropriate. After all, a prefix change would still be possible -- it just makes a higher bar. (Although I think if we are forced into a prefix change, it would not lead to successful deployment of IDNA2008.)<br>
<br>So if the working group determined that it couldn't meet its objectives without such a change (which I really doubt), rechartering would still be possible.<br><br>Mark<br><br><div class="gmail_quote">On Tue, Mar 25, 2008 at 5:04 AM, Vint Cerf <<a href="mailto:vint@google.com">vint@google.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">James, et al,<br>
<br>
May I suggest that we neither rule out nor explicitly suggest that<br>
there is need for a prefix change in the charter.<br>
<br>
If the working group comes to the conclusion that it cannot endorse<br>
the basic IDNA200X proposal and thinks that a new prefix is needed it<br>
will report that back to the IETF.<br>
<br>
To be honest, I hope that it will not come to that or, if it does, I<br>
hope that we can implement IDNA200X as an improvement over IDNA2003<br>
and that a prefix change proposal morphs into a serious "above the<br>
DNS" exploration that has been set aside in the past for good reasons<br>
but which might need to be resurrected as a serious piece of research.<br>
<font color="#888888"><br>
vint<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
On Mar 25, 2008, at 7:52 AM, James Seng wrote:<br>
<br>
> I remember xn-- was selected after exhaustive data mining on .COM zone<br>
> file back then and in the process, we found a few others that could be<br>
> use. "xn" basically was then pick "randomly".<br>
><br>
> I agree that there are complexity to change xn at this moment.<br>
> However, I am not totally against changing the prefix if the following<br>
> conditions are fulfill<br>
><br>
> a) there is a STRONG technical reason that a new prefix is needed<br>
><br>
> b) there must be backward compatibility with all existing IDN labels<br>
> with xn prefix.<br>
><br>
> For example, and I am not making any proposal, this is really just<br>
> merely an example, that I would consider a change of prefix if it we<br>
> agreed the best way to identify IDNA vs IDNA200X labels is via the<br>
> prefix (and I do not necessary agree at this moment) and that no<br>
> IDNA200X labels with a new prefix can be de-constructed to an xn--<br>
> IDNA label, ie the round-trip conversion between IDN and ACE labels<br>
> must always be consistent.<br>
><br>
> Much of the above are already captured somehow in Section 9.3 of the<br>
> issue document.<br>
><br>
> Perhaps lets not to mention the prefix change is allowed or disallowed<br>
> in the charter and let the working group sort it out.<br>
><br>
> -James Seng<br>
><br>
> On Tue, Mar 25, 2008 at 2:29 PM, YAO Jiankang <<a href="mailto:yaojk@cnnic.cn">yaojk@cnnic.cn</a>> wrote:<br>
>><br>
>> ----- Original Message -----<br>
>> From: "Patrik Fältström" <<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</a>><br>
>> To: "Shawn Steele" <<a href="mailto:Shawn.Steele@microsoft.com">Shawn.Steele@microsoft.com</a>><br>
>> Cc: <<a href="mailto:idna-update@alvestrand.no">idna-update@alvestrand.no</a>>; "John C Klensin"<br>
>> <<a href="mailto:klensin@jck.com">klensin@jck.com</a>>; "Mark Davis" <<a href="mailto:mark.davis@icu-project.org">mark.davis@icu-project.org</a>><br>
>> Sent: Tuesday, March 25, 2008 10:23 AM<br>
>> Subject: Re: Changing the xn-- prefix<br>
>><br>
>><br>
>><br>
>>> On 25 mar 2008, at 00.13, Shawn Steele wrote:<br>
>>><br>
>><br>
>>>> I reread your original mail, and in particular I don't want to get<br>
>>>> bogged down in the debate of details while trying to set the<br>
>>>> guidelines, but I'd like to try for "A prefix change MUST be<br>
>>>> avoided" (removing the condition). If that's going to cause too<br>
>>>> much randomization, then I'd back down, but the repercussions of<br>
>>>> changing the prefix are huge.<br>
>>><br>
>><br>
>>> I am personally in favor of text in the charter that say "The prefix<br>
>>> xn-- MUST NOT be changed." where MUST NOT is defined according to<br>
>>> the<br>
>>> IETF definition in RFC 2119 (<a href="http://www.ietf.org/rfc/rfc2119.txt" target="_blank">http://www.ietf.org/rfc/rfc2119.txt</a>).<br>
>><br>
>> +1<br>
>><br>
>><br>
>><br>
>>> This put a constrain on the changes the wg is allowed to do to<br>
>>> IDNA200X (not large so that the prefix has to change) -- at least<br>
>>> not<br>
>>> without rechartering.<br>
>>><br>
>>> Patrik<br>
>>><br>
>>> _______________________________________________<br>
>><br>
>><br>
>>> Idna-update mailing list<br>
>>> <a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
>>> <a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
>>><br>
>> _______________________________________________<br>
>> Idna-update mailing list<br>
>> <a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
>> <a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
>><br>
>><br>
> _______________________________________________<br>
> Idna-update mailing list<br>
> <a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
> <a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mark