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