<> 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.