MIME and HTTP
Larry Masinter (masinter@parc.xerox.com)
Wed, 17 Jan 1996 20:14:38 PST
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.