OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] NEW ISSUE - No indication of how to process NACKs in normalcase


I disagree. 

A Nack is an optimization of an Ack with gaps, true. However, if the RMD 
is issuing Nacks
(it's choice) then to ensure the correctness of the protocol, the RMS MUST 
retransmit the
messages, just as it MUST retransmit unacknowledged messages as expressed 
as a
SequenceAcknowledgement with more than one AcknowledgementRange elements.

What is not specified, nor should it be, is the timing of the 
retransmission.

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

"Marc Goodner" <mgoodner@microsoft.com> wrote on 09/07/2005 12:28:17 PM:

> Because this is up to the RMS and is only an optimization the RMD may
> use a MAY seems more appropriate here than either a SHOULD. A MUST is
> not acceptable, a SHOULD is. I think Steve's rationale for proposing
> this as a SHOULD based on previous discussion of this topic was correct.
> 
> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Wednesday, September 07, 2005 9:25 AM
> To: ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] NEW ISSUE - No indication of how to process NACKs
> in normal case
> 
> +1
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295
> 
> "Winkler, Steve" <steve.winkler@sap.com> wrote on 09/07/2005 12:09:18
> PM:
> 
> > 
> > Hi Doug,
> > 
> > I went back and forth on that one myself for a little while. I prefer 
> MUST too, but there appeared
> > to be some push back on this during the initial discussion so I stuck 
> with SHOULD.  Your rationale
> > makes sense to me though and I would be fine (even happy) to use MUST.
> 
> Let's see what the group 
> > thinks on the call on Thursday.
> > 
> > Cheers,
> > Steve
> > -----Original Message-----
> > From: Doug Davis [mailto:dug@us.ibm.com] 
> > Sent: Wednesday, September 07, 2005 6:37 AM
> > To: ws-rx@lists.oasis-open.org
> > Subject: Re: [ws-rx] NEW ISSUE - No indication of how to process NACKs
> 
> in normal case
> 
> > 
> > Steve, 
> >   +1 - although I'd prefer it to be a MUST to be consistent with the 
> text for AckRequested - but 
> > since its really up to the RMS to determine when to do it anyway its
> not 
> a huge thing. 
> > thanks 
> > -Doug 
> > 
> > 
> 
> > 
> > "Winkler, Steve" <steve.winkler@sap.com> 
> > 09/06/2005 02:54 PM 
> > 
> > To
> > 
> > <ws-rx@lists.oasis-open.org> 
> > 
> > cc
> > 
> > Subject
> > 
> > [ws-rx] NEW ISSUE - No indication of how to process NACKs in normal
> case
> > 
> > 
> > 
> 
> > All, 
> > Here's a description of the new issue I wanted to raise from the 
> discussion of the related issue i005 [1]. 
> > Title: Processing model of NACKs 
> > Description: Although it is assumed that a NACK will trigger 
> retransmission of a given message 
> > from the source to the destination there is no wording in the current 
> version of the spec that 
> > describes this feature adequately. 
> > Justification: This will clarify to implementers the spriit of the
> spec 
> by spelling out in more 
> > concrete terms what is currently only implied. 
> > Target: Core 
> > Type: Design 
> > Proposal: 
> > Add the following to the spec directly before the text that is 
> incorporated as a resolution to i005: 
> > Upon the receipt of a Nack, an RM Source SHOULD retransmit the message
> 
> identified by the Nack as 
> > soon as possible. 
> > Cheers,
> > Steve 
> > 
> > [1] http://lists.oasis-open.org/archives/ws-rx/200508/msg00272.html 
> > 
> > --------------------------- 
> > Steve Winkler 
> > SAP AG 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]