| 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. Crispin
|
|
yuuji@0
|
8 Request for Comments: 3502 University of Washington
|
|
yuuji@0
|
9 Category: Standards Track March 2003
|
|
yuuji@0
|
10
|
|
yuuji@0
|
11
|
|
yuuji@0
|
12 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
|
|
yuuji@0
|
13
|
|
yuuji@0
|
14 Status of this Memo
|
|
yuuji@0
|
15
|
|
yuuji@0
|
16 This document specifies an Internet standards track protocol for the
|
|
yuuji@0
|
17 Internet community, and requests discussion and suggestions for
|
|
yuuji@0
|
18 improvements. Please refer to the current edition of the "Internet
|
|
yuuji@0
|
19 Official Protocol Standards" (STD 1) for the standardization state
|
|
yuuji@0
|
20 and status of this protocol. Distribution of this memo is unlimited.
|
|
yuuji@0
|
21
|
|
yuuji@0
|
22 Copyright Notice
|
|
yuuji@0
|
23
|
|
yuuji@0
|
24 Copyright (C) The Internet Society (2003). All Rights Reserved.
|
|
yuuji@0
|
25
|
|
yuuji@0
|
26 Abstract
|
|
yuuji@0
|
27
|
|
yuuji@0
|
28 This document describes the multiappending extension to the Internet
|
|
yuuji@0
|
29 Message Access Protocol (IMAP) (RFC 3501). This extension provides
|
|
yuuji@0
|
30 substantial performance improvements for IMAP clients which upload
|
|
yuuji@0
|
31 multiple messages at a time to a mailbox on the server.
|
|
yuuji@0
|
32
|
|
yuuji@0
|
33 A server which supports this extension indicates this with a
|
|
yuuji@0
|
34 capability name of "MULTIAPPEND".
|
|
yuuji@0
|
35
|
|
yuuji@0
|
36 Terminology
|
|
yuuji@0
|
37
|
|
yuuji@0
|
38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
yuuji@0
|
39 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
|
|
yuuji@0
|
40 be interpreted as described in [KEYWORDS].
|
|
yuuji@0
|
41
|
|
yuuji@0
|
42 Introduction
|
|
yuuji@0
|
43
|
|
yuuji@0
|
44 The MULTIAPPEND extension permits uploading of multiple messages with
|
|
yuuji@0
|
45 a single command. When used in conjunction with the [LITERAL+]
|
|
yuuji@0
|
46 extension, the entire upload is accomplished in a single
|
|
yuuji@0
|
47 command/response round trip.
|
|
yuuji@0
|
48
|
|
yuuji@0
|
49 A MULTIAPPEND APPEND operation is atomic; either all messages are
|
|
yuuji@0
|
50 successfully appended, or no messages are appended.
|
|
yuuji@0
|
51
|
|
yuuji@0
|
52 In the base IMAP specification, each message must be appended in a
|
|
yuuji@0
|
53 separate command, and there is no mechanism to "unappend" messages if
|
|
yuuji@0
|
54 an error occurs while appending. Also, some mail stores may require
|
|
yuuji@0
|
55
|
|
yuuji@0
|
56
|
|
yuuji@0
|
57
|
|
yuuji@0
|
58 Crispin Standards Track [Page 1]
|
|
yuuji@0
|
59
|
|
yuuji@0
|
60 RFC 3502 IMAP MULTIAPPEND March 2003
|
|
yuuji@0
|
61
|
|
yuuji@0
|
62
|
|
yuuji@0
|
63 an expensive "open/lock + sync/unlock/close" operation as part of
|
|
yuuji@0
|
64 appending; this can be quite expensive if it must be done on a
|
|
yuuji@0
|
65 per-message basis.
|
|
yuuji@0
|
66
|
|
yuuji@0
|
67 If the server supports both LITERAL+ and pipelining but not
|
|
yuuji@0
|
68 MULTIAPPEND, it may be possible to get some of the performance
|
|
yuuji@0
|
69 advantages of MULTIAPPEND by doing a pipelined "batch" append.
|
|
yuuji@0
|
70 However, it will not work as well as MULTIAPPEND for the following
|
|
yuuji@0
|
71 reasons:
|
|
yuuji@0
|
72
|
|
yuuji@0
|
73 1) Multiple APPEND commands, even as part of a pipelined batch,
|
|
yuuji@0
|
74 are non-atomic by definition. There is no way to revert the
|
|
yuuji@0
|
75 mailbox to the state before the batch append in the event of an
|
|
yuuji@0
|
76 error.
|
|
yuuji@0
|
77
|
|
yuuji@0
|
78 2) It may not be feasible for the server to coalesce pipelined
|
|
yuuji@0
|
79 APPEND operations so as to avoid the "open/lock +
|
|
yuuji@0
|
80 sync/unlock/close" overhead described above. In any case, such
|
|
yuuji@0
|
81 coalescing would be timing dependent and thus potentially
|
|
yuuji@0
|
82 unreliable. In particular, with traditional UNIX mailbox files,
|
|
yuuji@0
|
83 it is assumed that a lock is held only for a single atomic
|
|
yuuji@0
|
84 operation, and many applications disregard any lock that is
|
|
yuuji@0
|
85 older than 5 minutes.
|
|
yuuji@0
|
86
|
|
yuuji@0
|
87 3) If an error occurs, depending upon the nature of the error,
|
|
yuuji@0
|
88 it is possible for additional messages to be appended after the
|
|
yuuji@0
|
89 error. For example, the user wants to append 5 messages, but a
|
|
yuuji@0
|
90 disk quota error occurs with the third message because of its
|
|
yuuji@0
|
91 size. However, the fourth and fifth messages have already been
|
|
yuuji@0
|
92 sent in the pipeline, so the mailbox ends up with the first,
|
|
yuuji@0
|
93 second, fourth, and fifth messages of the batch appended.
|
|
yuuji@0
|
94
|
|
yuuji@0
|
95 6.3.11. APPEND Command
|
|
yuuji@0
|
96
|
|
yuuji@0
|
97 Arguments: mailbox name
|
|
yuuji@0
|
98 one or more messages to upload, specified as:
|
|
yuuji@0
|
99 OPTIONAL flag parenthesized list
|
|
yuuji@0
|
100 OPTIONAL date/time string
|
|
yuuji@0
|
101 message literal
|
|
yuuji@0
|
102
|
|
yuuji@0
|
103 Data: no specific responses for this command
|
|
yuuji@0
|
104
|
|
yuuji@0
|
105 Result: OK - append completed
|
|
yuuji@0
|
106 NO - append error: can't append to that mailbox, error
|
|
yuuji@0
|
107 in flags or date/time or message text,
|
|
yuuji@0
|
108 append cancelled
|
|
yuuji@0
|
109 BAD - command unknown or arguments invalid
|
|
yuuji@0
|
110
|
|
yuuji@0
|
111
|
|
yuuji@0
|
112
|
|
yuuji@0
|
113
|
|
yuuji@0
|
114 Crispin Standards Track [Page 2]
|
|
yuuji@0
|
115
|
|
yuuji@0
|
116 RFC 3502 IMAP MULTIAPPEND March 2003
|
|
yuuji@0
|
117
|
|
yuuji@0
|
118
|
|
yuuji@0
|
119 The APPEND command appends the literal arguments as new messages
|
|
yuuji@0
|
120 to the end of the specified destination mailbox. This argument
|
|
yuuji@0
|
121 SHOULD be in the format of an [RFC-2822] message. 8-bit
|
|
yuuji@0
|
122 characters are permitted in the message. A server implementation
|
|
yuuji@0
|
123 that is unable to preserve 8-bit data properly MUST be able to
|
|
yuuji@0
|
124 reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
|
|
yuuji@0
|
125 content transfer encoding.
|
|
yuuji@0
|
126
|
|
yuuji@0
|
127 Note: There MAY be exceptions, e.g., draft messages, in
|
|
yuuji@0
|
128 which required [RFC-2822] header lines are omitted in the
|
|
yuuji@0
|
129 message literal argument to APPEND. The full implications
|
|
yuuji@0
|
130 of doing so MUST be understood and carefully weighed.
|
|
yuuji@0
|
131
|
|
yuuji@0
|
132 If a flag parenthesized list is specified, the flags SHOULD be set
|
|
yuuji@0
|
133 in the resulting message; otherwise, the flag list of the
|
|
yuuji@0
|
134 resulting message is set empty by default.
|
|
yuuji@0
|
135
|
|
yuuji@0
|
136 If a date-time is specified, the internal date SHOULD be set in
|
|
yuuji@0
|
137 the resulting message; otherwise, the internal date of the
|
|
yuuji@0
|
138 resulting message is set to the current date and time by default.
|
|
yuuji@0
|
139
|
|
yuuji@0
|
140 A zero-length message literal argument is an error, and MUST
|
|
yuuji@0
|
141 return a NO. This can be used to cancel the append.
|
|
yuuji@0
|
142
|
|
yuuji@0
|
143 If the append is unsuccessful for any reason (including being
|
|
yuuji@0
|
144 cancelled), the mailbox MUST be restored to its state before the
|
|
yuuji@0
|
145 APPEND attempt; no partial appending is permitted. The server MAY
|
|
yuuji@0
|
146 return an error before processing all the message arguments.
|
|
yuuji@0
|
147
|
|
yuuji@0
|
148 If the destination mailbox does not exist, a server MUST return an
|
|
yuuji@0
|
149 error, and MUST NOT automatically create the mailbox. Unless it
|
|
yuuji@0
|
150 is certain that the destination mailbox can not be created, the
|
|
yuuji@0
|
151 server MUST send the response code "[TRYCREATE]" as the prefix of
|
|
yuuji@0
|
152 the text of the tagged NO response. This gives a hint to the
|
|
yuuji@0
|
153 client that it can attempt a CREATE command and retry the APPEND
|
|
yuuji@0
|
154 if the CREATE is successful.
|
|
yuuji@0
|
155
|
|
yuuji@0
|
156 If the mailbox is currently selected, the normal new message
|
|
yuuji@0
|
157 actions SHOULD occur. Specifically, the server SHOULD notify the
|
|
yuuji@0
|
158 client immediately via an untagged EXISTS response. If the server
|
|
yuuji@0
|
159 does not do so, the client MAY issue a NOOP command (or failing
|
|
yuuji@0
|
160 that, a CHECK command) after one or more APPEND commands.
|
|
yuuji@0
|
161
|
|
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 Crispin Standards Track [Page 3]
|
|
yuuji@0
|
171
|
|
yuuji@0
|
172 RFC 3502 IMAP MULTIAPPEND March 2003
|
|
yuuji@0
|
173
|
|
yuuji@0
|
174
|
|
yuuji@0
|
175 Example: C: A003 APPEND saved-messages (\Seen) {329}
|
|
yuuji@0
|
176 S: + Ready for literal data
|
|
yuuji@0
|
177 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
|
|
yuuji@0
|
178 C: From: Fred Foobar <foobar@Blurdybloop.example.COM>
|
|
yuuji@0
|
179 C: Subject: afternoon meeting
|
|
yuuji@0
|
180 C: To: mooch@owatagu.example.net
|
|
yuuji@0
|
181 C: Message-Id: <B27397-0100000@Blurdybloop.example.COM>
|
|
yuuji@0
|
182 C: MIME-Version: 1.0
|
|
yuuji@0
|
183 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
|
|
yuuji@0
|
184 C:
|
|
yuuji@0
|
185 C: Hello Joe, do you think we can meet at 3:30 tomorrow?
|
|
yuuji@0
|
186 C: (\Seen) " 7-Feb-1994 22:43:04 -0800" {295}
|
|
yuuji@0
|
187 S: + Ready for literal data
|
|
yuuji@0
|
188 C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
|
|
yuuji@0
|
189 C: From: Joe Mooch <mooch@OWaTaGu.example.net>
|
|
yuuji@0
|
190 C: Subject: Re: afternoon meeting
|
|
yuuji@0
|
191 C: To: foobar@blurdybloop.example.com
|
|
yuuji@0
|
192 C: Message-Id: <a0434793874930@OWaTaGu.example.net>
|
|
yuuji@0
|
193 C: MIME-Version: 1.0
|
|
yuuji@0
|
194 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
|
|
yuuji@0
|
195 C:
|
|
yuuji@0
|
196 C: 3:30 is fine with me.
|
|
yuuji@0
|
197 C:
|
|
yuuji@0
|
198 S: A003 OK APPEND completed
|
|
yuuji@0
|
199 C: A004 APPEND bogusname (\Flagged) {1023}
|
|
yuuji@0
|
200 S: A004 NO [TRYCREATE] No such mailbox as bogusname
|
|
yuuji@0
|
201 C: A005 APPEND test (\Flagged) {99}
|
|
yuuji@0
|
202 S: + Ready for literal data
|
|
yuuji@0
|
203 C: Date: Mon, 7 Feb 2000 22:43:04 -0800 (PST)
|
|
yuuji@0
|
204 C: From: Fred Foobar <fred@example.com>
|
|
yuuji@0
|
205 C: Subject: hmm...
|
|
yuuji@0
|
206 C: {35403}
|
|
yuuji@0
|
207 S: A005 NO APPEND failed: Disk quota exceeded
|
|
yuuji@0
|
208
|
|
yuuji@0
|
209 Note: The APPEND command is not used for message delivery,
|
|
yuuji@0
|
210 because it does not provide a mechanism to transfer [SMTP]
|
|
yuuji@0
|
211 envelope information.
|
|
yuuji@0
|
212
|
|
yuuji@0
|
213 Modification to IMAP4rev1 Base Protocol Formal Syntax
|
|
yuuji@0
|
214
|
|
yuuji@0
|
215 The following syntax specification uses the Augmented Backus-Naur
|
|
yuuji@0
|
216 Form (ABNF) notation as specified in [ABNF].
|
|
yuuji@0
|
217
|
|
yuuji@0
|
218 append = "APPEND" SP mailbox 1*append-message
|
|
yuuji@0
|
219
|
|
yuuji@0
|
220 append-message = [SP flag-list] [SP date-time] SP literal
|
|
yuuji@0
|
221
|
|
yuuji@0
|
222
|
|
yuuji@0
|
223
|
|
yuuji@0
|
224
|
|
yuuji@0
|
225
|
|
yuuji@0
|
226 Crispin Standards Track [Page 4]
|
|
yuuji@0
|
227
|
|
yuuji@0
|
228 RFC 3502 IMAP MULTIAPPEND March 2003
|
|
yuuji@0
|
229
|
|
yuuji@0
|
230
|
|
yuuji@0
|
231 MULTIAPPEND Interaction with UIDPLUS Extension
|
|
yuuji@0
|
232
|
|
yuuji@0
|
233 Servers which support both MULTIAPPEND and [UIDPLUS] will have the
|
|
yuuji@0
|
234 "resp-code-apnd" rule modified as follows:
|
|
yuuji@0
|
235
|
|
yuuji@0
|
236 resp-code-apnd = "APPENDUID" SP nz-number SP set
|
|
yuuji@0
|
237
|
|
yuuji@0
|
238 That is, the APPENDUID response code returns as many UIDs as there
|
|
yuuji@0
|
239 were messages appended in the multiple append. The UIDs returned
|
|
yuuji@0
|
240 should be in the order the articles where appended. The message set
|
|
yuuji@0
|
241 may not contain extraneous UIDs or the symbol "*".
|
|
yuuji@0
|
242
|
|
yuuji@0
|
243 Security Considerations
|
|
yuuji@0
|
244
|
|
yuuji@0
|
245 The MULTIAPPEND extension does not raise any security considerations
|
|
yuuji@0
|
246 that are not present in the base [IMAP] protocol, and these issues
|
|
yuuji@0
|
247 are discussed in [IMAP]. Nevertheless, it is important to remember
|
|
yuuji@0
|
248 that IMAP4rev1 protocol transactions, including electronic mail data,
|
|
yuuji@0
|
249 are sent in the clear over the network unless protection from
|
|
yuuji@0
|
250 snooping is negotiated, either by the use of STARTTLS, privacy
|
|
yuuji@0
|
251 protection is negotiated in the AUTHENTICATE command, or some other
|
|
yuuji@0
|
252 protection mechanism is in effect.
|
|
yuuji@0
|
253
|
|
yuuji@0
|
254 Normative References
|
|
yuuji@0
|
255
|
|
yuuji@0
|
256 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
|
yuuji@0
|
257 Specifications: ABNF", RFC 2234, November 1997.
|
|
yuuji@0
|
258
|
|
yuuji@0
|
259 [IMAP] Crispin, M., "Internet Message Access Protocol - Version
|
|
yuuji@0
|
260 4rev1", RFC 3501, March 2003.
|
|
yuuji@0
|
261
|
|
yuuji@0
|
262 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
|
yuuji@0
|
263 Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
yuuji@0
|
264
|
|
yuuji@0
|
265 [MIME-IMB] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet
|
|
yuuji@0
|
266 Mail Extensions) Part One: Format of Internet Message
|
|
yuuji@0
|
267 Bodies", RFC 2045, November 1996.
|
|
yuuji@0
|
268
|
|
yuuji@0
|
269 [RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April
|
|
yuuji@0
|
270 2001.
|
|
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 Crispin Standards Track [Page 5]
|
|
yuuji@0
|
283
|
|
yuuji@0
|
284 RFC 3502 IMAP MULTIAPPEND March 2003
|
|
yuuji@0
|
285
|
|
yuuji@0
|
286
|
|
yuuji@0
|
287 Informative References
|
|
yuuji@0
|
288
|
|
yuuji@0
|
289 [LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
|
|
yuuji@0
|
290 January 1997.
|
|
yuuji@0
|
291
|
|
yuuji@0
|
292 [UIDPLUS] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June 1988.
|
|
yuuji@0
|
293
|
|
yuuji@0
|
294 [SMTP] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC
|
|
yuuji@0
|
295 2821, April 2001.
|
|
yuuji@0
|
296
|
|
yuuji@0
|
297 Author's Address
|
|
yuuji@0
|
298
|
|
yuuji@0
|
299 Mark R. Crispin
|
|
yuuji@0
|
300 Networks and Distributed Computing
|
|
yuuji@0
|
301 University of Washington
|
|
yuuji@0
|
302 4545 15th Avenue NE
|
|
yuuji@0
|
303 Seattle, WA 98105-4527
|
|
yuuji@0
|
304
|
|
yuuji@0
|
305 Phone: (206) 543-5762
|
|
yuuji@0
|
306 EMail: MRC@CAC.Washington.EDU
|
|
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 Crispin Standards Track [Page 6]
|
|
yuuji@0
|
339
|
|
yuuji@0
|
340 RFC 3502 IMAP MULTIAPPEND March 2003
|
|
yuuji@0
|
341
|
|
yuuji@0
|
342
|
|
yuuji@0
|
343 Full Copyright Statement
|
|
yuuji@0
|
344
|
|
yuuji@0
|
345 Copyright (C) The Internet Society (2003). All Rights Reserved.
|
|
yuuji@0
|
346
|
|
yuuji@0
|
347 This document and translations of it may be copied and furnished to
|
|
yuuji@0
|
348 others, and derivative works that comment on or otherwise explain it
|
|
yuuji@0
|
349 or assist in its implementation may be prepared, copied, published
|
|
yuuji@0
|
350 and distributed, in whole or in part, without restriction of any
|
|
yuuji@0
|
351 kind, provided that the above copyright notice and this paragraph are
|
|
yuuji@0
|
352 included on all such copies and derivative works. However, this
|
|
yuuji@0
|
353 document itself may not be modified in any way, such as by removing
|
|
yuuji@0
|
354 the copyright notice or references to the Internet Society or other
|
|
yuuji@0
|
355 Internet organizations, except as needed for the purpose of
|
|
yuuji@0
|
356 developing Internet standards in which case the procedures for
|
|
yuuji@0
|
357 copyrights defined in the Internet Standards process must be
|
|
yuuji@0
|
358 followed, or as required to translate it into languages other than
|
|
yuuji@0
|
359 English.
|
|
yuuji@0
|
360
|
|
yuuji@0
|
361 The limited permissions granted above are perpetual and will not be
|
|
yuuji@0
|
362 revoked by the Internet Society or its successors or assigns.
|
|
yuuji@0
|
363
|
|
yuuji@0
|
364 This document and the information contained herein is provided on an
|
|
yuuji@0
|
365 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|
yuuji@0
|
366 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|
yuuji@0
|
367 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|
yuuji@0
|
368 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|
yuuji@0
|
369 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
yuuji@0
|
370
|
|
yuuji@0
|
371 Acknowledgement
|
|
yuuji@0
|
372
|
|
yuuji@0
|
373 Funding for the RFC Editor function is currently provided by the
|
|
yuuji@0
|
374 Internet Society.
|
|
yuuji@0
|
375
|
|
yuuji@0
|
376
|
|
yuuji@0
|
377
|
|
yuuji@0
|
378
|
|
yuuji@0
|
379
|
|
yuuji@0
|
380
|
|
yuuji@0
|
381
|
|
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 Crispin Standards Track [Page 7]
|
|
yuuji@0
|
395
|
