Subject: Windowing of LIST?
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Date: Wed, 27 Jun 2001 15:14:02 -0400
List-Id: <ietf-imapext.imc.org>

Following the LIST/NAMESPACE discussion on the IMAP list, I've had the idea 
that perhaps a WINDOWLIST extension could be defined, along the same lines 
as WINDOW, that would allow output windowing of the LIST command. Barry's 
proposed LIST extension document doesn't appear to directly address output 
windowing of LIST, though it could be done as an extension to the extended 
list commands optional arguments.

Any thoughts on this?

To be honest with you, right now I would find WINDOWLIST much more 
worthwhile than WINDOW.

-- 
Cyrus Daboo

Date: Wed, 27 Jun 2001 15:10:52 -0400
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: draft-ietf-imapext-window-00.txt
Sender: [email-masked]

--On Tuesday, June 26, 2001 4:08 PM -0400 Ken Murchison <[email-masked]> 
wrote:

> Any thoughts on output filtering for THREAD?  For instance "show me only
> those threads containing unseen messages".  IIRC, Mark seemed to think
> that this might be a good fit for WINDOW/VIEW instead of making it a
> separate THREAD algorithm.

Right now WINDOW doesn't do any 'filtering' of the output results from the 
sub-command its targetting. However, adding a 'select only threads 
containing xxx' option to it would require some kind of additional 
filtering between the thread command results and the output window that the 
client operates on. For that reason I think this would best be left to the 
THREAD command - i.e. a new REFERENCES-UNSEEN thread algorithm.

I guess I should add and define the term 'output filtering' in the draft to 
explain how this differs from 'output windowing' (which is only what WINDOW 
does). I guess there is also the concept of 'input filtering' which should 
be described too.

-- 
Cyrus Daboo

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-window-00.txt
Date: Wed, 27 Jun 2001 07:03:06 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP WINDOW Extension
	Author(s)	: C. Daboo, C. Newman
	Filename	: draft-ietf-imapext-window-00.txt
	Pages		: 13
	Date		: 26-Jun-01
	
The WINDOW extension to the Internet Message Access Protocol [IMAP4]
permits windowing of the results of specific IMAP commands, so that
clients can retrieve the results in ranges to implement paging of
results or virtual scrollbars.  This eliminates the need to get and
manage the entire result set, improving scalability for large
mailboxes and slow connections.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-window-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-window-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-window-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-window-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-window-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 26 Jun 2001 16:08:46 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: draft-ietf-imapext-window-00.txt
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> I just sent the attached draft off to the draft repository.
> 
> This draft describes a proposed WINDOW extension that is designed as a
> simplified alternative to the VIEW extension (as discussed informally at
> the last IETF meeting). Its goal is to allow clients to 'window' (get a
> subset) of the results of SEARCH and SORT commands.
> 
> It does not address WINDOWing of THREAD. We felt that trying to design a
> windowing mechanism to cope with the hierarchical nature of THREAD would
> lead to a much more complex document, and that in general the complexity of
> windowing thread would likely be more costly than just getting the entire
> results set without it.

Any thoughts on output filtering for THREAD?  For instance "show me only
those threads containing unseen messages".  IIRC, Mark seemed to think
that this might be a good fit for WINDOW/VIEW instead of making it a
separate THREAD algorithm.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 25 Jun 2001 19:51:16 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-window-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 25 Jun 2001, Cyrus Daboo wrote:
> This draft describes a proposed WINDOW extension that is designed as a
> simplified alternative to the VIEW extension (as discussed informally at
> the last IETF meeting). Its goal is to allow clients to 'window' (get a
> subset) of the results of SEARCH and SORT commands.

I have skimmed the WINDOW extension proposal.  Although I have not
reviewed it in detail, it looks like something that I can support.

I am not sure that I understand why this framework is superior to a static
version of VIEW.  However, if it addresses Chris' requirements and doesn't
have any hidden negative impact on my requirements for SORT/THREAD, then
it's a good thing and we should move forward on it.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Date: Mon, 25 Jun 2001 20:11:56 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: draft-ietf-imapext-window-00.txt
Sender: [email-masked]

--==========00413164==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I just sent the attached draft off to the draft repository.

This draft describes a proposed WINDOW extension that is designed as a 
simplified alternative to the VIEW extension (as discussed informally at 
the last IETF meeting). Its goal is to allow clients to 'window' (get a 
subset) of the results of SEARCH and SORT commands.

It does not address WINDOWing of THREAD. We felt that trying to design a 
windowing mechanism to cope with the hierarchical nature of THREAD would 
lead to a much more complex document, and that in general the complexity of 
windowing thread would likely be more costly than just getting the entire 
results set without it.

-- 
Cyrus Daboo
--==========00413164==========
Content-Type: text/plain; charset=iso-8859-1;
 name="draft-ietf-imapext-window-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-ietf-imapext-window-00.txt";
 size=28230

IMAP Extensions Working Group                                 C. Daboo
Internet Draft: IMAP WINDOW Extension                        C. Newman
Document: draft-ietf-imapext-window-00.txt                   June 2001

                         IMAP WINDOW Extension
   =20
Status of this Memo
   =20
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.  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.
   =20
    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."
   =20
    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.
   =20
   =20
Copyright Notice
   =20
    Copyright (C) The Internet Society (2001). All Rights Reserved.

Daboo, Newman               Expires December 2001               [Page =
1]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

                           Table of Contents
     1  Abstract  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
     2  Conventions Used in This Document  . . . . . . . . . . . . .   2
     3  Introduction and Overview . . . . . . . . . . . . . . . . . .  3
     4  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .   4
     5  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  5
       5.1  Input Window . . . . . . . . . . . . . . . . . . . . . .   5
       5.2  Output Results  . . . . . . . . . . . . . . . . . . . . .  5
       5.3  Output Position  . . . . . . . . . . . . . . . . . . . .   5
       5.4  Output Window . . . . . . . . . . . . . . . . . . . . . .  5
       5.5  Anchor . . . . . . . . . . . . . . . . . . . . . . . . .   5
       5.6  Anchor Offset . . . . . . . . . . . . . . . . . . . . . .  5
     6  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7  Commands  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       7.1  WINDOW Command . . . . . . . . . . . . . . . . . . . . .   6
         7.1.1  WINDOW SET  . . . . . . . . . . . . . . . . . . . . .  6
         7.1.2  WINDOW SHOW  . . . . . . . . . . . . . . . . . . . .   7
         7.1.3  WINDOW UPDATE . . . . . . . . . . . . . . . . . . . .  8
         7.1.4  WINDOW MAP . . . . . . . . . . . . . . . . . . . . .   9
       7.2  UID Command modifications . . . . . . . . . . . . . . . . 10
         7.2.1  UID WINDOW SHOW  . . . . . . . . . . . . . . . . . .  10
         7.2.2  UID WINDOW MAP  . . . . . . . . . . . . . . . . . . . 10
     8  Responses  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       8.1  WINDOW SET Untagged Response  . . . . . . . . . . . . . . 10
       8.2  WINDOW Untagged Response . . . . . . . . . . . . . . . .  10
       8.3  WINDOW MAP Untagged Response  . . . . . . . . . . . . . . 10
     9  Handling message expunges  . . . . . . . . . . . . . . . . .  10
    10  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
    11  Security Considerations  . . . . . . . . . . . . . . . . . .  12
    12  References  . . . . . . . . . . . . . . . . . . . . . . . . . 12
    13  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  12
    14  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . 12
   =20
   =20
1 Abstract
   =20
    The WINDOW extension to the Internet Message Access Protocol [IMAP4]
    permits windowing of the results of specific IMAP commands, so that
    clients can retrieve the results in ranges to implement paging of
    results or virtual scrollbars.  This eliminates the need to get and
    manage the entire result set, improving scalability for large
    mailboxes and slow connections.
   =20
   =20
2 Conventions Used in This Document
   =20
    The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
    NOT", and "MAY" in this document are to be interpreted as described
    in "Key words for use in RFCs to Indicate Requirement Levels"
    [KEYWORDS].
   =20

Daboo, Newman               Expires December 2001               [Page =
2]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    Formal syntax is defined using ABNF [ABNF].
   =20
    In examples, "C:" and "S:" indicate lines sent by the client and
    server respectively.
   =20
   =20
3 Introduction and Overview
   =20
    The WINDOW extension is present in any IMAP4 implementation which
    returns "WINDOW" as one of the supported capabilities in the
    CAPABILITY command.
   =20
    The WINDOW extension specifies one new command (with a number of
    variants) and introduces one new untagged response (with a number of
    variants).
   =20
    The WINDOW command is an optimization for scalability purposes;
    clients can provide the same functionality, albeit more slowly, by
    using existing commands.
   =20
    The SEARCH [IMAP4], SORT [SORT] and THREAD [THREAD] commands in
    IMAP4 return a list of results equal to the size of the input
    window.  The input window is determined by the parameters to each
    command.  For example, the SEARCH command can limit its input window
    by using sequence number or UID number ranges as parameters to the
    SEARCH:
   =20
    Example:    C: A999 SEARCH UNSEEN 10:20
                S: * SEARCH 1 2 4 6
                S: A999 OK SEARCH completed
   =20
    In the above example, an input window of messages with sequence
    numbers in the range 10 through 20 are the only ones considered by
    the SEARCH command.  This limits the output to a maximum of 11 hits.
    The SORT and THREAD commands both take search criteria as
    parameters, and thus can also accomplish input windowing if desired.
   =20
    While input windowing can reduce the number of results returned, it
    does not offer a way to window the results based on their output
    ordering or size.  The design goal of the WINDOW extension is to
    allow clients to do output windowing of the results of SEARCH and
    SORT commands, and to provide an extensible mechanism for future
    IMAP command extensions that return results as a list of sequence
    numbers or UIDs.
   =20
    In order to keep the WINDOW extension simple, the THREAD command is
    not included as one of the commands that WINDOW works with, due to
    the hierarchical nature of the THREAD command results.
   =20
    This extension makes the following changes to the IMAP4 protocol:
   =20

Daboo, Newman               Expires December 2001               [Page =
3]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    (a) Adds a new WINDOW command which takes one of four forms:
      =20
        (i) The first form, WINDOW SET, takes an optional sub-command
        and is used to initiate or cancel the windowing mechanism on the
        server.  When initiating a window, the server creates an output
        results set consisting of all messages returned by the
        sub-command, in their appropriate ordering.  The server returns
        the maximum size of the output results set as well as the
        position of the first unseen message in the output results set.
       =20
        (ii) The second form, WINDOW SHOW, takes parameters that allow
        the client to precisely specify the output window range.  This
        command causes the server to return the message numbers for
        messages in this output window, which is a subset of the entire
        output results set.
       =20
        (iii) The third form, WINDOW UPDATE, causes the server to update
        the output results set to reflect any changes to the state of
        the mailbox since the last WINDOW SET <sub-command> command was
        issued.
       =20
        (iv) The fourth form, WINDOW MAP, the client provides a set of
        ordered message sequence numbers or UIDs and the server returns
        the output positions of those messages in the current output
        results set.  For example, this allows a client to preserve user
        message selections across WINDOW UPDATEs or other mailbox
        changes.
       =20
    (b) Adds a new WINDOW untagged response which takes one of three
        forms:
      =20
        (i) The first form, WINDOW SET, returns the size and position of
        the first unseen message in the output results set.
       =20
        (ii) The second form, WINDOW, returns the output window range.
       =20
        (iii) The third form, WINDOW MAP, returns the mapping results
        from message sequence number or UIDs to output positions in the
        current output results set.
       =20
    (c) Modifies the EXPUNGE untagged response to include the output
        position of the message being expunged, when a WINDOW SET
        operation is in effect.
      =20
   =20
    The rest of this document describes these changes more rigorously.
   =20
   =20
4 Open Issues
   =20
    - Should we have WINDOW FETCH and WINDOW STORE commands to allow
    accessing messages by output position?

Daboo, Newman               Expires December 2001               [Page =
4]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

5 Terminology
   =20
5.1 Input Window
   =20
    The set of messages used as input to a SEARCH or SORT command.  In
    the case of SEARCH this can be controlled via the message number or
    UID range search criteria.  In the case of SORT this is controlled
    by the search criteria used with those commands.
   =20
5.2 Output Results
   =20
    The set of ordered message numbers or UIDs that are the results of a
    SEARCH or SORT command.
   =20
5.3 Output Position
   =20
    The position of a message in the output results, a number from 1 to
    <n> where <n> is the total number of messages in the output results.
   =20
5.4 Output Window
   =20
    A contiguous range of messages in the output results that the client
    wishes to know about.
   =20
5.5 Anchor
   =20
    A specific message that the client wants to appear at a particular
    position in the output window, requiring the server to determine the
    actual output window range to accommodate this requirement.  For
    example, when first opening a mailbox, the client may want to
    position the first unseen message at the top of the list presented
    to the user by scrolling its graphical window to the appropriate
    place.
   =20
5.6 Anchor Offset
   =20
    The position of the anchor message in the output window, relative to
    the start or end of the output window.
   =20
   =20
6 Examples
   =20
    The examples below will all use the following output results set for
    consistency.  There are a total of 20 messages in this set and the
    first unseen message in the set has a sequence number of 14 and
    appears at output position 3.
   =20
    Output results:
   =20
    11 12 14 16 30 22 24 13 15 31 10 44 21 23 42 41 37 27 26 25
          ^
          first unseen message

Daboo, Newman               Expires December 2001               [Page =
5]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    The output results after an update.  There are a total of 14
    messages in this set and the first unseen message in the set has a
    sequence number of 22 and appears at output position 6.
   =20
    Output results after an update:
   =20
    11 12 14 16 30 22 24 13 15 31 10 44 21 23
                   ^
                   first unseen message
   =20
   =20
7 Commands
   =20
7.1 WINDOW Command
   =20
    The WINDOW command is only available when the server is in 'selected
    state' [IMAP4].  Thus a successful SELECT or EXAMINE command MUST
    have been issued before WINDOW can be used.  If a client attempts to
    use WINDOW while the server is not in 'selected state', then the
    server MUST respond with a BAD response.
   =20
    To avoid ambiguities when messages are expunged from the mailbox,
    the server MUST NOT send untagged EXPUNGE responses whilst a WINDOW
    command is in progress,
   =20
    The WINDOW command takes one of four forms.
   =20
7.1.1 WINDOW SET
   =20
    Arguments: OPTIONAL sub-command and associated arguments:
               this draft currently only allows the SEARCH and
               SORT [SORT] commands as the sub-commands.
   =20
    Responses: REQUIRED untagged responses: WINDOW SET
   =20
    Result:    OK - window set completed, now in window state
               NO - window set failure
               BAD - command unknown or arguments invalid
   =20
    The WINDOW SET command is used to define the set of messages that
    form the output results.  This set is determined by the result of
    the sub-command, and is ordered according to the sub-command.  The
    server stores the output results, which are used to return the data
    the client may request using other WINDOW commands.  The server MUST
    return an untagged WINDOW SET response to the WINDOW SET command,
    indicating the total number of messages in the output results, as
    well as the output position number of the first unseen message in
    the output results, or zero if there are no unseen messages in the
    output results.
   =20
    Example:    C: A999 WINDOW SET SEARCH FROM "Smith"
                S: * WINDOW SET 20 3

Daboo, Newman               Expires December 2001               [Page =
6]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

                S: A999 OK WINDOW SET completed
   =20
    In this example an output results set on a SEARCH command is
    created.  The output results have a total of 20 messages in it, and
    the first unseen message is at output position 3 in the output
    results.
   =20
    A WINDOW SET command with no arguments is used to cancel an earlier
    WINDOW SET with a sub-command.  This allows a client to turn off the
    windowing behaviour.
   =20
7.1.2 WINDOW SHOW
   =20
    Arguments: the message number or starting position of the anchor =
message,
               the anchor position within the output window,
               the size of the output window to return.
   =20
    Responses: REQUIRED untagged responses: WINDOW
   =20
    Result:    OK - window show completed
               NO - window show failure
               BAD - command unknown or arguments invalid
   =20
    The WINDOW SHOW command is used by the client to retrieve portions
    of the output results defined by an earlier WINDOW SET command.  If
    the server is in selected state and there was no previous WINDOW SET
    command, or the WINDOW SET command was cancelled, then the server
    MUST respond with a BAD response.
   =20
    The WINDOW SHOW command takes three parameters:
   =20
    a) An identifier indicating the position of the anchor message in
    the output window.  The client can specify the message by either its
    sequence number, uid or position in the output results set.  This is
    done by using a single character before the numeric value to
    indicate what type it is: 'S' for sequence number, 'U' for uid and
    'P' for output position.
   =20
    b) The requested anchor position where the anchor message should
    appear in the output window, relative to either the start or end of
    the output window.  The server MUST return a BAD response if the
    requested anchor position exceeds the size of the output window, as
    specified in the third argument.
   =20
    c) The size of the output window.  If the size provided by the
    client exceeds the size of the output results, the server MUST
    return a BAD response.
   =20
    The server MUST respond with an untagged WINDOW response indicating
    the output position of the first message in the output window range,
    followed by the message numbers of the messages in the range
    requested by the client.  In some cases the anchor may not appear at

Daboo, Newman               Expires December 2001               [Page =
7]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    the relative offset in the output window requested by the client,
    because the offset would result in the output window exceeding the
    range of the output results.
   =20
    Example:    C: A999 WINDOW SHOW P 3 +0 10
                S: * WINDOW 3 14 16 30 22 24 13 15 31 10 44
                S: A999 OK WINDOW SHOW completed
   =20
    In this example the client requests the server to return the message
    sequence numbers for 10 messages, anchored on output position 3 (the
    first unseen message), with the anchor set to appear first in the
    output window.  The server responds with the output position of the
    first message in the output window range, followed by the 10 message
    sequence numbers corresponding to the requested messages - the
    message with sequence number 14 is the anchor and the first unseen
    message in the output results.
   =20
    Example:    C: A999 WINDOW SHOW P 20 -0 10
                S: * WINDOW 11 10 44 21 23 42 41 37 27 26 25
                S: A999 OK WINDOW SHOW completed
   =20
    In this example the client requests the server to return the message
    sequence numbers for the last ten messages in the output results.
    This is accomplished by setting the anchor to the last output
    position, and requesting the anchor to appear last in the output
    window.
   =20
    Example:    C: A999 WINDOW SHOW S 14 +5 10
                S: * WINDOW 1 11 12 14 16 30 22 24 13 15 31
                S: A999 OK WINDOW SHOW completed
   =20
    In this example the client requests an output window centered on the
    message with sequence number 14.  However, that message actually
    appears at output position 3, so the specified anchor position
    cannot be accommodated, so the output window contains the anchor at
    position 3 instead of the requested position 5 from the start.
   =20
7.1.3 WINDOW UPDATE
   =20
    Arguments: None.
   =20
    Responses: REQUIRED untagged responses: WINDOW SET
   =20
    Result:    OK - window update completed
               NO - window update failure
               BAD - command unknown
   =20
    The WINDOW UPDATE command is used to update the output results
    created by a previous WINDOW SET command.  This is needed because
    WINDOW SET's output results are static - i.e. they do not change
    even when the state of messages changes, or new messages are added
    to the mailbox.  In order to account for change to the mailbox, the

Daboo, Newman               Expires December 2001               [Page =
8]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    client must use the WINDOW UPDATE command.  If the server is in
    selected state and there was no previous WINDOW SET command, or the
    WINDOW SET command was cancelled, then the server MUST respond with
    a BAD response.
   =20
    The server MUST return an untagged WINDOW SET response to the WINDOW
    SET command, indicating the total number of messages in the new
    output results, as well as the output position number of the first
    unseen message in the new output results, or zero if there are no
    unseen messages in the new output results.
   =20
    Example:    C: A999 WINDOW UPDATE
                S: * WINDOW SET 14 6
                S: A999 OK WINDOW UPDATE completed
   =20
    In this example the new output results have a total of 14 messages
    in it, and the first unseen message is now at output position 6 in
    the new output results.
   =20
7.1.4 WINDOW MAP
   =20
    Arguments: Message number range.
   =20
    Responses: REQUIRED untagged responses: WINDOW MAP
   =20
    Result:    OK - window map completed
               NO - window  map failure
               BAD - command unknown
   =20
    The WINDOW MAP command allows a client to determine the output
    positions of messages based on their sequence number or uid (if the
    UID command modifier is also used).  This is required to help
    preserve a user's message selection state before and after a WINDOW
    UPDATE command is used.
   =20
    If the server is in selected state and there was no previous WINDOW
    SET command, or the WINDOW SET command was cancelled, then the
    server MUST respond with a BAD response.
   =20
    The server MUST return an untagged WINDOW MAP response to the WINDOW
    MAP command, indicating the new output positions of the requested
    messages, corresponding to the range used as the argument to the
    command.  The server MUST return an output position number of zero
    for any messages that are no longer in the output results.
   =20
    If the message number argument specifies one or more messages that
    are not in the output results set, the server MUST respond with a
    BAD response.
   =20
    Example:    C: A999 WINDOW MAP 5,14:16,22,24
                S: * WINDOW MAP 0 3 9 4 5 6
                S: A999 OK WINDOW MAP completed

Daboo, Newman               Expires December 2001               [Page =
9]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    In this example the client requests the output positions of messages
    with sequence numbers 5, 14, 15, 16, 22 and 24.  Message 5 is not in
    the output results set, so its output position number is zero.
   =20
7.2 UID Command modifications
   =20
    The IMAP UID command is used to modify the meaning of another
    command and/or the untagged results of a command.  The WINDOW
    extensions extends the UID command to accept certain WINDOW commands
    as outlined below.
   =20
7.2.1 UID WINDOW SHOW
   =20
    The UID WINDOW SHOW causes the untagged WINDOW response for the
    WINDOW SHOW command to contain message uids rather than message
    sequence numbers.
   =20
7.2.2 UID WINDOW MAP
   =20
    The UID WINDOW MAP causes the message number range argument to the
    WINDOW MAP command to be interpreted as message uids rather than
    message sequence numbers.
   =20
   =20
8 Responses
   =20
8.1 WINDOW SET Untagged Response
   =20
    The WINDOW SET untagged response is used to inform the client of the
    total number of messages in the output results set and the output
    position of the first unseen message in the output results, or zero
    if no unseen message is present in the output results.  The WINDOW
    SET results can only occur as the result of a WINDOW SET or WINDOW
    UPDATE command.
   =20
8.2 WINDOW Untagged Response
   =20
    The WINDOW untagged response returns the output position of the
    first message in the requested output window, followed by the
    message numbers of the messages in the requested output window.  The
    message numbers may be either sequence numbers or uids depending on
    whether the UID command modifier is used.  The WINDOW response can
    only occur as the result of a WINDOW SHOW command.
   =20
8.3 WINDOW MAP Untagged Response
   =20
    The WINDOW MAP untagged response returns the output positions of
    messages in the output results, ordered according to the ordering of
    message numbers in the WINDOW MAP command.  The WINDOW MAP response
    can only occur as the result of a WINDOW MAP command.
   =20
   =20

Daboo, Newman              Expires December 2001              [Page =
10]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

9 Handling message expunges
   =20
    When a WINDOW SET command is in effect, the server MUST modify any
    untagged EXPUNGE responses it sends to the client to include the
    output position of the message being expunged, or zero if the
    message being expunged is not in the output results.  After each
    EXPUNGE response the output positions for the current WINDOW SET
    must be readjusted to account for the expunged message.  When an
    untagged EXPUNGE response with a non-zero output position is seen by
    the client, the client MUST adjust its output window and output
    results state to take account of the expunged message.
   =20
    Example:    C: A999 NOOP
                S: * 1 EXPUNGE 0
                S: * 10 EXPUNGE 1
                S: * 10 EXPUNGE 1
                S: A999 OK
   =20
    In this example three messages are expunged from the mailbox.
    Message number 1 is not part of the previously determined output
    results so its output position is shown as zero.  Message number 11
    was at output position 1, and message number 12 was at output
    position number 1 after message number 11 was expunged.
   =20
   =20
10 Formal Syntax
   =20
    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) notation as specified in [ABNF].
   =20
    Non-terminals referenced but not defined below are as defined by
    [IMAP4].
   =20
    Except as noted otherwise, all alphabetic characters are case-
    insensitive.  The use of upper or lower case characters to define
    token strings is for editorial clarity only.  Implementations MUST
    accept these strings in a case-insensitive fashion.
   =20
    window-set-cmd     =3D "WINDOW SET" SP window-set-arg
   =20
    window-set-arg     =3D search / sort / OTHER
                           ; search is defined in [IMAP4]
                           ; sort is defined in [SORT]
                           ; OTHER reserved for future definition
   =20
    window-update-cmd  =3D "WINDOW UPDATE"
   =20
    window-set-resp    =3D "*" SP "WINDOW SET" SP number SP number
   =20
    window-show-cmd    =3D "WINDOW SHOW" SP anchor-pos
                         SP anchor-rel SP nz-number
   =20

Daboo, Newman              Expires December 2001              [Page =
11]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    anchor-pos        =3D ("S" / "U" / "P") SP nz-number
                           ; "S" indicates sequence number
                           ; "U" indicates uid
                           ; "P" indicates output position
   =20
    anchor_rel        =3D ("+" / "-") number
                           ; "+" indicates offset from start
                           ; "-" indicates offset from end
   =20
    window-resp       =3D "*" SP "WINDOW" SP nz-number *(SP nz-number)
   =20
    window-map-cmd    =3D "WINDOW MAP" SP set
   =20
    window-map-resp   =3D "*" SP "WINDOW MAP" SP number *(SP number)
   =20
    message-data      /=3D nz-number SP "EXPUNGE" SP number
                           ; modifies [IMAP4] EXPUNGE response
                           ; to return output position when
                           ; WINDOW SET is in effect
   =20
   =20
11 Security Considerations
   =20
    There are no known security issues with this extension.
   =20
   =20
12 References
   =20
    [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
    ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
    November 1997.
   =20
    [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
    Requirement Levels", RFC 2119, Harvard University, March 1997.
   =20
    [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
    4rev1", RFC 2060, University of Washington, December 1996.
   =20
    [SORT] Crispin, M., "Internet Message Access Protocol - SORT
    Extension", draft-ietf-imapext-sort-03.txt (Work in progress)
   =20
    [THREAD] Crispin, M., "Internet Message Access Protocol - THREAD
    Extension", draft-crispin-imapext-thread-01.txt (Work in progress)
   =20
   =20
13 Acknowledgments
   =20
    This work is the result of many discussions within the imap-ext
    working group, and is based on the original VIEW draft.
   =20
   =20

Daboo, Newman              Expires December 2001              [Page =
12]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

14 Authors' Addresses
   =20
    Cyrus Daboo
    Cyrusoft International, Inc.
    Suite 780, 5001 Baum Blvd.
    Pittsburgh, PA 15213 USA

    Email: [email-masked]
   =20
   =20
    Chris Newman
    Sun Microsystems
    1050 Lakes Drive
    West Covina, CA 91790 USA

    Email: [email-masked]

Daboo, Newman              Expires December 2001              [Page 13]
--==========00413164==========--

Date: Wed, 13 Jun 2001 20:44:43 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, Ken Murchison <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-imapext-thread
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 13 Jun 2001, Cyrus Daboo wrote:
> There are two types of 'windowing' mode: input windowing and output
> windowing.

To expand on Cyrus' excellent summary, you need both types of windowing.
There are numerous cases where you do not want to sort or thread all
messages.

SORT and THREAD do input windowing because it is easy and obvious how to
do it, and because it follows the theme of SORT/THREAD being merely
expanded forms of SEARCH (or SEARCH the most degenerate form of
SORT/THREAD).

Right now, output windowing is done by the application.  I have stood firm
on NOT putting output windowing into SORT/THREAD, because I believe that
server-based output windowing will probably need to go through multiple
generations of evolution before it can replace application-based output
windowing.  If server-based output windowing is done by a VIEW or WINDOW
command, then it can evolve without forcing new generations of
SORT/THREAD.  Breaking up the problem into smaller pieces is a Good Thing.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Date: Wed, 13 Jun 2001 18:26:08 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Ken Murchison <[email-masked]>, Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-imapext-thread
Sender: [email-masked]

Cyrus Daboo <[email-masked]>
> --On Wednesday, June 13, 2001 03:50:07 PM +0200 Arnt Gulbrandsen 
> <[email-masked]> wrote:
> 
> >> It can't because the unseen search takes place BEFORE the threading.
> >
> > The answer sounds like putting the cart before the horse... _why_ does
> > the search take place before threading?
> 
> You need to think about this as two different actions (I've actually 
> written some of this up in the ficticious WINDOW draft which I hope to get 
> out soon):

I've been looking forward to reading that, actually.

> There are two types of 'windowing' mode: input windowing and output 
> windowing.
...

I can understand that. However, I get the impression that input windowing
in the case of THREAD isn't considered very useful. Is that right?

With output windowing, THREAD would be a sort of "SEARCH, and give me
context for the results, and give me the results in the right order"
command.  What does the input windowing do for the command?

> THREAD is also complicated to do output windowing on because of the nature 
> of the hierarchical data it outputs.

Yes. But a bit of graph colouring doesn't sound scary, compared to the
Zawinski algorithm THREAD describes.

--Arnt

Date: Wed, 13 Jun 2001 10:48:47 -0400
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, Ken Murchison <[email-masked]>
cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-imapext-thread
Sender: [email-masked]

--On Wednesday, June 13, 2001 03:50:07 PM +0200 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> It can't because the unseen search takes place BEFORE the threading.
>
> The answer sounds like putting the cart before the horse... _why_ does
> the search take place before threading?

You need to think about this as two different actions (I've actually 
written some of this up in the ficticious WINDOW draft which I hope to get 
out soon):

There are two types of 'windowing' mode: input windowing and output 
windowing.

Input windowing restricts the set of messages that a command acts upon. In 
the case of the SORT and THREAD commands, this is controlled via the search 
parameters that they take. In the case of the SEARCH command, input 
windoing can be accomplished by using sequence/uid ranges in the search 
criteria. Other commands that accept sequence/uid ranges effectively do 
input windowing too (e.g. FETCH). Also, the LIST command provides a way to 
do input windowing by using * or % wildcards to match ranges of mailbox 
names.

Output windowing means taking the results of a command and 
sub-setting/filtering those in some way. Neither SORT nor THREAD do this - 
you get the full range of inputs in the output. This is different than 
input windowing because it is applied after the command has run and acts on 
the results (and the order of the results in the case of SORT and THREAD). 
The LIST command too could benefit from output windowing that would lket 
clients get ranges of matching mailboxes rather than the whole lot.

SEARCH is somewhat of a special case as input and output windowing are 
effectively the same.

THREAD is also complicated to do output windowing on because of the nature 
of the hierarchical data it outputs.

-- 
Cyrus Daboo

Date: Wed, 13 Jun 2001 15:50:07 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-imapext-thread
Sender: [email-masked]

Ken Murchison <[email-masked]>
> It can't because the unseen search takes place BEFORE the threading.

The answer sounds like putting the cart before the horse... _why_ does
the search take place before threading?

--Arnt

Date: Wed, 13 Jun 2001 09:30:30 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Arnt Gulbrandsen <[email-masked]>
CC: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-imapext-thread
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Ken Murchison <[email-masked]>
> > Arnt Gulbrandsen wrote:
> > > Actually, subsetting would help with the cases I'm most interested in,
> > > particularly if the server is permitted to also return answers outside the
> > > requested set:  "Show me all the threads where there's new mail", "show me
> > > all the messages from [email-masked], and the threads to which those
> > > messages belong", "show me all discussion in our department-wide archive
> > > where the subject included 'fumble'" and so on.
> >
> > If I understand what you are looking for here, you want to filter the
> > messages AFTER they have been threaded.
> 
> Yes; that's one way of looking at it.
> 
> > Mark and I have discussed this
> > in the past, and other algorithms which are derivatives of REFERENCES
> > are possible.  For instance, a REFERENCES.UNSEEN algorithm would return
> > only those threads which contain at least one \Unseen message (similar
> > to Netscape's "Threads with Unread").
> 
> But isn't that really duplicating the fourth argument in the second?
> You're suggesting that
> 
>         thread references.unseen utf-8 unseen

This would return the same results as the one below because you've
thrown away the messages which have been read before you start
threading.  You'd want to do

	thread references.unseen utf-8 all

which first will thread ALL messages, and then only return those threads
containing unread messages.

> should return what I think
> 
>         thread references utf-8 unseen
> 
> should.

It can't because the unseen search takes place BEFORE the threading.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 13 Jun 2001 10:48:24 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-imapext-thread
Sender: [email-masked]

Ken Murchison <[email-masked]>
> Arnt Gulbrandsen wrote:
> > Actually, subsetting would help with the cases I'm most interested in,
> > particularly if the server is permitted to also return answers outside the
> > requested set:  "Show me all the threads where there's new mail", "show me
> > all the messages from [email-masked], and the threads to which those
> > messages belong", "show me all discussion in our department-wide archive
> > where the subject included 'fumble'" and so on.
> 
> If I understand what you are looking for here, you want to filter the
> messages AFTER they have been threaded.

Yes; that's one way of looking at it.

> Mark and I have discussed this
> in the past, and other algorithms which are derivatives of REFERENCES
> are possible.  For instance, a REFERENCES.UNSEEN algorithm would return
> only those threads which contain at least one \Unseen message (similar
> to Netscape's "Threads with Unread").

But isn't that really duplicating the fourth argument in the second?
You're suggesting that

	thread references.unseen utf-8 unseen

should return what I think

	thread references utf-8 unseen

should.

> To do something like your last two examples, we would have to come up
> with a way, either with the (upcoming?) VIEW/WINDOW extension or an
> extension to THREAD, to provide generic post-thread filtering.

If the server's permitted to return MSNs/UIDs for an entire thread when at
least one message in the thread matches the search criteria for that
thread command, that should do it.

--Arnt

Date: Tue, 12 Jun 2001 22:21:21 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Arnt Gulbrandsen <[email-masked]>
CC: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-imapext-thread
Sender: [email-masked]

Sorry about the delayed response.  Just catching up on old mailing list
stuff.

Arnt Gulbrandsen wrote:
> 
> Actually, subsetting would help with the cases I'm most interested in,
> particularly if the server is permitted to also return answers outside the
> requested set:  "Show me all the threads where there's new mail", "show me
> all the messages from [email-masked], and the threads to which those
> messages belong", "show me all discussion in our department-wide archive
> where the subject included 'fumble'" and so on.

If I understand what you are looking for here, you want to filter the
messages AFTER they have been threaded.  Mark and I have discussed this
in the past, and other algorithms which are derivatives of REFERENCES
are possible.  For instance, a REFERENCES.UNSEEN algorithm would return
only those threads which contain at least one \Unseen message (similar
to Netscape's "Threads with Unread").

To do something like your last two examples, we would have to come up
with a way, either with the (upcoming?) VIEW/WINDOW extension or an
extension to THREAD, to provide generic post-thread filtering.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 11 Jun 2001 14:18:13 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Progress
Sender: [email-masked]

--On Friday, June 8, 2001 11:01 AM -0500 Pete Resnick 
<[email-masked]> wrote:

> Our progress in this group has been glacial. Can I get a status
> report from document editors about where they think they are? (I know
> where BINARY is, but I want to hear about the rest.) It's time to
> fish or cut bait folks.
>
> After I hear back, I'll summarize and we'll figure out what our next
> step is, including whether to meet in London.

VIEW

Following the discussions at Minneapolis IETF: VIEW in its last published 
form has been discarded as being too complex. Chris proposed a new WINDOW 
extension that does output windowing of SORT/THREAD results without the 
complex dynamic update behaviour of VIEW. He and I were working on a draft 
of this, but its been languishing in a folder on my desktop for a while. I 
will try and get this finished and posted as a draft by the end of the week.

ANNOTATE

The last draft went out before Minneapolis. There haven't been any comments 
on it apart from one suggestion by Alexey. There are a number of 
outstanding issues that are described in the draft. What I will do is put 
together a message with each outstanding issue described to garner feedback.

-- 
Cyrus Daboo

Date: Fri, 8 Jun 2001 11:01:35 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Progress
Sender: [email-masked]

Our progress in this group has been glacial. Can I get a status 
report from document editors about where they think they are? (I know 
where BINARY is, but I want to hear about the rest.) It's time to 
fish or cut bait folks.

After I hear back, I'll summarize and we'll figure out what our next 
step is, including whether to meet in London.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Date: Wed, 27 Jun 2001 15:14:02 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Windowing of LIST?
Sender: [email-masked]

Following the LIST/NAMESPACE discussion on the IMAP list, I've had the idea 
that perhaps a WINDOWLIST extension could be defined, along the same lines 
as WINDOW, that would allow output windowing of the LIST command. Barry's 
proposed LIST extension document doesn't appear to directly address output 
windowing of LIST, though it could be done as an extension to the extended 
list commands optional arguments.

Any thoughts on this?

To be honest with you, right now I would find WINDOWLIST much more 
worthwhile than WINDOW.

-- 
Cyrus Daboo

Date: Wed, 27 Jun 2001 15:10:52 -0400
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: draft-ietf-imapext-window-00.txt
Sender: [email-masked]

--On Tuesday, June 26, 2001 4:08 PM -0400 Ken Murchison <[email-masked]> 
wrote:

> Any thoughts on output filtering for THREAD?  For instance "show me only
> those threads containing unseen messages".  IIRC, Mark seemed to think
> that this might be a good fit for WINDOW/VIEW instead of making it a
> separate THREAD algorithm.

Right now WINDOW doesn't do any 'filtering' of the output results from the 
sub-command its targetting. However, adding a 'select only threads 
containing xxx' option to it would require some kind of additional 
filtering between the thread command results and the output window that the 
client operates on. For that reason I think this would best be left to the 
THREAD command - i.e. a new REFERENCES-UNSEEN thread algorithm.

I guess I should add and define the term 'output filtering' in the draft to 
explain how this differs from 'output windowing' (which is only what WINDOW 
does). I guess there is also the concept of 'input filtering' which should 
be described too.

-- 
Cyrus Daboo

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-window-00.txt
Date: Wed, 27 Jun 2001 07:03:06 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP WINDOW Extension
	Author(s)	: C. Daboo, C. Newman
	Filename	: draft-ietf-imapext-window-00.txt
	Pages		: 13
	Date		: 26-Jun-01
	
The WINDOW extension to the Internet Message Access Protocol [IMAP4]
permits windowing of the results of specific IMAP commands, so that
clients can retrieve the results in ranges to implement paging of
results or virtual scrollbars.  This eliminates the need to get and
manage the entire result set, improving scalability for large
mailboxes and slow connections.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-window-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-window-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-window-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-window-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-window-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 26 Jun 2001 16:08:46 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: draft-ietf-imapext-window-00.txt
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> I just sent the attached draft off to the draft repository.
> 
> This draft describes a proposed WINDOW extension that is designed as a
> simplified alternative to the VIEW extension (as discussed informally at
> the last IETF meeting). Its goal is to allow clients to 'window' (get a
> subset) of the results of SEARCH and SORT commands.
> 
> It does not address WINDOWing of THREAD. We felt that trying to design a
> windowing mechanism to cope with the hierarchical nature of THREAD would
> lead to a much more complex document, and that in general the complexity of
> windowing thread would likely be more costly than just getting the entire
> results set without it.

Any thoughts on output filtering for THREAD?  For instance "show me only
those threads containing unseen messages".  IIRC, Mark seemed to think
that this might be a good fit for WINDOW/VIEW instead of making it a
separate THREAD algorithm.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 25 Jun 2001 19:51:16 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: draft-ietf-imapext-window-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 25 Jun 2001, Cyrus Daboo wrote:
> This draft describes a proposed WINDOW extension that is designed as a
> simplified alternative to the VIEW extension (as discussed informally at
> the last IETF meeting). Its goal is to allow clients to 'window' (get a
> subset) of the results of SEARCH and SORT commands.

I have skimmed the WINDOW extension proposal.  Although I have not
reviewed it in detail, it looks like something that I can support.

I am not sure that I understand why this framework is superior to a static
version of VIEW.  However, if it addresses Chris' requirements and doesn't
have any hidden negative impact on my requirements for SORT/THREAD, then
it's a good thing and we should move forward on it.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Date: Mon, 25 Jun 2001 20:11:56 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: draft-ietf-imapext-window-00.txt
Sender: [email-masked]

--==========00413164==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I just sent the attached draft off to the draft repository.

This draft describes a proposed WINDOW extension that is designed as a 
simplified alternative to the VIEW extension (as discussed informally at 
the last IETF meeting). Its goal is to allow clients to 'window' (get a 
subset) of the results of SEARCH and SORT commands.

It does not address WINDOWing of THREAD. We felt that trying to design a 
windowing mechanism to cope with the hierarchical nature of THREAD would 
lead to a much more complex document, and that in general the complexity of 
windowing thread would likely be more costly than just getting the entire 
results set without it.

-- 
Cyrus Daboo
--==========00413164==========
Content-Type: text/plain; charset=iso-8859-1;
 name="draft-ietf-imapext-window-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-ietf-imapext-window-00.txt";
 size=28230

IMAP Extensions Working Group                                 C. Daboo
Internet Draft: IMAP WINDOW Extension                        C. Newman
Document: draft-ietf-imapext-window-00.txt                   June 2001

                         IMAP WINDOW Extension
   =20
Status of this Memo
   =20
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.  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.
   =20
    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."
   =20
    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.
   =20
   =20
Copyright Notice
   =20
    Copyright (C) The Internet Society (2001). All Rights Reserved.

Daboo, Newman               Expires December 2001               [Page =
1]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

                           Table of Contents
     1  Abstract  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
     2  Conventions Used in This Document  . . . . . . . . . . . . .   2
     3  Introduction and Overview . . . . . . . . . . . . . . . . . .  3
     4  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .   4
     5  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  5
       5.1  Input Window . . . . . . . . . . . . . . . . . . . . . .   5
       5.2  Output Results  . . . . . . . . . . . . . . . . . . . . .  5
       5.3  Output Position  . . . . . . . . . . . . . . . . . . . .   5
       5.4  Output Window . . . . . . . . . . . . . . . . . . . . . .  5
       5.5  Anchor . . . . . . . . . . . . . . . . . . . . . . . . .   5
       5.6  Anchor Offset . . . . . . . . . . . . . . . . . . . . . .  5
     6  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7  Commands  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       7.1  WINDOW Command . . . . . . . . . . . . . . . . . . . . .   6
         7.1.1  WINDOW SET  . . . . . . . . . . . . . . . . . . . . .  6
         7.1.2  WINDOW SHOW  . . . . . . . . . . . . . . . . . . . .   7
         7.1.3  WINDOW UPDATE . . . . . . . . . . . . . . . . . . . .  8
         7.1.4  WINDOW MAP . . . . . . . . . . . . . . . . . . . . .   9
       7.2  UID Command modifications . . . . . . . . . . . . . . . . 10
         7.2.1  UID WINDOW SHOW  . . . . . . . . . . . . . . . . . .  10
         7.2.2  UID WINDOW MAP  . . . . . . . . . . . . . . . . . . . 10
     8  Responses  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       8.1  WINDOW SET Untagged Response  . . . . . . . . . . . . . . 10
       8.2  WINDOW Untagged Response . . . . . . . . . . . . . . . .  10
       8.3  WINDOW MAP Untagged Response  . . . . . . . . . . . . . . 10
     9  Handling message expunges  . . . . . . . . . . . . . . . . .  10
    10  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
    11  Security Considerations  . . . . . . . . . . . . . . . . . .  12
    12  References  . . . . . . . . . . . . . . . . . . . . . . . . . 12
    13  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  12
    14  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . 12
   =20
   =20
1 Abstract
   =20
    The WINDOW extension to the Internet Message Access Protocol [IMAP4]
    permits windowing of the results of specific IMAP commands, so that
    clients can retrieve the results in ranges to implement paging of
    results or virtual scrollbars.  This eliminates the need to get and
    manage the entire result set, improving scalability for large
    mailboxes and slow connections.
   =20
   =20
2 Conventions Used in This Document
   =20
    The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
    NOT", and "MAY" in this document are to be interpreted as described
    in "Key words for use in RFCs to Indicate Requirement Levels"
    [KEYWORDS].
   =20

Daboo, Newman               Expires December 2001               [Page =
2]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    Formal syntax is defined using ABNF [ABNF].
   =20
    In examples, "C:" and "S:" indicate lines sent by the client and
    server respectively.
   =20
   =20
3 Introduction and Overview
   =20
    The WINDOW extension is present in any IMAP4 implementation which
    returns "WINDOW" as one of the supported capabilities in the
    CAPABILITY command.
   =20
    The WINDOW extension specifies one new command (with a number of
    variants) and introduces one new untagged response (with a number of
    variants).
   =20
    The WINDOW command is an optimization for scalability purposes;
    clients can provide the same functionality, albeit more slowly, by
    using existing commands.
   =20
    The SEARCH [IMAP4], SORT [SORT] and THREAD [THREAD] commands in
    IMAP4 return a list of results equal to the size of the input
    window.  The input window is determined by the parameters to each
    command.  For example, the SEARCH command can limit its input window
    by using sequence number or UID number ranges as parameters to the
    SEARCH:
   =20
    Example:    C: A999 SEARCH UNSEEN 10:20
                S: * SEARCH 1 2 4 6
                S: A999 OK SEARCH completed
   =20
    In the above example, an input window of messages with sequence
    numbers in the range 10 through 20 are the only ones considered by
    the SEARCH command.  This limits the output to a maximum of 11 hits.
    The SORT and THREAD commands both take search criteria as
    parameters, and thus can also accomplish input windowing if desired.
   =20
    While input windowing can reduce the number of results returned, it
    does not offer a way to window the results based on their output
    ordering or size.  The design goal of the WINDOW extension is to
    allow clients to do output windowing of the results of SEARCH and
    SORT commands, and to provide an extensible mechanism for future
    IMAP command extensions that return results as a list of sequence
    numbers or UIDs.
   =20
    In order to keep the WINDOW extension simple, the THREAD command is
    not included as one of the commands that WINDOW works with, due to
    the hierarchical nature of the THREAD command results.
   =20
    This extension makes the following changes to the IMAP4 protocol:
   =20

Daboo, Newman               Expires December 2001               [Page =
3]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    (a) Adds a new WINDOW command which takes one of four forms:
      =20
        (i) The first form, WINDOW SET, takes an optional sub-command
        and is used to initiate or cancel the windowing mechanism on the
        server.  When initiating a window, the server creates an output
        results set consisting of all messages returned by the
        sub-command, in their appropriate ordering.  The server returns
        the maximum size of the output results set as well as the
        position of the first unseen message in the output results set.
       =20
        (ii) The second form, WINDOW SHOW, takes parameters that allow
        the client to precisely specify the output window range.  This
        command causes the server to return the message numbers for
        messages in this output window, which is a subset of the entire
        output results set.
       =20
        (iii) The third form, WINDOW UPDATE, causes the server to update
        the output results set to reflect any changes to the state of
        the mailbox since the last WINDOW SET <sub-command> command was
        issued.
       =20
        (iv) The fourth form, WINDOW MAP, the client provides a set of
        ordered message sequence numbers or UIDs and the server returns
        the output positions of those messages in the current output
        results set.  For example, this allows a client to preserve user
        message selections across WINDOW UPDATEs or other mailbox
        changes.
       =20
    (b) Adds a new WINDOW untagged response which takes one of three
        forms:
      =20
        (i) The first form, WINDOW SET, returns the size and position of
        the first unseen message in the output results set.
       =20
        (ii) The second form, WINDOW, returns the output window range.
       =20
        (iii) The third form, WINDOW MAP, returns the mapping results
        from message sequence number or UIDs to output positions in the
        current output results set.
       =20
    (c) Modifies the EXPUNGE untagged response to include the output
        position of the message being expunged, when a WINDOW SET
        operation is in effect.
      =20
   =20
    The rest of this document describes these changes more rigorously.
   =20
   =20
4 Open Issues
   =20
    - Should we have WINDOW FETCH and WINDOW STORE commands to allow
    accessing messages by output position?

Daboo, Newman               Expires December 2001               [Page =
4]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

5 Terminology
   =20
5.1 Input Window
   =20
    The set of messages used as input to a SEARCH or SORT command.  In
    the case of SEARCH this can be controlled via the message number or
    UID range search criteria.  In the case of SORT this is controlled
    by the search criteria used with those commands.
   =20
5.2 Output Results
   =20
    The set of ordered message numbers or UIDs that are the results of a
    SEARCH or SORT command.
   =20
5.3 Output Position
   =20
    The position of a message in the output results, a number from 1 to
    <n> where <n> is the total number of messages in the output results.
   =20
5.4 Output Window
   =20
    A contiguous range of messages in the output results that the client
    wishes to know about.
   =20
5.5 Anchor
   =20
    A specific message that the client wants to appear at a particular
    position in the output window, requiring the server to determine the
    actual output window range to accommodate this requirement.  For
    example, when first opening a mailbox, the client may want to
    position the first unseen message at the top of the list presented
    to the user by scrolling its graphical window to the appropriate
    place.
   =20
5.6 Anchor Offset
   =20
    The position of the anchor message in the output window, relative to
    the start or end of the output window.
   =20
   =20
6 Examples
   =20
    The examples below will all use the following output results set for
    consistency.  There are a total of 20 messages in this set and the
    first unseen message in the set has a sequence number of 14 and
    appears at output position 3.
   =20
    Output results:
   =20
    11 12 14 16 30 22 24 13 15 31 10 44 21 23 42 41 37 27 26 25
          ^
          first unseen message

Daboo, Newman               Expires December 2001               [Page =
5]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    The output results after an update.  There are a total of 14
    messages in this set and the first unseen message in the set has a
    sequence number of 22 and appears at output position 6.
   =20
    Output results after an update:
   =20
    11 12 14 16 30 22 24 13 15 31 10 44 21 23
                   ^
                   first unseen message
   =20
   =20
7 Commands
   =20
7.1 WINDOW Command
   =20
    The WINDOW command is only available when the server is in 'selected
    state' [IMAP4].  Thus a successful SELECT or EXAMINE command MUST
    have been issued before WINDOW can be used.  If a client attempts to
    use WINDOW while the server is not in 'selected state', then the
    server MUST respond with a BAD response.
   =20
    To avoid ambiguities when messages are expunged from the mailbox,
    the server MUST NOT send untagged EXPUNGE responses whilst a WINDOW
    command is in progress,
   =20
    The WINDOW command takes one of four forms.
   =20
7.1.1 WINDOW SET
   =20
    Arguments: OPTIONAL sub-command and associated arguments:
               this draft currently only allows the SEARCH and
               SORT [SORT] commands as the sub-commands.
   =20
    Responses: REQUIRED untagged responses: WINDOW SET
   =20
    Result:    OK - window set completed, now in window state
               NO - window set failure
               BAD - command unknown or arguments invalid
   =20
    The WINDOW SET command is used to define the set of messages that
    form the output results.  This set is determined by the result of
    the sub-command, and is ordered according to the sub-command.  The
    server stores the output results, which are used to return the data
    the client may request using other WINDOW commands.  The server MUST
    return an untagged WINDOW SET response to the WINDOW SET command,
    indicating the total number of messages in the output results, as
    well as the output position number of the first unseen message in
    the output results, or zero if there are no unseen messages in the
    output results.
   =20
    Example:    C: A999 WINDOW SET SEARCH FROM "Smith"
                S: * WINDOW SET 20 3

Daboo, Newman               Expires December 2001               [Page =
6]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

                S: A999 OK WINDOW SET completed
   =20
    In this example an output results set on a SEARCH command is
    created.  The output results have a total of 20 messages in it, and
    the first unseen message is at output position 3 in the output
    results.
   =20
    A WINDOW SET command with no arguments is used to cancel an earlier
    WINDOW SET with a sub-command.  This allows a client to turn off the
    windowing behaviour.
   =20
7.1.2 WINDOW SHOW
   =20
    Arguments: the message number or starting position of the anchor =
message,
               the anchor position within the output window,
               the size of the output window to return.
   =20
    Responses: REQUIRED untagged responses: WINDOW
   =20
    Result:    OK - window show completed
               NO - window show failure
               BAD - command unknown or arguments invalid
   =20
    The WINDOW SHOW command is used by the client to retrieve portions
    of the output results defined by an earlier WINDOW SET command.  If
    the server is in selected state and there was no previous WINDOW SET
    command, or the WINDOW SET command was cancelled, then the server
    MUST respond with a BAD response.
   =20
    The WINDOW SHOW command takes three parameters:
   =20
    a) An identifier indicating the position of the anchor message in
    the output window.  The client can specify the message by either its
    sequence number, uid or position in the output results set.  This is
    done by using a single character before the numeric value to
    indicate what type it is: 'S' for sequence number, 'U' for uid and
    'P' for output position.
   =20
    b) The requested anchor position where the anchor message should
    appear in the output window, relative to either the start or end of
    the output window.  The server MUST return a BAD response if the
    requested anchor position exceeds the size of the output window, as
    specified in the third argument.
   =20
    c) The size of the output window.  If the size provided by the
    client exceeds the size of the output results, the server MUST
    return a BAD response.
   =20
    The server MUST respond with an untagged WINDOW response indicating
    the output position of the first message in the output window range,
    followed by the message numbers of the messages in the range
    requested by the client.  In some cases the anchor may not appear at

Daboo, Newman               Expires December 2001               [Page =
7]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    the relative offset in the output window requested by the client,
    because the offset would result in the output window exceeding the
    range of the output results.
   =20
    Example:    C: A999 WINDOW SHOW P 3 +0 10
                S: * WINDOW 3 14 16 30 22 24 13 15 31 10 44
                S: A999 OK WINDOW SHOW completed
   =20
    In this example the client requests the server to return the message
    sequence numbers for 10 messages, anchored on output position 3 (the
    first unseen message), with the anchor set to appear first in the
    output window.  The server responds with the output position of the
    first message in the output window range, followed by the 10 message
    sequence numbers corresponding to the requested messages - the
    message with sequence number 14 is the anchor and the first unseen
    message in the output results.
   =20
    Example:    C: A999 WINDOW SHOW P 20 -0 10
                S: * WINDOW 11 10 44 21 23 42 41 37 27 26 25
                S: A999 OK WINDOW SHOW completed
   =20
    In this example the client requests the server to return the message
    sequence numbers for the last ten messages in the output results.
    This is accomplished by setting the anchor to the last output
    position, and requesting the anchor to appear last in the output
    window.
   =20
    Example:    C: A999 WINDOW SHOW S 14 +5 10
                S: * WINDOW 1 11 12 14 16 30 22 24 13 15 31
                S: A999 OK WINDOW SHOW completed
   =20
    In this example the client requests an output window centered on the
    message with sequence number 14.  However, that message actually
    appears at output position 3, so the specified anchor position
    cannot be accommodated, so the output window contains the anchor at
    position 3 instead of the requested position 5 from the start.
   =20
7.1.3 WINDOW UPDATE
   =20
    Arguments: None.
   =20
    Responses: REQUIRED untagged responses: WINDOW SET
   =20
    Result:    OK - window update completed
               NO - window update failure
               BAD - command unknown
   =20
    The WINDOW UPDATE command is used to update the output results
    created by a previous WINDOW SET command.  This is needed because
    WINDOW SET's output results are static - i.e. they do not change
    even when the state of messages changes, or new messages are added
    to the mailbox.  In order to account for change to the mailbox, the

Daboo, Newman               Expires December 2001               [Page =
8]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    client must use the WINDOW UPDATE command.  If the server is in
    selected state and there was no previous WINDOW SET command, or the
    WINDOW SET command was cancelled, then the server MUST respond with
    a BAD response.
   =20
    The server MUST return an untagged WINDOW SET response to the WINDOW
    SET command, indicating the total number of messages in the new
    output results, as well as the output position number of the first
    unseen message in the new output results, or zero if there are no
    unseen messages in the new output results.
   =20
    Example:    C: A999 WINDOW UPDATE
                S: * WINDOW SET 14 6
                S: A999 OK WINDOW UPDATE completed
   =20
    In this example the new output results have a total of 14 messages
    in it, and the first unseen message is now at output position 6 in
    the new output results.
   =20
7.1.4 WINDOW MAP
   =20
    Arguments: Message number range.
   =20
    Responses: REQUIRED untagged responses: WINDOW MAP
   =20
    Result:    OK - window map completed
               NO - window  map failure
               BAD - command unknown
   =20
    The WINDOW MAP command allows a client to determine the output
    positions of messages based on their sequence number or uid (if the
    UID command modifier is also used).  This is required to help
    preserve a user's message selection state before and after a WINDOW
    UPDATE command is used.
   =20
    If the server is in selected state and there was no previous WINDOW
    SET command, or the WINDOW SET command was cancelled, then the
    server MUST respond with a BAD response.
   =20
    The server MUST return an untagged WINDOW MAP response to the WINDOW
    MAP command, indicating the new output positions of the requested
    messages, corresponding to the range used as the argument to the
    command.  The server MUST return an output position number of zero
    for any messages that are no longer in the output results.
   =20
    If the message number argument specifies one or more messages that
    are not in the output results set, the server MUST respond with a
    BAD response.
   =20
    Example:    C: A999 WINDOW MAP 5,14:16,22,24
                S: * WINDOW MAP 0 3 9 4 5 6
                S: A999 OK WINDOW MAP completed

Daboo, Newman               Expires December 2001               [Page =
9]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    In this example the client requests the output positions of messages
    with sequence numbers 5, 14, 15, 16, 22 and 24.  Message 5 is not in
    the output results set, so its output position number is zero.
   =20
7.2 UID Command modifications
   =20
    The IMAP UID command is used to modify the meaning of another
    command and/or the untagged results of a command.  The WINDOW
    extensions extends the UID command to accept certain WINDOW commands
    as outlined below.
   =20
7.2.1 UID WINDOW SHOW
   =20
    The UID WINDOW SHOW causes the untagged WINDOW response for the
    WINDOW SHOW command to contain message uids rather than message
    sequence numbers.
   =20
7.2.2 UID WINDOW MAP
   =20
    The UID WINDOW MAP causes the message number range argument to the
    WINDOW MAP command to be interpreted as message uids rather than
    message sequence numbers.
   =20
   =20
8 Responses
   =20
8.1 WINDOW SET Untagged Response
   =20
    The WINDOW SET untagged response is used to inform the client of the
    total number of messages in the output results set and the output
    position of the first unseen message in the output results, or zero
    if no unseen message is present in the output results.  The WINDOW
    SET results can only occur as the result of a WINDOW SET or WINDOW
    UPDATE command.
   =20
8.2 WINDOW Untagged Response
   =20
    The WINDOW untagged response returns the output position of the
    first message in the requested output window, followed by the
    message numbers of the messages in the requested output window.  The
    message numbers may be either sequence numbers or uids depending on
    whether the UID command modifier is used.  The WINDOW response can
    only occur as the result of a WINDOW SHOW command.
   =20
8.3 WINDOW MAP Untagged Response
   =20
    The WINDOW MAP untagged response returns the output positions of
    messages in the output results, ordered according to the ordering of
    message numbers in the WINDOW MAP command.  The WINDOW MAP response
    can only occur as the result of a WINDOW MAP command.
   =20
   =20

Daboo, Newman              Expires December 2001              [Page =
10]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

9 Handling message expunges
   =20
    When a WINDOW SET command is in effect, the server MUST modify any
    untagged EXPUNGE responses it sends to the client to include the
    output position of the message being expunged, or zero if the
    message being expunged is not in the output results.  After each
    EXPUNGE response the output positions for the current WINDOW SET
    must be readjusted to account for the expunged message.  When an
    untagged EXPUNGE response with a non-zero output position is seen by
    the client, the client MUST adjust its output window and output
    results state to take account of the expunged message.
   =20
    Example:    C: A999 NOOP
                S: * 1 EXPUNGE 0
                S: * 10 EXPUNGE 1
                S: * 10 EXPUNGE 1
                S: A999 OK
   =20
    In this example three messages are expunged from the mailbox.
    Message number 1 is not part of the previously determined output
    results so its output position is shown as zero.  Message number 11
    was at output position 1, and message number 12 was at output
    position number 1 after message number 11 was expunged.
   =20
   =20
10 Formal Syntax
   =20
    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) notation as specified in [ABNF].
   =20
    Non-terminals referenced but not defined below are as defined by
    [IMAP4].
   =20
    Except as noted otherwise, all alphabetic characters are case-
    insensitive.  The use of upper or lower case characters to define
    token strings is for editorial clarity only.  Implementations MUST
    accept these strings in a case-insensitive fashion.
   =20
    window-set-cmd     =3D "WINDOW SET" SP window-set-arg
   =20
    window-set-arg     =3D search / sort / OTHER
                           ; search is defined in [IMAP4]
                           ; sort is defined in [SORT]
                           ; OTHER reserved for future definition
   =20
    window-update-cmd  =3D "WINDOW UPDATE"
   =20
    window-set-resp    =3D "*" SP "WINDOW SET" SP number SP number
   =20
    window-show-cmd    =3D "WINDOW SHOW" SP anchor-pos
                         SP anchor-rel SP nz-number
   =20

Daboo, Newman              Expires December 2001              [Page =
11]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

    anchor-pos        =3D ("S" / "U" / "P") SP nz-number
                           ; "S" indicates sequence number
                           ; "U" indicates uid
                           ; "P" indicates output position
   =20
    anchor_rel        =3D ("+" / "-") number
                           ; "+" indicates offset from start
                           ; "-" indicates offset from end
   =20
    window-resp       =3D "*" SP "WINDOW" SP nz-number *(SP nz-number)
   =20
    window-map-cmd    =3D "WINDOW MAP" SP set
   =20
    window-map-resp   =3D "*" SP "WINDOW MAP" SP number *(SP number)
   =20
    message-data      /=3D nz-number SP "EXPUNGE" SP number
                           ; modifies [IMAP4] EXPUNGE response
                           ; to return output position when
                           ; WINDOW SET is in effect
   =20
   =20
11 Security Considerations
   =20
    There are no known security issues with this extension.
   =20
   =20
12 References
   =20
    [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
    ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
    November 1997.
   =20
    [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
    Requirement Levels", RFC 2119, Harvard University, March 1997.
   =20
    [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
    4rev1", RFC 2060, University of Washington, December 1996.
   =20
    [SORT] Crispin, M., "Internet Message Access Protocol - SORT
    Extension", draft-ietf-imapext-sort-03.txt (Work in progress)
   =20
    [THREAD] Crispin, M., "Internet Message Access Protocol - THREAD
    Extension", draft-crispin-imapext-thread-01.txt (Work in progress)
   =20
   =20
13 Acknowledgments
   =20
    This work is the result of many discussions within the imap-ext
    working group, and is based on the original VIEW draft.
   =20
   =20

Daboo, Newman              Expires December 2001              [Page =
12]=0CInternet Draft              IMAP WINDOW Extension              June =
2001

14 Authors' Addresses
   =20
    Cyrus Daboo
    Cyrusoft International, Inc.
    Suite 780, 5001 Baum Blvd.
    Pittsburgh, PA 15213 USA

    Email: [email-masked]
   =20
   =20
    Chris Newman
    Sun Microsystems
    1050 Lakes Drive
    West Covina, CA 91790 USA

    Email: [email-masked]

Daboo, Newman              Expires December 2001              [Page 13]
--==========00413164==========--

Date: Wed, 13 Jun 2001 20:44:43 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, Ken Murchison <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-imapext-thread
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 13 Jun 2001, Cyrus Daboo wrote:
> There are two types of 'windowing' mode: input windowing and output
> windowing.

To expand on Cyrus' excellent summary, you need both types of windowing.
There are numerous cases where you do not want to sort or thread all
messages.

SORT and THREAD do input windowing because it is easy and obvious how to
do it, and because it follows the theme of SORT/THREAD being merely
expanded forms of SEARCH (or SEARCH the most degenerate form of
SORT/THREAD).

Right now, output windowing is done by the application.  I have stood firm
on NOT putting output windowing into SORT/THREAD, because I believe that
server-based output windowing will probably need to go through multiple
generations of evolution before it can replace application-based output
windowing.  If server-based output windowing is done by a VIEW or WINDOW
command, then it can evolve without forcing new generations of
SORT/THREAD.  Breaking up the problem into smaller pieces is a Good Thing.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

Date: Wed, 13 Jun 2001 18:26:08 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Ken Murchison <[email-masked]>, Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-imapext-thread
Sender: [email-masked]

Cyrus Daboo <[email-masked]>
> --On Wednesday, June 13, 2001 03:50:07 PM +0200 Arnt Gulbrandsen 
> <[email-masked]> wrote:
> 
> >> It can't because the unseen search takes place BEFORE the threading.
> >
> > The answer sounds like putting the cart before the horse... _why_ does
> > the search take place before threading?
> 
> You need to think about this as two different actions (I've actually 
> written some of this up in the ficticious WINDOW draft which I hope to get 
> out soon):

I've been looking forward to reading that, actually.

> There are two types of 'windowing' mode: input windowing and output 
> windowing.
...

I can understand that. However, I get the impression that input windowing
in the case of THREAD isn't considered very useful. Is that right?

With output windowing, THREAD would be a sort of "SEARCH, and give me
context for the results, and give me the results in the right order"
command.  What does the input windowing do for the command?

> THREAD is also complicated to do output windowing on because of the nature 
> of the hierarchical data it outputs.

Yes. But a bit of graph colouring doesn't sound scary, compared to the
Zawinski algorithm THREAD describes.

--Arnt

Date: Wed, 13 Jun 2001 10:48:47 -0400
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, Ken Murchison <[email-masked]>
cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-imapext-thread
Sender: [email-masked]

--On Wednesday, June 13, 2001 03:50:07 PM +0200 Arnt Gulbrandsen 
<[email-masked]> wrote:

>> It can't because the unseen search takes place BEFORE the threading.
>
> The answer sounds like putting the cart before the horse... _why_ does
> the search take place before threading?

You need to think about this as two different actions (I've actually 
written some of this up in the ficticious WINDOW draft which I hope to get 
out soon):

There are two types of 'windowing' mode: input windowing and output 
windowing.

Input windowing restricts the set of messages that a command acts upon. In 
the case of the SORT and THREAD commands, this is controlled via the search 
parameters that they take. In the case of the SEARCH command, input 
windoing can be accomplished by using sequence/uid ranges in the search 
criteria. Other commands that accept sequence/uid ranges effectively do 
input windowing too (e.g. FETCH). Also, the LIST command provides a way to 
do input windowing by using * or % wildcards to match ranges of mailbox 
names.

Output windowing means taking the results of a command and 
sub-setting/filtering those in some way. Neither SORT nor THREAD do this - 
you get the full range of inputs in the output. This is different than 
input windowing because it is applied after the command has run and acts on 
the results (and the order of the results in the case of SORT and THREAD). 
The LIST command too could benefit from output windowing that would lket 
clients get ranges of matching mailboxes rather than the whole lot.

SEARCH is somewhat of a special case as input and output windowing are 
effectively the same.

THREAD is also complicated to do output windowing on because of the nature 
of the hierarchical data it outputs.

-- 
Cyrus Daboo

Date: Wed, 13 Jun 2001 15:50:07 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-imapext-thread
Sender: [email-masked]

Ken Murchison <[email-masked]>
> It can't because the unseen search takes place BEFORE the threading.

The answer sounds like putting the cart before the horse... _why_ does
the search take place before threading?

--Arnt

Date: Wed, 13 Jun 2001 09:30:30 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Arnt Gulbrandsen <[email-masked]>
CC: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-imapext-thread
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> 
> Ken Murchison <[email-masked]>
> > Arnt Gulbrandsen wrote:
> > > Actually, subsetting would help with the cases I'm most interested in,
> > > particularly if the server is permitted to also return answers outside the
> > > requested set:  "Show me all the threads where there's new mail", "show me
> > > all the messages from [email-masked], and the threads to which those
> > > messages belong", "show me all discussion in our department-wide archive
> > > where the subject included 'fumble'" and so on.
> >
> > If I understand what you are looking for here, you want to filter the
> > messages AFTER they have been threaded.
> 
> Yes; that's one way of looking at it.
> 
> > Mark and I have discussed this
> > in the past, and other algorithms which are derivatives of REFERENCES
> > are possible.  For instance, a REFERENCES.UNSEEN algorithm would return
> > only those threads which contain at least one \Unseen message (similar
> > to Netscape's "Threads with Unread").
> 
> But isn't that really duplicating the fourth argument in the second?
> You're suggesting that
> 
>         thread references.unseen utf-8 unseen

This would return the same results as the one below because you've
thrown away the messages which have been read before you start
threading.  You'd want to do

	thread references.unseen utf-8 all

which first will thread ALL messages, and then only return those threads
containing unread messages.

> should return what I think
> 
>         thread references utf-8 unseen
> 
> should.

It can't because the unseen search takes place BEFORE the threading.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Wed, 13 Jun 2001 10:48:24 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Ken Murchison <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-imapext-thread
Sender: [email-masked]

Ken Murchison <[email-masked]>
> Arnt Gulbrandsen wrote:
> > Actually, subsetting would help with the cases I'm most interested in,
> > particularly if the server is permitted to also return answers outside the
> > requested set:  "Show me all the threads where there's new mail", "show me
> > all the messages from [email-masked], and the threads to which those
> > messages belong", "show me all discussion in our department-wide archive
> > where the subject included 'fumble'" and so on.
> 
> If I understand what you are looking for here, you want to filter the
> messages AFTER they have been threaded.

Yes; that's one way of looking at it.

> Mark and I have discussed this
> in the past, and other algorithms which are derivatives of REFERENCES
> are possible.  For instance, a REFERENCES.UNSEEN algorithm would return
> only those threads which contain at least one \Unseen message (similar
> to Netscape's "Threads with Unread").

But isn't that really duplicating the fourth argument in the second?
You're suggesting that

	thread references.unseen utf-8 unseen

should return what I think

	thread references utf-8 unseen

should.

> To do something like your last two examples, we would have to come up
> with a way, either with the (upcoming?) VIEW/WINDOW extension or an
> extension to THREAD, to provide generic post-thread filtering.

If the server's permitted to return MSNs/UIDs for an entire thread when at
least one message in the thread matches the search criteria for that
thread command, that should do it.

--Arnt

Date: Tue, 12 Jun 2001 22:21:21 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Arnt Gulbrandsen <[email-masked]>
CC: Mark Crispin <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-imapext-thread
Sender: [email-masked]

Sorry about the delayed response.  Just catching up on old mailing list
stuff.

Arnt Gulbrandsen wrote:
> 
> Actually, subsetting would help with the cases I'm most interested in,
> particularly if the server is permitted to also return answers outside the
> requested set:  "Show me all the threads where there's new mail", "show me
> all the messages from [email-masked], and the threads to which those
> messages belong", "show me all discussion in our department-wide archive
> where the subject included 'fumble'" and so on.

If I understand what you are looking for here, you want to filter the
messages AFTER they have been threaded.  Mark and I have discussed this
in the past, and other algorithms which are derivatives of REFERENCES
are possible.  For instance, a REFERENCES.UNSEEN algorithm would return
only those threads which contain at least one \Unseen message (similar
to Netscape's "Threads with Unread").

To do something like your last two examples, we would have to come up
with a way, either with the (upcoming?) VIEW/WINDOW extension or an
extension to THREAD, to provide generic post-thread filtering.

Ken
-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

Date: Mon, 11 Jun 2001 14:18:13 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Progress
Sender: [email-masked]

--On Friday, June 8, 2001 11:01 AM -0500 Pete Resnick 
<[email-masked]> wrote:

> Our progress in this group has been glacial. Can I get a status
> report from document editors about where they think they are? (I know
> where BINARY is, but I want to hear about the rest.) It's time to
> fish or cut bait folks.
>
> After I hear back, I'll summarize and we'll figure out what our next
> step is, including whether to meet in London.

VIEW

Following the discussions at Minneapolis IETF: VIEW in its last published 
form has been discarded as being too complex. Chris proposed a new WINDOW 
extension that does output windowing of SORT/THREAD results without the 
complex dynamic update behaviour of VIEW. He and I were working on a draft 
of this, but its been languishing in a folder on my desktop for a while. I 
will try and get this finished and posted as a draft by the end of the week.

ANNOTATE

The last draft went out before Minneapolis. There haven't been any comments 
on it apart from one suggestion by Alexey. There are a number of 
outstanding issues that are described in the draft. What I will do is put 
together a message with each outstanding issue described to garner feedback.

-- 
Cyrus Daboo

Date: Fri, 8 Jun 2001 11:01:35 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Progress
Sender: [email-masked]

Our progress in this group has been glacial. Can I get a status 
report from document editors about where they think they are? (I know 
where BINARY is, but I want to hear about the rest.) It's time to 
fish or cut bait folks.

After I hear back, I'll summarize and we'll figure out what our next 
step is, including whether to meet in London.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102