RFC 2359

IMAP4 UIDPLUS extension

📅 published June 1998, from ietf

RFC 2359: IMAP4 UIDPLUS extension 🎀

Written by: J. Myers (John Gardiner Myers), Netscape Communications 💅 Category: Standards Track 🦋 Date: June 1998 🌸 Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates ✨

Status of this Memo 📜

okay so this doc is an Internet standards track protocol for the Internet community 💖 it's basically asking for discussion and suggestions for improvements 🫶 if you want the current standardization state and status of this protocol, check the latest edition of the "Internet Official Protocol Standards" (STD 1) 🧚 and yes, you can distribute this memo as much as you want 🔥

Copyright (C) The Internet Society (1998). All Rights Reserved. 💜

IESG NOTE 🙈

so the IMAP extension in here assumes a specific way of using IMAP for disconnected operation 👀 but that method isn't documented yet 💀 and there are a bunch of competing ideas about how to do disconnected operation in IMAP, with no consensus yet on which one should become the standard 😭

this doc got approved as a Proposed Standard because it doesn't look like it has technical flaws in itself ✨ BUT approving it as a Proposed Standard should NOT be read as the IETF endorsing any particular disconnected-operation approach for IMAP 🙅‍♀️

Table of Contents 🗂️

1.   Abstract ..............................................    2
2.   Conventions Used in this Document .....................    2
3.   Introduction and Overview .............................    2
4.   Features ..............................................    2
4.1. UID EXPUNGE Command ...................................    2
4.2. APPENDUID response code ...............................    3
4.3. COPYUID response code .................................    4
5.   Formal Syntax .........................................    4
6.   References ............................................    4
7.   Security Considerations ...............................    5
8.   Author's Address ......................................    5
9.   Full Copyright Statement ..............................    6

1. Abstract 🌈

so UIDPLUS is an extension of the Internet Message Access Protocol [IMAP4] 🧁 its whole thing is cutting down the time and resources some client operations eat up ✨ and the features in UIDPLUS are mainly aimed at disconnected-use clients 📱

2. Conventions Used in this Document 📝

in examples, "C:" means lines the client sends and "S:" means lines the server sends 💬

the key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are meant to be read the way they're defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS] 🎀 so when you see them in caps, they're load-bearing, babe 💅

3. Introduction and Overview 🧚

UIDPLUS is there in any IMAP4 server that returns "UIDPLUS" as one of its capabilities when it gets the CAPABILITY command 🦋 it adds one extra command, plus some extra data that comes back with successful APPEND and COPY commands 🌸

if a client wants to use the new stuff, it has to check for the extension first by sending a CAPABILITY command, obviously 🙄 every UIDPLUS feature is an optimization, though 💖 clients can still get the same functionality using only base-protocol commands, it's just slower 🐌 and for each feature, this doc recommends a fallback approach to use when the server doesn't support UIDPLUS ✨

4. Features 👑

4.1. UID EXPUNGE Command 🗑️

Arguments:  message set

Data:       untagged responses: EXPUNGE

Result:     OK - expunge completed
            NO - expunge failure (e.g. permission denied)
            BAD - command unknown or arguments invalid

the UID EXPUNGE command permanently removes, from the currently selected mailbox, every message that has BOTH the \Deleted flag set AND a UID inside the specified message set 🔥 if a message doesn't have the \Deleted flag set, or its UID isn't in the message set, it's totally untouched 🫶

this command can be used so that a replayed EXPUNGE command doesn't remove any messages that got marked \Deleted between the moment the user asked for the expunge and the moment the server actually processes the command 😭 main character energy, no collateral damage 💅

if the server doesn't support the UIDPLUS capability, the client SHOULD fall back to using the STORE command to temporarily remove the \Deleted flag from the messages it doesn't want removed 🧚 the client could also fall back to the EXPUNGE command, but that risks accidentally removing some messages it wanted to keep 💀

Example:

C: A003 UID EXPUNGE 3000:3002
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: A003 OK UID EXPUNGE completed

4.2. APPENDUID response code 💌

successful APPEND commands return an APPENDUID response code in the tagged OK response 🎀 the APPENDUID response code carries two arguments: the UIDVALIDITY of the destination mailbox, and the UID assigned to the appended message 🌸

if the server doesn't support UIDPLUS, the client can only figure this out by selecting the destination mailbox and sending FETCH commands 🐌

Example:

C: A003 APPEND saved-messages (\Seen) {310}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@Blurdybloop.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK [APPENDUID 38505 3955] APPEND completed

4.3. COPYUID response code 🦋

successful COPY and UID COPY commands return a COPYUID response code in the tagged OK response, but only when at least one message actually got copied 💖 the COPYUID response code has three things going on: the UIDVALIDITY of the mailbox that got appended to, a message set with the UIDs of the copied messages (in the order they were copied), and a message set with the UIDs that were assigned to those copied messages (in the order they were assigned) 🧚 neither message set can contain extra UIDs or the symbol '*' 🙅‍♀️

if the server doesn't support UIDPLUS, the client can only find this out by selecting the destination mailbox and sending FETCH commands 🐌

Example:

C: A003 COPY 2:4 MEETING
S: A003 OK [COPYUID 38505 304,319:320 3956:3958] Done
C: A003 UID COPY 305:310 MEETING
S: A003 OK Done

5. Formal Syntax 🧩

this syntax spec uses the augmented Backus-Naur Form (BNF) notation from [RFC-822], as modified by [IMAP4] 🤓 anything referenced but not defined here is defined by [IMAP4] 💅

unless noted otherwise, all alphabetic characters are case-insensitive 🙈 using upper or lower case in these token strings is purely for editorial clarity 🫶 implementations MUST accept these strings in a case-insensitive way 🔥

resp_code_apnd  ::= "APPENDUID" SPACE nz_number SPACE uniqueid

resp_code_copy  ::= "COPYUID" SPACE nz_number SPACE set SPACE set

uid_expunge     ::= "UID" SPACE "EXPUNGE" SPACE set

6. References 📚

[IMAP4]    Crispin, M., "Internet Message Access Protocol -
           Version 4rev1", RFC 2060, December 1996.

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC-822]  Crocker, D., "Standard for the Format of ARPA Internet
           Text Messages", STD 11, RFC 822, August 1982.

7. Security Considerations 🚨

okay, the big moment: there are no known security issues with this extension 😤🔐 nothing flagged, nothing sus, so no known risks to watch out for right now 💖

8. Author's Address 📮

John Gardiner Myers Netscape Communications 501 East Middlefield Road Mail Stop MV-029 Mountain View, CA 94043

EMail: jgmyers@netscape.com 💌

Copyright (C) The Internet Society (1998). All Rights Reserved. 💜

this document and translations of it can be copied and handed out to others 🦋 and people can make derivative works that comment on it, explain it, or help implement it, then prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind 🌈 as long as the copyright notice and this paragraph stay on every copy and derivative work ✨

BUT this document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations 🙅‍♀️ the exceptions are when it's needed for developing Internet standards (in which case the Internet Standards process copyright procedures MUST be followed) or when it's translated into languages other than English 🌸

the limited permissions above are perpetual and the Internet Society or its successors or assigns won't revoke them 💖

this document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🫶🎀

📦 where this page comes from