- 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