idnits 2.17.1 draft-ietf-eai-imap-utf8-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (November 30, 2009) is 5259 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'NOT-UTF-8' is mentioned on line 326, but not defined == Missing Reference: 'UTF-8-ONLY' is mentioned on line 267, but not defined ** 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) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Email Address Internationalization P. Resnick 3 Internet-Draft Qualcomm Incorporated 4 Updates: 3501 (if approved) C. Newman 5 Intended status: Experimental Sun Microsystems 6 Expires: June 3, 2010 November 30, 2009 8 IMAP Support for UTF-8 9 draft-ietf-eai-imap-utf8-09 11 Abstract 13 This specification extends the Internet Message Access Protocol 14 version 4rev1 (IMAP4rev1) to support UTF-8 encoded international 15 characters in user names, mail addresses and message headers. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 3, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 70 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. UTF8=ACCEPT IMAP Capability . . . . . . . . . . . . . . . . . 3 72 3.1. IMAP UTF-8 Quoted Strings . . . . . . . . . . . . . . . . 3 73 3.2. UTF8 Parameter to SELECT and EXAMINE . . . . . . . . . . . 5 74 3.3. UTF-8 LIST and LSUB Responses . . . . . . . . . . . . . . 5 75 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions . . . 6 76 3.4.1. UTF8 and UTF8ONLY LIST Selection Options . . . . . . . 6 77 3.4.2. UTF8 LIST Return Option . . . . . . . . . . . . . . . 6 78 4. UTF8=APPEND Capability . . . . . . . . . . . . . . . . . . . . 7 79 5. UTF8=USER Capability . . . . . . . . . . . . . . . . . . . . . 7 80 6. UTF8=ALL Capability . . . . . . . . . . . . . . . . . . . . . 7 81 7. UTF8=ONLY Capability . . . . . . . . . . . . . . . . . . . . . 8 82 8. Up-Conversion Server Requirements . . . . . . . . . . . . . . 8 83 9. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 9 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 88 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 89 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 13 90 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Conventions Used in this Document 95 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 96 in this document are to be interpreted as defined in "Key words for 97 use in RFCs to Indicate Requirement Levels" [RFC2119]. 99 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] 100 notation including the core rules defined in Appendix B of [RFC5234]. 101 In addition, rules from IMAP4rev1 [RFC3501], UTF-8 [RFC3629], 102 Collected extensions to IMAP4 ABNF [RFC4466], and IMAP4 LIST Command 103 Extensions [RFC5258] are also referenced. 105 In examples, "C:" and "S:" indicate lines sent by the client and 106 server respectively. If a single "C:" or "S:" label applies to 107 multiple lines, then the line breaks between those lines are for 108 editorial clarity only and are not part of the actual protocol 109 exchange. 111 2. Introduction 113 This specification extends IMAP4rev1 [RFC3501] to permit UTF-8 114 [RFC3629] in headers as described in Internationalized Email Headers 115 [RFC5335]. It also adds a mechanism to support mailbox names, login 116 names and passwords using the UTF-8 charset. This specification 117 creates five new IMAP capabilities to allow servers to advertise 118 these new extensions, along with two new IMAP list extensions and a 119 new IMAP list return option. 121 3. UTF8=ACCEPT IMAP Capability 123 The "UTF8=ACCEPT" capability indicates the server supports UTF-8 124 quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8 125 responses from the LIST and LSUB commands. 127 A client MUST use the "ENABLE UTF8=ACCEPT" command (defined in 128 [RFC5161]) to indicate to the server that the client accepts UTF-8 129 quoted-strings. The "ENABLE UTF8=ACCEPT" command MUST only be used 130 in the authenticated state. (Note that the "UTF8=ONLY" capability 131 described in Section 7 implies the "UTF8=ACCEPT" capability. See 132 additional information in that section.) 134 3.1. IMAP UTF-8 Quoted Strings 136 The IMAP4rev1 [RFC3501] base specification forbids the use of 8-bit 137 characters in atoms or quoted strings. Thus a UTF-8 string can only 138 be sent as a literal. This can be inconvenient from a coding 139 standpoint, and unless the server offers IMAP4 non-synchronizing 140 literals [RFC2088], this requires an extra round trip for each UTF-8 141 string sent by the client. When the IMAP server advertises the 142 "UTF8=ACCEPT" capability, it informs the client that it supports 143 native UTF-8 quoted-strings with the following syntax: 145 string =/ utf8-quoted 147 utf8-quoted = "*" DQUOTE *UQUOTED-CHAR DQUOTE 149 UQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4 150 ; UTF8-2, UTF8-3, and UTF8-4 are as defined in RFC 3629 152 When this quoting mechanism is used by the client (specifically an 153 octet sequence beginning with *" and ending with "), then the server 154 MUST reject octet sequences with the high bit set that fail to comply 155 with the formal syntax in [RFC3629] with a BAD response. 157 The IMAP server MUST NOT send utf8-quoted syntax to the client unless 158 the client has indicated support for that syntax by using the "ENABLE 159 UTF8=ACCEPT" command. 161 If the server advertises the "UTF8=ACCEPT" capability, the client MAY 162 use utf8-quoted syntax with any IMAP argument that permits a string 163 (including astring and nstring). However, if characters outside the 164 US-ASCII repertoire are used in an inappropriate place, the results 165 would be the same as if other syntacticly valid but semantically 166 invalid characters were used. For example, if the client includes 167 UTF-8 characters in the user or password arguments (and the server 168 has not advertised "UTF8=USER"), the LOGIN command will fail as it 169 would with any other invalid user name or password. Specific cases 170 where UTF-8 characters are permitted or not permitted are described 171 in the following paragraphs. 173 All IMAP servers that advertise the "UTF8=ACCEPT" capability SHOULD 174 accept UTF-8 in mailbox names, and those that also support the 175 "Mailbox International Naming Convention" described in RFC 3501 176 section 5.1.3 MUST accept utf8-quoted mailbox names and convert them 177 to the appropriate internal format. Mailbox names MUST comply with 178 the Net-Unicode Definition (section 2 of [RFC5198]) with the specific 179 exception that they MUST NOT contain control characters (0000-001F, 180 0080-009F), delete (007F), line separator (2028) or paragraph 181 separator (2029). 183 An IMAP client MUST NOT issue a SEARCH command that uses a mixture of 184 utf8-quoted syntax and a SEARCH CHARSET other than UTF-8. If an IMAP 185 server receives such a SEARCH command, it SHOULD reject the command 186 with a BAD response (due to the conflicting charset labels). 188 3.2. UTF8 Parameter to SELECT and EXAMINE 190 The "UTF8=ACCEPT" capability also indicates the server supports the 191 "UTF8" parameter to SELECT and EXAMINE. When a mailbox is selected 192 with the "UTF8" parameter, it alters the behavior of all IMAP 193 commands related to message sizes, message headers and MIME body 194 headers so they refer to the message with UTF-8 headers. If the 195 mailstore is not UTF-8 header native and the SELECT or EXAMINE 196 command with UTF-8 header modifier succeeds, then the server MUST 197 return results as if the mailstore was UTF-8 header native with 198 upconversion requirements as described in Section 8. The server MAY 199 reject the SELECT or EXAMINE command with the [NOT-UTF-8] response 200 code, unless the "UTF8=ALL" or "UTF8=ONLY" capability is advertised. 202 Servers MAY include mailboxes that can only be selected or examined 203 if the "UTF8" parameter is provided. However, such mailboxes MUST 204 NOT be included in the output of an unextended LIST, LSUB or 205 equivalent command. If a client attempts to SELECT or EXAMINE such 206 mailboxes without the "UTF8" parameter, the server MUST reject the 207 command with a [UTF-8-ONLY] response code. As a result, such 208 mailboxes will not accessible by IMAP clients written prior to this 209 specification and are discouraged unless the server advertises 210 "UTF8=ONLY" or the server implements IMAP4 LIST Command Extensions 211 [RFC5258]. 213 utf8-select-param = "UTF8" 214 ;; Conforms to from RFC 4466 216 C: a SELECT newmailbox (UTF8) 217 S: ... 218 S: a OK SELECT completed 219 C: b FETCH 1 (SIZE ENVELOPE BODY) 220 S: ... < UTF-8 header native results > 221 S: b OK FETCH completed 223 C: c EXAMINE legacymailbox (UTF8) 224 S: c NO [NOT-UTF-8] Mailbox does not support UTF-8 access 226 C: d SELECT funky-new-mailbox 227 S: d NO [UTF-8-ONLY] Mailbox requires UTF-8 client 229 3.3. UTF-8 LIST and LSUB Responses 231 After an IMAP client successfully issues an "ENABLE UTF8=ACCEPT" 232 command, the server MUST NOT return in LIST results any mailbox names 233 to the client following the IMAP4 Mailbox International Naming 234 Convention. Instead, the server MUST return any mailbox names with 235 characters outside the US-ASCII repertoire using utf8-quoted syntax. 236 (The IMAP4 Mailbox International Naming Convention has proved 237 problematic in the past, so the desire is to make this syntax 238 obsolete as quickly as possible.) 240 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions 242 When an IMAP server advertises both the "UTF8=ACCEPT" capability and 243 the "LIST-EXTENEDED" [RFC5258] capability, the server MUST support 244 the LIST extensions described in this section. 246 3.4.1. UTF8 and UTF8ONLY LIST Selection Options 248 The "UTF8" LIST selection option tells the server to include 249 mailboxes that only support UTF-8 headers in the output of the list 250 command. The "UTF8ONLY" LIST selection option tells the server to 251 include all mailboxes that support UTF-8 headers and to exclude 252 mailboxes that don't support UTF-8 headers. Note that "UTF8ONLY" 253 implies "UTF8" so it is not necessary for the client to request both. 254 Use of either selection option will also result in UTF-8 mailbox 255 names in the result as described in Section 3.3 and implies the 256 "UTF8" List return option described in Section 3.4.2. 258 3.4.2. UTF8 LIST Return Option 260 If the client supplies the "UTF8" LIST return option, then the server 261 MUST include either the "\NoUTF8" or the "\UTF8Only" mailbox 262 attribute as appropriate. The "\NoUTF8" mailbox attribute indicates 263 an attempt to SELECT or EXAMINE that mailbox with the "UTF8" 264 parameter will fail with a [NOT-UTF-8] response code. The 265 "\UTF8Only" mailbox attribute indicates an attempt to SELECT or 266 EXAMINE that mailbox without the "UTF8" parameter will fail with a 267 [UTF-8-ONLY] response code. Note that computing this information may 268 be expensive on some server implementations so this return option 269 should not be used unless necessary. 271 The ABNF [RFC5234] for these LIST extensions follows: 273 list-select-independent-opt =/ "UTF8" 275 list-select-base-opt =/ "UTF8ONLY" 277 mbx-list-oflag =/ "\NoUTF8" / "\UTF8Only" 279 return-option =/ "UTF8" 281 resp-text-code =/ "NOT-UTF-8" / "UTF-8-ONLY" 283 4. UTF8=APPEND Capability 285 If the "UTF8=APPEND" capability is advertised, then the server 286 accepts UTF-8 headers in the APPEND command message argument. A 287 client that sends a message with UTF-8 headers to the server MUST 288 send them using the "UTF8" APPEND data extension. If the server also 289 advertises the CATENATE capability (as specified in [RFC4469]), the 290 client can use the same data extension to include such a message in a 291 CATENATE message part. The ABNF for the APPEND data extension and 292 CATENATE extension follows: 294 utf8-literal = "UTF8" SP "(" literal8 ")" 296 append-data =/ utf8-literal 298 cat-part =/ utf8-literal 300 A server that advertises "UTF8=APPEND" has to comply with the 301 requirements of the IMAP base specification and [RFC5322] for message 302 fetching. Mechanisms for 7-bit downgrading to help comply with the 303 standards are discussed in Downgrading mechanism for 304 Internationalized eMail Address (IMA) [RFC5504]. 306 IMAP servers that do not advertise the "UTF8=APPEND" or "UTF8=ONLY" 307 capability SHOULD reject an APPEND command that includes any 8-bit in 308 the message headers with a "NO" response. 310 Note that the "UTF8=ONLY" capability described in Section 7 implies 311 the "UTF8=APPEND" capability. See additional information in that 312 section. 314 5. UTF8=USER Capability 316 If the "UTF8=USER" capability is advertised, that indicates the 317 server accepts UTF-8 user names and passwords and applies SASLprep 318 [RFC4013] to both arguments of the LOGIN command. The server MUST 319 reject UTF-8 that fails to comply with the formal syntax in RFC 3629 320 [RFC3629]. 322 6. UTF8=ALL Capability 324 The "UTF8=ALL" capability indicates all server mailboxes support 325 UTF-8 headers. Specifically, SELECT and EXAMINE with the "UTF8" 326 parameter will never fail with a [NOT-UTF-8] response code. 328 Note that the "UTF8=ONLY" capability described in Section 7 implies 329 the "UTF8=ALL" capability. See additional information in that 330 section. 332 7. UTF8=ONLY Capability 334 The "UTF8=ONLY" capability permits an IMAP server to advertise that 335 it does not support the international mailbox name convention 336 (modified UTF-7), and does not permit selection or examination of any 337 mailbox unless the "UTF8" parameter is provided. As this is an 338 incompatible change to IMAP, a clear warning is necessary. IMAP 339 clients that find implementation of the "UTF8=ONLY" capability 340 problematic are encouraged to at least detect the "UTF8=ONLY" 341 capability and provide an informative error message to the end-user. 343 When an IMAP mailbox internally uses UTF-8 header native storage, the 344 down-conversion step is necessary to permit selection or examination 345 of the mailbox in a backwards compatible fashion will become more 346 difficult to support. Although it is hoped deployed IMAP servers do 347 not advertise "UTF8=ONLY" for some years, this capability is intended 348 to minimize the disruption when legacy support finally goes away. 350 The "UTF8=ONLY" capability implies the "UTF8=ACCEPT" capability, the 351 "UTF8=ALL" capability, and the "UTF8=APPEND" capability. A server 352 that advertises "UTF8=ONLY" need not advertise the three implicit 353 capabilities. 355 8. Up-Conversion Server Requirements 357 When an IMAP4 server uses a traditional mailbox format that includes 358 7-bit headers and it chooses to permit access to that mailbox with 359 the "UTF8" parameter, it MUST support minimal up-conversion as 360 described in this section. 362 The server MUST support up-conversion of the following address 363 header-fields in the message header: From, Sender, To, CC, Bcc, 364 Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and 365 Reply-To. This up-conversion MUST include address local-parts in 366 fields downgraded according to [RFC5504], address domains encoded 367 according to IDNA [RFC3490], and MIME header encoding [RFC2047] of 368 display-names and any [RFC5322] comments. 370 The following charsets MUST be supported for up-conversion of MIME 371 header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2, 372 ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, 373 ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15. 374 Other widely deployed MIME charsets SHOULD be supported. 376 Up-conversion of MIME header encoding of the following headers MUST 377 also be implemented: Subject, Date ([RFC5322] comments only), 378 Comments, Keywords, Content-Description. 380 Server implementations also SHOULD up-convert all MIME body headers 381 [RFC2045], SHOULD up-convert or remove the deprecated (and misused) 382 "name" parameter [RFC1341] on Content-Type and MUST up-convert the 383 Content-Disposition [RFC2183] "filename" parameter, except when any 384 of these are contained within a multipart/signed MIME body part (see 385 below). These parameters can be encoded using the standard MIME 386 parameter encoding [RFC2231] mechanism, or via non-standard use of 387 MIME header encoding [RFC2047] in quoted strings. 389 The IMAP server MUST NOT perform up-conversion of headers and content 390 of multipart/signed, as well as Original-Recipient and Return-Path. 392 9. Issues with UTF-8 Header Mailstore 394 When an IMAP server uses a mailbox format that supports UTF-8 headers 395 and it permits selection or examination of that mailbox without the 396 "UTF8" parameter, it is the responsibility of the server to comply 397 with the IMAP4rev1 [RFC3501] base specification and [RFC5322] with 398 respect to all header information transmitted over the wire. 399 Mechanisms for 7-bit downgrading to help comply with the standards 400 are discussed in "Downgrading Mechanism for Email Address 401 Internationalization" [RFC5504]. 403 An IMAP server with a mailbox that supports UTF-8 headers MUST comply 404 with the protocol requirements implicit from Section 8. However, the 405 code necessary for such compliance need not be part of the IMAP 406 server itself in this case. For example, the minimal required up- 407 conversion could be performed when a message is inserted into the 408 IMAP-accessible mailbox. 410 10. IANA Considerations 412 This adds five new capabilities ("UTF8=ACCEPT", "UTF8=USER", 413 "UTF8=APPEND", "UTF8=ALL", "UTF8=ONLY") to the IMAP4rev1 capability 414 registry [RFC3501]. 416 This adds two new IMAP4 list selection options and one new IMAP4 list 417 return option. 419 1. LIST-EXTENDED option name: UTF8 421 LIST-EXTENDED option type: SELECTION 422 Implied return options(s): UTF8 424 LIST-EXTENDED option description: Causes the LIST response to 425 include mailboxes that mandate the UTF8 SELECT/EXAMINE parameter. 427 Published specification: RFC XXXX, Section 3.4.1 429 Security considerations: RFC XXXX, Section 11 431 Intended usage: COMMON 433 Person an email address to contact for further information: see 434 Authors' Addresses at the end of this specification 436 Owner/Change controller: iesg@ietf.org 438 2. LIST-EXTENDED option name: UTF8ONLY 440 LIST-EXTENDED option type: SELECTION 442 Implied return options(s): UTF8 444 LIST-EXTENDED option description: Causes the LIST response to 445 include mailboxes that mandate the UTF8 SELECT/EXAMINE parameter 446 and exclude mailboxes that do not support the UTF8 SELECT/EXAMINE 447 parameter. 449 Published specification: RFC XXXX, Section 3.4.1 451 Security considerations: RFC XXXX, Section 11 453 Intended usage: COMMON 455 Person an email address to contact for further information: see 456 Authors' Addresses at the end of this specification 458 Owner/Change controller: iesg@ietf.org 460 3. LIST-EXTENDED option name: UTF8 462 LIST-EXTENDED option type: RETURN 464 Implied return options(s): none 466 LIST-EXTENDED option description: Causes the LIST response to 467 include \NoUTF8 and \UTF8Only mailbox attributes. 469 Published specification: RFC XXXX, Section 3.4.1 470 Security considerations: RFC XXXX, Section 11 472 Intended usage: COMMON 474 Person an email address to contact for further information: see 475 Authors' Addresses at the end of this specification 477 Owner/Change controller: iesg@ietf.org 479 11. Security Considerations 481 The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] 482 apply to this specification, particularly with respect to use of 483 UTF-8 in user names and passwords. Otherwise, this is not believed 484 to alter the security considerations of IMAP4rev1. 486 12. References 488 12.1. Normative References 490 [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 491 Mail Extensions): Mechanisms for Specifying and Describing 492 the Format of Internet Message Bodies", RFC 1341, 493 June 1992. 495 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 496 Extensions (MIME) Part One: Format of Internet Message 497 Bodies", RFC 2045, November 1996. 499 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 500 Part Three: Message Header Extensions for Non-ASCII Text", 501 RFC 2047, November 1996. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, March 1997. 506 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 507 Presentation Information in Internet Messages: The 508 Content-Disposition Header Field", RFC 2183, August 1997. 510 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 511 Word Extensions: 512 Character Sets, Languages, and Continuations", RFC 2231, 513 November 1997. 515 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 516 "Internationalizing Domain Names in Applications (IDNA)", 517 RFC 3490, March 2003. 519 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 520 4rev1", RFC 3501, March 2003. 522 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 523 10646", STD 63, RFC 3629, November 2003. 525 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 526 and Passwords", RFC 4013, February 2005. 528 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 529 ABNF", RFC 4466, April 2006. 531 [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP) 532 CATENATE Extension", RFC 4469, April 2006. 534 [RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE 535 Extension", RFC 5161, March 2008. 537 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 538 Interchange", RFC 5198, March 2008. 540 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 541 Specifications: ABNF", STD 68, RFC 5234, January 2008. 543 [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access 544 Protocol version 4 - LIST Command Extensions", RFC 5258, 545 June 2008. 547 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 548 October 2008. 550 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, 551 September 2008. 553 [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for 554 Email Address Internationalization", RFC 5504, March 2009. 556 12.2. Informative References 558 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 559 Extensions (MIME) Part Five: Conformance Criteria and 560 Examples", RFC 2049, November 1996. 562 [RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 563 January 1997. 565 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 566 Languages", BCP 18, RFC 2277, January 1998. 568 [I-D.ietf-eai-pop] 569 Gellens, R. and C. Newman, "POP3 Support for UTF-8", 570 draft-ietf-eai-pop-09 (work in progress), October 2009. 572 Appendix A. Design Rationale 574 This non-normative section discusses the reasons behind some of the 575 design choices in the above specification. 577 The basic approach of advertising the ability to access a mailbox in 578 UTF-8 mode is intended to permit graceful upgrade, including servers 579 that support multiple mailbox formats. In particular, it would be 580 undesirable to force conversion of an entire server mailstore to 581 UTF-8 headers, so being able to phase-in support for new mailboxes 582 and gradually migrate old mailboxes is permitted by this design. 584 "UTF8=USER" is optional because many identity systems are US-ASCII 585 only, so it's helpful to inform the client up-front that UTF-8 won't 586 work. 588 "UTF8=APPEND" is optional because it effectively requires IMAP server 589 support for down-conversion, which is a much more complex operation 590 than up-conversion. 592 The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability 593 problems when legacy support goes away. In the situation where 594 backwards compatibility is broken anyway, just-send-UTF-8 IMAP has 595 the advantage that it might work with some legacy clients. However, 596 the difficulty of diagnosing interoperability problems caused by a 597 just-send-UTF-8 IMAP mechanism is the reason the "UTF8=ONLY" 598 capability mechanism was chosen. 600 The up-conversion requirements are designed to balance the desire to 601 deprecate and eventually eliminate complicated encodings (like MIME 602 header encodings) without creating a significant deployment burden 603 for servers. As IMAP4 servers already require a MIME parser, this 604 includes additional server up-conversion requirements not present in 605 POP3 Support for UTF-8 [I-D.ietf-eai-pop]. 607 The set of mandatory charsets comes from two sources: MIME 608 requirements [RFC2049] and IETF Policy on Character Sets [RFC2277]. 609 Including a requirement to up-convert widely deployed encoded 610 ideographic charsets to UTF-8 would be reasonable for most scenarios, 611 but may require unacceptable table sizes for some embedded devices. 613 The open-ended recommendation to support widely deployed charsets 614 avoids the political ramifications of attempting to list such 615 charsets. The authors believe market forces, existing open-source 616 software, and public conversion tables are sufficient to deploy the 617 appropriate charsets. 619 Appendix B. Acknowledgments 621 The authors wish to thank the participants of the EAI working group 622 for their contributions to this document with particular thanks to 623 Harald Alvestrand, David Black, Randall Gellens, Arnt Gulbrandsen, 624 Kari Hurtta, John Klensin, Xiaodong Lee, Charles Lindsey, Alexey 625 Melnikov, Subramanian Moonesamy, Shawn Steele, Daniel Taharlev, and 626 Joseph Yee for their specific contributions to the discussion. 628 Authors' Addresses 630 Pete Resnick 631 Qualcomm Incorporated 632 5775 Morehouse Drive 633 San Diego, CA 92121-1714 634 US 636 Phone: +1 858 651 4478 637 Email: presnick@qualcomm.com 638 URI: http://www.qualcomm.com/~presnick/ 640 Chris Newman 641 Sun Microsystems 642 3401 Centrelake Dr., Suite 410 643 Ontario, CA 91761 644 US 646 Email: chris.newman@sun.com