idnits 2.17.1 draft-ietf-eai-imap-utf8-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 644. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 4, 2007) is 6256 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: 'NOT-UTF-8' is mentioned on line 295, but not defined == Missing Reference: 'UTF-8-ONLY' is mentioned on line 252, but not defined == Missing Reference: 'TBD' is mentioned on line 332, but not defined == Unused Reference: 'RFC1847' is defined on line 462, but no explicit reference was found in the text == 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 2822 (Obsoleted by RFC 5322) ** 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 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-utf8headers (ref. 'I-D.ietf-eai-utf8headers') -- Obsolete informational reference (is this intentional?): RFC 2088 (Obsoleted by RFC 7888) == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-02 Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 9 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 Expires: September 5, 2007 Sun Microsystems 6 March 4, 2007 8 IMAP Support for UTF-8 9 draft-ietf-eai-imap-utf8-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 5, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This specification extends the Internet Message Access Protocol 43 version 4rev1 (IMAP4rev1) to support unencoded international 44 characters in user names, mail addresses and message headers. This 45 is an early draft and intended as a framework for discussion. Please 46 do not deploy implementations of this draft. 48 Table of Contents 50 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. UTF8 IMAP Capability . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. IMAP UTF-8 Quoted Strings . . . . . . . . . . . . . . . . 3 54 3.2. UTF8 Parameter to SELECT and EXAMINE . . . . . . . . . . . 5 55 3.3. UTF-8 LIST and LSUB Responses . . . . . . . . . . . . . . 5 56 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions . . . 6 57 3.4.1. UTF8 and UTF8ONLY LIST Selection Options . . . . . . . 6 58 3.4.2. UTF8 LIST Return Option . . . . . . . . . . . . . . . 6 59 4. UTF8=APPEND Capability . . . . . . . . . . . . . . . . . . . . 7 60 5. UTF8=USER Capability . . . . . . . . . . . . . . . . . . . . . 7 61 6. UTF8=ALL Capability . . . . . . . . . . . . . . . . . . . . . 7 62 7. UTF8=ONLY Capability . . . . . . . . . . . . . . . . . . . . . 7 63 8. Up-Conversion Server Requirements . . . . . . . . . . . . . . 8 64 9. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 9 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 69 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 13 71 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . . . 15 75 1. Conventions Used in this Document 77 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 78 in this document are to be interpreted as defined in "Key words for 79 use in RFCs to Indicate Requirement Levels" [RFC2119]. 81 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC4234] 82 notation including the core rules defined in Appendix B of RFC 4234. 83 In addition, rules from IMAP4rev1 [RFC3501], UTF-8 [RFC3629], 84 Collected extensions to IMAP4 ABNF 85 [I-D.ietf-imapext-list-extensions], and IMAP4 LIST Command Extensions 86 [I-D.ietf-imapext-list-extensions] are also referenced. 88 In examples, "C:" and "S:" indicate lines sent by the client and 89 server respectively. If a single "C:" or "S:" label applies to 90 multiple lines, then the line breaks between those lines are for 91 editorial clarity only and are not part of the actual protocol 92 exchange. 94 2. Introduction 96 This specification extends IMAP4rev1 [RFC3501] to permit unencoded 97 UTF-8 [RFC3629] in headers as described in Transmission of Email 98 Headers in UTF-8 Encoding [I-D.ietf-eai-utf8headers]. It also adds a 99 mechanism to support mailbox names, login names and passwords using 100 the UTF-8 charset. 102 3. UTF8 IMAP Capability 104 The basic "UTF8" capability indicates the server supports UTF-8 105 quoted strings and the UTF8 parameter to SELECT and EXAMINE. 107 3.1. IMAP UTF-8 Quoted Strings 109 The IMAP4rev1 [RFC3501] base specification forbids the use of 8-bit 110 characters in atoms or quoted strings. Thus a UTF-8 string can only 111 be sent as a literal. This can be inconvenient from a coding 112 standpoint, and unless the server offers IMAP4 non-synchronizing 113 literals [RFC2088], this requires an extra round trip for each UTF-8 114 string sent by the client. When the IMAP server advertises the 115 "UTF8" capability, it informs the client that it supports native 116 UTF-8 quoted-strings with the following syntax: 118 string =/ utf8-quoted 120 utf8-quoted = "*" DQUOTE *UQUOTED-CHAR DQUOTE 122 UQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4 123 ; UTF8-2, UTF8-3, and UTF8-4 are as defined in RFC 3629 125 When this quoting mechanism is used by the client (specifically an 126 octet sequence beginning with *" and ending with "), then the server 127 MUST reject octet sequences with the high bit set which fail to 128 comply with the formal syntax in RFC 3629 [RFC3629] with a BAD 129 response. 131 The IMAP server MUST NOT send utf8-quoted syntax to the client unless 132 the client has indicated support for that syntax, either by using it 133 or by using the UTF8 parameter to SELECT or EXAMINE described in 134 Section 3.2. 136 If the UTF8 capability is advertised, then utf8-quoted syntax MAY be 137 used with any IMAP argument that permits a string or an astring. 138 However, if characters outside the US-ASCII repertoire are used in an 139 inappropriate place, the results would be the same as if other 140 syntacticly valid but semantically invalid characters were used. For 141 example, if the client includes UTF-8 characters in the user or 142 password arguments (and the server has not advertised UTF8-USER), the 143 LOGIN command will fail as it would with any other invalid user name 144 or password. Specific cases where UTF-8 characters are permitted or 145 not permitted are described in the following paragraphs. 147 All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP 148 servers which support the "Mailbox International Naming Convention" 149 described in RFC 3501 section 5.1.3 MUST accept utf8-quoted mailbox 150 names and convert them to the appropriate internal format. [TBD 151 stringprep for mailbox names? Can we reuse SASLprep?]. 153 IMAP servers MUST NOT accept UTF-8 characters when storing a new 154 message keyword, unless the mailbox is UTF-8 only, in which case IMAP 155 servers SHOULD accept UTF-8 in message keywords. [TBD stringprep for 156 message keywords? Can we reuse SASLprep?] 158 If an IMAP client issues a SEARCH command which uses a mixture of 159 utf8-quoted syntax and a SEARCH CHARSET other than UTF-8, then the 160 IMAP server SHOULD reject the command with a BAD response (due to the 161 conflicting charset labels). 163 3.2. UTF8 Parameter to SELECT and EXAMINE 165 The "UTF8" capability also indicates the server supports the UTF8 166 parameter to SELECT and EXAMINE. When a mailbox is selected with the 167 UTF8 parameter, that alters the behavior of all IMAP commands related 168 to message sizes, message headers and MIME body headers so they refer 169 to the message with UTF-8 headers. If the mailstore is not UTF-8 170 header native and the SELECT or EXAMINE command with UTF-8 header 171 modifier succeeds, then the server MUST return results as if the 172 mailstore was UTF-8 header native with upconversion requirements as 173 described in Section 8. The server MAY reject the SELECT or EXAMINE 174 command with the [NOT-UTF-8] response code, unless the UTF8=ALL or 175 UTF8=ONLY capability is advertised. 177 Servers MAY include mailboxes which can only be selected or examined 178 if the UTF8 parameter is provided. However, such mailboxes MUST NOT 179 be included in the output of an unextended LIST, LSUB or equivalent 180 command. If a client attempts to SELECT or EXAMINE such mailboxes 181 without the UTF8 parameter, the server MUST reject the command with a 182 [UTF-8-ONLY] response code. As a result, such mailboxes will not 183 accessible by IMAP clients written prior to this specification and 184 are discouraged unless the server advertises UTF8=ONLY or the server 185 implements IMAP4 LIST Command Extensions 186 [I-D.ietf-imapext-list-extensions]. 188 TBD: describe syntax based on draft-melnikov-imap-ext-abnf-05. 190 C: a SELECT newmailbox (UTF8) 191 S: ... 192 S: a OK SELECT completed 193 C: b FETCH 1 (SIZE ENVELOPE BODY) 194 S: ... < UTF-8 header native results > 195 S: b OK FETCH completed 197 C: c EXAMINE legacymailbox (UTF8) 198 S: c NO [NOT-UTF-8] Mailbox does not support UTF-8 access 200 C: d SELECT funky-new-mailbox 201 S: d NO [UTF-8-ONLY] Mailbox requires UTF-8 client 203 3.3. UTF-8 LIST and LSUB Responses 205 If an IMAP client has used utf8-quoted syntax prior to the server's 206 production of LIST results, then the server MUST NOT return any 207 mailbox names to the client following the IMAP4 Mailbox International 208 Naming Convention. Instead, the server MUST return any mailbox names 209 with characters outside the US-ASCII repertorie using utf8-quoted 210 syntax. An IMAP client can force this behavior by issuing the LIST 211 or LSUB command as follows: 213 C: a LIST *"" % 214 S: 215 S: a OK LIST completed 216 C: a LSUB *"*" 217 S: 218 S: a OK LSUB completed 220 The IMAP4 Mailbox International Naming Convention has proved 221 problematic in the past, so the desire is to make this syntax 222 obsolete as quickly as possible. 224 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions 226 When an IMAP server advertises both the "UTF8" capability and the 227 "LIST-EXTENEDED" [I-D.ietf-imapext-list-extensions] capability, the 228 server MUST support the LIST extensions described in this section. 229 When an IMAP server advertises the UTF8=ONLY capability and the LIST- 230 EXTENDED capability, the server MUST reject these LIST extensions 231 with a BAD response. 233 3.4.1. UTF8 and UTF8ONLY LIST Selection Options 235 The UTF8 LIST selection option tells the server to include mailboxes 236 that only support UTF-8 headers in the output of the list command. 237 The UTF8ONLY LIST selection option tells the server to include all 238 mailboxes that support UTF-8 headers and to exclude mailboxes that 239 don't support UTF-8 headers. Note that UTF8ONLY implies UTF8 so it 240 is not necessary for the client to request both. Use of either 241 selection option will also result in UTF-8 mailbox names in the 242 result as described in Section 3.3. 244 3.4.2. UTF8 LIST Return Option 246 If the client supplies the UTF8 LIST return option, then the server 247 MUST include either the \NoUTF8 or the \UTF8Only mailbox attribute as 248 appropriate. The \NoUTF8 mailbox attribute indicates an attempt to 249 SELECT or EXAMINE that mailbox with the UTF8 parameter will fail with 250 a [NOT-UTF-8] response code. The \UTF8Only mailbox attribute 251 indicates an attempt to SELECT or EXAMINE that mailbox without the 252 UTF8 parameter will fail with a [UTF-8-ONLY] response code. Note 253 that computing this information may be expensive on some server 254 implementations so this return option should not be used unless 255 necessary. 257 The ABNF [RFC4234] for these LIST extensions follows: 259 list-select-independent-opt =/ "UTF8" / "UTF8ONLY" 261 mbox-list-oflag =/ "\NoUTF8" / "\UTF8Only" 263 return-option =/ "UTF8" 265 4. UTF8=APPEND Capability 267 If the UTF8=APPEND capability is advertised, then the server accepts 268 UTF-8 headers in the APPEND command message argument. A client which 269 sends a message with UTF-8 headers to the server MUST include the 270 UTF8 APPEND parameter. The ABNF for this APPEND parameter follows: 272 append-ext =/ "UTF8" 274 A server which advertises UTF8=APPEND has to comply with the 275 requirements of the IMAP base specification and RFC 2822 for message 276 fetching. Mechanisms for 7-bit downgrading to help comply with the 277 standards are discussed in Downgrading mechanism for 278 Internationalized eMail Address (IMA) [I-D.ietf-eai-downgrade]. 280 IMAP servers which do not advertise the UTF8=APPEND or UTF8=ONLY 281 capability SHOULD reject an APPEND command which includes any 8-bit 282 in the message headers with a "NO" response. 284 5. UTF8=USER Capability 286 If the UTF8=USER capability is advertised, that indicates the server 287 accepts UTF-8 user names and passwords and applies SASLprep [RFC4013] 288 to both arguments of the LOGIN command. The server MUST reject UTF-8 289 which fails to comply with the formal syntax in RFC 3629 [RFC3629]. 291 6. UTF8=ALL Capability 293 This capability indicates all server mailboxes support UTF-8 headers. 294 Specifically, SELECT and EXAMINE with the UTF8 parameter will never 295 fail with a [NOT-UTF-8] response token. 297 7. UTF8=ONLY Capability 299 This capability permits an IMAP server to advertise that it does not 300 support the international mailbox name convention (modified UTF-7), 301 and does not permit selection or examination of any mailbox unless 302 the UTF8 parameter is provided. As this is an incompatible change to 303 IMAP, a clear warning is necessary. IMAP clients which find 304 implementation of the UTF8 capability problematic are encouraged to 305 at least detect the UTF8=ONLY capability and provide an informative 306 error message to the end-user. 308 When an IMAP mailbox internally uses UTF-8 header native storage, the 309 down-conversion step necessary to permit selection or examination of 310 the mailbox in a backwards compatible fashion will become more 311 difficult to support. Although it is hoped deployed IMAP servers do 312 not advertise UTF8=ONLY for some years, this capability is intended 313 to minimize the disruption when legacy support finally goes away. 315 The UTF8=ONLY capability implies the UTF8 base capability, the 316 UTF8=ALL capability and the UTF8=APPEND capability. A server which 317 advertises UTF8=ONLY need not advertise the three implicit 318 capabilities. 320 8. Up-Conversion Server Requirements 322 When an IMAP4 server uses a traditional mailbox format that includes 323 7-bit headers and it chooses to permit access to that mailbox with 324 the UTF8 parameter, it MUST support minimal up-conversion as 325 described in this section. Minimal up-conversion is described in 326 this section. 328 The server MUST support up-conversion of the following address 329 header-fields in the message header: From, Sender, To, CC, Bcc, 330 Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and 331 Reply-To. This up-conversion MUST include address local-parts 332 encoded according to [TBD], address domains encoded according to IDNA 333 [RFC3490], and MIME header encoding [RFC2047] of display-names and 334 any RFC 2822 comments. 336 The following charsets MUST be supported for up-conversion of MIME 337 header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2, 338 ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, 339 ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15. 340 Other widely deployed MIME charsets SHOULD be supported. 342 Up-conversion of MIME header encoding of the following headers MUST 343 also be implemented: Subject, Date (RFC 2822 comments only), 344 Comments, Keywords, Content-Description. 346 Server implementations also SHOULD up-convert all MIME body headers, 347 SHOULD up-convert or remove the deprecated (and misused) name 348 parameter [RFC1341] on Content-Type and MUST up-convert the Content- 349 Disposition filename parameter. These parameters can be encoded 350 using the standard MIME parameter encoding [RFC2231] mechanism, or 351 via non-standard use of MIME header encoding [RFC2047] in quoted 352 strings. 354 The IMAP server MUST NOT perform up-conversion of headers and content 355 of multipart/signed, as well as Original-Recipient and Return-Path. 357 9. Issues with UTF-8 Header Mailstore 359 When an IMAP server uses a mailbox format that supports UTF-8 headers 360 and it permits selection or examination of that mailbox without the 361 UTF8 parameter, it is the responsibility of the server to comply with 362 the IMAP4rev1 [RFC3501] base specification and RFC 2822 [RFC2822] 363 with respect to all header information transmitted over the wire. 364 Mechanisms for 7-bit downgrading to help comply with the standards 365 are discussed in Downgrading mechanism for Internationalized eMail 366 Address (IMA) [I-D.ietf-eai-downgrade]. 368 An IMAP server with a mailbox that supports UTF-8 headers MUST comply 369 with the protocol requirements implicit from Section 8. However, the 370 code necessary for such compliance need not be part of the IMAP 371 server itself in this case. For example, the minimal required up- 372 conversion could be performed when a message is inserted into the 373 IMAP-accessible mailbox. 375 10. IANA Considerations 377 This adds five new capabilities ("UTF8", "UTF8=USER", "UTF8=APPEND", 378 "UTF8=ALL", "UTF8=ONLY") to the IMAP4rev1 capability registry 379 [RFC3501]. 381 This adds two new IMAP4 list selection options and one new IMAP4 list 382 return option. 384 1. LIST-EXTENDED option name: UTF8 386 LIST-EXTENDED option type: SELECTION 388 Implied return options(s): none 390 LIST-EXTENDED option description: Causes the LIST response to 391 include mailboxes which mandate the UTF8 SELECT/EXAMINE 392 parameter. 394 Published specification: RFC XXXX, Section 3.4.1 396 Security considerations: RFC XXXX, Section 11 398 Intended usage: COMMON 400 Person an email address to contact for further information: see 401 Authors' Addresses at the end of this specification 403 Owner/Change controller: iesg@ietf.org 405 2. LIST-EXTENDED option name: UTF8ONLY 407 LIST-EXTENDED option type: SELECTION 409 Implied return options(s): none 411 LIST-EXTENDED option description: Causes the LIST response to 412 include mailboxes which mandate the UTF8 SELECT/EXAMINE parameter 413 and exclude mailboxes which do not support the UTF8 SELECT/ 414 EXAMINE parameter. 416 Published specification: RFC XXXX, Section 3.4.1 418 Security considerations: RFC XXXX, Section 11 420 Intended usage: COMMON 422 Person an email address to contact for further information: see 423 Authors' Addresses at the end of this specification 425 Owner/Change controller: iesg@ietf.org 427 3. LIST-EXTENDED option name: UTF8 429 LIST-EXTENDED option type: RETURN 431 Implied return options(s): none 433 LIST-EXTENDED option description: Causes the LIST response to 434 include \NoUTF8 and \UTF8Only mailbox attributes. 436 Published specification: RFC XXXX, Section 3.4.1 438 Security considerations: RFC XXXX, Section 11 440 Intended usage: COMMON 441 Person an email address to contact for further information: see 442 Authors' Addresses at the end of this specification 444 Owner/Change controller: iesg@ietf.org 446 11. Security Considerations 448 The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] 449 apply to this specification, particularly with respect to use of 450 UTF-8 in user names and passwords. Otherwise, this is not believed 451 to alter the security considerations of IMAP4rev1. 453 12. References 455 12.1. Normative References 457 [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 458 Mail Extensions): Mechanisms for Specifying and Describing 459 the Format of Internet Message Bodies", RFC 1341, 460 June 1992. 462 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 463 "Security Multiparts for MIME: Multipart/Signed and 464 Multipart/Encrypted", RFC 1847, October 1995. 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: Character Sets, Languages, and 483 Continuations", RFC 2231, November 1997. 485 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 486 April 2001. 488 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 489 "Internationalizing Domain Names in Applications (IDNA)", 490 RFC 3490, March 2003. 492 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 493 4rev1", RFC 3501, March 2003. 495 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 496 10646", STD 63, RFC 3629, November 2003. 498 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 499 and Passwords", RFC 4013, February 2005. 501 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 502 Specifications: ABNF", RFC 4234, October 2005. 504 [I-D.ietf-eai-utf8headers] 505 Yeh, J., "Internationalized Email Headers", 506 draft-ietf-eai-utf8headers-03 (work in progress), 507 March 2007. 509 [I-D.ietf-imapext-list-extensions] 510 Leiba, B. and A. Melnikov, "IMAP4 LIST Command 511 Extensions", draft-ietf-imapext-list-extensions-18 (work 512 in progress), September 2006. 514 12.2. Informative References 516 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 517 Extensions (MIME) Part Five: Conformance Criteria and 518 Examples", RFC 2049, November 1996. 520 [RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 521 January 1997. 523 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 524 Languages", BCP 18, RFC 2277, January 1998. 526 [I-D.newman-ima-pop] 527 Newman, C., "POP3 Support for UTF-8", 528 draft-newman-ima-pop-00 (work in progress), February 2006. 530 [I-D.ietf-eai-downgrade] 531 Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for 532 Email Address Internationalization (EAI)", 533 draft-ietf-eai-downgrade-02 (work in progress), 534 August 2006. 536 Appendix A. Design Rationale 538 This non-normative section discusses the reasons behind some of the 539 design choices in the above specification. 541 The basic approach of advertising the ability to access a mailbox in 542 UTF-8 mode is intended to permit graceful upgrade, including servers 543 which support multiple mailbox formats. In particular, it would be 544 undesirable to force conversion of an entire server mailstore to 545 UTF-8 headers, so being able to phase-in support for new mailboxes 546 and gradually migrate old mailboxes is permitted by this design. 548 UTF8=USER is optional because many identity systems are US-ASCII 549 only, so it's helpful to inform the client up-front that UTF-8 won't 550 work. 552 UTF8=APPEND is optional because it effectively requires IMAP server 553 support for down-conversion which is a much more complex operation 554 than up-conversion. 556 The UTF8=ONLY mechanism simplifies diagnosis of interoperability 557 problems when legacy support goes away. In the situation where 558 backwards compatibility is broken anyway, just-send-UTF-8 IMAP has 559 the advantage that it might work with some legacy clients. However, 560 the difficulty of diagnosing interoperability problems caused by a 561 just-send-UTF-8 IMAP mechanism is the reason the UTF8=ONLY capability 562 mechanism was chosen. 564 The up-conversion requirements are designed to balance the desire to 565 deprecate and eventually eliminate complicated encodings (like MIME 566 header encodings) without creating a significant deployment burden 567 for servers. As IMAP4 servers already require a MIME parser, this 568 includes additional server up-conversion requirements not present in 569 POP3 Support for UTF-8 [I-D.newman-ima-pop]. 571 The set of mandatory charsets comes from two sources: MIME 572 requirements [RFC2049] and IETF Policy on Character Sets [RFC2277]. 573 Including a requirement to up-convert widely deployed encoded 574 ideographic charsets to UTF-8 would be reasonable for most scenarios, 575 but may require unacceptable table sizes for some embedded devices. 576 The open-ended recommendation to support widely deployed charsets 577 avoids the political ramifications of attempting to list such 578 charsets. The author believes market forces, existing open-source 579 software, and public conversion tables are sufficient to deploy the 580 appropriate charsets. 582 Appendix B. Acknowledgments 584 TBD. 586 Authors' Addresses 588 Pete Resnick 589 QUALCOMM Incorporated 590 5775 Morehouse Drive 591 San Diego, CA 92121-1714 592 US 594 Phone: +1 858 651 4478 595 Email: presnick@qualcomm.com 596 URI: http://www.qualcomm.com/~presnick/ 598 Chris Newman 599 Sun Microsystems 600 3401 Centrelake Dr., Suite 410 601 Ontario, CA 91761 602 US 604 Email: chris.newman@sun.com 606 Full Copyright Statement 608 Copyright (C) The IETF Trust (2007). 610 This document is subject to the rights, licenses and restrictions 611 contained in BCP 78, and except as set forth therein, the authors 612 retain all their rights. 614 This document and the information contained herein are provided on an 615 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 616 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 617 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 618 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 619 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 620 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 622 Intellectual Property 624 The IETF takes no position regarding the validity or scope of any 625 Intellectual Property Rights or other rights that might be claimed to 626 pertain to the implementation or use of the technology described in 627 this document or the extent to which any license under such rights 628 might or might not be available; nor does it represent that it has 629 made any independent effort to identify any such rights. Information 630 on the procedures with respect to rights in RFC documents can be 631 found in BCP 78 and BCP 79. 633 Copies of IPR disclosures made to the IETF Secretariat and any 634 assurances of licenses to be made available, or the result of an 635 attempt made to obtain a general license or permission for the use of 636 such proprietary rights by implementers or users of this 637 specification can be obtained from the IETF on-line IPR repository at 638 http://www.ietf.org/ipr. 640 The IETF invites any interested party to bring to its attention any 641 copyrights, patents or patent applications, or other proprietary 642 rights that may cover technology that may be required to implement 643 this standard. Please address the information to the IETF at 644 ietf-ipr@ietf.org. 646 Acknowledgment 648 Funding for the RFC Editor function is provided by the IETF 649 Administrative Support Activity (IASA).