Internet DRAFT - draft-gahrns-imap-language
draft-gahrns-imap-language
Network Working Group M. Gahrns, Microsoft
Internet Draft
Document: draft-gahrns-imap-language-01.txt October 1999
IMAP4 Language Extension
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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 and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
0. Meta Information on this draft
This information is intended to facilitate discussion. It will be
removed when this document leaves the Internet-Draft stage.
This draft is being discussed on the IMAPEXT mailing list at ietf-
imapext@imc.org. Subscription requests can be sent to ietf-
imapext-request@imc.org (send an email message with the word
"subscribe" in the body). More information on the mailing list
along with a WWW archive of back messages is available at
HTTP://www.imc.org
Changes since -00
1) Now define an extension mechanism to allow additional parameters
to be passed so that this draft could serve as a framework for full
internationalization of other drafts such as SORT. This approach
would allow the language draft to proceed and solve the immediate
and easy case of allowing an IMAP user to read server responses in
their language. At the IMC interop event some vendors have already
implemented to language-draft-00. These implementations would
remain unaffected by future extensions to this language draft, since
a client would not include any additional extension parameters in
the LANGUAGE command unless the server advertised these extensions
Gahrns Expires April 2000 1
IMAP4 Language Extension October 1999
in its capability response. At the IMAPEXT Working Group at the
45th IETF in Oslo, it was proposed that an extension mechanism be
added to this draft and then have the working group debate the
merits of continuing with this existing draft versus starting a new
draft to tackle the more daunting problem of trying to solve all
internationalization issues in a single draft.
2) Included John Myers' suggestion to add to the requirements
section that a client that supports this extension must be prepared
for a NAMESPACE response.
3) Included John Myers' suggestion that if the server supports the
namespace extension it must send a NAMESPACE response when a
language is negotiated.
4) Included John Myers' suggestion that a TRANSLATION extension be
included to the NAMESPACE response to allow for localized version of
the NAMESPACE prefixes.
5) Included Jutta Degener's corrections to the grammar (e.g. 1# is
not defined in RFC2234-BNF, missing ] in grammar) along with her
minor editorial suggestions.
6) Included Mark Crispin's suggestion of allowing the server to
substitute a primary language if the sublanguage asked for is not
available.
1. Abstract
The Internet Message Access Protocol [RFC-2060] allows server
responses to include human-readable text that in many cases needs to
be presented to the user. This document specifies a way for a
client to negotiate which language the server should use when
sending human-readable text. It provides an extensible mechanism so
that it may be used as a framework for full internationalization of
other IMAP extensions such as SORT.
2. Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. If such lines are wrapped without a new "C:"
or "S:" label, then the wrapping is for editorial clarity and is not
part of the command.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119].
3. Requirements
Gahrns Expires April 2000 2
IMAP4 Language Extension October 1999
IMAP4 servers that support this extension MUST list the keyword
LANGUAGE in their CAPABILITY response.
A server that supports this extension SHOULD use the language "i-
default" as described in [CHARSET-POLICY] as its default language
until another supported language is negotiated by the client. A
server MUST include "i-default" as one of its supported languages.
A client that supports this extension MUST be prepared for a
possible NAMESPACE response [RFC-2342] from the server.
The LANGUAGE command is valid in the non-authenticated,
authenticated and selected state.
4. LANGUAGE Command
Arguments: Zero or one language tag as defined by [RFC-1766].
Response: A possible LANGUAGE response containing the list of
server supported languages.
If a sublanguage was asked for and not available but the
primary language is available, the server should switch to
the primary language and include a LANGUAGE response
containing the identifier of the primary language it
switched to.
A possible NAMESPACE response as defined by [RFC-2342].
Result: OK - Command completed
NO - Could not complete command
BAD - arguments invalid
The LANGUAGE command requests that human-readable text emitted by
the server be localized to the language specified in the language
tag argument.
If the command succeeds, the server will return human-readable
responses in the specified language starting with the tagged OK
response to the LANGUAGE command. These responses will be in UTF-8
[RFC-2044].
If the command fails, the server will continue to return human-
readable responses in the language it was previously using.
Example 4.1
===========
< The server defaults to using English responses until the user
explicitly changes the language. >
Gahrns Expires April 2000 3
IMAP4 Language Extension October 1999
C: A001 LOGIN KAREN PASSWORD
S: A001 OK LOGIN completed
< Once the client changes the language, all responses will be in
that language starting with the tagged OK to the LANGUAGE command. >
C: A002 LANGUAGE FR
S: A002 OK La Language commande a ete executee avec success
< If a server does not support the requested primary language,
responses will continue to be returned in the current language the
server is using. >
C: A003 LANGUAGE DE
S: A003 NO Ce Language n'est pas supporte
Example 4.2
===========
If the client requests a sublanguage that is not available, but the
primary language is available, the server SHOULD switch to the
primary language and return a LANGUAGE response indicating that it
switched to the primary language instead.
C: A002 LANGUAGE FR-CA
S: * LANGUAGE (FR)
S: A002 OK La Language commande a ete executee avec success
If the language tag argument is omitted, the server SHOULD send an
untagged LANGUAGE response listing the languages it supports. If
the server is unable to enumerate the list of languages it supports
it MAY return a tagged NO response to the enumeration request.
Example 4.3
===========
< A LANGUAGE command with no arguments is a request to enumerate the
list of languages the server supports. >
C: A001 LANGUAGE
S: * LANGUAGE (EN DE IT i-default)
S: A001 OK Supported languages have been enumerated
C: A001 LANGUAGE
S: A002 NO Server is unable to enumerate supported languages
5. TRANSLATION extension to the NAMESPACE response
If the server supports the IMAP4 NAMESPACE command [RFC-2342], the
server MUST return an untagged NAMESPACE response when a language is
negotiated.
Gahrns Expires April 2000 4
IMAP4 Language Extension October 1999
If as a result of the newly negotiated language, localized
representations of the namespace prefixes are available, the server
SHOULD include these in the TRANSLATION extension to the NAMESPACE
response.
The TRANSLATION extension to the NAMESPACE response returns a single
string, containing the Modified UTF-7 [RFC-2060] encoded translation
of the namespace prefix. It is the responsibility of the client to
convert between the namespace prefix and the translation of the
namespace prefix when presenting mailbox names to the user.
Example 5.1
===========
< In this example a server supports the IMAP4 NAMESPACE command. It
uses no prefix to the user's Personal Namespace, a prefix of "Other
Users" to its Other Users' Namespace and a prefix of "Public
Folders" to its only Shared Namespace. Since a client will often
display these prefixes to the user, the server includes a
translation of them that can be presented to the user. >
C: A001 LANGUAGE FR-CA
S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION" ("Autres
Utilisateurs/"))) (("Public Folders/" "/" "TRANSLATION" ("R&Aok-
pertoires Publics/")))
S: A001 OK La Language commande a ete executee avec success
6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [RFC-2234].
LANGUAGE_Command = "LANGUAGE" [SP <language_tag>] [*EXTENSION]
; A client should not issue the optional extension parameter
; unless a server has indicated in its capabilities that it
; supports that extension
EXTENSION = SP "(" string SP "(" string *(SP string)")" ")"
string = <string>
;string as defined in [RFC-2060]
LANGUAGE_Response = "*" SP "LANGUAGE" SP "(" <language_tag> *(SP
<language_tag>) ")"
; Note: the server is required to support the language i-default
; and as such i-default must appear in the language response.
Gahrns Expires April 2000 5
IMAP4 Language Extension October 1999
NAMESPACE_TRANSLATION_RESPONSE = SP <"> TRANSLATION <"> SP "("
string ")"
; the string is encoded in Modified UTF-7
<language_tag> = <language_tag> as defined in [RFC-1766]
; After the server is changed to a language other than i-default,
the resp_text as defined by [RFC-2060] becomes:
resp_text = ["[" <resp_text_code> "]" SP ] 1*UTF8_CHAR
; <resp_text_code as defined in RFC-2060
; UTF8_CHAR as defined in [RFC-2044] not starting with "[" or "="
7. Security Considerations
This extension allows the negotiation of a language for the human-
readable text returned by a server. A user is able to query the
languages that a server supports.
8. References
[RFC-1766], Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, UNINETT, March 1995
[RFC-2044], Yergeau, F., " UTF-8, a transformation format of Unicode
and ISO 10646, RFC 2044, Alis Technologies, October, 1996
[RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, University of Washington, December 1996.
[RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997
[RFC-2234], DRUMS working group, Dave Crocker Editor, "Augmented BNF
for Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium, November 1997
[CHARSET-POLICY], Alvestrand, H., "IETF Policy on Character Sets and
Languages", draft-alvestrand-charset-policy-02.txt (work in
progress), UNINETT, October 1997
[RFC-2342], Gahrns & Newman, "IMAP4 Namespace", RFC 2342, Microsoft
and Innosoft, May 1998
9. Acknowledgments
Many people have participated in discussions about an IMAP Language
extension in the various fora of the IETF and the internet working
groups, so any list of contributors is bound to be incomplete.
Gahrns Expires April 2000 6
IMAP4 Language Extension October 1999
However, the author would like to thank Andrew McCown for early work
on the original proposal, John Myers and Chris Newman for their
suggestions regarding the namespace issue, along with Jutta Degener,
Alexey Melnikov, Mark Crispin, Mark Pustilnik and Larry Osterman for
their many suggestions that have been incorporated into this
document.
10. Author's Address
Mike Gahrns
Microsoft
One Microsoft Way
Redmond, WA, 98072
Phone: (425) 936-9833
Email: mikega@microsoft.com
Gahrns Expires April 2000 7
IMAP4 Language Extension October 1999
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
For the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gahrns Expires April 2000 8
