Content-Length was Test Indicator Issue

[Nicholas Kassem <Nick.Kassem@eng.sun.com>]

>
>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