RE: Propsed new issue: variability of encoding in Miffy

I think the relevant text is in section 5 of[1]

Gudge

[1] http://www.faqs.org/rfcs/rfc1521.html

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Amelia A Lewis
> Sent: 14 January 2004 09:34
> To: Anish Karmarkar
> Cc: [email protected]
> Subject: Re: Propsed new issue: variability of encoding in Miffy
> 
> 
> On Wed, 14 Jan 2004 09:13:45 -0800
> Anish Karmarkar <[email protected]> wrote:
> > Amelia A Lewis wrote:
> > > On Wed, 14 Jan 2004 01:21:53 -0800
> > > Anish Karmarkar <[email protected]> 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.
> [email protected]
> 
>