Re: Propsed new issue: variability of encoding in Miffy

On Thu, 15 Jan 2004 10:14:58 -0500
Mark Nottingham <[email protected]> wrote:

> RFC2616, Section 14.15:
> 
> > There are several consequences of this. The entity-body for
> > composite
> >    types MAY contain many body-parts, each with its own MIME and
> >    HTTP headers (including Content-MD5, Content-Transfer-Encoding,
> >    and Content-Encoding headers). If a body-part has a
> >    Content-Transfer- Encoding or Content-Encoding header, it is
> >    assumed that the content of the body-part has had the encoding
> >    applied, and the body-part is included in the Content-MD5 digest
> >    as is -- i.e., after the application. The Transfer-Encoding
> >    header field is not allowed 
> > within
> >    body-parts.
> 
> Section 19.4.5:
> 
> >    HTTP does not use the Content-Transfer-Encoding (CTE) field of
> >    RFC 2045. Proxies and gateways from MIME-compliant protocols to
> >    HTTP 
> > MUST
> >    remove any non-identity CTE ("quoted-printable" or "base64") 
> > encoding
> >    prior to delivering the response message to an HTTP client.
> >
> >    Proxies and gateways from HTTP to MIME-compliant protocols are
> >    responsible for ensuring that the message is in the correct
> >    format and encoding for safe transport on that protocol, where
> >    "safe transport" is defined by the limitations of the protocol
> >    being used. Such a proxy or gateway SHOULD label the data with an
> >    appropriate Content-Transfer-Encoding if doing so will improve
> >    the likelihood of safe transport over the destination protocol.
> 
> I interpret this latter section as only applying to the HTTP entity, 
> not any body parts in a composite type. YMMV.
> 
> So, to answer your question, it's not allowed on the HTTP (top-level) 
> message, but CTE may be used in the component parts.

Agreed.  RFC 2557 (MHTML, which introduced multipart/related to the best
of my knowledge) uses CTE in part headers.

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
[email protected]