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:41:22 +0100
Message-ID: <001001c0d675$4c2c4020$0300a8c0@greyarea>
To: "Mark Nottingham" <mnot@mnot.net>
Cc: "XML Protocol Comments" <xml-dist-app@w3.org>

----- Original Message -----
From: "Mark Nottingham" <mnot@mnot.net>
To: "Martin Gudgin" <marting@develop.com>
Cc: "XML Protocol Comments" <xml-dist-app@w3.org>
Sent: Thursday, May 03, 2001 8:01 PM
Subject: Re: Must understand mustUnderstand proposal


> On Thu, May 03, 2001 at 03:49:21PM +0800, Martin Gudgin wrote:
> > 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'.
>
> While SOAP assumes this, I'd note that there is very little
> implementation of SOAP headers and intermediaries out there, and
> arguably they comprise the most underspecified part of it.
>
> It seems like there are several headers which may be processed (ah,
> that word again) by several intermediaries; for example, caching,
> logging, etc.
>
> Then again, does mustUnderstand really make sense in that context?
> These sorts of services are really advisory hints about what can be
> done, not instructions about what must be done to provide the
> service, so maybe the semantic of mustUnderstand *is* mustConsume in
> this context.
>
> Thoughts? Can anyone think of modules that could be targetted at
> multiple devices where mustUnderstand would make sense?

I initially though that reliable messaging might be such a module but in
reality I think that would be implemented by having each node in the chain
put in a 'ReliableMessage' block targetted at the next actor in the chain. I
guess this really brings us to thinking about the idea that the semantics of
a given module may have impact on downstream actors.

Gudge
Received on Sunday, 6 May 2001 17:42:53 GMT

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