[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: One last change request to ebXML TRP.
Hello Bernd. Thanks for your response. It further clarifies things for me. I agree with your assessment about traceheaderlist, although I had the same concern about XMLDSIG over PKCS#7 (which is what is commonly used today). David clarified that the specification in the via overrides the specification in the header over a hop. It would be good to clarify this in the spec because I misunderstood the spec in this area. I thought the receiving intermediary has to copy fields in the via to the appropriate fields (via is understood only by the intermediary, not the MSH/transport) in the header because only the fields in the header count. I think there is definitely a use case to be able to change reliability method from ebXML to transport or vice versa at every hop without compromising the end to end reliability specification specified by the original client. We for example support multiple transports for each leg with any subset of transports supported per leg. I am sure many implementors would prefer to just reject a message requesting transport level exactly once if a hop does not support a exactly once transport. However, I dont think customers will accept this semantic, or disallowing exactly once for a non exactly once transport and they might will be forced to bite the bullet and implement ebXML exactly once algorithm over a hop despite the complexity. There is also a use case for a service/action being inserted by a intermediary router in the via. The semantic could be (It should be specified in the spec) that the via service/action take priority over the header service/action. This way, an intermediary can reroute the message to a interception service which can remove the service/action in the via and route the message to the original destination. Same approach can be used for a copy routed to a logging service. Please note that all this can be done transparently by the MSH/intremediary and this addresses my concern about the client not knowing anything at all. Thanks a lot for your insights. ragards, Jay kasi -----Original Message----- From: Eckenfels. Bernd [mailto:B.Eckenfels@seeburger.de] Sent: Friday, May 04, 2001 11:16 AM To: Kasi, Jay; 'firstname.lastname@example.org' Subject: RE: One last change request to ebXML TRP. Hello, > 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). If we look at the most widely used messaging/routing implementations (SMTP and IP) we will see, that both have a "Source Routing" or "Next Hop" Option (Unix Bang-Style or Domain Routing Addresses for SMTP and IP Source Route Option for IP) and both are rarely used and always make trouble for implementations. Therefore I agree, that the VIA Element is not an good Idea, we should depricate it's use. On the Other Hand a Trace-Header (like Received in RFC822) is a good Tool for Diagonstics. So TraceHeader should be mustUnderstand=false, but still present. It is of course not considered in the Envelop Signature. Of course this requires us XML-Level Signatures which are a major pain to impleent (opposed to simple PKCS#7 Signatures like RosettaNet is doing.) But since we already agreed in XML Sign, it is not a big issue, I think. Greetings Bernd ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: email@example.com
Powered by eList eXpress LLC