From: Kurt Zeilenga Date: Mon, 29 Dec 2003 23:39:55 +0000 (+0000) Subject: Add new CSN draft X-Git-Tag: OPENLDAP_REL_ENG_2_1_MP~83 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=f03c29257ffefa4f5efca1b1d53f15cfc40f5d31;p=openldap Add new CSN draft Remove GSER drafts (now available as RFCs) --- diff --git a/doc/drafts/draft-legg-ldap-gser-abnf-xx.txt b/doc/drafts/draft-legg-ldap-gser-abnf-xx.txt deleted file mode 100644 index 710020fc51..0000000000 --- a/doc/drafts/draft-legg-ldap-gser-abnf-xx.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -INTERNET-DRAFT S. Legg -draft-legg-ldap-gser-abnf-06.txt Adacel Technologies -Intended Category: Informational May 7, 2003 - - - Common Elements of GSER Encodings - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - 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 document is unlimited. Comments should be sent - to the LDAPEXT working group mailing list - or to the author. - - This Internet-Draft expires on 7 November 2003. - - -Abstract - - The Generic String Encoding Rules (GSER) describe a human readable - text encoding for an ASN.1 value of any ASN.1 type. Specifications - making use of GSER may wish to provide an equivalent ABNF description - of the GSER encoding for a particular ASN.1 type as a convenience for - implementors. This document supports such specifications by - providing equivalent ABNF for the GSER encodings for ASN.1 types - commonly occuring in Lightweight Directory Access Protocol (LDAP) - syntaxes. - - - -Legg Expires 7 November 2003 [Page 1] - -INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003 - - -1. Table of Contents - - 1. Table of Contents ............................................. 2 - 2. Introduction .................................................. 2 - 3. Conventions ................................................... 2 - 4. Separators .................................................... 2 - 5. ASN.1 Built-in Types .......................................... 3 - 6. ASN.1 Restricted String Types ................................. 7 - 7. Directory ASN.1 Types ......................................... 9 - 8. Security Considerations ....................................... 10 - 9. Normative References .......................................... 11 - 10. Informative References ....................................... 11 - 11. Copyright Notice ............................................. 11 - 12. Author's Address ............................................. 12 - - -2. Introduction - - The Generic String Encoding Rules (GSER) defined in [7] define a - human readable text encoding, based on ASN.1 [8] value notation, for - an ASN.1 value of any ASN.1 type. Specifications making use of GSER - may wish to provide a non-normative equivalent ABNF [3] description - of the GSER encoding for a particular ASN.1 type as a convenience for - implementors unfamiliar with ASN.1. This document supports such - specifications by providing equivalent ABNF for the GSER encodings - for ASN.1 types commonly occuring in LDAP [9] or X.500 [10] attribute - and assertion syntaxes, as well as equivalent ABNF for the GSER - encodings for the ASN.1 built-in types. - - The ABNF given in this document does not replace or alter GSER in any - way. If there is a discrepancy between the ABNF specified here and - the encoding defined by GSER in [7] then [7] is to be taken as - definitive. - - -3. Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - - -4. Separators - - Certain separators are commonly used in constructing equivalent ABNF - for SET and SEQUENCE types. - - sp = *%x20 ; zero, one or more space characters - - - -Legg Expires 7 November 2003 [Page 2] - -INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003 - - - msp = 1*%x20 ; one or more space characters - - sep = [ "," ] - - The rule is used in the ABNF description of the encoding for - ASN.1 SET or SEQUENCE types where all the components are either - OPTIONAL or DEFAULT. It encodes to an empty string if and only if - the immediately preceding character in the encoding is "{", i.e. it - is only empty for the first optional component actually present in - the SET or SEQUENCE value being encoded. - - -5. ASN.1 Built-in Types - - This section describes the GSER encoding of values of the ASN.1 - built-in types, except for the restricted character string types. - - The rule describes the GSER encoding of values of the - BIT STRING type without a named bit list. - - BIT-STRING = bstring / hstring - - If the number of bits in a BIT STRING value is a multiple of four the - form of MAY be used. The form of - is used otherwise. The rule encodes each bit - as the character "0" or "1" in order from the first bit to the last - bit. The rule encodes each group of four bits as a - hexadecimal number where the first bit is the most significant. An - odd number of hexadecimal digits is permitted. - - hstring = squote *hexadecimal-digit squote %x48 ; '...'H - hexadecimal-digit = %x30-39 / ; "0" to "9" - %x41-46 ; "A" to "F" - - bstring = squote *binary-digit squote %x42 ; '...'B - binary-digit = "0" / "1" - - squote = %x27 ; ' (single quote) - - The rule describes the GSER encoding of values of the - BOOLEAN type. - - BOOLEAN = %x54.52.55.45 / ; "TRUE" - %x46.41.4C.53.45 ; "FALSE" - - The rule describes the GSER encoding of values of - the associated type for the unrestricted CHARACTER STRING type. - - - - -Legg Expires 7 November 2003 [Page 3] - -INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003 - - - CHARACTER-STRING = "{" sp id-identification msp Identification "," - sp id-data-value msp OCTET-STRING - sp "}" - - id-identification = %x69.64.65.6E.74.69.66.69.63.61.74.69.6F.6E - ; "identification" - id-data-value = %x64.61.74.61.2D.76.61.6C.75.65 ; "data-value" - - Identification = ( id-syntaxes ":" Syntaxes ) / - ( id-syntax ":" OBJECT-IDENTIFIER ) / - ( id-presentation-context-id ":" INTEGER ) / - ( id-context-negotiation ":" - ContextNegotiation ) / - ( id-transfer-syntax ":" OBJECT-IDENTIFIER ) / - ( id-fixed ":" NULL ) - - id-syntaxes = %x73.79.6E.74.61.78.65.73 - ; "syntaxes" - id-syntax = %x73.79.6E.74.61.78 ; "syntax" - id-presentation-context-id = %x70.72.65.73.65.6E.74.61.74.69.6F.6E - %x2D.63.6F.6E.74.65.78.74.2D.69.64 - ; "presentation-context-id" - id-context-negotiation = %x63.6F.6E.74.65.78.74.2D.6E.65.67.6F - %x74.69.61.74.69.6F.6E - ; "context-negotiation" - id-transfer-syntax = %x74.72.61.6E.73.66.65.72.2D.73.79.6E - %x74.61.78 ; "transfer-syntax" - id-fixed = %x66.69.78.65.64 ; "fixed" - - Syntaxes = "{" sp id-abstract msp OBJECT-IDENTIFIER "," - sp id-transfer msp OBJECT-IDENTIFIER - sp "}" - id-abstract = %x61.62.73.74.72.61.63.74 ; "abstract" - id-transfer = %x74.72.61.6E.73.66.65.72 ; "transfer" - - ContextNegotiation = "{" sp id-presentation-context-id msp - INTEGER "," - sp id-transfer-syntax msp - OBJECT-IDENTIFIER - sp "}" - - The rule describes the GSER encoding of values of the - INTEGER type without a named number list. The rule - describes the GSER encoding of values of the constrained type INTEGER - (0..MAX). The rule describes the GSER encoding of - values of the constrained type INTEGER (1..MAX). - - INTEGER = "0" / positive-number / ("-" positive-number) - - - -Legg Expires 7 November 2003 [Page 4] - -INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003 - - - INTEGER-0-MAX = "0" / positive-number - INTEGER-1-MAX = positive-number - positive-number = non-zero-digit *decimal-digit - decimal-digit = %x30-39 ; "0" to "9" - non-zero-digit = %x31-39 ; "1" to "9" - - The rule describes the GSER encoding of values of the - associated type for the EMBEDDED PDV type. - - EMBEDDED-PDV = "{" sp id-identification msp Identification "," - sp id-data-value msp OCTET-STRING - sp "}" - - The rule describes the GSER encoding of values of the - associated type for the EXTERNAL type. - - EXTERNAL = "{" [ sp id-direct-reference msp - OBJECT-IDENTIFIER "," ] - [ sp id-indirect-reference msp INTEGER "," ] - [ sp id-data-value-descriptor msp - ObjectDescriptor "," ] - sp id-encoding msp Encoding - sp "}" - - id-direct-reference = %x64.69.72.65.63.74.2D.72.65.66.65.72 - %x65.6E.63.65 - ; "direct-reference" - id-indirect-reference = %x69.6E.64.69.72.65.63.74.2D.72.65.66 - %x65.72.65.6E.63.65 - ; "indirect-reference" - id-data-value-descriptor = %x64.61.74.61.2D.76.61.6C.75.65.2D.64 - %x65.73.63.72.69.70.74.6F.72 - ; "data-value-descriptor" - id-encoding = %x65.6E.63.6F.64.69.6E.67 - ; "encoding" - - Encoding = ( id-single-ASN1-type ":" Value ) / - ( id-octet-aligned ":" OCTET-STRING ) / - ( id-arbitrary ":" BIT-STRING ) - - id-single-ASN1-type = %x73.69.6E.67.6C.65.2D.41.53.4E.31.2D.74.79 - %x70.65 - ; "single-ASN1-type" - id-octet-aligned = %x6F.63.74.65.74.2D.61.6C.69.67.6E.65.64 - ; "octet-aligned" - id-arbitrary = %x61.72.62.69.74.72.61.72.79 - ; "arbitrary" - - - - -Legg Expires 7 November 2003 [Page 5] - -INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003 - - - The rule is defined in [7]. It represents the GSER encoding - of a single value of the ASN.1 type identified by the direct- - reference and/or indirect-reference components. - - The rule describes the GSER encoding of values of the NULL - type. - - NULL = %x4E.55.4C.4C ; "NULL" - - The rule describes the GSER encoding of values of - the OBJECT IDENTIFIER type. - - OBJECT-IDENTIFIER = numeric-oid / descr - numeric-oid = oid-component 1*( "." oid-component ) - oid-component = "0" / positive-number - - An OBJECT IDENTIFIER value is encoded using either the dotted decimal - representation or an object descriptor name, i.e. . The - rule is described in [4]. An object descriptor name is - potentially ambiguous and should be used with care. - - The rule describes the GSER encoding of values of the - OCTET STRING type. - - OCTET-STRING = hstring - - The octets are encoded in order from the first octet to the last - octet. Each octet is encoded as a pair of hexadecimal digits where - the first digit corresponds to the four most significant bits of the - octet. If the hexadecimal string does not have an even number of - digits the four least significant bits in the last octet are assumed - to be zero. - - The rule describes the GSER encoding of values of the REAL - type. - - REAL = "0" ; zero - / PLUS-INFINITY ; positive infinity - / MINUS-INFINITY ; negative infinity - / realnumber ; positive base 10 REAL value - / ( "-" realnumber ) ; negative base 10 REAL value - / real-sequence-value ; non-zero base 2 or 10 REAL value - - PLUS-INFINITY = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59 - ; "PLUS-INFINITY" - MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59 - ; "MINUS-INFINITY" - - - - -Legg Expires 7 November 2003 [Page 6] - -INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003 - - - realnumber = mantissa exponent - mantissa = (positive-number [ "." *decimal-digit ]) - / ( "0." *("0") positive-number ) - exponent = "E" ( "0" / ([ "-" ] positive-number)) - - real-sequence-value = "{" sp id-mantissa msp INTEGER "," - sp id-base msp ( "2" / "10" ) "," - sp id-exponent msp INTEGER sp "}" - id-mantissa = %x6D.61.6E.74.69.73.73.61 ; "mantissa" - id-base = %x62.61.73.65 ; "base" - id-exponent = %x65.78.70.6F.6E.65.6E.74 ; "exponent" - - A value of the REAL type MUST be encoded as "0" if it is zero. - - The rule describes the GSER encoding of values of the - RELATIVE-OID type. - - RELATIVE-OID = oid-component *( "." oid-component ) - - -6. ASN.1 Restricted String Types - - This section describes the GSER encoding of values of the ASN.1 - restricted character string types. The characters of a value of a - restricted character string type are always encoded as a UTF8 - character string between double quotes. For some of the ASN.1 string - types this requires a translation to or from the UTF8 encoding. Some - of the ASN.1 string types permit only a subset of the characters - representable in UTF8. Any double quote characters in the character - string, where allowed by the character set, are escaped by being - repeated. - - The rule describes the GSER encoding of values of the - UTF8String type. The characters of this string type do not require - any translation before being encoded. - - UTF8String = StringValue - StringValue = dquote *SafeUTF8Character dquote - - dquote = %x22 ; " (double quote) - - SafeUTF8Character = %x00-21 / %x23-7F / ; ASCII minus dquote - dquote dquote / ; escaped double quote - %xC0-DF %x80-BF / ; 2 byte UTF8 character - %xE0-EF 2(%x80-BF) / ; 3 byte UTF8 character - %xF0-F7 3(%x80-BF) / ; 4 byte UTF8 character - %xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character - %xFC-FD 5(%x80-BF) ; 6 byte UTF8 character - - - -Legg Expires 7 November 2003 [Page 7] - -INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003 - - - The , , , - , , and rules - describe the GSER encoding of values of the correspondingly named - ASN.1 types. The characters of these string types are compatible - with UTF8 and do not require any translation before being encoded. - The GeneralizedTime and UTCTime types use the VisibleString character - set, but have a strictly defined format. - - NumericString = dquote *(decimal-digit / space) dquote - space = %x20 - - PrintableString = dquote *PrintableCharacter dquote - PrintableCharacter = decimal-digit / space - / %x41-5A ; A to Z - / %x61-7A ; a to z - / %x27-29 ; ' ( ) - / %x2B-2F ; + , - . / - / %x3A ; : - / %x3D ; = - / %x3F ; ? - - ISO646String = VisibleString - VisibleString = dquote *SafeVisibleCharacter dquote - SafeVisibleCharacter = %x20-21 - / %x23-7E ; printable ASCII minus dquote - / dquote dquote ; escaped double quote - - IA5String = dquote *SafeIA5Character dquote - SafeIA5Character = %x00-21 / %x23-7F ; ASCII minus dquote - / dquote dquote ; escaped double quote - - century = 2(%x30-39) ; "00" to "99" - year = 2(%x30-39) ; "00" to "99" - month = ( %x30 %x31-39 ) ; "01" (January) to "09" - / ( %x31 %x30-32 ) ; "10" to "12" - day = ( %x30 %x31-39 ) ; "01" to "09" - / ( %x31-32 %x30-39 ) ; "10" to "29" - / ( %x32 %x30-31 ) ; "30" to "31" - hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" - minute = %x30-36 %x30-39 ; "00" to "59" - second = %x30-36 %x30-39 ; "00" to "59" - - UTCTime = dquote year month day hour minute [ second ] - [ %x5A / u-differential ] dquote - u-differential = ( "-" / "+" ) hour minute - GeneralizedTime = dquote century year month day hour - [ minute [ second ] ] [ fraction ] - [ %x5A / g-differential ] dquote - - - -Legg Expires 7 November 2003 [Page 8] - -INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003 - - - fraction = ( "." / "," ) 1*(%x30-39) - g-differential = ( "-" / "+" ) hour [ minute ] - - The and rules describe the GSER - encoding of values of the BMPString and UniversalString types - respectively. BMPString (UCS-2) and UniversalString (UCS-4) values - are translated into UTF8 [6] character strings before being encoded - according to . - - BMPString = StringValue - UniversalString = StringValue - - The , , , , - and rules describe the GSER - encoding of values of the correspondingly named ASN.1 types. Values - of these string types are translated into UTF8 character strings - before being encoded according to . The - ObjectDescriptor type uses the GraphicString character set. - - TeletexString = StringValue - T61String = StringValue - VideotexString = StringValue - GraphicString = StringValue - GeneralString = StringValue - ObjectDescriptor = GraphicString - - -7. Directory ASN.1 Types - - This section describes the GSER encoding of values of selected ASN.1 - types defined for LDAP and X.500. The ABNF rule names beginning with - uppercase letters describe the GSER encoding of values of the ASN.1 - type with the same name. - - AttributeType = OBJECT-IDENTIFIER - - The characters of a DirectoryString are translated into UTF8 - characters as required before being encoded between double quotes - with any embedded double quotes escaped by being repeated. - - DirectoryString = StringValue / - ( id-teletexString ":" TeletexString ) / - ( id-printableString ":" PrintableString ) / - ( id-bmpString ":" BMPString ) / - ( id-universalString ":" UniversalString ) / - ( id-uTF8String ":" UTF8String ) - - id-teletexString = %x74.65.6C.65.74.65.78.53.74.72.69.6E.67 - - - -Legg Expires 7 November 2003 [Page 9] - -INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003 - - - ; "teletexString" - id-printableString = %x70.72.69.6E.74.61.62.6C.65 - %x53.74.72.69.6E.67 ; "printableString" - id-bmpString = %x62.6D.70.53.74.72.69.6E.67 ; "bmpString" - id-universalString = %x75.6E.69.76.65.72.73.61.6C - %x53.74.72.69.6E.67 ; "universalString" - id-uTF8String = %x75.54.46.38.53.74.72.69.6E.67 - ; "uTF8String" - - The rule describes the GSER encoding of values of the - RDNSequence type, which is syntactically equivalent to the - DistinguishedName and LocalName types. The rule - encodes a name as an LDAPDN character string between double quotes. - The character string is first derived according to the - rule in Section 3 of [5], and then it is encoded - between double quotes with any embedded double quotes escaped by - being repeated. - - DistinguishedName = RDNSequence - LocalName = RDNSequence - RDNSequence = dquote *SafeUTF8Character dquote - - The rule describes the GSER encoding of - values of the RelativeDistinguishedName type that are not part of an - RDNSequence value. The rule encodes an - RDN as a double quoted string containing the RDN as it would appear - in an LDAPDN character string. The character string is first derived - according to the rule in Section 3 of [6], and then - any embedded double quote characters are escaped by being repeated. - This resulting string is output between double quotes. - - RelativeDistinguishedName = dquote *SafeUTF8Character dquote - - The rule encodes an X.400 address as an IA5 character - string between double quotes. The character string is first derived - according to Section 4.1 of [2], and then any embedded double quotes - are escaped by being repeated. This resulting string is output - between double quotes. - - ORAddress = dquote *SafeIA5Character dquote - - -8. Security Considerations - - This document contains an alternative description of parts of the - Generic String Encoding Rules, but does not replace or alter GSER in - any way. For the full security implications of using GSER see the - Security Considerations section of [7]. - - - -Legg Expires 7 November 2003 [Page 10] - -INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003 - - -9. Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping - between X.400 and RFC 822/MIME", RFC 2156, January 1998. - - [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax Definitions", - RFC 2252, December 1997. - - [5] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access - Protocol (v3): UTF-8 String Representation of Distinguished - Names", RFC 2253, December 1997. - - [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC - 2279, January 1998. - - [7] Legg, S., "Generic String Encoding Rules for ASN.1 Types", - draft-legg-ldap-gser-xx.txt, a work in progress, May 2003. - - [8] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998 - Information Technology - Abstract Syntax Notation One (ASN.1): - Specification of basic notation - - -10. Informative References - - [9] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol - (v3): Technical Specification", RFC 3377, September 2002. - - [10] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, - Information Technology - Open Systems Interconnection - The - Directory: Overview of concepts, models and services - - -11. Copyright Notice - - 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 - - - -Legg Expires 7 November 2003 [Page 11] - -INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003 - - - 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. - - -12. Author's Address - - Steven Legg - Adacel Technologies Ltd. - 250 Bay Street - Brighton, Victoria 3186 - AUSTRALIA - - Phone: +61 3 8530 7710 - Fax: +61 3 8530 7888 - EMail: steven.legg@adacel.com.au - - - - - - - - - - - - - - - - - - - -Legg Expires 7 November 2003 [Page 12] - diff --git a/doc/drafts/draft-legg-ldap-gser-xx.txt b/doc/drafts/draft-legg-ldap-gser-xx.txt deleted file mode 100644 index cbca097e48..0000000000 --- a/doc/drafts/draft-legg-ldap-gser-xx.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -INTERNET-DRAFT S. Legg -draft-legg-ldap-gser-03.txt Adacel Technologies -Intended Category: Standard Track May 7, 2003 - - - Generic String Encoding Rules for ASN.1 Types - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - 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 document is unlimited. Comments should be sent - to the LDAPEXT working group mailing list - or to the author. - - This Internet-Draft expires on 7 November 2003. - - -Abstract - - This document defines a set of Abstract Syntax Notation One (ASN.1) - encoding rules, called the Generic String Encoding Rules, that - produce a human readable text encoding for values of any given ASN.1 - data type. - - - - - - - -Legg Expires 7 November 2003 [Page 1] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - -1. Table of Contents - - 1. Table of Contents ............................................. 2 - 2. Introduction .................................................. 2 - 3. Conventions ................................................... 3 - 4. Generic String Encoding Rules ................................. 3 - 4.1 Type Referencing Notations ................................ 4 - 4.2 Restricted Character String Types ......................... 4 - 4.3 ChoiceOfStrings Types ..................................... 5 - 4.4 Identifiers ............................................... 7 - 4.5 BIT STRING ................................................ 7 - 4.6 BOOLEAN ................................................... 8 - 4.7 ENUMERATED ................................................ 8 - 4.8 INTEGER ................................................... 8 - 4.9 NULL ...................................................... 8 - 4.10 OBJECT IDENTIFIER and RELATIVE-OID ....................... 9 - 4.11 OCTET STRING ............................................. 9 - 4.12 CHOICE ................................................... 9 - 4.13 SEQUENCE and SET ......................................... 10 - 4.14 SEQUENCE OF and SET OF ................................... 11 - 4.15 CHARACTER STRING ......................................... 11 - 4.16 EMBEDDED PDV ............................................. 11 - 4.17 EXTERNAL ................................................. 11 - 4.18 INSTANCE OF .............................................. 12 - 4.19 REAL ..................................................... 12 - 4.20 Variant Encodings ........................................ 12 - 5. GSER Transfer Syntax .......................................... 13 - 6. Security Considerations ....................................... 13 - 7. Normative References .......................................... 14 - 8. Informative References ........................................ 15 - 9. Copyright Notice .............................................. 15 - 10. Author's Address ............................................. 16 - - -2. Introduction - - This document defines a set of ASN.1 [8] encoding rules, called the - Generic String Encoding Rules or GSER, that produce a human readable - UTF8 [6] character string encoding of ASN.1 values of any given - arbitrary ASN.1 type. - - Note that "ASN.1 value" does not mean a BER [13] encoded value. The - ASN.1 value is an abstract concept that is independent of any - particular encoding. BER is just one possible encoding of an ASN.1 - value. - - GSER is based on ASN.1 value notation [8], with changes to - accommodate the notation's use as a transfer syntax, and to support - - - -Legg Expires 7 November 2003 [Page 2] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - well established ad-hoc string encodings for LDAP [14] directory data - types. - - Though primarily intended for defining the LDAP-specific encoding of - new LDAP attribute syntaxes and assertion syntaxes, these encoding - rules could also be used in other domains where human readable - renderings of ASN.1 values would be useful. - - Referencing the Generic String Encoding Rules (GSER) is sufficient to - define a human readable text encoding for values of a specific ASN.1 - type, however other specifications may wish to provide a customized - ABNF [3] description, independent of the ASN.1, as a convenience for - the implementor (equivalent ABNF for the GSER encodings for ASN.1 - types commonly occuring in LDAP syntaxes is provided in [15]). Such - a specification SHOULD state that if there is a discrepancy between - the customized ABNF and the GSER encoding defined by this document, - that the GSER encoding takes precedence. - - -3. Conventions - - Throughout this document "type" shall be taken to mean an ASN.1 type, - and "value" shall be taken to mean an ASN.1 value. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - - -4. Generic String Encoding Rules - - The GSER encoding of a value of any ASN.1 type is described by the - following ABNF [3]: - - Value = BitStringValue / - BooleanValue / - CharacterStringValue / - ChoiceValue / - EmbeddedPDVValue / - EnumeratedValue / - ExternalValue / - GeneralizedTimeValue / - IntegerValue / - InstanceOfValue / - NullValue / - ObjectDescriptorValue / - ObjectIdentifierValue / - OctetStringValue / - - - -Legg Expires 7 November 2003 [Page 3] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - RealValue / - RelativeOIDValue / - SequenceOfValue / - SequenceValue / - SetOfValue / - SetValue / - StringValue / - UTCTimeValue / - VariantEncoding - - The ABNF for each of the above rules is given in the following - sections. - - -4.1 Type Referencing Notations - - A value of a type with a defined type name is encoded according to - the type definition on the right hand side of the type assignment for - the type name. - - A value of a type denoted by the use of a parameterized type with - actual parameters is encoded according to the parameterized type with - the DummyReferences [12] substituted with the actual parameters. - - A value of a tagged or constrained type is encoded as a value of the - type without the tag or constraint, respectively. Tags do not appear - in the string encodings defined by this document. See [8] and [11] - for the details of ASN.1 constraint notation. - - A value of an open type denoted by an ObjectClassFieldType (Clause 14 - of [10]) is encoded according to the specific type of the value. - - A value of a fixed type denoted by an ObjectClassFieldType is encoded - according to that fixed type. - - A value of a selection type is encoded according to the type - referenced by the selection type. - - A value of a type described by TypeFromObject notation (Clause 15 of - [10]) is encoded according to the denoted type. - - A value of a type described by ValueSetFromObjects notation (Clause - 15 of [10]) is encoded according to the governing type. - - -4.2 Restricted Character String Types - - The contents of a string value are encoded as a UTF8 character string - - - -Legg Expires 7 November 2003 [Page 4] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - between double quotes, regardless of the ASN.1 string type. - Depending on the ASN.1 string type, and an application's internal - representation of that string type, a translation to or from the UTF8 - character encoding may be required. NumericString, PrintableString, - IA5String, VisibleString (ISO646String) are compatible with UTF8 and - do not require any translation. BMPString (UCS-2) and - UniversalString (UCS-4) have a direct mapping to and from UTF8 [6]. - For the remaining string types see [8]. Any embedded double quotes - in the resulting UTF8 character string are escaped by repeating the - double quote characters. - - A value of the NumericString, PrintableString, TeletexString - (T61String), VideotexString, IA5String, GraphicString, VisibleString - (ISO646String), GeneralString, BMPString, UniversalString or - UTF8String type is encoded according to the rule. - - StringValue = dquote *SafeUTF8Character dquote - - dquote = %x22 ; " (double quote) - - SafeUTF8Character = %x00-21 / %x23-7F / ; ASCII minus dquote - dquote dquote / ; escaped double quote - %xC0-DF %x80-BF / ; 2 byte UTF8 character - %xE0-EF 2(%x80-BF) / ; 3 byte UTF8 character - %xF0-F7 3(%x80-BF) / ; 4 byte UTF8 character - %xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character - %xFC-FD 5(%x80-BF) ; 6 byte UTF8 character - - A value of the GeneralizedTime type, UTCTime type or ObjectDescriptor - type is encoded as a string value. GeneralizedTime and UTCTime use - the VisibleString character set so the conversion to UTF8 is trivial. - ObjectDescriptor uses the GraphicString type. - - GeneralizedTimeValue = StringValue - UTCTimeValue = StringValue - ObjectDescriptorValue = StringValue - - -4.3 ChoiceOfStrings Types - - It is not uncommon for ASN.1 specifications to define types that are - a CHOICE between two or more alternative ASN.1 string types, where - the particular alternative chosen carries no semantic significance - (DirectoryString [7] being a prime example). Such types are defined - to avoid having to use a complicated character encoding for all - values when most values could use a simpler string type, or to deal - with evolving requirements that compel the use of a broader character - set while still maintaining backward compatibility. - - - -Legg Expires 7 November 2003 [Page 5] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - GSER encodes values of all the ASN.1 string types as UTF8 character - strings so the alternative chosen in a purely syntactic CHOICE of - string types makes no material difference to the final encoding of - the string value. - - While there are certain ASN.1 constructs that betray the semantic - significance of the alternatives within a CHOICE type, the absence of - those constructs does not necessarily mean a CHOICE type is purely - syntactic. Therefore, it is necessary for specifications to declare - the purely syntactic CHOICE types so that they may be more compactly - encoded (see Section 4.12). These declared CHOICE types are referred - to as ChoiceOfStrings types. - - To be eligible to be declared a ChoiceOfStrings type an ASN.1 type - MUST satisfy the following conditions. - - a) The type is a CHOICE type. - - b) The component type of each alternative is one of the following - ASN.1 restricted string types: NumericString, PrintableString, - TeletexString (T61String), VideotexString, IA5String, - GraphicString, VisibleString (ISO646String), GeneralString, - BMPString, UniversalString or UTF8String. - - c) All the alternatives are of different restricted string types, - i.e. no two alternatives have the same ASN.1 restricted string - type. - - d) Either none of the alternatives has a constraint, or all of the - alternatives have exactly the same constraint. - - Tagging on the alternative types is ignored. - - Consider the ASN.1 parameterized type definition of DirectoryString. - - DirectoryString { INTEGER : maxSize } ::= CHOICE { - teletexString TeletexString (SIZE (1..maxSize)), - printableString PrintableString (SIZE (1..maxSize)), - bmpString BMPString (SIZE (1..maxSize)), - universalString UniversalString (SIZE (1..maxSize)), - uTF8String UTF8String (SIZE (1..maxSize)) } - - Any use of the DirectoryString parameterized type with an actual - parameter defines a ASN.1 type that satisfies the above conditions. - Recognising that the alternative within a DirectoryString carries no - semantic significance, this document declares (each and every use of) - DirectoryString{} to be a ChoiceOfStrings type. - - - - -Legg Expires 7 November 2003 [Page 6] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - Other specifications MAY declare other types satisfying the above - conditions to be ChoiceOfStrings types. The declaration SHOULD be - made at the point where the ASN.1 type is defined, otherwise it - SHOULD be made at the point where it is introduced as, or in, an LDAP - attribute or assertion syntax. - - -4.4 Identifiers - - An conforms to the definition of an identifier in ASN.1 - notation (Clause 11.3 of [8]). It begins with a lowercase letter and - is followed by zero or more letters, digits, and hyphens. A hyphen - is not permitted to be the last character and a hyphen is not - permitted to be followed by another hyphen. The case of letters in - an identifier is always significant. - - identifier = lowercase *alphanumeric *(hyphen 1*alphanumeric) - alphanumeric = uppercase / lowercase / decimal-digit - uppercase = %x41-5A ; "A" to "Z" - lowercase = %x61-7A ; "a" to "z" - decimal-digit = %x30-39 ; "0" to "9" - hyphen = "-" - - -4.5 BIT STRING - - A value of the BIT STRING type is encoded according to the - rule. If the definition of the BIT STRING type - includes a named bit list, the form of - MAY be used. If the number of bits in a BIT STRING value is a - multiple of four the form of MAY be used. - The form of is used otherwise. - - BitStringValue = bstring / hstring / bit-list - - The rule encodes the one bits in the bit string value as a - comma separated list of identifiers. Each MUST be one - of those in the named bit list. An MUST NOT appear more - than once in the same . The rule encodes each - bit as the character "0" or "1" in order from the first bit to the - last bit. The rule encodes each group of four bits as a - hexadecimal number where the first bit is the most significant. An - odd number of hexadecimal digits is permitted. - - bit-list = "{" [ sp identifier - *( "," sp identifier ) ] sp "}" - - hstring = squote *hexadecimal-digit squote %x48 ; '...'H - - - -Legg Expires 7 November 2003 [Page 7] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - hexadecimal-digit = %x30-39 / ; "0" to "9" - %x41-46 ; "A" to "F" - - bstring = squote *binary-digit squote %x42 ; '...'B - binary-digit = "0" / "1" - - sp = *%x20 ; zero, one or more space characters - squote = %x27 ; ' (single quote) - - -4.6 BOOLEAN - - A value of the BOOLEAN type is encoded according to the - rule. - - BooleanValue = %x54.52.55.45 / ; "TRUE" - %x46.41.4C.53.45 ; "FALSE" - - -4.7 ENUMERATED - - A value of the ENUMERATED type is encoded according to the - rule. The MUST be one of those in the - list of enumerations in the definition of the ENUMERATED type. - - EnumeratedValue = identifier - - -4.8 INTEGER - - A value of the INTEGER type is encoded according to the - rule. If the definition of the INTEGER type includes - a named number list, the form of MAY be - used, in which case the MUST be one of those in the - named number list. - - IntegerValue = "0" / - positive-number / - ("-" positive-number) / - identifier - - positive-number = non-zero-digit *decimal-digit - non-zero-digit = %x31-39 ; "1" to "9" - - -4.9 NULL - - A value of the NULL type is encoded according to the - - - -Legg Expires 7 November 2003 [Page 8] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - rule. - - NullValue = %x4E.55.4C.4C ; "NULL" - - -4.10 OBJECT IDENTIFIER and RELATIVE-OID - - A value of the OBJECT IDENTIFIER type is encoded according to the - rule. The rule - allows either a dotted decimal representation of the OBJECT - IDENTIFIER value or an object descriptor name, i.e. . The - rule is described in [4]. An object descriptor name is - potentially ambiguous and should be used with care. - - ObjectIdentifierValue = numeric-oid / descr - numeric-oid = oid-component 1*( "." oid-component ) - oid-component = "0" / positive-number - - A value of the RELATIVE-OID [9] type is encoded according to the - rule. - - RelativeOIDValue = oid-component *( "." oid-component ) - - -4.11 OCTET STRING - - A value of the OCTET STRING type is encoded according to the - rule. The octets are encoded in order from the - first octet to the last octet. Each octet is encoded as a pair of - hexadecimal digits where the first digit corresponds to the four most - significant bits of the octet. If the hexadecimal string does not - have an even number of digits the four least significant bits in the - last octet are assumed to be zero. - - OctetStringValue = hstring - - -4.12 CHOICE - - A value of a CHOICE type is encoded according to the - rule. The encoding MAY be used if the - corresponding CHOICE type has been declared a ChoiceOfStrings type. - This document declares DirectoryString to be a ChoiceOfStrings type - (see Section 4.3). The form of - is used otherwise. - - ChoiceValue = IdentifiedChoiceValue / - ChoiceOfStringsValue - - - -Legg Expires 7 November 2003 [Page 9] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - IdentifiedChoiceValue = identifier ":" Value - ChoiceOfStringsValue = StringValue - - For implementations that recognise the internal structure of the - DirectoryString CHOICE type (e.g. X.500 directories [16]), if the - character string between the quotes in a contains only - characters that are permitted in a PrintableString the - DirectoryString is assumed to use the printableString alternative, - otherwise it is assumed to use the uTF8String alternative. The - rule MAY be used for a value of type - DirectoryString to indicate a different alternative to the one that - would otherwise be assumed from the string contents. No matter what - alternative is chosen, the will still be a UTF8 encoded - character string, however it is a syntax error if the characters in - the UTF8 string cannot be represented in the string type of the - chosen alternative. - - Implementations that don't care about the internal structure of a - DirectoryString value MUST be able to parse the - form for a DirectoryString value, though the - particular identifier found will be of no interest. - -4.13 SEQUENCE and SET - - A value of a SEQUENCE type is encoded according to the - rule. The rule encodes a comma - separated list of the particular component values present in the - SEQUENCE value, where each component value is preceded by the - corresponding identifier from the SEQUENCE type definition. The - components are encoded in the order of their definition in the - SEQUENCE type. - - SequenceValue = ComponentList - - ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}" - NamedValue = identifier msp Value - msp = 1*%x20 ; one or more space characters - - A value of a SET type is encoded according to the rule. - The components are encoded in the order of their definition in - the SET type (i.e. just like a SEQUENCE value). - This is a deliberate departure from ASN.1 value notation where - the components of a SET can be written in any order. - - SetValue = ComponentList - - SEQUENCE and SET type definitions are sometimes extended by the - inclusion of additional component types, so an implementation SHOULD - - - -Legg Expires 7 November 2003 [Page 10] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - be capable of skipping over any encoding with an - identifier that is not recognised, on the assumption that the sender - is using a more recent definition of the SEQUENCE or SET type. - - -4.14 SEQUENCE OF and SET OF - - A value of a SEQUENCE OF type is encoded according to the - rule, as a comma separated list of the instances in - the value. Each instance is encoded according to the component type - of the SEQUENCE OF type. - - SequenceOfValue = "{" [ sp Value *( "," sp Value) ] sp "}" - - A value of a SET OF type is encoded according to the - rule, as a list of the instances in the value. Each instance is - encoded according to the component type of the SET OF type. - - SetOfValue = "{" [ sp Value *( "," sp Value) ] sp "}" - - -4.15 CHARACTER STRING - - A value of the unrestricted CHARACTER STRING type is encoded - according to the corresponding SEQUENCE type defined in Clause 39.5 - of [8] (see [15] for equivalent ABNF). - - CharacterStringValue = SequenceValue - - -4.16 EMBEDDED PDV - - A value of the EMBEDDED PDV type is encoded according to the - corresponding SEQUENCE type defined in Clause 32.5 of [8] (see [15] - for equivalent ABNF). - - EmbeddedPDVValue = SequenceValue - - -4.17 EXTERNAL - - A value of the EXTERNAL type is encoded according to the - corresponding SEQUENCE type defined in Clause 8.18.1 of [13] (see - [15] for equivalent ABNF). - - ExternalValue = SequenceValue - - - - - -Legg Expires 7 November 2003 [Page 11] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - -4.18 INSTANCE OF - - A value of the INSTANCE OF type is encoded according to the - corresponding SEQUENCE type defined in Annex C of [10]. - - InstanceOfValue = SequenceValue - - -4.19 REAL - - A value of the REAL type MUST be encoded as "0" if it is zero, - otherwise it is encoded as either the special value , - the special value , an optionally signed - (based on the extended value notation for REAL from [17]) or as a - value of the corresponding SEQUENCE type for REAL defined in Clause - 20.5 of [8] (see [15] for equivalent ABNF). - - RealValue = "0" ; zero REAL value - / PLUS-INFINITY ; positive infinity - / MINUS-INFINITY ; negative infinity - / realnumber ; positive base 10 REAL value - / "-" realnumber ; negative base 10 REAL value - / SequenceValue ; non-zero REAL value, base 2 or 10 - realnumber = mantissa exponent - mantissa = (positive-number [ "." *decimal-digit ]) - / ( "0." *("0") positive-number ) - exponent = "E" ( "0" / ([ "-" ] positive-number)) - - PLUS-INFINITY = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59 - ; "PLUS-INFINITY" - MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59 - ; "MINUS-INFINITY" - - -4.20 Variant Encodings - - The values of some named complex ASN.1 types have special string - encodings. These special encodings are always used instead of the - encoding that would otherwise apply based on the ASN.1 type - definition. - - VariantEncoding = RDNSequenceValue / - RelativeDistinguishedNameValue / - ORAddressValue - - A value of the RDNSequence type, i.e. a distinguished name, is - encoded according to the rule, as a quoted LDAPDN - character string. The character string is first derived according to - - - -Legg Expires 7 November 2003 [Page 12] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - the rule in Section 3 of [5], and then it is - encoded as if it were a UTF8String value, i.e. between double quotes - with any embedded double quotes escaped by being repeated. - - RDNSequenceValue = StringValue - - A RelativeDistinguishedName value that is not part of an RDNSequence - value is encoded according to the - rule as a quoted character string. The character string is first - derived according to the rule in Section 3 of [5], - and then it is encoded as if it were a UTF8String value. - - RelativeDistinguishedNameValue = StringValue - - A value of the ORAddress type is encoded according to the - rule as a quoted character string. The character - string is first derived according to the textual representation of - MTS.ORAddress from [2], and then it is encoded as if it were an - IA5String value. - - ORAddressValue = StringValue - - -5. GSER Transfer Syntax - - The following OBJECT IDENTIFIER has been assigned to identify the - Generic String Encoding Rules: - - { 1 2 36 79672281 0 0 } - - This OBJECT IDENTIFIER would be used, for example, to describe the - transfer syntax for a GSER encoded data-value in an EMBEDDED PDV - value. - - -6. Security Considerations - - The Generic String Encoding Rules do not define a canonical encoding. - That is, a transformation from a GSER encoding into some other - encoding (e.g. BER) and back into GSER will not necessarily reproduce - exactly the original GSER octet encoding. Therefore GSER SHOULD NOT - be used where a canonical encoding is needed. - - Furthermore, GSER does not necessarily enable the exact octet - encoding of values of the TeletexString, VideotexString, - GraphicString or GeneralString types to be reconstructed, so a - transformation from DER to GSER and back to DER may not reproduce the - original DER encoding. Therefore GSER SHOULD NOT be used where - - - -Legg Expires 7 November 2003 [Page 13] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - reversibility to DER is needed, e.g. for the verification of digital - signatures. Instead, DER or a DER-reversible encoding should be - used. - - When interpreting security-sensitive fields, and in particular fields - used to grant or deny access, implementations MUST ensure that any - comparisons are done on the underlying abstract value, regardless of - the particular encoding used. - - -7. Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping - between X.400 and RFC 822/MIME", RFC 2156, January 1998. - - [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight - Directory Access Protocol (v3): Attribute Syntax Definitions", - RFC 2252, December 1997. - - [5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access - Protocol (v3): UTF-8 String Representation of Distinguished - Names", RFC 2253, December 1997. - - [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC - 2279, January 1998. - - [7] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, - Information Technology - Open Systems Interconnection - The - Directory: Selected attribute types - - [8] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998 - Information Technology - Abstract Syntax Notation One (ASN.1): - Specification of basic notation - - [9] ITU-T Recommendation X.680 - Amendment 1 (06/99) | ISO/IEC - 8824-1:1998/Amd 1:2000 Relative object identifiers - - [10] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998 - Information Technology - Abstract Syntax Notation One (ASN.1): - Information object specification - - [11] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998 - - - -Legg Expires 7 November 2003 [Page 14] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - Information Technology - Abstract Syntax Notation One (ASN.1): - Constraint specification - - [12] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998 - Information Technology - Abstract Syntax Notation One (ASN.1): - Parameterization of ASN.1 specifications - - [13] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998 - Information Technology - ASN.1 encoding rules: Specification of - Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and - Distinguished Encoding Rules (DER) - - -8. Informative References - - [14] Hodges, J. and R. Morgan, "Lightweight Directory Access - Protocol (v3): Technical Specification", RFC 3377, September - 2002. - - [15] Legg, S., "Common Elements of GSER Encodings", - draft-legg-ldap-gser-abnf-xx.txt, a work in progress, May 2003. - - [16] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, - Information Technology - Open Systems Interconnection - The - Directory: Overview of concepts, models and services - - [17] ITU-T Recommendation X.680 - Corrigendum 3 (02/2001) - - -9. Copyright Notice - - 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 - - - -Legg Expires 7 November 2003 [Page 15] - -INTERNET-DRAFT Generic String Encoding Rules May 7, 2003 - - - 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. - - -10. Author's Address - - Steven Legg - Adacel Technologies Ltd. - 250 Bay Street - Brighton, Victoria 3186 - AUSTRALIA - - Phone: +61 3 8530 7710 - Fax: +61 3 8530 7888 - EMail: steven.legg@adacel.com.au - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Legg Expires 7 November 2003 [Page 16] - diff --git a/doc/drafts/draft-sermersheim-ldap-csn-xx.txt b/doc/drafts/draft-sermersheim-ldap-csn-xx.txt new file mode 100644 index 0000000000..9395eb1534 --- /dev/null +++ b/doc/drafts/draft-sermersheim-ldap-csn-xx.txt @@ -0,0 +1,406 @@ + +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 +