idnits 2.17.1 draft-ietf-msgtrk-mtqp-01.txt: 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 expiration date. The document expiration date should appear on the first and last page. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 16 characters in excess of 72. 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 (November 21, 2000) is 8557 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) == Missing Reference: 'POP3' is mentioned on line 90, but not defined == Missing Reference: 'NNTP' is mentioned on line 90, but not defined == Missing Reference: 'TLS' is mentioned on line 255, but not defined == Unused Reference: 'RFC-821' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC-822' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC-ESMTP' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC-MD5' is defined on line 521, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2234 (ref. 'RFC-ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1651 (ref. 'RFC-ESMTP') (Obsoleted by RFC 1869) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'RFC-MD5') ** Obsolete normative reference: RFC 2554 (ref. 'RFC-SMTPEXT') (Obsoleted by RFC 4954) ** Obsolete normative reference: RFC 2487 (ref. 'RFC-SMTP-TLS') (Obsoleted by RFC 3207) == Outdated reference: A later version (-05) exists of draft-ietf-msgtrk-smtpext-00 == Outdated reference: A later version (-07) exists of draft-ietf-msgtrk-model-03 ** Downref: Normative reference to an Informational draft: draft-ietf-msgtrk-model (ref. 'RFC-TRACK-MODEL') == Outdated reference: A later version (-05) exists of draft-ietf-msgtrk-trkstat-00 ** Obsolete normative reference: RFC 2396 (ref. 'RFC-URI') (Obsoleted by RFC 3986) Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T. Hansen 3 draft-ietf-msgtrk-mtqp-01.txt AT&T Laboratories 4 Valid for six months November 21, 2000 6 Message Tracking Query Protocol 8 10 Authors' version: 1.5 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents at 23 any 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 memo and its companions are discussed on the MSGTRK working 33 group mailing list, ietf-msgtrk@imc.org. To subscribe, send a message 34 with the word "subscribe" in the body (on a line by itself) to the 35 address ietf-msgtrk-request@imc.org. An archive of the mailing list may 36 be found at http://www.ietf.org/archive/msgtrk. 38 Copyright Notice 40 Copyright (C) The Internet Society (1999). All Rights Reserved. 42 Abstract 44 Customers buying enterprise message systems often ask: Can I track 45 the messages? Message tracking is the ability to find out the path that 46 a particular message has taken through a messaging system and the 47 current routing status of that message. This document describes the 48 Message Tracking Query Protocol that is used in conjunction with exten- 49 sions to the ESMTP protocol to provide a complete message tracking solu- 50 tion for the Internet. 52 1. Introduction 54 The Message Tracking Models and Requirements document [RFC-TRACK- 55 MODEL] discusses the models that message tracking solutions could fol- 56 low, along with requirements for a message tracking solution that can be 57 used with the Internet-wide message infrastructure. This memo and its 58 companions, [RFC-TRACK-ESMTP] and [RFC-TRACK-TSN], describe a complete 59 message tracking solution that satisfies those requirements. The memo 60 [RFC-TRACK-ESMTP] defines an extension to the SMTP service that provides 61 the information necessary to track messages. This memo defines a proto- 62 col that can be used to query the status of messages that have been 63 transmitted on the Internet via SMTP. The memo [RFC-TRACK-TSN] 64 describes the message/tracking-status MIME media type that is used to 65 report tracking status information. Using the model document's termi- 66 nology, this solution uses active enabling and active requests with both 67 request and chaining referrals. 69 1.1. Terminology 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC-KEYWORDS]. 75 All syntax descriptions use the ABNF specified by [RFC-ABNF]. Ter- 76 minal nodes not defined elsewhere in this document are defined in [RFC- 77 ABNF], [RFC-URI], [RFC-TRACK-ESMTP] or [RFC-SMTPEXT]. 79 1.2. To Do 81 provide information on finding an MTQP server 83 provide TTL info, maximum times for keeping info 85 determine the TCP port to use 87 2. Basic Operation 89 The Message Tracking Query Protocol (MTQP) is similar to many other 90 line-oriented Internet protocols, such as [POP3] and [NNTP]. Initially, 91 the server host starts the MTQP service by listening on TCP port TBD. 92 When a client wishes to make use of the service, it establishes a TCP 93 connection with the server host. When the connection is established, 94 the MTQP server sends a greeting. The client and MTQP server then 95 exchange commands and responses (respectively) until the connection is 96 closed or aborted. 98 2.1. Commands 100 Commands in MTQP consist of a case-insensitive keyword, possibly 101 followed by one or more parameters. All commands are terminated by a 102 CRLF pair. Keywords and parameters consist of printable ASCII charac- 103 ters. Keywords and parameters are separated by whitespace (one or more 104 space or tab characters). A command line is limited to 998 characters 105 before the CRLF. 107 2.2. Responses 109 Responses in MTQP consist of a status indicator that indicates suc- 110 cess or failure. Successful commands may also be followed by additional 111 lines of data. All response lines are terminated by a CRLF pair and are 112 limited to 998 characters before the CRLF. There are several status 113 indicators: "+OK" indicates success; "+OK+" indicates a success fol- 114 lowed by additional lines of data, a multi-line success response; "- 115 TEMP" indicates a temporary failure; "-ERR" indicates a permanent 116 failure; and "-BAD" indicates a protocol error (such as for unrecognized 117 commands). 119 A status indicator MAY be followed by a series of machine- 120 parseable, case-insensitive response information giving more data about 121 the errors. These are separated from the status indicator and each 122 other by a single slash character ("/", decimal code 47). Following 123 that, there MAY be white space and a human-readable text message. 125 In a multi-line success response, each subsequent line is ter- 126 minated by a CRLF pair and limited to 998 characters before the CRLF. 127 When all lines of the response have been sent, a final line is sent con- 128 sisting of a single period (".", decimal code 046) and a CRLF pair. If 129 any line of the multi-line response begins with a period, the line is 130 "dot-stuffed" by prepending the period with a second period. When exa- 131 mining a multi-line response, the client checks to see if the line 132 begins with a period. If so, and octets other than CRLF follow, the 133 first octet of the line (the period) is stripped away. If so, and if 134 CRLF immediately follows the period, then the response from the MTQP 135 server is ended and the line containing the ".CRLF" is not considered 136 part of the multi-line response. 138 An MTQP server MUST respond to an unrecognized, unimplemented, or 139 syntactically invalid command by responding with a negative -BAD status 140 indicator. A server MUST respond to a command issued when the session 141 is in an incorrect state by responding with a negative -ERR status indi- 142 cator. 144 2.3. Optional Timers 146 An MTQP server MAY have an inactivity autologout timer. Such a 147 timer MUST be of at least 10 minutes in duration. The receipt of any 148 command from the client during that interval should suffice to reset the 149 autologout timer. An MTQP server MAY limit the number of commands or 150 total connection time to prevent denial of service attacks. 152 3. Initialization and Option Response 154 Once the TCP connection has been opened by an MTQP client, the MTQP 155 server issues an initial status response indicates its readiness. If 156 the status response is positive (+OK or +OK+), the client may proceed 157 with other commands. 159 The initial status response MUST include the response information 160 "/MTQP". Negative responses MUST include a reason code as response 161 information. The following reason codes are defined here; unrecognized 162 reason codes added in the future may be treated as equivalent to 163 "unknown". 164 "/" "unavailable" 165 "/" "admin" 166 "/" "unknown" 167 "/" "referral" "=" net_loc 169 If the server has any options enabled, they are listed as the 170 multi-line response of the initial status response, one per line. An 171 option specification consists of an identifier, optionally followed by 172 option-specific parameters. An option specification may be continued 173 onto additional lines by starting the continuation lines with white 174 space. The option identifier is case insensitive. Option identifiers 175 beginning with the characters "vnd." are reserved for vendor use. 177 One option specification is defined here: 179 STARTTLS 181 This capability MUST be listed if the optional STARTTLS command is sup- 182 ported by the MTQP server. It has no parameters. 184 Example #1 (no options): 185 S: +OK/MTQP MTQP server ready 187 Example #2 (service temporarily unavailable): 188 S: -TEMP/MTQP/admin Service down for admin, call back later 190 Example #3 (service permanently unavailable): 191 S: -ERR/MTQP/unavailable Service down 192 Example #4 (alternative for no options): 193 S: +OK+/MTQP MTQP server ready 194 S: . 196 Example #5 (options available): 197 S: +OK+/MTQP MTQP server ready 198 S: starttls 199 S: Option2 with parameters 200 S: Option3 with a very long 201 S: list of parameters 202 S: . 204 Example #6 (Referred to another server): 205 S: -ERR/MTQP/referral=server42.example.com:37 207 4. TRACK Command 209 Syntax: 210 "TRACK" 1*WSP envid 1*WSP mtrk-secret CRLF 212 mtrk-secret = base64 214 Envid is defined in [RFC-TRACK-ESMTP]. Mtrk-secret is the secret S 215 described in [RFC-TRACK-ESMTP], encoded using base64. 217 When the client issues the TRACK command, the MTQP server retrieves 218 tracking information about an email message. A successful response MUST 219 be multi-line, consisting of a [MIME] body part. The default content- 220 type for this MIME body part is message/tracking-status, as defined in 221 [RFC-TRACK-TSN]. The response contains the tracking information about 222 the email message that used the given tracking-id. Multiple responses 223 would be reported using a multipart/mixed body part with 224 message/tracking-status internals. The tracking-id and authorization- 225 cookie are defined in [RFC-TRACK-ESMTP]. 227 TBD: Give details on different modes of responses and how they map 228 into message/tracking-status 230 Example #7 : 231 C: TRACK 1234567890ABCDEF 232 S: +OK+ Tracking information follows 233 S: Content-Type: message/tracking-status 234 S: 235 S: ... details go here when ... 236 S: ... draft-ietf-msgtrk-trkstat becomes available ... 237 S: . 239 5. COMMENT Command 241 Syntax: 242 "COMMENT" opt-text CRLF 244 opt-text = [WSP *(VCHAR / WSP)] 246 When the client issues the COMMENT command, the MTQP server MUST 247 respond with a successful response (+OK or +OK+). All optional text 248 provided with the COMMENT command are ignored. 250 6. STARTTLS Command 252 Syntax: 253 "STARTTLS" CRLF 255 TLS [TLS], more commonly known as SSL, is a popular mechanism for 256 enhancing TCP communications with privacy and authentication. An MTQP 257 server MAY support TLS. If an MTQP server supports TLS, it MUST include 258 "STARTTLS" in the option specifications list on protocol startup. 260 If the server returns a negative response, it MAY use one of the 261 following response codes: 262 "/" "unsupported" 263 "/" "unavailable" 265 After receiving a positive response to a STARTTLS command, the 266 client MUST start the TLS negotiation before giving any other MTQP com- 267 mands. 269 If the MTQP client is using pipelining, the STARTTLS command must 270 be the last command in a group. 272 6.1. Processing After the STARTTLS Command 274 After the TLS handshake has been completed, both parties MUST 275 immediately decide whether or not to continue based on the authentica- 276 tion and privacy achieved. The MTQP client and server may decide to move 277 ahead even if the TLS negotiation ended with no authentication and/or no 278 privacy because most MTQP services are performed with no authentication 279 and no privacy, but some MTQP clients or servers may want to continue 280 only if a particular level of authentication and/or privacy was 281 achieved. 283 If the MTQP client decides that the level of authentication or 284 privacy is not high enough for it to continue, it SHOULD issue an MTQP 285 QUIT command immediately after the TLS negotiation is complete. If the 286 MTQP server decides that the level of authentication or privacy is not 287 high enough for it to continue, it SHOULD reply to every MTQP command 288 from the client (other than a QUIT command) with a negative "-BAD" 289 response and a response code of "/insecure". 291 6.2. Result of the STARTTLS Command 293 Upon completion of the TLS handshake, the MTQP protocol is reset to 294 the initial state (the state in MTQP after a server starts up). The 295 server MUST discard any knowledge obtained from the client prior to the 296 TLS negotiation itself. The client MUST discard any knowledge obtained 297 from the server, such as the list of MTQP options, which was not 298 obtained from the TLS negotiation itself. 300 At the end of the TLS handshake, the server acts as if the connec- 301 tion had been initiated and responds with an initial status response 302 and, optionally, a list of server options. The list of MTQP server 303 options received after the TLS handshake MUST be different than the list 304 returned before the TLS handshake. In particular, a server MUST NOT 305 return the STARTTLS option in the list of server options after a TLS 306 handshake has completed. 308 Both the client and the server MUST know if there is a TLS session 309 active. A client MUST NOT attempt to start a TLS session if a TLS ses- 310 sion is already active. 312 7. QUIT Command 314 Syntax: 315 "QUIT" CRLF 317 When the client issues the QUIT command, the MTQP session ter- 318 minates. The QUIT command has no parameters. The server MUST respond 319 with a successful response. The client may close the session from its 320 end immediately after issuing this command. 322 8. Pipelining 324 The MTQP client may elect to transmit groups of MTQP commands in 325 batches without waiting for a response to each individual command. The 326 MTQP server MUST process the commands in the order received. 328 Specific commands may place further constraints on pipelining. For 329 example, STARTTLS must be the last command in a batch of MTQP commands. 331 The following two examples are identical: 333 Example #8 : 334 C: TRACK 1234567890ABCDEF 335 S: +OK+ Tracking information follows 336 S: 337 S: ... details go here ... 338 S: . 339 C: TRACK ABCDEF1234567890 340 S: +OK+ Tracking information follows 341 S: 342 S: ... details #2 go here ... 343 S: . 345 Example #9 : 346 C: TRACK 1234567890ABCDEF 347 C: TRACK ABCDEF1234567890 348 S: +OK+ Tracking information follows 349 S: 350 S: ... details go here ... 351 S: . 352 S: +OK+ Tracking information follows 353 S: 354 S: ... details #2 go here ... 355 S: . 357 9. URL Format 359 The MTQP URL scheme is used to designate MTQP servers on Internet 360 hosts accessible using the MTQP protocol. An MTQP URL takes one of the 361 following forms: 363 mtqp:///track// 364 mtqp://:/track// 366 The first form is used to refer to an MTQP server on the standard 367 port, while the second form specifies a non-standard port. Both of 368 these forms specify that the TRACK command is to be issued using the 369 given tracking id and authorization cookie. The path element "/track/" 370 is case insensitive, but the envid and mtrk-secret may not be. 372 9.1. MTQP URL Syntax 374 This is an ABNF description of the MTQP URL. 376 mtqp-url = "mtqp://" net_loc "/track/" envid ":" mtrk-secret 378 10. IANA Considerations 380 The service name to be registered with the Internet Assigned Number 381 Authority (IANA) is "MTQP". 383 This document requests that IANA maintain one new registry: MTQP 384 options. 386 Additional options for this protocol whose names do not begin with 387 "vnd." MUST be defined in a standards track or IESG approved experimen- 388 tal RFC. New MTQP options MUST include the following information: 390 option identifier 391 option parameters 392 added commands 393 standard commands affected 394 specification reference 395 discussion 397 Additional options for this protocol whose names begin with "vnd." 398 MUST be registered with IANA on a Firt Come First Served basis. 400 11. Security Considerations 402 Security considerations discussed in [RFC-TRACK-MODEL] and [RFC- 403 TRACK-ESMTP] are relevant. 405 The security of tracking information is dependent on the randomness 406 of the secret chosen for each message and the level of exposure of that 407 secret. If different secrets are used for each message, then the max- 408 imum exposure from tracking any message will be that single message for 409 the time that the tracking information is kept on any MTQP server. If 410 this level of exposure is too much, TLS may be used to reduce the expo- 411 sure further. 413 It should be noted that message tracking is not an end-to-end 414 mechanism. Thus, if an MTQP client/server pair decide to use TLS 415 privacy, they are not securing tracking queries with any prior or suc- 416 cessive MTQP servers. 418 Both the STMP client and server must check the result of the TLS 419 negotiation to see whether acceptable authentication or privacy was 420 achieved. Ignoring this step completely invalidates using TLS for secu- 421 rity. The decision about whether acceptable authentication or privacy 422 was achieved is made locally, is implementation-dependant, and is beyond 423 the scope of this document. 425 The SMTP client and server should note carefully the result of the 426 TLS negotiation. If the negotiation results in no privacy, or if it 427 results in privacy using algorithms or key lengths that are deemed not 428 strong enough, or if the authentication is not good enough for either 429 party, the client may choose to end the MTQP session with an immediate 430 QUIT command, or the server may choose to not accept any more MTQP 431 commands. 433 A man-in-the-middle attack can be launched by deleting the 434 "STARTTLS" option response from the server. This would cause the client 435 not to try to start a TLS session. An MTQP client can protect against 436 this attack by recording the fact that a particular MTQP server offers 437 TLS during one session and generating an alarm if it does not appear in 438 an option response for a later session. 440 If TLS is not used, a tracking request is vulnerable to replay 441 attacks, such that a snoop can later replay the same handshake again to 442 potentially gain more information about a message's status. 444 Before the TLS handshake has begun, any protocol interactions are 445 performed in the clear and may be modified by an active attacker. For 446 this reason, clients and servers MUST discard any knowledge obtained 447 prior to the start of the TLS handshake upon completion of the TLS 448 handshake. 450 12. Protocol Syntax 452 This is a collected ABNF description of the MTQP protocol. 453 conversation = command-response *( client-command command-response ) 455 # client side 456 client-command = track-command / starttls-command / quit-command / comment-command 458 track-command = "TRACK" 1*WS envid 1*WS mtrk-secret CRLF 460 mtrk-secret = base64 462 starttls-command = "STARTTLS" CRLF 464 quit-command = "QUIT" CRLF 466 comment-command = "COMMENT" opt-text CRLF 468 # server side 469 command-response = success-response / temp-response / error-response / bad-response 471 temp-response = "-TEMP" response-info opt-text CRLF 473 opt-text = [WSP *(VCHAR / WSP)] 475 error-response = "-ERR" response-info opt-text CRLF 477 bad-response = "-BAD" response-info opt-text CRLF 478 success-response = single-line-success / multi-line-success 480 single-line-success = "+OK" response-info opt-text CRLF 482 multi-line-success = "+OK+" response-info opt-text CRLF *dataline dotcrlf 484 dataline = *998OCTET CRLF 486 dotcrlf = "." CRLF 488 option-list = *option-line 490 option-line = identifier opt-text *[CRLF WSP opt-text] CRLF 492 identifier = (ALPHA / "_") *(ALPHA / DIGIT / "-" / "_") 494 13. Acknowledgements 496 The description of STARTTLS is based on [RFC-SMTP-TLS]. 498 14. References 500 [MIME] RFC 2045, N. Freed & N. Borenstein, "Multipurpose Internet 501 Mail Extensions (MIME) Part One: Format of Internet Message Bodies", 502 November 1996. 504 [RFC-821] STD 10, RFC 821, J. Postel, "Simple Mail Transfer Proto- 505 col", University of Southern California / Information Sciences Insti- 506 tute, August 1982. 508 [RFC-822] STD 11, RFC 822, D. Crocker, "Standard for the Format of 509 ARPA Internet Text Messages", University of Delaware, August 1982. 511 [RFC-ABNF] RFC 2234, D. Crocker, Editor, and P. Overell, "Augmented 512 BNF for Syntax Specifications: ABNF", November 1997. 514 [RFC-ESMTP] RFC 1651, J. Klensin, N. Freed, M. Rose, E. Stefferud, 515 and D. Crocker, "SMTP Service Extensions", Silicon Graphics, Inc., July 516 1994. 518 [RFC-KEYWORDS] RFC 2119, S. Bradner, "Key words for use in RFCs to 519 Indicate Requirement Levels", March 1997. 521 [RFC-MD5] RFC 1321, R. Rivest, MIT Laboratory for Computer Science 522 and RSA Data Security, Inc., "The MD5 Message-Digest Algorithm", April 523 1992. 525 [RFC-SMTPEXT] RFC 2554, J. Myers, Netscape Communications, "SMTP 526 Service Extension for Authentication", March 1999. 528 [RFC-SMTP-TLS] RFC2487, P. Hoffman, "SMTP Service Extension for 529 Secure SMTP over TLS", Internet Mail Consortium, January 1999. 531 [RFC-TRACK-ESMTP] draft-ietf-msgtrk-smtpext-00.txt, E. Allman, T. 532 Hansen, "SMTP Service Extension for Message Tracking", Sendmail, Inc., 533 AT&T Laboratories, TBD 2000. 535 [RFC-TRACK-MODEL] draft-ietf-msgtrk-model-03.txt, T. Hansen, "Mes- 536 sage Tracking Models and Requirements", AT&T Laboratories, November 537 2000. 539 [RFC-TRACK-TSN] draft-ietf-msgtrk-trkstat-00.txt, E. Allman, "The 540 Message/Tracking-Status MIME Extension", Sendmail, Inc., TBD 2000. 542 [RFC-URI] RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter, "Uni- 543 form Resource Identifiers (URI): Generic Syntax", August 1998. 545 15. Authors' Addresses 547 Tony Hansen 548 AT&T Laboratories 549 Lincroft, NJ 07738 550 USA 552 Phone: +1.732.576.3207 553 E-Mail: tony@att.com 555 16. Full Copyright Statement 557 Copyright (C) The Internet Society (1999). All Rights Reserved. 559 This document and translations of it may be copied and furnished to 560 others, and derivative works that comment on or otherwise explain it or 561 assist in its implmentation may be prepared, copied, published and dis- 562 tributed, in whole or in part, without restriction of any kind, provided 563 that the above copyright notice and this paragraph are included on all 564 such copies and derivative works. However, this document itself may not 565 be modified in any way, such as by removing the copyright notice or 566 references to the Internet Society or other Internet organisations, 567 except as needed for the purpose of developing Internet standards in 568 which case the procedures for copyrights defined in the Internet Stan- 569 dards process must be followed, or as required to translate it into 570 languages other than English. 572 The limited permissions granted above are perpetual and will not be 574 revoked by the Internet Society or its successors or assigns. 576 This document and the information contained herein is provided on 577 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 578 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 579 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 580 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 581 FITNESS FOR A PARTICULAR PURPOSE. 583 This document expires May 21, 2001.