idnits 2.17.1 draft-ietf-eai-rfc5335bis-12.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 draft header indicates that this document obsoletes RFC5335, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5322, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2045, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2045, updated by this document, for RFC5378 checks: 1994-06-16) -- 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 (September 18, 2011) is 4603 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) == Missing Reference: 'RFC2821' is mentioned on line 417, but not defined ** Obsolete undefined reference: RFC 2821 (Obsoleted by RFC 5321) == Missing Reference: 'RFC2822' is mentioned on line 417, but not defined ** Obsolete undefined reference: RFC 2822 (Obsoleted by RFC 5322) == Missing Reference: 'RFC5504' is mentioned on line 421, but not defined ** Obsolete undefined reference: RFC 5504 (Obsoleted by RFC 6530) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' == Outdated reference: A later version (-12) exists of draft-ietf-eai-frmwrk-4952bis-10 == Outdated reference: A later version (-16) exists of draft-ietf-eai-rfc5336bis-07 -- Possible downref: Non-RFC (?) normative reference: ref. 'NFC' ** Downref: Normative reference to an Informational RFC: RFC 5598 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 A. Yang 3 (EAI) TWNIC 4 Internet-Draft S. Steele 5 Obsoletes: 5335 (if approved) Microsoft 6 Updates: 2045,5322 (if approved) N. Freed 7 Intended status: Standards Track Oracle 8 Expires: March 21, 2012 September 18, 2011 10 Internationalized Email Headers 11 draft-ietf-eai-rfc5335bis-12 13 Abstract 15 Internet mail was originally limited to 7-bit ASCII. MIME added 16 support for the use of 8-bit character sets in body parts, and also 17 defined an encoded-word construct so other character sets could be 18 used in certain header field values. But full internationalization 19 of electronic mail requires additional enhancements to allow the use 20 of Unicode, including characters outside the ASCII repertoire, in 21 mail addresses as well as direct use of Unicode in header fields like 22 From:, To:, and Subject:, without requiring the use of complex 23 encoded-word constructs. This document specifies an enhancement to 24 the Internet Message Format that allows use of Unicode in mail 25 addresses and most header field content. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 21, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology Used In This Specification . . . . . . . . . . . . 3 63 3. Changes to Message Header Fields . . . . . . . . . . . . . . . 4 64 3.1. UTF-8 Syntax and Normalization . . . . . . . . . . . . . . 4 65 3.2. Syntax Extensions to RFC 5322 . . . . . . . . . . . . . . 5 66 3.3. Use of 8-bit UTF-8 in Message-Ids . . . . . . . . . . . . 5 67 3.4. Effects on Line Length Limits . . . . . . . . . . . . . . 5 68 3.5. Changes to MIME Message Type Encoding Restrictions . . . . 6 69 3.6. Use of MIME Encoded-Words . . . . . . . . . . . . . . . . 6 70 3.7. The Message/global Media Type . . . . . . . . . . . . . . 6 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 74 7. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7.1. draft-ietf-eai-rfc5335bis-00 . . . . . . . . . . . . . . . 9 76 7.2. draft-ietf-eai-rfc5335bis-01 . . . . . . . . . . . . . . . 10 77 7.3. draft-ietf-eai-rfc5335bis-02 . . . . . . . . . . . . . . . 10 78 7.4. draft-ietf-eai-rfc5335bis-03 . . . . . . . . . . . . . . . 10 79 7.5. draft-ietf-eai-rfc5335bis-04 . . . . . . . . . . . . . . . 10 80 7.6. draft-ietf-eai-rfc5335bis-05 . . . . . . . . . . . . . . . 10 81 7.7. draft-ietf-eai-rfc5335bis-06 . . . . . . . . . . . . . . . 10 82 7.8. draft-ietf-eai-rfc5335bis-07 . . . . . . . . . . . . . . . 10 83 7.9. draft-ietf-eai-rfc5335bis-09 . . . . . . . . . . . . . . . 10 84 7.10. draft-ietf-eai-rfc5335bis-10 . . . . . . . . . . . . . . . 11 85 7.11. draft-ietf-eai-rfc5335bis-11 . . . . . . . . . . . . . . . 11 86 7.12. draft-ietf-eai-rfc5335bis-12 . . . . . . . . . . . . . . . 11 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 89 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 91 1. Introduction 93 Internet mail distinguishes a message from its transport and further 94 divides a message between a header and a body [RFC5598]. Internet 95 mail header field values contain a variety of strings that are 96 intended to be user-visible. The range of supported characters for 97 these strings was originally limited to 7-bit [ASCII]. MIME 98 [RFC2045] [RFC2046] [RFC2047] provides the ability to use additional 99 character sets, but this support is limited to body part data and to 100 special encoded-word constructs that were only allowed in a limited 101 number of places in header field values. 103 Globalization of the Internet requires support of the much larger set 104 of characters provided by Unicode [RFC5198] in both mail addresses 105 and most header field values. Additionally, complex encoding schemes 106 like encoded-words introduce inefficiencies as well as significant 107 opportunities for processing errors. And finally, native support for 108 the UTF-8 charset is now available on most systems. Hence it is 109 strongly desirable for Internet mail to support UTF-8 [RFC3629] 110 directly. 112 This document specifies an enhancement to the Internet Message Format 113 [RFC5322] and to MIME that permits the direct use of UTF-8, rather 114 than only ASCII, in header field values, including mail addresses. A 115 new media type, message/global, is defined for messages that use this 116 extended format. This specification also lifts the MIME restriction 117 on having non-identity content-transfer-encodings on any subtype of 118 the message top-level type so that message/global parts can be safely 119 transmitted across existing mail infrastructure. 121 This specification is based on a model of native, end-to-end support 122 for UTF-8, which depends on having an "8-bit clean" environment 123 assured by the transport system. Support for carriage across legacy, 124 7-bit infrastructure and for processing by 7-bit receivers requires 125 additional mechanisms that are not provided by these specifications. 127 2. Terminology Used In This Specification 129 A plain ASCII string is fully compatible with [RFC5321] and 130 [RFC5322]. In this document, non-ASCII strings are UTF-8 strings if 131 they are in header field values which contain at least one (see Section 3.1). 134 Unless otherwise noted, all terms used here are defined in [RFC5321], 135 [RFC5322], [I-D.ietf-eai-frmwrk-4952bis], or 136 [I-D.ietf-eai-rfc5336bis]. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 The term "8-bit" means octets are present in the data with values 143 above 0x7F. 145 3. Changes to Message Header Fields 147 To permit Unicode characters in field values, the header definition 148 in [RFC5322] is extended to support the new format. The following 149 sections specify the necessary changes to RFC 5322's ABNF. 151 The syntax rules not mentioned below remain defined as in [RFC5322]. 153 Note that this protocol does not change RFC 5322 rules for defining 154 header field names. The bodies of header fields are allowed to 155 contain Unicode characters, but the header field names themselves 156 must contain only ASCII characters. 158 Also note that messages in this format require the use of the 159 &UTF8SMTPbis; extension [I-D.ietf-eai-rfc5336bis] to be transferred 160 via SMTP. 162 3.1. UTF-8 Syntax and Normalization 164 UTF-8 characters can be defined in terms of octets using the 165 following ABNF [RFC5234], taken from [RFC3629]: 167 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 169 UTF8-2 = 171 UTF8-3 = 173 UTF8-4 = 175 See [RFC5198] for a discussion of Unicode normalization; 176 normalization form [NFC] SHOULD be used. Actually, if one is going 177 to do internationalization properly, one of the most often-cited 178 goals is to permit people to spell their names correctly. Since many 179 mailbox local parts reflect personal names, that principle applies to 180 mailboxes as well. The NFKC normalization form SHOULD NOT be used 181 because it may lose information that is needed to correctly spell 182 some names in some unusual circumstances. 184 3.2. Syntax Extensions to RFC 5322 186 The following rules extend the ABNF syntax defined in [RFC5322] and 187 [RFC5234] in order to allow UTF-8 content. 189 VCHAR =/ UTF8-non-ascii 191 ctext =/ UTF8-non-ascii 193 atext =/ UTF8-non-ascii 195 qtext =/ UTF8-non-ascii 197 text =/ UTF8-non-ascii 198 ; note that this upgrades the body to UTF-8 200 dtext =/ UTF8-non-ascii 202 The preceding changes mean that the following constructs now allow 203 UTF-8: 205 1. Unstructured text, used in header fields like Subject: or 206 Content-description:. 208 2. Any construct that uses atoms, including but not limited to the 209 local parts of addresses and message-ids. This includes 210 addresses in the "for" clauses of Received: header fields. 212 3. Quoted strings. 214 4. Domains. 216 Note that header field names are not on this list; these are still 217 restricted to ASCII. 219 3.3. Use of 8-bit UTF-8 in Message-Ids 221 Implementers of message-id generation algorithms MAY prefer to 222 restrain their output to ASCII since that has some advantages, such 223 as when constructing References fields in mailing-list threads where 224 some senders use EAI and others not. 226 3.4. Effects on Line Length Limits 228 Section 2.1.1 of [RFC5322] limits lines to 998 characters and 229 recommends that the lines be restricted to only 78 characters. This 230 specification changes the former limit to 988 octets. (Note that in 231 ASCII octets and characters are effectively the same but this is not 232 true in UTF-8.) The 78 character limit remains defined in terms of 233 characters, not octets, since it is intended to address display width 234 issues, not line length issues. 236 3.5. Changes to MIME Message Type Encoding Restrictions 238 This specification updates Section 6.4 of [RFC2045]. [RFC2045] 239 prohibits applying a content-transfer-encoding to any subtypes of 240 "message/". This specification relaxes that rule -- it allows newly 241 defined MIME types to permit content-transfer-encoding, and it allows 242 content-transfer-encoding for message/global (see Section 3.7). 244 Background: Normally, transfer of message/global will be done in 245 8-bit-clean channels, and body parts will have "identity" encodings, 246 that is, no decoding is necessary. 248 But in the case where a message containing a message/global is 249 downgraded from 8-bit to 7-bit as described in [RFC6152], an encoding 250 might have to be applied to the message; if the message travels 251 multiple times between a 7-bit environment and an environment 252 implementing these extensions, multiple levels of encoding may occur. 253 This is expected to be rarely seen in practice, and the potential 254 complexity of other ways of dealing with the issue are thought to be 255 larger than the complexity of allowing nested encodings where 256 necessary. 258 3.6. Use of MIME Encoded-Words 260 The MIME encoded-words facility [RFC2047] provides the ability to 261 place non-ASCII text, but only in a subset of the places allowed by 262 this extension. Additionally, encoded-words are substantially more 263 complex since they allow the use of arbitrary charsets. Accordingly, 264 encoded-words SHOULD NOT be used when generating header fields for 265 messages employing this extension. Agents MAY, when incorporating 266 material from another message, convert encoded-word use to direct use 267 of UTF-8. 269 Note that care must be taken when decoding encoded-words because the 270 results after replacing an encoded-word with its decoded equivalent 271 in UTF-8 may be syntactically invalid. Processors that elect to 272 decode encoded-words MUST NOT generate syntactically invalid fields. 274 3.7. The Message/global Media Type 276 Internationalized messages in this format MUST only be transmitted as 277 authorized by [I-D.ietf-eai-rfc5336bis] or within a non-SMTP 278 environment that supports these messages. A message is a "message/ 279 global message" if: 281 o it contains 8-bit UTF-8 header values as specified in this 282 document, or 284 o it contains 8-bit UTF-8 values in the header fields of body parts. 286 The content of a message/global part is otherwise identical to that 287 of a message/rfc822 part. 289 If this type is sent to a 7-bit-only system, it has to have an 290 appropriate content-transfer-encoding applied. (Note that a system 291 compliant with MIME that doesn't recognize message/global is supposed 292 to treat it as "application/octet-stream" as described in Section 293 5.2.4 of [RFC2046].) 295 Type name: message 297 Subtype name: global 299 Required parameters: none 301 Optional parameters: none 303 Encoding considerations: Any content-transfer-encoding is permitted. 304 The 8-bit or binary content-transfer-encodings are recommended 305 where permitted. 307 Security considerations: See Section 4. 309 Interoperability considerations: This media type provides 310 functionality similar to the message/rfc822 content type for email 311 messages with international email headers. When there is a need 312 to embed or return such content in another message, there is 313 generally an option to use this media type and leave the content 314 unchanged or down-convert the content to message/rfc822. Both of 315 these choices will interoperate with the installed base, but with 316 different properties. Systems unaware of internationalized 317 headers will typically treat a message/global body part as an 318 unknown attachment, while they will understand the structure of a 319 message/rfc822. However, systems that understand message/global 320 will provide functionality superior to the result of a down- 321 conversion to message/rfc822. The most interoperable choice 322 depends on the deployed software. 324 Published specification: RFC XXXX 326 Applications that use this media type: SMTP servers and email 327 clients that support multipart/report generation or parsing. 328 Email clients that forward messages with international headers as 329 attachments. 331 Additional information: 333 Magic number(s): none 335 File extension(s): The extension ".u8msg" is suggested. 337 Macintosh file type code(s): A uniform type identifier (UTI) of 338 "public.utf8-email-message" is suggested. This conforms to 339 "public.message" and "public.composite-content", but does not 340 necessarily conform to "public.utf8-plain-text". 342 Person & email address to contact for further information: See the 343 Author's Address section of this document. 345 Intended usage: COMMON 347 Restrictions on usage: This is a structured media type that embeds 348 other MIME media types. The 8-bit or binary content-transfer- 349 encoding SHOULD be used unless this media type is sent over a 350 7-bit-only transport. 352 Author: See the Author's Address section of this document. 354 Change controller: IETF Standards Process 356 4. Security Considerations 358 Because UTF-8 often requires several octets to encode a single 359 character, internationalization may cause header field values in 360 general and mail addresses in particular to become longer. As 361 specified in [RFC5322], each line of characters MUST be no more than 362 998 octets, excluding the CRLF. On the other hand, MDA (Mail 363 Delivery Agent) processes that parse, store, or handle email 364 addresses or local parts must take extra care not to overflow 365 buffers, truncate addresses, or exceed storage allotments. Also, 366 they must take care, when comparing, to use the entire lengths of the 367 addresses. 369 There are lots of ways to use UTF-8 to represent something equivalent 370 or similar to a particular displayed character or group of 371 characters; see the security considerations in [RFC3629] for details 372 on the problems this can cause. The normalization process is 373 described in Section 3.1 is recommended to minimize these issues. 375 The security impact of UTF-8 headers on email signature systems such 376 as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is 377 discussed in [I-D.ietf-eai-frmwrk-4952bis], Section 14. 379 If a user has a non-ASCII mailbox address and an ASCII mailbox 380 address, a digital certificate that identifies that user might have 381 both addresses in the identity. Having multiple email addresses as 382 identities in a single certificate is already supported in PKIX 383 (Public Key Infrastructure for X.509 Certificates) [RFC5280] and 384 OpenPGP [RFC3156], but there may be user interface issues associated 385 with the introduction of UTF-8 into addresses in this context. 387 5. IANA Considerations 389 IANA is requested to update the registration of the message/global 390 MIME type using the registration form contained in Section 3.7. 392 6. Acknowledgements 394 This document incorporates many ideas first described in Internet- 395 Draft form by Paul Hoffman, although many details have changed from 396 that earlier work. 398 The author especially thanks Jeff Yeh for his efforts and 399 contributions on editing previous versions. 401 Most of the content of this document was provided by John C Klensin 402 and Dave Crocker. Significant comments and suggestions were received 403 from Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, 404 Chris Newman, Kristin Hubner, Yangwoo Ko, Yoshiro Yoneya, and other 405 members of the JET team (Joint Engineering Team) and were 406 incorporated into the document. The editors wish to sincerely thank 407 them all for their contributions. 409 7. Edit history 411 [[RFC Editor: please remove this section before publishing.]] 413 7.1. draft-ietf-eai-rfc5335bis-00 415 1. Applied Errata suggested by Alfred Hoenes. 417 2. Adjust [RFC2821] and [RFC2822] to [RFC5321] and [RFC5322]. 419 3. Abrogate in ABNF of . 421 4. Revoke [RFC5504] from this document. 423 5. Upgrade some references from I-Ds to RFC. 425 7.2. draft-ietf-eai-rfc5335bis-01 427 1. Author name revised. 429 7.3. draft-ietf-eai-rfc5335bis-02 431 1. ABNF revised. 433 7.4. draft-ietf-eai-rfc5335bis-03 435 1. Fix typos 437 2. ABNF revised 439 3. Improve sentence 441 7.5. draft-ietf-eai-rfc5335bis-04 443 1. improve sentences and ABNF revised based on AD and Co-chairs 445 7.6. draft-ietf-eai-rfc5335bis-05 447 1. ABNF revised based on AD comments 449 7.7. draft-ietf-eai-rfc5335bis-06 451 1. ABNF revised 453 2. improve Section 5 455 7.8. draft-ietf-eai-rfc5335bis-07 457 1. Minor ABNF revised in Section 3.2 459 2. improve Section 5 461 7.9. draft-ietf-eai-rfc5335bis-09 463 Version -08 was posted in error and withdrawn. Version 09 is is 464 identical to version 07 except for a date change, addition of this 465 note, and some vertical spacing compression on this page. 467 7.10. draft-ietf-eai-rfc5335bis-10 469 1. Add appendix and overview of changes 471 2. Replace polls result in Abstract and Section 1 473 3. Minor Sentence modification 475 7.11. draft-ietf-eai-rfc5335bis-11 477 1. Major rewrite of entire document to incorporate Dave Crocker's 478 simplified ABNF. 480 2. The document has intentionally been refocused on implementors 481 wishing to adapt their software to support EAI, so much of the 482 explanatory and historical text has been removed. (Some of it 483 may be reintroduced later as an appendix. 485 7.12. draft-ietf-eai-rfc5335bis-12 487 1. Added a section on the handling of MIME encoded-words. 489 2. Updated the security considerations to refer to the more complete 490 discussion in RFC 3629. 492 3. Added a section on the effects on line length limits. 494 4. Removed the syntax restriction on the use of 8-bit UTF-8 in 495 message-ids. 497 5. Added text recommending that 8-bit UTF-8 be avoided in message- 498 ids. 500 8. References 502 8.1. Normative References 504 [ASCII] "Coded Character Set -- 7-bit American 505 Standard Code for Information 506 Interchange", ANSI X3.4, 1986. 508 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and 509 Framework for Internationalized 510 Email", 511 draft-ietf-eai-frmwrk-4952bis-10 (work 512 in progress), September 2010. 514 [I-D.ietf-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension 515 for Internationalized Email Address", 516 draft-ietf-eai-rfc5336bis-07 (work in 517 progress), December 2010. 519 [NFC] Davis, M. and K. Whistler, "Unicode 520 Standard Annex #15: Unicode 521 Normalization Forms", September 2010, 522 . 525 [RFC2119] Bradner, S., "Key words for use in 526 RFCs to Indicate Requirement Levels", 527 BCP 14, RFC 2119, March 1997. 529 [RFC3629] Yergeau, F., "UTF-8, a transformation 530 format of ISO 10646", STD 63, 531 RFC 3629, November 2003. 533 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode 534 Format for Network Interchange", 535 RFC 5198, March 2008. 537 [RFC5234] Crocker, D. and P. Overell, "Augmented 538 BNF for Syntax Specifications: ABNF", 539 STD 68, RFC 5234, January 2008. 541 [RFC5321] Klensin, J., "Simple Mail Transfer 542 Protocol", RFC 5321, October 2008. 544 [RFC5322] Resnick, P., Ed., "Internet Message 545 Format", RFC 5322, October 2008. 547 [RFC5598] Crocker, D., "Internet Mail 548 Architecture", RFC 5598, July 2009. 550 8.2. Informative References 552 [RFC2045] Freed, N. and N. Borenstein, 553 "Multipurpose Internet Mail Extensions 554 (MIME) Part One: Format of Internet 555 Message Bodies", RFC 2045, 556 November 1996. 558 [RFC2046] Freed, N. and N. Borenstein, 559 "Multipurpose Internet Mail Extensions 560 (MIME) Part Two: Media Types", 561 RFC 2046, November 1996. 563 [RFC2047] Moore, K., "MIME (Multipurpose 564 Internet Mail Extensions) Part Three: 565 Message Header Extensions for Non- 566 ASCII Text", RFC 2047, November 1996. 568 [RFC3156] Elkins, M., Del Torto, D., Levien, R., 569 and T. Roessler, "MIME Security with 570 OpenPGP", RFC 3156, August 2001. 572 [RFC5280] Cooper, D., Santesson, S., Farrell, 573 S., Boeyen, S., Housley, R., and W. 574 Polk, "Internet X.509 Public Key 575 Infrastructure Certificate and 576 Certificate Revocation List (CRL) 577 Profile", RFC 5280, May 2008. 579 [RFC6152] Klensin, J., Freed, N., Rose, M., and 580 D. Crocker, "SMTP Service Extension 581 for 8-bit MIME Transport", STD 71, 582 RFC 6152, March 2011. 584 Authors' Addresses 586 Abel Yang 587 TWNIC 588 4F-2, No. 9, Sec 2, Roosevelt Rd. 589 Taipei, 100 590 Taiwan 592 Phone: +886 2 23411313 ext 505 593 EMail: abelyang@twnic.net.tw 595 Shawn Steele 596 Microsoft 598 EMail: Shawn.Steele@microsoft.com 600 Ned Freed 601 Oracle 602 800 Royal Oaks 603 Monrovia, CA 91016-6347 604 USA 606 EMail: ned+ietf@mrochek.com