idnits 2.17.1 draft-ietf-eai-simpledowngrade-07.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 (August 2012) is 4266 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 173, but not defined -- Looks like a reference, but probably isn't: '105' on line 173 -- Looks like a reference, but probably isn't: '108' on line 173 -- Looks like a reference, but probably isn't: '109' on line 173 -- Looks like a reference, but probably isn't: '1' on line 306 ** 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 August 2012 4 Intended Status: Proposed Standard 5 Updates: 3501 7 Simplified POP/IMAP Downgrading for Internationalized Email 8 draft-ietf-eai-simpledowngrade-07.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 January 2013. 45 Internet-draft August 2012 47 Abstract 49 This document specifies a method for IMAP and POP servers to serve 50 internationalized messages to conventional clients. The specification 51 is simple, easy to implement and provides only rudimentary results. 53 1. Overview 55 It may happen that a conventional IMAP or POP client opens a mailbox 56 containing internationalized messages, or even attempt to read 57 internationalized messages, for instance when a user has both 58 internationalized and conventional MUAs. 60 Some operations cannot be performed by conventional clients. Most 61 importantly, an internationalized message usually contains at least 62 one internationalized address, so address-based operations are only 63 rarely possible. This includes displaying the addresses, replying, 64 and most types of address-based signature or security processing. 66 Still, the sender's name, the message subject, body text and 67 attachments can easily be displayed, so a helpful IMAP/POP server may 68 prefer to provide access to what it can rather than hide the message 69 entirely. 71 This document specifies a way to present such messages to the client. 72 It values simplicity of implementation over fidelity of 73 representation, since implementing a high-fidelity downgrade 74 algorithm is likely more work than implementing proper support for 75 [RFC5721] and/or [RFC5738]. 77 The server is assumed to be internationalized internally, and to 78 store messages internationalized messages natively. When it needs to 79 present an internationalized message to a conventional client, it 80 synthesizes a conventional message containing most of the information 81 and presents that (the "synthetic message"). 83 2. Information preserved and lost 85 The synthetic message is intended to convey the most important 86 information to the user. Where information is lost, the user should 87 see the message as incomplete rather than modified. 89 The synthetic message is not intended to convey any information to 90 the client software that would require or enable it to apply special 91 handling to the message. Client authors who wish to handle 92 internationalized messages are encouraged to implement [RFC5738]. 94 Internet-draft August 2012 96 Upper case in examples represents non-ASCII. example.com is a plain 97 domain, EXAMPLE.com represents a non-ASCII domain in the .com top- 98 level domain. 100 2.1 Email addresses 102 Each internationalized email address in the header fields listed 103 below is replaced with an invalid email address whose display-name 104 tells the user what happened. 106 The format of the display-name is explicitly unspecified. Anything 107 which tells the user what happened is good. Anything which produces 108 an email address which might belong to someone else is bad. 110 Given an internationalized address "Fred Foo ", an 111 implementation may choose to render it e.g. as these examples: 113 "fred@EXAMPLE.com" 114 Fred Foo 115 internationalized-address:; 116 fred:; 118 (The .invalid top-level domain is reserved by [RFC2606], therefore 119 the first two examples are syntactically valid, but will never belong 120 to anyone. Note that the display-name often will need [RFC2047] 121 encoding.) 123 The affected header fields are Bcc, Cc, From, Reply-To, Resent-Bcc, 124 Resent-Cc, Resent-From, Resent-Sender, Resent-To, Return-Path, Sender 125 and To. Any addresses present in other header fields, such as 126 Received, are not regarded as addresses by this specification. 128 2.2 MIME parameters 130 Any MIME parameter [RFC2045] (whether in the message header or a 131 bodypart header) which cannot be presented as-is to the client is 132 silently excised. 134 Given a field such as 136 Content-Disposition: attachment; filename=FOO 138 the field is presented as 140 Content-Disposition: attachment 142 Internet-draft August 2012 144 2.3 "Subject" 146 If the Subject field cannot be presented as-is, the server presents a 147 representation encoded as specified in [RFC2047]. 149 2.4 Remaining header fields 151 Any header field which cannot be presented to the client even after 152 the modifications in sections 2.1-2.3 is silently excised. 154 3. IMAP-specific details 156 IMAP allows clients to retrieve the message size without downloading 157 it, using RFC822.SIZE, BODY.SIZE[] and so on. [RFC3501] requires that 158 the returned size be exact. 160 This specification relaxes that requirement: When a conventional 161 client requests size information for a message, the IMAP server is 162 permitted to return size information for the internationalized 163 message, even though the synthetic message's size differs. 165 When an IMAP server carries out downgrading as part of generating 166 FETCH responses, it reports which messages were synthesised using a 167 response code and attendant UID set. This can be helpful to humans 168 debugging the server and/or client. 170 C: a UID FETCH 1:* BODY.PEEK[HEADER.FIELDS(To From Cc)] 171 S: 1 FETCH (UID 65 [...] 172 S: 2 FETCH (UID 70 [...] 173 S: a OK [DOWNGRADED 70,105,108,109] Done 175 The message-set argument to DOWNGRADED contains UIDs. 177 Note that DOWNGRADED does not necessarily mention all the 178 internationalized messages in the mailbox. In the example above, we 179 know that UID 65 does not contain internationalized addresses in 180 From, To and Cc. It may contain an internationalized Subject, etc. 182 4. POP-specific details 184 The number of lines specified in the TOP command (see [RFC1939]) 185 refers to the synthetic message. The message size reported by e.g. 186 LIST may refer to either the internationalized or the synthetic 187 message. 189 Internet-draft August 2012 191 5. Security Considerations 193 If the internationalized message uses any sort of signature, the 194 synthetic message's signature almost certainly is invalid. This is a 195 necessary limitation of displaying internationalized messages in 196 conventional clients, since the client does not support 197 internationalized addresses. 199 If any excised information is significant, then that information does 200 not arrive at the recipient. Notably, the Message-Id, In-Reference-To 201 and References fields may be excised, which might cause a lack of 202 context when the recipient reads the message. 204 Some POP or IMAP clients, such as Fetchmail, download messages and 205 delete the version on the server. This may lead to permanent loss of 206 information when the only remaining version of a message is the 207 synthetic message. 209 Other clients cache messages for a very long time, even across client 210 upgrades, such as the stock Android client. When such a client is 211 internationalized, care must be taken so that it will not use an old 212 synthetic message from its cache rather than retrieve the real 213 message from the server. 215 6. Acknowledgements 217 Claudio Allocchio, Ned Freed, Kazunori Fujiwara, Ted Hardie, John 218 Klensin, Barry Leiba, John Levine, Alexey Melnikov, Chris Newman, 219 Joseph Yee and the originator of rule 12 in [RFC1925] helped with 220 this document. 222 7. IANA Considerations 224 The IANA is requested to add DOWNGRADED to the IMAP Response Code 225 registry. 227 8. Normative References 229 [RFC1939] Myers, J and M. Rose, "Post Office Protocol - Version 3", 230 RFC 1939, May 1996. 232 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 233 Extensions (MIME) Part One: Format of Internet Message 234 Bodies", RFC 2045, November 1996. 236 Internet-draft August 2012 238 [RFC2047] Moore, "MIME (Multipurpose Internet Mail Extensions) Part 239 Three: Message Header Extensions for Non-ASCII Text", RFC 240 2047, November 1996. 242 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 243 Names", BCP 32, RFC 2606, June 1999. 245 [RFC3501] Crispin, "Internet Message Access Protocol - Version 246 4rev1", RFC 3501, June 2003. 248 9. Informative References 250 [RFC1925] Callon, R., "Fundamental Truths of Networking", RFC 1925, 251 April 1996. 253 [RFC5721] Gellens, R., and C. Newman, "POP3 Support for UTF-8", RFC 254 5721, February 2010. 255 [RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8", RFC 256 5738, March 2010. 258 10. Author's Address 260 Arnt Gulbrandsen 261 Schweppermannstr. 8 262 D-81671 Muenchen 263 Germany 265 Fax: +49 89 4502 9758 267 Email: arnt@gulbrandsen.priv.no 269 Internet-draft August 2012 271 (RFC Editor: Please delete everything after this point) 273 Open Issues 275 Should Kazunori Fujiwara's downgrade document also mention 276 DOWNGRADED? 278 RFC Editor: IF 5721 and/or 5738 have been superseded by new RFCs at 279 this time, please change the references to those RFCs throughout this 280 document. Well, except in the previous sentence. I'm such a pedant. 282 RFC Editor: I do not know the difference between that and which. Will 283 and shall outnumber me too. Please fix all that. Thank you. 285 Changes since -00 287 Added a rule to handle Subject 289 Removed the sentence about unknown:; 291 Terminology fixes 293 Changes since -01 295 Nits from Joseph Yee. 297 Clarified the address rendering and added non-.invalid examples, 298 based on suggestions from Kazunori Fujiwara. 300 Many changes from Barry Leiba: Simplified and better terminology, 301 reformatted examples, more references, etc. 303 Specified POP TOP. A bit of a no-op specification. 305 Mention BODY.SIZE[] as well as RFC822.SIZE. Wave hands so 306 BODY.SIZE[1] sneaks past. 308 http://rant.gulbrandsen.priv.no/good-bad-rfc fwiw 310 Changes since -02 312 Added the DOWNGRADED response code, since both Barry and Alexey wants 313 it. 315 Internet-draft August 2012 317 Changes since -03 319 Added/changed text in response to appsdir reviews from Ted Hardie and 320 Claudio Allocchio. 322 Changes since -04 324 Closed two open issues; the interest in them was clearly negligible. 326 "Updates: 3501" because of the SIZE relaxation. 328 Security considerations about download-and-delete and long-term 329 caching. 331 Bring on the WGLC! 333 Changes since -05 335 Text changes from John Klensin 337 Changes since -06 339 Text changes from Barry Leiba. I hate case sensitivity in human 340 language, but right now I need to pack my suitcases, not argue.