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