1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
|
IMAP4r1 Mailbox Names vs. Unicode
=================================
:author: Matthias_Andree_(ed.)_and_Mark_Crispin
:email: matthias.andree@gmx.de
:author initials: MA and MC
:revision: 0.2
:revdate: 2010-05-26
:toc:
:data-uri:
:icons:
:numbered:
''''
.Acknowledgment
****
This article would not have been possible without the
substantial contributions from Mark Crispin.
— Matthias Andree, editor
****
.Abstract
****
IMAP4rev1 is a widely used Internet Standards Track Protocol for remote
email access. Its adoption to international environments posed
interpretation problems as the construction and interpretation of
mailbox names, it particularly raised the question if there was
contractictory information within IMAP4rev1.
This article describes the problem, and shows that IMAP4rev1 is
consistent with respect to mailbox names. We document how the evolution
of Unicode character sets and transformation formats made the
interpretation of the IMAP4rev1 standard difficult, and how it is to
interpret properly.
Finally, we show that UTF-7, which is used in IMAP4rev1 to encode
mailbox names, does not impose artificial restrictions on the Unicode
character set.
****
== IMAP Mailbox Names in RFC-3501
In May 2010, some confusion arose on the getmail mailing list around a bug
report to Debian that complained getmail4 wouldn't allow non-ASCII characters
in an IMAP folder name http://bugs.debian.org/513116[Debian Bug#513116], and
the interpretation of support of international mailbox names
vs. http://tools.ietf.org/html/rfc3501[RFC-3501]. It seemed at first
glance that IMAP4rev1 were limited to the Basic Multilingual Plane of
Unicode.
=== Problem statement
Notably, RFC-3501 mandates that mailbox names are 7-bit, however clients are
supposed to accept 8-bit data and interpret it as UTF-8. This is apparently
contradictory or extraneous, because 7-bit ASCII data need not be encoded.
Let us look at the IMAP4rev1 standard:
[quote, Mark Crispin, RFC3501]
____
5.1. Mailbox Naming
Mailbox names are 7-bit. Client implementations MUST NOT attempt to
create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox names
returned by LIST or LSUB as UTF-8. Server implementations SHOULD
prohibit the creation of 8-bit mailbox names, and SHOULD NOT return
8-bit mailbox names in LIST or LSUB. See section 5.1.3 for more
information on how to represent non-ASCII mailbox names. [...]
____
[quote, Mark Crispin, RFC3501]
____
5.1.3. Mailbox International Naming Convention
By convention, international mailbox names in IMAP4rev1 are specified
using a modified version of the UTF-7 encoding described in [UTF-7].
Modified UTF-7 may also be usable in servers that implement an earlier
version of this protocol. [...]
____
This appears to be contradictory, because UTF-7 is not UTF-8. However, a UTF-7
mailbox name is not an 8-bit mailbox name, hence the clause "interpret any
8-bit mailbox names ... as UTF-8" does not apply. Mark writes:
=== Clarification
_by Mark Crispin_
8-bit octets are prohibited in mailbox names. Clients MUST use 7-bit
names, and servers MUST reject CREATE commands that contain 8-bit
octets.
However, clients MUST also interpret any 8-bit names in a list of
mailbox names (from LIST or LSUB) as UTF-8.
To understand the history here, we must go back to the 1990s where
people (in spite of being told not to do so) were writing IMAP2 clients
and servers which used ISO-8859-1 and Shift-JIS mailbox names. At that
time, it was by no means certain that UTF-8 would become the standard
Internet character set; I played an important role in making that
happen, but that was still a few years in the future.
The adoption of UTF-8 offered a chance to exterminate non-UTF-8 8-bit
mailbox names, and in 1996 the current rules were adopted. The
transition to IMAP4 (which required substantial changes to any IMAP2
servers) provided an opportunity to exterminate these non-interoperable
names once and for all.
The modified UTF-7 was a temporary expedient to allow non-ASCII mailbox
names while remaining with the 7-bit framework. Had punycode existed at
the time, it would have been a much better choice than UTF-7. But
punycode did not exist for several years later with IDN. In fact,
punycode was created because people learned the problems of UTF-7 from
IMAP.
The intent was always to move to a UTF-8 only environment and leave
behind UTF-7. When that happens, clients will start encountering UTF-8
names. It is therefore necessary to tell clients that, even though they
are not permitted to send them, they need to be written to handle them
so they work properly when the restriction is relaxed in the future.
=== Recommendations
_by Mark Crispin_
*Options for server implementors*
From the perspective of a server implementor, you have one of two choices
of how to implement MUTF-7:
footnote:[editor's note: Modified UTF-7 as specified by the ensemble of RFC-2152 and RFC-3501]
[horizontal]
[S1]:: Ignore it; just forbid 8-bit octets in the CREATE command.
[S2]:: Convert mailbox names in commands from MUTF-7 to UTF-8. When doing a
LIST or LSUB, convert mailbox names from UTF-8 to MUTF-7 before sending
them to the client.
Servers of type [S1] were far more common in the 1990s. [S2] is more
common today. However, a client neither knows, nor cares, which type of
server it is because the rules make both servers interoperate the same.
*Options for client implementors*
[horizontal]
[C1]:: Ignore it; you're an ASCII client.
[C2]:: Convert mailbox names from UTF-8 to MUTF-7 when sending a command.
When receiving a listing of mailboxes, convert MUTF-7 to UTF-8.
This all works, and works well. The routines to do the conversions are
quite straightforward. The only thing that you can't do well are mixed
wildcards with strings with non-ASCII names; and that is primarily a
curiousity since no clients do that with ASCII names.
== Unicode, UCS-2, UTF-16, and UTF-7
.Incomplete specification:
WARNING: This section and its subsections are not normative references,
and are insufficient to implement UCS-2, UTF-16 or UTF-7 based
software.
=== UCS-2 and UTF-16
_by Mark Crispin_
RFC-3501 uses http://tools.ietf.org/html/rfc2152[RFC-2152] by reference.
Some of the confusion on the getmail list arose from the fact that
RFC-2152 talks about UCS-2 representation, which is limited to the Basic
Multilingual Plane (BMP) range U+0000 to U+FFFF.
However, RFC-2152 also (page 5) refers to the handling of surrogate
pairs, which are defined in UTF-16 but not UCS-2.
The correct interpretation is that the wording in RFC-2152 was written
at a time when "UCS-2" was interpreted as a synonym for "16-bit value"
as opposed to "BMP-only codepoints". This happens frequently in older
standards. Since UTF-7 is deprecated, nobody has done the work to
update RFC-2152 to clarify this point.
Using surrogate pairs extends the capability of 16-bit words beyond the
BMP range.
The 0x0000 to 0xFFFF range comprises so-called surrogates, two character
ranges (0xD800 to 0xDBFF and 0xDC00 to 0xDFFF) of 1024 characters (2^10^)
each. These ranges are technically removed from the BMP (thus there is
no such thing as U+D800); and hence the BMP only contains 64,512
possible codepoints.
Both UTF-7 and UTF-16 transformation leverages these ranges to map
Unicode code points in the range from U+010000 to U+10FFFF (which is the
highest Unicode code point) to a pair of UCS-2 characters in the
surrogates ranges.
This happens by first subtracting 0x10000, which maps the input into the
range 0x0 to 0xFFFFF, representable in 20 bits. The most significant
10-bit portion is mapped into the range 0xD800…0xDBFF, the least
significant 10-bit portion into the range 0xDC00…0xDFFF, and these two
16-bit values are used in this order. UTF-7 does a further step of
encoding in modified BASE64.
Thus, UTF-7 and UTF-16 both deal with ``16-bit values'' and use the same
surrogate pair mechanism to access non-BMP codepoints. Although not
strictly accurate (the two are technically independent encodings of
Unicode), it may be helpful to think of UTF-7 as a further encoding of
UTF-16.
=== UTF-7
UTF-7 is a 7-bit representation of Unicode that makes use of character set
shifting. A character that is directly representable represents itself. Other
characters are subjected to a modified BASE64-encoding (that omits the padding
"=" characters at the end of a group) which is preceded by a "+" character
and trailed by a "-" character, which is discarded, or any other character
not in the modified BASE64 set, which remains in the stream.
As a special case, the sequence "\+-" is a shorthand to represent
the "+" character itself.
The modified BASE64 character set uses the characters A-Z, a-z, digits 0-9,
and the characters "+" and "/", omitting "=" to avoid collisions with
RFC-2047 encoding.
=== Modified UTF-7
This works similar to UTF-7, but mandates that printable ASCII characters
0x20...0x7E except 0x26 (the ampersand "&") represent themselves, and uses yet
another BASE64 alphabet consisting of the upper- and lowercase letters, the
digits, and the characters "+" and ",", with some further rules specified in
RFC-3501.
== Conclusions
IMAP Clients that want to support international mailbox names should send UTF-7,
and be prepared to handle UTF-7 (if no 8-bit data is found) and UTF-8 (if
8-bit data is found).
Modified UTF-7 as per the IMAP RFC #3501 is not limited to the Unicode Basic
Multilingual Plane, but maps the entire Unicode range.
|
