+++ /dev/null
-
-
-
-
-
-
-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 <ietf-ldapext@netscape.com>
- 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]
-\f
-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]
-\f
-INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
-
-
- msp = 1*%x20 ; one or more space characters
-
- sep = [ "," ]
-
- The <sep> 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 <BIT-STRING> 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
- <hstring> form of <BIT-STRING> MAY be used. The <bstring> form of
- <BIT-STRING> is used otherwise. The <bstring> rule encodes each bit
- as the character "0" or "1" in order from the first bit to the last
- bit. The <hstring> 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 <BOOLEAN> rule describes the GSER encoding of values of the
- BOOLEAN type.
-
- BOOLEAN = %x54.52.55.45 / ; "TRUE"
- %x46.41.4C.53.45 ; "FALSE"
-
- The <CHARACTER-STRING> rule describes the GSER encoding of values of
- the associated type for the unrestricted CHARACTER STRING type.
-
-
-
-
-Legg Expires 7 November 2003 [Page 3]
-\f
-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 <INTEGER> rule describes the GSER encoding of values of the
- INTEGER type without a named number list. The <INTEGER-0-MAX> rule
- describes the GSER encoding of values of the constrained type INTEGER
- (0..MAX). The <INTEGER-1-MAX> 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]
-\f
-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 <EMBEDDED-PDV> 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 <EXTERNAL> 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]
-\f
-INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
-
-
- The <Value> 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 <NULL> rule describes the GSER encoding of values of the NULL
- type.
-
- NULL = %x4E.55.4C.4C ; "NULL"
-
- The <OBJECT-IDENTIFIER> 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. <descr>. The
- <descr> rule is described in [4]. An object descriptor name is
- potentially ambiguous and should be used with care.
-
- The <OCTET-STRING> 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 <REAL> 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]
-\f
-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 <RELATIVE-OID> 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 <UTF8String> 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]
-\f
-INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
-
-
- The <NumericString>, <PrintableString>, <VisibleString>,
- <ISO646String>, <IA5String>, <GeneralizedTime> and <UTCTime> 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]
-\f
-INTERNET-DRAFT Common Elements of GSER Encodings May 7, 2003
-
-
- fraction = ( "." / "," ) 1*(%x30-39)
- g-differential = ( "-" / "+" ) hour [ minute ]
-
- The <BMPString> and <UniversalString> 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 <StringValue>.
-
- BMPString = StringValue
- UniversalString = StringValue
-
- The <TeletexString>, <T61String>, <VideotexString>, <GraphicString>,
- <GeneralString> and <ObjectDescriptor> 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 <StringValue>. 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]
-\f
-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 <RDNSequence> rule describes the GSER encoding of values of the
- RDNSequence type, which is syntactically equivalent to the
- DistinguishedName and LocalName types. The <RDNSequence> rule
- encodes a name as an LDAPDN character string between double quotes.
- The character string is first derived according to the
- <distinguishedName> 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 <RelativeDistinguishedName> rule describes the GSER encoding of
- values of the RelativeDistinguishedName type that are not part of an
- RDNSequence value. The <RelativeDistinguishedName> 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 <name-component> 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 <ORAddress> 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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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 <ietf-ldapext@netscape.com>
- 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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 <StringValue> 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]
-\f
-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]
-\f
-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 <identifier> 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
- <BitStringValue> rule. If the definition of the BIT STRING type
- includes a named bit list, the <bit-list> form of <BitStringValue>
- MAY be used. If the number of bits in a BIT STRING value is a
- multiple of four the <hstring> form of <BitStringValue> MAY be used.
- The <bstring> form of <BitStringValue> is used otherwise.
-
- BitStringValue = bstring / hstring / bit-list
-
- The <bit-list> rule encodes the one bits in the bit string value as a
- comma separated list of identifiers. Each <identifier> MUST be one
- of those in the named bit list. An <identifier> MUST NOT appear more
- than once in the same <bit-list>. The <bstring> rule encodes each
- bit as the character "0" or "1" in order from the first bit to the
- last bit. The <hstring> 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]
-\f
-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
- <BooleanValue> 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
- <EnumeratedValue> rule. The <identifier> 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
- <IntegerValue> rule. If the definition of the INTEGER type includes
- a named number list, the <identifier> form of <IntegerValue> MAY be
- used, in which case the <identifier> 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 <NullValue>
-
-
-
-Legg Expires 7 November 2003 [Page 8]
-\f
-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
- <ObjectIdentifierValue> rule. The <ObjectIdentifierValue> rule
- allows either a dotted decimal representation of the OBJECT
- IDENTIFIER value or an object descriptor name, i.e. <descr>. The
- <descr> 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
- <RelativeOIDValue> rule.
-
- RelativeOIDValue = oid-component *( "." oid-component )
-
-
-4.11 OCTET STRING
-
- A value of the OCTET STRING type is encoded according to the
- <OctetStringValue> 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 <ChoiceValue>
- rule. The <ChoiceOfStringsValue> 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 <IdentifiedChoiceValue> form of <ChoiceValue>
- is used otherwise.
-
- ChoiceValue = IdentifiedChoiceValue /
- ChoiceOfStringsValue
-
-
-
-Legg Expires 7 November 2003 [Page 9]
-\f
-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 <StringValue> 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
- <IdentifiedChoiceValue> 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 <Value> 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
- <IdentifiedChoiceValue> 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
- <SequenceValue> rule. The <ComponentList> 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 <SetValue> 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]
-\f
-INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
-
-
- be capable of skipping over any <NamedValue> 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
- <SequenceOfValue> 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 <SetOfValue>
- 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]
-\f
-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 <PLUS-INFINITY>,
- the special value <MINUS-INFINITY>, an optionally signed <realnumber>
- (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 <RDNSequenceValue> rule, as a quoted LDAPDN
- character string. The character string is first derived according to
-
-
-
-Legg Expires 7 November 2003 [Page 12]
-\f
-INTERNET-DRAFT Generic String Encoding Rules May 7, 2003
-
-
- the <distinguishedName> 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 <RelativeDistinguishedNameValue>
- rule as a quoted character string. The character string is first
- derived according to the <name-component> 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
- <ORAddressValue> 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
--- /dev/null
+
+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 \f
+ 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 \f
+ 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 \f
+ 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 \f
+ 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 \f
+ 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 \f
+ 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 \f
+
projects / openldap / commitdiff