D7net
Home
Console
Upload
information
Create File
Create Folder
About
Tools
:
/
usr
/
share
/
doc
/
openldap-devel
/
drafts
/
Filename :
draft-sermersheim-ldap-csn-xx.txt
back
Copy
Network Working Group J. Sermersheim Internet-Draft Novell, Inc Expires: August 5, 2005 H. Chu Symas Corp. February 2005 The LDAP Change Sequence Number draft-sermersheim-ldap-csn-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on August 5, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 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. Sermersheim & Chu Expires August 5, 2005 [Page 1] Internet-Draft LDAP CSN February 2005 Discussion Forum Technical discussion of this document will take place on the IETF LDAP Extensions mailing list <ldapext@ietf.org>. Please send editorial comments directly to the author(s). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . 4 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. ChangeSequenceNumber Syntax . . . . . . . . . . . . . 5 3.2. UTF8String . . . . . . . . . . . . . . . . . . . . . . 6 4. Matching Rules . . . . . . . . . . . . . . . . . . . . 7 4.1. changeSequenceNumberMatch Matching Rule . . . . . . . 7 4.2. utf8CodePointMatch Matching Rule . . . . . . . . . . . 7 4.3. changeSequenceNumberOrderingMatch Matching Rule . . . 7 4.4. utf8CodePointOrderingMatch Matching Rule . . . . . . . 8 5. Attributes . . . . . . . . . . . . . . . . . . . . . . 9 5.1. entryCSN Attribute . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . 10 7. Normative References . . . . . . . . . . . . . . . . . 10 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 11 A.1. LDAP Object Identifier Registrations . . . . . . . . . 11 A.2. LDAP Descriptor Registrations . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . 16 Sermersheim & Chu Expires August 5, 2005 [Page 2] Internet-Draft LDAP CSN February 2005 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). Sermersheim & Chu Expires August 5, 2005 [Page 3] Internet-Draft LDAP CSN February 2005 2. Conventions Imperative keywords defined in [RFC2119] are used in this document, and carry the meanings described there. The General Considerations of [I-D.ietf-ldapbis-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. Sermersheim & Chu Expires August 5, 2005 [Page 4] Internet-Draft LDAP CSN February 2005 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)[X680] type corresponding to this syntax is defined as follows: ChangeSequenceNumber ::= SEQUENCE { time GeneralizedTime, timeCount INTEGER (0 .. MaxInt), replicaID UTF8String, changeCount INTEGER (0 .. MaxInt)} MaxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- GeneralizedTime is defined in [X680]. 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)[RFC3641] 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' ) Sermersheim & Chu Expires August 5, 2005 [Page 5] Internet-Draft LDAP CSN February 2005 3.2. UTF8String The UTF8String syntax is used to express a string of characters from the [ISO.10646-1.1993] 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 encoded characters themselves. The following is an LDAP syntax description [RFC2252] suitable for publication in the subschema. ( IANA-ASSIGNED-OID.2 DESC 'UTF8String' ) Sermersheim & Chu Expires August 5, 2005 [Page 6] Internet-Draft LDAP CSN February 2005 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 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: o The time component uses generalizedTimeMatch. o The timeCount and changeCount components use integerMatch. o 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. When evaluating ChangeSequenceNumber values for ordering, the components are evaluated in this order: time, timeCount, replicaID, Sermersheim & Chu Expires August 5, 2005 [Page 7] Internet-Draft LDAP CSN February 2005 changeCount. If a component evaluates to TRUE using the appropriate ordering matching rule specified below, then the rule evaluates to TRUE. Otherwise if the component evaluates to TRUE using the equality matching rule specified below, the next component is evaluated. Otherwise the changeSequenceNumberOrderingMatch rule evaluates to FALSE or Undefined as appropriate. o The time components of the two values are evaluated for ordering using GeneralizedTimeOrderingMatch, and evaluated for equality using GeneralizedTimeMatch. o The timeCount and changeCount components of the two values are evaluated for ordering using integerOrderingMatch, and evaluated for equality using integerMatch. o The replicaID components of the two values are evaluated for ordering using utf8CodePointOrderingMatch and evaluated for equality using utf8CodePointMatch. 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 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 ) Sermersheim & Chu Expires August 5, 2005 [Page 8] Internet-Draft LDAP CSN February 2005 5. Attributes 5.1. entryCSN Attribute The entryCSN operational attribute provides the CSN of the last update applied to the entry. The following is a LDAP attribute type description [RFC2252] suitable for publication in the subschema. ( IANA-ASSIGNED-OID.7 NAME entryCSN DESC 'CSN of the entry content' EQUALITY changeSequenceNumberMatch ORDERING changeSequenceNumberOrderingMatch SYNTAX IANA-ASSIGNED-OID.1 SINGLE- VALUE NO-USER-MODIFICATION USAGE directoryOperation ) Servers MAY assign a CSN to each entry upon its addition to the directory and provide the entry's CSN as the value of the entryCSN operational attribute. If the entryCSN attribute is assigned, the attribute SHOULD be updated upon every update of the entry. Sermersheim & Chu Expires August 5, 2005 [Page 9] Internet-Draft LDAP CSN February 2005 6. Security Considerations 7. Normative References [I-D.ietf-ldapbis-syntaxes] Legg, S., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", draft-ietf-ldapbis-syntaxes-11 (work in progress), June 2005. [ISO.10646-1.1993] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO Standard 10646-1, May 1993. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002. [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 Types", RFC 3641, October 2003. [UTF-8] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2, October 1996. [Unicode] The Unicode Consortium, "The Unicode Standard", 2004. [X680] International Telecommunications Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, July 2002. Sermersheim & Chu Expires August 5, 2005 [Page 10] Internet-Draft LDAP CSN February 2005 Appendix A. IANA Considerations Registration of the following values is requested [RFC3383]. A.1. LDAP Object Identifier Registrations It is requested that IANA register upon Standards Action an LDAP Object Identifier in identifying the protocol elements defined in this technical specification. The following registration template is provided: Subject: Request for LDAP OID Registration Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Specification: RFCXXXX Author/Change Controller: IESG Comments: Seven delegations will be made under the assigned OID: IANA-ASSIGNED-OID.1 ChangeSequenceNumber: LDAP Syntax IANA-ASSIGNED-OID.2 UTF8String: LDAP Syntax IANA-ASSIGNED-OID.3 changeSequenceNumberMatch: LDAP Matching Rule IANA-ASSIGNED-OID.4 utf8CodePointMatch: LDAP Matching Rule IANA-ASSIGNED-OID.5 changeSequenceNumberOrderingMatch: LDAP Matching Rule IANA-ASSIGNED-OID.6 utf8CodePointOrderingMatch: LDAP Matching Rule IANA-ASSIGNED-OID.7 entryCSN: LDAP Attribute Type A.2. LDAP Descriptor Registrations It is requested that IANA register upon Standards Action the LDAP descriptors described in this document. The following registration templates are given: Sermersheim & Chu Expires August 5, 2005 [Page 11] Internet-Draft LDAP CSN February 2005 Subject: Request for LDAP Descriptor Registration Descriptor (short name): ChangeSequenceNumber Object Identifier: IANA-ASSIGNED-OID.1 Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: other Specification: RFCXXXX Author/Change Controller: IESG Comments: LDAP Syntax Subject: Request for LDAP Descriptor Registration Descriptor (short name): UTF8String Object Identifier: IANA-ASSIGNED-OID.2 Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: other Specification: RFCXXXX Author/Change Controller: IESG Comments: LDAP Syntax Subject: Request for LDAP Descriptor Registration Descriptor (short name): changeSequenceNumberMatch Object Identifier: IANA-ASSIGNED-OID.3 Person & email address to contact for further information: Sermersheim & Chu Expires August 5, 2005 [Page 12] Internet-Draft LDAP CSN February 2005 Jim Sermersheim jimse@novell.com Usage: other Specification: RFCXXXX Author/Change Controller: IESG Comments: LDAP Matching Rule Subject: Request for LDAP Descriptor Registration Descriptor (short name): utf8CodePointMatch Object Identifier: IANA-ASSIGNED-OID.4 Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: other Specification: RFCXXXX Author/Change Controller: IESG Comments: LDAP Matching Rule Subject: Request for LDAP Descriptor Registration Descriptor (short name): changeSequenceNumberOrderingMatch Object Identifier: IANA-ASSIGNED-OID.5 Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: other Specification: RFCXXXX Sermersheim & Chu Expires August 5, 2005 [Page 13] Internet-Draft LDAP CSN February 2005 Author/Change Controller: IESG Comments: LDAP Matching Rule Subject: Request for LDAP Descriptor Registration Descriptor (short name): utf8CodePointOrderingMatch Object Identifier: IANA-ASSIGNED-OID.6 Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: other Specification: RFCXXXX Author/Change Controller: IESG Comments: LDAP Matching Rule Subject: Request for LDAP Descriptor Registration Descriptor (short name): entryCSN Object Identifier: IANA-ASSIGNED-OID.7 Person & email address to contact for further information: Jim Sermersheim jimse@novell.com Usage: Attribute Type Specification: RFCXXXX Author/Change Controller: IESG Comments: LDAP Attribute Type Sermersheim & Chu Expires August 5, 2005 [Page 14] Internet-Draft LDAP CSN February 2005 Authors' Addresses Jim Sermersheim Novell, Inc 1800 South Novell Place Provo, Utah 84606 USA Phone: +1 801 861-3088 Email: jimse@novell.com Howard Chu Symas Corp. 18740 Oxnard Street, Suite 313A Tarzana, California 91356 USA Phone: +1 818 757-7087 Email: hyc@symas.com Sermersheim & Chu Expires August 5, 2005 [Page 15] Internet-Draft LDAP CSN February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sermersheim & Chu Expires August 5, 2005 [Page 16]