[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: ebXML TR&P: question re. MIME content length
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC