RFC 5032

WITHIN Search Extension to the IMAP Protocol

📅 published September 2007, from ietf

RFC 5032: WITHIN Search Extension to the IMAP Protocol 🎀

Okay bestie, here's the deets 💅

  • Network Working Group 🌸
  • RFC number: 5032
  • Editor: Eric W. Burger (BEA Systems, Inc.) ✨
  • Category: Standards Track 🔥
  • Date: September 2007 📅
  • Updates: RFC 3501 [RFC3501] 💖
  • Obsoletes: none listed in the title block 🧚

Status of This Memo

Okay so this doc is a standards track protocol for the whole Internet community, and it's basically asking everyone to weigh in with discussion and suggestions 🫶. If you want to know where it stands officially, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited, so share away 🦋.

Abstract

So WITHIN is an extension to IMAP SEARCH 💜. Normal IMAP SEARCH gives you messages whose internal date is within or outside a range, but the new OLDER and YOUNGER keys are different from BEFORE and SINCE because the client picks an interval instead of a date 🎀. This is clutch for persistent searches, especially when the device can't run searches at regular intervals, or when the network has limited bandwidth and you want to stop sending the same requests and getting the same responses over and over 🙈✨.

1. Introduction ✨

This extension adds two new search keys, OLDER and YOUNGER 🧚. Each one takes a non-zero integer, which is a time interval in seconds ⏱️. The server works out the time of interest by subtracting the client's interval from its own current date and time 🫶. Then it returns messages that are older or younger than that result, depending on which key you used 💅.

1.1. Conventions Used in This Document

In examples, "C:" means lines from the client and "S:" means lines from the server 💬.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔥.

When describing the general syntax, we skip some definitions, since RFC 3501 [RFC3501] already defines them 📖.

2. Protocol Operation 💅

An IMAP4 server that supports this capability MUST return "WITHIN" as one of its supported capabilities in the CAPABILITY command 🎀.

For both OLDER and YOUNGER, the server works out a target date and time by subtracting the interval (in seconds) from its current date and time ⏰. Then it compares that target with the INTERNALDATE of each message, as IMAP [RFC3501] specifies 🦋. For OLDER, a message matches if its INTERNALDATE is less recent than or equal to the target time 💜. For YOUNGER, a message matches if its INTERNALDATE is more recent than or equal to the target time ✨.

Both OLDER and YOUNGER searches always give exact matches, down to the second ⏱️. But if you're doing dynamic evaluation, like in a context [CONTEXT], keep in mind that the server might only evaluate periodically 🙈. So the server may delay updates. Clients MUST be aware that dynamic search results may not reflect the current state of the mailbox 😭. If the client needs a result that's up to date with the mailbox, we RECOMMEND that the client issue a new search 🫶.

3. Formal Syntax 🧚

The syntax below is written in Augmented Backus-Naur Form (ABNF) notation 🍓. Anything not defined here can be found in the formal syntax of ABNF [RFC4234] and IMAP [RFC3501] 📚.

This document extends RFC 3501 [RFC3501] with two new search keys: OLDER <interval> and YOUNGER <interval> 💖.

search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number
                  ; search-key defined in RFC 3501

4. Example 🌈

C: a1 SEARCH UNSEEN YOUNGER 259200
S: a1 * SEARCH 4 8 15 16 23 42

This searches for all unseen messages from the past 3 days, which is 259200 seconds, based on the server's current time 🫶.

5. Security Considerations 🔥

Okay, this part is serious 🥺. The WITHIN extension doesn't add any security considerations that aren't already in the base protocol 🛡️. The same considerations apply as for IMAP [RFC3501] 💜.

6. IANA Considerations 📋

So, per the IMAP RFC [RFC3501], registering a new IMAP capability in the IMAP Capability registry needs either a standards-track RFC or an IESG-approved experimental RFC 🧐. The registry lives at <http://www.iana.org/assignments/imap4-capabilities> 🦋. This standards-track document defines the WITHIN IMAP capability 👑. IANA has added this extension to the IANA IMAP Capability registry ✅.

7. References 📚

7.1. Normative References

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

[RFC3501]  Crispin, M., "Internet Message Access Protocol - Version
           4rev1", RFC 3501, March 2003.

[RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", RFC 4234, October 2005.

7.2. Informative References

[CONTEXT]  Melnikov, D. and C. King, "Contexts for IMAP4", Work
           in Progress, May 2006.

Appendix A. Contributors 🌸

Stephane Maes and Ray Cromwell wrote the first version of this document as part of P-IMAP, plus the first versions for the IETF 🧚. From an attribution standpoint, they are clearly authors 💅.

Appendix B. Acknowledgements 🫶

The authors want to thank everyone who brought key insight and reviewed and discussed the concepts of LPSEARCH extensively 💖. They also thank the authors of its early introduction in P-IMAP 🎀.

Special thanks also go to Arnt Gilbrandsen, Ken Murchison, Zoltan Ordogh, and most especially Dave Cridland for their reviews and suggestions 👑. And a very special thank you to Alexey Melnikov for his choice submission of text 🌈.

Author's Address 📮

Eric W. Burger (editor)
BEA Systems, Inc.
USA

EMail: eric.burger@bea.com
URI:   http://www.standardstrack.com

Copyright (C) The IETF Trust (2007) 💜.

This document is subject to the rights, licenses and restrictions in BCP 78, and except where BCP 78 says otherwise, the authors keep all their rights 📜.

This document and the info in it are provided "AS IS". THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT USING THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS, OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🙅‍♀️.

Intellectual Property 💎

The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope, or on whether any license for them is available 🤷‍♀️. It also doesn't claim to have done any independent work to find such rights 🔍. You can find the procedures for rights in RFC documents in BCP 78 and BCP 79 📖.

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️.

The IETF invites anyone interested to flag any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard 🙌. Send that info to the IETF at ietf-ipr@ietf.org 💌.

📦 where this page comes from