W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2004

Re: Propsed new issue: variability of encoding in Miffy

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Wed, 14 Jan 2004 09:13:45 -0800
Message-ID: <400578C9.40101@oracle.com>
To: Amelia A Lewis <alewis@tibco.com>
Cc: xml-dist-app@w3.org

Amelia A Lewis wrote:

> On Wed, 14 Jan 2004 01:21:53 -0800
> Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote:
> 
>>Mark Nottingham wrote:
>>
>>
>>>On Jan 7, 2004, at 9:04 AM, Martin Gudgin wrote:
>>>
>>>
>>>>So I think what it happening here is that when things are sent a
>>>
>>>binary> ( and 8-bit? ) no encoding/decoding occurs at the MIME level.
>>>For 7-bit.> base64 and quoted-printable encoding/decoding happens at
>>>the MIME layer.> In all cases the octets at the layer above MIME are
>>>the same.>
>>>
>>>>Is this correct?
>>>
>>>
>>>In broad brushstrokes, yes.
>>
>>Not quite, there isn't any encoding/decoding that occurs for 7-bit.
>>The content-transfer-encoding is just a declaration that the data is
>>7-bit clean.
> 
> 
> Also, for 7bit and 8bit (and as part of the encoding for
> quoted-printable and the MIME version of base64), the line termination
> is specified to be CRLF, but processors are expected to be forgiving,
> and lines may be padded with extra spaces, which may also be freely
> removed. 

Is this stated in RFC 2045? Or does this occur in some other spec?
I could not locate this in RFC 2045. But I could have missed it.

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.

Thanks!

-Anish
--
Received on Wednesday, 14 January 2004 12:14:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC