- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Wed, 14 Jan 2004 09:13:45 -0800
- 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