[Gen-art] LC review: draft-ietf-idnabis-bidi-06.txt
kenw at sybase.com
Mon Oct 5 22:14:36 CEST 2009
> Yes, this change occurred between bidi draft versions 3 and 4, and is
> due to Mati's proposal. I believe he came up with that suggestion
> based purely on the bidi criteria (grouping, uniqueness), and not
> based on what was allowed/disallowed in the Table draft.
Then I think the editor needs to address that more explicitly,
particularly at the point in Section 2 that says what bidi classes
are allowed in labels, so as not to lead to exactly the kind
of misreading and confusion that Joel Halpern has indicated.
> I think it's OK to leave CS in there, even if the Table spec excludes
> all of them in the current version of Unicode. Future versions of
> Unicode might introduce new CS characters that we want to allow in
> IDNs, though that seems unlikely.
Exceedingly unlikely. Astronomically unlikely. There is a
reason why bc=CS is actually Bidi_Class=Common_Separator,
as in characters that *separate* numeric parts and other
No character will be added to Bidi_Class=Common_Separator
in the future unless it is another punctuation analog (and
mostly likely even a compatibility equivalent to) a FULL STOP,
COMMA, SLASH, COLON, or a NO-BREAK SPACE.
I can't even conceive of the circumstances under which the IETF
would decide it would be a good idea to add a newly encoded
one of those into the allowed set of characters for IDNs
in the future.
More information about the Idna-update