[Date Prev][Date Next]
> With that, I leave determination of the technical suitability to the
It took me several passes through this discussion and the README to understand
what the intent of this code is. Just to make sure I get it, let me restate
what I saw:
3 extended matching rules for comparing a timestamp attribute to the server's
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.
The use of negatives is rather confusing. In the example, instead of
"nowNotBefore" and "nowNotAfter" I would simply have called them "startDate"
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" or
"syntactically standalone attribute".
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). 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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/