Re: Proposal and issues surrounding MustUnderstand faults

While this may be useful in some situations (i.e., where the fault is
being sent back in a response message), there are other message
exchange patterns where it does not make sense. We need to
diambiguate between fault mechansisms in general, and faults for RPC
in particular.

Cheers,



On Fri, May 11, 2001 at 04:48:02PM -0700, Kasi, Jay wrote:
> Hi glen. 
> 
> you said ----> 
> 
> "it would be good to bring up how Faults are generated, and look
> carefully at the current SOAP assumption that there is exactly one
> Fault per message, with a single <faultcode>."
> 
> This brings up the issue I posted earlier about the sender playing
> russian roulette where he learns about faults generated by a single
> intermediary or endpoint one at a time and has to keep resending
> until it succeeds. This can easily happen because mustunderstand
> faults are due to version or capability incompatibility and the
> sender never really knows or needs to know the version of the
> intermediaries and endpoints.  This is not a reasonable way to
> communicate.
> 
> It would also be nice if we could consider a way for the endpoint
> to generate all the mustunderstand faults even if an actor in the
> middle did not understand a block he was supposed to consume. It
> might be useful to let this block pass through unprocessed and let
> the endpoint generate a complete fault set. This again avoids the
> russian roulette problem in the presence of distributed actors who
> are supposed to consume them. Again I am planting a seed of an idea
> for consideration.
> 
> regards
> jay kasi
> 
> -----Original Message-----
> From: Glen Daniels [mailto:gdaniels@macromedia.com]
> Sent: Friday, May 11, 2001 4:24 PM
> To: xml-dist-app@w3.org
> Subject: Proposal and issues surrounding MustUnderstand faults
> 
> 
> Hi folks!
> 
> On this week's conference call, I volunteered to take a crack at a proposal
> for dealing with the difficulty of getting back useful information regarding
> which headers in particular were the cause of a MustUnderstand fault.
> 
> This message proposes two possible solutions for the problem, and suggests a
> bit more exploration into the issue of faults in general.
> 
> As background/context, you can read the description of the issue at [1].
> 
> ** PROPOSAL 1 : Use the <Fault> element
> 
> This proposal involves EITHER extending the Fault element with another
> sibling to <faultcode>,<faultactor>,etc. :
> 
> <faultcode>MustUnderstand</faultcode>
> <faultheaders>
>  <myNS:Header1 xmlns:myNS="http://some.com"/>
> </faultheaders>
> 
> OR changing the rules of section 4.4 to allow the <detail> element to carry
> information relating to headers, and adding the same <faultheaders> element
> underneath <detail>.
> 
> ** PROPOSAL 2 : Use the header
> 
> A similar proposal involves echoing back the offending headers in the
> <SOAP-ENV:Header> section of the fault response:
> 
> <Envelope>
>  <Header>
>   <SOAP-EXT:MisunderstoodHeaders>
>    <myNS:Header1 xmlns:myNS="http://some.com" mustUnderstand="1">
>      Nobody understands me.
>    </myNS:Header1>
>   </SOAP-EXT:MisunderstoodHeaders>
>  </Header>
>  <Body>
>   <Fault>
>    <faultcode>MustUnderstand</faultcode>
>   </Fault>
>  </Body>
> </Envelope>
> 
> The second one more cleanly fits the SOAP extensibility model, I think.
> This
> is potentially one of the "normative extensions" we could add to the spec,
> since while not absolutely essential, it would be very handy if most
> processors
> out there implemented this.
> 
> On a slightly broader note, I think in parallel with our discussion of the
> potential symmetry and/or differences between headers and bodies, it would
> be
> good to bring up how Faults are generated, and look carefully at the current
> SOAP assumption that there is exactly one Fault per message, with a single
> <faultcode>.  While convenient in some ways from a processing point of view,
> this does generate a contended resource - and there may be ways in which
> fault
> information can be orthogonally added to a message in the same way extension
> data will be.  I don't want to go into this too deeply in this note, but did
> want to sprout the seed of this discussion, which came up on the call.
> 
> --Glen
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Apr/0097.html
> 

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

Received on Friday, 11 May 2001 23:32:47 UTC