[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Content-Length was Test Indicator Issue
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC