Doug,
Doug Bunting wrote:
> Sunil,
>
> I believe John had a good point that, while it may not change the
> suggested text, is certainly an important part of your proposal. If we
> were to accept this proposal and require it in all implementations (not
> something that is entirely clear in this proposal), we may be changing
> the persistence requirements.
How does this proposal change the "existing" persistence requirements?
As far as I recollect, it supports the existing ones without any new
requirements. Atleast my intent was not to jeopardize any existing ones
or add new ones.
>
>
> I am curious why the StatusResponse contains a Status that seems to
> include error conditions. What rules decide whether a situation should
Are you referring to InvalidGroupId & InvalidSequenceNo? If so, they
are not the cause of the original msg., but rather the Status request msg.
itself. If a receiving RMP receives a Status request for a msg with a
GroupId that was not never sent or was invalid, it will then send an
InvalidGroupId 'status' response corresponding to the 'status' request
and not the original request.
>
> result in a Fault versus a Status? The current proposal leans toward
> Status handling without explanation.
I didn't understand the above.
>
> Other issues arise due to the bundling suggested below. When one
> StatusRequest is invalid (should result in a Fault) but the bundled
> business Request (or additional StatusRequest) does not, what happens?
This is a generic problem in the sense that we will have the same problem
if we want to piggy-back Acks on other Requests & Responses. We ran into
similar cases when Jacques is trying to propose a solution for Response
Ack. pattern,
>
> If multiple StatusRequest elements are contained in one message, must
> all related StatusResponse elements be included in a single message as well?
We could go either way, but for protocol simplicity we should say yes.
>
>
> The existing patterns are focused on RMP-level signals and this proposal
> puts handling the status requests at that level. This leads to
> potential handling delays if too many requests are bundled together. In
> turn, this proposal leads to additional cases in which the patterns
> cannot hold.
We should then come with recommendation and exclusion cases.
-Sunil
>
>
> Many systems will impose security restrictions in the area of these
> requests. Some will refuse to respond positively to any request; others
> will ignore requests not coming from the originator of the referenced
> message. These and other common situations should be described below.
>
> Finally a new (separable) issue, both this suggested Status text and the
> existing description of faultcode values defined in our specification
> are rather lax about qnames. Restrictions such as requiring a value to
> be a qname should be clear in the text, not just indicated in the schema
> (not a problem below). Any possible value examples and descriptions
> should use a fully qualified name.
>
> thanx,
> doug
>
> On 16-Sep-03 12:51, Sunil Kunisetty wrote:
>
> >
> > 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.
> >
> >
> >
> > 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.
> >
>
> --
> SunNetwork 2003 Conference and Pavilion
> "An unparalleled event in network computing! Make the net work for you!"
>
> WHEN: September 16-18, 2003
> WHERE: Moscone Center, San Francisco
>
> For more information or to register for the conference, please visit:
> http://www.sun.com/sunnetwork
