W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2001

Re: Must understand mustUnderstand proposal

From: Martin Gudgin <marting@develop.com>
Date: Sun, 6 May 2001 22:45:04 +0100
Message-ID: <002401c0d675$d0e06b20$0300a8c0@greyarea>
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
> > ensure that; a) no header elements exist that have mustUnderstand='1'
> > should have been processed by an intermediary b) no header elements
> > that have mustUnderstand='1' that the ultimate destination does not
> > understand. If either a) or b) is not true then a fault will be
> >
> > Observations/Open Questions:
> >
> > 1.    How do we make sure that the ultimate destination has
> > process all of the mustUnderstand='1' headers targeted at it? Or do we
> > 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

> > 2.    Do we want to deal with the 'badly written' XMLP/SOAP
> > that claims to have processed a header but in fact has not? See mail
> > 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?
> > 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 ;-)

Received on Sunday, 6 May 2001 17:46:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:13 UTC