imap/docs/rfc/rfc5738.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         P. Resnick
   8 Request for Comments: 5738                         Qualcomm Incorporated
   9 Updates: 3501                                                  C. Newman
  10 Category: Experimental                                  Sun Microsystems
  11                                                               March 2010
  12
  13
  14                          IMAP Support for UTF-8
  15
  16 Abstract
  17
  18    This specification extends the Internet Message Access Protocol
  19    version 4rev1 (IMAP4rev1) to support UTF-8 encoded international
  20    characters in user names, mail addresses, and message headers.
  21
  22 Status of This Memo
  23
  24    This document is not an Internet Standards Track specification; it is
  25    published for examination, experimental implementation, and
  26    evaluation.
  27
  28    This document defines an Experimental Protocol for the Internet
  29    community.  This document is a product of the Internet Engineering
  30    Task Force (IETF).  It represents the consensus of the IETF
  31    community.  It has received public review and has been approved for
  32    publication by the Internet Engineering Steering Group (IESG).  Not
  33    all documents approved by the IESG are a candidate for any level of
  34    Internet Standard; see Section 2 of RFC 5741.
  35
  36    Information about the current status of this document, any errata,
  37    and how to provide feedback on it may be obtained at
  38    http://www.rfc-editor.org/info/rfc5738.
  39
  40 Copyright Notice
  41
  42    Copyright (c) 2010 IETF Trust and the persons identified as the
  43    document authors.  All rights reserved.
  44
  45    This document is subject to BCP 78 and the IETF Trust's Legal
  46    Provisions Relating to IETF Documents
  47    (http://trustee.ietf.org/license-info) in effect on the date of
  48    publication of this document.  Please review these documents
  49    carefully, as they describe your rights and restrictions with respect
  50    to this document.  Code Components extracted from this document must
  51    include Simplified BSD License text as described in Section 4.e of
  52    the Trust Legal Provisions and are provided without warranty as
  53    described in the Simplified BSD License.
  54
  55
  56
  57
  58 Resnick & Newman              Experimental                      [Page 1]
  59 \f
  60 RFC 5738                 IMAP Support for UTF-8               March 2010
  61
  62
  63    This document may contain material from IETF Documents or IETF
  64    Contributions published or made publicly available before November
  65    10, 2008.  The person(s) controlling the copyright in some of this
  66    material may not have granted the IETF Trust the right to allow
  67    modifications of such material outside the IETF Standards Process.
  68    Without obtaining an adequate license from the person(s) controlling
  69    the copyright in such materials, this document may not be modified
  70    outside the IETF Standards Process, and derivative works of it may
  71    not be created outside the IETF Standards Process, except to format
  72    it for publication as an RFC or to translate it into languages other
  73    than English.
  74
  75 Table of Contents
  76
  77    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  78    2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
  79    3.  UTF8=ACCEPT IMAP Capability  . . . . . . . . . . . . . . . . .  3
  80      3.1.  IMAP UTF-8 Quoted Strings  . . . . . . . . . . . . . . . .  3
  81      3.2.  UTF8 Parameter to SELECT and EXAMINE . . . . . . . . . . .  5
  82      3.3.  UTF-8 LIST and LSUB Responses  . . . . . . . . . . . . . .  5
  83      3.4.  UTF-8 Interaction with IMAP4 LIST Command Extensions . . .  6
  84        3.4.1.  UTF8 and UTF8ONLY LIST Selection Options . . . . . . .  6
  85        3.4.2.  UTF8 LIST Return Option  . . . . . . . . . . . . . . .  6
  86    4.  UTF8=APPEND Capability . . . . . . . . . . . . . . . . . . . .  7
  87    5.  UTF8=USER Capability . . . . . . . . . . . . . . . . . . . . .  7
  88    6.  UTF8=ALL Capability  . . . . . . . . . . . . . . . . . . . . .  7
  89    7.  UTF8=ONLY Capability . . . . . . . . . . . . . . . . . . . . .  8
  90    8.  Up-Conversion Server Requirements  . . . . . . . . . . . . . .  8
  91    9.  Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . .  9
  92    10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
  93    11. Security Considerations  . . . . . . . . . . . . . . . . . . . 11
  94    12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
  95      12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
  96      12.2. Informative References . . . . . . . . . . . . . . . . . . 13
  97    Appendix A.  Design Rationale  . . . . . . . . . . . . . . . . . . 14
  98    Appendix B.  Examples Demonstrating Relationships between
  99                 UTF8= Capabilities  . . . . . . . . . . . . . . . . . 15
 100    Appendix C.  Acknowledgments . . . . . . . . . . . . . . . . . . . 15
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Resnick & Newman              Experimental                      [Page 2]
 115 \f
 116 RFC 5738                 IMAP Support for UTF-8               March 2010
 117
 118
 119 1.  Introduction
 120
 121    This specification extends IMAP4rev1 [RFC3501] to permit UTF-8
 122    [RFC3629] in headers as described in "Internationalized Email
 123    Headers" [RFC5335].  It also adds a mechanism to support mailbox
 124    names, login names, and passwords using the UTF-8 charset.  This
 125    specification creates five new IMAP capabilities to allow servers to
 126    advertise these new extensions, along with two new IMAP LIST
 127    selection options and a new IMAP LIST return option.
 128
 129 2.  Conventions Used in This Document
 130
 131    The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
 132    in this document are to be interpreted as defined in "Key words for
 133    use in RFCs to Indicate Requirement Levels" [RFC2119].
 134
 135    The formal syntax uses the Augmented Backus-Naur Form (ABNF)
 136    [RFC5234] notation including the core rules defined in Appendix B of
 137    [RFC5234].  In addition, rules from IMAP4rev1 [RFC3501], UTF-8
 138    [RFC3629], "Collected Extensions to IMAP4 ABNF" [RFC4466], and IMAP4
 139    LIST Command Extensions [RFC5258] are also referenced.
 140
 141    In examples, "C:" and "S:" indicate lines sent by the client and
 142    server, respectively.  If a single "C:" or "S:" label applies to
 143    multiple lines, then the line breaks between those lines are for
 144    editorial clarity only and are not part of the actual protocol
 145    exchange.
 146
 147 3.  UTF8=ACCEPT IMAP Capability
 148
 149    The "UTF8=ACCEPT" capability indicates that the server supports UTF-8
 150    quoted strings, the "UTF8" parameter to SELECT and EXAMINE, and UTF-8
 151    responses from the LIST and LSUB commands.
 152
 153    A client MUST use the "ENABLE UTF8=ACCEPT" command (defined in
 154    [RFC5161]) to indicate to the server that the client accepts UTF-8
 155    quoted-strings.  The "ENABLE UTF8=ACCEPT" command MUST only be used
 156    in the authenticated state.  (Note that the "UTF8=ONLY" capability
 157    described in Section 7 and the "UTF8=ALL" capability described in
 158    Section 6 imply the "UTF8=ACCEPT" capability.  See additional
 159    information in these sections.)
 160
 161 3.1.  IMAP UTF-8 Quoted Strings
 162
 163    The IMAP4rev1 [RFC3501] base specification forbids the use of 8-bit
 164    characters in atoms or quoted strings.  Thus, a UTF-8 string can only
 165    be sent as a literal.  This can be inconvenient from a coding
 166    standpoint, and unless the server offers IMAP4 non-synchronizing
 167
 168
 169
 170 Resnick & Newman              Experimental                      [Page 3]
 171 \f
 172 RFC 5738                 IMAP Support for UTF-8               March 2010
 173
 174
 175    literals [RFC2088], this requires an extra round trip for each UTF-8
 176    string sent by the client.  When the IMAP server advertises the
 177    "UTF8=ACCEPT" capability, it informs the client that it supports
 178    native UTF-8 quoted-strings with the following syntax:
 179
 180      string        =/ utf8-quoted
 181
 182      utf8-quoted   = "*" DQUOTE *UQUOTED-CHAR DQUOTE
 183
 184      UQUOTED-CHAR  = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4
 185                 ; UTF8-2, UTF8-3, and UTF8-4 are as defined in RFC 3629
 186
 187    When this quoting mechanism is used by the client (specifically an
 188    octet sequence beginning with *" and ending with "), then the server
 189    MUST reject octet sequences with the high bit set that fail to comply
 190    with the formal syntax in [RFC3629] with a BAD response.
 191
 192    The IMAP server MUST NOT send utf8-quoted syntax to the client unless
 193    the client has indicated support for that syntax by using the "ENABLE
 194    UTF8=ACCEPT" command.
 195
 196    If the server advertises the "UTF8=ACCEPT" capability, the client MAY
 197    use utf8-quoted syntax with any IMAP argument that permits a string
 198    (including astring and nstring).  However, if characters outside the
 199    US-ASCII repertoire are used in an inappropriate place, the results
 200    would be the same as if other syntactically valid but semantically
 201    invalid characters were used.  For example, if the client includes
 202    UTF-8 characters in the user or password arguments (and the server
 203    has not advertised "UTF8=USER"), the LOGIN command will fail as it
 204    would with any other invalid user name or password.  Specific cases
 205    where UTF-8 characters are permitted or not permitted are described
 206    in the following paragraphs.
 207
 208    All IMAP servers that advertise the "UTF8=ACCEPT" capability SHOULD
 209    accept UTF-8 in mailbox names, and those that also support the
 210    "Mailbox International Naming Convention" described in RFC 3501,
 211    Section 5.1.3 MUST accept utf8-quoted mailbox names and convert them
 212    to the appropriate internal format.  Mailbox names MUST comply with
 213    the Net-Unicode Definition (Section 2 of [RFC5198]) with the specific
 214    exception that they MUST NOT contain control characters (0000-001F,
 215    0080-009F), delete (007F), line separator (2028), or paragraph
 216    separator (2029).
 217
 218    An IMAP client MUST NOT issue a SEARCH command that uses a mixture of
 219    utf8-quoted syntax and a SEARCH CHARSET other than UTF-8.  If an IMAP
 220    server receives such a SEARCH command, it SHOULD reject the command
 221    with a BAD response (due to the conflicting charset labels).
 222
 223
 224
 225
 226 Resnick & Newman              Experimental                      [Page 4]
 227 \f
 228 RFC 5738                 IMAP Support for UTF-8               March 2010
 229
 230
 231 3.2.  UTF8 Parameter to SELECT and EXAMINE
 232
 233    The "UTF8=ACCEPT" capability also indicates that the server supports
 234    the "UTF8" parameter to SELECT and EXAMINE.  When a mailbox is
 235    selected with the "UTF8" parameter, it alters the behavior of all
 236    IMAP commands related to message sizes, message headers, and MIME
 237    body headers so they refer to the message with UTF-8 headers.  If the
 238    mailstore is not UTF-8 header native and the SELECT or EXAMINE
 239    command with UTF-8 header modifier succeeds, then the server MUST
 240    return results as if the mailstore were UTF-8 header native with
 241    upconversion requirements as described in Section 8.  The server MAY
 242    reject the SELECT or EXAMINE command with the [NOT-UTF-8] response
 243    code, unless the "UTF8=ALL" or "UTF8=ONLY" capability is advertised.
 244
 245    Servers MAY include mailboxes that can only be selected or examined
 246    if the "UTF8" parameter is provided.  However, such mailboxes MUST
 247    NOT be included in the output of an unextended LIST, LSUB, or
 248    equivalent command.  If a client attempts to SELECT or EXAMINE such
 249    mailboxes without the "UTF8" parameter, the server MUST reject the
 250    command with a [UTF-8-ONLY] response code.  As a result, such
 251    mailboxes will not be accessible by IMAP clients written prior to
 252    this specification and are discouraged unless the server advertises
 253    "UTF8=ONLY" or the server implements IMAP4 LIST Command Extensions
 254    [RFC5258].
 255
 256      utf8-select-param = "UTF8"
 257                ;; Conforms to <select-param> from RFC 4466
 258
 259      C: a SELECT newmailbox (UTF8)
 260      S: ...
 261      S: a OK SELECT completed
 262      C: b FETCH 1 (SIZE ENVELOPE BODY)
 263      S: ... < UTF-8 header native results >
 264      S: b OK FETCH completed
 265
 266      C: c EXAMINE legacymailbox (UTF8)
 267      S: c NO [NOT-UTF-8] Mailbox does not support UTF-8 access
 268
 269      C: d SELECT funky-new-mailbox
 270      S: d NO [UTF-8-ONLY] Mailbox requires UTF-8 client
 271
 272 3.3.  UTF-8 LIST and LSUB Responses
 273
 274    After an IMAP client successfully issues an "ENABLE UTF8=ACCEPT"
 275    command, the server MUST NOT return in LIST results any mailbox names
 276    to the client following the IMAP4 Mailbox International Naming
 277    Convention.  Instead, the server MUST return any mailbox names with
 278    characters outside the US-ASCII repertoire using utf8-quoted syntax.
 279
 280
 281
 282 Resnick & Newman              Experimental                      [Page 5]
 283 \f
 284 RFC 5738                 IMAP Support for UTF-8               March 2010
 285
 286
 287    (The IMAP4 Mailbox International Naming Convention has proved
 288    problematic in the past, so the desire is to make this syntax
 289    obsolete as quickly as possible.)
 290
 291 3.4.  UTF-8 Interaction with IMAP4 LIST Command Extensions
 292
 293    When an IMAP server advertises both the "UTF8=ACCEPT" capability and
 294    the "LIST-EXTENDED" [RFC5258] capability, the server MUST support the
 295    LIST extensions described in this section.
 296
 297 3.4.1.  UTF8 and UTF8ONLY LIST Selection Options
 298
 299    The "UTF8" LIST selection option tells the server to include
 300    mailboxes that only support UTF-8 headers in the output of the list
 301    command.  The "UTF8ONLY" LIST selection option tells the server to
 302    include all mailboxes that support UTF-8 headers and to exclude
 303    mailboxes that don't support UTF-8 headers.  Note that "UTF8ONLY"
 304    implies "UTF8", so it is not necessary for the client to request
 305    both.  Use of either selection option will also result in UTF-8
 306    mailbox names in the result as described in Section 3.3 and implies
 307    the "UTF8" List return option described in Section 3.4.2.
 308
 309 3.4.2.  UTF8 LIST Return Option
 310
 311    If the client supplies the "UTF8" LIST return option, then the server
 312    MUST include either the "\NoUTF8" or the "\UTF8Only" mailbox
 313    attribute as appropriate.  The "\NoUTF8" mailbox attribute indicates
 314    that an attempt to SELECT or EXAMINE that mailbox with the "UTF8"
 315    parameter will fail with a [NOT-UTF-8] response code.  The
 316    "\UTF8Only" mailbox attribute indicates that an attempt to SELECT or
 317    EXAMINE that mailbox without the "UTF8" parameter will fail with a
 318    [UTF-8-ONLY] response code.  Note that computing this information may
 319    be expensive on some server implementations, so this return option
 320    should not be used unless necessary.
 321
 322    The ABNF [RFC5234] for these LIST extensions follows:
 323
 324      list-select-independent-opt =/ "UTF8"
 325
 326      list-select-base-opt        =/ "UTF8ONLY"
 327
 328      mbx-list-oflag              =/ "\NoUTF8" / "\UTF8Only"
 329
 330      return-option               =/ "UTF8"
 331
 332      resp-text-code              =/ "NOT-UTF-8" / "UTF-8-ONLY"
 333
 334
 335
 336
 337
 338 Resnick & Newman              Experimental                      [Page 6]
 339 \f
 340 RFC 5738                 IMAP Support for UTF-8               March 2010
 341
 342
 343 4.  UTF8=APPEND Capability
 344
 345    If the "UTF8=APPEND" capability is advertised, then the server
 346    accepts UTF-8 headers in the APPEND command message argument.  A
 347    client that sends a message with UTF-8 headers to the server MUST
 348    send them using the "UTF8" APPEND data extension.  If the server also
 349    advertises the CATENATE capability (as specified in [RFC4469]), the
 350    client can use the same data extension to include such a message in a
 351    CATENATE message part.  The ABNF for the APPEND data extension and
 352    CATENATE extension follows:
 353
 354      utf8-literal   = "UTF8" SP "(" literal8 ")"
 355
 356      append-data    =/ utf8-literal
 357
 358      cat-part       =/ utf8-literal
 359
 360    A server that advertises "UTF8=APPEND" has to comply with the
 361    requirements of the IMAP base specification and [RFC5322] for message
 362    fetching.  Mechanisms for 7-bit downgrading to help comply with the
 363    standards are discussed in Downgrading mechanism for
 364    Internationalized eMail Address (IMA) [RFC5504].
 365
 366    IMAP servers that do not advertise the "UTF8=APPEND" or "UTF8=ONLY"
 367    capability SHOULD reject an APPEND command that includes any 8-bit in
 368    the message headers with a "NO" response.
 369
 370    Note that the "UTF8=ONLY" capability described in Section 7 implies
 371    the "UTF8=APPEND" capability.  See additional information in that
 372    section.
 373
 374 5.  UTF8=USER Capability
 375
 376    If the "UTF8=USER" capability is advertised, that indicates the
 377    server accepts UTF-8 user names and passwords and applies SASLprep
 378    [RFC4013] to both arguments of the LOGIN command.  The server MUST
 379    reject UTF-8 that fails to comply with the formal syntax in RFC 3629
 380    [RFC3629] or if it encounters Unicode characters listed in Section
 381    2.3 of SASLprep RFC 4013 [RFC4013].
 382
 383 6.  UTF8=ALL Capability
 384
 385    The "UTF8=ALL" capability indicates all server mailboxes support
 386    UTF-8 headers.  Specifically, SELECT and EXAMINE with the "UTF8"
 387    parameter will never fail with a [NOT-UTF-8] response code.
 388
 389
 390
 391
 392
 393
 394 Resnick & Newman              Experimental                      [Page 7]
 395 \f
 396 RFC 5738                 IMAP Support for UTF-8               March 2010
 397
 398
 399    Note that the "UTF8=ONLY" capability described in Section 7 implies
 400    the "UTF8=ALL" capability.  See additional information in that
 401    section.
 402
 403    Note that the "UTF8=ALL" capability implies the "UTF8=ACCEPT"
 404    capability.
 405
 406 7.  UTF8=ONLY Capability
 407
 408    The "UTF8=ONLY" capability permits an IMAP server to advertise that
 409    it does not support the international mailbox name convention
 410    (modified UTF-7), and does not permit selection or examination of any
 411    mailbox unless the "UTF8" parameter is provided.  As this is an
 412    incompatible change to IMAP, a clear warning is necessary.  IMAP
 413    clients that find implementation of the "UTF8=ONLY" capability
 414    problematic are encouraged to at least detect the "UTF8=ONLY"
 415    capability and provide an informative error message to the end-user.
 416
 417    When an IMAP mailbox internally uses UTF-8 header native storage, the
 418    down-conversion step is necessary to permit selection or examination
 419    of the mailbox in a backwards compatible fashion will become more
 420    difficult to support.  Although it is hoped that deployed IMAP
 421    servers will not advertise "UTF8=ONLY" for some years, this
 422    capability is intended to minimize the disruption when legacy support
 423    finally goes away.
 424
 425    The "UTF8=ONLY" capability implies the "UTF8=ACCEPT" capability, the
 426    "UTF8=ALL" capability, and the "UTF8=APPEND" capability.  A server
 427    that advertises "UTF8=ONLY" need not advertise the three implicit
 428    capabilities.
 429
 430 8.  Up-Conversion Server Requirements
 431
 432    When an IMAP4 server uses a traditional mailbox format that includes
 433    7-bit headers and it chooses to permit access to that mailbox with
 434    the "UTF8" parameter, it MUST support minimal up-conversion as
 435    described in this section.
 436
 437    The server MUST support up-conversion of the following address
 438    header-fields in the message header: From, Sender, To, CC, Bcc,
 439    Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and
 440    Reply-To.  This up-conversion MUST include address local-parts in
 441    fields downgraded according to [RFC5504], address domains encoded
 442    according to Internationalizing Domain Names in Applications (IDNA)
 443    [RFC3490], and MIME header encoding [RFC2047] of display-names and
 444    any [RFC5322] comments.
 445
 446
 447
 448
 449
 450 Resnick & Newman              Experimental                      [Page 8]
 451 \f
 452 RFC 5738                 IMAP Support for UTF-8               March 2010
 453
 454
 455    The following charsets MUST be supported for up-conversion of MIME
 456    header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2,
 457    ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7,
 458    ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15.
 459    If the server supports other charsets in IMAP SEARCH or IMAP CONVERT
 460    [RFC5259], it SHOULD also support those charsets in this conversion.
 461
 462    Up-conversion of MIME header encoding of the following headers MUST
 463    also be implemented: Subject, Date ([RFC5322] comments only),
 464    Comments, Keywords, and Content-Description.
 465
 466    Server implementations also SHOULD up-convert all MIME body headers
 467    [RFC2045], SHOULD up-convert or remove the deprecated (and misused)
 468    "name" parameter [RFC1341] on Content-Type, and MUST up-convert the
 469    Content-Disposition [RFC2183] "filename" parameter, except when any
 470    of these are contained within a multipart/signed MIME body part (see
 471    below).  These parameters can be encoded using the standard MIME
 472    parameter encoding [RFC2231] mechanism, or via non-standard use of
 473    MIME header encoding [RFC2047] in quoted strings.
 474
 475    The IMAP server MUST NOT perform up-conversion of headers and content
 476    of multipart/signed, as well as Original-Recipient and Return-Path.
 477
 478 9.  Issues with UTF-8 Header Mailstore
 479
 480    When an IMAP server uses a mailbox format that supports UTF-8 headers
 481    and it permits selection or examination of that mailbox without the
 482    "UTF8" parameter, it is the responsibility of the server to comply
 483    with the IMAP4rev1 base specification [RFC3501] and [RFC5322] with
 484    respect to all header information transmitted over the wire.
 485    Mechanisms for 7-bit downgrading to help comply with the standards
 486    are discussed in "Downgrading Mechanism for Email Address
 487    Internationalization" [RFC5504].
 488
 489    An IMAP server with a mailbox that supports UTF-8 headers MUST comply
 490    with the protocol requirements implicit from Section 8.  However, the
 491    code necessary for such compliance need not be part of the IMAP
 492    server itself in this case.  For example, the minimal required up-
 493    conversion could be performed when a message is inserted into the
 494    IMAP-accessible mailbox.
 495
 496 10.  IANA Considerations
 497
 498    This adds five new capabilities ("UTF8=ACCEPT", "UTF8=USER",
 499    "UTF8=APPEND", "UTF8=ALL", and "UTF8=ONLY") to the IMAP4rev1
 500    Capabilities registry [RFC3501].
 501
 502
 503
 504
 505
 506 Resnick & Newman              Experimental                      [Page 9]
 507 \f
 508 RFC 5738                 IMAP Support for UTF-8               March 2010
 509
 510
 511    This adds two new IMAP4 list selection options and one new IMAP4 list
 512    return option.
 513
 514    1.  LIST-EXTENDED option name: UTF8
 515
 516        LIST-EXTENDED option type: SELECTION
 517
 518        Implied return options(s): UTF8
 519
 520        LIST-EXTENDED option description: Causes the LIST response to
 521        include mailboxes that mandate the UTF8 SELECT/EXAMINE parameter.
 522
 523        Published specification: RFC 5738, Section 3.4.1
 524
 525        Security considerations: RFC 5738, Section 11
 526
 527        Intended usage: COMMON
 528
 529        Person and email address to contact for further information: see
 530        the Authors' Addresses at the end of this specification
 531
 532        Owner/Change controller: iesg@ietf.org
 533
 534    2.  LIST-EXTENDED option name: UTF8ONLY
 535
 536        LIST-EXTENDED option type: SELECTION
 537
 538        Implied return options(s): UTF8
 539
 540        LIST-EXTENDED option description: Causes the LIST response to
 541        include mailboxes that mandate the UTF8 SELECT/EXAMINE parameter
 542        and exclude mailboxes that do not support the UTF8 SELECT/EXAMINE
 543        parameter.
 544
 545        Published specification: RFC 5738, Section 3.4.1
 546
 547        Security considerations: RFC 5738, Section 11
 548
 549        Intended usage: COMMON
 550
 551        Person and email address to contact for further information: see
 552        the Authors' Addresses at the end of this specification
 553
 554        Owner/Change controller: iesg@ietf.org
 555
 556
 557
 558
 559
 560
 561
 562 Resnick & Newman              Experimental                     [Page 10]
 563 \f
 564 RFC 5738                 IMAP Support for UTF-8               March 2010
 565
 566
 567    3.  LIST-EXTENDED option name: UTF8
 568
 569        LIST-EXTENDED option type: RETURN
 570
 571        Implied return options(s): none
 572
 573        LIST-EXTENDED option description: Causes the LIST response to
 574        include \NoUTF8 and \UTF8Only mailbox attributes.
 575
 576        Published specification: RFC 5738, Section 3.4.1
 577
 578        Security considerations: RFC 5738, Section 11
 579
 580        Intended usage: COMMON
 581
 582        Person and email address to contact for further information: see
 583        the Authors' Addresses at the end of this specification
 584
 585        Owner/Change controller: iesg@ietf.org
 586
 587 11.  Security Considerations
 588
 589    The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013]
 590    apply to this specification, particularly with respect to use of
 591    UTF-8 in user names and passwords.  Otherwise, this is not believed
 592    to alter the security considerations of IMAP4rev1.
 593
 594 12.  References
 595
 596 12.1.  Normative References
 597
 598    [RFC1341]  Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
 599               Mail Extensions): Mechanisms for Specifying and Describing
 600               the Format of Internet Message Bodies", RFC 1341,
 601               June 1992.
 602
 603    [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 604               Extensions (MIME) Part One: Format of Internet Message
 605               Bodies", RFC 2045, November 1996.
 606
 607    [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
 608               Part Three: Message Header Extensions for Non-ASCII Text",
 609               RFC 2047, November 1996.
 610
 611    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 612               Requirement Levels", BCP 14, RFC 2119, March 1997.
 613
 614
 615
 616
 617
 618 Resnick & Newman              Experimental                     [Page 11]
 619 \f
 620 RFC 5738                 IMAP Support for UTF-8               March 2010
 621
 622
 623    [RFC2183]  Troost, R., Dorner, S., and K. Moore, "Communicating
 624               Presentation Information in Internet Messages: The
 625               Content-Disposition Header Field", RFC 2183, August 1997.
 626
 627    [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
 628               Word Extensions:
 629               Character Sets, Languages, and Continuations", RFC 2231,
 630               November 1997.
 631
 632    [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
 633               "Internationalizing Domain Names in Applications (IDNA)",
 634               RFC 3490, March 2003.
 635
 636    [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
 637               4rev1", RFC 3501, March 2003.
 638
 639    [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
 640               10646", STD 63, RFC 3629, November 2003.
 641
 642    [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
 643               and Passwords", RFC 4013, February 2005.
 644
 645    [RFC4466]  Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
 646               ABNF", RFC 4466, April 2006.
 647
 648    [RFC4469]  Resnick, P., "Internet Message Access Protocol (IMAP)
 649               CATENATE Extension", RFC 4469, April 2006.
 650
 651    [RFC5161]  Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE
 652               Extension", RFC 5161, March 2008.
 653
 654    [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
 655               Interchange", RFC 5198, March 2008.
 656
 657    [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
 658               Specifications: ABNF", STD 68, RFC 5234, January 2008.
 659
 660    [RFC5258]  Leiba, B. and A. Melnikov, "Internet Message Access
 661               Protocol version 4 - LIST Command Extensions", RFC 5258,
 662               June 2008.
 663
 664    [RFC5259]  Melnikov, A. and P. Coates, "Internet Message Access
 665               Protocol - CONVERT Extension", RFC 5259, July 2008.
 666
 667    [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
 668               October 2008.
 669
 670
 671
 672
 673
 674 Resnick & Newman              Experimental                     [Page 12]
 675 \f
 676 RFC 5738                 IMAP Support for UTF-8               March 2010
 677
 678
 679    [RFC5335]  Abel, Y., "Internationalized Email Headers", RFC 5335,
 680               September 2008.
 681
 682    [RFC5504]  Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for
 683               Email Address Internationalization", RFC 5504, March 2009.
 684
 685 12.2.  Informative References
 686
 687    [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 688               Extensions (MIME) Part Five: Conformance Criteria and
 689               Examples", RFC 2049, November 1996.
 690
 691    [RFC2088]  Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
 692               January 1997.
 693
 694    [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
 695               Languages", BCP 18, RFC 2277, January 1998.
 696
 697    [RFC5721]  Gellens, R. and C. Newman, "POP3 Support for UTF-8",
 698               RFC 5721, February 2010.
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 Resnick & Newman              Experimental                     [Page 13]
 731 \f
 732 RFC 5738                 IMAP Support for UTF-8               March 2010
 733
 734
 735 Appendix A.  Design Rationale
 736
 737    This non-normative section discusses the reasons behind some of the
 738    design choices in the above specification.
 739
 740    The basic approach of advertising the ability to access a mailbox in
 741    UTF-8 mode is intended to permit graceful upgrade, including servers
 742    that support multiple mailbox formats.  In particular, it would be
 743    undesirable to force conversion of an entire server mailstore to
 744    UTF-8 headers, so being able to phase-in support for new mailboxes
 745    and gradually migrate old mailboxes is permitted by this design.
 746
 747    "UTF8=USER" is optional because many identity systems are US-ASCII
 748    only, so it's helpful to inform the client up front that UTF-8 won't
 749    work.
 750
 751    "UTF8=APPEND" is optional because it effectively requires IMAP server
 752    support for down-conversion, which is a much more complex operation
 753    than up-conversion.
 754
 755    The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability
 756    problems when legacy support goes away.  In the situation where
 757    backwards compatibility is broken anyway, just-send-UTF-8 IMAP has
 758    the advantage that it might work with some legacy clients.  However,
 759    the difficulty of diagnosing interoperability problems caused by a
 760    just-send-UTF-8 IMAP mechanism is the reason the "UTF8=ONLY"
 761    capability mechanism was chosen.
 762
 763    The up-conversion requirements are designed to balance the desire to
 764    deprecate and eventually eliminate complicated encodings (like MIME
 765    header encodings) without creating a significant deployment burden
 766    for servers.  As IMAP4 servers already require a MIME parser, this
 767    includes additional server up-conversion requirements not present in
 768    POP3 Support for UTF-8 [RFC5721].
 769
 770    The set of mandatory charsets comes from two sources: MIME
 771    requirements [RFC2049] and IETF Policy on Character Sets [RFC2277].
 772    Including a requirement to up-convert widely deployed encoded
 773    ideographic charsets to UTF-8 would be reasonable for most scenarios,
 774    but may require unacceptable table sizes for some embedded devices.
 775    The open-ended recommendation to support widely deployed charsets
 776    avoids the political ramifications of attempting to list such
 777    charsets.  The authors believe market forces, existing open-source
 778    software, and public conversion tables are sufficient to deploy the
 779    appropriate charsets.
 780
 781
 782
 783
 784
 785
 786 Resnick & Newman              Experimental                     [Page 14]
 787 \f
 788 RFC 5738                 IMAP Support for UTF-8               March 2010
 789
 790
 791 Appendix B.  Examples Demonstrating Relationships between UTF8=
 792              Capabilities
 793
 794
 795      UTF8=ACCEPT UTF8=USER UTF8=APPEND
 796      UTF8=ACCEPT UTF8=ALL
 797      UTF8=ALL       ; Note, same as above
 798      UTF8=ACCEPT UTF8=USER UTF8=APPEND UTF8=ALL UTF8=ONLY
 799      UTF8=USER UTF8=ONLY ; Note, same as above
 800
 801 Appendix C.  Acknowledgments
 802
 803    The authors wish to thank the participants of the EAI working group
 804    for their contributions to this document with particular thanks to
 805    Harald Alvestrand, David Black, Randall Gellens, Arnt Gulbrandsen,
 806    Kari Hurtta, John Klensin, Xiaodong Lee, Charles Lindsey, Alexey
 807    Melnikov, Subramanian Moonesamy, Shawn Steele, Daniel Taharlev, and
 808    Joseph Yee for their specific contributions to the discussion.
 809
 810 Authors' Addresses
 811
 812    Pete Resnick
 813    Qualcomm Incorporated
 814    5775 Morehouse Drive
 815    San Diego, CA  92121-1714
 816    US
 817
 818    Phone: +1 858 651 4478
 819    EMail: presnick@qualcomm.com
 820    URI:   http://www.qualcomm.com/~presnick/
 821
 822    Chris Newman
 823    Sun Microsystems
 824    800 Royal Oaks
 825    Monrovia, CA  91016
 826    US
 827
 828    EMail: chris.newman@sun.com
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842 Resnick & Newman              Experimental                     [Page 15]
 843 \f