idnits 2.17.1 draft-ietf-ldapbis-filter-08.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 521. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 527), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** 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 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 (24 October 2004) is 7122 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 118 -- Looks like a reference, but probably isn't: '1' on line 466 -- Looks like a reference, but probably isn't: '2' on line 128 -- Looks like a reference, but probably isn't: '3' on line 129 -- Looks like a reference, but probably isn't: '4' on line 130 -- Looks like a reference, but probably isn't: '5' on line 108 -- Looks like a reference, but probably isn't: '6' on line 109 -- Looks like a reference, but probably isn't: '7' on line 110 -- Looks like a reference, but probably isn't: '8' on line 111 -- Looks like a reference, but probably isn't: '9' on line 112 == Missing Reference: 'ISO 10646' is mentioned on line 393, 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: 9 errors (**), 0 flaws (~~), 5 warnings (==), 29 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 Pearl Crescent, LLC 4 Obsoletes: RFC 2254 T. Howes 5 Expires: 24 April 2005 Opsware, Inc. 6 24 October 2004 8 LDAP: String Representation of Search Filters 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she become 16 aware will be disclosed, in accordance with RFC 3668. 18 This document is intended to be published as a Standards Track RFC, 19 replacing RFC 2254. Distribution of this memo is unlimited. 20 Technical discussion of this document will take place on the IETF 21 LDAP (v3) Revision (ldapbis) Working Group mailing list 22 . Please send editorial comments directly 23 to the editor . 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 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Please see the Full Copyright section near the end of this document 43 for more information. 45 Abstract 47 LDAP search filters are transmitted in the LDAP protocol using a 48 binary representation that is appropriate for use on the network. 49 This document defines a human-readable string representation of LDAP 50 search filters that is appropriate for use in LDAP URLs and in other 51 applications. 53 Table of Contents 55 Status of this Memo............................................1 56 Abstract.......................................................2 57 Table of Contents..............................................2 58 1. Introduction...................................................2 59 2. LDAP Search Filter Definition..................................3 60 3. String Search Filter Definition................................4 61 4. Examples.......................................................6 62 5. Security Considerations........................................7 63 6. IANA Considerations............................................7 64 7. Normative References...........................................7 65 8. Informative References.........................................8 66 9. Acknowledgments................................................8 67 10. Authors' Addresses.............................................8 68 11. Appendix A: Changes Since RFC 2254.............................9 69 11.1. Technical Changes...........................................9 70 11.2. Editorial Changes...........................................10 71 12. Appendix B: Changes Since Previous Document Revision...........11 72 12.1. Editorial Changes...........................................11 73 13. Intellectual Property Rights...................................11 74 14. Full Copyright.................................................12 76 1. Introduction 78 The Lightweight Directory Access Protocol (LDAP) [Protocol] 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 an integral part of the LDAP Technical Specification 88 [Roadmap]. 90 This document replaces RFC 2254. Changes to RFC 2254 are summarized 91 in Appendix A. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in BCP 14 [RFC2119]. 97 2. LDAP Search Filter Definition 99 An LDAPv3 search filter is defined in Section 4.5.1 of [Protocol] as 100 follows: 102 Filter ::= CHOICE { 103 and [0] SET SIZE (1..MAX) OF filter Filter, 104 or [1] SET SIZE (1..MAX) OF filter Filter, 105 not [2] Filter, 106 equalityMatch [3] AttributeValueAssertion, 107 substrings [4] SubstringFilter, 108 greaterOrEqual [5] AttributeValueAssertion, 109 lessOrEqual [6] AttributeValueAssertion, 110 present [7] AttributeDescription, 111 approxMatch [8] AttributeValueAssertion, 112 extensibleMatch [9] MatchingRuleAssertion } 114 SubstringFilter ::= SEQUENCE { 115 type AttributeDescription, 116 -- initial and final can occur at most once 117 substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { 118 initial [0] AssertionValue, 119 any [1] AssertionValue, 120 final [2] AssertionValue } } 122 AttributeValueAssertion ::= SEQUENCE { 123 attributeDesc AttributeDescription, 124 assertionValue AssertionValue } 126 MatchingRuleAssertion ::= SEQUENCE { 127 matchingRule [1] MatchingRuleId OPTIONAL, 128 type [2] AttributeDescription OPTIONAL, 129 matchValue [3] AssertionValue, 130 dnAttributes [4] BOOLEAN DEFAULT FALSE } 132 AttributeDescription ::= LDAPString 133 -- Constrained to 134 -- [Models] 136 AttributeValue ::= OCTET STRING 138 MatchingRuleId ::= LDAPString 140 AssertionValue ::= OCTET STRING 141 LDAPString ::= OCTET STRING -- UTF-8 encoded, 142 -- [Unicode] characters 144 The AttributeDescription is a string representation of the attribute 145 description and is defined in [Protocol]. The AttributeValue and 146 AssertionValue OCTET STRING have the form defined in [Syntaxes]. The 147 Filter is encoded for transmission over a network using the Basic 148 Encoding Rules (BER) defined in [X.690], with simplifications 149 described in [Protocol]. 151 3. String Search Filter Definition 153 The string representation of an LDAP search filter is a string of 154 UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined 155 by the following grammar, following the ABNF notation defined in 156 [RFC2234]. The productions used that are not defined here are 157 defined in section 1.4 (Common ABNF Productions) of [Models] unless 158 otherwise noted. The filter format uses a prefix notation. 160 filter = LPAREN filtercomp RPAREN 161 filtercomp = and / or / not / item 162 and = AMPERSAND filterlist 163 or = VERTBAR filterlist 164 not = EXCLAMATION filter 165 filterlist = 1*filter 166 item = simple / present / substring / extensible 167 simple = attr filtertype assertionvalue 168 filtertype = equal / approx / greaterorequal / lessorequal 169 equal = EQUALS 170 approx = TILDE EQUALS 171 greaterorequal = RANGLE EQUALS 172 lessorequal = LANGLE EQUALS 173 extensible = attr [dnattrs] 174 [matchingrule] COLON EQUALS assertionvalue 175 / [dnattrs] 176 matchingrule COLON EQUALS assertionvalue 177 / 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]. 186 dnattrs = COLON "dn" 187 matchingrule = COLON oid 188 assertionvalue = valueencoding 189 ; The rule is used to encode an 190 ; from Section 4.1.6 of [Protocol]. 191 valueencoding = 0*(normal / escaped) 192 normal = UTF1SUBSET / UTFMB 193 escaped = ESC HEX HEX 194 UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F 195 ; UTF1SUBSET excludes 0x00 (NUL), LPAREN, 196 ; RPAREN, ASTERISK, and ESC. 197 EXCLAMATION = %x21 ; exclamation mark ("!") 198 AMPERSAND = %x26 ; ampersand (or AND symbol) ("&") 199 ASTERISK = %x2A ; asterisk ("*") 200 COLON = %x3A ; colon (":") 201 VERTBAR = %x7C ; vertical bar (or pipe) ("|") 202 TILDE = %x7E ; tilde ("~") 204 Note that although both the and productions in 205 the grammar above can produce the "attr=*" construct, this construct 206 is used only to denote a presence filter. 208 The rule ensures that the entire filter string is a 209 valid UTF-8 string and provides that the octets that represent the 210 ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII 211 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a 212 backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits 213 representing the value of the encoded octet. 215 This simple escaping mechanism eliminates filter-parsing ambiguities 216 and allows any filter that can be represented in LDAP to be 217 represented as a NUL-terminated string. Other octets that are part of 218 the set may be escaped using this mechanism, for example, 219 non-printing ASCII characters. 221 For AssertionValues that contain UTF-8 character data, each octet of 222 the character to be escaped is replaced by a backslash and two hex 223 digits, which form a single octet in the code of the character. 225 For example, the filter checking whether the "cn" attribute contained 226 a value with the character "*" anywhere in it would be represented as 227 "(cn=*\2a*)". 229 As indicated by the valueencoding 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:1.2.3.4.5:=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 "1.2.3.4.5". 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 "2.4.6.8.10" should be used when making 265 comparisons, and that the attributes of an entry's distinguished name 266 should be considered part of the entry when evaluating the match 267 (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 attr has been omitted). 276 The sixth and final example is also a filter that should be applied 277 to any attribute supporting the matching rule given. Attributes 278 supporting the matching rule contained in the DN should also be 279 considered. 281 The following examples illustrate the use of the escaping mechanism. 283 (o=Parens R Us \28for all your parenthetical needs\29) 284 (cn=*\2A*) 285 (filename=C:\5cMyFile) 286 (bin=\00\00\00\04) 287 (sn=Lu\c4\8di\c4\87) 288 (1.3.6.1.4.1.1466.0=\04\02\48\69) 290 The first example shows the use of the escaping mechanism to 291 represent parenthesis characters. The second shows how to represent a 292 "*" in an assertion value, preventing it from being interpreted as a 293 substring indicator. The third illustrates the escaping of the 294 backslash character. 296 The fourth example shows a filter searching for the four-byte value 297 0x00000004, illustrating the use of the escaping mechanism to 298 represent arbitrary data, including NUL characters. 300 The fifth example illustrates the use of the escaping mechanism to 301 represent various non-ASCII UTF-8 characters. 303 The sixth and final example demonstrates assertion of a BER encoded 304 value. 306 5. Security Considerations 308 This memo describes a string representation of LDAP search filters. 309 While the representation itself has no known security implications, 310 LDAP search filters do. They are interpreted by LDAP servers to 311 select entries from which data is retrieved. LDAP servers should 312 take care to protect the data they maintain from unauthorized access. 314 Please refer to the Security Considerations sections of [Protocol] 315 and [AuthMeth] for more information. 317 6. IANA Considerations 319 This document has no actions for IANA. 321 7. Normative References 323 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and 324 Connection Level Security Mechanisms", 325 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. 327 [Models] Zeilenga, K. (editor), "LDAP: Directory Information Models", 328 draft-ietf-ldapbis-models-xx.txt, a work in progress. 330 [Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 332 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 335 [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax 336 Specifications: ABNF", RFC 2234, November 1997. 338 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 339 RFC 3629, November 2003. 341 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road 342 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. 344 [Syntaxes] Dally, K. (editor), "LDAP: Syntaxes", 345 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 347 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 348 3.2.0" is defined by "The Unicode Standard, Version 3.0" 349 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as 350 amended by the "Unicode Standard Annex #27: Unicode 3.1" 351 (http://www.unicode.org/reports/tr27/) and by the "Unicode 352 Standard Annex #28: Unicode 3.2." 354 [X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and 355 Distinguished Encoding Rules, ITU-T Recommendation X.690, 356 1994. 358 8. Informative References 360 None. 362 9. Acknowledgments 364 This document replaces RFC 2254 by Tim Howes. Changes included in 365 this revised specification are based upon discussions among the 366 authors, discussions within the LDAP (v3) Revision Working Group 367 (ldapbis), and discussions within other IETF Working Groups. The 368 contributions of individuals in these working groups is gratefully 369 acknowledged. 371 10. Authors' Addresses 373 Mark Smith, Editor 374 Pearl Crescent, LLC 375 447 Marlpool Dr. 376 Saline, MI 48176 377 USA 378 +1 734 944-2856 379 mcs@pearlcrescent.com 381 Tim Howes 382 Opsware, Inc. 383 599 N. Mathilda Ave. 384 Sunnyvale, CA 94085 385 USA 386 +1 408 744-7509 387 howes@opsware.com 389 11. Appendix A: Changes Since RFC 2254 391 11.1. Technical Changes 393 Replaced [ISO 10646] reference with [Unicode]. 395 The following technical changes were made to the contents of the 396 "String Search Filter Definition" section: 398 Added statement that the string representation is a string of UTF-8 399 encoded Unicode characters. 401 Revised all of the ABNF to use common productions from [Models]. 403 Replaced the "value" rule with a new "assertionvalue" rule within the 404 "simple", "extensible", and "substring" ("initial", "any", and 405 "final") rules. This matches a change made in [Syntaxes]. 407 Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more 408 precisely reference productions from the [Models] and [Protocol] 409 documents. 411 "String Search Filter Definition" section: replaced "greater" and 412 "less" with "greaterorequal" and "lessorequal" to avoid confusion. 414 Introduced the "valueencoding" and associated "normal" and "escaped" 415 rules to reduce the dependence on descriptive text. The "normal" 416 production restricts filter strings to valid UTF-8 sequences. 418 Added a third option to the "extensible" production to allow creation 419 of a MatchingRuleAssertion that only has a matchValue. 421 Added a statement about expected behavior in light of RFC 2254's lack 422 of a clear definition of "string representation." 424 11.2. Editorial Changes 426 Changed document title to include "LDAP:" prefix. 428 IESG Note: removed note about lack of satisfactory mandatory 429 authentication mechanisms. 431 Header and "Authors' Addresses" sections: added Mark Smith as the 432 document editor and updated affiliation and contact information. 434 "Table of Contents", "IANA Considerations", and "Intellectual 435 Property Rights" sections: added. 437 Copyright: updated per latest IETF guidelines. 439 "Abstract" section: separated from introductory material. 441 "Introduction" section: new section; separated from the Abstract. 442 Updated second paragraph to indicate that RFC 2254 is replaced by 443 this document (instead of RFC 1960). Added reference to the [Roadmap] 444 document. 446 "LDAP Search Filter Definition" section: made corrections to the 447 LDAPv3 search filter ABNF so it matches that used in [Protocol]. 449 Clarified the definition of 'value' (now 'assertionvalue') to take 450 into account the fact that it is not precisely an AttributeAssertion 451 from [Protocol] section 4.1.6 (special handling is required for some 452 characters). Added a note that each octet of a character to be 453 escaped is replaced by a backslash and two hex digits, which 454 represent a single octet. 456 "Examples" section: added four additional examples: (seeAlso=), 457 (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and 458 (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a 459 value" with "an assertion value". Corrected the description of this 460 example: (sn:dn:2.4.6.8.10:=Barney Rubble). 462 "Security Considerations" section: added references to [Protocol] and 463 [AuthMeth]. 465 "Normative References" section: renamed from "References" per new RFC 466 guidelines. Changed from [1] style to [Protocol] style throughout the 467 document. Added entries for [Unicode], [RFC2119], [AuthMeth], 468 [Models], and [Roadmap] and updated the UTF-8 reference. Replaced 469 RFC 822 reference with a reference to RFC 2234. 471 "Informative References" section: added for clarity. 473 "Acknowledgments" section: added. 475 "Appendix A: Changes Since RFC 2254" section: added. 477 "Appendix B: Changes Since Previous Document Revision" section: 478 added. 480 12. Appendix B: Changes Since Previous Document Revision 482 This appendix lists all changes relative to the previously published 483 revision, draft-ietf-ldapbis-filter-07.txt. Note that when 484 appropriate these changes are also included in Appendix A, but are 485 also included here for the benefit of the people who have already 486 reviewed draft-ietf-ldapbis-filter-07.txt. This section will be 487 removed before this document is published as an RFC. 489 12.1. Editorial Changes 491 "Status of this Memo" section: replaced RFC 3668 (IPR) boilerplate 492 paragraph with the version that says "each author" instead of "I." 494 "Status of this Memo" section: added 2 paragraphs that were 495 accidently removed from the -07 revision (one begins with "The list 496 of current Internet-Drafts..." and the other begins with "The list of 497 Internet-Draft Shadow Directories...." 499 13. Intellectual Property Rights 501 The IETF takes no position regarding the validity or scope of any 502 Intellectual Property Rights or other rights that might be claimed to 503 pertain to the implementation or use of the technology described in 504 this document or the extent to which any license under such rights 505 might or might not be available; nor does it represent that it has 506 made any independent effort to identify any such rights. Information 507 on the procedures with respect to rights in RFC documents can be 508 found in BCP 78 and BCP 79. 510 Copies of IPR disclosures made to the IETF Secretariat and any 511 assurances of licenses to be made available, or the result of an 512 attempt made to obtain a general license or permission for the use of 513 such proprietary rights by implementers or users of this 514 specification can be obtained from the IETF on-line IPR repository at 515 http://www.ietf.org/ipr. 517 The IETF invites any interested party to bring to its attention any 518 copyrights, patents or patent applications, or other proprietary 519 rights that may cover technology that may be required to implement 520 this standard. Please address the information to the IETF at 521 ietf-ipr@ietf.org. 523 14. Full Copyright 525 Copyright (C) The Internet Society (2004). This document is subject 526 to the rights, licenses and restrictions contained in BCP 78, and 527 except as set forth therein, the authors retain all their rights. 529 This document and the information contained herein are provided on an 530 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 531 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 532 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 533 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 534 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 535 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 537 This Internet Draft expires on 24 April 2005.