RE: [ws-rx] Issue 129: Define "discard"

["Bob Freund-Hitachi" <bob.freund@hitachisoftware.com>]

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
>