RE: Must understand mustUnderstand proposal

Hi Martin,

Great start...

> -----Original Message-----
> From: Martin Gudgin [mailto:marting@develop.com]
> Sent: 03 May 2001 08:49
> To: XML Protocol Comments
> Subject: Must understand mustUnderstand proposal
> 
> 
> On the XML Protocol telcon today I volunteered to start discussion of an
> extension Module for XMLP/SOAP. This mail serves as a kick off for
> discussion of that extension.
> 
> The problem: How to make sure that all headers in a message with
> mustUnderstand='1', targeted at any intermediary or the 
> ultimate destination have actually been processed.
> 
> Suggestion: Define an XMLP Module ( essentially an extension 
> header, as defined in the XMLP Requirements document[1] ) that is 
> processed by the ultimate destination whose semantics are; examine the 
> XMLP/SOAP message and ensure that; a) no header elements exist that have 
> mustUnderstand='1' *and* should have been processed by an intermediary b)
no header 
> elements exist  that have mustUnderstand='1' that the ultimate destination
does not
> understand. If either a) or b) is not true then a fault will be generated.

I hadn't quite taken the suggestion as being about XMLP blocks targetted at
at processed solely by the ultimate destination. It would certainly be
really interesting if you could perform the test that way, as it would not
then require (all?) XMLP Intermediaries with actors that act on the message
to understand these blocks.

[Having now been through your list of questions - I've come to the
conclusion that in SOAP there is a test that can be performed at the
ultimate destination to determined whether a message has been properly
processed by all relevant actors... although this does assume that
mustUnderstand also implies mustHappen. The question is more complex if
mustUnderstand and mustHappen are orthogonal].

> Observations/Open Questions:
> 
> 1.    How do we make sure that the ultimate destination has processed/can
> process all of the mustUnderstand='1' headers targeted at it? Or do we
even
> need to bother? Will knowing that intermediaries have processed their
> headers, because there are no headers left in the message that are not
> targeted at the ultimate destination, be enough?

Seems plausible... is there a scenario with correct behaviour where a SOAP
message has: 

a) visited all the actors required to process the blocks en-route (and the
actors that arise en-route, if any, due to the processing of blocks) and 

b) arrives at the ultimate destination with carrying blocks targetted actor
other than the ultimate destination? 

I can't think of one - but that could well be limited imagination!

> 2.    Do we want to deal with the 'badly written' XMLP/SOAP 
> implementations that claims to have processed a header but in fact has
not? 
> See mail from Frank DeRose[2] for more detail on this question.

Franks note is interesting... I think here we are working at the enveloping
level and not at the detailed level of the semantics of blocks tagged with
mustUnderstand. I think, as Frank suggests, that the removal of targetted
blocks by actors at intermediaries only establishes the 'claim' that that
intermediary understands the block. The truth/validity of that claim is
unproven - even response tokens from intermediaries to originators of
targetted blocks doesn't solve the problem - if we're being really paranoid
it could be a 'two-faced' intermediary . If the originator is truely
suspicious that the actions it requires of an intermediary are not being
carried our properly, it needs in some way (out-of-band probably) to gather
evidence of the material effects of those actions - for example who doesn't
check their bank statements? Even end-to-end, I have to either trust that
the recipient will indeed to the right thing based on the message it's been
sent - or my application design has to include safeguards that enable to
determine that it hasn't.

Malicious code and 'broken' code clearly have differing intents... if our
applications are vulnerable to malicious code then I think at least some of
the safeguards have to be built into the application semantics. Broken
code... just needs to get fixed!

So... at least as an advisory that the 'channel' 'claims' a message has been
properly processed en-route mustUnderstand has some utility against
mis-configuration/deployment errors. Against malicious behaviour it has
little to offer (I think).

> 3.    Does an intermediary *always* remove the headers targeted at it? 
> If not then I think we need some way of annotating them as 'processed'.

At least for SOAP the answer seems to be yes - from [3]:

"...That is, a recipient receiving a header element MUST NOT forward 
that header element to the next application in the SOAP message path."

It does go on to say in the next sentence:

"The recipient MAY insert a similar header element but in that case, the 
contract is between that application and the recipient of that header
element."

Which I take to mean that as well as deleting the processed header/block it
may also
insert further headers/blocks which may indeed be similar to the processed
block - and
could be an annotated variant of it.

It is interesting to ask what might happen in the case where the targetted
block is
also referenced from elsewhere in the message. Do those links break on
deletion?
Do they get reasserted on 'substitution'? 

> 4.    What do we do about ordering? This is an issue particularly at the
> ultimate destination. What if this header is encountered before other
> headers marked mustUnderstand='1'? What if it is encountered after?

Lexical ordering of blocks within the message? Evaluation order of the
processing of multiple blocks at the ultimate recipient?

> 5.    This header needs to be marked mustUnderstand='1' :-)

Would seem to be the case!

> 6.    This extension must be able to work by examining *only* 
> the message that arrives at the ultimate recipient.

I think that's an interesting challenge and as such keeps this orthogonal to
message path issues (maybe). It seems to be... devise a test to determine
that all the blocks that should have been processed before the messsage
arrive have indeed been processes. It's kind of a binary answer, although
any blocks that gave rise to the failure are identifiable and could be
quoted in a diagnostic and/or fault message.

> 7.    Is processing this at the ultimate destination enough? 
> Or do we need to have evaluate this at every intermediary? <gulp>

Again feels plausible... indeed it may be the case that a final destination
message validity test exists without the definition of a module - ie. no new
syntax... just a more explicit statement about the properties of a message
that has been properly processed by all relevant intermediaries/actors - ie.
it should contain no headers targetted elsewhere.

> I think that'll do as a start point. Please chime in with 
> your thoughts and suggestions about the open questions and the semantics
and 
> we'll see how things progress. I'd like to be able to come up with a 
> proposal by close of play Monday if possible.

Thats end of Monday UK (BST) right? :-)

> 
> Cheers
> 
> Martin Gudgin
> DevelopMentor

Regards

Stuart
> 
> [1] http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#g350
> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0020.html
> 
[3] http://www.w3.org/TR/SOAP/#_Toc478383499

Received on Thursday, 3 May 2001 06:53:46 UTC