[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] Issue 129: Define "discard"
Dougs, +1 and also to DougB's point concerning dropping "optional" This definition of discard is acceptable to me since it imposes no specific mechanism or division of labor between RMD and AD in those areas that are out of scope of this protocol specification. As for the use of MUST: I think it is preferable since the specified behavior is REQUIRED in order to remove ending status doubt. The default behavior as described is effectively a non-announcement, and imposes the simplest constraint (or lack of constraint) on an RMD implementation. The reason for describing behavior in the default case is to permit the accurate understanding at the RMS of the status of each message upon closure or termination. Without the default behavior description then there would always be ending status doubt unless an out of band agreement were reached. The protocol does not support any way of verifying the existence of such an out of band agreement. I believe that the potential casual relationship of parties employing this protocol requires the definition of the default behavior if the protocol's advertised characteristics as described in Section 2 are to be maintained. Thanks -bob -----Original Message----- From: Doug.Bunting@Sun.COM [mailto:Doug.Bunting@Sun.COM] Sent: Thursday, June 15, 2006 9:22 PM To: Doug Davis Cc: ws-rx@lists.oasis-open.org Subject: Re: [ws-rx] Issue 129: Define "discard" Doug, +1 modulo removing the word "optional" (RFC 2119 again) to align with other elements the RMD may leave out. Just noticed that bit. I suspect a few continue to have problems with MUST. This doesn't bother me that much at the moment because I'm tired but not (yet) cranky, and it's the RMD itself imposing (announcing) the constraints on its later behaviour. Bob may certainly be able to convince me otherwise. Lower level detail: Why does the text explicitly say the RMD has a particular behaviour when it leaves the element out? In other words, why can't the RMD choose not to announce how it will handle gap-filled but closed sequences? thanx, doug On 15/06/06 18:12, Doug Davis wrote: > > Ok, I can live with that text, how about: > > /wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior > This optional element, if present, specifies the behavior that the RM > Destination will exhibit upon the closure, or termination, of an > incomplete sequence. For the purposes of defining the values used, the > term 'discard' refers to the Application Destination never processing > a particular message. > > A value of "DiscardEntireSequence" indicates that the entire Sequence > MUST be discarded by the RM Destination if the Sequence is closed, or > terminated, when there are one or more gaps in the final > SequenceAcknowledgement. > > A value of "DiscardFollowingFirstGap" indicates that the messages in > the Sequence beyond the first gap MUST be discarded by the RM > Destination if the Sequence is closed, or terminated, when there are > one or more gaps in the final SequenceAcknowledgement. > > The default value of "NoDiscard" indicates that no acknowledged > messages in the Sequence will be discarded by the RM Destination. > > > Bob? DougB? > > thanks, > -Doug > > > > *Doug Bunting <Doug.Bunting@Sun.COM>* > Sent by: Doug.Bunting@Sun.COM > > 06/15/2006 05:30 PM > > > To > Doug Davis/Raleigh/IBM@IBMUS > cc > ws-rx@lists.oasis-open.org > Subject > Re: [ws-rx] Issue 129: Define "discard" > > > > > > > > > > Well, this mostly addresses my confused objection. I the 'discard' > definition still separates the RMD and AD more than necessary. How about: > > ... refers to the Application Destination never processing a > particular message. ... > > If you wish, could add "(or perhaps never receiving)" or "(or perhaps > never seeing)" or some such after "processing". > > thanx, > doug > > On 15/06/06 14:26, Doug Davis wrote: > > > > DougB, > > here's the latest proposal: > > > > /wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior > > This optional element, if present, specifies the behavior that the RM > > Destination will exhibit upon the closure, or termination, of an > > incomplete sequence. For the purposes of defining the values used, the > > term 'discard' refers to the RM Destination never allowing a > > particular message to be processed by the Application Destination. > > > > A value of "DiscardEntireSequence" indicates that the entire Sequence > > MUST be discarded by the RM Destination if the Sequence is closed, or > > terminated, when there are one or more gaps in the final > > SequenceAcknowledgement. > > > > A value of "DiscardFollowingFirstGap" indicates that the messages in > > the Sequence beyond the first gap MUST be discarded by the RM > > Destination if the Sequence is closed, or terminated, when there are > > one or more gaps in the final SequenceAcknowledgement. > > > > The default value of "NoDiscard" indicates that no acknowledged > > messages in the Sequence will be discarded by the RM Destination. > > > > > > thanks, > > -DougD >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]