ietf-822
[Top] [All Lists]

Re: Wrong Model (was Re: Alternative view of some aspects of MIME)

1992-03-10 07:38:27
On Tue, 10 Mar 92 09:33:01 +1000 you said:
Anyway the new
model is that the UNDERLYING form for text/anything is a sequence
of bytes in which end of line is represented by 0d0a(=CRLF).
I would not call that a new model, but rather the old 821/822 model.

The disadvantages are

1. It will be a real mistake if we later get character sets which
   contain 0d0a within a multi-octet character. However allowing
   0d0a in a line using q-p and not when using BASE64 would be a really
   strange way to solve the problem.
Perhaps not really. The definition of text as lines separated by CRLF
sequences has been made in a context of the ASCII character set, and
is easily extended for other single byte character sets where 0D and
0A are control characters. I have not yet seen a description of how
text will look exactly when multi-byte character sets will be in use.
In particular, I am not sure that lines will still be separated by
a sequence of two *single byte* entities. But as long as such texts
have a representation as a sequence of bytes, they will be encodable
with either base64 or q-p. The q-p encoding will look goofy, of course,
but it will preserve the content when decoded.

2. CRLF is really a transport artifact. Having it mean EOL in the
   underlying message is artificial, and it shows.
That artifact was already present in 821/822. This of course does not
make it neither better or worse 8-).

Well I liked the old system (and my model of it) better.
Your 'old' system was rather a new, more intelligent system with the
artifact removed....

P.S. better make sure that <CR>=0a and =0d<LF> are also illegal :-).
May sound repetitive, but bare CR's and bare LF's are allowed in 821/822.
Of course, this can sometimes lead to extra line separators when sending
between unlike machines, but that's life...                   /AF

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