Re: Proposal: Module for checking mustUnderstand headers have been processed

Martin,
  How do you see the "actor" attribute playing into this?  What does it
mean for this new header to be targeted at something other than the
ultimate destination?  I guess it only really becomes a problem when
that actor is actually hit. 8-)  I guess it should fault.....?
-Dug


"Martin Gudgin" <marting@develop.com>@w3.org on 05/07/2001 02:28:16 PM

Sent by:  xml-dist-app-request@w3.org


To:   "XML Protocol Comments" <xml-dist-app@w3.org>
cc:
Subject:  Proposal: Module for checking mustUnderstand headers have been
      processed



As promised here is a proposal for an XMLP Module that ensures that if any
XMLP Blocks marked mustUnderstand='1' targetted at actors other than the
ultimate recipient are present in the message when it arrives at the
ultimate recipient then a fault will be generated.

Begin XMLP Module Definition

Block: The block is a single element with a local name of
CheckMustUnderstand and a namespace name of http://www.w3.org/XMLP/Modules.
This element MUST be annotated with a mustUnderstand attribute in the
http://schemas.xmlsoap.org/soap/envelope/ namespace with a value of '1'.

Handler: On seeing the Block element the handler will inspect the XMLP
message for Blocks targeted at actors other than the ultimate recipient. If
any such Blocks exist and one or more of them is annotated with a
mustUnderstand attribute in the http://schemas.xmlsoap.org/soap/envelope/
namespace with a value of '1' then the Handler MUST generate a fault. The
fault MUST have a faultcode element with a value of
x:Server.MandatoryBlockNotProcessed where x maps to the namespace name
http://www.w3.org/XMLP/Modules.
The Handler MAY place information about the namespace name and local name
of
the block or blocks that caused the fault to be generated into the detail
element of the fault.

End XMLP Module Definition


Observations:

1.    The namespace name and local name of the Block element are of course
open to discussion, think of them as placeholders for now.

2.    The same applies to the faultcode

3.    Do we want to specify the faultcode that should be returned?

4.    Do we want to define what goes in the detail of the fault?

5.    Have I missed any edge/corner cases in my description of the Handler?

Comments, flames etc. to the usual address. Hopefully we can usefully
discuss this on this weeks concall.

Martin Gudgin
DevelopMentor

Received on Thursday, 10 May 2001 15:19:42 UTC