Issue 7 convo from Melbourne

At the F2F in Melbourne, we got into a discussion of issue 7 (processing
model for WSA SOAP headers) which resulted in some new
thoughts/questions.  I took an action to facilitate moving the
conversation forward, and as such this email will bring out some of the
points I believe we covered in the conversation there, and hopefully
encourage further discussion.

The issue involves the processing model for the WSA SOAP headers, and
there has already been a great thread about this beginning at [1].

The first part of this involves the specification of just what a node
should do when processing the WSA headers in a received message.  I
believe we should at a minimum specify (which we don't quite at present)
that processing the WSA headers has the result of filling in the
abstract message properties appropriately at the processing node.

Second, I agree with others that we should account for targeting
somehow.  It would be nice if WSA supported some kind of "target",
"node" or "role" attribe in the EPR structure which would instruct the
sender to target the WSA SOAP headers to a particular URI.  In fact we
should probably consider supporting both "role" and "node", as SOAP 1.2
does (the SOAP 1.1 binding could either ignore "node" or allow it, but
only as a default value for the "role" property).  Doug Davis brings up
this type of scenario in [2].

This clearly connects to some degree to the "Cardinality of Headers"
issue.  Personally, I'd like to consider multiple instances of WSA
headers to be allowed as long as they point at different roles.  This is
of course a little tricky to describe, in that a given node may act in
more than one role... however I think that is a general issue for WS*
specs (in that situation you also might end up with two WS-Security
headers to process, for instance) and something we can either skirt (and
just say "be careful like you would anyway") or attempt to bring to
closure.

Beyond that I'm not sure we need to constrain the SOAP headers much, but
we probably do want to note that it's up to the client/sender as to
whether or not they mark the WSA headers with MustUnderstand.

Thoughts/opinions?  Also if I missed any salient points from our
Melbourne conversation, please bring them up in here as well.

My proposal for moving forward on this would include:

1) Specify only one instance of each header per node, but multiples
targeted to different nodes/roles are OK.  Note that ordering is out of
scope, as it is for any other targeted header in other WS specs at
present.  It is assumed you either know the message path a priori at
each node, or there is some other extension which routes.

2) Specify the result of processing headers is filling in the abstract
properties.

3) Introduce "node"/"role" attributes on the EPR, and define.  Failing
to specify a value for these attributes would cause the headers to be
untargeted, and thus targeted by default at the ultimate destination,
which is I believe status quo.

4) Note that intermediaries may glance at the WSA headers that are not
targeted at them and use that information, but they SHOULD not change
the values in those headers (I'm loathe to make this a MUST because a)
there may be perfectly good reasons for doing so and b) this would be
hard to enforce).

Thanks,
--Glen

[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0047.ht
ml
[2]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0064.ht
ml

Received on Friday, 4 February 2005 12:55:50 UTC