idnits 2.17.1 draft-ietf-eai-smtpext-13.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1068. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1074. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2821, but the abstract doesn't seem to directly say this. It does mention RFC2821 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC2821, updated by this document, for RFC5378 checks: 1995-11-08) -- 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 (July 8, 2008) is 5769 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 721, but not defined ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) == Outdated reference: A later version (-05) exists of draft-hansen-4468upd-mailesc-registry-03 == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-07 -- Obsolete informational reference (is this intentional?): RFC 974 (Obsoleted by RFC 2821) == Outdated reference: A later version (-11) exists of draft-klensin-rfc2821bis-10 Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yao, Ed. 3 Internet-Draft W. Mao, Ed. 4 Updates: RFC4952, 2821 and 2822 CNNIC 5 (if approved) July 8, 2008 6 Intended status: Experimental 7 Expires: January 9, 2009 9 SMTP extension for internationalized email address 10 draft-ietf-eai-smtpext-13.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 9, 2009. 37 Abstract 39 This document specifies an SMTP extension for transport and delivery 40 of email messages with internationalized email addresses or header 41 information. Communication with systems that do not implement this 42 specification is specified in another document. This document 43 updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and 44 has some material updating RFC 4952. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 50 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 52 3. Mail Transport-level Protocol . . . . . . . . . . . . . . . . 4 53 3.1. Framework for the Internationalization Extension . . . . . 4 54 3.2. The UTF8SMTP Extension . . . . . . . . . . . . . . . . . . 5 55 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7 56 3.4. The ALT-ADDRESS Parameter . . . . . . . . . . . . . . . . 8 57 3.5. ALT-ADDRESS Parameter Usage and Response Codes . . . . . . 10 58 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 10 59 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 11 60 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 11 61 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 12 62 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 12 63 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 13 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 67 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 17 68 7.1. draft-ietf-eai-smtpext: Version 00 . . . . . . . . . . . . 17 69 7.2. draft-ietf-eai-smtpext: Version 01 . . . . . . . . . . . . 17 70 7.3. draft-ietf-eai-smtpext: Version 02 . . . . . . . . . . . . 18 71 7.4. draft-ietf-eai-smtpext: Version 03 . . . . . . . . . . . . 18 72 7.5. draft-ietf-eai-smtpext: Version 04 . . . . . . . . . . . . 18 73 7.6. draft-ietf-eai-smtpext: Version 05 . . . . . . . . . . . . 18 74 7.7. draft-ietf-eai-smtpext: Version 06 . . . . . . . . . . . . 18 75 7.8. draft-ietf-eai-smtpext: Version 07 . . . . . . . . . . . . 18 76 7.9. draft-ietf-eai-smtpext: Version 08 . . . . . . . . . . . . 19 77 7.10. draft-ietf-eai-smtpext: Version 09 . . . . . . . . . . . . 19 78 7.11. draft-ietf-eai-smtpext: Version 10 . . . . . . . . . . . . 19 79 7.12. draft-ietf-eai-smtpext: Version 11 . . . . . . . . . . . . 19 80 7.13. draft-ietf-eai-smtpext: Version 12 . . . . . . . . . . . . 19 81 7.14. draft-ietf-eai-smtpext: Version 13 . . . . . . . . . . . . 19 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 85 Appendix A. Material Updating RFC 4952 . . . . . . . . . . . . . 21 86 A.1. Conventional Message and Internationalized Message . . . . 22 87 A.2. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 A.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 22 89 A.4. Implementation Advice . . . . . . . . . . . . . . . . . . 22 90 A.5. Applicability of SMTP Extension to Additional Uses . . . . 23 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 92 Intellectual Property and Copyright Statements . . . . . . . . . . 24 94 1. Introduction 96 An internationalized email address includes two parts, the local part 97 and the domain part. The ways email addresses are used by protocols 98 are different from the ways domain names are used. The most critical 99 difference is that emails are delivered through a chain of clients 100 and servers while domain names are resolved by name servers looking 101 up those names in their own tables. In addition to this, the simple 102 mail transfer protocol [RFC2821] provides a negotiation mechanism 103 about service extension with which clients can discover server 104 capabilities and make decisions for further processing. An extended 105 overview of the extension model for internationalized addresses and 106 headers appears in [RFC4952], referred to as "the framework document" 107 or just as "Framework" elsewhere in this specification. This 108 document specifies an SMTP extension to permit internationalized 109 email addresses in envelopes, and UNICODE characters (encoded in 110 UTF-8) [RFC3629] in headers. 112 1.1. Role of this specification 114 The framework document specifies the requirements for, and describes 115 components of, full internationalization of electronic mail. A 116 thorough understanding of the information in that document and in the 117 base Internet email specifications [RFC2821] [RFC2822] is necessary 118 to understand and implement this specification. 120 This document specifies an element of the email internationalization 121 work, specifically the definition of an SMTP extension [RFC2821] for 122 internationalized email address transport delivery. 124 1.2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 The terms "conventional message" and "internationalized message" are 131 defined in an appendix to this specification. The terms "UTF-8 132 string" or "UTF-8 character" are used informally to refer to Unicode 133 characters encoded in UTF-8 [RFC3629]. All other specialized terms 134 used in this specification are defined in the framework document or 135 in the base Internet email specifications [RFC2821] [RFC2822]. In 136 particular, the terms "ASCII address", "internationalized email 137 address", "non-ASCII address", "i18mail address", "UTF8SMTP", 138 "message" and "mailing list" are used in this document according to 139 the definitions in the framework one. 141 This specification defines only those Augmented BNF for Syntax 142 Specifications (ABNF) [RFC5234] syntax rules that are different from 143 those of the base email specifications [RFC2821][RFC2822] and, where 144 the earlier rules are upgraded or extended, gives them new names. 145 When the new rule is a small modification to the older one, it is 146 typically given a name starting with "u". Rules that are undefined 147 here may be found in the base email specifications under the same 148 names. 150 [[anchor3: NOTE TO RFC EDITOR: Please remove the following text 151 before publication.]] 152 This specification is being discussed on the EAI mailing list. See 153 https://www1.ietf.org/mailman/listinfo/ima for information about 154 subscribing. The list's archive is at 155 http://www1.ietf.org/mail-archive/web/ima/index.html. 157 2. Overview of Operation 159 This specification describes an optional extension to the email 160 transport mechanism that permits non-ASCII [ASCII] characters in both 161 the envelope and header fields of messages, which are encoded with 162 UTF-8 [RFC3629] characters. The extension is identified with the 163 token "UTF8SMTP". In order to provide information that may be needed 164 in downgrading, an optional alternate ASCII address may be needed if 165 an SMTP client attempts to transfer an internationalized message and 166 encounters a server that does not support this extension. 168 The EAI-utf8header specification [EAI-utf8header] provides the 169 details of how and where non-ASCII characters are permitted in the 170 header fields of messages. The context for this specification is 171 described in the framework document. 173 3. Mail Transport-level Protocol 175 3.1. Framework for the Internationalization Extension 177 The following service extension is defined: 179 1. The name of the SMTP service extension is "Email Address 180 Internationalization". 181 2. The EHLO keyword value associated with this extension is 182 "UTF8SMTP". 183 3. No parameter values are defined for this EHLO keyword value. In 184 order to permit future (although unanticipated) extensions, the 185 EHLO response MUST NOT contain any parameters for that keyword. 186 Clients MUST ignore any parameters, that is, clients MUST behave 187 as if the parameters do not appear. If a server includes 188 UTF8SMTP in its EHLO response, it MUST be fully compliant with 189 this version of this specification. 190 4. One optional parameter, ALT-ADDRESS, is added to the MAIL and 191 RCPT commands of SMTP. ALT-ADDRESS specifies an all-ASCII 192 address which can be used as a substitute for the corresponding 193 primary (i18mail) address when downgrading. More discussion of 194 the use of this parameter appears in [RFC4952] and 195 [EAI-downgrading]. 196 5. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN 197 commands. The parameter UTF8REPLY has no value. The parameter 198 indicates that the SMTP client can accept Unicode characters in 199 UTF-8 encoding in replies from the VRFY and EXPN commands. 200 6. No additional SMTP verbs are defined by this extension. 201 7. Servers offering this extension MUST provide support for, and 202 announce, the 8BITMIME extension [RFC1652]. 203 8. The reverse-path and forward-path of the SMTP MAIL and RCPT 204 commands are extended to allow Unicode characters encoded in 205 UTF-8 in mailbox names (addresses). 206 9. The mail message body is extended as specified in 207 [EAI-utf8header]. 208 10. The maximum length of MAIL and RCPT command lines is increased 209 by 460 characters by the possible addition of the ALT-ADDRESS 210 keyword and value. 211 11. The UTF8SMTP extension is valid on the submission port 212 [RFC4409]. 214 3.2. The UTF8SMTP Extension 216 An SMTP Server that announces this extension MUST be prepared to 217 accept a UTF-8 string [RFC3629] in any position in which RFC 2821 218 specifies that a mailbox can appear. That string MUST be parsed only 219 as specified in RFC 2821, i.e., by separating the mailbox into source 220 route, local part and domain part, using only the characters colon 221 (U+003A), comma (U+002C), and at-sign (U+0040) as specified there. 222 Once isolated by this parsing process, the local part MUST be treated 223 as opaque unless the SMTP Server is the final delivery MTA. Any 224 domain names that are to be looked up in the DNS MUST first be 225 processed into the form specified in IDNA [RFC3490] by means of the 226 ToASCII() operation unless they are already in that form. Any domain 227 names that are to be compared to local strings SHOULD be checked for 228 validity and then MUST be compared as specified in section 3.4 of 229 IDNA. 231 An SMTP Client that receives the UTF8SMTP extension keyword in 232 response to the "EHLO" command MAY transmit mailbox names within SMTP 233 commands as internationalized strings in UTF-8 form. It MAY send a 234 UTF-8 header [EAI-utf8header] (which may also include mailbox names 235 in UTF-8). It MAY transmit the domain parts of mailbox names within 236 SMTP commands or the message header in either the form of ACE (ASCII 237 Compatible Encoding) labels as specified in IDNA [RFC3490] or as 238 UTF-8 strings. All labels in domain parts of mailbox names which are 239 IDNs (either UTF-8 or ACE strings) MUST be valid. If the original 240 client submits a message to a Message Submission Server ("MSA") 241 [RFC4409], it is the responsibility of the MSA that all domain labels 242 are valid; otherwise it is the original client's responsibility. The 243 presence of the UTF8SMTP extension does not change the requirement of 244 RFC 2821 that servers relaying mail MUST NOT attempt to parse, 245 evaluate, or transform the local part in any way. 247 If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP 248 client MUST NOT transmit an internationalized address (For this 249 paragraph, the internationalized domain name in the form of ACE 250 labels as specified in IDNA [RFC3490] is not considered as 251 "internationalized".) and MUST NOT transmit a mail message containing 252 internationalized mail headers as described in [EAI-utf8header] at 253 any level within its MIME structure. Instead, if an SMTP client 254 (SMTP sender) attempts to transfer an internationalized message and 255 encounters a server that does not support the extension, it MUST make 256 one of the following four choices: 258 1. If and only if the SMTP client (sender) is a Message Submission 259 Server ("MSA") [RFC4409], it MAY, consistent with the general 260 provisions for changes by such servers, rewrite the envelope, 261 headers, or message material to make them entirely ASCII and 262 consistent with the provisions of RFC 2821 [RFC2821] and RFC 2822 263 [RFC2822]. 264 2. Either reject the message during the SMTP transaction or accept 265 the message and then generate and transmit a notification of non- 266 deliverability. Such notification MUST be done as specified in 267 RFC 2821 [RFC2821], RFC 3464 [RFC3464], and the EAI DSN 268 specification [EAI-dsn]. 269 3. Find an alternate route to the destination that permits UTF8SMTP. 270 That route may be discovered by trying alternate MX hosts (using 271 preference rules as specified in RFC 2821) or using other means 272 available to the SMTP-sender. 273 4. If and only if ASCII addresses are available for all addresses 274 that appear in the return path and the specific forward paths 275 being attempted, downgrade the message to an all-ASCII form as 276 specified in [EAI-downgrading]. An ASCII address is considered 277 to be "available" for a particular address if the original 278 address in the envelope is in ASCII or if an ALT-ADDRESS 279 parameter is specified for a UTF8SMTP address. 281 The difference between "choice 1" and "choice 4" is that "choice 1" 282 is constrained by Message Submission [RFC4409], while "choice 4" is 283 constrained by [EAI-downgrading]. 285 3.3. Extended Mailbox Address Syntax 287 RFC 2821, section 4.1.2, defines the syntax of a mailbox entirely in 288 terms of ASCII characters, using the production for a mailbox and 289 those on which it depends. 291 The key changes made by this specification are, informally, to 293 o Change the definition of "sub-domain" to permit either the 294 definition above or a UTF-8 string representing a DNS label that 295 is conformant with IDNA [RFC3490]. 296 o Change the definition of "Atom" to permit either the definition 297 above or a UTF-8 string. That string MUST NOT contain any of the 298 ASCII characters (either graphics or controls) that are not 299 permitted in "atext"; it is otherwise unrestricted. 301 According to the description above, the syntax of an 302 internationalized email mailbox name (address) is defined in ABNF 303 [RFC5234] as 305 uMailbox = uLocal-part "@" uDomain 306 ; Replace Mailbox in RFC 2821, section 4.1.2 308 uLocal-part = uDot-string / uQuoted-string 309 ; MAY be case-sensitive 310 ; Replace Local-part in RFC 2821, section 4.1.2 312 uDot-string = uAtom *("." uAtom) 313 ; Replace Dot-string in RFC 2821, section 4.1.2 315 uAtom = 1*ucharacter 316 ; Replace Atom in RFC 2821, section 4.1.2 318 ucharacter = atext / UTF8-non-ascii 320 atext = 322 uQuoted-string = DQUOTE *uqcontent DQUOTE 323 ; Replace Quoted-string in RFC 2821, section 4.1.2 325 DQUOTE = 326 uqcontent = qcontent / UTF8-non-ascii 328 qcontent = 330 uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal 331 ; Replace Domain in RFC 2821, section 4.1.2 333 address-literal = 335 sub-udomain = uLet-dig [uLdh-str] 336 ; Replace sub-domain in RFC 2821, section 4.1.2 338 uLet-dig = Let-dig / UTF8-non-ascii 340 Let-dig = 342 uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig 343 ; Replace Ldh-str in RFC 2821, section 4.1.3 345 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 347 UTF8-2 = 349 UTF8-3 = 351 UTF8-4 = 353 The value of "uDomain" SHOULD be verified by applying the tests 354 specified as part of IDNA [RFC3490]. If that verification fails, the 355 email address with that uDomain MUST NOT be regarded as a valid email 356 address. 358 3.4. The ALT-ADDRESS Parameter 360 If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and 361 RCPT commands is extended to support the optional esmtp-keyword "ALT- 362 ADDRESS". That keyword specifies an alternate all-ASCII address 363 which may be used when downgrading. If the ALT-ADDRESS esmtp-keyword 364 is used, it MUST have an associated esmtp-value (ALT-ADDRESS-esmtp- 365 value, which is defined below). 367 While it may be tempting to consider ALT-ADDRESS as a general-purpose 368 second-chance address, such behavior is not defined here. Instead, 369 in this specification ALT-ADDRESS only has meaning when the 370 associated primary address is non-ASCII and the message is 371 downgraded. This restriction allows for future extension of the 372 specification even though no such extensions are currently 373 anticipated. 375 Based on the definition of mail-parameters in [RFC2821], the ALT- 376 ADDRESS parameter usage in the commands of "MAIL" and "RCPT" is 377 defined as follows. The following definitions are given in the same 378 format as used in RFC 2821. 380 "MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF 381 ; Update the MAIL command in RFC 2821, section 4.1.1.2. 382 ; A new parameter defined by the ABNF non-terminal 383 ; is added. It complies 384 ; with the syntax specified for in RFC 2821. 386 "RCPT TO:" ("" / "" / 387 uForward-path) [ SP Rcpt-parameters ] CRLF 388 ; Update RCPT command in RFC 2821, section 4.1.1.3. 389 ; A new parameter defined by the ABNF non-terminal 390 ; is added. It complies 391 ; with the syntax specified for . 392 ; uDomain is defined in section 3.3 of this document 394 uReverse-path = uPath 395 ; Replace Reverse-path in RFC 2821, section 4.1.2 397 uForward-path = uPath 398 ; Replace Forward-path in RFC 2821, section 4.1.2 400 uPath = "<" [ A-d-l ":" ] uMailbox ">" 401 ; Replace Path in RFC 2821, section 4.1.2 402 ; uMailbox is defined in section 3.3 of this document 404 A-d-l = 405 ALT-ADDRESS-parameter="ALT-ADDRESS=" ALT-ADDRESS-value 407 ALT-ADDRESS-value= xtext 408 ; The value is a mailbox name encoded as xtext. 410 xtext= 412 The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL 413 or RCPT command. ALT-ADDRESS-esmtp-value MUST be an all-ASCII email 414 address before xtext encoding. 416 3.5. ALT-ADDRESS Parameter Usage and Response Codes 418 An "internationalized message" as defined in the appendix of this 419 specification MUST NOT be sent to an SMTP server that does not 420 support UTF8SMTP. Such a message MAY be rejected by a server if it 421 lacks ALT-ADDRESSes as discussed in Section 3.2 of this 422 specification. 424 The three-digit reply codes used in this section are consistent with 425 their meanings as defined in RFC 2821. 427 When messages are rejected because the RCPT command requires an ALT- 428 ADDRESS, the response code 553 is used with the meaning "mailbox name 429 not allowed". When messages are rejected for other reasons, such as 430 the MAIL command requiring an ALT-ADDRESS, the response code 550 is 431 used with the meaning "mailbox unavailable". When the server 432 supports enhanced mail system status codes [RFC3463], response code 433 "5.6.x" [SMTP-codes] is used, meaning that "The ALT-ADDRESS is 434 required but not specified". 436 If the response code is issued after the final "." of the DATA 437 command, the response code "554" is used with the meaning 438 "Transaction failed". When the server supports enhanced mail system 439 status codes [RFC3463], response code "5.6.z" [SMTP-codes] is used, 440 meaning that "UTF8SMTP downgrade failed". 442 [[anchor6: RFC Editor: please insert the proper error codes for 443 "5.6.x" and "5.6.z" after IANA has made the relevant assignments.]] 445 3.6. Body Parts and SMTP Extensions 447 There is no ESMTP parameter to assert that a message is an 448 internationalized message. An SMTP server that requires accurate 449 knowledge of whether a message is internationalized is required to 450 parse all message header fields and MIME header fields in the message 451 body. 453 While this specification requires that servers support the 8BITMIME 454 extension [RFC1652] to ensure that servers have adequate handling 455 capability for 8-bit data and to avoid a number of complex encoding 456 problems, the use of internationalized addresses obviously does not 457 require non-ASCII body parts in the MIME message. The UTF8SMTP 458 extension MAY be used with the BODY=8BITMIME parameter if that is 459 appropriate given the body content or, with the BODY=BINARYMIME 460 parameter, if the server advertises BINARYMIME [RFC3030] and that is 461 appropriate. 463 Assuming that the server advertises UTF8SMTP and 8BITMIME, and 464 receives at least one non-ASCII address, with or without ALT-ADDRESS, 465 the precise interpretation of 'No BODY parameter', "BODY=8BITMIME", 466 and "BODY=BINARYMIME" in the MAIL command is: 467 1. If there is no BODY parameter, the header contains UTF-8 468 characters, but all the body parts are in ASCII (possibly as the 469 result of a Content-transfer-encoding). 470 2. If a BODY=8BITMIME parameter is present, the header contains 471 UTF-8 characters and some or all of the body parts contain 8-bit 472 line-oriented data. 473 3. If a BODY=BINARYMIME parameter is present, the header contains 474 UTF-8 characters and some or all body parts contain binary data 475 without restriction as to line lengths or delimiters. 477 3.7. Additional ESMTP Changes and Clarifications 479 The information carried in the mail transport process involves 480 addresses ("mailboxes") and domain names in various contexts in 481 addition to the MAIL and RCPT commands and extended alternatives to 482 them. In general, the rule is that, when RFC 2821 specifies a 483 mailbox, this specification expects UTF-8 to be used for the entire 484 string; when RFC 2821 specifies a domain name, the name SHOULD be in 485 the form of ACE labels if its raw form is non-ASCII. 487 The following subsections list and discuss all of the relevant cases. 489 3.7.1. The Initial SMTP Exchange 491 When an SMTP connection is opened, the server normally sends a 492 "greeting" response consisting of the '220' reply code and some 493 information. The client then sends the EHLO command. Since the 494 client cannot know whether the server supports UTF8SMTP until after 495 it receives the response from EHLO, any domain names that appear in 496 this dialogue, or in responses to EHLO, MUST be in the hostname form, 497 i.e., internationalized ones MUST be in the form of ACE labels. 499 3.7.2. Mail eXchangers 501 Organizations often authorize multiple servers to accept mail 502 addressed to them. For example, the organization may itself operate 503 more than one server, and may also or instead have an agreement with 504 other organizations to accept mail as a backup. Authorized servers 505 are generally listed in MX records as described in RFC2821. When 506 more than one server accepts mail for the domain-part of a mailbox, 507 it is strongly advised that either all or none of them support the 508 UTF8SMTP extension. Otherwise, surprising downgrades can happen 509 during temporary failures, which users might perceive as a serious 510 reliability issue. 512 3.7.3. Trace Information 514 When an SMTP server receives a message for delivery or further 515 processing, it MUST insert trace ("time stamp" or "Received") 516 information at the beginning of the message content. "Time stamp" or 517 "Received" appears in the form of "Received:" lines. The most 518 important use of Received: lines is for debugging mail faults. When 519 the delivery SMTP server makes the "final delivery" of a message, it 520 inserts a return-path line at the beginning of the mail data. The 521 primary purpose of the Return-path is to designate the address to 522 which messages indicating non-delivery or other mail system failures 523 are to be sent. For the trace information, this memo updates the 524 time stamp line and the return path line [RFC2821] formally defined 525 as follows: 527 uReturn-path-line = "Return-Path:" FWS uReverse-path 528 ; Replaces Return-path-line in section 4.4 of RFC2821 529 ; uReverse-path is defined in Section 3.3 of this document 531 uTime-stamp-line = "Received:" FWS uStamp 532 ; Replaces Time-stamp-line in section 4.4 of RFC2821 534 uStamp = From-domain By-domain uOpt-info ";" FWS date-time 535 ; Replaces Stamp in section 4.4 of RFC2821 537 uOpt-info = [Via] [With] [ID] [uFor] 538 ; Replaces Opt-info in section 4.4 of RFC2821 539 ; The protocol value for With will allow a UTF8SMTP value 541 uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS 542 ; Replaces For in section 4.4 of RFC2821 543 ; uPath and uMailbox are defined in Sections 2.4 and 544 ; 2.3, respectively, of this document 546 Note: The FOR parameter has been changed to match the definition in 547 [RFC2821bis], permitting only one address in the For clause. The 548 group working on that document reached mailing list consensus that 549 the syntax in [RFC2821] that permitted more than one address was 550 simply a mistake. 552 Except in the 'uFor' clause and 'uReverse-path' value where non-ASCII 553 domain names may be used, internationalized domain names in Received 554 fields MUST be transmitted in the form of ACE labels. The protocol 555 value of the WITH clause when this extension is used is one of the 556 UTF8SMTP values specified in the "IANA Considerations" section of 557 this document. 559 3.7.4. UTF-8 Strings in Replies 561 3.7.4.1. MAIL and RCPT Commands 563 If the client issues a RCPT command containing non-ASCII characters, 564 the SMTP server is permitted to use UTF-8 characters in the email 565 address associated with 251 and 551 response codes. 567 If an SMTP client follows this specification and sends any RCPT 568 commands containing non-ASCII addresses, it MUST be able to accept 569 and process 251 or 551 replies containing UTF-8 email addresses. If 570 a given RCPT command does not include a non-ASCII envelope address, 571 the server MUST NOT return a 251 or 551 response containing a non- 572 ASCII mailbox. Instead, it MUST transform such responses into 250 or 573 550 responses that do not contain addresses. 575 3.7.4.2. VRFY and EXPN Commands and the UTF8REPLY Parameter 577 If the VRFY and EXPN commands are transmitted with an optional 578 parameter "UTF8REPLY", it indicates the client can accept UTF-8 579 strings in replies from those commands. This allows the server to 580 use UTF-8 strings in mailbox names and full names which occur in 581 replies without concern that the client might be confused by them. 582 An SMTP client that conforms to this specification MUST accept and 583 correctly process replies from the VRFY and EXPN commands that 584 contain UTF-8 strings. However the SMTP server MUST NOT use UTF-8 585 strings in replies if the SMTP client does not specifically allow 586 such replies by transmitting this parameter. Most replies do not 587 require that a mailbox name be included in the returned text and 588 therefore UTF-8 is not needed in them. Some replies, notably those 589 resulting from successful execution of the VRFY and EXPN commands, do 590 include the mailbox, making the provisions of this section important. 592 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: 594 "VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF 595 ; uLocal-part and uMailbox are defined in 596 ; Section 3.3 of this document 598 "EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF 599 ; uLocal-part and uMailbox are defined in 600 ; Section 3.3 of this document 602 The "UTF8REPLY" parameter does not use a value. If the reply to a 603 VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8, but the SMTP 604 client does not use the "UTF8REPLY" parameter, then the server MUST 605 use either the reply code 252 or 550. Response code 252, defined in 606 [RFC2821], means "Cannot VRFY user, but will accept the message and 607 attempt the delivery". Response code 550, also defined in [RFC2821], 608 means "Requested action not taken: mailbox unavailable". When the 609 server supports enhanced mail system status codes [RFC3463], the 610 enhanced response code as specified below is used. Using the 611 "UTF8REPLY" parameter with a VERIFY (VRFY) or EXPAND (EXPN) command 612 enables UTF-8 replies for that command only. 614 If a normal success response (i.e., 250) is returned, the response 615 MAY include the full name of the user and MUST include the mailbox of 616 the user. It MUST be in either of the following forms: 618 User Name 619 ; uMailbox is defined in section 3.3 of this document 620 ; User Name can contain non-ASCII characters. 622 uMailbox 623 ; uMailbox is defined in section 3.3 of this document 625 If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in 626 the reply, and the server supports enhanced mail system status codes 627 [RFC3463], the enhanced response code is either "5.6.y" or "2.6.y" 628 [SMTP-codes], meaning "A reply containing a UTF-8 string is required 629 to show the mailbox name, but that form of response is not permitted 630 by the client". 632 If the SMTP Client does not support the UTF8SMTP extension, but 633 receives a UTF-8 string in a reply, it may not be able to properly 634 report the reply to the user, and some clients might crash. 636 Internationalized messages in replies are only allowed in the 637 commands under the situations described above. Under any other 638 circumstances, UTF-8 text MUST NOT appear in the reply. 640 Although UTF-8 is needed to represent email addresses in responses 641 under the rules specified in this section, this extension does not 642 permit the use of UTF-8 for any other purposes. SMTP servers MUST 643 NOT include non-ASCII characters in replies except in the limited 644 cases specifically permitted in this section. 646 [[anchor11: RFC Editor: please insert the proper error codes for 647 "5.6.y" and "2.6.y" after IANA has made the relevant assignments.]] 649 4. IANA Considerations 651 IANA is requested to add a new value "UTF8SMTP" to the SMTP Service 652 Extension subregistry of the Mail Parameters registry, according to 653 the following data: 655 +----------+---------------------------------+-----------+ 656 | Keywords | Description | Reference | 657 +----------+---------------------------------+-----------+ 658 | UTF8SMTP | Internationalized email address | [RFCXXXX] | 659 +----------+---------------------------------+-----------+ 661 This document adds new values to the SMTP Enhanced Status Code 662 subregistry of the Mail Parameters registry, following the guidance 663 in Section 3.5 and Section 3.7.4.2 of this document, and being based 664 on [SMTP-codes]. The registration data is as follows: 666 Code: 5.6.x 667 Sample Text: The ALT-ADDRESS is required but not specified 668 Associated basic status code: 553, 550 669 Description: This indicates the reception of a MAIL or RCPT 670 commands that required an ALT-ADDRESS parameter 671 but such parameter was not present. 672 Defined: RFC XXXX. (Experimental track) 673 Submitter: Jiankang YAO 674 Change controller: IESG. 676 Code: 5.6.y 677 Sample Text: UTF-8 string reply is required, 678 but not permitted by the client 679 Associated basic status code: 553, 550 680 Description: This indicates that a reply containing a UTF-8 681 string is required to show the mailbox name, 682 but that form of response is not 683 permitted by the client 684 Defined: RFC XXXX. (Experimental track) 685 Submitter: Jiankang YAO 686 Change controller: IESG. 688 Code: 5.6.z 689 Sample Text: UTF8SMTP downgrade failed 690 Associated basic status code: 550 691 Description: This indicates that transaction failed 692 after the final "." of the DATA command 693 Defined: RFC XXXX. (Experimental track) 694 Submitter: Jiankang YAO 695 Change controller: IESG. 697 Code: 2.6.y 698 Sample Text: UTF-8 string reply is required, 699 but not permitted by the client 700 Associated basic status code: 252 701 Description: This indicates that a reply containing a UTF-8 702 string is required to show the mailbox name, 703 but that form of response is not 704 permitted by the client 705 Defined: RFC XXXX. (Experimental track) 706 Submitter: Jiankang YAO 707 Change controller: IESG. 709 The "Mail Transmission Types" registry under Mail Parameters registry 710 is requested to be updated to include the following new entries: 712 +---------------+----------------------------+----------------------+ 713 | WITH protocol | Description | Reference | 714 | types | | | 715 +---------------+----------------------------+----------------------+ 716 | UTF8SMTP | UTF8SMTP with Service | [RFCXXXX] | 717 | | Extensions | | 718 | UTF8SMTPA | UTF8SMTP with SMTP AUTH | [RFC4954] [RFCXXXX] | 719 | UTF8SMTPS | UTF8SMTP with STARTTLS | [RFC3207] [RFCXXXX] | 720 | UTF8SMTPSA | UTF8SMTP with both | [RFC3207] [RFC4954] | 721 | | STARTTLS and SMTP AUTH | [RFCXXXX] | 722 +---------------+----------------------------+----------------------+ 724 5. Security Considerations 726 See the extended security considerations discussion in the framework 727 document [RFC4952]. 729 6. Acknowledgements 731 Much of the text in the initial version of this specification was 732 derived or copied from [Klensin-emailaddr] with the permission of the 733 author. Significant comments and suggestions were received from 734 Xiaodong LEE, Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other 735 members of the JET team and were incorporated into the specification. 736 Additional important comments and suggestions, and often specific 737 text, were contributed by many members of the WG and design team. 738 Those contributions include material from John C Klensin, Charles 739 Lindsey, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris 740 Newman, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall 741 Gellens, Frank Ellermann, Alexey Melnikov, Pete Resnick, S. 742 Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes Miguel Garcia, 743 Magnus Westerlund and Lars Eggert. Of course, none of the 744 individuals are necessarily responsible for the combination of ideas 745 represented here. 747 7. Change History 749 [[anchor15: RFC Editor: Please remove this section.]] 751 7.1. draft-ietf-eai-smtpext: Version 00 753 This version supercedes draft-yao-ima-smtpext-03.txt. It refines the 754 ABNF definition of the internationalized email address. It 755 represents as the EAI working group document. 757 7.2. draft-ietf-eai-smtpext: Version 01 759 o Upgraded to reflect discussions during IETF 66. 760 o Remove the atomic parameter. 761 o Add the new section of "the Suggestion of the value of the ALT- 762 ADDRESS parameter". 764 7.3. draft-ietf-eai-smtpext: Version 02 766 o Upgraded to reflect the recent discussion of the ima@ietf.org 767 mailing list. 768 o Add the section of "Body Parts and SMTP Extensions". 769 o Add the new section of "Change History". 770 o Add the subsection about SMTP extensions for DSN. 772 7.4. draft-ietf-eai-smtpext: Version 03 774 o Update the syntax related to mailbox. 775 o Update the trace field section. 776 o Add the new section about message retry. 777 o Update the subsection about SMTP extensions for DSN. 779 7.5. draft-ietf-eai-smtpext: Version 04 781 o Refine some syntax. 782 o Delete "Message Header Label" section. 783 o Change "bounce" to "reject". 785 7.6. draft-ietf-eai-smtpext: Version 05 787 o Refine the abstract. 788 o Delete "The Suggestion of the Value of the ALT-ADDRESS parameter" 789 section. 790 o Move original section 2.7.4 and 2.7.5 to section 3 with the name 791 "Issues with other parts of the email system". 792 o Add the new section "LMTP". 793 o Refine some text according to suggestions from the EAI mailing 794 list discussion 795 o Remove the section "Mailing List Question" 797 7.7. draft-ietf-eai-smtpext: Version 06 799 o Delete the section about message retry. 800 o Add the new subsection about Mail eXchangers 801 o Add the new section about "UTF-8 Reply" 802 o Refine some response code for the section "Using the ALT-ADDRESS 803 parameter" 805 7.8. draft-ietf-eai-smtpext: Version 07 807 o Rename the section 2.5 808 o Refine the section 2.7 810 7.9. draft-ietf-eai-smtpext: Version 08 812 o Refine some texts and update some references 814 7.10. draft-ietf-eai-smtpext: Version 09 816 o Add the appendix 817 o Move section 3.1, 3.2 and section 5 to Appendix 818 o Remove section 3.3 and section 4 819 o Add the new term definitions of conventional message and 820 international message in the appendix 821 o Refine some texts according to suggestions from the EAI mailing 822 list discussion during WG Last call 823 o Use the same reference for ASCII as RFC 2821. 824 o General editorial revision and cleanup, including extensive 825 modifications to the XML to produce a version that has better odds 826 of getting through the various checkers and validators. 828 7.11. draft-ietf-eai-smtpext: Version 10 830 o Refine the text 831 o Add some text about "ALT-ADDRESS" in the section 2.4 832 o Add the appendix A.5 834 7.12. draft-ietf-eai-smtpext: Version 11 836 o Refine the text 837 o Reference updating 839 7.13. draft-ietf-eai-smtpext: Version 12 841 o Remove the section 1.2 about Proposal Context and merge the text 842 into new section 2 843 o Add the new section 2 about overview of operation 844 o Update the IANA consideration 845 o Refine the text 847 7.14. draft-ietf-eai-smtpext: Version 13 849 o Update the Abstract 850 o Refine the syntax about the equivalent of import clause 852 8. References 853 8.1. Normative References 855 [ASCII] American National Standards Institute (formerly United 856 States of America Standards Institute), "USA Code for 857 Information Interchange", ANSI X3.4-1968, 1968. 859 [EAI-dsn] Newman, C. and A. Melnikov, "SMTP extensions for DSNs", 860 draft-ietf-eai-dsn-06.txt (work in progress), 861 January 2008. 863 [EAI-utf8header] 864 Abel, Y., "Transmission of Email Headers in UTF-8 865 Encoding", draft-ietf-eai-utf8headers-12.txt (work in 866 progress), July 2008. 868 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 869 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 870 RFC 1652, July 1994. 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, March 1997. 875 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 876 April 2001. 878 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 879 April 2001. 881 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 882 Extension for Delivery Status Notifications (DSNs)", 883 RFC 3461, January 2003. 885 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 886 RFC 3463, January 2003. 888 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 889 for Delivery Status Notifications", RFC 3464, 890 January 2003. 892 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 893 "Internationalizing Domain Names in Applications (IDNA)", 894 RFC 3490, March 2003. 896 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 897 10646", RFC 3629, November 2003. 899 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 900 RFC 4409, April 2006. 902 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 903 Internationalized Email", RFC 4952, July 2007. 905 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 906 Specifications: ABNF", STD 68, RFC 5234, January 2008. 908 [SMTP-codes] 909 Hansen , T. and J. Klensin, "A Registry for SMTP Enhanced 910 Mail System Status Codes", 911 draft-hansen-4468upd-mailesc-registry-03 (work in 912 progress), January 2008. 914 8.2. Informative References 916 [EAI-downgrading] 917 YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading 918 mechanism for Internationalized eMail Address", 919 draft-ietf-eai-downgrade-07 (work in progress), 3 2008. 921 [Klensin-emailaddr] 922 Klensin, J., "Internationalization of Email Addresses", 923 draft-klensin-emailaddr-i18n-03 (work in progress), 924 July 2005. 926 [RFC0974] Partridge, C., "Mail routing and the domain system", 927 RFC 974, January 1986. 929 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 930 October 1996. 932 [RFC2821bis] 933 Klensin, J., "Simple Mail Transfer Protocol", 934 draft-klensin-rfc2821bis-10 (work in progress), 4 2008. 936 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 937 of Large and Binary MIME Messages", RFC 3030, 938 December 2000. 940 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 941 Transport Layer Security", RFC 3207, February 2002. 943 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 944 for Authentication", RFC 4954, July 2007. 946 Appendix A. Material Updating RFC 4952 948 RFC 4952, the Overview and Framework document covering this set of 949 extensions for internationalized email [RFC4952], was completed 950 before this specification, which specifies a particular part of the 951 protocol set. This appendix, which is normative, contains material 952 that would have been incorporated into RFC 4952 had it been delayed 953 until the work described in the rest of this specification was 954 completed and that should be included in any update to RFC 4952. 956 A.1. Conventional Message and Internationalized Message 958 o A conventional message is one that does not use any extension 959 defined in this document or in the UTF8header specification 960 [EAI-utf8header], and which is strictly conformant to RFC 2822 961 [RFC2822]. 962 o An internationalized message is a message utilizing one or more of 963 the extensions defined in this specification or in the UTF8header 964 specification [EAI-utf8header], so that it is no longer conformant 965 to the RFC 2822 specification of a message. 967 A.2. LMTP 969 LMTP [RFC2033] may be used as the final delivery agent. In such 970 cases, LMTP may be arranged to deliver the mail to the mail store. 971 The mail store may not have UTF8SMTP capability. LMTP need to be 972 updated to deal with these situations. 974 A.3. SMTP Service Extension for DSNs 976 The existing draft standard Delivery status notifications (DSNs) 977 [RFC3461] is limited to ASCII text in the machine readable portions 978 of the protocol. "International Delivery and Disposition 979 Notifications" [EAI-dsn] adds a new address type for international 980 email addresses so an original recipient address with non-ASCII 981 characters can be correctly preserved even after downgrading. If an 982 SMTP server advertises both the UTF8SMTP and the DSN extension, that 983 server MUST implement EAI-dsn [EAI-dsn] including support for the 984 ORCPT parameter. 986 A.4. Implementation Advice 988 In the absence of this extension, SMTP clients and servers are 989 constrained to using only those addresses permitted by RFC 2821. The 990 local parts of those addresses MAY be made up of any ASCII 991 characters, although some of them MUST be quoted as specified there. 992 It is notable in an internationalization context that there is a long 993 history on some systems of using overstruck ASCII characters (a 994 character, a backspace, and another character) within a quoted string 995 to approximate non-ASCII characters. This form of 996 internationalization SHOULD be phased out as this extension becomes 997 widely deployed but backward-compatibility considerations require 998 that it continue to be supported. 1000 A.5. Applicability of SMTP Extension to Additional Uses 1002 Among other protocol changes, the SMTP extension allows an optional 1003 alternate address to be supplied with the MAIL and RCPT commands. 1004 For the purposes of this set of specifications, this alternate 1005 address only has meaning when the primary address contains UTF-8 1006 characters and the message is downgraded. While it may be tempting 1007 to consider the alternate address as a general-purpose second-chance 1008 address, to be used whenever the primary address is rejected, such 1009 behavior is not defined here. This restriction allows for future 1010 extensions to be developed which create such a general-purpose 1011 second-chance address, although no specific work on such an extension 1012 is currently anticipated. Note that any such extension needs to 1013 consider the question of what the [RFC0974] sequencing rules mean 1014 when different possible servers support different sets of ESMTP 1015 options (or, in this case, addresses). The answer to this question 1016 may also imply updates to [RFC2821]. 1018 Authors' Addresses 1020 Jiankang YAO (editor) 1021 CNNIC 1022 No.4 South 4th Street, Zhongguancun 1023 Beijing 1025 Phone: +86 10 58813007 1026 Email: yaojk@cnnic.cn 1028 Wei MAO (editor) 1029 CNNIC 1030 No.4 South 4th Street, Zhongguancun 1031 Beijing 1033 Phone: +86 10 58812230 1034 Email: maowei_ietf@cnnic.cn 1036 Full Copyright Statement 1038 Copyright (C) The IETF Trust (2008). 1040 This document is subject to the rights, licenses and restrictions 1041 contained in BCP 78, and except as set forth therein, the authors 1042 retain all their rights. 1044 This document and the information contained herein are provided on an 1045 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1046 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1047 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1048 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1049 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1050 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1052 Intellectual Property 1054 The IETF takes no position regarding the validity or scope of any 1055 Intellectual Property Rights or other rights that might be claimed to 1056 pertain to the implementation or use of the technology described in 1057 this document or the extent to which any license under such rights 1058 might or might not be available; nor does it represent that it has 1059 made any independent effort to identify any such rights. Information 1060 on the procedures with respect to rights in RFC documents can be 1061 found in BCP 78 and BCP 79. 1063 Copies of IPR disclosures made to the IETF Secretariat and any 1064 assurances of licenses to be made available, or the result of an 1065 attempt made to obtain a general license or permission for the use of 1066 such proprietary rights by implementers or users of this 1067 specification can be obtained from the IETF on-line IPR repository at 1068 http://www.ietf.org/ipr. 1070 The IETF invites any interested party to bring to its attention any 1071 copyrights, patents or patent applications, or other proprietary 1072 rights that may cover technology that may be required to implement 1073 this standard. Please address the information to the IETF at 1074 ietf-ipr@ietf.org.