idnits 2.17.1 draft-ietf-eai-imap-utf8-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 14 characters in excess of 72. -- The draft header indicates that this document updates RFC3501, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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). (Using the creation date from RFC3501, updated by this document, for RFC5378 checks: 1997-09-12) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2009) is 5418 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'NOT-UTF-8' is mentioned on line 301, but not defined == Missing Reference: 'UTF-8-ONLY' is mentioned on line 254, but not defined == Unused Reference: 'RFC2045' is defined on line 466, but no explicit reference was found in the text == Unused Reference: 'RFC2183' is defined on line 477, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1341 (Obsoleted by RFC 1521) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 5335 (Obsoleted by RFC 6532) ** Obsolete normative reference: RFC 5504 (Obsoleted by RFC 6530) -- Obsolete informational reference (is this intentional?): RFC 2088 (Obsoleted by RFC 7888) == Outdated reference: A later version (-09) exists of draft-ietf-eai-pop-06 Summary: 8 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 P. Resnick 3 Internet-Draft Qualcomm Incorporated 4 Updates: 3501 (if approved) C. Newman 5 Intended status: Experimental Sun Microsystems 6 Expires: December 27, 2009 June 25, 2009 8 IMAP Support for UTF-8 9 draft-ietf-eai-imap-utf8-06 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on December 27, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This specification extends the Internet Message Access Protocol 58 version 4rev1 (IMAP4rev1) to support unencoded international 59 characters in user names, mail addresses and message headers. This 60 is an early draft and intended as a framework for discussion. Please 61 do not deploy implementations of this draft. 63 Table of Contents 65 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. UTF8 IMAP Capability . . . . . . . . . . . . . . . . . . . . . 3 68 3.1. IMAP UTF-8 Quoted Strings . . . . . . . . . . . . . . . . 3 69 3.2. UTF8 Parameter to SELECT and EXAMINE . . . . . . . . . . . 4 70 3.3. UTF-8 LIST and LSUB Responses . . . . . . . . . . . . . . 5 71 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions . . . 6 72 3.4.1. UTF8 and UTF8ONLY LIST Selection Options . . . . . . . 6 73 3.4.2. UTF8 LIST Return Option . . . . . . . . . . . . . . . 6 74 4. UTF8=APPEND Capability . . . . . . . . . . . . . . . . . . . . 6 75 5. UTF8=USER Capability . . . . . . . . . . . . . . . . . . . . . 7 76 6. UTF8=ALL Capability . . . . . . . . . . . . . . . . . . . . . 7 77 7. UTF8=ONLY Capability . . . . . . . . . . . . . . . . . . . . . 7 78 8. Up-Conversion Server Requirements . . . . . . . . . . . . . . 8 79 9. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 8 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 84 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 85 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 12 86 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Conventions Used in this Document 91 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 92 in this document are to be interpreted as defined in "Key words for 93 use in RFCs to Indicate Requirement Levels" [RFC2119]. 95 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] 96 notation including the core rules defined in Appendix B of RFC 4234. 97 In addition, rules from IMAP4rev1 [RFC3501], UTF-8 [RFC3629], 98 Collected extensions to IMAP4 ABNF [RFC4466], and IMAP4 LIST Command 99 Extensions [RFC5258] are also referenced. 101 In examples, "C:" and "S:" indicate lines sent by the client and 102 server respectively. If a single "C:" or "S:" label applies to 103 multiple lines, then the line breaks between those lines are for 104 editorial clarity only and are not part of the actual protocol 105 exchange. 107 2. Introduction 109 This specification extends IMAP4rev1 [RFC3501] to permit unencoded 110 UTF-8 [RFC3629] in headers as described in Internationalized Email 111 Headers [RFC5335]. It also adds a mechanism to support mailbox 112 names, login names and passwords using the UTF-8 charset. 114 3. UTF8 IMAP Capability 116 The basic "UTF8" capability indicates the server supports UTF-8 117 quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8 118 responses from the LIST and LSUB commands. 120 A client MUST use the "ENABLE UTF8" command (defined in [RFC5161]) to 121 indicate to the server that the client accepts UTF-8 quoted-strings. 122 The "ENABLE UTF8" command MUST only be used in the authenticated 123 state. 125 3.1. IMAP UTF-8 Quoted Strings 127 The IMAP4rev1 [RFC3501] base specification forbids the use of 8-bit 128 characters in atoms or quoted strings. Thus a UTF-8 string can only 129 be sent as a literal. This can be inconvenient from a coding 130 standpoint, and unless the server offers IMAP4 non-synchronizing 131 literals [RFC2088], this requires an extra round trip for each UTF-8 132 string sent by the client. When the IMAP server advertises the 133 "UTF8" capability, it informs the client that it supports native 134 UTF-8 quoted-strings with the following syntax: 136 string =/ utf8-quoted 138 utf8-quoted = "*" DQUOTE *UQUOTED-CHAR DQUOTE 140 UQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4 141 ; UTF8-2, UTF8-3, and UTF8-4 are as defined in RFC 3629 143 When this quoting mechanism is used by the client (specifically an 144 octet sequence beginning with *" and ending with "), then the server 145 MUST reject octet sequences with the high bit set which fail to 146 comply with the formal syntax in [RFC3629] with a BAD response. 148 The IMAP server MUST NOT send utf8-quoted syntax to the client unless 149 the client has indicated support for that syntax by using the "ENABLE 150 UTF8" command. 152 If the UTF8 capability is advertised, then utf8-quoted syntax MAY be 153 used with any IMAP argument that permits a string or an astring. 154 However, if characters outside the US-ASCII repertoire are used in an 155 inappropriate place, the results would be the same as if other 156 syntacticly valid but semantically invalid characters were used. For 157 example, if the client includes UTF-8 characters in the user or 158 password arguments (and the server has not advertised UTF8-USER), the 159 LOGIN command will fail as it would with any other invalid user name 160 or password. Specific cases where UTF-8 characters are permitted or 161 not permitted are described in the following paragraphs. 163 All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP 164 servers which support the "Mailbox International Naming Convention" 165 described in RFC 3501 section 5.1.3 MUST accept utf8-quoted mailbox 166 names and convert them to the appropriate internal format. Mailbox 167 names must comply with the Net-Unicode Definition (section 2 of 168 [RFC5198]) with the specific exception that they may not contain 169 control characters (0000-001F, 0080-009F), delete (007F), line 170 separator (2028) or paragraph separator (2029). 172 If an IMAP client issues a SEARCH command which uses a mixture of 173 utf8-quoted syntax and a SEARCH CHARSET other than UTF-8, then the 174 IMAP server SHOULD reject the command with a BAD response (due to the 175 conflicting charset labels). 177 3.2. UTF8 Parameter to SELECT and EXAMINE 179 The "UTF8" capability also indicates the server supports the UTF8 180 parameter to SELECT and EXAMINE. When a mailbox is selected with the 181 UTF8 parameter, it alters the behavior of all IMAP commands related 182 to message sizes, message headers and MIME body headers so they refer 183 to the message with UTF-8 headers. If the mailstore is not UTF-8 184 header native and the SELECT or EXAMINE command with UTF-8 header 185 modifier succeeds, then the server MUST return results as if the 186 mailstore was UTF-8 header native with upconversion requirements as 187 described in Section 8. The server MAY reject the SELECT or EXAMINE 188 command with the [NOT-UTF-8] response code, unless the UTF8=ALL or 189 UTF8=ONLY capability is advertised. 191 Servers MAY include mailboxes which can only be selected or examined 192 if the UTF8 parameter is provided. However, such mailboxes MUST NOT 193 be included in the output of an unextended LIST, LSUB or equivalent 194 command. If a client attempts to SELECT or EXAMINE such mailboxes 195 without the UTF8 parameter, the server MUST reject the command with a 196 [UTF-8-ONLY] response code. As a result, such mailboxes will not 197 accessible by IMAP clients written prior to this specification and 198 are discouraged unless the server advertises UTF8=ONLY or the server 199 implements IMAP4 LIST Command Extensions [RFC5258]. 201 utf8-select-param = "UTF8" 202 ;; Conforms to from RFC 4466 204 C: a SELECT newmailbox (UTF8) 205 S: ... 206 S: a OK SELECT completed 207 C: b FETCH 1 (SIZE ENVELOPE BODY) 208 S: ... < UTF-8 header native results > 209 S: b OK FETCH completed 211 C: c EXAMINE legacymailbox (UTF8) 212 S: c NO [NOT-UTF-8] Mailbox does not support UTF-8 access 214 C: d SELECT funky-new-mailbox 215 S: d NO [UTF-8-ONLY] Mailbox requires UTF-8 client 217 3.3. UTF-8 LIST and LSUB Responses 219 After an IMAP client successfully issues an "ENABLE UTF8" command, 220 the server MUST NOT return in LIST results any mailbox names to the 221 client following the IMAP4 Mailbox International Naming Convention. 222 Instead, the server MUST return any mailbox names with characters 223 outside the US-ASCII repertorie using utf8-quoted syntax. (The IMAP4 224 Mailbox International Naming Convention has proved problematic in the 225 past, so the desire is to make this syntax obsolete as quickly as 226 possible.) 228 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions 230 When an IMAP server advertises both the "UTF8" capability and the 231 "LIST-EXTENEDED" [RFC5258] capability, the server MUST support the 232 LIST extensions described in this section. 234 3.4.1. UTF8 and UTF8ONLY LIST Selection Options 236 The UTF8 LIST selection option tells the server to include mailboxes 237 that only support UTF-8 headers in the output of the list command. 238 The UTF8ONLY LIST selection option tells the server to include all 239 mailboxes that support UTF-8 headers and to exclude mailboxes that 240 don't support UTF-8 headers. Note that UTF8ONLY implies UTF8 so it 241 is not necessary for the client to request both. Use of either 242 selection option will also result in UTF-8 mailbox names in the 243 result as described in Section 3.3 and implies the UTF8 List return 244 option described in Section 3.4.2. 246 3.4.2. UTF8 LIST Return Option 248 If the client supplies the UTF8 LIST return option, then the server 249 MUST include either the \NoUTF8 or the \UTF8Only mailbox attribute as 250 appropriate. The \NoUTF8 mailbox attribute indicates an attempt to 251 SELECT or EXAMINE that mailbox with the UTF8 parameter will fail with 252 a [NOT-UTF-8] response code. The \UTF8Only mailbox attribute 253 indicates an attempt to SELECT or EXAMINE that mailbox without the 254 UTF8 parameter will fail with a [UTF-8-ONLY] response code. Note 255 that computing this information may be expensive on some server 256 implementations so this return option should not be used unless 257 necessary. 259 The ABNF [RFC5234] for these LIST extensions follows: 261 list-select-independent-opt =/ "UTF8" 263 list-select-base-opt =/ "UTF8ONLY" 265 mbx-list-oflag =/ "\NoUTF8" / "\UTF8Only" 267 return-option =/ "UTF8" 269 resp-text-code =/ "NOT-UTF-8" / "UTF-8-ONLY" 271 4. UTF8=APPEND Capability 273 If the UTF8=APPEND capability is advertised, then the server accepts 274 UTF-8 headers in the APPEND command message argument. A client which 275 sends a message with UTF-8 headers to the server MUST include the 276 UTF8 APPEND parameter. The ABNF for this APPEND parameter follows: 278 append-ext =/ "UTF8" 280 A server which advertises UTF8=APPEND has to comply with the 281 requirements of the IMAP base specification and [RFC5322] for message 282 fetching. Mechanisms for 7-bit downgrading to help comply with the 283 standards are discussed in Downgrading mechanism for 284 Internationalized eMail Address (IMA) [RFC5504]. 286 IMAP servers which do not advertise the UTF8=APPEND or UTF8=ONLY 287 capability SHOULD reject an APPEND command which includes any 8-bit 288 in the message headers with a "NO" response. 290 5. UTF8=USER Capability 292 If the UTF8=USER capability is advertised, that indicates the server 293 accepts UTF-8 user names and passwords and applies SASLprep [RFC4013] 294 to both arguments of the LOGIN command. The server MUST reject UTF-8 295 which fails to comply with the formal syntax in RFC 3629 [RFC3629]. 297 6. UTF8=ALL Capability 299 This capability indicates all server mailboxes support UTF-8 headers. 300 Specifically, SELECT and EXAMINE with the UTF8 parameter will never 301 fail with a [NOT-UTF-8] response token. 303 7. UTF8=ONLY Capability 305 This capability permits an IMAP server to advertise that it does not 306 support the international mailbox name convention (modified UTF-7), 307 and does not permit selection or examination of any mailbox unless 308 the UTF8 parameter is provided. As this is an incompatible change to 309 IMAP, a clear warning is necessary. IMAP clients which find 310 implementation of the UTF8 capability problematic are encouraged to 311 at least detect the UTF8=ONLY capability and provide an informative 312 error message to the end-user. 314 When an IMAP mailbox internally uses UTF-8 header native storage, the 315 down-conversion step necessary to permit selection or examination of 316 the mailbox in a backwards compatible fashion will become more 317 difficult to support. Although it is hoped deployed IMAP servers do 318 not advertise UTF8=ONLY for some years, this capability is intended 319 to minimize the disruption when legacy support finally goes away. 321 The UTF8=ONLY capability implies the UTF8 base capability, the 322 UTF8=ALL capability and the UTF8=APPEND capability. A server which 323 advertises UTF8=ONLY need not advertise the three implicit 324 capabilities. 326 8. Up-Conversion Server Requirements 328 When an IMAP4 server uses a traditional mailbox format that includes 329 7-bit headers and it chooses to permit access to that mailbox with 330 the UTF8 parameter, it MUST support minimal up-conversion as 331 described in this section. 333 The server MUST support up-conversion of the following address 334 header-fields in the message header: From, Sender, To, CC, Bcc, 335 Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and 336 Reply-To. This up-conversion MUST include address local-parts in 337 fields downgraded according to [RFC5504], address domains encoded 338 according to IDNA [RFC3490], and MIME header encoding [RFC2047] of 339 display-names and any [RFC5322] comments. 341 The following charsets MUST be supported for up-conversion of MIME 342 header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2, 343 ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, 344 ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15. 345 Other widely deployed MIME charsets SHOULD be supported. 347 Up-conversion of MIME header encoding of the following headers MUST 348 also be implemented: Subject, Date ([RFC5322] comments only), 349 Comments, Keywords, Content-Description. 351 Server implementations also SHOULD up-convert all MIME body headers, 352 SHOULD up-convert or remove the deprecated (and misused) name 353 parameter [RFC1341] on Content-Type and MUST up-convert the Content- 354 Disposition filename parameter. These parameters can be encoded 355 using the standard MIME parameter encoding [RFC2231] mechanism, or 356 via non-standard use of MIME header encoding [RFC2047] in quoted 357 strings. 359 The IMAP server MUST NOT perform up-conversion of headers and content 360 of multipart/signed, as well as Original-Recipient and Return-Path. 362 9. Issues with UTF-8 Header Mailstore 364 When an IMAP server uses a mailbox format that supports UTF-8 headers 365 and it permits selection or examination of that mailbox without the 366 UTF8 parameter, it is the responsibility of the server to comply with 367 the IMAP4rev1 [RFC3501] base specification and [RFC5322] with respect 368 to all header information transmitted over the wire. Mechanisms for 369 7-bit downgrading to help comply with the standards are discussed in 370 Downgrading mechanism for Internationalized eMail Address (IMA) 371 [RFC5504]. 373 An IMAP server with a mailbox that supports UTF-8 headers MUST comply 374 with the protocol requirements implicit from Section 8. However, the 375 code necessary for such compliance need not be part of the IMAP 376 server itself in this case. For example, the minimal required up- 377 conversion could be performed when a message is inserted into the 378 IMAP-accessible mailbox. 380 10. IANA Considerations 382 This adds five new capabilities ("UTF8", "UTF8=USER", "UTF8=APPEND", 383 "UTF8=ALL", "UTF8=ONLY") to the IMAP4rev1 capability registry 384 [RFC3501]. 386 This adds two new IMAP4 list selection options and one new IMAP4 list 387 return option. 389 1. LIST-EXTENDED option name: UTF8 391 LIST-EXTENDED option type: SELECTION 393 Implied return options(s): UTF8 395 LIST-EXTENDED option description: Causes the LIST response to 396 include mailboxes which mandate the UTF8 SELECT/EXAMINE 397 parameter. 399 Published specification: RFC XXXX, Section 3.4.1 401 Security considerations: RFC XXXX, Section 11 403 Intended usage: COMMON 405 Person an email address to contact for further information: see 406 Authors' Addresses at the end of this specification 408 Owner/Change controller: iesg@ietf.org 410 2. LIST-EXTENDED option name: UTF8ONLY 412 LIST-EXTENDED option type: SELECTION 413 Implied return options(s): UTF8 415 LIST-EXTENDED option description: Causes the LIST response to 416 include mailboxes which mandate the UTF8 SELECT/EXAMINE parameter 417 and exclude mailboxes which do not support the UTF8 SELECT/ 418 EXAMINE parameter. 420 Published specification: RFC XXXX, Section 3.4.1 422 Security considerations: RFC XXXX, Section 11 424 Intended usage: COMMON 426 Person an email address to contact for further information: see 427 Authors' Addresses at the end of this specification 429 Owner/Change controller: iesg@ietf.org 431 3. LIST-EXTENDED option name: UTF8 433 LIST-EXTENDED option type: RETURN 435 Implied return options(s): none 437 LIST-EXTENDED option description: Causes the LIST response to 438 include \NoUTF8 and \UTF8Only mailbox attributes. 440 Published specification: RFC XXXX, Section 3.4.1 442 Security considerations: RFC XXXX, Section 11 444 Intended usage: COMMON 446 Person an email address to contact for further information: see 447 Authors' Addresses at the end of this specification 449 Owner/Change controller: iesg@ietf.org 451 11. Security Considerations 453 The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] 454 apply to this specification, particularly with respect to use of 455 UTF-8 in user names and passwords. Otherwise, this is not believed 456 to alter the security considerations of IMAP4rev1. 458 12. References 459 12.1. Normative References 461 [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 462 Mail Extensions): Mechanisms for Specifying and Describing 463 the Format of Internet Message Bodies", RFC 1341, 464 June 1992. 466 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 467 Extensions (MIME) Part One: Format of Internet Message 468 Bodies", RFC 2045, November 1996. 470 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 471 Part Three: Message Header Extensions for Non-ASCII Text", 472 RFC 2047, November 1996. 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, March 1997. 477 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 478 Presentation Information in Internet Messages: The 479 Content-Disposition Header Field", RFC 2183, August 1997. 481 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 482 Word Extensions: 483 Character Sets, Languages, and Continuations", RFC 2231, 484 November 1997. 486 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 487 "Internationalizing Domain Names in Applications (IDNA)", 488 RFC 3490, March 2003. 490 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 491 4rev1", RFC 3501, March 2003. 493 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 494 10646", STD 63, RFC 3629, November 2003. 496 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 497 and Passwords", RFC 4013, February 2005. 499 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 500 ABNF", RFC 4466, April 2006. 502 [RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE 503 Extension", RFC 5161, March 2008. 505 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 506 Interchange", RFC 5198, March 2008. 508 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 509 Specifications: ABNF", STD 68, RFC 5234, January 2008. 511 [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access 512 Protocol version 4 - LIST Command Extensions", RFC 5258, 513 June 2008. 515 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 516 October 2008. 518 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, 519 September 2008. 521 [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for 522 Email Address Internationalization", RFC 5504, March 2009. 524 12.2. Informative References 526 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 527 Extensions (MIME) Part Five: Conformance Criteria and 528 Examples", RFC 2049, November 1996. 530 [RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 531 January 1997. 533 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 534 Languages", BCP 18, RFC 2277, January 1998. 536 [I-D.ietf-eai-pop] 537 Gellens, R. and C. Newman, "POP3 Support for UTF-8", 538 draft-ietf-eai-pop-06 (work in progress), June 2009. 540 Appendix A. Design Rationale 542 This non-normative section discusses the reasons behind some of the 543 design choices in the above specification. 545 The basic approach of advertising the ability to access a mailbox in 546 UTF-8 mode is intended to permit graceful upgrade, including servers 547 which support multiple mailbox formats. In particular, it would be 548 undesirable to force conversion of an entire server mailstore to 549 UTF-8 headers, so being able to phase-in support for new mailboxes 550 and gradually migrate old mailboxes is permitted by this design. 552 UTF8=USER is optional because many identity systems are US-ASCII 553 only, so it's helpful to inform the client up-front that UTF-8 won't 554 work. 556 UTF8=APPEND is optional because it effectively requires IMAP server 557 support for down-conversion which is a much more complex operation 558 than up-conversion. 560 The UTF8=ONLY mechanism simplifies diagnosis of interoperability 561 problems when legacy support goes away. In the situation where 562 backwards compatibility is broken anyway, just-send-UTF-8 IMAP has 563 the advantage that it might work with some legacy clients. However, 564 the difficulty of diagnosing interoperability problems caused by a 565 just-send-UTF-8 IMAP mechanism is the reason the UTF8=ONLY capability 566 mechanism was chosen. 568 The up-conversion requirements are designed to balance the desire to 569 deprecate and eventually eliminate complicated encodings (like MIME 570 header encodings) without creating a significant deployment burden 571 for servers. As IMAP4 servers already require a MIME parser, this 572 includes additional server up-conversion requirements not present in 573 POP3 Support for UTF-8 [I-D.ietf-eai-pop]. 575 The set of mandatory charsets comes from two sources: MIME 576 requirements [RFC2049] and IETF Policy on Character Sets [RFC2277]. 577 Including a requirement to up-convert widely deployed encoded 578 ideographic charsets to UTF-8 would be reasonable for most scenarios, 579 but may require unacceptable table sizes for some embedded devices. 580 The open-ended recommendation to support widely deployed charsets 581 avoids the political ramifications of attempting to list such 582 charsets. The authors believe market forces, existing open-source 583 software, and public conversion tables are sufficient to deploy the 584 appropriate charsets. 586 Appendix B. Acknowledgments 588 TBD. 590 Authors' Addresses 592 Pete Resnick 593 Qualcomm Incorporated 594 5775 Morehouse Drive 595 San Diego, CA 92121-1714 596 US 598 Phone: +1 858 651 4478 599 Email: presnick@qualcomm.com 600 URI: http://www.qualcomm.com/~presnick/ 601 Chris Newman 602 Sun Microsystems 603 3401 Centrelake Dr., Suite 410 604 Ontario, CA 91761 605 US 607 Email: chris.newman@sun.com