Re: Content-Length was Test Indicator Issue

[Scott Hinkelman <srh@us.ibm.com>]

I feel that the "description" in the 21d spec on calculation was good and
accurate. The "example" is poor,
and I agree there should be a dump (in an appendix) but human-countable
(short). Clearly, the length is not
required, and in fact IBM did not use it in Tokyo as our parse engine
currently relies on the boundary during stream
processing. That is NOT to say that this is the *best* way to do it, and I
can see advantages to having it
present for non-stream designs. The question really is, does ebXML want to
provide a structure that allows
more flexibility in MIME processing but yet be compatable with existing
parse engines?
In Tokyo, my opinion was and still is that it enables processing capability
and I don't know why there would be strong objection for it to exist. Is
there?

Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



christopher ferris <chris.ferris@east.sun.com> on 11/30/2000 05:25:38 PM

To:   Nicholas Kassem <Nick.Kassem@eng.sun.com>,
      ebxml-transport@lists.ebxml.org
cc:   Michael Joya <mike.joya@xmlglobal.com>
Subject:  Re: Content-Length was Test Indicator Issue



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