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

RE: Must understand mustUnderstand proposal

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Fri, 4 May 2001 10:34:47 +0100
Message-ID: <5E13A1874524D411A876006008CD059F19240C@0-mail-1.hpl.hp.com>
To: "'Mark Nottingham'" <mnot@mnot.net>, Martin Gudgin <marting@develop.com>
Cc: XML Protocol Comments <xml-dist-app@w3.org>
Hi Mark,

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: 03 May 2001 20:01
> To: Martin Gudgin
> Cc: XML Protocol Comments
> 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.

In the logging case it may be that the sender of the message wants the
message logged by a 3rd for audit purposes. In such circumstances I think
that mustUnderstand is more than advisory.

> Thoughts? Can anyone think of modules that could be targetted at
> multiple devices where mustUnderstand would make sense?

A message path/routing module. Admittedly, we could discuss whether the
path/routing header is the same header with modified content or a different
header of the same 'type' at each intermediary along the path.

> -- 
> Mark Nottingham
> http://www.mnot.net/

Received on Friday, 4 May 2001 05:35:07 UTC

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