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

Henrik,

I see why you don't want to change the default (it being that way since
SOAP 1.1 at least) and I agree it would be a bigger change than
necessary and that some (AFAIK theoretical) scenarios would become
impossible.

What do you think about making the "relay" role more similar to "next"
by making it mandatory on all nodes? Do you have a scenario which would
be adversely affected by this change in the proposal? 

You see, with this change we would make it clear that we expect that
only one such role is necessary. Without it, while the expectation is
still there, it's not spelled out clearly and confusion could arise.

Best regards,

                   Jacek Kopecky

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



On Fri, 2002-10-18 at 19:19, Henrik Frystyk Nielsen wrote:
> 
> 
> 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 Monday, 21 October 2002 04:11:43 UTC