Subject: Re: SORT and THREAD documents
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Wed, 18 Aug 1999 22:50:30 -0700 (PDT)

On Wed, 18 Aug 1999, Pete Resnick wrote:
> Damn! I dropped the ball on this one. I was away on vacation when all 
> this went on, and when I came back I didn't get the message off to 
> the I-D editor to put them in the WG namespace. I will do so 
> immediately. Sorry for the inconvenience.

Thanks for the update.  You weren't the only one to have been on vacation.
What I saw on my end, just before I left on vacation, was a response to
the effect that I was not allowed to post ietf-imapext drafts, and that
the SORT and THREAD drafts would have to wait until you approved them or
some timeout expired at which point they'd be posted as a private draft
(which seems to have happened).

I always thought that you used the WG name if an active WG was in progress
on the specification, and used your name only if there wasn't an active
WG.  Did they change the policy as a result of some of the recent
catfights?  If so, perhaps the cure is worse than the disease.  Sigh.

Anyway, would people please look at the SORT and THREAD drafts and see if
they accurately reflect what I described at Oslo.  Also, please start
thinking about how THREAD would work with VIEW, and about additional
standard threading algorithms.  Although I'd like to make
THREAD=ORDEREDSUBJECT mandatory, I think that a standards-track THREAD
needs at least two other algorithms, one to do Message-ID/In-Reply-To and
the other to do Message-ID/References.

I'd also like for someone (other than me!!) who is familiar with the UW
implementation to verify that the THREAD draft accurately describes the UW
implementation of THREAD.  The purpose of the THREAD document is to
document how the UW implementation works (and once confirmed that it does
so propose it as our way of doing threading).  If there is a contradiction
between the document and the UW implementation, the document is the one
that needs to be fixed.

Another point is that there needs to be a second client and server
implementation of THREAD that is shown to interoperate with the UW
implementation.  Before we even think about pushing THREAD further, we
need this.  I suspect that we need to get the additional algorithms
established too, since ORDEREDSUBJECT threading doesn't do nesting and
each message only appears once.  We need threaders that break these
assumptions.

One last thing -- this SORT draft is the *unextended* SORT.  It's to
document today's status quo.  SORT *will* be extended, but not in this
document.  The sooner we get this document to RFC (as either Experimental
or Informational...I'd prefer Informational), the sooner that we can talk
about the extensions to produce a standards-track SORT (and VIEW SET
SORT).

-- Mark --

* RCW 19.190 notice: This email address is located in Washington State.	*
* Unsolicited commercial email may be billed $500 per message.		*
Science does not emerge from voting, party politics, or public debate.

Date: Wed, 18 Aug 1999 23:55:39 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: SORT and THREAD documents
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 8/18/99 at 9:00 PM -0700, Mark Crispin wrote:

>Apparently, these got delayed because they somehow think that these
>documents are not part of the IMAPEXT working group, so the Powers That Be
>objected to them being submitted as draft-ietf-imapext-...
>
>Damned if I know why the WG chair didn't educate them to the contrary.  We
>did talk about both of these at some length in Oslo.

Damn! I dropped the ball on this one. I was away on vacation when all 
this went on, and when I came back I didn't get the message off to 
the I-D editor to put them in the WG namespace. I will do so 
immediately. Sorry for the inconvenience.

Pete: 1 demerit.
Mark: 1 gold star for getting the docs in so quickly.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Wed, 18 Aug 1999 21:00:32 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: SORT and THREAD documents
Organization: Networks & Distributed Computing
Sender: [email-masked]

Apparently, these got delayed because they somehow think that these
documents are not part of the IMAPEXT working group, so the Powers That Be
objected to them being submitted as draft-ietf-imapext-...

Damned if I know why the WG chair didn't educate them to the contrary.  We
did talk about both of these at some length in Oslo.

-- Mark --

* RCW 19.190 notice: This email address is located in Washington State.	*
* Unsolicited commercial email may be billed $500 per message.		*
Science does not emerge from voting, party politics, or public debate.

---------- Forwarded message ----------
Date: Thu, 12 Aug 1999 07:06:44 -0400
From: [email-masked]
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-crispin-imapext-sort-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION
	Author(s)	: M. Crispin
	Filename	: draft-crispin-imapext-sort-00.txt
	Pages		: 8
	Date		: 11-Aug-99
	
This document describes an experimental server-based sorting
extension to the IMAP4rev1 protocol, as implemented by the University
of Washington's IMAP toolkit.  This extension provides substantial
performance improvements for IMAP clients which offer sorted views.
A server which supports this extension indicates this with a
capability name of 'SORT'.  Client implementations SHOULD accept any
capability name which begins with 'SORT' as indicating support for
the extension described in this document.  This provides for future
upwards-compatible extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crispin-imapext-sort-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-crispin-imapext-sort-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-crispin-imapext-sort-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.

---------- Forwarded message ----------
Date: Thu, 12 Aug 1999 07:06:50 -0400
From: [email-masked]
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-crispin-imapext-thread-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
	Author(s)	: M. Crispin
	Filename	: draft-crispin-imapext-thread-00.txt
	Pages		: 7
	Date		: 11-Aug-99
	
This document describes the server-based threading extension to the
IMAP4rev1 protocol.  This extension provides substantial performance
improvements for IMAP clients which offer threaded views.
A server which supports this extension indicates this with more or
more capability names consisting of 'THREAD-' followed by a supported
threading algorithm name as described in this document.  This
provides for future upwards-compatible extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crispin-imapext-thread-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-crispin-imapext-thread-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-crispin-imapext-thread-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.

Date: Thu, 12 Aug 1999 10:34:55 -0700
From: Chris Newman <[email-masked]>
Subject: RE: transcoding service (was Re: Oslo WG meeting notes)
Originator-info: login-id=chris; server=thor.innosoft.com
To: "Neystadt, John" <[email-masked]>
Cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

The two obvious choices are:

(1) at final delivery time, perform the transcoding (since a user isn't
waiting) and transform that part into a multipart/alternative.  Good IMAP
clients will only download the part they can use.

(2) use the "EXPORT" facility only when transcoding is needed; the user
will just have to wait if the transcoding CPUs are busy.

		- Chris

--On Thu, Aug 12, 1999 8:51 +0300 "Neystadt, John"
<[email-masked]> wrote:

> Chris, how would you solve the following scenario:
> 
> 1. You have a voice mail system with proprietry transcoding.
> 2. Transcoding is a versy expensive (CPU) action.
> 2. There are some smart clients that are able to process messages of
> proprietry transcoding.
> 3. All other clients should get the messages transcoded to a standard one.
> For backward compatibility you can't require them to specify transcoding,
> sine today's Netscape or Outlook don't do it.

Date: Thu, 12 Aug 1999 09:20:33 +0100
From: John Haxby <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Annotations: alternate data model
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------1EAC61DE18969975CE948B2B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

>
> I have to say that "use XML instead" is the correct response to anyone who
> is trying to use ASN.1.  XML is and order of magnitude simpler than ASN.1,
> plus it's trendier and has more tools (the latter two being the only
> important issues to someone considering ASN.1).
>

I'd stick to the "trendier" bit ... :-)

>
> However, within the IMAP protocol, I prefer that we stick to the data
> encoding scheme described in section 4 of RFC 2060.  It's at least an
> order of magnitude simpler than XML and all IMAP servers and clients
> already implement it.

That's all well and good, but you then need a means of describing what goes
in the parenthesised lists and how new annotations can be added and handled
by clients.  Where XML wins here is that the syntax deals with handling the
unknown almost automatically.  For example, the DTD could say that an
annotation looks like

    <annotation name="xyzzy">
        ... anything you like here so long as it's valid XML ...
    </annotation>

The definition of the "xyzzy" annotation could then extend the DTD to
encompass its own stuff.

One could do this for IMAP's parenthesised lists, but first of all you'd have
to agree a common framework into which the annotations could be dropped, and
then you'd have to agree a common structure to which all annotation types
must adhere (so that they can at least be read, if not understood), and then
.... Well, there's still the problem of those clients and servers that
*still* (after all this time) make a dog's dinner of handling literal
strings.

jch

--------------1EAC61DE18969975CE948B2B
Content-Type: text/x-vcard; charset=us-ascii;
 name="jch.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Haxby
Content-Disposition: attachment;
 filename="jch.vcf"

begin:vcard 
n:Haxby;John
tel;work:+44 1344 763711
x-mozilla-html:FALSE
url:http://www.hp.com/go/OpenMail
org:Hewlett Packard;OpenMail R&D<img src="http://www.ice.hp.com/cyc/om/50/graphics/omlinux.jpg" width=53 height=62 align=top>
adr:;;Nine Mile Ride;Wokingham;Berks;RG40 3LL;England
version:2.1
email;internet:[email-masked]
x-mozilla-cpt:;14976
fn:John Haxby
end:vcard

--------------1EAC61DE18969975CE948B2B--

From: "Neystadt, John" <[email-masked]>
To: "'Chris Newman'" <[email-masked]>
Cc: IMAP Extensions Working Group <[email-masked]>
Subject: RE: transcoding service (was Re: Oslo WG meeting notes)
Date: Thu, 12 Aug 1999 08:51:15 +0300
Sender: [email-masked]

Chris, how would you solve the following scenario:

1. You have a voice mail system with proprietry transcoding.
2. Transcoding is a versy expensive (CPU) action.
2. There are some smart clients that are able to process messages of
proprietry transcoding.
3. All other clients should get the messages transcoded to a standard one.
For backward compatibility you can't require them to specify transcoding,
sine today's Netscape or Outlook don't do it.

John Neystadt
[email-masked]
http://www.neystadt.org/john/

> -----Original Message-----
> From: Chris Newman [mailto:[email-masked]]
> Sent: Thursday, August 12, 1999 3:36 AM
> To: Barry Leiba
> Cc: IMAP Extensions Working Group
> Subject: transcoding service (was Re: Oslo WG meeting notes)
> 
> 
> On Fri, 23 Jul 1999, Barry Leiba wrote:
> > > > > *** Transcoding Request
> > > > > - assertion that there are substantial interoperability issues
> > > > > - better dealt with by picking standardized 
> represention of content-type
> > > 
> > > The concensus was that expecting servers to implement elaborate
> > > transcoding facilities, it would be much better if the 
> VPIM folks could
> > > settle on a reasonable small set of mandatory or 
> recommended to implement.
> > 
> > ...
> > 
> > I think it's useful to have such capability, and I think 
> it's worth discussing
> > how we might do it in an interoperable way.  The tough bits 
> will be defining
> > the various transcodings that can be done, how to list 
> them, how to specify
> > them, how to add more, and so on.  The basic mechanism 
> shouldn't be terribly
> > controversial.
> 
> Actually, I'm 100% opposed to including any transcoding 
> services (beyond
> removal of standard content-transfer-encodings) in IMAP itself.
> Transcoding is a general facility which could be applied to 
> data coming
> from a mail store, web server, ftp site or any other source.  
> Functional
> modularity suggests that IMAP has no business performing such 
> a general
> purpose service.
> 
> Given that, here's how I'd address the transcoding problem 
> with respect to
> IMAP.  The same approach could apply to the recurring issue 
> of forwarding
> a message via an SMTP SUBMIT server without downloading it to 
> a client. 
> 
> Add a simple extension to the IMAP server which allows a MIME 
> entity (or
> message) to be accessed by an external service.  This extension would
> return a URL to that MIME entity. 
> 
> Here's a very rough strawman:
> 
> tag EXPORT <service> <uid> "["[body-part-number]"]" <expires>
> * EXPORT <service> <uid> [body-part-number]
>   
> "imap://<service>@<imap-server>/Joe/;uid=10/;section=[body-par
> t-number]"
> 
> Then the client can simply pass that URL to the transcoding 
> service (or
> SMTP SUBMIT server) which can then log in to the IMAP server 
> and access
> the body part(s).  There a number of subtleties, especially related to
> security and persistance, but I think the general idea is workable. 
> 
> If all the details are nailed down correctly, then the 
> transcoding server
> could come from a different vendor than the IMAP server and 
> it would all
> interoperate.  Given that transcoding expertise and IMAP 
> server expertise
> are *very* different I think that's exactly as it should be.  If
> efficiency is an issue, just co-locate the transcoding server with the
> IMAP server and document an efficient "IMAP export" API. 
> 
> 		- Chris
> 

Date: Wed, 11 Aug 1999 17:36:02 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: transcoding service (was Re: Oslo WG meeting notes)
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Barry Leiba <[email-masked]>
Cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Fri, 23 Jul 1999, Barry Leiba wrote:
> > > > *** Transcoding Request
> > > > - assertion that there are substantial interoperability issues
> > > > - better dealt with by picking standardized represention of content-type
> > 
> > The concensus was that expecting servers to implement elaborate
> > transcoding facilities, it would be much better if the VPIM folks could
> > settle on a reasonable small set of mandatory or recommended to implement.
> 
> ...
> 
> I think it's useful to have such capability, and I think it's worth discussing
> how we might do it in an interoperable way.  The tough bits will be defining
> the various transcodings that can be done, how to list them, how to specify
> them, how to add more, and so on.  The basic mechanism shouldn't be terribly
> controversial.

Actually, I'm 100% opposed to including any transcoding services (beyond
removal of standard content-transfer-encodings) in IMAP itself.
Transcoding is a general facility which could be applied to data coming
from a mail store, web server, ftp site or any other source.  Functional
modularity suggests that IMAP has no business performing such a general
purpose service.

Given that, here's how I'd address the transcoding problem with respect to
IMAP.  The same approach could apply to the recurring issue of forwarding
a message via an SMTP SUBMIT server without downloading it to a client. 

Add a simple extension to the IMAP server which allows a MIME entity (or
message) to be accessed by an external service.  This extension would
return a URL to that MIME entity. 

Here's a very rough strawman:

tag EXPORT <service> <uid> "["[body-part-number]"]" <expires>
* EXPORT <service> <uid> [body-part-number]
  "imap://<service>@<imap-server>/Joe/;uid=10/;section=[body-part-number]"

Then the client can simply pass that URL to the transcoding service (or
SMTP SUBMIT server) which can then log in to the IMAP server and access
the body part(s).  There a number of subtleties, especially related to
security and persistance, but I think the general idea is workable. 

If all the details are nailed down correctly, then the transcoding server
could come from a different vendor than the IMAP server and it would all
interoperate.  Given that transcoding expertise and IMAP server expertise
are *very* different I think that's exactly as it should be.  If
efficiency is an issue, just co-locate the transcoding server with the
IMAP server and document an efficient "IMAP export" API. 

		- Chris

Date: Wed, 11 Aug 1999 17:04:42 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Annotations: alternate data model
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: IMAP Extensions Working Group <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Wed, 28 Jul 1999, John Haxby wrote:
> > I've been using XML in some projects here and like a lot of its
> > features. We did have to do something about representing binary values
> > within XML, but otherwise are fairly pleased with XML as a data
> > representation language.
> 
> I have to agree here.
> 
> It's certainly a lot easier to get to grips with than ASN.1!

I have to say that "use XML instead" is the correct response to anyone who
is trying to use ASN.1.  XML is and order of magnitude simpler than ASN.1,
plus it's trendier and has more tools (the latter two being the only
important issues to someone considering ASN.1).

However, within the IMAP protocol, I prefer that we stick to the data
encoding scheme described in section 4 of RFC 2060.  It's at least an
order of magnitude simpler than XML and all IMAP servers and clients
already implement it.

		- Chris

Date: Wed, 11 Aug 1999 05:51:32 +0200 (METDST)
From: Arnaud Taddei <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Chris Newman <[email-masked]>, steve spear <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Just for the anectdote try to oppen a 50,000 mailbox created by a user
mail loop with, say, pine and Netscape or Outlook ...  fortunately we have
the robust, non caching, pine program with the 2 others this is nearly
impossible to even get the cursor back after opening the folder.

On Tue, 10 Aug 1999, Mark Crispin wrote:

> On Tue, 10 Aug 1999, Chris Newman wrote:
> > While I think a full disconnected-model IMAP client makes sense for a
> > user's "primary mail reading machine" (I'm just waiting for a client
> > vendor to implemented background cache updating :-), there is a high
> > demand both for "kiosk" model usage (where a machine doesn't have a
> > primary user) and for "travel" usage (where a user is away from their
> > primary machine, and perhaps using someone else's primary machine).
> 
> Let's put it this way.  I find *all* of the full disconnected-model IMAP
> clients to be intolerable.  The only tolerable clients are those which
> permit turning off the disconnected-model.
> 
> On a fast network, it's a completely unnecessary waste of client disk
> space.  On a slow network, the first open of a 5000 message mailbox is
> ridiculously slow.
> 
> > wireless continues to become more popular, average network bandwidth may
> > *drop* from current levels.
> 
> Speaking as one who uses wireless a *lot*, I'm amazed at how well online
> model Pine performs, and how terribly disconnected model clients perform.
> 
> -- Mark --
> 
> * RCW 19.190 notice: This email address is located in Washington State.	*
> * Unsolicited commercial email may be billed $500 per message.		*
> Science does not emerge from voting, party politics, or public debate.
> 
> 

------------------------------------------------------------
Arnaud Taddei		tel:  +41 22 767 9349
IT Division  31 1-016	fax:  +41 22 767 7155
CERN			mail: [email-masked]
CH-1211 Geneve 23	URL:  http://home.cern.ch/taddei
------------------------------------------------------------

Date: Wed, 11 Aug 1999 05:47:27 +0200 (METDST)
From: Arnaud Taddei <[email-masked]>
To: Terry Gray <[email-masked]>
cc: Chris Newman <[email-masked]>, steve spear <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Some operational feedback, if in addition you add all the _pathological_
cases like:

- the IMAP cache is stored in files *without* locking mechanisms, when
  you start 2 instances of your clients and your home directory is coming
  from a central file server you have very nice corruptions (and it seems
  to be a very difficult message to pass to vendors!!!). It is even worse
  for the addressbook but this is a different _acap_/_ldap_ story.
- corruptions of the local IMAP cache lead to a wide spectra of side
  effects
- problems of synchronisation between the local cache with the
  subscription to folders model when you use other clients
- problems due to the access to the disks of PCs which happens too often
  (we had very interesting surprises when we inspeceted fragmentation
  rate of users PC disks). This _slows_ down programs!
- no button provided to users to force a resynchronisation between what is
  on the server and your cache

So yes please anything which can be done to remove the local IMAP cache
can only help by making sure the solution is to some extend truly location
independent (we have 50,000 physicists travelling with all possible
patterns and demands) and remove a wide range of operational problems.

>From our user support team, the corruption of the local IMAP cache is by
far the first problem they address on a daily basis for the support of
thousands of users and we desigend our own tools and recipes to have quick
ways to help users.

my $0.01

On Tue, 10 Aug 1999, Terry Gray wrote:

> I'll just add that folks who have no "primary" machine, but rather 
> routinely use two or three different computers every day, may prefer
> clients that operate in "kiosk" mode rather than suffer with the startup
> and resynch delays that seem to go with many of today's offline and
> disconnected clients...  (certainly I do! :)
> 
> -teg
> 
> On Tue, 10 Aug 1999, Chris Newman wrote:
> 
> > On Tue, 29 Jun 1999, steve spear wrote:
> > > Can someone explain how traffic is reduced by SORT over clients that are
> > > caching the headers and simply request messages headers they haven't seen
> > > before?
> > 
> > While I think a full disconnected-model IMAP client makes sense for a
> > user's "primary mail reading machine" (I'm just waiting for a client
> > vendor to implemented background cache updating :-), there is a high
> > demand both for "kiosk" model usage (where a machine doesn't have a
> > primary user) and for "travel" usage (where a user is away from their
> > primary machine, and perhaps using someone else's primary machine).  In
> > both cases a proper cache doesn't exist, so the VIEW SORT model allows the
> > client to download just what it needs rather than to populate a cache
> > which it will just have to discard.
> > 
> > One could argue that "web mail" products suffice for kiosk and travelling
> > users, but I'm dubious of their scalability, let alone their usability. 
> 
> (etc)
> 
> 

------------------------------------------------------------
Arnaud Taddei		tel:  +41 22 767 9349
IT Division  31 1-016	fax:  +41 22 767 7155
CERN			mail: [email-masked]
CH-1211 Geneve 23	URL:  http://home.cern.ch/taddei
------------------------------------------------------------

Date: Tue, 10 Aug 1999 20:15:40 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Chris Newman <[email-masked]>
cc: steve spear <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 10 Aug 1999, Chris Newman wrote:
> While I think a full disconnected-model IMAP client makes sense for a
> user's "primary mail reading machine" (I'm just waiting for a client
> vendor to implemented background cache updating :-), there is a high
> demand both for "kiosk" model usage (where a machine doesn't have a
> primary user) and for "travel" usage (where a user is away from their
> primary machine, and perhaps using someone else's primary machine).

Let's put it this way.  I find *all* of the full disconnected-model IMAP
clients to be intolerable.  The only tolerable clients are those which
permit turning off the disconnected-model.

On a fast network, it's a completely unnecessary waste of client disk
space.  On a slow network, the first open of a 5000 message mailbox is
ridiculously slow.

> wireless continues to become more popular, average network bandwidth may
> *drop* from current levels.

Speaking as one who uses wireless a *lot*, I'm amazed at how well online
model Pine performs, and how terribly disconnected model clients perform.

-- Mark --

* RCW 19.190 notice: This email address is located in Washington State.	*
* Unsolicited commercial email may be billed $500 per message.		*
Science does not emerge from voting, party politics, or public debate.

Date: Tue, 10 Aug 1999 19:30:27 -0700 (Pacific Daylight Time)
From: Terry Gray <[email-masked]>
To: Chris Newman <[email-masked]>
cc: steve spear <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Organization: University of Washington;  Computing & Communications
Sender: [email-masked]

I'll just add that folks who have no "primary" machine, but rather 
routinely use two or three different computers every day, may prefer
clients that operate in "kiosk" mode rather than suffer with the startup
and resynch delays that seem to go with many of today's offline and
disconnected clients...  (certainly I do! :)

-teg

On Tue, 10 Aug 1999, Chris Newman wrote:

> On Tue, 29 Jun 1999, steve spear wrote:
> > Can someone explain how traffic is reduced by SORT over clients that are
> > caching the headers and simply request messages headers they haven't seen
> > before?
> 
> While I think a full disconnected-model IMAP client makes sense for a
> user's "primary mail reading machine" (I'm just waiting for a client
> vendor to implemented background cache updating :-), there is a high
> demand both for "kiosk" model usage (where a machine doesn't have a
> primary user) and for "travel" usage (where a user is away from their
> primary machine, and perhaps using someone else's primary machine).  In
> both cases a proper cache doesn't exist, so the VIEW SORT model allows the
> client to download just what it needs rather than to populate a cache
> which it will just have to discard.
> 
> One could argue that "web mail" products suffice for kiosk and travelling
> users, but I'm dubious of their scalability, let alone their usability. 

(etc)

Date: Tue, 10 Aug 1999 16:54:10 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: steve spear <[email-masked]>
Cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Tue, 29 Jun 1999, steve spear wrote:
> Can someone explain how traffic is reduced by SORT over clients that are
> caching the headers and simply request messages headers they haven't seen
> before?

While I think a full disconnected-model IMAP client makes sense for a
user's "primary mail reading machine" (I'm just waiting for a client
vendor to implemented background cache updating :-), there is a high
demand both for "kiosk" model usage (where a machine doesn't have a
primary user) and for "travel" usage (where a user is away from their
primary machine, and perhaps using someone else's primary machine).  In
both cases a proper cache doesn't exist, so the VIEW SORT model allows the
client to download just what it needs rather than to populate a cache
which it will just have to discard.

One could argue that "web mail" products suffice for kiosk and travelling
users, but I'm dubious of their scalability, let alone their usability. 

> As Tony Hansen pointed out - AT&T is trying to handle many millions
> of users.  The thought of using more resources on the server instead of the
> clients that are largely idle is a concern of ours.

I think it's important to note that CPU speed, disk space, RAM, server
performance and client performance all are increasing by Moore's law. 
Network bandwidth and throughput between client&server are not, and if
wireless continues to become more popular, average network bandwidth may
*drop* from current levels.

		- Chris

Date: Tue, 10 Aug 1999 16:30:52 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: [VIEW] Dynamic vs static
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

I'm really torn on the dynamic vs. static issue.

The "static view" model is an order of magnitude easier and more efficient
to implement on the server.  But it clearly doesn't meet the needs of a
client.

The "semi-dynamic view" model is easier for a server to implement (as
flag-change notifications don't have to update the view mapping), and
seems to be closer to what most clients seem to want. But if the
connection is dropped there is no way for the client to reconnect and get
back to the same server state.  That makes the engineer in me cringe, but
I'm not sure it's a show-stopper.

The "fully-dynamic view" model forces a "semi-dynamic" client to keep a
UID-VIEW mapping for messages it's presented to the user.  That mapping
also allows it to gracefully deal with a server disconnect/reconnect
situation.  Furthermore if a client disconnects, reconnects, and re-issues
the SELECT and VIEW SET commands, then the protocol state is the same as
if the client had stayed connected.  That "feels" better.

Unfortunately, I think the bulk of the strong arguments seem to be leaning
in the direction of the "semi-dynamic view" model, and perhaps that is
"good enough" to get deployed and solve the problem.

		- Chris

Date: Tue, 10 Aug 1999 15:43:27 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: [VIEW] Unsolicited response rules
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

Sorry I haven't been involved in this discussion until now and couldn't
make it to Oslo.  FWIW, I support the general VIEW approach and feel a bit
more comfortable with it than with the modified SELECT.

One subtlety which hasn't been addressed carefully is the rules for
unsolicited responses.

The rules for EXPUNGE responses need to be adjusted:

   An EXPUNGE reponse MUST NOT be sent when no command is in progress;
   nor while responding to a FETCH, STORE, SEARCH, VIEW FETCH,
   VIEW STORE or VIEW SEARCH.

I'm wondering whether "VIEW SET" should also be in this list.  If we don't
add the "VIEW SELECT" feature, I'd say it has to be added.  Otherwise I'm
unsure.

The rules for the VIEW responses is that they can not occur during a VIEW
FETCH, VIEW STORE, or VIEW SEARCH.  A VIEW response doesn't have any
negative impact on a regular FETCH/STORE/SEARCH and certainly not on a UID
FETCH/STORE/SEARCH.

		- Chris

Date: Thu, 05 Aug 1999 14:21:29 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Wolfgang Segmuller <[email-masked]>
cc: IMAP Working Group <[email-masked]>
Subject: re: [View] Interactions with select
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Thu, Aug 5, 1999 11:09 AM -0700 Mark Crispin <[email-masked]>
wrote:

>> I think that this should be clearly spelled out in the proposal.  Which
>> way doesn't matter, but I would like to see select cancel a view.
> 
> I agree!

Agreed, a SELECT or EXAMINE will reset any VIEW in effect at the time. I
will ensure this is clearly spelled out in the next revision of the draft.

--
Cyrus

Date: Thu, 5 Aug 1999 11:09:18 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: [View] Interactions with select
To: Wolfgang Segmuller <[email-masked]>
cc: IMAP Working Group <[email-masked]>
Sender: [email-masked]

On Thu, 5 Aug 1999 14:04:18 -0400, Wolfgang Segmuller wrote:

> I think that this should be clearly spelled out in the proposal.  Which way
> doesn't matter, but I would like to see select cancel a view.

I agree!

From: Wolfgang Segmuller <[email-masked]>
Date: Thu, 5 Aug 1999 14:04:18 -0400
To: IMAP Working Group <[email-masked]>
Subject: [View] Interactions with select
Sender: [email-masked]

If a view is active and a select is issued, what is the status of the view.  
Is the last view still in effect.

I think that this should be clearly spelled out in the proposal.  Which way 
doesn't matter, but I would like to see select cancel a view.

Wolfgang

Date: Thu, 05 Aug 1999 09:36:43 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New version of the ID draft
Sender: [email-masked]

Greetings. I just discovered that I had not put the ID draft on the list of 
extensions on the web page at <http://www.imc.org/ietf-imapext/>. Given 
that the -03 version just came out, this is a tad late, but at least I got 
it there now.

If you know of any other drafts that should be listed on that page, please 
let me know.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 05 Aug 1999 10:31:58 -0400
From: Barry Leiba <[email-masked]>
Organization: Internet Messaging Technology; TR2_Xagent=WATSON
To: IMAP Extensions Working Group <[email-masked]>
Subject: Re: [VIEW] Dynamic vs static
Sender: [email-masked]

What I'm saying is basically the same as what Mark is saying... VIEW 
can perfectly well do things that affect how the *client* sees things
without having to affect how the *user* sees things.  In particular...

Cyrus Daboo wrote:
> Right, but from then on the client has to go through a complex procedure
> for figuring out which messages are in its display list and are part of the
> server view and which are not part of the server view. So if a user selects
> all the messages and then does a delete, the client ends up having to issue
> two commands to delete the message: 'VIEW STORE' for messages in the server
> view, and 'UID STORE' for messages outside the server view. 

Yes, but it only has to do that for messages that it's been told have been 
removed from the view.  That's not terrible, and not particularly "complex".
And to my mind it's sensible.  The client needs to be able to deal with these
issues anyway if it wants to seamlessly reconnect after a communication problem.

Simple enough to do: when the server tells you that a message was removed from
the view, you set a flag on that message.  Whenever you need to do anything
with that message, you now use the UID instead of the view position.  What's
the big deal?

> There is another option that I didn't mention in my first port on this, and
> that is the possibility of allowing both dynamic and static views but have
> the client decide when the VIEW is set which it wants.

I could implement this, but I'd rather not; it seems more involved than
necessary.  I'd rather define the view semantics clearly and distinctly.

One disagreement with Mark on this, BTW:
> (3) is a big pain for servers. 
No... (3) is a big pain for *some* servers, and for the UW server in 
particular, perhaps.  As it turns out, all three options are equally easy 
for me to implement in my server; it falls out of the "view" that's already 
designed in.  I suspect that server implementations will vary as to which
ones are easier or harder to do.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Wed, 4 Aug 1999 13:18:36 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: re: [VIEW] Dynamic vs static
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On 8/4/99 at 10:27 AM -0700, Mark Crispin wrote:

>The client programmers also have the task of developing an interface for the
>users that the users can use; the question is then whether or not VIEW assists
>them in this goal and which proposed flavor of VIEW does so the best.
>
>That's quite different from how easy it is for users to use VIEW, or whether
>VIEW does what users want.  I contend that these concerns are irrelevant...

I think Cyrus is just conflating some terms here, but his concerns 
are valid: We need to design the protocol so that the *semantics* of 
what the user wants to do are reflected in the *semantics* of the 
protocol. That's how we get VIEW to "assist" client programmers in 
their goal of implementing what the user wants. If you can't map the 
semantics of the protocol onto the semantics of the user action, then 
either you can't implement the user action, or it has to be done in 
an extra-protocol way (i.e., more work for the implementor, and 
potentially introducing interoperability problems).

Personally, I think because of the above, static VIEW is just a 
non-starter. My guess is that some people will want to implement 
semi-dynamic and some will want to implement fully-dynamic and it 
actually doesn't make much of a difference to client writers which 
one the server implements so long as it can find out which one it is.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

Date: Wed, 4 Aug 1999 10:27:15 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: [VIEW] Dynamic vs static
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Wed, 04 Aug 1999 12:40:18 -0400, Cyrus Daboo wrote:
> Well I would like to throw something else into this equation - namely
> 'users'. Its all well and good to have this functionality available on
> client and server but if its too difficult for the user to use, or doesn't
> do what they really want it to, then its not going to be of much use.

I'd like to move away from this sort of thinking.

VIEW (for that matter, all of IMAP) is not for users to use.  It is for client
programmers.  Users use the client program, *not* a protocol.

The usability questions therefore revolve among the programmers.  The server
programmers must be able to implement it, and the client programmers must be
able to use it.

The client programmers also have the task of developing an interface for the
users that the users can use; the question is then whether or not VIEW assists
them in this goal and which proposed flavor of VIEW does so the best.

That's quite different from how easy it is for users to use VIEW, or whether
VIEW does what users want.  I contend that these concerns are irrelevant, and
have the risk of leading people down the garden path of designing less
predictable "fuzzy" functionality into a protocol.  That, in turn, ultimately
renders the protocol less useful for clients with different designs.

Date: Wed, 04 Aug 1999 12:50:32 -0400
From: Cyrus Daboo <[email-masked]>
To: Barry Leiba <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Subject: Re: [VIEW] Dynamic vs static
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Tuesday, August 03, 1999, 5:05 PM -0400 Barry Leiba
<[email-masked]> wrote:

> No, not at all.  Only the messages it's shown the user.  If the user 
> hasn't seen the message, then the fact that it's disappeared from the
> view is irrelevant.  Once the user has seen the message (it's come up
> in the virtual window), then the client has presumably picked up the 
> ENVELOPE and FLAGS information, for instance (in order to display it 
> in the UI), and, so, can also have picked up the UID at the same time.

Right, but from then on the client has to go through a complex procedure
for figuring out which messages are in its display list and are part of the
server view and which are not part of the server view. So if a user selects
all the messages and then does a delete, the client ends up having to issue
two commands to delete the message: 'VIEW STORE' for messages in the server
view, and 'UID STORE' for messages outside the server view. It has to do
the same sort of thing if the user just wants to search the message within
the client's current view. There's no reason why a client can't do this,
but I don't think we should force this complex behaviour by requiring VIEW
to be fully dynamic, if most clients really want the static form of view.

Remember, its easy for a client to take the static form of VIEW and
effectively emulate a dynamic form by simply issuing a 'VIEW UPDATE'
command everytime there's an unsolicted response from the server that might
result in a change to the view. Its much harder to emulate the static mode
when the server only supports the dynamic mode.

There is another option that I didn't mention in my first port on this, and
that is the possibility of allowing both dynamic and static views but have
the client decide when the VIEW is set which it wants.
--
Cyrus

Date: Wed, 04 Aug 1999 12:40:18 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions Working Group <[email-masked]>
Subject: re: [VIEW] Dynamic vs static
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Tuesday, August 03, 1999, 4:45 PM -0700 Mark Crispin
<[email-masked]> wrote:

> One way of looking at this is that "what IMAP does is not necessarily
> what the client will show".  We should focus on what is best for client
> implementations (because clients are what will benefit from it) and what
> is feasible for server implementations (because if it isn't feasible then
> servers won't implement it).

Well I would like to throw something else into this equation - namely
'users'. Its all well and good to have this functionality available on
client and server but if its too difficult for the user to use, or doesn't
do what they really want it to, then its not going to be of much use.

Its already the case that a number of client vendors have a VIEW type
mechanism built into their clients, using client-based searching etc to
determine the view. I know from our own experience (about a year's worth)
that users want to have any new messages that arrive with matching view
criteria immediately displayed to them. In other words new message arrival
MUST result in dynamic VIEW responses.

Also, having looked back at user discussions, its clear that they do NOT
want a fully dynamic view at least in the sense that messages dissappear
from the view if they no longer match because of a flag change.

In other words option (2) as described in Mark's original post matches
(our) users' expectations of how view should work.

I think we should hear from otehr client vendors with a similar client-side
mechanism to see what their usability studies suggest in this area.

--
Cyrus

Date: Tue, 3 Aug 1999 17:14:29 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: [VIEW] Multiple views
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Tue, 03 Aug 1999 11:07:06 -0400, Cyrus Daboo wrote:
> I think it was clear that most server vendors felt this was adding too much
> complexity to VIEW from the outset and would provide too much of a hurdle
> for the adoption of the VIEW extension. Is this really how people feel
> about this now?

If the VIEW extension ends up requiring support for multiple views, I probably
won't implement it.

> One solution is to design VIEW now as a single VIEW mechanism but to allow
> a VIEW2 extension to extend it for multiple views once VIEW has proven
> itself to be useful and is widely adopted. If we were to do this it might
> be sensible to take this into account when designing VIEW.

I agree that VIEW should claim to be a proper subset of all IMAP capabilities
with begin with "VIEW", so as to provide extensibility.

> What I think we
> could do is make the definition of the view position more than just the
> hierarchical number currently proposed in the extension. If instead we
> allowed it to be single or multi-valued then we could add multiple view
> very easily in the future.

Ugh!  Think about what would happen if people want multiple *nested* views.
Please, let's not go here.

>         S: * 173 VIEW 5274234 (1.14 2.3)
>         A new message arrived and appeared at position 14 in view 1
>         and at position 3 in view 2.
> Note also that in the case of view operating with the THREAD extension, its
> clear that messages can appear in multiple positions in the SAME view. Thus
> defining the view position to be single or multi-valued also makes dealing
> with THREAD easier.

I don't understand this.  The view position has to be multi-valued, meaning
that the message appears in multiple places in the view.  If you really wanted
multiple view syntax, you would need something like:
	S: * 173 VIEW 5274234 (1.14) (2.3)

Date: Tue, 3 Aug 1999 16:45:41 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: [VIEW] Dynamic vs static
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

One way of looking at this is that "what IMAP does is not necessarily what the
client will show".  We should focus on what is best for client implementations
(because clients are what will benefit from it) and what is feasible for
server implementations (because if it isn't feasible then servers won't
implement it).

I think that I reject any idea to be "smart", e.g. making a special exception
for the \Seen or \Recent flags for "new" messages.

I think that our choices are:

1) fully-static.  Once a view is set, it's immutable.  I guess that this means
   that if a message in the view is expunged, the view gets a hole.

2) semi-static.  Once a message is entered into the view, it stays there even
   if its state changes in a way that would cause it to leave the view.
   However, expunged messages are removed from the view (so you can do math on
   view ids the way you can on sequences), and new messages are incorporated
   into the view as appropriate.

3) dynamic.  Messages are added to the view via new messages or if the state
   of a non-viewed message changes.  Messages are removed from the view via
   expunge or if the state of a viewed message changes.

I think that (1) is probably a non-starter for client implementors.  It would
be the easiest to implement for server implementors, since it doesn't require
us to remember the VIEW SET (as opposed to the map created by it).  The
problem with VIEW UPDATE is that it combines the worst of both worlds -- it
requires the client to issue a command to fix the view, and it requires the
server to remember the VIEW SET.  Let's reject VIEW UPDATE for (1), say "with
(1), the client must issue a new VIEW SET to update the view."

(2) is probably what most people want and what server guys will acceed to.
It's a pain for servers to have to remember the VIEW SET, but not as bad as
(3).  If clients really want messages to disappear from the view due to state
changes, they can issue a new VIEW SET.  VIEW UPDATE is a possibility here if
people insist.

(3) is a big pain for servers.  There's all the burdern of (2), plus they must
watch the state of all messages (either they have to get notified of the state
change, or they have to scan periodically) and reassess any changed-state
message against the VIEW SET.  Also, it can cause unexpected behavior for
users, so this extra "service" may not really be what clients want.

From: Barry Leiba <[email-masked]>
Date: Tue, 3 Aug 1999 17:05:24 -0400
To: IMAP Extensions Working Group <[email-masked]>
Subject: Re: [VIEW] Dynamic vs static
Sender: [email-masked]

> No - this is counter to one of the main purposes of VIEW. What you are
> suggesting requires the client to cache the entire view position<->UID
> mappings for ALL messages in the view.

No, not at all.  Only the messages it's shown the user.  If the user 
hasn't seen the message, then the fact that it's disappeared from the
view is irrelevant.  Once the user has seen the message (it's come up
in the virtual window), then the client has presumably picked up the 
ENVELOPE and FLAGS information, for instance (in order to display it 
in the UI), and, so, can also have picked up the UID at the same time.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 03 Aug 1999 16:30:26 -0400
From: Cyrus Daboo <[email-masked]>
To: Barry Leiba <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Subject: Re: [VIEW] Dynamic vs static
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Tuesday, August 03, 1999, 3:36 PM -0400 Barry Leiba
<[email-masked]> wrote:

> One thing to remember is that this has nothing to do with *user* 
> expectations; it's purely a matter for the client to deal with.  The
> original design of the "view" concept as an extension to "select" had
> it that messages outside the view weren't available to the client.
> That's no longer the case.  Therefore, a client could easily retrieve 
> the UIDs of the messages it presents to the user, and needn't remove
> those messages from the user's view when they're removed from the 
> client's view.
> 
> Another way of looking at it is that the client uses the view sequence 
> numbers to build the UI, but thereafter refers to the messages by UID.

No - this is counter to one of the main purposes of VIEW. What you are
suggesting requires the client to cache the entire view position<->UID
mappings for ALL messages in the view. But the one important point of VIEW
is that clients only need to download information for those messages it
needs to show to the user (i.e. virtual scrollbar). If you force the client
to maintain its own map then its really no different from what Mark
originally proposed with SORT.

Basically a client should be able to solely rely on view positions as
opposed to sequence numbers or UIDs if needs be.

--
Cyrus

Date: Tue, 03 Aug 1999 15:36:16 -0400
From: Barry Leiba <[email-masked]>
Organization: Internet Messaging Technology; TR2_Xagent=WATSON
To: IMAP Extensions Working Group <[email-masked]>
Subject: Re: [VIEW] Dynamic vs static
Sender: [email-masked]

Cyrus Daboo wrote:
> (c) is really the issue of this debate. Should changes to a message's state
> be notified to the client via untagged responses?
> 
> One argument against a dynamic view is to consider the case of a view set
> to display only unseen messages. As soon as a user tries to read such a
...
> suddenly the message the user is trying to read is now outside of the
> client's view! I think this is probably counter to user expectations.

One thing to remember is that this has nothing to do with *user* 
expectations; it's purely a matter for the client to deal with.  The
original design of the "view" concept as an extension to "select" had
it that messages outside the view weren't available to the client.
That's no longer the case.  Therefore, a client could easily retrieve 
the UIDs of the messages it presents to the user, and needn't remove
those messages from the user's view when they're removed from the 
client's view.

Another way of looking at it is that the client uses the view sequence 
numbers to build the UI, but thereafter refers to the messages by UID.

I think the only reasonable and consistent thing to do, given the current 
design, is to make the view fully dynamic.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 03 Aug 1999 11:14:11 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions Working Group <[email-masked]>
Subject: [ANNOTATE] Mailbox and server level annotations
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

The current annotation extension being discussed is for message annotations
only (i.e. each message could have its own set of annotations).

Its also potentially useful to allow mailbox annotations and indeed server
annotations.

For example, mailbox annotations could include annotations describing what
particular sort order a user likes to view this mailbox in, or the window
position and size for displaying a particular mailbox, or a detailed
description of the mailbox contents etc.

Server annotations might include a URL to a webpage for managing accounts
on the server or for doing password changing, a way to map user ids into
user names for handling access control lists, a description of who to
contact when things go wrong on the server etc

Would people find these useful? If they are worth considering as an
extension, they should probably be separate from message annotations, and
indeed separate from each other (i.e. we end up with three annotation
documents).

Any comments?

--
Cyrus

Date: Tue, 03 Aug 1999 11:07:06 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions Working Group <[email-masked]>
Subject: [VIEW] Multiple views
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

The issue of whether the VIEW extension should support multiple views was
raised in Oslo. Here are Steve's minutes on the subject for reference:

> ** Support for multiple VIEWS
> - very expensive for the server implementors
> - will clients actually use it?
>   - there are examples of how a client might use it.
>   - some vendors clearly expressed a desire to have it.
> - there are other workarounds (multiple connections, refining criteria
>   on reissued VIEW)
> - punt issue to list

I think it was clear that most server vendors felt this was adding too much
complexity to VIEW from the outset and would provide too much of a hurdle
for the adoption of the VIEW extension. Is this really how people feel
about this now?

One solution is to design VIEW now as a single VIEW mechanism but to allow
a VIEW2 extension to extend it for multiple views once VIEW has proven
itself to be useful and is widely adopted. If we were to do this it might
be sensible to take this into account when designing VIEW. What I think we
could do is make the definition of the view position more than just the
hierarchical number currently proposed in the extension. If instead we
allowed it to be single or multi-valued then we could add multiple view
very easily in the future.

For example, with multiple views we could say the view position specifier
has two levels of hierarchy - the first is the multiple view number, the
second the position of the message in the view. e.g. view position of 2.3
refers to the third message in view order in the second view. By also
allowing the view position specifier to be multi-valued, changes to a
single message that appears in multiple views could be communicated to the
client in a single response. e.g. for new mail arrival we might have:

        C: NOOP
        S: * 173 EXISTS 24
        S: * 1 RECENT
        S: * 173 VIEW 5274234 (1.14 2.3)
        S: NOOP complete

        A new message arrived and appeared at position 14 in view 1
        and at position 3 in view 2.

Note also that in the case of view operating with the THREAD extension, its
clear that messages can appear in multiple positions in the SAME view. Thus
defining the view position to be single or multi-valued also makes dealing
with THREAD easier.

Comments/other suggestions?

--
Cyrus

Date: Tue, 03 Aug 1999 10:50:15 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions Working Group <[email-masked]>
Subject: [VIEW] Dynamic vs static
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

Hi folks,
At the Oslo meeting we had discussions about whether the VIEW extenions
should be dynamic or static with respect to message changing position in a
view. This issue was not fully resolved and so I'm kicking off some list
discussion about it.

Right now the VIEW extension requires dynamic updates (via responses) from
the server for:

a) new messages arriving in the mailbox
b) messages being expunged from the mailbox
c) messages moving into or out of a view due to a change in some message
state (right now only flags, but this may include annotations once that's
available)

Of these I think (a) and (b) MUST be present. We were all agreed in Oslo
that (a) matches user expectations - i.e. the arrival of any new message
that matches the current view criteria MUST result in that message
appearing in the client's view.

(b) is merely an extenion of the current expunge mechanism where messages
have to be removed from the clients cache when an expunge occurs.

(c) is really the issue of this debate. Should changes to a message's state
be notified to the client via untagged responses?

One argument against a dynamic view is to consider the case of a view set
to display only unseen messages. As soon as a user tries to read such a
message the \Seen flag is implicitly set (of course the client could use
the .PEEK FETCH variant to stop this). At that point in a dynamic view, the
message would be removed from the view via an untagged response, and
suddenly the message the user is trying to read is now outside of the
client's view! I think this is probably counter to user expectations.

One solution to this is to say views are static with respect to changes in
message state and to introduce a new 'VIEW UPDATE' command that the client
can issue to 'refresh' its current view to the actually message state. This
way the client is in control of view updates.

What do people think? Should VIEW be fully dynamic (i.e. (a), (b) & (c)
produce untagged responses), or should it be static (i.e. (a) and (b) are
still dynamic, but (c) does not generate untagged responses)?

--
Cyrus

Date: Wed, 18 Aug 1999 22:50:30 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: SORT and THREAD documents
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 18 Aug 1999, Pete Resnick wrote:
> Damn! I dropped the ball on this one. I was away on vacation when all 
> this went on, and when I came back I didn't get the message off to 
> the I-D editor to put them in the WG namespace. I will do so 
> immediately. Sorry for the inconvenience.

Thanks for the update.  You weren't the only one to have been on vacation.
What I saw on my end, just before I left on vacation, was a response to
the effect that I was not allowed to post ietf-imapext drafts, and that
the SORT and THREAD drafts would have to wait until you approved them or
some timeout expired at which point they'd be posted as a private draft
(which seems to have happened).

I always thought that you used the WG name if an active WG was in progress
on the specification, and used your name only if there wasn't an active
WG.  Did they change the policy as a result of some of the recent
catfights?  If so, perhaps the cure is worse than the disease.  Sigh.

Anyway, would people please look at the SORT and THREAD drafts and see if
they accurately reflect what I described at Oslo.  Also, please start
thinking about how THREAD would work with VIEW, and about additional
standard threading algorithms.  Although I'd like to make
THREAD=ORDEREDSUBJECT mandatory, I think that a standards-track THREAD
needs at least two other algorithms, one to do Message-ID/In-Reply-To and
the other to do Message-ID/References.

I'd also like for someone (other than me!!) who is familiar with the UW
implementation to verify that the THREAD draft accurately describes the UW
implementation of THREAD.  The purpose of the THREAD document is to
document how the UW implementation works (and once confirmed that it does
so propose it as our way of doing threading).  If there is a contradiction
between the document and the UW implementation, the document is the one
that needs to be fixed.

Another point is that there needs to be a second client and server
implementation of THREAD that is shown to interoperate with the UW
implementation.  Before we even think about pushing THREAD further, we
need this.  I suspect that we need to get the additional algorithms
established too, since ORDEREDSUBJECT threading doesn't do nesting and
each message only appears once.  We need threaders that break these
assumptions.

One last thing -- this SORT draft is the *unextended* SORT.  It's to
document today's status quo.  SORT *will* be extended, but not in this
document.  The sooner we get this document to RFC (as either Experimental
or Informational...I'd prefer Informational), the sooner that we can talk
about the extensions to produce a standards-track SORT (and VIEW SET
SORT).

-- Mark --

* RCW 19.190 notice: This email address is located in Washington State.	*
* Unsolicited commercial email may be billed $500 per message.		*
Science does not emerge from voting, party politics, or public debate.

Date: Wed, 18 Aug 1999 23:55:39 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: SORT and THREAD documents
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 8/18/99 at 9:00 PM -0700, Mark Crispin wrote:

>Apparently, these got delayed because they somehow think that these
>documents are not part of the IMAPEXT working group, so the Powers That Be
>objected to them being submitted as draft-ietf-imapext-...
>
>Damned if I know why the WG chair didn't educate them to the contrary.  We
>did talk about both of these at some length in Oslo.

Damn! I dropped the ball on this one. I was away on vacation when all 
this went on, and when I came back I didn't get the message off to 
the I-D editor to put them in the WG namespace. I will do so 
immediately. Sorry for the inconvenience.

Pete: 1 demerit.
Mark: 1 gold star for getting the docs in so quickly.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Wed, 18 Aug 1999 21:00:32 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: SORT and THREAD documents
Organization: Networks & Distributed Computing
Sender: [email-masked]

Apparently, these got delayed because they somehow think that these
documents are not part of the IMAPEXT working group, so the Powers That Be
objected to them being submitted as draft-ietf-imapext-...

Damned if I know why the WG chair didn't educate them to the contrary.  We
did talk about both of these at some length in Oslo.

-- Mark --

* RCW 19.190 notice: This email address is located in Washington State.	*
* Unsolicited commercial email may be billed $500 per message.		*
Science does not emerge from voting, party politics, or public debate.

---------- Forwarded message ----------
Date: Thu, 12 Aug 1999 07:06:44 -0400
From: [email-masked]
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-crispin-imapext-sort-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION
	Author(s)	: M. Crispin
	Filename	: draft-crispin-imapext-sort-00.txt
	Pages		: 8
	Date		: 11-Aug-99
	
This document describes an experimental server-based sorting
extension to the IMAP4rev1 protocol, as implemented by the University
of Washington's IMAP toolkit.  This extension provides substantial
performance improvements for IMAP clients which offer sorted views.
A server which supports this extension indicates this with a
capability name of 'SORT'.  Client implementations SHOULD accept any
capability name which begins with 'SORT' as indicating support for
the extension described in this document.  This provides for future
upwards-compatible extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crispin-imapext-sort-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-crispin-imapext-sort-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-crispin-imapext-sort-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.

---------- Forwarded message ----------
Date: Thu, 12 Aug 1999 07:06:50 -0400
From: [email-masked]
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-crispin-imapext-thread-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
	Author(s)	: M. Crispin
	Filename	: draft-crispin-imapext-thread-00.txt
	Pages		: 7
	Date		: 11-Aug-99
	
This document describes the server-based threading extension to the
IMAP4rev1 protocol.  This extension provides substantial performance
improvements for IMAP clients which offer threaded views.
A server which supports this extension indicates this with more or
more capability names consisting of 'THREAD-' followed by a supported
threading algorithm name as described in this document.  This
provides for future upwards-compatible extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-crispin-imapext-thread-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-crispin-imapext-thread-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-crispin-imapext-thread-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.

Date: Thu, 12 Aug 1999 10:34:55 -0700
From: Chris Newman <[email-masked]>
Subject: RE: transcoding service (was Re: Oslo WG meeting notes)
Originator-info: login-id=chris; server=thor.innosoft.com
To: "Neystadt, John" <[email-masked]>
Cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

The two obvious choices are:

(1) at final delivery time, perform the transcoding (since a user isn't
waiting) and transform that part into a multipart/alternative.  Good IMAP
clients will only download the part they can use.

(2) use the "EXPORT" facility only when transcoding is needed; the user
will just have to wait if the transcoding CPUs are busy.

		- Chris

--On Thu, Aug 12, 1999 8:51 +0300 "Neystadt, John"
<[email-masked]> wrote:

> Chris, how would you solve the following scenario:
> 
> 1. You have a voice mail system with proprietry transcoding.
> 2. Transcoding is a versy expensive (CPU) action.
> 2. There are some smart clients that are able to process messages of
> proprietry transcoding.
> 3. All other clients should get the messages transcoded to a standard one.
> For backward compatibility you can't require them to specify transcoding,
> sine today's Netscape or Outlook don't do it.

Date: Thu, 12 Aug 1999 09:20:33 +0100
From: John Haxby <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Annotations: alternate data model
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------1EAC61DE18969975CE948B2B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

>
> I have to say that "use XML instead" is the correct response to anyone who
> is trying to use ASN.1.  XML is and order of magnitude simpler than ASN.1,
> plus it's trendier and has more tools (the latter two being the only
> important issues to someone considering ASN.1).
>

I'd stick to the "trendier" bit ... :-)

>
> However, within the IMAP protocol, I prefer that we stick to the data
> encoding scheme described in section 4 of RFC 2060.  It's at least an
> order of magnitude simpler than XML and all IMAP servers and clients
> already implement it.

That's all well and good, but you then need a means of describing what goes
in the parenthesised lists and how new annotations can be added and handled
by clients.  Where XML wins here is that the syntax deals with handling the
unknown almost automatically.  For example, the DTD could say that an
annotation looks like

    <annotation name="xyzzy">
        ... anything you like here so long as it's valid XML ...
    </annotation>

The definition of the "xyzzy" annotation could then extend the DTD to
encompass its own stuff.

One could do this for IMAP's parenthesised lists, but first of all you'd have
to agree a common framework into which the annotations could be dropped, and
then you'd have to agree a common structure to which all annotation types
must adhere (so that they can at least be read, if not understood), and then
.... Well, there's still the problem of those clients and servers that
*still* (after all this time) make a dog's dinner of handling literal
strings.

jch

--------------1EAC61DE18969975CE948B2B
Content-Type: text/x-vcard; charset=us-ascii;
 name="jch.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Haxby
Content-Disposition: attachment;
 filename="jch.vcf"

begin:vcard 
n:Haxby;John
tel;work:+44 1344 763711
x-mozilla-html:FALSE
url:http://www.hp.com/go/OpenMail
org:Hewlett Packard;OpenMail R&D<img src="http://www.ice.hp.com/cyc/om/50/graphics/omlinux.jpg" width=53 height=62 align=top>
adr:;;Nine Mile Ride;Wokingham;Berks;RG40 3LL;England
version:2.1
email;internet:[email-masked]
x-mozilla-cpt:;14976
fn:John Haxby
end:vcard

--------------1EAC61DE18969975CE948B2B--

From: "Neystadt, John" <[email-masked]>
To: "'Chris Newman'" <[email-masked]>
Cc: IMAP Extensions Working Group <[email-masked]>
Subject: RE: transcoding service (was Re: Oslo WG meeting notes)
Date: Thu, 12 Aug 1999 08:51:15 +0300
Sender: [email-masked]

Chris, how would you solve the following scenario:

1. You have a voice mail system with proprietry transcoding.
2. Transcoding is a versy expensive (CPU) action.
2. There are some smart clients that are able to process messages of
proprietry transcoding.
3. All other clients should get the messages transcoded to a standard one.
For backward compatibility you can't require them to specify transcoding,
sine today's Netscape or Outlook don't do it.

John Neystadt
[email-masked]
http://www.neystadt.org/john/

> -----Original Message-----
> From: Chris Newman [mailto:[email-masked]]
> Sent: Thursday, August 12, 1999 3:36 AM
> To: Barry Leiba
> Cc: IMAP Extensions Working Group
> Subject: transcoding service (was Re: Oslo WG meeting notes)
> 
> 
> On Fri, 23 Jul 1999, Barry Leiba wrote:
> > > > > *** Transcoding Request
> > > > > - assertion that there are substantial interoperability issues
> > > > > - better dealt with by picking standardized 
> represention of content-type
> > > 
> > > The concensus was that expecting servers to implement elaborate
> > > transcoding facilities, it would be much better if the 
> VPIM folks could
> > > settle on a reasonable small set of mandatory or 
> recommended to implement.
> > 
> > ...
> > 
> > I think it's useful to have such capability, and I think 
> it's worth discussing
> > how we might do it in an interoperable way.  The tough bits 
> will be defining
> > the various transcodings that can be done, how to list 
> them, how to specify
> > them, how to add more, and so on.  The basic mechanism 
> shouldn't be terribly
> > controversial.
> 
> Actually, I'm 100% opposed to including any transcoding 
> services (beyond
> removal of standard content-transfer-encodings) in IMAP itself.
> Transcoding is a general facility which could be applied to 
> data coming
> from a mail store, web server, ftp site or any other source.  
> Functional
> modularity suggests that IMAP has no business performing such 
> a general
> purpose service.
> 
> Given that, here's how I'd address the transcoding problem 
> with respect to
> IMAP.  The same approach could apply to the recurring issue 
> of forwarding
> a message via an SMTP SUBMIT server without downloading it to 
> a client. 
> 
> Add a simple extension to the IMAP server which allows a MIME 
> entity (or
> message) to be accessed by an external service.  This extension would
> return a URL to that MIME entity. 
> 
> Here's a very rough strawman:
> 
> tag EXPORT <service> <uid> "["[body-part-number]"]" <expires>
> * EXPORT <service> <uid> [body-part-number]
>   
> "imap://<service>@<imap-server>/Joe/;uid=10/;section=[body-par
> t-number]"
> 
> Then the client can simply pass that URL to the transcoding 
> service (or
> SMTP SUBMIT server) which can then log in to the IMAP server 
> and access
> the body part(s).  There a number of subtleties, especially related to
> security and persistance, but I think the general idea is workable. 
> 
> If all the details are nailed down correctly, then the 
> transcoding server
> could come from a different vendor than the IMAP server and 
> it would all
> interoperate.  Given that transcoding expertise and IMAP 
> server expertise
> are *very* different I think that's exactly as it should be.  If
> efficiency is an issue, just co-locate the transcoding server with the
> IMAP server and document an efficient "IMAP export" API. 
> 
> 		- Chris
> 

Date: Wed, 11 Aug 1999 17:36:02 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: transcoding service (was Re: Oslo WG meeting notes)
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Barry Leiba <[email-masked]>
Cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Fri, 23 Jul 1999, Barry Leiba wrote:
> > > > *** Transcoding Request
> > > > - assertion that there are substantial interoperability issues
> > > > - better dealt with by picking standardized represention of content-type
> > 
> > The concensus was that expecting servers to implement elaborate
> > transcoding facilities, it would be much better if the VPIM folks could
> > settle on a reasonable small set of mandatory or recommended to implement.
> 
> ...
> 
> I think it's useful to have such capability, and I think it's worth discussing
> how we might do it in an interoperable way.  The tough bits will be defining
> the various transcodings that can be done, how to list them, how to specify
> them, how to add more, and so on.  The basic mechanism shouldn't be terribly
> controversial.

Actually, I'm 100% opposed to including any transcoding services (beyond
removal of standard content-transfer-encodings) in IMAP itself.
Transcoding is a general facility which could be applied to data coming
from a mail store, web server, ftp site or any other source.  Functional
modularity suggests that IMAP has no business performing such a general
purpose service.

Given that, here's how I'd address the transcoding problem with respect to
IMAP.  The same approach could apply to the recurring issue of forwarding
a message via an SMTP SUBMIT server without downloading it to a client. 

Add a simple extension to the IMAP server which allows a MIME entity (or
message) to be accessed by an external service.  This extension would
return a URL to that MIME entity. 

Here's a very rough strawman:

tag EXPORT <service> <uid> "["[body-part-number]"]" <expires>
* EXPORT <service> <uid> [body-part-number]
  "imap://<service>@<imap-server>/Joe/;uid=10/;section=[body-part-number]"

Then the client can simply pass that URL to the transcoding service (or
SMTP SUBMIT server) which can then log in to the IMAP server and access
the body part(s).  There a number of subtleties, especially related to
security and persistance, but I think the general idea is workable. 

If all the details are nailed down correctly, then the transcoding server
could come from a different vendor than the IMAP server and it would all
interoperate.  Given that transcoding expertise and IMAP server expertise
are *very* different I think that's exactly as it should be.  If
efficiency is an issue, just co-locate the transcoding server with the
IMAP server and document an efficient "IMAP export" API. 

		- Chris

Date: Wed, 11 Aug 1999 17:04:42 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Annotations: alternate data model
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: IMAP Extensions Working Group <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Wed, 28 Jul 1999, John Haxby wrote:
> > I've been using XML in some projects here and like a lot of its
> > features. We did have to do something about representing binary values
> > within XML, but otherwise are fairly pleased with XML as a data
> > representation language.
> 
> I have to agree here.
> 
> It's certainly a lot easier to get to grips with than ASN.1!

I have to say that "use XML instead" is the correct response to anyone who
is trying to use ASN.1.  XML is and order of magnitude simpler than ASN.1,
plus it's trendier and has more tools (the latter two being the only
important issues to someone considering ASN.1).

However, within the IMAP protocol, I prefer that we stick to the data
encoding scheme described in section 4 of RFC 2060.  It's at least an
order of magnitude simpler than XML and all IMAP servers and clients
already implement it.

		- Chris

Date: Wed, 11 Aug 1999 05:51:32 +0200 (METDST)
From: Arnaud Taddei <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Chris Newman <[email-masked]>, steve spear <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Just for the anectdote try to oppen a 50,000 mailbox created by a user
mail loop with, say, pine and Netscape or Outlook ...  fortunately we have
the robust, non caching, pine program with the 2 others this is nearly
impossible to even get the cursor back after opening the folder.

On Tue, 10 Aug 1999, Mark Crispin wrote:

> On Tue, 10 Aug 1999, Chris Newman wrote:
> > While I think a full disconnected-model IMAP client makes sense for a
> > user's "primary mail reading machine" (I'm just waiting for a client
> > vendor to implemented background cache updating :-), there is a high
> > demand both for "kiosk" model usage (where a machine doesn't have a
> > primary user) and for "travel" usage (where a user is away from their
> > primary machine, and perhaps using someone else's primary machine).
> 
> Let's put it this way.  I find *all* of the full disconnected-model IMAP
> clients to be intolerable.  The only tolerable clients are those which
> permit turning off the disconnected-model.
> 
> On a fast network, it's a completely unnecessary waste of client disk
> space.  On a slow network, the first open of a 5000 message mailbox is
> ridiculously slow.
> 
> > wireless continues to become more popular, average network bandwidth may
> > *drop* from current levels.
> 
> Speaking as one who uses wireless a *lot*, I'm amazed at how well online
> model Pine performs, and how terribly disconnected model clients perform.
> 
> -- Mark --
> 
> * RCW 19.190 notice: This email address is located in Washington State.	*
> * Unsolicited commercial email may be billed $500 per message.		*
> Science does not emerge from voting, party politics, or public debate.
> 
> 

------------------------------------------------------------
Arnaud Taddei		tel:  +41 22 767 9349
IT Division  31 1-016	fax:  +41 22 767 7155
CERN			mail: [email-masked]
CH-1211 Geneve 23	URL:  http://home.cern.ch/taddei
------------------------------------------------------------

Date: Wed, 11 Aug 1999 05:47:27 +0200 (METDST)
From: Arnaud Taddei <[email-masked]>
To: Terry Gray <[email-masked]>
cc: Chris Newman <[email-masked]>, steve spear <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Sender: [email-masked]

Some operational feedback, if in addition you add all the _pathological_
cases like:

- the IMAP cache is stored in files *without* locking mechanisms, when
  you start 2 instances of your clients and your home directory is coming
  from a central file server you have very nice corruptions (and it seems
  to be a very difficult message to pass to vendors!!!). It is even worse
  for the addressbook but this is a different _acap_/_ldap_ story.
- corruptions of the local IMAP cache lead to a wide spectra of side
  effects
- problems of synchronisation between the local cache with the
  subscription to folders model when you use other clients
- problems due to the access to the disks of PCs which happens too often
  (we had very interesting surprises when we inspeceted fragmentation
  rate of users PC disks). This _slows_ down programs!
- no button provided to users to force a resynchronisation between what is
  on the server and your cache

So yes please anything which can be done to remove the local IMAP cache
can only help by making sure the solution is to some extend truly location
independent (we have 50,000 physicists travelling with all possible
patterns and demands) and remove a wide range of operational problems.

>From our user support team, the corruption of the local IMAP cache is by
far the first problem they address on a daily basis for the support of
thousands of users and we desigend our own tools and recipes to have quick
ways to help users.

my $0.01

On Tue, 10 Aug 1999, Terry Gray wrote:

> I'll just add that folks who have no "primary" machine, but rather 
> routinely use two or three different computers every day, may prefer
> clients that operate in "kiosk" mode rather than suffer with the startup
> and resynch delays that seem to go with many of today's offline and
> disconnected clients...  (certainly I do! :)
> 
> -teg
> 
> On Tue, 10 Aug 1999, Chris Newman wrote:
> 
> > On Tue, 29 Jun 1999, steve spear wrote:
> > > Can someone explain how traffic is reduced by SORT over clients that are
> > > caching the headers and simply request messages headers they haven't seen
> > > before?
> > 
> > While I think a full disconnected-model IMAP client makes sense for a
> > user's "primary mail reading machine" (I'm just waiting for a client
> > vendor to implemented background cache updating :-), there is a high
> > demand both for "kiosk" model usage (where a machine doesn't have a
> > primary user) and for "travel" usage (where a user is away from their
> > primary machine, and perhaps using someone else's primary machine).  In
> > both cases a proper cache doesn't exist, so the VIEW SORT model allows the
> > client to download just what it needs rather than to populate a cache
> > which it will just have to discard.
> > 
> > One could argue that "web mail" products suffice for kiosk and travelling
> > users, but I'm dubious of their scalability, let alone their usability. 
> 
> (etc)
> 
> 

------------------------------------------------------------
Arnaud Taddei		tel:  +41 22 767 9349
IT Division  31 1-016	fax:  +41 22 767 7155
CERN			mail: [email-masked]
CH-1211 Geneve 23	URL:  http://home.cern.ch/taddei
------------------------------------------------------------

Date: Tue, 10 Aug 1999 20:15:40 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Chris Newman <[email-masked]>
cc: steve spear <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 10 Aug 1999, Chris Newman wrote:
> While I think a full disconnected-model IMAP client makes sense for a
> user's "primary mail reading machine" (I'm just waiting for a client
> vendor to implemented background cache updating :-), there is a high
> demand both for "kiosk" model usage (where a machine doesn't have a
> primary user) and for "travel" usage (where a user is away from their
> primary machine, and perhaps using someone else's primary machine).

Let's put it this way.  I find *all* of the full disconnected-model IMAP
clients to be intolerable.  The only tolerable clients are those which
permit turning off the disconnected-model.

On a fast network, it's a completely unnecessary waste of client disk
space.  On a slow network, the first open of a 5000 message mailbox is
ridiculously slow.

> wireless continues to become more popular, average network bandwidth may
> *drop* from current levels.

Speaking as one who uses wireless a *lot*, I'm amazed at how well online
model Pine performs, and how terribly disconnected model clients perform.

-- Mark --

* RCW 19.190 notice: This email address is located in Washington State.	*
* Unsolicited commercial email may be billed $500 per message.		*
Science does not emerge from voting, party politics, or public debate.

Date: Tue, 10 Aug 1999 19:30:27 -0700 (Pacific Daylight Time)
From: Terry Gray <[email-masked]>
To: Chris Newman <[email-masked]>
cc: steve spear <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Organization: University of Washington;  Computing & Communications
Sender: [email-masked]

I'll just add that folks who have no "primary" machine, but rather 
routinely use two or three different computers every day, may prefer
clients that operate in "kiosk" mode rather than suffer with the startup
and resynch delays that seem to go with many of today's offline and
disconnected clients...  (certainly I do! :)

-teg

On Tue, 10 Aug 1999, Chris Newman wrote:

> On Tue, 29 Jun 1999, steve spear wrote:
> > Can someone explain how traffic is reduced by SORT over clients that are
> > caching the headers and simply request messages headers they haven't seen
> > before?
> 
> While I think a full disconnected-model IMAP client makes sense for a
> user's "primary mail reading machine" (I'm just waiting for a client
> vendor to implemented background cache updating :-), there is a high
> demand both for "kiosk" model usage (where a machine doesn't have a
> primary user) and for "travel" usage (where a user is away from their
> primary machine, and perhaps using someone else's primary machine).  In
> both cases a proper cache doesn't exist, so the VIEW SORT model allows the
> client to download just what it needs rather than to populate a cache
> which it will just have to discard.
> 
> One could argue that "web mail" products suffice for kiosk and travelling
> users, but I'm dubious of their scalability, let alone their usability. 

(etc)

Date: Tue, 10 Aug 1999 16:54:10 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: steve spear <[email-masked]>
Cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Tue, 29 Jun 1999, steve spear wrote:
> Can someone explain how traffic is reduced by SORT over clients that are
> caching the headers and simply request messages headers they haven't seen
> before?

While I think a full disconnected-model IMAP client makes sense for a
user's "primary mail reading machine" (I'm just waiting for a client
vendor to implemented background cache updating :-), there is a high
demand both for "kiosk" model usage (where a machine doesn't have a
primary user) and for "travel" usage (where a user is away from their
primary machine, and perhaps using someone else's primary machine).  In
both cases a proper cache doesn't exist, so the VIEW SORT model allows the
client to download just what it needs rather than to populate a cache
which it will just have to discard.

One could argue that "web mail" products suffice for kiosk and travelling
users, but I'm dubious of their scalability, let alone their usability. 

> As Tony Hansen pointed out - AT&T is trying to handle many millions
> of users.  The thought of using more resources on the server instead of the
> clients that are largely idle is a concern of ours.

I think it's important to note that CPU speed, disk space, RAM, server
performance and client performance all are increasing by Moore's law. 
Network bandwidth and throughput between client&server are not, and if
wireless continues to become more popular, average network bandwidth may
*drop* from current levels.

		- Chris

Date: Tue, 10 Aug 1999 16:30:52 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: [VIEW] Dynamic vs static
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

I'm really torn on the dynamic vs. static issue.

The "static view" model is an order of magnitude easier and more efficient
to implement on the server.  But it clearly doesn't meet the needs of a
client.

The "semi-dynamic view" model is easier for a server to implement (as
flag-change notifications don't have to update the view mapping), and
seems to be closer to what most clients seem to want. But if the
connection is dropped there is no way for the client to reconnect and get
back to the same server state.  That makes the engineer in me cringe, but
I'm not sure it's a show-stopper.

The "fully-dynamic view" model forces a "semi-dynamic" client to keep a
UID-VIEW mapping for messages it's presented to the user.  That mapping
also allows it to gracefully deal with a server disconnect/reconnect
situation.  Furthermore if a client disconnects, reconnects, and re-issues
the SELECT and VIEW SET commands, then the protocol state is the same as
if the client had stayed connected.  That "feels" better.

Unfortunately, I think the bulk of the strong arguments seem to be leaning
in the direction of the "semi-dynamic view" model, and perhaps that is
"good enough" to get deployed and solve the problem.

		- Chris

Date: Tue, 10 Aug 1999 15:43:27 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: [VIEW] Unsolicited response rules
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

Sorry I haven't been involved in this discussion until now and couldn't
make it to Oslo.  FWIW, I support the general VIEW approach and feel a bit
more comfortable with it than with the modified SELECT.

One subtlety which hasn't been addressed carefully is the rules for
unsolicited responses.

The rules for EXPUNGE responses need to be adjusted:

   An EXPUNGE reponse MUST NOT be sent when no command is in progress;
   nor while responding to a FETCH, STORE, SEARCH, VIEW FETCH,
   VIEW STORE or VIEW SEARCH.

I'm wondering whether "VIEW SET" should also be in this list.  If we don't
add the "VIEW SELECT" feature, I'd say it has to be added.  Otherwise I'm
unsure.

The rules for the VIEW responses is that they can not occur during a VIEW
FETCH, VIEW STORE, or VIEW SEARCH.  A VIEW response doesn't have any
negative impact on a regular FETCH/STORE/SEARCH and certainly not on a UID
FETCH/STORE/SEARCH.

		- Chris

Date: Thu, 05 Aug 1999 14:21:29 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Wolfgang Segmuller <[email-masked]>
cc: IMAP Working Group <[email-masked]>
Subject: re: [View] Interactions with select
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Thu, Aug 5, 1999 11:09 AM -0700 Mark Crispin <[email-masked]>
wrote:

>> I think that this should be clearly spelled out in the proposal.  Which
>> way doesn't matter, but I would like to see select cancel a view.
> 
> I agree!

Agreed, a SELECT or EXAMINE will reset any VIEW in effect at the time. I
will ensure this is clearly spelled out in the next revision of the draft.

--
Cyrus

Date: Thu, 5 Aug 1999 11:09:18 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: [View] Interactions with select
To: Wolfgang Segmuller <[email-masked]>
cc: IMAP Working Group <[email-masked]>
Sender: [email-masked]

On Thu, 5 Aug 1999 14:04:18 -0400, Wolfgang Segmuller wrote:

> I think that this should be clearly spelled out in the proposal.  Which way
> doesn't matter, but I would like to see select cancel a view.

I agree!

From: Wolfgang Segmuller <[email-masked]>
Date: Thu, 5 Aug 1999 14:04:18 -0400
To: IMAP Working Group <[email-masked]>
Subject: [View] Interactions with select
Sender: [email-masked]

If a view is active and a select is issued, what is the status of the view.  
Is the last view still in effect.

I think that this should be clearly spelled out in the proposal.  Which way 
doesn't matter, but I would like to see select cancel a view.

Wolfgang

Date: Thu, 05 Aug 1999 09:36:43 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New version of the ID draft
Sender: [email-masked]

Greetings. I just discovered that I had not put the ID draft on the list of 
extensions on the web page at <http://www.imc.org/ietf-imapext/>. Given 
that the -03 version just came out, this is a tad late, but at least I got 
it there now.

If you know of any other drafts that should be listed on that page, please 
let me know.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 05 Aug 1999 10:31:58 -0400
From: Barry Leiba <[email-masked]>
Organization: Internet Messaging Technology; TR2_Xagent=WATSON
To: IMAP Extensions Working Group <[email-masked]>
Subject: Re: [VIEW] Dynamic vs static
Sender: [email-masked]

What I'm saying is basically the same as what Mark is saying... VIEW 
can perfectly well do things that affect how the *client* sees things
without having to affect how the *user* sees things.  In particular...

Cyrus Daboo wrote:
> Right, but from then on the client has to go through a complex procedure
> for figuring out which messages are in its display list and are part of the
> server view and which are not part of the server view. So if a user selects
> all the messages and then does a delete, the client ends up having to issue
> two commands to delete the message: 'VIEW STORE' for messages in the server
> view, and 'UID STORE' for messages outside the server view. 

Yes, but it only has to do that for messages that it's been told have been 
removed from the view.  That's not terrible, and not particularly "complex".
And to my mind it's sensible.  The client needs to be able to deal with these
issues anyway if it wants to seamlessly reconnect after a communication problem.

Simple enough to do: when the server tells you that a message was removed from
the view, you set a flag on that message.  Whenever you need to do anything
with that message, you now use the UID instead of the view position.  What's
the big deal?

> There is another option that I didn't mention in my first port on this, and
> that is the possibility of allowing both dynamic and static views but have
> the client decide when the VIEW is set which it wants.

I could implement this, but I'd rather not; it seems more involved than
necessary.  I'd rather define the view semantics clearly and distinctly.

One disagreement with Mark on this, BTW:
> (3) is a big pain for servers. 
No... (3) is a big pain for *some* servers, and for the UW server in 
particular, perhaps.  As it turns out, all three options are equally easy 
for me to implement in my server; it falls out of the "view" that's already 
designed in.  I suspect that server implementations will vary as to which
ones are easier or harder to do.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Wed, 4 Aug 1999 13:18:36 -0500
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: re: [VIEW] Dynamic vs static
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On 8/4/99 at 10:27 AM -0700, Mark Crispin wrote:

>The client programmers also have the task of developing an interface for the
>users that the users can use; the question is then whether or not VIEW assists
>them in this goal and which proposed flavor of VIEW does so the best.
>
>That's quite different from how easy it is for users to use VIEW, or whether
>VIEW does what users want.  I contend that these concerns are irrelevant...

I think Cyrus is just conflating some terms here, but his concerns 
are valid: We need to design the protocol so that the *semantics* of 
what the user wants to do are reflected in the *semantics* of the 
protocol. That's how we get VIEW to "assist" client programmers in 
their goal of implementing what the user wants. If you can't map the 
semantics of the protocol onto the semantics of the user action, then 
either you can't implement the user action, or it has to be done in 
an extra-protocol way (i.e., more work for the implementor, and 
potentially introducing interoperability problems).

Personally, I think because of the above, static VIEW is just a 
non-starter. My guess is that some people will want to implement 
semi-dynamic and some will want to implement fully-dynamic and it 
actually doesn't make much of a difference to client writers which 
one the server implements so long as it can find out which one it is.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

Date: Wed, 4 Aug 1999 10:27:15 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: [VIEW] Dynamic vs static
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Wed, 04 Aug 1999 12:40:18 -0400, Cyrus Daboo wrote:
> Well I would like to throw something else into this equation - namely
> 'users'. Its all well and good to have this functionality available on
> client and server but if its too difficult for the user to use, or doesn't
> do what they really want it to, then its not going to be of much use.

I'd like to move away from this sort of thinking.

VIEW (for that matter, all of IMAP) is not for users to use.  It is for client
programmers.  Users use the client program, *not* a protocol.

The usability questions therefore revolve among the programmers.  The server
programmers must be able to implement it, and the client programmers must be
able to use it.

The client programmers also have the task of developing an interface for the
users that the users can use; the question is then whether or not VIEW assists
them in this goal and which proposed flavor of VIEW does so the best.

That's quite different from how easy it is for users to use VIEW, or whether
VIEW does what users want.  I contend that these concerns are irrelevant, and
have the risk of leading people down the garden path of designing less
predictable "fuzzy" functionality into a protocol.  That, in turn, ultimately
renders the protocol less useful for clients with different designs.

Date: Wed, 04 Aug 1999 12:50:32 -0400
From: Cyrus Daboo <[email-masked]>
To: Barry Leiba <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Subject: Re: [VIEW] Dynamic vs static
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Tuesday, August 03, 1999, 5:05 PM -0400 Barry Leiba
<[email-masked]> wrote:

> No, not at all.  Only the messages it's shown the user.  If the user 
> hasn't seen the message, then the fact that it's disappeared from the
> view is irrelevant.  Once the user has seen the message (it's come up
> in the virtual window), then the client has presumably picked up the 
> ENVELOPE and FLAGS information, for instance (in order to display it 
> in the UI), and, so, can also have picked up the UID at the same time.

Right, but from then on the client has to go through a complex procedure
for figuring out which messages are in its display list and are part of the
server view and which are not part of the server view. So if a user selects
all the messages and then does a delete, the client ends up having to issue
two commands to delete the message: 'VIEW STORE' for messages in the server
view, and 'UID STORE' for messages outside the server view. It has to do
the same sort of thing if the user just wants to search the message within
the client's current view. There's no reason why a client can't do this,
but I don't think we should force this complex behaviour by requiring VIEW
to be fully dynamic, if most clients really want the static form of view.

Remember, its easy for a client to take the static form of VIEW and
effectively emulate a dynamic form by simply issuing a 'VIEW UPDATE'
command everytime there's an unsolicted response from the server that might
result in a change to the view. Its much harder to emulate the static mode
when the server only supports the dynamic mode.

There is another option that I didn't mention in my first port on this, and
that is the possibility of allowing both dynamic and static views but have
the client decide when the VIEW is set which it wants.
--
Cyrus

Date: Wed, 04 Aug 1999 12:40:18 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions Working Group <[email-masked]>
Subject: re: [VIEW] Dynamic vs static
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Tuesday, August 03, 1999, 4:45 PM -0700 Mark Crispin
<[email-masked]> wrote:

> One way of looking at this is that "what IMAP does is not necessarily
> what the client will show".  We should focus on what is best for client
> implementations (because clients are what will benefit from it) and what
> is feasible for server implementations (because if it isn't feasible then
> servers won't implement it).

Well I would like to throw something else into this equation - namely
'users'. Its all well and good to have this functionality available on
client and server but if its too difficult for the user to use, or doesn't
do what they really want it to, then its not going to be of much use.

Its already the case that a number of client vendors have a VIEW type
mechanism built into their clients, using client-based searching etc to
determine the view. I know from our own experience (about a year's worth)
that users want to have any new messages that arrive with matching view
criteria immediately displayed to them. In other words new message arrival
MUST result in dynamic VIEW responses.

Also, having looked back at user discussions, its clear that they do NOT
want a fully dynamic view at least in the sense that messages dissappear
from the view if they no longer match because of a flag change.

In other words option (2) as described in Mark's original post matches
(our) users' expectations of how view should work.

I think we should hear from otehr client vendors with a similar client-side
mechanism to see what their usability studies suggest in this area.

--
Cyrus

Date: Tue, 3 Aug 1999 17:14:29 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: [VIEW] Multiple views
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Tue, 03 Aug 1999 11:07:06 -0400, Cyrus Daboo wrote:
> I think it was clear that most server vendors felt this was adding too much
> complexity to VIEW from the outset and would provide too much of a hurdle
> for the adoption of the VIEW extension. Is this really how people feel
> about this now?

If the VIEW extension ends up requiring support for multiple views, I probably
won't implement it.

> One solution is to design VIEW now as a single VIEW mechanism but to allow
> a VIEW2 extension to extend it for multiple views once VIEW has proven
> itself to be useful and is widely adopted. If we were to do this it might
> be sensible to take this into account when designing VIEW.

I agree that VIEW should claim to be a proper subset of all IMAP capabilities
with begin with "VIEW", so as to provide extensibility.

> What I think we
> could do is make the definition of the view position more than just the
> hierarchical number currently proposed in the extension. If instead we
> allowed it to be single or multi-valued then we could add multiple view
> very easily in the future.

Ugh!  Think about what would happen if people want multiple *nested* views.
Please, let's not go here.

>         S: * 173 VIEW 5274234 (1.14 2.3)
>         A new message arrived and appeared at position 14 in view 1
>         and at position 3 in view 2.
> Note also that in the case of view operating with the THREAD extension, its
> clear that messages can appear in multiple positions in the SAME view. Thus
> defining the view position to be single or multi-valued also makes dealing
> with THREAD easier.

I don't understand this.  The view position has to be multi-valued, meaning
that the message appears in multiple places in the view.  If you really wanted
multiple view syntax, you would need something like:
	S: * 173 VIEW 5274234 (1.14) (2.3)

Date: Tue, 3 Aug 1999 16:45:41 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: [VIEW] Dynamic vs static
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

One way of looking at this is that "what IMAP does is not necessarily what the
client will show".  We should focus on what is best for client implementations
(because clients are what will benefit from it) and what is feasible for
server implementations (because if it isn't feasible then servers won't
implement it).

I think that I reject any idea to be "smart", e.g. making a special exception
for the \Seen or \Recent flags for "new" messages.

I think that our choices are:

1) fully-static.  Once a view is set, it's immutable.  I guess that this means
   that if a message in the view is expunged, the view gets a hole.

2) semi-static.  Once a message is entered into the view, it stays there even
   if its state changes in a way that would cause it to leave the view.
   However, expunged messages are removed from the view (so you can do math on
   view ids the way you can on sequences), and new messages are incorporated
   into the view as appropriate.

3) dynamic.  Messages are added to the view via new messages or if the state
   of a non-viewed message changes.  Messages are removed from the view via
   expunge or if the state of a viewed message changes.

I think that (1) is probably a non-starter for client implementors.  It would
be the easiest to implement for server implementors, since it doesn't require
us to remember the VIEW SET (as opposed to the map created by it).  The
problem with VIEW UPDATE is that it combines the worst of both worlds -- it
requires the client to issue a command to fix the view, and it requires the
server to remember the VIEW SET.  Let's reject VIEW UPDATE for (1), say "with
(1), the client must issue a new VIEW SET to update the view."

(2) is probably what most people want and what server guys will acceed to.
It's a pain for servers to have to remember the VIEW SET, but not as bad as
(3).  If clients really want messages to disappear from the view due to state
changes, they can issue a new VIEW SET.  VIEW UPDATE is a possibility here if
people insist.

(3) is a big pain for servers.  There's all the burdern of (2), plus they must
watch the state of all messages (either they have to get notified of the state
change, or they have to scan periodically) and reassess any changed-state
message against the VIEW SET.  Also, it can cause unexpected behavior for
users, so this extra "service" may not really be what clients want.

From: Barry Leiba <[email-masked]>
Date: Tue, 3 Aug 1999 17:05:24 -0400
To: IMAP Extensions Working Group <[email-masked]>
Subject: Re: [VIEW] Dynamic vs static
Sender: [email-masked]

> No - this is counter to one of the main purposes of VIEW. What you are
> suggesting requires the client to cache the entire view position<->UID
> mappings for ALL messages in the view.

No, not at all.  Only the messages it's shown the user.  If the user 
hasn't seen the message, then the fact that it's disappeared from the
view is irrelevant.  Once the user has seen the message (it's come up
in the virtual window), then the client has presumably picked up the 
ENVELOPE and FLAGS information, for instance (in order to display it 
in the UI), and, so, can also have picked up the UID at the same time.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 03 Aug 1999 16:30:26 -0400
From: Cyrus Daboo <[email-masked]>
To: Barry Leiba <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Subject: Re: [VIEW] Dynamic vs static
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Tuesday, August 03, 1999, 3:36 PM -0400 Barry Leiba
<[email-masked]> wrote:

> One thing to remember is that this has nothing to do with *user* 
> expectations; it's purely a matter for the client to deal with.  The
> original design of the "view" concept as an extension to "select" had
> it that messages outside the view weren't available to the client.
> That's no longer the case.  Therefore, a client could easily retrieve 
> the UIDs of the messages it presents to the user, and needn't remove
> those messages from the user's view when they're removed from the 
> client's view.
> 
> Another way of looking at it is that the client uses the view sequence 
> numbers to build the UI, but thereafter refers to the messages by UID.

No - this is counter to one of the main purposes of VIEW. What you are
suggesting requires the client to cache the entire view position<->UID
mappings for ALL messages in the view. But the one important point of VIEW
is that clients only need to download information for those messages it
needs to show to the user (i.e. virtual scrollbar). If you force the client
to maintain its own map then its really no different from what Mark
originally proposed with SORT.

Basically a client should be able to solely rely on view positions as
opposed to sequence numbers or UIDs if needs be.

--
Cyrus

Date: Tue, 03 Aug 1999 15:36:16 -0400
From: Barry Leiba <[email-masked]>
Organization: Internet Messaging Technology; TR2_Xagent=WATSON
To: IMAP Extensions Working Group <[email-masked]>
Subject: Re: [VIEW] Dynamic vs static
Sender: [email-masked]

Cyrus Daboo wrote:
> (c) is really the issue of this debate. Should changes to a message's state
> be notified to the client via untagged responses?
> 
> One argument against a dynamic view is to consider the case of a view set
> to display only unseen messages. As soon as a user tries to read such a
...
> suddenly the message the user is trying to read is now outside of the
> client's view! I think this is probably counter to user expectations.

One thing to remember is that this has nothing to do with *user* 
expectations; it's purely a matter for the client to deal with.  The
original design of the "view" concept as an extension to "select" had
it that messages outside the view weren't available to the client.
That's no longer the case.  Therefore, a client could easily retrieve 
the UIDs of the messages it presents to the user, and needn't remove
those messages from the user's view when they're removed from the 
client's view.

Another way of looking at it is that the client uses the view sequence 
numbers to build the UI, but thereafter refers to the messages by UID.

I think the only reasonable and consistent thing to do, given the current 
design, is to make the view fully dynamic.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 03 Aug 1999 11:14:11 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions Working Group <[email-masked]>
Subject: [ANNOTATE] Mailbox and server level annotations
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

The current annotation extension being discussed is for message annotations
only (i.e. each message could have its own set of annotations).

Its also potentially useful to allow mailbox annotations and indeed server
annotations.

For example, mailbox annotations could include annotations describing what
particular sort order a user likes to view this mailbox in, or the window
position and size for displaying a particular mailbox, or a detailed
description of the mailbox contents etc.

Server annotations might include a URL to a webpage for managing accounts
on the server or for doing password changing, a way to map user ids into
user names for handling access control lists, a description of who to
contact when things go wrong on the server etc

Would people find these useful? If they are worth considering as an
extension, they should probably be separate from message annotations, and
indeed separate from each other (i.e. we end up with three annotation
documents).

Any comments?

--
Cyrus

Date: Tue, 03 Aug 1999 11:07:06 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions Working Group <[email-masked]>
Subject: [VIEW] Multiple views
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

The issue of whether the VIEW extension should support multiple views was
raised in Oslo. Here are Steve's minutes on the subject for reference:

> ** Support for multiple VIEWS
> - very expensive for the server implementors
> - will clients actually use it?
>   - there are examples of how a client might use it.
>   - some vendors clearly expressed a desire to have it.
> - there are other workarounds (multiple connections, refining criteria
>   on reissued VIEW)
> - punt issue to list

I think it was clear that most server vendors felt this was adding too much
complexity to VIEW from the outset and would provide too much of a hurdle
for the adoption of the VIEW extension. Is this really how people feel
about this now?

One solution is to design VIEW now as a single VIEW mechanism but to allow
a VIEW2 extension to extend it for multiple views once VIEW has proven
itself to be useful and is widely adopted. If we were to do this it might
be sensible to take this into account when designing VIEW. What I think we
could do is make the definition of the view position more than just the
hierarchical number currently proposed in the extension. If instead we
allowed it to be single or multi-valued then we could add multiple view
very easily in the future.

For example, with multiple views we could say the view position specifier
has two levels of hierarchy - the first is the multiple view number, the
second the position of the message in the view. e.g. view position of 2.3
refers to the third message in view order in the second view. By also
allowing the view position specifier to be multi-valued, changes to a
single message that appears in multiple views could be communicated to the
client in a single response. e.g. for new mail arrival we might have:

        C: NOOP
        S: * 173 EXISTS 24
        S: * 1 RECENT
        S: * 173 VIEW 5274234 (1.14 2.3)
        S: NOOP complete

        A new message arrived and appeared at position 14 in view 1
        and at position 3 in view 2.

Note also that in the case of view operating with the THREAD extension, its
clear that messages can appear in multiple positions in the SAME view. Thus
defining the view position to be single or multi-valued also makes dealing
with THREAD easier.

Comments/other suggestions?

--
Cyrus

Date: Tue, 03 Aug 1999 10:50:15 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions Working Group <[email-masked]>
Subject: [VIEW] Dynamic vs static
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

Hi folks,
At the Oslo meeting we had discussions about whether the VIEW extenions
should be dynamic or static with respect to message changing position in a
view. This issue was not fully resolved and so I'm kicking off some list
discussion about it.

Right now the VIEW extension requires dynamic updates (via responses) from
the server for:

a) new messages arriving in the mailbox
b) messages being expunged from the mailbox
c) messages moving into or out of a view due to a change in some message
state (right now only flags, but this may include annotations once that's
available)

Of these I think (a) and (b) MUST be present. We were all agreed in Oslo
that (a) matches user expectations - i.e. the arrival of any new message
that matches the current view criteria MUST result in that message
appearing in the client's view.

(b) is merely an extenion of the current expunge mechanism where messages
have to be removed from the clients cache when an expunge occurs.

(c) is really the issue of this debate. Should changes to a message's state
be notified to the client via untagged responses?

One argument against a dynamic view is to consider the case of a view set
to display only unseen messages. As soon as a user tries to read such a
message the \Seen flag is implicitly set (of course the client could use
the .PEEK FETCH variant to stop this). At that point in a dynamic view, the
message would be removed from the view via an untagged response, and
suddenly the message the user is trying to read is now outside of the
client's view! I think this is probably counter to user expectations.

One solution to this is to say views are static with respect to changes in
message state and to introduce a new 'VIEW UPDATE' command that the client
can issue to 'refresh' its current view to the actually message state. This
way the client is in control of view updates.

What do people think? Should VIEW be fully dynamic (i.e. (a), (b) & (c)
produce untagged responses), or should it be static (i.e. (a) and (b) are
still dynamic, but (c) does not generate untagged responses)?

--
Cyrus