[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: One last change request to ebXML TRP.
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: 'firstname.lastname@example.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.
Powered by eList eXpress LLC