idnits 2.17.1 draft-ietf-fax-eifax-07.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 174, but not defined == Missing Reference: 'IMAP4' is mentioned on line 174, but not defined == Missing Reference: 'RFC1892' is mentioned on line 297, but not defined ** Obsolete undefined reference: RFC 1892 (Obsoleted by RFC 3462) == Missing Reference: 'RFC1893' is mentioned on line 321, but not defined ** Obsolete undefined reference: RFC 1893 (Obsoleted by RFC 3463) == Unused Reference: 'RFC1893bis' is defined on line 371, but no explicit reference was found in the text -- No information found for draft-ietf-conneg-feature-syntax-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CONNEG-FEATURE-SYNTAX' -- 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 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-gellens-submit-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SUBMIT' Summary: 17 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Fax Working Group Larry Masinter 3 Internet Draft Xerox Corporation 4 October 16, 1998 Dan Wing 5 Expires March 1999 Cisco Systems 6 draft-ietf-fax-eifax-07.txt 8 Extended Facsimile Using Internet Mail 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 This draft is a product of the IETF Internet Fax working group. To 30 subscribe to the mailing list, send a message to 31 ietf-fax-request@imc.org with the line "subscribe" in the body of the 32 message. Archives are available from http://www.imc.org/ietf-fax. 34 Copyright Notice 36 Copyright (C) The Internet Society (1998). All Rights Reserved. 38 Abstract 40 This document describes extensions to "Simple Mode of Facsimile Using 41 Internet Mail" [RFC2305] and describes additional features, including 42 transmission of enhanced document characteristics (higher resolution, 43 color) and confirmation of delivery and processing. 45 These additional features are designed to provide the highest level 46 of interoperability with the existing and future standards-compliant 47 email infrastructure and mail user agents, while providing a level of 48 service that approximates the level currently enjoyed by fax users. 50 1. Introduction 52 This document notes a number of enhancements to the "Simple Mode of 53 Facsimile Using Internet Mail" [RFC2305] that may be combined to 54 create an extended mode of facsimile using Internet mail. 56 The new features are designed to be interoperable with the existing 57 base of mail transfer agents (MTAs) and mail user agents (MUAs), 58 and take advantage of existing standards for advanced functionality 59 such as positive delivery confirmation and disposition notification. 60 The enhancements described in this document utilize the messaging 61 infrastructure, where possible, instead of creating fax-specific 62 features which are unlikely to be implemented in non-fax messaging 63 software. 65 This document standardizes two features described in its companion 66 document, [GOALS]: 68 * Delivery confirmation (Section 2) (required) 69 * Additional document features (Section 3) (optional) 71 1.1. Definition of terms 73 The term "processing" indicates the ability to successfully render or 74 transmit the contents of the message to a printer, display device, or 75 fax machine. 77 The term "recipient" indicates the device which performs the 78 processing function. For example, a recipient could be implemented 79 as a traditional Mail User Agent on a PC, a standalone device which 80 retrieves mail using POP3 or IMAP, an SMTP server which prints 81 incoming messages (similar to an LPR server). 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 1.2. GSTN Fax Gateways ("onramp"/"offramp") 89 The behavior of gateways from GSTN fax to SMTP ("onramps") and from 90 SMTP to GSTN fax ("offramps") are not described in this document. 91 However, such gateways SHOULD have the behavior characteristics of 92 senders and recipients as described in this document. 94 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 mechanisms: 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 this document. 110 2.1. Sender Requirements 112 A delivery failure message (in the format described by [RFC1894] or 113 otherwise) may be sent to the envelope-from address specified by the 114 sender. Thus, the envelope-from address supplied by the sender MUST 115 be able to properly handle such delivery failure messages. 117 2.1.1. Delivery Confirmation 119 If the sender desires delivery confirmation, the sender MUST request 120 Delivery Status Notification by including the the esmtp-keyword 121 NOTIFY with the esmtp-value SUCCESS [section 5.1 of RFC1891]. 123 2.1.2. Processing Confirmation 125 If the sender desires processing confirmation, the sender MUST 126 request Message Disposition Notification using the method described 127 in section 2 of [RFC2298]. 129 Because a recipient may silently ignore a request for an MDN [section 130 2.1 of RFC2298] at any time: 131 * MDNs MUST NOT be used for delivery confirmation, but are only 132 useful for disposition ("processing") notification. 133 * the sender MUST NOT assume the recipient will respond to an MDN 134 request in a subsequent message, even if the recipient has 135 done so in the past. 137 The address provided by the sender on the Disposition-Notification-To 138 field MUST be able to receive Message Disposition Notifications 139 messages [RFC2298] and SHOULD be able to receive messages that are 140 not in the Message Disposition Notification format (due to the 141 existence of legacy systems that generate non-RFC2298-compliant 142 responses to the Disposition-Notification-To field). 144 2.2. Recipient Requirements 145 Recipients SHOULD implement Message Disposition Notifications 146 [RFC2298] and SHOULD indicate supported media features in 147 DSN and MDN messages per [REPORT-EXTENSIONS]. 149 If the recipient is an SMTP server, it behaves as part of the 150 receiver infrastructure and is therefore subject to the "Receiver 151 Infrastructure" requirements of this document. 153 See also "Recipient Recommendations" in section 5. 155 2.2.1. MDN Recipient Requirements 157 Recipients MUST be configurable to silently ignore a request for an 158 MDN ([section 2.1 of RFC2298]). 160 If the recipient is an automated message processing system which is 161 not associated with a person, the device MAY be configurable to 162 always respond to MDN requests, but in all cases MUST be configurable 163 to never generate MDNs. 165 A recipient MUST NOT generate an unsolicited MDN to indicate 166 successful processing. A recipient MAY generate an unsolicited MDN 167 (sent to the envelope-from (Return-Path:) address) to indicate 168 processing failure, but subject to the [RFC2298] requirement that it 169 MUST always be possible for an operator to disable unsolicited MDN 170 generation. 172 2.2.2. Recipients using Mailbox Access Protocols 174 A recipient using [POP3] or [IMAP4] to retrieve its mail MUST NOT 175 generate a Delivery Status Notification message [RFC1894]. 177 The recipient MUST NOT use the RFC822 "To:" fields, "Cc:" fields, 178 "Bcc:" fields, or any other fields containing header recipient 179 information to determine the ultimate destination mailbox or 180 addressee, and SHOULD NOT use other RFC822 or MIME fields for making 181 such determinations. 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 Support for DSN [RFC1891] MUST be provided by the mail submission 193 server [SUBMIT] used by the sender and MUST be provided up to the 194 mailer responsible for communicating with external (Internet) 195 mailers. 197 Also see section 5.1 of this document. 199 2.3.2. Receiver Infrastructure 201 Support for DSN [RFC1891] MUST be provided by the external 202 (Internet-accessible) mailer, and MUST be provided by each mailer 203 between the external mailer and the recipient. If the recipient is 204 implemented as an SMTP server it MUST also support DSN [RFC1891]. 206 3. Additional document capabilities 208 Section 4 of "A Simple Mode of Facsimile Using Internet Mail" 209 [RFC2305] allows sending only the minimum subset of TIFF for 210 Facsimile "unless the sender has prior knowledge of other TIFF fields 211 or values supported by the recipient." 213 If support for any additional feature of TIFF for facsimile, as 214 described by "File Format for Internet Fax" [RFC2301], are supported 215 by a recipient, the recipient SHOULD indicate support for those 216 additional features using the mechanism described in section 3.2 or 217 3.3 of this document. 219 A sender SHOULD be able to recognize and process the feature 220 tags as defined in [FAX-SCHEMA] when reviewing the capabilities 221 presented by a potential recipient. The capability matching rules 222 indicated there (by reference to [CONNEG-FEATURE-SYNTAX]) allow for 223 the introduction of new features that may be unrecognized by older 224 implementations. 226 Three methods for the sender to acquire such knowledge are 227 permitted: 229 1. Sender manual configuration 230 2. Capabilities in Directory 231 3. Capabilities returned in MDN or DSN 233 An implementation may cache capabilities locally and lose 234 synchronization with the recipient's actual capabilities. A 235 mechanism should be provided to allow the sender to override the 236 locally-stored cache of capabilities. Also note section 4.1 of this 237 document. 239 3.1. Sender manual configuration 240 One way a sender can send a document which exceeds the minimum subset 241 allowed by [RFC2305] is for the user controlling the sender to 242 manually override the default settings, usually on a per-recipient 243 basis. For example, during transmission a user could indicate the 244 recipient is capable of receiving high resolution images or color 245 images. 247 While awkward and not automatic, this mechanism reflects the current 248 state of deployment of configuration for extended capabilities to 249 ordinary Internet email users. 251 3.2. Capabilities in Directory 253 A future direction for enhanced document features is to create a 254 directory structure of recipient capabilities, deployed, for example, 255 through LDAP or DNS. The directory would provide a mechanism by which 256 a sender could determine a recipient's capabilities before message 257 construction or transmission, using a directory lookup. Such 258 mechanisms are not defined in this document. 260 There is active investigation within the IETF to develop a solution 261 to this problem, which would resolve a wide range of issues with 262 store-and-forward messaging. 264 3.3. Capabilities Returned in MDN or DSN 266 As outlined in section 2 of this document, a sender may request a 267 positive DSN or an MDN. 269 If the recipient implements [REPORT-EXTENSIONS], the DSN or MDN that 270 is returned can contain information describing the recipient's 271 capabilities. The sender can use this information for subsequent 272 communications with that recipient. 274 The advantage of this approach is that additional infrastructure is 275 not required (unlike section 3.2), and the information is acquired 276 automatically (unlike section 3.1). 278 4. Security Considerations 280 As this document is an extension of [RFC2305], the Security 281 Considerations section of [RFC2305] applies to this document. 283 The following additional security considerations are introduced by 284 the new features described in this document. 286 4.1. Inaccurate Capabilities Information 287 Inaccurate capability information (section 3) could cause a denial of 288 service. The capability information could be inaccurate due to many 289 reasons, including compromised or improperly configured directory 290 server, improper manual configuration of sender, compromised DNS, or 291 spoofed MDN. If a sender is using cached capability information, 292 there SHOULD be a mechanism to allow the cached information to be 293 ignored or overridden if necessary. 295 4.2. Forged MDNs or DSNs 297 Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298] 298 can provide incorrect information to a sender. 300 5. Implementation Notes 302 This section contains notes to implementors. 304 5.1. Submit mailer does not support DSN 306 In some installations the generally available submit server may not 307 support DSNs. In such circumstances, it may be useful for the sender 308 to implement [RFC974] mail routing as well as additional submission 309 server functions [SUBMIT] so that the installation is not constrained 310 by limitations of the incumbent submission server. 312 5.2. Recipient Recommendations 314 To provide a high degree of reliability, it is desirable for 315 the sender to know that a recipient could not process a message. 316 The inability to successfully process a message may be detectable 317 by the recipient's MTA or MUA. 319 If the recipient's MTA determines the message cannot be processed, 320 the recipient's MTA is strongly encouraged to reject the message with 321 a [RFC1893] status code of 5.6.1. This status code may be returned 322 in response to the end-of-mail-data indicator if the MTA supports 323 reporting of enhanced error codes [RFC2034], or after message 324 reception by generating a delivery failure DSN ("bounce"). 326 Note: Providing this functionality in the MTA, via either of the 327 two mechanisms described above, is superior to providing the 328 function using MDNs because MDNs must be requested by the 329 sender (and the request may, at any time, be ignored by 330 the receiver). Message rejection performed by the MTA can 331 always occur without the sender requesting such behavior 332 and without the receiver circumventing the behavior. 334 If the message contains an MDN request and the recipient's MUA 335 determines the message cannot be processed, the recipient's MUA is 336 strongly encouraged to repond to an MDN request and indicate that 337 processing failed with the disposition-type "processed" or 338 "displayed" and disposition-modifier "error" or "warning" [RFC2298]. 340 6. Acknowledgements 342 The authors would like to acknowledge the members of the IETF 343 Internet Fax working group, and especially the following contributors 344 who provided assistance and input during the development of this 345 document: Vivian Cancio, Richard Coles, David Crocker, Ned Freed, 346 Graham Klyne, MAEDA Toru, Geoff Marshall, Keith Moore, George Pajari, 347 James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford, and 348 Greg Vaudreuil. 350 7. References 352 [CONNEG-FEATURE-SYNTAX] G. Klyne, "A syntax for describing media 353 feature sets", Internet Draft, Work in Progress, 354 draft-ietf-conneg-feature-syntax-XX.txt. 356 [FAX-SCHEMA] L. McIntyre, G. Klyne, "Content feature schema for 357 Internet fax", Internet Draft, Work in Progress, 358 draft-ietf-fax-feature-schema-XX.txt. 360 [GOALS] L. Masinter, "Terminology and Goals for Internet Fax", 361 Internet Draft, Work in Progress, draft-ietf-fax-goals-XX.txt, 362 LAST CALL. 364 [REPORT-EXTENSIONS] D. Wing, "Offramp Gateway Extensions to DSN and 365 MDN", Internet Draft, Work in Progress, 366 draft-ietf-fax-reporting-extensions-XX.txt. 368 [RFC1891] K. Moore, "SMTP Service Extensions for Delivery Status 369 Notifications", RFC 1891, January 1996. 371 [RFC1893bis] G. Vaudreuil, "Enhanced Mail System Status Codes", 372 Internet Draft, Work in Progress, (update to RFC 1893). 374 [RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for 375 Delivery Status Notifications", RFC 1894, January 1996. 377 [RFC2034] N. Freed, "SMTP Service Extension for Returning Enhanced 378 Error Codes", RFC 2034, October 1996. 380 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 381 Requirement Levels", RFC 2119, March 1997. 383 [RFC2298] R. Fajman, "An Extensible Message Format for Message 384 Disposition Notifications", RFC 2298, March 1998. 386 [RFC2301] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, 387 J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998. 389 [RFC2305] K. Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of 390 Facsimile Using Internet Mail", RFC 2305, March 1998. 392 [RFC974] C. Partridge. "Mail routing and the domain system", RFC 974, 393 January 1986. 395 [SUBMIT] R. Gellens, J. Klensin, "Message Submission", Internet 396 Draft, Work in Progress, draft-gellens-submit-XX.txt. 398 8. Authors' Addresses 400 Larry Masinter 401 Xerox Palo Alto Research Center 402 3333 Coyote Hill Road 403 Palo Alto, CA 94304 USA 405 Fax: +1 415 812 4333 406 EMail: masinter@parc.xerox.com 408 Dan Wing 409 Cisco Systems, Inc. 410 101 Cooper Street 411 Santa Cruz, CA 95060 USA 413 Phone: +1 831 457 5200 414 Fax: +1 831 457 5208 415 EMail: dwing@cisco.com 417 9. Copyright 419 Copyright (C) The Internet Society 1998. All Rights Reserved. 421 This document and translations of it may be copied and furnished to 422 others, and derivative works that comment on or otherwise explain it 423 or assist in its implementation may be prepared, copied, published 424 and distributed, in whole or in part, without restriction of any 425 kind, provided that the above copyright notice and this paragraph are 426 included on all such copies and derivative works. However, this 427 document itself may not be modified in any way, such as by removing 428 the copyright notice or references to the Internet Society or other 429 Internet organizations, except as needed for the purpose of 430 developing Internet standards in which case the procedures for 431 copyrights defined in the Internet Standards process must be 432 followed, or as required to translate it into languages other than 433 English. 435 The limited permissions granted above are perpetual and will not be 436 revoked by the Internet Society or its successors or assigns. 438 This document and the information contained herein is provided on an 439 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 440 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 441 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 442 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 443 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.