idnits 2.17.1 draft-ietf-fax-eifax-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: ---------------------------------------------------------------------------- ** 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 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: 'POP3' is mentioned on line 175, but not defined == Missing Reference: 'IMAP4' is mentioned on line 175, but not defined == Missing Reference: 'REPORTING-EXTENSIONS' is mentioned on line 262, but not defined == Missing Reference: 'RFC1892' is mentioned on line 291, but not defined ** Obsolete undefined reference: RFC 1892 (Obsoleted by RFC 3462) -- No information found for draft-ietf-fax-feature-schema-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FAX-SCHEMA' -- No information found for draft-ietf-fax-goals-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GOALS' -- No information found for draft-ietf-fax-reporting-extensions-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'REPORT-EXTENSIONS' ** Obsolete normative reference: RFC 1891 (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1893 (Obsoleted by RFC 3463) ** Obsolete normative reference: RFC 1894 (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 2298 (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 2305 (Obsoleted by RFC 3965) ** Obsolete normative reference: RFC 974 (Obsoleted by RFC 2821) -- No information found for draft-gellens-submit-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SUBMIT' Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Fax Working Group Larry Masinter 2 Internet Draft Xerox Corporation 3 September 30, 1998 Dan Wing 4 Expires March 1999 Cisco Systems 5 draft-ietf-fax-eifax-05.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 a product of the IETF Internet 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 Using 40 Internet Mail' [RFC2305] and provides additional features, including 41 transmission of enhanced document characteristics (higher resolution, 42 color) and confirmation of delivery and processing. 44 These additional features are designed to provide the highest level 45 of interoperability with the existing and future standards-compliant 46 email infrastructure and mail user agents, while providing a level of 47 service that approximates the level currently enjoyed by fax users. 49 1. Introduction 51 This document notes a number of enhancements to the "Simple Mode of 52 Facsimile Using Internet Mail" [RFC2305] that may be combined to 53 create an extended mode of facsimile using Internet mail. 55 The new features are designed to be interoperable with the existing 56 base of mail transfer agents (MTAs) and mail user agents (MUAs), 57 and take advantage of existing standards for advanced functionality 58 such as positive delivery confirmation and disposition notification. 59 The enhancements described in this document utilize the messaging 60 infrastructure, where possible, instead of creating fax-specific 61 features which are unlikely to be implemented in non-fax messaging 62 software. 64 This document standardizes two features described in its companion 65 document, [GOALS]: 67 * Delivery confirmation (Section 2) (required) 68 * Additional document features (Section 3) (optional) 70 1.1. Definition of terms 72 The term "processing" indicates the ability to successfully render or 73 successfully transmit the contents of the message to a printer, on a 74 display device, or to a fax machine. 76 The term "recipient" indicates the device which processes the content 77 of the mail message and renders it to the user by transmitting it to 78 a remote fax machine, printer, displaying it on a terminal. For 79 example, a recipient could be implemented as a traditional Mail User 80 Agent on a PC, a standalone device which retreives mail using POP3 or 81 IMAP, an SMTP server which prints incoming messages (similar to an 82 LPR server). 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 1.2. GSTN Fax Gateways ("onramp"/"offramp") 90 The behavior of gateways from GSTN fax to SMTP ("onramps") and from 91 SMTP to GSTN fax ("offramps") are not described in this document. 92 However, such gateways SHOULD have the behavior characteristics of 93 senders and recipients as described in this document. 95 2. Delivery and Processing Confirmation 96 In traditional GSTN-based realtime facsimile, the receiving terminal 97 acknowledges successful receipt and processing of every page [T.30]. 99 In Internet Mail, the operations of Delivery (to the mailbox) and 100 Disposition (to paper or a screen) may be separated in time (due to 101 store and forwarding of messages) and location (due to separation of 102 delivery agent (MTA) and user agent (MUA)). The confirmation of 103 these two operations are supplied by two different standards-track 104 documents: Delivery Status Notifications (DSN) [RFC1891, RFC1894] 105 and Message Disposition Notifications (MDN) [RFC2298], respectively. 107 This section defines requirements for devices or services that are to 108 be considered compliant with the delivery and processing confirmation 109 section of this memo. 111 2.1. Sender Requirements 113 A delivery failure message (in a non-standard format or in the format 114 described by [RFC1894]) may be sent to the envelope-from address 115 specified by the sender. Thus, the envelope-from address supplied 116 by the sender MUST be able to properly handle such delivery failure 117 messages. 119 2.1.1. Delivery Confirmation 121 If the sender desires delivery confirmation, the sender MUST request 122 Delivery Status Notification by including the the esmtp-keyword 123 NOTIFY with the esmtp-value SUCCESS [section 5.1 of RFC1891]. 125 2.1.2. Processing Confirmation 127 If the sender desires processing confirmation, the sender MUST 128 request Message Disposition Notification using the method described 129 in section 2 of [RFC2298]. 131 Because a recipient can always silently ignore a request 132 for an MDN [section 2.1 of RFC2298]: 133 * MDNs MUST NOT be used for delivery confirmation, but are only 134 useful for disposition ("processing") notification. 135 * the sender MUST NOT assume the recipient will respond to an MDN 136 request in a subsequent message, even if the recipient has 137 always responded to MDNs in the past. 139 The address provided by the sender on the Disposition-Notification-To 140 field MUST be able to receive Message Disposition Notifications 141 messages [RFC2298] and be able to receive messages that are not in 142 the Message Disposition Notification format (due to the existence of 143 legacy systems that generate non-RFC2298-compliant responses to the 144 Disposition-Notification-To field). 146 2.2. Recipient Requirements 148 Recipients in compliance with this document SHOULD implement MDN 149 [RFC2298], and SHOULD implement Offramp Gateway Extensions for DSN 150 and MDN [REPORT-EXTENSIONS]. 152 If the recipient is an SMTP server, it behaves as part of the 153 receiver infrastructure and is therefore subject to the "Receiver 154 Infrastructure" requirements of this document. 156 See also "Recipient Recommendations" in section 5. 158 2.2.1. MDN Recipient Requirements 160 Recipients MUST be configurable to silently ignore a request for an 161 MDN ([section 2.1 of RFC2298]). 163 If the recipient is an automated message processing system which is 164 not associated with a person, the device MAY be configurable to 165 always respond to MDN requests, but in all cases MUST be configurable 166 to never generate MDNs. 168 A recipient MUST NOT generate an unsolicited MDN to indicate 169 successful processing, but a recipient MAY generate an unsolicited 170 MDN (sent to the envelope-from (Return-Path:) address) to indicate 171 processing failure following the rules in the above paragraph. 173 2.2.2. Recipients using Mailbox Access Protocols 175 A recipient using [POP3] or [IMAP4] to retrieve its mail is not 176 allowed to generate a Delivery Status Notification message [RFC1894]. 178 The recipient MUST NOT use anything but the POP/IMAP username to map 179 to a single destination. For example, using any RFC822 field or 180 information within the message body or MIME parts to make a decision 181 about the destination is not permitted. 183 2.3. Messaging Infrastructure Requirements 185 This section explains the requirements of the SMTP messaging 186 infrastructure used by the sender and receiver. This infrastructure 187 is commonly provided by the ISP or a company's internal mailers but 188 can actually be provided by another organization with appropriate 189 service contracts. 191 2.3.1. Sender Infrastructure 192 For the sender's infrastructure to provide conformance with 193 this document, support for DSN [RFC1891] MUST be provided by the mail 194 submission server [SUBMIT] used by the sender and MUST be provided 195 up to the mailer responsible for communicating with external 196 (Internet) mailers. 198 Also see section 5.1 of this document. 200 2.3.2. Receiver Infrastructure 202 Support for DSN [RFC1891] MUST be provided by the external 203 (Internet-accessible) mailer, and MUST be provided by each mailer 204 between the external mailer and the recipient. If the recipient is 205 implemented as an SMTP server it MUST also support DSN [RFC1891]. 207 3. Additional document capabilities 209 Section 4 of [RFC2305] only allows sending the minimum subset 210 of TIFF for Facsimile "unless the sender has prior knowledge 211 of other TIFF fields or values supported by the recipient." 213 A recipient SHOULD indicate which features and values from among 214 those available in [FAX-SCHEMA] are supported using one of the 215 mechanisms defined below. 217 Three methods for the sender to acquire such knowledge are 218 permitted: 220 1. Sender manual configuration 221 2. Capabilities in Directory 222 3. Capabilities returned in MDN or DSN 224 In any implementation it possible for a locally-stored 225 cache of capabilities to lose synchronization with the 226 recipient's actual capabilities. A mechanism should be 227 provided to allow the sender to override the locally-stored 228 cache of capabilities. Also note section 4.1 of this 229 document. 231 3.1. Sender manual configuration 233 One way a sender can send a document which exceeds the minimum 234 subset allowed by [RFC2305] is for the user controlling the sender 235 to manually override the default settings, usually on a 236 per-recipient basis. For example, during transmission a 237 user could indicate the recipient is capable of receiving 238 high resolution images or color images. 240 While awkward and not automatic, this mechanism reflects the current 241 state of deployment of configuration for extended capabilities to 242 ordinary Internet email users. 244 3.2. Capabilities in Directory 246 A future direction for enhanced document features is to create a 247 directory structure of recipient capabilities, deployed, for example, 248 through LDAP or DNS. The directory would provide a mechanism by which 249 a sender could determine a recipient's capabilities before message 250 construction or transmission, using a directory lookup. Such 251 mechanisms are not defined in this document. 253 There is active investigation within the IETF to develop a solution 254 to this problem, which would resolve a wide range of issues with 255 store-and-forward messaging. 257 3.3. Capabilities Returned in MDN or DSN 259 As outlined in section 2 of this document, a sender may request a 260 positive DSN or an MDN. 262 If the recipient implements [REPORTING-EXTENSIONS], the 263 DSN or MDN that is returned can contain information describing 264 the recipient's capabilities. The sender can use this information 265 for subsequent communications with that recipient. 267 The advantage of this approach is that additional infrastructure is 268 not required (unlike section 3.2), and the information is acquired 269 automatically (unlike section 3.1). 271 4. Security Considerations 273 As this document is an extension of [RFC2305], the Security 274 Considerations section of [RFC2305] applies to this document. 276 The following additional security considerations are introduced by 277 the new features described in this document. 279 4.1. Inaccurate Capabilities Information 281 Inaccurate capability information (section 3) could cause a denial 282 of service. The capability information could be inaccurate due to 283 many reasons, including compromised or improperly configured 284 directory server, improper manual configuration of sender, 285 compromised DNS, or spoofed MDN. If a sender is using cached 286 capability information, it SHOULD be manually confirmed by a user 287 before it is automatically used. 289 4.2. Forged MDNs or DSNs 291 Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298] 292 can provide incorrect information to a sender. 294 5. Implementation Notes 296 This section contains notes to implementors. 298 5.1. Submit mailer does not support DSN 300 In some installations the generally available submit server may not 301 support DSNs. In such circumstances, it may be useful for the sender 302 to implement [RFC974] mail routing as well as additional submission 303 server functions [SUBMIT] so that the installation is not constrained 304 by limitations of the incumbent submission server. 306 5.2. Recipient Recommendations 308 To provide a high degree of reliability, it is desirable for 309 the sender to know that a recipient could not process a message. 310 The inability to successfully process a message may be detectable 311 by the recipient's MTA or MUA. 313 If the recipient's MTA determines the message cannot be processed, 314 the recipient's MTA is strongly encouraged to reject the message with 315 a [RFC1893bis] status code of 5.6.--???-TBD-????--. This status code 316 may be returned in response to the end-of-mail-data indicator if the 317 MTA supports [RFC2034], or after message reception by generating a 318 delivery failure DSN ("bounce"). 320 Note: Because DSN bounces are not requested by the sender and are 321 not 'approved' by the receiver, DSNs can provide a more robust 322 mechanism than performing this function in the MUA using MDNs. 324 If the message contains an MDN request and the recipient's MUA 325 determines the message cannot be processed, the recipient's MUA is 326 strongly encouraged to repond to an MDN request and indicate that 327 processing failed with the disposition-type "processed" or 328 "displayed" and disposition-modifier "error" or "warning" [RFC2298]. 330 6. Acknowledgements 332 The authors would like to acknowledge the members of the IETF 333 Internet Fax working group, and especially the following contributors 334 who provided assistance and input during the development of this 335 document: Vivian Cancio, Richard Coles, David Crocker, Ned Freed, 336 Graham Klyne, MAEDA Toru, Geoff Marshall, Keith Moore, George Pajari, 337 James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford, and 338 Greg Vaudreuil. 340 7. References 342 [FAX-SCHEMA] L. McIntyre, G. Klyne, "Content feature schema for 343 Internet fax", Internet Draft, Work in Progress, 344 draft-ietf-fax-feature-schema-XX.txt. 346 [GOALS] L. Masinter, "Terminology and Goals for Internet Fax", 347 Internet Draft, Work in Progress, draft-ietf-fax-goals-XX.txt, 348 LAST CALL. 350 [REPORT-EXTENSIONS] D. Wing, "Offramp Gateway Extensions to DSN and 351 MDN", Internet Draft, Work in Progress, 352 draft-ietf-fax-reporting-extensions-XX.txt. 354 [RFC1891] K. Moore, "SMTP Service Extensions for Delivery Status 355 Notifications", RFC 1891, January 1996. 357 [RFC1893bis] G. Vaudreuil, "Enhanced Mail System Status Codes", 358 Internet Draft, Work in Progress, (update to RFC 1893). 360 [RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for 361 Delivery Status Notifications", RFC 1894, January 1996. 363 [RFC2034] N. Freed, "SMTP Service Extension for Returning Enhanced 364 Error Codes", RFC 2034, October 1996. 366 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 367 Requirement Levels", RFC 2119, March 1997. 369 [RFC2298] R. Fajman, "An Extensible Message Format for Message 370 Disposition Notifications", RFC 2298, March 1998. 372 [RFC2305] K. Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of 373 Facsimile Using Internet Mail", RFC 2305, March 1998. 375 [RFC974] C. Partridge. "Mail routing and the domain system", RFC 974, 376 January 1986. 378 [SUBMIT] R. Gellens, J. Klensin, "Message Submission", Internet 379 Draft, Work in Progress, draft-gellens-submit-XX.txt. 381 8. Authors' Addresses 383 Larry Masinter 384 Xerox Palo Alto Research Center 385 3333 Coyote Hill Road 386 Palo Alto, CA 94304 USA 388 Fax: +1 415 812 4333 389 EMail: masinter@parc.xerox.com 391 Dan Wing 392 Cisco Systems, Inc. 393 101 Cooper Street 394 Santa Cruz, CA 95060 USA 396 Phone: +1 831 457 5200 397 Fax: +1 831 457 5208 398 EMail: dwing@cisco.com 400 9. Copyright 402 Copyright (C) The Internet Society 1998. All Rights Reserved. 404 This document and translations of it may be copied and furnished to 405 others, and derivative works that comment on or otherwise explain it 406 or assist in its implementation may be prepared, copied, published 407 and distributed, in whole or in part, without restriction of any 408 kind, provided that the above copyright notice and this paragraph are 409 included on all such copies and derivative works. However, this 410 document itself may not be modified in any way, such as by removing 411 the copyright notice or references to the Internet Society or other 412 Internet organizations, except as needed for the purpose of 413 developing Internet standards in which case the procedures for 414 copyrights defined in the Internet Standards process must be 415 followed, or as required to translate it into languages other than 416 English. 418 The limited permissions granted above are perpetual and will not be 419 revoked by the Internet Society or its successors or assigns. 421 This document and the information contained herein is provided on an 422 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 423 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 424 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 425 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 426 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.