[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Comments on proposed resolutions for Deployment TemplateIssues T1 and T2
comments inline iwasa wrote: > Tom, > > Thank you for your updates. > Let me clarify your proposals to make sure how these should be > described in the issue list. > Are the followings correct statement for your proposed resolution? > > > Proposed resolution for Issue T1: > Delete the entire row for profile item (b) in section 4.1.1 and its columns. > Add the following statement to the right column of Notes in section 4.1.1: > > " > You may describe if there is any other requirement (e.g., Number > of retries, Interval between retries, and others). Describe any mechanisms > whereby the user of the deployed implementation may exercise control > of resending behavior. > " > > * I just want to make sure whether you want the first sentence above or not. > I do not want the first sentence, only the second starting with "Describe" > -- > > Proposed resolution for Issue T2: > Change the second column of profile item b) row in Section 4.1.3 from: > " > What is the behavior of a receiving RMP when a duplicate request is > received, for which a response had already been previously sent? (is a > Fault be sent back? Or a duplicate of the cached response?) > RECOMMENDED / REQUIRED > " > to > " > Which of the following statements describes the behavior of the > implementation of a receiving RMP when a duplicate request message, > which requires a response, is received: > 1) an application fault is always sent as response to the duplicate message > 2) a limited cache of sent responses is used to allow resend of the > prior response, when this cache is exhausted, an application fault is > sent in response to duplicate message > 3) all sent responses are cached until the expiry time for the original > request message > 4) other - please describe an alternative behavior regarding the > response sent after receipt of duplicate response > " > -- > > Thanks, > > Iwasa > > > ----- Original Message ----- > From: "Tom Rutt" <tom@coastin.com> > To: <tom@coastin.com> > Cc: "wsrm" <wsrm@lists.oasis-open.org> > Sent: Thursday, April 05, 2007 6:18 AM > Subject: [wsrm] Comments on proposed resolutions for Deployment Template > Issues T1 and T2 > > > >> I Talked to Jacques (who is away from reliable Internet access while on >> Vacation in France) regarding the issues for the deployment template >> candidate CD draft. >> >> Jacques stated that the Deployment template is not just for resolving >> interop concerns, but can be also >> used for a deployment to document any decisions it has made regarding >> stated options in the spec. >> >> This information may be considered useful to a prospective user of a >> deployed implementation of the standard. >> >> The answers may affect how the deployment may be used at run time, give >> the decisions the deployers have made regarding options. >> >> Regarding Issue T1: >> The entire row should be deleted (both collumns of profile item b) >> >> It might be better for the second column of the notes line to state the >> following: >> " >> Describe any mechanisms whereby the user of the deployed implementation >> > may > >> exercise control of resending behaviour. >> " >> >> Regarding Issue T2 - >> >> A user of a deployed implementation may want to know what the behaviour >> is upon receiving a duplicate request. >> >> This may be useful for deciding if reliability of the response can be >> attained by the actions of the request sender. >> >> Change the second column of profile item b) row from: >> >> " >> What is the behavior of a receiving RMP when a duplicate request is >> received, for which a response had already been previously sent? (is a >> Fault be sent back? Or a duplicate of the cached response?) >> RECOMMENDED / REQUIRED >> " >> >> Which of the following statements decribes the behaviour of the >> implementation of a receiving RMP when a duplicate request message, >> which requires a response, is received: >> 1) an application fault is alwayse sent as response to the duplicate >> > message > >> 2) a limited cache of sent responses is used to allow resend of the >> prior response, when this cache is exhausted, an application fault is >> sent in response to duplicate message >> 3) all sent responses are cached until the expiry time for the original >> request message >> 4) other - please describe an alternative behaviour regarding the >> response sent after receipt of duplicate response >> " >> >> >> >> Tom Rutt wrote: >> >>> Iwasa posted an issues list at: >>> >>> > http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/23358/IssueListForProfiles0.1.pdf > >>> The base Template Candidate CD refered to in the "T" issues in the >>> list is: >>> >>> > http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/23391/CandidateDeploymentTemplateCD-040207.pdf > >>> >>> The base Proposed CD for Information appliance profile, referred to in >>> the "P" issues in the list is: >>> >>> > http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/23275/wsr-profile-ias02.pdf > >>> Please provide comments on the proposed resolutions Iwasa has provided >>> in the Issues list for these two documents before the end >>> of this week. >>> >>> Tom Rutt >>> >>> >> -- >> ---------------------------------------------------- >> Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com >> Tel: +1 732 801 5744 Fax: +1 732 774 5133 >> >> >> > > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]