Re: [xml2rfc] [Tools-discuss] [Rfc-markdown] New xml2rfc release: v3.16.0

[John C Klensin <[e-mail]>]

--On Thursday, January 19, 2023 22:01 +0100 Carsten Bormann
<[e-mail]> wrote:

> On 2023-01-19, at 21:46, Marc Petit-Huguenin
> <[e-mail]> wrote:
>> 
>> Because what I find to be problematic is allowing Unicode
>> everywhere.
> 
> We already allow Unicode everywhere (all that ASCII is
> Unicode, too).
> 
> It's only that some of the Unicode characters are shunned in
> certain contexts (and these aren't even exactly the
> non-ASCII characters).
> 
> This discussion would be easier to take serious if we could at
> least get the terminology right.

Carsten,

I'm feeling forced into the uncomfortable role of picker of
nits.  However, strictly speaking, "all that ASCII is Unicode,
too", is not strictly true either.  For starters, ASCII is a
seven-bit encoding, not an eight bit or longer one.  It is
certainly the case that the Unicode characters from U+0021
through U+007E correspond to the "printable" ASCII characters
designated in the ASCII standard as 2/1 through 7/14 and that,
with, IIR, slight differences in definitions, the so-called C0
controls plus SP (U+0020) and DEL (U+007F) correspondence as
well.  Expressed in Hex UTF-8, the ASCII characters have the
same numeric values as the corresponding Unicode characters if
the ASCII ones are represented as right-justified in octets (not
the only plausible or historically important representation).
But that does not make them the same, especially if UTF-8 is a
preference and not a requirement.  And, of course, in UTF-16 or
UTF-32 (both perfectly good Unicode representations), the
characters that corresponding to ASCII occupy 16 or 32 bits
respectively with many leading zero bits.

I now return you to the usual hair-splitting.

     john