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

[Tom Rutt <tom@coastin.com>]

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)

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