ietf-822
[Top] [All Lists]

Re: Newline problem: Another stab

1992-03-03 19:55:04
I may not have been clear enough about this, so let me try one more time.

I do not care about the formal model.  I do not care about the
theoretical algorithm for newlines.  I care very strongly about one
thing:  existing assumptions about the way lines are separated should
NOT be broken by MIME.

What we have to remember is that there are lots of enclaves with which
assumptions are made about line breaks that are NOT conformant to CRLFs.
 There is NOTHING WRONG WITH THIS, if it is done properly -- i.e. if the
gateways to those localities do the right thing with translating between
line break conventions.

What this means, to me, is that in ANY encoding scheme, either line
breaks represent line breaks, period, or line breaks are "noise" and
ignored on the decoding end.  The latter describes base64.  The former
describes the existing prose for quoted-printable.  A change which says
that the CRLF form is always used in the encoded data may or may not
muddy this, depending on the wording.  If what it says is that line
breaks are always represented as CRLF's (note:  NOT as 0d0a) then this
can be ignored in enclaves the same way that the similar statement about
plain text is ignored, because it will be dealt with at the gateways. 
If it says that line breaks are represented as CRLF  in local storage
or, as people are more likely to argue, that line breaks may be
converted to 0d0a, I fear massive confusion and a net-wide profusion of
spurious newlines.

I really hope we don't rush into this kind of change.  -- Nathaniel

<Prev in Thread] Current Thread [Next in Thread>