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

Jacek,

>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.

I respectfully disagree with this interpretation. Look for example at
the description of "next" and "ultimateReceiver". The "next" role
doesn't say "anybody who can play next is it". It says the first "next"
is it. We say something similar for the ultimate receiver: it's the
first ultimate receiver, not some other ultimate receiver after that.

The notion of a contract has been in SOAP for a long time and was very
much behind the introduction of the "role" concept. If we went with the
interpretation above then I think it would not only erode the concept of
a contract but also of the mU flag: If a role is only sometimes the
first recipient, then why should it honor the mU flag if that can be
fulfilled by some other node acting in that role?

>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.

Fundamentally, what we are arguing is where to draw the line between
contracts implied by roles and how this interacts with related
parameters. We have already decided to make mU a standalone attribute,
and I think we are discussing whether making relaying another candidate.

A reason behind the "relay" role is that given that
"relayIfNotProcessed" does not imply any processing, one cannot
distinguish whether it was forwarded but ignored by one role or another:
the output is exactly the same. Similarly, I personally doubt that we
will see scenarios where two instances of the same header block will be
targeted at two different roles and both have "relayIfNotProcessed".
However, as you point out, it is possible that such scenarios will be
common.

>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.

The way I would put it that if people think that the sort of scenarios
above will be common then an attribute is the right way to go. If not
then a "relay" role can do the job. I think I have indicated that I
really don't like flipping the default ;)

Henrik

Received on Friday, 18 October 2002 13:20:05 UTC