idnits 2.17.1 draft-ietf-eai-simpledowngrade-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 2012) is 4331 days in the past. Is this intentional? 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: 'DOWNGRADED 70' is mentioned on line 165, but not defined -- Looks like a reference, but probably isn't: '105' on line 165 -- Looks like a reference, but probably isn't: '108' on line 165 -- Looks like a reference, but probably isn't: '109' on line 165 -- Looks like a reference, but probably isn't: '1' on line 290 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5721 (Obsoleted by RFC 6856) -- Obsolete informational reference (is this intentional?): RFC 5738 (Obsoleted by RFC 6855) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Arnt Gulbrandsen 3 Internet-Draft June 2012 4 Intended Status: Proposed Standard 5 Updates: 3501 7 EAI: Simplified POP/IMAP downgrading 8 draft-ietf-eai-simpledowngrade-05.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Copyright (c) 2012 IETF Trust and the persons identified as the 16 document authors. All rights reserved. 18 This document is subject to BCP 78 and the IETF Trust's Legal 19 Provisions Relating to IETF Documents 20 (http://trustee.ietf.org/license-info) in effect on the date of 21 publication of this document. Please review these documents 22 carefully, as they describe your rights and restrictions with respect 23 to this document. Code Components extracted from this document must 24 include Simplified BSD License text as described in Section 4.e of 25 the Trust Legal Provisions and are provided without warranty as 26 described in the Simplified BSD License. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 40 Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft expires in November 2012. 45 Abstract 47 This document specifies a method for IMAP and POP servers to serve 48 internationalized messages to conventional clients. The specification 49 is simple, easy to implement and provides only rudimentary results. 51 1. Overview 53 It may happen that a conventional IMAP or POP client opens a mailbox 54 containing internationalized messages, or even attempt to read 55 internationalized messages, for instance when a user has both 56 internationalized and conventional MUAs. 58 Some operations cannot be performed by conventional clients. Most 59 importantly, one or more addresses on an internationalized message 60 are not valid according to the specifications the client uses, so 61 address-based operations are not possible. This includes displaying 62 the addresses, replying, and most types of address-based signature or 63 security processing. 65 Still, the sender's name, the message subject, body text and 66 attachments can easily be displayed, so a helpful IMAP/POP server may 67 prefer to provide access to what it can rather than hide the message 68 entirely. 70 This document specifies a way to present such messages to the client. 71 It values simplicity of implementation over fidelity of 72 representation, since implementing a high-fidelity downgrade 73 algorithm is likely more work than implementing proper support for 74 [RFC5721] and/or [RFC5738]. 76 The server is assumed to be internationalized internally, and to 77 store messages internationalized messages natively. When it needs to 78 present an internationalized message to a conventional client, it 79 synthesizes a conventional message containing most of the information 80 and presents that (the "synthetic message"). 82 2. Information preserved and lost 84 The synthetic message is intended to convey the most important 85 information to the user. Where information is lost, the user should 86 see the message as incomplete rather than modified. 88 The synthetic message is not intended to convey any information to 89 the client software. 91 Upper case in examples represents non-ASCII. example.com is a plain 92 domain, EXAMPLE.com represents a non-ASCII .com domain. 94 2.1 Email addresses 96 Each internationalized email address in the header fields listed 97 below is replaced with an invalid email address whose display-name 98 tells the user what happened. 100 The format of the display-name is explicitly unspecified. Anything 101 which tells the user what happened is good. Anything which produces 102 an email address which might belong to someone else is bad. 104 Given an internationalized address "Fred Foo ", an 105 implementation may choose to render it e.g. as these examples: 107 "fred@EXAMPLE.com" 108 Fred Foo 109 internationalized-address:; 110 fred:; 112 (The .invalid top-level domain is reserved by [RFC2606], therefore 113 the first two examples are syntactically valid, but will never belong 114 to anyone. Note that the display-name often will need [RFC2047] 115 encoding.) 117 The affected header fields are Bcc, Cc, From, Reply-To, Resent-Bcc, 118 Resent-Cc, Resent-From, Resent-Sender, Resent-To, Return-Path, Sender 119 and To. Any addresses present in other header fields are not 120 regarded as addresses by this specification. 122 2.2 MIME parameters 124 Any MIME parameter [RFC2045] (whether in the message header or a 125 bodypart header) which cannot be presented as-is to the client is 126 silently excised. 128 Given a field such as 130 Content-Disposition: attachment; filename=FOO 132 the field is presented as 134 Content-Disposition: attachment 136 2.3 "Subject" 138 If the Subject field cannot be presented as-is, the server presents a 139 representation encoded as specified in [RFC2047]. 141 2.4 Remaining header fields 143 Any header field which cannot be presented to the client even after 144 the modifications in sections 2.1-2.3 is silently excised. 146 3. IMAP-specific details 148 IMAP allows clients to retrieve the message size without downloading 149 it, using RFC822.SIZE, BODY.SIZE[] and so on. [RFC3501] requires that 150 the returned size be exact. 152 This specification relaxes that requirement: When a conventional 153 client requests size information for a message, the IMAP server is 154 permitted to return size information for the internationalized 155 message, even though the synthetic message's size differs. 157 When an IMAP server carries out downgrading as part of generating 158 nFETCH responses, it reports which messages were synthesised using a 159 response code and attendant UID set. This can be helpful to humans 160 debugging the server and/or client. 162 C: a UID FETCH 1:* BODY.PEEK[HEADER.FIELDS(To From Cc)] 163 S: 1 FETCH (UID 65 [...] 164 S: 2 FETCH (UID 70 [...] 165 S: a OK [DOWNGRADED 70,105,108,109] Done 167 The message-set argument to DOWNGRADED contains UIDs. 169 Note that DOWNGRADED does not necessarily mention all the 170 internationalized messages in the mailbox. In the example above, we 171 know that UID 65 does not contain internationalized addresses in 172 From, To and Cc. It may contain an internationalized Subject, etc. 174 4. POP-specific details 176 The number of lines specified in the TOP command (see [RFC1939]) 177 refers to the synthetic message. The message size reported by e.g. 178 LIST may refer to either the internationalized or the synthetic 179 message. 181 5. Security Considerations 183 If the internationalized message contains signed body parts, the 184 synthetic message probably contains an invalid signature. This is a 185 necessary limitation of displaying internationalized messages in 186 conventional clients, since the client does not support 187 internationalized addresses. 189 If any excised information is significant, then that information does 190 not arrive at the recipient. Notably, the message-id, in-reference-to 191 and/or references fields may be excised, which might cause a lack of 192 context when the recipient reads the message. 194 Some POP/IMAP clients delete the original message and use only the 195 what they downloaded, Fetchmail is one well-known example. This may 196 lead to permament loss of information. 198 Other clients cache messages for a very long time, even across client 199 upgrades, such as the stock Android client. When such a client is 200 internationalized, care must be taken so that it will not use an old 201 synthetic message from its cache rather than retrieve the real 202 message from the server. 204 6. Acknowledgements 206 Claudio Allocchio, Ned Freed, Kazunori Fujiwara, Ted Hardie, Barry 207 Leiba, John Levine, Alexey Melnikov, Chris Newman, Joseph Yee and the 208 originator of rule 12 in [RFC1925] helped with this document. 210 7. IANA Considerations 212 The IANA is requested to add DOWNGRADED to the IMAP response code 213 registry. 215 (RFC editor: Please remove this paragraph. I can't remember the URL 216 of the registry, but it's the one specified in RFC 5530.) 218 8. Normative References 220 [RFC1939] Myers, J and M. Rose, "Post Office Protocol - Version 3", 221 RFC 1939, Carnegie Mellon, May 1996. 223 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 224 Extensions (MIME) Part One: Format of Internet Message 225 Bodies", RFC 2045, November 1996. 227 [RFC2047] Moore, "MIME (Multipurpose Internet Mail Extensions) Part 228 Three: Message Header Extensions for Non-ASCII Text", RFC 229 2047, University of Tennessee, November 1996. 231 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 232 Names", BCP 32, RFC 2606, June 1999. 234 [RFC3501] Crispin, "Internet Message Access Protocol - Version 235 4rev1", RFC 3501, University of Washington, June 2003. 237 9. Informative References 239 [RFC1925] Callon, R., "Fundamental Truths of Networking", RFC 1925, 240 Bay Networks, April 1996. 242 [RFC5721] Gellens, R., and C. Newman, "POP3 Support for UTF-8", RFC 243 5721, Qualcomm Incorporated, February 2010. 245 [RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8", RFC 246 5738, Qualcomm Incorporated, March 2010. 248 10. Author's Address 250 Arnt Gulbrandsen 251 Schweppermannstr. 8 252 D-81671 Muenchen 253 Germany 255 Fax: +49 89 4502 9758 257 Email: arnt@gulbrandsen.priv.no 258 (RFC Editor: Please delete everything after this point) 260 Open Issues 262 Should Kazunori Fujiwara's downgrade document also mention 263 DOWNGRADED? 265 RFC Editor: IF 5721 and/or 5738 have been superseded by new RFCs at 266 this time, please change the references to those RFCs throughout this 267 document. Well, except in the previous sentence. I'm such a pedant. 269 Changes since -00 271 Added a rule to handle Subject 273 Removed the sentence about unknown:; 275 Terminology fixes 277 Changes since -01 279 Nits from Joseph Yee. 281 Clarified the address rendering and added non-.invalid examples, 282 based on suggestions from Kazunori Fujiwara. 284 Many changes from Barry Leiba: Simplified and better terminology, 285 reformatted examples, more references, etc. 287 Specified POP TOP. A bit of a no-op specification. 289 Mention BODY.SIZE[] as well as RFC822.SIZE. Wave hands so 290 BODY.SIZE[1] sneaks past. 292 http://rant.gulbrandsen.priv.no/good-bad-rfc fwiw 294 Changes since -02 296 Added the DOWNGRADED response code, since both Barry and Alexey wants 297 it. 299 Changes since -03 300 Added/changed text in response to appsdir reviews from Ted Hardie and 301 Claudio Allocchio. 303 Changes since -04 305 Closed two open issues; the interest in them was clearly negligible. 307 "Updates: 3501" because of the SIZE relaxation. 309 Security considerations about download-and-delete and long-term 310 caching. 312 Bring on the WGLC!