idnits 2.17.1 draft-ietf-eai-downgrade-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 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 577. ** 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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 89: '...F-8 characters in mail headers MUST be...' RFC 2119 keyword, line 141: '... Downgrading MUST be performed in ea...' RFC 2119 keyword, line 155: '... ASCII, it MUST decide to bounce or ...' RFC 2119 keyword, line 165: '... MUA/MTA MUST downgrade mail headers...' RFC 2119 keyword, line 170: '... local-part: Punycode[RFC3492] without normalization. Prefix MUST be...' (15 more instances...) 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 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 (Jun 26, 2006) is 6513 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-ietf-eai-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-eai-framework (ref. 'EAI-Overview') == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-eai-smtpext (ref. 'EAI-SMTPext') == Outdated reference: A later version (-03) exists of draft-ietf-eai-scenarios-00 ** Downref: Normative reference to an Informational draft: draft-ietf-eai-scenarios (ref. 'EAI-Scenarios') -- Possible downref: Normative reference to a draft: ref. 'EAI-UTF8' ** 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) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Email Address Internationalization Y. YONEYA, Ed. 3 (EAI) K. Fujiwara, Ed. 4 Internet-Draft JPRS 5 Expires: December 28, 2006 Jun 26, 2006 7 Downgrading mechanism for Email Address Internationalization (EAI) 8 draft-ietf-eai-downgrade-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 December 28, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Traditional mail systems handle only US-ASCII characters in SMTP 42 envelope and mail headers. The Email Address Internationalization 43 (EAI) is implemented by allowing UTF-8 characters in SMTP envelope 44 and mail headers. To deliver Non-ASCII mail address through EAI 45 incompliant environment, some sort of converting mechanism (i.e. 46 downgrading) is required. This document describes requirements for 47 downgrading, SMTP session downgrading, header downgrading and 48 implementation consideration. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Downgrade Requirements . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Timing and conditions of downgrading . . . . . . . . . . . 3 56 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. SMTP DATA/Header downgrading . . . . . . . . . . . . . . . . . 5 59 5.1. No header downgrading . . . . . . . . . . . . . . . . . . 6 60 5.2. Downgrading with MIME encapsulation . . . . . . . . . . . 6 61 5.2.1. Downgrading with MIME encapsulation example . . . . . 7 62 5.3. Header conversion . . . . . . . . . . . . . . . . . . . . 8 63 5.3.1. Downgrading address headers . . . . . . . . . . . . . 9 64 5.3.2. Header conversion example . . . . . . . . . . . . . . 10 65 6. Implementation consideration . . . . . . . . . . . . . . . . . 12 66 6.1. MUA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 6.2. MDA Requirements . . . . . . . . . . . . . . . . . . . . . 12 68 7. Security considerations . . . . . . . . . . . . . . . . . . . 12 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 71 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . . . 15 75 1. Introduction 77 Traditional mail systems which are defined by [RFC2821] and [RFC2822] 78 allow US-ASCII characters in SMTP envelope and mail headers in body 79 part. The EAI proposal [EAI-Overview],[EAI-UTF8], [EAI-SMTPext] 80 allows UTF-8 characters in SMTP envelope and mail headers in body 81 part. 83 Carrying Non-ASCII mail address from sender to recipients requires 84 all components on the mail delivery route are EAI compliant. 85 Otherwise Non-ASCII mail address can't be delivered. To solve the 86 problem, this document describes downgrading mechanism that enables 87 delivering Non-ASCII mail address by converting it to corresponding 88 US-ASCII representation on current mail delivery system. Not only 89 SMTP envelope, but also UTF-8 characters in mail headers MUST be 90 converted to US-ASCII. 92 Downgrading in EAI consists from following two parts: 93 o SMTP session downgrading 94 o header downgrading 96 Decoding downgraded envelope/message is called 'Upgrading' in this 97 document. Each downgrading mechanism has corresponding upgrading 98 mechanism. 100 In this document, requirements for downgrading is described in 101 section Section 3, SMTP session downgrading is described in 102 Section 4, and mail header downgrading is described in Section 5. 104 2. Terminology 106 Terminology for this document is defined in [EAI-Overview]. 108 In this document, "algorithmic address" is an US-ASCII address which 109 is generated by algorithmic method. 111 3. Downgrade Requirements 113 3.1. Timing and conditions of downgrading 115 This section describes timing and conditions of downgrading. 116 o Timing: SMTP client detects that SMTP server doesn't support 117 "IEmail" option at EHLO. [EAI-SMTPext] 118 o Conditions: SMTP client detects that UTF-8 is included in the SMTP 119 envelope or mail headers in the SMTP DATA. 121 Note: If the i-Email header exists, downgrading will be performed. 122 If UTF-8 characters exist in mail headers without the i-Email header, 123 this is a protocol error, and handling of this situation is outside 124 the scope of this specification. 126 3.2. Requirements 128 1. Downgrading must be performed only once. 129 2. Upgrading must be performed at minimized place such as final 130 destination like recipient MUA. 131 3. Downgrading and upgrading must be automated. 132 4. Downgrading and upgrading should be easy and lightweight as it is 133 possible to do with MTA like 8BITMIME encapsulation. 134 5. Downgrade and upgrade method must be defined clearly. 135 6. Downgrading and upgrading should preserve all header information. 136 7. Downgrading must support SPF and DKIM. 137 8. Downgrading occurrence must be recorded. 139 4. SMTP Downgrading 141 Downgrading MUST be performed in each SMTP session. Target of 142 downgrading elements in SMTP envelope are below: 144 o MAIL FROM: 145 o RCPT TO: 147 Downgrading in SMTP envelope uses ALT-ADDR and ATOMIC option proposed 148 in [EAI-SMTPext]. 150 Downgrading is possible only when a mail sender's MUA appends ALT- 151 ADDR or ATOMIC option to all Non-ASCII envelope addresses to denote 152 their alternative US-ASCII address. 154 When MUA/MTA is transferring mail and finding its envelope is Non- 155 ASCII, it MUST decide to bounce or downgrade if receiving MTA is EAI 156 incompliant. 158 Both ALT-ADDR parameter and ATOMIC parameter is specified in one 159 envelope from/to, use ALT-ADDR parameter and ignore ATOMIC parameter. 161 MTA generates alternative US-ASCII address when ALT-ADDR option is 162 not specified and ATOMIC is "y". 164 Further, even if no downgrading is performed for envelope from/to, 165 MUA/MTA MUST downgrade mail headers including UTF-8 or bounce. This 166 is described in next section. 168 Algorithmic address generation method is below: 169 domain-part: Punycode/IDNA [RFC3490] 170 local-part: Punycode[RFC3492] without normalization. Prefix MUST be 171 assigned by IANA (which is not "xn--"). 173 MTA replaces Non-ASCII mail address with specified or generated 174 alternative US-ASCII address. Then appends replaced information with 175 EAI-Downgraded-From and EAI-Downgraded-To header in mail header 176 (outgoing SMTP DATA). 177 EAI-Downgraded-From: 178 EAI-Downgraded-From: 179 EAI-Downgraded-To: 180 EAI-Downgraded-To: 182 Note that when downgrading, not to disclose whole recipient address, 183 MUA/MTA SHOULD make SMTP connection per each recipient address. 185 Also note that by appending EAI-Downgraded-From/To headers, MUA/MTA 186 MUST perform SMTP DATA/Header downgrading. This is described in next 187 section. 189 Downgraded local-part is parsed only in MDA. MDA delivers the mail 190 to final mailbox. 192 Case study: SPF check 194 SPF checks domainname of the envelope from and smtp connection IP 195 address. If ALT-ADDR domainname is Punycode/IDNA form of Non-ASCII 196 domainname, it will be compatible with current SPF. In this case, 197 SPF check will be performed correctly. Otherwise, more detailed 198 consideration is required. 200 5. SMTP DATA/Header downgrading 202 In this section, three methods for SMTP DATA/Header downgrading is 203 proposed. Working group should select one. 205 o No header downgrading 206 o Encapsulating whole SMTP DATA 207 o Translating each header 209 Target and non-target of downgrading elements in mail headers (SMTP 210 data) are below: 212 Originator address(es): Non-ASCII mail addresses in From, Reply-To, 213 Sender and their Resent- headers MUST be target of downgrading. 214 Destination address(es): Non-ASCII mail addresses in To, CC, Bcc and 215 their Resent- headers MUST be target of downgrading. 216 IDs: IDs such as Message-ID, Date, In-Reply-To and References MUST 217 NOT be target of downgrading. 218 Trace headers: Received headers which contains Non-ASCII mail 219 addresses MUST be target of downgrading. 220 other headers: UTF-8 in other headers MUST be target of downgrading. 222 Rewriting Received header is prohibited in [RFC2821] Section 4.4 223 Trace field. But downgrading may be considered as the 'Mail 224 Gatewaying' which is described in [RFC2821] Section 3.8. If it is 225 true, these downgrading methods are acceptable. 227 5.1. No header downgrading 229 Most MTAs support 8bit characters in mail headers. Currently, mail 230 systems in some countries or languages use raw 8bit header value in 231 their local encoding. This method does not care about using UTF-8 232 headers in existing mail systems. 234 Pros: 235 * Easy to implement. 236 Cons: 237 * This method may break existing mail infrastructure. 239 5.2. Downgrading with MIME encapsulation 241 This downgrading method requires new MIME 'Content-Type:' which 242 express EAI. This document assumes 'Content-Type: Message/EAI' 243 existence. 245 Downgrading: 246 * If mail header contains UTF-8 data, downgrade whole message to 247 be MIME encoded. Whole message becomes new MIME part (Message/ 248 EAI). 249 * Message-ID, Subject, Date headers are copied from original 250 header. 251 * From header is generated with downgraded Envelope-from. 252 * To header is generated with single downgraded Envelope-to. 253 * If Subject header contains UTF-8, it is replaced to a certain 254 message or encoded by MIME [RFC2047]. 255 * Message-ID, Date headers are preserved. 256 As a result, new body contains one new MIME part (Message/EAI). 258 Upgrading: 259 * If mail message contains only one MIME part and its Content- 260 Type is 'Message/EAI', it may be a downgraded message. To 261 check if it is a downgraded message, compare mail body's 262 message-id and MIME part's message-id. If message-ids are the 263 same, it is a downgraded message. Then, treat MIME part as 264 entire mail message. 265 * When checking trace field, checker SHOULD check Received header 266 both in wrapping headers and headers in encapsulated part. 268 Case study: DKIM 270 DKIM checker performs upgrading the downgraded message first. 272 Pros: 273 * MTA does not need to decode each header carefully. 274 * Whole headers can be submitted AS IS. 275 Cons: 276 * Non-ASCII from/to can not distinguish from downgraded mail 277 headers. 278 * EAI incompliant MUA can not treat any downgraded mail. 280 [[Reference to [EAI-Scenarios] and evaluation of each case should be 281 described here.]] 283 5.2.1. Downgrading with MIME encapsulation example 284 Downgrading example 286 Message-Id: MESSAGE_ID 287 Mime-Version: 1.0 288 Content-Type: Multipart/Mixed; 289 boundary="--Next_Part(unique_string)--" 290 Content-Transfer-Encoding: 8bit 291 Subject: DOWNGRADED_SUBJECT 292 From: 293 To: 294 Date: DATE 296 ----Next_Part(unique_string)-- 297 Content-Type: Message/EAI 298 Content-Transfer-Encoding: 8bit 299 Content-Disposition: inline 301 EAI-Downgraded-From: 302 EAI-Downgraded-To: 303 Received: ... 304 Received: ... 305 Message-Id: MESSAGE_ID 306 Mime-Version: 1.0 307 Subject: UTF-8_SUBJECT 308 From: 309 To: 310 Date: DATE 312 MAIL_BODY 314 ----Next_Part(unique_string)---- 316 5.3. Header conversion 318 Define conversion method to US-ASCII for each header which may 319 contain Non-ASCII characters. Each header has its own downgrading 320 method. 322 To preserve all header information, define generic encapsulation 323 header: "Downgraded: HeaderName: HeaderValue". The header value is 324 encoded by [RFC2047] with UTF-8 tag. 326 Downgrading: 327 * For all headers, check if the header contains UTF-8 characters. 328 * Encapsulate 'i-Email' header in Downgraded header. 330 * If the header contains UTF-8 characters, 331 + If the header is an address header which is described in 332 Section 5.3.1, 333 - Preserve the header in 'Downgraded' header. 334 - Downgrade the header defined in Section 5.3.1. 335 + The other header case, encode the header by [RFC2047] with 336 UTF-8 tag. 337 Upgrading: 338 * If the mail has 'Downgraded' headers, the mail is a downgraded 339 EAI mail message. 340 * Decode all 'Downgraded' header. 341 + Decode header value field string which is [RFC2047] encoded. 342 + If the header is address headers described in Section 5.3.1, 343 - Apply address header downgrading to the decoded header. 344 - Remove the header line which is same to the downgraded 345 line. 346 + Remove the 'Downgraded' header. 347 + Add decoded header to mail header. "HeaderName: 348 HeaderValue". 349 * If each mail header has [RFC2047] encoded part and which 350 encoding is "UTF-8", it is a downgraded header, so decode it. 352 Pros: 353 * EAI incompliant MUA displays the downgraded mail body except 354 original Non-ASCII mail addresses. 355 * EAI incompliant MUA displays and handles the sender specified 356 or algorithmic address. 357 * EAI compliant MUA displays and handles original headers. 358 Cons: 359 * Implementation and processing cost is higher than 'Header 360 Encapsulation' defined in Section 5.2 because MUA/MTA must 361 parse each header and encode it by defined method. 362 * Hard to preserve whole information AS IS. The address headers 363 are preserved but the other headers which is [RFC2047] encoded 364 with UTF-8 tag are not distinguished that it is downgraded or 365 it is encoded by sender's MUA. Therefore, to check DKIM 366 requires special consideration. 368 [[Reference to [EAI-Scenarios] and evaluation of each case should be 369 described here.]] 371 5.3.1. Downgrading address headers 373 This section targets From, Sender, Reply-To, To, CC, BCC, Resent- 374 From, Resent-To, Resent-CC, Resent-Bcc, Resent-sender headers which 375 contains Originator/Destination address(es). 377 The header value is composed of single or multiple mailbox/angle-addr 378 fields defined in [EAI-UTF8]. 380 If the header contains UTF-8 characters, downgrading method is 381 follows. 382 1. Extract every field and downgrade mailbox/angle-addr described 383 below. 384 2. By mailbox/angle-addr downgrading, if the field became empty, the 385 field should be removed. 386 3. If all header field is removed, remove the header. 387 4. If From header is removed, generate new From header from 388 envelope-from address. 390 EAI angle-addr defined in [EAI-UTF8] consists of 4 forms. 391 Downgrading method is defined for each form. 392 1. 393 Non-ASCII mail address without ALT-ADDR and ATOMIC parameter 394 case, remove this angle-addr. 395 2. 396 Non-ASCII mail address with sender-specified US-ASCII address 397 case, replace it as . 398 3. 399 Non-ASCII mail address with ATOMIC parameter case, generate 400 the algorithmic address from Non-ASCII mail address and 401 replace it as . 402 4. 403 US-ASCII mail address case, preserve it. 405 "mailbox" is defined as "DISPLAY NAME angle-addr" in [EAI-UTF8]. The 406 "DISPLAY NAME" field should be encoded by [RFC2047] with UTF-8 tag, 407 if necessary. If the angle-addr is removed, remove the field 408 including "DISPLAY NAME". 410 5.3.2. Header conversion example 411 Original EAI message 413 i-Email: 1.0 414 Message-Id: MESSAGE_ID 415 Mime-Version: 1.0 416 Content-Type: text/plain; charset="UTF-8" 417 Content-Transfer-Encoding: 8bit 418 Subject: UTF-8_SUBJECT 419 From: 420 To: 421 CC: 422 Date: DATE 424 MAIL_BODY 426 SMTP downgrading adds EAI-Downgraded-From, EAI-Downgraded-To headers. 428 EAI-Downgraded-From: 429 EAI-Downgraded-To: 431 Result of the header conversion downgrading. 433 EAI-Downgraded-From: 434 MIME() 435 EAI-Downgraded-To: 436 MIME() 437 Downgraded: i-Email: 1.0 438 Message-Id: MESSAGE_ID 439 Mime-Version: 1.0 440 Content-Type: text/plain; charset="UTF-8" 441 Content-Transfer-Encoding: 8bit 442 Subject: MIME(UTF-8_SUBJECT) 443 Downgraded: From: MIME() 444 From: 445 Downgraded: To: MIME() 446 To: 447 Downgraded: CC: MIME() 448 CC: 449 Date: DATE 451 MAIL_BODY 453 MIME() stands for [RFC2047] encoding. 455 6. Implementation consideration 457 6.1. MUA 459 EAI compliant MUA MUST implement downgrading mechanism for sending. 461 MUA MAY encode UTF-8 in Subject header with the same encoding of body 462 part while downgrading. 464 EAI compliant MUA MUST upgrade downgraded mail and MUST show Non- 465 ASCII mail addresses on display. 467 6.2. MDA Requirements 469 This section describes downgrading in MDA. 470 1. MDA MUST NOT upgrade. 471 2. Perform downgrading for each Storage/Back-end-Process. If and 472 only if MDA knows recipient's MUA is EAI compliant, then no 473 downgrading is performed. 474 3. If MDA detects that SMTP recipient address is an algorithmic 475 address, then MDA MUST decode it and perform the same processing 476 as if it were Non-ASCII mail address. MDA MAY normalize or 477 canonicalize local-part before processing it. 479 7. Security considerations 481 See the extended security considerations discussion in [EAI-Overview] 483 8. IANA Considerations 485 To distinguish downgraded Non-ASCII mail addresses in ACE form, it 486 MUST have ACE-Prefix. The ACE-Prefix MUST differ from IDNA ACE- 487 Prefix to avoid possible confusion. IANA will assign Non-ASCII mail 488 address ACE-Prefix when RFC is published. 490 9. Acknowledgements 492 John Klensin, Harald Alvestrand, Chris Newman, Charles Lindsey, 493 Marcos Sanz, Alexey Melnikov, and JET members. 495 10. Normative References 497 [EAI-Overview] 498 Klensin, J. and Y. Ko, "Overview and Framework for 499 Internationalized Email", draft-ietf-eai-framework-01 500 (work in progress). 502 [EAI-SMTPext] 503 Yao, J., Ed., "SMTP extension for internationalized email 504 address", draft-ietf-eai-smtpext-00 (work in progress), 505 Febrary 2006. 507 [EAI-Scenarios] 508 Alvestrand, H., "Internationalized Email Addresses: 509 Scenarios", draft-ietf-eai-scenarios-00 (work in 510 progress), May 2006. 512 [EAI-UTF8] 513 Yeh, J., "Internationalized Email Headers", 514 draft-yeh-ima-utf8headers-01 (work in progress), 515 February 2006. 517 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 518 Part Three: Message Header Extensions for Non-ASCII Text", 519 RFC 2047, November 1996. 521 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 522 April 2001. 524 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 525 April 2001. 527 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 528 "Internationalizing Domain Names in Applications (IDNA)", 529 RFC 3490, March 2003. 531 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 532 for Internationalized Domain Names in Applications 533 (IDNA)", RFC 3492, March 2003. 535 Authors' Addresses 537 Yoshiro YONEYA (editor) 538 JPRS 539 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 540 Chiyoda-ku, Tokyo 101-0065 541 Japan 543 Phone: +81 3 5215 8451 544 Email: yone@jprs.co.jp 546 Kazunori Fujiwara (editor) 547 JPRS 548 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 549 Chiyoda-ku, Tokyo 101-0065 550 Japan 552 Phone: +81 3 5215 8451 553 Email: fujiwara@jprs.co.jp 555 Intellectual Property Statement 557 The IETF takes no position regarding the validity or scope of any 558 Intellectual Property Rights or other rights that might be claimed to 559 pertain to the implementation or use of the technology described in 560 this document or the extent to which any license under such rights 561 might or might not be available; nor does it represent that it has 562 made any independent effort to identify any such rights. Information 563 on the procedures with respect to rights in RFC documents can be 564 found in BCP 78 and BCP 79. 566 Copies of IPR disclosures made to the IETF Secretariat and any 567 assurances of licenses to be made available, or the result of an 568 attempt made to obtain a general license or permission for the use of 569 such proprietary rights by implementers or users of this 570 specification can be obtained from the IETF on-line IPR repository at 571 http://www.ietf.org/ipr. 573 The IETF invites any interested party to bring to its attention any 574 copyrights, patents or patent applications, or other proprietary 575 rights that may cover technology that may be required to implement 576 this standard. Please address the information to the IETF at 577 ietf-ipr@ietf.org. 579 Disclaimer of Validity 581 This document and the information contained herein are provided on an 582 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 583 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 584 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 585 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 586 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 587 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 589 Copyright Statement 591 Copyright (C) The Internet Society (2006). This document is subject 592 to the rights, licenses and restrictions contained in BCP 78, and 593 except as set forth therein, the authors retain all their rights. 595 Acknowledgment 597 Funding for the RFC Editor function is currently provided by the 598 Internet Society.