[OT] Re: Anyone competing with Zend?

Andy Bradford amb-plug at bradfords.org
Mon Sep 26 22:40:38 MDT 2005

[This is a resend]

Thus said Lonnie Olson on Mon, 26 Sep 2005 14:38:09 MDT:

> Actually No. There is a newline  before the next boundary, that is why
> it comes  on the next line.  There is not an  *extra* newline, however
> that is not required.

I'm sorry,  but I don't  believe that RFC 1521  and RFC 2049  agree with
you... An *extra* newline is required.

[RFC 1521]


   Note that the encapsulation boundary must occur at the beginning of a
   line, i.e., following a CRLF, and that the initial CRLF is considered
   to be attached to the encapsulation boundary rather than part of the
   preceding part.  The boundary must be followed immediately either by
   another CRLF and the header fields for the next part, or by two
   CRLFs, in which case there are no header fields for the next part
   (and it is therefore assumed to be of Content-Type text/plain).

      NOTE: The CRLF preceding the encapsulation line is conceptually
      attached to the boundary so that it is possible to have a part
      that does not end with a CRLF (line break). Body parts that must
      be considered to end with line breaks, therefore, must have two
      CRLFs preceding the encapsulation line, the first of which is part
      of the preceding body part, and the second of which is part of the
      encapsulation boundary.

[RFC 2049]

Appendix B:

    (7)   The BNF for the multipart media type has been
          rearranged to make it clear that the CRLF preceeding
          the boundary marker is actually part of the marker
          itself rather than the preceeding body part.

So, the CRLF that precedes the boundary is actually part of the boundary
itself, which means  that if you only  have one newline then  it will be
stripped by an  RFC compliant MIME parser. Indeed, none  of the examples
in RFC  2049 show a  boundary that immediately  follow the last  line of
text without an additional newline.

> The  messages Wade,  and myself  send *are*  formatted correctly.  The
> problem is only with the way Mail.app *displays* the messages.

Sounds like the  MIME parser is compliant while the  MIME writer is not.
Hence, the  fact that the PLUG  trailer appears to merge  right into the
last line of Wade's text.

GnuPG ID 0xA63888C9 (D2DA 68C9 BB2B 26B4 8204  2219 A43E F450 A638 88C9)
[-----------[system uptime]--------------------------------------------]
 10:40pm  up 98 days,  7:18,  3 users,  load average: 1.06, 1.48, 1.40

More information about the PLUG mailing list