Re: [ws-rx] proposal to address issue 140

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Durand, Jacques R. wrote:
> +1 for InvalidAck.
> 
> The behavior on reception of such an error could be configurable based 
> on some policy (out of scope).
> 
> This error should actually cover more than just the “cumulative ack 
> invariants” (which I assume are those stated in 2.3 Protocol invariants)
> 
> “Reason” should be: violate the invariants stated in 2.3 OR  any of the 
> requirements in 3.6 about valid combinations of AckRange, Nack and None 
> in a single SequenceAcknowledgement element or w/r to already received 
> such elements.
> 

I think it makes sense to include that.

>  
> 
> For SequenceClosed:
> 
>  
> 
> Upon Receipt, the RMS should close on its side . Do NOT terminate: It 
> could be that the seq was closed by RMD but the RMS did not get the 
> notice, in which case it still wants a chance to get the final ack.
> 

Right, I agree.

>  
> 
> Jacques
> 
> ------------------------------------------------------------------------
> 
> *From:* Doug Davis [mailto:dug@us.ibm.com]
> *Sent:* Thursday, July 27, 2006 8:21 AM
> *To:* Bob Freund-Hitachi
> *Cc:* [WS-RX]
> *Subject:* Re: [ws-rx] proposal to address issue 140
> 
>  
> 
> 
> Bob,
>   for InvalidAck - should it really close the sequence?  Since Acks are 
> just informational I'm not so sure they should initiate the closing down 
> of a sequence even when they have bad data - I'd prefer to let the 
> receiver of the InvalidAck fault make that decision for itself ( see 
> 5.1.3).
>   for seqClosed - I don't think the "action upon receipt" should be to 
> terminate - I think 'close' would be more appropriate.
> 
> btw - there were changes to the expires text in the pdf - I'm assuming 
> those were left over from other other work and not related to this, right?
> 
> -Doug
> 
> 
> *"Bob Freund-Hitachi" <bob.freund@hitachisoftware.com>*
> 
> 07/27/2006 05:59 AM
> 
> 	
> 
> To
> 
> 	
> 
> "[WS-RX]" <ws-rx@lists.oasis-open.org>
> 
> cc
> 
> 	
> 
>  
> 
> Subject
> 
> 	
> 
> [ws-rx] proposal to address issue 140
> 
>  
> 
>  
> 
> 	
> 
>  
> 
> 
> 
> 
> Anish has been kind enough to prepare the attached draft proposal to 
> address issue 140.
>  
> While preparing this draft, some additional points were raised which we 
> enumerate below:
>  
> Sequence Terminated Fault:
> There is no text that details under what conditions a sequence 
> terminated fault might be raised other than mention of a vague “protocol 
> error”.
> One way to address this is to list some or all of the conditions in 
> section 4, however it is more concise to represent these in the state 
> tables of appendix D were normative.
>  
> Unsupported Selection
> This fault description deserves elucidation
>  
> Thanks
> -bob[attachment "wsrm-1.1-spec-wd-15-issue140.pdf" deleted by Doug 
> Davis/Raleigh/IBM]
>