idnits 2.17.1 draft-ietf-eai-rfc5721bis-03.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 RFC5721, 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 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, 2011) is 4542 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 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) -- Obsolete informational reference (is this intentional?): RFC 5721 (Obsoleted by RFC 6856) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Gellens 3 Internet-Draft QUALCOMM Incorporated 4 Obsoletes: RFC5721 (if approved) C. Newman 5 Intended status: Standards Track Oracle 6 Expires: May 19, 2012 J. Yao 7 CNNIC 8 K. Fujiwara 9 JPRS 10 November 16, 2011 12 POP3 Support for UTF-8 13 draft-ietf-eai-rfc5721bis-03.txt 15 Abstract 17 This specification extends the Post Office Protocol version 3 (POP3) 18 to support un-encoded international characters in user names, 19 passwords, mail addresses, message headers, and protocol-level 20 textual strings. This specification replaces RFC 5721. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 19, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 70 2. LANG Capability . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. UTF8 Capability . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.1. The UTF8 Command . . . . . . . . . . . . . . . . . . . . . 7 73 3.2. USER Argument to UTF8 Capability . . . . . . . . . . . . . 8 74 4. Native UTF-8 Maildrops . . . . . . . . . . . . . . . . . . . . 9 75 5. UTF-8 Response Code . . . . . . . . . . . . . . . . . . . . . 9 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. draft-ietf-eai-rfc5721bis: Version 00 . . . . . . . . . . 11 80 8.2. draft-ietf-eai-rfc5721bis: Version 01 . . . . . . . . . . 11 81 8.3. draft-ietf-eai-rfc5721bis: Version 02 . . . . . . . . . . 11 82 8.4. draft-ietf-eai-rfc5721bis: Version 03 . . . . . . . . . . 11 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 86 9.3. Informative References . . . . . . . . . . . . . . . . . . 13 87 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 13 88 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 This document forms part of the Email Address Internationalization 93 (EAI) protocols described in the EAI Framework document 94 [I-D.ietf-eai-frmwrk-4952bis]. As part of the overall EAI work, 95 email messages may be transmitted and delivered containing un-encoded 96 UTF-8 characters in the header and/or body, and mail drops that are 97 accessed using POP3 [RFC1939] might natively store UTF-8. 99 This specification extends POP3 [RFC1939] using the POP3 extension 100 mechanism [RFC2449] to permit un-encoded UTF-8 [RFC3629] in headers, 101 and bodies (e.g., transferred using 8-bit Content Transfer Encoding) 102 as described in "Internationalized Email Headers" 103 [I-D.ietf-eai-rfc5335bis]. It also adds a mechanism to support login 104 names and passwords containing UTF-8 characters, and a mechanism to 105 support UTF-8 characters in protocol level response strings as well 106 as the ability to negotiate a language for such response strings. 108 This specification also adds a new response code to indicate that a 109 message could not be returned because it requires UTF-8 mode and the 110 server is unwilling to down-convert. 112 Within this specification, the term "down-conversion" refers to the 113 process of modifying a message containing UTF-8 headers 114 [I-D.ietf-eai-rfc5335bis] or body parts with 8bit content-transfer- 115 encoding, as defined in MIME Section 2.8 [RFC2045], into conforming 116 7-bit Internet Message Format [RFC5322] with message header 117 extensions for non-ASCII text [RFC2047] and other 7-bit encodings. 118 Down-conversion is specified by "Post-delivery Message Downgrading 119 for Internationalized Email Messages" [popimap-downgrade]. 121 This specification replaces an earlier, experimental, approach to the 122 same problem RFC 5721 [RFC5721]. Section 6 of 123 [I-D.ietf-eai-frmwrk-4952bis] describes the changes in approach 124 between RFC 5721 [RFC5721] and this specification. 126 1.1. Conventions Used in This Document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in "Key words for use in 131 RFCs to Indicate Requirement Levels" [RFC2119]. 133 In examples, "C:" and "S:" indicate lines sent by the client and 134 server, respectively. If a single "C:" or "S:" label applies to 135 multiple lines, then the line breaks between those lines are for 136 editorial clarity only and are not part of the actual protocol 137 exchange. 139 Note that examples always use 7-bit ASCII characters due to 140 limitations of this document format; in particular, some examples for 141 the "LANG" command may appear silly as a result. 143 2. LANG Capability 145 Per "POP3 Extension Mechanism" [RFC2449], this document adds a new 146 capability response tag to indicate support for a new command: LANG. 147 The capability tag and new command are described below. 149 CAPA tag: 150 LANG 152 Arguments with CAPA tag: 153 none 155 Added Commands: 156 LANG 158 Standard commands affected: 159 All 161 Announced states / possible differences: 162 both / no 164 Commands valid in states: 165 AUTHORIZATION, TRANSACTION 167 Specification reference: 168 this document 170 Discussion: 172 POP3 allows most +OK and -ERR server responses to include human- 173 readable text that, in some cases, might be presented to the user. 174 But that text is limited to ASCII by the POP3 specification 175 [RFC1939]. The LANG capability and command permit a POP3 client to 176 negotiate which language the server uses when sending human-readable 177 text. 179 A server that advertises the LANG extension MUST use the language 180 "i-default" as described in [RFC2277] as its default language until 181 another supported language is negotiated by the client. A server 182 MUST include "i-default" as one of its supported languages. 184 The LANG command requests that human-readable text included in all 185 subsequent +OK and -ERR responses be localized to a language matching 186 the language range argument (the "Basic Language Range" as described 187 by [RFC4647]). If the command succeeds, the server returns a +OK 188 response followed by a single space, the exact language tag selected, 189 another space, and the rest of the line is human-readable text in the 190 appropriate language. This and subsequent protocol-level human- 191 readable text is encoded in the UTF-8 charset. 193 If the command fails, the server returns an -ERR response and 194 subsequent human-readable response text continues to use the language 195 that was previously active (typically i-default). 197 The special "*" language range argument indicates a request to use a 198 language designated as preferred by the server administrator. The 199 preferred language MAY vary based on the currently active user. 201 If no argument is given and the POP3 server issues a positive 202 response, then the response given is multi-line. After the initial 203 +OK, for each language tag the server supports, the POP3 server 204 responds with a line for that language. This line is called a 205 "language listing". 207 In order to simplify parsing, all POP3 servers are required to use a 208 certain format for language listings. A language listing consists of 209 the language tag [RFC5646] of the message, optionally followed by a 210 single space and a human-readable description of the language in the 211 language itself, using the UTF-8 charset. 213 Examples: 215 < Note that some examples do not include the correct character 216 accents due to limitations of this document format. > 218 < The server defaults to using English i-default responses until 219 the client explicitly changes the language. > 221 C: USER karen 222 S: +OK Hello, karen 223 C: PASS password 224 S: +OK karen's maildrop contains 2 messages (320 octets) 226 < Client requests deprecated MUL language. Server replies 227 with -ERR response. > 229 C: LANG MUL 230 S: -ERR invalid language MUL 232 < A LANG command with no parameters is a request for 233 a language listing. > 234 C: LANG 235 S: +OK Language listing follows: 236 S: en English 237 S: en-boont English Boontling dialect 238 S: de Deutsch 239 S: it Italiano 240 S: es Espanol 241 S: sv Svenska 242 S: i-default Default language 243 S: . 245 < A request for a language listing might fail. > 247 C: LANG 248 S: -ERR Server is unable to list languages 250 < Once the client changes the language, all responses will be in 251 that language, starting with the response to the LANG command. > 253 C: LANG es 254 S: +OK es Idioma cambiado 256 < If a server does not support the requested primary language, 257 responses will continue to be returned in the current language 258 the server is using. > 260 C: LANG uga 261 S: -ERR es Idioma <> no es conocido 263 C: LANG sv 264 S: +OK sv Kommandot "LANG" lyckades 266 C: LANG * 267 S: +OK es Idioma cambiado 269 3. UTF8 Capability 271 Per "POP3 Extension Mechanism" [RFC2449], this document adds a new 272 capability response tag to indicate support for new server 273 functionality, including a new command: UTF8. The capability tag and 274 new command and functionality are described below. 276 CAPA tag: 277 UTF8 279 Arguments with CAPA tag: 280 USER 282 Added Commands: 283 UTF8 285 Standard commands affected: 286 USER, PASS, APOP, LIST, TOP, RETR 288 Announced states / possible differences: 289 both / no 291 Commands valid in states: 292 AUTHORIZATION 294 Specification reference: 295 this document 297 Discussion: 299 This capability adds the "UTF8" command to POP3. The UTF8 command 300 switches the session from ASCII to UTF-8 mode. In UTF-8 mode, both 301 servers and clients can send and accept UTF-8 characters. 303 3.1. The UTF8 Command 305 The UTF8 command enables UTF-8 mode. The UTF8 command has no 306 parameters. 308 Maildrops can natively store UTF-8 or be limited to ASCII. UTF-8 309 mode has no effect on messages in an ASCII-only maildrop. Messages 310 in native UTF-8 maildrops can be ASCII or UTF-8 using 311 internationalized headers [I-D.ietf-eai-rfc5335bis] and/or 8bit 312 content-transfer-encoding, as defined in MIME Section 2.8 [RFC2045]. 313 In UTF-8 mode, both UTF-8 and ASCII messages are sent to the client 314 as-is (without conversion). When not in UTF-8 mode, UTF-8 messages 315 in a native UTF-8 maildrop MUST NOT be sent to the client as-is. If 316 a client requests a UTF-8 message when not in UTF-8 mode, the server 317 MUST either down-convert (downgrade) the message content it sends to 318 the client to comply with unextended POP and Internet Mail Format 319 without UTF-8 mode support, or fail the request with a -ERR response 320 containing the UTF-8 response code (see section 5). The UTF8 command 321 MAY fail. 323 Note that even in UTF-8 mode, MIME binary content-transfer-encoding 324 is still not permitted. 326 The octet count (size) of a message reported in a response to the 327 LIST command SHOULD match the actual number of octets sent in a RETR 328 response (not counting byte-stuffing). Sizes reported elsewhere, 329 such as in STAT responses and non-standardized, free-form text in 330 positive status indicators (following "+OK") need not be accurate, 331 but it is preferable if they were. 333 Mail stores are either ASCII or native UTF-8, and clients either 334 issue the UTF8 command or not. The message needs converting only 335 when it is native UTF-8 and the client has not issued the UTF8 336 command, in which case the server MAY choose to down-convert it or 337 reject the command which requested the message with the new UTF-8 338 response code (see Section 5). The down-converted message may be 339 larger. The server may choose various strategies regarding down- 340 conversion, which include when to down-convert, whether to cache or 341 store the down-converted form of a message (and if so, for how long), 342 and whether to calculate or retain the size of a down-converted 343 message independently of the down-converted content. If the server 344 does not have immediate access to the accurate down-converted size, 345 it may be faster to estimate rather than calculate it. Servers are 346 expected to normally follow the RFC 1939 [RFC1939] text on using the 347 "exact size" in a scan listing, but there may be situations with 348 maildrops containing very large numbers of messages in which this 349 might be a problem. If the server does estimate, reporting a scan 350 listing size smaller than what it turns out to be could be a problem 351 for some clients. In summary, it is better for servers to report 352 accurate sizes, but if this is not possible, high guesses are better 353 than small ones. Some POP servers include the message size in the 354 non-standardized text response following "+OK" (the 'text' production 355 of RFC 2449 [RFC2449]), in a RETR or TOP response (possibly because 356 some examples in POP3 [RFC1939] do so). There has been at least one 357 known case of a client relying on this to know when it had received 358 all of the message rather than following the POP3 [RFC1939] rule of 359 looking for a line consisting of a termination octet (".") and a CRLF 360 pair. While any such client is non-compliant, if a server does 361 include the size in such text, it is better if it is accurate. 363 Clients MUST NOT issue the STLS command [RFC2595] after issuing UTF8; 364 servers MAY (but are not required to) enforce this by rejecting with 365 an "-ERR" response an STLS command issued subsequent to a successful 366 UTF8 command. (Because this is a protocol error as opposed to a 367 failure based on conditions, an extended response code [RFC2449] is 368 not specified.) 370 3.2. USER Argument to UTF8 Capability 372 If the USER argument is included with this capability, it indicates 373 that the server accepts UTF-8 user names and passwords. 375 Servers that include the USER argument in the UTF8 capability 376 response SHOULD apply SASLprep [RFC4013] to the arguments of the USER 377 and PASS commands. 379 A client or server that supports APOP and permits UTF-8 in user names 380 or passwords MUST apply SASLprep [RFC4013] to the user name and 381 password used to compute the APOP digest. 383 When applying SASLprep [RFC4013], servers MUST reject UTF-8 user 384 names or passwords that contain a Unicode character listed in Section 385 2.3 of SASLprep [RFC4013]. When applying SASLprep to the USER 386 argument, the PASS argument, or the APOP username argument, a 387 compliant server or client MUST treat them as a query string 388 [RFC3454](i.e., unassigned Unicode code points are allowed). When 389 applying SASLprep to the APOP password argument, a compliant server 390 or client MUST treat them as a stored string [RFC3454] (i.e., 391 unassigned Unicode code points are prohibited). 393 The client does not need to issue the UTF8 command prior to using 394 UTF-8 in authentication. However, clients MUST NOT use UTF-8 395 characters in USER, PASS, or APOP commands unless the USER argument 396 is included in the UTF8 capability response. 398 The server MUST reject UTF-8 user names or passwords that fail to 399 comply with the formal syntax in UTF-8 [RFC3629]. 401 Use of UTF-8 characters in the AUTH command is governed by the POP3 402 SASL [RFC5034] mechanism. 404 4. Native UTF-8 Maildrops 406 When a POP3 server uses a native UTF-8 maildrop, it is the 407 responsibility of the server to comply with the POP3 base 408 specification [RFC1939] and Internet Message Format [RFC5322] when 409 not in UTF-8 mode. Mechanisms for 7-bit downgrading to help comply 410 with the standards are described in [popimap-downgrade]. 412 5. UTF-8 Response Code 414 Per "POP3 Extension Mechanism" [RFC2449], this document adds a new 415 response code: UTF-8, described below. 417 Complete response code: 418 UTF8 420 Valid for responses: 421 -ERR 423 Valid for commands: 424 LIST, TOP, RETR 426 Response code meaning and expected client behavior: 428 The UTF-8 response code indicates that a failure is due to a request 429 when not in UTF-8 mode for message content containing UTF-8 430 characters. 432 The client MAY reissue the command after entering UTF-8 mode (or wait 433 for the server to be in a better mood and willing to downconvert). 435 6. IANA Considerations 437 This specification updates two capabilities ("UTF8" and "LANG") to 438 the POP3 capability registry [RFC2449]. 440 This specification also adds one new response code ("UTF-8") to the 441 POP3 response codes registry [RFC2449]. 443 7. Security Considerations 445 The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] 446 apply to this specification, particularly with respect to use of 447 UTF-8 in user names and passwords. 449 The "LANG *" command might reveal the existence and preferred 450 language of a user to an active attacker probing the system if the 451 active language changes in response to the USER, PASS, or APOP 452 commands prior to validating the user's credentials. Servers MUST 453 implement a configuration to prevent this exposure. 455 It is possible for a man-in-the-middle attacker to insert a LANG 456 command in the command stream, thus making protocol-level diagnostic 457 responses unintelligible to the user. A mechanism to integrity- 458 protect the session, such as Transport Layer Security (TLS) [RFC2595] 459 can be used to defeat such attacks. 461 Modifying server authentication code (in this case, to support UTF8 462 command) needs to be done with care to avoid introducing 463 vulnerabilities (for example, in string parsing). 465 The UTF8 command description (Section 3.1) contains a discussion on 466 reporting inaccurate sizes. An additional risk to doing so is that, 467 if a client allocates buffers based on the reported size, it may 468 overrun the buffer, crash, or have other problems if the message data 469 is larger than reported. 471 8. Change History 473 8.1. draft-ietf-eai-rfc5721bis: Version 00 475 following the new charter 477 8.2. draft-ietf-eai-rfc5721bis: Version 01 479 refine the texts 481 8.3. draft-ietf-eai-rfc5721bis: Version 02 483 update the texts based on Joseph's comments 485 8.4. draft-ietf-eai-rfc5721bis: Version 03 487 improve the texts 489 text instructing servers to either downconvert or reject 491 new UTF-8 response code for use 493 9. References 495 9.1. Normative References 497 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and 498 Framework for Internationalized 499 Email", 500 draft-ietf-eai-frmwrk-4952bis-12 (work 501 in progress), October 2011. 503 [I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., and N. Freed, 504 "Internationalized Email Headers", 505 draft-ietf-eai-rfc5335bis-13 (work in 506 progress), October 2011. 508 [RFC1939] Myers, J. and M. Rose, "Post Office 509 Protocol - Version 3", STD 53, 510 RFC 1939, May 1996. 512 [RFC2045] Freed, N. and N. Borenstein, 513 "Multipurpose Internet Mail Extensions 514 (MIME) Part One: Format of Internet 515 Message Bodies", RFC 2045, 516 November 1996. 518 [RFC2047] Moore, K., "MIME (Multipurpose 519 Internet Mail Extensions) Part Three: 520 Message Header Extensions for Non- 521 ASCII Text", RFC 2047, November 1996. 523 [RFC2119] Bradner, S., "Key words for use in 524 RFCs to Indicate Requirement Levels", 525 BCP 14, RFC 2119, March 1997. 527 [RFC2277] Alvestrand, H., "IETF Policy on 528 Character Sets and Languages", BCP 18, 529 RFC 2277, January 1998. 531 [RFC2449] Gellens, R., Newman, C., and L. 532 Lundblade, "POP3 Extension Mechanism", 533 RFC 2449, November 1998. 535 [RFC3454] Hoffman, P. and M. Blanchet, 536 "Preparation of Internationalized 537 Strings ("stringprep")", RFC 3454, 538 December 2002. 540 [RFC3629] Yergeau, F., "UTF-8, a transformation 541 format of ISO 10646", STD 63, 542 RFC 3629, November 2003. 544 [RFC4013] Zeilenga, K., "SASLprep: Stringprep 545 Profile for User Names and Passwords", 546 RFC 4013, February 2005. 548 [RFC4647] Phillips, A. and M. Davis, "Matching 549 of Language Tags", BCP 47, RFC 4647, 550 September 2006. 552 [RFC5322] Resnick, P., Ed., "Internet Message 553 Format", RFC 5322, October 2008. 555 [RFC5646] Phillips, A. and M. Davis, "Tags for 556 Identifying Languages", BCP 47, 557 RFC 5646, September 2009. 559 9.2. Informative References 561 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 562 and ACAP", RFC 2595, June 1999. 564 [RFC5034] Siemborski, R. and A. Menon-Sen, "The 565 Post Office Protocol (POP3) Simple 566 Authentication and Security Layer 567 (SASL) Authentication Mechanism", 568 RFC 5034, July 2007. 570 [popimap-downgrade] Fujiwara, K., "Post-delivery Message 571 Downgrading for Internationalized 572 Email Messages", 573 draft-ietf-eai-popimap-downgrade-00 574 (work in progress), October 2010. 576 9.3. Informative References 578 [RFC5721] Gellens, R. and C. Newman, "POP3 579 Support for UTF-8", RFC 5721, 580 February 2010. 582 Appendix A. Design Rationale 584 This non-normative section discusses the reasons behind some of the 585 design choices in the above specification. 587 Due to interoperability problems with RFC 2047 and limited deployment 588 of RFC 2231, it is hoped these 7-bit encoding mechanisms can be 589 deprecated in the future when UTF-8 header support becomes prevalent. 591 USER is optional because the implementation burden of SASLprep 592 [RFC4013] is not well understood, and mandating such support in all 593 cases could negatively impact deployment. 595 Appendix B. Acknowledgments 597 Thanks to John Klensin, Tony Hansen, and other EAI working group 598 participants who provided helpful suggestions and interesting debate 599 that improved this specification. 601 Authors' Addresses 603 Randall Gellens 604 QUALCOMM Incorporated 605 5775 Morehouse Drive 606 San Diego, CA 92651 607 US 609 EMail: rg+ietf@qualcomm.com 610 Chris Newman 611 Oracle 612 800 Royal Oaks 613 Monrovia, CA 91016-6347 614 US 616 EMail: chris.newman@oracle.com 618 Jiankang YAO 619 CNNIC 620 No.4 South 4th Street, Zhongguancun 621 Beijing 623 Phone: +86 10 58813007 624 EMail: yaojk@cnnic.cn 626 Kazunori Fujiwara 627 Japan Registry Services Co., Ltd. 628 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 629 Tokyo 631 Phone: +81 3 5215 8451 632 EMail: fujiwara@jprs.co.jp