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

Patrik Fältström patrik at frobbit.se
Tue Jul 21 10:03:00 CEST 2009


On 21 jul 2009, at 01.26, Kenneth Whistler wrote:

> =================================================================
>
> 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."

Fixed!

> ==============================================================
>
> 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.

Fixed!

> ================================================================
>
> Page 5, 2.1. LetterDigits (A)
>
> "These rules identify characters..."
>
> -->
>
> "This category identifies characters..."

Fixed!

> ================================================================
>
> Page 5, 2.2. Unstable (B)
>
> "The category is used..."
>
> -->
>
> "This category is used..."

Fixed!

> ================================================================
>
> 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.

Fixed!

> ===============================================================
>
> 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.

Fixed!

> ==============================================================
>
> 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.

This was something not deleted.

Fixed.

    Patrik



More information about the Idna-update mailing list