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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrm] time management: the options

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


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.


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


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


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

Easier to implement.


- 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]