idnits 2.17.1 draft-ietf-eai-pop-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 559. 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 updates RFC1939, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- 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). (Using the creation date from RFC1939, updated by this document, for RFC5378 checks: 1995-05-15) -- 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 (February 24, 2008) is 5906 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-09 == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-06 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet-Draft Sun Microsystems 4 Updates: 1939 (if approved) R. Gellens 5 Intended status: Experimental QUALCOMM Incorporated 6 Expires: August 27, 2008 February 24, 2008 8 POP3 Support for UTF-8 9 draft-ietf-eai-pop-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 27, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This specification extends the Post Office Protocol version 3 (POP3) 43 to support un-encoded international characters in user names, 44 passwords, mail addresses, message headers, and protocol-level 45 textual error strings. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Conventions Used in this Document . . . . . . . . . . . . 3 51 1.2. Change History . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2.1. Changes from -02 to -03 . . . . . . . . . . . . . . . 3 53 1.2.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 4 54 1.2.3. Changes from -00 to -01 . . . . . . . . . . . . . . . 4 55 1.2.4. Changes from draft-newman-ima-pop . . . . . . . . . . 4 56 1.3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. LANG Capability . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. UTF8 Capability . . . . . . . . . . . . . . . . . . . . . . . 8 59 3.1. The UTF8 Command . . . . . . . . . . . . . . . . . . . . . 8 60 3.2. USER Argument to UTF8 Capability . . . . . . . . . . . . . 9 61 4. Issues with UTF-8 Header maildrop . . . . . . . . . . . . . . 9 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 67 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 11 68 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 70 Intellectual Property and Copyright Statements . . . . . . . . . . 13 72 1. Introduction 74 This specification extends POP3 [RFC1939] using the POP3 Extension 75 Mechanism [RFC2449] to permit un-encoded UTF-8 [RFC3629] in headers 76 as described in Internationalized Email Headers 77 [I-D.ietf-eai-utf8headers]. It also adds a mechanism to support 78 login names outside the ASCII character set, and a mechanism to 79 support UTF-8 protocol-level error strings in a language appropriate 80 for the user. 82 Within this specification, the term down-conversion refers to the 83 process of modifying a message containing UTF8 headers 84 [I-D.ietf-eai-utf8headers] or body parts with 8bit content-transfer- 85 encoding as defined in MIME section 2.8 [RFC2045] into conforming 86 7-bit Internet message format [RFC2822] with Message Header 87 Extensions for Non-ASCII Text [RFC2047] and other 7-bit encodings. 88 Down-conversion is specified by Downgrading mechanism for Email 89 Address Internationalization [I-D.ietf-eai-downgrade]. 91 1.1. Conventions Used in this Document 93 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 94 in this document are to be interpreted as defined in "Key words for 95 use in RFCs to Indicate Requirement Levels" [RFC2119]. 97 The formal syntax uses the Augmented Backus-Naur Form (ABNF) 98 [RFC4234] notation including the core rules defined in Appendix B of 99 RFC 4234. 101 In examples, "C:" and "S:" indicate lines sent by the client and 102 server respectively. If a single "C:" or "S:" label applies to 103 multiple lines, then the line breaks between those lines are for 104 editorial clarity only and are not part of the actual protocol 105 exchange. 107 1.2. Change History 109 This section describes the change history of this Internet draft and 110 will be removed when/if this is published as an RFC. 112 1.2.1. Changes from -02 to -03 114 o Updated references. 116 o Replaced US-ASCII with ASCII. 118 o Added comment to language listing failure example. 120 o Replaced RET8, LST8, and TOP8 commands with a single mode-switch 121 UTF8 command issued before authentication. This simplifies the 122 protocol, and allows servers to optionally down-convert a cache of 123 the maildrop prior to issuing the +OK response entering 124 TRANSACTION state. 126 o Removed most up-conversion material. 128 o Removed definition of up-conversion. 130 o Removed IMAP4 reference. 132 o Added AUTH command to those affected by UTF8 capability. 134 o Removed LST8 and TOP8 capability parameters and commands. 136 o Removed NO-RETR capability. POP servers are now unconditionally 137 required to support down-conversion of UTF8-native maildrops. 139 o Added sentence about modifying authentication code to Security 140 Considerations. 142 o eai-downgrade draft is now normative and required. 144 o Deleted references to RFCs 1341, 1847, 2049, 2183, 3501, 3516, and 145 3490. 147 1.2.2. Changes from -01 to -02 149 o Minor grammatical tweaks. 151 o Add passwords to Abstract. 153 o Removed new editor's name from Acknowledgments. 155 1.2.3. Changes from -00 to -01 157 o Update references 159 1.2.4. Changes from draft-newman-ima-pop 161 o Change title to make this a WG document. 163 o Add LANG command and extension. 165 o Rename RET8 capability to UTF8 and add sub-sections for arguments. 167 o Add TOP8 command. 169 o Add definition of up-conversion and down-conversion. 171 o Some grammar fix-ups and section re-ordering based on RFC editor 172 style. 174 1.3. Open Issues 176 1. POP servers are now unconditionally required to down-convert 177 messages in a UTF8-native maildrop when not in UTF8 mode. 178 Previous versions of this document permitted servers to decline 179 to do so. This should be verified as group consensus. 181 2. Servers do not up-convert messages. While this makes sense for 182 RETR (since doing so would break digital signatures), it might 183 make sense for TOP, as it would provide a smaller and more clear 184 representation of the message. However, the usefulness of this 185 seems to be not worth the extra burden. 187 3. The current version allows clients to use UTF8 in authentication 188 commands without sending the UTF8 command. 190 2. LANG Capability 192 CAPA tag: 193 LANG 195 Arguments: 196 none 198 Added Commands: 199 LANG 201 Standard commands affected: 202 All 204 Announced states / possible differences: 205 both / no 207 Commands valid in states: 208 AUTHENTICATION, TRANSACTION 210 Specification reference: 211 this document 213 Discussion: 215 POP3 allows most +OK and -ERR server responses to include human- 216 readable text that in some cases needs to be presented to the user. 217 But that text is limited to ASCII by the POP3 specification 218 [RFC1939]. The LANG capability and command permit a POP3 client to 219 negotiate which language the server should use when sending human- 220 readable text. 222 A server that advertises the LANG extension MUST use the language 223 "i-default" as described in [RFC2277] as its default language until 224 another supported language is negotiated by the client. A server 225 MUST include "i-default" as one of its supported languages. 227 The LANG command requests that human-readable text included in all 228 subsequent +OK and -ERR responses be localized to a language matching 229 the language range argument as described by [RFC4647]. If the 230 command succeeds, the server returns a +OK response followed by a 231 single space, the exact language tag selected, another space, and the 232 rest of the line is human-readable text in the appropriate language. 233 This and subsequent protocol-level human readable text is encoded in 234 the UTF-8 charset. 236 If the command fails, the server returns an -ERR response and 237 subsequent human-readable response text continues to use the language 238 that was previously active (typically i-default). 240 The special "*" language range argument indicates a request to use a 241 language designated as preferred by the server administrator. The 242 preferred language MAY vary based on the currently active user. 244 If no argument is given and the POP3 server issues a positive 245 response, then the response given is multi-line. After the initial 246 +OK, for each language tag the server supports, the POP3 server 247 responds with a line for that language. This line is called a 248 "language listing". 250 In order to simplify parsing, all POP3 servers are required to use a 251 certain format for language listings. A language listing consists of 252 the language tag [RFC4646] of the message, optionally followed by a 253 single space and a human readable description of that language using 254 the UTF-8 charset. 256 < The server defaults to using English i-default responses until 257 the client explicitly changes the language. > 259 C: USER karen 260 S: +OK Hello, karen 261 C: PASS password 262 S: +OK karen's maildrop contains 2 messages (320 octets) 264 < Client requests depricated MUL language. Server replies 265 with -ERR response > 267 C: LANG MUL 268 S: -ERR invalid language MUL 270 < A LANG command with no arguments is a request for 271 a language listing. > 273 C: LANG 274 S: +OK Language listing follows: 275 S: en English 276 S: en-boont English Boontling dialect 277 S: de German 278 S: it Italian 279 S: i-default Default language 280 S: . 282 < A request for a language listing might fail > 284 C: LANG 285 S: -ERR Server is unable to list languages 287 < Once the client changes the language, all responses will be in 288 that language starting with the response to the LANG command. 289 Note: the example does not include the correct character accents 290 due to limitations of this document format. > 292 C: LANG fr 293 S: +OK fr La Language commande a ete execute avec success 295 < If a server does not support the requested primary language, 296 responses will continue to be returned in the current language 297 the server is using. > 299 C: LANG uga 300 S: -ERR Ce Language n'est pas supporte 302 C: LANG fr-ca 303 S: +OK fr La Language commande a ete execute avec success 305 C: LANG * 306 S: +OK fr La Language commande a ete execute avec success 308 Examples 310 3. UTF8 Capability 312 CAPA tag: 313 UTF8 315 Arguments: 316 USER, LIST, TOP 318 Added Commands: 319 UTF8 321 Standard commands affected: 322 AUTH, USER, PASS, APOP, LIST, TOP, RETR 324 Announced states / possible differences: 325 both / no 327 Commands valid in states: 328 AUTHORIZATION 330 Specification reference: 331 this document 333 Discussion: 335 This capability adds the "UTF8" command to POP3. The UTF8 command 336 switches the session from ASCII to UTF8 mode. 338 3.1. The UTF8 Command 340 The UTF8 command enables UTF8 mode. Maildrops can natively store 341 UTF8 or be limited to ASCII. UTF8 mode has no effect on messages in 342 an ACII-only maildrop. Messages in native-UTF8 maildrops can be 343 ASCII or UTF8 using internationalized headers 344 [I-D.ietf-eai-utf8headers] and/or 8bit content-transfer-encoding as 345 defined in MIME section 2.8 [RFC2045]. In UTF8 mode, both UTF8 and 346 ASCII messages are sent to the client as-is (without conversion). 347 When not in UTF8 mode, UTF8 messages in a native UTF8 maildrop MUST 348 be downconverted using the Downgrading mechanism for Email Address 349 Internationalization [I-D.ietf-eai-downgrade]. 351 Note that even in UTF8 mode, MIME binary content-transfer-encoding is 352 still not permitted. 354 The octet count (size) of a message reported in a response to the 355 LIST command SHOULD match what the server sends in a RETR response. 356 Sizes reported elsewhere, such as in STAT responses and free-form 357 text in positive status indicators (following "+OK") need not be 358 accurate, but it is preferable if they are. 360 3.2. USER Argument to UTF8 Capability 362 If the USER argument is included with this capability, it indicates 363 that the server accepts UTF-8 user names and passwords and applies 364 SASLprep [RFC4013] to the arguments of the AUTH, USER, PASS and APOP 365 commands. A client that supports APOP and permits UTF-8 in user 366 names or passwords MUST also implement SASLprep [RFC4013] on the user 367 name and password used to compute the APOP digest. 369 The client does not need to issue the UTF8 command prior to using 370 UTF8 in authentication. However, clients MUST NOT use UTF8 in USER, 371 PASS, or APOP commands unless the USER argument is included with the 372 UTF8 capability. 374 Use of UTF8 in the AUTH command is governed by the SASL mechanism. 376 4. Issues with UTF-8 Header maildrop 378 When a POP3 server uses a UTF8-native maildrop, it is the 379 responsibility of the server to comply with the POP3 base 380 specification [RFC1939] and RFC 2822 [RFC2822] when not in UTF8 mode. 381 Mechanisms for 7-bit downgrading to help comply with the standards 382 are specified in Downgrading mechanism for Email Address 383 Internationalization [I-D.ietf-eai-downgrade]. 385 5. IANA Considerations 387 This adds two new capabilities ("UTF8" and "LANG") to the POP3 388 capability registry [RFC2449]. 390 6. Security Considerations 392 The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] 393 apply to this specification, particularly with respect to use of 394 UTF-8 in user names and passwords. 396 The "LANG *" command can reveal the existence and preferred language 397 of a user to an active attacker probing the system if the active 398 language changes in response to the USER, PASS, or APOP commands 399 prior to validating the user's credentials. Servers MUST implement a 400 configuration to prevent this exposure. 402 It is possible for a man-in-the-middle attacker to insert a LANG 403 command in the command stream thus making protocol-level diagnostic 404 responses unintelligible to the user. A mechanism to integrity 405 protect the session, such as TLS [RFC2595] can be used to defeat such 406 attacks. 408 Modifying server authentication code (in this case, to support UTF8) 409 needs to be done with care to avoid introducing vulnerabilities (for 410 example, in string parsing). 412 7. References 414 7.1. Normative References 416 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 417 STD 53, RFC 1939, May 1996. 419 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 420 Extensions (MIME) Part One: Format of Internet Message 421 Bodies", RFC 2045, November 1996. 423 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 424 Part Three: Message Header Extensions for Non-ASCII Text", 425 RFC 2047, November 1996. 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 431 Languages", BCP 18, RFC 2277, January 1998. 433 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 434 Mechanism", RFC 2449, November 1998. 436 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 437 April 2001. 439 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 440 Languages", BCP 47, RFC 4646, September 2006. 442 [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", 443 BCP 47, RFC 4647, September 2006. 445 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 446 10646", STD 63, RFC 3629, November 2003. 448 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 449 and Passwords", RFC 4013, February 2005. 451 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 452 Specifications: ABNF", RFC 4234, October 2005. 454 [I-D.ietf-eai-utf8headers] 455 Yeh, J., "Internationalized Email Headers", 456 draft-ietf-eai-utf8headers-09 (work in progress), 457 Feb 2008. 459 7.2. Informative References 461 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 462 RFC 2595, June 1999. 464 [I-D.ietf-eai-downgrade] 465 Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for 466 Email Address Internationalization (EAI)", 467 draft-ietf-eai-downgrade-06 (work in progress), Feb 2008. 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 Having servers perform up-conversion so that, at a minimum, RFC2047- 475 encoded words are decoded into UTF8 is tempting, since this is an 476 area that clients often fail to correctly implement. However, 477 modifying messages breaks digital signatures, and would require 478 servers to support arbitrary charset conversion. 480 USER is optional because the implementation burden of SASLprep 481 [RFC4013] is not well understood and mandating such support in all 482 cases could negatively impact deployment. 484 Due to interoperability problems with RFC 2047 and limited deployment 485 of RFC 2231, it is hoped these 7-bit encoding mechanisms can be 486 deprecated in the future when UTF-8 header support becomes prevalent. 488 While it is possible to provide useful examples for language 489 negotiation without support for non-ASCII characters, it is difficult 490 to provide useful examples for commands specifically designed to use 491 the UTF-8 charset un-encoded when the document format is limited to 492 ASCII. As a result, there are no plans to provide examples for that 493 part of the specification as long as this remains an experimental 494 proposal. However, implementers of this specification are encouraged 495 to provide examples to the document author for a future revision. 497 Appendix B. Acknowledgments 499 Thanks to John Klensin, Tony Hansen and other EAI working group 500 participants who provided helpful suggestions and interesting debate 501 that improved this specification. 503 Authors' Addresses 505 Chris Newman 506 Sun Microsystems 507 3401 Centrelake Dr., Suite 410 508 Ontario, CA 91761 509 US 511 Email: chris.newman@sun.com 513 Randall Gellens 514 QUALCOMM Incorporated 515 5775 Morehouse Drive 516 San Diego, CA 92651 517 US 519 Email: rg+ietf@qualcomm.com 521 Full Copyright Statement 523 Copyright (C) The IETF Trust (2008). 525 This document is subject to the rights, licenses and restrictions 526 contained in BCP 78, and except as set forth therein, the authors 527 retain all their rights. 529 This document and the information contained herein are provided on an 530 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 531 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 532 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 533 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 534 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 535 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 537 Intellectual Property 539 The IETF takes no position regarding the validity or scope of any 540 Intellectual Property Rights or other rights that might be claimed to 541 pertain to the implementation or use of the technology described in 542 this document or the extent to which any license under such rights 543 might or might not be available; nor does it represent that it has 544 made any independent effort to identify any such rights. Information 545 on the procedures with respect to rights in RFC documents can be 546 found in BCP 78 and BCP 79. 548 Copies of IPR disclosures made to the IETF Secretariat and any 549 assurances of licenses to be made available, or the result of an 550 attempt made to obtain a general license or permission for the use of 551 such proprietary rights by implementers or users of this 552 specification can be obtained from the IETF on-line IPR repository at 553 http://www.ietf.org/ipr. 555 The IETF invites any interested party to bring to its attention any 556 copyrights, patents or patent applications, or other proprietary 557 rights that may cover technology that may be required to implement 558 this standard. Please address the information to the IETF at 559 ietf-ipr@ietf.org. 561 Acknowledgment 563 Funding for the RFC Editor function is provided by the IETF 564 Administrative Support Activity (IASA).