idnits 2.17.1 draft-ietf-fax-eifax-03.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 526 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 260, but not defined ** Obsolete undefined reference: RFC 2305 (Obsoleted by RFC 3965) == Missing Reference: 'PGPMIME' is mentioned on line 350, but not defined == Missing Reference: 'MIME-SECURE' is mentioned on line 349, but not defined == Missing Reference: 'IPSEC' is mentioned on line 359, but not defined == Unused Reference: 'MEDIA' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'FEATURES' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC1825' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'RFC1847' is defined on line 442, but no explicit reference was found in the text == Unused Reference: 'RFC2015' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'RFC2301' is defined on line 460, but no explicit reference was found in the text -- No information found for draft-myers-smtp-auth-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AUTH' -- No information found for draft-ietf-fax-report-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'REPORT-EXTENSIONS' -- No information found for draft-ietf-fax-mdn-features-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MDN-FEATURES' -- No information found for draft-ietf-conneg-media-features-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MEDIA' -- No information found for draft-ietf-conneg-feature-reg-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FEATURES' -- No information found for draft-ietf-fax-goals-XX - is the name correct? -- Possible downref: Normative reference to a draft: 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) -- No information found for draft-ietf-fax-smtp-session-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SESSION' -- No information found for draft-ietf-smime-msg-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SMIME' -- No information found for draft-gellens-submit-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SUBMIT' Summary: 16 errors (**), 0 flaws (~~), 14 warnings (==), 20 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 7, 1998 Dan Wing 4 Expires January 1999 Cisco Systems 5 draft-ietf-fax-eifax-03.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, 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 the 50 proposals are believed to be consistent with the goals of Internet 51 Fax as well as current standards-track directions for email 52 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 [SUBMIT] (MTA) using the RCPT command with the esmtp-keyword NOTIFY 147 and including esmtp-keyword SUCCESS. Other esmtp-keywords such as 148 DELAY and FAILURE may also be requested if the sender wishes to 149 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 messages 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 are only useful for determining if a 175 message was processed. In all cases MDNs are optionally 176 sent by the recipient. 178 NOTE: Receipt of an MDN MUST NOT be construed as any indication that 179 an MDN will be sent in response to another message requesting 180 an MDN. 182 The address provided by the EIFax sender on the 183 Disposition-Notification-To field MUST be able to receive Message 184 Disposition Notifications messages [RFC2298] and be able to receive 185 messages that are not in the Message Disposition Notification format 186 (due to the existence of legacy systems that utilize the same header 187 but do not generate RFC2298-compliant responses). 189 2.2.2. EIFax Recipient Requirements 191 All EIFax recipients SHOULD implement MDN [RFC2298], and SHOULD 192 implement Fax Extensions for DSN and MDN [REPORT-EXTENSIONS], 193 and MUST be configurable to silently ignore a request for an MDN 194 ([section 2.1 of RFC2298]). 196 2.2.2.1. Fax Offramp Requirements 198 A "Fax Offramp" is defined as a device that obtains a message and 199 connects to a fax machine, communicates using the fax protocol to 200 that fax machine, and transmits the message to that fax machine. 202 2.2.2.1.1. Fax Offramps Implemented as SMTP Servers 204 MUST implement Delivery Status Notifications [RFC1891 through 205 RFC1894], and SHOULD implement Fax Extensions for DSN and MDN 206 [REPORT-EXTENSIONS]. 208 If a successful DSN was requested and an MDN was requested, the MDN 209 SHOULD NOT be sent -- only the DSN needs to be sent. 211 The offramp MUST NOT use anything but the RFC821 envelope-to field to 212 make any decision about the actual telephone number to dial. 214 2.2.2.1.2. Fax Offramps Implemented as POP/IMAP Clients 216 MUST NOT generate a Delivery Status Notification message [RFC1894]. 218 The offramp MUST NOT use anything but the POP/IMAP username to map to 219 a single telephone number. For example, it MUST NOT use any RFC822 220 field or information within the message body or MIME parts to make 221 any decision about the telephone number to dial. 223 2.2.3. EIFax Messaging Infrastructure Requirements 225 This section explains the requirements of the SMTP messaging 226 infrastructure used by the EIFax sender and receiver. This 227 infrastructure is commonly provided by the ISP or a company's 228 internal mailers but can actually be provided by another organization 229 with appropriate service contracts. 231 2.2.3.1. Sender Infrastructure 233 Support for DSN [RFC1891] MUST be provided by the mail submission 234 server [SUBMIT] used by the EIFax sender, and SHOULD/MUST (?) be 235 provided up to the mailer responsible for communicating with external 236 (Internet) mailers. 238 2.2.3.2. Receiver Infrastructure 240 Support for DSN [RFC1891] SHOULD/MUST (?) be provided by the external 241 (Internet-accessible) mailer, and SHOULD/MUST (?) be provided by each 242 mailer between the external mailer and the EIFax recipient. 244 3. Additional document capabilities 246 Section 4 of [RFC2305] only allows sending the minimum subset 247 of TIFF for Facsimile "unless the sender has prior knowledge 248 of other TIFF fields or values supported by the recipient." 250 Various methods for the sender to aquire such knowledge have 251 been proposed: 253 1. Sender manual configuration 254 2. Message Disposition Notification Extension 255 3. Capabilities in Directory 257 3.1 Sender manual configuration 259 One way a sender can send a document which exceeds the minimum 260 subset allowed by [RFC 2305] is for the user controlling the sender 261 to manually override the default settings, at least for particular 262 recipients. 264 If there were well-known configurations with combined capabilities, 265 those capabilities could be described in the sender's user 266 interface. For example, a vendor or trade association could create 267 a profile of recipient capabilities that would describe an extended 268 set of TIFF features and image sizes, and then the sender could 269 manually be configured to send such files if the user controlling 270 the sender knows of the recipient capabilities. 272 For example, a trade association could create a profile named 273 "SuperInterFax", which would signify the ability to accept TIFF 274 profiles M, P, and F and any TIFF resolution and media size. 275 With this profile, a user could manually decide to send a 276 "SuperInterFax" to an address that was advertised to accept 277 this profile. 279 While awkward, this mechanism reflects the current state of 280 deployment of configuration for extended capabilities to ordinary 281 Internet email users. 283 3.2 Message Disposition Notification Extension 285 As outlined in section 2.2.1, an EIFax sender MAY request a Message 286 Disposition Notification. 288 If the recipient supports responding to such a message, and the 289 recipient authorizes responding to the MDN request, the recipient's 290 MDN MAY contain information describing the recipient's capabilities 291 as described in [MDN-FEATURES]. 293 EIFax senders MAY retain a local cache of information about the 294 features supported by recipients. When an EIFax device sends a 295 message to a specific recipient, it MAY use cached information to 296 determine the recipient's capabilities to handle extended document 297 features such as defined in [MDN-FEATURES]. 299 3.3 Capabilities in Directory 301 A future direction for enhanced document features is to create a 302 directory structure of recipient capabilities, deployed, for 303 example, through LDAP or DNS. The directory would provide a 304 mechanism by which a sender could determine a recipient's 305 capabilities before message construction or transmission, using a 306 directory lookup. Such mechanisms are not defined in this document. 308 4. Quick Delivery and Confirmation 310 [SESSION] describes a method by which delivery confirmation may be 311 delivered quickly if there is a direct connection between sender 312 and recipient. EIFax devices SHOULD implement 313 [SESSION]. Intermediate MTAs, e.g., as part of firewalls, MAY also 314 act as [SESSION] gateways, allowing for immediate delivery, with 315 fallback to store-and-forward. 317 EIFax devices MAY implement standard Internet mail routing using 318 the domain name system [RFC974]. EIFax devices MAY be SMTP 319 recipients registered as the primary mail exchanger for their 320 domain. This combination will allow the sending EIFax device to 321 communicate directly with the recipient device. 323 5. Security 325 Many uses of Internet Fax require greater security; the requirements 326 for security are discussed in [GOALS]. EIFax supports security by 327 providing for secured content and connections. 329 5.1 Content 331 To secure the contents of the message itself, EIFax devices SHOULD 332 implement S/MIME [SMIME] or PGP-MIME [PGPMIME] or both; these 333 systems are based on the security framework for MIME [MIME-SECURE]. 335 5.1.1 Authentication 337 EIFax devices SHOULD use the multipart/signed MIME type using 338 S/MIME or PGP-MIME signed messages. An EIFax SHOULD sign each 339 message with the identity of the originating user or with the 340 identity of the originating machine or service. An EIFax sender MAY 341 choose its method of signing a message. An EIFax recipient SHOULD 342 verify the signature of all received messages and indicate in any 343 particular way whether the message is unsigned, signed with an 344 unverifiable signature, signed with a signature that does not 345 verify, or signed with a verified signature. 347 5.1.2 Privacy 349 Using the methods of [MIME-SECURE], an EIFax device MAY use either 350 S/MIME [SMIME] or PGP-MIME [PGPMIME] to envelope the content of a 351 document. Enveloping MAY be applied either before or after signing. 353 Enveloped data should only be sent if the recipient's capability to 354 decode the enveloped data is known. 356 5.2 Connections 358 To secure the connection itself, including the envelope itself, EIFax 359 devices should implement [AUTH] or IPSsec [IPSEC]. 361 5.3 When to use security 363 The capability to perform secure transfer is discovered by a sender 364 either through a manual process or by discovering the public key of 365 the recipient. Senders may unilaterally send multipart/signed 366 documents using the signature method of their choice. 368 6. Security considerations 370 [RFC2305] describes the security environment of facsimile and the 371 considerations. This memo extends the requirements of RFC 2305 to 372 specifically recommend the use of both PGP and S/MIME. 374 Inaccurate capability information (section 3) could cause a denial 375 of service. The capability information could be inaccurate due to 376 many reasons, including compromised or improperly configured 377 directory server, improper manual configuration of sender, 378 compromised DNS, or spoofed MDN. If a sender is using cached 379 capability information, it SHOULD be manually confirmed by a user 380 before it is automatically used. 382 7. Implementation Notes 384 7.1 POP Clients and Message Disposition Notifications 386 If multiple POP clients are accessing the same mailbox the POP 387 clients MUST be configurable to leave mail on server (LMOS). This is 388 because the MDN specification permits only one response [section 2.1, 389 RFC2298], and because POP doesn't include a mechanism to indicate if 390 an MDN has already been generated by a POP client. 392 8. Acknowledgements 394 The authors would like to acknowledge the members of the IETF-FAX 395 working group, and especially the following contributors who provided 396 assistance in creating to this document. In alphabetical order: 398 Vivian Cancio, Xerox 399 Richard Coles, Lockheed Martin 400 David Crocker, Brandenburg Consulting 401 Ned Freed, Innosoft 402 Graham Klyne, Integralis Ltd. 403 Geoff Marshall, ___ 404 Keith Moore, University of Tennessee 405 George Pajari, Faximum Software Inc. 406 James Rafferty, Human Communications 407 Richard Shockey, Shockey Consulting LLC 408 Brian Stafford, Office Logic 409 Maeda Toru, Canon 411 ((Is this complete? Please email dwing@cisco.com if your 412 name was omitted, or your company name is incorrect)) 414 9. References 416 [AUTH] J. Myers, "SMTP Service Extension for Authentication", 417 Internet Draft, Work in Progress, draft-myers-smtp-auth-XX.txt, 418 February 1998. 420 [REPORT-EXTENSIONS] D. Wing, "Fax Extensions to DSN and MDN", 421 Internet Draft, Work in Progress, 422 draft-ietf-fax-report-extensions.txt. 424 [MDN-FEATURES] L. Masinter and D. Wing, "Using Message Disposition 425 Notifications to Indicate Supported Features", Internet Draft, Work 426 in Progress, draft-ietf-fax-mdn-features-XX.txt. 428 [MEDIA] "Media Features for Display, Print, and Fax", L. Masinter, K. 429 Holtman, A. Mutz, D. Wing, Internet Draft, Work in Progress, 430 draft-ietf-conneg-media-features-XX.txt. 432 [FEATURES] K. Holtman, A. Mutz, T. Hardie, "Feature Tag Registration 433 Procedures", Internet Draft, Work in Progress, 434 draft-ietf-conneg-feature-reg-XX.txt. 436 [GOALS] L. Masinter, "Terminology and Goals for Internet Fax", 437 Internet Draft, Work in Progress, draft-ietf-fax-goals-XX.txt. 439 [RFC1825] R. Atkinson, "Security Architecture for the Internet 440 Protocol", RFC 1825, Naval Research Laboratory, August 1995. 442 [RFC1847] "Security Multiparts for MIME: Multipart/Signed and 443 Multipart/Encrypted", RFC 1847, October 1995. 445 [RFC1891] K. Moore, "SMTP Service Extensions for Delivery Status 446 Notifications", RFC 1891, January 1996. 448 [RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for 449 Delivery Status Notifications", RFC 1894, January 1996 451 [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", 452 RFC2015, October 1996. 454 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 455 Requirement Levels", RFC 2119, March 1997. 457 [RFC2298] R. Fajman, "An Extensible Message Format for Message 458 Disposition Notifications", RFC 2298, March 1998. 460 [RFC2301] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, 461 J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998. 463 [RFC2305] K.Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of 464 Facsimile Using Internet Mail", RFC 2305, March 1998. 466 [RFC974] C. Partridge. "Mail routing and the domain system", RFC 974, 467 January 1986. 469 [SESSION] N. Joffe, D. Wing, L. Masinter, "SMTP Service Extension for 470 Immediate Delivery", Internet Draft, Work in Progress, 471 draft-ietf-fax-smtp-session-XX.txt. 473 [SMIME] B. Ramsdell. "S/MIME Version 3 Message Specification", 474 Internet Draft, Work in Progress, draft-ietf-smime-msg-XX.txt. 476 [SUBMIT] R. Gellens, J. Klensin, "Message Submission", Internet 477 Draft, Work in Progress, draft-gellens-submit-XX.txt. 479 10. Authors' Addresses 481 Larry Masinter 482 Xerox Palo Alto Research Center 483 3333 Coyote Hill Road 484 Palo Alto, CA 94304 USA 485 Fax: +1 415 812 4333 486 EMail: masinter@parc.xerox.com 488 Dan Wing 489 Cisco Systems, Inc. 490 101 Cooper Street 491 Santa Cruz, CA 95060 492 Phone: +1 408 457 5200 493 Fax: +1 408 457 5208 494 EMail: dwing@cisco.com 496 11. Copyright 498 Copyright (C) The Internet Society 1998. All Rights Reserved. 500 This document and translations of it may be copied and furnished to 501 others, and derivative works that comment on or otherwise explain it 502 or assist in its implementation may be prepared, copied, published 503 and distributed, in whole or in part, without restriction of any 504 kind, provided that the above copyright notice and this paragraph are 505 included on all such copies and derivative works. However, this 506 document itself may not be modified in any way, such as by removing 507 the copyright notice or references to the Internet Society or other 508 Internet organizations, except as needed for the purpose of 509 developing Internet standards in which case the procedures for 510 copyrights defined in the Internet Standards process must be 511 followed, or as required to translate it into languages other than 512 English. 514 The limited permissions granted above are perpetual and will not be 515 revoked by the Internet Society or its successors or assigns. 517 This document and the information contained herein is provided on an 518 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 519 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 520 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 521 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 522 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.