Re: (ITS#6247)

[daniel@pluta.biz]

Howard Chu schrieb:
> Kurt@OpenLDAP.org wrote:
>> With that, I leave determination of the technical suitability to the
>> Project.
@Kurt: my given copyright notices meet my intentions.


> I'm not sure why the 2 additional syntaxes are useful. If you want to 
> define a generalizedTime attribute that cannot be compared for ordering, 
> simply omit the ORDERING rule from the attribute's definition.

I thought, that it is possible to "overwrite" the ORDERING (even if its 
left empty) by using any kind of syntax-related matching rule assertion...

This is a quite old posting from the list but nevertheless I would like 
to cite it:
http://www.openldap.org/lists/openldap-devel/200010/msg00092.html

------8<-------8<------
 >Also, I have found this interesting section in RFC 2252:
 >
 >-----
 >8. Matching Rules
 >
 >   Servers which implement the extensibleMatch filter SHOULD allow all
 >   the matching rules listed in this section to be used in the
 >   extensibleMatch.  In general these servers SHOULD allow matching
 >   rules to be used with all attribute types known to the server, when
 >   the assertion syntax of the matching rule is the same as the value
 >   syntax of the attribute.
Yes.  That is, if the held value is syntax X, one should be able to
use any matching rule in which the assertion syntax X.
------8<-------8<------


> The use of negatives is rather confusing. In the example, instead of 
> "nowNotBefore" and "nowNotAfter" I would simply have called them 
> "startDate" and "endDate".
In general, the names indeed sound quite strange. But that seems only a 
matter of style. NotAfter and NotBefore is borrowed from ssl 
certificates' validNotBefore/-After fields. As I've called the module 
"now" I just replaced "valid" by "now"...

On the other hand I wanted to be sure to not collide with some might be 
existing attribute definitions.

> The language is also confusing in other areas, I don't understand what 
> property you're trying to convey with the terms "dead center attribute"
simply the lower and the upper limits of a time period
(lower: nowNotBefore, upper: nowNotAfter)


> or "syntactically standalone attribute".
All I've ment is just a new syntax name to differentiate regarding the 
special use of "now" and to avoid the possibility regarding my (possibly 
wrong) assumption that matching rules can be "overwritten".


> On a slightly related note, in the context of time-relative ACLs, it 
> would be worthwhile to define a behavior for time-of-day comparisons 
> (i.e., just compare hours:minutes:seconds, excluding year/month/day).
This kind of feature sounds fine to me, too.

Perhaps something like this could be implemented by introducing some 
kind of officeHourSyntax + matching rule which operates on e.g. 
"day(s)_of_week#hh:mm:ss#hh:mm:ss" attribute values (just my first 
thought and very simplified).

On the other side, using only one attribute which stores a start as well 
as an end timestamp is not what I originally wanted for "now" because I 
would like to have the possibility to track period extensions using the 
multi-valued upper dead center attribute.


> Companies often want to limit access to resources to only a set of 
> office hours, etc. Of course to properly handle the "office hours" case 
> would also require day-of-week matching. That may be getting to be too 
> complicated for this particular submission, but it seems closely related 
> so I mention it here.

In my opinion your suggestion sounds really interesting.

I personally just had searched for some kind of solution to get rid of 
the just-in-time event-triggered dependencies regarding provisioning of 
interconnected (not replicated) IDM-systems. So "now's" scope targets to 
longer (more static, not often changing) time-distances.

The check for the "office hours case" could be handled by an 
all-in-wonder (multi-valued) attribute which stores "day(s)#start#end".

Many thanks for your feedback. Some additional feedback/clarification 
regarding the above mentioned "overwriting" of matching rules would be 
very fine, too (e.g. a link where I can get the detailed specs).