<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Mark,<div><br></div><div>thanks - I think what left me in an ambiguous state was the term "bits on the wire". In your example, under the IDNA2003 mapping process, the final sigma is mapped into ordinary sigma and THEN the resulting string is looked up (after conversion to xn-- format using the punycode algorithm). The two forms become identical prior to lookup. Under the proposed IDNA2008 rules, the two strings remain distinct in both the U-label and A-label format and thus look "different" on the wire and unless other measures are taken (bundling, restricted registration, etc) it is possible for the two domains to yield distinct results on lookup. </div><div><br></div><div>Paul - is that the picture you wanted to paint?</div><div><br></div><div>sorry to be slow to see which bits you were comparing.</div><div><br></div><div>v</div><div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><div><br class="Apple-interchange-newline">Vint Cerf</div><div>Google</div><div>1818 Library Street, Suite 400</div><div>Reston, VA 20190</div><div>202-370-5637</div><div><a href="mailto:vint@google.com">vint@google.com</a></div><div><br></div></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline"></span> </div><br><div><div>On Feb 23, 2009, at 8:02 PM, Mark Davis wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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></blockquote></div><br></div></body></html>