IMAP4 Extension for Named Searches (Filters)
RFC 5466
|
| Document |
Type |
|
RFC - Proposed Standard
(February 2009; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5466 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Chris Newman
|
|
Send notices to |
|
dave.cridland@isode.com
|
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]
Show full document text