idnits 2.17.00 (12 Aug 2021) /tmp/idnits32914/draft-melnikov-smtp-lang-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 12. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 722. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 693. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 700. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 706. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 754 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 14, 2007) is 5448 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2821 (ref. 'ESMTP') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 4409 (ref. 'SUBMIT') (Obsoleted by RFC 6409) ** Downref: Normative reference to an Informational RFC: RFC 2033 (ref. 'LMTP') ** Obsolete normative reference: RFC 4646 (ref. 'LANG-TAGS') (Obsoleted by RFC 5646) ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- No information found for draft-ietf-eai-dsn-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'EAI-DSN' -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Melnikov (Ed.) 2 Internet Draft Isode Limited 3 Intended status: Standards Track June 14, 2007 4 Expires: December 2007 6 SMTP Language Extension 7 draft-melnikov-smtp-lang-07.txt 9 By submitting this Internet-Draft, each author represents that any 10 applicable patent or other IPR claims of which he or she is aware 11 have been or will be disclosed, and any of which he or she becomes 12 aware will be disclosed, in accordance with Section 6 of BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Copyright Notice 32 Copyright (C) The IETF Trust (2007). 34 Abstract 36 The Simple Mail Transfer Protocol (RFC 2821) allows server responses 37 to include human-readable text that in many cases needs to be 38 presented to the user. This document specifies a way for a client to 39 negotiate which language the server should use when sending 40 human-readable text. It also extends the UTF-8 Delivery Status 41 Notifications format to include language field for the human-readable 42 text. 44 0. Meta Information on this draft 46 This information is intended to facilitate discussion. 48 <> 50 The protocol discussed in this document is experimental and subject 51 to change. Persons planning on either implementing or using this 52 protocol are STRONGLY URGED to get in touch with the author before 53 embarking on such a project. 55 ToDo List: 57 1). Martin Duerst wrote: 59 On the other hand, for the LANG parameter for the MAIL 60 command should allow a language priority list. The reason 61 for this is that (if my understanding is correct), this 62 parameter is passed on along the relay chain of SMTP servers, 63 and is supposed to go back to the original sender, and 64 using a list increases the chance that there is something 65 at the relevant server that can be understood by the 66 originator. 68 2). Martin Duerst wrote: 70 For language fallback, I suggest you have a look at 71 http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-15.txt 72 (also IESG-approved). This gives you the (basic) "language-range" 73 ABNF construct that includes the "*" wildcard. 75 Also, it seems that the matching going on on the server when the 76 client issues a LANG command (e.g. in Example 5) is very close to 77 and can (and should) be described in terms of Section 3.4, Lookup, 78 of the above draft. The only difference I see is that Section 3.4 79 requires a solution (maybe default) in all cases, whereas in your 80 case, the default if no matching language is found is not i-default, 81 but "no change" or in other words, "previously selected language". 83 3). Greg Vaudreuil wrote: 85 The interaction between the LANG verb and the LANG Mail tag is not 86 specified. The goal of the MAIL FROM tag is to get responses useful 87 to the message sender. Those responses may come in the form of the 88 DSN itself (covered) or in the SMTP reply converted to a DSN by the 89 client SMTP. If the SMTP client requests french SMTP dialogue but 90 the message sender requests German for an error message, the SMTP 91 reply code text should be in German, that is, the MAIL-FROM LANG tag 92 should override the LANG verb for the SMTP responses used to 93 generate a DSN on the client SMTP side. 95 4). Chris Newman: 97 SMTP responses should be allowed to contain multiple languages: 98 the first is always English, followed by a special delimiter, 99 followed by text in another language (maybe allow for more than 100 2 languages). This can be done as a multiline response, e.g. 102 250-Command has succeeded 103 250 105 <> 109 5). Stephane Bortzmeyer wrote: 111 Otherwise, in the security section, I suggest to include text like: 113 Languages and language variations such as scripts are often closely 114 associated with specific social, national, religious or ethnic 115 affinities. Thus, language tags used in content negotiation, like 116 other information exchanged on the Internet, might be a source of 117 concern because they might be used to infer information about the 118 sender and thus identify potential targets for surveillance. 120 If, for instance, the same program is both a Web browser and a Mail 121 User Agent, the fact that the user configured his Web browser to 122 request pages in a specific language should not automatically imply 123 that his mail client broadcasts this preference to every Usenet 124 newsgroup or mailing list. 126 [Rationale: in countries like Moldavia or the former Yugoslavia, 127 asking for the cyrillic or the latin script is not innocent and 128 is often tied to political views.] 130 Changes since -00 132 1). Corrected grammar error in LANG command description section 134 2). Included Mark Crispin's suggestion of allowing the server to 135 substitute a primary language if the sublanguage asked for is not 136 available. 138 3). Added section 5 that describes extended LANG reply 140 4). Corrected example, more examples 142 5). Added extension mechanism 144 6). Specified interaction with RFC-2034 ("SMTP Service Extension for 145 Returning Enhanced Error Codes") 147 7). LANG command must always have language-tag as a parameter. Only EHLO 148 response could be used to examine list of supported languages. 150 Changes since -01 152 1). Corrected ABNF for CR 154 2). Updated Copyright section 156 3). Other minor bugfixes 158 Changes since -02 160 1). Extended DSN format to include language tag 162 2). Fixed few typos. 164 Changes since -03 166 1). Changed DSN format to include language tag and translation of text 167 part of diagnostic-code-field. Don't use diagnostic-code-field for 168 a non English text. 170 2). Added LANG parameter to MAIL FROM. 172 Changes since -04 174 1). Updated boilerplate. 176 2). Updated references. Split references into Normative and Informative. 178 3). Updated ABNF (ABNF for UTF-8 responses, allow for multiple language 179 tags) 181 4). Clarified that LANGUAGE extension is applicable to both MTAs and 182 MSAs. 184 5). Added '*' language (to match EAI POP3 draft). 186 6). Fixed EHLO capabilities in examples to match HELP output. 188 7). Added new section on line length limit. 190 8). Copied Security Considerations from EAI POP3 document. 192 9). Removed any mentioning of extensions to the LANG command. 194 10). Made extended data prefix optional (currently it is only used 195 in response to the LANG command) 197 11). Many minor editorial changes. 199 Changes since -05 201 1). Updated boilerplate. 203 2). Replaced reference to RFC 3066 with draft-ietf-ltru-registry, 204 removed some text as a result of this change. 206 3). Clarified that if the receiving MTA doesn't support the LANGUAGE 207 extension, then the LANG parameter must be silently ignored. 209 4). Updated DSN format ABNF as per comment from Harald Alvestrand. 211 Open issues 213 0). Open issues are enclosed in <<>>. 215 1. Conventions used in this document 217 In examples, "C:" and "S:" indicate lines sent by the client and 218 server respectively. If such lines are wrapped without a new "C:" or 219 "S:" label, then the wrapping is for editorial clarity and is not 220 part of the command. 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 226 2. Framework for the Language SMTP service extension 228 The Language SMTP service extension uses the SMTP service extension 229 mechanism described in [ESMTP]. The following SMTP service extension 230 is therefore defined: 232 (1) The name of the SMTP service extension is "Language". This 233 extension is applicable to regular SMTP [ESMTP], Message 234 Submission Protocol [SUBMIT] and LMTP [LMTP]. 236 (2) The EHLO keyword value associated with this service extension is 237 "LANGUAGE". 239 (3) The LANGUAGE EHLO keyword will have zero or more space separated 240 arguments, each containing a name of supported language tags. 241 If no arguments are specified, this means that server is 242 unable to enumerate the list of languages it supports. 244 (4) A new SMTP verb "LANG" is defined by this document. 246 (5) One optional parameter is added to the MAIL command: 248 An optional parameter for the MAIL command, using the 249 esmtp-keyword "LANG", (used to propagate a language that should be 250 used in human readable part and/or localized-diagnostic-text-field 251 field of "message/delivery-status" part (see section 6.) of a 252 delivery status notification for the message), is defined in 253 section 7. 255 3. LANG Command 257 LANG 1*(SP language-tag) 259 Arguments: 260 one or more language tag as defined in [LANG-TAGS]. 262 Restrictions: 263 The LANG command is permitted throughout a mail connection. 265 Reply Codes: 266 Success: 267 250 LANG command completed successfully 268 Error: 269 504 None of the specified languages is supported 270 421 Service not available, closing transmission 271 channel 273 Discussion: 274 The LANG command requests that human-readable text emitted by 275 the server be localized to one of the language specified in the 276 argument. If multiple language tags are specified, they are 277 specified in the decreasing order of preference. This is called 278 "the language priority list" in [LANG-MATCH]. 279 If the SMTP client is an MTA, the LANG command can be used to 280 return potential error messages in the language requested by 281 the original sender. 283 If a sublanguage was asked for and not available but the 284 primary language is available, the server SHOULD switch to the 285 primary language and MUST use an extended LANG reply containing 286 the identifier of the primary language it switched to as 287 described in section 5. 289 <> 291 <> 295 Any server that supports this extension MUST support the 296 language "i-default". It SHOULD <> use the language 297 "i-default" as described in [CHARSET-POLICY] as its default 298 language until another supported language is negotiated by the 299 client. If a server is able to enumerate supported languages 300 it MUST include "i-default" in the EHLO response. Otherwise it 301 MUST NOT return any language in the LANGUAGE EHLO response. 303 The special "*" language range argument indicates a request to 304 use a language designated as preferred by the server 305 administrator. The preferred language MAY vary based on the 306 currently authenticated user. 308 If the server can't find any language (or sublanguage) that it 309 supports, the server returns the 504 reply code. Servers 310 supporting the Enhanced Error Codes extension [RFC-2034] 311 SHOULD use the 5.3.3 "System not capable of selected features" 312 [ENHANCED-SC] error code in this case. 314 If the command succeeds, the server will return human-readable 315 responses in the specified language starting with the 316 successful 250 response to the LANG command. These responses 317 will be in UTF-8 [UTF-8]. In particular, LANG command MAY 318 affect the result of a HELP command. The successful 250 319 response to the LANG command MUST use the extended reply as 320 described in section 5. This reply will communicate the 321 selected language to the client. 323 If the command fails, the server will continue to return human- 324 readable responses in the language it was previously using. 326 Example 1: 328 < The server defaults to using responses in "i-default" language 329 until the user explicitly changes the language. > 331 S: 220 smtp.example.com ESMTP server ready 332 C: EHLO main.example.com 333 S: 250-smtp.example.com 334 S: 250-AUTH CRAM-MD5 DIGEST-MD5 335 S: 250-EXPN 336 S: 250-VRFY 337 S: 250-DSN 338 S: 250 LANGUAGE EN FR RU i-default 339 C: HELP 340 S: 214-This is Bukamail version X.X.X 341 S: 214-Topics: 342 S: 214- HELO EHLO MAIL RCPT DATA 343 S: 214- RSET NOOP QUIT HELP VRFY 344 S: 214- EXPN VERB AUTH DSN 345 S: 214-For more info use "HELP ". 346 S: 214 End of HELP info 348 < Once the client changes the language, all responses will be in 349 that language starting with 250 response to the LANG command. 350 Note that in the following examples accented characters 351 are not shown, as they are not allowed in RFCs. However the 352 accented characters, encoded in UTF-8, would be present in 353 the actual protocol exchange. > 355 C: LANG FR 356 S: 250 La commande LANG a ete executee avec succes 358 C: HELP 359 S: 214-Ici le programme Bukamail version X.X.X 360 S: 214-Topics: 361 S: 214- HELO EHLO MAIL RCPT DATA 362 S: 214- RSET NOOP QUIT HELP VRFY 363 S: 214- EXPN VERB AUTH DSN 364 S: 214-Pour obtenir de l'information supplementaire, utilisez 365 "HELP ". 366 S: 214 Fin de l'information 368 < If a server does not support the requested language, responses 369 will continue to be returned in the current language the 370 server is using. > 372 C: LANG DE 373 S: 504 Cette langue n'est pas acceptee 375 Example 2: 377 < The client tries to select a language that is not supported > 379 C: LANG be-Latn 380 S: 504 The specified language is not supported. 382 Example 3: 384 < The client tries to use a LANG extension not supported by 385 the server > 387 C: LANG i-default (blah blah) 388 S: 504 LANG extension blah is not recognized. 390 4. SMTP Line length limit 392 This extension doesn't affect the maximim text line length as defined 393 by [ESMTP] and extended by other ESMTP extensions. However ESMTP 394 maximum line length is defined in octets and *not* Unicode 395 characters. If a server implementation truncates (or splits to create 396 multiline response) UTF-8 response text to conform to such ESMTP 397 limits, it MUST truncate the response at the Unicode character 398 boundary. (E.g. if a response encoded in UTF-8 would be 1002 octets 399 including the terminating CRLF and the last Unicode character before 400 CRLF is represented as 3 UTF-8 octets, the response must be truncated 401 after 997 octets, with the terminating CRLF added after that). 403 5. "LANG" extended reply 405 Extended reply is the reply that contains additional information in 406 the text part. Extended reply allows to pass additional information 407 from server to client. Client may choose to ignore additional 408 information in an extended reply. Thus client that doesn't recognize 409 an extended reply would treat it as a regular SMTP reply. 411 Example 4: 413 < The client tries to select the language, but it is 414 unavailable. However primary language is available> 416 C: LANG FR-ca 417 S: 250 [LANG FR]La commande LANG a ete executee avec succes 419 Client that supports LANGUAGE extension MUST recognize Enhanced Error 420 Codes defined in [RFC-2034]. When server supports both LANGUAGE and 421 ENHANCEDSTATUSCODES extensions, Extended reply data MUST follow any 422 Enhanced Error Code in reply. 424 Example 5: 426 < The server supports both LANGUAGE and ENHANCEDSTATUSCODES> 428 S: 220 smtp.example.com ESMTP server ready 429 C: EHLO main.example.com 430 S: 250-smtp.example.com 431 S: 250-LANGUAGE EN FR RU i-default 432 S: 250 ENHANCEDSTATUSCODES 433 C: LANG FR-ca 434 S: 250 2.0.0 [LANG FR]La Language commande a ete execute avec 435 success 437 6. The LANG parameter of the ESMTP MAIL command 439 Then LANG esmtp-keyword on the extended MAIL command specifies what 440 language should be used in human readable part and/or 441 localized-diagnostic-text-field field of "message/delivery-status" 442 part (see section 7.) of a delivery status notification for the 443 message. 445 If the LANG esmtp-keyword is used, it MUST have an associated 446 esmtp-value. The ABNF for the LANG parameter is: 448 lang-parameter = "LANG=" language-tag 450 If the message is relayed to another SMTP server that supports 451 LANGUAGE ESMTP extension, the MTA acting as the client MUST check if 452 the receiving MTA lists the language specified in lang-param 453 ("requested language") in the list of supported language tags in 454 LANGUAGE EHLO response. If the receiving MTA either lists the 455 requested language or doesn't list any language tag (i.e. the 456 receiving MTA is unable to list languages it supports) the sender 457 MUST issue LANG command for the requested language. After that, 458 regardless of the result of LANG command, the client MTA MUST 459 specify LANG parameter in MAIL command. 461 The receiving MTA SHOULD use the language specified in LANG parameter 462 if it has to generates a DSN for the message. Human readable part in 463 generated DSN SHOULD contain the description of the event in both 464 i-default and the requested language. If the receiving MTA doesn't 465 support the requested language, it MUST act as if the client didn't 466 specify any LANG parameter in the MAIL command. 468 If the receiving MTA doesn't support the LANGUAGE extension, the 469 sending MTA MUST behave as if the LANG parameter was not specified, 470 i.e. the LANG parameter MUST be silently dropped. 472 Example 6: 474 < Relaying of the message > 476 S: 220 smtp.example.com ESMTP server ready 477 C: EHLO main.example.com 478 S: 250-smtp.example.com 479 S: 250-DSN 480 S: 250-8BITMIME 481 S: 250 LANGUAGE 482 C: LANG RU 483 S: 504 Unsupported language 484 C: MAIL FROM: LANG=ru 485 S: 250 sender ok 486 C: DATA 487 S: 354 okay, send message 488 C: (message goes here) 489 C: . 490 S: 250 message accepted 491 C: QUIT 492 S: 221 goodbye 494 7. Delivery status notifications and extension 496 This section updates [EAI-DSN]. 498 The format of International delivery status notifications 499 (message/utf-8-delivery-status content type) is specified in 500 [EAI-DSN]. This memo extends the per-recipient-fields of [EAI-DSN] 501 [DSN] to include one new field, Localized-Diagnostic, that is 502 equivalent to text part of Diagnostic-Code but includes a language 503 tag and contains text in the specified language. In the Augmented 504 BNF [ABNF], per-recipient-fields is therefore extended as follows: 506 per-recipient-fields = 507 [ original-recipient-field CRLF ] 508 final-recipient-field CRLF 509 action-field CRLF 510 status-field CRLF 511 [ remote-mta-field CRLF ] 512 [ *(localized-diagnostic-text-field CRLF) 513 diagnostic-code-field CRLF ] 514 [ last-attempt-date-field CRLF ] 515 [ will-retry-until-field CRLF ] 516 *( extension-field CRLF ) 518 <> 521 localized-diagnostic-text-field = "Localized-Diagnostic" ":" 522 language ";" *utf8-text 524 where language is a language tag as described in [LANG-TAGS] and 525 ABNF for utf8-text is specified in Section 8 of this document. 527 An SMTP server that supports both DSN and LANGUAGE extensions SHOULD 528 include localized-diagnostic-text-field. Note that multiple 529 Localized-Diagnostic DSN fields are allowed, but they MUST use 530 different language tags. diagnostic-code-field MUST NOT contain 531 text in any language other than English. 533 8. Formal Syntax 535 The following syntax specification uses the augmented Backus-Naur 536 Form (BNF) as described in [ABNF]. Non-terminals referenced but not 537 defined below are as defined by [ESMTP] or [ABNF]. 539 Except as noted otherwise, all alphabetic characters are 540 case-insensitive. The use of upper or lower case characters to 541 define token strings is for editorial clarity only. Implementations 542 MUST accept these strings in a case-insensitive fashion. 544 LANG-Command = "LANG" 1*(SP language-tag) CRLF 546 LANGUAGE-List = "LANGUAGE" *(SP ) CRLF 547 ; Note 1: When "i-default" is used, all responses MUST be 548 ; entirely in ASCII. 549 ; 550 ; Note 2: See [LANG-TAGS] for the list of allowed 551 ; language tags. 553 language-tag = as defined in [LANG-TAGS] 555 Reply-line |= Lang-Reply-line 556 ; Reply-line is defined in [ESMTP]. 557 ; See section 5 for description of Lang-Reply-line 559 Lang-Reply-line = Reply-code [ SP ext-text ] CRLF 560 ; Reply line for a LANG command 562 ext-text = [ext-data] utf8-text 564 utf8-text = 1*utf8-no-cr-lf 566 utf8-no-cr-lf = %d1-9 / ; Any Unicode character except for NUL, 567 %d11 / ; CR and LF 568 %d12 / 569 %d14-127 / 570 UTFMB 572 UTFMB = UTF2 / UTF3 / UTF4 574 UTF0 = %x80-BF 576 UTF2 = %xC2-DF UTF0 578 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / 579 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) 581 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / 582 %xF4 %x80-8F 2(UTF0) 584 ext-data = "[" ext-name SP ext-value "]" 585 ; Note 1: In the case of multiline response the same ext-data 586 ; SHOULD appear on every line. 587 ; 588 ; Note 2: In case when server also supports "SMTP Service 589 ; Extension for Returning Enhanced Error Codes" [RFC-2034], 590 ; ext-data MUST follow any Enhanced Error Code. 592 ext-name = "LANG" 594 ext-value = Primary-tag 595 ; Primary tag as defined by [LANG-TAGS] 597 9. Security Considerations 599 It is possible for a man-in-the-middle attacker to insert a LANG 600 command in the command stream thus making protocol-level diagnostic 601 responses unintelligible to the user. A mechanism to integrity 602 protect the session, such as TLS [TLS] can be used to defeat such 603 attacks. 605 10. References 607 10.1. Normative References 609 [ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 610 April 2001. 612 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for 613 Mail", RFC 4409, April 2006. 615 [LMTP] Myers, J., "Local Mail Transfer Protocol", Carnegie-Mellon 616 University, RFC 2033, October 1996. 618 [LANG-TAGS] Phillips, A. and M. Davis, "Tags for Identifying 619 Languages", RFC 4646, September 2006. 621 [LANG-MATCH] Phillips, A. and M. Davis, "Matching of Language Tags", 622 RFC 4647, September 2006. 624 [CHARSET-POLICY] Alvestrand, H., "IETF Policy on Character Sets and 625 Languages", RFC 2277, January 1998. 627 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 628 10646", STD 63, RFC 3629, November 2003. 630 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", RFC 2119, March 1997. 633 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 634 Specifications: ABNF", RFC 4234, October 2005. 636 [RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced 637 Error Codes", RFC 2034, Innosoft, October 1996. 639 [ENHANCED-SC] Vaudreuil, G., "Enhanced Mail System Status Codes", 640 RFC 3463, January 2003. 642 [EAI-DSN] Newman, C., "International Delivery and Disposition 643 Notifications", work in progress, draft-ietf-eai-dsn-XX.txt 645 [DSN] Moore , K., Vaudreuil, G., "An Extensible Message Format for 646 Delivery Status Notifications", University of Tennessee, Lucent 647 Technologies, RFC 3464, January 2003. 649 10.2. Informative References 651 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer 652 Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. 654 11. Acknowledgments 656 This document is based on the early version of 657 draft-gahrns-imap-language-xx.txt. Thus the work of Andrew McCown is 658 appreciated. 660 Many thanks to the following people who gave feedback on the 661 document: Chris Newman, Brad Knowles, Paul Hoffman, Harald 662 Alvestrand, Martin Duerst, Greg Vaudreuil and Stephane Bortzmeyer. 664 12. Author's Address 666 Mike Gahrns 667 Microsoft 668 One Microsoft Way 669 Redmond, WA, 98072 671 Phone: (425) 936-9833 672 Email: mikega@microsoft.com 674 Alexey Melnikov (Editor) 675 Isode Limited 676 5 Castle Business Village 677 36 Station Road 678 Hampton, Middlesex 679 TW12 2BX, 680 United Kingdom 682 EMail: Alexey.Melnikov@isode.com 684 Intellectual Property Statement 686 The IETF takes no position regarding the validity or scope of any 687 Intellectual Property Rights or other rights that might be claimed to 688 pertain to the implementation or use of the technology described in 689 this document or the extent to which any license under such rights 690 might or might not be available; nor does it represent that it has 691 made any independent effort to identify any such rights. Information 692 on the procedures with respect to rights in RFC documents can be 693 found in BCP 78 and BCP 79. 695 Copies of IPR disclosures made to the IETF Secretariat and any 696 assurances of licenses to be made available, or the result of an 697 attempt made to obtain a general license or permission for the use of 698 such proprietary rights by implementers or users of this 699 specification can be obtained from the IETF on-line IPR repository at 700 http://www.ietf.org/ipr. 702 The IETF invites any interested party to bring to its attention any 703 copyrights, patents or patent applications, or other proprietary 704 rights that may cover technology that may be required to implement 705 this standard. Please address the information to the IETF at 706 ietf-ipr@ietf.org. 708 Copyright Statement 710 Copyright (C) The IETF Trust (2007). 712 This document is subject to the rights, licenses and restrictions 713 contained in BCP 78, and except as set forth therein, the authors 714 retain all their rights. 716 This document and the information contained herein are provided on an 717 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 718 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 719 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 720 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 721 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 722 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 724 Acknowledgment 726 Funding for the RFC Editor function is provided by the IETF 727 Administrative Support Activity (IASA).