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

 

Jacques

 

 

 -----Original 
Message-----
From: John Fuller 
[mailto:]
Sent: Friday, November 07, 2003 4:42 
AM
To: Jacques Durand
Cc: 
''
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.