idnits 2.17.1 draft-ietf-eai-imap-utf8-04.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 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 629. 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 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 3, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'NOT-UTF-8' is mentioned on line 283, but not defined == Missing Reference: 'UTF-8-ONLY' is mentioned on line 238, but not defined == Missing Reference: 'TBD' is mentioned on line 319, but not defined == Unused Reference: 'RFC2045' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC2183' is defined on line 459, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1341 (Obsoleted by RFC 1521) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 5335 (Obsoleted by RFC 6532) -- Obsolete informational reference (is this intentional?): RFC 2088 (Obsoleted by RFC 7888) == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-09 == Outdated reference: A later version (-09) exists of draft-ietf-eai-pop-04 Summary: 6 errors (**), 0 flaws (~~), 9 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 Intended status: Experimental Sun Microsystems 6 Expires: May 7, 2009 November 3, 2008 8 IMAP Support for UTF-8 9 draft-ietf-eai-imap-utf8-04 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 7, 2009. 36 Abstract 38 This specification extends the Internet Message Access Protocol 39 version 4rev1 (IMAP4rev1) to support unencoded international 40 characters in user names, mail addresses and message headers. This 41 is an early draft and intended as a framework for discussion. Please 42 do not deploy implementations of this draft. 44 Table of Contents 46 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 47 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. UTF8 IMAP Capability . . . . . . . . . . . . . . . . . . . . . 3 49 3.1. IMAP UTF-8 Quoted Strings . . . . . . . . . . . . . . . . 3 50 3.2. UTF8 Parameter to SELECT and EXAMINE . . . . . . . . . . . 4 51 3.3. UTF-8 LIST and LSUB Responses . . . . . . . . . . . . . . 5 52 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions . . . 6 53 3.4.1. UTF8 and UTF8ONLY LIST Selection Options . . . . . . . 6 54 3.4.2. UTF8 LIST Return Option . . . . . . . . . . . . . . . 6 55 4. UTF8=APPEND Capability . . . . . . . . . . . . . . . . . . . . 6 56 5. UTF8=USER Capability . . . . . . . . . . . . . . . . . . . . . 7 57 6. UTF8=ALL Capability . . . . . . . . . . . . . . . . . . . . . 7 58 7. UTF8=ONLY Capability . . . . . . . . . . . . . . . . . . . . . 7 59 8. Up-Conversion Server Requirements . . . . . . . . . . . . . . 8 60 9. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 8 61 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 65 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 66 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 12 67 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 69 Intellectual Property and Copyright Statements . . . . . . . . . . 15 71 1. Conventions Used in this Document 73 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 74 in this document are to be interpreted as defined in "Key words for 75 use in RFCs to Indicate Requirement Levels" [RFC2119]. 77 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] 78 notation including the core rules defined in Appendix B of RFC 4234. 79 In addition, rules from IMAP4rev1 [RFC3501], UTF-8 [RFC3629], 80 Collected extensions to IMAP4 ABNF [RFC4466], and IMAP4 LIST Command 81 Extensions [RFC5258] are also referenced. 83 In examples, "C:" and "S:" indicate lines sent by the client and 84 server respectively. If a single "C:" or "S:" label applies to 85 multiple lines, then the line breaks between those lines are for 86 editorial clarity only and are not part of the actual protocol 87 exchange. 89 2. Introduction 91 This specification extends IMAP4rev1 [RFC3501] to permit unencoded 92 UTF-8 [RFC3629] in headers as described in Internationalized Email 93 Headers [RFC5335]. It also adds a mechanism to support mailbox 94 names, login names and passwords using the UTF-8 charset. 96 3. UTF8 IMAP Capability 98 The basic "UTF8" capability indicates the server supports UTF-8 99 quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8 100 responses from the LIST and LSUB commands. 102 A client MUST use the "ENABLE UTF8" command (defined in [RFC5161]) to 103 indicate to the server that the client accepts UTF-8 quoted-strings. 104 The "ENABLE UTF8" command MUST only be used in the authenticated 105 state. 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 [RFC3629] with a BAD response. 130 The IMAP server MUST NOT send utf8-quoted syntax to the client unless 131 the client has indicated support for that syntax by using the "ENABLE 132 UTF8" command. 134 If the UTF8 capability is advertised, then utf8-quoted syntax MAY be 135 used with any IMAP argument that permits a string or an astring. 136 However, if characters outside the US-ASCII repertoire are used in an 137 inappropriate place, the results would be the same as if other 138 syntacticly valid but semantically invalid characters were used. For 139 example, if the client includes UTF-8 characters in the user or 140 password arguments (and the server has not advertised UTF8-USER), the 141 LOGIN command will fail as it would with any other invalid user name 142 or password. Specific cases where UTF-8 characters are permitted or 143 not permitted are described in the following paragraphs. 145 All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP 146 servers which support the "Mailbox International Naming Convention" 147 described in RFC 3501 section 5.1.3 MUST accept utf8-quoted mailbox 148 names and convert them to the appropriate internal format. [TBD 149 stringprep for mailbox names? Can we reuse SASLprep?]. 151 IMAP servers MUST NOT accept UTF-8 characters when storing a new 152 message keyword, unless the mailbox is UTF-8 only, in which case IMAP 153 servers SHOULD accept UTF-8 in message keywords. [TBD stringprep for 154 message keywords? Can we reuse SASLprep?] 156 If an IMAP client issues a SEARCH command which uses a mixture of 157 utf8-quoted syntax and a SEARCH CHARSET other than UTF-8, then the 158 IMAP server SHOULD reject the command with a BAD response (due to the 159 conflicting charset labels). 161 3.2. UTF8 Parameter to SELECT and EXAMINE 163 The "UTF8" capability also indicates the server supports the UTF8 164 parameter to SELECT and EXAMINE. When a mailbox is selected with the 165 UTF8 parameter, it alters the behavior of all IMAP commands related 166 to message sizes, message headers and MIME body headers so they refer 167 to the message with UTF-8 headers. If the mailstore is not UTF-8 168 header native and the SELECT or EXAMINE command with UTF-8 header 169 modifier succeeds, then the server MUST return results as if the 170 mailstore was UTF-8 header native with upconversion requirements as 171 described in Section 8. The server MAY reject the SELECT or EXAMINE 172 command with the [NOT-UTF-8] response code, unless the UTF8=ALL or 173 UTF8=ONLY capability is advertised. 175 Servers MAY include mailboxes which can only be selected or examined 176 if the UTF8 parameter is provided. However, such mailboxes MUST NOT 177 be included in the output of an unextended LIST, LSUB or equivalent 178 command. If a client attempts to SELECT or EXAMINE such mailboxes 179 without the UTF8 parameter, the server MUST reject the command with a 180 [UTF-8-ONLY] response code. As a result, such mailboxes will not 181 accessible by IMAP clients written prior to this specification and 182 are discouraged unless the server advertises UTF8=ONLY or the server 183 implements IMAP4 LIST Command Extensions [RFC5258]. 185 TBD: describe syntax based on draft-melnikov-imap-ext-abnf-05. 187 C: a SELECT newmailbox (UTF8) 188 S: ... 189 S: a OK SELECT completed 190 C: b FETCH 1 (SIZE ENVELOPE BODY) 191 S: ... < UTF-8 header native results > 192 S: b OK FETCH completed 194 C: c EXAMINE legacymailbox (UTF8) 195 S: c NO [NOT-UTF-8] Mailbox does not support UTF-8 access 197 C: d SELECT funky-new-mailbox 198 S: d NO [UTF-8-ONLY] Mailbox requires UTF-8 client 200 3.3. UTF-8 LIST and LSUB Responses 202 After an IMAP client successfully issues an "ENABLE UTF8" command, 203 the server MUST NOT return in LIST results any mailbox names to the 204 client following the IMAP4 Mailbox International Naming Convention. 205 Instead, the server MUST return any mailbox names with characters 206 outside the US-ASCII repertorie using utf8-quoted syntax. (The IMAP4 207 Mailbox International Naming Convention has proved problematic in the 208 past, so the desire is to make this syntax obsolete as quickly as 209 possible.) 211 3.4. UTF-8 Interaction with IMAP4 LIST Command Extensions 213 When an IMAP server advertises both the "UTF8" capability and the 214 "LIST-EXTENEDED" [RFC5258] capability, the server MUST support the 215 LIST extensions described in this section. When an IMAP server 216 advertises the UTF8=ONLY capability and the LIST-EXTENDED capability, 217 the server MUST reject these LIST extensions with a BAD response. 219 3.4.1. UTF8 and UTF8ONLY LIST Selection Options 221 The UTF8 LIST selection option tells the server to include mailboxes 222 that only support UTF-8 headers in the output of the list command. 223 The UTF8ONLY LIST selection option tells the server to include all 224 mailboxes that support UTF-8 headers and to exclude mailboxes that 225 don't support UTF-8 headers. Note that UTF8ONLY implies UTF8 so it 226 is not necessary for the client to request both. Use of either 227 selection option will also result in UTF-8 mailbox names in the 228 result as described in Section 3.3. 230 3.4.2. UTF8 LIST Return Option 232 If the client supplies the UTF8 LIST return option, then the server 233 MUST include either the \NoUTF8 or the \UTF8Only mailbox attribute as 234 appropriate. The \NoUTF8 mailbox attribute indicates an attempt to 235 SELECT or EXAMINE that mailbox with the UTF8 parameter will fail with 236 a [NOT-UTF-8] response code. The \UTF8Only mailbox attribute 237 indicates an attempt to SELECT or EXAMINE that mailbox without the 238 UTF8 parameter will fail with a [UTF-8-ONLY] response code. Note 239 that computing this information may be expensive on some server 240 implementations so this return option should not be used unless 241 necessary. 243 The ABNF [RFC5234] for these LIST extensions follows: 245 list-select-independent-opt =/ "UTF8" / "UTF8ONLY" 247 mbox-list-oflag =/ "\NoUTF8" / "\UTF8Only" 249 return-option =/ "UTF8" 251 resp-text-code =/ "NOT-UTF-8" / "UTF-8-ONLY" 253 4. UTF8=APPEND Capability 255 If the UTF8=APPEND capability is advertised, then the server accepts 256 UTF-8 headers in the APPEND command message argument. A client which 257 sends a message with UTF-8 headers to the server MUST include the 258 UTF8 APPEND parameter. The ABNF for this APPEND parameter follows: 260 append-ext =/ "UTF8" 262 A server which advertises UTF8=APPEND has to comply with the 263 requirements of the IMAP base specification and [RFC5322] for message 264 fetching. Mechanisms for 7-bit downgrading to help comply with the 265 standards are discussed in Downgrading mechanism for 266 Internationalized eMail Address (IMA) [I-D.ietf-eai-downgrade]. 268 IMAP servers which do not advertise the UTF8=APPEND or UTF8=ONLY 269 capability SHOULD reject an APPEND command which includes any 8-bit 270 in the message headers with a "NO" response. 272 5. UTF8=USER Capability 274 If the UTF8=USER capability is advertised, that indicates the server 275 accepts UTF-8 user names and passwords and applies SASLprep [RFC4013] 276 to both arguments of the LOGIN command. The server MUST reject UTF-8 277 which fails to comply with the formal syntax in RFC 3629 [RFC3629]. 279 6. UTF8=ALL Capability 281 This capability indicates all server mailboxes support UTF-8 headers. 282 Specifically, SELECT and EXAMINE with the UTF8 parameter will never 283 fail with a [NOT-UTF-8] response token. 285 7. UTF8=ONLY Capability 287 This capability permits an IMAP server to advertise that it does not 288 support the international mailbox name convention (modified UTF-7), 289 and does not permit selection or examination of any mailbox unless 290 the UTF8 parameter is provided. As this is an incompatible change to 291 IMAP, a clear warning is necessary. IMAP clients which find 292 implementation of the UTF8 capability problematic are encouraged to 293 at least detect the UTF8=ONLY capability and provide an informative 294 error message to the end-user. 296 When an IMAP mailbox internally uses UTF-8 header native storage, the 297 down-conversion step necessary to permit selection or examination of 298 the mailbox in a backwards compatible fashion will become more 299 difficult to support. Although it is hoped deployed IMAP servers do 300 not advertise UTF8=ONLY for some years, this capability is intended 301 to minimize the disruption when legacy support finally goes away. 303 The UTF8=ONLY capability implies the UTF8 base capability, the 304 UTF8=ALL capability and the UTF8=APPEND capability. A server which 305 advertises UTF8=ONLY need not advertise the three implicit 306 capabilities. 308 8. Up-Conversion Server Requirements 310 When an IMAP4 server uses a traditional mailbox format that includes 311 7-bit headers and it chooses to permit access to that mailbox with 312 the UTF8 parameter, it MUST support minimal up-conversion as 313 described in this section. 315 The server MUST support up-conversion of the following address 316 header-fields in the message header: From, Sender, To, CC, Bcc, 317 Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and 318 Reply-To. This up-conversion MUST include address local-parts 319 encoded according to [TBD], address domains encoded according to IDNA 320 [RFC3490], and MIME header encoding [RFC2047] of display-names and 321 any [RFC5322] comments. 323 The following charsets MUST be supported for up-conversion of MIME 324 header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2, 325 ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, 326 ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15. 327 Other widely deployed MIME charsets SHOULD be supported. 329 Up-conversion of MIME header encoding of the following headers MUST 330 also be implemented: Subject, Date ([RFC5322] comments only), 331 Comments, Keywords, Content-Description. 333 Server implementations also SHOULD up-convert all MIME body headers, 334 SHOULD up-convert or remove the deprecated (and misused) name 335 parameter [RFC1341] on Content-Type and MUST up-convert the Content- 336 Disposition filename parameter. These parameters can be encoded 337 using the standard MIME parameter encoding [RFC2231] mechanism, or 338 via non-standard use of MIME header encoding [RFC2047] in quoted 339 strings. 341 The IMAP server MUST NOT perform up-conversion of headers and content 342 of multipart/signed, as well as Original-Recipient and Return-Path. 344 9. Issues with UTF-8 Header Mailstore 346 When an IMAP server uses a mailbox format that supports UTF-8 headers 347 and it permits selection or examination of that mailbox without the 348 UTF8 parameter, it is the responsibility of the server to comply with 349 the IMAP4rev1 [RFC3501] base specification and [RFC5322] with respect 350 to all header information transmitted over the wire. Mechanisms for 351 7-bit downgrading to help comply with the standards are discussed in 352 Downgrading mechanism for Internationalized eMail Address (IMA) 353 [I-D.ietf-eai-downgrade]. 355 An IMAP server with a mailbox that supports UTF-8 headers MUST comply 356 with the protocol requirements implicit from Section 8. However, the 357 code necessary for such compliance need not be part of the IMAP 358 server itself in this case. For example, the minimal required up- 359 conversion could be performed when a message is inserted into the 360 IMAP-accessible mailbox. 362 10. IANA Considerations 364 This adds five new capabilities ("UTF8", "UTF8=USER", "UTF8=APPEND", 365 "UTF8=ALL", "UTF8=ONLY") to the IMAP4rev1 capability registry 366 [RFC3501]. 368 This adds two new IMAP4 list selection options and one new IMAP4 list 369 return option. 371 1. LIST-EXTENDED option name: UTF8 373 LIST-EXTENDED option type: SELECTION 375 Implied return options(s): UTF8 377 LIST-EXTENDED option description: Causes the LIST response to 378 include mailboxes which mandate the UTF8 SELECT/EXAMINE 379 parameter. 381 Published specification: RFC XXXX, Section 3.4.1 383 Security considerations: RFC XXXX, Section 11 385 Intended usage: COMMON 387 Person an email address to contact for further information: see 388 Authors' Addresses at the end of this specification 390 Owner/Change controller: iesg@ietf.org 392 2. LIST-EXTENDED option name: UTF8ONLY 394 LIST-EXTENDED option type: SELECTION 395 Implied return options(s): UTF8 397 LIST-EXTENDED option description: Causes the LIST response to 398 include mailboxes which mandate the UTF8 SELECT/EXAMINE parameter 399 and exclude mailboxes which do not support the UTF8 SELECT/ 400 EXAMINE parameter. 402 Published specification: RFC XXXX, Section 3.4.1 404 Security considerations: RFC XXXX, Section 11 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 3. LIST-EXTENDED option name: UTF8 415 LIST-EXTENDED option type: RETURN 417 Implied return options(s): none 419 LIST-EXTENDED option description: Causes the LIST response to 420 include \NoUTF8 and \UTF8Only mailbox attributes. 422 Published specification: RFC XXXX, Section 3.4.1 424 Security considerations: RFC XXXX, Section 11 426 Intended usage: COMMON 428 Person an email address to contact for further information: see 429 Authors' Addresses at the end of this specification 431 Owner/Change controller: iesg@ietf.org 433 11. Security Considerations 435 The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] 436 apply to this specification, particularly with respect to use of 437 UTF-8 in user names and passwords. Otherwise, this is not believed 438 to alter the security considerations of IMAP4rev1. 440 12. References 441 12.1. Normative References 443 [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 444 Mail Extensions): Mechanisms for Specifying and Describing 445 the Format of Internet Message Bodies", RFC 1341, 446 June 1992. 448 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 449 Extensions (MIME) Part One: Format of Internet Message 450 Bodies", RFC 2045, November 1996. 452 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 453 Part Three: Message Header Extensions for Non-ASCII Text", 454 RFC 2047, November 1996. 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 460 Presentation Information in Internet Messages: The 461 Content-Disposition Header Field", RFC 2183, August 1997. 463 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 464 Word Extensions: 465 Character Sets, Languages, and Continuations", RFC 2231, 466 November 1997. 468 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 469 "Internationalizing Domain Names in Applications (IDNA)", 470 RFC 3490, March 2003. 472 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 473 4rev1", RFC 3501, March 2003. 475 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 476 10646", STD 63, RFC 3629, November 2003. 478 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 479 and Passwords", RFC 4013, February 2005. 481 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 482 ABNF", RFC 4466, April 2006. 484 [RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE 485 Extension", RFC 5161, March 2008. 487 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 488 Specifications: ABNF", STD 68, RFC 5234, January 2008. 490 [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access 491 Protocol version 4 - LIST Command Extensions", RFC 5258, 492 June 2008. 494 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 495 October 2008. 497 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, 498 September 2008. 500 12.2. Informative References 502 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 503 Extensions (MIME) Part Five: Conformance Criteria and 504 Examples", RFC 2049, November 1996. 506 [RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, 507 January 1997. 509 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 510 Languages", BCP 18, RFC 2277, January 1998. 512 [I-D.ietf-eai-downgrade] 513 Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for 514 Email Address Internationalization", 515 draft-ietf-eai-downgrade-09 (work in progress), 516 September 2008. 518 [I-D.ietf-eai-pop] 519 Newman, C. and R. Gellens, "POP3 Support for UTF-8", 520 draft-ietf-eai-pop-04 (work in progress), July 2008. 522 Appendix A. Design Rationale 524 This non-normative section discusses the reasons behind some of the 525 design choices in the above specification. 527 The basic approach of advertising the ability to access a mailbox in 528 UTF-8 mode is intended to permit graceful upgrade, including servers 529 which support multiple mailbox formats. In particular, it would be 530 undesirable to force conversion of an entire server mailstore to 531 UTF-8 headers, so being able to phase-in support for new mailboxes 532 and gradually migrate old mailboxes is permitted by this design. 534 UTF8=USER is optional because many identity systems are US-ASCII 535 only, so it's helpful to inform the client up-front that UTF-8 won't 536 work. 538 UTF8=APPEND is optional because it effectively requires IMAP server 539 support for down-conversion which is a much more complex operation 540 than up-conversion. 542 The UTF8=ONLY mechanism simplifies diagnosis of interoperability 543 problems when legacy support goes away. In the situation where 544 backwards compatibility is broken anyway, just-send-UTF-8 IMAP has 545 the advantage that it might work with some legacy clients. However, 546 the difficulty of diagnosing interoperability problems caused by a 547 just-send-UTF-8 IMAP mechanism is the reason the UTF8=ONLY capability 548 mechanism was chosen. 550 The up-conversion requirements are designed to balance the desire to 551 deprecate and eventually eliminate complicated encodings (like MIME 552 header encodings) without creating a significant deployment burden 553 for servers. As IMAP4 servers already require a MIME parser, this 554 includes additional server up-conversion requirements not present in 555 POP3 Support for UTF-8 [I-D.ietf-eai-pop]. 557 The set of mandatory charsets comes from two sources: MIME 558 requirements [RFC2049] and IETF Policy on Character Sets [RFC2277]. 559 Including a requirement to up-convert widely deployed encoded 560 ideographic charsets to UTF-8 would be reasonable for most scenarios, 561 but may require unacceptable table sizes for some embedded devices. 562 The open-ended recommendation to support widely deployed charsets 563 avoids the political ramifications of attempting to list such 564 charsets. The authors believe market forces, existing open-source 565 software, and public conversion tables are sufficient to deploy the 566 appropriate charsets. 568 Appendix B. Acknowledgments 570 TBD. 572 Authors' Addresses 574 Pete Resnick 575 Qualcomm Incorporated 576 5775 Morehouse Drive 577 San Diego, CA 92121-1714 578 US 580 Phone: +1 858 651 4478 581 Email: presnick@qualcomm.com 582 URI: http://www.qualcomm.com/~presnick/ 583 Chris Newman 584 Sun Microsystems 585 3401 Centrelake Dr., Suite 410 586 Ontario, CA 91761 587 US 589 Email: chris.newman@sun.com 591 Full Copyright Statement 593 Copyright (C) The IETF Trust (2008). 595 This document is subject to the rights, licenses and restrictions 596 contained in BCP 78, and except as set forth therein, the authors 597 retain all their rights. 599 This document and the information contained herein are provided on an 600 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 601 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 602 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 603 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 604 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 605 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 607 Intellectual Property 609 The IETF takes no position regarding the validity or scope of any 610 Intellectual Property Rights or other rights that might be claimed to 611 pertain to the implementation or use of the technology described in 612 this document or the extent to which any license under such rights 613 might or might not be available; nor does it represent that it has 614 made any independent effort to identify any such rights. Information 615 on the procedures with respect to rights in RFC documents can be 616 found in BCP 78 and BCP 79. 618 Copies of IPR disclosures made to the IETF Secretariat and any 619 assurances of licenses to be made available, or the result of an 620 attempt made to obtain a general license or permission for the use of 621 such proprietary rights by implementers or users of this 622 specification can be obtained from the IETF on-line IPR repository at 623 http://www.ietf.org/ipr. 625 The IETF invites any interested party to bring to its attention any 626 copyrights, patents or patent applications, or other proprietary 627 rights that may cover technology that may be required to implement 628 this standard. Please address the information to the IETF at 629 ietf-ipr@ietf.org.