LDAP Object Class for Application Users
draft-greenblatt-ldap-applusers-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Bruce Greenblatt | ||
| Last updated | 1997-07-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
In working with various directory enabled applications and services, it has been noticed that several of them presume the existence of an auxiliary object class with no attributes that is used to detect 'their' users. For example, the foo application service will use the fooUser object class, and attach this object class to all of its user objects in the directory in order that it may later on easily detect 'its' users, by virtue of the fact that those users are members of the fooUser object class. This fooUser object class is a subclass of top with no additional attributes. This specification intends to head off the day when a user would get one of these applicationUser object class things attached to its directory object for each application that it uses. This would mean that that object's object class attribute would eventually have dozens of values, which would in turn lessen the value of this attribute.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)