idnits 2.17.1 draft-ietf-ldapbis-filter-06.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 7 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == 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 February 2004) is 7377 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 110 -- Looks like a reference, but probably isn't: '1' on line 496 -- Looks like a reference, but probably isn't: '2' on line 120 -- Looks like a reference, but probably isn't: '3' on line 121 -- Looks like a reference, but probably isn't: '4' on line 122 -- Looks like a reference, but probably isn't: '5' on line 100 -- Looks like a reference, but probably isn't: '6' on line 101 -- Looks like a reference, but probably isn't: '7' on line 102 -- Looks like a reference, but probably isn't: '8' on line 103 -- Looks like a reference, but probably isn't: '9' on line 104 == Missing Reference: 'UTF-8' is mentioned on line 528, 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' -- 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' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 24 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 August 2004 Opsware, Inc. 5 13 February 2004 7 LDAP: String Representation of Search Filters 8 10 1. Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Discussion of this document should take place on the LDAP (v3) 32 Revision (ldapbis) Working Group mailing list . 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 2. Abstract 39 LDAP search filters are transmitted in the LDAP protocol using a 40 binary representation that is appropriate for use on the network. 41 This document defines a human-readable string representation of LDAP 42 search filters that is appropriate for use in LDAP URLs and in other 43 applications. 45 3. Table of Contents 47 1. Status of this Memo............................................1 48 2. Abstract.......................................................1 49 3. Table of Contents..............................................2 50 4. Introduction...................................................2 51 5. LDAP Search Filter Definition..................................2 52 6. String Search Filter Definition................................4 53 7. Examples.......................................................5 54 8. Security Considerations........................................7 55 9. Normative References...........................................7 56 10. Informative References.........................................8 57 11. Intellectual Property Rights...................................8 58 12. Acknowledgments................................................8 59 13. Authors' Addresses.............................................9 60 14. Full Copyright Statement.......................................9 61 15. Appendix A: Changes Since RFC 2254.............................10 62 15.1. Technical Changes...........................................10 63 15.2. Editorial Changes...........................................10 64 16. Appendix B: Changes Since Previous Document Revision...........11 65 16.1. Technical Changes...........................................12 66 16.2. Editorial Changes...........................................12 68 4. Introduction 70 The Lightweight Directory Access Protocol (LDAP) [Protocol] defines a 71 network representation of a search filter transmitted to an LDAP 72 server. Some applications may find it useful to have a common way of 73 representing these search filters in a human-readable form; LDAP URLs 74 are an example of one such application. This document defines a 75 human-readable string format for representing the full range of 76 possible LDAP version 3 search filters, including extended match 77 filters. 79 This document is an integral part of the LDAP Technical 80 Specification [Roadmap]. 82 This document replaces RFC 2254. Changes to RFC 2254 are summarized 83 in Appendix A. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in BCP 14 [RFC2119]. 89 5. LDAP Search Filter Definition 91 An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as 92 follows: 94 Filter ::= CHOICE { 95 and [0] SET SIZE (1..MAX) OF filter Filter, 96 or [1] SET SIZE (1..MAX) OF filter Filter, 97 not [2] Filter, 98 equalityMatch [3] AttributeValueAssertion, 99 substrings [4] SubstringFilter, 100 greaterOrEqual [5] AttributeValueAssertion, 101 lessOrEqual [6] AttributeValueAssertion, 102 present [7] AttributeDescription, 103 approxMatch [8] AttributeValueAssertion, 104 extensibleMatch [9] MatchingRuleAssertion } 106 SubstringFilter ::= SEQUENCE { 107 type AttributeDescription, 108 -- initial and final can occur at most once 109 substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { 110 initial [0] AssertionValue, 111 any [1] AssertionValue, 112 final [2] AssertionValue } } 114 AttributeValueAssertion ::= SEQUENCE { 115 attributeDesc AttributeDescription, 116 assertionValue AssertionValue } 118 MatchingRuleAssertion ::= SEQUENCE { 119 matchingRule [1] MatchingRuleId OPTIONAL, 120 type [2] AttributeDescription OPTIONAL, 121 matchValue [3] AssertionValue, 122 dnAttributes [4] BOOLEAN DEFAULT FALSE } 124 AttributeDescription ::= LDAPString 125 -- Constrained to 126 -- [Models] 128 AttributeValue ::= OCTET STRING 130 MatchingRuleId ::= LDAPString 132 AssertionValue ::= OCTET STRING 134 LDAPString ::= OCTET STRING -- UTF-8 encoded, 135 -- [ISO10646] characters 137 The AttributeDescription is a string representation of the attribute 138 description and is defined in [Protocol]. The AttributeValue and 139 AssertionValue OCTET STRING have the form defined in [Syntaxes]. The 140 Filter is encoded for transmission over a network using the Basic 141 Encoding Rules defined in [X.690], with simplifications described in 143 [Protocol]. 145 6. String Search Filter Definition 147 The string representation of an LDAP search filter is a string of 148 UTF-8[RFC3629] encoded ISO 10646-1 characters that is defined by the 149 following grammar, following the ABNF notation defined in [RFC2234]. 150 The productions used that are not defined here are defined in section 151 1.4 (Common ABNF Productions) of [Models] unless otherwise noted. 152 The filter format uses a prefix notation. 154 filter = LPAREN filtercomp RPAREN 155 filtercomp = and / or / not / item 156 and = AMPERSAND filterlist 157 or = VERTBAR filterlist 158 not = EXCLAMATION filter 159 filterlist = 1*filter 160 item = simple / present / substring / extensible 161 simple = attr filtertype assertionvalue 162 filtertype = equal / approx / greater / less 163 equal = EQUALS 164 approx = TILDE EQUALS 165 greater = RANGLE EQUALS 166 less = LANGLE EQUALS 167 extensible = attr [dnattrs] [matchingrule] COLON EQUALS assertionvalue 168 / [dnattrs] matchingrule COLON EQUALS assertionvalue 169 / COLON EQUALS assertionvalue 170 present = attr EQUALS ASTERISK 171 substring = attr EQUALS [initial] any [final] 172 initial = assertionvalue 173 any = ASTERISK *(assertionvalue ASTERISK) 174 final = assertionvalue 175 attr = attributedescription 176 ; The attributedescription rule is defined in 177 ; Section 2.5 of [Models]. 178 dnattrs = COLON "dn" 179 matchingrule = COLON oid 180 assertionvalue = valueencoding 181 ; The rule is used to encode an 182 ; from Section 4.1.6 of [Protocol]. 183 valueencoding = 0*(normal / escaped) 184 normal = UTF1SUBSET / UTFMB 185 escaped = ESC HEX HEX 186 UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F 187 ; UTF1SUBSET excludes 0x00 (NUL), LPAREN, 188 ; RPAREN, ASTERISK, and ESC. 189 EXCLAMATION = %x21 ; exclamation mark ("!") 190 AMPERSAND = %x26 ; ampersand (or AND symbol) ("&") 191 ASTERISK = %x2A ; asterisk ("*") 192 COLON = %x3A ; colon (":") 193 VERTBAR = %x7C ; vertical bar (or pipe) ("|") 194 TILDE = %x7E ; tilde ("~") 196 Note that although both the and productions in 197 the grammar above can produce the "attr=*" construct, this construct 198 is used only to denote a presence filter. 200 The rule ensures that the entire filter string is a 201 valid UTF-8 string and provides that the octets that represent the 202 ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII 203 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a 204 backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits 205 representing the value of the encoded octet. 207 This simple escaping mechanism eliminates filter-parsing ambiguities 208 and allows any filter that can be represented in LDAP to be 209 represented as a NUL-terminated string. Other octets that are part of 210 the set may be escaped using this mechanism, for example, 211 non-printing ASCII characters. 213 For AssertionValues that contain UTF-8 character data, each octet of 214 the character to be escaped is replaced by a backslash and two hex 215 digits, which form a single octet in the code of the character. 217 For example, the filter checking whether the "cn" attribute contained 218 a value with the character "*" anywhere in it would be represented as 219 "(cn=*\2a*)". 221 As indicated by the valueencoding rule, implementations MUST escape 222 all octets greater than 0x7F that are not part of a valid UTF-8 223 encoding sequence when they generate a string representation of a 224 search filter. Implementations SHOULD accept as input strings that 225 are not valid UTF-8 strings. This is necessary because RFC 2254 did 226 not clearly define the term "string representation" (and in 227 particular did not mention that the string representation of an LDAP 228 search filter is a string of UTF-8 encoded ISO 10646-1 characters). 230 7. Examples 232 This section gives a few examples of search filters written using 233 this notation. 235 (cn=Babs Jensen) 236 (!(cn=Tim Howes)) 237 (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) 238 (o=univ*of*mich*) 239 (seeAlso=) 241 The following examples illustrate the use of extensible matching. 243 (cn:1.2.3.4.5:=Fred Flintstone) 244 (cn:=Betty Rubble) 245 (sn:dn:2.4.6.8.10:=Barney Rubble) 246 (o:dn:=Ace Industry) 247 (:1.2.3:=Wilma Flintstone) 248 (:dn:2.4.6.8.10:=Dino) 250 The first example shows use of the matching rule "1.2.3.4.5". 252 The second example demonstrates use of a MatchingRuleAssertion form 253 without a matchingRule. 255 The third example illustrates the use of the ":oid" notation to 256 indicate that matching rule "2.4.6.8.10" should be used when making 257 comparisons, and that the attributes of an entry's distinguished name 258 should be considered part of the entry when evaluating the match 259 (indicated by the use of ":dn"). 261 The fourth example denotes an equality match, except that DN 262 components should be considered part of the entry when doing the 263 match. 265 The fifth example is a filter that should be applied to any attribute 266 supporting the matching rule given (since the attr has been omitted). 268 The sixth and final example is also a filter that should be applied 269 to any attribute supporting the matching rule given. Attributes 270 supporting the matching rule contained in the DN should also be 271 considered. 273 The following examples illustrate the use of the escaping mechanism. 275 (o=Parens R Us \28for all your parenthetical needs\29) 276 (cn=*\2A*) 277 (filename=C:\5cMyFile) 278 (bin=\00\00\00\04) 279 (sn=Lu\c4\8di\c4\87) 280 (1.3.6.1.4.1.1466.0=\04\02\48\69) 282 The first example shows the use of the escaping mechanism to 283 represent parenthesis characters. The second shows how to represent a 284 "*" in an assertion value, preventing it from being interpreted as a 285 substring indicator. The third illustrates the escaping of the 286 backslash character. 288 The fourth example shows a filter searching for the four-byte value 289 0x00000004, illustrating the use of the escaping mechanism to 290 represent arbitrary data, including NUL characters. 292 The fifth example illustrates the use of the escaping mechanism to 293 represent various non-ASCII UTF-8 characters. 295 The sixth and final example demonstrates assertion of a BER encoded 296 value. 298 8. Security Considerations 300 This memo describes a string representation of LDAP search filters. 301 While the representation itself has no known security implications, 302 LDAP search filters do. They are interpreted by LDAP servers to 303 select entries from which data is retrieved. LDAP servers should 304 take care to protect the data they maintain from unauthorized access. 306 Please refer to the Security Considerations sections of [Protocol] 307 and [AuthMeth] for more information. 309 9. Normative References 311 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and 312 Connection Level Security Mechanisms", draft-ietf-ldapbis- 313 authmeth-xx.txt, a work in progress. 315 [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - 316 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1, 317 1993. 319 [Models] Zeilenga, K. (editor), "LDAP: Directory Information Models", 320 draft-ietf-ldapbis-models-xx.txt, a work in progress. 322 [Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 324 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 327 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 328 Specifications: ABNF", RFC 2234, November 1997. 330 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 331 RFC 3629, November 2003. 333 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road 334 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 336 [Syntaxes] Dally, K. (editor), "LDAP: Syntaxes", draft-ietf-ldapbis- 337 syntaxes-xx.txt, a work in progress. 339 [X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and 340 Distinguished Encoding Rules, ITU-T Recommendation X.690, 341 1994. 343 10. Informative References 345 None. 347 11. Intellectual Property Rights 349 The IETF takes no position regarding the validity or scope of any 350 intellectual property or other rights that might be claimed to 351 pertain to the implementation or use of the technology described in 352 this document or the extent to which any license under such rights 353 might or might not be available; neither does it represent that it 354 has made any effort to identify any such rights. Information on the 355 IETF's procedures with respect to rights in standards-track and 356 standards-related documentation can be found in BCP-11. Copies of 357 claims of rights made available for publication and any assurances of 358 licenses to be made available, or the result of an attempt made to 359 obtain a general license or permission for the use of such 360 proprietary rights by implementors or users of this specification can 361 be obtained from the IETF Secretariat. 363 The IETF invites any interested party to bring to its attention any 364 copyrights, patents or patent applications, or other proprietary 365 rights which may cover technology that may be required to practice 366 this standard. Please address the information to the IETF Executive 367 Director. 369 12. Acknowledgments 371 This document replaces RFC 2254 by Tim Howes. Changes included in 372 this revised specification are based upon discussions among the 373 authors, discussions within the LDAP (v3) Revision Working Group 374 (ldapbis), and discussions within other IETF Working Groups. The 375 contributions of individuals in these working groups is gratefully 376 acknowledged. 378 13. Authors' Addresses 380 Mark Smith, Editor 381 Pearl Crescent, LLC 382 447 Marlpool Dr. 383 Saline, MI 48176 384 USA 385 +1 734 944-2856 386 mcs@pearlcrescent.com 388 Tim Howes 389 Opsware, Inc. 390 599 N. Mathilda Ave. 391 Sunnyvale, CA 94085 392 USA 393 +1 408 744-7509 394 howes@opsware.com 396 14. Full Copyright Statement 398 Copyright (C) The Internet Society (2004). All Rights Reserved. 400 This document and translations of it may be copied and furnished to 401 others, and derivative works that comment on or otherwise explain it 402 or assist in its implementation may be prepared, copied, published 403 and distributed, in whole or in part, without restriction of any 404 kind, provided that the above copyright notice and this paragraph are 405 included on all such copies and derivative works. However, this 406 document itself may not be modified in any way, such as by removing 407 the copyright notice or references to the Internet Society or other 408 Internet organizations, except as needed for the purpose of 409 developing Internet standards in which case the procedures for 410 copyrights defined in the Internet Standards process must be 411 followed, or as required to translate it into languages other than 412 English. 414 The limited permissions granted above are perpetual and will not be 415 revoked by the Internet Society or its successors or assigns. 417 This document and the information contained herein is provided on an 418 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 419 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 420 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 421 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 422 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 424 15. Appendix A: Changes Since RFC 2254 426 15.1. Technical Changes 428 The following technical changes were made to the contents of the 429 "String Search Filter Definition" section: 431 Added statement that the string representation is a string of UTF-8 432 encoded ISO 10646-1 characters. 434 Revised all of the ABNF to use common productions from [Models]. 436 Replaced the "value" rule with a new "assertionvalue" rule within the 437 "simple", "extensible", and "substring" ("initial", "any", and 438 "final") rules. This matches a change made in [Syntaxes]. 440 Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more 441 precisely reference productions from the [Models] and [Protocol] 442 documents. 444 Introduced the "valueencoding" and associated "normal" and "escaped" 445 rules to reduce the dependence on descriptive text. The "normal" 446 production restricts filter strings to valid UTF-8 sequences. 448 Added a third option to the "extensible" production to allow creation 449 of a MatchingRuleAssertion that only has a matchValue. 451 Added a statement about expected behavior in light of RFC 2254's lack 452 of a clear definition of "string representation." 454 15.2. Editorial Changes 456 Changed document title to include "LDAP:" prefix. 458 IESG Note: removed note about lack of satisfactory mandatory 459 authentication mechanisms. 461 Header and "Authors' Addresses" sections: added Mark Smith as the 462 document editor and updated affiliation and contact information. 464 "Table of Contents" and "Intellectual Property Rights" sections: 465 added. 467 Copyright: updated per latest IETF guidelines. 469 "Abstract" section: separated from introductory material. 471 "Introduction" section: new section; separated from the Abstract. 472 Updated second paragraph to indicate that RFC 2254 is replaced by 473 this document (instead of RFC 1960). Added reference to the [Roadmap] 474 document. 476 "LDAP Search Filter Definition" section: made corrections to the 477 LDAPv3 search filter ABNF so it matches that used in [Protocol]. 479 Clarified the definition of 'value' (now 'assertionvalue') to take 480 into account the fact that it is not precisely an AttributeAssertion 481 from [Protocol] section 4.1.6 (special handling is required for some 482 characters). Added a note that each octet of a character to be 483 escaped is replaced by a backslash and two hex digits, which 484 represent a single octet. 486 "Examples" section: added four additional examples: (seeAlso=), 487 (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and 488 (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a 489 value" with "an assertion value". Corrected the description of this 490 example: (sn:dn:2.4.6.8.10:=Barney Rubble). 492 "Security Considerations" section: added references to [Protocol] and 493 [AuthMeth]. 495 "Normative References" section: renamed from "References" per new RFC 496 guidelines. Changed from [1] style to [Protocol] style throughout the 497 document. Added entries for [ISO10646], [RFC2119], [AuthMeth], 498 [Models], and [Roadmap] and updated the UTF-8 reference. Replaced 499 RFC 822 reference with a reference to RFC 2234. 501 "Informative References" section: added for clarity. 503 "Acknowledgments" section: added. 505 "Appendix A: Changes Since RFC 2254" section: added. 507 "Appendix B: Changes Since Previous Document Revision" section: 508 added. 510 16. Appendix B: Changes Since Previous Document Revision 512 This appendix lists all changes relative to the previously published 513 revision, draft-ietf-ldapbis-filter-05.txt. Note that when 514 appropriate these changes are also included in Appendix A, but are 515 also included here for the benefit of the people who have already 516 reviewed draft-ietf-ldapbis-filter-05.txt. This section will be 517 removed before this document is published as an RFC. 519 16.1. Technical Changes 521 None. 523 16.2. Editorial Changes 525 "LDAP Search Filter Definition" section: changed the LDAPv3 search 526 filter ABNF so it matches that used in the latest revision of 527 [Protocol] and removed the following redundant descriptive text: 528 "where the LDAPString above is limited to the UTF-8 encoding [UTF-8] 529 of the ISO 10646 character set [ISO10646]." 531 "String Search Filter Definition" section: Corrected section 532 reference to [Models] and replaced this sentence: "Implementations 533 SHOULD accept as input a string that includes invalid UTF-8 octet 534 sequences." with the following: "Implementations SHOULD accept as 535 input strings that are not valid UTF-8 strings." 537 "Examples" section: Corrected the description of this example: 538 (sn:dn:2.4.6.8.10:=Barney Rubble). 540 "Normative References" section: changed UTF-8 reference to point to 541 RFC 3629, replaced [ASN.1] with [X.690] for consistency, and indented 542 the reference descriptions to enhance readability. 544 Authors' Addresses section: New contact information for Mark Smith. 546 Updated the copyright year to 2004. 548 This Internet Draft expires on 13 August 2004.