ietf-822
[Top] [All Lists]

Re: Don't change RFC822 for the worse!

1994-12-07 22:02:22
< I've got two replies so far.  I'd like to state my objection for those
< responses here.
<
<< You have been misled. The intent of the text in RFC 822 is clear, and
<< confirmed by the author, to mean US ASCII, not "anything that will fit in
<< 7 bits".
<
< Since RFC-822 is a standard, not a someone's memorandum, I think
< confirmation by some other one is not needed even by the author.  We
< cannot implement a system if we need confirmation by the author for each
< standard.
<
< RFC-822 is ambiguous about the difference between characters and codes.
< It has been led two different interpretations.  For those who have been
< used only ASCII characters, the difference is not crucial. But for those
< people who uses more than one character set for usual communication, this
< is very much important.
<
< RFC-822 says as follows,
<
<     CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)

It appears to be ambiguous only because you're ignoring the statement
immedialy preceding what you quote here:

          The following rules are used to define an underlying lexical
     analyzer,  which  feeds  tokens to higher level parsers.  See the
     ANSI references, in the Bibliography.

If you look at the ANSI references in the Bibliography, you find the
exact definition of what is meant by ASCII:

     ANSI.  "USA Standard Code  for  Information  Interchange,"  X3.4.
        American  National Standards Institute: New York (1968).  Also
        in:  Feinler, E.  and J. Postel, eds., "ARPANET Protocol Hand-
        book", NIC 7104.

This reference DOES discuss the character set and its encoding scheme.

< Since RFC-822 uses only the term ASCII but says nothing about character
< sets and its encoding scheme, we have been interpreted the above
< definition like,
<
<   1. <any ASCII character> means codepoints 0/0-7/15(0.-127.).
<   2. RFC-822 itself does not define character encoding scheme.

You've been working under false assumptions.

Nonetheless, since you have, and other enclaves around the world have done
similar extensions in other, incompatible, ways, this working group is
responsible for dealing with the mess.

                                        Tony Hansen
                            hansen(_at_)pegasus(_dot_)att(_dot_)com, 
tony(_at_)attmail(_dot_)com
                                att!pegasus!hansen, attmail!tony