[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern
On Tuesday, September 16, 2003, at 03:59 PM, Sunil Kunisetty wrote: > > 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. >> If someone asks for the status of a message that was successfully >> passed on to the application layer or that expired and was purged, >> at sometime in the past, how do we know the status of the request >> without archiving beyond the current requirements of the specification? > >> >> >> 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]