Skip to content

Commit 3bb35bc

Browse files
jstedfastjstedfast
committedJul 15, 2014
Added UTF8 extension RFCs for SMTP, POP3, and IMAP
·
4.11.01.0.0
1 parent 6f42494 commit 3bb35bc

File tree

3 files changed

+2473
-0
lines changed

3 files changed

+2473
-0
lines changed
 

‎rfc/rfc6531.txt

+1,011
Large diffs are not rendered by default.

‎rfc/rfc6855.txt

+675
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,675 @@
1+
2+
3+
4+
5+
6+
7+
Internet Engineering Task Force (IETF) P. Resnick, Ed.
8+
Request for Comments: 6855 Qualcomm Incorporated
9+
Obsoletes: 5738 C. Newman, Ed.
10+
Category: Standards Track Oracle
11+
ISSN: 2070-1721 S. Shen, Ed.
12+
CNNIC
13+
March 2013
14+
15+
16+
IMAP Support for UTF-8
17+
18+
Abstract
19+
20+
This specification extends the Internet Message Access Protocol
21+
(IMAP) to support UTF-8 encoded international characters in user
22+
names, mail addresses, and message headers. This specification
23+
replaces RFC 5738.
24+
25+
Status of This Memo
26+
27+
This is an Internet Standards Track document.
28+
29+
This document is a product of the Internet Engineering Task Force
30+
(IETF). It represents the consensus of the IETF community. It has
31+
received public review and has been approved for publication by the
32+
Internet Engineering Steering Group (IESG). Further information on
33+
Internet Standards is available in Section 2 of RFC 5741.
34+
35+
Information about the current status of this document, any errata,
36+
and how to provide feedback on it may be obtained at
37+
http://www.rfc-editor.org/info/rfc6855.
38+
39+
Copyright Notice
40+
41+
Copyright (c) 2013 IETF Trust and the persons identified as the
42+
document authors. All rights reserved.
43+
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.
53+
54+
55+
56+
57+
58+
Resnick, et al. Standards Track [Page 1]
59+
60+
RFC 6855 IMAP Support for UTF-8 March 2013
61+
62+
63+
Table of Contents
64+
65+
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
66+
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
67+
3. "UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP
68+
Quoted-Strings . . . . . . . . . . . . . . . . . . . . . . . . 3
69+
4. IMAP UTF8 "APPEND" Data Extension . . . . . . . . . . . . . . 4
70+
5. "LOGIN" Command and UTF-8 . . . . . . . . . . . . . . . . . . 5
71+
6. "UTF8=ONLY" Capability . . . . . . . . . . . . . . . . . . . . 5
72+
7. Dealing with Legacy Clients . . . . . . . . . . . . . . . . . 6
73+
8. Issues with UTF-8 Header Mailstore . . . . . . . . . . . . . . 7
74+
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
75+
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
76+
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
77+
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
78+
11.2. Informative References . . . . . . . . . . . . . . . . . 10
79+
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 11
80+
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
81+
82+
1. Introduction
83+
84+
This specification forms part of the Email Address
85+
Internationalization protocols described in the Email Address
86+
Internationalization Framework document [RFC6530]. It extends IMAP
87+
[RFC3501] to permit UTF-8 [RFC3629] in headers, as described in
88+
"Internationalized Email Headers" [RFC6532]. It also adds a
89+
mechanism to support mailbox names using the UTF-8 charset. This
90+
specification creates two new IMAP capabilities to allow servers to
91+
advertise these new extensions.
92+
93+
This specification assumes that the IMAP server will be operating in
94+
a fully internationalized environment, i.e., one in which all clients
95+
accessing the server will be able to accept non-ASCII message header
96+
fields and other information, as specified in Section 3. At least
97+
during a transition period, that assumption will not be realistic for
98+
many environments; the issues involved are discussed in Section 7
99+
below.
100+
101+
This specification replaces an earlier, experimental approach to the
102+
same problem [RFC5738].
103+
104+
2. Conventions Used in This Document
105+
106+
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
107+
in this document are to be interpreted as defined in "Key words for
108+
use in RFCs to Indicate Requirement Levels" [RFC2119].
109+
110+
111+
112+
113+
114+
Resnick, et al. Standards Track [Page 2]
115+
116+
RFC 6855 IMAP Support for UTF-8 March 2013
117+
118+
119+
The formal syntax uses the Augmented Backus-Naur Form (ABNF)
120+
[RFC5234] notation. In addition, rules from IMAP [RFC3501], UTF-8
121+
[RFC3629], Extensions to IMAP ABNF [RFC4466], and IMAP "LIST" command
122+
extensions [RFC5258] are also referenced. This document assumes that
123+
the reader will have a reasonably good understanding of these RFCs.
124+
125+
3. "UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP Quoted-Strings
126+
127+
The "UTF8=ACCEPT" capability indicates that the server supports the
128+
ability to open mailboxes containing internationalized messages with
129+
the "SELECT" and "EXAMINE" commands, and the server can provide UTF-8
130+
responses to the "LIST" and "LSUB" commands. This capability also
131+
affects other IMAP extensions that can return mailbox names or their
132+
prefixes, such as NAMESPACE [RFC2342] and ACL [RFC4314].
133+
134+
The "UTF8=ONLY" capability, described in Section 6, implies the
135+
"UTF8=ACCEPT" capability. A server is said to support "UTF8=ACCEPT"
136+
if it advertises either "UTF8=ACCEPT" or "UTF8=ONLY".
137+
138+
A client MUST use the "ENABLE" command [RFC5161] with the
139+
"UTF8=ACCEPT" option (defined in Section 4 below) to indicate to the
140+
server that the client accepts UTF-8 in quoted-strings and supports
141+
the "UTF8=ACCEPT" extension. The "ENABLE UTF8=ACCEPT" command is
142+
only valid in the authenticated state.
143+
144+
The IMAP base specification [RFC3501] forbids the use of 8-bit
145+
characters in atoms or quoted-strings. Thus, a UTF-8 string can only
146+
be sent as a literal. This can be inconvenient from a coding
147+
standpoint, and unless the server offers IMAP non-synchronizing
148+
literals [RFC2088], this requires an extra round trip for each UTF-8
149+
string sent by the client. When the IMAP server supports
150+
"UTF8=ACCEPT", it supports UTF-8 in quoted-strings with the following
151+
syntax:
152+
153+
quoted =/ DQUOTE *uQUOTED-CHAR DQUOTE
154+
; QUOTED-CHAR is not modified, as it will affect
155+
; other RFC 3501 ABNF non-terminals.
156+
157+
uQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4
158+
159+
UTF8-2 = <Defined in Section 4 of RFC 3629>
160+
161+
UTF8-3 = <Defined in Section 4 of RFC 3629>
162+
163+
UTF8-4 = <Defined in Section 4 of RFC 3629>
164+
165+
When this extended quoting mechanism is used by the client, the
166+
server MUST reject, with a "BAD" response, any octet sequences with
167+
168+
169+
170+
Resnick, et al. Standards Track [Page 3]
171+
172+
RFC 6855 IMAP Support for UTF-8 March 2013
173+
174+
175+
the high bit set that fail to comply with the formal syntax
176+
requirements of UTF-8 [RFC3629]. The IMAP server MUST NOT send UTF-8
177+
in quoted-strings to the client unless the client has indicated
178+
support for that syntax by using the "ENABLE UTF8=ACCEPT" command.
179+
180+
If the server supports "UTF8=ACCEPT", the client MAY use extended
181+
quoted syntax with any IMAP argument that permits a string (including
182+
astring and nstring). However, if characters outside the US-ASCII
183+
repertoire are used in an inappropriate place, the results would be
184+
the same as if other syntactically valid but semantically invalid
185+
characters were used. Specific cases where UTF-8 characters are
186+
permitted or not permitted are described in the following paragraphs.
187+
188+
All IMAP servers that support "UTF8=ACCEPT" SHOULD accept UTF-8 in
189+
mailbox names, and those that also support the Mailbox International
190+
Naming Convention described in RFC 3501, Section 5.1.3, MUST accept
191+
UTF8-quoted mailbox names and convert them to the appropriate
192+
internal format. Mailbox names MUST comply with the Net-Unicode
193+
Definition ([RFC5198], Section 2) with the specific exception that
194+
they MUST NOT contain control characters (U+0000-U+001F and U+0080-U+
195+
009F), a delete character (U+007F), a line separator (U+2028), or a
196+
paragraph separator (U+2029).
197+
198+
Once an IMAP client has enabled UTF-8 support with the "ENABLE
199+
UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that
200+
contains a charset specification. If an IMAP server receives such a
201+
"SEARCH" command in that situation, it SHOULD reject the command with
202+
a "BAD" response (due to the conflicting charset labels).
203+
204+
4. IMAP UTF8 "APPEND" Data Extension
205+
206+
If the server supports "UTF8=ACCEPT", then the server accepts UTF-8
207+
headers in the "APPEND" command message argument. A client that
208+
sends a message with UTF-8 headers to the server MUST send them using
209+
the "UTF8" data extension to the "APPEND" command. If the server
210+
also advertises the "CATENATE" capability [RFC4469], the client can
211+
use the same data extension to include such a message in a catenated
212+
message part. The ABNF for the "APPEND" data extension and
213+
"CATENATE" extension follows:
214+
215+
utf8-literal = "UTF8" SP "(" literal8 ")"
216+
217+
literal8 = <Defined in RFC 4466>
218+
219+
append-data =/ utf8-literal
220+
221+
cat-part =/ utf8-literal
222+
223+
224+
225+
226+
Resnick, et al. Standards Track [Page 4]
227+
228+
RFC 6855 IMAP Support for UTF-8 March 2013
229+
230+
231+
If an IMAP server supports "UTF8=ACCEPT" and the IMAP client has not
232+
issued the "ENABLE UTF8=ACCEPT" command, the server MUST reject, with
233+
a "NO" response, an "APPEND" command that includes any 8-bit
234+
character in message header fields.
235+
236+
5. "LOGIN" Command and UTF-8
237+
238+
This specification does not extend the IMAP "LOGIN" command [RFC3501]
239+
to support UTF-8 usernames and passwords. Whenever a client needs to
240+
use UTF-8 usernames or passwords, it MUST use the IMAP "AUTHENTICATE"
241+
command, which is already capable of passing UTF-8 usernames and
242+
credentials.
243+
244+
Although using the IMAP "AUTHENTICATE" command in this way makes it
245+
syntactically legal to have a UTF-8 username or password, there is no
246+
guarantee that the user provisioning system utilized by the IMAP
247+
server will allow such identities. This is an implementation
248+
decision and may depend on what identity system the IMAP server is
249+
configured to use.
250+
251+
6. "UTF8=ONLY" Capability
252+
253+
The "UTF8=ONLY" capability indicates that the server supports
254+
"UTF8=ACCEPT" (see Section 4) and that it requires support for UTF-8
255+
from clients. In particular, this means that the server will send
256+
UTF-8 in quoted-strings, and it will not accept the older
257+
international mailbox name convention (modified UTF-7 [RFC3501]).
258+
Because these are incompatible changes to IMAP, explicit server
259+
announcement and client confirmation is necessary: clients MUST use
260+
the "ENABLE UTF8=ACCEPT" command before using this server. A server
261+
that advertises "UTF8=ONLY" will reject, with a "NO [CANNOT]"
262+
response [RFC5530], any command that might require UTF-8 support and
263+
is not preceded by an "ENABLE UTF8=ACCEPT" command.
264+
265+
IMAP clients that find support for a server that announces
266+
"UTF8=ONLY" problematic are encouraged to at least detect the
267+
announcement and provide an informative error message to the
268+
end-user.
269+
270+
Because the "UTF8=ONLY" server capability includes support for
271+
"UTF8=ACCEPT", the capability string will include, at most, one of
272+
those and never both. For the client, "ENABLE UTF8=ACCEPT" is always
273+
used -- never "ENABLE UTF8=ONLY".
274+
275+
276+
277+
278+
279+
280+
281+
282+
Resnick, et al. Standards Track [Page 5]
283+
284+
RFC 6855 IMAP Support for UTF-8 March 2013
285+
286+
287+
7. Dealing with Legacy Clients
288+
289+
In most situations, it will be difficult or impossible for the
290+
implementer or operator of an IMAP (or POP) server to know whether
291+
all of the clients that might access it, or the associated mail store
292+
more generally, will be able to support the facilities defined in
293+
this document. In almost all cases, servers that conform to this
294+
specification will have to be prepared to deal with clients that do
295+
not enable the relevant capabilities. Unfortunately, there is no
296+
completely satisfactory way to do so other than for systems that wish
297+
to receive email that requires SMTPUTF8 capabilities to be sure that
298+
all components of those systems -- including IMAP and other clients
299+
selected by users -- are upgraded appropriately.
300+
301+
When a message that requires SMTPUTF8 is encountered and the client
302+
does not enable UTF-8 capability, choices available to the server
303+
include hiding the problematic message(s), creating in-band or
304+
out-of-band notifications or error messages, or somehow trying to
305+
create a surrogate of the message with the intention of providing
306+
useful information to that client about what has occurred. Such
307+
surrogate messages cannot be actual substitutes for the original
308+
message: they will almost always be impossible to reply to (either at
309+
all or without loss of information) and the new header fields or
310+
specialized constructs for server-client communications may go beyond
311+
the requirements of current email specifications (e.g., [RFC5322]).
312+
Consequently, such messages may confuse some legacy mail user agents
313+
(including IMAP clients) or not provide expected information to
314+
users. There are also trade-offs in constructing surrogates of the
315+
original message between accepting complexity and additional
316+
computation costs in order to try to preserve as much information as
317+
possible (for example, in "Post-Delivery Message Downgrading for
318+
Internationalized Email Messages" [RFC6857]) and trying to minimize
319+
those costs while still providing useful information (for example, in
320+
"Simplified POP and IMAP Downgrading for Internationalized Email"
321+
[RFC6858]).
322+
323+
Implementations that choose to perform downgrading SHOULD use one of
324+
the standardized algorithms provided in RFC 6857 or RFC 6858.
325+
Getting downgrade algorithms right, and minimizing the risk of
326+
operational problems and harm to the email system, is tricky and
327+
requires careful engineering. These two algorithms are well
328+
understood and carefully designed.
329+
330+
Because such messages are really surrogates of the original ones, not
331+
really "downgraded" ones (although that terminology is often used for
332+
convenience), they inevitably have relationships to the originals
333+
that the IMAP specification [RFC3501] did not anticipate. This
334+
brings up two concerns in particular: First, digital signatures
335+
336+
337+
338+
Resnick, et al. Standards Track [Page 6]
339+
340+
RFC 6855 IMAP Support for UTF-8 March 2013
341+
342+
343+
computed over and intended for the original message will often not be
344+
applicable to the surrogate message, and will often fail signature
345+
verification. (It will be possible for some digital signatures to be
346+
verified, if they cover only parts of the original message that are
347+
not affected in the creation of the surrogate.) Second, servers that
348+
may be accessed by the same user with different clients or methods
349+
(e.g., POP or webmail systems in addition to IMAP or IMAP clients
350+
with different capabilities) will need to exert extreme care to be
351+
sure that UIDVALIDITY [RFC3501] behaves as the user would expect.
352+
Those issues may be especially sensitive if the server caches the
353+
surrogate message or computes and stores it when the message arrives
354+
with the intent of making either form available depending on client
355+
capabilities. Additionally, in order to cope with the case when a
356+
server compliant with this extension returns the same UIDVALIDITY to
357+
both legacy and "UTF8=ACCEPT"-aware clients, a client upgraded from
358+
being non-"UTF8=ACCEPT"-aware MUST discard its cache of messages
359+
downloaded from the server.
360+
361+
The best (or "least bad") approach for any given environment will
362+
depend on local conditions, local assumptions about user behavior,
363+
the degree of control the server operator has over client usage and
364+
upgrading, the options that are actually available, and so on. It is
365+
impossible, at least at the time of publication of this
366+
specification, to give good advice that will apply to all situations,
367+
or even particular profiles of situations, other than "upgrade legacy
368+
clients as soon as possible".
369+
370+
8. Issues with UTF-8 Header Mailstore
371+
372+
When an IMAP server uses a mailbox format that supports UTF-8 headers
373+
and it permits selection or examination of that mailbox without
374+
issuing "ENABLE UTF8=ACCEPT" first, it is the responsibility of the
375+
server to comply with the IMAP base specification [RFC3501] and the
376+
Internet Message Format [RFC5322] with respect to all header
377+
information transmitted over the wire. The issue of handling
378+
messages containing non-ASCII characters in legacy environments is
379+
discussed in Section 7.
380+
381+
382+
383+
384+
385+
386+
387+
388+
389+
390+
391+
392+
393+
394+
Resnick, et al. Standards Track [Page 7]
395+
396+
RFC 6855 IMAP Support for UTF-8 March 2013
397+
398+
399+
9. IANA Considerations
400+
401+
This document redefines two capabilities ("UTF8=ACCEPT" and
402+
"UTF8=ONLY") in the "IMAP 4 Capabilities" registry [RFC3501]. Three
403+
other capabilities that were described in the experimental
404+
predecessor to this document ("UTF8=ALL", "UTF8=APPEND", "UTF8=USER")
405+
are now OBSOLETE. IANA has updated the registry as follows:
406+
407+
OLD:
408+
+--------------+-----------------+
409+
| UTF8=ACCEPT | [RFC5738] |
410+
| UTF8=ALL | [RFC5738] |
411+
| UTF8=APPEND | [RFC5738] |
412+
| UTF8=ONLY | [RFC5738] |
413+
| UTF8=USER | [RFC5738] |
414+
+--------------+-----------------+
415+
416+
417+
NEW:
418+
+------------------------+---------------------+
419+
| UTF8=ACCEPT | [RFC6855] |
420+
| UTF8=ALL (OBSOLETE) | [RFC5738] [RFC6855]|
421+
| UTF8=APPEND (OBSOLETE) | [RFC5738] [RFC6855]|
422+
| UTF8=ONLY | [RFC6855] |
423+
| UTF8=USER (OBSOLETE) | [RFC5738] [RFC6855]|
424+
+------------------------+---------------------+
425+
426+
10. Security Considerations
427+
428+
The security considerations of UTF-8 [RFC3629] and SASLprep [RFC4013]
429+
apply to this specification, particularly with respect to use of
430+
UTF-8 in usernames and passwords. Otherwise, this is not believed to
431+
alter the security considerations of IMAP.
432+
433+
Special considerations, some of them with security implications,
434+
occur if a server that conforms to this specification is accessed by
435+
a client that does not, as well as in some more complex situations in
436+
which a given message is accessed by multiple clients that might use
437+
different protocols and/or support different capabilities. Those
438+
issues are discussed in Section 7.
439+
440+
441+
442+
443+
444+
445+
446+
447+
448+
449+
450+
Resnick, et al. Standards Track [Page 8]
451+
452+
RFC 6855 IMAP Support for UTF-8 March 2013
453+
454+
455+
11. References
456+
457+
11.1. Normative References
458+
459+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
460+
Requirement Levels", BCP 14, RFC 2119, March 1997.
461+
462+
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
463+
4rev1", RFC 3501, March 2003.
464+
465+
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
466+
10646", STD 63, RFC 3629, November 2003.
467+
468+
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
469+
and Passwords", RFC 4013, February 2005.
470+
471+
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
472+
ABNF", RFC 4466, April 2006.
473+
474+
[RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP)
475+
CATENATE Extension", RFC 4469, April 2006.
476+
477+
[RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE
478+
Extension", RFC 5161, March 2008.
479+
480+
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
481+
Interchange", RFC 5198, March 2008.
482+
483+
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
484+
Specifications: ABNF", STD 68, RFC 5234, January 2008.
485+
486+
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
487+
Protocol version 4 - LIST Command Extensions", RFC 5258,
488+
June 2008.
489+
490+
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
491+
October 2008.
492+
493+
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
494+
Internationalized Email", RFC 6530, February 2012.
495+
496+
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
497+
Email Headers", RFC 6532, February 2012.
498+
499+
[RFC6857] Fujiwara, K., "Post-Delivery Message Downgrading for
500+
Internationalized Email Messages", RFC 6857, March 2013.
501+
502+
503+
504+
505+
506+
Resnick, et al. Standards Track [Page 9]
507+
508+
RFC 6855 IMAP Support for UTF-8 March 2013
509+
510+
511+
[RFC6858] Gulbrandsen, A., "Simplified POP and IMAP Downgrading for
512+
Internationalized Email", RFC 6858, March 2013.
513+
514+
11.2. Informative References
515+
516+
[RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
517+
January 1997.
518+
519+
[RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
520+
May 1998.
521+
522+
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
523+
RFC 4314, December 2005.
524+
525+
[RFC5530] Gulbrandsen, A., "IMAP Response Codes", RFC 5530,
526+
May 2009.
527+
528+
[RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8",
529+
RFC 5738, March 2010.
530+
531+
532+
533+
534+
535+
536+
537+
538+
539+
540+
541+
542+
543+
544+
545+
546+
547+
548+
549+
550+
551+
552+
553+
554+
555+
556+
557+
558+
559+
560+
561+
562+
Resnick, et al. Standards Track [Page 10]
563+
564+
RFC 6855 IMAP Support for UTF-8 March 2013
565+
566+
567+
Appendix A. Design Rationale
568+
569+
This non-normative section discusses the reasons behind some of the
570+
design choices in this specification.
571+
572+
The "UTF8=ONLY" mechanism simplifies diagnosis of interoperability
573+
problems when legacy support goes away. In the situation where
574+
backwards compatibility is not working anyway, the non-conforming
575+
"just-send-UTF-8 IMAP" has the advantage that it might work with some
576+
legacy clients. However, the difficulty of diagnosing
577+
interoperability problems caused by a "just-send-UTF-8 IMAP"
578+
mechanism is the reason the "UTF8=ONLY" capability mechanism was
579+
chosen.
580+
581+
Appendix B. Acknowledgments
582+
583+
The authors wish to thank the participants of the EAI working group
584+
for their contributions to this document, with particular thanks to
585+
Harald Alvestrand, David Black, Randall Gellens, Arnt Gulbrandsen,
586+
Kari Hurtta, John Klensin, Xiaodong Lee, Charles Lindsey, Alexey
587+
Melnikov, Subramanian Moonesamy, Shawn Steele, Daniel Taharlev, and
588+
Joseph Yee for their specific contributions to the discussion.
589+
590+
591+
592+
593+
594+
595+
596+
597+
598+
599+
600+
601+
602+
603+
604+
605+
606+
607+
608+
609+
610+
611+
612+
613+
614+
615+
616+
617+
618+
Resnick, et al. Standards Track [Page 11]
619+
620+
RFC 6855 IMAP Support for UTF-8 March 2013
621+
622+
623+
Authors' Addresses
624+
625+
Pete Resnick (editor)
626+
Qualcomm Incorporated
627+
5775 Morehouse Drive
628+
San Diego, CA 92121-1714
629+
USA
630+
631+
Phone: +1 858 651 4478
632+
EMail: presnick@qti.qualcomm.com
633+
634+
635+
Chris Newman (editor)
636+
Oracle
637+
800 Royal Oaks
638+
Monrovia, CA 91016
639+
USA
640+
641+
Phone:
642+
EMail: chris.newman@oracle.com
643+
644+
645+
Sean Shen (editor)
646+
CNNIC
647+
No.4 South 4th Zhongguancun Street
648+
Beijing, 100190
649+
China
650+
651+
Phone: +86 10-58813038
652+
EMail: shenshuo@cnnic.cn
653+
654+
655+
656+
657+
658+
659+
660+
661+
662+
663+
664+
665+
666+
667+
668+
669+
670+
671+
672+
673+
674+
Resnick, et al. Standards Track [Page 12]
675+

‎rfc/rfc6856.txt

+787
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,787 @@
1+
2+
3+
4+
5+
6+
7+
Internet Engineering Task Force (IETF) R. Gellens
8+
Request for Comments: 6856 QUALCOMM Incorporated
9+
Obsoletes: 5721 C. Newman
10+
Category: Standards Track Oracle
11+
ISSN: 2070-1721 J. Yao
12+
CNNIC
13+
K. Fujiwara
14+
JPRS
15+
March 2013
16+
17+
18+
Post Office Protocol Version 3 (POP3) Support for UTF-8
19+
20+
Abstract
21+
22+
This specification extends the Post Office Protocol version 3 (POP3)
23+
to support international strings encoded in UTF-8 in usernames,
24+
passwords, mail addresses, message headers, and protocol-level text
25+
strings.
26+
27+
Status of This Memo
28+
29+
This is an Internet Standards Track document.
30+
31+
This document is a product of the Internet Engineering Task Force
32+
(IETF). It represents the consensus of the IETF community. It has
33+
received public review and has been approved for publication by the
34+
Internet Engineering Steering Group (IESG). Further information on
35+
Internet Standards is available in Section 2 of RFC 5741.
36+
37+
Information about the current status of this document, any errata,
38+
and how to provide feedback on it may be obtained at
39+
http://www.rfc-editor.org/info/rfc6856.
40+
41+
42+
43+
44+
45+
46+
47+
48+
49+
50+
51+
52+
53+
54+
55+
56+
57+
58+
Gellens, et al. Standards Track [Page 1]
59+
60+
RFC 6856 POP3 Support for UTF-8 March 2013
61+
62+
63+
Copyright Notice
64+
65+
Copyright (c) 2013 IETF Trust and the persons identified as the
66+
document authors. All rights reserved.
67+
68+
This document is subject to BCP 78 and the IETF Trust's Legal
69+
Provisions Relating to IETF Documents
70+
(http://trustee.ietf.org/license-info) in effect on the date of
71+
publication of this document. Please review these documents
72+
carefully, as they describe your rights and restrictions with respect
73+
to this document. Code Components extracted from this document must
74+
include Simplified BSD License text as described in Section 4.e of
75+
the Trust Legal Provisions and are provided without warranty as
76+
described in the Simplified BSD License.
77+
78+
This document may contain material from IETF Documents or IETF
79+
Contributions published or made publicly available before November
80+
10, 2008. The person(s) controlling the copyright in some of this
81+
material may not have granted the IETF Trust the right to allow
82+
modifications of such material outside the IETF Standards Process.
83+
Without obtaining an adequate license from the person(s) controlling
84+
the copyright in such materials, this document may not be modified
85+
outside the IETF Standards Process, and derivative works of it may
86+
not be created outside the IETF Standards Process, except to format
87+
it for publication as an RFC or to translate it into languages other
88+
than English.
89+
90+
Table of Contents
91+
92+
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
93+
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
94+
2. "UTF8" Capability . . . . . . . . . . . . . . . . . . . . . . 4
95+
2.1. The "UTF8" Command . . . . . . . . . . . . . . . . . . . . 5
96+
2.2. USER Argument to "UTF8" Capability . . . . . . . . . . . . 6
97+
3. "LANG" Capability . . . . . . . . . . . . . . . . . . . . . . 7
98+
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 7
99+
3.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 7
100+
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
101+
4. Non-ASCII Character Maildrops . . . . . . . . . . . . . . . . 9
102+
5. "UTF8" Response Code . . . . . . . . . . . . . . . . . . . . . 10
103+
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
104+
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
105+
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
106+
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
107+
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
108+
Appendix A. Design Rationale . . . . . . . . . . . . . . . . . . 13
109+
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
110+
111+
112+
113+
114+
Gellens, et al. Standards Track [Page 2]
115+
116+
RFC 6856 POP3 Support for UTF-8 March 2013
117+
118+
119+
1. Introduction
120+
121+
This document forms part of the Email Address Internationalization
122+
protocols described in the Email Address Internationalization
123+
Framework document [RFC6530]. As part of the overall Email Address
124+
Internationalization work, email messages can be transmitted and
125+
delivered containing a Unicode string encoded in UTF-8 in the header
126+
and/or body, and maildrops that are accessed using POP3 [RFC1939]
127+
might natively store Unicode characters.
128+
129+
This specification extends POP3 using the POP3 extension mechanism
130+
[RFC2449] to permit un-encoded UTF-8 [RFC3629] in headers and bodies
131+
(e.g., transferred using 8-bit content-transfer-encoding) as
132+
described in "Internationalized Email Headers" [RFC6532]. It also
133+
adds a mechanism to support login names and passwords containing a
134+
UTF-8 string (see Section 1.1 below), a mechanism to support UTF-8
135+
strings in protocol-level response strings, and the ability to
136+
negotiate a language for such response strings.
137+
138+
This specification also adds a new response code to indicate that a
139+
message was not delivered because it required UTF-8 mode (as
140+
discussed in Section 2) and the server was unable or unwilling to
141+
create and deliver a surrogate form of the message as discussed in
142+
Section 7 of "IMAP Support for UTF-8" [RFC6855].
143+
144+
This specification replaces an earlier, experimental, approach to the
145+
same problem [RFC5721].
146+
147+
1.1. Conventions Used in This Document
148+
149+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
150+
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
151+
document are to be interpreted as described in "Key words for use in
152+
RFCs to Indicate Requirement Levels" [RFC2119].
153+
154+
The terms "UTF-8 string" or "UTF-8 character" are used to refer to
155+
Unicode characters, which may or may not be members of the ASCII
156+
repertoire, encoded in UTF-8 [RFC3629], a standard Unicode encoding
157+
form. All other specialized terms used in this specification are
158+
defined in the Email Address Internationalization framework document.
159+
160+
In examples, "C:" and "S:" indicate lines sent by the client and
161+
server, respectively. If a single "C:" or "S:" label applies to
162+
multiple lines, then the line breaks between those lines are for
163+
editorial clarity only and are not part of the actual protocol
164+
exchange.
165+
166+
167+
168+
169+
170+
Gellens, et al. Standards Track [Page 3]
171+
172+
RFC 6856 POP3 Support for UTF-8 March 2013
173+
174+
175+
Note that examples always use ASCII characters due to limitations of
176+
the RFC format; otherwise, some examples for the "LANG" command would
177+
have appeared incorrectly.
178+
179+
2. "UTF8" Capability
180+
181+
This specification adds a new POP3 Extension [RFC2449] capability
182+
response tag and command to specify support for header field
183+
information outside the ASCII repertoire. The capability tag and new
184+
command and functionality are described below.
185+
186+
CAPA tag:
187+
UTF8
188+
189+
Arguments with CAPA tag:
190+
USER
191+
192+
Added Commands:
193+
UTF8
194+
195+
Standard commands affected:
196+
USER, PASS, APOP, LIST, TOP, RETR
197+
198+
Announced states / possible differences:
199+
both / no
200+
201+
Commands valid in states:
202+
AUTHORIZATION
203+
204+
Specification reference:
205+
this document
206+
207+
Discussion:
208+
209+
This capability adds the "UTF8" command to POP3. The "UTF8" command
210+
switches the session from the ASCII-only mode of POP3 [RFC1939] to
211+
UTF-8 mode. The UTF-8 mode means that all messages transmitted
212+
between servers and clients are UTF-8 strings, and both servers and
213+
clients can send and accept UTF-8 strings.
214+
215+
216+
217+
218+
219+
220+
221+
222+
223+
224+
225+
226+
Gellens, et al. Standards Track [Page 4]
227+
228+
RFC 6856 POP3 Support for UTF-8 March 2013
229+
230+
231+
2.1. The "UTF8" Command
232+
233+
The "UTF8" command enables UTF-8 mode. The "UTF8" command has no
234+
parameters.
235+
236+
UTF-8 mode has no effect on messages in an ASCII-only maildrop.
237+
Messages in native Unicode maildrops can be encoded in UTF-8 using
238+
internationalized headers [RFC6532], in 8bit
239+
content-transfer-encoding (see Section 2.8 of MIME [RFC2045]), in
240+
ASCII, or in any combination of these options. In UTF-8 mode, if the
241+
character encoding format of maildrops is UTF-8 or ASCII, the
242+
messages are sent to the client as is; if the character encoding
243+
format of maildrops is a format other than UTF-8 or ASCII, the
244+
messages' encoding format SHOULD be converted to be UTF-8 before they
245+
are sent to the client. When UTF-8 mode has not been enabled,
246+
character strings outside the ASCII repertoire MUST NOT be sent to
247+
the client as is. If a client requests a UTF-8 message when UTF-8
248+
mode is not enabled, the server MUST either send the client a
249+
surrogate message that complies with unextended POP and Internet Mail
250+
Format without UTF-8 mode support, or fail the request with an -ERR
251+
response. See Section 7 of "IMAP Support for UTF-8" [RFC6855] for
252+
information about creating a surrogate message and for a discussion
253+
of potential issues. Section 5 of this document discusses "UTF8"
254+
response codes. The server MAY respond to the "UTF8" command with an
255+
-ERR response.
256+
257+
Note that even in UTF-8 mode, MIME binary content-transfer-encoding
258+
as defined in Section 6.2 of MIME [RFC2045] is still not permitted.
259+
MIME 8bit content-transfer-encoding (8BITMIME) [RFC6152] is obviously
260+
allowed.
261+
262+
The octet count (size) of a message reported in a response to the
263+
"LIST" command SHOULD match the actual number of octets sent in a
264+
"RETR" response (not counting byte-stuffing). Sizes reported
265+
elsewhere, such as in "STAT" responses and non-standardized,
266+
free-form text in positive status indicators (following "+OK") need
267+
not be accurate, but it is preferable if they are.
268+
269+
Normal operation for maildrops that natively support non-ASCII
270+
characters will be for both servers and clients to support the
271+
extension discussed in this specification. Upgrading both clients
272+
and servers is the only fully satisfactory way to support the
273+
capabilities offered by the "UTF8" extension and SMTPUTF8 mail more
274+
generally. Servers must, however, anticipate the possibility of a
275+
client attempting to access a message that requires this extension
276+
without having issued the "UTF8" command. There are no completely
277+
satisfactory responses for this case other than upgrading the client
278+
to support this specification. One solution, unsatisfactory because
279+
280+
281+
282+
Gellens, et al. Standards Track [Page 5]
283+
284+
RFC 6856 POP3 Support for UTF-8 March 2013
285+
286+
287+
the user may be confused by being able to access the message through
288+
some means and not others, is that a server MAY choose to reject the
289+
command to retrieve the message as discussed in Section 5. Other
290+
alternatives, including the possibility of creating and delivering a
291+
surrogate form of the message, are discussed in Section 7 of "IMAP
292+
Support for UTF-8" [RFC6855].
293+
294+
Clients MUST NOT issue the "STLS" command [RFC2595] after issuing
295+
UTF8; servers MAY (but are not required to) enforce this by rejecting
296+
with an -ERR response an "STLS" command issued subsequent to a
297+
successful "UTF8" command. (Because this is a protocol error as
298+
opposed to a failure based on conditions, an extended response code
299+
[RFC2449] is not specified.)
300+
301+
2.2. USER Argument to "UTF8" Capability
302+
303+
If the USER argument is included with this capability, it indicates
304+
that the server accepts UTF-8 usernames and passwords.
305+
306+
Servers that include the USER argument in the "UTF8" capability
307+
response SHOULD apply SASLprep [RFC4013] or one of its Standards
308+
Track successors to the arguments of the "USER" and "PASS" commands.
309+
310+
A client or server that supports APOP and permits UTF-8 in usernames
311+
or passwords MUST apply SASLprep or one of its Standards Track
312+
successors to the username and password used to compute the APOP
313+
digest.
314+
315+
When applying SASLprep, servers MUST reject UTF-8 usernames or
316+
passwords that contain a UTF-8 character listed in Section 2.3 of
317+
SASLprep. When applying SASLprep to the USER argument, the PASS
318+
argument, or the APOP username argument, a compliant server or client
319+
MUST treat them as a query string [RFC3454]. When applying SASLprep
320+
to the APOP password argument, a compliant server or client MUST
321+
treat them as a stored string [RFC3454].
322+
323+
If the server includes the USER argument in the UTF8 capability
324+
response, the client MAY use UTF-8 characters with a "USER", "PASS",
325+
or "APOP" command; the client MAY do so before issuing the "UTF8"
326+
command. Clients MUST NOT use UTF-8 characters when authenticating
327+
if the server did not include the USER argument in the UTF8
328+
capability response.
329+
330+
The server MUST reject UTF-8 usernames or passwords that fail to
331+
comply with the formal syntax in UTF-8 [RFC3629].
332+
333+
Use of UTF-8 strings in the "AUTH" command is governed by the POP3
334+
SASL [RFC5034] mechanism.
335+
336+
337+
338+
Gellens, et al. Standards Track [Page 6]
339+
340+
RFC 6856 POP3 Support for UTF-8 March 2013
341+
342+
343+
3. "LANG" Capability
344+
345+
This document adds a new POP3 extension [RFC2449] capability response
346+
tag to indicate support for a new command: "LANG".
347+
348+
3.1. Definition
349+
350+
The capability tag and new command are described below.
351+
352+
CAPA tag:
353+
LANG
354+
355+
Arguments with CAPA tag:
356+
none
357+
358+
Added Commands:
359+
LANG
360+
361+
Standard commands affected:
362+
All
363+
364+
Announced states / possible differences:
365+
both / no
366+
367+
Commands valid in states:
368+
AUTHORIZATION, TRANSACTION
369+
370+
Specification reference:
371+
this document
372+
373+
3.2. Discussion
374+
375+
POP3 allows most +OK and -ERR server responses to include human-
376+
readable text that, in some cases, might be presented to the user.
377+
But that text is limited to ASCII by the POP3 specification
378+
[RFC1939]. The "LANG" capability and command permit a POP3 client to
379+
negotiate which language the server uses when sending human-readable
380+
text.
381+
382+
The "LANG" command requests that human-readable text included in all
383+
subsequent +OK and -ERR responses be localized to a language matching
384+
the language range argument (the "basic language range" as described
385+
by the "Matching of Language Tags" [RFC4647]). If the command
386+
succeeds, the server returns a +OK response followed by a single
387+
space, the exact language tag selected, and another space. Human-
388+
readable text in the appropriate language then appears in the rest of
389+
the line. This, and subsequent protocol-level human-readable text,
390+
is encoded in the UTF-8 charset.
391+
392+
393+
394+
Gellens, et al. Standards Track [Page 7]
395+
396+
RFC 6856 POP3 Support for UTF-8 March 2013
397+
398+
399+
If the command fails, the server returns an -ERR response and
400+
subsequent human-readable response text continues to use the language
401+
that was previously used.
402+
403+
If the client issues a "LANG" command with the special "*" language
404+
range argument, it indicates a request to use a language designated
405+
as preferred by the server administrator. The preferred language MAY
406+
vary based on the currently active user.
407+
408+
If no argument is given and the POP3 server issues a positive
409+
response, that response will usually consist of multiple lines.
410+
After the initial +OK, for each language tag the server supports, the
411+
POP3 server responds with a line for that language. This line is
412+
called a "language listing".
413+
414+
In order to simplify parsing, all POP3 servers are required to use a
415+
certain format for language listings. A language listing consists of
416+
the language tag [RFC5646] of the message, optionally followed by a
417+
single space and a human-readable description of the language in the
418+
language itself, using the UTF-8 charset. There is no specific order
419+
to the listing of languages; the order may depend on configuration or
420+
implementation.
421+
422+
3.3. Examples
423+
424+
Examples for "LANG" capability usage are shown below.
425+
426+
Note that some examples do not include the correct character
427+
accents due to limitations of the RFC format.
428+
429+
C: USER karen
430+
S: +OK Hello, karen
431+
C: PASS password
432+
S: +OK karen's maildrop contains 2 messages (320 octets)
433+
434+
Client requests deprecated MUL language [ISO639-2]. Server
435+
replies with -ERR response.
436+
437+
C: LANG MUL
438+
S: -ERR invalid language MUL
439+
440+
441+
442+
443+
444+
445+
446+
447+
448+
449+
450+
Gellens, et al. Standards Track [Page 8]
451+
452+
RFC 6856 POP3 Support for UTF-8 March 2013
453+
454+
455+
A LANG command with no parameters is a request for
456+
a language listing.
457+
458+
C: LANG
459+
S: +OK Language listing follows:
460+
S: en English
461+
S: en-boont English Boontling dialect
462+
S: de Deutsch
463+
S: it Italiano
464+
S: es Espanol
465+
S: sv Svenska
466+
S: .
467+
468+
A request for a language listing might fail.
469+
470+
C: LANG
471+
S: -ERR Server is unable to list languages
472+
473+
Once the client selects the language, all responses will be in
474+
that language, starting with the response to the "LANG" command.
475+
476+
C: LANG es
477+
S: +OK es Idioma cambiado
478+
479+
If a server returns an -ERR response to a "LANG" command
480+
that specifies a primary language, the current language
481+
for responses remains in effect.
482+
483+
C: LANG uga
484+
S: -ERR es Idioma <<UGA>> no es conocido
485+
486+
C: LANG sv
487+
S: +OK sv Kommandot "LANG" lyckades
488+
489+
C: LANG *
490+
S: +OK es Idioma cambiado
491+
492+
4. Non-ASCII Character Maildrops
493+
494+
When a POP3 server uses a native non-ASCII character maildrop, it is
495+
the responsibility of the server to comply with the POP3 base
496+
specification [RFC1939] and Internet Message Format [RFC5322] when
497+
not in UTF-8 mode. When the server is not in UTF-8 mode and the
498+
message requires that mode, requests to download the message MAY be
499+
rejected (as specified in the next section) or the various
500+
alternatives outlined in Section 2.1 above, including creation and
501+
delivery of surrogates for the original message, MAY be considered.
502+
503+
504+
505+
506+
Gellens, et al. Standards Track [Page 9]
507+
508+
RFC 6856 POP3 Support for UTF-8 March 2013
509+
510+
511+
5. "UTF8" Response Code
512+
513+
Per "POP3 Extension Mechanism" [RFC2449], this document adds a new
514+
response code: UTF8, described below.
515+
516+
Complete response code:
517+
UTF8
518+
519+
Valid for responses:
520+
-ERR
521+
522+
Valid for commands:
523+
LIST, TOP, RETR
524+
525+
Response code meaning and expected client behavior:
526+
The "UTF8" response code indicates that a failure is due to a
527+
request for message content that contains a UTF-8 string when the
528+
client is not in UTF-8 mode.
529+
530+
The client MAY reissue the command after entering UTF-8 mode.
531+
532+
6. IANA Considerations
533+
534+
Sections 2 and 3 of this specification update two capabilities
535+
("UTF8" and "LANG") in the POP3 capability registry [RFC2449].
536+
537+
Section 5 of this specification adds one new response code ("UTF8")
538+
to the POP3 response codes registry [RFC2449].
539+
540+
7. Security Considerations
541+
542+
The security considerations of UTF-8 [RFC3629], SASLprep [RFC4013],
543+
and the Unicode Format for Network Interchange [RFC5198] apply to
544+
this specification, particularly with respect to use of UTF-8 strings
545+
in usernames and passwords.
546+
547+
The "LANG *" command might reveal the existence and preferred
548+
language of a user to an active attacker probing the system if the
549+
active language changes in response to the "USER", "PASS", or "APOP"
550+
commands prior to validating the user's credentials. Servers are
551+
strongly advised to implement a configuration to prevent this
552+
exposure.
553+
554+
It is possible for a man-in-the-middle attacker to insert a "LANG"
555+
command in the command stream, thus, making protocol-level diagnostic
556+
responses unintelligible to the user. A mechanism to protect the
557+
558+
559+
560+
561+
562+
Gellens, et al. Standards Track [Page 10]
563+
564+
RFC 6856 POP3 Support for UTF-8 March 2013
565+
566+
567+
integrity of the session can be used to defeat such attacks. For
568+
example, a client can issue the "STLS" command [RFC2595] before
569+
issuing the "LANG" command.
570+
571+
As with other internationalization upgrades, modifications to server
572+
authentication code (in this case, to support non-ASCII strings) need
573+
to be done with care to avoid introducing vulnerabilities (for
574+
example, in string parsing or matching). This is particularly
575+
important if the native databases or mailstore of the operating
576+
system use some character set or encoding other than Unicode in
577+
UTF-8.
578+
579+
8. References
580+
581+
8.1. Normative References
582+
583+
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version
584+
3", STD 53, RFC 1939, May 1996.
585+
586+
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
587+
Extensions (MIME) Part One: Format of Internet Message
588+
Bodies", RFC 2045, November 1996.
589+
590+
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
591+
Part Three: Message Header Extensions for Non-ASCII
592+
Text", RFC 2047, November 1996.
593+
594+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
595+
Requirement Levels", BCP 14, RFC 2119, March 1997.
596+
597+
[RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3
598+
Extension Mechanism", RFC 2449, November 1998.
599+
600+
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
601+
Internationalized Strings ("stringprep")", RFC 3454,
602+
December 2002.
603+
604+
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
605+
10646", STD 63, RFC 3629, November 2003.
606+
607+
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
608+
Names and Passwords", RFC 4013, February 2005.
609+
610+
[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags",
611+
BCP 47, RFC 4647, September 2006.
612+
613+
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
614+
Interchange", RFC 5198, March 2008.
615+
616+
617+
618+
Gellens, et al. Standards Track [Page 11]
619+
620+
RFC 6856 POP3 Support for UTF-8 March 2013
621+
622+
623+
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
624+
October 2008.
625+
626+
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
627+
Languages", BCP 47, RFC 5646, September 2009.
628+
629+
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
630+
Service Extension for 8-bit MIME Transport", STD 71,
631+
RFC 6152, March 2011.
632+
633+
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
634+
Internationalized Email", RFC 6530, February 2012.
635+
636+
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
637+
Email Headers", RFC 6532, February 2012.
638+
639+
[RFC6855] Resnick, P., Newman, C., and S. Shen, "IMAP Support for
640+
UTF-8", RFC 6855, March 2013.
641+
642+
8.2. Informative References
643+
644+
[ISO639-2] International Organization for Standardization, "ISO
645+
639-2:1998. Codes for the representation of names of
646+
languages -- Part 2: Alpha-3 code", October 1998.
647+
648+
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
649+
Word Extensions:
650+
Character Sets, Languages, and Continuations", RFC 2231,
651+
November 1997.
652+
653+
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
654+
RFC 2595, June 1999.
655+
656+
[RFC5034] Siemborski, R. and A. Menon-Sen, "The Post Office
657+
Protocol (POP3) Simple Authentication and Security Layer
658+
(SASL) Authentication Mechanism", RFC 5034, July 2007.
659+
660+
[RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8",
661+
RFC 5721, February 2010.
662+
663+
664+
665+
666+
667+
668+
669+
670+
671+
672+
673+
674+
Gellens, et al. Standards Track [Page 12]
675+
676+
RFC 6856 POP3 Support for UTF-8 March 2013
677+
678+
679+
Appendix A. Design Rationale
680+
681+
This non-normative section discusses the reasons behind some of the
682+
design choices in this specification.
683+
684+
Due to interoperability problems with the MIME Message Header
685+
Extensions [RFC2047] and limited deployment of the extended MIME
686+
parameter encodings [RFC2231], it is hoped these 7-bit encoding
687+
mechanisms can be deprecated in the future when UTF-8 header support
688+
becomes prevalent.
689+
690+
The USER capability (Section 2.2) and hence the upgraded "USER"
691+
command and additional support for non-ASCII credentials, are
692+
optional because the implementation burden of SASLprep [RFC4013] is
693+
not well understood, and mandating such support in all cases could
694+
negatively impact deployment.
695+
696+
Appendix B. Acknowledgments
697+
698+
Thanks to John Klensin, Joseph Yee, Tony Hansen, Alexey Melnikov, and
699+
other Email Address Internationalization working group participants
700+
who provided helpful suggestions and interesting debate that improved
701+
this specification.
702+
703+
704+
705+
706+
707+
708+
709+
710+
711+
712+
713+
714+
715+
716+
717+
718+
719+
720+
721+
722+
723+
724+
725+
726+
727+
728+
729+
730+
Gellens, et al. Standards Track [Page 13]
731+
732+
RFC 6856 POP3 Support for UTF-8 March 2013
733+
734+
735+
Authors' Addresses
736+
737+
Randall Gellens
738+
QUALCOMM Incorporated
739+
5775 Morehouse Drive
740+
San Diego, CA 92651
741+
USA
742+
743+
EMail: rg+ietf@qualcomm.com
744+
745+
746+
Chris Newman
747+
Oracle
748+
800 Royal Oaks
749+
Monrovia, CA 91016-6347
750+
USA
751+
752+
EMail: chris.newman@oracle.com
753+
754+
755+
Jiankang YAO
756+
CNNIC
757+
No.4 South 4th Street, Zhongguancun
758+
Beijing
759+
China
760+
761+
Phone: +86 10 58813007
762+
EMail: yaojk@cnnic.cn
763+
764+
765+
Kazunori Fujiwara
766+
Japan Registry Services Co., Ltd.
767+
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
768+
Tokyo
769+
Japan
770+
771+
Phone: +81 3 5215 8451
772+
EMail: fujiwara@jprs.co.jp
773+
774+
775+
776+
777+
778+
779+
780+
781+
782+
783+
784+
785+
786+
Gellens, et al. Standards Track [Page 14]
787+

0 commit comments

Comments
 (0)
Please sign in to comment.