[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
Network Working Group                              M. Gahrns, Microsoft
                                     A. McCown, Mitsubishi Electric ITA
Internet Draft
Document: draft-gahrns-imap-language-00.txt               November 1997

                          IMAP4 Language Extension

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 ds.internic.net, nic.nordu.net, ftp.isi.edu, or

   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 June 1998. Distribution of this draft is

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.

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",
   this document are to be interpreted as described in [RFC-2119].

Gahrns and McCown                                                    1

                       IMAP4 Language Extension          November 1997

3. Requirements

   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.

   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.
             A possible NAMESPACE response as defined by [IMAP-

   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

   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. >

   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. >

Gahrns and McCown                                                    2

                       IMAP4 Language Extension          November 1997

   S: A002 OK La Language commande a ete executee avec success

   < If a server does not support the requested language, responses
   will continue to be returned in the current language the server is
   using. >

   S: A003 NO Ce Language n'est pas supporte

   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.2

   < A LANGUAGE command with no arguments is a request to enumerate the
   list of languages the server supports. >

   S: * LANGUAGE (EN DE IT i-default)
   S: A001 OK Supported languages have been enumerated

   S: A002 NO Server is unable to enumerate supported languages

   If the server supports the IMAP4 NAMESPACE command [IMAP-NAMESPACE],
   the server SHOULD return an untagged NAMESPACE response if namespace
   information changed as a result of the LANGUAGE command.  Note that
   the namespace prefix is to a mailbox and following IMAP4 convention,
   any international string in the NAMESPACE response MUST be of
   modified UTF-7 format as described in [RFC-2060].

   Example 4.3

   < 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 changes these based
   on the language of the connecting client. >

   S: * NAMESPACE (("" "/"))(("Autres Utilisateurs/" "/")) (("Dossiers
          Publics" "/")
   S: A001 OK La Language commande a ete executee avec success

Gahrns and McCown                                                    3

                       IMAP4 Language Extension          November 1997

   Note: A server should be aware that changing the namespace prefixes
   based upon the language of the connecting client can invalidate
   mailbox URLs that are shared by clients of various languages.
   Addressing this issue is outside the scope of this document, and is
   part of a much larger problem of how a client should share/send urls
   to a particular mailbox that may be represented differently by the
   server based upon the identity of the connected user.

5. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].

   LANGUAGE_Command = "LANGUAGE" [SP <language_tag>]

   LANGUAGE_Response = "*" SP "LANGUAGE" SP "(" 1*<language_tag> ")"
      ; Note: the server is required to support the language i-default
      ; and as such i-default must appear in the language response.
      ; Although primarily English text, the "i-default" language may
      ; contain some non-English text.
      ; Any international characters in the "i-default" response
      ; text MUST be encoded as per <text_mime2> as defined in
      ; [RFC-2060] and not as <text_utf8>

   <language_tag> =  <language_tag> as defined in [RFC-1766]

   ; After the server is changed to a language other than English, the
   resp_text as defined by [RFC-2060] becomes:

   resp_text = ["[" <resp_text_code> "]" SP <text_utf8>
      ; <resp_text_code as defined in RFC-2060
      ; <text_utf8> any valid UTF-8 character as defined in [RFC-2044]

6. 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.

7. References

   [RFC-1766], Alvestrand, H., "Tags for the Identification of
   Languages", RFC 1766, UNINETT, March 1995

Gahrns and McCown                                                    4

                       IMAP4 Language Extension          November 1997

   [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

   [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
   Syntax Specifications: ABNF", draft-drums-abnf-04.txt (work in
   progress), Internet Mail Consortium, September 1997

   [CHARSET-POLICY], Alvestrand, H., "IETF Policy on Character Sets and
   Languages", draft-alvestrand-charset-policy-02.txt (work in
   progress), UNINETT, October 1997

   [IMAP-NAMESPACE], Gahrns, M., "IMAP4 Namespace", draft-gahrns-imap-
   namespace-05.txt (work in progress), Microsoft, November 1997

8.  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.
   However, the authors would like to thank John Myers and Chris Newman
   for their suggestions regarding the namespace issue and Larry
   Osterman for his review of this document.

9. Author's Address

   Mike Gahrns
   One Microsoft Way
   Redmond, WA, 98072

   Phone: (425) 936-9833
   Email: mikega@microsoft.com

   Andrew McCown
   Mitsubishi Electric ITA
   1432 Main St.
   Waltham MA, 02154

   Email: andy@meitca.com

Gahrns and McCown                                                    5