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

Re: Propsed new issue: variability of encoding in Miffy

From: Amelia A Lewis <alewis@tibco.com>
Date: Wed, 14 Jan 2004 10:54:30 -0500
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Cc: xml-dist-app@w3.org
Message-id: <20040114105430.7e16c45a.alewis@tibco.com>

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.  Recommended minimum line length differs for 8bit versus 7bit. 
Using either also implies (though it does not guarantee) that most
"characters" in the control region are absent, and particularly that
0x00 does not occur.

These are slightly different expectations than the expectation that data
will be 7bit clean or 8bit clean (the difference between 8bit and binary
is the difference between text (which can be mangled, per line ending
convention and introduction and removal of trailing space) and
really-truly 8bit-clean).

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com
Received on Wednesday, 14 January 2004 11:01:54 UTC

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