Re: [ldapext] need of dynamic attributes

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:28 PM 2002-10-11, Mark Wahl wrote:
>christine.yoon@us.pwcglobal.com wrote:
>> If a dynamic attribute such as todaysdate is defined as a part of ldap schema
>> and
>> the value of the attribute is the ldap server system's date, the application
>> may simply configure a ldap filter something like
>>     (&(ou=useraccount)(todaysdate()<expirationdate)
>
>But if my application is running at 2002101023412Z wouldn't it just send
>(&(ou=useraccount)(expirationDate>=2002101023412Z) ? This wouldn't need
>a todays date or other LDAP schema extension.

I note that even if one had an operational 'todaysdate' attribute
in every entry, there is no standard mechanism for compare values
of one attribute to another attribute.  An extension of some sort
would be needed, like an extensible matching rule allowing
assertions like:
        (expirationDate:=valuesGreaterThanOrEqualTo:=todaysdate)

(where expirationDate and todaysdate are attribute types).

>> Dynamic attributes can be quite useful, which requires such attributes and
>> search filter using dynamic attributes to be defined.
>
>There was an earlier draft on dynamic attributes which were attributes 
>that would time out and disappear if not refreshed.  This draft document 
>itself timed out and disappeared though you might be able to find it
>from the informal expired I-D archives.  What you describe sounds also like
>the capability which some LDAP implementations provide, which I call virtual
>attributes.

I note as well that the LDAP provides "collective" attributes
(RFC 2252/X.501) which appear to be similar in concept to
"virtual" attributes (as provided by some LDAP implementations).
As there are big gaps between RFC 2252 and X.501, I authored
draft-zeilenga-ldap-collective.

Kurt

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext