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

[dick@8760.com]

Chris,

I'm going to write-up some guidelines for calculating content-length for the MS
spec . I hope to distribute this information by Monday, 10/9.

Regards,

Dick Brooks
http://www.8760.com/

----- Original Message -----
From: Christopher Ferris <chris.ferris@east.sun.com>
To: Philippe DeSmedt <PDeSmedt@viquity.com>
Cc: <ebxml-transport@lists.ebxml.org>
Sent: Friday, October 06, 2000 7:47 AM
Subject: Re: ebXML TR&P: question re. MIME content length


> List-Unsubscribe:
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
>
> Thanks guys!
>
> Philippe DeSmedt wrote:
> >
> > 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
> > > > > >
> > > >
>
> --
>     _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
>    _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
>   _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
>        _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
> _/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903