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: One last change request to ebXML TRP.


David Burdett educated me on ebXML's thinking on via and traceheader. It
does make 
sense now that I fully understand it (I was not privy to any of the ebXML

So my request/questions really boils down to the following: 

1. Not include via in the header signature (I believe this is already being
2. If via and traceheader is truely optional, should mustUndetstand be
specifyable with these two? 
3. Does syncreply belong in via or indicated some other way? Afterall a
reply is a syncreply 
   no matter how many hops are involved. Why should an intermediary be able
to change it? 

Thanks for a well thought spec. 

jay kasi 

-----Original Message-----
From: Kasi, Jay 
Sent: Thursday, May 03, 2001 6:23 PM
To: 'ebxml-transport@lists.ebxml.org'
Subject: One last change request to ebXML TRP. 


The public review period ends tomorrow, so I am hurrying to mail 
this last change request. 


VIA section and traceHeaderList section. 


Eliminate or make completely optional VIA and TraceHeaderList. 


There are many reasons why I feel this way. 

1. Routers should not be an intermediary because the routing path could be 
   very complex (for example commerceone global trading web) and message
   or MSH should not have to know anything about the routing path. I dont
   the CPP/CPA provides a way to discover a complex routing path. Again I
dont think
   gateways, etc should be intermediaries because they should be
transparently invoked. 
   I think ebXML should focus on endpoint to endpoint information in the
2. In the future (or now?) the header might be signed for integrity. The
concept of 
   modifying the header by intermediaries is not a good idea.  
3. The concept of reliability specification being changed by an intermediary
   incorrect in my viewpoint because the sender has a contract on the
   behavior he expects END to END, and no intermediary should be able to
change it. 
   It is the routers and transports job to enforce this contract doing
whatever it 
   takes to do so (or give an error). 
4. The concept of a service/action being changed by an intermediary is
   If the message has to be transparently intercepted and rerouted back to
   true destination, this should be done without changing the target
   (the intercepting service/action has to somehow figure out which
   to route to after the intermediate processing). If a copy of the message
has to 
   be routed to a logging service, again the service needs to know the true
   in the envelope. 
5. The concept of an acknowledgement spec being changed by an intermediary
   incorrect in my viewpoint for the same reasons as 3.
6. The concept of a sync reply being made oneway by an intermediary is
   because the sender has a blocked thread waiting for the response. I
believe it 
   is always possible to map a sync request to async transports if necessary
in a 
   multihop scenerio. The reverse is also incorrect (oneway request being
   sync) because the receiver may not be equipped to reply immediately.   


Make VIA and TraceHeaderList completely optional or elimininate it.  

[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