Re: Propsed new issue: variability of encoding in Miffy

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.


On Jan 14, 2004, at 5:23 PM, Martin Gudgin wrote:

>
>
>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Amelia A Lewis
>> Sent: 14 January 2004 09:34
>> To: Anish Karmarkar
>> Cc: [email protected]
>> Subject: Re: Propsed new issue: variability of encoding in Miffy
>>
> <SNIP/>
>>> If processors are indeed allowed to pad lines with extra
>> spaces, then
>>> I would have to agree with Noah that we must not allow
>> 7-bit and 8-bit
>>> value for cte field.
>>
>> Shouldn't allow it for HTTP anyway; illegal according to 2616.
>
> Amy,
>
> Do you read 2616 as saying that CTE is illegal in HTTP, period? Or just
> that it cannot appear as an HTTP header? I ask because the discussion
> here is about CTE on individual parts of a multipart\related package.
>
> Gudge