[rfc-i] Incorrect use of the word "ASCII" in section 3.2
mrex at sap.com
Mon Mar 11 18:52:37 PDT 2013
Paul Hoffman wrote:
> P.S. Please do not interpret my offering of technically more correct
> wording above as supporting the idea in the paragraph. I think it is
> unnecessarily restrictive to prevent the use of ASCII in text that
> is needed to be read or understood. It's 2013, folks.
> If an example that is needed to be understood contains a character
> such as ü, it is better to include the character directly than putting
> in some placeholder and trying to describe that in the text surrounding
> the example. I hope ADs in the future can convince the RSE to change
> this rule for IETF Stream RFCs.
The problem with characters from not from US-ASCII is that you can
NEVER be sure that you recognize them (a) as not being from US-ASCII,
and (b) which Unicode codepoints what you're seeing actually refers to.
There are numerous Unicode codepoints that get displayed with glyphs
that are indistinguishable from US-ASCII latin characters.
To ensure that there will *NEVER* arise any ambiguity or confusion
about what is really meant, examples within RFCs MUST include
an additional representation with Unicode codepoints whenever
characters from outside US-ASCII are used to clarify what is meant.
Example Unicode codepoints that are typically indistuigishable
from US-ASCII when rendered as glyphs:
A 0x41 U+0391 U+0410
B 0x42 U+0342 U+0412
E 0x45 U+0395 U+0415
H 0x48 U+0397 U+0410
M 0x4D U+039C U+041C
P 0x50 U+03A1 U+0420
Examples where the actual codepoint doesn't matter will be entirely
unnecessary in the first place.
Examples where the actual codepoint matters may become highly abiguous
when the codepoint is *NOT* included.
More information about the rfc-interest