idnits 2.17.1 draft-ietf-fax-eifax-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 436 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2305]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2298' is mentioned on line 173, but not defined ** Obsolete undefined reference: RFC 2298 (Obsoleted by RFC 3798) == Missing Reference: 'RFC 2305' is mentioned on line 195, but not defined ** Obsolete undefined reference: RFC 2305 (Obsoleted by RFC 3965) == Missing Reference: 'PGPMIME' is mentioned on line 294, but not defined == Missing Reference: 'MIME-SECURE' is mentioned on line 293, but not defined == Missing Reference: 'IPSEC' is mentioned on line 303, but not defined == Unused Reference: 'MEDIA' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'FEATURES' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RFC1825' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'RFC1847' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'RFC2015' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC2301' is defined on line 373, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-myers-smtp-auth-11 -- Possible downref: Non-RFC (?) normative reference: ref. 'DSN-EXTENSIONS' -- Possible downref: Normative reference to a draft: ref. 'MDN-FEATURES' == Outdated reference: A later version (-05) exists of draft-ietf-conneg-media-features-00 == Outdated reference: A later version (-03) exists of draft-ietf-conneg-feature-reg-00 == Outdated reference: A later version (-04) exists of draft-ietf-fax-goals-02 ** Downref: Normative reference to an Informational draft: draft-ietf-fax-goals (ref. 'GOALS') ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1891 (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1894 (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 2298 (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 2301 (Obsoleted by RFC 3949) ** Obsolete normative reference: RFC 2305 (Obsoleted by RFC 3965) ** Obsolete normative reference: RFC 974 (Obsoleted by RFC 2821) == Outdated reference: A later version (-04) exists of draft-ietf-fax-smtp-session-02 -- Possible downref: Normative reference to a draft: ref. 'SESSION' == Outdated reference: A later version (-08) exists of draft-ietf-smime-msg-04 Summary: 18 errors (**), 0 flaws (~~), 21 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Fax Working Group Larry Masinter 2 Internet Draft Xerox Corporation 3 May 27, 1998 13:49PDT Dan Wing 4 Expires November 1998 Cisco Systems 5 draft-ietf-fax-eifax-01.txt 7 Extended Facsimile Using Internet Mail 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 This draft is being discussed by the IETF FAX working group. To 29 subscribe to the mailing list, send a message to 30 ietf-fax-request@imc.org with the line "subscribe" in the body of the 31 message. Archives are available from http://www.imc.org/ietf-fax. 33 Copyright Notice 35 Copyright (C) The Internet Society (1998). All Rights Reserved. 37 Abstract 39 This document describes extensions to "Simple Mode of Facsimile 40 Using Internet Mail" [RFC2305] to accomplish additional features, 41 including transmission of enhanced document characteristics (higher 42 resolution, color), confirmation of delivery, quick message 43 delivery, GSTN billing information, and message confidentiality. 45 Note: some features in this Internet Draft are being actively 46 discussed in the Internet Fax working group and amongst experts in 47 both facsimile and email. This document does not represent a final 48 consensus of the working group, but is offered as a probable 49 resolution of those discussions, based on current directions, as 50 the proposals are believed to be consistent with the goals of 51 Internet Fax as well as current standards-track directions for 52 email protocols. 54 1. Introduction 56 This document notes a number of enhancements to the "Simple Mode of 57 Facsimile Using Internet Mail" [RFC2305] that may be combined to 58 create an extended mode of facsimile using Internet mail. 60 To promote interoperability, the new features are designed to be 61 interoperable with the existing base of mail transfer agents (MTAs) 62 and mail user agents (MUAs), and take advantage of standards-track 63 mechanisms for positive delivery and disposition notifications. 64 Thus, the enhancements described in this document utilize the 65 messaging infrastructure, where possible, instead of creating 66 fax-specific features which are unlikely to be implemented in 67 non-fax messaging software. 69 This document describes a protocol suite that satisfies all of the 70 required and highly desirable features identified in [GOALS]: 72 * Delivery confirmation (Section 2) (required) 73 * Additional document features (Section 3) (optional) 74 * Quick delivery and confirmation (Section 4) (optional) 75 * GSTN billing information (Section 5) (optional) 76 * Confidentiality (Section 6) (optional) 78 A device which supports all of these recommendations is called an 79 EIFax (Extended Internet Fax) device. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. Delivery Confirmation 87 2.1 Background 89 This section explains the background of delivery confirmation for 90 facsimile and Internet mail as a justification for the protocol 91 requirements made in section 2.2. 93 In traditional facsimile, the sending terminal receives a 94 confirmation when the receiving terminal has finished processing 95 the incoming fax. 97 In Internet Mail, the operations of Delivery (to the mailbox) and 98 Disposition (to paper or a screen) may be separated in time and 99 location. The confirmation of these two operations are supplied by 100 two different standards-track documents, Delivery Status 101 Notifications (DSN) [RFC1891, RFC1894] and Message Disposition 102 Notifications (MDN) [RFC2298] respectively. 104 a) how they are requested: 105 Delivery status notifications are requested within the SMTP 106 protocol using SMTP extensions [RFC1891], while disposition 107 notifications are requested by including a 108 Disposition-Notification-To header in the message. 110 b) when they are reported: 111 Delivery status is reported when a message is delivered to some 112 repository or end-point under the control of the 113 recipient. Disposition notification (MDN) is provided when the 114 message is disposed of by the recipient user, either manually or 115 automatically. 117 c) which agent reports them: 118 Delivery status is reported by the mail transport mechanism, while 119 disposition is reported by the end mail user agent. 121 d) what form the reports take: 122 Both DSNs and MDNs are sent in a "multipart/report". DSNs use 123 "report-type=delivery-status"; MDNs use 124 "report-type=disposition-notification". 126 e) the requirement for notification: 127 The standards for MDNs and DSNs differ on the requirement for 128 automatically generating them. The generation of MDNs by any 129 recipient is entirely optional, and thus no sender can rely on 130 obtaining a MDN from an arbitrary recipient. The generation of some 131 kind of DSN (if only a 'relayed' message) is required and a 132 standard part of MTA operation. 134 2.2 EIFax requirements 136 This section defines requirements for devices that are to be 137 considered EIFax compliant. 139 2.2.1 EIFax Sender Requirements 141 An EIFax sender MUST request successful DSN (NOTIFY=SUCCESS) from 142 the mail transfer agent to which the message is being submitted, if 143 that transfer agent supports DSN. 145 An EIFax sender (or, more precisely, the return address supplied by 146 the EIFax sender) MUST be prepared to accept and display to the 147 sending user the various states of DSN that will be returned, 148 including the possibility that the message was relayed to a MTA 149 that does not support DSN, as well as receiving a status message 150 that is not in DSN format. 152 An EIFax sender MAY also request MDNs, using the mechanism 153 described in Section 2 of [RFC2298]. 155 2.2.2 EIFax Recipient Requirements 157 An EIFax message may be received by software compliant with this 158 document, or may be received by software that provides fewer 159 features such as a legacy MTA or MUA. 161 An EIFax recipient that acts as a SMTP server MUST support 162 [RFC1891]. Other EIFax recipients that perform the function of a 163 MTA SHOULD also support the sending of delivery status 164 notifications. 166 All delivery status notifications generated by an EIFax recipient 167 MUST be in the format described in [RFC1894]. 169 An EIFax recipient that performs message disposition SHOULD support 170 the return of Message Disposition Notifications [RFC2298] following 171 the guidelines for generation of MDNs in that document. While a 172 user agent is "free to silently ignore" a request for a message 173 disposition notification ([RFC 2298] section 2.1), in the case of 174 a network printer which automatically prints messages it receives 175 or an offramp gateway which automatically forwards such messages, 176 the delivery status "dispatched" combined with disposition mode 177 "automatic-action" SHOULD be sent. 179 3. Additional document capabilities 181 Section 4 of [RFC2305] only allows sending the minimum subset 182 of TIFF for Facsimile "unless the sender has prior knowledge 183 of otehr TIFF fields or values supported by the recipient." 185 Various methods for the sender to aquire such knowledge have 186 been proposed: 188 1. Sender manual configuration 189 2. Message Disposition Notification Extension 190 3. Capabilities in Directory 192 3.1 Sender manual configuration 194 One way a sender can send a document which exceeds the minimum 195 subset allowed by [RFC 2305] is for the user controlling the sender 196 to manually override the default settings, at least for particular 197 recipients. 199 If there were well-known configurations with combined capabilities, 200 those capabilities could be described in the sender's user 201 interface. For example, a vendor or trade association could create 202 a profile of recipient capabilities that would describe an extended 203 set of TIFF features and image sizes, and then the sender could 204 manually be configured to send such files if the user controlling 205 the sender knows of the recipient capabilities. 207 For example, a trade association could create a profile named 208 "SuperInterFax", which would signify the ability to accept TIFF 209 profiles M, P, and F and any TIFF resolution and media size. 210 With this profile, a user could manually decide to send a 211 "SuperInterFax" to an address that was advertised to accept 212 this profile. 214 While awkward, this mechanism reflects the current state of 215 deployment of configuration for extended capabilities to ordinary 216 Internet email users. 218 3.2 Message Disposition Notification Extension 220 As outlined in section 2.2.1, an EIFax sender MAY request a Message 221 Disposition Notification. 223 If the recipient supports responding to such a message, and the 224 recipient authorizes responding to the MDN request, the recipient's 225 MDN MAY contain information describing the recipient's capabilities 226 as described in [MDN-FEATURES]. 228 EIFax senders MAY retain a local cache of information about the 229 features supported by recipients. When an EIFax device sends a 230 message to a specific recipient, it MAY use cached information to 231 determine the recipient's capabilities to handle extended document 232 features such as defined in [MDN-FEATURES]. 234 3.3 Capabilities in Directory 236 A future direction for enhanced document features is to create a 237 directory structure of recipient capabilities, deployed, for 238 example, through LDAP or DNS. The directory would provide a 239 mechanism by which a sender could determine a recipient's 240 capabilities before message construction or transmission, using a 241 directory lookup. Such mechanisms are not defined in this document. 243 4. Quick Delivery and Confirmation 245 [SESSION] describes a method by which delivery confirmation may be 246 delivered quickly if there is a direct connection between sender 247 and recipient. EIFax devices SHOULD implement 248 [SESSION]. Intermediate MTAs, e.g., as part of firewalls, MAY also 249 act as [SESSION] gateways, allowing for immediate delivery, with 250 fallback to store-and-forward. 252 EIFax devices MAY implement standard Internet mail routing using 253 the domain name system [RFC974]. EIFax devices MAY be SMTP 254 recipients registered as the primary mail exchanger for their 255 domain. This combination will allow the sending EIFax device to 256 communicate directly with the recipient device. 258 5. GSTN Billing Information 260 [RFC2305] recommends that an offramp gateway servicing multiple 261 mailboxes use SMTP as its protocol. 263 To provide billing information for the offramp service back to the 264 originator of a message, the offramp gateway SHOULD implement 265 [DSN-EXTENSIONS]. 267 6. Security 269 Many uses of Internet Fax require greater security; the requirements 270 for security are discussed in [GOALS]. EIFax supports security by 271 providing for secured content and connections. 273 6.1 Content 275 To secure the contents of the message itself, EIFax devices SHOULD 276 implement S/MIME [SMIME] or PGP-MIME [PGPMIME] or both; these 277 systems are based on the security framework for MIME [MIME-SECURE]. 279 6.1.1 Authentication 281 EIFax devices SHOULD use the multipart/signed MIME type using 282 S/MIME or PGP-MIME signed messages. An EIFax SHOULD sign each 283 message with the identity of the originating user or with the 284 identity of the originating machine or service. An EIFax sender MAY 285 choose its method of signing a message. An EIFax recipient SHOULD 286 verify the signature of all received messages and indicate in any 287 particular way whether the message is unsigned, signed with an 288 unverifiable signature, signed with a signature that does not 289 verify, or signed with a verified signature. 291 6.1.2 Privacy 293 Using the methods of [MIME-SECURE], an EIFax device MAY use either 294 S/MIME [SMIME] or PGP-MIME [PGPMIME] to envelope the content of a 295 document. Enveloping MAY be applied either before or after signing. 297 Enveloped data should only be sent if the recipient's capability to 298 decode the enveloped data is known. 300 6.2 Connections 302 To secure the connection itself, including the envelope itself, EIFax 303 devices should implement [AUTH] or IPSsec [IPSEC]. 305 6.3 When to use security 307 The capability to perform secure transfer is discovered by a sender 308 either through a manual process or by discovering the public key of 309 the recipient. Senders may unilaterally send multipart/signed 310 documents using the signature method of their choice. 312 7. Security considerations 314 [RFC2305] describes the security environment of facsimile and the 315 considerations. This memo extends the requirements of RFC 2305 to 316 specifically recommend the use of both PGP and S/MIME. 318 Inaccurate capability information (section 3) could cause a denial 319 of service. The capability information could be inaccurate due to 320 many reasons, including compromised or improperly configured 321 directory server, improper manual configuration of sender, 322 compromised DNS, or spoofed MDN. If a sender is using cached 323 capability information, it SHOULD be manually confirmed by a user 324 before it is automatically used. 326 8. References 328 [AUTH] J. Myers, "SMTP Service Extension for Authentication", 329 draft-myers-smtp-auth-11.txt, Internet Draft, Work in Progress, 330 February 1998. 332 [DSN-EXTENSIONS] D. Wing. "Extensions to Delivery Status 333 Notifications for Fax", Internet Draft, Work in Progress, November, 334 1997. 336 [MDN-FEATURES] L. Masinter and D. Wing, "Using Message Disposition 337 Notifications to Indicate Supported Features", Internet Draft, Work 338 in Progress, draft-ietf-fax-mdn-features-01.txt, March 1998. 340 [MEDIA] "Media Features for Display, Print, and Fax", L. Masinter, K. 341 Holtman, A. Mutz, D. Wing, Internet Draft, Work in Progress, 342 draft-ietf-conneg-media-features-00.txt, March 1998. 344 [FEATURES] K. Holtman, A. Mutz, T. Hardie, "Feature Tag Registration 345 Procedures", Internet Draft, Work in Progress, 346 draft-ietf-conneg-feature-reg-00.txt, March 1998. 348 [GOALS] L. Masinter, "Terminology and Goals for Internet Fax", 349 Internet Draft, Work in Progress, draft-ietf-fax-goals-02.txt, March 350 1998. 352 [RFC1825] R. Atkinson, "Security Architecture for the Internet 353 Protocol", RFC 1825, Naval Research Laboratory, August 1995. 355 [RFC1847] "Security Multiparts for MIME: Multipart/Signed and 356 Multipart/Encrypted", RFC 1847, October 1995. 358 [RFC1891] K. Moore, "SMTP Service Extensions for Delivery Status 359 Notifications", RFC 1891, January 1996. 361 [RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for 362 Delivery Status Notifications", RFC 1894, January 1996 364 [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", 365 RFC2015, October 1996. 367 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 368 Requirement Levels", RFC 2119, March 1997. 370 [RFC2298] R. Fajman, "An Extensible Message Format for Message 371 Disposition Notifications", RFC 2298, March 1998. 373 [RFC2301] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, 374 J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998. 376 [RFC2305] K.Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of 377 Facsimile Using Internet Mail", RFC 2305, March 1998. 379 [RFC974] C. Partridge. "Mail routing and the domain system", RFC 974, 380 January 1986. 382 [SESSION] N. Joffe, D. Wing, L. Masinter, "SMTP Service Extension for 383 Immediate Delivery", Internet Draft, Work in Progress, 384 draft-ietf-fax-smtp-session-02.txt, Feb 1998. 386 [SMIME] B. Ramsdell. "S/MIME Version 3 Message Specification", 387 Internet Draft, Work in Progress, draft-ietf-smime-msg-04.txt, May 388 1998. 390 9. Authors' Addresses 392 Larry Masinter 393 Xerox Palo Alto Research Center 394 3333 Coyote Hill Road 395 Palo Alto, CA 94304 USA 396 Fax: +1 415 812 4333 397 EMail: masinter@parc.xerox.com 399 Dan Wing 400 Cisco Systems, Inc. 401 170 West Tasman Drive 402 San Jose, CA 95134-1619 403 Phone: +1 408 526 4000 404 Fax: +1 408 457 5208 405 EMail: dwing@cisco.com 407 10. Copyright 409 Copyright (C) The Internet Society 1998. All Rights Reserved. 411 This document and translations of it may be copied and furnished to 412 others, and derivative works that comment on or otherwise explain it 413 or assist in its implementation may be prepared, copied, published 414 and distributed, in whole or in part, without restriction of any 415 kind, provided that the above copyright notice and this paragraph are 416 included on all such copies and derivative works. However, this 417 document itself may not be modified in any way, such as by removing 418 the copyright notice or references to the Internet Society or other 419 Internet organizations, except as needed for the purpose of 420 developing Internet standards in which case the procedures for 421 copyrights defined in the Internet Standards process must be 422 followed, or as required to translate it into languages other than 423 English. 425 The limited permissions granted above are perpetual and will not be 426 revoked by the Internet Society or its successors or assigns. 428 This document and the information contained herein is provided on an 429 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 430 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 431 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 432 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 433 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.