idnits 2.17.1 draft-ietf-eai-pop-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 642. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 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 (June 13, 2006) is 6526 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 361, but not defined == Missing Reference: 'TBD-ref' is mentioned on line 384, but not defined ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Possible downref: Normative reference to a draft: ref. 'I-D.yeh-ima-utf8headers' -- Obsolete informational reference (is this intentional?): RFC 1341 (Obsoleted by RFC 1521) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-00 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 11 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) June 13, 2006 5 Expires: December 15, 2006 7 POP3 Support for UTF-8 8 draft-ietf-eai-pop-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 15, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This specification extends the Post Office Protocol version 3 (POP3) 42 to support un-encoded international characters in user names, mail 43 addresses, message headers, and protocol-level textual error strings. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Conventions Used in this Document . . . . . . . . . . . . 3 49 1.2. Change History . . . . . . . . . . . . . . . . . . . . . . 3 50 1.2.1. Changes from draft-newman-ima-pop . . . . . . . . . . 3 51 1.3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. LANG Capability . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. UTF8 Capability . . . . . . . . . . . . . . . . . . . . . . . 7 54 3.1. USER Argument to UTF8 Capability . . . . . . . . . . . . . 7 55 3.2. LST8 Argument to UTF8 Capability . . . . . . . . . . . . . 7 56 3.3. TOP8 Argument to UTF8 Capability . . . . . . . . . . . . . 8 57 4. NO-RETR Capability . . . . . . . . . . . . . . . . . . . . . . 8 58 5. Up-Conversion Server Requirements . . . . . . . . . . . . . . 9 59 6. Issues with UTF-8 Header Mail Drop . . . . . . . . . . . . . . 10 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 65 Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 12 66 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 Intellectual Property and Copyright Statements . . . . . . . . . . 16 70 1. Introduction 72 This specification extends POP3 [RFC1939] using the POP3 Extension 73 Mechanism [RFC2449] to permit un-encoded UTF-8 [RFC3629] in headers 74 as described in Transmission of Email Headers in UTF-8 Encoding 75 [I-D.yeh-ima-utf8headers]. It also adds a mechanism to support login 76 names outside the US-ASCII character set, and a mechanism to support 77 UTF-8 protocol-level error strings in a language appropriate for the 78 user. 80 Within this specification, the term up-conversion refers to 81 converting a traditional 7-bit Internet message [RFC2822] with 82 Message Header Extensions for Non-ASCII Text [RFC2047] and other 83 7-bit encodings to a message with UTF-8 headers [I-D.yeh-ima- 84 utf8headers] and minimal use of 7-bit encodings. Down-conversion 85 refers to the inverse process. One mechanism to perform down- 86 conversion is described by Downgrading mechanism for 87 Internationalized eMail Address [I-D.ietf-eai-downgrade]. 89 1.1. Conventions Used in this Document 91 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 92 in this document are to be interpreted as defined in "Key words for 93 use in RFCs to Indicate Requirement Levels" [RFC2119]. 95 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC4234] 96 notation including the core rules defined in Appendix B of RFC 4234. 98 In examples, "C:" and "S:" indicate lines sent by the client and 99 server respectively. If a single "C:" or "S:" label applies to 100 multiple lines, then the line breaks between those lines are for 101 editorial clarity only and are not part of the actual protocol 102 exchange. 104 1.2. Change History 106 This section describes the change history of this Internet draft and 107 will be removed when/if this is published as an RFC. 109 1.2.1. Changes from draft-newman-ima-pop 111 o Change title to make this a WG document. 113 o Add LANG command and extension. 115 o Rename RET8 capability to UTF8 and add sub-sections for arguments. 117 o Add TOP8 command. 119 o Add definition of up-conversion and down-conversion. 121 o Some grammar fix-ups and section re-ordering based on RFC editor 122 style. 124 1.3. Open Issues 126 The decision on how to handle UTF-8 in Received headers will impact 127 the up-conversion requirements section. 129 2. LANG Capability 131 CAPA tag: 132 LANG 134 Arguments: 135 none 137 Added Commands: 138 LANG 140 Standard commands affected: 141 All 143 Announced states / possible differences: 144 both / no 146 Commands valid in states: 147 AUTHENTICATION, TRANSACTION 149 Specification reference: 150 this document 152 Discussion: 154 POP3 allows most +OK and -ERR server responses to include human- 155 readable text that in some cases needs to be presented to the user. 156 But that text is limited to US-ASCII by the POP3 specification 157 [RFC1939]. The LANG capability and command permit a POP3 client to 158 negotiate which language the server should use when sending human- 159 readable text. 161 A server that advertises the LANG extension MUST use the language 162 "i-default" as described in [RFC2277] as its default language until 163 another supported language is negotiated by the client. A server 164 MUST include "i-default" as one of its supported languages. 166 The LANG command requests that human-readable text included in all 167 subsequent +OK and -ERR responses be localized to a language matching 168 the language range argument as described by section 2.5 of [RFC3066]. 169 If the command succeeds, the server returns a +OK response followed 170 by a single space, the exact RFC 3066 language tag selected, another 171 space, and the rest of the line is human-readable text in the 172 appropriate language. This and subsequent protocol-level human 173 readable text is encoded in the UTF-8 charset. 175 If the command fails, the server returns a -ERR response and 176 subsequent human-readable response text continues to use the language 177 that was previously active (typically i-default). 179 The client MUST NOT use MUL (Multiple languages) or UND 180 (Undetermined) language tags and the server MUST return -ERR if 181 either tag is used. The special "*" language range argument 182 indicates a request to use a language designated as preferred by the 183 server administrator. The preferred language MAY vary based on the 184 currently active user. 186 If no argument was given and the POP3 server issues a positive 187 response, then the response given is multi-line. After the initial 188 +OK, for each language tag the server supports, the POP3 server 189 responds with a line for that language. This line is called a 190 "language listing". 192 In order to simplify parsing, all POP3 servers are required to use a 193 certain format for language listings. A language listing consists of 194 the RFC 3066 language tag of the message, optionally followed by a 195 single space and a human readable description of that language using 196 the UTF-8 charset. 198 < The server defaults to using English i-default responses until 199 the user explicitly changes the language. > 201 C: USER karen 202 S: +OK Hello, karen 203 C: PASS password 204 S: +OK karen's maildrop contains 2 messages (320 octets) 206 < Client requested MUL language. Server MUST reply with -ERR > 208 C: LANG MUL 209 S: -ERR invalid language MUL 211 < A LANG command with no arguments is a request for 212 a language listing. > 214 C: LANG 215 S: +OK Language listing follows: 216 S: en English 217 S: en-boont English Boontling dialect 218 S: de German 219 S: it Italian 220 S: i-default Default language 221 S: . 223 C: LANG 224 S: -ERR Server is unable to list languages 226 < Once the client changes the language, all responses will be in 227 that language starting with the response to the LANG command. 228 Note: the example does not include the correct character accents 229 due to limitations of this document format. > 231 C: LANG fr 232 S: +OK fr La Language commande a ete execute avec success 234 < If a server does not support the requested primary language, 235 responses will continue to be returned in the current language 236 the server is using. > 238 C: LANG uga 239 S: -ERR Ce Language n'est pas supporte 241 C: LANG fr-ca 242 S: +OK fr La Language commande a ete execute avec success 244 C: LANG * 245 S: +OK fr La Language commande a ete execute avec success 247 3. UTF8 Capability 249 CAPA tag: 250 UTF8 252 Arguments: 253 USER, LST8, TOP8 255 Added Commands: 256 RET8, LST8, TOP8 258 Standard commands affected: 259 USER, PASS, APOP 261 Announced states / possible differences: 262 both / no 264 Commands valid in states: 265 TRANSACTION 267 Specification reference: 268 this document 270 Discussion: 272 This capability adds UTF-8 content support to POP3. This capability 273 always adds the "RET8" command to POP3. The RET8 command is 274 identical to the RETR command, except that the retrieved message uses 275 UTF-8 in headers [I-D.yeh-ima-utf8headers]. In addition, the 8bit 276 content-transfer-encoding as defined in MIME section 2.8 [RFC2045] is 277 explicitly permitted. The retrieved message MUST still be textual 278 and otherwise formatted according to RFC 2822 [RFC2822] and MIME 279 [RFC2045]. The MIME binary content-transfer-encoding is not 280 permitted. Clients wishing to use binary MIME should implement IMAP4 281 [RFC3501] with the IMAP4 Binary Content Extension [RFC3516]. 283 3.1. USER Argument to UTF8 Capability 285 If the USER argument is included with this capability, that indicates 286 the server accepts UTF-8 user names and passwords and applies 287 SASLprep [RFC4013] to the arguments of the USER, PASS and APOP 288 commands. A client that supports APOP and permits UTF-8 in user 289 names or passwords MUST also implement SASLprep [RFC4013] on the user 290 name and password used to compute the APOP digest. 292 3.2. LST8 Argument to UTF8 Capability 294 If the LST8 argument is included with this capability, that indicates 295 the server implements the LST8 command. The LST8 command is 296 identical to the LIST command except that the octet counts are the 297 exact octet counts returned by the RET8 command. A POP3 client that 298 uses RET8 MUST use LST8 instead of LIST if LST8 is advertised. 300 3.3. TOP8 Argument to UTF8 Capability 302 If the TOP8 argument is included with this capability, that indicates 303 the server implements the TOP8 command. TOP8 is identical to TOP, 304 except the headers are UTF-8. 306 4. NO-RETR Capability 308 CAPA tag: 309 NO-RETR 311 Arguments: 312 none 314 Added Commands: 315 none 317 Standard commands affected: 318 RETR, LIST, TOP 320 Announced states / possible differences: 321 both / no 323 Commands valid in states: 324 N/A 326 Specification reference: 327 this document 329 Discussion: 331 This capability permits a POP3 server to advertise that it does not 332 support the RETR, LIST or TOP commands. Any attempt to use any of 333 these three commands results in an error response. As this is an 334 incompatible change to POP3, a clear warning is necessary. POP3 335 clients that find implementation of the UTF8 capability problematic 336 are encouraged to at least detect the NO-RETR capability and provide 337 an informative error message to the end-user. 339 When a POP3 server runs on a UTF-8 header native mail drop, the down- 340 conversion step necessary to implement RETR in a backwards compatible 341 fashion becomes more difficult to support. Although it is hoped 342 deployed POP3 servers do not advertise NO-RETR for some years, this 343 capability is intended to minimize the disruption when legacy support 344 finally goes away. 346 A server that advertises NO-RETR MUST advertise UTF8 with at least 347 the LST8 argument and MUST NOT advertise TOP. 349 5. Up-Conversion Server Requirements 351 When a POP3 server uses a traditional mail drop that supports only 352 7-bit headers, it MUST support message header up-conversion for the 353 RET8, LST8, and TOP8 commands. As POP3 clients are best when simple, 354 the more up-conversion the server performs, the better. Minimal up- 355 conversion is described in this section. 357 The server MUST support up-conversion of the following address 358 header-fields in the message header: From, Sender, To, CC, Bcc, 359 Resent-From, Resent-Sender, Resent-To, Resent-CC, Resent-Bcc, and 360 Reply-To. This up-conversion MUST include address local-parts 361 encoded according to [TBD], address domains encoded according to IDNA 362 [RFC3490], and MIME header encoding [RFC2047] of display-names and 363 any RFC 2822 comments. 365 The following charsets MUST be supported for up-conversion of MIME 366 header encoding [RFC2047]: UTF-8, US-ASCII, ISO-8859-1, ISO-8859-2, 367 ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, 368 ISO-8859-8, ISO-8859-9, ISO-8859-10, ISO-8859-14, and ISO-8859-15. 369 Other widely deployed MIME charsets SHOULD be supported. 371 Up-conversion of MIME header encoding of the following headers MUST 372 also be implemented: Subject, Date (RFC 2822 comments only), 373 Comments, Keywords, Content-Description. 375 While this specification does not require it, server implementations 376 are encouraged to up-convert all MIME body headers, and particularly 377 the deprecated (and misused) name parameter [RFC1341] on Content-Type 378 and the Content-Disposition [RFC2183] filename parameter. These may 379 be encoded using the standard MIME parameter encoding [RFC2231] 380 mechanism, or via non-standard use of MIME header encoding [RFC2047] 381 in quoted strings. 383 Servers are also encouraged to up-convert the headers on embedded 384 message/rfc822 body parts [TBD-ref]. Servers MAY convert the charset 385 on MIME body parts to UTF-8, and MAY remove quoted-printable or 386 base64 encodings as long as the resulting text complies with the 387 requirements of the 8-bit content-transfer-encoding [RFC2045]. 389 The POP3 server MUST NOT perform up-conversion of headers and content 390 of multipart/signed [RFC1847], as well as Original-Recipient and 391 Return-Path. 393 6. Issues with UTF-8 Header Mail Drop 395 When a POP3 server uses a mail drop that supports UTF-8 headers and 396 it does not advertise the NO-RETR capability, it is the 397 responsibility of the server to comply with the POP3 base 398 specification [RFC1939] and RFC 2822 [RFC2822] with respect to the 399 RETR, LIST, and TOP commands. Mechanisms for 7-bit downgrading to 400 help comply with the standards are discussed in Downgrading mechanism 401 for Internationalized eMail Address (IMA) [I-D.ietf-eai-downgrade]. 403 A POP3 server with a mail drop that supports UTF-8 headers MUST 404 comply with the RET8 protocol requirements implicit from Section 5. 405 However, the code necessary for such compliance need not be part of 406 the POP3 server itself in this case. For example, the minimal 407 required up-conversion could be performed when a message is inserted 408 into the POP3-accessible mail drop. 410 7. IANA Considerations 412 This adds three new capabilities ("UTF8", "LANG", and "NO-RETR") to 413 the POP3 capability registry [RFC2449]. 415 8. Security Considerations 417 The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013] 418 apply to this specification, particularly with respect to use of 419 UTF-8 in user names and passwords. 421 The "LANG *" command can reveal the existence and preferred language 422 of a user to an active attacker probing the system if the active 423 language changes in response to the USER, PASS, or APOP commands 424 prior to validating the user's credentials. Servers MUST implement a 425 configuration to prevent this exposure. 427 It is possible for a man-in-the-middle attacker to insert a LANG 428 command in the command stream thus making protocol-level diagnostic 429 responses unintelligible to the user. A mechanism to integrity 430 protect the session, such as TLS [RFC2595] can be used to defeat such 431 attacks. 433 9. References 435 9.1. Normative References 437 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 438 STD 53, RFC 1939, May 1996. 440 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 441 Extensions (MIME) Part One: Format of Internet Message 442 Bodies", RFC 2045, November 1996. 444 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 445 Part Three: Message Header Extensions for Non-ASCII Text", 446 RFC 2047, November 1996. 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 452 Languages", BCP 18, RFC 2277, January 1998. 454 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 455 Mechanism", RFC 2449, November 1998. 457 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 458 April 2001. 460 [RFC3066] Alvestrand, H., "Tags for the Identification of 461 Languages", BCP 47, RFC 3066, January 2001. 463 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 464 "Internationalizing Domain Names in Applications (IDNA)", 465 RFC 3490, March 2003. 467 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 468 10646", STD 63, RFC 3629, November 2003. 470 [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 471 and Passwords", RFC 4013, February 2005. 473 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 474 Specifications: ABNF", RFC 4234, October 2005. 476 [I-D.yeh-ima-utf8headers] 477 Yeh, J., "Transmission of Email Headers in UTF-8 478 Encoding", draft-yeh-ima-utf8headers-01 (work in 479 progress), February 2006. 481 9.2. Informative References 483 [RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet 484 Mail Extensions): Mechanisms for Specifying and Describing 485 the Format of Internet Message Bodies", RFC 1341, 486 June 1992. 488 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 489 "Security Multiparts for MIME: Multipart/Signed and 490 Multipart/Encrypted", RFC 1847, October 1995. 492 [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 493 Extensions (MIME) Part Five: Conformance Criteria and 494 Examples", RFC 2049, November 1996. 496 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 497 Presentation Information in Internet Messages: The 498 Content-Disposition Header Field", RFC 2183, August 1997. 500 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 501 Word Extensions: Character Sets, Languages, and 502 Continuations", RFC 2231, November 1997. 504 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 505 RFC 2595, June 1999. 507 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 508 4rev1", RFC 3501, March 2003. 510 [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, 511 April 2003. 513 [I-D.ietf-eai-downgrade] 514 Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for 515 Internationalized eMail Address (IMA)", 516 draft-ietf-eai-downgrade-00 (work in progress), May 2006. 518 Appendix A. Design Rationale 520 This non-normative section discusses the reasons behind some of the 521 design choices in the above specification. 523 The basic approach of advertising a parallel command set and 524 permitting graceful migration of both client and server with minimal 525 disruption is a deliberate choice. While a mechanism that makes RETR 526 "just-send-UTF-8" might deploy faster, it would also create 527 interoperability problems. The approach used prevents 528 interoperability problems until the NO-RETR mechanism is deployed. A 529 client command to cause a model switch could also work, but the 530 parallel command approach is cleaner given the small number of 531 commands. 533 The choice to make RET8 nearly identical to RETR is important to 534 minimize the code changes necessary in a client. An alternative 535 approach that permits binary MIME and uses a length-counted argument 536 would be architecturally superior but is dismissed due to the 537 migration problems it would cause. The IMAP4 Binary extension should 538 be sufficient for cases where binary MIME support is deemed 539 necessary. 541 LST8 is optional to minimize the cost of deploying UTF-8 support on a 542 legacy mail drop. The server load necessary to perform up-conversion 543 on every message in the mail drop to determine the LST8 octet-counts 544 would be prohibitively expensive when there's no way to cache those 545 counts. The octet counts from the LIST command should be close 546 enough to the RET8 size for most POP3 user interfaces, and robust 547 POP3 clients already have to deal with LIST octet counts that don't 548 match the actual size of the RETR result. 550 USER is optional because the implementation burden of SASLprep 551 [RFC4013] is not well understood and mandating such support in all 552 cases could negatively impact deployment. 554 The NO-RETR mechanism simplifies diagnosis of interoperability 555 problems when legacy support goes away. In the situation where 556 backwards compatibility is broken anyway, just-send-8 RETR has the 557 advantage that it might work with some legacy clients. However, the 558 difficulty of diagnosing interoperability problems caused by a just- 559 send-8 RETR mechanism is the reason the NO-RETR mechanism was chosen. 561 The up-conversion requirements are designed to balance the desire to 562 deprecate and eventually eliminate complicated encodings (like MIME 563 header encodings) without creating a significant deployment burden 564 for servers. While it would be desirable to require up-conversion of 565 attachment file names, the erroneous perception that MIME parsing is 566 difficult in combination with multiple deployed mechanisms for such 567 file names tip the balance. 569 Due to interoperability problems with RFC 2047 and limited deployment 570 of RFC 2231, it is hoped these 7-bit encoding mechanisms can be 571 deprecated in the future when UTF-8 header support becomes prevalent. 572 Aggressive conversion of these encodings to UTF-8 will help simplify 573 the infrastructure and improve interoperability in the future. 575 The set of mandatory charsets comes from two sources: MIME 576 requirements [RFC2049] and IETF Policy on Character Sets [RFC2277]. 577 Including a requirement to up-convert widely deployed encoded 578 ideographic charsets to UTF-8 would be reasonable for most scenarios, 579 but may require unacceptable table sizes for some embedded devices. 580 The open-ended recommendation to support widely deployed charsets 581 avoids the political ramifications of attempting to list such 582 charsets. The author believes market forces, existing open-source 583 software, and public conversion tables are sufficient to deploy the 584 appropriate charsets. Specifically, use of an open-source charset 585 conversion library (such as ICU) is likely sufficient to fulfill this 586 recommendation. 588 While it is possible to provide useful examples for language 589 negotiation without support for non-ASCII characters, it is difficult 590 to provide useful examples for commands specifically designed to use 591 the UTF-8 charset un-encoded when the document format is limited to 592 US-ASCII. As a result, there are no plans to provide examples for 593 that part of the specification as long as this remains an 594 experimental proposal. However, implementers of this specification 595 are encouraged to provide examples to the document author for a 596 future revision. 598 This was deliberately written so the down-conversion specification is 599 not a normative reference. While this specification does reiterate 600 the requirements of the base POP3 specification with respect to 601 message format, no specific mechanism to achieve those requirements 602 is mandated. 604 Appendix B. Acknowledgments 606 Thanks to Randy Gellens, John Klensin, Tony Hansen and other EAI 607 working group participants who provided helpful suggestions and 608 interesting debate that improved this specification. 610 Author's Address 612 Chris Newman 613 Sun Microsystems 614 3401 Centrelake Dr., Suite 410 615 Ontario, CA 91761 616 US 618 Email: chris.newman@sun.com 620 Intellectual Property Statement 622 The IETF takes no position regarding the validity or scope of any 623 Intellectual Property Rights or other rights that might be claimed to 624 pertain to the implementation or use of the technology described in 625 this document or the extent to which any license under such rights 626 might or might not be available; nor does it represent that it has 627 made any independent effort to identify any such rights. Information 628 on the procedures with respect to rights in RFC documents can be 629 found in BCP 78 and BCP 79. 631 Copies of IPR disclosures made to the IETF Secretariat and any 632 assurances of licenses to be made available, or the result of an 633 attempt made to obtain a general license or permission for the use of 634 such proprietary rights by implementers or users of this 635 specification can be obtained from the IETF on-line IPR repository at 636 http://www.ietf.org/ipr. 638 The IETF invites any interested party to bring to its attention any 639 copyrights, patents or patent applications, or other proprietary 640 rights that may cover technology that may be required to implement 641 this standard. Please address the information to the IETF at 642 ietf-ipr@ietf.org. 644 Disclaimer of Validity 646 This document and the information contained herein are provided on an 647 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 648 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 649 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 650 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 651 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 652 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 654 Copyright Statement 656 Copyright (C) The Internet Society (2006). This document is subject 657 to the rights, licenses and restrictions contained in BCP 78, and 658 except as set forth therein, the authors retain all their rights. 660 Acknowledgment 662 Funding for the RFC Editor function is currently provided by the 663 Internet Society.