Network Working Group                                        J. G. Myers
Internet Draft: IMAP4 Internationalized Mailboxes        Carnegie Mellon
Document: internet-drafts/draft-ietf-imap-mbox-00.txt       January internet-drafts/draft-ietf-imap-mbox-01.txt     September 1995

                   IMAP4 Internationalized Mailboxes

Status of this memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress``.

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on,,, or

   This is a draft document of the IETF IMAP Working Group.  A revised
   version of this draft document will be submitted to the RFC editor as
   a Proposed Standard for the Internet Community.  Discussion and
   suggestions for improvement are requested.  This document will expire
   before 15 July 1995.  Distribution of this draft is unlimited.
   Comments are solicited and should be sent to imap@CAC.Washington.EDU.

1. Introduction

   The Internet Message Access Protocol, Version 4 [RFC1730] contains a
   number of commands which accept and/or manipulate mailbox names.  In
   the base IMAP4 protocol, mailbox names may only contain characters in
   the US-ASCII character set.  This document defines an extension to
   the IMAP4 protocol whereby a client and a server may negotiate the
   use of some other character set for use in mailbox names.

2. MBOXCHARSET capability

   Servers which support this extension must advertise the MBOXCHARSET
   capability name in the untagged CAPABILITY response.

3. MBOXCHARSET command

   Arguments:  registered  MIME charset name

   Data:       none

   Result:     OK - character set is selected
               NO - character set is not supported
               BAD - command unknown or arguments invalid

      The MBOXCHARSET command selects the character set for use in
      mailbox names.  The command may only be given when a connection is
      in the authenticated or selected state.

      If the server does not recognize or support the specified
      character set name, it must return a tagged NO response.  The
      previously selected character set remains.

      If the server returns a tagged OK response, then all mailbox names
      (those names corresponding to mailbox or list_mailbox nonterminals
      in the formal syntax) in subsequent commands and responses are in
      the specified character set.

      All servers MUST support the US-ASCII character set.  It is not
      required that any other particular character set be supported.
      Servers need not support the same set of character sets they
      support for SEARCH CHARSET.

4. LIST wildcards

   In the LIST, LSUB, and FIND MAILBOX commands, matching is done on the
   underlying glyphs, not on the octets of the encoded octet stream.  The list
   wildcards are the underlying glyphs which correspond to the US-ASCII
   glyphs "*", "%", and in the case of FIND MAILBOX, "?".

   Requirements imposed on returned mailbox names apply to the
   underlying glyphs.  In character sets where there are multiple
   possible encodings of the same glyph sequence, the server may pick
   whichever encoding is most convenient for it.

5. Examples

   [Some Example

   In the following example, the sequence ``^['' represents ESC, an
   octet with decimal value 27.
   C: A003 MBOXCHARSET iso-2022-jp
   S: A003 OK Mailbox names using iso-2022-jp examples] charset
   C: A004 LIST "" "^[$B$*5R$5$s$,5%^[(J*"
   S: * LIST () "/" "$B$*5R$5$s$,5%<V$G5"$k(J"
   S: A004 OK LIST completed

   In the above example, although the fifth and the fifteenth octets had
   the values 42 and 37 respectively, they were not treated by the
   server as wildcards.
6. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in RFC 822.

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

   mboxcharset    ::= "MBOXCHARSET" SP astring
                      ;; Valid only in Authenticated or Selected state
                      ;; Character set must be registered with IANA
                      ;; as a MIME character set

7. References

   [IMAP4] Crispin, M., "Internet Message Access Protocol -
   Version 4", RFC 1730, University of Washington, December 1994.

8. Security Considerations

   Security issues

   There are not discussed in no known security issues with respect to this memo. document.

9. Author's Address

   John G. Myers
   Carnegie-Mellon University
   5000 Forbes Ave.
   Pittsburgh PA, 15213-3890