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

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

Tom Rutt wrote:

> Sunil Kunisetty wrote:
>
> > All -
> >
> > I had an AI @ the last F2F for coming up with a proposal for POLL pattern.
> >
> > Mark/Doug:
> >
> >
> Does this proposal allow only one message being referred to in the
> status request (e.g, what if there are multiple sequence numbers
> currently acknowledged for a specified group ID)

 It allows both piggy-backing (i.e. to be sent along another request/response)
 and batching (i.e. sending multiple status inquiries).

 -Sunil



>
>
> Tom Rutt
>
> > 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.
> >
> >
> >
>
> --
> ----------------------------------------------------
> Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
>
> 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.