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