MHonArc v2.5.0b2 -->
ebxml-msg message
[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]