[Freeipa-devel] Time-Based Account Policies

[Stanislav Laznicka]

On 08/03/2015 04:30 PM, Alexander Bokovoy wrote:
> On Mon, 03 Aug 2015, Stanislav Laznicka wrote:
>>>> dragons may appear, although with a tiny tiny possibility of a 
>>>> golden treasure in the end.
>>> Yes, I think intervals are required.
>>>
>> Alright. I gave it a little thought considering the current state of 
>> the language for time rules and considering where I should go with 
>> these intervals. The thing about the 'interval' in iCalendar is that 
>> to use it it is necessary to also add at least the 'frequency' and 
>> 'startdate' elements to the language. With that, adding 'enddate' and 
>> 'count' optional elements should not be that bad. What I am hoping 
>> for is that the same functionality as in iCalendar can be achieved 
>> here and so far I do not see why not.
> Yep.
So I have been struggling with this for some time but I hopefully have a 
solution now. As for the language, I suggest using a new keyword with 
possible values as in following:

repeat=date1(-date2)?\+[1-9][0-9]*(d|w|m|y)(:[1-9][0-9]*)?

Here, the date1 and optional date2 are dates in format YYYYMMDD and 
stand for the start and end dates.
The number after + denotes the repetition interval and d/w/m/y stand for 
day/week/month/year periods respectively. I am omitting the SECONDLY, 
MINUTELY and HOURLY frequencies from iCalendar as I don't consider them 
appropriate for our purpose. Besides, if "repeat" is not set, the 
behavior is similar as with freq=SECONDLY. The number in the optional 
part with ':' stands for the iCalendar COUNT feature. **However**, I do 
not think the COUNT feature should be included in this implementation. 
It probably makes sense as far as the generating of "time events" 
(single occurences in time) goes, but in the context of time policies it 
seems quite confusing to me. Here are some reasons why I think it should 
not be included:

1. Suppose you want to set, say, something like freq=DAILY;count=100; 
with timeofday=0730-1600. Such range ends at 9:10 the first day and 
setting time with any freq+count combination would not therefore make 
much sense. Yes, omitting the time from COUNT would be possible 
solution, yet it is a different behavior as in iCalendar.

2. You want to set some really complex time policy that should repeat 
for certain amount of times. To me, it seems safer to set a certain 
fixed final date rather than have it automagically decided for you.

3. The code would get messier with COUNT included. Currently, the time 
policies are evaluated as they are parsed without the need of storing 
them. With COUNT, they will need to be stored and also, before the 
actual evaluation, the events would need to be generated which can be 
hard with more complex policies (is it possible to set an event that 
would never happen, yet each part describing it would be correct?).

4. Not including COUNT in implementation is not a blocker from importing 
from the iCalendar format. If anything, COUNT just allows generating a 
finite set of events. During the import, the last event of such set can 
be either counted and filled in as end date, or the events can just be 
imported one by one.

Do you consider such a solution passable?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20150806/d18f5da6/attachment.htm>