idnits 2.17.1 draft-ietf-ldapbis-filter-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 572. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 578), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([LDAPURL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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. -- The draft header indicates that this document obsoletes RFC2254, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (16 November 2004) is 7091 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) -- Looks like a reference, but probably isn't: '0' on line 119 -- Looks like a reference, but probably isn't: '1' on line 481 -- Looks like a reference, but probably isn't: '2' on line 129 -- Looks like a reference, but probably isn't: '3' on line 130 -- Looks like a reference, but probably isn't: '4' on line 131 -- Looks like a reference, but probably isn't: '5' on line 109 -- Looks like a reference, but probably isn't: '6' on line 110 -- Looks like a reference, but probably isn't: '7' on line 111 -- Looks like a reference, but probably isn't: '8' on line 112 -- Looks like a reference, but probably isn't: '9' on line 113 == Missing Reference: 'ISO 10646' is mentioned on line 401, but not defined -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AuthMeth' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Syntaxes' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- No information found for draft-ietf-ldapbis-url-xx - is the name correct? Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Smith, Editor 2 Request for Comments: DRAFT Pearl Crescent, LLC 3 Obsoletes: RFC 2254 T. Howes 4 Expires: 16 May 2005 Opsware, Inc. 5 16 November 2004 7 LDAP: String Representation of Search Filters 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she become 15 aware will be disclosed, in accordance with RFC 3668. 17 This document is intended to be published as a Standards Track RFC, 18 replacing RFC 2254. Distribution of this memo is unlimited. 19 Technical discussion of this document will take place on the IETF 20 LDAP (v3) Revision (ldapbis) Working Group mailing list 21 . Please send editorial comments directly 22 to the editor . 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than a "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Please see the Full Copyright section near the end of this document 42 for more information. 44 Abstract 46 LDAP search filters are transmitted in the LDAP protocol using a 47 binary representation that is appropriate for use on the network. 48 This document defines a human-readable string representation of LDAP 49 search filters that is appropriate for use in LDAP URLs [LDAPURL] and 50 in other applications. 52 Table of Contents 54 Status of this Memo............................................1 55 Abstract.......................................................2 56 Table of Contents..............................................2 57 1. Introduction...................................................2 58 2. LDAP Search Filter Definition..................................3 59 3. String Search Filter Definition................................4 60 4. Examples.......................................................6 61 5. Security Considerations........................................7 62 6. IANA Considerations............................................7 63 7. Normative References...........................................7 64 8. Informative References.........................................8 65 9. Acknowledgments................................................8 66 10. Authors' Addresses.............................................9 67 11. Appendix A: Changes Since RFC 2254.............................9 68 11.1. Technical Changes...........................................9 69 11.2. Editorial Changes...........................................10 70 12. Appendix B: Changes Since Previous Document Revision...........11 71 12.1. Technical Changes...........................................11 72 12.2. Editorial Changes...........................................12 73 Intellectual Property Rights...................................12 74 Full Copyright.................................................13 76 1. Introduction 78 The Lightweight Directory Access Protocol (LDAP) [Roadmap] defines a 79 network representation of a search filter transmitted to an LDAP 80 server. Some applications may find it useful to have a common way of 81 representing these search filters in a human-readable form; LDAP URLs 82 are an example of one such application. This document defines a 83 human-readable string format for representing the full range of 84 possible LDAP version 3 search filters, including extended match 85 filters. 87 This document is a integral part of the LDAP technical specification 88 [Roadmap] which obsoletes the previously defined LDAP technical 89 specification, RFC 3377, in its entirety. 91 This document replaces RFC 2254. Changes to RFC 2254 are summarized 92 in Appendix A. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in BCP 14 [RFC2119]. 98 2. LDAP Search Filter Definition 100 An LDAP search filter is defined in Section 4.5.1 of [Protocol] as 101 follows: 103 Filter ::= CHOICE { 104 and [0] SET SIZE (1..MAX) OF filter Filter, 105 or [1] SET SIZE (1..MAX) OF filter Filter, 106 not [2] Filter, 107 equalityMatch [3] AttributeValueAssertion, 108 substrings [4] SubstringFilter, 109 greaterOrEqual [5] AttributeValueAssertion, 110 lessOrEqual [6] AttributeValueAssertion, 111 present [7] AttributeDescription, 112 approxMatch [8] AttributeValueAssertion, 113 extensibleMatch [9] MatchingRuleAssertion } 115 SubstringFilter ::= SEQUENCE { 116 type AttributeDescription, 117 -- initial and final can occur at most once 118 substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { 119 initial [0] AssertionValue, 120 any [1] AssertionValue, 121 final [2] AssertionValue } } 123 AttributeValueAssertion ::= SEQUENCE { 124 attributeDesc AttributeDescription, 125 assertionValue AssertionValue } 127 MatchingRuleAssertion ::= SEQUENCE { 128 matchingRule [1] MatchingRuleId OPTIONAL, 129 type [2] AttributeDescription OPTIONAL, 130 matchValue [3] AssertionValue, 131 dnAttributes [4] BOOLEAN DEFAULT FALSE } 133 AttributeDescription ::= LDAPString 134 -- Constrained to 135 -- [Models] 137 AttributeValue ::= OCTET STRING 138 MatchingRuleId ::= LDAPString 140 AssertionValue ::= OCTET STRING 142 LDAPString ::= OCTET STRING -- UTF-8 encoded, 143 -- [Unicode] characters 145 The AttributeDescription, as defined in [Protocol], is a string 146 representation of the attribute description that is discussed in 147 [Models]. The AttributeValue and AssertionValue OCTET STRING have 148 the form defined in [Syntaxes]. The Filter is encoded for 149 transmission over a network using the Basic Encoding Rules (BER) 150 defined in [X.690], with simplifications described in [Protocol]. 152 3. String Search Filter Definition 154 The string representation of an LDAP search filter is a string of 155 UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined 156 by the following grammar, following the ABNF notation defined in 157 [RFC2234]. The productions used that are not defined here are 158 defined in section 1.4 (Common ABNF Productions) of [Models] unless 159 otherwise noted. The filter format uses a prefix notation. 161 filter = LPAREN filtercomp RPAREN 162 filtercomp = and / or / not / item 163 and = AMPERSAND filterlist 164 or = VERTBAR filterlist 165 not = EXCLAMATION filter 166 filterlist = 1*filter 167 item = simple / present / substring / extensible 168 simple = attr filtertype assertionvalue 169 filtertype = equal / approx / greaterorequal / lessorequal 170 equal = EQUALS 171 approx = TILDE EQUALS 172 greaterorequal = RANGLE EQUALS 173 lessorequal = LANGLE EQUALS 174 extensible = ( attr [dnattrs] 175 [matchingrule] COLON EQUALS assertionvalue ) 176 / ( [dnattrs] 177 matchingrule COLON EQUALS assertionvalue ) 178 present = attr EQUALS ASTERISK 179 substring = attr EQUALS [initial] any [final] 180 initial = assertionvalue 181 any = ASTERISK *(assertionvalue ASTERISK) 182 final = assertionvalue 183 attr = attributedescription 184 ; The attributedescription rule is defined in 185 ; Section 2.5 of [Models]. 187 dnattrs = COLON "dn" 188 matchingrule = COLON oid 189 assertionvalue = valueencoding 190 ; The rule is used to encode an 191 ; from Section 4.1.6 of [Protocol]. 192 valueencoding = 0*(normal / escaped) 193 normal = UTF1SUBSET / UTFMB 194 escaped = ESC HEX HEX 195 UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F 196 ; UTF1SUBSET excludes 0x00 (NUL), LPAREN, 197 ; RPAREN, ASTERISK, and ESC. 198 EXCLAMATION = %x21 ; exclamation mark ("!") 199 AMPERSAND = %x26 ; ampersand (or AND symbol) ("&") 200 ASTERISK = %x2A ; asterisk ("*") 201 COLON = %x3A ; colon (":") 202 VERTBAR = %x7C ; vertical bar (or pipe) ("|") 203 TILDE = %x7E ; tilde ("~") 205 Note that although both the and productions in 206 the grammar above can produce the "attr=*" construct, this construct 207 is used only to denote a presence filter. 209 The rule ensures that the entire filter string is a 210 valid UTF-8 string and provides that the octets that represent the 211 ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII 212 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a 213 backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits 214 representing the value of the encoded octet. 216 This simple escaping mechanism eliminates filter-parsing ambiguities 217 and allows any filter that can be represented in LDAP to be 218 represented as a NUL-terminated string. Other octets that are part of 219 the set may be escaped using this mechanism, for example, 220 non-printing ASCII characters. 222 For AssertionValues that contain UTF-8 character data, each octet of 223 the character to be escaped is replaced by a backslash and two hex 224 digits, which form a single octet in the code of the character. For 225 example, the filter checking whether the "cn" attribute contained a 226 value with the character "*" anywhere in it would be represented as 227 "(cn=*\2a*)". 229 As indicated by the rule, implementations MUST escape 230 all octets greater than 0x7F that are not part of a valid UTF-8 231 encoding sequence when they generate a string representation of a 232 search filter. Implementations SHOULD accept as input strings that 233 are not valid UTF-8 strings. This is necessary because RFC 2254 did 234 not clearly define the term "string representation" (and in 235 particular did not mention that the string representation of an LDAP 236 search filter is a string of UTF-8 encoded Unicode characters). 238 4. Examples 240 This section gives a few examples of search filters written using 241 this notation. 243 (cn=Babs Jensen) 244 (!(cn=Tim Howes)) 245 (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) 246 (o=univ*of*mich*) 247 (seeAlso=) 249 The following examples illustrate the use of extensible matching. 251 (cn:caseExactMatch:=Fred Flintstone) 252 (cn:=Betty Rubble) 253 (sn:dn:2.4.6.8.10:=Barney Rubble) 254 (o:dn:=Ace Industry) 255 (:1.2.3:=Wilma Flintstone) 256 (:DN:2.4.6.8.10:=Dino) 258 The first example shows use of the matching rule "caseExactMatch." 260 The second example demonstrates use of a MatchingRuleAssertion form 261 without a matchingRule. 263 The third example illustrates the use of the ":oid" notation to 264 indicate that matching rule identified by the OID "2.4.6.8.10" should 265 be used when making comparisons, and that the attributes of an 266 entry's distinguished name should be considered part of the entry 267 when evaluating the match (indicated by the use of ":dn"). 269 The fourth example denotes an equality match, except that DN 270 components should be considered part of the entry when doing the 271 match. 273 The fifth example is a filter that should be applied to any attribute 274 supporting the matching rule given (since the has been 275 omitted). 277 The sixth and final example is also a filter that should be applied 278 to any attribute supporting the matching rule given. Attributes 279 supporting the matching rule contained in the DN should also be 280 considered. 282 The following examples illustrate the use of the escaping mechanism. 284 (o=Parens R Us \28for all your parenthetical needs\29) 285 (cn=*\2A*) 286 (filename=C:\5cMyFile) 287 (bin=\00\00\00\04) 288 (sn=Lu\c4\8di\c4\87) 289 (1.3.6.1.4.1.1466.0=\04\02\48\69) 291 The first example shows the use of the escaping mechanism to 292 represent parenthesis characters. The second shows how to represent a 293 "*" in an assertion value, preventing it from being interpreted as a 294 substring indicator. The third illustrates the escaping of the 295 backslash character. 297 The fourth example shows a filter searching for the four octet value 298 00 00 00 04 (hex), illustrating the use of the escaping mechanism to 299 represent arbitrary data, including NUL characters. 301 The fifth example illustrates the use of the escaping mechanism to 302 represent various non-ASCII UTF-8 characters. Specifically, there are 303 5 characters in the portion of this example: LATIN 304 CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN SMALL 305 LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069), and 306 LATIN SMALL LETTER C WITH ACUTE (U+0107). 308 The sixth and final example demonstrates assertion of a BER encoded 309 value. 311 5. Security Considerations 313 This memo describes a string representation of LDAP search filters. 314 While the representation itself has no known security implications, 315 LDAP search filters do. They are interpreted by LDAP servers to 316 select entries from which data is retrieved. LDAP servers should 317 take care to protect the data they maintain from unauthorized access. 319 Please refer to the Security Considerations sections of [Protocol] 320 and [AuthMeth] for more information. 322 6. IANA Considerations 324 This document has no actions for IANA. 326 7. Normative References 328 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and 329 Connection Level Security Mechanisms", 330 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. 332 [Models] Zeilenga, K. (editor), "LDAP: Directory Information Models", 333 draft-ietf-ldapbis-models-xx.txt, a work in progress. 335 [Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 337 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 340 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 341 Specifications: ABNF", RFC 2234, November 1997. 343 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 344 RFC 3629, November 2003. 346 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road 347 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 349 [Syntaxes] Dally, K. (editor), "LDAP: Syntaxes", 350 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 352 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 353 3.2.0" is defined by "The Unicode Standard, Version 3.0" 354 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as 355 amended by the "Unicode Standard Annex #27: Unicode 3.1" 356 (http://www.unicode.org/reports/tr27/) and by the "Unicode 357 Standard Annex #28: Unicode 3.2." 359 8. Informative References 361 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", 362 draft-ietf-ldapbis-url-xx.txt, a work in progress. 364 [X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and 365 Distinguished Encoding Rules, ITU-T Recommendation X.690, 366 1994. 368 9. Acknowledgments 370 This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product 371 of the IETF ASID Working Group. 373 Changes included in this revised specification are based upon 374 discussions among the authors, discussions within the LDAP (v3) 375 Revision Working Group (ldapbis), and discussions within other IETF 376 Working Groups. The contributions of individuals in these working 377 groups is gratefully acknowledged. 379 10. Authors' Addresses 381 Mark Smith, Editor 382 Pearl Crescent, LLC 383 447 Marlpool Dr. 384 Saline, MI 48176 385 USA 386 +1 734 944-2856 387 mcs@pearlcrescent.com 389 Tim Howes 390 Opsware, Inc. 391 599 N. Mathilda Ave. 392 Sunnyvale, CA 94085 393 USA 394 +1 408 744-7509 395 howes@opsware.com 397 11. Appendix A: Changes Since RFC 2254 399 11.1. Technical Changes 401 Replaced [ISO 10646] reference with [Unicode]. 403 The following technical changes were made to the contents of the 404 "String Search Filter Definition" section: 406 Added statement that the string representation is a string of UTF-8 407 encoded Unicode characters. 409 Revised all of the ABNF to use common productions from [Models]. 411 Replaced the "value" rule with a new "assertionvalue" rule within the 412 "simple", "extensible", and "substring" ("initial", "any", and 413 "final") rules. This matches a change made in [Syntaxes]. 415 Added "(" and ")" around the components of the 416 subproductions for clarity. 418 Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more 419 precisely reference productions from the [Models] and [Protocol] 420 documents. 422 "String Search Filter Definition" section: replaced "greater" and 423 "less" with "greaterorequal" and "lessorequal" to avoid confusion. 425 Introduced the "valueencoding" and associated "normal" and "escaped" 426 rules to reduce the dependence on descriptive text. The "normal" 427 production restricts filter strings to valid UTF-8 sequences. 429 Added a statement about expected behavior in light of RFC 2254's lack 430 of a clear definition of "string representation." 432 11.2. Editorial Changes 434 Changed document title to include "LDAP:" prefix. 436 IESG Note: removed note about lack of satisfactory mandatory 437 authentication mechanisms. 439 Header and "Authors' Addresses" sections: added Mark Smith as the 440 document editor and updated affiliation and contact information. 442 "Table of Contents", "IANA Considerations", and "Intellectual 443 Property Rights" sections: added. 445 Copyright: updated per latest IETF guidelines. 447 "Abstract" section: separated from introductory material. 449 "Introduction" section: new section; separated from the Abstract. 450 Updated second paragraph to indicate that RFC 2254 is replaced by 451 this document (instead of RFC 1960). Added reference to the [Roadmap] 452 document. 454 "LDAP Search Filter Definition" section: made corrections to the LDAP 455 search filter ABNF so it matches that used in [Protocol]. 457 Clarified the definition of 'value' (now 'assertionvalue') to take 458 into account the fact that it is not precisely an AttributeAssertion 459 from [Protocol] section 4.1.6 (special handling is required for some 460 characters). Added a note that each octet of a character to be 461 escaped is replaced by a backslash and two hex digits, which 462 represent a single octet. 464 "Examples" section: added four additional examples: (seeAlso=), 465 (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and 466 (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a 467 value" with "an assertion value". Corrected the description of this 468 example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID 469 in the first extensible match example with "caseExactMatch" to 470 demonstrate use of the descriptive form. Used "DN" (uppercase) in 471 the last extensible match example to remind the reader to treat the 472 production as case insensitive. Reworded the description 473 of the fourth escaping mechanism example to avoid making assumptions 474 about byte order. Added text to the fifth escaping mechanism example 475 to spell out what the non-ASCII characters are in Unicode terms. 477 "Security Considerations" section: added references to [Protocol] and 478 [AuthMeth]. 480 "Normative References" section: renamed from "References" per new RFC 481 guidelines. Changed from [1] style to [Protocol] style throughout the 482 document. Added entries for [Unicode], [RFC2119], [AuthMeth], 483 [Models], and [Roadmap] and updated the UTF-8 reference. Replaced 484 RFC 822 reference with a reference to RFC 2234. 486 "Informative References" section: (new section) moved [X.690] to this 487 section. Added a reference to [LDAPURL]. 489 "Acknowledgments" section: added. 491 "Appendix A: Changes Since RFC 2254" section: added. 493 "Appendix B: Changes Since Previous Document Revision" section: 494 added. 496 Surrounded the names of all ABNF productions with "<" and ">" where 497 they are used in descriptive text. 499 Replaced all occurrences of "LDAPv3" with "LDAP." 501 12. Appendix B: Changes Since Previous Document Revision 503 This appendix lists all changes relative to the previously published 504 revision, draft-ietf-ldapbis-filter-08.txt. Note that when 505 appropriate these changes are also included in Appendix A, but are 506 also included here for the benefit of the people who have already 507 reviewed draft-ietf-ldapbis-filter-08.txt. This section will be 508 removed before this document is published as an RFC. 510 12.1. Technical Changes 512 Removed the third option from the "extensible" production that 513 allowed creation of a MatchingRuleAssertion that only had a 514 matchValue (disallowed By [Protocol]). Added "(" and ")" around the 515 components of the subproductions for clarity. 517 12.2. Editorial Changes 519 "Introduction" section: referenced [Roadmap] upon first use of LDAP 520 and expanded the paragraph that begins "This document is an integral 521 part of the LDAP technical specification..." to match the text used 522 in [Protocol]. 524 "LDAP Search Filter Definition" section: reworded the last paragraph 525 for clarity. 527 "Examples" section: Replaced the numeric OID in the first extensible 528 match example with "caseExactMatch" to demonstrate use of the 529 descriptive form. Used "DN" (uppercase) in the last extensible match 530 example to remind the reader to treat the production as 531 case insensitive. Reworded the description of the fourth escaping 532 mechanism example to avoid making assumptions about byte order. 533 Added text to the fifth escaping mechanism example to spell out what 534 the non-ASCII characters are in Unicode terms. 536 References: added [LDAPURL] and moved [X.690] to "Informative 537 References." 539 "Acknowledgements" section: added the sentence "RFC 2254 was a 540 product of the IETF ASID Working Group." 542 Changed these two sections to unnumbered ones: "Intellectual Property 543 Rights" and "Full Copyright." 545 Surrounded the names of all ABNF productions with "<" and ">" where 546 they are used in descriptive text. 548 Replaced all occurrences of "LDAPv3" with "LDAP." 550 Intellectual Property Rights 552 The IETF takes no position regarding the validity or scope of any 553 Intellectual Property Rights or other rights that might be claimed to 554 pertain to the implementation or use of the technology described in 555 this document or the extent to which any license under such rights 556 might or might not be available; nor does it represent that it has 557 made any independent effort to identify any such rights. Information 558 on the procedures with respect to rights in RFC documents can be 559 found in BCP 78 and BCP 79. 561 Copies of IPR disclosures made to the IETF Secretariat and any 562 assurances of licenses to be made available, or the result of an 563 attempt made to obtain a general license or permission for the use of 564 such proprietary rights by implementers or users of this 565 specification can be obtained from the IETF on-line IPR repository at 566 http://www.ietf.org/ipr. 568 The IETF invites any interested party to bring to its attention any 569 copyrights, patents or patent applications, or other proprietary 570 rights that may cover technology that may be required to implement 571 this standard. Please address the information to the IETF at 572 ietf-ipr@ietf.org. 574 Full Copyright 576 Copyright (C) The Internet Society (2004). This document is subject 577 to the rights, licenses and restrictions contained in BCP 78, and 578 except as set forth therein, the authors retain all their rights. 580 This document and the information contained herein are provided on an 581 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 582 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 583 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 584 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 585 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 586 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 588 This Internet Draft expires on 16 May 2005.