Next in thread →
Next in month →
RE: [ws-rx] i019 - Proposal #5
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 <> 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:] > Sent: Thursday, September 08, 2005 6:20 AM > To: > 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 <> > 09/06/2005 09:24 PM > > To > > Doug Davis/Raleigh/IBM@IBMUS, > > 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:] > Sent: Monday, September 05, 2005 5:05 PM > To: > 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
Next in thread →
Next in month →