As per Relevance of the word services, we have this rfc below:
Network Working Group Y.
Request for Comments: 2589
Category: Standards Track M.
Innosoft International, Inc
T.
May 1999
Lightweight Directory Access Protocol (v3):
Extensions for Dynamic Directory
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
1.
This document defines the requirements for dynamic directory
and specifies the format of request and response extended
for supporting client-server interoperation in a dynamic
environment
The Lightweight Directory Access Protocol (LDAP) [1]
lightweight access to static directory services, allowing
fast search and update access. Static directory services
information about people that persists in its accuracy and value
a long period of time
Dynamic directory services are different in that they
information that only persists in its accuracy and value when it
being periodically refreshed. This information is stored as
entries in the directory. A typical use will be a client or a
that is either online - in which case it has an entry in
directory, or is offline - in which case its entry disappears
the directory. Though the protocol operations and attributes used
dynamic directory services are similar to the ones used for
directory services, clients that store dynamic information in
directory need to periodically refresh this information, in order
prevent it from disappearing. If dynamic entries are not
Yaacovi, et al. Standards Track [Page 1]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
within a given timeout, they will be removed from the directory.
example, this will happen if the client that set them goes offline
A flow control mechanism from the server is also described
allows a server to inform clients how often they should refresh
presence
2.
The protocol extensions must allow accessing dynamic information in
directory in a standard LDAP manner, to allow clients to
static and dynamic information in the same way
By definition, dynamic entries are not persistent and clients may
away gracefully or not. The proposed extensions must offer a way
a server to tell if entries are still valid, and to do this in a
that is scalable. There also must be a mechanism for clients
reestablish their entry with the server
There must be a way for clients to find out, in a standard
manner, if servers support the dynamic extensions
Finally, to allow clients to broadly use the dynamic extensions,
extensions need to be registered as standard LDAP
operations
3. Description of
The Lightweight Directory Access Protocol (LDAP) [1]
additional operation requests and responses to be added to
protocol. This proposal takes advantage of these to
directories which contain dynamic information in a manner which
fully integrated with LDAP
The approach described in this proposal defines dynamic entries
order to allow implementing directories with dynamic information.
implementation of dynamic directories, must be able to
dynamic directory entries
3.1. Dynamic Entries and the dynamicObject object
A dynamic entry is an object in the directory tree which has a time
to-live associated with it. This time-to-live is set when the
is created. The time-to-live is automatically decremented, and
it expires the dynamic entry disappears. By invoking the
extended operation (defined below) to re-set the time-to-live,
client can cause the entry to remain present a while longer
Yaacovi, et al. Standards Track [Page 2]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
A dynamic entry is created by including the objectClass value
in section 5 in the list of attributes when adding an entry.
method is subject to standard access control restrictions
The extended operation covered here, allows a client to refresh
dynamic entry by invoking, at intervals, refresh
containing that entry's name. Dynamic entries will be treated
same as non-dynamic entries when processing search, compare, add
delete, modify and modifyDN operations. However if clients
sending refresh operations for an entry, then the server
automatically and without notification remove that entry from
directory. This removal will be treated the same as if the entry
been deleted by an LDAP protocol operation
There is no way to change a static entry into a dynamic one
vice-versa. If the client is using Modify with an objectClass
dynamicObject on a static entry, the server must return a
error either "objectClassModsProhibited" (if the server does
allow objectClass modifications at all) or "objectClassViolation" (
the server does allow objectClass modifications in general).
A dynamic entry may be removed by the client using the
operation. This operation will be subject to access
restrictions
A non-dynamic entry cannot be added subordinate to a dynamic entry
the server must return an appropriate update or service error if
is attempted
The support of dynamic attributes of an otherwise static object,
outside the scope of this document
3.2 Dynamic meetings (conferences
The way dynamicObject is defined, it has a time-to-live
with it, and that's about it. Though the most common dynamic
is a person object, there is no specific type associated with
dynamicObject as defined here. By the use of the dynamic object'
attributes, one can make this object represent practically anything
Specifically, Meetings (conferences) can be represented by
objects. While full-featured meeting support requires
semantics and handling by the server (and is not in the scope of
document), the extensions described here, provide basic
support. A meeting object can be refreshed by the
participants, and when it is not, the meeting entry disappears.
one meeting type that is naturally supported by the
extensions is creator-owned meeting
Yaacovi, et al. Standards Track [Page 3]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
3.2.1 Creator-owned
Creator-owned meetings are created by a client that sets the time
to-live attribute for the entry, and it is this client'
responsibility to refresh the meeting entry, so that it will
disappear. Others might join the meeting, by modifying
appropriate attribute, but they are not allowed to refresh the entry
When the client that created the entry goes away, it can delete
meeting entry, or it might disappear when its time-to-live expires
This is consistent with the common model for dynamicObject
described above
4. Protocol
4.1 Refresh
Refresh is a protocol operation sent by a client to tell the
that the client is still alive and the dynamic directory entry
still accurate and valuable. The client sends a Refresh
periodically based on the value of the client refresh period (CRP).
The server can request that the client change this value. As long
the server receives a Refresh request within the timeout period,
directory entry is guaranteed to persist on the server.
implementers should be aware that since the intervening
between the client and server is unreliable, a Refresh request
may be delayed or lost while in transit. If this occurs, the
may disappear, and the client will need to detect this and re-add
entry
A client may request this operation by transmitting an LDAP
containing an ExtendedRequest. An LDAP ExtendedRequest is defined
follows
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID
requestValue [1] OCTET STRING OPTIONAL }
The requestName field must be set to the
"1.3.6.1.4.1.1466.101.119.1".
The requestValue field will contain as a value the DER-encoding
the following ASN.1 data type
SEQUENCE {
entryName [0] LDAPDN
requestTtl [1]
}
Yaacovi, et al. Standards Track [Page 4]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
The entryName field is the UTF-8 string representation of the name
the dynamic entry [3]. This entry must already exist
The requestTtl is a time in seconds (between 1 and 31557600) that
client requests that the entry exists in the directory before
automatically removed. Servers are not required to accept this
and might return a different TTL value to the client. Clients
be able to use this server-dictated value as their CRP
4.2 Refresh
If a server implements this extension, then when the request is
it will return an LDAP PDU containing an ExtendedResponse. An
ExtendedResponse is defined as follows
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult
responseName [10] LDAPOID OPTIONAL
response [11] OCTET STRING OPTIONAL }
The responseName field contains the same string as that present
the request
The response field will contain as a value the DER-encoding of
following ASN.1 data type
SEQUENCE {
responseTtl [1]
}
The responseTtl field is the time in seconds which the server
to have as the time-to-live field for that entry. It must not be
smaller than that which the client requested, and it may be larger
However, to allow servers to maintain a relatively
directory, and to prevent clients from abusing the
extensions, servers are permitted to shorten a client-
time-to-live value, down to a minimum of 86400 seconds (one day).
If the operation was successful, the errorCode field in
standardResponse part of an ExtendedResponse will be set to success
In case of an error, the responseTtl field will have the value 0,
the errorCode field will contain an appropriate value, as follows:
the entry named by entryName could not be located, the
field will contain "noSuchObject". If the entry is not dynamic,
errorCode field will contain "objectClassViolation". If
requester does not have permission to refresh the entry,
Yaacovi, et al. Standards Track [Page 5]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
errorCode field will contain "insufficientAccessRights". If
requestTtl field is too large, the errorCode field will
"sizeLimitExceeded".
If a server does not implement this extension, it will return an
PDU containing an ExtendedResponse, which contains only
standardResponse element (the responseName and response elements
be absent). The LDAPResult element will indicate the
result code
This request is permitted to be invoked when LDAP is carried by
connectionless transport
When using a connection-oriented transport, there is no
that this operation be on the same particular connection as
other. A client may open multiple connections, or close and
reopen a connection
4.3 X.500/DAP Modify(97)
X.500/DAP servers can map the Refresh request and response
into the X.500/DAP Modify(97) operation
5. Schema
All dynamic entries must have the dynamicObject value in
objectClass attribute. This object class is defined as
(using the ObjectClassDescription notation of [2]):
( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject
DESC 'This class, if present in an entry, indicates that this
has a limited lifetime and may disappear automatically
its time-to-live has reached 0. There are no
attributes of this class, however if the client has
supplied a value for the entryTtl attribute, the server
provide one.'
SUP top AUXILIARY )
Furthermore, the dynamic entry must have the following
attribute. It is described using the
notation of [2]:
( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl
DESC 'This operational attribute is maintained by the server
appears to be present in every dynamic entry. The
is not present when the entry does not contain
dynamicObject object class. The value of this attribute
the time in seconds that the entry will continue to
Yaacovi, et al. Standards Track [Page 6]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
before disappearing from the directory. In the absence
intervening refresh operations, the values returned
reading the attribute in two successive searches
guaranteed to be nonincreasing. The smallest
value is 0, indicating that the entry may disappear
warning. The attribute is marked NO-USER-MODIFICATION
it may only be changed using the refresh operation.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-
NO-USER-MODIFICATION USAGE dSAOperation )
To allow servers to support dynamic entries in only a part of
DIT, the following operational attribute is defined. It
described using the AttributeTypeDescription notation of [2]:
( 1.3.6.1.4.1.1466.101.119.4 NAME 'dynamicSubtrees
DESC 'This operational attribute is maintained by the server and
present in the Root DSE, if the server supports the
extensions described in this memo. The attribute contains
list of all the subtrees in this directory for which
server supports the dynamic extensions.'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-
USAGE dSAOperation )
6. Client and Server
6.1 Client
Clients can find out if a server supports the dynamic extensions
checking the supportedExtension field in the root DSE, to see if
OBJECT IDENTIFIER described in section 4 is present. Since
may select to support the dynamic extensions in only some of
subtrees of the DIT, clients must check the
operational attribute in the root DSE to find out if the
extensions are supported on a specific subtree
Once a dynamic entry has been created, clients are responsible
invoking the refresh extended operation, in order to keep that
present in the directory
Clients must not expect that a dynamic entry will be present in
DIT after it has timed out, however it must not require that
server remove the entry immediately (some servers may only
timing out entries at intervals). If the client wishes to ensure
entry does not exist it should issue a RemoveRequest for that entry
Initially, a client needs to know how often it should send
requests to the server. This value is defined as the CRP (
Refresh Period) and is set by the server based on the entryTtl
Yaacovi, et al. Standards Track [Page 7]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
Since the LDAP AddRequest operation is left unchanged and is
modified in this proposal to return this value, a client must issue
Refresh extended operation immediately after an Add that created
dynamic entry. The Refresh Response will return the CRP (
responseTtl) to the client
Clients must not issue the refresh request for dynamic entries
they have not created. If an anonymous client attempts to do so,
server is permitted to return insufficientAccessRights (50) in
RefreshResponse, enforcing the client to bind first. Please note
servers which allow anonymous clients to create and refresh
entries will not be able to enforce the above
Clients should always be ready to handle the case in which
entry timed out. In such a case, the Refresh operation will
with an error code such as noSuchObject, and the client is
to re-create its entry
Clients should be prepared to experience refresh operations
with protocolError, even though the add and any previous
requests succeeded. This might happen if a proxy between the
and the server goes down, and another proxy is used which does
support the Refresh extended operation
6.2 Server
Servers are responsible for removing dynamic entries when they
out. Servers are not required to do this immediately
Servers must enforce the structural rules listed in above section 3.
Servers must ensure that the operational attribute described
section 5 is present in dynamic
Servers may permit anonymous users to refresh entries. However,
eliminate the possibility of a malicious use of the
operation, servers may require the refreshing client to bind first.
server implementation can achieve this by presenting ACLs on
entryTtl attribute, and returning insufficientAccessRights (50)
the RefreshResponse, if the client is not allowed to refresh
entry. Doing this, though, might have performance implications on
server and might impact the server's scalability
Servers may require that a client which attempts to create a
entry have a remove permission for that entry
Servers which implement the dynamic extensions must have the
IDENTIFIER, described above in section 4 for the request
Yaacovi, et al. Standards Track [Page 8]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
response, present as a value of the supportedExtension field in
root DSE. They must also have as values in the attributeTypes
objectClasses attributes of their subschema subentries,
AttributeTypeDescription and ObjectClassDescription from section 5.
Servers can limit the support of the dynamic extensions to only
of the subtrees in the DIT. Servers indicate for which subtrees
support the extensions, by specifying the OIDs for the
subtrees in the dynamicSubtrees attribute described in section 5.
a server supports the dynamic extensions for all naming contexts
holds, the dynamicSubtrees attribute may be absent
7. Implementation
7.1 Storage of dynamic
Dynamic information is expected to change very often. In addition
Refresh requests are expected to arrive at the server very often
Disk-based databases that static directory services often use
likely inappropriate for storing dynamic information. We
that server implementations store dynamic entries in
sufficient to avoid paging. This is not a requirement
We expect LDAP servers to be able to store static and
entries. If an LDAP server does not support dynamic entries,
should respond with an error code such as objectClassViolation
7.2 Client refresh
In some cases, the client might not get a Refresh response. This
happen as a result of a server crash after receiving the
request, the TCP/IP socket timing out in the connection case, or
UDP packet getting lost in the connection-less case
It is recommended that in such a case, the client will retry
Refresh operation immediately, and if this Refresh request does
get a response as well, it will resort to its original Refresh cycle
i.e. send a Refresh request at its Client Refresh Period (CRP).
7.3 Configuration of refresh
We recommend that servers will provide administrators with
ability to configure the default client refresh period (CRP),
also a minimum and maximum CRP values. This, together with
administrators to request that the server will not change the
dynamically, will allow administrators to set CRP values which
enforce a low refresh traffic, or - on the other extreme, an
up-to-date directory
Yaacovi, et al. Standards Track [Page 9]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
8.
Replication is only partially addressed in this memo. There is
separate effort in progress at the IETF on replication of static
dynamic directories
it is allowed to replicate a dynamic entry or a static entry
dynamic attributes. Since the entryTtl is expressed as a
time (how many seconds till the entry will expire), replicating
means that the replicated entry will be "off" by the
time
9.
The are no localization issues for this extended operation
10. Security
Standard LDAP security rules and support apply for the
described in this document, and there are no special security
for these extensions. Please note, though, that servers may
anonymous clients to refresh entries which they did not create
Servers are also permitted to control a refresh access to an entry
requiring clients to bind before issuing a RefreshRequest. This
have implications on the server performance and scalability
Also, Care should be taken in making use of information obtained
directory servers that has been supplied by client, as it may now
out of date. In many networks, for example, IP addresses
automatically assigned when a host connects to the network, and
be reassigned if that host later disconnects. An IP address
from the directory may no longer be assigned to the host that
the address in the directory. This issue is not specific to LDAP
dynamic directories
11.
Design ideas included in this document are based on those
in ASID and other IETF Working Groups
Yaacovi, et al. Standards Track [Page 10]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
12. Authors'
Yoram
One Microsoft
Redmond, WA 98052
Phone: +1 206-936-9629
EMail: yoramy@microsoft.
Mark
Innosoft International, Inc
8911 Capital of Texas Hwy #4140
Austin, TX 78759
Email: M.Wahl@innosoft.
Tony
One Microsoft
Redmond, WA 98052
Phone: +1 206-703-0852
EMail: tonyg@microsoft.
13.
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Protocol (Version 3)", RFC 2251, December 1997.
[2] Wahl, M. Coulbeck, A., Howes, T. and S. Kille, "
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[3] Wahl, M. and S. Kille, "Lightweight Directory Access
(v3): UTF-8 String Representation of Distinguished Names",
2253, December 1997.
Yaacovi, et al. Standards Track [Page 11]
RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
14. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Yaacovi, et al. Standards Track [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
