[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
-------------------------------------------------------------------------= --- Proposed-04 Title: Whose Inactivity Timeout is it anyway?=20 Description:=20 Currently the WS-RM Policy Assertion describes four distinctive = parameters in Section 2.1 [1]: Base Retransmission Interval, Exponential = Backoff, Inactivity Timeout and Acknowledgement Interval. Further, these = parameters are scoped with respect to two distinct roles as summarized = below: RMS:=20 -- Base Retransmission Interval (BRI)=20 -- Exponential Backoff (EB)=20 -- Inactivity Timeout (IT)=20 RMD:=20 -- Inactivity Timeout (IT)=20 -- Acknowledgement Interval (AI)=20 The current WS-RM Policy Specification allows the specification of the = Inactivity Timeout, however it is not clear who actually "owns" this = value. Is it the RMS or the RMD that specifies the value of the = Inactivity Timeout?=20 Currently the specification indicates the following in Lines 108-111:=20 {The assertion defines an inactivity timeout parameter that either the = RM Source or RM Destination MAY include. If during this duration, an = endpoint has received no application or control messages, the endpoint = MAY consider the RM Sequence to have been terminated due to = inactivity.=A0 } If either of the parties can include this value, which party does the = WS-RM Policy Attachment refer to? If it applies to, say RMD, shouldn't = the RMS be able to specify this in some fashion? Justification: Simply, it is not clear from the specification which = party it applies to. This must be clarified. Further, if either of the = parties can include this value, it should be stated when RMS or RMD may = specify this value.=20 Target: policy=20 Type: design=20 Proposal: TBD=20 RelatedTo: Previous New Issue Posted, "Target of RM Assertion parameters = are confusing with respect to how they are specified and attached" = ("soon" ;-) to appear at the tc website near you if you are patient! ).=20 References:=20 [1] = http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14793/wsr= mp-1.1-spec-wd-01.pdf=20 -------------------------------------------------------------------------= --- Proposed-05 Title: How can RMS communicate the Base Retransmission Interval, = Exponential Backoff and Inactivity Timeout values?=20 Description:=20 Currently the WS-RM Policy Assertion specification describes four = distinctive assertion parameters in Section 2.1 [1]: Base Retransmission = Interval, Exponential Backoff, Inactivity Timeout and Acknowledgement = Interval. Further, these parameters are scoped with respect to two = distinct roles as summarized below: RMS:=20 -- Base Retransmission Interval (BRI)=20 -- Exponential Backoff (EB)=20 -- Inactivity Timeout (IT)=20 RMD:=20 -- Inactivity Timeout (IT)=20 -- Acknowledgement Interval (AI)=20 The specification makes the above distinction and allows both the RMS = and the RMD to include their respective parameters. However, it is not = clear "where" these parameters would be included and "how" they would be = communicated between the RMS and RMD. Specifically, the current RM = Assertion element appears to apply only to a WSDL which enables the RMD = to communicate it assertions. However, it is not clear how the RMS can = express and communicate its RM Assertion parameters. Justification:=20 Although the specification defines certain parameters with respect to a = role, namely the RMS, it is not clear how they would be expressed and = communicated. This makes the specification incomplete and unusable from = the perspective of RMS.=A0 For example, it is impossible for an RMS to = configure its system once with parameters that suits its own needs and = allow these parameters to be negotiated with the RMD. Target: policy=20 Type: design=20 Proposal:=20 Scope the RM Assertion parameters on a per Sequence basis and utilize = the CreateSequence message exchange for communicating RM Assertion = parameters between the RMS and the RMD. Detailed proposal: TBD.=20 Related Issues:=20 References:=20 [1] = http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14793/wsr= mp-1.1-spec-wd-01.pdf=20 -------------------------------------------------------------------------= --- Proposed-06 Title: Classification of References (normative vs. non-normative) is = needed=20 Description:=20 Currently our working draft references are all over the map.=20 -- WS-RM: Lists most references as Normative, except those that are = related to WS-Policy. [1]=20 -- WS-RM Policy Assertion: All references are non-normative. [2]=20 As one of the editors of this spec, to put all references as = non-normative was deliberate on my part. IMO, the tc should make the = decision about the references and which bucket they belong to. This is = not an editorial decision and other TCs, such as WS-RF, went through = each reference and determined where they belong to.=A0=20 Justification: Obvious :-). We need normative and non-normative = references clearly delineated.=20 Target: core, policy=20 Type: design=20 Proposal: Review each reference by the tc and determine whether the = reference is normative. This must be done before we go to public draft = (PD).=20 I think we can live with this issue right now and should not affect our = first CD. For the first CD, I propose=A0 we leave everything as is and = put a note stating that the decision on classifying references is = pending.=20 References:=20 [1] = http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14785/wsr= m-1.1-spec-wd-05.pdf=20 [2] = http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14793/wsr= mp-1.1-spec-wd-01.pdf=20
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]