git.sur5r.net Git - openldap/blob - doc/drafts/draft-sermersheim-ldap-csn-xx.txt

   1
   2 Internet-Draft                                  Editor:  J. Sermersheim
   3 Intended Category: Experimental                             Novell, Inc
   4 Document: draft-sermersheim-ldap-csn-00.txt                    Dec 2003
   5
   6
   7
   8          The LDAP Change Sequence Number Syntax and Matching Rules
   9
  10
  11 Status of this Memo
  12
  13    This document is an Internet-Draft and is in full conformance with
  14    all provisions of Section 10 of RFC2026.
  15
  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."
  23
  24    The list of current Internet-Drafts can be accessed at
  25    http://www.ietf.org/ietf/1id-abstracts.txt
  26
  27    The list of Internet-Draft Shadow Directories can be accessed at
  28    http://www.ietf.org/shadow.html.
  29
  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
  34    <jimse@novell.com>.
  35
  36
  37 Abstract
  38
  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.
  45
  46
  47 Table of Contents
  48
  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
  56
  57 Sermersheim       Internet-Draft - Expires Jun 2004               Page 1 \f
  58                         LDAP Change Sequence Number
  59
  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
  69
  70
  71 1. Introduction
  72
  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
  82    the other element(s).
  83
  84
  85 2. Conventions
  86
  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].
  90
  91    The General Considerations in Section 3.1 of [Syntaxes] apply to the
  92    syntax definition in this document.
  93
  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.
  97
  98
  99 3. Syntaxes
 100
 101 3.1 ChangeSequenceNumber Syntax
 102
 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.
 108
 109    The Abstract Syntax Notation One ([ASN.1]) type corresponding to this
 110    syntax is defined as follows:
 111
 112    ChangeSequenceNumber ::= SEQUENCE {
 113         time                    GeneralizedTime,
 114
 115 Sermersheim       Internet-Draft - Expires Jun 2004               Page 2 \f
 116                         LDAP Change Sequence Number
 117
 118         timeCount               INTEGER (0 .. MaxInt),
 119         replicaID               UTF8String,
 120         changeCount             INTEGER (0 .. MaxInt)}
 121
 122    MaxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
 123
 124    GeneralizedTime is defined in [ASN.1]. Local time without a
 125    differential SHALL NOT be used.
 126
 127    UTF8String is defined below.
 128
 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.
 131
 132    Example:
 133         { time "196701160315-0700",
 134           timeCount 0,
 135           replicaID "DSA666",
 136           changeCount 1 }
 137
 138    The following is an LDAP syntax description [RFC2252] suitable for
 139    publication in the subschema.
 140
 141         ( IANA-ASSIGNED-OID.1 DESC 'ChangeSequenceNumber' )
 142
 143
 144 3.2 UTF8String
 145
 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.
 152
 153         UTF8String::= OCTET STRING  -- UTF-8 encoded,
 154                                     -- [ISO10646] characters
 155
 156    The LDAP-specific encoding of a value of this syntax are the UTF-8
 157    characters themselves.
 158
 159    The following is an LDAP syntax description [RFC2252] suitable for
 160    publication in the subschema.
 161
 162         ( IANA-ASSIGNED-OID.2 DESC 'UTF8String')
 163
 164
 165 4. Matching Rules
 166
 167
 168 4.1 changeSequenceNumberMatch Matching Rule
 169
 170    The changeSequenceNumberMatch rule compares an assertion value of the
 171    ChangeSequenceNumber syntax to a value of a syntax (e.g the
 172
 173 Sermersheim       Internet-Draft - Expires Jun 2004               Page 3 \f
 174                         LDAP Change Sequence Number
 175
 176    ChangeSequenceNumber syntax) whose corresponding ASN.1 type is
 177    ChangeSequenceNumber.
 178
 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.
 184
 185    The following is a LDAP matching rule description [RFC2252] suitable
 186    for publication in the subschema.
 187
 188         ( IANA-ASSIGNED-OID.3 NAME changeSequenceNumberMatch
 189           SYNTAX IANA-ASSIGNED-OID.1 )
 190
 191
 192 4.2 utf8CodePointMatch Matching Rule
 193
 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
 198    characters is equal.
 199
 200    The following is a LDAP matching rule description [RFC2252] suitable
 201    for publication in the subschema.
 202
 203         ( IANA-ASSIGNED-OID.4 NAME utf8CodePointMatch
 204           SYNTAX IANA-ASSIGNED-OID.2 )
 205
 206
 207 4.3 changeSequenceNumberOrderingMatch Matching Rule
 208
 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.
 214
 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.
 220
 221    The following is a LDAP matching rule description [RFC2252] suitable
 222    for publication in the subschema.
 223
 224         ( IANA-ASSIGNED-OID.5 NAME changeSequenceNumberOrderingMatch
 225           SYNTAX SYNTAX IANA-ASSIGNED-OID.1 )
 226
 227
 228 4.4 utf8CodePointOrderingMatch Matching Rule
 229
 230
 231 Sermersheim       Internet-Draft - Expires Jun 2004               Page 4 \f
 232                         LDAP Change Sequence Number
 233
 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
 237    UTF8String.
 238
 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.
 243
 244    The following is a LDAP matching rule description [RFC2252] suitable
 245    for publication in the subschema.
 246
 247         ( IANA-ASSIGNED-OID.6 NAME utf8CodePointOrderingMatch
 248           SYNTAX IANA-ASSIGNED-OID.2 )
 249
 250
 251 5. Security Considerations
 252
 253
 254 6. Acknowledgements
 255
 256
 257 7. Normative References
 258
 259    [ABNF]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
 260              Specifications: ABNF", RFC 2234, November 1997.
 261
 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"
 265
 266    [Keyword] Bradner, S., "Key words for use in RFCs to Indicate
 267              Requirement Levels", RFC 2119, March 1997.
 268
 269    [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching
 270              Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in
 271              progress).
 272
 273    [Models]  Zeilenga, K., "LDAP: Directory Information Models", draft-
 274              ietf-ldapbis-models-xx.txt (a work in progress).
 275
 276    [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
 277              Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
 278              : 1993.
 279
 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/).
 287
 288
 289 Sermersheim       Internet-Draft - Expires Jun 2004               Page 5 \f
 290                         LDAP Change Sequence Number
 291
 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.
 295
 296
 297 8. Informative References
 298
 299 9. IANA Considerations
 300
 301 10. Editor's Address
 302
 303    Jim Sermersheim
 304    Novell, Inc.
 305    1800 South Novell Place
 306    Provo, Utah 84606, USA
 307    jimse@novell.com
 308    +1 801 861-3088
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347 Sermersheim       Internet-Draft - Expires Jun 2004               Page 6 \f
 348                         LDAP Change Sequence Number
 349
 350 Intellectual Property Rights
 351
 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.
 365
 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
 370    Director.
 371
 372
 373 Full Copyright Statement
 374
 375    Copyright (C) The Internet Society (2003). All Rights Reserved.
 376
 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
 389    English.
 390
 391    The limited permissions granted above are perpetual and will not be
 392    revoked by the Internet Society or its successors or assigns.
 393
 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.
 400
 401
 402
 403
 404
 405 Sermersheim       Internet-Draft - Expires Jun 2004               Page 7 \f
 406