Proposed resolutions will be incorporated.

["iwasa" <kiwasa@jp.fujitsu.com>]

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
>
>