<font face="georgia,serif">Ken said what I was trying to say, but much more clearly and hypobolically. Further, I agree with John about the direction that the text should take.</font><div><font face="georgia,serif"><br></font></div>
<div><font face="georgia,serif">I have two quibbles about the current wording:</font></div><div><font face="georgia,serif"><br></font></div><meta charset="utf-8"><font class="Apple-style-span" face="georgia, serif"><meta charset="utf-8">       When the algorithm presented in RFC 5892 is applied to<br>
       Unicode 6.0 and all newly-added code points are ignored<br></font><div class="im"><font class="Apple-style-span" face="georgia, serif">       the results will differ from when it is applied to<br>       Unicode 5.2 for the three code points discussed in this<br>
</font></div><div><font face="georgia,serif">       document.</font></div><div><font face="georgia,serif"><br></font></div><div><font face="georgia,serif">The phrasing "<meta charset="utf-8">algorithm presented in RFC 5892 is applied to Unicode 6.0" is a bit odd, and inconsistent with 5892. If anything, the algorithm applies to code points, not a version of the standard. </font><span class="Apple-style-span" style="font-family: georgia, serif; ">The phrasing that is used in 5892 is "<span class="Apple-style-span" style="white-space: pre; ">It then defines an algorithm for determining a derived </span><span class="Apple-style-span" style="white-space: pre; ">property value.  It specifies a procedure, and not a table, of code </span><span class="Apple-style-span" style="white-space: pre; ">points so that the algorithm can be used to determine code point sets </span><span class="Apple-style-span" style="white-space: pre; ">independent of the version of Unicode that is in use." </span></span><span class="Apple-style-span" style="font-family: georgia, serif; ">Thus the algorithm <b>determines</b> a derived property value <b>using</b> a version of the Unicode standard. </span></div>
<div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font class="Apple-style-span" face="georgia, serif">Moreover, "newly-added code points" is incorrect. No version of Unicode (except very early versions) has <b>added code points</b>. Code points are from 0 to 0x10FFFF; that hasn't changed. Instead, it has added <b>characters</b>, by designating previously-reserved code points as representing (new) characters.</font></div>
<meta charset="utf-8"><div><font face="georgia,serif"><br></font></div><div><font face="georgia,serif">So I'm guessing the most consistent language to use in the new document would be:</font></div><div><font face="georgia,serif"><br>
</font></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><font class="Apple-style-span" face="georgia, serif">When the algorithm presented in RFC 5892 uses Unicode 6.0, and all characters added by Unicode 6.0 are ignored, the results will differ from when it is used with </font><span class="Apple-style-span" style="font-family: georgia, serif; ">Unicode 5.2 for the three code points discussed in this </span><span class="Apple-style-span" style="font-family: georgia, serif; ">document.</span></div>
</blockquote><div><font class="Apple-style-span" face="georgia, serif"><br></font></div><div><font class="Apple-style-span" face="georgia, serif">Mark<br><br><i>— Il meglio è l’inimico del bene —</i><br>
<br><br></font><div class="gmail_quote"><font class="Apple-style-span" face="georgia, serif">On Thu, Dec 23, 2010 at 08:28, John C Klensin <span dir="ltr"><<a href="mailto:klensin@jck.com">klensin@jck.com</a>></span> wrote:<br>
</font><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font class="Apple-style-span" face="georgia, serif"><br>
<br>
--On Thursday, December 23, 2010 10:30 -0500 Andrew Sullivan<br>
</font><div class="im"><font class="Apple-style-span" face="georgia, serif"><<a href="mailto:ajs@shinkuro.com">ajs@shinkuro.com</a>> wrote:<br>
<br>
> There seemed to be a lot of cc:s.  I trimmed them.<br>
><br>
> On Thu, Dec 23, 2010 at 03:41:44PM +0100, J-F C. Morfin wrote:<br>
><br>
>> Would this Draft be submitted to a sole IETF Last Call and<br>
>> not to a   prior WG/IDNA2011 LC, I would obviously appeal it<br>
>> since it would only   represent the consensus of a small<br>
>> group of people.  This would be the   same as if the new IUTF<br>
>> published a fundamental document without first  liaising at<br>
>> least with ISO, ITU and IETF.<br>
><br>
> I think you have a deep confusion about IETF procedures.<br>
> There is no requirement that documents from the IETF<br>
> automatically came from a working group.  An AD-sponsored<br>
> document that goes through an IETF last call can still<br>
> represent IETF consensus.  There is no IETF requirement at all<br>
> for a working group for this draft.<br>
<br>
</font></div><font class="Apple-style-span" face="georgia, serif">Procedurally, there is one other bit of information about this.<br>
Assuming that the text committing the IETF to produce a new RFC<br>
every time a new version of Unicode is produced (see my note of<br>
13 December) is removed, this document is a complete NO-OP from<br>
a protocol specification standpoint.  While it describes<br>
something that happened (a new version of Unicode) and a<br>
decision to do nothing, it changes nothing in any of RFCs<br>
5890-5895.  I would not recommend this, but if the language of<br>
the document were changed slightly to indicate that Patrik and<br>
Paul think that these are the reasons why no change was made, we<br>
have well-established procedures for publishing it as an<br>
Informational opinion piece without any Last Call or other<br>
explicit sign of community consensus.<br>
<br>
In terms of protocols and tables, the difference between the<br>
effect   of publishing this document and the effect of just<br>
losing it is zero.    It provides a historical record of our<br>
deciding to not do something, but that is all.   Indeed, the<br>
main issue I see with this document is the importance of wording<br>
it carefully to avoid having it become, in the words of one or<br>
two earlier notes, "an event".  Changing the 5890-5894 rule<br>
requiring no action unless a change is being made to the<br>
compatibility tables to a rule that requires a new RFC for every<br>
version of Unicode would be such an event; that is why I feel<br>
quite strongly that we should not be making such a change.<br>
<br>
Certainly, there has been a Unicode change and that change<br>
causes the non-normative IANA tables that reflect the 5892 rules<br>
to change, but that was exactly the way that this group of<br>
standards were expected to work.  Not much more news, or<br>
requirement for broad consensus, there than is required to BGP<br>
documents when a new network comes online and requires<br>
adjustment to global routing tables.<br>
<br>
In that context, Ken's revised formulation of the Security<br>
Considerations section doesn't quite work although the required<br>
change is fairly obvious, e.g.,<br>
</font><div class="im"><font class="Apple-style-span" face="georgia, serif"><br>
Ken wrote:<br>
<br>
>  When the algorithm presented in RFC 5892 is applied to<br>
> Unicode 6.0 the results will differ from when it is applied<br>
> to Unicode 5.2 for the three code points discussed in this<br>
> document.<br>
<br>
</font></div><font class="Apple-style-span" face="georgia, serif">and we would need something like:<br>
<br>
        When the algorithm presented in RFC 5892 is applied to<br>
        Unicode 6.0 and all newly-added code points are ignored<br>
</font><div class="im"><font class="Apple-style-span" face="georgia, serif">        the results will differ from when it is applied to<br>
        Unicode 5.2 for the three code points discussed in this<br>
        document.<br>
<br>
</font></div><font class="Apple-style-span" face="georgia, serif">Otherwise, it is possible to read that statement as "only these<br>
three changes occurred", which we have discussed elsewhere and<br>
are trying to avoid.<br>
<br>
My personal view of the moment is that, if we cannot swiftly<br>
reach reasonable agreement about the content and wording of this<br>
document, we should just drop it.  Again, its presence or<br>
absence would not change anything normative.<br>
<font color="#888888"><br>
    john<br>
</font></font><div><div></div><div class="h5"><font class="Apple-style-span" face="georgia, serif"><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>
</font></div></div></blockquote></div><br></div>