IMAP4 Extension for Named Searches (Filters)
RFC 5466

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

Network Working Group                                        A. Melnikov
Request for Comments: 5466                                       C. King
Category: Standards Track                                      Isode Ltd
                                                           February 2009

              IMAP4 Extension for Named Searches (Filters)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (http://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The document defines a way to persistently store named IMAP (RFC
   3501) searches on the server.  Such named searches can be
   subsequently referenced in a SEARCH or any other command that accepts
   a search criterion as a parameter.

Table of Contents

   1.  Introduction and Overview . . . . . . . . . . . . . . . . . . . 2
   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 2
   3.  IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . . 2
     3.1.  FILTER SEARCH Criterion . . . . . . . . . . . . . . . . . . 3
     3.2.  Managing Filters Using SETMETADATA/GETMETADATA Commands . . 4
   4.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8

Melnikov & King             Standards Track                     [Page 1]
RFC 5466                      IMAP Filters                 February 2009

1.  Introduction and Overview

   Persistent named searches described in this document allow clients to
   save favorite searches on the server.  Such saved searches can save
   bandwidth for clients that need to regularly repeat them.

   The FILTERS IMAP extension adds a new FILTER search criterion for
   referencing persistent named searches (a.k.a. "filters"), as well as
   reuses GETMETADATA/SETMETADATA commands [METADATA] for listing/
   creating/updating/deleting such filters.

   A filter can be private (only accessible to the logged-in user) or
   public (accessible to all logged-in users).  Both a private and a
   public filter with the same name can exist at the same time.  If both
   filter types with the same name exist, the FILTER SEARCH criterion
   (see Section 3.1) MUST use the value of the private filter;
   otherwise, it MUST use the value of the filter that exists.

   Let us call a pair of filter name and filter type a "typed filter".
   Each typed filter can have a value (which is a valid IMAP SEARCH
   criteria conforming to ABNF for the "search-criteria" non-terminal)
   and an optional human-readable description.  The SETMETADATA command
   creates or updates the value and/or the description of a typed
   filter.

   Values of all search keys stored in a filter MUST be encoded in
   UTF-8.

2.  Conventions Used in This Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server, respectively.  If a single "C:" or "S:" label applies to
   multiple lines, then the line breaks between those lines are for
   editorial clarity only and are not part of the actual protocol
   exchange.

   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 [RFC2119].

   Basic familiarity with the METADATA-SERVER extension [METADATA] and
   terms defined therein is required to understand this document.

3.  IMAP Protocol Changes

   The IMAP extension for persistent named searches is present in any
   IMAP4 implementation that advertises "FILTERS" as one of the
   supported capabilities in the CAPABILITY response or response code.

Melnikov & King             Standards Track                     [Page 2]
RFC 5466                      IMAP Filters                 February 2009

3.1.  FILTER SEARCH Criterion

   The FILTER criterion for the SEARCH command allows a client to
   reference by name a filter stored on the server.  Such filter was
   created by setting the server annotation named "/private/filters/
   values/<filter_name>" (or the server annotation "/shared/filters/