idnits 2.17.1 draft-ietf-ldapbis-filter-05.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 3 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 (25 October 2003) is 7489 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 112 -- Looks like a reference, but probably isn't: '1' on line 495 -- Looks like a reference, but probably isn't: '2' on line 122 -- Looks like a reference, but probably isn't: '3' on line 123 -- Looks like a reference, but probably isn't: '4' on line 124 -- Looks like a reference, but probably isn't: '5' on line 101 -- Looks like a reference, but probably isn't: '6' on line 102 -- Looks like a reference, but probably isn't: '7' on line 103 -- Looks like a reference, but probably isn't: '8' on line 104 -- Looks like a reference, but probably isn't: '9' on line 105 -- 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' -- No information found for draft-yergeau-rfc2279bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UTF-8' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Smith, Editor 3 Request for Comments: DRAFT Netscape Communications Corp. 4 Obsoletes: RFC 2254 T. Howes 5 Expires: 25 April 2004 Opsware, Inc. 6 25 October 2003 8 LDAP: String Representation of Search Filters 9 11 1. Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Discussion of this document should take place on the LDAP (v3) 33 Revision (ldapbis) Working Group mailing list . 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 2. Abstract 40 LDAP search filters are transmitted in the LDAP protocol using a 41 binary representation that is appropriate for use on the network. 42 This document defines a human-readable string representation of LDAP 43 search filters that is appropriate for use in LDAP URLs and in other 44 applications. 46 3. Table of Contents 48 1. Status of this Memo............................................1 49 2. Abstract.......................................................1 50 3. Table of Contents..............................................2 51 4. Introduction...................................................2 52 5. LDAP Search Filter Definition..................................2 53 6. String Search Filter Definition................................4 54 7. Examples.......................................................5 55 8. Security Considerations........................................7 56 9. Normative References...........................................7 57 10. Informative References.........................................8 58 11. Intellectual Property Rights...................................8 59 12. Acknowledgments................................................8 60 13. Authors' Address...............................................8 61 14. Full Copyright Statement.......................................9 62 15. Appendix A: Changes Since RFC 2254.............................9 63 15.1. Technical Changes...........................................10 64 15.2. Editorial Changes...........................................10 65 16. Appendix B: Changes Since Previous Document Revision...........11 66 16.1. Technical Changes...........................................12 67 16.2. Editorial Changes...........................................12 69 4. Introduction 71 The Lightweight Directory Access Protocol (LDAP) [Protocol] defines a 72 network representation of a search filter transmitted to an LDAP 73 server. Some applications may find it useful to have a common way of 74 representing these search filters in a human-readable form; LDAP URLs 75 are an example of one such application. This document defines a 76 human-readable string format for representing the full range of 77 possible LDAP version 3 search filters, including extended match 78 filters. 80 This document is an integral part of the LDAP Technical 81 Specification [Roadmap]. 83 This document replaces RFC 2254. Changes to RFC 2254 are summarized 84 in Appendix A. 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in BCP 14 [RFC2119]. 90 5. LDAP Search Filter Definition 92 An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as 93 follows: 95 Filter ::= CHOICE { 96 and [0] SET SIZE (1..MAX) OF Filter, 97 or [1] SET SIZE (1..MAX) OF Filter, 98 not [2] Filter, 99 equalityMatch [3] AttributeValueAssertion, 100 substrings [4] SubstringFilter, 101 greaterOrEqual [5] AttributeValueAssertion, 102 lessOrEqual [6] AttributeValueAssertion, 103 present [7] AttributeDescription, 104 approxMatch [8] AttributeValueAssertion, 105 extensibleMatch [9] MatchingRuleAssertion } 107 SubstringFilter ::= SEQUENCE { 108 type AttributeDescription, 109 -- at least one must be present, 110 -- initial and final can occur at most once 111 substrings SEQUENCE OF CHOICE { 112 initial [0] AssertionValue, 113 any [1] AssertionValue, 114 final [2] AssertionValue } } 116 AttributeValueAssertion ::= SEQUENCE { 117 attributeDesc AttributeDescription, 118 assertionValue AssertionValue } 120 MatchingRuleAssertion ::= SEQUENCE { 121 matchingRule [1] MatchingRuleId OPTIONAL, 122 type [2] AttributeDescription OPTIONAL, 123 matchValue [3] AssertionValue, 124 dnAttributes [4] BOOLEAN DEFAULT FALSE } 126 AttributeDescription ::= LDAPString 127 -- Constrained to attributedescription 128 -- [Models] 130 AttributeValue ::= OCTET STRING 132 MatchingRuleId ::= LDAPString 134 AssertionValue ::= OCTET STRING 136 LDAPString ::= OCTET STRING -- UTF-8 encoded, 137 -- ISO 10646 characters 139 where the LDAPString above is limited to the UTF-8 encoding [UTF-8] 140 of the ISO 10646 character set [ISO10646]. The AttributeDescription 141 is a string representation of the attribute description and is 142 defined in [Protocol]. The AttributeValue and AssertionValue OCTET 143 STRING have the form defined in [Syntaxes]. The Filter is encoded 144 for transmission over a network using the Basic Encoding Rules 145 defined in [ASN.1], with simplifications described in [Protocol]. 147 6. String Search Filter Definition 149 The string representation of an LDAP search filter is a string of 150 UTF-8 encoded ISO 10646-1 characters that is defined by the following 151 grammar, following the ABNF notation defined in [RFC2234]. The 152 productions used that are not defined here are defined in section 1.3 153 (Common ABNF Productions) of [Models] unless otherwise noted. The 154 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 / greater / less 165 equal = EQUALS 166 approx = TILDE EQUALS 167 greater = RANGLE EQUALS 168 less = LANGLE EQUALS 169 extensible = attr [dnattrs] [matchingrule] COLON EQUALS assertionvalue 170 / [dnattrs] matchingrule COLON EQUALS assertionvalue 171 / COLON EQUALS assertionvalue 172 present = attr EQUALS ASTERISK 173 substring = attr EQUALS [initial] any [final] 174 initial = assertionvalue 175 any = ASTERISK *(assertionvalue ASTERISK) 176 final = assertionvalue 177 attr = attributedescription 178 ; The attributedescription rule is defined in 179 ; Section 2.5 of [Models]. 180 dnattrs = COLON "dn" 181 matchingrule = COLON oid 182 assertionvalue = valueencoding 183 ; The rule is used to encode an 184 ; from Section 4.1.6 of [Protocol]. 185 valueencoding = 0*(normal / escaped) 186 normal = UTF1SUBSET / UTFMB 187 escaped = ESC HEX HEX 188 UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F 189 ; UTF1SUBSET excludes 0x00 (NUL), LPAREN, 190 ; RPAREN, ASTERISK, and ESC. 192 EXCLAMATION = %x21 ; exclamation mark ("!") 193 AMPERSAND = %x26 ; ampersand (or AND symbol) ("&") 194 ASTERISK = %x2A ; asterisk ("*") 195 COLON = %x3A ; colon (":") 196 VERTBAR = %x7C ; vertical bar (or pipe) ("|") 197 TILDE = %x7E ; tilde ("~") 199 Note that although both the and productions in 200 the grammar above can produce the "attr=*" construct, this construct 201 is used only to denote a presence filter. 203 The rule ensures that the entire filter string is a 204 valid UTF-8 string and provides that the octets that represent the 205 ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII 206 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a 207 backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits 208 representing the value of the encoded octet. 210 This simple escaping mechanism eliminates filter-parsing ambiguities 211 and allows any filter that can be represented in LDAP to be 212 represented as a NUL-terminated string. Other octets that are part of 213 the set may be escaped using this mechanism, for example, 214 non-printing ASCII characters. 216 For AssertionValues that contain UTF-8 character data, each octet of 217 the character to be escaped is replaced by a backslash and two hex 218 digits, which form a single octet in the code of the character. 220 For example, the filter checking whether the "cn" attribute contained 221 a value with the character "*" anywhere in it would be represented as 222 "(cn=*\2a*)". 224 As indicated by the valueencoding rule, implementations MUST escape 225 all octets greater than 0x7F that are not part of a valid UTF-8 226 encoding sequence when they generate a string representation of a 227 search filter. Implementations SHOULD accept as input a string that 228 includes invalid UTF-8 octet sequences. This is necessary because RFC 229 2254 did not clearly define the term "string representation" (and in 230 particular did not mention that the string representation of an LDAP 231 search filter is a string of UTF-8 encoded ISO 10646-1 characters). 233 7. Examples 235 This section gives a few examples of search filters written using 236 this notation. 238 (cn=Babs Jensen) 239 (!(cn=Tim Howes)) 240 (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) 241 (o=univ*of*mich*) 242 (seeAlso=) 244 The following examples illustrate the use of extensible matching. 246 (cn:1.2.3.4.5:=Fred Flintstone) 247 (cn:=Betty Rubble) 248 (sn:dn:2.4.6.8.10:=Barney Rubble) 249 (o:dn:=Ace Industry) 250 (:1.2.3:=Wilma Flintstone) 251 (:dn:2.4.6.8.10:=Dino) 253 The first example shows use of the matching rule "1.2.3.4.5". 255 The second example demonstrates use of a MatchingRuleAssertion form 256 without a matchingRule. 258 The third example illustrates the use of the ":dn" notation to 259 indicate that matching rule "2.4.6.8.10" should be used when making 260 comparisons, and that the attributes of an entry's distinguished name 261 should be considered part of the entry when evaluating the match. 263 The fourth example denotes an equality match, except that DN 264 components should be considered part of the entry when doing the 265 match. 267 The fifth example is a filter that should be applied to any attribute 268 supporting the matching rule given (since the attr has been omitted). 270 The sixth and final example is also a filter that should be applied 271 to any attribute supporting the matching rule given. Attributes 272 supporting the matching rule contained in the DN should also be 273 considered. 275 The following examples illustrate the use of the escaping mechanism. 277 (o=Parens R Us \28for all your parenthetical needs\29) 278 (cn=*\2A*) 279 (filename=C:\5cMyFile) 280 (bin=\00\00\00\04) 281 (sn=Lu\c4\8di\c4\87) 282 (1.3.6.1.4.1.1466.0=\04\02\48\69) 284 The first example shows the use of the escaping mechanism to 285 represent parenthesis characters. The second shows how to represent a 286 "*" in an assertion value, preventing it from being interpreted as a 287 substring indicator. The third illustrates the escaping of the 288 backslash character. 290 The fourth example shows a filter searching for the four-byte value 291 0x00000004, illustrating the use of the escaping mechanism to 292 represent arbitrary data, including NUL characters. 294 The fifth example illustrates the use of the escaping mechanism to 295 represent various non-ASCII UTF-8 characters. 297 The sixth and final example demonstrates assertion of a BER encoded 298 value. 300 8. Security Considerations 302 This memo describes a string representation of LDAP search filters. 303 While the representation itself has no known security implications, 304 LDAP search filters do. They are interpreted by LDAP servers to 305 select entries from which data is retrieved. LDAP servers should 306 take care to protect the data they maintain from unauthorized access. 308 Please refer to the Security Considerations sections of [Protocol] 309 and [AuthMeth] for more information. 311 9. Normative References 313 [ASN.1] Specification of ASN.1 encoding rules: Basic, Canonical, and 314 Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994. 316 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and 317 Connection Level Security Mechanisms", draft-ietf-ldapbis-authmeth- 318 xx.txt, a work in progress. 320 [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - 321 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1, 1993. 323 [Models] Zeilenga, K. (editor), "LDAP: Directory Information Models", 324 draft-ietf-ldapbis-models-xx.txt, a work in progress. 326 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft- 327 ietf-ldapbis-protocol-xx.txt, a work in progress. 329 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 332 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 333 Specifications: ABNF", RFC 2234, November 1997. 335 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road 336 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 338 [Syntaxes] Dally, K. (editor), "LDAP: Syntaxes", draft-ietf-ldapbis- 339 syntaxes-xx.txt, a work in progress. 341 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 342 draft-yergeau-rfc2279bis-xx.txt, a work in progress. 344 10. Informative References 346 None. 348 11. Intellectual Property Rights 350 The IETF takes no position regarding the validity or scope of any 351 intellectual property or other rights that might be claimed to 352 pertain to the implementation or use of the technology described in 353 this document or the extent to which any license under such rights 354 might or might not be available; neither does it represent that it 355 has made any effort to identify any such rights. Information on the 356 IETF's procedures with respect to rights in standards-track and 357 standards-related documentation can be found in BCP-11. Copies of 358 claims of rights made available for publication and any assurances of 359 licenses to be made available, or the result of an attempt made to 360 obtain a general license or permission for the use of such 361 proprietary rights by implementors or users of this specification can 362 be obtained from the IETF Secretariat. 364 The IETF invites any interested party to bring to its attention any 365 copyrights, patents or patent applications, or other proprietary 366 rights which may cover technology that may be required to practice 367 this standard. Please address the information to the IETF Executive 368 Director. 370 12. Acknowledgments 372 This document replaces RFC 2254 by Tim Howes. Changes included in 373 this revised specification are based upon discussions among the 374 authors, discussions within the LDAP (v3) Revision Working Group 375 (ldapbis), and discussions within other IETF Working Groups. The 376 contributions of individuals in these working groups is gratefully 377 acknowledged. 379 13. Authors' Address 381 Mark Smith, Editor 382 Netscape Communications Corp. 383 360 W. Caribbean Drive 384 Sunnyvale, CA 94089 385 USA 386 +1 650 937-3477 387 MarkCSmithWork@aol.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 14. Full Copyright Statement 399 Copyright (C) The Internet Society (2003). All Rights Reserved. 401 This document and translations of it may be copied and furnished to 402 others, and derivative works that comment on or otherwise explain it 403 or assist in its implementation may be prepared, copied, published 404 and distributed, in whole or in part, without restriction of any 405 kind, provided that the above copyright notice and this paragraph are 406 included on all such copies and derivative works. However, this 407 document itself may not be modified in any way, such as by removing 408 the copyright notice or references to the Internet Society or other 409 Internet organizations, except as needed for the purpose of 410 developing Internet standards in which case the procedures for 411 copyrights defined in the Internet Standards process must be 412 followed, or as required to translate it into languages other than 413 English. 415 The limited permissions granted above are perpetual and will not be 416 revoked by the Internet Society or its successors or assigns. 418 This document and the information contained herein is provided on an 419 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 420 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 421 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 422 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 423 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 425 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". 491 "Security Considerations" section: added references to [Protocol] and 492 [AuthMeth]. 494 "Normative References" section: renamed from "References" per new RFC 495 guidelines. Changed from [1] style to [Protocol] style throughout the 496 document. Added entries for [ISO10646], [RFC2119], [AuthMeth], 497 [Models], and [Roadmap] and updated the UTF-8 reference. Replaced 498 RFC 822 reference with a reference to RFC 2234. 500 "Informative References" section: added for clarity. 502 "Acknowledgments" section: added. 504 "Appendix A: Changes Since RFC 2254" section: added. 506 "Appendix B: Changes Since Previous Document Revision" section: 507 added. 509 16. Appendix B: Changes Since Previous Document Revision 511 This appendix lists all changes relative to the previously published 512 revision, draft-ietf-ldapbis-filter-04.txt. Note that when 513 appropriate these changes are also included in Appendix A, but are 514 also included here for the benefit of the people who have already 515 reviewed draft-ietf-ldapbis-filter-04.txt. This section will be 516 removed before this document is published as an RFC. 518 16.1. Technical Changes 520 "Examples" section: Removed the (:=Fred Flintstone) example which is 521 not allowed by the protocol. 523 16.2. Editorial Changes 525 "String Search Filter Definition" section: Revised the last two 526 sentences in this section to improve clarity (the updated text now 527 begins with the text "Implementations SHOULD accept as input a string 528 that includes...." 530 Replaced all occurrences of "asterix" with the correctly spelled 531 "asterisk." 533 "Normative References" section: changed UTF-8 reference to point to 534 the UTF-8 Internet Draft. 536 "Intellectual Property Rights" section: added. 538 Author's Addresses section: New email address for Mark Smith. 540 "Full Copyright Statement" section: updated text to match latest IETF 541 guidelines. 543 This Internet Draft expires on 25 April 2004.