idnits 2.17.1 draft-ietf-fax-mdn-features-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 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 2 characters in excess of 72. ** The abstract seems to contain references ([FEATURES], [MDN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 134: '...receiving system SHOULD update feature...' RFC 2119 keyword, line 145: '... mail user agent SHOULD send the messa...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 236 has weird spacing: '...for the purpo...' -- 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: 'MEDIA-FEATURES' is defined on line 209, but no explicit reference was found in the text == Unused Reference: 'RFC822' is defined on line 217, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 220, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'FEATURES' -- No information found for draft-masinter-media-features - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MEDIA-FEATURES' -- No information found for draft-ietf-receipt-mdn-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MDN' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Applications Area Dan Wing 2 Internet Draft Cisco Systems 3 March 10, 1998 Larry Masinter 4 Expires August 1998 Xerox Corporation 6 Using Message Disposition Notifications to 7 Indicate Supported Features 9 draft-ietf-fax-mdn-features-01.txt 11 Status of this memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Copyright Notice 31 Copyright (C) The Internet Society (1998). All Rights Reserved. 33 Abstract 35 This document describes how Message Disposition Notifications [MDN] 36 are used to indicate the supported features of a user's Mail User 37 Agent (MUA). Knowing the supported features of a recipient or the 38 recipient's MUA allows a sender to generate messages which take 39 advantage of those features. 41 Features indicate the MIME content-types are supported by the 42 Mail User Agent, or finer gradations of features such as 43 resolution, maximum image size, or software version number. 44 The representation of features is still under discussion in 45 the CONNEG working group. 47 Features are registered using the framework described in [FEATURES]. 49 1. Introduction 51 In an open email environment, such as the Internet, it is not generally 52 possible to know, a priori, if a recipient will be able to process 53 certain enhanced forms of a message. Because of this, only 7-bit 54 text/plain messages can be assumed to be readable by unknown Internet 55 mail user agents. Even with MIME-aware user agents, some messages 56 are still not usable by some recipients (for example, a viewer or 57 a decryption package may be necessary). 59 Currently, the only method available to indicate the ability 60 to receive certain file formats is for a human to indicate 61 this ability out-of-band ("Yes, I can receive PowerPoint" 62 in an email message or telephone call). Likewise, the only method 63 available to indicate inability to process a certain file is via a 64 similar manual method. 66 Message Disposition Notifications (MDNs) can be used to automate the 67 sending of recipient features. As most people communicate often 68 with co-workers, vendors, and collegues, constant exchange of 69 messages already occurs. 71 Message Disposition Notifications (MDNs) can be used to exchange 72 information between mail user agents. This information can indicate 73 user and system preferences and features, as described in [FEATURES]. 75 Because disposition notifications are communicated end-to-end, they 76 do not require new infrastructure in the email environment that are 77 required by other methods of communicating recipient features such as 78 white page directory entries or SMTP extensions. 80 1.1. Discussion of this Draft 82 This draft is being discussed by the IETF FAX working group. To 83 subscribe to the mailing list, send a message to 84 ietf-fax-request@imc.org with the line "subscribe" in the body of the 85 message. Archives are available from http://www.imc.org/ietf-fax. 87 2. Determining Supported Features 89 Any request for a disposition notification [MDN] can also cause a 90 list of features to be sent in that same disposition notification 91 message. 93 2.1. Including Features in MDNs 95 If the receiving user agent decides to send a disposition 96 notification message per [MDN] it can include the new field described 97 below in the disposition notification message. 99 To indicate features, the receiving user agent includes the 100 following new extension field 101 [MDN]. The syntax of this new field, using the Augmented BNF of 102 [ABNF], is: 104 extension-field = "Features" ":" ttl-value ";" 105 feature 106 *( "," [ LWSP ] feature ) 108 ttl-value = seconds ; maximum number of seconds from 109 ; Date: header of this message 110 ; that receiver should believe 111 ; the feature information is 112 ; still accurate 114 seconds = 1*DIGIT 116 feature = 118 Long headers should be folded [RFC822, section 3.1.1]. 120 3. Processing of Feature Information 122 3.1. TTL value 124 The TTL value indicates the maximum number of seconds the receiving 125 system can expect the list of features to be valid. The TTL value is 126 calculated from the Date: header of the disposition notification 127 message. 129 To avoid caching features for excessively long or short periods, the 130 receiving system may minimize or maximize the TTL value. On a 131 production system, a lower bound of 5 minutes and an upper bound on 132 one week would be reasonable. 134 The receiving system SHOULD update feature information and the 135 associated TTL whenever new features are obtained. 137 Originating mail user agents may wish to use expired feature 138 information, but are encouraged to follow the recommendations 139 in section 3.3. 141 3.2. Unlisted features 142 If a sender's mail user agent has cached the features of a certain 143 recipient, and wishes to send a message which exceeds the 144 previously-cached list of features for the recipient, originating 145 mail user agent SHOULD send the message only after informing the 146 user. 148 For example, if the following features are cached: 150 web=mozilla4; tiff=f 152 and the sender wishes to send application/pdf (which is not 153 supported by either of the above features), the originating mail user 154 agent would inform the user that the recipient may not be able to 155 process the message. A sophisticated mail user agent may 156 follow the recommendations in section 3.3. 158 3.3. Unknown Features 160 If no feature information for a recipient is available, the sender 161 should send a message that has a reasonable chance of being processed 162 by a recipient, or send a multipart/alternative message containing 163 "dumbed-down" versions of the same content. 165 A message that has a "reasonable chance" should be user configurable, 166 as what is "reasonable" is dependant on the user's experience, 167 knowledge of the recipient's software or recipient user's expertise, 168 and other factors. 170 4. Security Considerations 172 In addition to the security considerations discussed in [MDN], 173 this memo creates other security risks, listed below. 175 4.1. Disclosure of Preferences 177 In many cases it is undesirable to disclose certain preferences 178 for things such as language or accessibility. XXX - more verbage 180 4.2. Spoofed Feature Information 182 During the design of mail user agents, it should be remembered 183 that the cached feature information could be incorrect 184 due to a malicious MDN. Because of this, the user should be provided 185 with a mechanism to send a message which exceeds the recipient's 186 cached features. 188 4.3. Macro Viruses 189 Macro Viruses [reference?] are a widespread problem among 190 applications such as word processors and spreadsheets. Knowing which 191 featuers a user's Mail User Agent supports can assist in a malicious 192 attack. However, such viruses can be spread easily without such 193 knowledge by sending multiple messages, and each message infects a 194 specific application version. 196 5. Acknowledgments 198 Thanks to the members of the IETF FAX and CONNEG Working Groups, and 199 especially to Graham Klyne (Integralis) for their assistance with 200 the developement of this document. 202 6. References 204 [ABNF] Crocker, D., and P. Overell, "Augmented BNF for Syntax 205 Specifications: ABNF", RFC 2234, November 1997. 207 [FEATURES] IETF Conneg WG, Work in Progress. 209 [MEDIA-FEATURES] Masinter, L., Holtman, K., and D. Wing, "Media 210 Features for Display, Print, and Fax", Work in Progress, 211 Internet Draft, draft-masinter-media-features-02.txt. 213 [MDN] Fajman, R., "An Extensible Message Format for Message 214 Disposition Notifications", Work in Progress, Internet Draft, 215 draft-ietf-receipt-mdn-XX.txt (soon to be Proposed Standard). 217 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet 218 Text Messages", RFC 822, STD 11, August 1982. 220 [RFC2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail 221 Extensions (MIME) Part One: Format of Internet Message Bodies", 222 RFC 2045, November 1996. 224 7. Copyright 226 Copyright (C) The Internet Society 1998. All Rights Reserved. 228 This document and translations of it may be copied and furnished to 229 others, and derivative works that comment on or otherwise explain it 230 or assist in its implmentation may be prepared, copied, published and 231 distributed, in whole or in part, without restriction of any kind, 232 provided that the above copyright notice and this paragraph are 233 included on all such copies and derivative works. However, this 234 document itself may not be modified in any way, such as by removing 235 the copyright notice or references to the Internet Society or other 236 Internet organizations, except as needed for the purpose of 237 developing Internet standards in which case the procedures for 238 copyrights defined in the Internet Standards process must be 239 followed, or as required to translate it into languages other than 240 English. 242 The limited permissions granted above are perpetual and will not be 243 revoked by the Internet Society or its successors or assigns. 245 This document and the information contained herein is provided on an 246 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 247 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 248 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 249 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 250 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 252 8. Authors' Addresses 254 Dan Wing 255 Cisco Systems, Inc. 256 101 Cooper Street 257 Santa Cruz, CA 95060 USA 259 Phone: +1 408 457 5200 260 Fax: +1 408 457 5208 261 EMail: dwing@cisco.com 263 Larry Masinter 264 Xerox Palo Alto Research Center 265 3333 Coyote Hill Road 266 Palo Alto, CA 94304 USA 268 Fax: +1 415 812 4333 269 EMail: masinter@parc.xerox.com 271 A. Examples 273 A.1. MDN with Features Included 275 This example shows an MDN with the new "Features" field 276 included. 278 Date: Fri, 5 Dec 1997 14:03:06 (PST) -0800 279 From: Joe Recipient > 280 Message-Id: <19971205.14030618@hq.cisco.com> 281 Subject: Disposition notification 282 To: Jane Sender 283 MIME-Version: 1.0 284 Content-Type: multipart/report; boundary="NextPart"; 285 report-type=disposition-notification; 287 --NextPart 289 Your message sent on Friday, 5 Dec 1997 at 14:00 to 290 Joe Recipient with the subject 291 "Hello there" has been displayed. This is no guarantee 292 that the message has been read or understood. 294 --NextPart 295 Content-Type: message/disposition-notification 297 Reporting-UA: hq.cisco.com; MultiNet 298 Original-Recipient: rfc822;Joe_Recipient@cisco.com 299 Final-Recipient: rfc822;Joe_Recipient@hq.cisco.com 300 Original-Message-ID: <19971205.140123@yoyodyne.com> 301 Disposition: manual-action/MDN-sent-manually; displayed 302 Original-Content-ID: <19971205.140000.813@yoyodyne.com> 303 Features: web=mozilla4; tiff=faxbw; microsoft=word5,word95,excel 305 --NextPart 306 Content-Type: message/rfc822 308 [original message goes here] 310 --NextPart--