| 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 A. Gulbrandsen, Ed.
|
|
yuuji@0
|
8 Request for Comments: 5161 Oryx Mail Systems GmbH
|
|
yuuji@0
|
9 Category: Standards Track A. Melnikov, Ed.
|
|
yuuji@0
|
10 Isode Limited
|
|
yuuji@0
|
11 March 2008
|
|
yuuji@0
|
12
|
|
yuuji@0
|
13
|
|
yuuji@0
|
14 The IMAP ENABLE Extension
|
|
yuuji@0
|
15
|
|
yuuji@0
|
16 Status of This Memo
|
|
yuuji@0
|
17
|
|
yuuji@0
|
18 This document specifies an Internet standards track protocol for the
|
|
yuuji@0
|
19 Internet community, and requests discussion and suggestions for
|
|
yuuji@0
|
20 improvements. Please refer to the current edition of the "Internet
|
|
yuuji@0
|
21 Official Protocol Standards" (STD 1) for the standardization state
|
|
yuuji@0
|
22 and status of this protocol. Distribution of this memo is unlimited.
|
|
yuuji@0
|
23
|
|
yuuji@0
|
24 Abstract
|
|
yuuji@0
|
25
|
|
yuuji@0
|
26 Most IMAP extensions are used by the client when it wants to and the
|
|
yuuji@0
|
27 server supports it. However, a few extensions require the server to
|
|
yuuji@0
|
28 know whether a client supports that extension. The ENABLE extension
|
|
yuuji@0
|
29 allows an IMAP client to say which extensions it supports.
|
|
yuuji@0
|
30
|
|
yuuji@0
|
31 1. Overview
|
|
yuuji@0
|
32
|
|
yuuji@0
|
33 Several IMAP extensions allow the server to return unsolicited
|
|
yuuji@0
|
34 responses specific to these extensions in certain circumstances.
|
|
yuuji@0
|
35 However, servers cannot send those unsolicited responses until they
|
|
yuuji@0
|
36 know that the clients support such extensions and thus won't choke on
|
|
yuuji@0
|
37 the extension response data.
|
|
yuuji@0
|
38
|
|
yuuji@0
|
39 Up until now, extensions have typically stated that a server cannot
|
|
yuuji@0
|
40 send the unsolicited responses until after the client has used a
|
|
yuuji@0
|
41 command with the extension data (i.e., at that point the server knows
|
|
yuuji@0
|
42 the client is aware of the extension). CONDSTORE ([RFC4551]),
|
|
yuuji@0
|
43 ANNOTATE ([ANNOTATE]), and some extensions under consideration at the
|
|
yuuji@0
|
44 moment use various commands to enable server extensions. For
|
|
yuuji@0
|
45 example, CONDSTORE uses a SELECT or FETCH parameter, and ANNOTATE
|
|
yuuji@0
|
46 uses a side effect of FETCH.
|
|
yuuji@0
|
47
|
|
yuuji@0
|
48 The ENABLE extension provides an explicit indication from the client
|
|
yuuji@0
|
49 that it supports particular extensions. This is done using a new
|
|
yuuji@0
|
50 ENABLE command.
|
|
yuuji@0
|
51
|
|
yuuji@0
|
52 An IMAP server that supports ENABLE advertises this by including the
|
|
yuuji@0
|
53 word ENABLE in its capability list.
|
|
yuuji@0
|
54
|
|
yuuji@0
|
55
|
|
yuuji@0
|
56
|
|
yuuji@0
|
57
|
|
yuuji@0
|
58 Gulbrandsen & Melnikov Standards Track [Page 1]
|
|
yuuji@0
|
59
|
|
yuuji@0
|
60 RFC 5161 The IMAP ENABLE Extension March 2008
|
|
yuuji@0
|
61
|
|
yuuji@0
|
62
|
|
yuuji@0
|
63 Most IMAP extensions do not require the client to enable the
|
|
yuuji@0
|
64 extension in any way.
|
|
yuuji@0
|
65
|
|
yuuji@0
|
66 2. Conventions Used in This Document
|
|
yuuji@0
|
67
|
|
yuuji@0
|
68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
yuuji@0
|
69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
yuuji@0
|
70 document are to be interpreted as described in [RFC2119].
|
|
yuuji@0
|
71
|
|
yuuji@0
|
72 Formal syntax is defined by [RFC5234] and [RFC3501].
|
|
yuuji@0
|
73
|
|
yuuji@0
|
74 Example lines prefaced by "C:" are sent by the client and ones
|
|
yuuji@0
|
75 prefaced by "S:" by the server. The five characters [...] means that
|
|
yuuji@0
|
76 something has been elided.
|
|
yuuji@0
|
77
|
|
yuuji@0
|
78 3. Protocol Changes
|
|
yuuji@0
|
79
|
|
yuuji@0
|
80 3.1. The ENABLE Command
|
|
yuuji@0
|
81
|
|
yuuji@0
|
82 Arguments: capability names
|
|
yuuji@0
|
83
|
|
yuuji@0
|
84 Result: OK: Relevant capabilities enabled
|
|
yuuji@0
|
85 BAD: No arguments, or syntax error in an argument
|
|
yuuji@0
|
86
|
|
yuuji@0
|
87 The ENABLE command takes a list of capability names, and requests the
|
|
yuuji@0
|
88 server to enable the named extensions. Once enabled using ENABLE,
|
|
yuuji@0
|
89 each extension remains active until the IMAP connection is closed.
|
|
yuuji@0
|
90 For each argument, the server does the following:
|
|
yuuji@0
|
91
|
|
yuuji@0
|
92 - If the argument is not an extension known to the server, the server
|
|
yuuji@0
|
93 MUST ignore the argument.
|
|
yuuji@0
|
94
|
|
yuuji@0
|
95 - If the argument is an extension known to the server, and it is not
|
|
yuuji@0
|
96 specifically permitted to be enabled using ENABLE, the server MUST
|
|
yuuji@0
|
97 ignore the argument. (Note that knowing about an extension doesn't
|
|
yuuji@0
|
98 necessarily imply supporting that extension.)
|
|
yuuji@0
|
99
|
|
yuuji@0
|
100 - If the argument is an extension that is supported by the server and
|
|
yuuji@0
|
101 that needs to be enabled, the server MUST enable the extension for
|
|
yuuji@0
|
102 the duration of the connection. At present, this applies only to
|
|
yuuji@0
|
103 CONDSTORE ([RFC4551]). Note that once an extension is enabled,
|
|
yuuji@0
|
104 there is no way to disable it.
|
|
yuuji@0
|
105
|
|
yuuji@0
|
106 If the ENABLE command is successful, the server MUST send an untagged
|
|
yuuji@0
|
107 ENABLED response (see Section 3.2).
|
|
yuuji@0
|
108
|
|
yuuji@0
|
109
|
|
yuuji@0
|
110
|
|
yuuji@0
|
111
|
|
yuuji@0
|
112
|
|
yuuji@0
|
113
|
|
yuuji@0
|
114 Gulbrandsen & Melnikov Standards Track [Page 2]
|
|
yuuji@0
|
115
|
|
yuuji@0
|
116 RFC 5161 The IMAP ENABLE Extension March 2008
|
|
yuuji@0
|
117
|
|
yuuji@0
|
118
|
|
yuuji@0
|
119 Clients SHOULD only include extensions that need to be enabled by the
|
|
yuuji@0
|
120 server. At the time of publication, CONDSTORE is the only such
|
|
yuuji@0
|
121 extension (i.e., ENABLE CONDSTORE is an additional "CONDSTORE
|
|
yuuji@0
|
122 enabling command" as defined in [RFC4551]). Future RFCs may add to
|
|
yuuji@0
|
123 this list.
|
|
yuuji@0
|
124
|
|
yuuji@0
|
125 The ENABLE command is only valid in the authenticated state (see
|
|
yuuji@0
|
126 [RFC3501]), before any mailbox is selected. Clients MUST NOT issue
|
|
yuuji@0
|
127 ENABLE once they SELECT/EXAMINE a mailbox; however, server
|
|
yuuji@0
|
128 implementations don't have to check that no mailbox is selected or
|
|
yuuji@0
|
129 was previously selected during the duration of a connection.
|
|
yuuji@0
|
130
|
|
yuuji@0
|
131 The ENABLE command can be issued multiple times in a session. It is
|
|
yuuji@0
|
132 additive; i.e., "ENABLE a b", followed by "ENABLE c" is the same as a
|
|
yuuji@0
|
133 single command "ENABLE a b c". When multiple ENABLE commands are
|
|
yuuji@0
|
134 issued, each corresponding ENABLED response SHOULD only contain
|
|
yuuji@0
|
135 extensions enabled by the corresponding ENABLE command.
|
|
yuuji@0
|
136
|
|
yuuji@0
|
137 There are no limitations on pipelining ENABLE. For example, it is
|
|
yuuji@0
|
138 possible to send ENABLE and then immediately SELECT, or a LOGIN
|
|
yuuji@0
|
139 immediately followed by ENABLE.
|
|
yuuji@0
|
140
|
|
yuuji@0
|
141 The server MUST NOT change the CAPABILITY list as a result of
|
|
yuuji@0
|
142 executing ENABLE; i.e., a CAPABILITY command issued right after an
|
|
yuuji@0
|
143 ENABLE command MUST list the same capabilities as a CAPABILITY
|
|
yuuji@0
|
144 command issued before the ENABLE command. This is demonstrated in
|
|
yuuji@0
|
145 the following example:
|
|
yuuji@0
|
146
|
|
yuuji@0
|
147 C: t1 CAPABILITY
|
|
yuuji@0
|
148 S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
|
|
yuuji@0
|
149 S: t1 OK foo
|
|
yuuji@0
|
150 C: t2 ENABLE CONDSTORE X-GOOD-IDEA
|
|
yuuji@0
|
151 S: * ENABLED X-GOOD-IDEA
|
|
yuuji@0
|
152 S: t2 OK foo
|
|
yuuji@0
|
153 C: t3 CAPABILITY
|
|
yuuji@0
|
154 S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
|
|
yuuji@0
|
155 S: t3 OK foo again
|
|
yuuji@0
|
156
|
|
yuuji@0
|
157 In the following example, the client enables CONDSTORE:
|
|
yuuji@0
|
158
|
|
yuuji@0
|
159 C: a1 ENABLE CONDSTORE
|
|
yuuji@0
|
160 S: * ENABLED CONDSTORE
|
|
yuuji@0
|
161 S: a1 OK Conditional Store enabled
|
|
yuuji@0
|
162
|
|
yuuji@0
|
163
|
|
yuuji@0
|
164
|
|
yuuji@0
|
165
|
|
yuuji@0
|
166
|
|
yuuji@0
|
167
|
|
yuuji@0
|
168
|
|
yuuji@0
|
169
|
|
yuuji@0
|
170 Gulbrandsen & Melnikov Standards Track [Page 3]
|
|
yuuji@0
|
171
|
|
yuuji@0
|
172 RFC 5161 The IMAP ENABLE Extension March 2008
|
|
yuuji@0
|
173
|
|
yuuji@0
|
174
|
|
yuuji@0
|
175 3.2. The ENABLED Response
|
|
yuuji@0
|
176
|
|
yuuji@0
|
177 Contents: capability listing
|
|
yuuji@0
|
178
|
|
yuuji@0
|
179 The ENABLED response occurs as a result of an ENABLE command. The
|
|
yuuji@0
|
180 capability listing contains a space-separated listing of capability
|
|
yuuji@0
|
181 names that the server supports and that were successfully enabled.
|
|
yuuji@0
|
182 The ENABLED response may contain no capabilities, which means that no
|
|
yuuji@0
|
183 extensions listed by the client were successfully enabled.
|
|
yuuji@0
|
184
|
|
yuuji@0
|
185 3.3. Note to Designers of Extensions That May Use the ENABLE Command
|
|
yuuji@0
|
186
|
|
yuuji@0
|
187 Designers of IMAP extensions are discouraged from creating extensions
|
|
yuuji@0
|
188 that require ENABLE unless there is no good alternative design.
|
|
yuuji@0
|
189 Specifically, extensions that cause potentially incompatible behavior
|
|
yuuji@0
|
190 changes to deployed server responses (and thus benefit from ENABLE)
|
|
yuuji@0
|
191 have a higher complexity cost than extensions that do not.
|
|
yuuji@0
|
192
|
|
yuuji@0
|
193 4. Formal Syntax
|
|
yuuji@0
|
194
|
|
yuuji@0
|
195 The following syntax specification uses the Augmented Backus-Naur
|
|
yuuji@0
|
196 Form (ABNF) notation as specified in [RFC5234] including the core
|
|
yuuji@0
|
197 rules in Appendix B.1. [RFC3501] defines the non-terminals
|
|
yuuji@0
|
198 "capability" and "command-any".
|
|
yuuji@0
|
199
|
|
yuuji@0
|
200 Except as noted otherwise, all alphabetic characters are
|
|
yuuji@0
|
201 case-insensitive. The use of upper or lower case characters to
|
|
yuuji@0
|
202 define token strings is for editorial clarity only. Implementations
|
|
yuuji@0
|
203 MUST accept these strings in a case-insensitive fashion.
|
|
yuuji@0
|
204
|
|
yuuji@0
|
205 capability =/ "ENABLE"
|
|
yuuji@0
|
206
|
|
yuuji@0
|
207 command-any =/ "ENABLE" 1*(SP capability)
|
|
yuuji@0
|
208
|
|
yuuji@0
|
209 response-data =/ "*" SP enable-data CRLF
|
|
yuuji@0
|
210
|
|
yuuji@0
|
211 enable-data = "ENABLED" *(SP capability)
|
|
yuuji@0
|
212
|
|
yuuji@0
|
213 5. Security Considerations
|
|
yuuji@0
|
214
|
|
yuuji@0
|
215 It is believed that this extension doesn't add any security
|
|
yuuji@0
|
216 considerations that are not already present in the base IMAP protocol
|
|
yuuji@0
|
217 [RFC3501].
|
|
yuuji@0
|
218
|
|
yuuji@0
|
219 6. IANA Considerations
|
|
yuuji@0
|
220
|
|
yuuji@0
|
221 The IANA has added ENABLE to the IMAP4 Capabilities Registry.
|
|
yuuji@0
|
222
|
|
yuuji@0
|
223
|
|
yuuji@0
|
224
|
|
yuuji@0
|
225
|
|
yuuji@0
|
226 Gulbrandsen & Melnikov Standards Track [Page 4]
|
|
yuuji@0
|
227
|
|
yuuji@0
|
228 RFC 5161 The IMAP ENABLE Extension March 2008
|
|
yuuji@0
|
229
|
|
yuuji@0
|
230
|
|
yuuji@0
|
231 7. Acknowledgments
|
|
yuuji@0
|
232
|
|
yuuji@0
|
233 The editors would like to thank Randy Gellens, Chris Newman, Peter
|
|
yuuji@0
|
234 Coates, Dave Cridland, Mark Crispin, Ned Freed, Dan Karp, Cyrus
|
|
yuuji@0
|
235 Daboo, Ken Murchison, and Eric Burger for comments and corrections.
|
|
yuuji@0
|
236 However, this doesn't necessarily mean that they endorse this
|
|
yuuji@0
|
237 extension, agree with all details, or are responsible for errors
|
|
yuuji@0
|
238 introduced by the editors.
|
|
yuuji@0
|
239
|
|
yuuji@0
|
240 8. Normative References
|
|
yuuji@0
|
241
|
|
yuuji@0
|
242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
yuuji@0
|
243 Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
yuuji@0
|
244
|
|
yuuji@0
|
245 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
|
|
yuuji@0
|
246 4rev1", RFC 3501, March 2003.
|
|
yuuji@0
|
247
|
|
yuuji@0
|
248 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
|
|
yuuji@0
|
249 Syntax Specifications: ABNF", STD 68, RFC 5234, January
|
|
yuuji@0
|
250 2008.
|
|
yuuji@0
|
251
|
|
yuuji@0
|
252 [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
|
|
yuuji@0
|
253 STORE Operation or Quick Flag Changes Resynchronization",
|
|
yuuji@0
|
254 RFC 4551, June 2006.
|
|
yuuji@0
|
255
|
|
yuuji@0
|
256 9. Informative References
|
|
yuuji@0
|
257
|
|
yuuji@0
|
258 [ANNOTATE] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work
|
|
yuuji@0
|
259 in Progress, August 2006.
|
|
yuuji@0
|
260
|
|
yuuji@0
|
261
|
|
yuuji@0
|
262
|
|
yuuji@0
|
263
|
|
yuuji@0
|
264
|
|
yuuji@0
|
265
|
|
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 Gulbrandsen & Melnikov Standards Track [Page 5]
|
|
yuuji@0
|
283
|
|
yuuji@0
|
284 RFC 5161 The IMAP ENABLE Extension March 2008
|
|
yuuji@0
|
285
|
|
yuuji@0
|
286
|
|
yuuji@0
|
287 Editors' Addresses
|
|
yuuji@0
|
288
|
|
yuuji@0
|
289 Arnt Gulbrandsen
|
|
yuuji@0
|
290 Oryx Mail Systems GmbH
|
|
yuuji@0
|
291 Schweppermannstr. 8
|
|
yuuji@0
|
292 D-81671 Muenchen
|
|
yuuji@0
|
293 Germany
|
|
yuuji@0
|
294
|
|
yuuji@0
|
295 Fax: +49 89 4502 9758
|
|
yuuji@0
|
296 EMail: arnt@oryx.com
|
|
yuuji@0
|
297
|
|
yuuji@0
|
298
|
|
yuuji@0
|
299 Alexey Melnikov
|
|
yuuji@0
|
300 Isode Ltd
|
|
yuuji@0
|
301 5 Castle Business Village
|
|
yuuji@0
|
302 36 Station Road
|
|
yuuji@0
|
303 Hampton, Middlesex TW12 2BX
|
|
yuuji@0
|
304 UK
|
|
yuuji@0
|
305
|
|
yuuji@0
|
306 EMail: Alexey.Melnikov@isode.com
|
|
yuuji@0
|
307
|
|
yuuji@0
|
308
|
|
yuuji@0
|
309
|
|
yuuji@0
|
310
|
|
yuuji@0
|
311
|
|
yuuji@0
|
312
|
|
yuuji@0
|
313
|
|
yuuji@0
|
314
|
|
yuuji@0
|
315
|
|
yuuji@0
|
316
|
|
yuuji@0
|
317
|
|
yuuji@0
|
318
|
|
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 Gulbrandsen & Melnikov Standards Track [Page 6]
|
|
yuuji@0
|
339
|
|
yuuji@0
|
340 RFC 5161 The IMAP ENABLE Extension March 2008
|
|
yuuji@0
|
341
|
|
yuuji@0
|
342
|
|
yuuji@0
|
343 Full Copyright Statement
|
|
yuuji@0
|
344
|
|
yuuji@0
|
345 Copyright (C) The IETF Trust (2008).
|
|
yuuji@0
|
346
|
|
yuuji@0
|
347 This document is subject to the rights, licenses and restrictions
|
|
yuuji@0
|
348 contained in BCP 78, and except as set forth therein, the authors
|
|
yuuji@0
|
349 retain all their rights.
|
|
yuuji@0
|
350
|
|
yuuji@0
|
351 This document and the information contained herein are provided on an
|
|
yuuji@0
|
352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|
yuuji@0
|
353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
|
yuuji@0
|
354 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
|
yuuji@0
|
355 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
|
yuuji@0
|
356 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|
yuuji@0
|
357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
yuuji@0
|
358
|
|
yuuji@0
|
359 Intellectual Property
|
|
yuuji@0
|
360
|
|
yuuji@0
|
361 The IETF takes no position regarding the validity or scope of any
|
|
yuuji@0
|
362 Intellectual Property Rights or other rights that might be claimed to
|
|
yuuji@0
|
363 pertain to the implementation or use of the technology described in
|
|
yuuji@0
|
364 this document or the extent to which any license under such rights
|
|
yuuji@0
|
365 might or might not be available; nor does it represent that it has
|
|
yuuji@0
|
366 made any independent effort to identify any such rights. Information
|
|
yuuji@0
|
367 on the procedures with respect to rights in RFC documents can be
|
|
yuuji@0
|
368 found in BCP 78 and BCP 79.
|
|
yuuji@0
|
369
|
|
yuuji@0
|
370 Copies of IPR disclosures made to the IETF Secretariat and any
|
|
yuuji@0
|
371 assurances of licenses to be made available, or the result of an
|
|
yuuji@0
|
372 attempt made to obtain a general license or permission for the use of
|
|
yuuji@0
|
373 such proprietary rights by implementers or users of this
|
|
yuuji@0
|
374 specification can be obtained from the IETF on-line IPR repository at
|
|
yuuji@0
|
375 http://www.ietf.org/ipr.
|
|
yuuji@0
|
376
|
|
yuuji@0
|
377 The IETF invites any interested party to bring to its attention any
|
|
yuuji@0
|
378 copyrights, patents or patent applications, or other proprietary
|
|
yuuji@0
|
379 rights that may cover technology that may be required to implement
|
|
yuuji@0
|
380 this standard. Please address the information to the IETF at
|
|
yuuji@0
|
381 ietf-ipr@ietf.org.
|
|
yuuji@0
|
382
|
|
yuuji@0
|
383
|
|
yuuji@0
|
384
|
|
yuuji@0
|
385
|
|
yuuji@0
|
386
|
|
yuuji@0
|
387
|
|
yuuji@0
|
388
|
|
yuuji@0
|
389
|
|
yuuji@0
|
390
|
|
yuuji@0
|
391
|
|
yuuji@0
|
392
|
|
yuuji@0
|
393
|
|
yuuji@0
|
394 Gulbrandsen & Melnikov Standards Track [Page 7]
|
|
yuuji@0
|
395
|
