Internet DRAFT - draft-wener-lemonade-msgfilter

draft-wener-lemonade-msgfilter




Internet Draft: IMAP Extension for MSGFILTER                    M. Wener
Document: draft-wener-lemonade-msgfilter-02.txt              Nokia, Inc.
Expires:  August 2005                                      February 2005

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

    A STATUS 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. The full set of STATUS data 
    items are included except for the UIDVALIDITY.

    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: * STATUS INBOX (MESSAGES 3 RECENT 0 UNSEEN 0 UIDNEXT 497 )
                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: * STATUS INBOX (MESSAGES 3 RECENT 1 UNSEEN 1 UIDNEXT 498 )
                S: * 1 RECENT
                S: * FILTER SET 76 78 497
                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: * STATUS INBOX (MESSAGES 5 RECENT 0 UNSEEN 2 UIDNEXT 101 )
                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 Code

    While there are Filter Sets in effect in a session all normal IMAP
    commands are still legal. A FILTERED response code is returned 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 code 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 response
    code MUST be included on every such command.

    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: * STATUS INBOX (MESSAGES 5 RECENT 0 UNSEEN 2 UIDNEXT 101 )
                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

    A server may for a reason unknown to the client terminate all active
    filtering. The server MUST terminate the session or notify the client
    via a NO response with the FILTERED Response Code.

    When the later behavior is used, a FILTERED Response Code MUST be 
    returned in an untagged NO response in reponse to all commands that 
    took as an argument a sequence set if the Filter Set is no longer in
    effect for any reason that was not directly caused by the client.

    Example:    C: 1 FILTER SET TAG TravelingProfile
                S: * STATUS INBOX (MESSAGES 5 RECENT 0 UNSEEN 2 UIDNEXT 101 )
                S: * FILTER SET 78 80 90 91 98
                S: 1 OK FILTER SET Completed
		< Server Stops Filtering >
                C: 2 UID FETCH 91 FLAGS
                S: * NO [FILTERED] Filters have been terminated
                S: * 4 FETCH (FLAGS (\Seen) UID 91)
                S: 2 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 MUST always contain the exact set of UIDs that 
    are the result of all FILTER SET commands during this session. The
    set is subject to the accumulation rules specified in section 2.1.

    The FILTER SET response MUST be reruened only in reponse to FILTER
    SET commands.

    The set MAY also use sequence set range syntax for specifyng the set
    of UIDs. This is encouraged as it avoids possibly long strings of 
    UIDs.

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 sequence-set) /
                   ("TAG" SP astring))
                 ; mailbox-data is as defined in [IMAP4]
                 ; sequence-set 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") sequence-set

   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.