Son of MIME (was comments)

Chuck Shotton said:
>Marc VanHeyningen said:
>>Albert Lunde said:
>>>Now, it seems like we are saying is that current practice
>>>(not just "bad" servers) is to treat EOL differently in
>>>the object body for performance reasons.
>>>
>>>In this, and in other ways, we are not just quoting the MIME
>>>spec, we are sort of rewriting it.
>>
>>Yes.  Absolutely.
>
>No, this is the HTTP spec! As Roy has said earlier, there are lots of
>things that are MIME-like, and may even be considered MIME by some people,
>but the HTTP standard doesn't say how to interpret the semantics of this
>MIME info. Rather, it says how to parse it. Interpretation is the MIME
>standard's problem. The MIME standard says nothing about the "proper"
>format for GIF files, XBMs, MPEGs, or any of the other content-types
>(except for text/plain, perhaps) used by HTTP. The HTTP standard doesn't
>either. So, why are we singling out text in object bodies?

The MIME standard does refer back a lot to RFC822 for text...

But the more I read these specs together, the more I seem to be
convincing myself that HTTP is not MIME, as the older spec
I quoted earlier suggests, but "MIME-like" as the recent draft says.

(Sort of a "Son of MIME" or "MIME meets Mozilla" ;)

We _are_ using a bunch of headers and the MIME/Internet media types
but the message structure is rather freely interpreted.

This leads me to some different thoughts:

- We should omit MIME Version headers, since the body returned
isn't really MIME-conforming.

- We should put off multipart types to HTTP-NG or some such
because 1) they aren't current practice 2) their syntax is
complex and may be sensitive to what we do with EOL.

We still need to agree what to advocate for for treatment of EOL
but it may be easier to explain if it's not MIME...

-- 
    Albert Lunde                      Albert-Lunde@nwu.edu

Received on Thursday, 8 December 1994 10:20:56 UTC