idnits 2.17.1 draft-ietf-eai-imap-utf8-02.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 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 656. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 662. 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 (November 18, 2007) is 6004 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 304, but not defined == Missing Reference: 'UTF-8-ONLY' is mentioned on line 261, but not defined == Missing Reference: 'TBD' is mentioned on line 341, but not defined == Unused Reference: 'RFC1847' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC2183' is defined on line 485, 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.crocker-rfc4234bis' == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-07 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-utf8headers (ref. 'I-D.ietf-eai-utf8headers') == Outdated reference: A later version (-05) exists of draft-gulbrandsen-imap-enable-03 == Outdated reference: A later version (-06) exists of draft-resnick-2822upd-03 -- Obsolete informational reference (is this intentional?): RFC 2088 (Obsoleted by RFC 7888) == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-05 Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 10 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: May 21, 2008 Sun Microsystems 6 November 18, 2007 8 IMAP Support for UTF-8 9 draft-ietf-eai-imap-utf8-02 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 May 21, 2008. 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. Enabling UTF-8 . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. UTF8 IMAP Capability . . . . . . . . . . . . . . . . . . . . . 3 54 4.1. IMAP UTF-8 Quoted Strings . . . . . . . . . . . . . . . . 4 55 4.2. UTF8 Parameter to SELECT and EXAMINE . . . . . . . . . . . 5 56 4.3. UTF-8 LIST and LSUB Responses . . . . . . . . . . . . . . 6 57 4.4. UTF-8 Interaction with IMAP4 LIST Command Extensions . . . 6 58 4.4.1. UTF8 and UTF8ONLY LIST Selection Options . . . . . . . 6 59 4.4.2. UTF8 LIST Return Option . . . . . . . . . . . . . . . 6 60 5. UTF8=APPEND Capability . . . . . . . . . . . . . . . . . . . . 7 61 6. UTF8=USER Capability . . . . . . . . . . . . . . . . . . . . . 7 62 7. UTF8=ALL Capability . . . . . . . . . . . . . . . . . . . . . 7 63 8. UTF8=ONLY Capability . . . . . . . . . . . . . . . . . . . . . 8 64 9. Up-Conversion Server Requirements . . . . . . . . . . . . . . 8 65 10. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 9 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 70 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 71 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 13 72 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 74 Intellectual Property and Copyright Statements . . . . . . . . . . 15 76 1. Conventions Used in this Document 78 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 79 in this document are to be interpreted as defined in "Key words for 80 use in RFCs to Indicate Requirement Levels" [RFC2119]. 82 The formal syntax use the Augmented Backus-Naur Form (ABNF) 83 [I-D.crocker-rfc4234bis] notation including the core rules defined in 84 Appendix B of RFC 4234. In addition, rules from IMAP4rev1 [RFC3501], 85 UTF-8 [RFC3629], Collected extensions to IMAP4 ABNF 86 [I-D.ietf-imapext-list-extensions], and IMAP4 LIST Command Extensions 87 [I-D.ietf-imapext-list-extensions] are also referenced. 89 In examples, "C:" and "S:" indicate lines sent by the client and 90 server respectively. If a single "C:" or "S:" label applies to 91 multiple lines, then the line breaks between those lines are for 92 editorial clarity only and are not part of the actual protocol 93 exchange. 95 2. Introduction 97 This specification extends IMAP4rev1 [RFC3501] to permit unencoded 98 UTF-8 [RFC3629] in headers as described in Transmission of Email 99 Headers in UTF-8 Encoding [I-D.ietf-eai-utf8headers]. It also adds a 100 mechanism to support mailbox names, login names and passwords using 101 the UTF-8 charset. 103 3. Enabling UTF-8 105 A client may use the ENABLE command (defined in 106 [I-D.gulbrandsen-imap-enable]) to inform the server to enable any or 107 all of the UTF-8 extension defined herein. The argument to ENABLE in 108 order to use this extension is the "UTF8" IMAP Capability defined in 109 section 4. The "ENABLE UTF8" command MUST only be used in the not 110 authenticated state. After the client issues the "ENABLE UTF8" 111 command, a subsequent "CAPABILITY" command may return one or more of 112 the capabilities defined in this document. 114 4. UTF8 IMAP Capability 116 The basic "UTF8" capability indicates the server supports UTF-8 117 quoted strings and the UTF8 parameter to SELECT and EXAMINE. 119 4.1. IMAP UTF-8 Quoted Strings 121 The IMAP4rev1 [RFC3501] base specification forbids the use of 8-bit 122 characters in atoms or quoted strings. Thus a UTF-8 string can only 123 be sent as a literal. This can be inconvenient from a coding 124 standpoint, and unless the server offers IMAP4 non-synchronizing 125 literals [RFC2088], this requires an extra round trip for each UTF-8 126 string sent by the client. When the IMAP server advertises the 127 "UTF8" capability, it informs the client that it supports native 128 UTF-8 quoted-strings with the following syntax: 130 string =/ utf8-quoted 132 utf8-quoted = "*" DQUOTE *UQUOTED-CHAR DQUOTE 134 UQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4 135 ; UTF8-2, UTF8-3, and UTF8-4 are as defined in RFC 3629 137 When this quoting mechanism is used by the client (specifically an 138 octet sequence beginning with *" and ending with "), then the server 139 MUST reject octet sequences with the high bit set which fail to 140 comply with the formal syntax in [RFC3629] with a BAD response. 142 The IMAP server MUST NOT send utf8-quoted syntax to the client unless 143 the client has indicated support for that syntax by using the "ENABLE 144 UTF8" command. 146 If the UTF8 capability is advertised, then utf8-quoted syntax MAY be 147 used with any IMAP argument that permits a string or an astring. 148 However, if characters outside the US-ASCII repertoire are used in an 149 inappropriate place, the results would be the same as if other 150 syntacticly valid but semantically invalid characters were used. For 151 example, if the client includes UTF-8 characters in the user or 152 password arguments (and the server has not advertised UTF8-USER), the 153 LOGIN command will fail as it would with any other invalid user name 154 or password. Specific cases where UTF-8 characters are permitted or 155 not permitted are described in the following paragraphs. 157 All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP 158 servers which support the "Mailbox International Naming Convention" 159 described in RFC 3501 section 5.1.3 MUST accept utf8-quoted mailbox 160 names and convert them to the appropriate internal format. [TBD 161 stringprep for mailbox names? Can we reuse SASLprep?]. 163 IMAP servers MUST NOT accept UTF-8 characters when storing a new 164 message keyword, unless the mailbox is UTF-8 only, in which case IMAP 165 servers SHOULD accept UTF-8 in message keywords. [TBD stringprep for 166 message keywords? Can we reuse SASLprep?] 167 If an IMAP client issues a SEARCH command which uses a mixture of 168 utf8-quoted syntax and a SEARCH CHARSET other than UTF-8, then the 169 IMAP server SHOULD reject the command with a BAD response (due to the 170 conflicting charset labels). 172 4.2. UTF8 Parameter to SELECT and EXAMINE 174 The "UTF8" capability also indicates the server supports the UTF8 175 parameter to SELECT and EXAMINE. When a mailbox is selected with the 176 UTF8 parameter, it alters the behavior of all IMAP commands related 177 to message sizes, message headers and MIME body headers so they refer 178 to the message with UTF-8 headers. If the mailstore is not UTF-8 179 header native and the SELECT or EXAMINE command with UTF-8 header 180 modifier succeeds, then the server MUST return results as if the 181 mailstore was UTF-8 header native with upconversion requirements as 182 described in Section 9. The server MAY reject the SELECT or EXAMINE 183 command with the [NOT-UTF-8] response code, unless the UTF8=ALL or 184 UTF8=ONLY capability is advertised. 186 Servers MAY include mailboxes which can only be selected or examined 187 if the UTF8 parameter is provided. However, such mailboxes MUST NOT 188 be included in the output of an unextended LIST, LSUB or equivalent 189 command. If a client attempts to SELECT or EXAMINE such mailboxes 190 without the UTF8 parameter, the server MUST reject the command with a 191 [UTF-8-ONLY] response code. As a result, such mailboxes will not 192 accessible by IMAP clients written prior to this specification and 193 are discouraged unless the server advertises UTF8=ONLY or the server 194 implements IMAP4 LIST Command Extensions 195 [I-D.ietf-imapext-list-extensions]. 197 TBD: describe syntax based on draft-melnikov-imap-ext-abnf-05. 199 C: a SELECT newmailbox (UTF8) 200 S: ... 201 S: a OK SELECT completed 202 C: b FETCH 1 (SIZE ENVELOPE BODY) 203 S: ... < UTF-8 header native results > 204 S: b OK FETCH completed 206 C: c EXAMINE legacymailbox (UTF8) 207 S: c NO [NOT-UTF-8] Mailbox does not support UTF-8 access 209 C: d SELECT funky-new-mailbox 210 S: d NO [UTF-8-ONLY] Mailbox requires UTF-8 client 212 4.3. UTF-8 LIST and LSUB Responses 214 If an IMAP client has used utf8-quoted syntax prior to the server's 215 production of LIST results, then the server MUST NOT return any 216 mailbox names to the client following the IMAP4 Mailbox International 217 Naming Convention. Instead, the server MUST return any mailbox names 218 with characters outside the US-ASCII repertorie using utf8-quoted 219 syntax. An IMAP client can force this behavior by issuing the LIST 220 or LSUB command as follows: 222 C: a LIST *"" % 223 S: 224 S: a OK LIST completed 225 C: a LSUB *"*" 226 S: 227 S: a OK LSUB completed 229 The IMAP4 Mailbox International Naming Convention has proved 230 problematic in the past, so the desire is to make this syntax 231 obsolete as quickly as possible. 233 4.4. UTF-8 Interaction with IMAP4 LIST Command Extensions 235 When an IMAP server advertises both the "UTF8" capability and the 236 "LIST-EXTENEDED" [I-D.ietf-imapext-list-extensions] capability, the 237 server MUST support the LIST extensions described in this section. 238 When an IMAP server advertises the UTF8=ONLY capability and the LIST- 239 EXTENDED capability, the server MUST reject these LIST extensions 240 with a BAD response. 242 4.4.1. UTF8 and UTF8ONLY LIST Selection Options 244 The UTF8 LIST selection option tells the server to include mailboxes 245 that only support UTF-8 headers in the output of the list command. 246 The UTF8ONLY LIST selection option tells the server to include all 247 mailboxes that support UTF-8 headers and to exclude mailboxes that 248 don't support UTF-8 headers. Note that UTF8ONLY implies UTF8 so it 249 is not necessary for the client to request both. Use of either 250 selection option will also result in UTF-8 mailbox names in the 251 result as described in Section 4.3. 253 4.4.2. UTF8 LIST Return Option 255 If the client supplies the UTF8 LIST return option, then the server 256 MUST include either the \NoUTF8 or the \UTF8Only mailbox attribute as 257 appropriate. The \NoUTF8 mailbox attribute indicates an attempt to 258 SELECT or EXAMINE that mailbox with the UTF8 parameter will fail with 259 a [NOT-UTF-8] response code. The \UTF8Only mailbox attribute 260 indicates an attempt to SELECT or EXAMINE that mailbox without the 261 UTF8 parameter will fail with a [UTF-8-ONLY] response code. Note 262 that computing this information may be expensive on some server 263 implementations so this return option should not be used unless 264 necessary. 266 The ABNF [I-D.crocker-rfc4234bis] for these LIST extensions follows: 268 list-select-independent-opt =/ "UTF8" / "UTF8ONLY" 270 mbox-list-oflag =/ "\NoUTF8" / "\UTF8Only" 272 return-option =/ "UTF8" 274 5. UTF8=APPEND Capability 276 If the UTF8=APPEND capability is advertised, then the server accepts 277 UTF-8 headers in the APPEND command message argument. A client which 278 sends a message with UTF-8 headers to the server MUST include the 279 UTF8 APPEND parameter. The ABNF for this APPEND parameter follows: 281 append-ext =/ "UTF8" 283 A server which advertises UTF8=APPEND has to comply with the 284 requirements of the IMAP base specification and RFC 2822 for message 285 fetching. Mechanisms for 7-bit downgrading to help comply with the 286 standards are discussed in Downgrading mechanism for 287 Internationalized eMail Address (IMA) [I-D.ietf-eai-downgrade]. 289 IMAP servers which do not advertise the UTF8=APPEND or UTF8=ONLY 290 capability SHOULD reject an APPEND command which includes any 8-bit 291 in the message headers with a "NO" response. 293 6. UTF8=USER Capability 295 If the UTF8=USER capability is advertised, that indicates the server 296 accepts UTF-8 user names and passwords and applies SASLprep [RFC4013] 297 to both arguments of the LOGIN command. The server MUST reject UTF-8 298 which fails to comply with the formal syntax in RFC 3629 [RFC3629]. 300 7. UTF8=ALL Capability 302 This capability indicates all server mailboxes support UTF-8 headers. 303 Specifically, SELECT and EXAMINE with the UTF8 parameter will never 304 fail with a [NOT-UTF-8] response token. 306 8. UTF8=ONLY Capability 308 This capability permits an IMAP server to advertise that it does not 309 support the international mailbox name convention (modified UTF-7), 310 and does not permit selection or examination of any mailbox unless 311 the UTF8 parameter is provided. As this is an incompatible change to 312 IMAP, a clear warning is necessary. IMAP clients which find 313 implementation of the UTF8 capability problematic are encouraged to 314 at least detect the UTF8=ONLY capability and provide an informative 315 error message to the end-user. 317 When an IMAP mailbox internally uses UTF-8 header native storage, the 318 down-conversion step necessary to permit selection or examination of 319 the mailbox in a backwards compatible fashion will become more 320 difficult to support. Although it is hoped deployed IMAP servers do 321 not advertise UTF8=ONLY for some years, this capability is intended 322 to minimize the disruption when legacy support finally goes away. 324 The UTF8=ONLY capability implies the UTF8 base capability, the 325 UTF8=ALL capability and the UTF8=APPEND capability. A server which 326 advertises UTF8=ONLY need not advertise the three implicit 327 capabilities. 329 9. Up-Conversion Server Requirements 331 When an IMAP4 server uses a traditional mailbox format that includes 332 7-bit headers and it chooses to permit access to that mailbox with 333 the UTF8 parameter, it MUST support minimal up-conversion as 334 described in this section. Minimal up-conversion is described in 335 this section. 337 The server MUST support up-conversion of the following address 338 header-fields in the message header: From, Sender, To, CC, Bcc, 339 Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and 340 Reply-To. This up-conversion MUST include address local-parts 341 encoded according to [TBD], address domains encoded according to IDNA 342 [RFC3490], and MIME header encoding [RFC2047] of display-names and 343 any RFC 2822 comments. 345 The following charsets MUST be supported for up-conversion of MIME 346 header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2, 347 ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, 348 ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15. 349 Other widely deployed MIME charsets SHOULD be supported. 351 Up-conversion of MIME header encoding of the following headers MUST 352 also be implemented: Subject, Date (RFC 2822 comments only), 353 Comments, Keywords, Content-Description. 355 Server implementations also SHOULD up-convert all MIME body headers, 356 SHOULD up-convert or remove the deprecated (and misused) name 357 parameter [RFC1341] on Content-Type and MUST up-convert the Content- 358 Disposition filename parameter. These parameters can be encoded 359 using the standard MIME parameter encoding [RFC2231] mechanism, or 360 via non-standard use of MIME header encoding [RFC2047] in quoted 361 strings. 363 The IMAP server MUST NOT perform up-conversion of headers and content 364 of multipart/signed, as well as Original-Recipient and Return-Path. 366 10. Issues with UTF-8 Header Mailstore 368 When an IMAP server uses a mailbox format that supports UTF-8 headers 369 and it permits selection or examination of that mailbox without the 370 UTF8 parameter, it is the responsibility of the server to comply with 371 the IMAP4rev1 [RFC3501] base specification and RFC 2822 372 [I-D.resnick-2822upd] with respect to all header information 373 transmitted over the wire. Mechanisms for 7-bit downgrading to help 374 comply with the standards are discussed in Downgrading mechanism for 375 Internationalized eMail Address (IMA) [I-D.ietf-eai-downgrade]. 377 An IMAP server with a mailbox that supports UTF-8 headers MUST comply 378 with the protocol requirements implicit from Section 9. However, the 379 code necessary for such compliance need not be part of the IMAP 380 server itself in this case. For example, the minimal required up- 381 conversion could be performed when a message is inserted into the 382 IMAP-accessible mailbox. 384 11. IANA Considerations 386 This adds five new capabilities ("UTF8", "UTF8=USER", "UTF8=APPEND", 387 "UTF8=ALL", "UTF8=ONLY") to the IMAP4rev1 capability registry 388 [RFC3501]. 390 This adds two new IMAP4 list selection options and one new IMAP4 list 391 return option. 393 1. LIST-EXTENDED option name: UTF8 395 LIST-EXTENDED option type: SELECTION 397 Implied return options(s): none 398 LIST-EXTENDED option description: Causes the LIST response to 399 include mailboxes which mandate the UTF8 SELECT/EXAMINE 400 parameter. 402 Published specification: RFC XXXX, Section 4.4.1 404 Security considerations: RFC XXXX, Section 12 406 Intended usage: COMMON 408 Person an email address to contact for further information: see 409 Authors' Addresses at the end of this specification 411 Owner/Change controller: iesg@ietf.org 413 2. LIST-EXTENDED option name: UTF8ONLY 415 LIST-EXTENDED option type: SELECTION 417 Implied return options(s): none 419 LIST-EXTENDED option description: Causes the LIST response to 420 include mailboxes which mandate the UTF8 SELECT/EXAMINE parameter 421 and exclude mailboxes which do not support the UTF8 SELECT/ 422 EXAMINE parameter. 424 Published specification: RFC XXXX, Section 4.4.1 426 Security considerations: RFC XXXX, Section 12 428 Intended usage: COMMON 430 Person an email address to contact for further information: see 431 Authors' Addresses at the end of this specification 433 Owner/Change controller: iesg@ietf.org 435 3. LIST-EXTENDED option name: UTF8 437 LIST-EXTENDED option type: RETURN 439 Implied return options(s): none 441 LIST-EXTENDED option description: Causes the LIST response to 442 include \NoUTF8 and \UTF8Only mailbox attributes. 444 Published specification: RFC XXXX, Section 4.4.1 445 Security considerations: RFC XXXX, Section 12 447 Intended usage: COMMON 449 Person an email address to contact for further information: see 450 Authors' Addresses at the end of this specification 452 Owner/Change controller: iesg@ietf.org 454 12. Security Considerations 456 The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] 457 apply to this specification, particularly with respect to use of 458 UTF-8 in user names and passwords. Otherwise, this is not believed 459 to alter the security considerations of IMAP4rev1. 461 13. References 463 13.1. Normative References 465 [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 466 Mail Extensions): Mechanisms for Specifying and Describing 467 the Format of Internet Message Bodies", RFC 1341, 468 June 1992. 470 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 471 "Security Multiparts for MIME: Multipart/Signed and 472 Multipart/Encrypted", RFC 1847, October 1995. 474 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 475 Extensions (MIME) Part One: Format of Internet Message 476 Bodies", RFC 2045, November 1996. 478 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 479 Part Three: Message Header Extensions for Non-ASCII Text", 480 RFC 2047, November 1996. 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 486 Presentation Information in Internet Messages: The 487 Content-Disposition Header Field", RFC 2183, August 1997. 489 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 490 Word Extensions: 492 Character Sets, Languages, and Continuations", RFC 2231, 493 November 1997. 495 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 496 "Internationalizing Domain Names in Applications (IDNA)", 497 RFC 3490, March 2003. 499 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 500 4rev1", RFC 3501, March 2003. 502 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 503 10646", STD 63, RFC 3629, November 2003. 505 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 506 and Passwords", RFC 4013, February 2005. 508 [I-D.crocker-rfc4234bis] 509 Crocker, D. and P. Overell, "Augmented BNF for Syntax 510 Specifications: ABNF", draft-crocker-rfc4234bis-01 (work 511 in progress), October 2007. 513 [I-D.ietf-eai-utf8headers] 514 Yeh, J., "Internationalized Email Headers", 515 draft-ietf-eai-utf8headers-07 (work in progress), 516 September 2007. 518 [I-D.ietf-imapext-list-extensions] 519 Leiba, B. and A. Melnikov, "IMAP4 LIST Command 520 Extensions", draft-ietf-imapext-list-extensions-18 (work 521 in progress), September 2006. 523 [I-D.gulbrandsen-imap-enable] 524 Gulbrandsen, A., "The IMAP ENABLE Extension", 525 draft-gulbrandsen-imap-enable-03 (work in progress), 526 August 2007. 528 [I-D.resnick-2822upd] 529 Resnick, P., "Internet Message Format", 530 draft-resnick-2822upd-03 (work in progress), October 2007. 532 13.2. Informative References 534 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 535 Extensions (MIME) Part Five: Conformance Criteria and 536 Examples", RFC 2049, November 1996. 538 [RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 539 January 1997. 541 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 542 Languages", BCP 18, RFC 2277, January 1998. 544 [I-D.newman-ima-pop] 545 Newman, C., "POP3 Support for UTF-8", 546 draft-newman-ima-pop-00 (work in progress), February 2006. 548 [I-D.ietf-eai-downgrade] 549 Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for 550 Email Address Internationalization", 551 draft-ietf-eai-downgrade-05 (work in progress), 552 November 2007. 554 Appendix A. Design Rationale 556 This non-normative section discusses the reasons behind some of the 557 design choices in the above specification. 559 The basic approach of advertising the ability to access a mailbox in 560 UTF-8 mode is intended to permit graceful upgrade, including servers 561 which support multiple mailbox formats. In particular, it would be 562 undesirable to force conversion of an entire server mailstore to 563 UTF-8 headers, so being able to phase-in support for new mailboxes 564 and gradually migrate old mailboxes is permitted by this design. 566 UTF8=USER is optional because many identity systems are US-ASCII 567 only, so it's helpful to inform the client up-front that UTF-8 won't 568 work. 570 UTF8=APPEND is optional because it effectively requires IMAP server 571 support for down-conversion which is a much more complex operation 572 than up-conversion. 574 The UTF8=ONLY mechanism simplifies diagnosis of interoperability 575 problems when legacy support goes away. In the situation where 576 backwards compatibility is broken anyway, just-send-UTF-8 IMAP has 577 the advantage that it might work with some legacy clients. However, 578 the difficulty of diagnosing interoperability problems caused by a 579 just-send-UTF-8 IMAP mechanism is the reason the UTF8=ONLY capability 580 mechanism was chosen. 582 The up-conversion requirements are designed to balance the desire to 583 deprecate and eventually eliminate complicated encodings (like MIME 584 header encodings) without creating a significant deployment burden 585 for servers. As IMAP4 servers already require a MIME parser, this 586 includes additional server up-conversion requirements not present in 587 POP3 Support for UTF-8 [I-D.newman-ima-pop]. 589 The set of mandatory charsets comes from two sources: MIME 590 requirements [RFC2049] and IETF Policy on Character Sets [RFC2277]. 591 Including a requirement to up-convert widely deployed encoded 592 ideographic charsets to UTF-8 would be reasonable for most scenarios, 593 but may require unacceptable table sizes for some embedded devices. 594 The open-ended recommendation to support widely deployed charsets 595 avoids the political ramifications of attempting to list such 596 charsets. The authors believe market forces, existing open-source 597 software, and public conversion tables are sufficient to deploy the 598 appropriate charsets. 600 Appendix B. Acknowledgments 602 TBD. 604 Authors' Addresses 606 Pete Resnick 607 Qualcomm Incorporated 608 5775 Morehouse Drive 609 San Diego, CA 92121-1714 610 US 612 Phone: +1 858 651 4478 613 Email: presnick@qualcomm.com 614 URI: http://www.qualcomm.com/~presnick/ 616 Chris Newman 617 Sun Microsystems 618 3401 Centrelake Dr., Suite 410 619 Ontario, CA 91761 620 US 622 Email: chris.newman@sun.com 624 Full Copyright Statement 626 Copyright (C) The IETF Trust (2007). 628 This document is subject to the rights, licenses and restrictions 629 contained in BCP 78, and except as set forth therein, the authors 630 retain all their rights. 632 This document and the information contained herein are provided on an 633 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 634 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 635 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 636 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 637 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 638 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 640 Intellectual Property 642 The IETF takes no position regarding the validity or scope of any 643 Intellectual Property Rights or other rights that might be claimed to 644 pertain to the implementation or use of the technology described in 645 this document or the extent to which any license under such rights 646 might or might not be available; nor does it represent that it has 647 made any independent effort to identify any such rights. Information 648 on the procedures with respect to rights in RFC documents can be 649 found in BCP 78 and BCP 79. 651 Copies of IPR disclosures made to the IETF Secretariat and any 652 assurances of licenses to be made available, or the result of an 653 attempt made to obtain a general license or permission for the use of 654 such proprietary rights by implementers or users of this 655 specification can be obtained from the IETF on-line IPR repository at 656 http://www.ietf.org/ipr. 658 The IETF invites any interested party to bring to its attention any 659 copyrights, patents or patent applications, or other proprietary 660 rights that may cover technology that may be required to implement 661 this standard. Please address the information to the IETF at 662 ietf-ipr@ietf.org. 664 Acknowledgment 666 Funding for the RFC Editor function is provided by the IETF 667 Administrative Support Activity (IASA).