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 --