| 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: 4315 December 2005
|
|
yuuji@0
|
9 Obsoletes: 2359
|
|
yuuji@0
|
10 Category: Standards Track
|
|
yuuji@0
|
11
|
|
yuuji@0
|
12
|
|
yuuji@0
|
13 Internet Message Access Protocol (IMAP) - UIDPLUS extension
|
|
yuuji@0
|
14
|
|
yuuji@0
|
15 Status of This Memo
|
|
yuuji@0
|
16
|
|
yuuji@0
|
17 This document specifies an Internet standards track protocol for the
|
|
yuuji@0
|
18 Internet community, and requests discussion and suggestions for
|
|
yuuji@0
|
19 improvements. Please refer to the current edition of the "Internet
|
|
yuuji@0
|
20 Official Protocol Standards" (STD 1) for the standardization state
|
|
yuuji@0
|
21 and status of this protocol. Distribution of this memo is unlimited.
|
|
yuuji@0
|
22
|
|
yuuji@0
|
23 Copyright Notice
|
|
yuuji@0
|
24
|
|
yuuji@0
|
25 Copyright (C) The Internet Society (2005).
|
|
yuuji@0
|
26
|
|
yuuji@0
|
27 Abstract
|
|
yuuji@0
|
28
|
|
yuuji@0
|
29 The UIDPLUS extension of the Internet Message Access Protocol (IMAP)
|
|
yuuji@0
|
30 provides a set of features intended to reduce the amount of time and
|
|
yuuji@0
|
31 resources used by some client operations. The features in UIDPLUS
|
|
yuuji@0
|
32 are primarily intended for disconnected-use clients.
|
|
yuuji@0
|
33
|
|
yuuji@0
|
34 1. Introduction and Overview
|
|
yuuji@0
|
35
|
|
yuuji@0
|
36 The UIDPLUS extension is present in any IMAP server implementation
|
|
yuuji@0
|
37 that returns "UIDPLUS" as one of the supported capabilities to the
|
|
yuuji@0
|
38 CAPABILITY command.
|
|
yuuji@0
|
39
|
|
yuuji@0
|
40 The UIDPLUS extension defines an additional command. In addition,
|
|
yuuji@0
|
41 this document recommends new status response codes in IMAP that
|
|
yuuji@0
|
42 SHOULD be returned by all server implementations, regardless of
|
|
yuuji@0
|
43 whether or not the UIDPLUS extension is implemented.
|
|
yuuji@0
|
44
|
|
yuuji@0
|
45 The added facilities of the features in UIDPLUS are optimizations;
|
|
yuuji@0
|
46 clients can provide equivalent functionality, albeit less
|
|
yuuji@0
|
47 efficiently, by using facilities in the base protocol.
|
|
yuuji@0
|
48
|
|
yuuji@0
|
49 1.1. Conventions Used in This Document
|
|
yuuji@0
|
50
|
|
yuuji@0
|
51 In examples, "C:" and "S:" indicate lines sent by the client and
|
|
yuuji@0
|
52 server, respectively.
|
|
yuuji@0
|
53
|
|
yuuji@0
|
54
|
|
yuuji@0
|
55
|
|
yuuji@0
|
56
|
|
yuuji@0
|
57
|
|
yuuji@0
|
58 Crispin Standards Track [Page 1]
|
|
yuuji@0
|
59
|
|
yuuji@0
|
60 RFC 4315 IMAP - UIDPLUS Extension December 2005
|
|
yuuji@0
|
61
|
|
yuuji@0
|
62
|
|
yuuji@0
|
63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
yuuji@0
|
64 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
|
|
yuuji@0
|
65 be interpreted as described in [KEYWORDS].
|
|
yuuji@0
|
66
|
|
yuuji@0
|
67 A "UID set" is similar to the [IMAP] sequence set; however, the "*"
|
|
yuuji@0
|
68 value for a sequence number is not permitted.
|
|
yuuji@0
|
69
|
|
yuuji@0
|
70 2. Additional Commands
|
|
yuuji@0
|
71
|
|
yuuji@0
|
72 The following command definition is an extension to [IMAP] section
|
|
yuuji@0
|
73 6.4.
|
|
yuuji@0
|
74
|
|
yuuji@0
|
75 2.1. UID EXPUNGE Command
|
|
yuuji@0
|
76
|
|
yuuji@0
|
77 Arguments: sequence set
|
|
yuuji@0
|
78
|
|
yuuji@0
|
79 Data: untagged responses: EXPUNGE
|
|
yuuji@0
|
80
|
|
yuuji@0
|
81 Result: OK - expunge completed
|
|
yuuji@0
|
82 NO - expunge failure (e.g., permission denied)
|
|
yuuji@0
|
83 BAD - command unknown or arguments invalid
|
|
yuuji@0
|
84
|
|
yuuji@0
|
85 The UID EXPUNGE command permanently removes all messages that both
|
|
yuuji@0
|
86 have the \Deleted flag set and have a UID that is included in the
|
|
yuuji@0
|
87 specified sequence set from the currently selected mailbox. If a
|
|
yuuji@0
|
88 message either does not have the \Deleted flag set or has a UID
|
|
yuuji@0
|
89 that is not included in the specified sequence set, it is not
|
|
yuuji@0
|
90 affected.
|
|
yuuji@0
|
91
|
|
yuuji@0
|
92 This command is particularly useful for disconnected use clients.
|
|
yuuji@0
|
93 By using UID EXPUNGE instead of EXPUNGE when resynchronizing with
|
|
yuuji@0
|
94 the server, the client can ensure that it does not inadvertantly
|
|
yuuji@0
|
95 remove any messages that have been marked as \Deleted by other
|
|
yuuji@0
|
96 clients between the time that the client was last connected and
|
|
yuuji@0
|
97 the time the client resynchronizes.
|
|
yuuji@0
|
98
|
|
yuuji@0
|
99 If the server does not support the UIDPLUS capability, the client
|
|
yuuji@0
|
100 should fall back to using the STORE command to temporarily remove
|
|
yuuji@0
|
101 the \Deleted flag from messages it does not want to remove, then
|
|
yuuji@0
|
102 issuing the EXPUNGE command. Finally, the client should use the
|
|
yuuji@0
|
103 STORE command to restore the \Deleted flag on the messages in
|
|
yuuji@0
|
104 which it was temporarily removed.
|
|
yuuji@0
|
105
|
|
yuuji@0
|
106 Alternatively, the client may fall back to using just the EXPUNGE
|
|
yuuji@0
|
107 command, risking the unintended removal of some messages.
|
|
yuuji@0
|
108
|
|
yuuji@0
|
109
|
|
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 4315 IMAP - UIDPLUS Extension December 2005
|
|
yuuji@0
|
117
|
|
yuuji@0
|
118
|
|
yuuji@0
|
119 Example: C: A003 UID EXPUNGE 3000:3002
|
|
yuuji@0
|
120 S: * 3 EXPUNGE
|
|
yuuji@0
|
121 S: * 3 EXPUNGE
|
|
yuuji@0
|
122 S: * 3 EXPUNGE
|
|
yuuji@0
|
123 S: A003 OK UID EXPUNGE completed
|
|
yuuji@0
|
124
|
|
yuuji@0
|
125 3. Additional Response Codes
|
|
yuuji@0
|
126
|
|
yuuji@0
|
127 The following response codes are extensions to the response codes
|
|
yuuji@0
|
128 defined in [IMAP] section 7.1. With limited exceptions, discussed
|
|
yuuji@0
|
129 below, server implementations that advertise the UIDPLUS extension
|
|
yuuji@0
|
130 SHOULD return these response codes.
|
|
yuuji@0
|
131
|
|
yuuji@0
|
132 In the case of a mailbox that has permissions set so that the client
|
|
yuuji@0
|
133 can COPY or APPEND to the mailbox, but not SELECT or EXAMINE it, the
|
|
yuuji@0
|
134 server SHOULD NOT send an APPENDUID or COPYUID response code as it
|
|
yuuji@0
|
135 would disclose information about the mailbox.
|
|
yuuji@0
|
136
|
|
yuuji@0
|
137 In the case of a mailbox that has UIDNOTSTICKY status (as defined
|
|
yuuji@0
|
138 below), the server MAY omit the APPENDUID or COPYUID response code as
|
|
yuuji@0
|
139 it is not meaningful.
|
|
yuuji@0
|
140
|
|
yuuji@0
|
141 If the server does not return the APPENDUID or COPYUID response
|
|
yuuji@0
|
142 codes, the client can discover this information by selecting the
|
|
yuuji@0
|
143 destination mailbox. The location of messages placed in the
|
|
yuuji@0
|
144 destination mailbox by COPY or APPEND can be determined by using
|
|
yuuji@0
|
145 FETCH and/or SEARCH commands (e.g., for Message-ID or some unique
|
|
yuuji@0
|
146 marker placed in the message in an APPEND).
|
|
yuuji@0
|
147
|
|
yuuji@0
|
148 APPENDUID
|
|
yuuji@0
|
149
|
|
yuuji@0
|
150 Followed by the UIDVALIDITY of the destination mailbox and the UID
|
|
yuuji@0
|
151 assigned to the appended message in the destination mailbox,
|
|
yuuji@0
|
152 indicates that the message has been appended to the destination
|
|
yuuji@0
|
153 mailbox with that UID.
|
|
yuuji@0
|
154
|
|
yuuji@0
|
155 If the server also supports the [MULTIAPPEND] extension, and if
|
|
yuuji@0
|
156 multiple messages were appended in the APPEND command, then the
|
|
yuuji@0
|
157 second value is a UID set containing the UIDs assigned to the
|
|
yuuji@0
|
158 appended messages, in the order they were transmitted in the
|
|
yuuji@0
|
159 APPEND command. This UID set may not contain extraneous UIDs or
|
|
yuuji@0
|
160 the symbol "*".
|
|
yuuji@0
|
161
|
|
yuuji@0
|
162 Note: the UID set form of the APPENDUID response code MUST NOT
|
|
yuuji@0
|
163 be used if only a single message was appended. In particular,
|
|
yuuji@0
|
164 a server MUST NOT send a range such as 123:123. This is
|
|
yuuji@0
|
165 because a client that does not support [MULTIAPPEND] expects
|
|
yuuji@0
|
166 only a single UID and not a UID set.
|
|
yuuji@0
|
167
|
|
yuuji@0
|
168
|
|
yuuji@0
|
169
|
|
yuuji@0
|
170 Crispin Standards Track [Page 3]
|
|
yuuji@0
|
171
|
|
yuuji@0
|
172 RFC 4315 IMAP - UIDPLUS Extension December 2005
|
|
yuuji@0
|
173
|
|
yuuji@0
|
174
|
|
yuuji@0
|
175 UIDs are assigned in strictly ascending order in the mailbox
|
|
yuuji@0
|
176 (refer to [IMAP], section 2.3.1.1) and UID ranges are as in
|
|
yuuji@0
|
177 [IMAP]; in particular, note that a range of 12:10 is exactly
|
|
yuuji@0
|
178 equivalent to 10:12 and refers to the sequence 10,11,12.
|
|
yuuji@0
|
179
|
|
yuuji@0
|
180 This response code is returned in a tagged OK response to the
|
|
yuuji@0
|
181 APPEND command.
|
|
yuuji@0
|
182
|
|
yuuji@0
|
183 COPYUID
|
|
yuuji@0
|
184
|
|
yuuji@0
|
185 Followed by the UIDVALIDITY of the destination mailbox, a UID set
|
|
yuuji@0
|
186 containing the UIDs of the message(s) in the source mailbox that
|
|
yuuji@0
|
187 were copied to the destination mailbox and containing the UIDs
|
|
yuuji@0
|
188 assigned to the copied message(s) in the destination mailbox,
|
|
yuuji@0
|
189 indicates that the message(s) have been copied to the destination
|
|
yuuji@0
|
190 mailbox with the stated UID(s).
|
|
yuuji@0
|
191
|
|
yuuji@0
|
192 The source UID set is in the order the message(s) were copied; the
|
|
yuuji@0
|
193 destination UID set corresponds to the source UID set and is in
|
|
yuuji@0
|
194 the same order. Neither of the UID sets may contain extraneous
|
|
yuuji@0
|
195 UIDs or the symbol "*".
|
|
yuuji@0
|
196
|
|
yuuji@0
|
197 UIDs are assigned in strictly ascending order in the mailbox
|
|
yuuji@0
|
198 (refer to [IMAP], section 2.3.1.1) and UID ranges are as in
|
|
yuuji@0
|
199 [IMAP]; in particular, note that a range of 12:10 is exactly
|
|
yuuji@0
|
200 equivalent to 10:12 and refers to the sequence 10,11,12.
|
|
yuuji@0
|
201
|
|
yuuji@0
|
202 This response code is returned in a tagged OK response to the COPY
|
|
yuuji@0
|
203 command.
|
|
yuuji@0
|
204
|
|
yuuji@0
|
205 UIDNOTSTICKY
|
|
yuuji@0
|
206
|
|
yuuji@0
|
207 The selected mailbox is supported by a mail store that does not
|
|
yuuji@0
|
208 support persistent UIDs; that is, UIDVALIDITY will be different
|
|
yuuji@0
|
209 each time the mailbox is selected. Consequently, APPEND or COPY
|
|
yuuji@0
|
210 to this mailbox will not return an APPENDUID or COPYUID response
|
|
yuuji@0
|
211 code.
|
|
yuuji@0
|
212
|
|
yuuji@0
|
213 This response code is returned in an untagged NO response to the
|
|
yuuji@0
|
214 SELECT command.
|
|
yuuji@0
|
215
|
|
yuuji@0
|
216 Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores.
|
|
yuuji@0
|
217 This facility exists to support legacy mail stores in which it
|
|
yuuji@0
|
218 is technically infeasible to support persistent UIDs. This
|
|
yuuji@0
|
219 should be avoided when designing new mail stores.
|
|
yuuji@0
|
220
|
|
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 4315 IMAP - UIDPLUS Extension December 2005
|
|
yuuji@0
|
229
|
|
yuuji@0
|
230
|
|
yuuji@0
|
231 Example: C: A003 APPEND saved-messages (\Seen) {297}
|
|
yuuji@0
|
232 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
|
|
yuuji@0
|
233 C: From: Fred Foobar <foobar@example.com>
|
|
yuuji@0
|
234 C: Subject: afternoon meeting
|
|
yuuji@0
|
235 C: To: mooch@example.com
|
|
yuuji@0
|
236 C: Message-Id: <B27397-0100000@example.com>
|
|
yuuji@0
|
237 C: MIME-Version: 1.0
|
|
yuuji@0
|
238 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
|
|
yuuji@0
|
239 C:
|
|
yuuji@0
|
240 C: Hello Joe, do you think we can meet at 3:30 tomorrow?
|
|
yuuji@0
|
241 C:
|
|
yuuji@0
|
242 S: A003 OK [APPENDUID 38505 3955] APPEND completed
|
|
yuuji@0
|
243 C: A004 COPY 2:4 meeting
|
|
yuuji@0
|
244 S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done
|
|
yuuji@0
|
245 C: A005 UID COPY 305:310 meeting
|
|
yuuji@0
|
246 S: A005 OK No matching messages, so nothing copied
|
|
yuuji@0
|
247 C: A006 COPY 2 funny
|
|
yuuji@0
|
248 S: A006 OK Done
|
|
yuuji@0
|
249 C: A007 SELECT funny
|
|
yuuji@0
|
250 S: * 1 EXISTS
|
|
yuuji@0
|
251 S: * 1 RECENT
|
|
yuuji@0
|
252 S: * OK [UNSEEN 1] Message 1 is first unseen
|
|
yuuji@0
|
253 S: * OK [UIDVALIDITY 3857529045] Validity session-only
|
|
yuuji@0
|
254 S: * OK [UIDNEXT 2] Predicted next UID
|
|
yuuji@0
|
255 S: * NO [UIDNOTSTICKY] Non-persistent UIDs
|
|
yuuji@0
|
256 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
|
|
yuuji@0
|
257 S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited
|
|
yuuji@0
|
258 S: A007 OK [READ-WRITE] SELECT completed
|
|
yuuji@0
|
259
|
|
yuuji@0
|
260 In this example, A003 and A004 demonstrate successful appending and
|
|
yuuji@0
|
261 copying to a mailbox that returns the UIDs assigned to the messages.
|
|
yuuji@0
|
262 A005 is an example in which no messages were copied; this is because
|
|
yuuji@0
|
263 in A003, we see that message 2 had UID 304, and message 3 had UID
|
|
yuuji@0
|
264 319; therefore, UIDs 305 through 310 do not exist (refer to section
|
|
yuuji@0
|
265 2.3.1.1 of [IMAP] for further explanation). A006 is an example of a
|
|
yuuji@0
|
266 message being copied that did not return a COPYUID; and, as expected,
|
|
yuuji@0
|
267 A007 shows that the mail store containing that mailbox does not
|
|
yuuji@0
|
268 support persistent UIDs.
|
|
yuuji@0
|
269
|
|
yuuji@0
|
270 4. Formal Syntax
|
|
yuuji@0
|
271
|
|
yuuji@0
|
272 Formal syntax is defined using ABNF [ABNF], which extends the ABNF
|
|
yuuji@0
|
273 rules defined in [IMAP]. The IMAP4 ABNF should be imported before
|
|
yuuji@0
|
274 attempting to validate these rules.
|
|
yuuji@0
|
275
|
|
yuuji@0
|
276 append-uid = uniqueid
|
|
yuuji@0
|
277
|
|
yuuji@0
|
278 capability =/ "UIDPLUS"
|
|
yuuji@0
|
279
|
|
yuuji@0
|
280
|
|
yuuji@0
|
281
|
|
yuuji@0
|
282 Crispin Standards Track [Page 5]
|
|
yuuji@0
|
283
|
|
yuuji@0
|
284 RFC 4315 IMAP - UIDPLUS Extension December 2005
|
|
yuuji@0
|
285
|
|
yuuji@0
|
286
|
|
yuuji@0
|
287 command-select =/ uid-expunge
|
|
yuuji@0
|
288
|
|
yuuji@0
|
289 resp-code-apnd = "APPENDUID" SP nz-number SP append-uid
|
|
yuuji@0
|
290
|
|
yuuji@0
|
291 resp-code-copy = "COPYUID" SP nz-number SP uid-set SP uid-set
|
|
yuuji@0
|
292
|
|
yuuji@0
|
293 resp-text-code =/ resp-code-apnd / resp-code-copy / "UIDNOTSTICKY"
|
|
yuuji@0
|
294 ; incorporated before the expansion rule of
|
|
yuuji@0
|
295 ; atom [SP 1*<any TEXT-CHAR except "]">]
|
|
yuuji@0
|
296 ; that appears in [IMAP]
|
|
yuuji@0
|
297
|
|
yuuji@0
|
298 uid-expunge = "UID" SP "EXPUNGE" SP sequence-set
|
|
yuuji@0
|
299
|
|
yuuji@0
|
300 uid-set = (uniqueid / uid-range) *("," uid-set)
|
|
yuuji@0
|
301
|
|
yuuji@0
|
302 uid-range = (uniqueid ":" uniqueid)
|
|
yuuji@0
|
303 ; two uniqueid values and all values
|
|
yuuji@0
|
304 ; between these two regards of order.
|
|
yuuji@0
|
305 ; Example: 2:4 and 4:2 are equivalent.
|
|
yuuji@0
|
306
|
|
yuuji@0
|
307 Servers that support [MULTIAPPEND] will have the following extension
|
|
yuuji@0
|
308 to the above rules:
|
|
yuuji@0
|
309
|
|
yuuji@0
|
310 append-uid =/ uid-set
|
|
yuuji@0
|
311 ; only permitted if client uses [MULTIAPPEND]
|
|
yuuji@0
|
312 ; to append multiple messages.
|
|
yuuji@0
|
313
|
|
yuuji@0
|
314 5. Security Considerations
|
|
yuuji@0
|
315
|
|
yuuji@0
|
316 The COPYUID and APPENDUID response codes return information about the
|
|
yuuji@0
|
317 mailbox, which may be considered sensitive if the mailbox has
|
|
yuuji@0
|
318 permissions set that permit the client to COPY or APPEND to the
|
|
yuuji@0
|
319 mailbox, but not SELECT or EXAMINE it.
|
|
yuuji@0
|
320
|
|
yuuji@0
|
321 Consequently, these response codes SHOULD NOT be issued if the client
|
|
yuuji@0
|
322 does not have access to SELECT or EXAMINE the mailbox.
|
|
yuuji@0
|
323
|
|
yuuji@0
|
324 6. IANA Considerations
|
|
yuuji@0
|
325
|
|
yuuji@0
|
326 This document constitutes registration of the UIDPLUS capability in
|
|
yuuji@0
|
327 the imap4-capabilities registry, replacing [RFC2359].
|
|
yuuji@0
|
328
|
|
yuuji@0
|
329 7. Normative References
|
|
yuuji@0
|
330
|
|
yuuji@0
|
331 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
|
|
yuuji@0
|
332 Specifications: ABNF", RFC 4234, October 2005.
|
|
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 4315 IMAP - UIDPLUS Extension December 2005
|
|
yuuji@0
|
341
|
|
yuuji@0
|
342
|
|
yuuji@0
|
343 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
|
|
yuuji@0
|
344 VERSION 4rev1", RFC 3501, March 2003.
|
|
yuuji@0
|
345
|
|
yuuji@0
|
346 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
|
yuuji@0
|
347 Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
yuuji@0
|
348
|
|
yuuji@0
|
349 [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
|
|
yuuji@0
|
350 MULTIAPPEND Extension", RFC 3502, March 2003.
|
|
yuuji@0
|
351
|
|
yuuji@0
|
352 8. Informative References
|
|
yuuji@0
|
353
|
|
yuuji@0
|
354 [RFC2359] Myers, J., "IMAP4 UIDPLUS extension", RFC 2359, June
|
|
yuuji@0
|
355 1998.
|
|
yuuji@0
|
356
|
|
yuuji@0
|
357 9. Changes from RFC 2359
|
|
yuuji@0
|
358
|
|
yuuji@0
|
359 This document obsoletes [RFC2359]. However, it is based upon that
|
|
yuuji@0
|
360 document, and takes substantial text from it (albeit with numerous
|
|
yuuji@0
|
361 clarifications in wording).
|
|
yuuji@0
|
362
|
|
yuuji@0
|
363 [RFC2359] implied that a server must always return COPYUID/APPENDUID
|
|
yuuji@0
|
364 data; thus suggesting that in such cases the server should return
|
|
yuuji@0
|
365 arbitrary data if the destination mailbox did not support persistent
|
|
yuuji@0
|
366 UIDs. This document adds the UIDNOTSTICKY response code to indicate
|
|
yuuji@0
|
367 that a mailbox does not support persistent UIDs, and stipulates that
|
|
yuuji@0
|
368 a UIDPLUS server does not return COPYUID/APPENDUID data when the COPY
|
|
yuuji@0
|
369 (or APPEND) destination mailbox has UIDNOTSTICKY status.
|
|
yuuji@0
|
370
|
|
yuuji@0
|
371 Author's Address
|
|
yuuji@0
|
372
|
|
yuuji@0
|
373 Mark R. Crispin
|
|
yuuji@0
|
374 Networks and Distributed Computing
|
|
yuuji@0
|
375 University of Washington
|
|
yuuji@0
|
376 4545 15th Avenue NE
|
|
yuuji@0
|
377 Seattle, WA 98105-4527
|
|
yuuji@0
|
378
|
|
yuuji@0
|
379 Phone: (206) 543-5762
|
|
yuuji@0
|
380 EMail: MRC@CAC.Washington.EDU
|
|
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
|
|
yuuji@0
|
396 RFC 4315 IMAP - UIDPLUS Extension December 2005
|
|
yuuji@0
|
397
|
|
yuuji@0
|
398
|
|
yuuji@0
|
399 Full Copyright Statement
|
|
yuuji@0
|
400
|
|
yuuji@0
|
401 Copyright (C) The Internet Society (2005).
|
|
yuuji@0
|
402
|
|
yuuji@0
|
403 This document is subject to the rights, licenses and restrictions
|
|
yuuji@0
|
404 contained in BCP 78, and except as set forth therein, the authors
|
|
yuuji@0
|
405 retain all their rights.
|
|
yuuji@0
|
406
|
|
yuuji@0
|
407 This document and the information contained herein are provided on an
|
|
yuuji@0
|
408 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|
yuuji@0
|
409 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
|
yuuji@0
|
410 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
|
yuuji@0
|
411 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
|
yuuji@0
|
412 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|
yuuji@0
|
413 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
yuuji@0
|
414
|
|
yuuji@0
|
415 Intellectual Property
|
|
yuuji@0
|
416
|
|
yuuji@0
|
417 The IETF takes no position regarding the validity or scope of any
|
|
yuuji@0
|
418 Intellectual Property Rights or other rights that might be claimed to
|
|
yuuji@0
|
419 pertain to the implementation or use of the technology described in
|
|
yuuji@0
|
420 this document or the extent to which any license under such rights
|
|
yuuji@0
|
421 might or might not be available; nor does it represent that it has
|
|
yuuji@0
|
422 made any independent effort to identify any such rights. Information
|
|
yuuji@0
|
423 on the procedures with respect to rights in RFC documents can be
|
|
yuuji@0
|
424 found in BCP 78 and BCP 79.
|
|
yuuji@0
|
425
|
|
yuuji@0
|
426 Copies of IPR disclosures made to the IETF Secretariat and any
|
|
yuuji@0
|
427 assurances of licenses to be made available, or the result of an
|
|
yuuji@0
|
428 attempt made to obtain a general license or permission for the use of
|
|
yuuji@0
|
429 such proprietary rights by implementers or users of this
|
|
yuuji@0
|
430 specification can be obtained from the IETF on-line IPR repository at
|
|
yuuji@0
|
431 http://www.ietf.org/ipr.
|
|
yuuji@0
|
432
|
|
yuuji@0
|
433 The IETF invites any interested party to bring to its attention any
|
|
yuuji@0
|
434 copyrights, patents or patent applications, or other proprietary
|
|
yuuji@0
|
435 rights that may cover technology that may be required to implement
|
|
yuuji@0
|
436 this standard. Please address the information to the IETF at ietf-
|
|
yuuji@0
|
437 ipr@ietf.org.
|
|
yuuji@0
|
438
|
|
yuuji@0
|
439 Acknowledgement
|
|
yuuji@0
|
440
|
|
yuuji@0
|
441 Funding for the RFC Editor function is currently provided by the
|
|
yuuji@0
|
442 Internet Society.
|
|
yuuji@0
|
443
|
|
yuuji@0
|
444
|
|
yuuji@0
|
445
|
|
yuuji@0
|
446
|
|
yuuji@0
|
447
|
|
yuuji@0
|
448
|
|
yuuji@0
|
449
|
|
yuuji@0
|
450 Crispin Standards Track [Page 8]
|
|
yuuji@0
|
451
|
