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