Re: Next step (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt

> The mail seems to me to fall into three categories:

> (1) Evidence that I still cannot do ABNF properly, plus a few other
> editorial issues.  The most important of the ABNF issues is that "u"
> and "U" cannot be specified as different without escaping both into
> their character code positions (since character-literals in ABNF are
> case-insensitive).

This says to me that ABNF is the wrong tool for the job here.  It seems
to me that we really want to specify "backslash" "lowercase u" and
"backslash" "uppercase U" rather than octet sequences, so that the
result is not tied to ASCII (while it's unlikely that anyone wants to
inject Unicode into EBCDIC text, I just don't like seeing a problem
"fixed" by introducing other problems in a workaround instead of
addressing the real problem).

If ABNF can't do what we want, I'd say, use something better-suited to
the need.  Perhaps it would be enough to say that the spec uses ABNF
except that the character after the backslash is case-sensitive?

That said, I don't consider this a showstopper - not that my opinion of
what is or isn't a showstopper necessarily matters....

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               mouse@xxxxxxxxxxxxxxxxxxxxxx
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B