Internet-Draft ESEARCH Return Opt & Data Tag Registry October 2023
Murchison Expires 25 April 2024 [Page]
Workgroup:
EXTRA
Internet-Draft:
draft-murchison-imap-esearch-return-opt-registry-01
Published:
Intended Status:
Informational
Expires:
Author:
K. Murchison
Fastmail

IANA Registry for IMAP Extended SEARCH Return Options and Data Tags

Abstract

This document creates a registry of IMAP Extended Search Return Options and Data Tags (RFC 4466) in order to help developers and IMAP extension writers track interactions between different extensions.

Open Issues

  • Is Expert Review the correct registration policy?
  • Should we also add a registry of SEARCH criteria?

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 25 April 2024.

1. Introduction

The Internet Message Access Protocol (IMAP) [RFC3501], [RFC9051] is used for accessing and manipulating email messages on a server. Over the years, the syntax of the IMAP SEARCH command has been extended to include return options and corresponding return data in the response [RFC4466]. There is currently no easy way to find out all of the return options and data tags defined by IMAP extensions published in RFCs, which makes it quite difficult for IMAP extension writers and IMAP implementation developers to forsee interactions between such extensions.

This document creates a registry of IMAP Extended Search Return Options and Data Tags in order to help developers and IMAP extension writers track interactions between different extensions.

2. IANA Considerations

2.1. IMAP ESEARCH Return Option and Data Tag Registration Template and Procedure

IANA is requested to create a new registry for IMAP ESEARCH Return Options and Data Tags. Registration of both options/tags specified in IETF Stream RFCs and vendor specific actions is allowed and encouraged. The registration template contains:

  1. name of the return option;
  2. any implied return data tags;
  3. short description;
  4. references: one or more documents describing the option/tag and any significant updates to its definition (this field is required for option/tag described in RFCs and is optional otherwise);

The registration procedure for this registry is Expert Review, per [RFC8126], Section 4.5. The Designated Expert only checks that the name of the return option or return data tag being registered matches the documentation, that the description field is accurate, that the correct documents are referenced and that the list of relevant documents is as complete as possible. The Designated Expert can't reject a registration based on personal dislike of the document defining a return option or return data tag and should always err on the side of registering, even if documentation is not complete.

Addition of a new reference to an existing registration or change to the description field goes through the same registration procedure as a new registration.

2.2. Initial IMAP ESEARCH Return Option and Data Tag Registry

The following table is used to initialize the return option and data tag registry.

Table 1
Return Option Name Implied Return Data Tags Description References
ALL ALL Return all message numbers/UIDs that satisfy the SEARCH criteria. [RFC4731] (Section 3.1), [RFC9051] (Section 6.4.4)
CONTEXT Indicate that subsequent use of the SEARCH criteria are likely. [RFC5267] (Section 4.2)
COUNT COUNT Return number of the messages that satisfy the SEARCH criteria. [RFC4731] (Section 3.1), [RFC9051] (Section 6.4.4)
MAX MAX Return the highest message number/UID that satisfies the SEARCH criteria [RFC4731] (Section 3.1), [RFC9051] (Section 6.4.4)
MIN MIN Return the lowest message number/UID that satisfies the SEARCH criteria. [RFC4731] (Section 3.1), [RFC9051] (Section 6.4.4)
* MODSEQ The highest mod-sequence of all messages in the set that satisfy the SEARCH criteria and result options. [RFC4731] (Section 3.2), [RFC7162] (Section 3.1.5)
PARTIAL PARTIAL Return a subset of the message numbers/UIDs that satisfy the SEARCH criteria. [RFC5267] (Section 4.4), [RFC9394] (Section 3.1)
RELEVANCY RELEVANCY Return a relevancy score for each message that satisfies the SEARCH criteria. [RFC6203] (Section 4)
SAVE Set the value of the search result variable to the set of message numbers/UIDs that satisfy the SEARCH criteria. [RFC5182] (Section 2), [RFC9051] (Section 6.4.4)
UPDATE ADDTO, REMOVEFROM Request unsolicited notifications of updates to the set of messages that satisfy the SEARCH criteria. [RFC5267] (Section 4.3)
* Any set of return options (including the empty set) plus the MODSEQ SEARCH criteria.

3. Security Considerations

The sole purpose of this document is to create a new IANA registry, so it doesn't create new security considerations for IMAP implementations.

The new registry should help IMAP extension writers and IMAP implementors track interactions between different IMAP extensions, so it might improve quality of specifications and implementations, including security aspects.

4. References

4.1. Normative References

[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.

4.2. Informative References

[RFC3501]
Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, , <https://www.rfc-editor.org/info/rfc3501>.
[RFC4466]
Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, DOI 10.17487/RFC4466, , <https://www.rfc-editor.org/info/rfc4466>.
[RFC4731]
Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, DOI 10.17487/RFC4731, , <https://www.rfc-editor.org/info/rfc4731>.
[RFC5182]
Melnikov, A., "IMAP Extension for Referencing the Last SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, , <https://www.rfc-editor.org/info/rfc5182>.
[RFC5267]
Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, DOI 10.17487/RFC5267, , <https://www.rfc-editor.org/info/rfc5267>.
[RFC6203]
Sirainen, T., "IMAP4 Extension for Fuzzy Search", RFC 6203, DOI 10.17487/RFC6203, , <https://www.rfc-editor.org/info/rfc6203>.
[RFC7162]
Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)", RFC 7162, DOI 10.17487/RFC7162, , <https://www.rfc-editor.org/info/rfc7162>.
[RFC9051]
Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message Access Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, , <https://www.rfc-editor.org/info/rfc9051>.
[RFC9122]
Melnikov, A. and K. Murchison, "IANA Registry for Sieve Actions", RFC 9122, DOI 10.17487/RFC9122, , <https://www.rfc-editor.org/info/rfc9122>.
[RFC9394]
Melnikov, A., Achuthan, A. P., Nagulakonda, V., and L. Alves, "IMAP PARTIAL Extension for Paged SEARCH and FETCH", RFC 9394, DOI 10.17487/RFC9394, , <https://www.rfc-editor.org/info/rfc9394>.

Appendix A. Acknowledgements

Portions of the text in the document have been borrowed from [RFC9122].

Appendix B. Change History (To be removed by RFC Editor before publication)

Changes from draft-murchison-imap-esearch-return-opt-registry-00:

  • Updated references with RFC 9122 and RFC 9394.

Author's Address

Kenneth Murchison
Fastmail US LLC
1429 Walnut Street - Suite 1201
Philadelphia, PA 19102
United States of America