From: Kurt Zeilenga Date: Tue, 30 Dec 2003 00:53:19 +0000 (+0000) Subject: Sync with HEAD X-Git-Tag: OPENLDAP_REL_ENG_2_2_4~5 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=0fcf37ca6fa6d9abb1752f5d00b52d945b34f03a;p=openldap Sync with HEAD --- 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 + diff --git a/include/ldap.h b/include/ldap.h index 8b6615eb23..6ba6d990c6 100644 --- a/include/ldap.h +++ b/include/ldap.h @@ -473,6 +473,9 @@ typedef struct ldapcontrol { /* for the LDAP Sync operation */ #define LDAP_SYNC_REFRESH_REQUIRED 0x4100 +/* for the LDAP No-Op control */ +#define LDAP_NO_OPERATION 0x410e + /* for the Assertion control */ #define LDAP_ASSERTION_FAILED 0x410f diff --git a/libraries/libldap/cancel.c b/libraries/libldap/cancel.c index 0770389d3f..f314d9816d 100644 --- a/libraries/libldap/cancel.c +++ b/libraries/libldap/cancel.c @@ -29,8 +29,6 @@ #include "ldap-int.h" #include "ldap_log.h" -#ifdef LDAP_EXOP_X_CANCEL - int ldap_cancel( LDAP *ld, @@ -72,4 +70,3 @@ ldap_cancel_s( return rc; } -#endif /* LDAP_EXOP_X_CANCEL */ diff --git a/libraries/libldap/error.c b/libraries/libldap/error.c index c537d398b6..3b4572e3bd 100644 --- a/libraries/libldap/error.c +++ b/libraries/libldap/error.c @@ -106,14 +106,14 @@ static struct ldaperror ldap_builtin_errlist[] = { {LDAP_REFERRAL_LIMIT_EXCEEDED, N_("Referral Limit Exceeded")}, {LDAP_SYNC_REFRESH_REQUIRED, N_("Content Sync Refresh Required")}, + + {LDAP_NO_OPERATION, N_("No Operation")}, {LDAP_ASSERTION_FAILED, N_("Assertion Failed")}, -#ifdef LDAP_EXOP_X_CANCEL {LDAP_CANCELLED, N_("Cancelled")}, {LDAP_NO_SUCH_OPERATION, N_("No Operation to Cancel")}, {LDAP_TOO_LATE, N_("Too Late to Cancel")}, {LDAP_CANNOT_CANCEL, N_("Cannot Cancel")}, -#endif {0, NULL} }; diff --git a/servers/slapd/back-bdb/add.c b/servers/slapd/back-bdb/add.c index e08f764c4c..763523cdd4 100644 --- a/servers/slapd/back-bdb/add.c +++ b/servers/slapd/back-bdb/add.c @@ -40,7 +40,6 @@ bdb_add(Operation *op, SlapReply *rs ) #endif u_int32_t locker = 0; DB_LOCK lock; - int noop = 0; int num_retries = 0; @@ -460,8 +459,8 @@ retry: /* transaction retry */ if (( rs->sr_err=TXN_ABORT( ltid )) != 0 ) { rs->sr_text = "txn_abort (no-op) failed"; } else { - noop = 1; - rs->sr_err = LDAP_SUCCESS; + rs->sr_err = LDAP_NO_OPERATION; + goto return_results; } } else { @@ -488,10 +487,11 @@ retry: /* transaction retry */ } } - if ( rs->sr_err == LDAP_SUCCESS && !noop && !op->o_no_psearch ) { + if ( rs->sr_err == LDAP_SUCCESS && !op->o_no_psearch ) { ldap_pvt_thread_rdwr_rlock( &bdb->bi_pslist_rwlock ); LDAP_LIST_FOREACH ( ps_list, &bdb->bi_psearch_list, o_ps_link ) { - bdb_psearch( op, rs, ps_list, op->oq_add.rs_e, LDAP_PSEARCH_BY_ADD ); + bdb_psearch( op, rs, ps_list, op->oq_add.rs_e, + LDAP_PSEARCH_BY_ADD ); } ldap_pvt_thread_rdwr_runlock( &bdb->bi_pslist_rwlock ); } @@ -506,7 +506,7 @@ retry: /* transaction retry */ ltid = NULL; op->o_private = NULL; - if (rs->sr_err != LDAP_SUCCESS) { + if ( rs->sr_err != LDAP_SUCCESS ) { #ifdef NEW_LOGGING LDAP_LOG ( OPERATION, ERR, "bdb_add: %s : %s (%d)\n", rs->sr_text, @@ -548,5 +548,5 @@ done: op->o_private = NULL; } - return ( ( rs->sr_err == LDAP_SUCCESS ) ? noop : rs->sr_err ); + return rs->sr_err; } diff --git a/servers/slapd/back-bdb/delete.c b/servers/slapd/back-bdb/delete.c index eca84dcfee..f374e9e110 100644 --- a/servers/slapd/back-bdb/delete.c +++ b/servers/slapd/back-bdb/delete.c @@ -40,8 +40,6 @@ bdb_delete( Operation *op, SlapReply *rs ) u_int32_t locker = 0; DB_LOCK lock, plock; - int noop = 0; - int num_retries = 0; Operation* ps_list; @@ -505,8 +503,8 @@ retry: /* transaction retry */ if ( ( rs->sr_err = TXN_ABORT( ltid ) ) != 0 ) { rs->sr_text = "txn_abort (no-op) failed"; } else { - noop = 1; - rs->sr_err = LDAP_SUCCESS; + rs->sr_err = LDAP_NO_OPERATION; + goto return_results; } } else { bdb_cache_delete( &bdb->bi_cache, e, bdb->bi_dbenv, @@ -519,7 +517,7 @@ retry: /* transaction retry */ } } - if ( rs->sr_err == LDAP_SUCCESS && !noop && !op->o_no_psearch ) { + if ( rs->sr_err == LDAP_SUCCESS && !op->o_no_psearch ) { ldap_pvt_thread_rdwr_rlock( &bdb->bi_pslist_rwlock ); LDAP_LIST_FOREACH( ps_list, &bdb->bi_psearch_list, o_ps_link ) { bdb_psearch( op, rs, ps_list, e, LDAP_PSEARCH_BY_DELETE ); @@ -536,7 +534,8 @@ retry: /* transaction retry */ #ifdef NEW_LOGGING LDAP_LOG ( OPERATION, ERR, "bdb_delete: txn_%s failed: %s (%d)\n", - op->o_noop ? "abort (no-op)" : "commit", db_strerror(rs->sr_err), rs->sr_err ); + op->o_noop ? "abort (no-op)" : "commit", + db_strerror(rs->sr_err), rs->sr_err ); #else Debug( LDAP_DEBUG_TRACE, "bdb_delete: txn_%s failed: %s (%d)\n", @@ -552,7 +551,8 @@ retry: /* transaction retry */ #ifdef NEW_LOGGING LDAP_LOG ( OPERATION, RESULTS, "bdb_delete: deleted%s id=%08lx db=\"%s\"\n", - op->o_noop ? " (no-op)" : "", e->e_id, e->e_dn ); + op->o_noop ? " (no-op)" : "", + e->e_id, e->e_dn ); #else Debug( LDAP_DEBUG_TRACE, "bdb_delete: deleted%s id=%08lx dn=\"%s\"\n", @@ -566,7 +566,7 @@ retry: /* transaction retry */ return_results: send_ldap_result( op, rs ); - if(rs->sr_err == LDAP_SUCCESS && bdb->bi_txn_cp ) { + if( rs->sr_err == LDAP_SUCCESS && bdb->bi_txn_cp ) { ldap_pvt_thread_yield(); TXN_CHECKPOINT( bdb->bi_dbenv, bdb->bi_txn_cp_kbyte, bdb->bi_txn_cp_min, 0 ); @@ -588,5 +588,5 @@ done: op->o_private = NULL; } - return ( ( rs->sr_err == LDAP_SUCCESS ) ? noop : rs->sr_err ); + return rs->sr_err; } diff --git a/servers/slapd/back-bdb/modify.c b/servers/slapd/back-bdb/modify.c index 9debb6c59c..5a1e857d0e 100644 --- a/servers/slapd/back-bdb/modify.c +++ b/servers/slapd/back-bdb/modify.c @@ -307,8 +307,6 @@ bdb_modify( Operation *op, SlapReply *rs ) u_int32_t locker = 0; DB_LOCK lock; - int noop = 0; - int num_retries = 0; LDAPControl *ctrls[SLAP_MAX_RESPONSE_CONTROLS]; @@ -613,8 +611,8 @@ retry: /* transaction retry */ if ( ( rs->sr_err = TXN_ABORT( ltid ) ) != 0 ) { rs->sr_text = "txn_abort (no-op) failed"; } else { - noop = 1; - rs->sr_err = LDAP_SUCCESS; + rs->sr_err = LDAP_NO_OPERATION; + goto return_results; } } else { bdb_cache_modify( e, dummy.e_attrs, bdb->bi_dbenv, locker, &lock ); @@ -626,7 +624,7 @@ retry: /* transaction retry */ } } - if ( rs->sr_err == LDAP_SUCCESS && !op->o_noop ) { + if ( rs->sr_err == LDAP_SUCCESS ) { /* Loop through in-scope entries for each psearch spec */ ldap_pvt_thread_rdwr_rlock( &bdb->bi_pslist_rwlock ); LDAP_LIST_FOREACH ( ps_list, &bdb->bi_psearch_list, o_ps_link ) { @@ -707,5 +705,5 @@ done: if( e != NULL ) { bdb_unlocked_cache_return_entry_w (&bdb->bi_cache, e); } - return ( ( rs->sr_err == LDAP_SUCCESS ) ? noop : rs->sr_err ); + return rs->sr_err; } diff --git a/servers/slapd/back-bdb/modrdn.c b/servers/slapd/back-bdb/modrdn.c index f1d58647f8..8fe60a078b 100644 --- a/servers/slapd/back-bdb/modrdn.c +++ b/servers/slapd/back-bdb/modrdn.c @@ -58,8 +58,6 @@ bdb_modrdn( Operation *op, SlapReply *rs ) u_int32_t locker = 0; DB_LOCK lock, plock, nplock; - int noop = 0; - int num_retries = 0; LDAPControl *ctrls[SLAP_MAX_RESPONSE_CONTROLS]; @@ -975,8 +973,8 @@ retry: /* transaction retry */ if(( rs->sr_err=TXN_ABORT( ltid )) != 0 ) { rs->sr_text = "txn_abort (no-op) failed"; } else { - noop = 1; rs->sr_err = LDAP_SUCCESS; + goto return_results; } } else { @@ -990,7 +988,7 @@ retry: /* transaction retry */ } } - if ( rs->sr_err == LDAP_SUCCESS && !op->o_noop ) { + if ( rs->sr_err == LDAP_SUCCESS ) { /* Loop through in-scope entries for each psearch spec */ ldap_pvt_thread_rdwr_rlock( &bdb->bi_pslist_rwlock ); LDAP_LIST_FOREACH ( ps_list, &bdb->bi_psearch_list, o_ps_link ) { @@ -1034,11 +1032,13 @@ retry: /* transaction retry */ #ifdef NEW_LOGGING LDAP_LOG ( OPERATION, RESULTS, "bdb_modrdn: rdn modified%s id=%08lx dn=\"%s\"\n", - op->o_noop ? " (no-op)" : "", e->e_id, e->e_dn ); + op->o_noop ? " (no-op)" : "", + e->e_id, e->e_dn ); #else Debug(LDAP_DEBUG_TRACE, "bdb_modrdn: rdn modified%s id=%08lx dn=\"%s\"\n", - op->o_noop ? " (no-op)" : "", e->e_id, e->e_dn ); + op->o_noop ? " (no-op)" : "", + e->e_id, e->e_dn ); #endif rs->sr_text = NULL; if( num_ctrls ) rs->sr_ctrls = ctrls; @@ -1106,5 +1106,5 @@ done: op->o_private = NULL; } - return ( ( rs->sr_err == LDAP_SUCCESS ) ? noop : rs->sr_err ); + return rs->sr_err; } diff --git a/servers/slapd/back-bdb/search.c b/servers/slapd/back-bdb/search.c index 98c23d2309..7223daecc0 100644 --- a/servers/slapd/back-bdb/search.c +++ b/servers/slapd/back-bdb/search.c @@ -386,7 +386,8 @@ bdb_do_search( Operation *op, SlapReply *rs, Operation *sop, ID lastid = NOID; AttributeName *attrs; - Filter contextcsnand, contextcsnle, cookief, csnfnot, csnfeq, csnfand, csnfge; + Filter contextcsnand, contextcsnle, cookief, csnfnot, + csnfeq, csnfand, csnfge; AttributeAssertion aa_ge, aa_eq, aa_le; int entry_count = 0; struct berval *search_context_csn = NULL; @@ -440,8 +441,10 @@ bdb_do_search( Operation *op, SlapReply *rs, Operation *sop, ldap_pvt_thread_rdwr_wlock( &bdb->bi_pslist_rwlock ); LDAP_LIST_INSERT_HEAD( &bdb->bi_psearch_list, sop, o_ps_link ); ldap_pvt_thread_rdwr_wunlock( &bdb->bi_pslist_rwlock ); + } else if ( !IS_PSEARCH && sop->o_sync_mode & SLAP_SYNC_REFRESH_AND_PERSIST - && sop->o_sync_slog_size >= 0 ) { + && sop->o_sync_slog_size >= 0 ) + { ldap_pvt_thread_rdwr_wlock( &bdb->bi_pslist_rwlock ); LDAP_LIST_FOREACH( ps_list, &bdb->bi_psearch_list, o_ps_link ) { if ( ps_list->o_sync_slog_size >= 0 ) { @@ -504,11 +507,13 @@ bdb_do_search( Operation *op, SlapReply *rs, Operation *sop, /* Sync control overrides manageDSAit */ if ( !IS_PSEARCH && sop->o_sync_mode & SLAP_SYNC_REFRESH ) { - if ( manageDSAit == SLAP_NO_CONTROL ) + if ( manageDSAit == SLAP_NO_CONTROL ) { manageDSAit = SLAP_CRITICAL_CONTROL; + } } else if ( IS_PSEARCH ) { - if ( manageDSAit == SLAP_NO_CONTROL ) + if ( manageDSAit == SLAP_NO_CONTROL ) { manageDSAit = SLAP_CRITICAL_CONTROL; + } } rs->sr_err = LOCK_ID (bdb->bi_dbenv, &locker ); @@ -534,9 +539,11 @@ dn2entry_retry: switch(rs->sr_err) { case DB_NOTFOUND: - matched = ei->bei_e; break; + matched = ei->bei_e; + break; case 0: - e = ei->bei_e; break; + e = ei->bei_e; + break; case LDAP_BUSY: send_ldap_error( sop, rs, LDAP_BUSY, "ldap server busy" ); LOCK_ID_FREE (bdb->bi_dbenv, locker ); @@ -736,16 +743,19 @@ dn2entry_retry: e = NULL; if ( !IS_PSEARCH ) { - rs->sr_err = bdb_get_commit_csn( sop, rs, &search_context_csn, locker, &ctxcsn_lock ); + rs->sr_err = bdb_get_commit_csn( sop, rs, &search_context_csn, + locker, &ctxcsn_lock ); if ( rs->sr_err != LDAP_SUCCESS ) { - send_ldap_error( sop, rs, rs->sr_err, "error in csn management in search" ); + send_ldap_error( sop, rs, rs->sr_err, + "error in csn management in search" ); goto done; } - if ( sop->o_sync_mode != SLAP_SYNC_NONE && sop->o_sync_state.ctxcsn && - sop->o_sync_state.ctxcsn->bv_val && - ber_bvcmp( &sop->o_sync_state.ctxcsn[0], search_context_csn ) == 0 ) + if ( sop->o_sync_mode != SLAP_SYNC_NONE && + sop->o_sync_state.ctxcsn && + sop->o_sync_state.ctxcsn->bv_val && + ber_bvcmp( &sop->o_sync_state.ctxcsn[0], search_context_csn ) == 0 ) { bdb_cache_entry_db_unlock( bdb->bi_dbenv, &ctxcsn_lock ); goto nochange; @@ -761,7 +771,8 @@ dn2entry_retry: } else { BDB_IDL_ZERO( candidates ); BDB_IDL_ZERO( scopes ); - rs->sr_err = search_candidates( op, sop, rs, &base, locker, candidates, scopes ); + rs->sr_err = search_candidates( op, sop, rs, &base, + locker, candidates, scopes ); } if ( !IS_PSEARCH ) { @@ -852,9 +863,8 @@ dn2entry_retry: goto loop_begin; } - if ( (sop->o_sync_mode & SLAP_SYNC_REFRESH) || IS_PSEARCH ) - { - int match; + if ( (sop->o_sync_mode & SLAP_SYNC_REFRESH) || IS_PSEARCH ) { + int match; cookief.f_choice = LDAP_FILTER_AND; cookief.f_and = &csnfnot; @@ -901,7 +911,8 @@ dn2entry_retry: mr = slap_schema.si_ad_entryCSN->ad_type->sat_ordering; if ( sop->o_sync_state.ctxcsn && - sop->o_sync_state.ctxcsn->bv_val != NULL ) { + sop->o_sync_state.ctxcsn->bv_val != NULL ) + { value_match( &match, slap_schema.si_ad_entryCSN, mr, SLAP_MR_VALUE_OF_ATTRIBUTE_SYNTAX, &sop->o_sync_state.ctxcsn[0], search_context_csn, @@ -931,7 +942,6 @@ loop_begin: goto done; } -#ifdef LDAP_EXOP_X_CANCEL if ( sop->o_cancel ) { assert( sop->o_cancel == SLAP_CANCEL_REQ ); rs->sr_err = LDAP_CANCELLED; @@ -940,7 +950,6 @@ loop_begin: rs->sr_err = LDAP_SUCCESS; goto done; } -#endif /* check time limit */ if ( sop->oq_search.rs_tlimit != -1 && slap_get_time() > stoptime ) { @@ -998,9 +1007,11 @@ id2entry_retry: rs->sr_entry = e; #ifdef BDB_SUBENTRIES - /* FIXME: send all but syncrepl - if ( !is_sync_protocol( sop ) ) { - */ + /* FIXME: send all but syncrepl */ +#if 0 + if ( !is_sync_protocol( sop ) ) +#endif + { if ( is_entry_subentry( e ) ) { if( sop->oq_search.rs_scope != LDAP_SCOPE_BASE ) { if(!get_subentries_visibility( sop )) { @@ -1019,10 +1030,8 @@ id2entry_retry: /* only subentries are visible */ goto loop_continue; } - /* } - */ -#endif +#endif /* BDB_SUBENTRIES */ /* Does this candidate actually satisfy the search scope? * @@ -1036,23 +1045,24 @@ id2entry_retry: switch( sop->ors_scope ) { case LDAP_SCOPE_BASE: /* This is always true, yes? */ - if ( id == base.e_id ) - scopeok = 1; + if ( id == base.e_id ) scopeok = 1; break; + case LDAP_SCOPE_ONELEVEL: - if ( ei->bei_parent->bei_id == base.e_id ) - scopeok = 1; + if ( ei->bei_parent->bei_id == base.e_id ) scopeok = 1; break; - case LDAP_SCOPE_SUBTREE: - { EntryInfo *tmp; + + case LDAP_SCOPE_SUBTREE: { + EntryInfo *tmp; for ( tmp = BEI(e); tmp->bei_parent; - tmp = tmp->bei_parent ) { + tmp = tmp->bei_parent ) + { if ( tmp->bei_id == base.e_id ) { scopeok = 1; break; } - } } - break; + } + } break; } #ifdef BDB_ALIASES @@ -1062,8 +1072,8 @@ id2entry_retry: * deref it when finding, return it. */ if ( is_entry_alias(e) && - ((sop->ors_deref & LDAP_DEREF_FINDING) - || !bvmatch(&e->e_nname, &op->o_req_ndn))) + ((sop->ors_deref & LDAP_DEREF_FINDING) || + !bvmatch(&e->e_nname, &op->o_req_ndn))) { goto loop_continue; } @@ -1079,10 +1089,8 @@ id2entry_retry: } else { /* subtree, walk up the tree */ EntryInfo *tmp = BEI(e); - for (;tmp->bei_parent; - tmp=tmp->bei_parent) { - x = bdb_idl_search( - scopes, tmp->bei_id ); + for (;tmp->bei_parent; tmp=tmp->bei_parent) { + x = bdb_idl_search( scopes, tmp->bei_id ); if ( scopes[x] == tmp->bei_id ) { scopeok = 1; break; @@ -1176,7 +1184,8 @@ id2entry_retry: if ( rs->sr_err == LDAP_COMPARE_TRUE ) { /* check size limit */ if ( --sop->oq_search.rs_slimit == -1 && - sop->o_sync_slog_size == -1 ) { + sop->o_sync_slog_size == -1 ) + { if (!IS_PSEARCH) { bdb_cache_return_entry_r( bdb->bi_dbenv, &bdb->bi_cache, e, &lock ); @@ -1203,11 +1212,6 @@ id2entry_retry: /* safe default */ int result = -1; -#if 0 /* noop is masked SLAP_CTRL_UPDATE */ - if( op->o_noop ) { - result = 0; - } else -#endif if (IS_PSEARCH) { int premodify_found = 0; int entry_sync_state; @@ -1581,9 +1585,7 @@ static void search_stack_free( void *key, void *data ) ber_memfree_x(data, NULL); } -static void *search_stack( - Operation *op -) +static void *search_stack( Operation *op ) { struct bdb_info *bdb = (struct bdb_info *) op->o_bd->be_private; void *ret = NULL; diff --git a/servers/slapd/back-sql/init.c b/servers/slapd/back-sql/init.c index c4fb088a51..46e89cd14b 100644 --- a/servers/slapd/back-sql/init.c +++ b/servers/slapd/back-sql/init.c @@ -55,9 +55,11 @@ sql_back_initialize( BackendInfo *bi ) { static char *controls[] = { +#if 0 /* needs updating */ #ifdef LDAP_CONTROL_NOOP LDAP_CONTROL_NOOP, #endif +#endif #ifdef LDAP_CONTROL_VALUESRETURNFILTER LDAP_CONTROL_VALUESRETURNFILTER, #endif diff --git a/servers/slapd/backend.c b/servers/slapd/backend.c index e90440a3ca..f781e676d4 100644 --- a/servers/slapd/backend.c +++ b/servers/slapd/backend.c @@ -904,27 +904,19 @@ backend_check_restrictions( break; } - { - if( bvmatch( opdata, &slap_EXOP_START_TLS ) ) { - session++; - starttls++; - break; - } + if( bvmatch( opdata, &slap_EXOP_START_TLS ) ) { + session++; + starttls++; + break; } - { - if( bvmatch( opdata, &slap_EXOP_WHOAMI ) ) { - break; - } + if( bvmatch( opdata, &slap_EXOP_WHOAMI ) ) { + break; } -#ifdef LDAP_EXOP_X_CANCEL - { - if ( bvmatch( opdata, &slap_EXOP_CANCEL ) ) { - break; - } + if ( bvmatch( opdata, &slap_EXOP_CANCEL ) ) { + break; } -#endif /* treat everything else as a modify */ opflag = SLAP_RESTRICT_OP_MODIFY; diff --git a/servers/slapd/cancel.c b/servers/slapd/cancel.c index 5dcea54114..65d5fe8ba5 100644 --- a/servers/slapd/cancel.c +++ b/servers/slapd/cancel.c @@ -25,8 +25,6 @@ #include "slap.h" -#ifdef LDAP_EXOP_X_CANCEL - #include #include @@ -127,5 +125,3 @@ int cancel_extop( Operation *op, SlapReply *rs ) return rc; } - -#endif /* LDAP_EXOP_X_CANCEL */ diff --git a/servers/slapd/connection.c b/servers/slapd/connection.c index 01b17e5886..9fe27be408 100644 --- a/servers/slapd/connection.c +++ b/servers/slapd/connection.c @@ -1105,7 +1105,6 @@ operations_error: #endif /* SLAPD_MONITOR */ ldap_pvt_thread_mutex_unlock( &num_ops_mutex ); -#ifdef LDAP_EXOP_X_CANCEL if ( op->o_cancel == SLAP_CANCEL_REQ ) { op->o_cancel = LDAP_TOO_LATE; } @@ -1115,7 +1114,6 @@ operations_error: { ldap_pvt_thread_yield(); } -#endif ldap_pvt_thread_mutex_lock( &conn->c_mutex ); diff --git a/servers/slapd/extended.c b/servers/slapd/extended.c index 83e9af4a8b..639b3b78ff 100644 --- a/servers/slapd/extended.c +++ b/servers/slapd/extended.c @@ -65,9 +65,7 @@ static SLAP_EXTOP_MAIN_FN whoami_extop; * just a way to get built-in extops onto the extop list without * having a separate init routine for each built-in extop. */ -#ifdef LDAP_EXOP_X_CANCEL const struct berval slap_EXOP_CANCEL = BER_BVC(LDAP_EXOP_X_CANCEL); -#endif const struct berval slap_EXOP_WHOAMI = BER_BVC(LDAP_EXOP_X_WHO_AM_I); const struct berval slap_EXOP_MODIFY_PASSWD = BER_BVC(LDAP_EXOP_MODIFY_PASSWD); const struct berval slap_EXOP_START_TLS = BER_BVC(LDAP_EXOP_START_TLS); @@ -77,9 +75,7 @@ static struct { slap_mask_t flags; SLAP_EXTOP_MAIN_FN *ext_main; } builtin_extops[] = { -#ifdef LDAP_EXOP_X_CANCEL { &slap_EXOP_CANCEL, SLAP_EXOP_HIDE, cancel_extop }, -#endif { &slap_EXOP_WHOAMI, 0, whoami_extop }, { &slap_EXOP_MODIFY_PASSWD, 0, passwd_extop }, #ifdef HAVE_TLS diff --git a/servers/slapd/proto-slap.h b/servers/slapd/proto-slap.h index 6227b18fcd..a81c5ebeab 100644 --- a/servers/slapd/proto-slap.h +++ b/servers/slapd/proto-slap.h @@ -505,9 +505,7 @@ LDAP_SLAPD_F (Entry *) entry_dup LDAP_P(( Entry *e )); */ LDAP_SLAPD_F (int) exop_root_dse_info LDAP_P ((Entry *e)); -#ifdef LDAP_EXOP_X_CANCEL LDAP_SLAPD_V( const struct berval ) slap_EXOP_CANCEL; -#endif LDAP_SLAPD_V( const struct berval ) slap_EXOP_WHOAMI; LDAP_SLAPD_V( const struct berval ) slap_EXOP_MODIFY_PASSWD; LDAP_SLAPD_V( const struct berval ) slap_EXOP_START_TLS; diff --git a/servers/slapd/result.c b/servers/slapd/result.c index 0a75e23024..23ba65a102 100644 --- a/servers/slapd/result.c +++ b/servers/slapd/result.c @@ -1255,7 +1255,7 @@ slap_send_search_entry( Operation *op, SlapReply *rs ) } if ( op->o_res_ber == NULL ) { - bytes = op->o_noop ? 0 : send_ldap_ber( op->o_conn, ber ); + bytes = send_ldap_ber( op->o_conn, ber ); ber_free_buf( ber ); if ( bytes < 0 ) { @@ -1476,7 +1476,7 @@ slap_send_search_reference( Operation *op, SlapReply *rs ) #ifdef LDAP_CONNECTIONLESS if (!op->o_conn || op->o_conn->c_is_udp == 0) { #endif - bytes = op->o_noop ? 0 : send_ldap_ber( op->o_conn, ber ); + bytes = send_ldap_ber( op->o_conn, ber ); ber_free_buf( ber ); ldap_pvt_thread_mutex_lock( &num_sent_mutex );