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

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.
>
Exactly.

> 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.

Regards,
Marc.

--
Marc Hadley <marc.hadley@sun.com>
Tel: +44 1252 423740
Int: x23740

Received on Thursday, 19 July 2001 05:08:18 UTC