rfc4533.txt

samba最新软件

   modifiersName [RFC4512].  Servers MAY support synchronization of
   other operational attributes.

4.3.  Collective Attributes

   A collective attribute is "a user attribute whose values are the same
   for each member of an entry collection" [X.501].  Use of collective
   attributes in LDAP is discussed in [RFC3671].

   Modification of a collective attribute generally affects the content
   of multiple entries, which are the members of the collection.  It is
   inefficient to include values of collective attributes visible in
   entries of the collection, as a single modification of a collective
   attribute requires transmission of multiple SearchResultEntry (one
   for each entry of the collection that the modification affected).

   Servers SHOULD NOT synchronize collective attributes appearing in
   entries of any collection.  Servers MAY support synchronization of
   collective attributes appearing in collective attribute subentries.

4.4.  Access and Other Administrative Controls

   Entries are commonly subject to access and other administrative
   Controls.  While portions of the policy information governing a
   particular entry may be held in the entry, policy information is
   often held elsewhere (in superior entries, in subentries, in the root
   DSE, in configuration files, etc.).  Because of this, changes to
   policy information make it difficult to ensure eventual convergence
   during incremental synchronization.

   Where it is impractical or infeasible to generate content changes
   resulting from a change to policy information, servers may opt to
   return e-syncRefreshRequired or to treat the Sync Operation as an
   initial content request (e.g., ignore the cookie or the
   synchronization state represented in the cookie).

5.  Interaction with Other Controls

   The Sync Operation may be used with:

      - ManageDsaIT Control [RFC3296]




Zeilenga & Choi               Experimental                     [Page 23]

RFC 4533         LDAP Content Synchronization Operation        June 2006


      - Subentries Control [RFC3672]

   as described below.  The Sync Operation may be used with other LDAP
   extensions as detailed in other documents.

5.1.  ManageDsaIT Control

   The ManageDsaIT Control [RFC3296] indicates that the operation acts
   upon the DSA Information Tree and causes referral and other special
   entries to be treated as object entries with respect to the
   operation.

5.2.  Subentries Control

   The Subentries Control is used with the search operation "to control
   the visibility of entries and subentries which are within scope"
   [RFC3672].  When used with the Sync Operation, the subentries control
   and other factors (search scope, filter, etc.) are used to determine
   whether an entry or subentry appears in the content.

6.  Shadowing Considerations

   As noted in [RFC4511], some servers may hold shadow copies of entries
   that can be used to answer search and comparison queries.  Such
   servers may also support content synchronization requests.  This
   section discusses considerations for implementors and deployers for
   the implementation and deployment of the Sync operation in shadowed
   directories.

   While a client may know of multiple servers that are equally capable
   of being used to obtain particular directory content from, a client
   SHOULD NOT assume that each of these servers is equally capable of
   continuing a content synchronization session.  As stated in Section
   3.1, the client SHOULD issue each Sync request of a Sync session to
   the same server.

   However, through domain naming or IP address redirection or other
   techniques, multiple physical servers can be made to appear as one
   logical server to a client.  Only servers that are equally capable in
   regards to their support for the Sync operation and that hold equally
   complete copies of the entries should be made to appear as one
   logical server.  In particular, each physical server acting as one
   logical server SHOULD be equally capable of continuing a content
   synchronization based upon cookies provided by any of the other
   physical servers without requiring a full reload.  Because there is
   no standard LDAP shadowing mechanism, the specification of how to
   independently implement equally capable servers (as well as the
   precise definition of "equally capable") is left to future documents.



Zeilenga & Choi               Experimental                     [Page 24]

RFC 4533         LDAP Content Synchronization Operation        June 2006


   Note that it may be difficult for the server to reliably determine
   what content was provided to the client by another server, especially
   in the shadowing environments that allow shadowing events to be
   coalesced.  For these servers, the use of the delete phase discussed
   in Section 3.3.2 may not be applicable.

7.  Security Considerations

   In order to maintain a synchronized copy of the content, a client is
   to delete information from its copy of the content as described
   above.  However, the client may maintain knowledge of information
   disclosed to it by the server separate from its copy of the content
   used for synchronization.  Management of this knowledge is beyond the
   scope of this document.  Servers should be careful not to disclose
   information for content the client is not authorized to have
   knowledge of and/or about.

   While the information provided by a series of refreshOnly Sync
   Operations is similar to that provided by a series of Search
   Operations, persist stage may disclose additional information.  A
   client may be able to discern information about the particular
   sequence of update operations that caused content change.

   Implementors should take precautions against malicious cookie
   content, including malformed cookies or valid cookies used with
   different security associations and/or protections in an attempt to
   obtain unauthorized access to information.  Servers may include a
   digital signature in the cookie to detect tampering.

   The operation may be the target of direct denial-of-service attacks.
   Implementors should provide safeguards to ensure the operation is not
   abused.  Servers may place access control or other restrictions upon
   the use of this operation.

   Note that even small updates to the directory may cause a significant
   amount of traffic to be generated to clients using this operation.  A
   user could abuse its update privileges to mount an indirect denial of
   service to these clients, other clients, and/or portions of the
   network.  Servers should provide safeguards to ensure that update
   operations are not abused.

   Implementors of this (or any) LDAP extension should be familiar with
   general LDAP security considerations [RFC4510].








Zeilenga & Choi               Experimental                     [Page 25]

RFC 4533         LDAP Content Synchronization Operation        June 2006


8.  IANA Considerations

   Registration of the following values have been completed by the IANA
   [RFC4520].

8.1.  Object Identifier

   The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by the
   OpenLDAP Foundation, under its IANA-assigned private enterprise
   allocation [PRIVATE], for use in this specification.

8.2.  LDAP Protocol Mechanism

   The IANA has registered the LDAP Protocol Mechanism described in this
   document.

      Subject: Request for LDAP Protocol Mechanism Registration
      Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1
      Description: LDAP Content Synchronization Control
      Person & email address to contact for further information:
          Kurt Zeilenga <[e-mail]>
      Usage: Control
      Specification: RFC 4533
      Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
      Comments: none

8.3.  LDAP Result Codes

   The IANA has registered the LDAP Result Code described in this
   document.

      Subject: LDAP Result Code Registration
      Person & email address to contact for further information:
          Kurt Zeilenga <[e-mail]>
      Result Code Name: e-syncRefreshRequired (4096)
      Specification: RFC 4533
      Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
      Comments:  none

9.  Acknowledgements

   This document borrows significantly from the LDAP Client Update
   Protocol [RFC3928], a product of the IETF LDUP working group.  This
   document also benefited from Persistent Search [PSEARCH], Triggered
   Search [TSEARCH], and Directory Synchronization [DIRSYNC] works.
   This document also borrows from "Lightweight Directory Access
   Protocol (v3)" [RFC2251].




Zeilenga & Choi               Experimental                     [Page 26]

RFC 4533         LDAP Content Synchronization Operation        June 2006


10.  Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3296]   Zeilenga, K., "Named Subordinate References in
               Lightweight Directory Access Protocol (LDAP)
               Directories", RFC 3296, July 2002.

   [RFC3671]   Zeilenga, K., "Collective Attributes in the Lightweight
               Directory Access Protocol (LDAP)", RFC 3671, December
               2003.

   [RFC3672]   Zeilenga, K., "Subentries in the Lightweight Directory
               Access Protocol (LDAP)", RFC 3672, December 2003.

   [RFC3909]   Zeilenga, K., "Lightweight Directory Access Protocol
               (LDAP) Cancel Operation", RFC 3909, October 2004.

   [RFC4510]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
               (LDAP): Technical Specification Road Map", RFC 4510, June
               2006.

   [RFC4511]   Sermersheim, J., Ed., "Lightweight Directory Access
               Protocol (LDAP): The Protocol", RFC 4511, June 2006.

   [RFC4512]   Zeilenga, K., "Lightweight Directory Access Protocol
               (LDAP): Directory Information Models", RFC 4512, June
               2006.

   [RFC4530]   Zeilenga, K., "Lightweight Directory Access Protocol
               (LDAP) entryUUID Operational Attribute", RFC 4530, June
               2006.

   [UUID]      International Organization for Standardization (ISO),
               "Information technology - Open Systems Interconnection -
               Remote Procedure Call", ISO/IEC 11578:1996

   [X.501]     International Telecommunication Union - Telecommunication
               Standardization Sector, "The Directory -- Models,"
               X.501(1993) (also ISO/IEC 9594-2:1994).

   [X.680]     International Telecommunication Union - Telecommunication
               Standardization Sector, "Abstract Syntax Notation One
               (ASN.1) - Specification of Basic Notation", X.680(1997)
               (also ISO/IEC 8824-1:1998).





Zeilenga & Choi               Experimental                     [Page 27]

RFC 4533         LDAP Content Synchronization Operation        June 2006


   [X.690]     International Telecommunication Union - Telecommunication
               Standardization Sector, "Specification of ASN.1 encoding
               rules: Basic Encoding Rules (BER), Canonical Encoding
               Rules (CER), and Distinguished Encoding Rules (DER)",
               X.690(1997) (also ISO/IEC 8825-1:1998).

11.  Informative References

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

   [RFC3928]   Megginson, R., Ed., Smith, M., Natkovich, O., and J.
               Parham, "Lightweight Directory Access Protocol (LDAP)
               Client Update Protocol (LCUP)", RFC 3928, October 2004.

   [RFC4520]   Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
               Considerations for the Lightweight Directory Access
               Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

   [PRIVATE]   IANA, "Private Enterprise Numbers",
               http://www.iana.org/assignments/enterprise-numbers.

   [ASSIGN]    OpenLDAP Foundation, "OpenLDAP OID Delegations",
               http://www.openldap.org/foundation/oid-delegate.txt.

   [X.500]     International Telecommunication Union - Telecommunication
               Standardization Sector, "The Directory -- Overview of
               concepts, models and services," X.500(1993) (also ISO/IEC
               9594-1:1994).

   [X.525]     International Telecommunication Union - Telecommunication
               Standardization Sector, "The Directory: Replication",
               X.525(1993).

   [DIRSYNC]   Armijo, M., "Microsoft LDAP Control for Directory
               Synchronization", Work in