<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">1) In section 2, first paragraph, "</font><tt><font size=3>satisifes</font></tt><font size=2 face="sans-serif">"
should be "</font><tt><font size=3>satisfies</font></tt><font size=2 face="sans-serif">".</font>
<br>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">", "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 size=2 face="sans-serif">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 size=2 face="sans-serif">", "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 size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">"</font>
<br><font size=2 face="sans-serif">Also the title of section 2 is "</font><tt><font size=3>A
replacement for the RFC 3454 BIDI rule</font></tt><font size=2 face="sans-serif">"
which implies that the text only deals with "Bidi" labels.</font>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">",
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 size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif"> a. network order = "ABC123.456xyz"
display order (LTR) = "123.456CBAxyz" display order
(RTL) = "123.456xyzCBA"</font>
<br>
<br><font size=2 face="sans-serif"> b. network order = "ABC.456-xyz"
display order (LTR) = "456.CBA-xyz" display order
(RTL) = "xyz-456.CBA"</font>
<br>
<br><font size=2 face="sans-serif"> c. network order = "ABC123.456.xyz"
display order (LTR) = "123.456CBA.xyz" display order
(RTL) = "xyz.123.456CBA"</font>
<br>
<br><font size=2 face="sans-serif"> d. network order = "ABC.456.xyz"
display order (LTR) = "456.CBA.xyz" display order
(RTL) = "xyz.456.CBA"</font>
<br>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">Whether this modest benefit justifies
imposing such a restriction is subject to discussion.</font>
<br>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">"</font>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">"</font>
<br><font size=2 face="sans-serif">This is not true. See example
b above.</font>
<br>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">"</font>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">"</font>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">"
can be shortened to "</font><tt><font size=3>any label S1 and S2 that
is an unproblematic label</font></tt><font size=2 face="sans-serif">".</font>
<br>
<br><font size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif">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 size=2 face="sans-serif"><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>