[rfc-i] Incorrect use of the word "ASCII" in section 3.2

Martin Rex 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:

  Glyph  US-ASCII
    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.


-Martin


More information about the rfc-interest mailing list