Re: Content-Length was Test Indicator Issue

[christopher ferris <chris.ferris@east.sun.com>]

All,

This is beginning to get extremely frustrating. It is
beginning to feel like Decision 2000 all over again;-)
We need to come to closure on this so that we can
move on to other outstanding issues.

We had a TR&P conference call today with an agenda 
published *well* in advance that we were going to 
come to closure on the four issues Ian laid out
in his email [1], including the Content-Length issue
which was raised by the POC team if I am not mistaken.

There were, prior to the call, a number of emails exchanged
on the list which clearly favored removal of the Content-Length
header. In addition, the issue was discussed at length in Tokyo
where the consensus was that most favored removal, but we were
awaiting feedback from Dick Brooks, who was not in attendance
as he was the principal author of the packaging spec.

The subject was also discussed in last weeks call, where
again, there was almost no opinion voiced which suggested
that we keep the Content-Length headers. This was followed
up with my proposal [2] which laid out explicit edits to
remove the Content-Length references from the spec.

MIME parsers have been parsing multipart messages for
years now, without the Content-Length (the parsing is
based on the boundary) which is, afterall, NOT a MIME 
header but an HTTP header.

As to the assertions that clearer language in the spec
is needed, I believe that might be true of previous
versions, but there has been a description of how to
compute Content-Length for at least the past two versions
of the spec. Granted, we could have referenced back
to the single description in each of the cases where
Content-Length was cited... We could also add Prasad's
note referencing RFC2616.

It was my understanding from the discussions in Tokyo
that most POC teams were ignoring Content-Length and that
most MIME parsers do so as well (because it is NOT a MIME
header afterall!). Please give me a compelling reason to leave 
it in besides generalities that it might come in handy.

Cheers,

Chris

[1] http://lists.ebxml.org/archives/ebxml-transport/200011/msg00147.html
[2] http://lists.ebxml.org/archives/ebxml-transport/200011/msg00097.html

Nicholas Kassem wrote:
> 
> >
> >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
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard