idnits 2.17.1 draft-ietf-fax-service-v2-00.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 Abstract section. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 96 has weird spacing: '...e using an In...' == Line 97 has weird spacing: '... device using...' == Line 538 has weird spacing: '... in a fil...' == Line 540 has weird spacing: '...int/fax the r...' == Line 541 has weird spacing: '... rather than ...' -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 2306 (ref. '5') ** Obsolete normative reference: RFC 2301 (ref. '6') (Obsoleted by RFC 3949) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2060 (ref. '10') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2303 (ref. '11') (Obsoleted by RFC 3191) ** Obsolete normative reference: RFC 2304 (ref. '12') (Obsoleted by RFC 3192) ** Obsolete normative reference: RFC 2440 (ref. '13') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 1894 (ref. '14') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 1891 (ref. '15') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 2401 (ref. '18') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2302 (ref. '19') (Obsoleted by RFC 3302) ** Obsolete normative reference: RFC 2487 (ref. '20') (Obsoleted by RFC 3207) ** Downref: Normative reference to an Historic RFC: RFC 2311 (ref. '21') Summary: 22 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Toyoda 3 Internet Draft H. Ohno 4 February 26, 1999 J. Murai 5 Expires August 1999 WIDE Project 6 draft-ietf-fax-service-v2-00.txt D. Wing 7 Cisco 9 A Simple Mode of Facsimile Using Internet Mail 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), 16 its areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 31 This draft is a product of the IETF Internet Fax working group. To 32 subscribe to the mailing list, send a message to 33 ietf-fax-request@imc.org with the line "subscribe" in the body of the 34 message. Archives are available from . 36 Copyright Notice 38 Copyright (C) The Internet Society (1999). All Rights Reserved. 40 SUMMARY 42 This specification provides for "simple mode" carriage of facsimile 43 data over the Internet. Extensions to this document will follow. 44 The current specification employs standard protocols and file formats 45 such as TCP/IP, Internet mail protocols [1, 2, 3], MIME [4, 16, 17], 46 and TIFF for Facsimile [5,6,19]. It can send images not only to 47 other Internet-aware facsimile devices but also to Internet-native 48 systems, such as PCs with common email readers which can handle MIME 49 mail and TIFF for Facsimile data. The specification facilitates 50 communication among existing facsimile devices, Internet mail agents, 51 and the gateways which connect them. 53 The IETF has been notified of intellectual property rights claimed in 54 regard to some or all of the specification contained in this 55 document. For more information consult the online list of claimed 56 rights in . 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in [7]. 62 1 SCOPE 64 This specification defines a message-based facsimile communication 65 over the Internet. It describes a minimum set of capabilities, 66 taking into account those of typical facsimile devices and PCs that 67 can generate facsimile data. 69 A G3Fax device has substantial restrictions due to specifications in 70 the standards, such as for timers. This specification defines a 71 profile for Internet mail, rather than creating a distinct "facsimile 72 over the Internet" service. The semantics resulting from the profile 73 are designed to be compatible with facsimile operation over the 74 general switched telephone network, so that gateways between 75 facsimile and Internet mail can operate with very high fidelity. 77 The reason for developing this capability as an email profile is to 78 permit interworking amongst facsimile and email users. For example 79 it is intended that existing email users be able to send normal 80 messages to lists of users, including facsimile-based recipients, and 81 that other email recipients shall be able to reply to the original 82 and continue to include facsimile recipients. Similarly it is 83 intended that existing email software work without modification and 84 not be required to process new, or different data structures, beyond 85 what is normal for Internet mail users. Existing email service 86 standards are used, rather than replicating mechanisms which are more 87 tailored to existing facsimile standards, to ensure this 88 compatibility with existing email service. 90 1.1 Services 92 A facsimile-capable device that uses T.4 [8] and the general switched 93 telephone network (GSTN) is called a "G3Fax device" in this 94 specification. An "IFax device" is an Internet- accessible device 95 capable of sending, receiving or forwarding Internet faxes. A 96 message can be sent to an IFax device using an Internet mail 97 address. A message can be sent to a G3Fax device using an Internet 98 mail address; the message MAY be forwarded via an IFax offramp 99 gateway. 101 1.2 Cases 103 This specification provides for communication between each of the 104 following combinations: 105 Internet mail => Network printer 106 Internet mail => Offramp gateway (forward to 107 G3Fax) 108 Network scanner => Network printer 109 Network scanner => Offramp gateway (forward to 110 G3Fax) 111 Network scanner => Internet mail 113 2 COMMUNICATION PROTOCOLS 115 The set of conventions necessary to achieve facsimile- compatible 116 service covers basic data transport, document data formats, message 117 (document) addressing, delivery confirmation, and message security. 118 In this section, the first 4 are covered. The remainder are covered 119 in following sections, along with additional details for addressing 120 and formats. 122 2.1 Transport 124 This section describes mechanisms involved in the transport between 125 IFAX devices. 127 2.1.1 Relay 129 Data transfer MAY be achieved using standard Internet mail transfer 130 mechanisms[1, 3]. The format of addresses MUST conform to the RFC 131 821 and RFC 822 Internet mail standards [1, 2, 132 3]. 134 2.1.2 Gateway 136 A gateway translates between dissimilar environments. For IFax, a 137 gateway connects between Internet mail and the T.4/GSTN facsimile. 138 Gateways can service multiple T.4/GSTN facsimile users or can service 139 only one. In the former case, they serve as a classic "mail transfer 140 agent" (MTA) and in the latter as a classic "mail user agent" (UA). 142 An onramp is a gateway which connects from T.4/GSTN facsimile to 143 Internet mail. An offramp is a gateway which connects from Internet 144 mail to T.4/GSTN facsimile. Behavior of onramps is out of scope for 145 this specification. 147 This specification describes the Internet mail service portion of 148 offramp addressing, confirmation and failure notification. Details 149 are provided in later sections. 151 2.1.3 Mailbox protocols 153 An offramp gateway that operate as an MTA serving multiple users 154 SHOULD use SMTP; a gateway that operates as a UA serving a single 155 mail recipient MAY use a mailbox access protocol such as POP or IMAP 156 [9, 10]. 158 NOTE: An offramp gateway that relays mail based on addressing 159 information needs to ensure that it uses addresses supplied in the 160 MTA envelope, rather than from elsewhere, such as addresses listed in 161 the message content headers. 163 2.2 Formats 165 2.2.1 Headers 167 IFax devices MUST be compliant with RFC 822 and RFC1123, which define 168 the format of mail headers. The header of an IFax message SHOULD 169 include Message-ID and MUST include all fields required by [2, 3], 170 such as DATE and FROM. 172 2.2.2 MIME 174 IFax devices MUST be compliant with MIME [4], except as noted in 175 Appendix A. 177 2.2.3 Content 179 The data format of the facsimile image is based on the minimum set of 180 TIFF for Facsimile[6], also known as the S profile. Such facsimile 181 data are included in a MIME object by use of the image/TIFF sub-type 182 [19]. Additional rules for the use of TIFF for Facsimile, for the 183 message-based Internet facsimile application, are defined later. 185 2.2.4 Multipart 187 A single multi-page document SHOULD be sent as a single multi- page 188 TIFF file, even though recipients MUST process multipart/mixed 189 containing multiple TIFF files. If multipart content is present and 190 processing of any part fails, then processing for the entire message 191 is treated as failing, per [Processing failure] below. 193 2.3 Error Handling 195 2.3.1 Delivery failure 197 This section describes existing requirements for Internet mail, 198 rather than indicating special requirements for IFax devices. 200 In the event of relay failure, the sending relay MUST generate a 201 failure message, which SHOULD be in the format of a DSN. [14,15] 203 NOTE: Internet mail transported via SMTP MUST contain a MAIL 204 FROM address appropriate for delivery of return notices [Also 205 see section 5.2.6] 207 2.3.2 Processing failure 209 IFax devices with limited capabilities might be unable to process the 210 content of a message. If this occurs it is important to ensure that 211 the message is not lost without any notice. Notice MAY be provided in 212 any appropriate fashion, and the exact handling is a local matter. 213 (Also see Appendix A, second bullet.) 215 3 ADDRESSING 217 3.1 Classic Email Destinations 219 Messages being sent to normal Internet mail recipients will use 220 standard Internet mail addresses, without additional constraints. 222 3.2 G3Fax Devices 224 G3Fax devices are accessed via an IFAX offramp gateway, which 225 performs any authorized telephone dial-up. 227 3.3 Address Formats Used by Offramps 229 When a G3Fax device is identified by a telephone number, the entire 230 address used for the G3fax device, including the number and offramp 231 host reference MUST be contained within standard Internet mail 232 transport fields, such as RCPT TO and MAIL FROM [1, 3]. The address 233 MAY be contained within message content fields, such as 234 and [2, 3], as appropriate. 236 As for all Internet mail addresses, the left-hand-side (local- part) 237 of an address is not to be interpreted except by the MTA that is 238 named on the right-hand-side (domain). 240 The telephone number format SHOULD conform to [11, 12]. Other 241 formats MUST be syntactically distinct from [11, 12]. 243 4 IMAGE FILE FORMAT 245 Sending IFax devices MUST be able to write minimum set TIFF files, 246 per the rules for creating minimum set TIFF files defined in TIFF for 247 Facsimile (the S profile) [6], which is also compatible with the 248 specification for the minimum subset of TIFF-F in [5]. Receiving 249 IFax devices MUST be able to read minimum set TIFF files. 251 A sender SHOULD NOT use TIFF fields and values beyond the minimum 252 subset of TIFF for Facsimile unless the sender has prior knowledge of 253 other TIFF fields or values supported by the recipient. The 254 mechanism for determining capabilities of recipients is beyond the 255 scope of this document. 257 5 SECURITY CONSIDERATIONS 259 5.1 General Directive 261 This specification is based on use of existing Internet mail. To 262 maintain interoperability with Internet mail, any security to be 263 provided should be part of the of the Internet security 264 infrastructure, rather than a new mechanism or some other mechanism 265 outside of the Internet infrastructure. 267 5.2 Threats and Problems 269 Both Internet mail and G3Fax standards and operational services have 270 their own set of threats and countermeasures. This section attends 271 only to the set of additional threats which ensue from integrating 272 the two services. This section reviews relevant concerns about 273 Internet mail for IFax environments, as well as considering the 274 potential problems which can result of integrating the existing G3Fax 275 service with Internet mail. 277 5.2.1 Spoofed sender 279 The actual sender of the message might not be the same as that 280 specified in the Sender or From fields of the message content headers 281 or the MAIL FROM address from the SMTP envelope. 283 In a tightly constrained environment, sufficient physical and 284 software controls may be able to ensure prevention of this problem. 285 The usual solution is through encryption-based authentication, either 286 for the channel or associated with the object, as discussed below. 288 It should be recognized that SMTP implementations do not provide 289 inherent authentication of the senders of messages, nor are sites 290 under obligation to provide such authentication. End-to-end 291 approaches such as S/MIME and PGP/MIME are currently being developed 292 within the IETF. These technologies can provide such authentication. 294 5.2.2 Resources consumed by dialout 296 In addition to the resources normally consumed for email (CPU cycles 297 and disk), offramp facsimile causes an outdial which often imposes 298 significant resource consumption, such as financial cost. Techniques 300 for establishing authorization of the sender are essential to those 301 offramp facsimile services that need to manage such consumption. 303 Due to the consumption of these resources by dialout, unsolicited 304 bulk email which causes an outdial is undesirable. 306 Offramp gateways SHOULD provide the ability to authorize senders in 307 some manner to prevent unauthorized use of the offramp. There are no 308 standard techniques for authorization using Internet protocols. 310 Typical solutions use simple authentication of the originator to 311 establish and verify their identity and then check the identity 312 against a private authorization table. 314 Originator authentication entails the use of weak or strong 315 mechanisms, such as cleartext keywords or encryption-based data- 316 signing, respectively, to determine and validate the identify of the 317 sender and assess permissions accordingly. 319 Other control mechanisms which are common include source filtering 320 and originator authentication. Source filtering entails offramp 321 gateway verification of the host or network originating the message 322 and permitting or prohibiting relaying accordingly. 324 5.2.3 GSTN authorization information 326 Confidential information about the sender necessary to dial a G3Fax 327 recipient, such as sender's calling card authorization number, might 328 be disclosed to the G3Fax recipient (on the cover page), such as 329 through parameters encoded in the G3Fax recipients address in the To: 330 or CC: fields. 332 Senders SHOULD be provided with a method of preventing such 333 disclosure. As with mechanisms for handling unsolicited faxes, there 334 are not yet standard mechanisms for protecting such information. 335 Out-of-band communication of authorization information or use of 336 encrypted data in special fields are the available non-standard 337 techniques. 339 Typically authorization needs to be associated to specific senders 340 and specific messages, in order to prevent a "replay" attack which 341 causes and earlier authorization to enable a later dial-out by a 342 different (and unauthorized) sender. A non-malicious example of such 343 a replay would be to have an email recipient reply to all original 344 recipients -- including an offramp IFax recipient -- and have the 345 original sender's authorization cause the reply to be sent. 347 5.2.4 Sender accountability 349 In many countries, there is a legal requirement that the "sender" be 350 disclosed on a facsimile message. Email From addresses are trivial 351 to fake, so that using only the MAIL FROM [1, 3] or From [2, 3] 352 header is not sufficient. 354 Offramps SHOULD ensure that the recipient is provided contact 355 information about the offramp, in the event of problems. 357 The G3Fax recipient SHOULD be provided with sufficient information 358 which permits tracing the originator of the IFax message. Such 359 information might include the contents of the MAIL FROM, From, Sender 360 and Reply-To headers, as well as Message-Id and Received headers. 362 5.2.5 Message disclosure 364 Users of G3Fax devices have an expectation of a level of message 365 privacy which is higher than the level provided by Internet mail 366 without security enhancements. 368 This expectation of privacy by G3Fax users SHOULD be preserved as 369 much as possible. 371 Sufficient physical and software control may be acceptable in 372 constrained environments. The usual mechanism for ensuring data 373 confidentially entail encryption, as discussed below. 375 5.2.6 Non private mailboxes 377 With email, bounces (delivery failures) are typically returned to the 378 sender and not to a publicly-accessible email account or printer. 379 With facsimile, bounces do not typically occur. However, with IFax, 380 a bounce could be sent elsewhere (see section [Delivery Failure]), 381 such as a local system administrator's account, publicly-accessible 382 account, or an IFax printer (see also [Traffic Analysis]). 384 5.2.7 Traffic analysis 386 Eavesdropping of senders and recipients is easier on the Internet 387 than GSTN. Note that message object encryption does not prevent 388 traffic analysis, but channel security can help to frustrate attempts 389 at traffic analysis. 391 5.3 Security Techniques 393 There are two basic approaches to encryption-based security which 394 support authentication and privacy: 396 5.3.1 Channel security 398 As with all email, an IFax message can be viewed as it traverses 399 internal networks or the Internet itself. 401 Virtual Private Networks (VPN), IPSec [18], or transport layer 402 security [20], can be used to prevent eavesdropping of a message 403 as it traverses such networks. It also provides some protection 404 against traffic analysis, as described above. 406 5.3.2 Object security 408 As with all email, an IFax message can be viewed while it resides on, 409 or while it is relayed through, an intermediate Mail Transfer Agent. 411 Message encryption, such as PGP-MIME [13] and S/MIME [21], can be 412 used to provide end-to-end encryption. 414 6 REFERENCES 416 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 417 821, August 1982. 419 [2] Crocker, D., "Standard for the Format of ARPA Internet 420 Text Messages", STD 11, RFC 822, August l982. 422 [3] Braden, R., 1123 "Requirements for Internet hosts - 423 application and support", RFC 1123, October 1989. 425 [4] Borenstein, N., and N. Freed, " Multipurpose Internet 426 Mail Extensions (MIME) Part Five: Conformance Criteria and 427 Examples ", RFC 2049, November 1996. 429 [5] Parsons, G., and J. Rafferty, "Tag Image File Format 430 (TIFF) -- F Profile for Facsimile", RFC 2306, March 1998. 432 [6] McIntyre, L., Zilles, S., Buckley, R., Venable, D., 433 Parsons, G., and J. Rafferty, "File Format for Internet Fax", 434 RFC 2301, March 1998. 436 [7] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", RFC 2119, March 1997. 439 [8] ITU-T (CCITT), "Standardization of Group 3 facsimile 440 apparatus for document transmission", ITU-T (CCITT), 441 Recommendation T.4. 443 [9] Myers, J., and M. Rose, "Post Office Protocol - Version 444 3", STD 53, RFC 1939, May 1996. 446 [10] Crispin, M., "Internet Message Access Protocol - Version 447 4Rev1", RFC 2060, December 1996. 449 [11] Allocchio, C., "Minimal PSTN address format for Internet 450 mail", RFC 2303, March 1998. 452 [12] Allocchio, C., "Minimal fax address format for Internet 453 mail", RFC 2304, March 1998. 455 [13] Callas, J., Donnerhacke, L., Finney, H., and Thayer, R., 456 "OpenPGP Message Format", RFC 2440, November 1998 458 [14] Moore, K., and G. Vaudreuil, "An Extensible Message 459 Format for Delivery Status Notifications", RFC 1894, January 460 1996. 462 [15] Moore, K., "SMTP Service Extension for Delivery Status 463 Notifications", RFC 1891, January 1996. 465 [16] Freed, N., and N. Borenstein, "Multipurpose Internet 466 Mail Extensions (MIME) Part Two: Media Types", RFC 2046, 467 November 1996. 469 [17] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 470 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 471 November 1996. 473 [18] Kent, S. and Atkinson, R., "Security Architecture for the 474 Internet Protocol", RFC 2401, November 1998. 476 [19] Parsons, G. and Rafferty, J., "Tag Image File Format 477 (TIFF) -- image/TIFF: MIME Sub-type Registration", RFC 2302, 478 March 1998. 480 [20] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", 481 RFC 2487, January 1999. 483 [21] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and 484 L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, 485 March 1998. 487 7 ACKNOWLEDGEMENTS 489 This specification was produced by the Internet Engineering Task 490 Force Fax Working Group, over the course of more than one year's 491 online and face-to-face discussions. As with all IETF efforts, many 492 people contributed to the final product. 494 Active for this document were: Steve Huston, Jeffrey Perry, Greg 495 Vaudreuil, Richard Shockey, Charles Wu, Graham Klyne, Robert A. 496 Rosenberg, Larry Masinter, Dave Crocker, Herman Silbiger, James 497 Rafferty. 499 8 AUTHORS' ADDRESSES 501 Kiyoshi Toyoda 502 Matsushita Graphic Communication Systems, Inc. 503 2-3-8 Shimomeguro, Meguro-ku 504 Tokyo 153 Japan 505 Fax: +81 3 5434 7166 506 Email: ktoyoda@rdmg.mgcs.mei.co.jp 508 Hiroyuki Ohno 509 Tokyo Institute of Technology 510 2-12-1 O-okayama, Meguro-ku 511 Tokyo 152 Japan 512 FAX: +81 3 5734 2754 513 Email: hohno@is.titech.ac.jp 515 Jun Murai 516 Keio University 517 5322 Endo, Fujisawa 518 Kanagawa 252 Japan 519 Fax: +81 466 49 1101 520 Email: jun@wide.ad.jp 522 Dan Wing 523 Cisco Systems, Inc. 524 101 Cooper Street 525 Santa Cruz, CA 95060 USA 526 Phone: +1 831 457 5200 527 Fax: +1 831 457 5208 528 Email: dwing@cisco.com 530 9 APPENDIX A: Exceptions to MIME 532 * IFax senders are NOT REQUIRED to be able to send 533 text/plain messages (RFC 2049 requirement 4), although IFax 534 recipients are required to accept such messages, and to process 535 them. 537 * IFax recipients are NOT REQUIRED to offer to put results 538 in a file. (Also see 2.3.2.) 540 * IFax recipients MAY directly print/fax the received 541 message rather than "display" it, as indicated in RFC 2049.