RE: [wsrm] time management: the options

[Jacques Durand <JDurand@fsw.fujitsu.com>]

That seems to be a far-reaching question...

A  future version will probably need to express endpoint-policy,

something we call for now  "RM parameters", which do not always need to appear in the protocol.

 

Remains that we still need to figure how V1.0 should talk about such parameters as retry intervall, retrycount,

which have no room in the protocol.

 

XACML is still very much access-control oriented ("Permit" or "deny"), yet the new direction

that the TC seems to take (more focused on WS) is quite interesting. Some practical question remain

on its appropriate use: when the scope of a policy - here a reliability requirement-  is too fine-grained, like a "small" group,

do we want the overhead of communicating the policy to the Sender/Receiver via  a separate protocol, or would

it be more convenient to just have the message header dictate the behavior of Receiver, like we do now...

 

Jacques

 

 

 -----Original Message-----
From: John Fuller [mailto:jfuller@wernervas.com]
Sent: Friday, November 07, 2003 4:42 AM
To: Jacques Durand
Cc: 'wsrm@lists.oasis-open.org'
Subject: Re: [wsrm] time management: the options

can XACML help at the granularity of endpoint-policy?

On Nov 7, 2003, at 1:23 AM, Jacques Durand wrote:

Here is a summary of the two major options I believe we face about dealing with timing, as outlined in previous mails,

and my analysis of their advantages / disadvantages.

After consideration, I personally favor Proposal #1 (the one we started on at f-2-f).

Tomorrow I will map this time management proposal to our list of current issues,

and propose corresponding resolution/impact to several of them.

The schema so far is same as last proposed in f-2-f.

Jacques

Proposal #1: (use time parameters)

-----------

Uses ExpiryTime, GroupExpiryTime, MaxGroupIdleTime, here carried in the protocol

(messages), as discussed last f-2-f.

The group termination follows rules based on these values, as we outlined them

in f-2-f, and of which I propose/summarize a complete version in draft sent out Nov 2.

Advantage:

- group duration, scope of duplicate check, is clearly controlled

by these parameters. Semantics is clear to users.

- control of storage space is better (much less chance to overflow available space)

- synchronization between sender and receiver via protocol (same understanding

on both sides, of persistence conditions).

Drawbacks:

- possible abuse by users (the RMP may have to "cap" these values, based

on some configuration).

- implementors must implement these rules in order to conform to spec (more complex).

Proposal #2: (timeless)

------------

Does NOT specify ExpiryTime, GroupExpiryTime, MaxGroupIdleTime.

Instead, groups and message IDs are kept open and persisting until some garbage

collection takes place, controlled by config for each implementation.

Advantage:

- no "termination" management is required to conform to specification. Simpler spec,

Easier to implement.

Drawbacks:

- the contract about the scope of dup elimination, of group duration, is unclear

as controlled by storage availability, possibly differently by each impleemntation.

- synchronization of termination and removal of states between Sender and Receiver unclear.

- more chance to overflow available storage, watermark parameters for space limits

will be reached more often, making terminations of persisted groups and message IDs

unpredictable.