I have had a close look at the latest (I hope, it's marked January 92) draft,
and I have prepared a proposal for a few changes in order to 1- correct some
parts that are wrong (because they do not reflect the actual intentions
that were explained at long yesterday) 2- add some warnings for the
implementer.
----------
In 5, after the paragraph :
This should be interpreted to mean that the message body (or
body part) is a base64 ASCII encoding of data that was
originally in ISO-8859-1, and will be in that character set
again after decoding.
Add a new paragraph like this one, but in good english :
It should be noted that, when textual data is to be encoded,
it must be submitted to the encoder with lines separated by
a CRLF sequence, and not with any other separator that
happens to be in local use. When textual data is decoded,
the inverse operation must be performed after the decoding.
Comment : clarification.
----------
In 5.1, change the beginning of Rule #1 to read :
Rule #1: (General 8-bit representation) Any octet,
may be represented by an "=" followed by a two digit
hexadecimal representation of the octet's value.
... etc etc
Comment : rule #1 was wrong : it did make reference to the local newline
convention, while text should be in 'Internet standard' form before the
encoding. Also, there is no reason to disallow the representation of
CRLF by =0D=0A, so the 'except' makes no sense.
----------
In 5.1, change Rule #4 to read :
Rule #4 (Line Breaks): Any CRLF sequence appearing
in the data may be represented by a (RFC 822) line
break, which is also a CRLF sequence, in the Quoted-
Printable encoding. Isolated CRs and LFs, or LF CR
sequences are not affected by this rule and must thus be
represented using the "=0D", "=0A" and "=0A=0D"
notations respectively. Since textual data to be encoded
must be presented to the encoder with lines separated by
CRLF sequences, this rule allows the encoder to preserve
the line breaks for ease of human reading.
Comment : rule #4 was also wrong, since it did also make reference to the
local newline convention. 'must' has been replaced by 'may', since CRLF
may also be represented as =0D=0A. More clarification added.
----------
In 7.1, just before the 7.1.1 title, add a paragraph like :
All forms of text must be transferred with lines separated
by CRLF sequences, as prescribed in RFC822. In particular,
when textual data must be encoded for transport, local line
separators must be replaced by CRLF sequences before
encoding. The reverse transformation must be performed
after decoding textual data.
Comment : clarification, clarification...
----------
General comment : the modifications to rules #1 and #4 are more than simple
editorial changes. Nevertheless, it seems that these changes put the words
in sync with what the most knowledgeable people think of what the
specification actually means.
/AF