idnits 2.17.1 draft-malamud-keyword-discovery-05.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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 524. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 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 (April 24, 2005) is 6939 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 243 == Unused Reference: 'RFC2795' is defined on line 423, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Downref: Normative reference to an Historic RFC: RFC 2660 -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3761 (Obsoleted by RFC 6116, RFC 6117) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Malamud 3 Internet-Draft Memory Palace Press 4 Expires: October 26, 2005 April 24, 2005 6 Attaching Meaning to Solicitation Class Keywords 7 draft-malamud-keyword-discovery-05 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 26, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This Internet-Draft proposes a mechanism for finding a URI associated 41 with a solicitation class keyword, which is defined in RFC 3865, the 42 No Soliciting SMTP Service Extension. Solicitation class keywords 43 are simple labels consisting of a domain name that has been reversed, 44 such as "org.example.adv". These solicitation class keywords are 45 inserted in selected header fields or used in the ESMTP service 46 extension, including a new "No-Solicit:" header which can contain one 47 or more solicitation class keywords inserted by the sender. 49 This draft specifies an application based on the Dynamic Delegation 50 Discovery System (DDDS) described in RFC 3401 and related documents. 51 An algorithm is specified to associate a solicitation class keyword 52 with a URI which contains further information about the meaning and 53 usage of that solicitation class keyword. For example, the 54 registrant of the "example.org" domain could use this mechanism to 55 create a URI which contains detailed information about the 56 "org.example.adv" solicitation class keyword. 58 Terminology 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in BCP 14, [RFC2119]. 64 Table of Contents 66 1. Solicitation Class Keywords . . . . . . . . . . . . . . . . . 3 67 2. The No-Solicit NAPTR Application . . . . . . . . . . . . . . . 3 68 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. DDDS Application Specification . . . . . . . . . . . . . . . . 7 70 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1 Normative References . . . . . . . . . . . . . . . . . . . 9 75 8.2 Informative References . . . . . . . . . . . . . . . . . . 10 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 77 A. Intended Status and Discussion (TO BE REMOVED UPON 78 PUBLICATION) . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 B. Changes From Previous Draft (TO BE REMOVED UPON 80 PUBLICATION) . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 Intellectual Property and Copyright Statements . . . . . . . . 12 83 1. Solicitation Class Keywords 85 [RFC3865] defines the concept of a "solicitation class keyword", 86 which is an arbitrary string or label which can be associated with an 87 electronic mail message and transported by the ESMTP mail service as 88 defined in [RFC2821] and related documents. Solicitation class 89 keywords are formatted like domain names, but reversed. For example, 90 the zone administrator of "example.com" might specify a particular 91 solicitation class keyword such as "com.example.adv" that could be 92 inserted in a "No-Solicit:" header by the message sender or in a 93 trace field by a message transfer agent (MTA). This solicitation 94 class keyword is inserted by the sender of the message, who may also 95 insert a variety of other solicitation class keywords as defined by 96 the sender or by other parties. 98 [RFC3865] explicitly places discovery of the meaning of a 99 solicitation class keyword as outside of the scope of the basic ESMTP 100 service extension. For the purposes of message transport, these 101 solicitation class keywords are opaque. However, if RFC 3865 becomes 102 widely used, a mail message might contain a large number of 103 solicitation class keywords. The "No-Solicit:" header has keywords 104 inserted by the sender of the message, which might include the 105 sender's own keywords, as well as those mandated by regulatory 106 authorities or recommended by voluntary industry associations. 107 Likewise, the "received:" trace fields might contain a large number 108 of keywords produced by message transfer agents, filtering software, 109 forwarding software in the message user agent (MUA), or any other 110 system in the chain of delivery. 112 As the number of keywords employed grows, it will be important to 113 find a method for discovering the meaning behind the various 114 solicitation class keywords. This document specifies such a 115 mechanism, associating a solicitation class keyword with a URI which 116 contains further information by using the DNS NAPTR Resource Record, 117 which is defined in [RFC3403]. An explicit design goal is to keep 118 the system as simple as possible. Approaches such as defining an 119 XML-based structure that would contain specific meta-data about the 120 solicitation class keyword or other approaches that define the format 121 of the explanation were ruled out. Instead, the goal is to simply to 122 associate a solicitation class keyword with a URI, which in turn 123 contains an explanation of the keyword. 125 2. The No-Solicit NAPTR Application 127 The DDDS framework of [RFC3401] and related documents provides a 128 powerful set of mechanisms that can yield sophisticated applications 129 such as ENUM as specified in [RFC3761]. There is a simplification of 130 the DDDS framework called the Straightforward-NAPTR (S-NAPTR) 131 application as specified in [RFC3958]. Unfortunately, S-NAPTR does 132 not permit the use of the "U" flag for terminal lookups and does not 133 support the regular expression field of the NAPTR RR. Since a 134 replacement field in a NAPTR record must contain only a domain name, 135 and our goal is to find a URI, this draft does not use the S-NAPTR 136 mechanism. 138 This draft uses the NAPTR RR to do a single lookup from solicitation 139 class keyword to URI. The character "." is first substituted for any 140 instances of the character ":" and then the solicitation class 141 keyword is reversed, using the character "." as the delimiter. This 142 becomes the domain name lookup key. For example, "org.example:ADV" 143 becomes "ADV.example.org". 145 _Note On Domain Names: _ RFC3865 states that a solicitation class 146 keyword consists of a valid domain name followed by the ":" 147 character and by additional valid characters. Several points are 148 important to remember for implementors. Since domain names are 149 case insensitive and the ":" character is translated to the "." 150 character, for purposes of this DDDS application, the following 151 solicitation class keywords are syntactically equivalent: 152 "com.example:ADV", "com.Example:adv", and "com:example:ADV". 153 In addition, it is important to remember that the resulting string 154 must meet other DNS validity checks. In particular, domain labels 155 are limited to 63 characters in length and the total length of the 156 resulting string must be less than 253 characters. Any non-ASCII 157 characters must be encoded using the Internationalized Domain 158 Names (IDN) specifications in [RFC3490] and related documents. 159 Note that non-ASCII characters may be encoded after the ":" 160 character as well. 162 The fields of the NAPTR RR are used as follows: 163 o The "ORDER" and "PREFERENCE" fields are to be processed as 164 specified in [RFC3403]: if multiple records are returned, the 165 one(s) with the lowest "ORDER" value that have a matching 166 "SERVICE" field MUST be used. Of those with the lowest ORDER 167 value, those with the lowest "PREFERENCE" SHOULD be used. 168 o The "FLAGS" field MUST contain the character "U". 169 o The "SERVICES" field MUST contain only the string "no-solicit". 170 o The "REGEXP" field MUST contain a valid URI as further specified 171 in this section. 172 o The "REPLACEMENT" field MUST be empty. 174 The "REGEXP" field is defined in [RFC3402] as consisting of a "delim- 175 character", a POSIX Extended Regular Expression, another "delim- 176 character", a replacement value, and a final "delim-character". For 177 this application the following rules apply: 179 o The "delim-character" MAY be any valid character as defined in 180 section 3.2 of [RFC3402]. 181 o The extended regular expression MUST be empty. 182 o The replacement value MUST contain a valid URI as specified in 183 [RFC2396]. 184 o The replacement value SHOULD contain a URI limited to the "ftp", 185 "http", and "https" schemes as specified in [RFC2396] and 186 [RFC2660]. 187 o The document that is retrieved at the URI SHOULD conform to [HTML- 188 4.01], including the Accessibility Guidelines contained therein. 190 3. Example 192 In this example, a set of NAPTR records are added to the 193 "example.com" zone and can be retrieved using "dig" or other DNS 194 utilities: 196 [carl@example.com]% dig 2795.example.com naptr 198 ; <<>> DiG 9.2.3 <<>> 2795.example.com naptr 199 ;; global options: printcmd 200 ;; Got answer: 201 ;; ->>HEADER<<- opcode: QUERY, 202 status: NOERROR, id: 43494 203 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, 204 AUTHORITY: 2, ADDITIONAL: 1 206 ;; QUESTION SECTION: 207 ;2795.example.com. IN NAPTR 209 ;; ANSWER SECTION: 210 2795.example.com. 86400 IN 211 NAPTR 1 1 "U" "iam+invalid" 212 "!!http://invalid.example.com/contact.html!" . 213 2795.example.com. 86400 IN 214 NAPTR 1 1 "U" "sip+invalid" 215 "!!http://invalid.example.com/contact.html!" . 216 2795.example.com. 86400 IN 217 NAPTR 1 2 "U" "no-solicit" 218 "!!http://infinite.example.com/keywordinfo.html!" . 219 2795.example.com. 86400 IN 220 NAPTR 2 1 "U" "no-solicit" 221 "!!http://infinite.example.com/keywordinfo.html!" . 222 2795.example.com. 86400 IN 223 NAPTR 1 1 "U" "no-solicit" 224 "!!http://infinite.example.com/keywordinfo.html!" . 226 A simple utility written in PERL accepts a lookup key and returns a 227 URI using the specifications in this document. This example is non- 228 normative: 230 #!/usr/bin/perl 232 # THIS SAMPLE CODE IS NOT NORMATIVE 234 # This program accepts a solicitation class keyword and 235 # returns a URI on success. It dies quietly on failure. 236 use strict; 238 # http://www.net-dns.org/ 239 use Net::DNS; 241 # reverse the label to create a domain name 242 $ARGV[0] =~ tr/:/./ ; 243 my $target = join( ".", reverse( split( /\./, $ARGV[0] ) ) ); 245 # create a resolver 246 my $res = Net::DNS::Resolver->new; 248 # find all naptr records 249 my $query = $res->query( "$target", "NAPTR" ) || exit ; 251 # Do your DNSSEC checks here, throw away all invalid RRs 253 # get the answers, strip out non-matching services, 254 # sort by order, preference 255 my @rr sort { 256 # sort records numerically by order, preference 257 $a->order <=> $b->order 258 || $a->preference <=> $b->preference 259 } 260 grep { $_->service =~ /no-solicit/ } $query->answer; 262 # print the first qualifying record, strip out the 263 # regexp markers 264 my $op = substr( my $answer = $rr[0]->regexp , 0, 1 ) 265 || exit ; 266 print split ( $op, $answer ) ; exit ; 268 Running the sample code gives the following results: 270 [carl@example.com]% lynx -source `./discover.pl com.example.2795` 271 272 273 274 About Our Solicitation Class Keyword 275 276 277
278 279 bouncy monkey logo 281
282 283
284 About com.example.2795:
285 It has been determined that the content of this 286 mail message
287 conforms to the spirit of RFC 2795. 288 Congratulations? 289
290 291 293 4. DDDS Application Specification 295 The following definitions apply to this application: 296 o Application Unique String: The application unique string is a 297 Solicitation Class Keyword as defined in [RFC3865]. 298 o First Well Known Rule: The character "." is substituted for the 299 character ":" and then the Solicitation Class Keyword is reversed 300 in order to produce a valid domain name. For example, 301 "com.example:adv" would become "adv.example.com". 302 o Valid Databases: The DNS _is_ the database. 303 o Expected Output: A URI. 304 o The "SERVICE" field MUST contain the string "no-solicit", the 305 "FLAGS" field MUST contain the string "U", the "REPLACEMENT" field 306 MUST be empty, and the "REGEXP" field MUST be formatted as 307 specified in Section 2. 309 Wildcards are appropriate for this application, allowing multiple 310 solicitation class keywords that share a common prefix to all point 311 to the same URI. Note that the NAPTR Resource Record is known as a 312 "subtyping" RR, which means that additional selectors are available 313 within the RR to "winnow down" the choices. This means more records 314 are returned than are actually needed, resulting in more traffic. 315 But, this also means that wildcards may have unintended effects of 316 multiple types of NAPTR resource records are used. Implementors and 317 zone administrators should exercise care in the use of such wildcards 318 in this application. 320 5. Acknowledgments 322 The author would like to thank the following for their helpful 323 suggestions and reviews of this draft: Leslie Daigle, Spencer 324 Dawkins, Arnt Gulbrandsen, Ted Hardie, Scott Hollenbeck, Russ 325 Housley, David Kessens, Peter Koch, Michael Mealling, Pekka Savola, 326 Mark Townsley, and Margaret Wasserman. 328 6. Security Considerations 330 This document specifies an application which depends on the Domain 331 Name System to associate a solicitation class keyword with a URI. 332 Four security considerations are raised by this application: 333 1. If the domain name lookup has been compromised, the application 334 may return a URI with incorrect guidance on the use of a 335 particular solicitation class keyword. In particular, if the 336 application returns a URI with the "https:" scheme, and the DNS 337 Security Extensions as defined in [RFC4033] and related documents 338 are not used, the user would have an unwarranted illusion of 339 authenticity making the possibility of active attacks a serious 340 concern. Even if both DNS Security Extensions and the "https:" 341 scheme are used, the client will need to take additional steps to 342 ensure that the two different digital signature validation 343 contexts are being administered by the same domain owner. 344 2. RFC 3865 bases solicitation class keywords on domain names. 345 However, it does not define whom a user should trust. A sender 346 or an intermediate MTA could insert a solicitation class keyword 347 in a message and then use the application defined in this 348 document to mislead the message recipient. For example, a 349 malicious direct marketer might insert a keyword such as 350 "org.example.certified.message" and use a URI to somehow indicate 351 that the message (wrongly) has some official status. As with any 352 URI, users must take further steps that are outside the scope of 353 this specification to determine what and whom to believe. 354 3. Domain names are not persistent identifiers. As with any 355 application that uses domain names, including the World Wide Web, 356 if a domain name or a URI is embedded in an electronic mail 357 message, there is a possibility that in the future the domain 358 name will be controled by a different zone administrator and that 359 use of the application described in this document will yield 360 different and possibly inconsistent results over time. 361 4. A malicious sender could insert a large number of solicitation 362 class keywords or improperly formatted solicitation keywords, 363 thus performing a Denial of Service attack on the recipient's 364 resources through the use of an excessive number of DNS lookups. 366 If such a message is sent to many recipients, this can result in 367 a Denial of Service attack on the provider at a particular URI 368 (e.g., a large number of requests attempting to access a URI such 369 as "http://example.net/index.html"). Improperly formatted 370 solicitation class keywords, particularly those with a non- 371 existent top level or second level domain, could result in a 372 Denial of Service attack on DNS registry providers or the DNS 373 root servers. 375 7. IANA Considerations 377 There is no central registry maintained by the IANA of values that 378 might appear in the "SERVICE" field of a NAPTR resource record. 379 Thus, no direct IANA actions are required. 381 However, the IANA does maintain an Application Service Tag Registry, 382 which is used to support the S-NAPTR DDDS application defined in 383 [RFC3958]. The IANA is advised that the "no-solicit" value for the 384 SERVICE field is in use per this draft and thus should not be used in 385 the Application Service Tag Registry for other applications. 387 8. References 389 8.1 Normative References 391 [HTML-4.01] 392 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 393 Specification", W3C REC REC-html401-19991224, 394 December 1999. 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 400 Resource Identifiers (URI): Generic Syntax", RFC 2396, 401 August 1998. 403 [RFC2660] Rescorla, E. and A. Schiffman, "The Secure HyperText 404 Transfer Protocol", RFC 2660, August 1999. 406 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 407 Part Two: The Algorithm", RFC 3402, October 2002. 409 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 410 Part Three: The Domain Name System (DNS) Database", 411 RFC 3403, October 2002. 413 [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer 414 Protocol (SMTP) Service Extension", RFC 3865, 415 September 2004. 417 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 418 Service Location Using SRV RRs and the Dynamic Delegation 419 Discovery Service (DDDS)", RFC 3958, January 2005. 421 8.2 Informative References 423 [RFC2795] Christey, S., "The Infinite Monkey Protocol Suite (IMPS)", 424 RFC 2795, April 2000. 426 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 427 April 2001. 429 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 430 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 432 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 433 "Internationalizing Domain Names in Applications (IDNA)", 434 RFC 3490, March 2003. 436 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 437 Resource Identifiers (URI) Dynamic Delegation Discovery 438 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 440 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 441 Rose, "DNS Security Introduction and Requirements", 442 RFC 4033, March 2005. 444 Author's Address 446 Carl Malamud 447 Memory Palace Press 448 PO Box 300 449 Sixes, OR 97476 450 US 452 Email: carl@media.org 454 Appendix A. Intended Status and Discussion (TO BE REMOVED UPON 455 PUBLICATION) 457 This draft is being submitted as an individual submission with an 458 intended publication as a Proposed Standard. Discussion of this 459 draft should take place on the 460 mailing list ( to 461 subscribe). The source and alternative transformations for this 462 draft may be found at . 464 Appendix B. Changes From Previous Draft (TO BE REMOVED UPON 465 PUBLICATION) 467 From draft-malamud-keyword-discovery-04 to 468 draft-malamud-keyword-discovery-05: 469 o Changed IPR to 3978. 470 o Specified that DNS length rules still apply. 471 o Added caution on the use of wildcards. 472 o Clarified that IDN standards govern the encoding of 8-bit data. 473 o Changed registrant to zone administrator. 475 From draft-malamud-keyword-discovery-03 to 476 draft-malamud-keyword-discovery-04: 477 o Revised the abstract to more clearly describe what is in the 478 document. 479 o Minor surgery on the introduction to make it flow better and 480 better state the problem being solved. 481 o Reworked security considerations section to be more specific. 482 o Changed non-normative example to a normative example, adjusting 483 domain names used appropriately. 485 From draft-malamud-keyword-discovery-02 to 486 draft-malamud-keyword-discovery-03: 487 o Added a specification to the first Well Known Rule that the 488 character ":" is translated to the character "." before the 489 Solicitation Class Keyword is reversed. 491 From draft-malamud-keyword-discovery-01 to 492 draft-malamud-keyword-discovery-02: 493 o Clarified intended publication status. 495 From draft-malamud-keyword-discovery-00 to 496 draft-malamud-keyword-discovery-01: 497 o Moved the example from the appendix to the main text. 498 o Added a brief note on use of wildcards to the DDDS application 499 definition. 500 o Minor re-arranging to conform to RFC Editor requirements. 502 Intellectual Property Statement 504 The IETF takes no position regarding the validity or scope of any 505 Intellectual Property Rights or other rights that might be claimed to 506 pertain to the implementation or use of the technology described in 507 this document or the extent to which any license under such rights 508 might or might not be available; nor does it represent that it has 509 made any independent effort to identify any such rights. Information 510 on the procedures with respect to rights in RFC documents can be 511 found in BCP 78 and BCP 79. 513 Copies of IPR disclosures made to the IETF Secretariat and any 514 assurances of licenses to be made available, or the result of an 515 attempt made to obtain a general license or permission for the use of 516 such proprietary rights by implementers or users of this 517 specification can be obtained from the IETF on-line IPR repository at 518 http://www.ietf.org/ipr. 520 The IETF invites any interested party to bring to its attention any 521 copyrights, patents or patent applications, or other proprietary 522 rights that may cover technology that may be required to implement 523 this standard. Please address the information to the IETF at 524 ietf-ipr@ietf.org. 526 Disclaimer of Validity 528 This document and the information contained herein are provided on an 529 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 530 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 531 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 532 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 533 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 534 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 536 Copyright Statement 538 Copyright (C) The Internet Society (2005). This document is subject 539 to the rights, licenses and restrictions contained in BCP 78, and 540 except as set forth therein, the authors retain all their rights. 542 Acknowledgment 544 Funding for the RFC Editor function is currently provided by the 545 Internet Society.