[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Another header v 3.0 option (ws-addressing) withdiscussion and a question.
Doug possibly wrote: "Duplication or overlap of headers in a specific SOAP message certainly leaves that message open to conflicts and ambiguity." <Dale> I think this header interaction effect is something the SOAP world has not really noodled through thoroughly IMO. Modularity is not necessarily attained by having distinct header blocks. Possibly the SOAP module idea could be embellished so that header block interaction is controlled, but I think most of the work is left to the reader. For example, mixing intermediary wsse security headers with originator headers can, when both encryption and signatures are involved, lead to unsuccessful security implementation because SOAP header processing has no agreed upon way to introduce order for header processing when it is needed (and multiple wsse headers can very much need to be processed in the "right" order. The current example involving possible interaction of a v 3.0 ebXML header with a ws-addressing header (or ws-routing headers for that matter), are another instance of potential header interaction. Suppose header processing supported two distinct "routing" decisions? Should both be done (maybe making copies of the message with routing info separated?), should one take precedence, should they fault when both are marked true for mustUnderstand? (It is not that the headers are not understood, it is just that which processing fork to take (or both) is indeterminate/underspecified.) So would we (ebXML) have to issue warnings about non-standard standards like ws-addressing or ws-routing when an attempt is made to use them with ebXML v 3.0 headers? Where will that responsibility terminate? Or do we issue a disclaimer saying that if you mix ebXML headers with stuff not on an approved list, results are unpredictable? </Dale> Doug continues: "For example, would the CPA governing the relation between the two endpoints (not the intermediaries) need to describe whether the ebXML Messaging headers have precedence over other information also available in the messages exchanged? Which is the normative message identifier, the one from WS-Reliability or something else?" <Dale> I would hope that this kind of complexity could be avoided in the CPPA and handled in some kind of header block compatibility chart (in so far as it is known) within the Messaging specification.When CPPA adds the SecurityPolicy element for 2.1 CPPA or perhaps 3.0 CPPA, they may include elements from the XACML namespace (WSPL?) and because those policy nuggets could be extended beyond simple access control policies to SOAP processing policies, I guess they could begin to express agreements on those topics, using the syntax and container apparatus of whatever gets standardized in the policy area. But because thestandardization of policy syntax is still a ways off. XACML is the only one approved anywhere so far. Incidentally, XACML is used in recent versions of ebXML Registry or so I have heard from Farrukh. </Dale> Doug continues: "I am generally not sure where you are heading with this message because our specification should remain "composable" with any other headers a sender chooses to include, modulo the possible conflicts that arise. Such inclusion is not something we can control though we may mention a few examples of useful compositions. <Dale> I think I am mainly raising a concern about the possibility of conflicts, especially over things like routing in this message. I am not certain whether any specifications can control end user behavior :-), but we can warn that we do not support mixing certain header blocks (because of undefined outcomes for processing at SOAP or ebXML levels). </Dale> Doug concludes: "With respect to our document, I would strongly recommend we avoid reference to work not yet available as a standard." For normative reference, +1. Eliminating any reference, especially a warning not to use, I am leaning 0 to -1. "Reliance on open standards has been a strong attribute of the ebXML work to date and is not something we should change going forward." Yep.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]