OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Test Indicator Issue


 From an implementor's perspective:

   I'm writing TR&P and registry stuff for the POC team right now, and 
from an engineering perspective, some of these changes do not make clear 
sense to me. POC seems to be rolling now and I'd like to provide some 
feedback on TRP; seeing as how it is the first part of the puzzle we 
need to grok in order to make something that looks functional.

---
Issue 1: I am on the hook to provide two formal proposals for addressing
the test indicator. There was some consensus that it be added, but we 
need to have clearer semantics defined w/r/t MSH handling REQUIRED
to be supported by an implementation. I'll try to get that to the
list today and put it to a list vote.
---
   My vote, were I to have one, would be to leave it out. I believe that 
it's an extraneous feature that should be left up to the application. 
There are always other ways to accomplish the things that a test flag 
would be used for. Either way you slice it, is it really of sufficient 
importance to debate over? It's a single bit of information, after all.

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


-- 
// mike.joya@xmlglobal.com
// XML Global
// POC Working Group - ebXML
// Vancouver, Canada
// 604.717.1100 x230




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC