idnits 2.17.1 draft-ietf-fax-service-v2-05.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an 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.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references (14], 3], [5,12,, [4,10,, 11], [1,2,), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 88 has weird spacing: '...e using an In...' == Line 89 has weird spacing: '... device using...' == Line 544 has weird spacing: '... in a fil...' == Line 546 has weird spacing: '...int/fax the r...' == Line 547 has weird spacing: '... rather than ...' -- 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) ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2301 (ref. '5') (Obsoleted by RFC 3949) ** Obsolete normative reference: RFC 1894 (ref. '9') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 2302 (ref. '12') (Obsoleted by RFC 3302) -- Obsolete informational reference (is this intentional?): RFC 2440 (ref. '16') (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '17') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2487 (ref. '18') (Obsoleted by RFC 3207) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Toyoda 3 Internet Draft H. Ohno 4 October 23, 2001 J. Murai 5 Expires April 2002 WIDE Project 6 Obsoletes: RFC2305 D. Wing 7 draft-ietf-fax-service-v2-05.txt Cisco 9 A Simple Mode of Facsimile Using Internet Mail 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), 16 its areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This draft is a product of the IETF Internet Fax working group. To 31 subscribe to the mailing list, send a message to 32 ietf-fax-request@imc.org with the line "subscribe" in the body of the 33 message. Archives are available from . 35 Copyright Notice 37 Copyright (C) The Internet Society (1999,2000). All Rights Reserved. 39 ABSTRACT 41 This specification provides for "simple mode" carriage of facsimile 42 data using Internet mail. Extensions to this document will follow. 43 The current specification employs standard protocols and file formats 44 such as TCP/IP, Internet mail protocols [1, 2, 3], MIME [4, 10, 11], 45 and TIFF for Facsimile [5, 12, 14]. It can send images not only to 46 other Internet-aware facsimile devices but also to Internet-native 47 systems, such as PCs with common email readers which can handle MIME 48 mail and TIFF for Facsimile data. The specification facilitates 49 communication among existing facsimile devices, Internet mail agents, 50 and the gateways which connect them. 52 This document is a revision of RFC 2305. There have been no technical 53 changes. 55 1 INTRODUCTION 57 This specification defines message-based facsimile communication 58 over the Internet. It describes a minimum set of capabilities, 59 taking into account those of typical facsimile devices and PCs that 60 can generate facsimile data. 62 A G3Fax device has substantial restrictions due to specifications in 63 the standards, such as for timers. This specification defines a 64 profile for Internet mail, rather than creating a distinct "facsimile 65 over the Internet" service. The semantics resulting from the profile 66 are designed to be compatible with facsimile operation over the 67 general switched telephone network, so that gateways between 68 facsimile and Internet mail can operate with very high fidelity. 70 The reason for developing this capability as an email profile is to 71 permit interworking amongst facsimile and email users. For example 72 it is intended that existing email users be able to send normal 73 messages to lists of users, including facsimile-based recipients, and 74 that other email recipients shall be able to reply to the original 75 and continue to include facsimile recipients. Similarly it is 76 intended that existing email software work without modification and 77 not be required to process new, or different data structures, beyond 78 what is normal for Internet mail users. Existing email service 79 standards are used, rather than replicating mechanisms which are more 80 tailored to existing facsimile standards, to ensure this 81 compatibility with existing email service. 83 1.1 Services 84 A facsimile-capable device that uses T.4 [15] and the general switched 85 telephone network (GSTN) is called a "G3Fax device" in this 86 specification. An "IFax device" is an Internet- accessible device 87 capable of sending, receiving or forwarding Internet faxes. A 88 message can be sent to an IFax device using an Internet mail 89 address. A message can be sent to a G3Fax device using an Internet 90 mail address; the message MAY be forwarded via an IFax offramp 91 gateway. 93 1.2 Cases 94 This specification provides for communication between each of the 95 following combinations: 97 Internet mail => Network printer 98 Internet mail => Offramp gateway (forward to 99 G3Fax) 100 Network scanner => Network printer 101 Network scanner => Offramp gateway (forward to 102 G3Fax) 103 Network scanner => Internet mail 105 1.3 Intellectual Property 106 The IETF has been notified of intellectual property rights claimed in 107 regard to some or all of the specification contained in this 108 document. For more information consult the online list of claimed 109 rights in . 111 1.4 Key Words 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [13]. 116 2 COMMUNICATION PROTOCOLS 118 The set of conventions necessary to achieve facsimile- compatible 119 service covers basic data transport, document data formats, message 120 (document) addressing, delivery confirmation, and message security. 121 In this section, the first 4 are covered. The remainder are covered 122 in following sections, along with additional details for addressing 123 and formats. 125 2.1 Transport 127 This section describes mechanisms involved in the transport between 128 IFAX devices. 130 2.1.1 Relay 132 Data transfer MAY be achieved using standard Internet mail transfer 133 mechanisms[1, 3]. The format of addresses MUST conform to the RFC 134 821 and RFC 822 Internet mail standards [1, 2, 135 3]. 137 2.1.2 Gateway 139 A gateway translates between dissimilar environments. For IFax, a 140 gateway connects between Internet mail and the T.4/GSTN facsimile. 141 Gateways can service multiple T.4/GSTN facsimile users or can service 142 only one. In the former case, they serve as a classic "mail transfer 143 agent" (MTA) and in the latter as a classic "mail user agent" (UA). 145 An onramp is a gateway which connects from T.4/GSTN facsimile to 146 Internet mail. An offramp is a gateway which connects from Internet 147 mail to T.4/GSTN facsimile. Behavior of onramps is out of scope for 148 this specification. 150 This specification describes the Internet mail service portion of 151 offramp addressing, confirmation and failure notification. Details 152 are provided in later sections. 154 2.1.3 Mailbox protocols 156 An offramp gateway that operate as an MTA serving multiple users 157 SHOULD use SMTP; a gateway that operates as a UA serving a single 158 mail recipient MAY use a mailbox access protocol such as POP [6] or 159 similar mailbox access protocols. 161 NOTE: An offramp gateway that relays mail based on addressing 162 information needs to ensure that it uses addresses supplied in the 163 MTA envelope, rather than from elsewhere, such as addresses listed in 164 the message content headers. 166 2.2 Formats 168 2.2.1 Headers 170 IFax devices MUST be compliant with RFC 822 and RFC1123, which define 171 the format of mail headers. The header of an IFax message SHOULD 172 include Message-ID and MUST include all fields required by [2, 3], 173 such as DATE and FROM. 175 2.2.2 MIME 177 IFax devices MUST be compliant with MIME [4], except as noted in 178 Appendix A. 180 2.2.3 Content 182 The data format of the facsimile image is based on the minimum set of 183 TIFF for Facsimile [5], also known as the S profile. Such facsimile 184 data are included in a MIME object by use of the image/TIFF sub-type 185 [12]. Additional rules for the use of TIFF for Facsimile, for the 186 message-based Internet facsimile application, are defined later. 188 2.2.4 Multipart 190 A single multi-page document SHOULD be sent as a single multi- page 191 TIFF file, even though recipients MUST process multipart/mixed 192 containing multiple TIFF files. If multipart content is present and 193 processing of any part fails, then processing for the entire message 194 is treated as failing, per [Processing failure] below. 196 2.3 Error Handling 198 2.3.1 Delivery failure 200 This section describes existing requirements for Internet mail, 201 rather than indicating special requirements for IFax devices. 203 In the event of relay failure, the sending relay MUST generate a 204 failure message, which SHOULD be in the format of a DSN. [9] 206 NOTE: Internet mail transported via SMTP MUST contain a MAIL 207 FROM address appropriate for delivery of return notices [Also 208 see section 5.2.6] 210 2.3.2 Processing failure 212 IFax devices with limited capabilities might be unable to process the 213 content of a message. If this occurs it is important to ensure that 214 the message is not lost without any notice. Notice MAY be provided in 215 any appropriate fashion, and the exact handling is a local matter. 216 (Also see Appendix A, second bullet.) 218 3 ADDRESSING 220 3.1 Classic Email Destinations 222 Messages being sent to normal Internet mail recipients will use 223 standard Internet mail addresses, without additional constraints. 225 3.2 G3Fax Devices 227 G3Fax devices are accessed via an IFAX offramp gateway, which 228 performs any authorized telephone dial-up. 230 3.3 Address Formats Used by Offramps 232 When a G3Fax device is identified by a telephone number, the entire 233 address used for the G3fax device, including the number and offramp 234 host reference MUST be contained within standard Internet mail 235 transport fields, such as RCPT TO and MAIL FROM [1, 3]. The address 236 MAY be contained within message content fields, such as 237 and [2, 3], as appropriate. 239 As for all Internet mail addresses, the left-hand-side (local- part) 240 of an address is not to be interpreted except by the MTA that is 241 named on the right-hand-side (domain). 243 The telephone number format SHOULD conform to [7, 8]. Other 244 formats MUST be syntactically distinct from [7, 8]. 246 4 IMAGE FILE FORMAT 248 Sending IFax devices MUST be able to write minimum set TIFF files, 249 per the rules for creating minimum set TIFF files defined in TIFF for 250 Facsimile (the S profile) [5], which is also compatible with the 251 specification for the minimum subset of TIFF-F in [14]. Receiving 252 IFax devices MUST be able to read minimum set TIFF files. 254 A sender SHOULD NOT use TIFF fields and values beyond the minimum 255 subset of TIFF for Facsimile unless the sender has prior knowledge of 256 other TIFF fields or values supported by the recipient. The 257 mechanism for determining capabilities of recipients is beyond the 258 scope of this document. 260 5 SECURITY CONSIDERATIONS 262 5.1 General Directive 264 This specification is based on use of existing Internet mail. To 265 maintain interoperability with Internet mail, any security to be 266 provided should be part of the of the Internet security 267 infrastructure, rather than a new mechanism or some other mechanism 268 outside of the Internet infrastructure. 270 5.2 Threats and Problems 272 Both Internet mail and G3Fax standards and operational services have 273 their own set of threats and countermeasures. This section attends 274 only to the set of additional threats which ensue from integrating 275 the two services. This section reviews relevant concerns about 276 Internet mail for IFax environments, as well as considering the 277 potential problems which can result of integrating the existing G3Fax 278 service with Internet mail. 280 5.2.1 Spoofed sender 282 The actual sender of the message might not be the same as that 283 specified in the Sender or From fields of the message content headers 284 or the MAIL FROM address from the SMTP envelope. 286 In a tightly constrained environment, sufficient physical and 287 software controls may be able to ensure prevention of this problem. 288 The usual solution is through encryption-based authentication, either 289 for the channel or associated with the object, as discussed below. 291 It should be recognized that SMTP implementations do not provide 292 inherent authentication of the senders of messages, nor are sites 293 under obligation to provide such authentication. End-to-end 294 approaches such as S/MIME and PGP/MIME are currently being developed 295 within the IETF. These technologies can provide such authentication. 297 5.2.2 Resources consumed by dialout 299 In addition to the resources normally consumed for email (CPU cycles 300 and disk), offramp facsimile causes an outdial which often imposes 301 significant resource consumption, such as financial cost. Techniques 303 for establishing authorization of the sender are essential to those 304 offramp facsimile services that need to manage such consumption. 306 Due to the consumption of these resources by dialout, unsolicited 307 bulk email which causes an outdial is undesirable. 309 Offramp gateways SHOULD provide the ability to authorize senders in 310 some manner to prevent unauthorized use of the offramp. There are no 311 standard techniques for authorization using Internet protocols. 313 Typical solutions use simple authentication of the originator to 314 establish and verify their identity and then check the identity 315 against a private authorization table. 317 Originator authentication entails the use of weak or strong 318 mechanisms, such as cleartext keywords or encryption-based data- 319 signing, respectively, to determine and validate the identify of the 320 sender and assess permissions accordingly. 322 Other control mechanisms which are common include source filtering 323 and originator authentication. Source filtering entails offramp 324 gateway verification of the host or network originating the message 325 and permitting or prohibiting relaying accordingly. 327 5.2.3 GSTN authorization information 329 Confidential information about the sender necessary to dial a G3Fax 330 recipient, such as sender's calling card authorization number, might 331 be disclosed to the G3Fax recipient (on the cover page), such as 332 through parameters encoded in the G3Fax recipients address in the To: 333 or CC: fields. 335 Senders SHOULD be provided with a method of preventing such 336 disclosure. As with mechanisms for handling unsolicited faxes, there 337 are not yet standard mechanisms for protecting such information. 338 Out-of-band communication of authorization information or use of 339 encrypted data in special fields are the available non-standard 340 techniques. 342 Typically authorization needs to be associated to specific senders 343 and specific messages, in order to prevent a "replay" attack which 344 causes and earlier authorization to enable a later dial-out by a 345 different (and unauthorized) sender. A non-malicious example of such 346 a replay would be to have an email recipient reply to all original 347 recipients -- including an offramp IFax recipient -- and have the 348 original sender's authorization cause the reply to be sent. 350 5.2.4 Sender accountability 352 In many countries, there is a legal requirement that the "sender" be 353 disclosed on a facsimile message. Email From addresses are trivial 354 to fake, so that using only the MAIL FROM [1, 3] or From [2, 3] 355 header is not sufficient. 357 Offramps SHOULD ensure that the recipient is provided contact 358 information about the offramp, in the event of problems. 360 The G3Fax recipient SHOULD be provided with sufficient information 361 which permits tracing the originator of the IFax message. Such 362 information might include the contents of the MAIL FROM, From, Sender 363 and Reply-To headers, as well as Message-Id and Received headers. 365 5.2.5 Message disclosure 367 Users of G3Fax devices have an expectation of a level of message 368 privacy which is higher than the level provided by Internet mail 369 without security enhancements. 371 This expectation of privacy by G3Fax users SHOULD be preserved as 372 much as possible. 374 Sufficient physical and software control may be acceptable in 375 constrained environments. The usual mechanism for ensuring data 376 confidentially entail encryption, as discussed below. 378 5.2.6 Non private mailboxes 380 With email, bounces (delivery failures) are typically returned to the 381 sender and not to a publicly-accessible email account or printer. 382 With facsimile, bounces do not typically occur. However, with IFax, 383 a bounce could be sent elsewhere (see section [Delivery Failure]), 384 such as a local system administrator's account, publicly-accessible 385 account, or an IFax printer (see also [Traffic Analysis]). 387 5.2.7 Traffic analysis 389 Eavesdropping of senders and recipients is easier on the Internet 390 than GSTN. Note that message object encryption does not prevent 391 traffic analysis, but channel security can help to frustrate attempts 392 at traffic analysis. 394 5.3 Security Techniques 396 There are two basic approaches to encryption-based security which 397 support authentication and privacy: 399 5.3.1 Channel security 401 As with all email, an IFax message can be viewed as it traverses 402 internal networks or the Internet itself. 404 Virtual Private Networks (VPN), encrypted tunnels, or transport 405 layer security can be used to prevent eavesdropping of a message 406 as it traverses such networks. It also provides some protection 407 against traffic analysis, as described above. 409 At the current time various protocols exist for performing the above 410 functions, and are only mentioned here for information. Such protocols 411 are IPSec [17] and TLS [18]. 413 5.3.2 Object security 415 As with all email, an IFax message can be viewed while it resides on, 416 or while it is relayed through, an intermediate Mail Transfer Agent. 418 Message encryption can be used to provide end-to-end encryption. 420 At the current time two protocols are commonly used for message 421 encryption and are only mentioned here for information. The two 422 protocols are PGP-MIME [16] and S/MIME [19]. 424 6 REFERENCES 426 6.1 Normative references 428 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 429 821, August 1982. 431 [2] Crocker, D., "Standard for the Format of ARPA Internet 432 Text Messages", STD 11, RFC 822, August l982. 434 [3] Braden, R., 1123 "Requirements for Internet hosts - 435 application and support", RFC 1123, October 1989. 437 [4] Borenstein, N., and N. Freed, " Multipurpose Internet 438 Mail Extensions (MIME) Part Five: Conformance Criteria and 439 Examples ", RFC 2049, November 1996. 441 [5] McIntyre, L., Zilles, S., Buckley, R., Venable, D., 442 Parsons, G., and J. Rafferty, "File Format for Internet Fax", 443 RFC 2301, March 1998. 445 [6] Myers, J., and M. Rose, "Post Office Protocol - Version 446 3", STD 53, RFC 1939, May 1996. 448 [7] Allocchio, C., "Minimal PSTN address format for Internet 449 mail", draft-ietf-fax-faxaddr-v2-04.txt, June 2001. 451 [8] Allocchio, C., "Minimal fax address format for Internet 452 mail", draft-ietf-fax-minaddr-v2-04.txt, June 2001. 454 [9] Moore, K., and G. Vaudreuil, "An Extensible Message 455 Format for Delivery Status Notifications", RFC 1894, January 456 1996. 458 [10] Freed, N., and N. Borenstein, "Multipurpose Internet 459 Mail Extensions (MIME) Part Two: Media Types", RFC 2046, 460 November 1996. 462 [11] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 463 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 464 November 1996. 466 [12] Parsons, G. and Rafferty, J., "Tag Image File Format 467 (TIFF) -- image/TIFF: MIME Sub-type Registration", RFC 2302, 468 March 1998. 470 [13] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", RFC 2119, March 1997. 473 6.2 Non-normative references 475 [14] Parsons, G., and J. Rafferty, "Tag Image File Format 476 (TIFF) -- F Profile for Facsimile", RFC 2306, March 1998. 478 [15] ITU-T (CCITT), "Standardization of Group 3 facsimile 479 apparatus for document transmission", ITU-T (CCITT), 480 Recommendation T.4. 482 [16] Callas, J., Donnerhacke, L., Finney, H., and Thayer, R., 483 "OpenPGP Message Format", RFC 2440, November 1998 485 [17] Kent, S. and Atkinson, R., "Security Architecture for the 486 Internet Protocol", RFC 2401, November 1998. 488 [18] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", 489 RFC 2487, January 1999. 491 [19] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and 492 L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, 493 March 1998. 495 7 ACKNOWLEDGEMENTS 497 This specification was produced by the Internet Engineering Task 498 Force Fax Working Group, over the course of more than one year's 499 online and face-to-face discussions. As with all IETF efforts, many 500 people contributed to the final product. 502 Active for this document were: Steve Huston, Jeffrey Perry, Greg 503 Vaudreuil, Richard Shockey, Charles Wu, Graham Klyne, Robert A. 504 Rosenberg, Larry Masinter, Dave Crocker, Herman Silbiger, James 505 Rafferty. 507 8 AUTHORS' ADDRESSES 509 Kiyoshi Toyoda 510 Matsushita Graphic Communication Systems, Inc. 511 2-3-8 Shimomeguro, Meguro-ku 512 Tokyo 153 Japan 513 Fax: +81 3 5434 7166 514 Email: ktoyoda@rdmg.mgcs.mei.co.jp 516 Hiroyuki Ohno 517 Communications Research Laboratory. 518 4-2-1, Nukui-Kitamachi, Koganei, Tokyo, 519 184-8795, Japan 520 FAX: +81 42 327 7941 521 Email: hohno@ohnolab.org 523 Jun Murai 524 Keio University 525 5322 Endo, Fujisawa 526 Kanagawa 252 Japan 527 Fax: +81 466 49 1101 528 Email: jun@wide.ad.jp 530 Dan Wing 531 170 W. Tasman Drive 532 San Jose, CA 95134 533 Phone: +1 408 525 5314 534 Email: dwing@cisco.com 536 9 APPENDIX A: Exceptions to MIME 538 * IFax senders are not required to be able to send 539 text/plain messages (RFC 2049 requirement 4), although IFax 540 recipients are required to accept such messages, and to process 541 them. 543 * IFax recipients are not required to offer to put results 544 in a file. (Also see 2.3.2.) 546 * IFax recipients MAY directly print/fax the received 547 message rather than "display" it, as indicated in RFC 2049. 549 10 APPENDIX B: List of edits to RFC2305 551 +----+----------+-------------------------------------------------+ 552 | No.| Section | Edit July 27, 2001 | 553 +----+----------+-------------------------------------------------+ 554 | 1. |Copyright | Updated copyrihght from "1998" to "1999,2000" | 555 | |Notice | | 556 +----+----------+-------------------------------------------------+ 557 | 2. |SUMMARY | Changed the phrase "over the Internet" to | 558 | | | "using Internet mail" | 559 +----+----------+-------------------------------------------------+ 560 | 3. |5 | Changed the paragraphs regarding to the | 561 | | | following references to make them very | 562 | | | non-normative. | 563 | | | "OpenPGP Message Format", RFC2440 | 564 | | | "Securiy Architecture for the IP", RFC2401 | 565 | | | "SMTP Service Extensions for Secure SMTP over | 566 | | | TLS", RFC2487 | 567 | | | "S/MIME Version 2 Message Specification", | 568 | | | RFC2311 | 569 +----+----------+-------------------------------------------------+ 570 | 4. |REFERENCES| Removed the following references because they | 571 | | | are non-normative | 572 | | | "SMTP Service Extensions for Delivery Status | 573 | | | Notifications", RFC1891 | 574 | | | "Internet Message Access Protocol", RFC2060 | 575 +----+----------+-------------------------------------------------+ 576 | 5. |REFERENCES| Separated REFERENCES to the normative and | 577 | | | non-normative | 578 +----+----------+-------------------------------------------------+ 579 | 6. |Appendix | Changed the phrase from "NOT REQUIRED" to | 580 | | A | "not required" | 581 +----+----------+-------------------------------------------------+ 582 | 7. |Appendix | Added "Appendix B List of edits to RFC2305" | 583 +----+----------+-------------------------------------------------+ 585 10 Full Copyright Statement 587 Copyright (C) The Internet Society (1999). All Rights Reserved. 589 This document and translations of it may be copied and furnished to 590 others, and derivative works that comment on or otherwise explain it 591 or assist in its implementation may be prepared, copied, published 592 and distributed, in whole or in part, without restriction of any 593 kind, provided that the above copyright notice and this paragraph are 594 included on all such copies and derivative works. However, this 595 document itself may not be modified in any way, such as by removing 596 the copyright notice or references to the Internet Society or other 597 Internet organizations, except as needed for the purpose of 598 developing Internet standards in which case the procedures for 599 copyrights defined in the Internet Standards process must be 600 followed, or as required to translate it into languages other than 601 English. 603 The limited permissions granted above are perpetual and will not be 604 revoked by the Internet Society or its successors or assigns. 606 This document and the information contained herein is provided on an 607 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 608 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 609 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 610 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 611 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.