Note that part of what Mati is suggesting is that simplified rules can meet the objectives in the bidi document. For that, Harald (and Erik) would have to run their tools to see if the suggested rules still work, and point Mati to problem cases if they don't.<br>
<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Tue, Feb 10, 2009 at 06:36, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com">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;">
<div style="">
thanks for these precise comments, Mati.<div><br></div><div>Harald, I hope you can assess and incorporate as appropriate into a revised draft.</div><div><br></div><div>vint</div><div><br><div> <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; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><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; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><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; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;"><div>
<div><br>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" target="_blank">vint@google.com</a></div><div><br></div>
</div></span><br></span><br></span> </div><br><div><div><div></div><div class="Wj3C7c"><div>On Feb 10, 2009, at 3:28 AM, Matitiahu Allouche wrote:</div><br></div></div><blockquote type="cite"><div><div></div><div class="Wj3C7c">
<br><font face="sans-serif" size="2">My attention was recently drawn to the subject document (version 03) and I have a number of comments. Some of them are very minor (typos, editorial) and reflect my pedantic mind, but I thought that I could as well help improve the form of the document. Other comments touch more to the essence, and I will appreciate considering them seriously.</font> <br>
<br><font face="sans-serif" size="2">1) In section 2, first paragraph, "</font><tt><font size="3">satisifes</font></tt><font face="sans-serif" size="2">" should be "</font><tt><font size="3">satisfies</font></tt><font face="sans-serif" size="2">".</font> <br>
<br><font face="sans-serif" size="2">2) Section 2, rule 1 mentions the "Character Grouping requirement" for the first time in the document. Either there should be a forward reference to section 3 where it will be explained, or (better, in my opinion), the content of the current section 3 should precede the content of the current section 2.</font> <br>
<br><font face="sans-serif" size="2">3) In the sentence "</font><tt><font size="3">ET is excluded because the string L ET does not satisfy the Character Grouping requirement.</font></tt><font face="sans-serif" size="2">", "L" seems to represent a label, but can easily be confused with the L Bidi property (all the more since it is adjacent to ET which surely represents a character with the ET Bidi property).</font> <br>
<br><font face="sans-serif" size="2">4) In the sentence "</font><tt><font size="3">CS is excluded because the string L CS does not satisfy the Character Grouping requirement.</font></tt><font face="sans-serif" size="2">", "L" seems to represent a label, but can easily be confused with the L Bidi property (all the more since it is adjacent to CS which surely represents a character with the CS Bidi property).</font> <br>
<br><font face="sans-serif" size="2">5) I see no reason why CS is excluded while ES is allowed. Both can be the source of the same kind of violation of the Character Grouping requirement. ES characters are excluded from the first and last positions by rules 2 and 3. With the same restrictions (exclusion from the first and last positions), ES and ET characters can be allowed and will not violate the Character Grouping requirement any more than ES characters.</font> <br>
<br><font face="sans-serif" size="2">6) In section 1.1, there appears the following statement: "</font><tt><font size="3">This specification is not intended to place any requirements on domain names that do not contain right-to-left characters.</font></tt><font face="sans-serif" size="2">"</font> <br>
<font face="sans-serif" size="2">Also the title of section 2 is "</font><tt><font size="3">A replacement for the RFC 3454 BIDI rule</font></tt><font face="sans-serif" size="2">" which implies that the text only deals with "Bidi" labels.</font> <br>
<font face="sans-serif" size="2">If that means that the specification applies only to labels which contain at least one character with Bidi property R, AL or AN, and we combine that with rule 4 "</font><tt><font size="3">If an R, AL or AN is present, no L may be present.</font></tt><font face="sans-serif" size="2">", then an L character can never be part of a Bidi label, and the L should be removed from the list of allowed Bidi properties in rule 1.</font> <br>
<br><font face="sans-serif" size="2">7) In [UAX9], rule X9 says that BN characters must be removed from the displayed text. Any such invisible character violates the Label Uniqueness requirement. BN characters must not be allowed by rule 1.</font> <br>
<br><font face="sans-serif" size="2">8) From rules 1, 2, 4, 6 and 7, plus our comments 6 and 7 above, it results that the first character of a Bidi label can only be of type R or AL. Such a statement can advantageously replace rules 2, 6 and 7.</font> <br>
<br><font face="sans-serif" size="2">9) Rule 5 includes no justification. While a mixture of AN and EN characters in the same label seems odd and not required in real life situations, it is not clear what requirement would be violated by such a combination.</font> <br>
<br><font face="sans-serif" size="2">10) The rules allow AN or EN digits to appear in the last position of a label (in opposition to RFC 3454). Let us consider the following examples (where lower case letters represent L characters and upper case letters represent R or AL characters):</font> <br>
<br><font face="sans-serif" size="2"> a. network order = "ABC123.456xyz" display order (LTR) = "123.456CBAxyz" display order (RTL) = "123.456xyzCBA"</font> <br> <br><font face="sans-serif" size="2"> b. network order = "ABC.456-xyz" display order (LTR) = "456.CBA-xyz" display order (RTL) = "xyz-456.CBA"</font> <br>
<br><font face="sans-serif" size="2"> c. network order = "ABC123.456.xyz" display order (LTR) = "123.456CBA.xyz" display order (RTL) = "xyz.123.456CBA"</font> <br> <br><font face="sans-serif" size="2"> d. network order = "ABC.456.xyz" display order (LTR) = "456.CBA.xyz" display order (RTL) = "xyz.456.CBA"</font> <br>
<br><font face="sans-serif" size="2">Examples a, b and c show very ugly violations of the Character Grouping requirement. Since the document does not place requirements on non-Bidi labels, any non-Bidi label starting with digits following a Bidi label will cause a Character Grouping violation. If Bidi labels are restricted from ending with digits (optionally followed by NSMs), then non-Bidi labels which contain only digits (example d) following a Bidi label will not cause a Character Grouping violation.</font> <br>
<font face="sans-serif" size="2">Whether this modest benefit justifies imposing such a restriction is subject to discussion.</font> <br> <br><font face="sans-serif" size="2">11) Towards the end of section 2, there appears the following sentence: "</font><tt><font size="3">In a domain name consisting of only labels that pass the test, the requirements of Section 3 are satisfied.</font></tt><font face="sans-serif" size="2">"</font> <br>
<font face="sans-serif" size="2">This is not true for domain names like in the examples above, unless non-Bidi labels are excluded, which is a very hard constraint.</font> <br> <br><font face="sans-serif" size="2">12) The next sentence says: "</font><tt><font size="3">In a domain name consisting of only LDH-labels and labels that pass the test, the requirements of Section 3 are satisfied as long as a label that starts with an ASCII digit does not come after a right-to-left label that ends in a digit.</font></tt><font face="sans-serif" size="2">"</font> <br>
<font face="sans-serif" size="2">This is not true. See example b above.</font> <br> <br><font face="sans-serif" size="2">13) In section 3, there appears the sentence: "</font><tt><font size="3">the label "123-456" will have a different display order in an RTL context than in a LTR context.</font></tt><font face="sans-serif" size="2">"</font> <br>
<font face="sans-serif" size="2">This is not true, IMHO. If the last letter before the label is not an Arabic Letter, it will be displayed as "123-456" both in LTR and RTL context. If it is an Arabic Letter, it will be displayed as "456-123".</font> <br>
<br><font face="sans-serif" size="2">14) In section 3, there appears the sentence: "</font><tt><font size="3">The Label Uniqueness property should hold true between LTR paragraphs and RTL paragraphs. This was shown to be unsound.</font></tt><font face="sans-serif" size="2">"</font> <br>
<font face="sans-serif" size="2">In fact, in all cases where Character Grouping and Label Uniqueness are satisfied for each paragraph direction separately, there will be Label Uniqueness between LTR and RTL paragraphs.</font> <br>
<br><font face="sans-serif" size="2">15) In section 3, since an "unproblematic label" can be a label which satisfies the requirements, the clause "</font><tt><font size="3">any label S1 and S2 that is either a label satisfying the requirements or an unproblematic label</font></tt><font face="sans-serif" size="2">" can be shortened to "</font><tt><font size="3">any label S1 and S2 that is an unproblematic label</font></tt><font face="sans-serif" size="2">".</font> <br>
<br><font face="sans-serif" size="2">16) In the formal statement of the Label Uniqueness requirement, there is no provision (or exclusion) for the case where L and L' are identical.</font> <br> <br><font face="sans-serif" size="2">17) In summary I suggest that the rules in section 2 should be reformulated as below.</font> <br>
<br><tt><font size="3"> 1. Only characters with the BIDI properties R, AL, AN, EN, ES,<br> CS, ET, ON and NSM are allowed in RTL labels.<br> <br> 2. The first position must be a character with Bidi property R or AL.<br>
<br> 3. The last position must be a character with Bidi property R or AL,</font></tt> <br><tt><font size="3"> followed by zero or more NSM.<br> <br> 3 variant. The last position must be a character with Bidi property R,</font></tt> <br>
<tt><font size="3"> AL, EN or AN, followed by zero or more NSM.<br> <br> 4 (debatable). If an EN is present, no AN may be present, and vice</font></tt> <br><tt><font size="3"> versa.<br> <br> </font></tt><font face="sans-serif" size="2">It can be seen that this formulation is quite close to that in RFC 3454, while solving all the problems that the subject document aims to solve.</font> <br>
<font face="sans-serif" size="2"><br> <br> Shalom (Regards), Mati<br> Bidi Architect<br> Globalization Center Of Competency - Bidirectional Scripts<br> IBM Israel<br> Phone: +972 2 5888802 Fax: +972 2 5870333 Mobile: +972 52 2554160<br>
</font></div></div><div style="margin: 0px;">_______________________________________________</div><div style="margin: 0px;">Idna-update mailing list</div><div style="margin: 0px;"><a href="mailto:Idna-update@alvestrand.no" target="_blank">Idna-update@alvestrand.no</a></div>
<div style="margin: 0px;"><a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a></div> </blockquote></div><br></div></div><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>
<br></blockquote></div><br>