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

Henrik, 8-)

In the text below you are first saying that you agree "targeting is
about establishing a contract between the sender and a receiving role"
and then that "the default is that a contract is between the sender and
the first receiver acting in the specified role".

I think the first statement can be interpreted differently from the way
the second statement interprets it. The flipped default would change
that interpretation.

(For those in a hurry - the last 2 paragraphs contain my position.)

Anyway, by introducing a single special role for relaying, you're saying
that a single application will never have two conflicting sets of
headers that should be relayed if not processed.

This can be possible if we assume there will always be only one header
(or a set of related headers that would normally be targeted at the same
role) that need to be relayed. I doubt this is going to be the case if
intermediaries are ever widely used.

Alternatively, it can be possible if we assume that nodes that don't act
as caching managers also don't understand caching managers' headers. But
in this case the whole idea of targeting is unnecessary because you just
stick headers in there and assume the appropriate nodes will understand
the appropriate headers. Again, I doubt this is workable.

So my position is that you can't just have one special role that has
relaying semantics because in more complex scenarios multiple different
roles with this semantics would be necessary.

In other words, if you can't agree to just flip the default (which
changes the contract for everybody to something I view as more
realistic) then an additional attribute is the only way to go if we want
to add the possibility of relaying unprocessed headers into SOAP 1.2.

Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



On Thu, 2002-10-17 at 19:53, Henrik Frystyk Nielsen wrote:
> 
> 
> 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 Friday, 18 October 2002 04:37:23 UTC