idnits 2.17.1 draft-ietf-fax-eifax-11.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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 192, but not defined == Missing Reference: 'IMAP4' is mentioned on line 192, but not defined == Missing Reference: 'RFC23035' is mentioned on line 246, but not defined == Missing Reference: 'RFC1892' is mentioned on line 339, but not defined ** Obsolete undefined reference: RFC 1892 (Obsoleted by RFC 3462) == Unused Reference: 'RFC2301' is defined on line 427, 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. -------------------------------------------------------------------------------- 1 Internet Fax Working Group Larry Masinter 2 Internet Draft Xerox Corporation 3 November 11, 1998 Dan Wing 4 Expires April 1999 Cisco Systems 5 draft-ietf-fax-eifax-11.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 describes 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 NOTE: The authors of this document have recently been made aware of 50 several intellectual property claims that relate to the technology 51 described in this document, including US patents 5812278 and 5805298. 52 This disclosure is being made according to the rules laid out in RFC 53 2026 and 2028, where contributors are required to disclose the 54 existence of any proprietary or intellectual property rights in the 55 contribution that are reasonably and personally known to the 56 contributor. These intellectual property claims may interfere with 57 this specification moving forward along standards track. 59 1. Introduction 61 This document notes a number of enhancements to the "Simple Mode of 62 Facsimile Using Internet Mail" [RFC2305] that may be combined to 63 create an extended mode of facsimile using Internet mail. 65 The new features are designed to be interoperable with the existing 66 base of mail transfer agents (MTAs) and mail user agents (MUAs), 67 and take advantage of existing standards for advanced functionality 68 such as positive delivery confirmation and disposition notification. 69 The enhancements described in this document utilize the messaging 70 infrastructure, where possible, instead of creating fax-specific 71 features which are unlikely to be implemented in non-fax messaging 72 software. 74 This document standardizes two features described in its companion 75 document, [GOALS]: 77 * Delivery confirmation (Section 2) (required) 78 * Additional document features (Section 3) (optional) 80 1.1. Definition of Terms 82 The term "processing" indicates the action of rendering or 83 transmitting the contents of the message to a printer, display device, 84 or fax machine. 86 The term "processing confirmation" is an indication by the 87 recipient of a message that it is able to process the contents 88 of that message. 90 The term "recipient" indicates the device which performs the 91 processing function. For example, a recipient could be implemented 92 as a traditional Mail User Agent on a PC, a standalone device which 93 retrieves mail using POP3 or IMAP, an SMTP server which prints 94 incoming messages (similar to an LPR server). 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 1.2. GSTN Fax Gateways ("onramp"/"offramp") 102 The behavior of gateways from GSTN fax to SMTP ("onramps") and from 103 SMTP to GSTN fax ("offramps") are not described in this document. 104 However, such gateways SHOULD have the behavior characteristics of 105 senders and recipients as described in this document. 107 2. Delivery and Processing Confirmation 109 In traditional GSTN-based realtime facsimile, the receiving terminal 110 acknowledges successful receipt and processing of every page [T.30]. 112 In Internet Mail, the operations of Delivery (to the mailbox) and 113 Disposition (to paper or a screen) may be separated in time (due to 114 store and forwarding of messages) and location (due to separation of 115 delivery agent (MTA) and user agent (MUA)). The confirmation of 116 these two operations are supplied by two different standards-track 117 mechanisms: Delivery Status Notifications (DSN) [RFC1891, RFC1894] 118 and Message Disposition Notifications (MDN) [RFC2298], respectively. 120 This section defines requirements for devices or services that are to 121 be considered compliant with this document. 123 2.1. Sender Requirements 125 Because delivery failure may occur (over disk quota, user no longer 126 exists, malconfigured mailer), a delivery failure message (in the 127 format described by [RFC1894] or otherwise) may be sent to the 128 envelope-from address specified by the sender. Thus, the 129 envelope-from address supplied by the sender MUST be able to properly 130 handle such delivery failure messages. 132 2.1.1. Delivery Confirmation 134 If the sender desires delivery confirmation, the sender MUST request 135 Delivery Status Notification by including the the esmtp-keyword 136 NOTIFY with the esmtp-value SUCCESS [section 5.1 of RFC1891]. 138 2.1.2. Processing Confirmation 140 If the sender desires processing confirmation, the sender MUST 141 request Message Disposition Notification [RFC2298 section 2] 142 when sending the message itself. 144 Because a recipient may silently ignore a request for an MDN [section 145 2.1 of RFC2298] at any time: 146 * MDNs MUST NOT be used for delivery confirmation, but are only 147 useful for disposition ("processing") notification. 148 * the sender MUST NOT assume the recipient will respond to an MDN 149 request in a subsequent message, even if the recipient has 150 done so in the past. 152 The address provided by the sender on the Disposition-Notification-To 153 field MUST be able to receive Message Disposition Notifications 154 messages [RFC2298] and SHOULD be able to receive messages that are 155 not in the Message Disposition Notification format (due to the 156 existence of legacy systems that generate non-RFC2298-compliant 157 responses to the Disposition-Notification-To field). The 158 Disposition-Notification-To address and the envelope-from address 159 SHOULD match to allow automated responses to MDN requests (section 160 2.1 of [RFC2298]). 162 2.2. Recipient Requirements 164 Recipients SHOULD implement Message Disposition Notifications 165 [RFC2298] and SHOULD indicate supported media features in 166 DSN and MDN messages per [REPORT-EXTENSIONS]. 168 If the recipient is an SMTP server, it behaves as part of the 169 receiver infrastructure and is therefore subject to the "Receiver 170 Infrastructure" requirements of this document. 172 See also "Recipient Recommendations" in section 5. 174 2.2.1. MDN Recipient Requirements 176 Recipients MUST be configurable to silently ignore a request for an 177 MDN ([section 2.1 of RFC2298]). 179 If the recipient is an automated message processing system which is 180 not associated with a person, the device MAY be configurable to 181 always respond to MDN requests, but in all cases MUST be configurable 182 to never generate MDNs. 184 A recipient MUST NOT generate an unsolicited MDN to indicate 185 successful processing. A recipient MAY generate an unsolicited MDN 186 (sent to the envelope-from (Return-Path:) address) to indicate 187 processing failure, but subject to the [RFC2298] requirement that it 188 MUST always be possible for an operator to disable unsolicited MDN 189 generation. 191 2.2.2. Recipients Using Mailbox Access Protocols 192 A recipient using [POP3] or [IMAP4] to retrieve its mail MUST NOT 193 generate a Delivery Status Notification message [RFC1894]. 195 The recipient MUST NOT use the RFC822 "To:" fields, "Cc:" fields, 196 "Bcc:" fields, or any other fields containing header recipient 197 information to determine the ultimate destination mailbox or 198 addressee, and SHOULD NOT use other RFC822 or MIME fields for making 199 such determinations. 201 2.3. Messaging Infrastructure Requirements 203 This section explains the requirements of the SMTP messaging 204 infrastructure used by the sender and receiver. This infrastructure 205 is commonly provided by the ISP or a company's internal mailers but 206 can actually be provided by another organization with appropriate 207 service contracts. 209 2.3.1. Sender Infrastructure 211 Support for DSN [RFC1891] MUST be provided by the mail submission 212 server [SUBMIT] used by the sender and MUST be provided up to the 213 mailer responsible for communicating with external (Internet) 214 mailers. 216 Also see section 5.1 of this document. 218 2.3.2. Receiver Infrastructure 220 Support for DSN [RFC1891] MUST be provided by the external 221 (Internet-accessible) mailer, and MUST be provided by each mailer 222 between the external mailer and the recipient. If the recipient is 223 implemented as an SMTP server it MUST also support DSN [RFC1891]. 225 3. Additional Document Capabilities 227 Section 4 of "A Simple Mode of Facsimile Using Internet Mail" 228 [RFC2305] allows sending only the minimum subset of TIFF for 229 Facsimile "unless the sender has prior knowledge of other TIFF fields 230 or values supported by the recipient." 232 A recipient MAY support any or all (or any combination) of the TIFF 233 profiles defined in RFC 2301, in addition to profile S. A recipient 234 which supports additional profiles SHOULD indicate this support as 235 per section 3.2 or 3.3 of this document. As a consequence, a sender 236 MAY use those additional TIFF profiles when sending to a recipient 237 with the corresponding capabilities. 239 A sender SHOULD be able to recognize and process the feature tags as 240 defined in [FAX-SCHEMA] when reviewing the capabilities presented by 241 a potential recipient. The capability matching rules indicated there 242 (by reference to [CONNEG-FEATURE-SYNTAX]) allow for the introduction 243 of new features that may be unrecognized by older implementations. 245 A sender MAY send a message containing both the minimum subset of 246 TIFF for Facsimile (as specified in [RFC23035]) and a higher quality 247 TIFF using multipart/alternative. 249 Three methods for the sender to acquire such knowledge are 250 described: 252 1. Sender manual configuration 253 2. Capabilities in Directory 254 3. Capabilities returned in MDN or DSN 256 Method (3) SHOULD be used. 258 An implementation may cache capabilities locally and lose 259 synchronization with the recipient's actual capabilities. A 260 mechanism SHOULD be provided to allow the sender to override the 261 locally-stored cache of capabilities. Also note section 4.1 of this 262 document. 264 3.1. Sender Manual Configuration 266 One way a sender can send a document which exceeds the minimum subset 267 allowed by [RFC2305] is for the user controlling the sender to 268 manually override the default settings, usually on a per-recipient 269 basis. For example, during transmission a user could indicate the 270 recipient is capable of receiving high resolution images or color 271 images. 273 While awkward and not automatic, this mechanism reflects the current 274 state of deployment of configuration for extended capabilities to 275 ordinary Internet email users. 277 3.2. Capabilities in Directory 279 A future direction for enhanced document features is to create a 280 directory structure of recipient capabilities, deployed, for example, 281 through LDAP or DNS. The directory would provide a mechanism by which 282 a sender could determine a recipient's capabilities before message 283 construction or transmission, using a directory lookup. Such 284 mechanisms are not defined in this document. 286 There is active investigation within the IETF to develop a solution 287 to this problem, which would resolve a wide range of issues with 288 store-and-forward messaging. 290 3.3. Capabilities Returned in MDN or DSN 292 As outlined in section 2 of this document, a sender may request a 293 positive DSN or an MDN. 295 If the recipient implements [REPORT-EXTENSIONS], the DSN or MDN that 296 is returned can contain information describing the recipient's 297 capabilities. The sender can use this information for subsequent 298 communications with that recipient. 300 The advantage of this approach is that additional infrastructure is 301 not required (unlike section 3.2), and the information is acquired 302 automatically (unlike section 3.1). 304 3.3.1. Restrictions and Recommendations 306 A sender MUST NOT send a message with no processable content to 307 attempt to elicit an MDN/DSN capability response. Doing so with a 308 message with no processable content (such as a message containing 309 only a request for capabilities or a blank message) will confuse a 310 recipient not already designed to understand the semantics of such a 311 message. 313 A recipient SHOULD indicate the profiles and features supported, 314 even if the recipient supports only Tiff Profile S (the minimum 315 set for fax as defined by [RFC2305]) [FAX-SCHEMA]. This allows 316 a sender to determine that the recipient is compliant with 317 this Extended Facsimile Using Internet Mail specification. 319 4. Security Considerations 321 As this document is an extension of [RFC2305], the Security 322 Considerations section of [RFC2305] applies to this document. 324 The following additional security considerations are introduced by 325 the new features described in this document. 327 4.1. Inaccurate Capabilities Information 329 Inaccurate capability information (section 3) could cause a denial of 330 service. The capability information could be inaccurate due to many 331 reasons, including compromised or improperly configured directory 332 server, improper manual configuration of sender, compromised DNS, or 333 spoofed MDN. If a sender is using cached capability information, 334 there SHOULD be a mechanism to allow the cached information to be 335 ignored or overridden if necessary. 337 4.2. Forged MDNs or DSNs 339 Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298] 340 can provide incorrect information to a sender. 342 5. Implementation Notes 344 This section contains notes to implementors. 346 5.1. Submit Mailer Does Not Support DSN 348 In some installations the generally available submit server may not 349 support DSNs. In such circumstances, it may be useful for the sender 350 to implement [RFC974] mail routing as well as additional submission 351 server functions [SUBMIT] so that the installation is not constrained 352 by limitations of the incumbent submission server. 354 5.2. Recipient Recommendations 356 To provide a high degree of reliability, it is desirable for 357 the sender to know that a recipient could not process a message. 358 The inability to successfully process a message may be detectable 359 by the recipient's MTA or MUA. 361 If the recipient's MTA determines the message cannot be processed, 362 the recipient's MTA is strongly encouraged to reject the message with 363 a [RFC1893] status code of 5.6.1. This status code may be returned 364 in response to the end-of-mail-data indicator if the MTA supports 365 reporting of enhanced error codes [RFC2034], or after message 366 reception by generating a delivery failure DSN ("bounce"). 368 Note: Providing this functionality in the MTA, via either of the 369 two mechanisms described above, is superior to providing the 370 function using MDNs because MDNs must be requested by the 371 sender (and the request may, at any time, be ignored by 372 the receiver). Message rejection performed by the MTA can 373 always occur without the sender requesting such behavior 374 and without the receiver circumventing the behavior. 376 If the message contains an MDN request and the recipient's MUA 377 determines the message cannot be processed, the recipient's MUA is 378 strongly encouraged to repond to an MDN request and indicate that 379 processing failed with the disposition-type "processed" or 380 "displayed" and disposition-modifier "error" or "warning" [RFC2298]. 382 6. Acknowledgements 383 The authors would like to acknowledge the members of the IETF 384 Internet Fax working group, and especially the following contributors 385 who provided assistance and input during the development of this 386 document: Vivian Cancio, Richard Coles, David Crocker, Ned Freed, 387 Graham Klyne, MAEDA Toru, Geoff Marshall, Lloyd McIntyre, Keith 388 Moore, George Pajari, James Rafferty, Mike Ruhl, Richard Shockey, 389 Brian Stafford, and Greg Vaudreuil. 391 7. References 393 [CONNEG-FEATURE-SYNTAX] G. Klyne, "A syntax for describing media 394 feature sets", Internet Draft, Work in Progress, 395 draft-ietf-conneg-feature-syntax-XX.txt. 397 [FAX-SCHEMA] L. McIntyre, G. Klyne, "Content feature schema for 398 Internet fax", Internet Draft, Work in Progress, 399 draft-ietf-fax-feature-schema-XX.txt. 401 [GOALS] L. Masinter, "Terminology and Goals for Internet Fax", 402 Internet Draft, Work in Progress, draft-ietf-fax-goals-XX.txt, 403 LAST CALL. 405 [REPORT-EXTENSIONS] D. Wing, "Offramp Gateway Extensions to DSN and 406 MDN", Internet Draft, Work in Progress, 407 draft-ietf-fax-reporting-extensions-XX.txt. 409 [RFC1891] K. Moore, "SMTP Service Extensions for Delivery Status 410 Notifications", RFC 1891, January 1996. 412 [RFC1893] G. Vaudreuil, "Enhanced Mail System Status Codes", 413 RFC 1893, January 1996. 415 [RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for 416 Delivery Status Notifications", RFC 1894, January 1996. 418 [RFC2034] N. Freed, "SMTP Service Extension for Returning Enhanced 419 Error Codes", RFC 2034, October 1996. 421 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 422 Requirement Levels", RFC 2119, March 1997. 424 [RFC2298] R. Fajman, "An Extensible Message Format for Message 425 Disposition Notifications", RFC 2298, March 1998. 427 [RFC2301] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, 428 J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998. 430 [RFC2305] K. Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of 431 Facsimile Using Internet Mail", RFC 2305, March 1998. 433 [RFC974] C. Partridge. "Mail routing and the domain system", RFC 974, 434 January 1986. 436 [SUBMIT] R. Gellens, J. Klensin, "Message Submission", Internet 437 Draft, Work in Progress, draft-gellens-submit-XX.txt. 439 8. Authors' Addresses 441 Larry Masinter 442 Xerox Palo Alto Research Center 443 3333 Coyote Hill Road 444 Palo Alto, CA 94304 USA 446 Fax: +1 650 812 4333 447 EMail: masinter@parc.xerox.com 449 Dan Wing 450 Cisco Systems, Inc. 451 101 Cooper Street 452 Santa Cruz, CA 95060 USA 454 Phone: +1 831 457 5200 455 Fax: +1 831 457 5208 456 EMail: dwing@cisco.com 458 9. Copyright 460 Copyright (C) The Internet Society 1998. All Rights Reserved. 462 This document and translations of it may be copied and furnished to 463 others, and derivative works that comment on or otherwise explain it 464 or assist in its implementation may be prepared, copied, published 465 and distributed, in whole or in part, without restriction of any 466 kind, provided that the above copyright notice and this paragraph are 467 included on all such copies and derivative works. However, this 468 document itself may not be modified in any way, such as by removing 469 the copyright notice or references to the Internet Society or other 470 Internet organizations, except as needed for the purpose of 471 developing Internet standards in which case the procedures for 472 copyrights defined in the Internet Standards process must be 473 followed, or as required to translate it into languages other than 474 English. 476 The limited permissions granted above are perpetual and will not be 477 revoked by the Internet Society or its successors or assigns. 479 This document and the information contained herein is provided on an 480 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 481 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 482 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 483 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 484 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.