[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposed resolutions will be incorporated.
All, I will post the updated specs soon. I see no objections to the proposed resolution from Tom about T1 and T2, and other resolutions from me, I will incorporate those resolutions in the coming specs. Thanks, Iwasa ----- Original Message ----- From: "Tom Rutt" <tom@coastin.com> To: "iwasa" <kiwasa@jp.fujitsu.com> Cc: "wsrm" <wsrm@lists.oasis-open.org> Sent: Saturday, April 07, 2007 2:00 AM Subject: Re: [wsrm] Comments on proposed resolutions for Deployment Template Issues 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]