- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Thu, 15 Jan 2004 15:58:31 -0800
- To: Martin Gudgin <mgudgin@microsoft.com>
- Cc: Amelia A Lewis <alewis@tibco.com>, xml-dist-app@w3.org
Martin Gudgin wrote: > I think the relevant text is in section 5 of[1] > > Gudge > > [1] http://www.faqs.org/rfcs/rfc1521.html > RFC 1521 is obsoleted by RFC 2045. Looking at 2049 (pointed to by Amy), it seems like misbehaving SMTP transport agents may pad lines with spaces or remove them. What that really means is that if we wanted to send MIFFY/MTOM over SMTP, and we wanted the message to ensure that misbehaving SMTP gateways do not garble the message, then the CTE must be either quoted-printable or base64 (independent of the data domain). Did I understand the RFC correctly? For transports, like HTTP, which are safe for binary, a more restrictive domain such as 7bit and 8bit should not pose a problem. -Anish -- > >>-----Original Message----- >>From: xml-dist-app-request@w3.org >>[mailto:xml-dist-app-request@w3.org] On Behalf Of Amelia A Lewis >>Sent: 14 January 2004 09:34 >>To: Anish Karmarkar >>Cc: xml-dist-app@w3.org >>Subject: Re: Propsed new issue: variability of encoding in Miffy >> >> >>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 Thursday, 15 January 2004 18:58:38 UTC