[Date Prev][Date Next]
Howard Chu schrieb:
> Kurt@OpenLDAP.org wrote:
>> With that, I leave determination of the technical suitability to the
@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:
>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.
> 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).