idnits 2.17.1 draft-ietf-fax-eifax-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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 253 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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. ** 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 ([SERVICE]), 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) == Unused Reference: 'GOALS' is defined on line 200, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-ietf-fax-service is -04, but you're referring to -05. ** Obsolete normative reference: RFC 1894 (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 1891 (Obsoleted by RFC 3461) -- Unexpected draft version: The latest known version of draft-ietf-receipt-mdn is -07, but you're referring to -08. -- Unexpected draft version: The latest known version of draft-ietf-fax-tiffplus is -07, but you're referring to -08. == Outdated reference: A later version (-03) exists of draft-ietf-conneg-feature-reg-00 == Outdated reference: A later version (-05) exists of draft-ietf-conneg-media-features-00 -- Possible downref: Normative reference to a draft: ref. 'MDN-FEATURES' == Outdated reference: A later version (-04) exists of draft-ietf-fax-smtp-session-02 -- Possible downref: Normative reference to a draft: ref. 'SESSION' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSN-EXTENSIONS' == Outdated reference: A later version (-07) exists of draft-ietf-openpgp-formats-01 == Outdated reference: A later version (-08) exists of draft-ietf-smime-msg-02 == Outdated reference: A later version (-12) exists of draft-myers-smtp-auth-11 == 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 822 (ref. 'RFC974') (Obsoleted by RFC 2822) Summary: 14 errors (**), 0 flaws (~~), 12 warnings (==), 8 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 March 13, 1998 08:53PST Dan Wing 4 Expires August 1998 Cisco Systems 5 draft-ietf-fax-eifax-00.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 learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 This draft is being discussed by the IETF FAX working group. To 28 subscribe to the mailing list, send a message to 29 ietf-fax-request@imc.org with the line "subscribe" in the body of 30 the message. Archives are available from 31 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" [SERVICE] to accomplish additional features, 41 including transmission enhanced faxes (higher resolution, color), 42 confirmation of delivery, quick message delivery, GSTN billing 43 information and message confidentiality. 45 1. Introduction 47 This document notes a number of enhancements to the "Simple Mode of 48 Facsimile Using Internet Mail" [SERVICE] that may be combined to 49 create an extended mode of facsimile using Internet mail: 51 * Delivery confirmation (Section 2) 52 * Additional document features (Section 3) 53 * Quick delivery and confirmation (Section 4) 54 * GSTN billing information (Section 5) 55 * Confidentiality (Section 6) 56 * Cover sheet generation (Section 7) 58 A device which supports all of these recommendations is called an 59 EIFax (Extended Internet Fax) device. 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 2. Delivery Confirmation 67 In Internet Mail, the operations of Delivery (to the mailbox) and 68 Disposition (to paper or a screen) may be separated in time and 69 location. The confirmation of these two operations are supplied by 70 Delivery Status Notifications [RFC1891, RFC1894] and Message 71 Disposition Notifications [MDN] respectively. 73 An EIFax sender MAY request either DSN or MDN, or both. 75 An EIFax recipient that performs message delivery MUST provide DSN 76 [RFC1891]; an EIFax recipient that performs message disposition 77 MUST support the return of Message Disposition Notifications [MDN]. 79 3. Additional document features 81 [SERVICE] requires that a sender must not send documents with 82 features beyond those supported by the S profile of [TIFF], unless 83 the capabilities of the recipient are known. To extend [SERVICE] to 84 allow sending of other document features, a mechanism by which the 85 sender can determine additional recipient capabilities is 86 necessary. 88 Recipient capabilities to handle document features are described 89 using media features as described in [FEATURES]; media features 90 appropriate for facsimile are established in [MEDIA]. Other 91 features (for private extensions by particular manufacturers, for 92 example) MAY also be registered and used. 94 3.1 Message Disposition Notification Extension 96 EIFax recipients SHOULD implement [MDN-FEATURES]; this returns to 97 the sender the recipient's features as part of the message 98 disposition notification. 100 EIFax senders MAY retain a local cache of information about the 101 features supported by recipients. When an EIFax device sends a 102 message to a specific recipient, it MAY use cached information to 103 determine the recipient's capabilities to handle extended document 104 features, such as the ability to handle additional TIFF profiles, 105 media size and resolution, or document formats. 107 4. Quick Delivery and Confirmation 109 [SESSION] describes a method by which delivery confirmation may be 110 delivered quickly, if there is a simultaneous connection between 111 sender and recipient. EIFax devices SHOULD implement 112 [SESSION]. Intermediate MTAs, e.g., as part of firewalls, MAY also 113 act as [SESSION] gateways, allowing for immediate delivery, with 114 fallback to store-and-forward. 116 EIFax devices MAY implement standard Internet mail routing using 117 the domain name system [RFC974]. EIFax devices MAY be SMTP 118 recipients registered as the primary mail exchanger for their 119 domain. This combination will allow the sending EIFax device to 120 communicate directly with the recipient device. 122 5. GSTN Billing Information 124 [SERVICE] recommends that an offramp gateway servicing multiple 125 mailboxes use SMTP as its protocol. 127 To provide billing information for the offramp service back to the 128 originator of a message, the offramp gateway SHOULD implement 129 [DSN-EXTENSIONS]. 131 6. Confidentiality 133 The user perception of GSTN-based fax is that it is secure, and faxes 134 are used to send many confidential documents. In order to provide 135 the same level of confidentiality for fax over email, even better 136 levels of security are necessary due to the nature of email and the 137 threats of snooping. 139 6.1 Content 141 p To secure the contents of the message itself, EIFax devices SHOULD 142 implement S/MIME [SMIME] or PGP-MIME [PGPMIME] or both. 144 6.2 Envelope 146 To secure the envelope itself, EIFax devices should implement [AUTH]. 148 7. References 150 [SERVICE] K.Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of 151 Facsimile Using Internet Mail", draft-ietf-fax-service-05.txt, Feb 152 1998. 154 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 155 Requirement Levels", RFC 2119, March 1997. 157 [RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for 158 Delivery Status Notifications", RFC 1894, January 1996 160 [RFC1891] K. Moore, "SMTP Service Extensions for Delivery Status 161 Notifications", RFC 1891, January 1996. 163 [MDN] R. Fajman, "An Extensible Message Format for Message 164 Disposition Notifications", draft-ietf-receipt-mdn-08.txt, Feb 165 1998. 167 [TIFF] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, 168 J. Rafferty, "File Format for Internet Fax", 169 draft-ietf-fax-tiffplus-08.txt, Feb 1998. 171 [FEATURES] K. Holtman, A. Mutz, T. Hardie, "Feature Tag 172 Registration Procedures", draft-ietf-conneg-feature-reg-00.txt, 173 March 1998. 175 [MEDIA] "Media Features for Display, Print, and Fax", L. Masinter, 176 K. Holtman, A. Mutz, D. Wing. 177 draft-ietf-conneg-media-features-00.txt, March 1998. 179 [MDN-FEATURES] L. Masinter and D. Wing, "Using Message Disposition 180 Notifications to Indicate Supported Features", 181 draft-ietf-fax-mdn-features-01.txt, March 1998. 183 [SESSION] N. Joffe, D. Wing, L. Masinter, "SMTP Service Extension 184 for Immediate Delivery", draft-ietf-fax-smtp-session-02.txt, Feb 185 1998. 187 [DSN-EXTENSIONS] D. Wing. "Extensions to Delivery Status Notifications 188 for Fax", November, 1997. 190 [PGPMIME] J. Calls, L. Donnerhacke, H. Finney, R. Thayer. "OP 191 Formats - OpenPGP Message Format", 192 draft-ietf-openpgp-formats-01.txt, March 1998. 194 [SMIME] B. Ramsdell. "S/MIME Version 3 Message Specification", 195 draft-ietf-smime-msg-02.txt, March, 1998. 197 [AUTH] J. Myers, "SMTP Service Extension for Authentication", 198 draft-myers-smtp-auth-11.txt, February 1998. 200 [GOALS] L. Masinter, "Terminology and Goals for Internet Fax", 201 draft-ietf-fax-goals-02.txt, March 1998. 203 [RFC974] C. Partridge. "Mail routing and the domain system", 204 RFC 822, January 1986. 206 8. Authors' Addresses 208 Larry Masinter 209 Xerox Palo Alto Research Center 210 3333 Coyote Hill Road 211 Palo Alto, CA 94304 USA 212 Fax: +1 415 812 4333 213 EMail: masinter@parc.xerox.com 215 Dan Wing 216 Cisco Systems, Inc. 217 101 Cooper Street 218 Santa Cruz, CA 95060 USA 219 Phone: +1 408 457 5200 220 Fax: +1 408 457 5208 221 EMail: dwing@cisco.com 223 Copyright 225 Copyright (C) The Internet Society 1998. All Rights Reserved. 227 This document and translations of it may be copied and furnished to 228 others, and derivative works that comment on or otherwise explain it 229 or assist in its implementation may be prepared, copied, published 230 and distributed, in whole or in part, without restriction of any 231 kind, provided that the above copyright notice and this paragraph are 232 included on all such copies and derivative works. However, this 233 document itself may not be modified in any way, such as by removing 234 the copyright notice or references to the Internet Society or other 235 Internet organizations, except as needed for the purpose of 236 developing Internet standards in which case the procedures for 237 copyrights defined in the Internet Standards process must be 238 followed, or as required to translate it into languages other than 239 English. 241 The limited permissions granted above are perpetual and will not be 242 revoked by the Internet Society or its successors or assigns. 244 This document and the information contained herein is provided on an 245 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 246 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 247 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 248 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 249 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.