Re: Comments on the HTTP/1.0 draft.

At  3:22 PM 12/7/94 -0600, I  wrote:
>We need to be clear which parts of MIME we are reusing and
>which parts we are rewriting. (Are we redefining EOL
>treatment for object bodies of type text/*?
>We might do as well to redefine EOL for the whole message
>to remap CR LF or CRLF to EOL before doing any MIME header/body
>processing. It might make a spec easier to write.)

As I looked at this more, and re-read the MIME spec, I realized this
suggestion makes no sense in the case that an HTTP message contains
arbitrary binary data types, since we clearly only want to cannonize EOL on
text data.

This led me back to asking: What are we doing (in a MIME framework) when we
say we tolerate or advocate a different or mixed EOL encoding than CRLF in
text bodies?

It seems to me that we are in effect defining a
new Content-Transfer-Encoding: which is not "binary" but something more
like"8bit-sloppy-eol" ;) ;) and saying that this new encoding shall be the
default for text bodies.

Alternately, we can say that text/html *is* treansferred as binary and push the
question off onto the HTML WG (then fight over how to treat EOL in the other
text types.) ;)

I'm a little worried about the more complex MIME constructs like multipart
going off the deep end if we can't make the treatment of EOLs 100% clear.

Can someone think of a nicer way to express the idea of mixing EOLs in MIME

    Albert Lunde            

Received on Wednesday, 7 December 1994 17:11:27 UTC