RE: ebXML TR&P: question re. MIME content length

[Philippe DeSmedt <PDeSmedt@viquity.com>]

All,

At the Dallas ebXML TR&P face-to-face, there was an action item to precisely
define content-length in MIME, and I was asked to check with Dick Brooks on
this. Below is the exchange. If you start reading from the bottom, and take
into account the subsequent comments, I believe you'll be able to figure it
out :) . Any volunteers to update the spec accordingly?

-Philippe
_______________________________
Philippe De Smedt
Architect
Viquity Corporation (www.viquity.com)
1161 N. Fair Oaks Avenue
Sunnyvale, CA 94089-2102
(408) 548-9722
(408) 747-5586 (fax)
pdesmedt@viquity.com


-----Original Message-----
From: Rik Drummond [mailto:rvd2@worldnet.att.net]
Sent: Monday, October 02, 2000 5:45 AM
To: Philippe DeSmedt
Subject: FW: CORRECTION - RE: ebXML TR&P: question re. MIME content
length




-----Original Message-----
From: Dick Brooks [mailto:dick@8760.com]
Sent: Sunday, October 01, 2000 8:05 PM
To: Rik Drummond
Subject: RE: CORRECTION - RE: ebXML TR&P: question re. MIME content
length


Agree.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Rik Drummond [mailto:rvd2@worldnet.att.net]
> Sent: Sunday, October 01, 2000 7:38 PM
> To: Dick Brooks
> Subject: RE: CORRECTION - RE: ebXML TR&P: question re. MIME content
> length
>
>
> i think the only way to interpret a boundary is crlf -- s;sdfdjfjd-- crlf
>
> not just the end... that is because a blank line followed by a
> --.s.jfdj is
> a boundary... rik
>
> -----Original Message-----
> From: Dick Brooks [mailto:dick@8760.com]
> Sent: Sunday, October 01, 2000 7:08 PM
> To: Rik Drummond; Philippe DeSmedt
> Subject: RE: CORRECTION - RE: ebXML TR&P: question re. MIME content
> length
>
>
> Rik, you meant END with a CRLF, right?
>
> Dick Brooks
> Group 8760
> 110 12th Street North
> Birmingham, AL 35203
> dick@8760.com
> 205-250-8053
> Fax: 205-250-8057
> http://www.8760.com/
>
> InsideAgent - Empowering e-commerce solutions
>
> > -----Original Message-----
> > From: Rik Drummond [mailto:rvd2@worldnet.att.net]
> > Sent: Sunday, October 01, 2000 7:02 PM
> > To: Dick Brooks; Philippe DeSmedt
> > Subject: RE: CORRECTION - RE: ebXML TR&P: question re. MIME content
> > length
> >
> >
> > i think it should say all lines start with crlf, even the last
> > boundery....
> > rik
> >
> > -----Original Message-----
> > From: Dick Brooks [mailto:dick@8760.com]
> > Sent: Sunday, October 01, 2000 4:57 PM
> > To: dick@8760.com; Philippe DeSmedt
> > Cc: 'Rik Drummond'
> > Subject: CORRECTION - RE: ebXML TR&P: question re. MIME content length
> >
> >
> > The statement " (assume all lines end with CRLF except the last
> > boundary):"
> > SHOULD HAVE READ
> > " (assume all lines end with CRLF including the last boundary):"
> >
> > Dick Brooks
> > Group 8760
> > 110 12th Street North
> > Birmingham, AL 35203
> > dick@8760.com
> > 205-250-8053
> > Fax: 205-250-8057
> > http://www.8760.com/
> >
> > InsideAgent - Empowering e-commerce solutions
> >
> > > -----Original Message-----
> > > From: Dick Brooks [mailto:dick@8760.com]
> > > Sent: Sunday, October 01, 2000 4:31 PM
> > > To: Philippe DeSmedt
> > > Cc: 'Rik Drummond'; Dick Brooks
> > > Subject: RE: ebXML TR&P: question re. MIME content length
> > >
> > >
> > > Philippe,
> > >
> > > Thanks for the kind words, I too enjoy getting together with
> you and the
> > > others. We are very fortunate to have such a highly functional team of
> > > people in TRP. The key, I believe, is our ability to work and
> > > play together;
> > > this makes it enjoyable.
> > >
> > > Hopefully I can clear up the confusion over content-length, so
> > here goes:
> > >
> > > Content-length has one meaning: the number of OCTETS of
> "actual payload
> > > data" within a message body or body part. The HTTP spec (RFC
> > > 2616) states it
> > > as follows:
> > >    "When a Content-Length is given in a message where a
> message-body is
> > >    allowed, its field value MUST exactly match the number of OCTETs in
> > >    the message-body. HTTP/1.1 user agents MUST notify the user when an
> > >    invalid length is received and detected."
> > >
> > > Content-length is fairly straight forward to calculate at the message
> > > envelope level, it should equal the total number of octets
> > > starting with the
> > > first character of the body through the last character of the
> body, for
> > > example:
> > >
> > > Content-length: 3
> > > Content-type: text/plain
> > >
> > > 123
> > >
> > > (note there is no CRLF after 123, if there had been the
> > > content-length would
> > > have been 5). The blank line after the MIME headers is
> > considered part of
> > > the headers and is not included in the calculation of content-length.
> > >
> > > Things can get a bit tricky when you're dealing with multipart's and
> > > boundaries. When calculating the content-length for the message
> > > envelope you
> > > must include all body parts and boundaries in the calculation,
> > for example
> > > (assume all lines end with CRLF except the last boundary):
> > >
> > > Content-length: 129
> > > Content-type: multipart/related; boundary="XXX"
> > >
> > > --XXX
> > > Content-length: 3
> > > Content-type: text/plain
> > >
> > > 123
> > > --XXX
> > > Content-length: 5
> > > Content-type: text/plain
> > >
> > > 456
> > >
> > > --XXX--
> > >
> > > The 129 content-length breaks out as follows (calculation
> > includes CRLF at
> > > the end of lines):
> > >
> > > 7 octets for the first boundary string
> > > 19 octets for the Content-length header of the first body part
> > > 26 octets for Content-type
> > > 2 octets for CRLF blank line
> > > 3 octets of actual payload
> > > 9 octets for the boundary between body part 1 and 2
> > > 19 octets for the Content-length header of the second body part
> > > 26 octets for Content-type
> > > 5 octets of actual payload ((note inclusion of a CRLF this time)
> > > 13 octets for the ending boundary
> > >
> > > Notice once again the blank line following the multipart/related
> > > MIME header
> > > is not counted as part of the content-length because it's
> > > considered part of
> > > the MIME headers.
> > > ----------------------------------
> > >
> > > There are a couple of fundamental "rules" to consider when
> dealing with
> > > multipart's (ref RFC 2046):
> > >
> > > - The boundary delimiter line is defined as a line
> > >    consisting entirely of two hyphen characters ("-", decimal
> value 45)
> > >    followed by the boundary parameter value from the
> Content-Type header
> > >    field, optional linear white space, and a terminating CRLF.
> > >
> > > - The boundary delimiter MUST NOT appear inside any of the
> encapsulated
> > > parts, on a
> > >   line by itself or as the prefix of any line.
> > >   Said another way, boundaries must appear at the beginning of
> > a line and
> > > the pattern MUST NOT appear in the content of a
> > >   body part.
> > >
> > > -  The boundary delimiter MUST occur at the beginning of a line, i.e.,
> > >    following a CRLF, and the initial CRLF is considered to be attached
> > >    to the boundary delimiter line rather than part of the preceding
> > >    part.  The boundary may be followed by zero or more characters of
> > >    linear white space. It is then terminated by either
> 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.  If no Content-Type
> > >    field is present it is assumed to be "message/rfc822" in a
> > >    "multipart/digest" and "text/plain" otherwise.
> > >
> > >    NOTE:  The CRLF preceding the boundary delimiter 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 boundary delimiter line, the first of which
> is part of
> > >    the preceding body part, and the second of which is part of the
> > >    encapsulation boundary.
> > >
> > >    The boundary delimiter line following the last body part is a
> > >    distinguished delimiter that indicates that no further body parts
> > >    will follow.  Such a delimiter line is identical to the previous
> > >    delimiter lines, with the addition of two more hyphens after the
> > >    boundary parameter value.
> > >
> > >      --gc0pJq0M:08jU534c0p--
> > >
> > >    NOTE TO IMPLEMENTORS:  Boundary string comparisons must compare the
> > >    boundary value with the beginning of each candidate line.  An exact
> > >    match of the entire candidate line is not required; it is
> sufficient
> > >    that the boundary appear in its entirety following the CRLF.
> > >
> > > I hope this helped.
> > >
> > >
> > > Dick Brooks
> > > Group 8760
> > > 110 12th Street North
> > > Birmingham, AL 35203
> > > dick@8760.com
> > > 205-250-8053
> > > Fax: 205-250-8057
> > > http://www.8760.com/
> > >
> > > InsideAgent - Empowering e-commerce solutions
> > >
> > > > -----Original Message-----
> > > > From: Philippe DeSmedt [mailto:PDeSmedt@viquity.com]
> > > > Sent: Friday, September 29, 2000 6:29 PM
> > > > To: 'dick@8760.com'
> > > > Cc: 'Rik Drummond'
> > > > Subject: ebXML TR&P: question re. MIME content length
> > > >
> > > >
> > > > Dick,
> > > >
> > > > Good seeing you again at the face-to-face. Have a fun and
> > > > productive time at
> > > > ecWorld.
> > > >
> > > > After you left, an issue that was discussed is that of
> > content length in
> > > > MIME (section 7.2.2, page 11, in the ebXML TR&P messaging
> > document). It
> > > > caused a lot of grief at the San Jose ebXML PoC, mostly due to
> > > > the fact that
> > > > there appears to be no clear and definitive specification as
> > to what the
> > > > content length applies to (i.e., how it is measured -- where it
> > > starts and
> > > > where it ends). We're hoping that you can shed some light on
> > this murky
> > > > issue. Thanks much.
> > > >
> > > > -Philippe
> > > > _______________________________
> > > > Philippe De Smedt
> > > > Architect
> > > > Viquity Corporation (www.viquity.com)
> > > > 1161 N. Fair Oaks Avenue
> > > > Sunnyvale, CA 94089-2102
> > > > (408) 548-9722
> > > > (408) 747-5586 (fax)
> > > > pdesmedt@viquity.com
> > > >
> >