draft-ietf-idnabis-tables-06a.txt

Kenneth Whistler kenw at sybase.com
Tue Jul 21 01:26:32 CEST 2009


Patrik,

> Here is the first cut of draft-ietf-idnabis-tables-06.txt. I have  
> probably errors in here. For example, I am still to check in detail  
> that the appendix with codepoints is ok. 

The diff from 05.txt seems to have the correct changes to
the Appendix in it.

> But, I want you to see this  
> earlier rather than later.
> 
> http://stupid.domain.name/stuff/draft-ietf-idnabis-tables-06a.txt

What follows are some suggestions for minor editorial corrections.

Substantive comments on other issues -- particularly the
CONTEXTO rules, to follow as separate postings.

--Ken

=================================================================

Page 4, paragraph starting "The mechanisms described here..."
has an error in it:

"For example, a character can move from So to Sm, or from
Lo to Lu, without affecting the table results."

So --> Sm will not affect the table, but, Lo --> Lu assuredly
could, because as a result of 2.2 Unstable, uppercase letters
are generally all DISALLOWED in the table. Actually, the
situation is even more complex, because there are stability
constraints now on the Unicode Standard itself that would
prevent the UTC from changing the General_Category of a
character from Lo to Lu *and* introducing a case folding for
it, but I think the subtlety of that might be lost on people
reading the tables document. I suggest just replacing the
existing sentence in tables-06a.txt with a more possible
transition that would also be uncontroversial as an example.
So:

"For example, a character can have its Unicode General_Category
value change from So to Sm, or from Lo to Ll, without
affecting the table results."

==============================================================

Page 4, last paragraph:

"constitute a preliminary proposal for updating..."

I suggest removing the word "preliminary" in that phrase,
as surely if you are about to get consensus to approve
the entire set of documents, it can no longer be considered
preliminary.

================================================================

Page 5, 2.1. LetterDigits (A)

"These rules identify characters..."

-->

"This category identifies characters..."

================================================================

Page 5, 2.2. Unstable (B)

"The category is used..."

-->

"This category is used..."

================================================================

Page 11, Appendix A, 2nd and 3rd paragraphs:

"A single TRUE or FALSE sets the default result value, and
following TRUE or FALSE set the result value."

-->

"A simple "True;" or "False;" rule sets the default
result value. Subsequent conditional rules that evaluate
to True or False may re-set the result value."

This corrects the casing of "TRUE" and "FALSE", since the
actual rules use "True" and "False", but also rewords it
a little to be clearer.

"If evaluated to TRUE, the codepoint is ok as used, if
evaluated to FALSE, it is not ok."

-->

"If evaluated to True, the codepoint is ok as used; if
evaluated to False, it is not o.k."

Corrected the casing of "TRUE" and "FALSE" and corrects
the comma run-on sentence to use a semicolon.

===============================================================

Page 12, top of page, Lookup description:

"True or False whether applying this rule is recommended for
lookup time (True) or not (False)."

-->

"True if application of this rule is recommended at lookup
time; False otherwise."

Simpler stated that way, and avoids an unfortunate ambiguity
in the current wording.

==============================================================

Page 12, Appendex A.2. Overview.

"The rules are not"

Not what? Either this was a fragment that didn't get deleted,
or it is incomplete and something is missing.

 



More information about the Idna-update mailing list