[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
John Fuller wrote: > 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, One of the current requirement reads "The receiver MUST persist the Message ID to support duplicate elimination". So to support this requirement, we anyway need to archive the ID. > > >> 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 > > > > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]