draft-ietf-imap-mbox-00.txt   draft-ietf-imap-mbox-01.txt 
Network Working Group J. G. Myers Network Working Group J. G. Myers
Internet Draft: IMAP4 Internationalized Mailboxes Carnegie Mellon Internet Draft: IMAP4 Internationalized Mailboxes Carnegie Mellon
Document: internet-drafts/draft-ietf-imap-mbox-00.txt January 1995 Document: internet-drafts/draft-ietf-imap-mbox-01.txt September 1995
IMAP4 Internationalized Mailboxes IMAP4 Internationalized Mailboxes
Status of this memo Status of this memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the IMAP4 protocol whereby a client and a server may negotiate the the IMAP4 protocol whereby a client and a server may negotiate the
use of some other character set for use in mailbox names. use of some other character set for use in mailbox names.
2. MBOXCHARSET capability 2. MBOXCHARSET capability
Servers which support this extension must advertise the MBOXCHARSET Servers which support this extension must advertise the MBOXCHARSET
capability name in the untagged CAPABILITY response. capability name in the untagged CAPABILITY response.
3. MBOXCHARSET command 3. MBOXCHARSET command
Arguments: registered MIME charset name Arguments: MIME charset name
Data: none Data: none
Result: OK - character set is selected Result: OK - character set is selected
NO - character set is not supported NO - character set is not supported
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The MBOXCHARSET command selects the character set for use in The MBOXCHARSET command selects the character set for use in
mailbox names. The command may only be given when a connection is mailbox names. The command may only be given when a connection is
in the authenticated or selected state. in the authenticated or selected state.
If the server does not recognize or support the specified If the server does not recognize or support the specified
character set name, it must return a tagged NO response. 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 If the server returns a tagged OK response, then all mailbox names
(those names corresponding to mailbox or list_mailbox nonterminals (those names corresponding to mailbox or list_mailbox nonterminals
in the formal syntax) in subsequent commands and responses are in in the formal syntax) in subsequent commands and responses are in
the specified character set. the specified character set.
All servers MUST support the US-ASCII character set. It is not All servers MUST support the US-ASCII character set. It is not
required that any other particular character set be supported. required that any other particular character set be supported.
Servers need not support the same set of character sets they Servers need not support the same set of character sets they
support for SEARCH CHARSET. support for SEARCH CHARSET.
4. LIST wildcards 4. LIST wildcards
In the LIST, LSUB, and FIND MAILBOX commands, matching is done on the In the LIST, LSUB, and FIND MAILBOX commands, matching is done on the
underlying glyphs, not on the encoded octet stream. The list underlying glyphs, not on the octets of the encoded stream. The list
wildcards are the underlying glyphs which correspond to the US-ASCII wildcards are the underlying glyphs which correspond to the US-ASCII
characters "*", "%", and in the case of FIND MAILBOX, "?". glyphs "*", "%", and in the case of FIND MAILBOX, "?".
Requirements imposed on returned mailbox names apply to the Requirements imposed on returned mailbox names apply to the
underlying glyphs. In character sets where there are multiple underlying glyphs. In character sets where there are multiple
possible encodings of the same glyph sequence, the server may pick possible encodings of the same glyph sequence, the server may pick
whichever encoding is most convenient for it. whichever encoding is most convenient for it.
5. Examples 5. Example
[Some iso-2022-jp examples] 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 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 6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in RFC 822. Form (BNF) notation as specified in RFC 822.
Except as noted otherwise, all alphabetic characters are case- Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion. accept these strings in a case-insensitive fashion.
mboxcharset ::= "MBOXCHARSET" SP astring mboxcharset ::= "MBOXCHARSET" SP astring
;; Valid only in Authenticated or Selected state ;; Valid only in Authenticated or Selected state
;; Character set must be registered with IANA ;; Character set must be a MIME character set
;; as a MIME character set
7. References 7. References
[IMAP4] Crispin, M., "Internet Message Access Protocol - [IMAP4] Crispin, M., "Internet Message Access Protocol -
Version 4", RFC 1730, University of Washington, December 1994. Version 4", RFC 1730, University of Washington, December 1994.
8. Security Considerations 8. Security Considerations
Security issues are not discussed in this memo. There are no known security issues with respect to this document.
9. Author's Address 9. Author's Address
John G. Myers John G. Myers
Carnegie-Mellon University Carnegie-Mellon University
5000 Forbes Ave. 5000 Forbes Ave.
Pittsburgh PA, 15213-3890 Pittsburgh PA, 15213-3890
Email: jgm+@cmu.edu Email: jgm+@cmu.edu
 End of changes. 9 change blocks. 
10 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/