RE: One last change request to ebXML TRP.

["Kasi, Jay" <jay.kasi@commerceone.com>]

Hi. 

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
discussions).

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

1. Not include via in the header signature (I believe this is already being
considered). 
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. 

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


Hello. 

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

LINE RANGE: 

VIA section and traceHeaderList section. 

COMMENT: 

Eliminate or make completely optional VIA and TraceHeaderList. 

RATIONALE: 

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
senders
   or MSH should not have to know anything about the routing path. I dont
believe 
   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
envelope. 
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
is 
   incorrect in my viewpoint because the sender has a contract on the
desired
   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
incorrect. 
   If the message has to be transparently intercepted and rerouted back to
the 
   true destination, this should be done without changing the target
service/action. 
   (the intercepting service/action has to somehow figure out which
service/action 
   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
destination 
   in the envelope. 
5. The concept of an acknowledgement spec being changed by an intermediary
is 
   incorrect in my viewpoint for the same reasons as 3.
6. The concept of a sync reply being made oneway by an intermediary is
incorrect 
   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
made 
   sync) because the receiver may not be equipped to reply immediately.   

 
PROPOSAL: 

Make VIA and TraceHeaderList completely optional or elimininate it.