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

Re: Issue 100 (MustUnderstand fault caused by block addressed to anot her node)

From: Marc Hadley <marc.hadley@sun.com>
Date: Thu, 19 Jul 2001 10:07:49 +0100
Message-ID: <3B56A365.1A828C1E@sun.com>
To: Glen Daniels <gdaniels@macromedia.com>
CC: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Glen Daniels wrote:
> I don't believe we can or should actually prohibit producing a fault based
> on any information the paricular application decides to examine.  However, I
> think mandating a fault like this might be a bad idea, as it would enforce a
> more complex processing model for a standard SOAP engine (which would need
> to always know if it was the ultimate destination, and tweak the
> mustUnderstand processing if so).
The processor needs to know if it is the ultimate receipient anyway
since only the ultimate receipient processes the body and header blocks
targetted at the anonymous actor. Given this I don't think that the
processing model is unduly complicated by adding the requirement to
check for mU header blocks not targetted at it.

> I think the core issue that proponents of the faulting model are concerned
> about is the fact that there are sometimes blocks which a client sends that
> are highly important, which simply should not make it to the endpoint
> without being processed.

> This seems to me to be a very important issue, but
> not necessarily one which we should change the core processing model to
> handle.
> I would propose that this is perhaps more in the realm of something like
> Noah's suggested "mustHappen" extension (described in [3]), and should
> perhaps be attacked as such.  If viewed as important enough, I could see
> making this sort of thing a normative extension.
I could live with this approach and do think that it's important enough
to warrant inclusion of a normative extension in the spec.


Marc Hadley <marc.hadley@sun.com>
Tel: +44 1252 423740
Int: x23740
Received on Thursday, 19 July 2001 05:08:18 UTC

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