Re: Propsed new issue: variability of encoding in Miffy

Anish Karmarkar <[email protected]>
Newsgroups gmane.text.xml.distributed
Message-ID <[email protected]>
Amelia A Lewis wrote:

> On Wed, 14 Jan 2004 01:21:53 -0800
> Anish Karmarkar <[email protected]> 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
--
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.