rfc2589.txt

<VC++网络游戏建摸与实现>源代码


RFC 2589    LDAPv3 Extensions for Dynamic Directory Services    May 1999


           before disappearing from the directory.  In the absence of
           intervening refresh operations, the values returned by
           reading the attribute in two successive searches are
           guaranteed to be nonincreasing.  The smallest permissible
           value is 0, indicating that the entry may disappear without
           warning.  The attribute is marked NO-USER-MODIFICATION since
           it may only be changed using the refresh operation.'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE
     NO-USER-MODIFICATION USAGE dSAOperation )

   To allow servers to support dynamic entries in only a part of the
   DIT, the following operational attribute is defined.   It is
   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 is
           present in the Root DSE, if the server supports the dynamic
           extensions described in this memo. The attribute contains a
           list of all the subtrees in this directory for which the
           server supports the dynamic extensions.'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
     USAGE dSAOperation )

6. Client and Server Requirements

6.1 Client Requirements

   Clients can find out if a server supports the dynamic extensions by
   checking the supportedExtension field in the root DSE, to see if the
   OBJECT IDENTIFIER described in section 4 is present. Since servers
   may select to support the dynamic extensions in only some of the
   subtrees of the DIT, clients must check the dynamicSubtrees
   operational attribute in the root DSE to find out if the dynamic
   extensions are supported on a specific subtree.

   Once a dynamic entry has been created, clients are responsible for
   invoking the refresh extended operation, in order to keep that entry
   present in the directory.

   Clients must not expect that a dynamic entry will be present in the
   DIT after it has timed out, however it must not require that the
   server remove the entry immediately (some servers may only process
   timing out entries at intervals).  If the client wishes to ensure the
   entry does not exist it should issue a RemoveRequest for that entry.

   Initially, a client needs to know how often it should send refresh
   requests to the server.  This value is defined as the CRP (Client
   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 not
   modified in this proposal to return this value, a client must issue a
   Refresh extended operation immediately after an Add that created a
   dynamic entry.  The Refresh Response will return the CRP (in
   responseTtl) to the client.

   Clients must not issue the refresh request for dynamic entries which
   they have not created.  If an anonymous client attempts to do so, a
   server is permitted to return insufficientAccessRights (50) in the
   RefreshResponse, enforcing the client to bind first. Please note that
   servers which allow anonymous clients to create and refresh dynamic
   entries will not be able to enforce the above.

   Clients should always be ready to handle the case in which their
   entry timed out.  In such a case, the Refresh operation will fail
   with an error code such as noSuchObject, and the client is expected
   to re-create its entry.

   Clients should be prepared to experience refresh operations failing
   with protocolError, even though the add and any previous refresh
   requests succeeded.  This might happen if a proxy between the client
   and the server goes down, and another proxy is used which does not
   support the Refresh extended operation.

6.2 Server Requirements

   Servers are responsible for removing dynamic entries when they time
   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 in
   section 5 is present in dynamic entries

   Servers may permit anonymous users to refresh entries. However, to
   eliminate the possibility of a malicious use of the Refresh
   operation, servers may require the refreshing client to bind first. A
   server implementation can achieve this by presenting ACLs on the
   entryTtl attribute, and returning insufficientAccessRights (50) in
   the RefreshResponse, if the client is not allowed to refresh the
   entry. Doing this, though, might have performance implications on the
   server and might impact the server's scalability.

   Servers may require that a client which attempts to create a dynamic
   entry have a remove permission for that entry.

   Servers which implement the dynamic extensions must have the OBJECT
   IDENTIFIER, described above in section 4 for the request and



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 the
   root DSE.  They must also have as values in the attributeTypes and
   objectClasses attributes of their subschema subentries, the
   AttributeTypeDescription and ObjectClassDescription from section 5.

   Servers can limit the support of the dynamic extensions to only some
   of the subtrees in the DIT. Servers indicate for which subtrees they
   support the extensions, by specifying the OIDs for the supported
   subtrees in the dynamicSubtrees attribute described in section 5. If
   a server supports the dynamic extensions for all naming contexts it
   holds, the dynamicSubtrees attribute may be absent.

7. Implementation issues

7.1 Storage of dynamic information

   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 are
   likely inappropriate for storing dynamic information.  We recommend
   that server implementations store dynamic entries in memory
   sufficient to avoid paging.  This is not a requirement.

   We expect LDAP servers to be able to store static and dynamic
   entries.  If an LDAP server does not support dynamic entries, it
   should respond with an error code such as objectClassViolation.

7.2 Client refresh behavior

   In some cases, the client might not get a Refresh response.  This may
   happen as a result of a server crash after receiving the Refresh
   request, the TCP/IP socket timing out in the connection case, or the
   UDP packet getting lost in the connection-less case.

   It is recommended that in such a case, the client will retry the
   Refresh operation immediately, and if this Refresh request does not
   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 times

   We recommend that servers will provide administrators with the
   ability to configure the default client refresh period (CRP), and
   also a minimum and maximum CRP values. This, together with allowing
   administrators to request that the server will not change the CRP
   dynamically, will allow administrators to set CRP values which will
   enforce a low refresh traffic, or - on the other extreme, an highly
   up-to-date directory.



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


8. Replication

   Replication is only partially addressed in this memo. There is a
   separate effort in progress at the IETF on replication of static and
   dynamic directories.

   it is allowed to replicate a dynamic entry or a static entry with
   dynamic attributes. Since the entryTtl is expressed as a relative
   time (how many seconds till the entry will expire), replicating it
   means that the replicated entry will be "off" by the replication
   time.

9. Localization

   The are no localization issues for this extended operation.

10. Security Considerations

   Standard LDAP security rules and support apply for the extensions
   described in this document, and there are no special security issues
   for these extensions. Please note, though, that servers may permit
   anonymous clients to refresh entries which they did not create.
   Servers are also permitted to control a refresh access to an entry by
   requiring clients to bind before issuing a RefreshRequest. This will
   have implications on the server performance and scalability.

   Also, Care should be taken in making use of information obtained from
   directory servers that has been supplied by client, as it may now be
   out of date.  In many networks, for example, IP addresses are
   automatically assigned when a host connects to the network, and may
   be reassigned if that host later disconnects.  An IP address obtained
   from the directory may no longer be assigned to the host that placed
   the address in the directory.  This issue is not specific to LDAP or
   dynamic directories.

11. Acknowledgments

   Design ideas included in this document are based on those discussed
   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' Addresses

   Yoram Yaacovi
   Microsoft
   One Microsoft way
   Redmond, WA 98052
   USA

   Phone:  [phone]
   EMail:  [e-mail]


   Mark Wahl
   Innosoft International, Inc.
   8911 Capital of Texas Hwy #4140
   Austin, TX 78759
   USA

   Email: [e-mail]


   Tony Genovese
   Microsoft
   One Microsoft way
   Redmond, WA 98052
   USA

   Phone:  [phone]
   EMail:  [e-mail]

13. Bibliography

   [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
       Protocol (Version 3)", RFC 2251, December 1997.

   [2] Wahl, M. Coulbeck, A., Howes, T. and S. Kille, "Lightweight
       Directory Access Protocol (v3): Attribute Syntax Definitions",
       RFC 2252, December 1997.

   [3] Wahl, M. and S. Kille, "Lightweight Directory Access Protocol
       (v3): UTF-8 String Representation of Distinguished Names", RFC
       2253, December 1997.









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


14.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Yaacovi, et al.             Standards Track                    [Page 12]