idnits 2.17.1 draft-ietf-fax-eifax-02.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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 521 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2305]), 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC 2305' is mentioned on line 259, but not defined ** Obsolete undefined reference: RFC 2305 (Obsoleted by RFC 3965) == Missing Reference: 'PGPMIME' is mentioned on line 349, but not defined == Missing Reference: 'MIME-SECURE' is mentioned on line 348, but not defined == Missing Reference: 'IPSEC' is mentioned on line 358, but not defined == Unused Reference: 'MEDIA' is defined on line 421, but no explicit reference was found in the text == Unused Reference: 'FEATURES' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC1825' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'RFC1847' is defined on line 436, but no explicit reference was found in the text == Unused Reference: 'RFC2015' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'RFC2301' is defined on line 454, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-myers-smtp-auth-11 -- No information found for draft-ietf-fax-report-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'REPORT-EXTENSIONS' -- Possible downref: Normative reference to a draft: ref. 'MDN-FEATURES' == Outdated reference: A later version (-05) exists of draft-ietf-conneg-media-features-00 == Outdated reference: A later version (-03) exists of draft-ietf-conneg-feature-reg-00 == Outdated reference: A later version (-04) exists of draft-ietf-fax-goals-02 ** Downref: Normative reference to an Informational draft: draft-ietf-fax-goals (ref. 'GOALS') ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1891 (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1894 (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 2298 (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 2301 (Obsoleted by RFC 3949) ** Obsolete normative reference: RFC 2305 (Obsoleted by RFC 3965) ** Obsolete normative reference: RFC 974 (Obsoleted by RFC 2821) == Outdated reference: A later version (-04) exists of draft-ietf-fax-smtp-session-02 -- Possible downref: Normative reference to a draft: ref. 'SESSION' == Outdated reference: A later version (-08) exists of draft-ietf-smime-msg-04 Summary: 17 errors (**), 0 flaws (~~), 20 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Fax Working Group Larry Masinter 2 Internet Draft Xerox Corporation 3 August 3, 1998 Dan Wing 4 Expires January 1999 Cisco Systems 5 draft-ietf-fax-eifax-02.txt 7 Extended Facsimile Using Internet Mail 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 This draft is being discussed by the IETF FAX working group. To 29 subscribe to the mailing list, send a message to 30 ietf-fax-request@imc.org with the line "subscribe" in the body of the 31 message. Archives are available from http://www.imc.org/ietf-fax. 33 Copyright Notice 35 Copyright (C) The Internet Society (1998). All Rights Reserved. 37 Abstract 39 This document describes extensions to "Simple Mode of Facsimile 40 Using Internet Mail" [RFC2305] to accomplish additional features, 41 including transmission of enhanced document characteristics (higher 42 resolution, color), confirmation of delivery, quick message 43 delivery, GSTN billing information, and message confidentiality. 45 Note: some features in this Internet Draft are being actively 46 discussed in the Internet Fax working group and amongst experts in 47 both facsimile and email. This document does not represent a final 48 consensus of the working group, but is offered as a probable 49 resolution of those discussions, based on current directions, as 50 the proposals are believed to be consistent with the goals of 51 Internet Fax as well as current standards-track directions for 52 email protocols. 54 1. Introduction 56 This document notes a number of enhancements to the "Simple Mode of 57 Facsimile Using Internet Mail" [RFC2305] that may be combined to 58 create an extended mode of facsimile using Internet mail. 60 To promote interoperability, the new features are designed to be 61 interoperable with the existing base of mail transfer agents (MTAs) 62 and mail user agents (MUAs), and take advantage of standards-track 63 mechanisms for positive delivery and disposition notifications. 64 Thus, the enhancements described in this document utilize the 65 messaging infrastructure, where possible, instead of creating 66 fax-specific features which are unlikely to be implemented in 67 non-fax messaging software. 69 This document describes a protocol suite that satisfies all of the 70 required and highly desirable features identified in [GOALS]: 72 * Delivery confirmation (Section 2) (required) 73 * Additional document features (Section 3) (optional) 74 * Quick delivery and confirmation (Section 4) (optional) 75 * Confidentiality (Section 5) (optional) 77 A device which supports all of these recommendations is called an 78 EIFax (Extended Internet Fax) device. 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Delivery and Processing Confirmation 86 2.1. Background 88 This section explains the background of delivery confirmation for 89 facsimile and Internet mail as a justification for the protocol 90 requirements made in section 2.2. 92 In traditional facsimile, the sending terminal receives a 93 confirmation when the receiving terminal has finished processing 94 the incoming fax. 96 In Internet Mail, the operations of Delivery (to the mailbox) and 97 Disposition (to paper or a screen) may be separated in time and 98 location. The confirmation of these two operations are supplied by 99 two different standards-track documents, Delivery Status 100 Notifications (DSN) [RFC1891, RFC1894] and Message Disposition 101 Notifications (MDN) [RFC2298] respectively. 103 a) how they are requested: 104 Delivery status notifications are requested within the SMTP 105 protocol using SMTP extensions [RFC1891], while disposition 106 notifications are requested by including a 107 Disposition-Notification-To header in the message. 109 b) when they are reported: 110 Delivery status is reported when a message is delivered to some 111 repository or end-point under the control of the recipient. 112 Disposition notification (MDN) is provided when the message is 113 disposed of by the recipient user, either manually or 114 automatically. 116 c) which agent reports them: 117 Delivery status is reported by the mail transport mechanism, while 118 disposition is reported by the end mail user agent. 120 d) what form the reports take: 121 Both DSNs and MDNs are sent in a "multipart/report". DSNs use 122 "report-type=delivery-status"; MDNs use 123 "report-type=disposition-notification". 125 e) the requirement for notification: 126 The standards for MDNs and DSNs differ on the requirement for 127 automatically generating them. The generation of MDNs by any 128 recipient is entirely optional, and thus no sender can rely on 129 obtaining a MDN from an arbitrary recipient. The generation of some 130 kind of DSN (if only a 'relayed' message) is required and a 131 standard part of MTA operation. 133 2.2. Confirmation Requirements 135 This section defines requirements for devices or services that are to 136 be considered compliant with the delivery and processing confirmation 137 section of this memo. 139 2.2.1. EIFax Sender Requirements 141 2.2.1.1. Delivery Confirmation 143 If the sender wishes to receive a delivery confirmation or an 144 indication that delivery confirmation is not possible, an EIFax 145 sender MUST request a DSN [RFC1891] from its mail submission server 146 (MTA) using the RCPT command with the esmtp-keyword NOTIFY and 147 including esmtp-keyword SUCCESS. Other esmtp-keywords such as 148 DELAY and FAILURE may also be requested if the sender wishes 149 to receive notification of delivery delays or delivery failures). 151 The envelope-from address provided by the EIFax sender MUST be able 152 to receive all types of Delivery Status Notifications [RFC1894] and 153 be able to receive delivery failure or delayed delivery message that 154 are not in the Delivery Status Notification format [RFC1894]. 156 2.2.1.2. Processing Confirmation 158 If an EIFax sender wishes to receive processing confirmation 159 and the final recipient is a Mail User Agent, the EIFax sender 160 MUST request an MDN [RFC2298]. 162 If an EIFax sender wishes to receive processing confirmation 163 and the final recipient is a fax offramp implemented as an 164 MTA, the fax offramp will generate processing confirmation 165 in the absense of an MDN request, so an MDN request is not 166 necessary. 168 If an EIFax sender wishes to receive processing confirmation 169 and is unaware of the recipient's implementation, the EIFax sender 170 SHOULD request an MDN. 172 NOTE: Because a request for an MDN can be silently ignored [section 173 2.1 of RFC2298], MDNs MUST NOT be used for delivery 174 confirmation, but only be used for confirmation a message was 175 processed. 177 NOTE: Receipt of an MDN MUST NOT be construed as any indication that 178 an MDN will be sent in response to another message requesting 179 an MDN. 181 The address provided by the EIFax sender on the 182 Disposition-Notification-To field MUST be able to receive Message 183 Disposition Notifications messages [RFC2298] and be able to receive 184 messages that are not in the Message Disposition Notification format 185 (due to the existance of legacy systems that utilize the same header 186 but do not generate RFC2298-compliant responses). 188 2.2.2. EIFax Recipient Requirements 190 All EIFax recipients SHOULD implement MDN [RFC2298], and SHOULD 191 implement Fax Extensions for DSN and MDN [REPORT-EXTENSIONS], 192 and MUST be configurable to silently ignore a request for an MDN 193 ([section 2.1 of RFC2298]). 195 2.2.2.1. Fax Offramp Requirements 197 A "Fax Offramp" is defined as a device that obtains a message 198 and connect to a fax machine, communicates using the fax protocol to 199 that fax machine, and transmits the message to that fax machine. 201 2.2.2.1.1. Fax Offramps Implemented as SMTP Servers 203 MUST implement Delivery Status Notifications [RFC1891 through 204 RFC1894], and SHOULD implement Fax Extensions for DSN and MDN 205 [REPORT-EXTENSIONS]. 207 If a successful DSN was requested and an MDN was requested, the MDN 208 SHOULD NOT be sent -- only the DSN needs to be sent. 210 The offramp MUST NOT use anything but the RFC821 envelope-to field to 211 make any decision about the actual telephone number to dial. 213 2.2.2.1.2. Fax Offramps Implemented as POP/IMAP Clients 215 MUST NOT generate a Delivery Status Notification message [RFC1894]. 217 The offramp MUST NOT use anything but the POP/IMAP username to map to 218 a single telephone number. For example, it MUST NOT use any RFC822 219 field or information within the message body or MIME parts to make 220 any decision about the telephone number to dial. 222 2.2.3. EIFax Messaging Infrastructure Requirements 224 This section explains the requirements of the SMTP messaging 225 infrastructure used by the EIFax sender and receiver. This 226 infrastructure is commonly provided by the ISP or a company's 227 internal mailers but can actually be provided by another organization 228 with appropriate service contracts. 230 2.2.3.1. Sender Infrastructure 232 Support for DSN [RFC1891] MUST be provided by the mail submission 233 server used by the EIFax sender, and SHOULD/MUST (?) be provided up 234 to the mailer responsible for communicating with external (Internet) 235 mailers. 237 2.2.3.2. Receiver Infrastructure 239 Support for DSN [RFC1891] SHOULD/MUST (?) be provided by the external 240 (Internet-accessible) mailer, and SHOULD/MUST (?) be provided by each 241 mailer between the external mailer and the EIFax recipient. 243 3. Additional document capabilities 245 Section 4 of [RFC2305] only allows sending the minimum subset 246 of TIFF for Facsimile "unless the sender has prior knowledge 247 of otehr TIFF fields or values supported by the recipient." 249 Various methods for the sender to aquire such knowledge have 250 been proposed: 252 1. Sender manual configuration 253 2. Message Disposition Notification Extension 254 3. Capabilities in Directory 256 3.1 Sender manual configuration 258 One way a sender can send a document which exceeds the minimum 259 subset allowed by [RFC 2305] is for the user controlling the sender 260 to manually override the default settings, at least for particular 261 recipients. 263 If there were well-known configurations with combined capabilities, 264 those capabilities could be described in the sender's user 265 interface. For example, a vendor or trade association could create 266 a profile of recipient capabilities that would describe an extended 267 set of TIFF features and image sizes, and then the sender could 268 manually be configured to send such files if the user controlling 269 the sender knows of the recipient capabilities. 271 For example, a trade association could create a profile named 272 "SuperInterFax", which would signify the ability to accept TIFF 273 profiles M, P, and F and any TIFF resolution and media size. 274 With this profile, a user could manually decide to send a 275 "SuperInterFax" to an address that was advertised to accept 276 this profile. 278 While awkward, this mechanism reflects the current state of 279 deployment of configuration for extended capabilities to ordinary 280 Internet email users. 282 3.2 Message Disposition Notification Extension 284 As outlined in section 2.2.1, an EIFax sender MAY request a Message 285 Disposition Notification. 287 If the recipient supports responding to such a message, and the 288 recipient authorizes responding to the MDN request, the recipient's 289 MDN MAY contain information describing the recipient's capabilities 290 as described in [MDN-FEATURES]. 292 EIFax senders MAY retain a local cache of information about the 293 features supported by recipients. When an EIFax device sends a 294 message to a specific recipient, it MAY use cached information to 295 determine the recipient's capabilities to handle extended document 296 features such as defined in [MDN-FEATURES]. 298 3.3 Capabilities in Directory 300 A future direction for enhanced document features is to create a 301 directory structure of recipient capabilities, deployed, for 302 example, through LDAP or DNS. The directory would provide a 303 mechanism by which a sender could determine a recipient's 304 capabilities before message construction or transmission, using a 305 directory lookup. Such mechanisms are not defined in this document. 307 4. Quick Delivery and Confirmation 309 [SESSION] describes a method by which delivery confirmation may be 310 delivered quickly if there is a direct connection between sender 311 and recipient. EIFax devices SHOULD implement 312 [SESSION]. Intermediate MTAs, e.g., as part of firewalls, MAY also 313 act as [SESSION] gateways, allowing for immediate delivery, with 314 fallback to store-and-forward. 316 EIFax devices MAY implement standard Internet mail routing using 317 the domain name system [RFC974]. EIFax devices MAY be SMTP 318 recipients registered as the primary mail exchanger for their 319 domain. This combination will allow the sending EIFax device to 320 communicate directly with the recipient device. 322 5. Security 324 Many uses of Internet Fax require greater security; the requirements 325 for security are discussed in [GOALS]. EIFax supports security by 326 providing for secured content and connections. 328 5.1 Content 330 To secure the contents of the message itself, EIFax devices SHOULD 331 implement S/MIME [SMIME] or PGP-MIME [PGPMIME] or both; these 332 systems are based on the security framework for MIME [MIME-SECURE]. 334 5.1.1 Authentication 336 EIFax devices SHOULD use the multipart/signed MIME type using 337 S/MIME or PGP-MIME signed messages. An EIFax SHOULD sign each 338 message with the identity of the originating user or with the 339 identity of the originating machine or service. An EIFax sender MAY 340 choose its method of signing a message. An EIFax recipient SHOULD 341 verify the signature of all received messages and indicate in any 342 particular way whether the message is unsigned, signed with an 343 unverifiable signature, signed with a signature that does not 344 verify, or signed with a verified signature. 346 5.1.2 Privacy 348 Using the methods of [MIME-SECURE], an EIFax device MAY use either 349 S/MIME [SMIME] or PGP-MIME [PGPMIME] to envelope the content of a 350 document. Enveloping MAY be applied either before or after signing. 352 Enveloped data should only be sent if the recipient's capability to 353 decode the enveloped data is known. 355 5.2 Connections 357 To secure the connection itself, including the envelope itself, EIFax 358 devices should implement [AUTH] or IPSsec [IPSEC]. 360 5.3 When to use security 362 The capability to perform secure transfer is discovered by a sender 363 either through a manual process or by discovering the public key of 364 the recipient. Senders may unilaterally send multipart/signed 365 documents using the signature method of their choice. 367 6. Security considerations 369 [RFC2305] describes the security environment of facsimile and the 370 considerations. This memo extends the requirements of RFC 2305 to 371 specifically recommend the use of both PGP and S/MIME. 373 Inaccurate capability information (section 3) could cause a denial 374 of service. The capability information could be inaccurate due to 375 many reasons, including compromised or improperly configured 376 directory server, improper manual configuration of sender, 377 compromised DNS, or spoofed MDN. If a sender is using cached 378 capability information, it SHOULD be manually confirmed by a user 379 before it is automatically used. 381 7. Implementation Notes 383 7.1 POP Clients and Message Disposition Notifications 385 If multiple POP clients are accessing the same mailbox the POP 386 clients MUST be configurable to leave mail on server (LMOS). This is 387 because the MDN specification permits only one response [section 2.1, 388 RFC2298], and beacuse POP doesn't include a mechanism to indicate if 389 an MDN has already been generated by a POP client. 391 8. Acknowledgements 393 The authors would like to acknowledge the following contributors 394 to this specification, in alphabetical order: 396 Vivian Cancio, Xerox 397 David Crocker, Brandenburg Consulting 398 Ned Freed, Innosoft 399 Graham Klyne, Integralis Ltd. 400 Geoff Marshall, ___ 401 Keith Moore, University of Tennessee 402 George Pajari, Faximum Software Inc. 403 James Rafferty, Human Communications 404 Richard Shockey, ___ 405 Brian Stafford, Office Logic 406 Maeda Toru, Canon 408 9. References 410 [AUTH] J. Myers, "SMTP Service Extension for Authentication", 411 draft-myers-smtp-auth-11.txt, Internet Draft, Work in Progress, 412 February 1998. 414 [REPORT-EXTENSIONS] D. Wing, "Fax Extensions to DSN and MDN" Internet 415 Draft, Work in Progress, draft-ietf-fax-report-extensions.txt. 417 [MDN-FEATURES] L. Masinter and D. Wing, "Using Message Disposition 418 Notifications to Indicate Supported Features", Internet Draft, Work 419 in Progress, draft-ietf-fax-mdn-features-01.txt, March 1998. 421 [MEDIA] "Media Features for Display, Print, and Fax", L. Masinter, K. 422 Holtman, A. Mutz, D. Wing, Internet Draft, Work in Progress, 423 draft-ietf-conneg-media-features-00.txt, March 1998. 425 [FEATURES] K. Holtman, A. Mutz, T. Hardie, "Feature Tag Registration 426 Procedures", Internet Draft, Work in Progress, 427 draft-ietf-conneg-feature-reg-00.txt, March 1998. 429 [GOALS] L. Masinter, "Terminology and Goals for Internet Fax", 430 Internet Draft, Work in Progress, draft-ietf-fax-goals-02.txt, March 431 1998. 433 [RFC1825] R. Atkinson, "Security Architecture for the Internet 434 Protocol", RFC 1825, Naval Research Laboratory, August 1995. 436 [RFC1847] "Security Multiparts for MIME: Multipart/Signed and 437 Multipart/Encrypted", RFC 1847, October 1995. 439 [RFC1891] K. Moore, "SMTP Service Extensions for Delivery Status 440 Notifications", RFC 1891, January 1996. 442 [RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for 443 Delivery Status Notifications", RFC 1894, January 1996 445 [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", 446 RFC2015, October 1996. 448 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 449 Requirement Levels", RFC 2119, March 1997. 451 [RFC2298] R. Fajman, "An Extensible Message Format for Message 452 Disposition Notifications", RFC 2298, March 1998. 454 [RFC2301] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, 455 J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998. 457 [RFC2305] K.Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of 458 Facsimile Using Internet Mail", RFC 2305, March 1998. 460 [RFC974] C. Partridge. "Mail routing and the domain system", RFC 974, 461 January 1986. 463 [SESSION] N. Joffe, D. Wing, L. Masinter, "SMTP Service Extension for 464 Immediate Delivery", Internet Draft, Work in Progress, 465 draft-ietf-fax-smtp-session-02.txt, Feb 1998. 467 [SMIME] B. Ramsdell. "S/MIME Version 3 Message Specification", 468 Internet Draft, Work in Progress, draft-ietf-smime-msg-04.txt, May 469 1998. 471 10. Authors' Addresses 473 Larry Masinter 474 Xerox Palo Alto Research Center 475 3333 Coyote Hill Road 476 Palo Alto, CA 94304 USA 477 Fax: +1 415 812 4333 478 EMail: masinter@parc.xerox.com 480 Dan Wing 481 Cisco Systems, Inc. 482 101 Cooper Street 483 Santa Cruz, CA 95060 484 Phone: +1 408 457 5200 485 Fax: +1 408 457 5208 486 EMail: dwing@cisco.com 488 11. Copyright 490 Copyright (C) The Internet Society 1998. All Rights Reserved. 492 This document and translations of it may be copied and furnished to 493 others, and derivative works that comment on or otherwise explain it 494 or assist in its implementation may be prepared, copied, published 495 and distributed, in whole or in part, without restriction of any 496 kind, provided that the above copyright notice and this paragraph are 497 included on all such copies and derivative works. However, this 498 document itself may not be modified in any way, such as by removing 499 the copyright notice or references to the Internet Society or other 500 Internet organizations, except as needed for the purpose of 501 developing Internet standards in which case the procedures for 502 copyrights defined in the Internet Standards process must be 503 followed, or as required to translate it into languages other than 504 English. 506 The limited permissions granted above are perpetual and will not be 507 revoked by the Internet Society or its successors or assigns. 509 This document and the information contained herein is provided on an 510 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 511 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 512 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 513 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 514 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.