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


[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