2 Internet-Draft Editor: J. Sermersheim
3 Intended Category: Experimental Novell, Inc
4 Document: draft-sermersheim-ldap-csn-00.txt Dec 2003
8 The LDAP Change Sequence Number Syntax and Matching Rules
13 This document is an Internet-Draft and is in full conformance with
14 all provisions of Section 10 of RFC2026.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that other
18 groups may also distribute working documents as Internet-Drafts.
19 Internet-Drafts are draft documents valid for a maximum of six months
20 and may be updated, replaced, or obsoleted by other documents at any
21 time. It is inappropriate to use Internet-Drafts as reference
22 material or to cite them other than as "work in progress."
24 The list of current Internet-Drafts can be accessed at
25 http://www.ietf.org/ietf/1id-abstracts.txt
27 The list of Internet-Draft Shadow Directories can be accessed at
28 http://www.ietf.org/shadow.html.
30 Distribution of this memo is unlimited. Technical discussion of this
31 document will take place on the IETF LDAP
32 Duplication/Replication/Update Protocols (ldup) mailing list <ietf-
33 ldup@imc.org>. Please send editorial comments directly to the editor
39 This document defines a syntax schema element for the Lightweight
40 Directory Access Protocol ([LDAP]) which is used to hold a Change
41 Sequence Number (CSN). In general, a change sequence number
42 represents the place and time that a directory entity was changed. It
43 may be used by various attributes for various LDAP replication, and
44 synchronization applications.
49 1. Introduction....................................................2
50 2. Conventions.....................................................2
51 3. Syntaxes........................................................2
52 3.1 ChangeSequenceNumber Syntax....................................2
53 3.2 UTF8String.....................................................3
54 4. Matching Rules..................................................3
55 4.1 changeSequenceNumberMatch Matching Rule........................3
57 Sermersheim Internet-Draft - Expires Jun 2004 Page 1
\f
58 LDAP Change Sequence Number
60 4.2 utf8CodePointMatch Matching Rule...............................4
61 4.3 changeSequenceNumberOrderingMatch Matching Rule................4
62 4.4 utf8CodePointOrderingMatch Matching Rule.......................4
63 5. Security Considerations.........................................5
64 6. Acknowledgements................................................5
65 7. Normative References............................................5
66 8. Informative References..........................................6
67 9. IANA Considerations.............................................6
68 10. Editor's Address...............................................6
73 A number of technologies have been documented, implemented and
74 experimented with which in one way or another seek to replicate, or
75 synchronize directory data. A common need among these technologies is
76 to determine which of two copies of an element represents the latest
77 or most authoritative data. Part of meeting this need involves
78 associating a change sequence number to an element copy at the time
79 of an update to that element. When replication or synchronization
80 occurs, the change sequence numbers associated with directory
81 elements can be used to decide which element's data will be copied to
87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
88 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
89 to be interpreted as described in [Keyword].
91 The General Considerations in Section 3.1 of [Syntaxes] apply to the
92 syntax definition in this document.
94 The terms "directory element" and "element" refer to data held in a
95 directory and may apply to an attribute value, attribute, entry, or
96 any other identifiable directory entity.
101 3.1 ChangeSequenceNumber Syntax
103 A value of the ChangeSequenceNumber syntax is the time of a change
104 along with a replicaID which represents the Directory System Agent
105 (DSA) holding the element when it was changed. There are also two
106 sequence numbers used to disambiguate directory entities that are
107 changed at the same time and place.
109 The Abstract Syntax Notation One ([ASN.1]) type corresponding to this
110 syntax is defined as follows:
112 ChangeSequenceNumber ::= SEQUENCE {
113 time GeneralizedTime,
115 Sermersheim Internet-Draft - Expires Jun 2004 Page 2
\f
116 LDAP Change Sequence Number
118 timeCount INTEGER (0 .. MaxInt),
119 replicaID UTF8String,
120 changeCount INTEGER (0 .. MaxInt)}
122 MaxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
124 GeneralizedTime is defined in [ASN.1]. Local time without a
125 differential SHALL NOT be used.
127 UTF8String is defined below.
129 The LDAP-specific encoding of a value of this syntax is the Generic
130 String Encoding Rules ([GSER]) encoding of the ASN.1 type.
133 { time "196701160315-0700",
138 The following is an LDAP syntax description [RFC2252] suitable for
139 publication in the subschema.
141 ( IANA-ASSIGNED-OID.1 DESC 'ChangeSequenceNumber' )
146 The UTF8String syntax is used to express a string of characters from
147 the [ISO10646] character set (a superset of [Unicode]), encoded
148 following the [UTF-8] algorithm. Note that Unicode characters U+0000
149 through U+007F are the same as ASCII 0 through 127, respectively, and
150 have the same single octet UTF-8 encoding. Other Unicode characters
151 have a multiple octet UTF-8 encoding.
153 UTF8String::= OCTET STRING -- UTF-8 encoded,
154 -- [ISO10646] characters
156 The LDAP-specific encoding of a value of this syntax are the UTF-8
157 characters themselves.
159 The following is an LDAP syntax description [RFC2252] suitable for
160 publication in the subschema.
162 ( IANA-ASSIGNED-OID.2 DESC 'UTF8String')
168 4.1 changeSequenceNumberMatch Matching Rule
170 The changeSequenceNumberMatch rule compares an assertion value of the
171 ChangeSequenceNumber syntax to a value of a syntax (e.g the
173 Sermersheim Internet-Draft - Expires Jun 2004 Page 3
\f
174 LDAP Change Sequence Number
176 ChangeSequenceNumber syntax) whose corresponding ASN.1 type is
177 ChangeSequenceNumber.
179 The rule evaluates to TRUE if and only if each of the components of
180 the two values evaluate to true using the following rules:
181 - The time component uses generalizedTimeMatch.
182 - The timeCount and changeCount components use integerMatch.
183 - The replicaID component uses utf8CodePointMatch.
185 The following is a LDAP matching rule description [RFC2252] suitable
186 for publication in the subschema.
188 ( IANA-ASSIGNED-OID.3 NAME changeSequenceNumberMatch
189 SYNTAX IANA-ASSIGNED-OID.1 )
192 4.2 utf8CodePointMatch Matching Rule
194 The utf8CodePointMatch rule compares an assertion value of the
195 UTF8String syntax to a value of a syntax (e.g the UTF8String syntax)
196 whose corresponding ASN.1 type is UTF8String. The rule evaluates to
197 TRUE if and only if the code points [Unicode] of each of the
200 The following is a LDAP matching rule description [RFC2252] suitable
201 for publication in the subschema.
203 ( IANA-ASSIGNED-OID.4 NAME utf8CodePointMatch
204 SYNTAX IANA-ASSIGNED-OID.2 )
207 4.3 changeSequenceNumberOrderingMatch Matching Rule
209 The changeSequenceNumberOrderingMatch rule compares the
210 ChangeSequenceNumber ordering of an assertion value of the
211 ChangeSequenceNumber syntax to a value of a syntax (e.g the
212 ChangeSequenceNumber syntax) whose corresponding ASN.1 type is
213 ChangeSequenceNumber.
215 The rule evaluates to TRUE if and only if each of the components of
216 the two values evaluate to true using the following rules:
217 - The time component uses GeneralizedTimeOrderingMatch.
218 - The timeCount and changeCount components use integerOrderingMatch.
219 - The replicaID component uses utf8CodePointOrderingMatch.
221 The following is a LDAP matching rule description [RFC2252] suitable
222 for publication in the subschema.
224 ( IANA-ASSIGNED-OID.5 NAME changeSequenceNumberOrderingMatch
225 SYNTAX SYNTAX IANA-ASSIGNED-OID.1 )
228 4.4 utf8CodePointOrderingMatch Matching Rule
231 Sermersheim Internet-Draft - Expires Jun 2004 Page 4
\f
232 LDAP Change Sequence Number
234 The utf8CodePointOrderingMatch rule compares the ordering of an
235 assertion value of the UTF8String syntax to a stored value of a
236 syntax (e.g the UTF8String syntax) whose corresponding ASN.1 type is
239 The rule evaluates to TRUE if, and only if, in the code point
240 collation order, the stored value character string appears earlier
241 than the assertion value character string, i.e., the stored value is
242 "less than" the assertion value.
244 The following is a LDAP matching rule description [RFC2252] suitable
245 for publication in the subschema.
247 ( IANA-ASSIGNED-OID.6 NAME utf8CodePointOrderingMatch
248 SYNTAX IANA-ASSIGNED-OID.2 )
251 5. Security Considerations
257 7. Normative References
259 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
260 Specifications: ABNF", RFC 2234, November 1997.
262 [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
263 "Information Technology - Abstract Syntax Notation One
264 (ASN.1): Specification of basic notation"
266 [Keyword] Bradner, S., "Key words for use in RFCs to Indicate
267 Requirement Levels", RFC 2119, March 1997.
269 [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching
270 Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in
273 [Models] Zeilenga, K., "LDAP: Directory Information Models", draft-
274 ietf-ldapbis-models-xx.txt (a work in progress).
276 [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
277 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
280 [Unicode] The Unicode Consortium, "The Unicode Standard, Version
281 3.2.0" is defined by "The Unicode Standard, Version 3.0"
282 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
283 as amended by the "Unicode Standard Annex #27: Unicode
284 3.1" (http://www.unicode.org/reports/tr27/) and by the
285 "Unicode Standard Annex #28: Unicode 3.2"
286 (http://www.unicode.org/reports/tr28/).
289 Sermersheim Internet-Draft - Expires Jun 2004 Page 5
\f
290 LDAP Change Sequence Number
292 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
293 "Lightweight Directory Access Protocol (v3): Attribute
294 Syntax Definitions", RFC 2252, December 1997.
297 8. Informative References
299 9. IANA Considerations
305 1800 South Novell Place
306 Provo, Utah 84606, USA
347 Sermersheim Internet-Draft - Expires Jun 2004 Page 6
\f
348 LDAP Change Sequence Number
350 Intellectual Property Rights
352 The IETF takes no position regarding the validity or scope of any
353 intellectual property or other rights that might be claimed to
354 pertain to the implementation or use of the technology described in
355 this document or the extent to which any license under such rights
356 might or might not be available; neither does it represent that it
357 has made any effort to identify any such rights. Information on the
358 IETF's procedures with respect to rights in standards-track and
359 standards-related documentation can be found in BCP-11. Copies of
360 claims of rights made available for publication and any assurances of
361 licenses to be made available, or the result of an attempt made to
362 obtain a general license or permission for the use of such
363 proprietary rights by implementors or users of this specification can
364 be obtained from the IETF Secretariat.
366 The IETF invites any interested party to bring to its attention any
367 copyrights, patents or patent applications, or other proprietary
368 rights which may cover technology that may be required to practice
369 this standard. Please address the information to the IETF Executive
373 Full Copyright Statement
375 Copyright (C) The Internet Society (2003). All Rights Reserved.
377 This document and translations of it may be copied and furnished to
378 others, and derivative works that comment on or otherwise explain it
379 or assist in its implementation may be prepared, copied, published
380 and distributed, in whole or in part, without restriction of any
381 kind, provided that the above copyright notice and this paragraph are
382 included on all such copies and derivative works. However, this
383 document itself may not be modified in any way, such as by removing
384 the copyright notice or references to the Internet Society or other
385 Internet organizations, except as needed for the purpose of
386 developing Internet standards in which case the procedures for
387 copyrights defined in the Internet Standards process must be
388 followed, or as required to translate it into languages other than
391 The limited permissions granted above are perpetual and will not be
392 revoked by the Internet Society or its successors or assigns.
394 This document and the information contained herein is provided on an
395 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
396 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
397 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
398 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
399 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
405 Sermersheim Internet-Draft - Expires Jun 2004 Page 7
\f