| rev |
line source |
|
yuuji@0
|
1
|
|
yuuji@0
|
2
|
|
yuuji@0
|
3
|
|
yuuji@0
|
4
|
|
yuuji@0
|
5
|
|
yuuji@0
|
6
|
|
yuuji@0
|
7 Network Working Group M. Gahrns
|
|
yuuji@0
|
8 Request for Comments: 3348 R. Cheng
|
|
yuuji@0
|
9 Category: Informational Microsoft
|
|
yuuji@0
|
10 July 2002
|
|
yuuji@0
|
11
|
|
yuuji@0
|
12
|
|
yuuji@0
|
13 The Internet Message Action Protocol (IMAP4)
|
|
yuuji@0
|
14 Child Mailbox Extension
|
|
yuuji@0
|
15
|
|
yuuji@0
|
16 Status of this Memo
|
|
yuuji@0
|
17
|
|
yuuji@0
|
18 This memo provides information for the Internet community. It does
|
|
yuuji@0
|
19 not specify an Internet standard of any kind. Distribution of this
|
|
yuuji@0
|
20 memo is unlimited.
|
|
yuuji@0
|
21
|
|
yuuji@0
|
22 Copyright Notice
|
|
yuuji@0
|
23
|
|
yuuji@0
|
24 Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|
yuuji@0
|
25
|
|
yuuji@0
|
26 Abstract
|
|
yuuji@0
|
27
|
|
yuuji@0
|
28 The Internet Message Action Protocol (IMAP4) CHILDREN extension
|
|
yuuji@0
|
29 provides a mechanism for a client to efficiently determine if a
|
|
yuuji@0
|
30 particular mailbox has children, without issuing a LIST "" * or a
|
|
yuuji@0
|
31 LIST "" % for each mailbox.
|
|
yuuji@0
|
32
|
|
yuuji@0
|
33 1. Conventions used in this document
|
|
yuuji@0
|
34
|
|
yuuji@0
|
35 In examples, "C:" and "S:" indicate lines sent by the client and
|
|
yuuji@0
|
36 server respectively. If such lines are wrapped without a new "C:" or
|
|
yuuji@0
|
37 "S:" label, then the wrapping is for editorial clarity and is not
|
|
yuuji@0
|
38 part of the command.
|
|
yuuji@0
|
39
|
|
yuuji@0
|
40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
yuuji@0
|
41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
yuuji@0
|
42 document are to be interpreted as described in [RFC-2119].
|
|
yuuji@0
|
43
|
|
yuuji@0
|
44 2. Introduction and Overview
|
|
yuuji@0
|
45
|
|
yuuji@0
|
46 Many IMAP4 [RFC-2060] clients present to the user a hierarchical view
|
|
yuuji@0
|
47 of the mailboxes that a user has access to. Rather than initially
|
|
yuuji@0
|
48 presenting to the user the entire mailbox hierarchy, it is often
|
|
yuuji@0
|
49 preferable to show to the user a collapsed outline list of the
|
|
yuuji@0
|
50 mailbox hierarchy (particularly if there is a large number of
|
|
yuuji@0
|
51 mailboxes). The user can then expand the collapsed outline hierarchy
|
|
yuuji@0
|
52 as needed. It is common to include within the collapsed hierarchy a
|
|
yuuji@0
|
53
|
|
yuuji@0
|
54
|
|
yuuji@0
|
55
|
|
yuuji@0
|
56
|
|
yuuji@0
|
57
|
|
yuuji@0
|
58 Gahrns, et al. Informational [Page 1]
|
|
yuuji@0
|
59
|
|
yuuji@0
|
60 RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
|
yuuji@0
|
61
|
|
yuuji@0
|
62
|
|
yuuji@0
|
63 visual clue (such as a "+") to indicate that there are child
|
|
yuuji@0
|
64 mailboxes under a particular mailbox. When the visual clue is
|
|
yuuji@0
|
65 clicked the hierarchy list is expanded to show the child mailboxes.
|
|
yuuji@0
|
66
|
|
yuuji@0
|
67 Several IMAP vendors implemented this proposal, and it is proposed to
|
|
yuuji@0
|
68 document this behavior and functionality as an Informational RFC.
|
|
yuuji@0
|
69
|
|
yuuji@0
|
70 There is interest in addressing the general extensibility of the IMAP
|
|
yuuji@0
|
71 LIST command through an IMAP LIST Extension draft. Similar
|
|
yuuji@0
|
72 functionality to the \HasChildren and \HasNoChildren flags could be
|
|
yuuji@0
|
73 incorporated into this new LIST Extension. It is proposed that the
|
|
yuuji@0
|
74 more general LIST Extension draft proceed on the standards track with
|
|
yuuji@0
|
75 this proposal being relegated to informational status only.
|
|
yuuji@0
|
76
|
|
yuuji@0
|
77 If the functionality of the \HasChildren and \HasNoChildren flags
|
|
yuuji@0
|
78 were incorporated into a more general LIST extension, this would have
|
|
yuuji@0
|
79 the advantage that a client could then have the opportunity to
|
|
yuuji@0
|
80 request whether or not the server should return this information.
|
|
yuuji@0
|
81 This would be an advantage over the current draft for servers where
|
|
yuuji@0
|
82 this information is expensive to compute, since the server would only
|
|
yuuji@0
|
83 need to compute the information when it knew that the client
|
|
yuuji@0
|
84 requesting the information was able to consume it.
|
|
yuuji@0
|
85
|
|
yuuji@0
|
86 3. Requirements
|
|
yuuji@0
|
87
|
|
yuuji@0
|
88 IMAP4 servers that support this extension MUST list the keyword
|
|
yuuji@0
|
89 CHILDREN in their CAPABILITY response.
|
|
yuuji@0
|
90
|
|
yuuji@0
|
91 The CHILDREN extension defines two new attributes that MAY be
|
|
yuuji@0
|
92 returned within a LIST response.
|
|
yuuji@0
|
93
|
|
yuuji@0
|
94 \HasChildren - The presence of this attribute indicates that the
|
|
yuuji@0
|
95 mailbox has child mailboxes.
|
|
yuuji@0
|
96
|
|
yuuji@0
|
97 Servers SHOULD NOT return \HasChildren if child mailboxes exist, but
|
|
yuuji@0
|
98 none will be displayed to the current user in a LIST response (as
|
|
yuuji@0
|
99 should be the case where child mailboxes exist, but a client does not
|
|
yuuji@0
|
100 have permissions to access them.) In this case, \HasNoChildren
|
|
yuuji@0
|
101 SHOULD be used.
|
|
yuuji@0
|
102
|
|
yuuji@0
|
103 In many cases, however, a server may not be able to efficiently
|
|
yuuji@0
|
104 compute whether a user has access to all child mailboxes, or multiple
|
|
yuuji@0
|
105 users may be accessing the same account and simultaneously changing
|
|
yuuji@0
|
106 the mailbox hierarchy. As such a client MUST be prepared to accept
|
|
yuuji@0
|
107 the \HasChildren attribute as a hint. That is, a mailbox MAY be
|
|
yuuji@0
|
108 flagged with the \HasChildren attribute, but no child mailboxes will
|
|
yuuji@0
|
109 appear in a subsequent LIST response.
|
|
yuuji@0
|
110
|
|
yuuji@0
|
111
|
|
yuuji@0
|
112
|
|
yuuji@0
|
113
|
|
yuuji@0
|
114 Gahrns, et al. Informational [Page 2]
|
|
yuuji@0
|
115
|
|
yuuji@0
|
116 RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
|
yuuji@0
|
117
|
|
yuuji@0
|
118
|
|
yuuji@0
|
119 Example 3.1:
|
|
yuuji@0
|
120 ============
|
|
yuuji@0
|
121
|
|
yuuji@0
|
122 /*** Consider a server that has the following mailbox hierarchy:
|
|
yuuji@0
|
123
|
|
yuuji@0
|
124 INBOX
|
|
yuuji@0
|
125 ITEM_1
|
|
yuuji@0
|
126 ITEM_1A
|
|
yuuji@0
|
127 ITEM_2
|
|
yuuji@0
|
128 TOP_SECRET
|
|
yuuji@0
|
129
|
|
yuuji@0
|
130 Where INBOX, ITEM_1 and ITEM_2 are top level mailboxes. ITEM_1A is a
|
|
yuuji@0
|
131 child mailbox of ITEM_1 and TOP_SECRET is a child mailbox of ITEM_2
|
|
yuuji@0
|
132 that the currently logged on user does NOT have access to.
|
|
yuuji@0
|
133
|
|
yuuji@0
|
134 Note that in this case, the server is not able to efficiently compute
|
|
yuuji@0
|
135 access rights to child mailboxes and responds with a \HasChildren
|
|
yuuji@0
|
136 attribute for mailbox ITEM_2, even though ITEM_2/TOP_SECRET does not
|
|
yuuji@0
|
137 appear in the list response. ***/
|
|
yuuji@0
|
138
|
|
yuuji@0
|
139 C: A001 LIST "" *
|
|
yuuji@0
|
140 S: * LIST (\HasNoChildren) "/" INBOX
|
|
yuuji@0
|
141 S: * LIST (\HasChildren) "/" ITEM_1
|
|
yuuji@0
|
142 S: * LIST (\HasNoChildren) "/" ITEM_1/ITEM_1A
|
|
yuuji@0
|
143 S: * LIST (\HasChildren) "/" ITEM_2
|
|
yuuji@0
|
144 S: A001 OK LIST Completed
|
|
yuuji@0
|
145
|
|
yuuji@0
|
146 \HasNoChildren - The presence of this attribute indicates that the
|
|
yuuji@0
|
147 mailbox has NO child mailboxes that are accessible to the currently
|
|
yuuji@0
|
148 authenticated user. If a mailbox has the \Noinferiors attribute, the
|
|
yuuji@0
|
149 \HasNoChildren attribute is redundant and SHOULD be omitted in the
|
|
yuuji@0
|
150 LIST response.
|
|
yuuji@0
|
151
|
|
yuuji@0
|
152 In some instances a server that supports the CHILDREN extension MAY
|
|
yuuji@0
|
153 NOT be able to determine whether a mailbox has children. For example
|
|
yuuji@0
|
154 it may have difficulty determining whether there are child mailboxes
|
|
yuuji@0
|
155 when LISTing mailboxes while operating in a particular namespace.
|
|
yuuji@0
|
156
|
|
yuuji@0
|
157 In these cases, a server MAY exclude both the \HasChildren and
|
|
yuuji@0
|
158 \HasNoChildren attributes in the LIST response. As such, a client
|
|
yuuji@0
|
159 can not make any assumptions about whether a mailbox has children
|
|
yuuji@0
|
160 based upon the absence of a single attribute.
|
|
yuuji@0
|
161
|
|
yuuji@0
|
162 It is an error for the server to return both a \HasChildren and a
|
|
yuuji@0
|
163 \HasNoChildren attribute in a LIST response.
|
|
yuuji@0
|
164
|
|
yuuji@0
|
165
|
|
yuuji@0
|
166
|
|
yuuji@0
|
167
|
|
yuuji@0
|
168
|
|
yuuji@0
|
169
|
|
yuuji@0
|
170 Gahrns, et al. Informational [Page 3]
|
|
yuuji@0
|
171
|
|
yuuji@0
|
172 RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
|
yuuji@0
|
173
|
|
yuuji@0
|
174
|
|
yuuji@0
|
175 It is an error for the server to return both a \HasChildren and a
|
|
yuuji@0
|
176 \NoInferiors attribute in a LIST response.
|
|
yuuji@0
|
177
|
|
yuuji@0
|
178 Note: the \HasNoChildren attribute should not be confused with the
|
|
yuuji@0
|
179 IMAP4 [RFC-2060] defined attribute \Noinferiors which indicates that
|
|
yuuji@0
|
180 no child mailboxes exist now and none can be created in the future.
|
|
yuuji@0
|
181
|
|
yuuji@0
|
182 The \HasChildren and \HasNoChildren attributes might not be returned
|
|
yuuji@0
|
183 in response to a LSUB response. Many servers maintain a simple
|
|
yuuji@0
|
184 mailbox subscription list that is not updated when the underlying
|
|
yuuji@0
|
185 mailbox structure is changed. A client MUST NOT assume that
|
|
yuuji@0
|
186 hierarchy information will be maintained in the subscription list.
|
|
yuuji@0
|
187
|
|
yuuji@0
|
188 RLIST is a command defined in [RFC-2193] that includes in a LIST
|
|
yuuji@0
|
189 response mailboxes that are accessible only via referral. That is, a
|
|
yuuji@0
|
190 client must explicitly issue an RLIST command to see a list of these
|
|
yuuji@0
|
191 mailboxes. Thus in the case where a mailbox has child mailboxes that
|
|
yuuji@0
|
192 are available only via referral, the mailboxes would appear as
|
|
yuuji@0
|
193 \HasNoChildren in response to the LIST command, and \HasChildren in
|
|
yuuji@0
|
194 response to the RLIST command.
|
|
yuuji@0
|
195
|
|
yuuji@0
|
196 5. Formal Syntax
|
|
yuuji@0
|
197
|
|
yuuji@0
|
198 The following syntax specification uses the augmented Backus-Naur
|
|
yuuji@0
|
199 Form (BNF) as described in [ABNF].
|
|
yuuji@0
|
200
|
|
yuuji@0
|
201 Two new mailbox attributes are defined as flag_extensions to the
|
|
yuuji@0
|
202 IMAP4 mailbox_list response:
|
|
yuuji@0
|
203
|
|
yuuji@0
|
204 HasChildren = "\HasChildren"
|
|
yuuji@0
|
205
|
|
yuuji@0
|
206 HasNoChildren = "\HasNoChildren"
|
|
yuuji@0
|
207
|
|
yuuji@0
|
208 6. Security Considerations
|
|
yuuji@0
|
209
|
|
yuuji@0
|
210 This extension provides a client a more efficient means of
|
|
yuuji@0
|
211 determining whether a particular mailbox has children. If a mailbox
|
|
yuuji@0
|
212 has children, but the currently authenticated user does not have
|
|
yuuji@0
|
213 access to any of them, the server SHOULD respond with a
|
|
yuuji@0
|
214 \HasNoChildren attribute. In many cases, however, a server may not
|
|
yuuji@0
|
215 be able to efficiently compute whether a user has access to all child
|
|
yuuji@0
|
216 mailboxes. If such a server responds with a \HasChildren attribute,
|
|
yuuji@0
|
217 when in fact the currently authenticated user does not have access to
|
|
yuuji@0
|
218 any child mailboxes, potentially more information is conveyed about
|
|
yuuji@0
|
219 the mailbox than intended. A server designed with such levels of
|
|
yuuji@0
|
220 security in mind SHOULD NOT attach the \HasChildren attribute to a
|
|
yuuji@0
|
221 mailbox unless the server is certain that the user has access to at
|
|
yuuji@0
|
222 least one of the child mailboxes.
|
|
yuuji@0
|
223
|
|
yuuji@0
|
224
|
|
yuuji@0
|
225
|
|
yuuji@0
|
226 Gahrns, et al. Informational [Page 4]
|
|
yuuji@0
|
227
|
|
yuuji@0
|
228 RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
|
yuuji@0
|
229
|
|
yuuji@0
|
230
|
|
yuuji@0
|
231 7. References
|
|
yuuji@0
|
232
|
|
yuuji@0
|
233 [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version
|
|
yuuji@0
|
234 4rev1", RFC 2060, December 1996.
|
|
yuuji@0
|
235
|
|
yuuji@0
|
236 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
yuuji@0
|
237 Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
yuuji@0
|
238
|
|
yuuji@0
|
239 [RFC-2234] Crocker, D. and P. Overell, Editors, "Augmented BNF for
|
|
yuuji@0
|
240 Syntax Specifications: ABNF", RFC 2234, November 1997.
|
|
yuuji@0
|
241
|
|
yuuji@0
|
242 [RFC-2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September
|
|
yuuji@0
|
243 1997.
|
|
yuuji@0
|
244
|
|
yuuji@0
|
245 8. Acknowledgments
|
|
yuuji@0
|
246
|
|
yuuji@0
|
247 The authors would like to thank the participants of several IMC Mail
|
|
yuuji@0
|
248 Connect events for their input when this idea was originally
|
|
yuuji@0
|
249 presented and refined.
|
|
yuuji@0
|
250
|
|
yuuji@0
|
251 9. Author's Address
|
|
yuuji@0
|
252
|
|
yuuji@0
|
253 Mike Gahrns
|
|
yuuji@0
|
254 Microsoft
|
|
yuuji@0
|
255 One Microsoft Way
|
|
yuuji@0
|
256 Redmond, WA, 98052
|
|
yuuji@0
|
257 Phone: (425) 936-9833
|
|
yuuji@0
|
258 EMail: mikega@microsoft.com
|
|
yuuji@0
|
259
|
|
yuuji@0
|
260 Raymond Cheng
|
|
yuuji@0
|
261 Microsoft
|
|
yuuji@0
|
262 One Microsoft Way
|
|
yuuji@0
|
263 Redmond, WA, 98052
|
|
yuuji@0
|
264 Phone: (425) 703-4913
|
|
yuuji@0
|
265 EMail: raych@microsoft.com
|
|
yuuji@0
|
266
|
|
yuuji@0
|
267
|
|
yuuji@0
|
268
|
|
yuuji@0
|
269
|
|
yuuji@0
|
270
|
|
yuuji@0
|
271
|
|
yuuji@0
|
272
|
|
yuuji@0
|
273
|
|
yuuji@0
|
274
|
|
yuuji@0
|
275
|
|
yuuji@0
|
276
|
|
yuuji@0
|
277
|
|
yuuji@0
|
278
|
|
yuuji@0
|
279
|
|
yuuji@0
|
280
|
|
yuuji@0
|
281
|
|
yuuji@0
|
282 Gahrns, et al. Informational [Page 5]
|
|
yuuji@0
|
283
|
|
yuuji@0
|
284 RFC 3348 IMAP4 Child Mailbox Extension July 2002
|
|
yuuji@0
|
285
|
|
yuuji@0
|
286
|
|
yuuji@0
|
287 10. Full Copyright Statement
|
|
yuuji@0
|
288
|
|
yuuji@0
|
289 Copyright (C) The Internet Society (2002). All Rights Reserved.
|
|
yuuji@0
|
290
|
|
yuuji@0
|
291 This document and translations of it may be copied and furnished to
|
|
yuuji@0
|
292 others, and derivative works that comment on or otherwise explain it
|
|
yuuji@0
|
293 or assist in its implementation may be prepared, copied, published
|
|
yuuji@0
|
294 and distributed, in whole or in part, without restriction of any
|
|
yuuji@0
|
295 kind, provided that the above copyright notice and this paragraph are
|
|
yuuji@0
|
296 included on all such copies and derivative works. However, this
|
|
yuuji@0
|
297 document itself may not be modified in any way, such as by removing
|
|
yuuji@0
|
298 the copyright notice or references to the Internet Society or other
|
|
yuuji@0
|
299 Internet organizations, except as needed for the purpose of
|
|
yuuji@0
|
300 developing Internet standards in which case the procedures for
|
|
yuuji@0
|
301 copyrights defined in the Internet Standards process must be
|
|
yuuji@0
|
302 followed, or as required to translate it into languages other than
|
|
yuuji@0
|
303 English.
|
|
yuuji@0
|
304
|
|
yuuji@0
|
305 The limited permissions granted above are perpetual and will not be
|
|
yuuji@0
|
306 revoked by the Internet Society or its successors or assigns.
|
|
yuuji@0
|
307
|
|
yuuji@0
|
308 This document and the information contained herein is provided on an
|
|
yuuji@0
|
309 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|
yuuji@0
|
310 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|
yuuji@0
|
311 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|
yuuji@0
|
312 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|
yuuji@0
|
313 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
yuuji@0
|
314
|
|
yuuji@0
|
315 Acknowledgement
|
|
yuuji@0
|
316
|
|
yuuji@0
|
317 Funding for the RFC Editor function is currently provided by the
|
|
yuuji@0
|
318 Internet Society.
|
|
yuuji@0
|
319
|
|
yuuji@0
|
320
|
|
yuuji@0
|
321
|
|
yuuji@0
|
322
|
|
yuuji@0
|
323
|
|
yuuji@0
|
324
|
|
yuuji@0
|
325
|
|
yuuji@0
|
326
|
|
yuuji@0
|
327
|
|
yuuji@0
|
328
|
|
yuuji@0
|
329
|
|
yuuji@0
|
330
|
|
yuuji@0
|
331
|
|
yuuji@0
|
332
|
|
yuuji@0
|
333
|
|
yuuji@0
|
334
|
|
yuuji@0
|
335
|
|
yuuji@0
|
336
|
|
yuuji@0
|
337
|
|
yuuji@0
|
338 Gahrns, et al. Informational [Page 6]
|
|
yuuji@0
|
339
|
