Internet-Draft Editor: J. Sermersheim Intended Category: Experimental Novell, Inc Document: draft-sermersheim-ldap-csn-00.txt Dec 2003 The LDAP Change Sequence Number Syntax and Matching Rules Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Technical discussion of this document will take place on the IETF LDAP Duplication/Replication/Update Protocols (ldup) mailing list . Please send editorial comments directly to the editor . Abstract This document defines a syntax schema element for the Lightweight Directory Access Protocol ([LDAP]) which is used to hold a Change Sequence Number (CSN). In general, a change sequence number represents the place and time that a directory entity was changed. It may be used by various attributes for various LDAP replication, and synchronization applications. Table of Contents 1. Introduction....................................................2 2. Conventions.....................................................2 3. Syntaxes........................................................2 3.1 ChangeSequenceNumber Syntax....................................2 3.2 UTF8String.....................................................3 4. Matching Rules..................................................3 4.1 changeSequenceNumberMatch Matching Rule........................3 Sermersheim Internet-Draft - Expires Jun 2004 Page 1 LDAP Change Sequence Number 4.2 utf8CodePointMatch Matching Rule...............................4 4.3 changeSequenceNumberOrderingMatch Matching Rule................4 4.4 utf8CodePointOrderingMatch Matching Rule.......................4 5. Security Considerations.........................................5 6. Acknowledgements................................................5 7. Normative References............................................5 8. Informative References..........................................6 9. IANA Considerations.............................................6 10. Editor's Address...............................................6 1. Introduction A number of technologies have been documented, implemented and experimented with which in one way or another seek to replicate, or synchronize directory data. A common need among these technologies is to determine which of two copies of an element represents the latest or most authoritative data. Part of meeting this need involves associating a change sequence number to an element copy at the time of an update to that element. When replication or synchronization occurs, the change sequence numbers associated with directory elements can be used to decide which element's data will be copied to the other element(s). 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [Keyword]. The General Considerations in Section 3.1 of [Syntaxes] apply to the syntax definition in this document. The terms "directory element" and "element" refer to data held in a directory and may apply to an attribute value, attribute, entry, or any other identifiable directory entity. 3. Syntaxes 3.1 ChangeSequenceNumber Syntax A value of the ChangeSequenceNumber syntax is the time of a change along with a replicaID which represents the Directory System Agent (DSA) holding the element when it was changed. There are also two sequence numbers used to disambiguate directory entities that are changed at the same time and place. The Abstract Syntax Notation One ([ASN.1]) type corresponding to this syntax is defined as follows: ChangeSequenceNumber ::= SEQUENCE { time GeneralizedTime, Sermersheim Internet-Draft - Expires Jun 2004 Page 2 LDAP Change Sequence Number timeCount INTEGER (0 .. MaxInt), replicaID UTF8String, changeCount INTEGER (0 .. MaxInt)} MaxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- GeneralizedTime is defined in [ASN.1]. Local time without a differential SHALL NOT be used. UTF8String is defined below. The LDAP-specific encoding of a value of this syntax is the Generic String Encoding Rules ([GSER]) encoding of the ASN.1 type. Example: { time "196701160315-0700", timeCount 0, replicaID "DSA666", changeCount 1 } The following is an LDAP syntax description [RFC2252] suitable for publication in the subschema. ( IANA-ASSIGNED-OID.1 DESC 'ChangeSequenceNumber' ) 3.2 UTF8String The UTF8String syntax is used to express a string of characters from the [ISO10646] character set (a superset of [Unicode]), encoded following the [UTF-8] algorithm. Note that Unicode characters U+0000 through U+007F are the same as ASCII 0 through 127, respectively, and have the same single octet UTF-8 encoding. Other Unicode characters have a multiple octet UTF-8 encoding. UTF8String::= OCTET STRING -- UTF-8 encoded, -- [ISO10646] characters The LDAP-specific encoding of a value of this syntax are the UTF-8 characters themselves. The following is an LDAP syntax description [RFC2252] suitable for publication in the subschema. ( IANA-ASSIGNED-OID.2 DESC 'UTF8String') 4. Matching Rules 4.1 changeSequenceNumberMatch Matching Rule The changeSequenceNumberMatch rule compares an assertion value of the ChangeSequenceNumber syntax to a value of a syntax (e.g the Sermersheim Internet-Draft - Expires Jun 2004 Page 3 LDAP Change Sequence Number ChangeSequenceNumber syntax) whose corresponding ASN.1 type is ChangeSequenceNumber. The rule evaluates to TRUE if and only if each of the components of the two values evaluate to true using the following rules: - The time component uses generalizedTimeMatch. - The timeCount and changeCount components use integerMatch. - The replicaID component uses utf8CodePointMatch. The following is a LDAP matching rule description [RFC2252] suitable for publication in the subschema. ( IANA-ASSIGNED-OID.3 NAME changeSequenceNumberMatch SYNTAX IANA-ASSIGNED-OID.1 ) 4.2 utf8CodePointMatch Matching Rule The utf8CodePointMatch rule compares an assertion value of the UTF8String syntax to a value of a syntax (e.g the UTF8String syntax) whose corresponding ASN.1 type is UTF8String. The rule evaluates to TRUE if and only if the code points [Unicode] of each of the characters is equal. The following is a LDAP matching rule description [RFC2252] suitable for publication in the subschema. ( IANA-ASSIGNED-OID.4 NAME utf8CodePointMatch SYNTAX IANA-ASSIGNED-OID.2 ) 4.3 changeSequenceNumberOrderingMatch Matching Rule The changeSequenceNumberOrderingMatch rule compares the ChangeSequenceNumber ordering of an assertion value of the ChangeSequenceNumber syntax to a value of a syntax (e.g the ChangeSequenceNumber syntax) whose corresponding ASN.1 type is ChangeSequenceNumber. The rule evaluates to TRUE if and only if each of the components of the two values evaluate to true using the following rules: - The time component uses GeneralizedTimeOrderingMatch. - The timeCount and changeCount components use integerOrderingMatch. - The replicaID component uses utf8CodePointOrderingMatch. The following is a LDAP matching rule description [RFC2252] suitable for publication in the subschema. ( IANA-ASSIGNED-OID.5 NAME changeSequenceNumberOrderingMatch SYNTAX SYNTAX IANA-ASSIGNED-OID.1 ) 4.4 utf8CodePointOrderingMatch Matching Rule Sermersheim Internet-Draft - Expires Jun 2004 Page 4 LDAP Change Sequence Number The utf8CodePointOrderingMatch rule compares the ordering of an assertion value of the UTF8String syntax to a stored value of a syntax (e.g the UTF8String syntax) whose corresponding ASN.1 type is UTF8String. The rule evaluates to TRUE if, and only if, in the code point collation order, the stored value character string appears earlier than the assertion value character string, i.e., the stored value is "less than" the assertion value. The following is a LDAP matching rule description [RFC2252] suitable for publication in the subschema. ( IANA-ASSIGNED-OID.6 NAME utf8CodePointOrderingMatch SYNTAX IANA-ASSIGNED-OID.2 ) 5. Security Considerations 6. Acknowledgements 7. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002 "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation" [Keyword] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in progress). [Models] Zeilenga, K., "LDAP: Directory Information Models", draft- ietf-ldapbis-models-xx.txt (a work in progress). [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 : 1993. [Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). Sermersheim Internet-Draft - Expires Jun 2004 Page 5 LDAP Change Sequence Number [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. 8. Informative References 9. IANA Considerations 10. Editor's Address Jim Sermersheim Novell, Inc. 1800 South Novell Place Provo, Utah 84606, USA jimse@novell.com +1 801 861-3088 Sermersheim Internet-Draft - Expires Jun 2004 Page 6 LDAP Change Sequence Number Intellectual Property Rights The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). 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. Sermersheim Internet-Draft - Expires Jun 2004 Page 7