idnits 2.17.1 draft-ietf-asid-ldapv3-filter-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 3) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 76: '... matchingRule [1] MatchingRuleID OPTIONAL,...' RFC 2119 keyword, line 77: '... type [2] AttributeDescription OPTIONAL,...' == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...fts are worki...' == Line 12 has weird spacing: '...ments of the ...' == Line 13 has weird spacing: '...t other group...' == Line 17 has weird spacing: '...and may be ...' == Line 21 has weird spacing: '...atus of any ...' == (33 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1997) is 9905 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 223 looks like a reference -- Missing reference section? '0' on line 64 looks like a reference -- Missing reference section? '2' on line 227 looks like a reference -- Missing reference section? '3' on line 231 looks like a reference -- Missing reference section? '4' on line 234 looks like a reference -- Missing reference section? '5' on line 54 looks like a reference -- Missing reference section? '6' on line 55 looks like a reference -- Missing reference section? '7' on line 56 looks like a reference -- Missing reference section? '8' on line 57 looks like a reference -- Missing reference section? '9' on line 58 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tim Howes 2 INTERNET DRAFT Netscape Communications Corp. 3 OBSOLETES: RFC 1960 March 1997 4 Expire in six months 6 The String Representation of LDAP Search Filters 7 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference material 19 or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 2. Abstract 28 The Lightweight Directory Access Protocol (LDAP) [1] defines a network 29 representation of a search filter transmitted to an LDAP server. Some 30 applications may find it useful to have a common way of representing 31 these search filters in a human-readable form. This document defines a 32 human-readable string format for representing LDAP search filters. 34 This document replaces RFC 1960, extending the string LDAP filter defin- 35 ition to include support for LDAP version 3 extended match filters, and 36 including support for representing the full range of possible LDAP 37 search filters. 39 3. LDAP Search Filter Definition 41 An LDAPv3 search filter is defined in [1] as follows: 43 Filter ::=3D CHOICE { 44 and [0] SET OF Filter, 45 or [1] SET OF Filter, 46 not [2] Filter, 48 =0C 50 RFC DRAFT March 1997 52 equalityMatch [3] AttributeValueAssertion, 53 substrings [4] SubstringFilter, 54 greaterOrEqual [5] AttributeValueAssertion, 55 lessOrEqual [6] AttributeValueAssertion, 56 present [7] AttributeDescription, 57 approxMatch [8] AttributeValueAssertion, 58 extensibleMatch [9] MatchingRuleAssertion 59 } 61 SubstringFilter ::=3D SEQUENCE { 62 type AttributeDescription, 63 SEQUENCE OF CHOICE { 64 initial [0] LDAPString, 65 any [1] LDAPString, 66 final [2] LDAPString 67 } 68 } 70 AttributeValueAssertion ::=3D SEQUENCE { 71 attributeDesc AttributeDescription, 72 attributeValue AttributeValue 73 } 75 MatchingRuleAssertion ::=3D SEQUENCE { 76 matchingRule [1] MatchingRuleID OPTIONAL, 77 type [2] AttributeDescription OPTIONAL, 78 matchValue [3] AssertionValue, 79 dnAttributes [4] BOOLEAN DEFAULT FALSE 80 } 82 AttributeDescription ::=3D LDAPString 84 AttributeValue ::=3D OCTET STRING 86 MatchingRuleID ::=3D LDAPString 88 AssertionValue ::=3D OCTET STRING 90 LDAPString ::=3D OCTET STRING 92 where the LDAPString above is limited to the UTF-8 encoding of the ISO 93 10646 [4] character set. The AttributeDescription is a string represen- 94 tation of the attribute description name and is defined in [1]. The 95 AttributeValue and AssertionValue OCTET STRING have the form defined in 96 [2]. The Filter is encoded for transmission over a network using the 97 Basic Encoding Rules defined in [3], with simplifications described in 98 [1]. 100 =0C 102 RFC DRAFT March 1997 104 4. String Search Filter Definition 106 The string representation of an LDAP search filter is defined by the 107 following grammar. The filter format uses a prefix notation. 109 ::=3D '(' ')' 110 ::=3D | | | 111 ::=3D '&' 112 ::=3D '|' 113 ::=3D '!' 114 ::=3D | 115 ::=3D | | | 116 ::=3D 117 ::=3D | | | 118 ::=3D '=3D' 119 ::=3D '~=3D' 120 ::=3D '>=3D' 121 ::=3D '<=3D' 122 ::=3D ( NULL | ) [ ':dn' ] [ ':' = 123 ] 124 ':=3D' 125 ::=3D | 126 ::=3D 127 ::=3D 128 ::=3D '=3D*' 129 ::=3D '=3D' 130 ::=3D NULL | 131 ::=3D '*' 132 ::=3D NULL | '*' 133 ::=3D NULL | 135 is a string representing an AttributeDescription, and has the 136 format defined in [1]. is a string representing an Attribu- 137 teValue, or part of one, and has the form defined in [2]. 139 If a should contain any of the characters '*' (ASCII 0x2a) or 140 0x00), the character must be encoded as the backslash '\' character fol- 141 lowed by the two hexadecimal digits representing the encoded character. 143 This simple escaping mechanism eliminates filter-parsing ambiguities and 144 allows the construction of any filter that can be represented in LDAP. 145 The case of the two hexadecimal digits is not significant. Other charac- 146 ters besides the ones listed above may be escaped using this mechanism, 147 for example, non-printing characters. 149 For example, the filter checking whether the "cn" attribute contained a 150 value with the character "*" anywhere in it would be represented as 151 "(cn=3D*2a*)". 153 =0C 155 RFC DRAFT March 1997 157 Note that although both the and productions can 158 produce the 'attr=3D*' construct, this construct is used only to denote = 159 a 160 presence filter. 162 is a dotted string representation of an object identifier (e.g., 163 "1.2.3.4") identifying a matching rule to use when comparing . 164 is a name given to a matching rule, as defined in 165 [2]. One of or is required in the 166 production. 168 5. Examples 170 This section gives a few examples of search filters written using this 171 notation. 173 (cn=3DBabs Jensen) 174 (!(cn=3DTim Howes)) 175 (&(objectClass=3DPerson)(|(sn=3DJensen)(cn=3DBabs J*))) 176 (o=3Duniv*of*mich*) 178 The following examples illustrate the use of extensible matching. 180 (cn:1.2.3.4.5:=3DFred Flintstone) 181 (sn:dn:2.4.6.8.10:=3DBarney Rubble) 182 (o:dn:=3DAce Industry) 184 The second example illustrates the use of the ":dn" notation to indicate 185 that matching rule "2.4.6.8.10" should be used when making comparisons, 186 and that the attributes of an entry's distinguished name should be con- 187 sidered part of the entry when evaluating the match. 189 The third example denotes an equality match, except that DN components 190 should be considered part of the entry when doing the match. 192 The following examples illustrate the use of the escaping mechanism. 194 (o=3DParens R Us \28for all your parenthetical needs\29) 195 (cn=3D*\2A*) 196 (filename=3DC:\5cMyFile) 197 (bin=3D\00\00\00\04) 198 (sn=3DLu\c4\8di\c4\c7) 200 The first example shows the use of the escaping mechanism to represent 201 parenthesis characters. The second shows how to represent a "*" in a 202 value, preventing it from being interpreted as a substring indicator. 203 The third illustrates the escaping of the backslash character. 205 The fourth example shows a filter searching for the four-byte value 207 =0C 209 RFC DRAFT March 1997 211 0x00000004, illustrating the use of the escaping mechanism to represent 212 arbitrary data, including NUL characters. 214 The final example illustrates the use of the escaping mechanism to 215 represent various non-printing UTF-8 characters. 217 6. Security Considerations 219 Security considerations are not discussed in this document. 221 7. Bibliography 223 [1] Lightweight Directory Access Protocol (v3), M. Wahl, T. Howes, S. 224 Kille, Internet Draft draft-ietf-asid-ldapv3-protocol-04.txt, 225 March, 1997. 227 [2] Lightweight Directory Access Protocol (v3): Attribute Syntax Defin- 228 itions, M. Wahl, A. Coulbeck, T. Howes, S. Kille, Internet Draft 229 draft-ietf-asid-ldapv3-attributes-04.txt, March, 1997. 231 [3] Specification of ASN.1 encoding rules: Basic, Canonical, and Dis- 232 tinguished Encoding Rules, ITU-T Recommendation X.690, 1994. 234 [4] Universal Multiple-Octet Coded Character Set (UCS) - Architecture 235 and Basic Multilingual Plane, ISO/ IEC 10646-1, 1993. 237 8. Author's Address 239 Tim Howes 240 Netscape Communications Corp. 241 501 E. Middlefield Road 242 Mountain View, CA 94043 243 USA 244 +1 415 937-3419 245 howes@netscape.com