<<draft-wener-lemonade-msgfilter-01.txt>>
Internet Draft: IMAP Extension for MSGFILTER M. Wener
Document: draft-wener-lemonade-msgfilter-01.txt Nokia, Inc.
Expires: May 2005 December 2004
IMAP Extension for MSGFILTER
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
In a mobile environment it is often desirable to allow a user to
restrict or constrain the set of messages that will be sent to
the mobile device. There may be several reasons. The user may
not want to pay for the bandwidth consumed, they may not want to
to consume memory on the phone or they may just want to restrict
what they get "bothered" by while in a mobile environment. This
draft defines a way to allow the user to restrict message sets per
folder.
1 Introduction and Overview
The purpose of this extension is to allow a client visibility to a
constrained message set while performing normal IMAP commands in the
Selected state. The benefits to a client are several:
1) Bandwidth reduction
2) Processing effort reduction
3) Memory consumption reduction
The target set of clients are those with limited resources such as
Mobile devices.
In addition it more easily allows the client to achieve a user
experience using selective information. This is the notion that when
a client becomes mobile the desire is to only deal with a very select
set of information in a controlled fashion.
It is acknowledged that much of the functionality defined in this
draft could be accomplished using a combination of the IMAP SEARCH
command and client logic. This is an optimization that allows the
client to achieve this more efficiently.
The goals are:
1) Extend IMAP functionality in an as minimalistic a way as possible.
2) Allow the set of messages that are part of a filter set to be
modified while the filter set is in effect.
3) Minimize load on the server. This is accomplished by requiring the
filter set to be transient during the life of the session. This
does not mean that the same Filter Set can not be active on more
then one session at a time.
If a server supports the message filtering extension then the keyword
MSGFILTER is returned in the capability string.
1.1 Definitions
Filter Set - A set of UIDs that are the result of applying a
collective group of FILTER SET commands. This set is what is visible
when one or more FILTER SET commands are in force. This visibility
constraint envelopes all commands issued during the session.
Filter Set Identifier - This is a name that refers to a profile that
defines a set of criteria used to constrain the Filter Set to a set
of UIDs. How this is accomplished is outside the scope of this
document. Where these criteria are stored is outside the scope of this
document.
2 Commands
All commands defined in this extension are only valid in the Selected
state.
2.1 FILTER SET Command
Arguments: OPTIONAL Sub-Command with arguments. The allowed sub
commands are SEARCH, UID, LIST and TAG. The SEARCH
command can be followed by all associated SEARCH
arguments. The TAG command MUST be followed by an
identifier. The UID sub command MUST be followed by one
or more numeric numbers.
Responses: REQUIRED untagged responses: FILTER SET, FILTER TAG
and EXISTS
Result: OK - filter set completed, now in filter state
NO - filter set failure
BAD - command unknown or arguments invalid
A FILTER SET command will restrict the set of UIDs that are visible
to the client. The three forms allow the Filter Set to be changed
during the session. The total Filter Set is an accumulation of all
FILTER SET commands issued during the session. The accumulation is
not a simple UNION.
The search command behaves as if it was preceeded by the UID prefix
command. A SEARCH Sub-Command will result in a set of UIDs that
match the search criteria.
A TAG Sub-Command will result in a set of UIDs that match some
external set of criteria. The argument pasted to the this Sub-
Command is a Filter Set Indentifier.
The LIST Sub-Command followed by a TAGS modifier tells the server
to list all opaque Filter Set Identifiers that it has available.
Being available means the server can apply these to produce a
Filter Set. Any identifier returned from this command may be used
with the TAG Sub-Command.
A UID Sub-Command takes two forms. The UID ADD form and the UID
REMOVE form. The impact the Filter Set as expected. ADD adds the
given UID set to the Filter Set. REMOVE removes the given UID from
the Filter Set.
Multiple FILTER SET commands may be issued during a single session.
The rules of accumulation are:
1) TAG Sub-Commands MUST replace ALL previous Sub-Commands,
including previous TAG Sub-Commands.
2) New SEARCH sub-commands MUST replace a previous SEARCH
Sub-Command. New SEARCH sub-commands MUST union with previous
TAG commands.
3) UID Sub-Commands are always cumulative. Multiple UID ADD
Sub-Commands will increase the Filter Set, while UID REMOVE
Sub-Commands will reduce the Filter Set if the specified UID
was already in the set.
Filter Sets are transient. A Filter Set only lasts for the duration
of the Session. A new Session requires the re-establishment of the
Filter Set.
An EXISTS response is sent as the first response in a Filter Set. It
represents the total number of messages visible after the
application of the latest FILTER SET.
Example: C: 1 SELECT INBOX
S: * 50 EXISTS
S: * 0 RECENT
S: ...
S: 1 OK [READ-WRITE] SELECT Completed
C: 2 FILTER SET SEARCH SINCE "10-Sep-2004"
S: * 3 EXISTS
S: * FILTER SET 76 78 90
S: 2 OK FILTER SET Completed
< ... Some time goes on, and the client wishes to remove
from consideration UID 90. Also, in the mean time a new
mail arrived ...>
C: 3 FILTER SET UID REMOVE 90
S: * 3 EXISTS
S: * 1 RECENT
S: * FILTER SET 76 78 95
S: 3 OK FILTER SET Completed
Example: C: 1 SELECT INBOX
S: * 50 EXISTS
S: * 0 RECENT
S: ...
S: 1 OK [READ-WRITE] SELECT Completed
C: 2 FILTER SET TAG TravelingProfile
S: * 5 EXISTS
S: * FILTER SET 78 80 90 91 98
S: 2 OK FILTER SET Completed
Example: C: 1 SELECT INBOX
S: * 50 EXISTS
S: * 0 RECENT
S: ...
S: 1 OK [READ-WRITE] SELECT Completed
C: 2 FILTER SET LIST TAGS
S: S: * FILTER TAG DEFAULT
S: S: * FILTER TAG Profile2
S: 2 OK FILTER SET Completed
3 Responses
3.1 FILTERED Response
While there are Filter Sets in effect in a session all normal IMAP
commands are still legal. A FILTERED response is returned when
issued to communicate to the client that the current set of
responses are representative of a Filter Set and not the total set
of messages that may have been returned had the Filter Set not been
in effect.
The FILTERED response is returned when any command is issued in
the Selected state and the sequence or UID arguments are sets that
may include numbers not explicitly asked for by the client. This
includes the FETCH, SEARCH, COPY and STORE commands.
The effect is that any COMMAND that may take a sequence id or a UID
will not see the specified message if it is not included in the
Filter Set.
Example: C: 1 FILTER SET TAG TravelingProfile
S: * 5 EXISTS
S: * FILTER SET 78 80 90 91 98
S: 1 OK FILTER SET Completed
C: 2 UID FETCH 91 FLAGS
S: * 4 FETCH (FLAGS (\Seen) UID 91)
S: 2 OK FETCH Completed
C: 3 UID FETCH 91:* FLAGS
S: * OK [FILTERED] Response may have been filtered
S: * 4 FETCH (FLAGS (\Seen) UID 91)
S: * 5 FETCH (FLAGS (\Seen) UID 98)
S: 3 OK FETCH Completed
3.2 FILTER SET response
When a FILTER SET command is issued the resulting set of message
UIDs is communicated to the client via the FILTER SET response. The
response always reflects the accumulated Filter Set. This requires
that each response always contain the exact set of UIDs that are
the result of all FILTER SET commands during this session.
3.3 FILTER TAG response
When a FILTER LIST TAGS command is issued the resulting list of
Filter Set Identifiers is communicated to the client via the FILTER
TAG response. The response always reflects the complete list of
available identifiers. Each identifier is available to be used as
an argument to the TAG Sub-Command.
4. Formal Syntax
mailbox-data = "FILTER" SP (("SET" SP *(SP nz-number)) /
("TAG" SP astring))
; mailbox-data is as defined in [IMAP4]
; nz-number is as defined in [IMAP4]
resp-text-code = "FILTERED"
; resp-text-code is as defined in [IMAP4]
command-select = filter_set
; command-select is as defined in [IMAP4]. The
; filter-set variable ias added to the already
; existing set of commands in the Selected state.
filter-set = "FILTER" SP "SET" SP (search / uid-set / tag-set /
list-set)
; search is as defined in [IMAP4]
uid-set = "UID" SP ("REMOVE" / ADD") *(SP nz-number)
tag-set = "TAG" SP astring
list-set = "LIST" SP "TAGS"
5 Author
Michael J. Wener
Enterprise Mobility Systems
Nokia, Inc.
EMail: Michael.Wener@Nokia.com
6 Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
7 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org."
References
[IMAP4] Crispin, M., "Internet Message Access Protocol Version
4rev1", RFC 3501, March 2003.