Internet DRAFT - draft-melnikov-esmtp-lang
draft-melnikov-esmtp-lang
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
