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 12:34:03 -0500
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Cc: xml-dist-app@w3.org
Message-id: <20040114123403.79ccb304.alewis@tibco.com>

On Wed, 14 Jan 2004 09:13:45 -0800
Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote:
> Amelia A Lewis wrote:
> > On Wed, 14 Jan 2004 01:21:53 -0800
> > Anish Karmarkar <Anish.Karmarkar@oracle.com> wrote:
> >>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.

Sorry.  There are too many bloody specs, all interacting with each
other.  I can answer this question if I can look at my references, but I
can't remember off-hand whether this is stated in 821/822, in the best
current practices RFC that discusses email, or in the MIME series (2045
et al.).

It might be mentioned in the section on quoted-printable, though.  The
reason that qp places an = at the end of soft-wrapped lines is so that
processors can tell where the line ending is, even if it's been padded.

The original reason for allowing this had to do with interoperation with
computers that used record-oriented structures (typically, 80-column
records, each corresponding to one line) for file storage; SMTP was
originally deployed on a sparse network in which best effort and
store-and-forward provided the most likely guarantee of timely delivery.
 Since such mail might easily pass through all sorts of bizarre and
unexpected systems (which were, however, required to ensure that it was
passed at least seven-bit clean, a significant step forward for the
time), the rules specified a least common denominator (NVT ASCII,
80-column lines), and permitted white space to be used where it was not
possible to otherwise indicate "nothing in this column".

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

Shouldn't allow it for HTTP anyway; illegal according to 2616.

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

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