RE: Proposal for new last call issue: Some unprocessed headersshould stay

I think you may have flipped (pun intended :) my point of view. I have
on several occasions argued that we should have only one concept of
identifying a node. In the current terminology, this means that we
*only* think of identity in terms of roles:

* A node is the actual processor of SOAP messages

* A role is a URI identifying a node

This model is very similar to the relationship between a resource and a
URI in traditional Web terminology--and for a good reason! As a result
of this model, a message path only contains a set of roles that are
linked to specific nodes through late binding. In other words, this is
the Web as we know and love with respect to URIs vs. resources.

I completely agree that targeting is about establishing a contract
between the sender and a receiving role. Flipping the default has
nothing to do with the node/role model above but everything to do with
how we think of the contract. In addition, we use the mU flag to
indicate whether the contract is mandatory or optional. I think we all
agree that when combined, targeting and mU provide a very powerful
processing model.

The reason why the default is that a contract is between the sender and
the first receiver acting in the specified role is that the receiver can
not know whether the sender intended the contract automatically to be
extended to downstream nodes acting in that role. As Jean-Jacques points
out, there are scenarios where this is the case and there are scenarios
where this is not the case.

Mark Jones originally asked the question of how a sender can request the
contract to be extended to other SOAP nodes acting in the same role in
the case that the first node didn't understand the optional header
block.

This question is based on the assumption that the sender has some
knowledge of the role being targeted. At least, it has to know that the
role may be acted in by a number of SOAP nodes and not just uniquely
identify a SOAP node. That is, an implicit assumption is that roles have
properties and characteristics. This is in fact in line with the roles
we define in the spec, for example:

* "ultimateReceiver" is the last role in a message path indicating that
a node acting as the ultimateReceiver has to process the body.

* "next" always identified a node which means that contracts are always
for you.

That is: a sender needs to know something about a role in order to
target a header block at it and a receiver needs to know something about
a role in order to be able to act in it.

Given this, I think we really only have two options: the "relay" role or
an "RelayIfIgnored" attribute. I would evaluate them as follows:

1) Based on where we are at the current time, I prefer the "relay" role
as it does solve Mark's scenario. It has the smallest impact on the spec
and can be defended in the same manner that "next" can--the two are in
fact very similar.

2) After that I prefer a separate attribute as this also solves Mark's
problem. My concern is that it has a bigger impact on the spec.

Flipping the default, by itself, doesn't solve anything, and if we have
either a "relay" role or a separate attribute then it is not necessary.
I therefore see this as a dead end.

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

>Jean-Jacques, others,
>
>there are two different views of the world competing here. The 
>views concern in particular how a sender node views the 
>message path in terms of nodes and roles:
>
>1) (status quo) the message path contains some nodes and some 
>roles, and the mapping from a role to a node is unambiguous. 
>In other words, a role name identifies at most one node (from 
>the POV of the sender) and the contract is between the sender 
>and that node.
>
>2) (after proposed default flip) the message path contains 
>some roles, the contract is between the sender and the role 
>(anyone playing the role).
>
>I think Henrik assumes the first view but wants to make an 
>exception for a specific scenario.
>
>I think the specific scenario is very close to the second view 
>so I thought that view was being adopted here.

Received on Thursday, 17 October 2002 13:54:17 UTC