RE: Issue 7 convo from Melbourne

I don't think I have any problems with your proposal, other than this:

  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.

I don't have a problem with WS-A headers being targeted to
intermediaries - that seems like it might be useful at some point.  But
I am very wary of introducing the concept of a "targeted EPR" by adding
in attributes targeting its use toward a particular intermediary.  The
obvious scenario for such a beast is to provide information needed by an
EPR consumer to construct a message that targets both the ultimate
receiver and N intermediaries.  To really make this work I think you'd
need a much more complex structure than we currently have (such as a
bucket of EPRs).  I don't see that adding a couple of attributes is
going to appreciably solve the scenario.  The whole scenario falls way
under the 20% case, and can be solved by extending or packaging WS-A
once the real interop scenarios are clear.

So, I support dropping item 3 of your proposal.

> -----Original Message-----
> From: public-ws-addressing-request@w3.org [mailto:public-ws-
> addressing-request@w3.org] On Behalf Of Glen Daniels
> Sent: Friday, February 04, 2005 4:56 AM
> To: public-ws-addressing@w3.org
> Subject: 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 Monday, 21 February 2005 22:30:42 UTC