idnits 2.17.1 draft-ietf-eai-imap-utf8-05.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 : ---------------------------------------------------------------------------- -- 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 22, 2009) is 5422 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'NOT-UTF-8' is mentioned on line 299, 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-05 Summary: 7 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 24, 2009 June 22, 2009 8 IMAP Support for UTF-8 9 draft-ietf-eai-imap-utf8-05 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 24, 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 . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 12.1. Normative References . . . . . . . . . . . . . . . . . . . 10 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. 168 IMAP servers MUST NOT accept UTF-8 characters when storing a new 169 message keyword, unless the mailbox is UTF-8 only, in which case IMAP 170 servers SHOULD accept UTF-8 in message keywords. 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 select-param =/ "UTF8" 203 C: a SELECT newmailbox (UTF8) 204 S: ... 205 S: a OK SELECT completed 206 C: b FETCH 1 (SIZE ENVELOPE BODY) 207 S: ... < UTF-8 header native results > 208 S: b OK FETCH completed 210 C: c EXAMINE legacymailbox (UTF8) 211 S: c NO [NOT-UTF-8] Mailbox does not support UTF-8 access 213 C: d SELECT funky-new-mailbox 214 S: d NO [UTF-8-ONLY] Mailbox requires UTF-8 client 216 3.3. UTF-8 LIST and LSUB Responses 218 After an IMAP client successfully issues an "ENABLE UTF8" command, 219 the server MUST NOT return in LIST results any mailbox names to the 220 client following the IMAP4 Mailbox International Naming Convention. 221 Instead, the server MUST return any mailbox names with characters 222 outside the US-ASCII repertorie using utf8-quoted syntax. (The IMAP4 223 Mailbox International Naming Convention has proved problematic in the 224 past, so the desire is to make this syntax obsolete as quickly as 225 possible.) 227 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions 229 When an IMAP server advertises both the "UTF8" capability and the 230 "LIST-EXTENEDED" [RFC5258] capability, the server MUST support the 231 LIST extensions described in this section. When an IMAP server 232 advertises the UTF8=ONLY capability and the LIST-EXTENDED capability, 233 the server MUST reject these LIST extensions with a BAD response. 235 3.4.1. UTF8 and UTF8ONLY LIST Selection Options 237 The UTF8 LIST selection option tells the server to include mailboxes 238 that only support UTF-8 headers in the output of the list command. 239 The UTF8ONLY LIST selection option tells the server to include all 240 mailboxes that support UTF-8 headers and to exclude mailboxes that 241 don't support UTF-8 headers. Note that UTF8ONLY implies UTF8 so it 242 is not necessary for the client to request both. Use of either 243 selection option will also result in UTF-8 mailbox names in the 244 result as described in Section 3.3. 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" / "UTF8ONLY" 263 mbox-list-oflag =/ "\NoUTF8" / "\UTF8Only" 265 return-option =/ "UTF8" 267 resp-text-code =/ "NOT-UTF-8" / "UTF-8-ONLY" 269 4. UTF8=APPEND Capability 271 If the UTF8=APPEND capability is advertised, then the server accepts 272 UTF-8 headers in the APPEND command message argument. A client which 273 sends a message with UTF-8 headers to the server MUST include the 274 UTF8 APPEND parameter. The ABNF for this APPEND parameter follows: 276 append-ext =/ "UTF8" 278 A server which advertises UTF8=APPEND has to comply with the 279 requirements of the IMAP base specification and [RFC5322] for message 280 fetching. Mechanisms for 7-bit downgrading to help comply with the 281 standards are discussed in Downgrading mechanism for 282 Internationalized eMail Address (IMA) [RFC5504]. 284 IMAP servers which do not advertise the UTF8=APPEND or UTF8=ONLY 285 capability SHOULD reject an APPEND command which includes any 8-bit 286 in the message headers with a "NO" response. 288 5. UTF8=USER Capability 290 If the UTF8=USER capability is advertised, that indicates the server 291 accepts UTF-8 user names and passwords and applies SASLprep [RFC4013] 292 to both arguments of the LOGIN command. The server MUST reject UTF-8 293 which fails to comply with the formal syntax in RFC 3629 [RFC3629]. 295 6. UTF8=ALL Capability 297 This capability indicates all server mailboxes support UTF-8 headers. 298 Specifically, SELECT and EXAMINE with the UTF8 parameter will never 299 fail with a [NOT-UTF-8] response token. 301 7. UTF8=ONLY Capability 303 This capability permits an IMAP server to advertise that it does not 304 support the international mailbox name convention (modified UTF-7), 305 and does not permit selection or examination of any mailbox unless 306 the UTF8 parameter is provided. As this is an incompatible change to 307 IMAP, a clear warning is necessary. IMAP clients which find 308 implementation of the UTF8 capability problematic are encouraged to 309 at least detect the UTF8=ONLY capability and provide an informative 310 error message to the end-user. 312 When an IMAP mailbox internally uses UTF-8 header native storage, the 313 down-conversion step necessary to permit selection or examination of 314 the mailbox in a backwards compatible fashion will become more 315 difficult to support. Although it is hoped deployed IMAP servers do 316 not advertise UTF8=ONLY for some years, this capability is intended 317 to minimize the disruption when legacy support finally goes away. 319 The UTF8=ONLY capability implies the UTF8 base capability, the 320 UTF8=ALL capability and the UTF8=APPEND capability. A server which 321 advertises UTF8=ONLY need not advertise the three implicit 322 capabilities. 324 8. Up-Conversion Server Requirements 326 When an IMAP4 server uses a traditional mailbox format that includes 327 7-bit headers and it chooses to permit access to that mailbox with 328 the UTF8 parameter, it MUST support minimal up-conversion as 329 described in this section. 331 The server MUST support up-conversion of the following address 332 header-fields in the message header: From, Sender, To, CC, Bcc, 333 Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and 334 Reply-To. This up-conversion MUST include address local-parts in 335 fields downgraded according to [RFC5504], address domains encoded 336 according to IDNA [RFC3490], and MIME header encoding [RFC2047] of 337 display-names and any [RFC5322] comments. 339 The following charsets MUST be supported for up-conversion of MIME 340 header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2, 341 ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, 342 ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15. 343 Other widely deployed MIME charsets SHOULD be supported. 345 Up-conversion of MIME header encoding of the following headers MUST 346 also be implemented: Subject, Date ([RFC5322] comments only), 347 Comments, Keywords, Content-Description. 349 Server implementations also SHOULD up-convert all MIME body headers, 350 SHOULD up-convert or remove the deprecated (and misused) name 351 parameter [RFC1341] on Content-Type and MUST up-convert the Content- 352 Disposition filename parameter. These parameters can be encoded 353 using the standard MIME parameter encoding [RFC2231] mechanism, or 354 via non-standard use of MIME header encoding [RFC2047] in quoted 355 strings. 357 The IMAP server MUST NOT perform up-conversion of headers and content 358 of multipart/signed, as well as Original-Recipient and Return-Path. 360 9. Issues with UTF-8 Header Mailstore 362 When an IMAP server uses a mailbox format that supports UTF-8 headers 363 and it permits selection or examination of that mailbox without the 364 UTF8 parameter, it is the responsibility of the server to comply with 365 the IMAP4rev1 [RFC3501] base specification and [RFC5322] with respect 366 to all header information transmitted over the wire. Mechanisms for 367 7-bit downgrading to help comply with the standards are discussed in 368 Downgrading mechanism for Internationalized eMail Address (IMA) 369 [RFC5504]. 371 An IMAP server with a mailbox that supports UTF-8 headers MUST comply 372 with the protocol requirements implicit from Section 8. However, the 373 code necessary for such compliance need not be part of the IMAP 374 server itself in this case. For example, the minimal required up- 375 conversion could be performed when a message is inserted into the 376 IMAP-accessible mailbox. 378 10. IANA Considerations 380 This adds five new capabilities ("UTF8", "UTF8=USER", "UTF8=APPEND", 381 "UTF8=ALL", "UTF8=ONLY") to the IMAP4rev1 capability registry 382 [RFC3501]. 384 This adds two new IMAP4 list selection options and one new IMAP4 list 385 return option. 387 1. LIST-EXTENDED option name: UTF8 389 LIST-EXTENDED option type: SELECTION 391 Implied return options(s): UTF8 393 LIST-EXTENDED option description: Causes the LIST response to 394 include mailboxes which mandate the UTF8 SELECT/EXAMINE 395 parameter. 397 Published specification: RFC XXXX, Section 3.4.1 399 Security considerations: RFC XXXX, Section 11 401 Intended usage: COMMON 403 Person an email address to contact for further information: see 404 Authors' Addresses at the end of this specification 406 Owner/Change controller: iesg@ietf.org 408 2. LIST-EXTENDED option name: UTF8ONLY 410 LIST-EXTENDED option type: SELECTION 412 Implied return options(s): UTF8 414 LIST-EXTENDED option description: Causes the LIST response to 415 include mailboxes which mandate the UTF8 SELECT/EXAMINE parameter 416 and exclude mailboxes which do not support the UTF8 SELECT/ 417 EXAMINE parameter. 419 Published specification: RFC XXXX, Section 3.4.1 421 Security considerations: RFC XXXX, Section 11 423 Intended usage: COMMON 425 Person an email address to contact for further information: see 426 Authors' Addresses at the end of this specification 428 Owner/Change controller: iesg@ietf.org 430 3. LIST-EXTENDED option name: UTF8 432 LIST-EXTENDED option type: RETURN 434 Implied return options(s): none 436 LIST-EXTENDED option description: Causes the LIST response to 437 include \NoUTF8 and \UTF8Only mailbox attributes. 439 Published specification: RFC XXXX, Section 3.4.1 441 Security considerations: RFC XXXX, Section 11 443 Intended usage: COMMON 445 Person an email address to contact for further information: see 446 Authors' Addresses at the end of this specification 448 Owner/Change controller: iesg@ietf.org 450 11. Security Considerations 452 The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] 453 apply to this specification, particularly with respect to use of 454 UTF-8 in user names and passwords. Otherwise, this is not believed 455 to alter the security considerations of IMAP4rev1. 457 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 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 506 Specifications: ABNF", STD 68, RFC 5234, January 2008. 508 [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access 509 Protocol version 4 - LIST Command Extensions", RFC 5258, 510 June 2008. 512 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 513 October 2008. 515 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, 516 September 2008. 518 [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for 519 Email Address Internationalization", RFC 5504, March 2009. 521 12.2. Informative References 523 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 524 Extensions (MIME) Part Five: Conformance Criteria and 525 Examples", RFC 2049, November 1996. 527 [RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 528 January 1997. 530 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 531 Languages", BCP 18, RFC 2277, January 1998. 533 [I-D.ietf-eai-pop] 534 Newman, C. and R. Gellens, "POP3 Support for UTF-8", 535 draft-ietf-eai-pop-05 (work in progress), November 2008. 537 Appendix A. Design Rationale 539 This non-normative section discusses the reasons behind some of the 540 design choices in the above specification. 542 The basic approach of advertising the ability to access a mailbox in 543 UTF-8 mode is intended to permit graceful upgrade, including servers 544 which support multiple mailbox formats. In particular, it would be 545 undesirable to force conversion of an entire server mailstore to 546 UTF-8 headers, so being able to phase-in support for new mailboxes 547 and gradually migrate old mailboxes is permitted by this design. 549 UTF8=USER is optional because many identity systems are US-ASCII 550 only, so it's helpful to inform the client up-front that UTF-8 won't 551 work. 553 UTF8=APPEND is optional because it effectively requires IMAP server 554 support for down-conversion which is a much more complex operation 555 than up-conversion. 557 The UTF8=ONLY mechanism simplifies diagnosis of interoperability 558 problems when legacy support goes away. In the situation where 559 backwards compatibility is broken anyway, just-send-UTF-8 IMAP has 560 the advantage that it might work with some legacy clients. However, 561 the difficulty of diagnosing interoperability problems caused by a 562 just-send-UTF-8 IMAP mechanism is the reason the UTF8=ONLY capability 563 mechanism was chosen. 565 The up-conversion requirements are designed to balance the desire to 566 deprecate and eventually eliminate complicated encodings (like MIME 567 header encodings) without creating a significant deployment burden 568 for servers. As IMAP4 servers already require a MIME parser, this 569 includes additional server up-conversion requirements not present in 570 POP3 Support for UTF-8 [I-D.ietf-eai-pop]. 572 The set of mandatory charsets comes from two sources: MIME 573 requirements [RFC2049] and IETF Policy on Character Sets [RFC2277]. 574 Including a requirement to up-convert widely deployed encoded 575 ideographic charsets to UTF-8 would be reasonable for most scenarios, 576 but may require unacceptable table sizes for some embedded devices. 577 The open-ended recommendation to support widely deployed charsets 578 avoids the political ramifications of attempting to list such 579 charsets. The authors believe market forces, existing open-source 580 software, and public conversion tables are sufficient to deploy the 581 appropriate charsets. 583 Appendix B. Acknowledgments 585 TBD. 587 Authors' Addresses 589 Pete Resnick 590 Qualcomm Incorporated 591 5775 Morehouse Drive 592 San Diego, CA 92121-1714 593 US 595 Phone: +1 858 651 4478 596 Email: presnick@qualcomm.com 597 URI: http://www.qualcomm.com/~presnick/ 599 Chris Newman 600 Sun Microsystems 601 3401 Centrelake Dr., Suite 410 602 Ontario, CA 91761 603 US 605 Email: chris.newman@sun.com