Network Working Group                            Mike Gahrns, Microsoft 
Internet Draft                        Alexey Melnikov, Messaging Direct
Document: draft-melnikov-smtp-lang-01.txt                  October 1999


                          SMTP Language Extension


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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.


   This document  suggests  a  proposed  protocol  for  the   Internet
   community,    and   requests   discussion   and   suggestions   for
   improvements. Distribution of this draft is unlimited.

   The protocol discussed in this document is experimental and subject
   to change.  Persons planning on either implementing or using this
   protocol are STRONGLY URGED to get in touch with the author before
   embarking on such a project.


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. 
    

   Changes since -00 
    
1) Corrected grammar error in LANG command description section

2) Included Mark Crispin's suggestion of allowing the server to 
   substitute a primary language if the sublanguage asked for is not
   available.

3) Added section 5 that describes extended LANG reply

4) Corrected example, more examples

5) Added extension mechanism

6) Specified interaction with RFC-2034 ("SMTP Service Extension for Returning Enhanced)

7) LANG command must always have language-tag as a parameter. Only EHLO response could
   be used to examine list of supported languages.


   Open issues

1) Should language information be added to MAIL FROM so that it could be used
   in DSN/MDN notification messages?


1. Abstract

   The Simple Mail Transfer Protocol [RFC-821] 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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [KEYWORDS].


3. Framework for the Language SMTP service extension

   The Language SMTP  service  extension  uses the  SMTP  service  extension  
   mechanism described in [ESMTP].  The following SMTP service extension is 
   therefore defined:

  (1) The name of the SMTP service extension is "Language".

  (2) The EHLO keyword value associated with this service extension is
      "LANGUAGE".

  (3) The LANGUAGE EHLO keyword contains as a parameter a space separated
      list of the names of supported language tags. This list is optional. 
      If the language tag argument is omitted, this means that server is 
      unable to enumerate the list of languages it supports.

  (4) A new SMTP verb "LANG" is defined by this document.

  (5) No additional SMTP parameters to either MAIL FROM or RCPT TO commands 
      are defined by this extension.

  An additional document may define an extension to LANGUAGE ESMTP extension.
  Any such extension MUST use ESMTP extension name that starts with LANGUAGE
  prefix. This document doesn't specify any LANG command extension.


4. Requirements

   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 support
   and include "i-default" in EHLO response.


5. LANG Command

   LANG language-tag [*extension]

     Arguments:
         language tag as defined by [RFC-1766].
         optional extension specific parameters 

     Restrictions:
         The LANG command is permitted throughout a mail connection.

     Reply Codes:
         Success:
            250 LANG command completed successfully
         Error: 
            504 Language is not supported
            421 <domain> Service not available, closing transmission channel

     Discussion:
         The LANG command requests that human-readable text emitted by
         the server be localized to the language specified in the language
         tag argument.

         If a sublanguage was asked for and not available but the primary
         language is available, the server SHOULD switch to the primary language
         and MUST use an extended LANG reply containing the identifier of the primary
         language it switched to as described in section 5.

         It is also recommended that server recognizes languages that have multiple
         different tags (for example "ru" and "rus").

         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. [RFC-1766] 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 language 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 described fallback rule MUST NOT
         be used. In particular, language tags starting with 'i-' and 'x-' SHOULD NOT
         be treated as hierarchical.

         If the command succeeds, the server will return human-readable
         responses in the specified language starting with the successful
         250 response to the LANG command.  These responses will be in UTF-8
         [RFC-2044]. In particular, LANG command MAY affect the result of 
         a HELP command.

         If the command fails, the server will continue to return human-
         readable responses in the language it was previously using.


         An additional document may define an extension to LANGUAGE ESMTP extension.
         Any such extension MUST use ESMTP extension name that starts with LANGUAGE
         prefix. This document doesn't specify any LANG extension.

         LANG extension document may define additional parameters to LANG command.  Client
         MUST NOT issue the optional extension parameters unless a server has indicated
         in its EHLO response that it supports that extension. In case when server
         doesn't support requested parameter(s) or any parameters, it MUST respond with
         504 code.

     Example 1:

        < The server defaults to using responses in "i-default" language
          until the user explicitly changes the language. >

         S: 220 smtp.example.com ESMTP server ready
         C: EHLO main.example.com
         S: 250-smtp.example.com
         S: 250-AUTH CRAM-MD5 DIGEST-MD5
         S: 250 LANGUAGE EN FR RU i-default
         C: HELP
         S: 214-This is Sendmail version X.X.X
         S: 214-Topics:
         S: 214-    HELO    EHLO    MAIL    RCPT    DATA
         S: 214-    RSET    NOOP    QUIT    HELP    VRFY
         S: 214-    EXPN    VERB    ETRN    DSN
         S: 214-For more info use "HELP <topic>".
         S: 214 End of HELP info

        < Once the client changes the language, all responses will be in
          that language starting with 250 response to the LANG command. >

         C: LANG FR
         S: 250 La Language commande a ete execute avec success

         C: HELP
         S: 214-C'est le programme Sendmail version X.X.X
         S: 214-Topics:
         S: 214-    HELO    EHLO    MAIL    RCPT    DATA
         S: 214-    RSET    NOOP    QUIT    HELP    VRFY
         S: 214-    EXPN    VERB    ETRN    DSN
         S: 214-Pour obtenir l'information supplementaire utilisez "HELP <topic>".
         S: 214 La fin de l'information 

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

         C: LANG DE
         S: 504 Ce Language n'est pas supporte

     Example 2:

        < The client tries to select MUL language that couldn't be used with described
          extension>

         C: LANG MUL
         S: 504 It is not allowed to use MUL language.

     Example 3:

        < The client tries to use LANG extension not supported by server>

         C: LANG i-default (blah blah)
         S: 504 LANG extension blah is not recognized.


5. Extended LANG reply

   Extended reply is the reply that contains additional information in the text
   part. Extended reply allows to pass additional information from server to client.
   Client may choose to ignore additional information in an extended reply. Thus client
   that doesn't recognize an extended reply would treat it as a regular SMTP reply.

     Example 4:

        < The client tries to select the language, but it is unavailable.
          However primary language is available>

         C: LANG FR-ca
         S: 250 [LANG FR]La Language commande a ete execute avec success

   Client that supports LANGUAGE extension must recognize Enhanced Error Codes defined in 
  [RFC-2034]. When server supports both LANGUAGE and ENHANCEDSTATUSCODES extensions,
  Extended reply data MUST follow Enchanced Error Code in reply.

     Example 5:

        < The server supports both LANGUAGE and ENHANCEDSTATUSCODES>

         S: 220 smtp.example.com ESMTP server ready
         C: EHLO main.example.com
         S: 250-smtp.example.com
         S: 250 LANGUAGE EN FR RU i-default
         S: 250 ENHANCEDSTATUSCODES
         C: LANG FR-ca
         S: 250 2.0.0 [LANG FR]La Language commande a ete execute avec success


6. Formal Syntax

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

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

   CR              = %x0C     ;; ASCII CR, carriage return

   CRLF            = CR LF

   LF              = %x0A     ;; ASCII LF, line feed

   SPACE           = %x20     ;; ASCII SP, space

   LANG_Command = "LANG" SPACE language_tag [*extension] CRLF
      ; A client MUST NOT issue the optional extension parameter 
      ; unless a server has indicated in its EHLO response that it 
      ; supports that extension 

   extension = SP "(" lang-ext-name SP lang-ext-values ")" 

   lang-ext-name = text
      ; Name of LANG extension

   lang-ext-values = "(" lang-ext-value *(SP lang-ext-value)")"
      ; List of LANG extension specific values 

   lang-ext-value = text

   LANGUAGE_List = "LANGUAGE" *(SPACE <language_tag>) CRLF
      ; Note 1: the server is required to support the language i-default
      ; and as such i-default MUST appear in the language response.
      ; When "i-default" is used, all responses MUST contain only 
      ; ASCII text.
      ;
      ; Note 2: Language tags MUL (Multiple languages) and UND (Undetermined)
      ; MUST NOT be used.


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

   Reply-line |= Lang-Reply-line
      ; Reply-line is defined in [SMTP-UPD]
      ; See section 5 for definition of Lang-Reply-line

   Lang-Reply-line = Reply-code [ SP ext-text ] CRLF
      ; Reply line for LANG command

   ext-text = ext-data text

   ext-data = "[" ext-name SP ext-value "]"
      ; Note 1: In the case of multiline response the same ext-data SHOULD appear
      ; on every line.
      ;
      ; Note 2: In case when server also supports "SMTP Service Extension for
      ; Returning Enhanced Error Codes" [RFC-2034], ext-data MUST follow Enhanced
      ; Error Code. 

   ext-name = "LANG"

   ext-value = Primary-tag
      ; Primary tag as defined by [RFC-1766]  


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-821], Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
   821, August 1982, <ftp://ftp.isi.edu/in-notes/rfc821.txt>

   [SMTP-UPD], Klensin, J., "Simple Mail Transfer Protocol",
   draft-ietf-drums-smtpupd-10.txt (work in progress), February 1999. 

   [RFC-1766], Alvestrand, H., "Tags for the Identification of
   Languages", RFC 1766, UNINETT, March 1995,
   <ftp://ftp.isi.edu/in-notes/rfc1766.txt>

   [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 
   Languages", RFC 2277, January 1998, <ftp://ftp.isi.edu/in-notes/rfc2277.txt>

   [RFC-2044], Yergeau, F., "UTF-8, a transformation format of Unicode
   and ISO 10646, RFC 2044, Alis Technologies, October 1996,
   <ftp://ftp.isi.edu/in-notes/rfc2044.txt>

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997,
   <ftp://ftp.isi.edu/in-notes/rfc2119.txt>

   [IMAP-LANGUAGE], Gahrns, M., "IMAP4 Language Extension", 
   draft-gahrns-imap-language-01.txt (work in progress), Microsoft, 
   October 1999

   [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
   ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd.,
   November 1997, <ftp://ftp.isi.edu/in-notes/rfc2234.txt>

   [RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced
   Error Codes", RFC 2034, Innosoft, October 1996

8.  Acknowledgments

   This document is derived from [IMAP-LANGUAGE]. Thus the work of
   Mike Gahrns and Andrew McCown is appreciated.


9.  Copyright

   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.

10. Author's Address

    Mike Gahrns
    Microsoft
    One Microsoft Way
    Redmond, WA, 98072

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

    Alexey Melnikov
    Messaging Direct, Inc.
    #900, 10117 Jasper Avenue,
    Edmonton, Alberta, T5J 1W8

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

