idnits 2.17.1 draft-ietf-ldapbis-filter-07.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 3667, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 529. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 535), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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? ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (13 July 2004) is 7226 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 113 -- Looks like a reference, but probably isn't: '1' on line 461 -- Looks like a reference, but probably isn't: '2' on line 123 -- Looks like a reference, but probably isn't: '3' on line 124 -- Looks like a reference, but probably isn't: '4' on line 125 -- Looks like a reference, but probably isn't: '5' on line 103 -- Looks like a reference, but probably isn't: '6' on line 104 -- Looks like a reference, but probably isn't: '7' on line 105 -- Looks like a reference, but probably isn't: '8' on line 106 -- Looks like a reference, but probably isn't: '9' on line 107 == Missing Reference: 'ISO 10646' is mentioned on line 486, 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' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 29 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: 13 January 2005 Opsware, Inc. 5 13 July 2004 7 LDAP: String Representation of Search Filters 8 10 Status of this Memo 12 This document is intended to be published as a Standard Track RFC, 13 replacing RFC 2254. Distribution of this memo is unlimited. 14 Technical discussion of this document will take place on the IETF 15 LDAP (v3) Revision (ldapbis) Working Group mailing list 16 . Please send editorial comments directly 17 to the editor . 19 By submitting this Internet-Draft, I accept the provisions of Section 20 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 21 applicable patent or other IPR claims of which I am aware have been 22 disclosed, and any of which I become aware will be disclosed, in 23 accordance with RFC 3668. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than a "work in progress." 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Please see the Full Copyright section near the end of this document 37 for more information. 39 Abstract 41 LDAP search filters are transmitted in the LDAP protocol using a 42 binary representation that is appropriate for use on the network. 43 This document defines a human-readable string representation of LDAP 44 search filters that is appropriate for use in LDAP URLs and in other 45 applications. 47 Table of Contents 49 Status of this Memo............................................1 50 Abstract.......................................................1 51 Table of Contents..............................................2 52 1. Introduction...................................................2 53 2. LDAP Search Filter Definition..................................3 54 3. String Search Filter Definition................................4 55 4. Examples.......................................................6 56 5. Security Considerations........................................7 57 6. IANA Considerations............................................7 58 7. Normative References...........................................7 59 8. Informative References.........................................8 60 9. Acknowledgments................................................8 61 10. Authors' Addresses.............................................8 62 11. Appendix A: Changes Since RFC 2254.............................9 63 11.1. Technical Changes...........................................9 64 11.2. Editorial Changes...........................................10 65 12. Appendix B: Changes Since Previous Document Revision...........11 66 12.1. Technical Changes...........................................11 67 12.2. Editorial Changes...........................................11 68 13. Intellectual Property Rights...................................12 69 14. Full Copyright.................................................12 71 1. Introduction 73 The Lightweight Directory Access Protocol (LDAP) [Protocol] defines a 74 network representation of a search filter transmitted to an LDAP 75 server. Some applications may find it useful to have a common way of 76 representing these search filters in a human-readable form; LDAP URLs 77 are an example of one such application. This document defines a 78 human-readable string format for representing the full range of 79 possible LDAP version 3 search filters, including extended match 80 filters. 82 This document is an integral part of the LDAP Technical 83 Specification [Roadmap]. 85 This document replaces RFC 2254. Changes to RFC 2254 are summarized 86 in Appendix A. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in BCP 14 [RFC2119]. 92 2. LDAP Search Filter Definition 94 An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as 95 follows: 97 Filter ::= CHOICE { 98 and [0] SET SIZE (1..MAX) OF filter Filter, 99 or [1] SET SIZE (1..MAX) OF filter Filter, 100 not [2] Filter, 101 equalityMatch [3] AttributeValueAssertion, 102 substrings [4] SubstringFilter, 103 greaterOrEqual [5] AttributeValueAssertion, 104 lessOrEqual [6] AttributeValueAssertion, 105 present [7] AttributeDescription, 106 approxMatch [8] AttributeValueAssertion, 107 extensibleMatch [9] MatchingRuleAssertion } 109 SubstringFilter ::= SEQUENCE { 110 type AttributeDescription, 111 -- initial and final can occur at most once 112 substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { 113 initial [0] AssertionValue, 114 any [1] AssertionValue, 115 final [2] AssertionValue } } 117 AttributeValueAssertion ::= SEQUENCE { 118 attributeDesc AttributeDescription, 119 assertionValue AssertionValue } 121 MatchingRuleAssertion ::= SEQUENCE { 122 matchingRule [1] MatchingRuleId OPTIONAL, 123 type [2] AttributeDescription OPTIONAL, 124 matchValue [3] AssertionValue, 125 dnAttributes [4] BOOLEAN DEFAULT FALSE } 127 AttributeDescription ::= LDAPString 128 -- Constrained to 129 -- [Models] 131 AttributeValue ::= OCTET STRING 133 MatchingRuleId ::= LDAPString 135 AssertionValue ::= OCTET STRING 137 LDAPString ::= OCTET STRING -- UTF-8 encoded, 138 -- [Unicode] characters 140 The AttributeDescription is a string representation of the attribute 141 description and is defined in [Protocol]. The AttributeValue and 142 AssertionValue OCTET STRING have the form defined in [Syntaxes]. The 143 Filter is encoded for transmission over a network using the Basic 144 Encoding Rules (BER) defined in [X.690], with simplifications 145 described in [Protocol]. 147 3. String Search Filter Definition 149 The string representation of an LDAP search filter is a string of 150 UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined 151 by the following grammar, following the ABNF notation defined in 152 [RFC2234]. The productions used that are not defined here are 153 defined in section 1.4 (Common ABNF Productions) of [Models] unless 154 otherwise noted. The filter format uses a prefix notation. 156 filter = LPAREN filtercomp RPAREN 157 filtercomp = and / or / not / item 158 and = AMPERSAND filterlist 159 or = VERTBAR filterlist 160 not = EXCLAMATION filter 161 filterlist = 1*filter 162 item = simple / present / substring / extensible 163 simple = attr filtertype assertionvalue 164 filtertype = equal / approx / greaterorequal / lessorequal 165 equal = EQUALS 166 approx = TILDE EQUALS 167 greaterorequal = RANGLE EQUALS 168 lessorequal = LANGLE EQUALS 169 extensible = attr [dnattrs] 170 [matchingrule] COLON EQUALS assertionvalue 171 / [dnattrs] 172 matchingrule COLON EQUALS assertionvalue 173 / COLON EQUALS assertionvalue 174 present = attr EQUALS ASTERISK 175 substring = attr EQUALS [initial] any [final] 176 initial = assertionvalue 177 any = ASTERISK *(assertionvalue ASTERISK) 178 final = assertionvalue 179 attr = attributedescription 180 ; The attributedescription rule is defined in 181 ; Section 2.5 of [Models]. 182 dnattrs = COLON "dn" 183 matchingrule = COLON oid 184 assertionvalue = valueencoding 185 ; The rule is used to encode an 186 ; from Section 4.1.6 of [Protocol]. 187 valueencoding = 0*(normal / escaped) 188 normal = UTF1SUBSET / UTFMB 189 escaped = ESC HEX HEX 190 UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F 191 ; UTF1SUBSET excludes 0x00 (NUL), LPAREN, 192 ; RPAREN, ASTERISK, and ESC. 193 EXCLAMATION = %x21 ; exclamation mark ("!") 194 AMPERSAND = %x26 ; ampersand (or AND symbol) ("&") 195 ASTERISK = %x2A ; asterisk ("*") 196 COLON = %x3A ; colon (":") 197 VERTBAR = %x7C ; vertical bar (or pipe) ("|") 198 TILDE = %x7E ; tilde ("~") 200 Note that although both the and productions in 201 the grammar above can produce the "attr=*" construct, this construct 202 is used only to denote a presence filter. 204 The rule ensures that the entire filter string is a 205 valid UTF-8 string and provides that the octets that represent the 206 ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII 207 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a 208 backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits 209 representing the value of the encoded octet. 211 This simple escaping mechanism eliminates filter-parsing ambiguities 212 and allows any filter that can be represented in LDAP to be 213 represented as a NUL-terminated string. Other octets that are part of 214 the set may be escaped using this mechanism, for example, 215 non-printing ASCII characters. 217 For AssertionValues that contain UTF-8 character data, each octet of 218 the character to be escaped is replaced by a backslash and two hex 219 digits, which form a single octet in the code of the character. 221 For example, the filter checking whether the "cn" attribute contained 222 a value with the character "*" anywhere in it would be represented as 223 "(cn=*\2a*)". 225 As indicated by the valueencoding rule, implementations MUST escape 226 all octets greater than 0x7F that are not part of a valid UTF-8 227 encoding sequence when they generate a string representation of a 228 search filter. Implementations SHOULD accept as input strings that 229 are not valid UTF-8 strings. This is necessary because RFC 2254 did 230 not clearly define the term "string representation" (and in 231 particular did not mention that the string representation of an LDAP 232 search filter is a string of UTF-8 encoded Unicode characters). 234 4. Examples 236 This section gives a few examples of search filters written using 237 this notation. 239 (cn=Babs Jensen) 240 (!(cn=Tim Howes)) 241 (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) 242 (o=univ*of*mich*) 243 (seeAlso=) 245 The following examples illustrate the use of extensible matching. 247 (cn:1.2.3.4.5:=Fred Flintstone) 248 (cn:=Betty Rubble) 249 (sn:dn:2.4.6.8.10:=Barney Rubble) 250 (o:dn:=Ace Industry) 251 (:1.2.3:=Wilma Flintstone) 252 (:dn:2.4.6.8.10:=Dino) 254 The first example shows use of the matching rule "1.2.3.4.5". 256 The second example demonstrates use of a MatchingRuleAssertion form 257 without a matchingRule. 259 The third example illustrates the use of the ":oid" notation to 260 indicate that matching rule "2.4.6.8.10" should be used when making 261 comparisons, and that the attributes of an entry's distinguished name 262 should be considered part of the entry when evaluating the match 263 (indicated by the use of ":dn"). 265 The fourth example denotes an equality match, except that DN 266 components should be considered part of the entry when doing the 267 match. 269 The fifth example is a filter that should be applied to any attribute 270 supporting the matching rule given (since the attr has been omitted). 272 The sixth and final example is also a filter that should be applied 273 to any attribute supporting the matching rule given. Attributes 274 supporting the matching rule contained in the DN should also be 275 considered. 277 The following examples illustrate the use of the escaping mechanism. 279 (o=Parens R Us \28for all your parenthetical needs\29) 280 (cn=*\2A*) 281 (filename=C:\5cMyFile) 282 (bin=\00\00\00\04) 283 (sn=Lu\c4\8di\c4\87) 284 (1.3.6.1.4.1.1466.0=\04\02\48\69) 286 The first example shows the use of the escaping mechanism to 287 represent parenthesis characters. The second shows how to represent a 288 "*" in an assertion value, preventing it from being interpreted as a 289 substring indicator. The third illustrates the escaping of the 290 backslash character. 292 The fourth example shows a filter searching for the four-byte value 293 0x00000004, illustrating the use of the escaping mechanism to 294 represent arbitrary data, including NUL characters. 296 The fifth example illustrates the use of the escaping mechanism to 297 represent various non-ASCII UTF-8 characters. 299 The sixth and final example demonstrates assertion of a BER encoded 300 value. 302 5. Security Considerations 304 This memo describes a string representation of LDAP search filters. 305 While the representation itself has no known security implications, 306 LDAP search filters do. They are interpreted by LDAP servers to 307 select entries from which data is retrieved. LDAP servers should 308 take care to protect the data they maintain from unauthorized access. 310 Please refer to the Security Considerations sections of [Protocol] 311 and [AuthMeth] for more information. 313 6. IANA Considerations 315 This document has no actions for IANA. 317 7. Normative References 319 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and 320 Connection Level Security Mechanisms", 321 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. 323 [Models] Zeilenga, K. (editor), "LDAP: Directory Information Models", 324 draft-ietf-ldapbis-models-xx.txt, a work in progress. 326 [Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 328 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 331 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 332 Specifications: ABNF", RFC 2234, November 1997. 334 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 335 RFC 3629, November 2003. 337 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road 338 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 340 [Syntaxes] Dally, K. (editor), "LDAP: Syntaxes", 341 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 343 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 344 3.2.0" is defined by "The Unicode Standard, Version 3.0" 345 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as 346 amended by the "Unicode Standard Annex #27: Unicode 3.1" 347 (http://www.unicode.org/reports/tr27/) and by the "Unicode 348 Standard Annex #28: Unicode 3.2." 350 [X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and 351 Distinguished Encoding Rules, ITU-T Recommendation X.690, 352 1994. 354 8. Informative References 356 None. 358 9. Acknowledgments 360 This document replaces RFC 2254 by Tim Howes. Changes included in 361 this revised specification are based upon discussions among the 362 authors, discussions within the LDAP (v3) Revision Working Group 363 (ldapbis), and discussions within other IETF Working Groups. The 364 contributions of individuals in these working groups is gratefully 365 acknowledged. 367 10. Authors' Addresses 369 Mark Smith, Editor 370 Pearl Crescent, LLC 371 447 Marlpool Dr. 372 Saline, MI 48176 373 USA 374 +1 734 944-2856 375 mcs@pearlcrescent.com 376 Tim Howes 377 Opsware, Inc. 378 599 N. Mathilda Ave. 379 Sunnyvale, CA 94085 380 USA 381 +1 408 744-7509 382 howes@opsware.com 384 11. Appendix A: Changes Since RFC 2254 386 11.1. Technical Changes 388 Replaced [ISO 10646] reference with [Unicode]. 390 The following technical changes were made to the contents of the 391 "String Search Filter Definition" section: 393 Added statement that the string representation is a string of UTF-8 394 encoded Unicode characters. 396 Revised all of the ABNF to use common productions from [Models]. 398 Replaced the "value" rule with a new "assertionvalue" rule within the 399 "simple", "extensible", and "substring" ("initial", "any", and 400 "final") rules. This matches a change made in [Syntaxes]. 402 Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more 403 precisely reference productions from the [Models] and [Protocol] 404 documents. 406 "String Search Filter Definition" section: replaced "greater" and 407 "less" with "greaterorequal" and "lessorequal" to avoid confusion. 409 Introduced the "valueencoding" and associated "normal" and "escaped" 410 rules to reduce the dependence on descriptive text. The "normal" 411 production restricts filter strings to valid UTF-8 sequences. 413 Added a third option to the "extensible" production to allow creation 414 of a MatchingRuleAssertion that only has a matchValue. 416 Added a statement about expected behavior in light of RFC 2254's lack 417 of a clear definition of "string representation." 419 11.2. Editorial Changes 421 Changed document title to include "LDAP:" prefix. 423 IESG Note: removed note about lack of satisfactory mandatory 424 authentication mechanisms. 426 Header and "Authors' Addresses" sections: added Mark Smith as the 427 document editor and updated affiliation and contact information. 429 "Table of Contents", "IANA Considerations", and "Intellectual 430 Property Rights" sections: added. 432 Copyright: updated per latest IETF guidelines. 434 "Abstract" section: separated from introductory material. 436 "Introduction" section: new section; separated from the Abstract. 437 Updated second paragraph to indicate that RFC 2254 is replaced by 438 this document (instead of RFC 1960). Added reference to the [Roadmap] 439 document. 441 "LDAP Search Filter Definition" section: made corrections to the 442 LDAPv3 search filter ABNF so it matches that used in [Protocol]. 444 Clarified the definition of 'value' (now 'assertionvalue') to take 445 into account the fact that it is not precisely an AttributeAssertion 446 from [Protocol] section 4.1.6 (special handling is required for some 447 characters). Added a note that each octet of a character to be 448 escaped is replaced by a backslash and two hex digits, which 449 represent a single octet. 451 "Examples" section: added four additional examples: (seeAlso=), 452 (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and 453 (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a 454 value" with "an assertion value". Corrected the description of this 455 example: (sn:dn:2.4.6.8.10:=Barney Rubble). 457 "Security Considerations" section: added references to [Protocol] and 458 [AuthMeth]. 460 "Normative References" section: renamed from "References" per new RFC 461 guidelines. Changed from [1] style to [Protocol] style throughout the 462 document. Added entries for [Unicode], [RFC2119], [AuthMeth], 463 [Models], and [Roadmap] and updated the UTF-8 reference. Replaced 464 RFC 822 reference with a reference to RFC 2234. 466 "Informative References" section: added for clarity. 468 "Acknowledgments" section: added. 470 "Appendix A: Changes Since RFC 2254" section: added. 472 "Appendix B: Changes Since Previous Document Revision" section: 473 added. 475 12. Appendix B: Changes Since Previous Document Revision 477 This appendix lists all changes relative to the previously published 478 revision, draft-ietf-ldapbis-filter-06.txt. Note that when 479 appropriate these changes are also included in Appendix A, but are 480 also included here for the benefit of the people who have already 481 reviewed draft-ietf-ldapbis-filter-06.txt. This section will be 482 removed before this document is published as an RFC. 484 12.1. Technical Changes 486 Replaced [ISO 10646] reference with [Unicode]. 488 "String Search Filter Definition" section: replaced "greater" and 489 "less" with "greaterorequal" and "lessorequal" to avoid confusion. 490 Also, broke some long lines into two lines to avoid exceeding the 72 491 column limit. 493 12.2. Editorial Changes 495 "Status of this Memo", "Intellectual Property Rights", and "Full 496 Copyright" sections: updated to use boilerplate from RFC 3667 and RFC 497 3668. 499 "Status of this Memo", "Abstract" and "Table of Contents" sections: 500 removed section numbers. 502 "LDAP Search Filter Definition" section: added (BER) to the last 503 sentence. 505 "IANA Considerations" section: added. 507 13. Intellectual Property Rights 509 The IETF takes no position regarding the validity or scope of any 510 Intellectual Property Rights or other rights that might be claimed to 511 pertain to the implementation or use of the technology described in 512 this document or the extent to which any license under such rights 513 might or might not be available; nor does it represent that it has 514 made any independent effort to identify any such rights. Information 515 on the procedures with respect to rights in RFC documents can be 516 found in BCP 78 and BCP 79. 518 Copies of IPR disclosures made to the IETF Secretariat and any 519 assurances of licenses to be made available, or the result of an 520 attempt made to obtain a general license or permission for the use of 521 such proprietary rights by implementers or users of this 522 specification can be obtained from the IETF on-line IPR repository at 523 http://www.ietf.org/ipr. 525 The IETF invites any interested party to bring to its attention any 526 copyrights, patents or patent applications, or other proprietary 527 rights that may cover technology that may be required to implement 528 this standard. Please address the information to the IETF at 529 ietf-ipr@ietf.org. 531 14. Full Copyright 533 Copyright (C) The Internet Society (2004). This document is subject 534 to the rights, licenses and restrictions contained in BCP 78, and 535 except as set forth therein, the authors retain all their rights. 537 This document and the information contained herein are provided on an 538 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 539 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 540 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 541 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 542 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 543 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 545 This Internet Draft expires on 13 January 2005.