idnits 2.17.1 draft-ietf-eai-pop-04.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 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 582. 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 (July 13, 2008) is 5737 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: January 14, 2009 July 13, 2008 8 POP3 Support for UTF-8 9 draft-ietf-eai-pop-04.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 January 14, 2009. 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 -03 to -04 . . . . . . . . . . . . . . . 3 53 1.2.2. Changes from -02 to -03 . . . . . . . . . . . . . . . 4 54 1.2.3. Changes from -01 to -02 . . . . . . . . . . . . . . . 4 55 1.2.4. Changes from -00 to -01 . . . . . . . . . . . . . . . 4 56 1.2.5. Changes from draft-newman-ima-pop . . . . . . . . . . 5 57 1.3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. LANG Capability . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. UTF8 Capability . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.1. The UTF8 Command . . . . . . . . . . . . . . . . . . . . . 8 61 3.2. USER Argument to UTF8 Capability . . . . . . . . . . . . . 9 62 4. Issues with UTF-8 Header maildrop . . . . . . . . . . . . . . 10 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 68 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 12 69 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 71 Intellectual Property and Copyright Statements . . . . . . . . . . 14 73 1. Introduction 75 This specification extends POP3 [RFC1939] using the POP3 Extension 76 Mechanism [RFC2449] to permit un-encoded UTF-8 [RFC3629] in headers 77 as described in Internationalized Email Headers 78 [I-D.ietf-eai-utf8headers]. It also adds a mechanism to support 79 login names outside the ASCII character set, and a mechanism to 80 support UTF-8 protocol-level error strings in a language appropriate 81 for the user. 83 Within this specification, the term down-conversion refers to the 84 process of modifying a message containing UTF8 headers 85 [I-D.ietf-eai-utf8headers] or body parts with 8bit content-transfer- 86 encoding as defined in MIME section 2.8 [RFC2045] into conforming 87 7-bit Internet message format [RFC2822] with Message Header 88 Extensions for Non-ASCII Text [RFC2047] and other 7-bit encodings. 89 Down-conversion is specified by Downgrading mechanism for Email 90 Address Internationalization [I-D.ietf-eai-downgrade]. 92 1.1. Conventions Used in this Document 94 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 95 in this document are to be interpreted as defined in "Key words for 96 use in RFCs to Indicate Requirement Levels" [RFC2119]. 98 The formal syntax uses the Augmented Backus-Naur Form (ABNF) 99 [RFC4234] notation including the core rules defined in Appendix B of 100 RFC 4234. 102 In examples, "C:" and "S:" indicate lines sent by the client and 103 server respectively. If a single "C:" or "S:" label applies to 104 multiple lines, then the line breaks between those lines are for 105 editorial clarity only and are not part of the actual protocol 106 exchange. 108 1.2. Change History 110 This section describes the change history of this Internet draft and 111 will be removed when/if this is published as an RFC. 113 1.2.1. Changes from -03 to -04 115 o Specified that it is an error to issue STLS after UTF8. 117 o Removed prior open issues. 119 o Downgrading added as open issue. 121 1.2.2. Changes from -02 to -03 123 o Updated references. 125 o Replaced US-ASCII with ASCII. 127 o Added comment to language listing failure example. 129 o Replaced RET8, LST8, and TOP8 commands with a single mode-switch 130 UTF8 command issued before authentication. This simplifies the 131 protocol, and allows servers to optionally down-convert a cache of 132 the maildrop prior to issuing the +OK response entering 133 TRANSACTION state. 135 o Removed most up-conversion material. 137 o Removed definition of up-conversion. 139 o Removed IMAP4 reference. 141 o Added AUTH command to those affected by UTF8 capability. 143 o Removed LST8 and TOP8 capability parameters and commands. 145 o Removed NO-RETR capability. POP servers are now unconditionally 146 required to support down-conversion of UTF8-native maildrops. 148 o Added sentence about modifying authentication code to Security 149 Considerations. 151 o eai-downgrade draft is now normative and required. 153 o Deleted references to RFCs 1341, 1847, 2049, 2183, 3501, 3516, and 154 3490. 156 1.2.3. Changes from -01 to -02 158 o Minor grammatical tweaks. 160 o Add passwords to Abstract. 162 o Removed new editor's name from Acknowledgments. 164 1.2.4. Changes from -00 to -01 166 o Update references 168 1.2.5. Changes from draft-newman-ima-pop 170 o Change title to make this a WG document. 172 o Add LANG command and extension. 174 o Rename RET8 capability to UTF8 and add sub-sections for arguments. 176 o Add TOP8 command. 178 o Add definition of up-conversion and down-conversion. 180 o Some grammar fix-ups and section re-ordering based on RFC editor 181 style. 183 1.3. Open Issues 185 1. How should downgrading (Section 3.1) be handled? 187 2. LANG Capability 189 CAPA tag: 190 LANG 192 Arguments: 193 none 195 Added Commands: 196 LANG 198 Standard commands affected: 199 All 201 Announced states / possible differences: 202 both / no 204 Commands valid in states: 205 AUTHENTICATION, TRANSACTION 207 Specification reference: 208 this document 210 Discussion: 212 POP3 allows most +OK and -ERR server responses to include human- 213 readable text that in some cases needs to be presented to the user. 214 But that text is limited to ASCII by the POP3 specification 216 [RFC1939]. The LANG capability and command permit a POP3 client to 217 negotiate which language the server should use when sending human- 218 readable text. 220 A server that advertises the LANG extension MUST use the language 221 "i-default" as described in [RFC2277] as its default language until 222 another supported language is negotiated by the client. A server 223 MUST include "i-default" as one of its supported languages. 225 The LANG command requests that human-readable text included in all 226 subsequent +OK and -ERR responses be localized to a language matching 227 the language range argument as described by [RFC4647]. If the 228 command succeeds, the server returns a +OK response followed by a 229 single space, the exact language tag selected, another space, and the 230 rest of the line is human-readable text in the appropriate language. 231 This and subsequent protocol-level human readable text is encoded in 232 the UTF-8 charset. 234 If the command fails, the server returns an -ERR response and 235 subsequent human-readable response text continues to use the language 236 that was previously active (typically i-default). 238 The special "*" language range argument indicates a request to use a 239 language designated as preferred by the server administrator. The 240 preferred language MAY vary based on the currently active user. 242 If no argument is given and the POP3 server issues a positive 243 response, then the response given is multi-line. After the initial 244 +OK, for each language tag the server supports, the POP3 server 245 responds with a line for that language. This line is called a 246 "language listing". 248 In order to simplify parsing, all POP3 servers are required to use a 249 certain format for language listings. A language listing consists of 250 the language tag [RFC4646] of the message, optionally followed by a 251 single space and a human readable description of that language using 252 the UTF-8 charset. 254 < The server defaults to using English i-default responses until 255 the client explicitly changes the language. > 257 C: USER karen 258 S: +OK Hello, karen 259 C: PASS password 260 S: +OK karen's maildrop contains 2 messages (320 octets) 262 < Client requests depricated MUL language. Server replies 263 with -ERR response > 264 C: LANG MUL 265 S: -ERR invalid language MUL 267 < A LANG command with no arguments is a request for 268 a language listing. > 270 C: LANG 271 S: +OK Language listing follows: 272 S: en English 273 S: en-boont English Boontling dialect 274 S: de German 275 S: it Italian 276 S: i-default Default language 277 S: . 279 < A request for a language listing might fail > 281 C: LANG 282 S: -ERR Server is unable to list languages 284 < Once the client changes the language, all responses will be in 285 that language starting with the response to the LANG command. 286 Note: the example does not include the correct character accents 287 due to limitations of this document format. > 289 C: LANG fr 290 S: +OK fr La Language commande a ete execute avec success 292 < If a server does not support the requested primary language, 293 responses will continue to be returned in the current language 294 the server is using. > 296 C: LANG uga 297 S: -ERR Ce Language n'est pas supporte 299 C: LANG fr-ca 300 S: +OK fr La Language commande a ete execute avec success 302 C: LANG * 303 S: +OK fr La Language commande a ete execute avec success 305 Examples 307 3. UTF8 Capability 308 CAPA tag: 309 UTF8 311 Arguments: 312 USER, LIST, TOP 314 Added Commands: 315 UTF8 317 Standard commands affected: 318 AUTH, USER, PASS, APOP, LIST, TOP, RETR 320 Announced states / possible differences: 321 both / no 323 Commands valid in states: 324 AUTHORIZATION 326 Specification reference: 327 this document 329 Discussion: 331 This capability adds the "UTF8" command to POP3. The UTF8 command 332 switches the session from ASCII to UTF8 mode. 334 3.1. The UTF8 Command 336 The UTF8 command enables UTF8 mode. Maildrops can natively store 337 UTF8 or be limited to ASCII. UTF8 mode has no effect on messages in 338 an ACII-only maildrop. Messages in native-UTF8 maildrops can be 339 ASCII or UTF8 using internationalized headers 340 [I-D.ietf-eai-utf8headers] and/or 8bit content-transfer-encoding as 341 defined in MIME section 2.8 [RFC2045]. In UTF8 mode, both UTF8 and 342 ASCII messages are sent to the client as-is (without conversion). 343 When not in UTF8 mode, UTF8 messages in a native UTF8 maildrop MUST 344 be downconverted using the Downgrading mechanism for Email Address 345 Internationalization [I-D.ietf-eai-downgrade]. 347 [[Downgrading: How should downgrading and the reference to 348 draft-ietf-eai-downgrade be handled?]] 350 Options: 352 1 MUST downgrade according to eai-downgrade, 353 2 SHOULD downgrade according to eai-downgrade, 355 3 "might" downgrade according to eai-downgrade-. In this case, 356 "might" is just a note that "many people like to do it this way", 357 and has no normative force. 359 The main argument against a prescribed mechanism for downgrade by a 360 POP server is that the only clients that have any use for a 361 standardized downgraded message (because they wish to interpret 362 downgrade headers, for example) are ones that can support UTF8 and 363 hence will issue the UTF8 command in the first place. The counter 364 argument is that non-UTF8 clients might be upgraded to be capable of 365 interpreting prior downgraded messages if they were in a standard 366 format. [[ (end of downgrade open issue): ]] 368 Note that even in UTF8 mode, MIME binary content-transfer-encoding is 369 still not permitted. 371 The octet count (size) of a message reported in a response to the 372 LIST command SHOULD match what the server sends in a RETR response. 373 Sizes reported elsewhere, such as in STAT responses and free-form 374 text in positive status indicators (following "+OK") need not be 375 accurate, but it is preferable if they are. 377 Clients MUST NOT issue the STLS command [RFC2595] after issuing UTF8; 378 servers MAY (but are not required to) enforce this by rejecting with 379 an "-ERR" response an STLS command issued subsequent to a successful 380 UTF8 command. (Because this is a protocol error as opposed to a 381 failure based on conditions, an extended response code [RFC2449] is 382 not specified.) 384 3.2. USER Argument to UTF8 Capability 386 If the USER argument is included with this capability, it indicates 387 that the server accepts UTF-8 user names and passwords and applies 388 SASLprep [RFC4013] to the arguments of the AUTH, USER, PASS and APOP 389 commands. A client that supports APOP and permits UTF-8 in user 390 names or passwords MUST also implement SASLprep [RFC4013] on the user 391 name and password used to compute the APOP digest. 393 The client does not need to issue the UTF8 command prior to using 394 UTF8 in authentication. However, clients MUST NOT use UTF8 in USER, 395 PASS, or APOP commands unless the USER argument is included with the 396 UTF8 capability. 398 Use of UTF8 in the AUTH command is governed by the SASL mechanism. 400 4. Issues with UTF-8 Header maildrop 402 When a POP3 server uses a UTF8-native maildrop, it is the 403 responsibility of the server to comply with the POP3 base 404 specification [RFC1939] and RFC 2822 [RFC2822] when not in UTF8 mode. 405 Mechanisms for 7-bit downgrading to help comply with the standards 406 are specified in Downgrading mechanism for Email Address 407 Internationalization [I-D.ietf-eai-downgrade]. 409 5. IANA Considerations 411 This adds two new capabilities ("UTF8" and "LANG") to the POP3 412 capability registry [RFC2449]. 414 6. Security Considerations 416 The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] 417 apply to this specification, particularly with respect to use of 418 UTF-8 in user names and passwords. 420 The "LANG *" command can reveal the existence and preferred language 421 of a user to an active attacker probing the system if the active 422 language changes in response to the USER, PASS, or APOP commands 423 prior to validating the user's credentials. Servers MUST implement a 424 configuration to prevent this exposure. 426 It is possible for a man-in-the-middle attacker to insert a LANG 427 command in the command stream thus making protocol-level diagnostic 428 responses unintelligible to the user. A mechanism to integrity 429 protect the session, such as TLS [RFC2595] can be used to defeat such 430 attacks. 432 Modifying server authentication code (in this case, to support UTF8) 433 needs to be done with care to avoid introducing vulnerabilities (for 434 example, in string parsing). 436 7. References 438 7.1. Normative References 440 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 441 STD 53, RFC 1939, May 1996. 443 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 444 Extensions (MIME) Part One: Format of Internet Message 445 Bodies", RFC 2045, November 1996. 447 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 448 Part Three: Message Header Extensions for Non-ASCII Text", 449 RFC 2047, November 1996. 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, March 1997. 454 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 455 Languages", BCP 18, RFC 2277, January 1998. 457 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 458 Mechanism", RFC 2449, November 1998. 460 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 461 April 2001. 463 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 464 Languages", BCP 47, RFC 4646, September 2006. 466 [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", 467 BCP 47, RFC 4647, September 2006. 469 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 470 10646", STD 63, RFC 3629, November 2003. 472 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 473 and Passwords", RFC 4013, February 2005. 475 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 476 Specifications: ABNF", RFC 4234, October 2005. 478 [I-D.ietf-eai-utf8headers] 479 Yeh, J., "Internationalized Email Headers", 480 draft-ietf-eai-utf8headers-09 (work in progress), 481 Feb 2008. 483 7.2. Informative References 485 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 486 RFC 2595, June 1999. 488 [I-D.ietf-eai-downgrade] 489 Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for 490 Email Address Internationalization (EAI)", 491 draft-ietf-eai-downgrade-06 (work in progress), Feb 2008. 493 Appendix A. Design Rationale 495 This non-normative section discusses the reasons behind some of the 496 design choices in the above specification. 498 Having servers perform up-conversion so that, at a minimum, RFC2047- 499 encoded words are decoded into UTF8 is tempting, since this is an 500 area that clients often fail to correctly implement. However, 501 modifying messages breaks digital signatures, and would require 502 servers to support arbitrary charset conversion. 504 USER is optional because the implementation burden of SASLprep 505 [RFC4013] is not well understood and mandating such support in all 506 cases could negatively impact deployment. 508 Due to interoperability problems with RFC 2047 and limited deployment 509 of RFC 2231, it is hoped these 7-bit encoding mechanisms can be 510 deprecated in the future when UTF-8 header support becomes prevalent. 512 While it is possible to provide useful examples for language 513 negotiation without support for non-ASCII characters, it is difficult 514 to provide useful examples for commands specifically designed to use 515 the UTF-8 charset un-encoded when the document format is limited to 516 ASCII. As a result, there are no plans to provide examples for that 517 part of the specification as long as this remains an experimental 518 proposal. However, implementers of this specification are encouraged 519 to provide examples to the document author for a future revision. 521 Appendix B. Acknowledgments 523 Thanks to John Klensin, Tony Hansen and other EAI working group 524 participants who provided helpful suggestions and interesting debate 525 that improved this specification. 527 Authors' Addresses 529 Chris Newman 530 Sun Microsystems 531 3401 Centrelake Dr., Suite 410 532 Ontario, CA 91761 533 US 535 Email: chris.newman@sun.com 536 Randall Gellens 537 QUALCOMM Incorporated 538 5775 Morehouse Drive 539 San Diego, CA 92651 540 US 542 Email: rg+ietf@qualcomm.com 544 Full Copyright Statement 546 Copyright (C) The IETF Trust (2008). 548 This document is subject to the rights, licenses and restrictions 549 contained in BCP 78, and except as set forth therein, the authors 550 retain all their rights. 552 This document and the information contained herein are provided on an 553 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 554 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 555 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 556 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 557 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 558 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 560 Intellectual Property 562 The IETF takes no position regarding the validity or scope of any 563 Intellectual Property Rights or other rights that might be claimed to 564 pertain to the implementation or use of the technology described in 565 this document or the extent to which any license under such rights 566 might or might not be available; nor does it represent that it has 567 made any independent effort to identify any such rights. Information 568 on the procedures with respect to rights in RFC documents can be 569 found in BCP 78 and BCP 79. 571 Copies of IPR disclosures made to the IETF Secretariat and any 572 assurances of licenses to be made available, or the result of an 573 attempt made to obtain a general license or permission for the use of 574 such proprietary rights by implementers or users of this 575 specification can be obtained from the IETF on-line IPR repository at 576 http://www.ietf.org/ipr. 578 The IETF invites any interested party to bring to its attention any 579 copyrights, patents or patent applications, or other proprietary 580 rights that may cover technology that may be required to implement 581 this standard. Please address the information to the IETF at 582 ietf-ipr@ietf.org. 584 Acknowledgment 586 Funding for the RFC Editor function is provided by the IETF 587 Administrative Support Activity (IASA).