- From: Martin Gudgin <marting@develop.com>
- Date: Sun, 6 May 2001 22:45:04 +0100
- To: "Hugo Haas" <hugo@w3.org>, "XML Protocol Comments" <xml-dist-app@w3.org>
----- Original Message ----- From: "Hugo Haas" <hugo@w3.org> To: "XML Protocol Comments" <xml-dist-app@w3.org> Sent: Thursday, May 03, 2001 11:23 AM Subject: Re: Must understand mustUnderstand proposal > * Martin Gudgin <marting@develop.com> [2001-05-03 15:49+0800] > > 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. > > > > 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? > > If the XMLP message has reached the ultimate destination, I think that > we should trust the final implementation to do the right thing. The > problem was more about blocks that were supposed to be processed by > someone before this ultimate step and this someone never was contacted. OK, so this is just a check to see if any upstream actor didn't do it's job properly. > > > 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. > > Checking that implementations behave correctly might prove to be > complex and expensive. I think that we should assume that they behave > correctly. > > > 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'. > > From the abstract model[3]: > > 5. When a block is selected for processing at an intermediary, the > block is removed from the envelope. A handler may add zero or > more blocks. Blocks which are merely referenced are not removed. > SOAP: SOAP doesn't allow body entries to be processed at > intermediaries and hence they are never removed. > > So yes, blocks are always removed. I'm going to claim lack of sleep as my reason for not remembering this ;-) Gudge
Received on Sunday, 6 May 2001 17:46:35 UTC