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.
