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

Henrik,

I think I now see an inkling of where you're coming from here, even if I'm 
not sure I agree...

So, two comments:

- This underpinning notion of a "contract" is not one that was apparent to 
me when I read through the SOAP messaging framework document ... that could 
be because my reading wasn't particularly thorough, but if it really is 
fundamental to the design I think it would be worth making sure that's 
adequately exposed in the specification docs.

- I'm not currently clear what the benefits are of this "contract" 
approach, though I could imagine it results in greater predictability of 
behaviour when a message passes through several SOAP processors.  I could 
see that the scenario I outlined in my message to Noah (to do with multiple 
transcoding intermediaries on a message path) might be handled with 
mustUnderstand and re-emitting the header:  maybe that's OK.

What I can't tell is if that would result in a deployed framework in which 
it is harder to deploy new features.   E.g., I could imagine a SOAP 
intermediary at an organizational boundary whose job is to check for 
threats, etc. -- if a new mustUnderstand feature is to deployed, that 
gatekeeper system must be upgraded to allow the new feature to pass, even 
if such understanding is not needed for it to fulfil its role (sic) in life.

#g
--

At 10:19 AM 10/18/02 -0700, 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

-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Monday, 21 October 2002 08:44:02 UTC