RE: [ws-rx] i019 - Proposal #5

[Doug Davis <dug@us.ibm.com>]

Jacques,
  I'm ok either way with this.
 I've added it to the list of editorial tweaks that should be made,
since I'm avoiding sending out yet another draft  :-)
thanks,
-Doug


Jacques Durand <JDurand@us.fujitsu.com> wrote
on 09/08/2005 01:42:55 PM:

> That would work, if the definition of Receive were not so narrow:
> Receive: The act of reading a message from a
network connection.
> I assume you can't just decide to stop reading
a network connection. How about:
> Receive: The act of reading a message from a
network connection and qualifying it 
> as relevant to RMD functions.
> (which is always what needs to be done before
acknowledging: "successful reception"
> only concerns well formed messages of which you have parsed the header
 so that you
> know which sequence they belong to)
> Would that be better?
>  
> Jacques
> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Thursday, September 08, 2005 6:20 AM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] i019 - Proposal #5
>  
> 
> Jacque, 
>   You're correct that using additional terms might lead to confusion
- and I need 
> to me more careful about that.  What if I simply used the term
"receive" instead, 
> and tried to avoid using the term "application message"?
 So, for the example you 
> sited it would be:  ...to the RM Destination to indicate that
the RM Destination 
> MUST NOT receive any new messages for the specified sequence. 
> 
> thanks 
> -Doug 
> 

> 
> Jacques Durand <JDurand@us.fujitsu.com> 
> 09/06/2005 09:24 PM 
> 
> To
> 
> Doug Davis/Raleigh/IBM@IBMUS, ws-rx@lists.oasis-open.org 
> 
> cc
> 
>  
> 
> Subject
> 
> RE: [ws-rx] i019 - Proposal #5
> 
>  
> 
>  
> 
>  
> 
> 
> 
> 
> Doug: 
>   
> Rereading your proposal end-to-end,  a couple of lingering concerns
on the terminology side:
>   
> 1. The proposal uses at quite a few places the term "accept"
: e.g. "  ... to the 
> RM Destination to indicate that     
>  RM Destination MUST NOT accept any new application messages."
The reliance on an 
> intuitive meaning of what "accept "means could lead to some
misinterpretation: we 
> all understand that a message could be "Received"  yet
not "Accepted" . Although it
> is implied that a non-accepted message shall not be acknowledged,
that is not very 
> clear, as the specification only associates Ack semantics with "successful
message 
> reception" .  One way to clarify this  is to add in
the Glossary: " message 
> acceptance: commitment to process the message further beyond reception,
including 
> acknowledging it." Also, in Section 3.2 beginning: "...The
RM Destination informs 
> the RM Source of successful message receipt using a 
> <SequenceAcknowledgement> header block."  Shouldn't
 we add "and acceptance" after "receipt".
>   
> 2. I thought we had defined this before: "application message:
a message containing
> a wsrm:Sequence header". (also candidate for the Glossary). 
>   
> I'd vote for the proposal even without these precisions, but then
would have to 
> file additional editorial issues here... 
>   
> Jacques 
>   
>  
> 
> 
> From: Doug Davis [mailto:dug@us.ibm.com] 
> Sent: Monday, September 05, 2005 5:05 PM
> To: ws-rx@lists.oasis-open.org
> Subject: [ws-rx] i019 - Proposal #5 
>   
> 
> DougB proposed some good editoral fixes.  Picked up the change
about when Close 
> should be used, removed the bit about InOrder+ExactlyOne DA, and the
typo he noticed. 
> thanks 
> -DougD 
> 
> __________________   
> 
> 
> 
> Using the pdf file at http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.
> php/13493/WS-ReliableMessaging-v1.0-wd-01.pdf   
> here's the proposal:     
> 
> Change lines 340-347, the SeqAck syntax, to:   
> <wsrm:SequenceAcknowledgement ...>   
>  <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>
  
>  [ [<wsrm:AcknowledgementRange ...   
>      Upper="xs:unsignedLong"   
>      Lower="xs:unsignedLong"/> +  
>     <wsrm:Final/> ? ]   
>  | <wsrm:Nack> xs:unsignedLong </wsrm:Nack> + ]  
>  ...   
> </wsrm:SequenceAcknowledgement>   
> 
> After line 378, add to the description of the SeqAck elements:  
  
>  /wsrm:SequenceAcknowledgement/wsrm:Final     
>  This optional element, if present, indicates that the RM  
  
>  Destination is not accepting new messages for the    
>  specified Sequence.  The RM Source can be assured that
    
>  the ranges of messages acknowledged by this   
>  SequenceAcknowledgement header block will not change in the
    
>  future.  Any attempt to deliver additional messages to
this     
>  sequence MUST generate a SequenceClosed fault by the RM  
>  Destination.  This element MUST be present when the Sequence
    
>  is no longer accepting new message.   
>  Note: this element MUST NOT be used when sending a Nack, it
    
>  can only be used when sending AcknowledgementRanges.  
> 
> On lines 569 and 570 change:   
>  After an RM Source receives the <SequenceAcknowledgement>
    
>  acknowledging the complete range of messages in a Sequence,
it 
>  sends a ... 
> to     
>  When the RM Source has completed its use of the Sequence, it
    
>  sends a ...     
> 
> To the end of that para, at the end of line 574, add:    
>  Note, under normal usage the RM source will complete its use
of   
>  the sequence when all of the messages in the Sequence have been
    
>  acknowledged.  However, the RM Source is free to Terminate
    
>  or Close a Sequence at any time regardless of the acknowledgement
    
>  state of the messages.   
> 
> Change lines 581 and 582 from:   
>  This element is sent by an RM Source after it has received the
    
>  final <SequenceAcknowledgement> covering the full range
of a Sequence.     
> to     
>  This element is sent by an RM Source to indicate it has completed
>  its use of the Sequence, i.e. it will not attempt to send any
  
>  additional application messages to the RM Destination.  RM
protocol   
>  messages, e.g. AckRequested, CloseSequence and TerminateSequence
  
>  may still be sent.   
> 
> After line 396, add a new section about closing a Sequence:  
>  3.6 Closing A Sequence     
>  There may be times during the use of an RM Sequence that the
RM   
>  Source or RM Destination will wish to discontinue using a Sequence
  
>  even if some of the messages have not been successfully delivered
  
>  to the RM Destination.   
> 
>  In the case where the RM Source wishes to discontinue use of
a 
>  sequence, while it can send a TerminateSequence to the RM Destination,
    
>  since this is a one-way message and due to the possibility of
late     
>  arriving (or lost) messages and Acknowledgements, this would
leave     
>  the RM Source unsure of the final ranges of messages that were
    
>  successfully delivered to the RM Destination.    
> 
>  To alleviate this, the RM Source can send a <wsrm:CloseSequence>
element,     
>  in the body of a message, to the RM Destination to indicate
that     
>  RM Destination MUST NOT accept any new application messages
for the     
>  specified sequence, other than those already received at the
time 
>  the <wsrm:CloseSequence> element is interpreted by the
RMD.  Upon receipt 
>  of this message the RM Destination MUST send a SequenceAcknowledgement
  
>  to the RM Source.  Note, this SequenceAcknowledgement MUST
include the   
>  <wsrm:Final> element indicating that the RM Destination
will not accept   
>  any new messages for this sequence. 
> 
>  While the RM Destination MUST NOT accept any new application
messages   
>  it MUST still accept and process RM protocol messages.  For
example,   
>  it MUST accept and respond to AckRequested, TerminateSequence
as well as   
>  CloseSequence messages.  Note, subsequent CloseSequence
messages have no   
>  effect on the state of the sequence. 
> 
>  In the case where the RM Destination wishes to discontinue use
of a
> sequence it may 'close' the sequence itself.  Please see wsrm:Final
> above and the Sequence Closed fault below. Note the SequenceClosed
> Fault SHOULD be used in place of the SequenceTerminated Fault, 
> whenever possible, to allow the RM Source to still receive 
>  Acknowledgements. 
> 
>  The following exemplar defines the CloseSequence syntax:  
>    <wsrm:CloseSequence wsrm:Identifier="xs:anyURI"/>
    
> 
>  /wsrm:CloseSequence   
>  This element is sent by an RM Source to indicate that the RM
    
>  Destination MUST NOT accept any new messages for this sequence.
  
>  Any attempt to deliver additional messages to this sequence
    
>  MUST generate a SequenceClosed fault by the RM Destination.
    
> 
>  /wsrm:CloseSequence@Identifier   
>  This required attribute contains an absolute URI conformant
    
>  with RFC2396 that uniquely identifies the sequence.   
> 
>  /wsrm:CloseSequence/{any}     
>  This is an extensibility mechanism to allow different (extensible)
    
>  types of information, based on a schema, to be passed.  
  
>    
>  /wsrm:CloseSequence@{any}   
>  This is an extensibility mechanism to allow additional attributes,
    
>  based on schemas, to be added to the element.   
> 
>  A <wsrm:CloseSequenceResponse> is sent in the body of
a response message by     
>  an RM Destination in response to receipt of a <wsrm:CloseSequence>
request   
>  message.  It indicates that the RM Destination has closed
the   
>  sequence.   
> 
>  The following exemplar defines the <wsrm:CloseSequenceResponse>
syntax:     
> 
>  /wsrm:CloseSequenceResponse   
>  The element is sent in the body of a response message by  
  
>  an RM Destination in response to receipt of a <wsrm:CloseSequence>
request   
>  message.  It indicates that the RM Destination has closed
the   
>  sequence.   
> 
>  /wsrm:CloseSequenceResponse/{any}   
>  This is an extensibility mechanism to allow different (extensible)
    
>  types of information, based on a schema, to be passed.  
  
>    
>  /wsrm:CloseSequenceResponse@{any}     
>  This is an extensibility mechanism to allow additional attributes,
    
>  based on schemas, to be added to the element.   
> 
> On lines 735 and 746 make these faults non-terminating by removing:
    
>  It is an unrecoverable error and terminates the Sequence.  
  
>    
> After line 760, add a new fault:   
>  4.8 Sequence Closed     
>  This fault is sent by an RM Destination to indicate that the
>  specified sequence has been closed. 
>  Properties:     
>  [Code] Sender   
>  [Subcode] wsrm:SequenceClosed   
>  [Reason] The sequence is closed and can not accept new messages.
  
>  [Detail] <wsrm:Identifier...> xs:anyURI </wsrm:Identifier>
> 
> Add the proper XML to the schema and WSDL....   
> 
> thanks,     
> -Doug