RE: Content-Length

[Dick Brooks <dick@8760.com>]

I think some clarification is needed.

The consensus on today's call was to remove the Content-Length header from
the normative
part of the ebXML message envelope (multipart/related envelope) and
subsequent body parts.
However everyone recognized that HTTP requires a Content-Length header so
the Messaging
Service spec will contain a section called HTTP bindings that will include a
Content-Length header
on the ebXML message envelope (but not the subsequent body parts).

This means that Content-Length will not appear in the FTP, or SMTP binding
sections, which are
also TBD.

BTW: I agree with Michael Joya and Nick that a Content-Length does provide
an opportunity to
implement optimizations, that was the reason for its inclusion in the
original packaging design.

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: Nicholas Kassem [mailto:Nick.Kassem@eng.sun.com]
> Sent: Thursday, November 30, 2000 4:41 PM
> To: Michael Joya; ebxml-transport@lists.ebxml.org
> Subject: Content-Length was Test Indicator Issue
>
>
> 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>
>
>
> >
> >Issue 2: Content-Length.
> >It was agreed unanimously that it be removed from all but the HTTP
> >binding (transport-level header).
> >---
> >    I disagree with this strongly. This forces implementors to use a
> >regular expression or similar matching pattern to grab out each segment
> >of the entire message. This makes for slow, clunky implementations that
> >may or may not agree with each other. A content-length header is
> >invaluable to message parsing for simplicity and speed. It also gives a
> >great starting point for message digests, signing and encryption.
> >Security is an upcoming issue in TRP if I am not mistaken. I believe the
> >issue of parsing payloads will come back to bite us if Content-Length is
> >not communicated explicitly from sender to receiver.
> >
> >    That said, can someone explain why this was brought out? It doesn't
> >seem to do any good. I think that what is really needed here is a
> >clearer description of Content-Length calculation in the specification;
> >including at least one sample of a complete wire dump of an actual
> >transmission. The ones I have seen passed around from the Tokyo
> >demonstration were, in some places, contradictory to each other, or to
> >known specifications.
> >
> >    It seems as though the design was changed to conform to the proof,
> >rather than the other way around. Can someone from TRP shed
> light on this?
>
> I disagree with removing the Content-Length too. I don't think we
> have (as
> yet) fully exercised the potential of compound messages (multiple
> payloads)
> and hence may be prematurely discounting the value of having an early
> "hint" for the size of a given payload element. This hint may be
> useful for
> triggering different optimization strategies and algorithms depending on
> payload type/size. IMHO, I believe most of the implementation problems
> encountered to-date could be handled via word-smithing the spec.
>
> Nick
>