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

Re: Must understand mustUnderstand proposal

From: Marc J. Hadley <marc.hadley@sun.com>
Date: Thu, 03 May 2001 11:27:50 +0100
Message-ID: <3AF132A6.5AF579BB@sun.com>
To: XML Protocol Comments <xml-dist-app@w3.org>
Martin Gudgin wrote:
> 
> 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?
> 
Presumably the ultimate destination itself will generate a fault if it
sees a mustUnderstand header targeted at itself that it doesn't
understand. So I don't think the module needs to worry about headers
targeted at the ultimate destination, it can take care of itself.

> 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'.
> 
The SOAP 1.1 spec says: "If the SOAP application is not the ultimate
destination of the message then remove all parts identified in step 1
before forwarding the message." where step 1 is to identify all parts of
the SOAP message intended for the application with reference to the SOAP
actor attribute. Its not clear though whether this applies only at
intermediaries or to handlers collocated with the ultimate destination.

> 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?
> 
A good point, this header would have to be processed last, but see my
comment above: do collocated handlers have to remove their headers
during message processing at the final recipient ?

Regards,
Marc.

--
Marc Hadley <marc.hadley@sun.com>
Tel: +44 1252 423740
Int: x23740
Received on Thursday, 3 May 2001 06:28:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:01 GMT