Subject: [ldapext] need of dynamic attributes

From: [email-masked]
Date: Fri, 11 Oct 2002 15:14:22 -0400

When a user account in a directory has expirationdate attribute,
a today's ldap application needs to write a code to check the user's 
expirationdate against the system's today's date
to validate if the account is valid.

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)

Dynamic attributes can be quite useful, which requires such attributes and
search filter using dynamic attributes to be defined.

I wonder if work on dynamic attributes is within ldapext scope.

Any thoughts?

Thanks,

Christine Yoon
Security Integration
PricewaterhouseCoopers
(201)981-1172 (cell)
(732)706-3559

_________________________________________________________________
The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential and/or privileged 
material.  Any review, retransmission, dissemination or other use of, or 
taking of any action in reliance upon, this information by persons or 
entities other than the intended recipient is prohibited.   If you 
received this in error, please contact the sender and delete the material 
from any computer.

---

From: Mark Wahl <[email-masked]>
Date: Fri, 11 Oct 2002 14:28:52 -0500

[email-masked] wrote:
> the value of the attribute is the ldap server system's date, the application
> may simply configure a ldap filter something like

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.

> 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 wonder if work on dynamic attributes is within ldapext scope.

LDAPEXT the working group has shut down already.  You can discuss it on this
mailing list but there is no working group 'scope' for dynamic attributes
any more.

Mark Wahl
Sun Microsystems Inc.
_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 11 Oct 2002 13:01:40 -0700

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

>the capability which some LDAP implementations provide, which I call virtual

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