openldap/doc/drafts/draft-sermersheim-ldap-csn-xx.txt

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 <ietf-
   ldup@imc.org>. Please send editorial comments directly to the editor 
   <jimse@novell.com>. 
    
    
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