MIME and HTTP

I told Paul and Roy that I'd send this out sooner; my apologies for
the 1-week delay.

Here's the issue:

draft-ietf-http-v10-spec-01.txt says:

>   HTTP redefines the canonical form of text media to allow multiple 
>   octet sequences to indicate a text line break.

As I see it, the wording is wrong in that it is:

a) ill-formed:
There can only be a single 'canonical form'. That is, you cannot
define a canonical form of an object with more than one form.

b) unacceptable as IETF document:
It is not acceptable for one standard to redefine another. HTTP cannot
'redefine' MIME. HTTP might use a different standard than MIME, but it
would not be a redefinition.

c) unacceptable as a 'current practice' informational document:
Informational documents do not define standards or acceptable
practice, they just describe what's done.

d) not WG consensus:
no WG member wants to call for the establishment of a different
object registry of MIME, or, for that matter, for HTTP to redefine
MIME.

Any one of these would be a good reason to change the wording.

Personally, I prefer the wording that was in the last discussion of
this topic on the mailing list, from
http://www.ics.uci.edu/pub/ietf/http/hypermail/1994q4/0267.html

namely:

>>  Internet media types [cite 1590] are registered in a canonical form.
>>  In general, Object-Bodies transferred via HTTP must be represented
>>  in the appropriate canonical form prior to the application of
>>  Content-Encoding and/or Content-Transfer-Encoding, if any, and
>>  transmission.
> 
>>  Object-Bodies with a Content-Type of text/*, however, may represent
>>  line breaks not only in the canonical form of CRLF, but also as CR
>>  or LF alone, used consistently within an Object-Body.  Conforming
>>  implementations *must* accept any of these three byte sequences as
>>  representing a single line break in text/* Object-Bodies.

except of course that the 'and/or Content-Transfer-Encoding' should be
dropped.

Received on Wednesday, 17 January 1996 20:17:32 UTC