smtp language extenstion

3 files changed, 1283 insertions, 0 deletions

diff --git a/Documentation/en/I-D/draft-melnikov-smtp-lang-00.txt b/Documentation/en/I-D/draft-melnikov-smtp-lang-00.txt
new file mode 100644
index 00000000..ea172768
--- /dev/null
+++ b/Documentation/en/I-D/draft-melnikov-smtp-lang-00.txt
@@ -0,0 +1,275 @@
+Network Working Group                     A. Melnikov, Messaging Direct
+Internet Draft
+Document: draft-melnikov-smtp-lang-00.txt                     June 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.
+
+
+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 AUTH 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
+
+  (5) No additional SMTP parameters to either MAIL FROM or RCPT TO commands 
+      are defined by this 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]
+
+     Arguments:
+         Zero or one language tag as defined by [RFC-1766].
+
+     Restrictions:
+         The LANG command is permitted throughout a mail connection.
+
+     Reply Codes:
+         Success:
+            250 LANG command completed successfully
+         Error: 
+            504 Language tag is unknown
+            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 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.
+
+     Example:
+
+        < The server defaults to using English responses 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 DE 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 executee 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 utiliser "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: 250 Ce Language n'est pas supporte
+
+
+5. 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 CRLF
+
+   LANGUAGE_List = "LANGUAGE" *(SPACE <language_tag>) CRLF
+      ; Note: 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 
+      ; English text.
+
+   language_tag =  <language_tag> as defined in [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>
+
+   [RFC-1766], Alvestrand, H., "Tags for the Identification of
+   Languages", RFC 1766, UNINETT, March 1995,
+   <ftp://ftp.isi.edu/in-notes/rfc1766.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., McCown, A., "IMAP4 Language Extension", 
+   draft-gahrns-imap-language-00.txt (work in progress), Microsoft, 
+   Mitsubishi Electric ITA, November 1997
+
+   [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>
+
+   [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 
+   Languages", RFC 2277, January 1998, <ftp://ftp.isi.edu/in-notes/rfc2277.txt>
+
+
+8.  Acknowledgments
+
+   This document is derived from [IMAP-LANGUAGE]. The authors would thank 
+   Mike Gahrns and Andrew McCown for their perfect work.
+
+
+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
+
+    Alexey Melnikov
+    Messaging Direct, Inc.
+
+    Home address :
+    121293, Russia, Moscow,
+    general Ermolov street, 6 - 90
+
+    Email: alexey.melnikov@messagingdirect.com
+
+    Fax (San Diego, CA) : 1 (619) 8393837
+
diff --git a/Documentation/en/I-D/draft-melnikov-smtp-lang-02.txt b/Documentation/en/I-D/draft-melnikov-smtp-lang-02.txt
new file mode 100644
index 00000000..ffc9a4db
--- /dev/null
+++ b/Documentation/en/I-D/draft-melnikov-smtp-lang-02.txt
@@ -0,0 +1,510 @@
+Network Working Group                            Mike Gahrns, Microsoft 
+Internet Draft                        Alexey Melnikov, Messaging Direct
+Document: draft-melnikov-smtp-lang-02.txt                 November 2000
+
+
+                          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.
+
+
+   Changes since -01 
+    
+1). Corrected ABNF for CR
+
+2). Updated Copyright section
+
+2). Other minor bugfixes
+
+
+   Changes since -02 
+    
+1). Extended DSN format to include language tag
+
+
+   Open issues
+
+1) Should language information be added to MAIL FROM so that it could be used
+   in DSN/MDN notification messages?
+
+2). What a server should send in LANGUAGE EHLO response if it can't enumerate all
+   of the supported languages but only some of them?
+
+3). There are several ways for representing language information
+in DSN format. Some of them listed below:
+
+      a). Add new field to per-recipient part of message/delivery-status part of DSN
+      b). Extend format of diagnostic-code-field to include language, for example:
+            diagnostic-code-field =
+                 "Diagnostic-Code" ":" diagnostic-type ";" [ language ";" ] *text
+
+	    As an alternative the idea of encoding language inside text as proposed
+          by RFC 2231 ("MIME Parameter Value and Encoded Word Extensions: 
+          Character Sets, Languages, and Continuations") can be used.
+
+      c). Use Content-Language MIME header in message/delivery-status part of DSN
+
+    The draft uses a), however another alternative may be better.
+
+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. It also extends DSN format to include
+   language field for the 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
+
+   Any server that supports this extension MUST support the language "i-default".
+   It SHOULD use the language "i-default" as described in [CHARSET-POLICY] as its
+   default language until another supported language is negotiated by the client. 
+   If a server is able to enumerate supported languages it MUST include "i-default"
+   in EHLO response. Otherwise it MUST NOT return any language in LANGUAGE 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.
+
+
+6. "LANG" extended 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
+
+
+7. Delivery status notifications and extension
+
+   The format of delivery status notifications (DSNs) is specified in
+   [DSN]. This memo extends the per-recipient-fields of [DSN] to include a new DSN field, 
+   Language, indicating the language tag for diagnostic-code-field. In the augmented BNF
+   of RFC 822 [ABNF], per-recipient-fields is therefore extended as follows:
+
+     per-recipient-fields =
+          [ original-recipient-field CRLF ]
+          final-recipient-field CRLF
+          action-field CRLF
+          status-field CRLF
+          [ remote-mta-field CRLF ]
+          [ [language-field CRLF]
+            diagnostic-code-field CRLF ]
+          [ last-attempt-date-field CRLF ]
+          [ will-retry-until-field CRLF ]
+          *( extension-field CRLF )
+
+    language-field = "Language" ":" language
+
+   where language is a language tag as described in [RFC-1766].
+
+   An SMTP server that supports both DSN and LANG extensions SHOULD include language-field
+   if diagnostic-code-field contains text in any language other than English.
+
+
+8. 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              = %x0D     ;; 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 6 for description 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]  
+
+
+9. 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.
+
+
+10. 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
+
+   [DSN]  Moore, K. and G. Vaudreuil, "An Extensible Message Format for
+   Delivery Status Notifications", RFC 1894, January 1996.
+
+11.  Acknowledgments
+
+   This document is derived from [IMAP-LANGUAGE]. Thus the work of
+   Mike Gahrns and Andrew McCown is appreciated.
+
+
+12.  Copyright
+
+   Copyright (C) The Internet Society 2000. 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+13. 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
+
diff --git a/Documentation/en/I-D/draft-melnikov-smtp-lang-03.txt b/Documentation/en/I-D/draft-melnikov-smtp-lang-03.txt
new file mode 100644
index 00000000..50b46f0c
--- /dev/null
+++ b/Documentation/en/I-D/draft-melnikov-smtp-lang-03.txt
@@ -0,0 +1,498 @@
+Network Working Group                            Mike Gahrns, Microsoft 
+Internet Draft           Alexey Melnikov, ACI WorldWide/MessagingDirect
+Document: draft-melnikov-smtp-lang-03.txt                    March 2001
+
+
+                          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 Error Codes")
+
+7) LANG command must always have language-tag as a parameter. 
+   Only EHLO response could be used to examine list of supported languages.
+
+
+   Changes since -01 
+    
+1). Corrected ABNF for CR
+
+2). Updated Copyright section
+
+2). Other minor bugfixes
+
+
+   Changes since -02 
+    
+1). Extended DSN format to include language tag
+
+2). Fixed few typos.
+
+
+   Open issues
+
+1) Should language information be added to MAIL FROM so that it could be used
+   in DSN/MDN notification messages?
+
+2). What a server should send in LANGUAGE EHLO response if it can't enumerate all
+   of the supported languages but only some of them?
+
+
+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. It also extends DSN format to include
+   language field for the 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
+
+   Any server that supports this extension MUST support the language "i-default".
+   It SHOULD use the language "i-default" as described in [CHARSET-POLICY] as its
+   default language until another supported language is negotiated by the client. 
+   If a server is able to enumerate supported languages it MUST include "i-default"
+   in EHLO response. Otherwise it MUST NOT return any language in LANGUAGE 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 error code 504 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.
+
+
+6. "LANG" extended 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
+
+
+7. Delivery status notifications and extension
+
+   The format of delivery status notifications (DSNs) is specified in
+   [DSN]. This memo extends the per-recipient-fields of [DSN] to include a new DSN field, 
+   Language, indicating the language tag for diagnostic-code-field. In the augmented BNF
+   of RFC 822 [ABNF], per-recipient-fields is therefore extended as follows:
+
+     per-recipient-fields =
+          [ original-recipient-field CRLF ]
+          final-recipient-field CRLF
+          action-field CRLF
+          status-field CRLF
+          [ remote-mta-field CRLF ]
+          [ [language-field CRLF]
+            diagnostic-code-field CRLF ]
+          [ last-attempt-date-field CRLF ]
+          [ will-retry-until-field CRLF ]
+          *( extension-field CRLF )
+
+    language-field = "Language" ":" language
+
+   where language is a language tag as described in [RFC-1766].
+
+   An SMTP server that supports both DSN and LANG extensions SHOULD include language-field
+   if it knows that diagnostic-code-field contains text in any language other than English.
+
+
+8. 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              = %x0D     ;; 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 6 for description 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]  
+
+
+9. 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.
+
+
+10. 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
+
+   [DSN]  Moore, K. and G. Vaudreuil, "An Extensible Message Format for
+   Delivery Status Notifications", RFC 1894, January 1996.
+
+11.  Acknowledgments
+
+   This document is derived from [IMAP-LANGUAGE]. Thus the work of
+   Mike Gahrns and Andrew McCown is appreciated.
+
+
+12.  Copyright
+
+   Copyright (C) The Internet Society 2000-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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+13. 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
+