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