Issue 6472 Proposal - WS-Eventing EventSourceUnableToProcess: Distinguish temporary v permanent failure

Here are a couple of proposed solutions for 
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6472.

I've added the text changes that I think would be required for both 
proposals as concern was raised on the last call regarding the amount of 
change required for this issue.

thanks
Katy

Suggestion 1: Introduction of "retryAfter"
------------------------------------------

Introduce an optional retryAfter element  (in homage to ws-addressing soap 
;o) ) in the detail of EventSourceUnableToProcess and UnableToRenew. 
Absence of the retryAfter element would mean: don't bother to retry. 

This suggestion has the advantage that it reuses an existing pattern from 
another spec.  It also is more useful to the client as it gives some 
indication as to when it might be worth retrying.  This may be useful (for 
example) if an event source had too many subscribers and was therefore 
being taken off-line for a while.

Here's an example fault using this suggestion:

 <S:Fault>
   <S:Code>
     <S:Value>
        S:Sender
     </S:Value>
     <S:Subcode>
        <S:Value>wse:EventSourceUnableToProcess</S:Value>
     </S:Subcode>
   </S:Code>
   <S:Reason>
     <S:Text xml:lang="en">The event source has too many 
subscribers</S:Text>
   </S:Reason>
   <S:Detail>
     <wse:RetryAfter>1000</wse:RetryAfter>
   </S:Detail> 
 </S:Fault>


Required Changes to the specification:

1) Add to Section 5:Faults

Fault detail elements:

The following element is used to convey additional information in the 
faults.
Retry After
  The following describes the <wse:RetryAfter> element:
  /wse:RetryAfter
  This element (whose content is of type xs:unsignedLong) is a suggested 
minimum duration in milliseconds to wait before retransmitting the 
message. Omission of this element indicates that a retry is never likely 
to succeed.
  /wse:RetryAfter/@{any}
  Optional extensibility attributes that do not affect processing.

2) Add "<wsa:RetryAfter> Optional" to the [Detail] section of 5.6 
EventSourceUnableToProcess and 5.7 UnableToRenew


Suggestion 2: PermanentFailure Subsubcode
-----------------------------------------

A simpler, but less powerful solution, would be to enable an event source 
to set a subsubcode in the fault to indicate that the error was permanent. 
 Absence of this subsubcode would indicate to clients that it may be worth 
retrying the request.

Here's an example fault using this suggestion:

  <S:Fault>
   <S:Code>
     <S:Value>
        S:Sender
     </S:Value>
     <S:Subcode>
        <S:Value>wse:EventSourceUnableToProcess</S:Value>
        <S:Subcode>wse:PermanentFailure</S:Subcode>
     </S:Subcode>
   </S:Code>
   <S:Reason>
     <S:Text xml:lang="en">The endpoint is no longer acting as an event 
source</S:Text>
   </S:Reason>

  </S:Fault>

Required Changes to the specification:

1) Section 5 Faults.
In the table following "The definitions of faults use the following 
properties:"
change the text in the subcode row from 
"The fault subcode" 
to 
"The fault subcode (with optional nested subcode)".

2)Change [subcode] row of section of 5.6 EventSourceUnableToProcess and 
5.7 UnableToRenew to:

wse:EventSourceUnableToProcess
The EventSourceUnableToProcess subcode can be further narrowed in scope by 
use of an optional nested subcode <wse:PermanentFailure>. Inclusion of 
this nested subcode indicates that a retry is never likely to succeed.






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU