W3C home > Mailing lists > Public > public-ws-addressing@w3.org > June 2005

AI: Faults/error conditions

From: David Hull <dmh@tibco.com>
Date: Thu, 02 Jun 2005 18:58:23 -0400
To: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
Message-id: <429F8F0F.7080906@tibco.com>
As per my AI for LC76, here is a list of the error conditions I see the
WSA core.  I'm working from the latest editor's draft which includes the
text from ~mnot/wsa (thanks again to Marc for the realtime editing!). 
Rather than give specific fault codes, which are only relevant to the
SOAP binding, I'm listing the specified requirement and the information
that needs to be reported if the requirement is violated.

As a general principle, a fault message should give /all/ know problems
with the offending message.


      Section 2:

    * 2.1: [address] is mandatory.  Report the contents of the bad EPR
      and where it was found.
    * 2.1: [address] is not an IRI. Report the offending value and where
      it was found, noting that it is not an IRI.


      Section 3:

    * 3.1 [action] is mandatory ([destination] always given a value in
      the infoset -- I'm not sure whether it can be missing or not). 
      Report that it is missing and how to supply it.
    * 3.1 [source endpoint],[reply endpoint],[fault endpoint],[message
      id] have cardinality (0 .. 1).  Report which properties have
      cardinality > 1.
    * 3.1 [destination],[source endpoint], [reply endpoint], [fault
      endpoint] not well-formed EPRs (currently this means their
      [address] is not an IRI).  Report the problem with the EPR, as
      above, including where it was found.
    * 3.1: [message id] must be unique.  Report the message id,
      including its value, and any information available about the
      previous message with the offending id. (note that this
      requirement is not quite RFC 2119 compliant, but it's clearly
      meant to be).
    * 3.1 messages using anonymous address MUST rely on out-of-band
      mechanism for delivery. Not sure what to report.
    * 3.1.1 [action], [message id] and [relationship] IRIs are
      absolute.  Report the offending IRI and where it was found.
    * 3.2 [reply endpoint] or [message id] missing in request message. 
      Report it missing, noting specifically that the message was
      interpreted as a request message.
    * 3.3 reply message MUST contain reply relation.  No fault to be
      thrown.  An endpoint that violates this is non-compliant.

Note that not all of the faults I listed in LC76 are here.  This is
because I couldn't find anything RFC 2119 compliant mandating faults for
them.  These are:

    * Unknown relationship type
    * Duplicate reply relation.
Received on Thursday, 2 June 2005 22:58:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:05 GMT