idnits 2.17.1 draft-ietf-nntpext-streaming-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 619. ** 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. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([NNTP], [NNTP-COMMON]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC2970, 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2970, updated by this document, for RFC5378 checks: 1999-07-02) -- 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 (January 2005) is 7042 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) == Missing Reference: 'C' is mentioned on line 422, but not defined == Missing Reference: 'S' is mentioned on line 423, but not defined == Unused Reference: 'ABNF' is defined on line 542, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- No information found for draft-ietf-nntpext-base- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NNTP' Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NNTP Extensions Working Group J. Vinocur 3 Internet Draft Cornell University 4 Updates: 2970 (if approved) K. Murchison 5 Expires: July 2005 Oceana Matrix Ltd. 6 January 2005 8 NNTP Extension for Streaming Feeds 9 draft-ietf-nntpext-streaming-03 11 Status of this memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance 16 with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.html. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This memo defines an extension to the Network News Transport 42 Protocol [NNTP] to provide asynchronous (otherwise known as 43 "streaming") transfer of articles. This allows servers to transfer 44 articles to other servers with much greater efficiency. 46 Section 1 of [NNTP-COMMON] summarizes some ad-hoc transport 47 extensions currently used in the NNTP protocol. This document 48 updates and formalizes the CHECK and TAKETHIS commands and 49 deprecates the MODE STREAM command. 51 Table of Contents 53 0. Changes from Previous Version ............................ 2 54 1. Introduction ............................................. 3 55 1.1. Conventions Used in this Document ................... 3 56 2. The STREAMING Extension .................................. 4 57 2.1. Advertising the STREAMING Extension ................. 4 58 2.2. Streaming Article Transfer .......................... 4 59 2.3. MODE STREAM Command ................................. 5 60 2.3.1. Usage .......................................... 5 61 2.3.2. Description .................................... 5 62 2.3.3. Examples ....................................... 6 63 2.4. CHECK Command ....................................... 6 64 2.4.1. Usage .......................................... 6 65 2.4.2. Description .................................... 6 66 2.4.3. Examples ....................................... 7 67 2.5. TAKETHIS Command .................................... 7 68 2.5.1. Usage .......................................... 7 69 2.5.2. Description .................................... 8 70 2.5.3. Examples ....................................... 8 71 3. Augmented BNF Syntax for the STREAMING Extension ......... 9 72 3.1. Commands ............................................ 10 73 3.2. Command Datastream .................................. 10 74 3.3. Capability entries .................................. 10 75 4. Summary of Response Codes ................................ 10 76 5. Security Considerations .................................. 11 77 6. IANA Considerations ...................................... 11 78 7. References ............................................... 12 79 7.1. Normative References ................................ 12 80 7.2. Informative References .............................. 12 81 8. Authors' Addresses ....................................... 12 82 9. Acknowledgements ......................................... 13 83 10. Intellectual Property Rights ............................ 13 84 11. Copyright ............................................... 13 86 0. Changes from Previous Version 88 New: 89 o Added "Command Datastream" section. 91 Changed: 92 o Use of "streaming", "asynchronous", "pipeline", and 93 "server-to-server". 94 o CAPABILITIES replaces LIST EXTENSIONS. 95 o Wording used for MODE STREAM and examples. 97 o Removed pipelining restriction on MODE STREAM. 98 o Removed (ill-advised) 432 response code as a temporary failure for 99 TAKETHIS. Replaced with discussion of 400 response for temporary 100 failure. 101 o Capabilities are now case-insensitive. 102 o Changed reference to IANA requirements in [NNTP] from Section 8 to 103 Section 3.3.4. 105 Clarified: 106 o MODE STREAM must not have any side effects and must return 501 if 107 any arguments are provided. 108 o TAKETHIS must not be used unless STREAMING is advertised or MODE 109 STREAM returns 203. 111 Outstanding issues: 112 o Are there any security issues with this extension? Is is possible 113 to launch a DoS attack on a non-streaming server by pipelining a 114 bunch of TAKETHIS commands? 116 1. Introduction 118 According to the NNTP specification [NNTP], a peer uses the IHAVE 119 command to query whether a server wants a particular article. 120 Because the IHAVE command cannot be pipelined, the need to stop and 121 wait for the remote end's response greatly restricts the throughput 122 that can be achieved. The alternative method of peer-to-peer 123 article transfer described in this document permits a more 124 consistent use of network bandwidth. 126 1.1. Conventions Used in this Document 128 The notational conventions used in this document are the same as 129 those in [NNTP] and any term not defined in this document has the 130 same meaning as in that one. 132 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 133 NOT", "MAY", and "OPTIONAL" in this document are to be interpreted 134 as described in "Key words for use in RFCs to Indicate Requirement 135 Levels" [KEYWORDS]. 137 This document assumes you are familiar with NNTP [NNTP]. In 138 general, the connections described below are from one peer to 139 another, but we will continue to use "client" to mean the initiator 140 of the NNTP connection, and "server" to mean the other endpoint. 142 In the examples, commands from the client are indicated with [C], 143 and responses from the server are indicated with [S]. 145 2. The STREAMING Extension 147 This extension provides three new commands: MODE STREAM, CHECK, and 148 TAKETHIS. The capability label for this extension is STREAMING. 150 2.1. Advertising the STREAMING Extension 152 A server supporting the streaming commands described in this 153 document will advertise the "STREAMING" capability label in 154 response to the CAPABILITIES command. The server MUST continue to 155 advertise this capability after a client has issued the MODE STREAM 156 command. This capability MAY be advertised both before and after 157 any use of MODE READER, with the same semantics. 159 Example of a client using CAPABILITIES and MODE STREAM on a mode- 160 switching server: 161 [C] CAPABILITIES 162 [S] 101 Capability list: 163 [S] VERSION 2 164 [S] MODE-READER 165 [S] IHAVE 166 [S] LIST ACTIVE 167 [S] STREAMING 168 [S] . 169 [C] MODE STREAM 170 [S] 203 Streaming permitted 171 [C] CAPABILITIES 172 [S] 101 Capability list: 173 [S] VERSION 2 174 [S] MODE-READER 175 [S] IHAVE 176 [S] LIST ACTIVE 177 [S] STREAMING 178 [S] . 179 [C] MODE READER 180 [S] 200 Posting allowed 181 [C] CAPABILITIES 182 [S] 101 Capability list: 183 [S] VERSION 2 184 [S] READER POST 185 [S] LIST ACTIVE NEWSGROUPS 186 [S] HDR 187 [S] . 189 2.2. Streaming Article Transfer 191 The STREAMING extension provides the same functionality as the 192 IHAVE command ([NNTP] section 6.3.2) but splits the query and 193 transfer functionality into the CHECK and TAKETHIS commands 194 respectively. This allows the CHECK and TAKETHIS commands to be 195 pipelined (unlike IHAVE) and provides for "streaming" article 196 transfer. 198 A streaming client will often pipeline many CHECK commands and use 199 the responses to construct a list of articles to be sent by a 200 pipelined sequence of TAKETHIS commands, thus increasing the 201 fraction of time spent transferring articles. The CHECK and 202 TAKETHIS commands utilize distinct response codes so that these 203 commands can be intermingled in a pipeline and the response to any 204 single command can be definitively identified by the client. 206 The client MAY send articles via TAKETHIS without first querying 207 the server with CHECK. The client SHOULD NOT send every article in 208 this fashion unless explicitly configured to do so by the site 209 administrator based on out-of-band information. However, the 210 client MAY use an adaptive strategy where it initially sends CHECK 211 commands for all articles, but switches to using TAKETHIS without 212 CHECK if most articles are being accepted (over 95% acceptance may 213 be a reasonable metric in some configurations). If the client uses 214 such a strategy, it SHOULD also switch back to using CHECK on all 215 articles if the acceptance rate ever falls much below the 216 threshold. 218 2.3. MODE STREAM Command 220 Historically this command was used by a client to discover if a 221 server supported the STREAMING extension. This command is 222 deprecated in favor of the CAPABILITIES discovery command and is 223 only documented here for compatibility with legacy implementations 224 of the STREAMING extension. New clients SHOULD use the 225 CAPABILITIES command to check a server for support of the STREAMING 226 extension but MAY implement and use the MODE STREAM command for 227 backwards compatibility. 229 2.3.1. Usage 231 Syntax 232 MODE STREAM 234 Responses 235 203 Streaming permitted 237 2.3.2. Description 239 If a server supports the CHECK and TAKETHIS commands it MUST return 240 a 203 response to the MODE STREAM command (or 501 if an argument is 241 given) and MUST NOT have any other effect. 243 A server MUST NOT require that the MODE STREAM command be issued by 244 the client before accepting the CHECK or TAKETHIS commands. A 245 server SHOULD accept the MODE STREAM command for compatibility with 246 legacy clients which don't use the CAPABILITIES discovery 247 mechanism. 249 2.3.3. Examples 251 Example of a client checking the ability to stream articles on a 252 legacy server which does not support this extension: 253 [C] MODE STREAM 254 [S] 501 Unknown MODE variant 256 Example of a client checking the ability to stream articles on a 257 legacy server which supports this extension: 258 [C] MODE STREAM 259 [S] 203 Streaming permitted 261 2.4. CHECK Command 263 2.4.1. Usage 265 Syntax 266 CHECK message-id 268 Responses 269 238 message-id Send article to be transferred 270 431 message-id Transfer not possible; try again later 271 438 message-id Article not wanted 273 Parameters 274 message-id = Article message-id 276 The first parameter of the 238, 431, and 438 responses MUST be the 277 message-id provided by the client as the parameter to CHECK. 279 2.4.2. Description 281 The CHECK command informs the server that the client has an article 282 with the specified message-id. If the server desires a copy of 283 that article a 238 response MUST be returned, indicating that the 284 client may send the article using the TAKETHIS command. If the 285 server does not want the article (if, for example, the server 286 already has a copy of it), a 438 response MUST be returned, 287 indicating that the article is not wanted. Finally, if the article 288 isn't wanted immediately but the client should retry later if 289 possible (if, for example, another client has offered to send the 290 same article to the server), a 431 response MUST be returned. Note 291 however, that the responses to CHECK are advisory; the server MUST 292 NOT rely on the client to behave as requested by these responses. 294 2.4.3. Examples 296 Example of a client checking whether the server would like a set of 297 articles and getting a mixture of responses: 299 [C] CHECK 300 [S] 238 301 [C] CHECK 302 [S] 438 303 [C] CHECK 304 [S] 431 306 Example of pipelining the CHECK commands in the previous example: 308 [C] CHECK 309 [C] CHECK 310 [C] CHECK 311 [S] 238 312 [S] 438 313 [S] 431 315 2.5. TAKETHIS Command 317 2.5.1. Usage 319 A client MUST NOT use this command unless the server advertises the 320 STREAMING capability or returns a 203 response to the MODE STREAM 321 command. 323 Syntax 324 TAKETHIS message-id 326 Responses 327 239 message-id Article transferred OK 328 439 message-id Transfer rejected; do not retry 330 Parameters 331 message-id = Article message-id 333 The first parameter of the 239 and 439 responses MUST be the 334 message-id provided by the client as the parameter to TAKETHIS. 336 2.5.2. Description 338 The TAKETHIS command is used to send an article with the specified 339 message-id to the server. The article is sent immediately 340 following the CRLF at the end of the TAKETHIS command line. The 341 client MUST send the entire article, including headers and body, in 342 the format defined in Section 3.1 of [NNTP] for multi-line 343 responses (except that there is no initial line containing a 344 response code). Thus a single dot (".") on a line indicates the 345 end of the text, and lines starting with a dot in the original text 346 have that dot doubled during transmission. The server MUST return 347 either a 239 response, indicating that the article was successfully 348 transferred or a 439 response, indicating that the article was 349 rejected. If the server encounters a temporary error that prevents 350 it from processing the article but does not want to reject the 351 article, it MUST reply with a 400 response to the client and close 352 the connection. 354 This function differs from the POST command in that it is intended 355 for use in transferring already-posted articles between hosts. It 356 SHOULD NOT be used when the client is a personal news reading 357 program, since use of this command indicates that the article has 358 already been posted at another site and is simply being forwarded 359 from another host. However, despite this, the server MAY elect not 360 to post or forward the article if, after further examination of the 361 article, it deems it inappropriate to do so. Reasons for such 362 subsequent rejection of an article may include such problems as 363 inappropriate newsgroups or distributions, disc space limitations, 364 article lengths, garbled headers, and the like. These are 365 typically restrictions enforced by the server host's news software 366 and not necessarily the NNTP server itself. 368 The client SHOULD NOT assume that the article has been successfully 369 transferred unless it receives an affirmative response from the 370 server. A lack of response (such as a dropped network connection 371 or a network timeout) or a 400 response SHOULD be treated as a 372 temporary failure and cause the transfer to be tried again later if 373 possible. 375 Because some news server software may not be able immediately to 376 determine whether or not an article is suitable for posting or 377 forwarding, an NNTP server MAY acknowledge the successful transfer 378 of the article (with a 239 response) but later silently discard it. 380 2.5.3. Examples 382 Example of streaming two articles to another site (the first 383 article is accepted and the second is rejected): 385 [C] TAKETHIS 386 [C] Path: pathost!demo!somewhere!not-for-mail 387 [C] From: "Demo User" 388 [C] Newsgroups: misc.test 389 [C] Subject: I am just a test article 390 [C] Date: 6 Oct 1998 04:38:40 -0500 391 [C] Organization: An Example Com, San Jose, CA 392 [C] Message-ID: 393 [C] 394 [C] This is just a test article. 395 [C] . 396 [C] TAKETHIS 397 [C] Path: pathost!demo!somewhere!not-for-mail 398 [C] From: "Demo User" 399 [C] Newsgroups: misc.test 400 [C] Subject: I am just a test article 401 [C] Date: 6 Oct 1998 04:38:40 -0500 402 [C] Organization: An Example Com, San Jose, CA 403 [C] Message-ID: 404 [C] 405 [C] This is just a test article. 406 [C] . 407 [S] 239 408 [S] 439 410 Example of sending an article to a site where the transfer fails: 412 [C] TAKETHIS 413 [C] Path: pathost!demo!somewhere!not-for-mail 414 [C] From: "Demo User" 415 [C] Newsgroups: misc.test 416 [C] Subject: I am just a test article 417 [C] Date: 6 Oct 1998 04:38:40 -0500 418 [C] Organization: An Example Com, San Jose, CA 419 [C] Message-ID: 420 [C] 421 [C] This is just a test article. 422 [C] . 423 [S] 400 Service temporarily unavailable 424 [Server closes connection.] 426 3. Augmented BNF Syntax for the STREAMING Extension 428 This section describes the syntax of the STREAMING extension. It 429 extends the syntax in [NNTP], and non-terminals not defined in this 430 document are defined there. 432 3.1. Commands 434 This syntax extends the non-terminal "command", which represents an 435 NNTP command. 437 command =/ check-command / 438 mode-stream-command / 439 takethis-command 441 check-command = "CHECK" WS message-id 442 mode-stream-command = "MODE" WS "STREAM" 443 takethis-command = "TAKETHIS" WS message-id 445 3.2. Command Datastream 447 This syntax extends the non-terminal "command-datastream", which 448 represents the further material sent by the client in the case of 449 streaming commands. 451 command-datastream =/ takethis-datastream 452 takethis-datastream = encoded-article 454 3.3. Capability entries 456 This syntax extends the non-terminal "capability-entry", which 457 represents a capability that may be advertised by the server. 459 capability-entry =/ streaming-capability 460 streaming-capability = "STREAMING" 462 4. Summary of Response Codes 464 This section contains a list of every new response code defined in 465 this document, whether it is multi-line, which commands can 466 generate it, what arguments it has, and what its meaning is. 468 Response code 203 469 Generated by: MODE STREAM 470 Meaning: streaming permitted. 472 Response code 238 473 Generated by: CHECK 474 Meaning: send article to be transferred. 476 Response code 239 477 Generated by: TAKETHIS 478 Meaning: article transferred OK. 480 Response code 431 481 Generated by: CHECK 482 Meaning: transfer not possible; try again later. 484 Response code 438 485 Generated by: CHECK 486 Meaning: article not wanted. 488 Response code 439 489 Generated by: TAKETHIS 490 Meaning: transfer rejected; do not retry. 492 5. Security Considerations 494 No new security considerations are introduced by this extension, 495 beyond those already described in the core specification [NNTP]. 497 6. IANA Considerations 499 This section gives a formal definition of the STREAMING extension 500 as required by Section 3.3.4 of [NNTP] for the IANA registry. 502 o The STREAMING extension provides for streaming transfer of 503 articles. 505 o The capability label for this extension is "STREAMING". 507 o The capability label has no arguments. 509 o The extension defines three new commands, MODE STREAM, CHECK, 510 and TAKETHIS, whose behavior, arguments, and responses are 511 defined in Sections 2.2, 2.3, and 2.4 respectively. 513 o The extension does not associate any new responses with pre- 514 existing NNTP commands. 516 o The extension does not affect the behavior of a server or client 517 other than via the new commands. 519 o The extension does not affect the maximum length of commands or 520 initial response lines. 522 o The extension does not alter pipelining, and the MODE STREAM, 523 CHECK and TAKETHIS command can be pipelined. 525 o Use of this extension does not alter the capabilities list. 527 o The extension does not cause any pre-existing command to produce 528 a 401, 480, or 483 response. 530 o Use of the MODE READER command on a mode-switching server may 531 disable this extension. 533 o Published Specification: This document. 535 o Author, Change Controller, and Contact for Further Information: 536 Author of this document. 538 7. References 540 7.1. Normative References 542 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax 543 Specifications: ABNF", RFC 2234, November 1997. 545 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", RFC 2119, March 1997. 548 [NNTP] Feather, C., "Network News Transport Protocol", 549 draft-ietf-nntpext-base-*.txt, Work in Progress. 551 7.2. Informative References 553 [NNTP-COMMON] Barber, S., "Common NNTP Extensions", RFC 2980, 554 Academ Consulting Services, October 2000. 556 8. Authors' Addresses 558 Jeffrey M. Vinocur 559 Department of Computer Science 560 Upson Hall 561 Cornell University 562 Ithaca, NY 14853 564 EMail: vinocur@cs.cornell.edu 566 Kenneth Murchison 567 Oceana Matrix Ltd. 568 21 Princeton Place 569 Orchard Park, NY 14127 USA 571 Email: ken@oceana.com 573 9. Acknowledgements 575 This document is based heavily on the relevant sections of RFC 2980 576 [NNTP-COMMON], by Stan Barber. 578 Special acknowledgment also goes to Russ Allbery, Clive Feather, 579 and others who commented privately on intermediate revisions of 580 this document, as well as the members of the IETF NNTP Working 581 Group for continual (yet sporadic) insight in discussion. 583 10. Intellectual Property Rights 585 The IETF takes no position regarding the validity or scope of any 586 intellectual property or other rights that might be claimed to 587 pertain to the implementation or use of the technology described in 588 this document or the extent to which any license under such rights 589 might or might not be available; neither does it represent that it 590 has made any effort to identify any such rights. Information on 591 the IETF's procedures with respect to rights in standards-track and 592 standards-related documentation can be found in BCP-11. Copies of 593 claims of rights made available for publication and any assurances 594 of licenses to be made available, or the result of an attempt made 595 to obtain a general license or permission for the use of such 596 proprietary rights by implementers or users of this specification 597 can be obtained from the IETF Secretariat. 599 The IETF invites any interested party to bring to its attention any 600 copyrights, patents or patent applications, or other proprietary 601 rights which may cover technology that may be required to practice 602 this standard. Please address the information to the IETF 603 Executive Director. 605 11. Copyright 607 Copyright (C) The Internet Society (2005). This document is 608 subject to the rights, licenses and restrictions contained in BCP 609 78, and except as set forth therein, the authors retain all their 610 rights." 612 This document and the information contained herein are provided on 613 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 614 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 615 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 616 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 617 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 618 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 619 PARTICULAR PURPOSE.