Re: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

John Fuller wrote:

> While I suppose it would add a diagnostic benefit, it sort of directly
> addresses the RMP
> as opposed to the RMP just knowing how to manage messages and hand them
> off.

 The above issue  while is  important is out-of-scope of this particular requirement/proposal.
 "Message management" was/should-be handled in the persistence/DE/RM sections.

>
> How long would you have to archive message information to know
> when expired groups were purged?  Or does it not assume transient
> services
> that persist, but a daemon that would only respond with knowledge since
> its startup?
>
> On Tuesday, September 16, 2003, at 01:51 PM, Sunil Kunisetty wrote:
>
> >
> >  All -
> >
> >  I had an AI @ the last F2F for coming up with a proposal for POLL
> > pattern.
> >
> >  Mark/Doug:
> >
> >  Could you create a Spec. Issue for Requirement Issues 3.6 & 3.7?
> >
> >  <ProposalBegin/>
> >
> >   I'd like to propose to have 2 new Headers:
> >
> >      StatusRequest
> >      StatusResponse
> >
> >   StatusRequest will be the Header used by the Sender to send a
> > poll/status
> >   inquiry to the Receiver. It will have 2 sub-elements. A mandatory
> > GroupId
> >   and an optional SequenceNo. The types for these are the same as the
> > ones
> >   in MessageHeader element.
> >
> >   StatusRequest
> >       - GroupId  - Mid URI type - Mandatory
> >       - SequenceNo - UnsignedLong - Optional
> >
> >   StatusRequest can be sent without a MessageHeader and hence can be
> >   piggy-backed on another Request or can be batched with other status
> > requests.
> >
> >   StatusResponse Header will be used by a Receiver to send the status
> > back
> >   to Sender. It will have the following sub-elements:
> >         - RefToGroupId      -  mid URI type - Mandatory
> >         - RefToSequenceNo - unsigned long  - Optional
> >         - Status                    - QNAME        - Mandatory
> >
> >   Possible Status Values are:
> >         - InvalidGroupId -  When the GroupId is invalid or
> > un-recognized
> >         - InvalidSequenceNo  - When the SequenceNo is invalid or
> > un-recognized
> >         - MsgExpired - When the message was expired (based on
> > ExpiryTime)
> >         - MsgReceived - When the message was received and ack-ed by
> > the RMP/
> >
> >   Since all our Header elements are extensible, Implementations can
> > extend with a
> >   new element called 'sub-status' and send more implementation
> > specific details
> >   if desired. But I prefer that Spec. level requirements for Status be
> > simple.
> >
> >   Multiple StatusResponse(s)  can be batched or can be piggy-backed on
> > Response.
> >
> >   We should be able to share the above Status values with Fault Codes.
> > Note both
> >   are QNAME types and hence shareable.
> >
> >   Error due to StatusRequest processing will result in a Fault with
> > error code
> >   InvalidStatusRequest.
> >
> >   <ProposalEnd/>
> >
> >  Comments ???
> >
> >  -Sunil
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster
> > of the OASIS TC), go to
> > http://www.oasis-open.org/apps/org/workgroup/wsrm/members/
> > leave_workgroup.php.
> >
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.