idnits 2.17.1 draft-ietf-eai-downgrade-05.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1211. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1218. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1224. 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 IETF Trust 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 (November 18, 2007) is 6004 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 220, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-eai-dsn-05 == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-09 == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-07 ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 7 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 Intended status: Experimental November 18, 2007 6 Expires: May 21, 2008 8 Downgrading mechanism for Email Address Internationalization 9 draft-ietf-eai-downgrade-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Traditional mail systems handle only ASCII characters in SMTP 43 envelope and mail header fields. The Email Address 44 Internationalization (UTF8SMTP) extension allows UTF-8 characters in 45 SMTP envelope and mail header fields. To avoid bouncing 46 internationalized Email messages when a server in the delivery path 47 does not support the UTF8SMTP extension, some sort of converting 48 mechanism is required. This document describes a downgrading 49 mechanism for Email Address Internationalization. Note that this is 50 a way to downgrade, not tunnel. There is no associated up-conversion 51 mechanism, although internationalized email clients might use 52 original internationalized addresses or other data when displaying or 53 replying to downgraded messages. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. New header fields definition . . . . . . . . . . . . . . . . . 5 60 3.1. Envelope information preservation headers . . . . . . . . 5 61 3.2. Address header field preservation headers . . . . . . . . 5 62 3.3. Unknown header fields preservation headers . . . . . . . . 6 63 4. SMTP Downgrading . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Email header fields downgrading . . . . . . . . . . . . . . . 8 65 5.1. Downgrading method for each header field . . . . . . . . . 9 66 6. MIME body part headers downgrading . . . . . . . . . . . . . . 11 67 7. Security considerations . . . . . . . . . . . . . . . . . . . 11 68 8. Implementation notes . . . . . . . . . . . . . . . . . . . . . 12 69 8.1. Trivial downgrading . . . . . . . . . . . . . . . . . . . 12 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 72 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 73 11.1. draft-yoneya-ima-downgrade: Version 00 . . . . . . . . . . 15 74 11.2. draft-yoneya-ima-downgrade: Version 01 . . . . . . . . . . 15 75 11.3. draft-ietf-eai-downgrade: Version 00 . . . . . . . . . . . 16 76 11.4. draft-ietf-eai-downgrade: Version 01 . . . . . . . . . . . 16 77 11.5. draft-ietf-eai-downgrade: Version 02 . . . . . . . . . . . 16 78 11.6. draft-ietf-eai-downgrade: Version 03 . . . . . . . . . . . 16 79 11.7. draft-ietf-eai-downgrade: Version 04 . . . . . . . . . . . 16 80 11.8. draft-ietf-eai-downgrade: Version 05 . . . . . . . . . . . 17 81 12. Normative References . . . . . . . . . . . . . . . . . . . . . 17 82 Appendix A. Displaying downgraded message . . . . . . . . . . . . 18 83 A.1. Displaying technique 1 . . . . . . . . . . . . . . . . . . 18 84 A.2. Displaying technique 2 . . . . . . . . . . . . . . . . . . 19 85 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 19 86 B.1. Downgrading example 1 . . . . . . . . . . . . . . . . . . 19 87 B.2. Displaying example . . . . . . . . . . . . . . . . . . . . 22 88 B.2.1. Displaying technique 1 example . . . . . . . . . . . . 23 89 B.2.2. Displaying technique 2 example . . . . . . . . . . . . 24 90 B.3. Downgrading example 2 . . . . . . . . . . . . . . . . . . 27 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 92 Intellectual Property and Copyright Statements . . . . . . . . . . 30 94 1. Introduction 96 Traditional mail systems which are defined by [RFC2821] and [RFC2822] 97 allow ASCII characters in SMTP envelope and mail header field values. 98 The UTF8SMTP extension [RFC4952], [I-D.ietf-eai-utf8headers] and 99 [I-D.ietf-eai-smtpext] allows UTF-8 characters in SMTP envelope and 100 mail header field values. 102 If an envelope address or header field contains non-ASCII characters, 103 the message cannot be delivered unless every system in the delivery 104 path supports UTF8SMTP. To avoid bouncing such messages when a 105 server is encountered which does not support the UTF8SMTP extension, 106 this document describes a downgrading mechanism. Downgrading a 107 message converts envelope and header fields to an all-ASCII 108 representation. 110 [I-D.ietf-eai-utf8headers] allows UTF-8 characters to be used in mail 111 header fields and MIME header fields. The downgrading mechanism 112 specified here converts mail header fields and MIME header fields to 113 ASCII. 115 This document does not change any protocols except by defining new 116 header fields. It describes the conversion method from the 117 internationalized email envelopes/messages which are defined in 118 [RFC4952] [I-D.ietf-eai-utf8headers] [I-D.ietf-eai-smtpext] to the 119 traditional email envelopes/messages which are defined in [RFC2821] 120 [RFC2822]. 122 [I-D.ietf-eai-smtpext] section 2.2 defines when downgrading occurs. 123 If the SMTP client has an UTF8SMTP envelope or an internationalized 124 message and the SMTP server doesn't support the UTF8SMTP SMTP 125 extension, then the SMTP client MUST NOT send a UTF8SMTP envelope or 126 an internationalized message to the SMTP server. The section shows 4 127 choices. The fourth choice is downgrading, as described here. 129 Downgrading may be implemented in MUAs, MSAs, MTAs which act as the 130 SMTP client, or in MDAs, POP servers, IMAP servers which store or 131 offer UTF8SMTP envelopes or internationalized messages to non- 132 UTF8SMTP compliant systems which include message stores. 134 This document tries to define the downgrading process clearly and it 135 preserves the original information as much as possible. 137 Downgrading in UTF8SMTP consists of the following four parts: 138 o New header fields definition 139 o SMTP downgrading 140 o Email header fields downgrading 141 o MIME header fields downgrading 143 In Section 3, many header fields starting with "downgraded" are 144 introduced. They preserve the original envelope information and the 145 original header fields. 147 The SMTP downgrading is described in Section 4. It generates ASCII 148 only envelope information from an UTF8SMTP envelope. 150 The Email header fields downgrading is described in Section 5. It 151 generates ASCII only header fields. 153 The MIME header fields are expanded in [I-D.ietf-eai-utf8headers]. 154 The MIME header fields downgrading is described in Section 6. It 155 generates ASCII only MIME header fields. 157 Decoding downgraded message is described in Appendix A. This 158 mechanism is for use by internationalized email clients. Once a 159 message has been downgraded, there is no up-conversion which can be 160 applied on the SMTP delivery path. 162 2. Terminology 164 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 165 and "MAY" in this document are to be interpreted as described in RFC 166 2119 [RFC2119]. 168 All specialized terms used in this specification are defined in the 169 EAI overview [RFC4952] or in [RFC2821][RFC2822], MIME documents 170 [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address", 171 "internationalized email address", "non-ASCII address", "i18mail 172 address", "UTF8SMTP", "message" and "mailing list" are used with the 173 definitions from [RFC4952] document. 175 This document depends on [I-D.ietf-eai-smtpext], 176 [I-D.ietf-eai-utf8headers], and [I-D.ietf-eai-dsn]. Key words used 177 in these document are used in this document, too. 179 The term "non-ASCII" is an UTF-8 string which contains at least one 180 non-ASCII character. 182 An "UTF8SMTP envelope" has Email originator/recipient addresses 183 expanded by [I-D.ietf-eai-smtpext] and [I-D.ietf-eai-dsn]. 185 An "UTF8SMTP message" is Email messages expanded by 187 [I-D.ietf-eai-utf8headers]. 189 3. New header fields definition 191 New header fields starting with "downgraded" are defined here to 192 preserve those original envelope and header values which contain 193 UTF-8 characters. During downgrading, one new "downgraded" header 194 field is added for each original envelope or header field which 195 cannot be passed as-is to a server which does not support UTF8SMTP. 196 The original envelope or header field is removed or altered. Only 197 those envelope and header fields which contain non-ASCII characters 198 are affected. The result of this process is a message which is 199 compliant with existing email specifications [RFC2821] and [RFC2822]. 200 The original internationalized information can be retrieved by 201 examining the "downgraded" header fields which were added. Even 202 though the information is not lost, the original message cannot be 203 perfectly reconstructed. Hence, downgrading is a one-way process. 204 However, an internationalized client might use the information in the 205 "downgraded" header fields when processing a downgraded message, for 206 example, such as displaying or composing a reply. 208 3.1. Envelope information preservation headers 210 Two headers "Downgraded-Mail-From:" and "Downgraded-Rcpt-To:" are 211 defined to preserve SMTP envelope downgraded information. SMTP 212 envelope downgraded information consists of the original non-ASCII 213 address and the downgraded all-ASCII address. The header field 214 syntax is specified as follows: 216 fields =/ downgradedmailfrom / downgradedrcptto 217 downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" 1*[FWS] 218 "<" Mailbox ">" [FWS] CRLF 219 downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS] 220 "<" Mailbox ">" [FWS] CRLF 222 Original non-ASCII address is defined in 223 [I-D.ietf-eai-smtpext]; it is treated as unstructured in this header 224 and it is encoded according to [RFC2047]. is defined in 225 [RFC2821], section 4.1.2. 227 3.2. Address header field preservation headers 229 The address header fields preservation headers are defined to 230 preserve the original header field. Their value field holds the 231 original header field value. Any original header field value is 232 treated as an and it MUST be encoded according to 233 [RFC2047] with charset='UTF-8'. The header field syntax is specified 234 as follows: 236 fields =/ known-downgraded-headers ":" unstructued CRLF 237 known-downgraded-headers = "Downgraded-" original-headers 238 original-headers = "From" / "To" / "Cc" / "Bcc" / 239 "Sender" / "Reply-To" / 240 "Resent-From" / "Resent-Sender" / 241 "Resent-To" / "Resent-Cc" / "Return-Path" 243 Preserving a header field in a downgraded header field is defined as: 244 1. Generate new downgraded header field whose value is the original 245 header field value. 246 2. Encode the generated header according to [RFC2047] with 247 charset='UTF-8'. 249 3.3. Unknown header fields preservation headers 251 The unknown header fields preservation headers are defined to 252 encapsulate those original header field which contains non-ASCII 253 characters and are not otherwise provided for in the this 254 specification. The encapsulation header field name is the 255 concatenation of "Downgraded-" and the original name. The value 256 field holds the original header field value. 258 Any original header field value is treated as an unstructured value 259 and it MUST be encoded according to [RFC2047] with charset='UTF-8'. 260 The header field syntax is specified as follows: 262 fields =/ unknown-downgraded-headers ":" unstructued CRLF 263 unknown-downgraded-headers = "Downgraded-" original-header-field-name 264 original-header-field-name = field-name 266 field-name = 1*ftext 268 ftext = %d33-57 / ; Any character except 269 %d59-126 ; controls, SP, and 270 ; ":". 272 Encapsulating a header field in a Downgraded header field is defined 273 as: 274 1. Generate new Downgraded header whose value is the original header 275 field value. 277 2. Encode the generated header field according to [RFC2047] with 278 charset='UTF-8'. 279 3. Remove the original header field. 281 4. SMTP Downgrading 283 Target of downgrading elements in SMTP envelope are below: 285 o MAIL FROM: 286 o RCPT TO: 287 o ORCPT parameter 289 Downgrading the SMTP envelope uses ALT-ADDRESS parameter defined in 290 [I-D.ietf-eai-smtpext]. An address is downgradable if the address is 291 non-ASCII address and has ASCII address specified by ALT-ADDRESS 292 parameter. Since only non-ASCII addresses are downgradable, 293 specifying an ALT-ADDRESS value for an all-ASCII address is invalid 294 for use with this specification, and no interpretation is assigned to 295 it. This restriction allows for future extension of the 296 specification even though no such extensions are currently 297 anticipated. 299 Note that even if no downgrading is performed on the envelope, 300 message header fields and message body MIME header fields that 301 contain non-ASCII characters MUST be downgraded. This is described 302 in Section 5 and Section 6. 304 When downgrading, replace each non-ASCII mail address in the envelope 305 with its specified alternative ASCII address and preserve the 306 original information using "Downgraded-Mail-From" and "Downgraded- 307 Rcpt-To" header fields as defined in Section 3. Before replacing, 308 decode the ALT-ADDRESS parameter value because it is encoded as xtest 309 [RFC3461]. 311 To avoid disclosing recipient addresses, the downgrading process MUST 312 NOT add "Downgraded-Rcpt-To:" header if the SMTP downgrading targets 313 multiple recipients. See Section 7 for more detail. 315 The "RCPT TO" command may have an ORCPT parameter when the recipient 316 address is downgraded. The ORCPT parameter is used for DSN 317 [RFC3461]. If the ORCPT parameter contains an "utf-8" address and 318 the address contains non-ASCII characters, the ORCPT parameter MUST 319 be converted to utf-8-addr-xtext form or utf-8-addr-unitext form 320 which are described in [I-D.ietf-eai-dsn]. 322 5. Email header fields downgrading 324 This section defines the conversion method to ASCII for each header 325 field which may contain non-ASCII characters. 327 [I-D.ietf-eai-utf8headers] expands Received: header fields, [RFC2822] 328 ABNF elements , , , , [RFC2045] 329 ABNF element . 331 Header field downgrading is defined below for each ABNF element. 332 Downgrading an unknown header field is also defined as ENCAPSULATION 333 downgrading. Converting the header field terminates when no non- 334 ASCII characters remain in the header field. 336 RECEIVED downgrading: If the header field name is "Received:" and 337 the FOR clause contains a non-ASCII addresses, remove the FOR 338 clause from the header field. The other part except in the 339 comments does not contain non-ASCII values. 341 UNSTRUCTURED downgrading: If the header field has an 342 field which contains non-ASCII characters, encode the field 343 according to [RFC2047] with charset='UTF-8'. 345 WORD downgrading: If the header field has any fields which 346 contains non-ASCII characters, encode the fields according to 347 [RFC2047] with charset='UTF-8'. 349 COMMENT downgrading: If the header field has any fields 350 which contains non-ASCII characters, encode the fields according 351 to [RFC2047] with charset='UTF-8'. 353 MIME-VALUE downgrading: If the header field has any 354 elements defined by [RFC2045] and the elements contain non-ASCII 355 characters, encode the elements by [RFC2231] with 356 charset='UTF-8' and the Language information empty. If the 357 element is and it contains outside 358 the DQUOTE, remove the before this conversion. 360 DISPLAY-NAME downgrading: If the header field has any 361 elements and they have elements which contain non- 362 ASCII characters, encode the elements according to 363 [RFC2047] with charset='UTF-8'. 365 MAILBOX downgrading: The elements have no equivalent 366 format for non-ASCII addresses. If the header field has any 367 elements which contain non-ASCII characters, preserve 368 the header field in each Address header field preservation header 369 defined in Section 3.2, and rewrite each element to 370 ASCII only format. The element which contains non-ASCII 371 characters is one of three formats. 373 * [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>" 375 Rewrite it as 377 [ Display-name ] "<" Addr-spec ">" 379 * [ Display-name ] "<" Utf8-addr-spec ">" 380 * Utf8-addr-spec 382 Rewrite both as 383 [ Display-name ] "Internationalized Address " Encoded-word 384 " Removed:;" 386 where the is the original 387 encoded according to [RFC2047]. 389 ENCAPSULATION downgrading: if the header field contains non-ASCII 390 characters and for which no rule is given above, encapsulate it in 391 a Downgraded header field described in Section 3.3 as a last 392 resort. 394 5.1. Downgrading method for each header field 396 Header fields are listed in [RFC4021]. This section describes the 397 downgrading method for each header field. 399 If the whole mail header field does not contain non-ASCII characters, 400 email header field downgrading is not required. Each header field's 401 downgrading method is described below. 403 o Address header fields which contain s 405 From: 406 Sender: 407 Reply-To: 408 To: 409 Cc: 410 Bcc: 411 Resent-From: 412 Resent-Sender: 414 Resent-To: 415 Resent-Cc: 416 Return-Path: 418 If the header field contains elements which contains 419 non-ASCII addresses, preserve the header field in a downgraded 420 header before the conversion. Then do COMMENT downgrading, 421 DISPLAY-NAME downgrading and MAILBOX downgrading. 423 o Downgrading Non-ASCII in comments 425 Date: 426 Message-ID: 427 In-Reply-To: 428 References: 429 Resent-Date: 430 Resent-Message-ID: 431 MIME-Version: 432 Content-ID: 434 These header fields do not contain non-ASCII characters except in 435 comments. If the header contains UTF-8 characters in comments, do 436 COMMENT downgrading. 438 o Trace header fields 440 Received: 442 do COMMENT downgrading and do RECEIVED downgrading. 444 o MIME Content header fields 446 Content-Type: 447 Content-Disposition: 449 Do MIME-VALUE downgrading. 451 o Non-ASCII in 453 Subject: 454 Comments: 455 Content-Description: 457 Do UNSTRUCTURED downgrading. 459 o Non-ASCII in or 460 Keywords: 462 Do WORD downgrading. 464 o Other header fields 466 All other header fields which contains non-ASCII characters are 467 user-defined, missing from this draft or future defined header 468 fields. Do ENCAPSULATION downgrading as a last resort. 470 6. MIME body part headers downgrading 472 MIME body part header fields may contain non-ASCII characters 473 [I-D.ietf-eai-utf8headers]. This section defines the conversion 474 method to ASCII only header fields for each MIME header field which 475 contains non-ASCII characters. Parse the message body's MIME 476 structure for all levels and check each MIME header field whether it 477 contains non-ASCII characters. If the header field contains non- 478 ASCII characters in the header value, the header is a target of the 479 MIME body part headers downgrading. Each MIME header field's 480 downgrading method is described below. COMMENT downgrading, MIME- 481 VALUE downgrading, UNSTRUCTURED downgrading are described in 482 Section 5. 484 Content-ID: 485 The Content-ID: header does not contain non-ASCII characters 486 except in comments. If the header contains UTF-8 characters in 487 comments, do COMMENT downgrading. 489 Content-Type: 490 Content-Disposition: 491 Do MIME-VALUE downgrading. 493 Content-Description: 494 Do UNSTRUCTURED downgrading. 496 7. Security considerations 498 o A Downgraded message's header fields contain ASCII characters 499 only. But they still contain MIME encapsulated header fields 500 which contains non-ASCII UTF-8 characters. And more, the body 501 part may contain UTF-8 message. The recipients need to accept 502 UTF-8 mail body and UTF-8 header fields which is MIME encoded. 504 o Rewriting headers increases the opportunities for undetected 505 spoofing. 507 o Recipients addresses can be undisclosed if those addresses are 508 listed on Bcc or group address. Those undisclosed addresses are 509 used only in the Envelope. Copying information from the Envelope 510 into headers risks inadvertent information disclosure (not just 511 about addresses). See Section 4 for instructions on recipient 512 address handling. 514 o The techniques described here invalidates methods that depend on 515 signatures over the envelope or any part of the message which 516 includes the top-level header or body part headers. Depending on 517 the specific message being downgraded, DKIM especially, but also 518 possibly S/MIME, PGP, and similar techniques are all likely to 519 break. 521 o Many gateways and servers on the Internet will discard headers 522 with which they are not familiar. To the extent to which the 523 downgrade procedures depend on new headers (e.g., "Downgraded") to 524 avoid information loss, then the risk of having those headers 525 dropped and its implications must be identified. In particular, 526 it appears to me that, if the Downgraded headers are dropped, 527 there is no possibility of reconstructing the original information 528 at any point (before, during, or after delivery). 530 See "Security considerations" section in [RFC4952] for more 531 discussion. 533 8. Implementation notes 535 Downgrading is an alternative to rejection for delivering messages 536 which require UTF8SMTP support to a server which does not provide 537 this. Implementing the full specification of this document is 538 desirable, but a partial implementation is also possible. 540 If a partial downgrading implementation confronts an unsupported 541 downgrading target, the implementation MUST NOT send the message to 542 server which does not support UTF8SMTP. Instead, it MUST reject the 543 message or generate a notification of non-deliverability. 545 8.1. Trivial downgrading 547 A partial downgrading, Trivial downgrading is discussed. It does not 548 support non-ASCII addresses in SMTP envelope and address header 549 fields, unknown header fields downgrading, the MIME body part headers 550 downgrading. It supports 551 o some simple header fields downgrading: Subject 552 o comments and display name downgrading: From, To, CC 553 o trace header field downgrading: Received 555 Otherwise, the downgrading fails. 557 Trivial downgrading targets mail messages which are generated by 558 UTF8SMTP aware MUAs and contain non-ASCII characters in comments, 559 display names, unstructured parts without using non-ASCII E-mail 560 addresses. This E-mail message does not contain non-ASCII addresses 561 in SMTP Envelope and its header fields. But it is not deliverable 562 via UTF8SMTP un-aware MTA. Implementing full spec downgrading may be 563 hard, but trivial downgrading saves mail messages without using non- 564 ASCII addresses. 566 9. IANA Considerations 568 IANA is requested to register the following header fields in the 569 Permanent Message Header Field Repository, in accordance with the 570 procedures set out in [RFC3864]. 572 Header field name: Downgraded-Mail-From 573 Applicable protocol: mail 574 Status: experimental 575 Author/change controller: IETF 576 Specification document(s): This document (Section 3) 578 Header field name: Downgraded-Rcpt-To 579 Applicable protocol: mail 580 Status: experimental 581 Author/change controller: IETF 582 Specification document(s): This document (Section 3) 584 Header field name: Downgraded-From 585 Applicable protocol: mail 586 Status: experimental 587 Author/change controller: IETF 588 Specification document(s): This document (Section 3) 590 Header field name: Downgraded-Sender 591 Applicable protocol: mail 592 Status: experimental 593 Author/change controller: IETF 594 Specification document(s): This document (Section 3) 596 Header field name: Downgraded-To 597 Applicable protocol: mail 598 Status: experimental 599 Author/change controller: IETF 600 Specification document(s): This document (Section 3) 602 Header field name: Downgraded-Cc 603 Applicable protocol: mail 604 Status: experimental 605 Author/change controller: IETF 606 Specification document(s): This document (Section 3) 608 Header field name: Downgraded-Reply-To 609 Applicable protocol: mail 610 Status: experimental 611 Author/change controller: IETF 612 Specification document(s): This document (Section 3) 614 Header field name: Downgraded-Bcc 615 Applicable protocol: mail 616 Status: experimental 617 Author/change controller: IETF 618 Specification document(s): This document (Section 3) 620 Header field name: Downgraded-Resent-From 621 Applicable protocol: mail 622 Status: experimental 623 Author/change controller: IETF 624 Specification document(s): This document (Section 3) 626 Header field name: Downgraded-Resent-To 627 Applicable protocol: mail 628 Status: experimental 629 Author/change controller: IETF 630 Specification document(s): This document (Section 3) 632 Header field name: Downgraded-Resent-Cc 633 Applicable protocol: mail 634 Status: experimental 635 Author/change controller: IETF 636 Specification document(s): This document (Section 3) 637 Header field name: Downgraded-Resent-Sender 638 Applicable protocol: mail 639 Status: experimental 640 Author/change controller: IETF 641 Specification document(s): This document (Section 3) 643 Header field name: Downgraded-Return-Path 644 Applicable protocol: mail 645 Status: experimental 646 Author/change controller: IETF 647 Specification document(s): This document (Section 3) 649 And more, IANA is requested to reserve all the field names that start 650 by "Downgraded-" for unknown header fields downgrading described in 651 Section 3.3, in accordance with the procedures set out in [RFC3864]. 653 Header field name: Names which starts by "Downgraded-" 654 Applicable protocol: mail 655 Status: experimental 656 Author/change controller: IETF 657 Specification document(s): This document (Section 3) 659 10. Acknowledgements 661 Significant comments and suggestions were received from John Klensin, 662 Harald Alvestrand, Chris Newman, Randall Gellens, Charles Lindsey, 663 Marcos Sanz, Alexey Melnikov, Frank Ellermann, Edward Lewis, S. 664 Moonesamy and JET members. 666 11. Change History 668 This section is used for tracking the update of this document. Will 669 be removed after finalize. 671 11.1. draft-yoneya-ima-downgrade: Version 00 673 o Initial version 674 o Followed draft-yeh-ima-utf8headers-00 and draft-yao-smtpext-00 676 11.2. draft-yoneya-ima-downgrade: Version 01 678 o Document structure was changed 679 o Followed draft-yeh-ima-utf8headers-01 and draft-yao-smtpext-02 680 o Downgrading requirements were added 681 o SMTP DATA encapsulation method was proposed 682 o Downgrading examples was provided 684 11.3. draft-ietf-eai-downgrade: Version 00 686 o Followed draft-yeh-ima-utf8headers-01 and 687 draft-ietf-eai-smtpext-00 688 o No header downgrading method was proposed 689 o Header encapsulation method was proposed 691 11.4. draft-ietf-eai-downgrade: Version 01 693 o Followed draft-ietf-eai-utf8headers-00 694 o Header conversion and encapsulation method was merged 695 o Header conversion method was defined in detail 697 11.5. draft-ietf-eai-downgrade: Version 02 699 o Followed draft-ietf-eai-utf8headers-01 and 700 draft-ietf-eai-smtpext-01 701 o Specification about algorithmic generated address is removed 702 o No header downgrading method was removed 703 o SMTP DATA encapsulation method was removed 705 11.6. draft-ietf-eai-downgrade: Version 03 707 o Followed draft-ietf-eai-utf8headers-03 and 708 draft-ietf-eai-smtpext-03 709 o Downgraded: and Envelope-Downgraded: headers definition was added 710 o Mail header fields downgrading method was refined 711 o Examples in Appendix A were refined 713 11.7. draft-ietf-eai-downgrade: Version 04 715 o Followed draft-ietf-eai-utf8headers-06, draft-ietf-eai-smtpext-07 716 and draft-ietf-eai-dsn-02 717 o Downgrading requirements and conditions were moved to 718 Introduction. 719 o Descriptions about upgrading were removed. 720 o SPF and DKIM discussion were removed. 721 o Added many header fields downgrading. 722 o Allow address literal rewriting without alternate ASCII address in 723 header fields. 724 o Added MIME body part headers downgrading. 725 o Added ORCPT downgrading. 727 11.8. draft-ietf-eai-downgrade: Version 05 729 o fixed examples 730 * ALT-ADDRESS parameter mistake 731 * RFC2047(x) notation was changed to encoded-word format 732 o Added implementation consideration section and trivial downgrading 733 o Downgraded: and Envelope-Downgraded: headers are separated for 734 each original headers. 735 o Removed list-* header fields downgrading 736 o Changed the way of writing the header field downgrading section 738 12. Normative References 740 [I-D.ietf-eai-dsn] 741 Newman, C. and A. Melnikov, "International Delivery and 742 Disposition Notifications", draft-ietf-eai-dsn-05 (work in 743 progress), November 2007. 745 [I-D.ietf-eai-smtpext] 746 Yao, J. and W. Mao, "SMTP extension for internationalized 747 email address", draft-ietf-eai-smtpext-09 (work in 748 progress), November 2007. 750 [I-D.ietf-eai-utf8headers] 751 Yeh, J., "Internationalized Email Headers", 752 draft-ietf-eai-utf8headers-07 (work in progress), 753 September 2007. 755 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 756 Extensions (MIME) Part One: Format of Internet Message 757 Bodies", RFC 2045, November 1996. 759 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 760 Part Three: Message Header Extensions for Non-ASCII Text", 761 RFC 2047, November 1996. 763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 764 Requirement Levels", BCP 14, RFC 2119, March 1997. 766 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 767 Presentation Information in Internet Messages: The 768 Content-Disposition Header Field", RFC 2183, August 1997. 770 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 771 Word Extensions: 772 Character Sets, Languages, and Continuations", RFC 2231, 773 November 1997. 775 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 776 April 2001. 778 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 779 April 2001. 781 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 782 Extension for Delivery Status Notifications (DSNs)", 783 RFC 3461, January 2003. 785 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 786 Procedures for Message Header Fields", BCP 90, RFC 3864, 787 September 2004. 789 [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME 790 Header Fields", RFC 4021, March 2005. 792 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 793 Internationalized Email", RFC 4952, July 2007. 795 Appendix A. Displaying downgraded message 797 A perfect reverse-function of the downgrading does not exist because 798 the encoding defined in [RFC2047] is not exactly reversible. The 799 restoration of the downgrading should be done once at the final 800 destination of the downgraded message such as MUAs or IMAP servers. 801 This document describes the restoration methods as displaying 802 technique. 804 Displaying downgraded message is mostly retrieved by MIME decoding 805 according to [RFC2047] and [RFC2231]. Result of MIME decoding, 806 downgraded header fields are still in Downgraded-*: header fields, 807 but the header field values are MIME decoded. These decoded 808 Downgraded-*: header fields contain the original header field values 809 and the recipient can read them. But the recipient's MUA cannot use 810 the original header fields automatically. 812 Additionally, MUAs can process Downgraded-*: header. It is described 813 in Appendix A.1 and Appendix A.2. 815 A.1. Displaying technique 1 817 MUA can remove 'Downgraded-' from decoded 'Downgraded-*:' header 818 fields' name. With this technique, The address header fields may be 819 displayed twice, one is ASCII-only downgraded header field and the 820 other is from decoded Downgraded-*: header. 822 A.2. Displaying technique 2 824 MUA can decode and regenerate headers which contains the original 825 non-ASCII addresses. It is described below: 826 o For each Downgraded-*: header field, generate new header field 827 which field name is the original header name and the field value 828 is the decoded header field value. 829 * If the header is an address header described in Section 5, 830 + Generate ASCII only header fields defined in Section 5 from 831 the decoded header fields without re-generating 832 Downgraded-*: header fields. 833 + Remove the header field which is the same with the generated 834 ASCII only header from the header fields. This comparison 835 requires considerations for foldings and [RFC2047] encoded 836 parts. 838 Appendix B. Examples 840 B.1. Downgrading example 1 842 This section shows an SMTP Downgrading example. Consider a mail 843 message. 844 o The sender address is "NON-ASCII-local@example.com" which is non- 845 ASCII address. Its ASCII alternative is "ASCII-local@example.com" 846 and its display-name is "DISPLAY-local". 847 o The "To" address is "NON-ASCII-remote1@example.net" which is non- 848 ASCII address. Its ASCII alternative is 849 "ASCII-remote1@example.net" and its display-name is "DISPLAY- 850 remote1". 851 o The "CC" address is non-ASCII address 852 "NON-ASCII-remote2@example.org" without alternative ASCII address. 853 Its display-name is "DISPLAY-remote2". 854 o Three display-names contains non-ASCII characters. 855 o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII 856 characters. 857 o assume To: recipient's MTA (example.net) does not support 858 UTF8SMTP. 859 o assume Cc: recipient's MTA (example.org) supports UTF8SMTP. 860 The example SMTP envelope/message is showin in Figure 4. In this 861 example, the To: recipient's session is fucused. 863 MAIL From: 864 ALT-ADDRESS=ASCII-local@example.com 865 RCPT TO: 866 ALT-ADDRESS=ASCII-remote1@example.net 867 RCPT TO: 868 ------------------------------------------------------------- 869 Message-Id: MESSAGE_ID 870 Mime-Version: 1.0 871 Content-Type: text/plain; charset="UTF-8" 872 Content-Transfer-Encoding: 8bit 873 Subject: NON-ASCII-SUBJECT 874 From: DISPLAY-local > 876 To: DISPLAY-remote1 > 878 CC: DISPLAY-remote2 879 Date: DATE 881 MAIL_BODY 883 Figure 4: Original envelope/message (example 1) 885 In this example, there are two SMTP recipients, one is To:, the other 886 is CC:. The SMTP downgrading treats To: session downgrading. 887 Figure 5 shows SMTP downgraded example. 889 MAIL From: 890 RCPT TO: 891 ------------------------------------------------------------- 892 Downgraded-Mail-From: =?UTF-8?Q??= 893 894 Downgraded-Rcpt-To: =?UTF-8?Q??= 895 896 Message-Id: MESSAGE_ID 897 Mime-Version: 1.0 898 Content-Type: text/plain; charset="UTF-8" 899 Content-Transfer-Encoding: 8bit 900 Subject: NON-ASCII-SUBJECT 901 From: DISPLAY-local > 903 To: DISPLAY-remote1 > 905 CC: DISPLAY-remote2 906 Date: DATE 908 MAIL_BODY 910 Figure 5: SMTP Downgraded envelope/message (example 1) 912 After SMTP downgrading, header fields downgrading is performed. 913 Final downgraded message is shown in Figure 6. Return-Path header 914 will be added by the final destination MTA. 916 Return-Path: 917 Downgraded-Mail-From: =?UTF-8?Q??= 918 919 Downgraded-Rcpt-To: =?UTF-8?Q??= 920 921 Message-Id: MESSAGE_ID 922 Mime-Version: 1.0 923 Content-Type: text/plain; charset="UTF-8" 924 Content-Transfer-Encoding: 8bit 925 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 926 Downgraded-From: =?UTF-8?Q?DISPLAY-local?= 927 =?UTF-8?Q?> 928 From: =?UTF-8?Q?DISPLAY-local?= 929 To: =?UTF-8?Q?DISPLAY-remote1?= 930 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1?= 931 =?UTF-8?Q?> 932 CC: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 933 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; 934 Downgraded-CC: =?UTF-8?Q?DISPLAY-remote2?= 935 =?UTF-8?Q??= 936 Date: DATE 938 MAIL_BODY 940 Figure 6: Downgraded message (example 1) 942 B.2. Displaying example 944 Figure 7 shows MIME decoded message of Figure 6. 946 Return-Path: 947 Downgraded-Mail-From: 948 949 Downgraded-Rcpt-To: 950 951 Message-Id: MESSAGE_ID 952 Mime-Version: 1.0 953 Content-Type: text/plain; charset="UTF-8" 954 Content-Transfer-Encoding: 8bit 955 Subject: NON-ASCII-SUBJECT 956 Downgraded-From: DISPLAY-local> 958 From: DISPLAY-local 959 Downgraded-To: DISPLAY-remote1> 961 To: DISPLAY-remote1 962 Downgraded-CC: DISPLAY-remote2 963 CC: DISPLAY-remote2 Internationalized address 964 NON-ASCII-remote2@example.org removed:; 965 Date: DATE 967 MAIL_BODY 969 Figure 7: MIME decoded message 971 B.2.1. Displaying technique 1 example 972 After removing 'Downgraded-' from decoded 'Downgraded-*:' header 973 fields 975 Return-Path: 976 Downgraded-Mail-From: 977 978 Downgraded-Rcpt-To: 979 980 Message-Id: MESSAGE_ID 981 Mime-Version: 1.0 982 Content-Type: text/plain; charset="UTF-8" 983 Content-Transfer-Encoding: 8bit 984 Subject: NON-ASCII-SUBJECT 985 From: DISPLAY-local> 987 From: DISPLAY-local 988 To: DISPLAY-remote1> 990 To: DISPLAY-remote1 991 CC: DISPLAY-remote2 992 CC: DISPLAY-remote2 Internationalized address 993 NON-ASCII-remote2@example.org removed:; 994 Date: DATE 996 MAIL_BODY 998 Figure 8: Displaying technique 1 1000 B.2.2. Displaying technique 2 example 1002 This example shows displaying process of Appendix A.2 for Figure 6. 1004 First, check downgraded address header fields existence. 1006 Downgraded-From: =?UTF-8?Q?DISPLAY-local?= 1007 =?UTF-8?Q?> 1008 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1?= 1009 =?UTF-8?Q?> 1010 Downgraded-CC: =?UTF-8?Q?DISPLAY-remote2?= 1011 =?UTF-8?Q??= 1013 Figure 9: Displaying technique 2: selecting downgraded address header 1014 fields 1016 Then, decode MIME encoded parts. 1018 Downgraded-From: DISPLAY-local> 1020 Downgraded-To: DISPLAY-remote1> 1022 Downgraded-CC: DISPLAY-remote2 1024 Figure 10: Displaying technique 2: decode downgraded address header 1025 fields 1027 Apply header fields downgrading to the decoded header without re- 1028 generating Downgraded-*: header. 1030 From: =?UTF-8?Q?DISPLAY-local?= 1031 To: =?UTF-8?Q?DISPLAY-remote1?= 1032 CC: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 1033 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; 1035 Figure 11: Displaying technique 2: downgraded decoded 'Downgraded-*:' 1037 Remove the header fields which is the same with Figure 11 from 1038 Figure 6. 1040 Return-Path: 1041 Downgraded-Mail-From: =?UTF-8?Q??= 1042 1043 Downgraded-Rcpt-To: =?UTF-8?Q??= 1044 1045 Message-Id: MESSAGE_ID 1046 Mime-Version: 1.0 1047 Content-Type: text/plain; charset="UTF-8" 1048 Content-Transfer-Encoding: 8bit 1049 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 1050 Downgraded-From: =?UTF-8?Q?DISPLAY-local?= 1051 =?UTF-8?Q?> 1052 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1?= 1053 =?UTF-8?Q?> 1054 Downgraded-CC: =?UTF-8?Q?DISPLAY-remote2?= 1055 =?UTF-8?Q??= 1056 Date: DATE 1058 MAIL_BODY 1060 Figure 12: Displaying technique 2: Removing duplicated headers 1062 Decode each 'Downgraded' header and replace it with its decoded 1063 header. If each mail header has [RFC2047] encoded part and which 1064 encoding is "UTF-8", it is a downgraded header, so decode it. 1066 Return-Path: 1067 Downgraded-Mail-From: 1068 1069 Downgraded-Rcpt-To: 1070 1071 Message-Id: MESSAGE_ID 1072 Mime-Version: 1.0 1073 Content-Type: text/plain; charset="UTF-8" 1074 Content-Transfer-Encoding: 8bit 1075 Subject: NON-ASCII-SUBJECT 1076 From: DISPLAY-local> 1078 To: DISPLAY-remote1> 1080 CC: DISPLAY-remote2 1081 Date: DATE 1083 MAIL_BODY 1084 Figure 13: Display technique 2: decoded message 1086 As a result, in this simple example, all original header fields are 1087 displayed in the original form. 1089 B.3. Downgrading example 2 1091 In many cases, the sender wants to use non-ASCII address, the 1092 recipient does not support UTF8SMTP and does not have non-ASCII 1093 address. 1094 o The sender address is "NON-ASCII-local@example.com" which is non- 1095 ASCII address. Its ASCII alternative is 1096 "ASCII-local@example.com". It has a display-name "DISPLAY-local" 1097 which contains non-ASCII characters. 1098 o The "To" address is "ASCII-remote1@example.net" which is ASCII 1099 only. It has a display-name "DISPLAY-remote1" which contains non- 1100 ASCII characters. 1101 o The Subject header is "NON-ASCII-SUBJECT" which contains non-ASCII 1102 characters. 1103 The second example envelope/message is shown in Figure 14. 1105 MAIL From: 1106 ALT-ADDRESS=ASCII-local@example.com 1107 RCPT TO: 1108 ------------------------------------------------------------- 1109 Message-Id: MESSAGE_ID 1110 Mime-Version: 1.0 1111 Content-Type: text/plain; charset="UTF-8" 1112 Content-Transfer-Encoding: 8bit 1113 Subject: NON-ASCII-SUBJECT 1114 From: DISPLAY-local > 1116 To: DISPLAY-remote1 1117 Date: DATE 1119 MAIL_BODY 1121 Figure 14: Original message (example 2) 1123 In this example, SMTP session is downgradable. Figure 15 shows SMTP 1124 downgraded envelope/message. 1126 MAIL From: 1127 RCPT TO: 1128 ------------------------------------------------------------- 1129 Downgraded-Mail-From: =?UTF-8?Q??= 1130 1131 Message-Id: MESSAGE_ID 1132 Mime-Version: 1.0 1133 Content-Type: text/plain; charset="UTF-8" 1134 Content-Transfer-Encoding: 8bit 1135 Subject: NON-ASCII-SUBJECT 1136 From: DISPLAY-local > 1138 To: DISPLAY-remote1 1139 Date: DATE 1141 MAIL_BODY 1143 Figure 15: SMTP Downgraded envelope/message (example 2) 1145 After SMTP downgrading, header fields downgrading is performed. The 1146 downgraded example is shown in Figure 16. 1148 Return-Path: 1149 Downgraded-Mail-From: =?UTF-8?Q??= 1150 1151 Message-Id: MESSAGE_ID 1152 Mime-Version: 1.0 1153 Content-Type: text/plain; charset="UTF-8" 1154 Content-Transfer-Encoding: 8bit 1155 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 1156 Downgraded-From: =?UTF-8?Q?DISPLAY-local?= 1157 =?UTF-8?Q?> 1158 From: =?UTF-8?Q?DISPLAY-local?= 1159 To: =?UTF-8?Q?DISPLAY-remote1?= 1160 Date: DATE 1162 MAIL_BODY 1164 Figure 16: Downgraded message (example 2) 1166 Authors' Addresses 1168 Yoshiro YONEYA (editor) 1169 JPRS 1170 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 1171 Chiyoda-ku, Tokyo 101-0065 1172 Japan 1174 Phone: +81 3 5215 8451 1175 Email: yone@jprs.co.jp 1177 Kazunori Fujiwara (editor) 1178 JPRS 1179 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 1180 Chiyoda-ku, Tokyo 101-0065 1181 Japan 1183 Phone: +81 3 5215 8451 1184 Email: fujiwara@jprs.co.jp 1186 Full Copyright Statement 1188 Copyright (C) The IETF Trust (2007). 1190 This document is subject to the rights, licenses and restrictions 1191 contained in BCP 78, and except as set forth therein, the authors 1192 retain all their rights. 1194 This document and the information contained herein are provided on an 1195 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1196 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1197 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1198 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1199 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1200 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1202 Intellectual Property 1204 The IETF takes no position regarding the validity or scope of any 1205 Intellectual Property Rights or other rights that might be claimed to 1206 pertain to the implementation or use of the technology described in 1207 this document or the extent to which any license under such rights 1208 might or might not be available; nor does it represent that it has 1209 made any independent effort to identify any such rights. Information 1210 on the procedures with respect to rights in RFC documents can be 1211 found in BCP 78 and BCP 79. 1213 Copies of IPR disclosures made to the IETF Secretariat and any 1214 assurances of licenses to be made available, or the result of an 1215 attempt made to obtain a general license or permission for the use of 1216 such proprietary rights by implementers or users of this 1217 specification can be obtained from the IETF on-line IPR repository at 1218 http://www.ietf.org/ipr. 1220 The IETF invites any interested party to bring to its attention any 1221 copyrights, patents or patent applications, or other proprietary 1222 rights that may cover technology that may be required to implement 1223 this standard. Please address the information to the IETF at 1224 ietf-ipr@ietf.org. 1226 Acknowledgment 1228 Funding for the RFC Editor function is provided by the IETF 1229 Administrative Support Activity (IASA).