[Next] [Previous] [Up] [Top] [Full Contents] [Search]

Appendices

D. Relationship to MIME

HTTP/1.0 reuses many of the constructs defined for Internet Mail (RFC 822 [8]) and the Multipurpose Internet Mail Extensions (MIME [6]) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, HTTP is not a MIME-conforming application. HTTP's performance requirements differ substantially from those of Internet mail. Since it is not limited by the restrictions of existing mail protocols and gateways, HTTP does not obey some of the constraints imposed by RFC 822 and MIME for mail transport.

This appendix describes specific areas where HTTP differs from MIME. Gateways to MIME-compliant protocols must be aware of these differences and provide the appropriate conversions where necessary. No conversion should be necessary for a MIME-conforming entity to be transferred using HTTP.

D.1 Conversion to Canonical Form

MIME requires that an entity be converted to canonical form prior to being transferred, as described in Appendix G of RFC 1521 [6]. Although HTTP does require media types to be transferred in canonical form, it changes the definition of "canonical form" for text-based media types as described in Section 8.1.1.

D.1.1 Representation of Line Breaks

MIME requires that the canonical form of any text type represent line breaks as CRLF and forbids the use of CR or LF outside of line break sequences. Since HTTP allows CRLF, bare CR, and bare LF (or the octet sequence(s) to which they would be translated for the given character set) to indicate a line break within text content, recipients of an HTTP message cannot rely upon receiving MIME-canonical line breaks in text.

Where it is possible, a gateway from HTTP to a MIME-conformant protocol should translate all line breaks within text/* media types to the MIME canonical form of CRLF. However, this may be complicated by the presence of a Content-Encoding and by the fact that HTTP allows the use of some character sets which do not use octets 13 and 10 to represent CR and LF (as is the case for some multi-byte character sets).

D.1.2 Default Character Set

MIME requires that all subtypes of the top-level Content-Type "text" have a default character set of US-ASCII [18]. In contrast, HTTP defines the default character set for "text" to be ISO88591 [19] (a superset of US-ASCII). Therefore, if a text/* media type given in the Content-Type header field does not already include an explicit charset parameter, the parameter

;charset="iso-8859-1"
should be added by the gateway if the entity contains any octets greater than 127.

D.2 Default Content-Transfer-Encoding

The default Content-Transfer-Encoding (CTE) for all MIME messages is "7bit". In contrast, HTTP defines the default CTE to be "binary". Therefore, if an entity does not include an explicit CTE header field, the gateway should apply either the "quoted-printable" or "base64" transfer encodings and add the appropriate Content-Transfer-Encoding field. At a minimum, the explicit CTE field of

Content-Transfer-Encoding: binary
should be added by the gateway if it is unwilling to apply a mail-safe encoding.

D.3 Introduction of Content-Encoding

MIME does not include any concept equivalent to HTTP's Content-Encoding header field. Since this acts as a modifier on the media type, gateways to MIME-conformant protocols should either change the value of the Content-Type header field or decode the Entity-Body before forwarding the message.

Note
Some experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<encoding-mechanisms>" to perform an equivalent function as Content-Encoding. However, this parameter is not part of the MIME specification at the time of this writing.

T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen - 12 MAR 95

[Next] [Previous] [Up] [Top] [Full Contents] [Search]

Generated with CERN WebMaker