idnits 2.17.1 draft-ietf-eai-5738bis-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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document obsoletes RFC5738, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2012) is 4150 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) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 2088 (Obsoleted by RFC 7888) -- Obsolete informational reference (is this intentional?): RFC 5738 (Obsoleted by RFC 6855) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Resnick, Ed. 3 Internet-Draft Qualcomm Incorporated 4 Obsoletes: RFC5738 (if approved) C. Newman, Ed. 5 Intended status: Standards Track Oracle 6 Expires: May 20, 2013 S. Shen, Ed. 7 CNNIC 8 November 16, 2012 10 IMAP Support for UTF-8 11 draft-ietf-eai-5738bis-12 13 Abstract 15 This specification extends the Internet Message Access Protocol 16 version 4rev1 (IMAP4rev1) to support UTF-8 encoded international 17 characters in user names, mail addresses and message headers. This 18 specification replaces RFC 5738. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 20, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 68 3. UTF8=ACCEPT IMAP Capability and UTF-8 in IMAP Quoted 69 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. IMAP UTF8 Append Data Extension . . . . . . . . . . . . . . . 5 71 5. LOGIN Command and UTF-8 . . . . . . . . . . . . . . . . . . . 5 72 6. UTF8=ONLY Capability . . . . . . . . . . . . . . . . . . . . . 6 73 7. Dealing With Legacy Clients . . . . . . . . . . . . . . . . . 6 74 8. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 8 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 11.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 11 81 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 This specification forms part of the Email Address 86 Internationalization protocols described in the Email Address 87 Internationalization Framework document [RFC6530]. It extends 88 IMAP4rev1 [RFC3501] to permit UTF-8 [RFC3629] in headers as described 89 in "Internationalized Email Headers" [RFC6532]. It also adds a 90 mechanism to support mailbox names using the UTF-8 charset. This 91 specification creates two new IMAP capabilities to allow servers to 92 advertise these new extensions. 94 This specification assumes that the IMAP server will be operating in 95 a fully internationalized environment, i.e., one in which all clients 96 accessing the server will be able to accept non-ASCII message header 97 fields and other information as specified in Section 3. At least 98 during a transition period, that assumption will not be realistic for 99 many environments; the issues involved are discussed in Section 7 100 below. 102 This specification replaces an earlier, experimental, approach to the 103 same problem [RFC5738]. 105 2. Conventions Used in this Document 107 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 108 in this document are to be interpreted as defined in "Key words for 109 use in RFCs to Indicate Requirement Levels" [RFC2119]. 111 The formal syntax uses the Augmented Backus-Naur Form (ABNF) 112 [RFC5234] notation. In addition, rules from IMAP4rev1 [RFC3501], 113 UTF-8 [RFC3629], "Collected Extensions to IMAP4 ABNF" [RFC4466], and 114 IMAP4 LIST Command Extensions [RFC5258] are also referenced. This 115 document assumes that the reader will have a reasonably good 116 understanding of the RFCs above. 118 In examples, "C:" and "S:" indicate lines sent by the client and 119 server, respectively. If a single "C:" or "S:" label applies to 120 multiple lines, then the line breaks between those lines are for 121 editorial clarity only and are not part of the actual protocol 122 exchange. 124 3. UTF8=ACCEPT IMAP Capability and UTF-8 in IMAP Quoted Strings 126 The "UTF8=ACCEPT" capability indicates that the server supports the 127 ability to open mailboxes containing internationalized messages with 128 SELECT and EXAMINE, and can provide UTF-8 responses to the LIST and 129 LSUB commands. This capability also affects other IMAP extensions 130 that can return mailbox names or their prefixes, such as NAMESPACE 132 [RFC2342] and ACL [RFC4314]. 134 The "UTF8=ONLY" capability described in Section 6 implies the 135 "UTF8=ACCEPT" capability. A server is said to "support UTF8=ACCEPT" 136 if it advertises either "UTF8=ACCEPT" or "UTF8=ONLY". 138 A client MUST use the "ENABLE" command (defined in [RFC5161]) with 139 the "UTF8=ACCEPT" option (defined in Section 4 below) to indicate to 140 the server that the client accepts UTF-8 in quoted-strings and 141 supports UTF8=ACCEPT extension. The "ENABLE UTF8=ACCEPT" command is 142 only valid in the authenticated state. 144 The IMAP4rev1 [RFC3501] base specification forbids the use of 8-bit 145 characters in atoms or quoted strings. Thus, a UTF-8 string can only 146 be sent as a literal. This can be inconvenient from a coding 147 standpoint, and unless the server offers IMAP4 non-synchronizing 148 literals [RFC2088], this requires an extra round trip for each UTF-8 149 string sent by the client. When the IMAP server supports 150 "UTF8=ACCEPT" it supports UTF-8 in quoted-strings with the following 151 syntax: 153 quoted =/ DQUOTE *uQUOTED-CHAR DQUOTE 154 ; QUOTED-CHAR is not modified, as it will affect 155 ; other RFC 3501 ABNF non terminal. 157 uQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4 159 UTF8-2 = 161 UTF8-3 = 163 UTF8-4 = 165 When this extended quoting mechanism is used by the client, then the 166 server MUST reject with a "BAD" response any octet sequences with the 167 high bit set that fail to comply with the formal syntax in [RFC3629]. 168 The IMAP server MUST NOT send UTF-8 in quoted strings to the client 169 unless the client has indicated support for that syntax by using the 170 "ENABLE UTF8=ACCEPT" command. 172 If the server supports "UTF8=ACCEPT", the client MAY use extended 173 quoted syntax with any IMAP argument that permits a string (including 174 astring and nstring). However, if characters outside the US-ASCII 175 repertoire are used in an inappropriate place, the results would be 176 the same as if other syntactically valid but semantically invalid 177 characters were used. Specific cases where UTF-8 characters are 178 permitted or not permitted are described in the following paragraphs. 180 All IMAP servers that support "UTF8=ACCEPT" SHOULD accept UTF-8 in 181 mailbox names, and those that also support the "Mailbox International 182 Naming Convention" described in RFC 3501, Section 5.1.3, MUST accept 183 utf8-quoted mailbox names and convert them to the appropriate 184 internal format. Mailbox names MUST comply with the Net-Unicode 185 Definition ([RFC5198], Section 2) with the specific exception that 186 they MUST NOT contain control characters (0000-001F, 0080-009F), 187 delete (007F), line separator (2028), or paragraph separator (2029). 189 Once an IMAP client has enabled UTF-8 support with the "ENABLE 190 UTF8=ACCEPT" command, it MUST NOT issue a SEARCH command that 191 contains a CHARSET specification. If an IMAP server receives such a 192 SEARCH command in that situation, it SHOULD reject the command with a 193 BAD response (due to the conflicting charset labels). 195 4. IMAP UTF8 Append Data Extension 197 If the server supports "UTF8=ACCEPT", then the server accepts UTF-8 198 headers in the APPEND command message argument. A client that sends 199 a message with UTF-8 headers to the server MUST send them using the 200 "UTF8" APPEND data extension. If the server also advertises the 201 CATENATE capability (as specified in [RFC4469]), the client can use 202 the same data extension to include such a message in a CATENATE 203 message part. The ABNF for the APPEND data extension and CATENATE 204 extension follows: 206 utf8-literal = "UTF8" SP "(" literal8 ")" 208 literal8 = 210 append-data =/ utf8-literal 212 cat-part =/ utf8-literal 214 If an IMAP server supports "UTF8=ACCEPT" and the IMAP client has not 215 issued the "ENABLE UTF8=ACCEPT" command, the server MUST reject with 216 a "NO" response an APPEND command that includes any 8-bit character 217 in message header fields. 219 5. LOGIN Command and UTF-8 221 This specification doesn't extend the IMAP LOGIN command [RFC3501] to 222 support UTF-8 usernames and passwords. Whenever a client needs to 223 use UTF-8 username/passwords, it MUST use the IMAP AUTHENTICATE 224 command which is already capable of passing UTF-8 user names and 225 credentials. 227 Although the use of the IMAP AUTHENTICATE command in this way makes 228 it syntactically legal to have a UTF-8 user name or password, there 229 is no guarantee the user provisioning system used by the IMAP server 230 will allow such identities. This is an implementation decision and 231 may depend on what identity system the IMAP server is configured to 232 use. 234 6. UTF8=ONLY Capability 236 The "UTF8=ONLY" capability indicates that the server supports 237 "UTF8=ACCEPT" (see Section 4), and also that it requires support for 238 UTF-8 from clients. In particular, this means that it will send 239 UTF-8 in quoted strings, and it will not accept the older 240 international mailbox name convention (modified UTF-7). Because 241 these are incompatible changes to IMAP, explicit server announcement 242 and client confirmation is necessary: clients MUST use the "ENABLE 243 UTF8=ACCEPT" command before using this server. A server that 244 advertises "UTF8=ONLY" will reject with a "NO [CANNOT]" response any 245 command that might require UTF-8 support and is not preceded by an 246 "ENABLE UTF8=ACCEPT" command. 248 IMAP clients that find support for a server that announces 249 "UTF8=ONLY" problematic are encouraged to at least detect the 250 announcement and provide an informative error message to the end- 251 user. 253 Because the "UTF8=ONLY" server capability includes support for 254 "UTF8=ACCEPT", the capability string will include at most one of 255 those and never both. For the client, "ENABLE UTF8=ACCEPT" is always 256 used -- never "ENABLE UTF8-ONLY". 258 7. Dealing With Legacy Clients 260 In most situations, it will be difficult or impossible for the 261 implementer or operator of an IMAP (or POP) server to know whether 262 all of the clients that might access it, or the associated mail store 263 more generally, will be able to support the facilities defined in 264 this document. In almost all cases, servers who conform to this 265 specification will have to be prepared to deal with clients that do 266 not enable the relevant capabilities. Unfortunately, there is no 267 completely satisfactory way to do so other than for systems that wish 268 to receive email that requires SMTPUTF8 capabilities to be sure that 269 all components of those systems -- including IMAP and other clients 270 selected by users -- are upgraded appropriately. 272 Choices available to the server when a message that requires SMTPUTF8 273 is encountered and the client doesn't enable UTF-8 capability include 274 hiding the problematic message(s), creating in band or out of band 275 notifications or error messages, or somehow trying to create a 276 variation on the message with the intention of providing useful 277 information to that client about what has occurred. Such variant 278 messages cannot be actual substitutes for the original message: they 279 will almost always be impossible to reply to (either at all or 280 without loss of information); the new header fields or specialized 281 constructs for server-client communication may go beyond the 282 requirements of, e.g., RFC 5322; they may consequently confuse some 283 legacy mail user agents (including IMAP clients) or otherwise may not 284 provide the expected information to users. There are also tradeoffs 285 in constructing variants of the original message between accepting 286 complexity and additional computation costs in order to try to 287 preserve as much information as possible (for example, in 288 [I-D.ietf-eai-popimap-downgrade]) and trying to minimize those costs 289 while still providing useful information (for example, in 290 [I-D.ietf-eai-simpledowngrade]). 292 Implementations that choose to do downgrading SHOULD use one of the 293 standardized algorithms, [I-D.ietf-eai-popimap-downgrade] or 294 [I-D.ietf-eai-simpledowngrade]. Getting downgrade algorithms right, 295 and minimizing the risk of operational problems and harm to the email 296 system, is tricky and requires careful engineering. These two 297 algorithms are well understood and carefully designed. 299 Because such messages are really variations on the original ones, not 300 really "downgraded ones" (although that terminology is often used for 301 convenience), they inevitably have relationships to the original ones 302 that the IMAP specification [RFC3501] did not anticipate. This 303 brings up two concerns in particular: First, digital signatures 304 computed over and intended for the original message will often not be 305 applicable to the variant message, and will often fail signature 306 verification. (It will be possible for some digital signatures to be 307 verified, if they cover only parts of the original message that are 308 not affected in the creation of the variant.) Second, servers that 309 may be accessed by the same user with different clients or methods 310 (e.g., POP or webmail systems in addition to IMAP or IMAP clients 311 with different capabilities) will need to exert extreme care to be 312 sure that UIDVALIDITY behaves as the user would expect. Those issues 313 may be especially sensitive if the server caches the variant message 314 or computes and stores it when the message arrives with the intent of 315 making either form available depending on client capabilities. 316 Additionally, in order to cope with the case when a server compliant 317 with this extension returns the same UIDVALIDITY to both legacy and 318 UTF8=ACCEPT-aware clients, a client upgraded from non UTF8=ACCEPT 319 aware MUST discard its cache of messages downloaded from the server. 321 The best (or "least bad") approach for any given environment will 322 depend on local conditions, local assumptions about user behavior, 323 the degree of control the server operator has over client usage and 324 upgrading, the options that are actually available, and so on. It is 325 impossible, at least at the time of publication of this 326 specification, to give good advice that will apply to all situations, 327 or even particular profiles of situations, other than "upgrade legacy 328 clients as soon as possible". 330 8. Issues with UTF-8 Header Mailstore 332 When an IMAP server uses a mailbox format that supports UTF-8 headers 333 and it permits selection or examination of that mailbox without 334 issuing "ENABLE UTF8=ACCEPT" first, it is the responsibility of the 335 server to comply with the IMAP4rev1 base specification [RFC3501] and 336 [RFC5322] with respect to all header information transmitted over the 337 wire. The issue of handling messages containing non-ASCII characters 338 in legacy environments is discussed in Section 7. 340 9. IANA Considerations 342 This document redefines two capabilities ("UTF8=ACCEPT" and 343 "UTF8=ONLY") in the IMAP 4 Capabilities registry [RFC3501]. Three 344 other capabilities that were described in the experimental 345 predecessor to this document (UTF8=ALL, UTF8=APPEND, UTF8=USER) are 346 now made OBSOLETE. IANA is asked to change the IMAP 4 Capabilities 347 registry as follows: 349 OLD: 350 +--------------+---------------------------+ 351 | UTF8=ACCEPT | [RFC5738] | 352 | UTF8=ALL | [RFC5738] | 353 | UTF8=APPEND | [RFC5738] | 354 | UTF8=ONLY | [RFC5738] | 355 | UTF8=USER | [RFC5738] | 356 +--------------+---------------------------+ 358 NEW: 359 +--------------+---------------------------+ 360 | UTF8=ACCEPT | [[this RFC]] | 361 | UTF8=ALL | OBSOLETE (was [RFC5738]) | 362 | UTF8=APPEND | OBSOLETE (was [RFC5738]) | 363 | UTF8=ONLY | [[this RFC]] | 364 | UTF8=USER | OBSOLETE (was [RFC5738]) | 365 +--------------+---------------------------+ 367 10. Security Considerations 369 The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] 370 apply to this specification, particularly with respect to use of 371 UTF-8 in user names and passwords. Otherwise, this is not believed 372 to alter the security considerations of IMAP4rev1. 374 Special considerations, some of them with security implications, 375 occur if a server that conforms to this specification is accessed by 376 a client that does not, as well as in some more complex situations in 377 which a given message is accessed by multiple clients that might use 378 different protocols and/or support different capabilities. Those 379 issues are discussed in Section 7 above. 381 11. References 383 11.1. Normative References 385 [RFC2119] Bradner, S., "Key words for use in 386 RFCs to Indicate Requirement 387 Levels", BCP 14, RFC 2119, 388 March 1997. 390 [RFC3501] Crispin, M., "INTERNET MESSAGE 391 ACCESS PROTOCOL - VERSION 4rev1", 392 RFC 3501, March 2003. 394 [RFC3629] Yergeau, F., "UTF-8, a 395 transformation format of ISO 396 10646", STD 63, RFC 3629, 397 November 2003. 399 [RFC4013] Zeilenga, K., "SASLprep: Stringprep 400 Profile for User Names and 401 Passwords", RFC 4013, 402 February 2005. 404 [RFC4466] Melnikov, A. and C. Daboo, 405 "Collected Extensions to IMAP4 406 ABNF", RFC 4466, April 2006. 408 [RFC4469] Resnick, P., "Internet Message 409 Access Protocol (IMAP) CATENATE 410 Extension", RFC 4469, April 2006. 412 [RFC5161] Gulbrandsen, A. and A. Melnikov, 413 "The IMAP ENABLE Extension", 414 RFC 5161, March 2008. 416 [RFC5198] Klensin, J. and M. Padlipsky, 417 "Unicode Format for Network 418 Interchange", RFC 5198, March 2008. 420 [RFC5234] Crocker, D. and P. Overell, 421 "Augmented BNF for Syntax 422 Specifications: ABNF", STD 68, 423 RFC 5234, January 2008. 425 [RFC5258] Leiba, B. and A. Melnikov, 426 "Internet Message Access Protocol 427 version 4 - LIST Command 428 Extensions", RFC 5258, June 2008. 430 [RFC6532] Yang, A., Steele, S., and N. Freed, 431 "Internationalized Email Headers", 432 RFC 6532, February 2012. 434 [RFC5322] Resnick, P., Ed., "Internet Message 435 Format", RFC 5322, October 2008. 437 [RFC6530] Klensin, J. and Y. Ko, "Overview 438 and Framework for Internationalized 439 Email", RFC 6530, February 2012. 441 [I-D.ietf-eai-popimap-downgrade] Fujiwara, K., "Post-delivery 442 Message Downgrading for 443 Internationalized Email Messages", 444 draft-ietf-eai-popimap-downgrade-08 445 (work in progress), October 2012. 447 [I-D.ietf-eai-simpledowngrade] Gulbrandsen, A., "Simplified POP/ 448 IMAP Downgrading for 449 Internationalized Email", 450 draft-ietf-eai-simpledowngrade-07 451 (work in progress), August 2012. 453 11.2. Informative References 455 [RFC2088] Myers, J., "IMAP4 non-synchronizing 456 literals", RFC 2088, January 1997. 458 [RFC5738] Resnick, P. and C. Newman, "IMAP 459 Support for UTF-8", RFC 5738, 460 March 2010. 462 [RFC2342] Gahrns, M. and C. Newman, "IMAP4 463 Namespace", RFC 2342, May 1998. 465 [RFC4314] Melnikov, A., "IMAP4 Access Control 466 List (ACL) Extension", RFC 4314, 467 December 2005. 469 Appendix A. Design Rationale 471 This non-normative section discusses the reasons behind some of the 472 design choices in the above specification. 474 The basic approach of advertising the ability to access a mailbox in 475 UTF-8 mode is intended to permit graceful upgrade, including servers 476 that support multiple mailbox formats. In particular, it would be 477 undesirable to force conversion of an entire server mailstore to 478 UTF-8 headers, so being able to phase-in support for new mailboxes 479 and gradually migrate old mailboxes is permitted by this design. 481 The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability 482 problems when legacy support goes away. In the situation where 483 backwards compatibility is broken anyway, just-send-UTF-8 IMAP has 484 the advantage that it might work with some legacy clients. However, 485 the difficulty of diagnosing interoperability problems caused by a 486 just-send-UTF-8 IMAP mechanism is the reason the "UTF8=ONLY" 487 capability mechanism was chosen. 489 Appendix B. Acknowledgments 491 The authors wish to thank the participants of the EAI working group 492 for their contributions to this document with particular thanks to 493 Harald Alvestrand, David Black, Randall Gellens, Arnt Gulbrandsen, 494 Kari Hurtta, John Klensin, Xiaodong Lee, Charles Lindsey, Alexey 495 Melnikov, Subramanian Moonesamy, Shawn Steele, Daniel Taharlev, and 496 Joseph Yee for their specific contributions to the discussion. 498 Authors' Addresses 500 Pete Resnick (editor) 501 Qualcomm Incorporated 502 5775 Morehouse Drive 503 San Diego, CA 92121-1714 504 US 506 Phone: +1 858 651 4478 507 EMail: presnick@qti.qualcomm.com 508 Chris Newman (editor) 509 Oracle 510 800 Royal Oaks 511 Monrovia, CA 91016 512 USA 514 Phone: 515 EMail: chris.newman@oracle.com 517 Sean Shen (editor) 518 CNNIC 519 No.4 South 4th Zhongguancun Street 520 Beijing, 100190 521 China 523 Phone: +86 10-58813038 524 EMail: shenshuo@cnnic.cn