RE: PROPOSAL: enhanced Fault information - re-revised

Jonathan added one that I missed:
 
<wsa:ProblemIRI>string</wsa:ProblemIRI>
a detail element containing a string that was passed for an IRI. Note that this is a string rather than an IRI because the problem may be that it is not a valid IRI.
 
Tony

	-----Original Message----- 
	From: public-ws-addressing-request@w3.org on behalf of Rogers, Tony 
	Sent: Tue 19-Jul-05 23:56 
	To: public-ws-addressing@w3.org 
	Cc: 
	Subject: RE: PROPOSAL: enhanced Fault information - re-revised
	
	
	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>