rfc2589.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         Y. Yaacovi
Request for Comments: 2589                                     Microsoft
Category: Standards Track                                        M. Wahl
                                            Innosoft International, Inc.
                                                             T. Genovese
                                                               Microsoft
                                                                May 1999


              Lightweight Directory Access Protocol (v3):
               Extensions for Dynamic Directory Services

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1.  Abstract

   This document defines the requirements for dynamic directory services
   and specifies the format of request and response extended operations
   for supporting client-server interoperation in a dynamic directories
   environment.

   The Lightweight Directory Access Protocol (LDAP) [1] supports
   lightweight access to static directory services, allowing relatively
   fast search and update access.  Static directory services store
   information about people that persists in its accuracy and value over
   a long period of time.

   Dynamic directory services are different in that they store
   information that only persists in its accuracy and value when it is
   being periodically refreshed.  This information is stored as dynamic
   entries in the directory.  A typical use will be a client or a person
   that is either online - in which case it has an entry in the
   directory, or is offline - in which case its entry disappears from
   the directory.  Though the protocol operations and attributes used by
   dynamic directory services are similar to the ones used for static
   directory services, clients that store dynamic information in the
   directory need to periodically refresh this information, in order to
   prevent it from disappearing.  If dynamic entries are not refreshed



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.  For
   example, this will happen if the client that set them goes offline.

   A flow control mechanism from the server is also described that
   allows a server to inform clients how often they should refresh their
   presence.

2. Requirements

   The protocol extensions must allow accessing dynamic information in a
   directory in a standard LDAP manner, to allow clients to access
   static and dynamic information in the same way.

   By definition, dynamic entries are not persistent and clients may go
   away gracefully or not.  The proposed extensions must offer a way for
   a server to tell if entries are still valid, and to do this in a way
   that is scalable.  There also must be a mechanism for clients to
   reestablish their entry with the server.

   There must be a way for clients to find out, in a standard LDAP
   manner, if servers support the dynamic extensions.

   Finally, to allow clients to broadly use the dynamic extensions, the
   extensions need to be registered as standard LDAP extended
   operations.

3. Description of Approach

   The Lightweight Directory Access Protocol (LDAP) [1] permits
   additional operation requests and responses to be added to the
   protocol.  This proposal takes advantage of these to support
   directories which contain dynamic information in a manner which is
   fully integrated with LDAP.

   The approach described in this proposal defines dynamic entries in
   order to allow implementing directories with dynamic information.  An
   implementation of dynamic directories, must be able to support
   dynamic directory entries.

3.1. Dynamic Entries and the dynamicObject object class

   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 entry
   is created.  The time-to-live is automatically decremented, and when
   it expires the dynamic entry disappears.  By invoking the refresh
   extended operation (defined below) to re-set the time-to-live, a
   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 given
   in section 5 in the list of attributes when adding an entry.  This
   method is subject to standard access control restrictions.

   The extended operation covered here, allows a client to refresh a
   dynamic entry by invoking, at intervals, refresh operations
   containing that entry's name.  Dynamic entries will be treated the
   same as non-dynamic entries when processing search, compare, add,
   delete, modify and modifyDN operations.  However if clients stop
   sending refresh operations for an entry, then the server will
   automatically and without notification remove that entry from the
   directory.  This removal will be treated the same as if the entry had
   been deleted by an LDAP protocol operation.

   There is no way to change a static entry into a dynamic one and
   vice-versa.  If the client is using Modify with an objectClass of
   dynamicObject on a static entry, the server must return a service
   error either "objectClassModsProhibited" (if the server does not
   allow objectClass modifications at all) or "objectClassViolation" (if
   the server does allow objectClass modifications in general).

   A dynamic entry may be removed by the client using the delete
   operation.  This operation will be subject to access control
   restrictions.

   A non-dynamic entry cannot be added subordinate to a dynamic entry:
   the server must return an appropriate update or service error if this
   is attempted.

   The support of dynamic attributes of an otherwise static object, are
   outside the scope of this document.

3.2 Dynamic meetings (conferences)

   The way dynamicObject is defined, it has a time-to-live associated
   with it, and that's about it.  Though the most common dynamic object
   is a person object, there is no specific type associated with the
   dynamicObject as defined here.  By the use of the dynamic object's
   attributes, one can make this object represent practically anything.

   Specifically, Meetings (conferences) can be represented by dynamic
   objects.  While full-featured meeting support requires special
   semantics and handling by the server (and is not in the scope of this
   document), the extensions described here, provide basic meetings
   support.  A meeting object can be refreshed by the meeting
   participants, and when it is not, the meeting entry disappears.  The
   one meeting type that is naturally supported by the dynamic
   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 meetings

   Creator-owned meetings are created by a client that sets the time-
   to-live attribute for the entry, and it is this client's
   responsibility to refresh the meeting entry, so that it will not
   disappear.  Others might join the meeting, by modifying the
   appropriate attribute, but they are not allowed to refresh the entry.
   When the client that created the entry goes away, it can delete the
   meeting entry, or it might disappear when its time-to-live expires.
   This is consistent with the common model for dynamicObject as
   described above.

4. Protocol Additions

4.1 Refresh Request

   Refresh is a protocol operation sent by a client to tell the server
   that the client is still alive and the dynamic directory entry is
   still accurate and valuable.  The client sends a Refresh request
   periodically based on the value of the client refresh period (CRP).
   The server can request that the client change this value.  As long as
   the server receives a Refresh request within the timeout period, the
   directory entry is guaranteed to persist on the server.  Client
   implementers should be aware that since the intervening network
   between the client and server is unreliable, a Refresh request packet
   may be delayed or lost while in transit.  If this occurs, the entry
   may disappear, and the client will need to detect this and re-add the
   entry.

   A client may request this operation by transmitting an LDAP PDU
   containing an ExtendedRequest.  An LDAP ExtendedRequest is defined as
   follows:

         ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
                 requestName             [0] LDAPOID,
                 requestValue            [1] OCTET STRING OPTIONAL }

   The requestName field must be set to the string
   "1.3.6.1.4.1.1466.101.119.1".

   The requestValue field will contain as a value the DER-encoding of
   the following ASN.1 data type:

        SEQUENCE {
                entryName  [0] LDAPDN,
                requestTtl [1] INTEGER
        }




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 of
   the dynamic entry [3].  This entry must already exist.

   The requestTtl is a time in seconds (between 1 and 31557600) that the
   client requests that the entry exists in the directory before being
   automatically removed.  Servers are not required to accept this value
   and might return a different TTL value to the client.  Clients must
   be able to use this server-dictated value as their CRP.

4.2 Refresh Response

   If a server implements this extension, then when the request is made
   it will return an LDAP PDU containing an ExtendedResponse.  An LDAP
   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 in
   the request.

   The response field will contain as a value the DER-encoding of the
   following ASN.1 data type:

        SEQUENCE {
                responseTtl [1] INTEGER
        }

   The responseTtl field is the time in seconds which the server chooses
   to have as the time-to-live field for that entry.  It must not be any
   smaller than that which the client requested, and it may be larger.
   However, to allow servers to maintain a relatively accurate
   directory, and to prevent clients from abusing the dynamic
   extensions, servers are permitted to shorten a client-requested
   time-to-live value, down to a minimum of 86400 seconds (one day).

   If the operation was successful, the errorCode field in the
   standardResponse part of an ExtendedResponse will be set to success.

   In case of an error, the responseTtl field will have the value 0, and
   the errorCode field will contain an appropriate value, as follows: If
   the entry named by entryName could not be located, the errorCode
   field will contain "noSuchObject".  If the entry is not dynamic, the
   errorCode field will contain "objectClassViolation".  If the
   requester does not have permission to refresh the entry, the




Yaacovi, et al.             Standards Track                     [Page 5]

RFC 2589    LDAPv3 Extensions for Dynamic Directory Services    May 1999


   errorCode field will contain "insufficientAccessRights".  If the
   requestTtl field is too large, the errorCode field will contain
   "sizeLimitExceeded".

   If a server does not implement this extension, it will return an LDAP
   PDU containing an ExtendedResponse, which contains only the
   standardResponse element (the responseName and response elements will
   be absent).  The LDAPResult element will indicate the protocolError
   result code.

   This request is permitted to be invoked when LDAP is carried by a
   connectionless transport.

   When using a connection-oriented transport, there is no requirement
   that this operation be on the same particular connection as any
   other.  A client may open multiple connections, or close and then
   reopen a connection.

4.3 X.500/DAP Modify(97)

   X.500/DAP servers can map the Refresh request and response operations
   into the X.500/DAP Modify(97) operation.

5. Schema Additions

   All dynamic entries must have the dynamicObject value in their
   objectClass attribute.  This object class is defined as follows
   (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 entry
           has a limited lifetime and may disappear automatically when
           its time-to-live has reached 0.  There are no mandatory
           attributes of this class, however if the client has not
           supplied a value for the entryTtl attribute, the server will
           provide one.'
     SUP top AUXILIARY )

   Furthermore, the dynamic entry must have the following operational
   attribute.  It is described using the AttributeTypeDescription
   notation of [2]:

   ( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl'
     DESC 'This operational attribute is maintained by the server and
           appears to be present in every dynamic entry.  The attribute
           is not present when the entry does not contain the
           dynamicObject object class. The value of this attribute is
           the time in seconds that the entry will continue to exist



Yaacovi, et al.             Standards Track                     [Page 6]