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: ;
> 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.
