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

Re: mustUnderstand on client side

From: Mark Nottingham <mnot@akamai.com>
Date: Mon, 23 Apr 2001 12:55:10 -0700
To: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Cc: soapbuilders@yahoogroups.com, xml-dist-app@w3.org
Message-ID: <20010423125508.D24820@akamai.com>

Just thinking out loud...

There seem to be a number of conflicting interests re: what do to
with a fault. It seems *most* tied to an application's message
exchange pattern (i.e., request/response will probably send a fault
back in the response, one way will probably propogate the fault to
the destination if possible, etc.). I can imagine that default fault
handling behaviours might be defined for each, and a module can be
built that will explicitly tell processors what do do with faults in
the exception cases.

On Sun, Apr 22, 2001 at 07:11:57PM -0700, Henrik Frystyk Nielsen wrote:
> The basic SOAP processing model described in [1] doesn't know about
> servers or clients but only "SOAP processors" which is the reason why
> SOAP in general walks a fine line when talking about *generating* a
> fault vs. *sending* a fault. The latter is only mentioned in the HTTP
> binding and the RPC convention as these two talk about "requests" and
> "responses". That is, SOAP distinguishes between generating a fault and
> sending a fault message somewhere.
> Within the context of a request/response model, I think the right thing
> for an HTTP client that cannot accept/obey the SOAP message semantics is
> to fault the processing or to suggest that the message is saved for
> later processing by a more savvy processor. The latter is similar to
> what clients do when receiving a response with an unknown media type.
> It is important that a SOAP processor doesn't break the processing model
> and merely ignores the SOAP rules just because it may not be in a
> position where it can notify the sender about the fault.
> Henrik
> [1] http://www.w3.org/TR/SOAP/#_Toc478383491
> Doug Davis wrote:
> >
> >I see 3 choices:
> >  1 - ignore it
> >  2 - fault back to the server
> >  3 - fault back to the client
> >
> >While 2 is probably what "should" happen, I doubt many
> >will be able to support this.  1 seems most likely, but
> >scares me.  3 seems like a nice middle of the road solution.
> >8-)
> >
> >Paul Kulchenko wrote:
> >
> >Since it's possible to return Header from server to client 
> >also, what should client do if this header has mustUnderstand 
> >attribute or wrong actor?

Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)
Received on Monday, 23 April 2001 15:55:50 UTC

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