<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 17 dec 2007, at 22.39, Mark Davis wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Patrik, I'm afraid that somehow we have a miscommunication.</div></blockquote><div><br class="webkit-block-placeholder"></div>Possibly. Or even "most certainly" :-)</div><div><br><blockquote type="cite"><div> We haven't ever<br>been saying that all the properties that you've considered in<br>tables-xx.txtare stable.</div></blockquote><div><br class="webkit-block-placeholder"></div>What we have said is that the properties we use in the algorithms have to be stable.</div><div><br class="webkit-block-placeholder"></div><div>The rubber as not hit the road yet, I am aware of that, and that is why I want this meta discussion now. Before going into the details of the tables document.</div><div><br><blockquote type="cite"><div> What we<br>*have* been saying is that once the IETF comes up with a set of rules that<br>define an IDN property, we can and will commit to providing the mechanism to<br>stabilize that IDN property. Nobody has been saying that all of the<br>underlying properties will themselves be stable.</div></blockquote><div><br class="webkit-block-placeholder"></div>Correct, but the question is also (for the IETF, as this is an IETF document) wether the property value (ALWAYS, MAYBE YES, MAYBE NO, NEVER etc) is to be provided as a stable property by the Unicode Consortium, or whether some underlying data is provided by Unicode Consortium (and possibly others) and then the property value is defined by an IETF defined algorithm/process/table.</div><div><br class="webkit-block-placeholder"></div><div>At the moment, we have the latter process. That something is provided by the Unicode Consortium that is stable enough so that the IETF defined algorithm according to what is in the tables document give a property value that is stable according to the definitions: Basically "Never change the property value of a codepoint that has value ALWAYS or NEVER".</div><div><br class="webkit-block-placeholder"></div><div>I.e. there is a meta issue here that might end up in much more formal&nbsp;liaison&nbsp;statement, agreements and what not between various organisations. And IF such formality is needed, we need to know what the needs are, and who are the involved parties.</div><div><br><blockquote type="cite"><div>*This is a bit tricky, so please bear with me. *Because I have not<br>communicated this effectively so far, please read this over carefully and<br>let me know where you have questions or I am unclear. I will letter these<br>items for reference.<br><br><br>A. There is always a tension between having properties be stable and having<br>them be as accurate as possible.</div></blockquote><div><br class="webkit-block-placeholder"></div>Agreed.</div><div><br class="webkit-block-placeholder"></div><div>And this is where, I claim, IETF have concentrated on stability, while Unicode Consortium has concentrated on correctness. And that is where the shoe is not fitting very well (as we say in Sweden).</div><div><br class="webkit-block-placeholder"></div><div>I am here not saying one of the models is better than the other one. Different goals.</div><div><br><blockquote type="cite"><div>&nbsp;&nbsp;1. Application X wants to get the most accurate information about<br> &nbsp;&nbsp;characters with property X, and doesn't care about compatibility.<br> &nbsp;&nbsp;2. Application Y wants to property X in some special way (such as<br> &nbsp;&nbsp;identifiers) that requires absolute backwards compatibility. If the Unicode<br> &nbsp;&nbsp;consortium finds out that a character has different properties, that doesn't<br> &nbsp;&nbsp;matter. Compatibility swamps accuracy.<br><br>Because of that, all and only the properties on<br><a href="http://www.unicode.org/policies/stability_policy.html">http://www.unicode.org/policies/stability_policy.html</a> are guaranteed to be<br>stable. That page sets out exactly how the properties are stable.</div></blockquote><div><br class="webkit-block-placeholder"></div>Thanks for this list. If I compare this list with the list I sent to the list (what properties the algorithm in the tables document is based on) I see that the following is not on your list: script and block.</div><div><br class="webkit-block-placeholder"></div><div>Am I correct?</div><div><br></div><div><blockquote type="cite"><div>The Unicode consortium, however, does have a tool that it has used<br>successfully for many years to guarantee absolute stability, *while allowing<br>for fixes to underlying properties. *<br><br>B. Let's suppose IETF wants to define IDN_ALWAYS as being characters<br>according to a given formulation, such as the following (for brevity, X<br>means the set of characters having the property X)<br><br> &nbsp;&nbsp;- IDN_ALWAYS = ((X + Y + Z) - W) + V.<br><br>The properties X, Y, Z, W, and V the *underlying properties* for IDN_ALWAYS.<br>The Unicode consortium can supply absolute stability for IDN_ALWAYS in the<br>following way. In each version of Unicode, the consortium would commit to<br>defining the property:<br><br>Other_IDN_ALWAYS<br><br>to be all those characters that were in IDN_ALWAYS in the previous version,<br>but would not be in the current version according to the formulation.<br><br>Then the IETFs formulation becomes:<br><br> &nbsp;&nbsp;- IDN_ALWAYS = (((X + Y + Z) - W) + V) + Other_IDN_ALWAYS<br><br>That provides absolute stability across versions. Given a version of Unicode<br>V and the IETF's formulation, anyone can calculate IDN_ALWAYS for version V,<br>and it will always include all characters that were in IDN_ALWAYS for<br>version V-1.<br><br>Nobody needs to access multiple versions of Unicode to make this<br>calculation. As far as I understand them, I believe this satisfies all of<br>your requirements for stability.</div></blockquote><div><br class="webkit-block-placeholder"></div><div>Understood.</div></div><div><br><blockquote type="cite"><div>C. Now, what we would also do in Unicode would be to provide, in each<br>version of Unicode, what is called a "derived property", where we go ahead<br>and compute the tables for IDN_ALWAYS. This is simply a convenience to<br>users, since the vast majority don't want to do the computation themselves;<br>they just want to get the values. But someone always could.</div></blockquote><div><br class="webkit-block-placeholder"></div>Also understood. So far the signs I have heard in the IETF is though that the algorithm itself (((X + Y + Z) - W) + V) is to be explained in an IETF document.</div><div><br><blockquote type="cite"><div>D. If you want to see an example of this, look at the Unicode identifiers<br>over the years. Those use two properties (like C or Java, some characters<br>cannot be at the start of identifiers).<br><br>ID_Start = [[:L:][:Nl:][:Other_ID_Start:]]<br>ID_Continue = [[:L:][:Nl:][:Mn:][:Mc:][:Nd:][:Other_ID_Continue:]]<br><br>// this uses the POSIX syntax, whereby [:L:] is the set of all code points C<br>such that general_category(C) = Letter.<br>// one can of course use other syntax, like Perl's \p{L}, and so on.<br><br>We formalized and stabilized them in Unicode 3.0, in 1999.<br><br>If you search for Other_ID_Start and Other_ID_Continue in the following<br>files, you'll find that over the course of the eight years since then, we've<br>added a handful of characters to the grandfathering categories Other_... so<br>as to maintain backwards compatibility with each and every release.<br><br><a href="http://www.unicode.org/Public/4.0-Update/PropList-4.0.0.txt">http://www.unicode.org/Public/4.0-Update/PropList-4.0.0.txt</a><br><a href="http://www.unicode.org/Public/4.1.0/ucd/PropList.txt">http://www.unicode.org/Public/4.1.0/ucd/PropList.txt</a><br>http://www.unicode.org/Public/5.0.0/ucd/PropList.txt<br>http://www.unicode.org/Public/5.1.0/ucd/PropList-5.1.0d20.txt (the current<br>beta)<br><br>We have a set of tools that we run over each release to verify<br>compatibility, and we have a beta period of several months for each release<br>where others can run external own tools as well.</div></blockquote><div><br class="webkit-block-placeholder"></div>Ok.</div><div><br><blockquote type="cite"><div>E. While I do believe that the Unicode consortium would be best placed to<br>update the categorization of characters over time, based on the broad<br>internationalization expertise of its members, that is an orthogonal issue.<br>The IETF could decide that it wants some other group to do that -- that does<br>not affect the consortium's commitment to provide for stability of IDN. It<br>would, of course, require synchronization between the groups, much like the<br>extremely successful working relationship between the consortium and the ISO<br>subcommittee responsible for ISO 10646.<br><br>I'm hoping this makes sense to you now.<br></div></blockquote></div><br><div>Yes.</div><div><br class="webkit-block-placeholder"></div><div>The questions now I think are:</div><div><br class="webkit-block-placeholder"></div><div>a. What differences exist between the algorithms in the table document and Unicode "stable" properties?</div><div>b. What differences exists between IDNA2003 and the tables document?</div><div>c. What differences will exist if tables document algorithms are only based on stable properties (where some of them are only stable from Unicode 5.0)</div><div><br class="webkit-block-placeholder"></div><div>&nbsp;&nbsp; Patrik</div><div><br class="webkit-block-placeholder"></div></body></html>