Re: [higgins-dev] OID and name uniqueness

[Mark Wahl <Mark.Wahl@xxxxxxxxxxxxxxxxxxxx>]

Tom Doman wrote:

> Being more of an eDirectory guy than a straight up LDAP guy like Jim, 
> I went to consult RFC2252 to see if I could get definitions on the different
> USAGE values but I couldn't find them there.  One of the things I wanted to
> verify was that "directoryOperation" meant that EVERY entry was required to
> have this attribute maintained.

No, on ordinary entries, operational attributes are generally not
required to be present, apart from the special attribute objectClass.
The correct way in LDAP subschema to say that every entry MUST contain
a particular attribute (other than the "objectClass" attribute, which
is required by the objectclass "top"), is to use DIT Content Rules;
however, only LDAP servers based on X.500 typically implement this
feature, so I would suggest not worrying about DIT Content Rules for
a version 1 release.  (Some servers, such as from Microsoft, modify the
definition of "top" to add attributes, which is incorrect).  At present
there is no way in common use to indicate to directory clients what
operational attributes MAY be present on entries.  Ie., if there is
an operational attribute "foo" that is NOT marked NO-USER-MODIFICATION,
then there's no easy way for an LDAP client to know whether to put
"foo" into a GUI as a potential attribute for inclusion when adding or
modifying an entry.  In general, the majority of operational attributes
are either read-only OR are updated only by special-purpose clients which
implement the semantics of that attribute (e.g. the time to live operational
attribute is only sent by a client which is aware of what it means for an
entry to time out.), so the safest thing is treat operational attributes
as read-only unless the application knows to mention them by name.

The differences between dSAOperation, distributedOperation and
directoryOperation are generally significant only to directory server
management tools.  There's a little bit of documentation in RFC 4512
section 3.4, but the full definition is in X.501, which, apart from
its ASN.1 module, is not online, as it's a pay to read ITU-T standard.

> Further I wanted to verify that "dSAOperation" meant that these attributes
> were required to be maintained on the rootDSE (

Sorry, the main distinction between the usages is that attributes in
ordinary entries with types of usage dSAOperation are not replicated when the
entries containing them are replicated between directory servers, but attributes
with types with usage directoryOperation, usage distributedOperation, and no usage
(not operational attribute) ARE replicated between servers.  A dSAOperational
attribute can be present in any ordinary entry.  For example, on some
implementations, a "last login time" on a user's entry is a dSAOperational attribute,
meaning that each directory server keeps its own last login time, whereas in
other implementations a "last login time" is a directoryOperation or
distributedOperation attribute, meaning that the directory servers replicate
this, and when two servers are replicating, the latest time value is used as
the value.

At present, there's no way for a directory server to indicate that
an attribute is permitted to be present in the root DSE.  Few servers
support modification of the root DSE, and even fewer support adding
attributes to the root DSE over LDAP.  Since the root DSE is not replicated,
some attributes present there are dSAOperation, some are directoryOperation,
others distributedOperation - there hasn't been a need to make them
consistent.

Mark Wahl
Informed Control Inc.