idnits 2.17.1 draft-ietf-eai-utf8headers-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 575. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (August 7, 2006) is 6465 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 203, but not defined == Unused Reference: 'ASCII' is defined on line 461, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-02 == Outdated reference: A later version (-05) exists of draft-ietf-eai-framework-01 ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-01 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yeh, Ed. 3 Internet-Draft TWNIC 4 Intended status: Informational August 7, 2006 5 Expires: February 8, 2007 7 Internationalized Email Headers 8 draft-ietf-eai-utf8headers-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 8, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Full internationalization of electronic mail requires not only the 42 capability to transmit non-ASCII content, to encode selected 43 information in specific header fields, and to use non-ASCII 44 characters in envelope addresses. It also requires being able to 45 express those addresses and information based on them in mail header 46 fields. This document specifies the use of Unicode encoded in UTF-8, 47 rather than ASCII, as the base form for Internet email header field 48 bodies. This form is permitted in transmission only if authorized by 49 an SMTP extension, as specified in an associated specification. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 55 2. Background and History . . . . . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Pre-requirement . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Identification of internationalized email . . . . . . . . . . 5 59 6. Changes on Message Header Fields . . . . . . . . . . . . . . . 6 60 6.1. UTF8 Syntax . . . . . . . . . . . . . . . . . . . . . . . 6 61 6.2. Syntax extend from RFC 2822 . . . . . . . . . . . . . . . 7 62 6.3. Change on addr-spec syntax . . . . . . . . . . . . . . . . 8 63 6.4. Trace field syntax . . . . . . . . . . . . . . . . . . . . 9 64 7. Additional issue . . . . . . . . . . . . . . . . . . . . . . . 9 65 7.1. Mailing list header fields . . . . . . . . . . . . . . . . 9 66 7.2. MIME headers . . . . . . . . . . . . . . . . . . . . . . . 9 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 70 11. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 11.1. draft-ietf-eai-utf8header-00 . . . . . . . . . . . . . . . 11 72 11.2. draft-yeh-ima-utf8header-01 . . . . . . . . . . . . . . . 11 73 11.3. draft-yeh-ima-utf8header-00 . . . . . . . . . . . . . . . 11 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 12.2. Informative References . . . . . . . . . . . . . . . . . . 12 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 Intellectual Property and Copyright Statements . . . . . . . . . . 14 80 1. Introduction 82 1.1. Role of this specification 84 Full internationalization of electronic mail requires several 85 capabilities: 87 o The capability to transmit non-ASCII content, provided for as part 88 of the basic MIME specification [RFC2045], [RFC2046]. 89 o The capability to encode selected information in specific header 90 fields, provided for as another part of the MIME specification 91 [RFC2047]. 92 o The capability to use international characters in envelope 93 addresses, discussed in [EAI-overview] and specified in 94 [EAI-SMTP-extension]. And, finally, 95 o The capability to express those addresses, and information related 96 to and based on them, in mail header fields, defined in this 97 document. 99 This document specifies the use of Unicode encoded in UTF-8 100 [RFC3629], rather than ASCII, as the base form for Internet email 101 header fields. This form is permitted in transmission, if authorized 102 by the SMTP extension specified in [EAI-SMTP-extension]. 104 2. Background and History 106 Mailbox names often represent the names of human users. Many of 107 these users throughout the world have names that are not normally 108 represented with just the ASCII repertoire of characters, and would 109 more or less like to use their real names in their mailbox names. 110 These users are also likely to use non-ASCII text in their common 111 names and subjects of email messages, both in what they send and what 112 they receive. This protocol specifies UTF-8 as the encoding to 113 represent email header field bodies. 115 The traditional format of email messages [RFC2822] only allows ASCII 116 characters in the header fields of messages. This prevents users 117 from having email addresses that contain non-ASCII characters. It 118 further forces non-ASCII text in common names, comments, and in free 119 text (such as in the Subject: field) to be in MIME format [RFC2047]. 120 This specification describes a change to the email message format 121 that is connected to the SMTP message transport change described in 122 the associated specifications [EAI-overview] and 123 [EAI-SMTP-extension], and that allows non-ASCII characters throughout 124 email header fields. These changes affect SMTP clients, SMTP 125 servers, mail user agents (MUAs), list expanders and and gateways to 126 other media. 128 As specified in [EAI-SMTP-extension], an SMTP protocol extension 129 "UTF8SMTP" is used to prevent the transmission of messages with UTF-8 130 header fields to systems that cannot handle such messages. 132 Use of this SMTP extension helps prevent against the introduction of 133 such messages into message stores that might misrepresent or mangle 134 such messages. It should be noted that using an ESMTP extension does 135 not prevent against transferring email messages with UTF-8 header 136 fields to other systems that use the email format for messages and 137 that may not be upgraded, such as the POP and IMAP protocols. Those 138 protocols also need to be changed in order to handle stored messages 139 that have UTF-8 header fields. 141 The objective for this protocol is to allow UTF-8 in email header 142 fields. Issues about how to handle messages that contain UTF-8 143 header fields but are proposed to be delivered to systems that have 144 not been upgraded to support this capability are discussed elsewhere, 145 particularly in [EAI-downgrading]. 147 3. Terminology 149 In this document, header fields are "UTF-8 header" if the bodies of 150 those headers contain UTF-8 characters. 152 Unless otherwise noted, all terms used here are defined in [RFC2821] 153 or [RFC2822] or in [EAI-overview]. 155 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 156 and "MAY" in this document are to be interpreted as described in RFC 157 2119 [RFC2119]. 159 This document is being discussed on the ima mailing list. See 160 https://www1.ietf.org/mailman/listinfo/ima for information about 161 subscribing. The list's archive is at 162 http://www1.ietf.org/mail-archive/web/ima/index.html. 164 4. Pre-requirement 166 The use of UTF-8 header fields is dependent on the use of an SMTP 167 extension named "UTF8SMTP". 169 That protocol is defined in [EAI-SMTP-extension]. If that extension 170 is not supported, UTF-8 header fields MUST NOT be transmitted by 171 SMTP. 173 Sending MUAs that follow this protocol MUST create all header fields 174 encoded in UTF-8. No other direct encodings (like Big-5) are 175 allowed. Though there's nothing bad to use [RFC2047], but it is not 176 recommended in this document. 178 5. Identification of internationalized email 180 When a SMTP client tries to send a mail to a SMTP server that does 181 not support EAI, the client should know whether the message requires 182 the support for EAI or not. In addition to this, identification of 183 internationalized email is also required when a message is stored and 184 resent. Checking the presence of UTF-8 characters in the header 185 whenever such an identification is required may also achieve the 186 goal. However, this type of repeated processing wastes time and 187 processing power of involved systems. It is nice to have a mechanism 188 (such as self-label) or some indicator to identify whether the 189 message is new format(i.e. EAI compliant) or old one (i.e. RFC 2822 190 compliant). 192 To be able to do so, sending MUA MUST insert a new header field to 193 identify the presence of i18n information (particularly UTF-8 194 headers) in the message. The new header specified as "UTF8SMTP", and 195 elements of the header is the version number of i18n email. The i18n 196 header field syntax specified as below: 198 header-content = "UTF8SMTP:" [FWS] content-code [FWS] 199 *( ";" parameter ) CRLF 200 content-code = "UTF8" / "ASCII" / "Downgraded" 201 parameter = "Header-Language:" [FWS] Language-List 202 Language-List = Language-Tag [FWS] 203 *("," [FWS] Language-Tag [FWS]) 205 The Language-Tag token is the language identifier described in 206 [RFC3066] (ex: zh-TW). 208 [note: Thought the "parameter" token is currently used only for the 209 header-language, but can be extended in future use.] 211 While we can't require ordering of headers, it would be good to have 212 it appear as near the top of the headers as possible. It would also 213 be good to be able to guarantee that it will be there when the 214 message is dropped into a mail store. Thus, when a i18n email is 215 delivered. 217 o The "UTF8SMTP" header field MUST be inserted by the originating 218 MUA. 220 o The "UTF8SMTP" header field MUST be inserted, along with Return- 221 path, by the final delivery MTA if not presented. 222 o Whenever the email need to downgrade, the content-code of the 223 "UTF8SMTP" MUST change to "Downgraded", the detail of downgrade 224 process will describe in [EAI-downgrading]. 225 o If more than one "UTF8SMTP" header is presented, MTA SHOULD simply 226 ignore any excess ones. 228 6. Changes on Message Header Fields 230 SMTP client can send header fields in UTF-8 format, if the UTF8SMTP 231 extension advertised by SMTP server. 233 This protocol does NOT change the definition of header field names. 234 That is, only the bodies of header fields are allowed to have UTF-8 235 characters; the rules in RFC 2822 for header names are not changed. 236 To be able to do so, the header definition in RFC 2822 must extended 237 to support new format. That following ABNF is defined to substitute 238 those definition in RFC 2822. 240 For those tokens not referred in this section remains as the original 241 definition in RFC 2822. 243 6.1. UTF8 Syntax 245 The use of UTF8 characters are defined as following. 247 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 249 UTF8-2 = %xC2-DF UTF8-tail 251 UTF8-3 = %xE0 %xA0-BF UTF8-tail / 252 %xE1-EC 2(UTF8-tail) / 253 %xED %x80-9F UTF8-tail / 254 %xEE-EF 2(UTF8-tail) 256 UTF8-4 = %xF0 %x90-BF 2(UTF8-tail) / 257 %xF1-F7 3(UTF8-tail) 259 UTF8-tail = %x80-BF 261 These are taken from FRC 3629, but keep in this document for 262 convenient reason. 263 [Note in draft: Weather normalizing is needed or not will be place in 264 here.] 266 6.2. Syntax extend from RFC 2822 268 The following rules are intended to extend the corresponding rules in 269 RFC 2822 to allow UTF8 characters. 271 ctext = NO-WS-CTL / ; all of except 272 %d33-39 / ; SP, HTAB, "(", ")" 273 %d42-91 / ; and "\" 274 %d93-126 / 275 UTF8-xtra-char 277 qtext = NO-WS-CTL / ; all of except 278 %d33 / ; The rest of the US-ASCII 279 %d35-91 / ; characters not including "\" 280 %d93-126 / ; or the quote character 281 UTF8-xtra-char 283 text = %d1-9 / ; all UTF-8 characters except 284 %d11-12 / ; US-ASCII NUL, CR and LF 285 %d14-127 / 286 UTF8-xtra-char 288 utext = NO-WS-CTL / ; Non white space controls 289 %d33-126 / ; The rest of US-ASCII 290 UTF8-xtra-char 292 This means that all the RFC 2822 constructs that build upon these 293 will permit UTF-8 characters, including comments and quoted strings. 294 Besides, in order to allow UTF8 characters in we have to 295 change the syntax of . However, it will also lead 296 to allow UTF8 characters, which is not allowed due to the limitation 297 describe in Section 6.4. So is added to meet this 298 requirement. 300 utf8-atext = ALPHA / DIGIT / 301 "!" / "#" / ; Any character except 302 "$" / "%" / ; controls, SP, and specials. 303 "&" / "'" / ; Used for atoms 304 "*" / "+" / 305 "-" / "/" / 306 "=" / "?" / 307 "^" / "_" / 308 "`" / "{" / 309 "|" / "}" / 310 "~" / 311 UTF8-xtra-char 313 utf8-atom = [CFWS] 1*utf8-atext [CFWS] 315 utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS] 317 utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext) 319 [NOTE IN DRAFT: If any header needs to be restricted to disallow 320 this, please raise the issue on the mailing list.] 321 Note, however, that this does not remove any constraint on the 322 character set of protocol elements; for instance, all the allowed 323 values for timezone in the Date: headers are still expressed in 324 ASCII. 326 6.3. Change on addr-spec syntax 328 In this specification, internationalized email address will be 329 presented in UTF-8. Thus, all header fields involving es 330 may be different from traditional ones. There might be EAI unaware 331 MTAs in the mail routing path. In that case, MTA may bounce the 332 message with reply code 550, or downgrade the non-ASCII contents of 333 all header bodies before continuing to send the message. The 334 downgrade process involve with a new ALT-ADDRESS parameter. When 335 downgrade occurs, the ALT-ADDRESS will be used for mail delivery 336 instead of the internationalized email address, the detail is 337 described in [EAI-downgrading]. 339 angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] 341 utf8-addr-spec = utf8-local-part "@" utf8-domain 343 utf8-local-part= utf8-dot-atom / quoted-string / obs-local-part 345 utf8-domain = utf8-dot-atom / domain-literal / obs-domain 347 alt-address = "{" [CFWS] addr-spec [CFWS] "}" 348 Below list a few possible representation as example. 350 "DISPLAY_NAME" 351 ; tradition mailbox format 353 "DISPLAY_NAME" 354 ; EAI but no ALT-ADDRESS parameter provided, 355 ; message will bounce if UTF8SMTP extension is not supported 357 "DISPLAY_NAME" 358 ; UTF8SMTP with ALT-ADDRESS parameter provided, 359 ; ALT-ADDRESS can be used if downgrade is necessary 361 6.4. Trace field syntax 363 Internationalized domain names in Received fields must be transmitted 364 in punycode form. "For" fields containing internationalized 365 addresses are prohibited, since subsequent downgrading would force 366 violating rules in RFC 2821 prohibiting altering existing Received 367 fields. With these two restrictions, there should be no need for 368 UTF-8 information in Received fields and such information is 369 prohibited to preserve the integrity of those fields. More 370 generally, UTF-8 information of any sort MUST NOT appear in Received 371 fields, even in comments within those fields. 373 7. Additional issue 375 This section identifies issues that are not covered as part of this 376 set of specifications, but that will need to be considered as part of 377 EAI deployment. 379 7.1. Mailing list header fields 381 All mailing list and mail redistribution related header fields may 382 need further discuss. 384 7.2. MIME headers 386 MIME header bodies (parameter in [RFC2231]) need to allow 387 UTF8 characters in conformance with this specification. 389 8. Security Considerations 391 If a user has a non-ASCII mailbox address and an ASCII mailbox 392 address, a digital certificate that identifies that user may have 393 both addresses in the identity. Having multiple email addresses as 394 identities in a single certificate is already supported in PKIX and 395 OpenPGP. 397 Because UTF-8 often requires several octets to encode a single 398 character, internationalized local parts may cause mail addresses to 399 become longer. As specified in RFC 2822, each line of characters 400 MUST be no more 998 octets, excluding the CRLF. 402 In this specification, a user could provide a ASCII alternative 403 address for a non-ASCII address. However, it is possible these two 404 address going to different mailbox, or even different person. This 405 might not be the protocol problem, but user's personal choice (or 406 administration policy). 408 9. IANA considerations 410 IANA is requested to add the "UTF8SMTP" new header to the registry 411 with the entry pointing to this specification for its definition. 412 For those headers that modified in this document need to have their 413 registrations modified, so as to refer to the specification in 414 addition to their current definitions. 416 10. Acknowledgements 418 This document was created by incorporating a good deal of material 419 from an old Internet Draft by Paul Hoffman [Hoffman-utf8-headers]. 420 While many of the concepts and details have changed, the 421 contributions from that draft are greatly appreciated. 423 Most of the content of this document is provided by John C Klensin. 424 Also some significant comments and suggestions were received from 425 Charles H. Lindsey, Chris Newman, Yangwoo KO, Yoshiro YONEYA, and 426 other members of the JET team and were incorporated into the 427 document. The editor is much great thanks to their contribution 428 sincerely. 430 11. Edit history 432 This section is used for tracking the update of this document. Will 433 be removed after finalize. 435 11.1. draft-ietf-eai-utf8header-00 437 1. ABNF revise. 438 2. Terminology sync with overview document. 439 3. addr-spec change, put ALT-ADDRESS inside "<" and ">" quote with 440 "{" and "}". 441 4. add IANA considerations to register the new 2822 header 442 "UTF8SMTP". 443 5. add Security considerations about relation of EAI address to ALT- 444 ADDRESS. 446 11.2. draft-yeh-ima-utf8header-01 448 1. ABNF added. 449 2. Editrial changes. 450 3. Sent it as WG document. 452 11.3. draft-yeh-ima-utf8header-00 454 1. Section re-arranged. 455 2. Remove contains are not below to this document to. 457 12. References 459 12.1. Normative References 461 [ASCII] American National Standards Institute (formerly United 462 States of America Standards Institute), "USA Code for 463 Information Interchange", ANSI X3.4-1968, 1968. 465 ANSI X3.4-1968 has been replaced by newer versions with 466 slight modifications, but the 1968 version remains 467 definitive for the Internet. 469 [EAI-SMTP-extension] 470 Yao, J., Ed. and Wei. Mao, "SMTP extension for 471 internationalized email address", 472 draft-ietf-eai-smtpext-02.txt (work in progress), 473 July 2006. 475 [EAI-overview] 476 Klensin, J. and Y. Ko, "Overview and Framework of 477 Internationalized Email Address Delivery", 478 draft-ietf-eai-framework-01.txt (work in progress), 479 June 2006. 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 485 Word Extensions: Character Sets, Languages, and 486 Continuations", RFC 2231, November 1997. 488 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 489 April 2001. 491 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 492 April 2001. 494 [RFC3066] Alvestrand, H., "Tags for the Identification of 495 Languages", BCP 47, RFC 3066, January 2001. 497 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 498 10646", STD 63, RFC 3629, November 2003. 500 12.2. Informative References 502 [EAI-downgrading] 503 YONEYA, Yoshiro., Ed. and Kazunori. Fujiwara, Ed., 504 "Downgrading mechanism for Internationalized eMail Address 505 (IMA)", draft-ietf-eai-downgrade-01.txt (work in 506 progress), June 2006. 508 [Hoffman-utf8-headers] 509 Hoffman, P., "SMTP Service Extensions or Transmission of 510 Headers in UTF-8 Encoding", 511 draft-hoffman-utf8headers-00.txt (work in progress), 512 December 2003. 514 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 515 Extensions (MIME) Part One: Format of Internet Message 516 Bodies", RFC 2045, November 1996. 518 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 519 Extensions (MIME) Part Two: Media Types", RFC 2046, 520 November 1996. 522 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 523 Part Three: Message Header Extensions for Non-ASCII Text", 524 RFC 2047, November 1996. 526 Author's Address 528 Jeff Yeh (editor) 529 TWNIC 530 4F-2, No. 9, Sec 2, Roosvelt Rd. 531 Taipei, 100 532 Taiwan 534 Phone: +886 2 23411313 ext 506 535 Email: jeff@twnic.net.tw 537 Full Copyright Statement 539 Copyright (C) The Internet Society (2006). 541 This document is subject to the rights, licenses and restrictions 542 contained in BCP 78, and except as set forth therein, the authors 543 retain all their rights. 545 This document and the information contained herein are provided on an 546 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 547 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 548 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 549 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 550 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 551 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 553 Intellectual Property 555 The IETF takes no position regarding the validity or scope of any 556 Intellectual Property Rights or other rights that might be claimed to 557 pertain to the implementation or use of the technology described in 558 this document or the extent to which any license under such rights 559 might or might not be available; nor does it represent that it has 560 made any independent effort to identify any such rights. Information 561 on the procedures with respect to rights in RFC documents can be 562 found in BCP 78 and BCP 79. 564 Copies of IPR disclosures made to the IETF Secretariat and any 565 assurances of licenses to be made available, or the result of an 566 attempt made to obtain a general license or permission for the use of 567 such proprietary rights by implementers or users of this 568 specification can be obtained from the IETF on-line IPR repository at 569 http://www.ietf.org/ipr. 571 The IETF invites any interested party to bring to its attention any 572 copyrights, patents or patent applications, or other proprietary 573 rights that may cover technology that may be required to implement 574 this standard. Please address the information to the IETF at 575 ietf-ipr@ietf.org. 577 Acknowledgment 579 Funding for the RFC Editor function is provided by the IETF 580 Administrative Support Activity (IASA).