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

Versions: 00 01 02                                                      
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) <language tag> formally defined as an <astring>, [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 <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 "(" 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>
      ; string as defined in [RFC-2060]




Gahrns, Melnikov         Expires August 2001                 [Page 6]


                       IMAP4 Language Extension          February 2001


   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.

   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

   <language_tag> =  <astring> as defined in [RFC-2060]
      ; <language_tag> 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 = ["[" <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

   [LANG-TAGS], Alvestrand, H., "Tags for the Identification of
   Languages", RFC 3066, Cisco Systems, January 2001

   [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


Gahrns, Melnikov         Expires August 2001                 [Page 7]


                       IMAP4 Language Extension          February 2001


   [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.
   However, the authors 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,
   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


   Alexey Melnikov
   ACI Worldwide/MessagingDirect
   #900, 10117 Jasper Avenue,
   Edmonton, Alberta, T5J 1W8

   Phone: (780) 424-4922 Ext 357
   Email: mel@messagingdirect.com




















Gahrns, Melnikov         Expires August 2001                 [Page 8]


                       IMAP4 Language Extension          February 2001



Full Copyright Statement


   Copyright (C) The Internet Society 2001. 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, Melnikov         Expires August 2001                 [Page 9]