<span class="Apple-style-span" style="font-family: 'Times New Roman'; font-size: 13px; "><div id="u7bu" style="margin-top: 0px; margin-bottom: 0px; "><div id="algi" style="margin-top: 0px; margin-bottom: 0px; "><div id="rhno1" style="text-align: left;margin-top: 0px; margin-bottom: 0px; ">
This document: <a class="tabcontent" href="http://docs.google.com/Doc?id=dfqr8rd5_77hqpj2rfc" id="publishedDocumentUrl" target="_blank">http://docs.google.com/Doc?id=dfqr8rd5_77hqpj2rfc</a><br id="rhno2"></div><br id="p6se">
Now that the Unicode and CLDR releases are out the door, I've had some time to turn back to IDNAbis. I did another pass through, and here are my comments. The documents continue to show progress with each revision, so that's very promising. Some of the main issues I see that still thread through all of these documents are:<br id="noof">
<br id="algi0"></div><ol id="algi1" style="margin-top: 0px; margin-bottom: 0px; "><li id="algi2" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; "><b id="njml">Stability of Labels. </b>I believe quite strongly that once a domain name is valid, it should not be invalidated by any later version of IDNA. Now, while we cannot prevent a later RFC from doing that, we <b id="uaup">can </b>prevent such invalidation by the normal process of updating tables under these RFCs for new versions, adding exceptions, and changing contextual rules.</li>
<li id="uaup0" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; "><b id="u.88">Instability of Nonlabels. </b>I also think that making nonlabels stable should <i id="n-_2">not </i>be a goal. It can't really be achieved anyway, since the presence of an UNALLOWED character can make a label be invalid in version X yet valid in version Y (where that character is defined).</li>
<li id="w:8:" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; "><b id="w:8:0">Management.</b> The process of adding backwards compatibility characters, context conditions, and exceptions needs to be much more definitive.<br id="w:8:1">
</li></ol><div id="algi4" style="margin-top: 0px; margin-bottom: 0px; "><p id="ewpe0" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "></p><h2 id="f5vy" style="padding-top: 12pt; font-family: Garamond; font-size: 14pt; color: rgb(0, 51, 0); border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: rgb(0, 51, 0); ">
Documents</h2><i id="ewpe1"><br id="gck2"></i><p id="gck20" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><span class="Apple-style-span" id="ewpe3" style="font-size: 16px; "><i id="f5vy0"><a href="https://datatracker.ietf.org/drafts/?filename=idnabis" id="bcvi6" title="https://datatracker.ietf.org/drafts/?filename=idnabis">https://datatracker.ietf.org/drafts/?filename=idnabis</a> </i></span></p>
<i id="gck21"><br id="gck22"></i><ol id="bp820" style="margin-top: 0px; margin-bottom: 0px; "><li id="bp821" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; "><a href="http://tools.ietf.org/html/draft-ietf-idnabis-bidi" id="q5jm" title="http://tools.ietf.org/html/draft-ietf-idnabis-bidi">http://tools.ietf.org/html/draft-ietf-idnabis-bidi</a></li>
<li id="mze71" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; "><a href="http://tools.ietf.org/html/draft-ietf-idnabis-tables" id="hp48" title="http://tools.ietf.org/html/draft-ietf-idnabis-tables">http://tools.ietf.org/html/draft-ietf-idnabis-tables</a></li>
<li id="n:sh" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; "><a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol" id="cqys" title="http://tools.ietf.org/html/draft-ietf-idnabis-protocol">http://tools.ietf.org/html/draft-ietf-idnabis-protocol</a></li>
<a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol" id="qe08" title="http://tools.ietf.org/html/draft-ietf-idnabis-protocol"></a><li id="sh1y" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">
<a href="http://tools.ietf.org/html/draft-ietf-idnabis-rationale" id="zdjf" title="http://tools.ietf.org/html/draft-ietf-idnabis-rationale">http://tools.ietf.org/html/draft-ietf-idnabis-rationale</a> <br id="sh1y0"></li></ol>
<h2 id="bcvi7" style="padding-top: 12pt; font-family: Garamond; font-size: 14pt; color: rgb(0, 51, 0); border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: rgb(0, 51, 0); ">Comments on bidi-00</h2><ol id="stb7" style="margin-top: 0px; margin-bottom: 0px; ">
<li id="stb70" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">Typos (minor) : document needs spell-checking.</li><ol id="u:330" style="margin-top: 0px; margin-bottom: 0px; "><li id="u:331" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">
...when it's embedded... <br id="u:332"></li><li id="u:333" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; "> ...compatibiltiy... </li></ol><li id="u:335" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">
Odd phrasing: should be specification, or document, ...</li><ul id="v-oa" style="margin-top: 0px; margin-bottom: 0px; "><li id="v-oa0" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"This memo doesn't propose..."</li>
</ul><li id="r7ow0" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">The following is problematic. It appears that the most we could do is place conditions on a label<i id="ia4j"> in the context of the other labels</i>. That is, this would require a test on the entire domain name, not just an issue with a single label.<br id="rn3v">
</li><ul id="qazi0" style="margin-top: 0px; margin-bottom: 0px; "><li id="rn3v0" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"This specification forbids using leading European numbers in ASCII-<br id="rn3v1">
</li></ul><ol id="qazi1" style="margin-top: 0px; margin-bottom: 0px; ">only labels; this is in conflict with a large installed base of such<br id="rn3v2">labels. The harm resulting from violating this rule is seen when a<br id="rn3v3">
label at the next level down in the hierarchy ends with a number<br id="rn3v4">(Arabic or European).<br id="x4ju"></ol><li id="amkm0" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">Older Comments on bidi: <a href="http://www.alvestrand.no/pipermail/idna-update/2008-March/001263.html" id="pgki7" target="_blank">http://www.alvestrand.no/pipermail/idna-update/2008-March/001263.html</a></li>
<ul id="xix_" style="margin-top: 0px; margin-bottom: 0px; "><li id="amkm1" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; "><i id="qeg4">So far as I can tell, these have not yet been addressed in the text.</i></li>
</ul></ol><h2 id="stb75" style="padding-top: 12pt; font-family: Garamond; font-size: 14pt; color: rgb(0, 51, 0); border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: rgb(0, 51, 0); ">Comments on tables-01</h2>
<ol id="xy3s" style="margin-top: 0px; margin-bottom: 0px; "><li id="xy3s0" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">The use of human-readable names in this version is a big plus, thanks!</li>
<li id="s.e-" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"Codepoints with this property value will never be permitted in IDNs."<br id="s.e-0">Aside from the stability issue, this is a promise that cannot be kept, since a future RFC could modify this for IDNs (as pointed out on the list). Replace by:<br id="s.e-1">
"are not permitted", or something like "will never be permitted unless this document were obsoleted".</li><li id="v_jd" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">
"It should be suitable for newer revisions of Unicode, as long as the Unicode properties on which it is based remain stable."<br id="e1_w">Replace by<br id="e1_w0">"This is suitable for any newer versions of Unicod as well. Changes in Unicode properties that do not affect the outcome of this process do not affect IDN. For example, a character can move from So to Sm, or from Lo to Lu, without affecting the table results. Moreover, even if such changes were to result, the BackwardCompatible list (<a id="e1_w1" name="section-2.2.3">2.2.3</a>.) will be adjusted to ensure the stability of the results."</li>
<li id="s.e-2" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">... on a two step procedure... => on a two-step procedure</li><li id="qg66" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">
... That a label consists only of codepoints... => However, that a label consists only of codepoints</li><li id="t-60" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">Section 2.1.3: there was a change in the definition of DICP in preparation for IDNA. See Derived Property: Default_Ignorable_Code_Point in <a href="http://www.unicode.org/Public/5.1.0/ucd/DerivedCoreProperties.txt">http://www.unicode.org/Public/5.1.0/ucd/DerivedCoreProperties.txt</a> for the text for the updated text.</li>
<li id="put:" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"In many cases aliases are used in the data in the Unicode Standard. This document uses both the alias and the spelled out terms (for example alias Ll for the General Category Lowercase_Letter)."<br id="put:0">
Replace with:<br id="put:1">"Unicode property names and property value names may have short abbreviations, such as gc for the General_Category property, and Ll for the Lowercase_Letter property value of that property."</li>
<li id="fgxh" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">Sort the following by value instead of code point, for clarity. Ideally each value would be in its own subsection: PVALID, CONTEXTO,...<br id="fgxh0">
<pre id="ero0"> 002D; CONTEXTO # HYPHEN-MINUS<br id="ero00"> ...<br id="ero010"> 3007; PVALID # IDEOGRAPHIC NUMBER ZERO<br id="ero011"> 303B; CONTEXTO # VERTICAL IDEOGRAPHIC ITERATION MARK<br id="ero012"> 30FB; CONTEXTO # KATAKANA MIDDLE DOT</pre>
</li><li id="xmal" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"The characters 02B9, 0375 and 0483..." In Unicode we have the convention that characters are represented by the format "U+02B9 MODIFIER LETTER PRIME" in free-flowing text, that is, always including the name. I strongly recommend that practice be followed in all of these documents; it makes it far easier for someone to follow what is going on (since most people don't memorize these numbers ;-). You can use <a href="http://unicode.org/cldr/utility/character.jsp?a=02B9">http://unicode.org/cldr/utility/character.jsp?a=02B9</a> to get the name, or just grep the main unicode property file.</li>
<li id="q:n1" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"This category includes the codepoints that property values in versions of Unicode after 5.0". The 5.0 value was changed to 5.1 in most cases, but not here. Search all the documents for 5.0 in case any others were missed.</li>
<li id="s501" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"As the requirement is that codepoints having either of these derived..." Missing reference. What requirement?</li>
<li id="wrmh" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"This category consists of codepoints in the Unicode character set that are not (yet) assigned. It should be noted that the set of unassigned characters is the larger set {Cn, Cs}."<br id="zov.">
The last sentence needs clarification: suggest<br id="kicn">"It should be noted that Unicode distinguishes between 'unassigned code points' and 'unassigned characters'. The unassigned code points are all but (Cn - Noncharacters), while the unassigned *characters* are all but (Cn + Cs).</li>
<li id="lk4m" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"If needed, IANA should (with the help of an appointed expert) suggest updates of this RFC where BackwardCompatible (Section 2.2.3) is updated, a set that is at<br id="lk4m2">
</li>release of this document is empty."<br id="kh7.">This isn't going to work. I suggest that the backwards compatible character list, the exceptions list, and the context rules all be in a single document published by IANA, and controlled by the group discussed in rationale. We then need to provide guidance and constraints on this group. This kind of process is not new: for example, BCP 47 has very stringent guidelines on how the IANA language-subtag-registry is to be changed. In this case, the text should read something like:<br id="oi7s">
"If as a result of property changes in a version of Unicode, any assigned character under the old version of Unicode would have a different value according to this document than in the new version, then the IANA IDNA committee must amend the BackwardsCompatible List to ensure that the value remains stable. This must be published by IANA immediately upon release of the new version of Unicode (such timing is easily feasible because of the long lead times for Unicode beta versions)."<br id="o-iq">
</ol></div></div><h2 id="stb73" style="padding-top: 12pt; font-family: Garamond; font-size: 14pt; color: rgb(0, 51, 0); border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: rgb(0, 51, 0); ">Comments on protocol-01</h2>
<ol id="guy1" style="margin-top: 0px; margin-bottom: 0px; "><li id="guy10" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; "><a href="http://4.3.2.4">4.3.2.4</a>: the bidi constraints apply to more than just single labels.</li>
<li id="gn_j" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">4.4: "While exact policies are not specified as part of IDNA2008 and it is expected that different registries may specify different policies,<br id="x47m">
there SHOULD be policies." This SHOULD is pointless, unless some constraints or guidance are given. Otherwise my policy could be "any valid IDNA label", which would be precisely the same as no policy at all.</li>
<li id="iu3b" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">5.2: "The local character set, character coding conventions, and, as necessary, display and presentation conventions, are converted to Unicode (without surrogates), paralleling the process described above in Section 4.2."<br id="ttvc">
In the vast majority of cases in modern software, the local charset IS Unicode, so this may be confusing. Also, UTF-16 does and must use surrogate code units, so this needs to be more precise. And excluding surrogate code points isn't necessary since gc=Cs are forbidden anyway. Suggest:<br id="a4la">
"The string is converted from the local character set into Unicode, if it is not already Unicode. The exact nature of this conversion is beyond the scope of this document, but may involve normalization, as described in Section 4.2."</li>
<li id="y1_i" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">5.4: "In general, that conversion and testing should be performed if the domain name will later be presented to the user in native character form (this requires that the lookup application be IDNA-aware)."<br id="n22-">
Suppose that program X creates an A-Label from a U-Label, then sends that A-Label to program Y, which sends it to program Z, which sends it to program W, which displays it. It sounds like each of Y, Z, W need to validate. Is that the intent of this text? If it is only W that needs to validate, then it gets a bit murky in today's world, where the boundaries between cooperating processes and programs are very fuzzy.</li>
<li id="z7.l" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">5.5: "In parallel with the registration procedure...". The use of "in parallel with", here and elsewhere, sounds like they might be concurrent operations, which is not what is intended. I suggest other wording. Also, the steps in 5.5 are all the same as in 4.3 -- except for bidi. This fact should be very clear in the text.</li>
<li id="l2pm" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">Regex table. See below for recommendations. Note that what we did in BCP 47 is have a separate document specifying the initial contents of the registry<br id="rkp-">
</li></ol><br id="iufa0"><p id="cw.s0" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Older Comments on protocol -- haven't reviewed these yet: <a href="http://www.alvestrand.no/pipermail/idna-update/2008-March/001171.html" id="pgki12" target="_blank">http://www.alvestrand.no/pipermail/idna-update/2008-March/001171.html</a></p>
<p id="rkp-0" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br id="rkp-1"></p><pre id="mkkk0"></pre><h2 id="stb74" style="padding-top: 12pt; font-family: Garamond; font-size: 14pt; color: rgb(0, 51, 0); border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: rgb(0, 51, 0); ">
Comments on rationale-00</h2><ol id="cuty" style="margin-top: 0px; margin-bottom: 0px; "><li id="cuty0" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">Rationale is currently a mixture of background information, plus text required for conformance to the protocol, plus rationale for why to change, and meta discussions like "In these cases, we should avoid trying to tell implementers what...". It should focus solely on the rationale, and all the normative text should be moved into the protocol document.</li>
<li id="ta:u" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"IDNA uses the Unicode character repertoire, which avoids the significant delays that would be inherent in waiting for a different and specific character sets to be defined for IDN purposes, presumably by some other standards developing organization. " This is a very strange rationale, like saying: "IDNA uses the English language, which avoids the significant delays that would be inherent in waiting for a different and specific language to be defined for IDN purposes, presumably by some other standards developing organization." Delete the "which avoids... organization."</li>
<li id="xu9v" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"to reduce the opportunities for attacks on the encoding system." => "to reduce the opportunities for attacks via the encoding system."</li>
<li id="jvy_" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"9. Make bidirectional domain names in a paragraph display in a non-surprising fashion." This is just a special case of the previous item, so delete.</li>
<li id="jvy_0" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"11. Make some currently-valid labels that are not actually IDNA labels invalid." Why do we care that labels invalid under IDNA2003 are also invalid under IDNA2008? Why wouldn't they be? Perhaps an example would help to clarify this.</li>
<li id="gzd5" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"are needed to make reasonable use of some scripts but become invisible characters in others." => "are needed to make reasonable use of some scripts but have no visible affect in others." These characters are always invisible; they cause the surrounding characters to change form.</li>
<li id="ynb4" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"that are safe for use only in conjunction". Since you never say why they are unsafe, this needs clarification. Do you mean this because of visible confusability?</li>
<li id="hdnu" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"If a character is classified as "DISALLOWED" in error and the error is sufficiently problematic, the only recourse would be either to introduce a new code point into Unicode and classify it as "PROTOCOL-VALID...". Unless you have some evidence to think that this is a real possibility (I don't), it should be removed.</li>
<li id="o3_2" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"[anchor25: Note in Draft: the last sentence above basically<br id="o3_20"></li>duplicates a comment in Security Considerations. Is it worth having<br id="o3_21">
in both places??" For my part, yes.<br id="k1op"><li id="k1op0" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"Applications MAY allow the display and user input of A-labels, but are encouraged to not do so except as an interface for special purposes, possibly for debugging, or to cope with display limitations." There is widespread use of the A-Label to signal a possible spoof -- while you discuss that later, I think it's swimming against the tide not to mention it here.</li>
<li id="kzha" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"the two-character sequence "ae" is usually treated as a fully acceptable alternate orthography." Add: "for the "umlauted a" character".</li>
<li id="bv.x" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"They may occur in running text or be processed by one system after being provided in another. They may wish to try to normalize..." The two "they"s have different subjects; reword.</li>
<li id="ufnp" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"use characters that cannot be represented directly in domain names but for which interpretations are provided." What is meant by this, and how is it different in IDNA2008? In both IDNA2003 and 2008 they are illegal.</li>
<li id="tg26" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">" If a domain name appears in an arbitrary context (such as running text), one may be faced with the requirement to know that a string is a domain name in order to adjust for the different forms of dots but also to have traditional dots to recognize that a string is a domain name -- an obvious contradiction." Not a contradiction, remove. Example, if one recognizes full-width dot in detecting URLs, then one can clearly use them in parsing within labels.</li>
<li id="g6y9" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"None of those local decisions<br id="bq832">are a threat to interoperability as long as (i) only U-labels and<br id="bq833">
A-labels are used in interchange with systems outside the local<br id="bq834">environment,...".<br id="ky8v">Doesn't really follow that there are no problems. The obvious example of interoperability problems are where a Turkish friend has a URL that works in his browser, copies the text in an email and sends to me." When I click on it, it either 404's or <i id="ky8v0"><b id="ky8v1">*much worse*</b></i>, goes to a different website.</li>
<li id="eqtw" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"The fact that a word exists is<br id="eqtw0"> not proof that it should be usable in a DNS label and DNS labels<br id="eqtw1">
are not expected to be usable for multiple-word phrases (although<br id="eqtw2"> they are certainly not prohibited if the conventions and<br id="eqtw3"> orthography of a particular language cause that to be possible)." Add, to show that we not playing favorites, "Even the very common words in English like "can't, and "don't" are not allowed.</li>
<li id="yx49" style="margin-top: 0px; margin-bottom: 0px; padding-top: 2pt; padding-bottom: 2pt; ">"Most Unicode names for letters are, in most cases, fairly<br id="yx490"> intuitive, unambiguous and recognizable to users of the relevant<br id="yx491">
script....and there are far more squares of various flavors in<br id="yx492"> Unicode than there are hearts or stars." This just needs to be removed; the argumentation is faulty. For the same pronunciation, Chinese has hundreds of possible characters. If you want another reason (and someone to point a finger at), you could say: "The Unicode Standard recommends that these types of identifiers not contain symbols [UAX31].<br id="bq839">
</li></ol><br id="jvy_7">Older Comments on issues (rationale) -- haven't reviewed these yet: <a href="http://www.alvestrand.no/pipermail/idna-update/2008-March/001295.html" id="pgki1" target="_blank">http://www.alvestrand.no/pipermail/idna-update/2008-March/001295.html</a><br id="yrm6">
<h2 id="rkp-2" style="padding-top: 12pt; font-family: Garamond; font-size: 14pt; color: rgb(0, 51, 0); border-bottom-width: 2px; border-bottom-style: solid; border-bottom-color: rgb(0, 51, 0); ">Regex format</h2><p id="gbal1" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">
I suggest that the table be formatted for clarity to not depend on whitespace -- using names for each field -- and be broken into a list of condition/result pairs.</p><pre id="l42i0"><span class="Apple-style-span" id="kzjf" style="font-size: 10px; ">Code point: 200C<br id="l42i1">
Name: ZERO WIDTH NON-JOINER<br id="uu85">Lookup: True<br id="wfbq"><br id="tkd7"># Allow ZWNJ for breaking cursive connection, as needed in Farsi.<br id="h__w">Before: [[:Joining_Type=Dual_Joining:][:Joining_Type=Left_Joining:]] [:Joining_Type=Transparent:]*<br id="o:w3">
After: [:Joining_Type=Transparent:]* [[:Joining_Type=Dual_Joining:][:Joining_Type=Right_Joining:]]<br id="xk1h">Value: PVALID<br id="wfbq0"><br id="tkd70"># Allow ZWNJ after letter-virama in same script, starting with Devanagari, Gurmukhi,...<br id="tkd71">
Before: [[:gc=Letter:]&[:Script=Deva:]] [[:ccc=Virama:]&[:Script=Deva:]]<br id="csw5">Value: PVALID<br id="p_.p">Before: [[:gc=Letter:]&[:Script=Guru:]] [[:ccc=Virama:]&[:Script=Guru:]]<br id="p_.p0">
Value: PVALID<br id="csw50"><br id="p_.p1">Code point: 200D<br id="tjxc">Name: </span><span id="tjxc0" class="name"><span class="Apple-style-span" id="kzjf0" style="font-size: 10px; ">ZERO WIDTH JOINER<br id="tjxc1">
...</span></span><span class="Apple-style-span" id="kzjf1" style="font-size: 10px; "><br id="b4v_"><br id="b4v_0">Code point: 00B7<br id="b4v_1">...</span><br id="oir40"></pre><p id="mkkk" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">
The reason for breaking the condition into two parts is then it is very clear exactly what we are testing.</p><div id="u7bu2" style="margin-top: 0px; margin-bottom: 0px; "><div id="u7bu3" style="margin-top: 0px; margin-bottom: 0px; ">
<br id="xmal0"></div></div></span>