OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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