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

RE: PROPOSAL: enhanced Fault information - re-revised

From: Rogers, Tony <Tony.Rogers@ca.com>
Date: Tue, 19 Jul 2005 23:56:04 +1000
Message-ID: <7997F38251504E43B38435DAF917887F40C5F7@ausyms23.ca.com>
To: <public-ws-addressing@w3.org>
Leaving all the subsubcodes as-is (possibly only removing the MalformedAddress code), but wrapping them as recursive subcodes (rather than inventing a subsubcode element).
 
New set of detail elements - note that ALL details are replaced with these detail elements.
 
<wsa:ProblemHeaderQName>QName</wsa:ProblemHeaderQName>
this detail element will be the first detail element if present. It replaces wsa:InvalidAddressingHeader in 5.3, wsa:MissingAddressingHeaderRequired in 5.4, provides the name of the EPR that cannot be reached in 5.5 or is unavailable in 5.7.
 
<wsa:ProblemEPRContent>any</wsa:ProblemEPRContent>
this detail element will hold the entire EPR that is problematic. It is used in 5.5 and 5.7, and in 5.3.2, 5.3.4 and 5.3.5 (Missing or Malformed Address in EPR).
 
<wsa:ProblemCardinality role="anyURI">int</wsa:ProblemCardinality>
this detail element (which may be repeated for each role the endpoint is playing) specifies the cardinality that is present in the addressing header - the expected cardinality is implicit in the specification of the standard. Will be used in 5.3.3 and possibly 5.4
 
<wsa:messageID>
this detail element will be exactly as it is in the header - no change, no wrapper
 
 
 
Are there any other ProblemX detail elements we require?

	-----Original Message----- 
	From: public-ws-addressing-request@w3.org on behalf of Rogers, Tony 
	Sent: Tue 19-Jul-05 23:00 
	To: public-ws-addressing@w3.org 
	Cc: 
	Subject: PROPOSAL: enhanced Fault information
	
	
	Here is what I compiled from David's proposals, and Marc's outline. It could be tidied up (editorial discretion), but the fundamentals seem sound.
	 
	(Please excuse the disturbed formatting - for some reason my webmail client decided everything was double-spaced.)
	 

	(revised) General layout of the fault:

	<Fault>

	                <Code><Value>sender</Value>

	                                <Subcode><Value>wsa:InvalidAddressingHeader</Value>

	                                                <Subsubcode><Value>wsa:InvalidAddress</Value></Subsubcode>

	                                </Subcode>

	                </Code>

	                <Detail>

	                                <wsa:InvalidAddressingHeader>wsa:FaultTo</wsa:InvalidAddressingHeader>

	                                <wsa:MalformedAddress>http:/foo</wsa:MalformedAddress>

	                </Detail>

	</Fault>

	 

	Additional text in Section 5 as follows – all are new subsections under existing sections. Note that the [Detail] in the subsections is appended to any [Detail] in the parent section.

	 

	Under 5.3 Invalid Addressing Header

	 

	5.3.1 Invalid Address

	The invalid header contains an invalid address – additional detail specifies the invalid address

	[Subsubcode] wsa:InvalidAddress

	[Detail] a <wsa:MalformedAddress> element giving the content of the faulty address

	                <wsa:MalformedAddress>any<wsa:MalformedAddress>

	 

	5.3.2 Invalid EPR

	The invalid header contains an invalid EPR – additional (optional) detail specifies the invalid EPR

	[Subsubcode] wsa:InvalidEPR

	[Detail] a <wsa:InvalidEPR> element containing the invalid EPR. Note that the content is any because it may be structured

	                <wsa:InvalidEPR>any</wsa:InvalidEPR>

	 

	5.3.3 Invalid Cardinality

	The invalid header has an inappropriate cardinality – additional detail specifies the actual cardinality by role.

	[Subsubcode] wsa:InvalidCardinality

	[Detail] a <wsa:InvalidCardinality> element containing a list of <wsa:ActualCardinality/> elements

	                <wsa:ActualCardinality role=”anyURI”>int</wsa:ActualCardinality>

	 

	5.3.4 Missing Address in EPR

	The invalid header contains an EPR which is missing an address – additional detail specifies which address in the EPR is missing

	[Subsubcode] wsa:MissingAddressInEPR

	[Detail] a <wsa:MissingAddress> containing the name of the missing address (such as “wsa:FaultTo”)

	                <wsa:MissingAddress address=”wsa:FaultTo”/>

	 

	5.3.5 Malformed Address in EPR

	The invalid header contains an EPR which is missing an address – additional detail specifies which address in the EPR is malformed

	[Subsubcode] wsa:MalformedAddressInEPR

	[Detail] a <wsa:MalformedAddress> containing the name of the missing address (such as “wsa:FaultTo”) and (optionally) the content of the malformed address

	                <wsa:MalformedAddress address=”wsa:FaultTo”>anyURI</wsa:MalformedAddress>

	 

	5.3.6 Duplicate Message ID

	The invalid header contains a message ID which has already been used – additional detail specifies the message id in question

	[Subsubcode] wsa:DuplicateMessageID

	[Detail] a <wsa:DuplicateMessageID> containing the message id in question

	                <wsa:DuplicateMessageID><messageID>anyURI</messageID></wsa:DuplicateMessageID>

	 

	 

	 

	Under 5.4 Message Addressing Header Required

	 

	5.4.1 Invalid Cardinality

	The required message header which is missing has inappropriate cardinality – additional detail specifies the actual cardinality, by role, of this header

	[Subsubcode] wsa:InvalidCardinality

	[Detail] a <wsa:InvalidCardinality> element containing a list of <wsa:ActualCardinality/> elements

	                <wsa:ActualCardinality role=”anyURI”>int</wsa:ActualCardinality>

	 

	 

	Under 5.5 Destination Unreachable

	 

	5.5.1 Unreachable EPR

	 

	[Subsubcode] none

	[Detail] a <wsa:ProblemEPR> element containing the name of the offending EPR, and (optionally) its content

	                <wsa:ProblemEPR epr=”wsa:ReplyTo”>any</wsa:ProblemEPR>

	 

	 

	Under 5.6 Action Not Supported – nothing – no changes required

	 

	 

	Under 5.7 Endpoint Unavailable

	 

	5.7.1 Unavailable EPR

	 

	[Subsubcode] none

	[Detail] a <wsa:ProblemEPR> element containing the name of the offending EPR, and (optionally) its content

	                <wsa:ProblemEPR epr=”wsa:ReplyTo”>any</wsa:ProblemEPR>

	 
Received on Tuesday, 19 July 2005 13:56:15 GMT

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