idnits 2.17.1 draft-ietf-eai-email-clients-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6530]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 7, 2012) is 4247 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-eai-5738bis-09 == Outdated reference: A later version (-08) exists of draft-ietf-eai-popimap-downgrade-07 == Outdated reference: A later version (-08) exists of draft-ietf-eai-rfc5721bis-07 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Email Address Internationalization E. Dainow 3 (EAI) Afilias 4 Internet-Draft K. Fujiwara 5 Intended status: Informational JPRS 6 Expires: March 11, 2013 September 7, 2012 8 Guidelines for Internationalized Email Clients 9 draft-ietf-eai-email-clients-01 11 Abstract 13 This document provides some guidelines for email clients that support 14 Email Address Internationalization (EAI) as outlined in [RFC6530]. A 15 number of interoperability cases between different versions of email 16 components are reviewed. Recommendations are made to improve 17 interoperability and usability and to minimize discrepancies between 18 the display of composed and received email in different language 19 environments. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 11, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Conventions used in this document . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Interoperability . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Interoperability Scenarios . . . . . . . . . . . . . . . . 5 60 5. Compatibility Support . . . . . . . . . . . . . . . . . . . . 6 61 5.1. Address Book . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.2. Message Mode . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.3. Message Format . . . . . . . . . . . . . . . . . . . . . . 8 64 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 8 65 5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.6. Limitations . . . . . . . . . . . . . . . . . . . . . . . 10 67 6. Mailbox Integration . . . . . . . . . . . . . . . . . . . . . 12 68 7. Character Encoding . . . . . . . . . . . . . . . . . . . . . . 12 69 8. Normalization . . . . . . . . . . . . . . . . . . . . . . . . 13 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 73 12. Normative References . . . . . . . . . . . . . . . . . . . . . 14 75 1. Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2. Introduction 83 [RFC6530] Overview and Framework for Internationalized Email 84 describes changes to electronic mail (email) to fully support 85 internationalized characters. The fundamental change is to remove 86 the ASCII only restriction on email addresses and allow them to 87 contain UTF-8 characters. Additional documents provide detailed 88 specifications for the extensions required to email headers [RFC6532] 89 and to the protocols SMTP [RFC6531], POP [I-D.ietf-eai-rfc5721bis] 90 and IMAP [I-D.ietf-eai-5738bis]. 92 This document provides guidelines for email clients that support 93 these specifications for Email Address Internationalization (EAI). 94 It does not introduce any protocol extensions that are not defined in 95 the above documents. It highlights the extensions that are important 96 to the design and implementation of email clients and makes a number 97 of recommendations intended to improve interoperability and 98 usability. 100 3. Terminology 102 A number of different acronyms are typically used to describe the 103 major functional components of email. 105 Mail User Agent (MUA) 106 Message Submission Agent (MSA) 107 Message Transfer Agent (MTA) 108 Message Delivery Agent (MDA) 109 Message Store (MS) 111 The architecture of modern email systems can range from simple, with 112 all components running on one server, to very complex, with 113 components being distributed across multiple, geographically 114 dispersed machines. Nevertheless, the above terminology is generally 115 sufficient to represent different architectures from a functional 116 point of view. For a comprehensive description of email architecture 117 see [RFC5598]. 119 sender -> MUA -> MSA -> MTA 120 ... 121 MTA -> MDA -> MS -> PIF -> MUA -> recipient 123 In this context, an "Email Client" is an MUA that has an interface to 124 an MSA to send email and an interface to the MS to retrieve email. 125 The interface to retrieve mail (PIF) is a POP or IMAP server or 126 direct access to the File system. The MUA also provides a User 127 Interface (UI) that allows an end user to read (display) and write 128 (compose) their email. 130 A common email architecture includes the MSA function within the MTA. 131 An improved architecture that better addresses security concerns is a 132 separate MSA component as shown here [RFC6409], [RFC5068]. 134 "SMTPUTF8" is used to indicate email address internationalization as 135 specified by [RFC6530] and related documents. 137 "ASCII" refers to the strict 7-bit ASCII character set 138 [ANSI.X3-4.1968]. 140 "UTF-8", Unicode Transformation Format/8-bit is a character encoding 141 scheme that can represent any character in the Unicode standard 142 [RFC3629]. It contains ASCII as a subset. 144 "message/global" is an email message that contains UTF-8 characters 145 beyond 7-bit ASCII in message headers and/or body parts [RFC6532]. 147 "message/rfc822" is an email message that contains only 7 bit ASCII 148 and does not use any SMTPUTF8 extensions. Note that the original 149 message (as composed by the user) may contain non-ASCII characters 150 that have been encoded into ASCII using IDNA [RFC5890], MIME body 151 encoding [RFC2045] or MIME header encoding [RFC2047]. 153 4. Interoperability 155 Internationalized Email is not compatible with legacy email systems, 156 those based on prior Internet email standards [RFC5321], [RFC5322]. 157 Non-ASCII email addresses cannot be submitted in legacy SMTP commands 158 like MAIL FROM or RCPT TO. In addition the Internationalized Email 159 standard does not include a method to "downgrade" message/global to 160 message/rfc822. 162 An Internationalized message cannot be transmitted via SMTP if the 163 receiving MTA does not announce SMTPUTF8 in response to EHLO. There 164 are two failure cases that an email client may have to handle 165 described in Section 3.2 of [RFC6531]. 167 a) If the client is submitting a message to an MSA that does not 168 support SMTPUTF8, the message will be rejected. 170 b) If the MSA does support SMTPUTF8 but a downstream MTA does not, 171 then the mail will bounce. That is, a delivery status notification 172 (DSN) that the mail could not be delivered will be sent back to the 173 sender. 175 Incompatibility between Internationalized email and legacy systems is 176 expected to be important initially during a transition period but 177 less important over time as more email systems upgrade to support the 178 SMTPUTF8 extensions. To the extent that this incompatibility is 179 deemed important at the time an implementation is undertaken, the 180 email client should provide methods to prevent or at least minimize 181 these failures. 183 4.1. Interoperability Scenarios 185 The following scenarios cover the different cases of sending mail 186 from an Internationalized server to a legacy server. 188 'I' indicates an Internationalized address (a non-ASCII address on an 189 Internationalized mail server). 191 'IA' indicates an ASCII address on an Internationalized server. 193 'LA' indicates an address on a Legacy mail server, which must be 194 ASCII. 196 Case 1. The simple compatibility case 198 From: IA1 (or LA1) 199 To: LA2 200 Subject: ... 201 Body ... 203 The message will be successfully sent as long as the email client 204 sends message/rfc822 rather than message/global. 206 Case 2. The simple incompatibility case 208 From: I1 209 To: LA2 210 Subject: ... 211 Body ... 213 The message will be rejected by the MSA or will bounce from a 214 downstream SMTP server. 216 If user I1 also has an ASCII email address IA1 or LA1, there may be a 217 simple workaround. If the email client supports multiple email 218 accounts, the user just has to switch the From address to an ASCII 219 address and it becomes Case 1. 221 Case 3. The general incompatibility cases 223 The general case is a mix of Internationalized and legacy addresses. 224 While many combinations are possible, the two cases below essentially 225 cover all possibilities. 227 From: I1 228 To: LA2 229 Cc: I3 231 The message will be sent to I3 but it will bounce from LA2. 233 Switching the From address to an ASCII address as in Case 2 is not a 234 solution, as the following case demonstrates. 236 From: IA1 (or LA1) 237 To: LA2 238 Cc: I3 240 This message will bounce from LA2 since the address in the Cc header 241 cannot be transmitted to a legacy server. 243 In these cases, users will likely send the message twice in order to 244 reach all intended recipients. First, to the original list and then 245 using an ASCII address to the bounced recipients. 247 If users know beforehand which addresses are on legacy servers, they 248 can avoid bounced messages by removing those addresses, but they 249 still have to send a second email to reach recipients that were 250 removed. 252 5. Compatibility Support 254 An email client can provide support to minimize the incompatibility 255 problems outlined in Section 4. There may be several ways to do 256 this. Following are guidelines on some of the ways that this can be 257 accomplished. 259 At the very least, to provide basic compatibility between 260 Internationalized and legacy systems, if all email addresses in the 261 SMTP envelope and the message headers are ASCII, then a message/ 262 rfc822 should be sent (Case 1 above). 264 For Case 2, the email client should support multiple email accounts 265 and allow the user to switch the From address at any time during 266 composition of the message. 268 For Case 3, several mechanisms may be required to provide 269 compatibility support. These are outlined in the following sub- 270 sections. 272 5.1. Address Book 274 Each contact in the address book should be able to have several email 275 addresses, each of which is configured to be either an 276 Internationalized or a Legacy address. 278 The user may not necessarily know if an ASCII address they enter in 279 their address book is on a legacy server or not. If it is configured 280 as an Internationalized address and that turns out to be wrong, then 281 email sent to that contact may bounce. The user can then re- 282 configure the address as Legacy so the email client can provide 283 warnings of a possible bounce on subsequent messages. 285 5.2. Message Mode 287 Message composition should have "Message Mode" option to specify 288 "Internationalized Mode" or "Legacy Mode". 290 If the type of each address in the headers does not conform to the 291 message mode, then the user is given a warning about those addresses 292 that don't match the mode. In a graphical user interface this might 293 be done by setting such addresses to a different color such as red. 295 The user would typically first change the message mode to see if the 296 warnings disappear. 298 When the mode is switched, the email client switches addresses in 299 message header fields to match the mode, selecting from the list of 300 addresses in each contact. 302 There are cases where both modes provide warnings (see Example 5 303 below). In these cases, the user can remove the addresses that don't 304 conform to the mode. 306 For Internationalized mode, the user has an additional option to send 307 the message anyway, without removing flagged addresses. They would 308 have to handle bounced messages from Legacy servers later. The 309 option to send anyway cannot be provided in Legacy mode, as it is not 310 possible to compose a message/rfc822 if any sender or recipient 311 address is not ASCII. 313 Where both modes provide warnings, users will likely want to send the 314 message in each mode in order to reach all recipients. The email 315 client should make it easy to do this. There are many possible 316 designs to accomplish this. The following is one example. 318 An option is provided when composing email to add a second message 319 header section in the other mode that allows the user to move 320 addresses between sections. This is in addition to making individual 321 changes to address headers as in normal email composition. The 322 Subject and Body are common so the user can compose a single message 323 but have it sent in the two different modes to different recipients. 325 Following is an example of this for Case 3 above. 327 --------------------------------------------- 328 Legacy Internationalized 329 From: IA1 From: I1 330 To: LA2 <---> To: 331 Cc: <---> Cc: I3 332 --------------------------------------------- 333 Subject: ... 334 Body: ... 335 --------------------------------------------- 337 5.3. Message Format 339 In Internationalized Mode, mail should be sent as message/global. 340 The aim of Internationalized Email is 8 bit clean messages using 341 UTF-8 encoding to represent Unicode characters in header fields and 342 the message body. 344 In Legacy Mode, mail must be sent as message/rfc822. This may 345 include non-ASCII characters that are encoded into ASCII using MIME 346 body encoding [RFC2045] or MIME header encoding [RFC2047]. Any 347 encoding should be based on UTF-8. In the interest of 348 interoperability, charsets other than UTF-8 are prohibited in mail 349 addresses and message headers described in Section 7.1 of [RFC6530]. 351 5.4. Error Handling 353 If a message is rejected by the MSA with a response code that 354 indicates incompatibility with legacy email described in Section 3.2 355 of [RFC6531], the compose window should be kept open so that the user 356 can make changes and retry. The email client should provide guidance 357 to the user about switching the Message Mode, reconfiguring the type 358 of an address in the address book or adding an ASCII legacy address 359 for a contact in the address book. 361 Similarly, if a message bounces, the email client could parse the 362 delivery status notifications and message disposition notifications 363 [RFC6533] to determine if the failure was a compatibility problem and 364 if so, which addresses caused the problem. 366 5.5. Examples 368 The following examples illustrate most of the different possible 369 cases. 371 Suppose the user (Sender) has set up the following email account 372 containing two email addresses, an Internationalized address and an 373 ASCII address on an Internationalized server. 375 Sender: I0, IA0 377 Examples are not provided for the following cases: 379 a) Sender: I0, LA0 381 If the Sender has both Internationalized and Legacy addresses, then 382 this is equivalent to the above. 384 b) Sender: I0 386 If the Sender has only Internationalized addresses, then it cannot 387 send Legacy messages. The email client cannot provide an option to 388 switch the Message Mode to Legacy. 390 c) Sender: LA0 392 If the Sender has only accounts on Legacy servers, then it cannot 393 send Internationalized messages. The email client cannot provide an 394 option to switch the Message Mode to Internationalized. 396 The address book has the following contacts with email addresses. 398 Contact1: I1, IA1 399 Contact2: I2 400 Contact3: IA3 401 Contact4: LA4 403 Example 1: 405 From: Sender 406 To: Contact1 407 CC: Contact2 409 This message can be sent in Internationalized mode. 411 In Legacy mode the email client would flag Contact2, who does not 412 have an ASCII address. 414 Example 2: 416 From: Sender 417 To: Contact1 418 CC: Contact3 420 This message can be sent in either Internationalized or Legacy mode. 422 Example 3: 424 From: Sender 425 To: Contact1 426 CC: Contact4 428 This message cannot be sent in Internationalized mode. Contact4 429 would be flagged since it is not on an Internationalized server. 431 This message can be sent in Legacy mode. 433 Example 4: 435 From: Sender 436 To: Contact2 437 CC: Contact3 439 This message can be sent in either Internationalized mode or Legacy 440 mode. 442 Example 5: 444 From: Sender 445 To: Contact2 446 CC: Contact4 448 This message cannot be sent in either mode. 450 Internationalized mode would flag Contact4 which is on a Legacy 451 server. The user can remove Contact4 or use the send anyway option. 453 Legacy mode would flag Contact2 who does not have an ASCII address. 454 The user would have to remove Contact2 in order to send this message. 456 5.6. Limitations 458 In summary, the guidelines outlines in Section 4 and Section 5 will 459 provide the following compatibility solutions: 461 1. When there is an ASCII address for all contacts in the message, 462 then a single legacy compatible message can be sent to all 463 recipients. 465 2. When some contacts in the message do not have an ASCII address 466 and some have only ASCII addresses on legacy servers, then the 467 message can be split into two. One message is sent as an 468 Internationalized message to recipients on Internationalized servers. 469 The other is sent as a legacy compatible message to recipients on 470 legacy servers. 472 These guidelines have a number of limitations. 474 a) Unknown Address Types 476 Message Mode is effective only if users are fairly disciplined about 477 keeping addresses in their address book and configuring the type 478 correctly as Internationalized or Legacy. 480 When replying to an email, the message may have addresses that are 481 not in the address book. The user may also enter addresses directly 482 during message composition that are not in the address book. 484 The email client may determine by inspection that some addresses are 485 Internationalized. If an address contains any non-ASCII character, 486 then it must be Internationalized. However, an ASCII address may be 487 on either an Internationalized server or a Legacy server and there is 488 no way software can determine this automatically. 490 In such cases, it may be useful for the email client to flag unknown 491 address types in a message so that the user is not lead to believe 492 that the message will not bounce just because there were no 493 incompatibility warnings. 495 b) Address Removal 497 When email addresses are removed from a message to meet compatibility 498 requirements, recipients do not see everyone who was intended to be 499 part of the conversation. The email client can provide the address 500 of removed recipients by using an empty group. This technique is 501 described in Section 3.1.8 of [I-D.ietf-eai-popimap-downgrade]. 503 This is not an ideal solution, since replies to the message will not 504 reach everyone intended. But at least it provides the necessary 505 contact information to recipients who may be able to use other 506 methods to reply to all intended. 508 6. Mailbox Integration 510 If more than one email address is used for the sender user, emails 511 may arrive at different email accounts. There are several ways to 512 provide mailbox integration so the user is able to view all mail in 513 one location, such as a single 'Inbox' folder. 515 If integration is done on the server, through the use of aliases, 516 then the email client does not need to do anything. All mail will be 517 received at the client from one address. 519 The email client should provide mailbox integration for cases where 520 server side integration is not available and for more flexibility on 521 the part of the user. Many email clients already provide a 522 convenient way to manage multiple email accounts. 524 An option to view all mail from a group of accounts in one integrated 525 folder should also be provided. 527 7. Character Encoding 529 Email message bodies may be composed and displayed using many 530 different character encoding schemes. Numerous character encodings 531 have been developed over time in order to best represent different 532 language scripts. In recent years there has been a trend to prefer 533 Unicode as a "universal" character set and UTF-8 as the preferred 534 encoding method. 536 A good general principle to follow is to minimize character 537 conversions. This will reduce the chance that the received message 538 is displayed differently from how it was composed. Displaying 539 received mail SHOULD use the character encoding of the received mail. 541 Since older MUAs may not be able to parse UTF-8, the MUA SHOULD try 542 to reply to mail using the character encoding of the received mail. 543 This may not be possible if the sender adds new characters that 544 cannot be encoded in the original encoding. For example, if the 545 received message is encoded in ISO-2022-JP and characters in ISO- 546 8859-1 are added to the message, the text cannot be carried in ISO- 547 2022-JP and conversion to UTF-8 may be the best solution. 549 For new mail, A SMTPUTF8 compliant MUA SHOULD use UTF-8 as the 550 default encoding if the message type is global or if the envelope 551 contains non-ASCII addresses. If email clients utilize this default, 552 character conversions will be minimized and there will be less chance 553 that someone will receive mail in an unrecognized encoding. 555 If the message type is rfc822, other considerations may apply, such 556 as using the system locale/language. 558 Notwithstanding the above, there may be cases where the default does 559 not work well. There SHOULD be options for the user to reset the 560 default character encoding. There SHOULD also be options to change 561 the encoding when reading or writing individual email messages. 563 8. Normalization 565 Different sequences of UTF-8 characters may represent the same thing. 566 Normalization is a process that converts all canonically equivalent 567 sequences to a single unique form. 569 Normalization of email headers is specified in Section 3.1 of 570 [RFC6532]. The MUA SHOULD normalize all email addresses in the 571 envelope and message headers. 573 For message bodies that contain UTF-8 characters (message/global), 574 the "Net-Unicode" standardized text transmission format specified in 575 [RFC5198] SHOULD be followed. It covers both normalization and 576 control characters that may affect display of text. 578 If the MUA saves email addresses (such as in an address book), they 579 SHOULD be stored in normalized form. 581 Other normalizations may be needed in specific language environments. 582 For example, in the Japanese environment, special considerations are 583 needed for the "@" and "." symbols. Most Japanese input methods 584 convert "@" to FULLWIDTH COMMERCIAL AT (U+FF20) and "." to either 585 IDEOGRAPHIC FULL STOP (U+3002) or FILLWIDTH FULL STOP (U+FF0E). In 586 email addresses, "@" is needed to separate the local name from the 587 domain name and "." to separate domain name labels. Normalization is 588 necessary to replace FULLWIDTH COMMERCIAL AT (U+FF20) with ASCII "@", 589 IDEOGRAPHIC FULL STOP (U+3002) with ASCII "." and FILLWIDTH FULL STOP 590 (U+FF0E) with ASCII ".". 592 9. Security Considerations 594 This document does not introduce any security considerations beyond 595 those already covered by the normative references for Email Address 596 Internationalization (EAI). 598 10. IANA Considerations 600 IANA changes are covered by the normative references for Email 601 Address Internationalization (EAI). 603 11. Acknowledgments 605 12. Normative References 607 [ANSI.X3-4.1968] American National Standards 608 Institute, "USA Code for 609 Information Interchange", 610 ANSI X3.4, 1968. 612 [I-D.ietf-eai-5738bis] Resnick, P., Newman, C., and S. 613 Shen, "IMAP Support for UTF-8", 614 draft-ietf-eai-5738bis-09 (work in 615 progress), August 2012. 617 [I-D.ietf-eai-popimap-downgrade] Fujiwara, K., "Post-delivery 618 Message Downgrading for 619 Internationalized Email Messages", 620 draft-ietf-eai-popimap-downgrade-07 621 (work in progress), August 2012. 623 [I-D.ietf-eai-rfc5721bis] Gellens, R., Newman, C., Yao, J., 624 and K. Fujiwara, "POP3 Support for 625 UTF-8", 626 draft-ietf-eai-rfc5721bis-07 (work 627 in progress), July 2012. 629 [RFC2045] Freed, N. and N. Borenstein, 630 "Multipurpose Internet Mail 631 Extensions (MIME) Part One: Format 632 of Internet Message Bodies", 633 RFC 2045, November 1996. 635 [RFC2047] Moore, K., "MIME (Multipurpose 636 Internet Mail Extensions) Part 637 Three: Message Header Extensions 638 for Non-ASCII Text", RFC 2047, 639 November 1996. 641 [RFC2119] Bradner, S., "Key words for use in 642 RFCs to Indicate Requirement 643 Levels", BCP 14, RFC 2119, 644 March 1997. 646 [RFC3629] Yergeau, F., "UTF-8, a 647 transformation format of ISO 648 10646", STD 63, RFC 3629, 649 November 2003. 651 [RFC5068] Hutzler, C., Crocker, D., Resnick, 652 P., Allman, E., and T. Finch, 653 "Email Submission Operations: 654 Access and Accountability 655 Requirements", BCP 134, RFC 5068, 656 November 2007. 658 [RFC5198] Klensin, J. and M. Padlipsky, 659 "Unicode Format for Network 660 Interchange", RFC 5198, March 2008. 662 [RFC5321] Klensin, J., "Simple Mail Transfer 663 Protocol", RFC 5321, October 2008. 665 [RFC5322] Resnick, P., Ed., "Internet Message 666 Format", RFC 5322, October 2008. 668 [RFC5598] Crocker, D., "Internet Mail 669 Architecture", RFC 5598, July 2009. 671 [RFC5890] Klensin, J., "Internationalized 672 Domain Names for Applications 673 (IDNA): Definitions and Document 674 Framework", RFC 5890, August 2010. 676 [RFC6409] Gellens, R. and J. Klensin, 677 "Message Submission for Mail", 678 STD 72, RFC 6409, November 2011. 680 [RFC6530] Klensin, J. and Y. Ko, "Overview 681 and Framework for Internationalized 682 Email", RFC 6530, February 2012. 684 [RFC6531] Yao, J. and W. Mao, "SMTP Extension 685 for Internationalized Email", 686 RFC 6531, February 2012. 688 [RFC6532] Yang, A., Steele, S., and N. Freed, 689 "Internationalized Email Headers", 690 RFC 6532, February 2012. 692 [RFC6533] Hansen, T., Newman, C., and A. 693 Melnikov, "Internationalized 694 Delivery Status and Disposition 695 Notifications", RFC 6533, 696 February 2012. 698 Authors' Addresses 700 Ernie Dainow 701 Afilias Canada 702 4141 Yonge Street 703 Toronto, Ontario M2P 2A8 704 Canada 706 Phone: 707 EMail: edainow@afilias.info 709 Kazunori Fujiwara 710 Japan Registry Services Co., Ltd. 711 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 712 Chiyoda-ku, Tokyo 101-0065 713 Japan 715 Phone: +81 3 5215 8451 716 EMail: fujiwara@jprs.co.jp