Network Working Group M. Gahrns, Microsoft Internet Draft A. Melnikov, ACI WorldWide/MessagingDirect Document: draft-gahrns-imap-language-02.txt February 2001 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, Melnikov Expires August 2001 [Page 1] IMAP4 Language Extension February 2001 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. Changes since -01 1) formally defined as an , [RFC 3066] only described it. 2) Grammar for EXTENSION updated to show the parts of the extension. 3) Incorporated text about MUL, UND and hierarchy. 4) References to RFC 1766 were replaced with RFC 3066 that obsoleted it. 5) ABNF declaration for NAMESPACE_TRANSLATION_RESPONSE is now linked to NAMESPACE extension [RFC-2342]. 6) Server MUST NOT return a NAMESPACE response if it is in non-authenticated state. Gahrns, Melnikov Expires August 2001 [Page 2] IMAP4 Language Extension February 2001 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. 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 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 described by [LANG-TAGS]. Response: A possible LANGUAGE response containing the list of server supported languages. A possible NAMESPACE response as defined by [RFC-2342]. Gahrns, Melnikov Expires August 2001 [Page 3] IMAP4 Language Extension February 2001 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. > 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 execute 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 < Client requested MUL language. Server MUST reply with BAD > C: A003 LANGUAGE MUL S: A003 BAD Invalid language MUL 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. Server SHOULD recognize languages that have multiple different tags (for example "ru" and "rus"). Gahrns, Melnikov Expires August 2001 [Page 4] IMAP4 Language Extension February 2001 Note 1. Client MUST NOT use MUL (Multiple languages) and UND(Undetermined) language tags and server MUST return BAD to the LANG command that is used with such parameter. Note 2. [LANG-TAGS] warns that there is no guaranteed relationship between languages whose tags start out with the same series of subtags. However it is believed that for the purpose of this document it is safe to treat all languages, whose tags starts with primary languages described in ISO 639-1 and ISO 639-2 (i.e. all 2 or 3 letters primary languages) as hierarchical. For all languages with other primary tags, the described fallback rule MUST NOT be used. In particular, language tags starting with 'i-' and 'x-' MUST NOT be treated as hierarchical. Example 4.2 =========== C: A002 LANGUAGE FR-CA S: * LANGUAGE (FR) S: A002 OK La Language commande a ete execute 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. However server MUST NOT return a NAMESPACE response if it is in non-authenticated state. If as a result of the newly negotiated language, localized representations of the namespace prefixes are available, the server Gahrns, Melnikov Expires August 2001 [Page 5] IMAP4 Language Extension February 2001 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 ] [*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 "(" LANG-EXT-NAME SP LANG-EXT-VALUES ")" LANG-EXT-NAME = string ; Name of LANG extension LANG-EXT-VALUES = "(" LANG-EXT-VALUE *(SP LANG-EXT-VALUE)")" ; List of LANG extension specific values LANG-EXT-VALUE = string string = ; string as defined in [RFC-2060] Gahrns, Melnikov Expires August 2001 [Page 6] IMAP4 Language Extension February 2001 LANGUAGE_Response = "*" SP "LANGUAGE" SP "(" *(SP ) ")" ; Note: the server is required to support the language i-default ; and as such i-default must appear in the language response. Namespace_Response_Extension =/ NAMESPACE_TRANSLATION_RESPONSE ; Namespace_Response_Extension is defined in [RFC-2342] NAMESPACE_TRANSLATION_RESPONSE = SP <"> TRANSLATION <"> SP "(" string ")" ; the string is encoded in Modified UTF-7 = as defined in [RFC-2060] ; is described in [LANG-TAGS] ; After the server is changed to a language other than i-default, the resp_text as defined by [RFC-2060] becomes: resp_text = ["[" "]" SP ] 1*UTF8_CHAR ;