I forgot to add:<br><br>And I don't think changing the "xn--" helps any with this. If it is already an XN-label, this is not a problem. The problem for domain names stored in Unicode. They'll will be interpreted differently.<br>
<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Mon, Feb 23, 2009 at 16:59, Mark Davis <span dir="ltr"><<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I tend to agree with Andrew that *effectively* this is a change to "bits on the wire".<br><br>That is, under IDNA2003 both "<a href="http://xn--oxaekj2bcabb8h.com/" target="_blank">τιςγλώσσες.com</a>" and "<a href="http://xn--oxaekj2bcabb8h.com/" target="_blank">τισγλώσσεσ.com</a>", for example, go to the same location, while under IDNA2008, they go to different locations (unless special registry actions are taken that are outside the control of this group).<br>
<br>For example, in an HTML page posted on the web:<br><br> href="<a href="http://xn--oxaekj2bcabb8h.com/" target="_blank">τιςγλώσσες.com</a>"<br><br>gets interpreted differently by an IDNA2003 browser than by an IDNA2008 browser.<br>
<font color="#888888">
<br clear="all">Mark</font><div><div></div><div class="Wj3C7c"><br>
<br><br><div class="gmail_quote">On Mon, Feb 23, 2009 at 12:17, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com" target="_blank">vint@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Paul,<br>
<br>
For clarity's sake, can we look at the "bits on the wire" issue for a<br>
moment?<br>
<br>
Would the addition of any new character to the allowed set constitute<br>
changing bits on the wire? There would be no bits on the wire for,<br>
e.g. an unassigned character, but bits would flow once the character<br>
is defined and is PVALID.<br>
<br>
In the case of sharp-S, under IDNA2003 the bits sent would have been<br>
"ss" but under IDNA2008,<br>
assuming sharp-S becomes a PVALID character, the bits sent would be<br>
the xn-- A-label form containing the ACE-encoded sharp-S character.<br>
<br>
Is it this change that captures your concern for "bits on the wire" or<br>
have I not understood the point?<br>
<br>
thanks<br>
<div><br>
vint<br>
<br>
<br>
<br>
Vint Cerf<br>
Google<br>
1818 Library Street, Suite 400<br>
Reston, VA 20190<br>
202-370-5637<br>
<a href="mailto:vint@google.com" target="_blank">vint@google.com</a><br>
<br>
<br>
<br>
<br>
</div><div><div></div><div>On Feb 23, 2009, at 2:45 PM, Paul Hoffman wrote:<br>
<br>
> At 1:48 PM -0500 2/23/09, John C Klensin wrote:<br>
>> I'm having trouble understanding your position (and Paul's).<br>
>> The charter rather specifically says that we can consider and<br>
>> make incompatible changes:<br>
>><br>
>> "Subject to the more general constraints described<br>
>> above, the WG is permitted to consider changes that are<br>
>> not strictly backwards-compatible. For any such change<br>
>> that is recommended, it is expected to document the<br>
>> reasons for the change, the characters affected, and<br>
>> possible transition strategies."<br>
>><br>
>> Now, I suppose one could read "- Ensure practical stability of<br>
>> validity algorithms for IDNs." as one of those "general<br>
>> constraints" and prohibiting _any_ change that is not strictly<br>
>> backward-compatible. But (i) that is explicitly an "additional<br>
>> goal", not a "general constraint". And (ii) even if it were a<br>
>> "general constraint", reading it to prohibit this case would, I<br>
>> believe, require reading it to prohibit _any_ change that is not<br>
>> strictly backward-compatible with IDNA2003 and that would<br>
>> completely contradict the provision quoted above.<br>
><br>
> Note the word "strictly" in "strictly backwards-compatible". Some of<br>
> us think, I think with justification, that it means there was room<br>
> for variance as long as other parts of the charter were not messed<br>
> with. Making some characters that were prohibited in IDNA2003 now<br>
> allowed clearly meets this requirement; so does prohibiting some<br>
> characters that were allowed in IDNA2003 now prohibited. Changing<br>
> the bits-on-the-wire representation of labels does not meet that,<br>
> particularly when combined with the prohibition on changing the<br>
> Punycode prefix.<br>
><br>
> In any other IETF protocol, if you are going to change the bits on<br>
> the wire and you have an unambiguous method to flag that change,<br>
> such flagging would be required. I am having trouble understanding<br>
> why you think this protocol is special.<br>
> _______________________________________________<br>
> Idna-update mailing list<br>
> <a href="mailto:Idna-update@alvestrand.no" target="_blank">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" target="_blank">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>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>