Subject: re: Stalled?
From: Mark Crispin <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: [email-masked]
Date: Thu, 30 May 2002 09:42:40 -0700 (PDT)
List-Id: <ietf-imapext.imc.org>

On Thu, 30 May 2002 11:07:09 -0500, Pete Resnick wrote:
> We seem to be stalled. Would the document editors please tell their status?

IMAP base document...well, everybody should know what's going on there.

MULTIAPPEND is awaiting IESG action.

Just over two months ago, I posted new versions of THREAD and SORT.  There
hasn't been much discussion on the "ITEM FOR DISCUSSION" in these two
documents.

Date: Thu, 30 May 2002 12:37:17 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Stalled?
Sender: [email-masked]

Hi,

--On Thursday, May 30, 2002 11:07 AM -0500 Pete Resnick 
<[email-masked]> wrote:

| We seem to be stalled. Would the document editors please tell their
| status?

ANNOTATE - there are two outstanding issues that I have listed:

COPY and .priv annotations
  Should the copy command copy both .priv and .shared annotations all the 
time? There was a thread on this back in March after -04 came out.

Distinguish between system flags andc keywords in entry names
  Current draft uses e.g. '/message/flags/recent' for flag names, but in 
IMAP the flag name is actuall '\Recent'. Should the '\' prefix appear in 
the annotation entry name or should there be separate entries for system 
flags vs keywords, e.g. '/message/flags/system/recent' or 
'/message/flags/keyword/$mdnsent'? This was discussed at the BAR BOF (I was 
not present) and relayed to me second-hand.

If there are other issues with the current -04 draft please post to the 
list.

-- 
Cyrus Daboo

Date: Thu, 30 May 2002 12:35:05 -0400
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATE/ANNOTATEMORE vendor tokens
Sender: [email-masked]

Hi,

--On Thursday, May 16, 2002 10:03 AM -0400 Ken Murchison <[email-masked]> 
wrote:

| I'm working on a limited scope, special purpose ANNOTATEMORE
| implementation for CMU and I have a question about the naming of vendor
| tokens.  Assuming that a vendor might have a handful of tokens, should
| they be grouped in their own hierarchy, ie:
|
| /mailbox/{mailbox-name}/vendor/cyrus/entry1
| /mailbox/{mailbox-name}/vendor/cyrus/entry2
| /mailbox/{mailbox-name}/vendor/cyrus/entry3
|
| or, should they all be at the same level, ie:
|
| /mailbox/{mailbox-name}/vendor/cyrus.entry1
| /mailbox/{mailbox-name}/vendor/cyrus.entry2
| /mailbox/{mailbox-name}/vendor/cyrus.entry3

I suggest you have vendor/<vendor-name>/<product-name>/<entries>

If the options are global to all products, then you could just skip that 
level, but there would be a potential name clash if you had an entry name 
that later was used as a product name. Perhaps setting the product name to 
'Global' for those would be better.

Ultimately it is up to each vendor as to how to use their own vendor space, 
but from experience I think what I suggest above is a good way to go. I 
could add that as a suggested syntax for the vendor space.

I believe ACAP had the vendor token be the vendor name and product name, 
but that means a vendor has to register separately for each product, as 
opposed to registering a single vendor name and then being free to add 
product names at the next level down in the entry namespace.

-- 
Cyrus Daboo

Date: Thu, 30 May 2002 10:20:29 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Stalled?
Sender: [email-masked]

Pete Resnick wrote:

> We seem to be stalled. Would the document editors please tell their status?

I've sent an update to Conditional Store recently. One or two revisions and it
should be ready to Last Call. Please comment on the draft.

I will send an update to the ACL2 draft in two-three weeks, after I submit two
more drafts (one IMAP related, one not).

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Thu, 30 May 2002 11:07:09 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Stalled?
Sender: [email-masked]

We seem to be stalled. Would the document editors please tell their status?

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

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-melnikov-imap-condstore-07.txt
Date: Tue, 21 May 2002 07:30:19 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-melnikov-imap-condstore-07.txt
	Pages		: 
	Date		: 20-May-02
	
Often, multiple IMAP clients need to coordinate changes to a common
IMAP mailbox.  Examples include different clients for the same user,
and multiple users accessing shared mailboxes. These clients
need a mechanism to synchronize state changes for messages within the
mailbox. They must be able to guarantee that only one client can change
message state (e.g., message flags or annotations) at any time.  An
example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-imap-condstore-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-melnikov-imap-condstore-07.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-melnikov-imap-condstore-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-melnikov-imap-condstore-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-melnikov-imap-condstore-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Fri, 17 May 2002 10:05:17 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: IMAP Extensions WG <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, Randall Gellens <[email-masked]>, Rob Siemborski <[email-masked]>
Subject: FETCH ANNOTATION / GETANNOTATION response data
Sender: [email-masked]

I've read through both drafts several times, and it appears to me that
the example responses and the grammar for those responses do not match. 
The examples have parenthesis around each entry-att as well as the
complete list, where the grammar only shows parenthesis around the list.

Am I correct in my assessment that there is a discrepancy here, and if
so, which response form is correct?

entry-att = entry SP "(" att-value *(SP att-value) ")"

OR

entry-att = "(" entry SP "(" att-value *(SP att-value) ")" ")"

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

Date: Thu, 16 May 2002 10:03:25 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE/ANNOTATEMORE vendor tokens
Sender: [email-masked]

Cyrus,

I'm working on a limited scope, special purpose ANNOTATEMORE
implementation for CMU and I have a question about the naming of vendor
tokens.  Assuming that a vendor might have a handful of tokens, should
they be grouped in their own hierarchy, ie:

/mailbox/{mailbox-name}/vendor/cyrus/entry1
/mailbox/{mailbox-name}/vendor/cyrus/entry2
/mailbox/{mailbox-name}/vendor/cyrus/entry3

or, should they all be at the same level, ie:

/mailbox/{mailbox-name}/vendor/cyrus.entry1
/mailbox/{mailbox-name}/vendor/cyrus.entry2
/mailbox/{mailbox-name}/vendor/cyrus.entry3

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

Date: Thu, 09 May 2002 05:25:00 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Neystadt, John" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

"Neystadt, John" wrote:

> > What about an extension to STATUS that returns the number of
> messages having a
> > particular flag. This definitely has applicability beyond VPIM.
> > For example, Cyrus was asking for the way of returning number of
> messages having
> > \Deleted flag and the total size of the deleted messages. This can
> be used
> > together with QUOTA extension to discover how much space can be
> recovered if the
> > user expunge a mailbox.
>
> Ok, to summarize: What you propose is to add new $Important flag and
> provide generic way to count messages marked by certain flag using
> STATUS.
>
> I like this idea and I will incorporate this in next revision of the
> draft.
>
> What about combinations how to obtain counter for both Unseen and
> Important messages? I see two options:
> - introduce boolean syntax in this command (i.e. \Unseen AND NOT
> $Important)
> - use pre-defined shortcuts for few well known combinations like
> current draft proposes (i.e. Unseen-Important)
>
> First way is certainly more generic, but also very complicate both in
> syntax and for server implementations to optimize for. So I would
> still prefer the second...?

For now I would rather do the second, as I am not too eager to spend
time on adding extended parser to STATUS. I don't think a client will be
willing to know, for example, how many messages in a mailbox with both
\Answered and \Deleted flags set.

Alexey

From: "Neystadt, John" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Date: Sun, 5 May 2002 10:53:40 +0300 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F409.F862EBC0
Content-Type: text/plain;
	charset="koi8-r"

> What about an extension to STATUS that returns the number of 
> messages having a
> particular flag. This definitely has applicability beyond VPIM.
> For example, Cyrus was asking for the way of returning number 
> of messages having
> \Deleted flag and the total size of the deleted messages. 
> This can be used
> together with QUOTA extension to discover how much space can 
> be recovered if the
> user expunge a mailbox.

Ok, to summarize: What you propose is to add new $Important flag and provide
generic way to count messages marked by certain flag using STATUS.

I like this idea and I will incorporate this in next revision of the draft. 

What about combinations how to obtain counter for both Unseen and Important
messages? I see two options:
- introduce boolean syntax in this command (i.e. \Unseen AND NOT $Important)
- use pre-defined shortcuts for few well known combinations like current
draft proposes (i.e. Unseen-Important)

First way is certainly more generic, but also very complicate both in syntax
and for server implementations to optimize for. So I would still prefer the
second...?

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

------_=_NextPart_001_01C1F409.F862EBC0
Content-Type: text/html;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dkoi8-r">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [VPIM] Re: I-D =
ACTION:draft-neystadt-imap-status-counters-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; What about an extension to STATUS that returns =
the number of </FONT>
<BR><FONT SIZE=3D2>&gt; messages having a</FONT>
<BR><FONT SIZE=3D2>&gt; particular flag. This definitely has =
applicability beyond VPIM.</FONT>
<BR><FONT SIZE=3D2>&gt; For example, Cyrus was asking for the way of =
returning number </FONT>
<BR><FONT SIZE=3D2>&gt; of messages having</FONT>
<BR><FONT SIZE=3D2>&gt; \Deleted flag and the total size of the deleted =
messages. </FONT>
<BR><FONT SIZE=3D2>&gt; This can be used</FONT>
<BR><FONT SIZE=3D2>&gt; together with QUOTA extension to discover how =
much space can </FONT>
<BR><FONT SIZE=3D2>&gt; be recovered if the</FONT>
<BR><FONT SIZE=3D2>&gt; user expunge a mailbox.</FONT>
</P>

<P><FONT SIZE=3D2>Ok, to summarize: What you propose is to add new =
$Important flag and provide generic way to count messages marked by =
certain flag using STATUS.</FONT></P>

<P><FONT SIZE=3D2>I like this idea and I will incorporate this in next =
revision of the draft. </FONT>
</P>

<P><FONT SIZE=3D2>What about combinations how to obtain counter for =
both Unseen and Important messages? I see two options:</FONT>
<BR><FONT SIZE=3D2>- introduce boolean syntax in this command (i.e. =
\Unseen AND NOT $Important)</FONT>
<BR><FONT SIZE=3D2>- use pre-defined shortcuts for few well known =
combinations like current draft proposes (i.e. Unseen-Important)</FONT>
</P>

<P><FONT SIZE=3D2>First way is certainly more generic, but also very =
complicate both in syntax and for server implementations to optimize =
for. So I would still prefer the second...?</FONT></P>

<P><FONT SIZE=3D2>John Neystadt</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.neystadt.org/john/" =
TARGET=3D"_blank">http://www.neystadt.org/john/</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F409.F862EBC0--

From: "Neystadt, John" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Date: Sun, 5 May 2002 10:02:18 +0300 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F402.CB401110
Content-Type: text/plain;
	charset="koi8-r"

> > I think your proposal is very good for Unseen and may be 
> Important (new flag
> > or reuse \Flagged). BTW is \Flagged semantics is really 
> "importance". If I
> > make my server (by Sieve or other mechanism) turn \Flagged 
> on all messages
> > with "Importance: High" header, would that be ok.
> 
> What about "X-Priority: 1 (Highest)" and "Priority: HIGH" 
> headers that are in
> use by the MUA today?

Uh-hu :( You right. My current proposal handles this by "not a client's
problem" way. Namely it leaves to the server disicion of what is "Important"
and what is not. A clever and interoperable server will mark message as
"Important" according to "Importance:" and those ugly de-facto standard
headers.

If however we shift towards search expressions in status, then client will
have to specify all these headers in the command.

Actually both of these solutions are ugly, any other ideas on how to solve
this?

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

------_=_NextPart_001_01C1F402.CB401110
Content-Type: text/html;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dkoi8-r">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: I-D =
ACTION:draft-neystadt-imap-status-counters-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; &gt; I think your proposal is very good for =
Unseen and may be </FONT>
<BR><FONT SIZE=3D2>&gt; Important (new flag</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; or reuse \Flagged). BTW is \Flagged =
semantics is really </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;importance&quot;. If I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; make my server (by Sieve or other =
mechanism) turn \Flagged </FONT>
<BR><FONT SIZE=3D2>&gt; on all messages</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; with &quot;Importance: High&quot; header, =
would that be ok.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What about &quot;X-Priority: 1 (Highest)&quot; =
and &quot;Priority: HIGH&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; headers that are in</FONT>
<BR><FONT SIZE=3D2>&gt; use by the MUA today?</FONT>
</P>

<P><FONT SIZE=3D2>Uh-hu :( You right. My current proposal handles this =
by &quot;not a client's problem&quot; way. Namely it leaves to the =
server disicion of what is &quot;Important&quot; and what is not. A =
clever and interoperable server will mark message as =
&quot;Important&quot; according to &quot;Importance:&quot; and those =
ugly de-facto standard headers.</FONT></P>

<P><FONT SIZE=3D2>If however we shift towards search expressions in =
status, then client will have to specify all these headers in the =
command.</FONT></P>

<P><FONT SIZE=3D2>Actually both of these solutions are ugly, any other =
ideas on how to solve this?</FONT>
</P>

<P><FONT SIZE=3D2>John Neystadt</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.neystadt.org/john/" =
TARGET=3D"_blank">http://www.neystadt.org/john/</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F402.CB401110--

Date: Fri, 03 May 2002 07:37:16 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Arnt Gulbrandsen <[email-masked]>
CC: "Erev, Ari" <[email-masked]>, "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> > Can you suggest a better/quicker way to get this information?
>
> Yes, but you might still decide that a new extension is the best option.
> I too think it might be. The current draft doesn't argue its case very
> well.

One more proposal: If your mailstore supports SIEVE on injection and IMAPFLAGS
SIEVE extension ;-), you can write a SIEVE script that will mark all messages
containing "Important: high" with $Important keyword. Then IMAP client can open a
mailbox and do a search on $Important keyword, that for many servers will be
faster that header search. Even if the messaging server doesn't support SIEVE, you
can have a client that watches a mailbox and does SEARCHes for required content:
 tag SEARCH <n>:* HEADER Importance low HEADER Message-Context text-message

Pay attention that this SEARCH is only performed on new messages (n is the last
processed message). Several servers will be optimized for this type of search.
Then the client can mark all found messages as $Important.

Arnt Gulbrandsen wrote:

> > Note that STATUS has always been designed to provide this "type" of
> > information (message counters) -
>
> Agreed.

> > just not in the detailed manner it is now
> > required when clients need to get the counters "per message-context". So, an
> > enhancement to STATUS seems to me a logical way to achieve this.
>
> If so, it must not be VPIM-specific. Try to tweak the extension so that
> it's useful for other clients, and provide a couple of examples showing
> how non-VPIM clients might use it.

Mark Crispin wrote:

> Also, the more minimal a VPIM extension to IMAP is, the more likely it is
> that you'll get it generally implemented.  For example, if a VPIM
> extension requires only about 15 minutes of programming work, I'm likely
> to do it in my server, just to preclude having to answer an email require
> to do it.  If, on the other hand, an extension requires many hours of
> work, it's much less likely to happen without specific value to us.

What about an extension to STATUS that returns the number of messages having a
particular flag. This definitely has applicability beyond VPIM.
For example, Cyrus was asking for the way of returning number of messages having
\Deleted flag and the total size of the deleted messages. This can be used
together with QUOTA extension to discover how much space can be recovered if the
user expunge a mailbox.

As far as our server is concerned, we already count all messages that don't have
\Seen flag on STATUS command. Adding other flags would be trivial for us.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

I speak for myself only, not for my employer.
__________________________________________

Date: Fri, 03 May 2002 07:34:18 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Vaudreuil, Greg M (Greg)" <[email-masked]>
CC: Mark Crispin <[email-masked]>, John Neystadt <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

"Vaudreuil, Greg M (Greg)" wrote:

> The importance is a sender-indicated message attribute, not a recipient
> indication of a particular level of interest or importance they may wish to
> recall between sessions. We need a flag that is standardized by convention
> between a message deposit process that can set this flag and the many
> different clients that would expect the flag to be there if a message is
> tagged as important.
>
> I think use of a new flag makes plenty of sense for \important.  I don't
> think a flag per message context makes much sense tho.

If you decide to introduce a new flag, don't use \important, as the leading "\"
has special semantic in IMAP and server that don't support it will most likely
refuse to store it. I suggest you use $Important instead. This way you will be
able to store it on a IMAP server that allows for storing of arbitrary keywords.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

I speak for myself only, not for my employer.
__________________________________________

Date: Fri, 03 May 2002 06:54:56 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: "Vaudreuil, Greg M (Greg)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Sender: [email-masked]

Mark Crispin wrote:

> On Sun, 28 Apr 2002 20:54:15 -0600, Vaudreuil, Greg M (Greg) wrote:
> > Is there any objection to a new flag with explicit semantics of importance?
>
> I think that you will find a very strong lack of enthusiasm for adding a flag
> which duplicates the existing functionality of \Flagged and/or SEARCH HEADER.

I agree in general but not in this particular case.
I use Netscape Communicator 4.79 as a mail client. It allows to change priority
of the message (i.e. overwrite X-Priority header) and I use this feature quite a
bit. Unfortunately Netscape stores this value in the local mailbox cache and this
change is lost when I synchronize a mailbox. I would love to see the mail client
being able to store this on a IMAP server. [Netscape people, are you listening
;-)?]

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

I speak for myself only, not for my employer.
__________________________________________

Date: Fri, 03 May 2002 06:38:16 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: John Neystadt <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

Let me through couple more rocks ;-):

John Neystadt wrote:

> I think your proposal is very good for Unseen and may be Important (new flag
> or reuse \Flagged). BTW is \Flagged semantics is really "importance". If I
> make my server (by Sieve or other mechanism) turn \Flagged on all messages
> with "Importance: High" header, would that be ok.

What about "X-Priority: 1 (Highest)" and "Priority: HIGH" headers that are in
use by the MUA today?

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

I speak for myself only, not for my employer.
__________________________________________

To: "Erev, Ari" <[email-masked]>
Cc: "'Arnt Gulbrandsen'" <[email-masked]>, "Neystadt, John" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
From: Simon Josefsson <[email-masked]>
Date: Thu, 02 May 2002 19:26:28 +0200
Lines: 28
Sender: [email-masked]

"Erev, Ari" <[email-masked]> writes:

> According to your example, I believe the client can get the counters
> information this way (12 round trips):
>
> tag SEARCH UNSEEN HEADER Importance high HEADER Message-Context
> voice-message
> tag SEARCH    SEEN HEADER Importance high HEADER Message-Context
> voice-message
> tag SEARCH UNSEEN HEADER Importance low HEADER Message-Context voice-message
> tag SEARCH     SEEN HEADER Importance low  HEADER Message-Context
> voice-message
>
> tag SEARCH UNSEEN HEADER Importance high HEADER Message-Context text-message
> tag SEARCH    SEEN HEADER Importance high HEADER Message-Context
> text-message
> tag SEARCH UNSEEN HEADER Importance low HEADER Message-Context text-message
> tag SEARCH    SEEN HEADER Importance low HEADER Message-Context text-message
>
> tag SEARCH UNSEEN HEADER Importance high HEADER Message-Context fax-message
> tag SEARCH    SEEN HEADER Importance high HEADER Message-Context fax-message
> tag SEARCH UNSEEN HEADER Importance low HEADER Message-Context fax-message
> tag SEARCH    SEEN HEADER Importance low HEADER Message-Context fax-message
>
> Can you suggest a better/quicker way to get this information? 

I see only one round trip.  Send all commands in one operation and
then wait for the responses.

Date: Thu, 2 May 2002 11:36:42 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Erev, Ari" <[email-masked]>
Cc: "Neystadt, John" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Sender: [email-masked]

"Erev, Ari" <[email-masked]>
> Let's assume a mailbox which has (only) 3 types of messages
> (message-contexts). 
> According to your example, I believe the client can get the counters
> information this way (12 round trips):

That's one scary-looking series of commands. However, it translates into
this equally scary prompt:

	Hello, this is your voice-mail system. You have 4 new important
	voice messages, 12 old important voice messages, 3 unimportant new
	voice messages, 4 unimportant old voice messages, 4 new important
	text messages, 12 old important text messages, 3 unimportant new
	text messages, 4 unimportant old text messages, 4 new important
	fax messages, 12 old important fax messages, 3 unimportant new fax
	messages and 4 unimportant old fax messages. Press 1 to...

Performancewise, this does not seem to be a problem. One search must
complete before the start of the sentence, and all 12 searches before the
word 'and'. And that prompt is a great April fool's joke ;)

Seriously, if the prompt contains n numbers, you should need about n
SEARCH commands.  If, as you say, the server selects to optimize for this
task, it should require as little processor time as e.g. SEARCH UNSEEN
does.

> Can you suggest a better/quicker way to get this information?

Yes, but you might still decide that a new extension is the best option.
I too think it might be. The current draft doesn't argue its case very
well.

As I see it, using SEARCH optimally, using the ANNOTATE extension, or a
combination of the two are all worth looking into.

ANNOTATE is a larger extension than STATUS-COUNTERS, but it looks to have
wide support, so that it'll be implemented by many servers. The message
context and importance you're using sound like annotations to my ears, so
ANNOTATE might be a good fit.

> Note that STATUS has always been designed to provide this "type" of
> information (message counters) - 

Agreed.

> just not in the detailed manner it is now
> required when clients need to get the counters "per message-context". So, an
> enhancement to STATUS seems to me a logical way to achieve this.

If so, it must not be VPIM-specific. Try to tweak the extension so that
it's useful for other clients, and provide a couple of examples showing
how non-VPIM clients might use it.

--Arnt

From: "Erev, Ari" <[email-masked]>
To: "'Arnt Gulbrandsen'" <[email-masked]>, "Neystadt, John" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Date: Thu, 2 May 2002 11:11:18 +0300 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F1B0.F00FF400
Content-Type: text/plain;
	charset="iso-8859-1"

Arnt,

I think everybody (including John) agrees that _FUNCTIONALLY_ the current
IMAP provides what is required for a client to get the 'counters'
information - whether it is by using FETCH or SEARCH.

The main point in John proposal is not about functionality - it is about
performance (and possibly scalability).
It allow the counters information (which is required very early in the
session) to be available to the client with minimal round-trips and it
allows the server to optimize for this task - if it selects to do so.

Let's assume a mailbox which has (only) 3 types of messages
(message-contexts). 
According to your example, I believe the client can get the counters
information this way (12 round trips):

tag SEARCH UNSEEN HEADER Importance high HEADER Message-Context
voice-message
tag SEARCH    SEEN HEADER Importance high HEADER Message-Context
voice-message
tag SEARCH UNSEEN HEADER Importance low HEADER Message-Context voice-message
tag SEARCH     SEEN HEADER Importance low  HEADER Message-Context
voice-message

tag SEARCH UNSEEN HEADER Importance high HEADER Message-Context text-message
tag SEARCH    SEEN HEADER Importance high HEADER Message-Context
text-message
tag SEARCH UNSEEN HEADER Importance low HEADER Message-Context text-message
tag SEARCH    SEEN HEADER Importance low HEADER Message-Context text-message

tag SEARCH UNSEEN HEADER Importance high HEADER Message-Context fax-message
tag SEARCH    SEEN HEADER Importance high HEADER Message-Context fax-message
tag SEARCH UNSEEN HEADER Importance low HEADER Message-Context fax-message
tag SEARCH    SEEN HEADER Importance low HEADER Message-Context fax-message

Can you suggest a better/quicker way to get this information? 

Maybe there is an option to skip the last group of 4 by computing it somehow
but anyway - it is obvious that with more "Message-Contexts" this scenario
gets longer and longer - which does not seem to be a good way to achieve
scalability AND  short response time - which is the original requirement!

And so, John proposal suggests to get the required information in ONE
command (STATUS). 
This provides for short response time, and also allows for servers that want
to optimize for this case to do so in whichever way they choose to do so.

Note that STATUS has always been designed to provide this "type" of
information (message counters) - just not in the detailed manner it is now
required when clients need to get the counters "per message-context". So, an
enhancement to STATUS seems to me a logical way to achieve this.

Ari Erev

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]]
Sent: Wednesday, May 01, 2002 10:43 PM
To: Neystadt, John
Cc: [email-masked]'; [email-masked]; [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.
txt

"Neystadt, John" <[email-masked]>
> My extension does not mandate VPIM clients not to work with servers that
> does not implement it. Section 8.2 of the draft says:
...

Why do you specify using FETCH? SEARCH seems better:

	a SELECT mailbox
	b SEARCH UNSEEN
	c SEARCH HEADER Importance: high
	d SEARCH HEADER Message-Context: blah

--Arnt

------_=_NextPart_001_01C1F1B0.F00FF400
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [VPIM] Re: I-D =
ACTION:draft-neystadt-imap-status-counters-00. txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Arnt,</FONT>
</P>

<P><FONT SIZE=3D2>I think everybody (including John) agrees that =
_FUNCTIONALLY_ the current IMAP provides what is required for a client =
to get the 'counters' information - whether it is by using FETCH or =
SEARCH.</FONT></P>

<P><FONT SIZE=3D2>The main point in John proposal is not about =
functionality - it is about performance (and possibly =
scalability).</FONT>
<BR><FONT SIZE=3D2>It allow the counters information (which is required =
very early in the session) to be available to the client with minimal =
round-trips and it allows the server to optimize for this task - if it =
selects to do so.</FONT></P>

<P><FONT SIZE=3D2>Let's assume a mailbox which has (only) 3 types of =
messages (message-contexts). </FONT>
<BR><FONT SIZE=3D2>According to your example, I believe the client can =
get the counters information this way (12 round trips):</FONT>
</P>

<P><FONT SIZE=3D2>tag SEARCH UNSEEN HEADER Importance high HEADER =
Message-Context voice-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH&nbsp;&nbsp;&nbsp; SEEN HEADER Importance =
high HEADER Message-Context voice-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH UNSEEN HEADER Importance low HEADER =
Message-Context voice-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH&nbsp;&nbsp;&nbsp;&nbsp; SEEN HEADER =
Importance low&nbsp; HEADER Message-Context voice-message</FONT>
</P>

<P><FONT SIZE=3D2>tag SEARCH UNSEEN HEADER Importance high HEADER =
Message-Context text-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH&nbsp;&nbsp;&nbsp; SEEN HEADER Importance =
high HEADER Message-Context text-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH UNSEEN HEADER Importance low HEADER =
Message-Context text-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH&nbsp;&nbsp;&nbsp; SEEN HEADER Importance =
low HEADER Message-Context text-message</FONT>
</P>

<P><FONT SIZE=3D2>tag SEARCH UNSEEN HEADER Importance high HEADER =
Message-Context fax-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH&nbsp;&nbsp;&nbsp; SEEN HEADER Importance =
high HEADER Message-Context fax-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH UNSEEN HEADER Importance low HEADER =
Message-Context fax-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH&nbsp;&nbsp;&nbsp; SEEN HEADER Importance =
low HEADER Message-Context fax-message</FONT>
</P>

<P><FONT SIZE=3D2>Can you suggest a better/quicker way to get this =
information? </FONT>
</P>

<P><FONT SIZE=3D2>Maybe there is an option to skip the last group of 4 =
by computing it somehow but anyway - it is obvious that with more =
&quot;Message-Contexts&quot; this scenario gets longer and longer - =
which does not seem to be a good way to achieve scalability AND&nbsp; =
short response time - which is the original requirement!</FONT></P>

<P><FONT SIZE=3D2>And so, John proposal suggests to get the required =
information in ONE command (STATUS). </FONT>
<BR><FONT SIZE=3D2>This provides for short response time, and also =
allows for servers that want to optimize for this case to do so in =
whichever way they choose to do so.</FONT></P>

<P><FONT SIZE=3D2>Note that STATUS has always been designed to provide =
this &quot;type&quot; of information (message counters) - just not in =
the detailed manner it is now required when clients need to get the =
counters &quot;per message-context&quot;. So, an enhancement to STATUS =
seems to me a logical way to achieve this.</FONT></P>

<P><FONT SIZE=3D2>Ari Erev</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Arnt Gulbrandsen [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, May 01, 2002 10:43 PM</FONT>
<BR><FONT SIZE=3D2>To: Neystadt, John</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]'; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [VPIM] Re: I-D =
ACTION:draft-neystadt-imap-status-counters-00. txt</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;Neystadt, John&quot; =
&lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; My extension does not mandate VPIM clients not =
to work with servers that</FONT>
<BR><FONT SIZE=3D2>&gt; does not implement it. Section 8.2 of the draft =
says:</FONT>
<BR><FONT SIZE=3D2>...</FONT>
</P>

<P><FONT SIZE=3D2>Why do you specify using FETCH? SEARCH seems =
better:</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a SELECT =
mailbox</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>b SEARCH =
UNSEEN</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>c SEARCH =
HEADER Importance: high</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>d SEARCH =
HEADER Message-Context: blah</FONT>
</P>

<P><FONT SIZE=3D2>--Arnt</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F1B0.F00FF400--

Date: Wed, 1 May 2002 21:43:18 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Neystadt, John" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Sender: [email-masked]

"Neystadt, John" <[email-masked]>
> My extension does not mandate VPIM clients not to work with servers that
> does not implement it. Section 8.2 of the draft says:
...

Why do you specify using FETCH? SEARCH seems better:

	a SELECT mailbox
	b SEARCH UNSEEN
	c SEARCH HEADER Importance: high
	d SEARCH HEADER Message-Context: blah

--Arnt

Date: Wed, 1 May 2002 09:59:20 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
To: "Neystadt, John" <[email-masked]>
cc: [email-masked], [email-masked]
Sender: [email-masked]

On Wed, 1 May 2002 19:05:47 +0300 , Neystadt, John wrote:
> This is what the MUAs do today. Basic problem with that is to calculate
> message counters per message-context (MIME header) MUA must download message
> headers of whole mailbox.

As I pointed out before, you do not need to do this.

You can do searches and partial header fetches to reduce greatly the amount of
downloading you must do.  You can also use keyword flags to avoid using the
headers at all.

Please to leverage existing mechanisms as much as possible rather than create
new mechanisms.  This includes design of extensions.  You're much more likely
to get extensions widely deployed if those extensions are built on top of
existing mechanisms, particularly if the extension is as narrowly focused as
this.

From: "Neystadt, John" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Date: Wed, 1 May 2002 19:11:52 +0300 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F12A.E7B517D0
Content-Type: text/plain;
	charset="iso-8859-1"

> I have to agree with Mark's sentiment expressed below.  The 
> whole point of
> using IMAP for Pink Lemonade is there is a large existing 
> base of servers
> and developers.  If we set out to build "VPIM-IMAP", we might 
> as well call
> it son/daughter of IMAP and be done with it.

First of all, some of us develop products who do enhancements for Pink
Lemonde. For example SNAP protocol is such an enhancement that requires
modification of the servers as well.

My extension does not mandate VPIM clients not to work with servers that
does not implement it. Section 8.2 of the draft says:

> 8.2 Client Issues 
>     
>    Is imap server implementation does not support this command, its 
>    logic can be achieved by the following algorithm: 
>     
>    For the given mailbox do: 
>     
>       1. a SELECT mailbox 
>       2. b FETCH 1:* BODY[HEADER (Importance Message-Context)] 
>       3. Calculate the counters from FETCH responses. 

Servers that will not implement this, will burn more CPU and have worse
response time, but other than that that will work.

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

------_=_NextPart_001_01C1F12A.E7B517D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [VPIM] Re: I-D =
ACTION:draft-neystadt-imap-status-counters-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; I have to agree with Mark's sentiment expressed =
below.&nbsp; The </FONT>
<BR><FONT SIZE=3D2>&gt; whole point of</FONT>
<BR><FONT SIZE=3D2>&gt; using IMAP for Pink Lemonade is there is a =
large existing </FONT>
<BR><FONT SIZE=3D2>&gt; base of servers</FONT>
<BR><FONT SIZE=3D2>&gt; and developers.&nbsp; If we set out to build =
&quot;VPIM-IMAP&quot;, we might </FONT>
<BR><FONT SIZE=3D2>&gt; as well call</FONT>
<BR><FONT SIZE=3D2>&gt; it son/daughter of IMAP and be done with =
it.</FONT>
</P>

<P><FONT SIZE=3D2>First of all, some of us develop products who do =
enhancements for Pink Lemonde. For example SNAP protocol is such an =
enhancement that requires modification of the servers as =
well.</FONT></P>

<P><FONT SIZE=3D2>My extension does not mandate VPIM clients not to =
work with servers that does not implement it. Section 8.2 of the draft =
says:</FONT></P>

<P><FONT SIZE=3D2>&gt; 8.2 Client Issues </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Is imap server implementation =
does not support this command, its </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; logic can be achieved by the =
following algorithm: </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; For the given mailbox do: =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. a SELECT =
mailbox </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. b FETCH =
1:* BODY[HEADER (Importance Message-Context)] </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. =
Calculate the counters from FETCH responses. </FONT>
</P>

<P><FONT SIZE=3D2>Servers that will not implement this, will burn more =
CPU and have worse response time, but other than that that will =
work.</FONT></P>

<P><FONT SIZE=3D2>John Neystadt</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.neystadt.org/john/" =
TARGET=3D"_blank">http://www.neystadt.org/john/</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F12A.E7B517D0--

From: "Neystadt, John" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Date: Wed, 1 May 2002 19:05:47 +0300 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F12A.0E2B6550
Content-Type: text/plain;
	charset="iso-8859-1"

> Mark's suggestion of having a 
> simple indicator
> to go look at the mailbox in more detail is reasonable for this
> application. 

This is what the MUAs do today. Basic problem with that is to calculate
message counters per message-context (MIME header) MUA must download message
headers of whole mailbox. This can take a while on big mailboxes and
represents considerable overhead for servers.

The idea of status-counters is to have server cache this information and be
able to provide it to MUA in fraction of time and overhead. 

Think for example about telephony MUA, that announces to subscriber "You
have 301 new email messages". This must be down in less than 100ms after
users picks up the phone and not after few secs as it must be now (after
downloading and processing all message headers).

> If you need to do more than that then look to do 
> it outside of
> IMAP - I thought SNAP was supposed to provide a way to get the same
> information as you are proposing adding to STATUS. Why duplicate SNAP
> inside of IMAP? Just let clients interested in that info use 
> SNAP instead.

I rather would say they complement each other. SNAP is away for subscriber
to get notifications when he is off-line. They can be sent to PUA, though
Unix message service or thorugh SMS. When subscriber runs his mail program
he wants to see counters which are most up-to-date. 

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

------_=_NextPart_001_01C1F12A.0E2B6550
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: I-D =
ACTION:draft-neystadt-imap-status-counters-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; Mark's suggestion of having a </FONT>
<BR><FONT SIZE=3D2>&gt; simple indicator</FONT>
<BR><FONT SIZE=3D2>&gt; to go look at the mailbox in more detail is =
reasonable for this</FONT>
<BR><FONT SIZE=3D2>&gt; application. </FONT>
</P>

<P><FONT SIZE=3D2>This is what the MUAs do today. Basic problem with =
that is to calculate message counters per message-context (MIME header) =
MUA must download message headers of whole mailbox. This can take a =
while on big mailboxes and represents considerable overhead for =
servers.</FONT></P>

<P><FONT SIZE=3D2>The idea of status-counters is to have server cache =
this information and be able to provide it to MUA in fraction of time =
and overhead. </FONT></P>

<P><FONT SIZE=3D2>Think for example about telephony MUA, that announces =
to subscriber &quot;You have 301 new email messages&quot;. This must be =
down in less than 100ms after users picks up the phone and not after =
few secs as it must be now (after downloading and processing all =
message headers).</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; If you need to do more than that then look to do =
</FONT>
<BR><FONT SIZE=3D2>&gt; it outside of</FONT>
<BR><FONT SIZE=3D2>&gt; IMAP - I thought SNAP was supposed to provide a =
way to get the same</FONT>
<BR><FONT SIZE=3D2>&gt; information as you are proposing adding to =
STATUS. Why duplicate SNAP</FONT>
<BR><FONT SIZE=3D2>&gt; inside of IMAP? Just let clients interested in =
that info use </FONT>
<BR><FONT SIZE=3D2>&gt; SNAP instead.</FONT>
</P>

<P><FONT SIZE=3D2>I rather would say they complement each other. SNAP =
is away for subscriber to get notifications when he is off-line. They =
can be sent to PUA, though Unix message service or thorugh SMS. When =
subscriber runs his mail program he wants to see counters which are =
most up-to-date. </FONT></P>

<P><FONT SIZE=3D2>John Neystadt</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.neystadt.org/john/" =
TARGET=3D"_blank">http://www.neystadt.org/john/</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F12A.0E2B6550--

Date: Thu, 30 May 2002 09:42:40 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Stalled?
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Thu, 30 May 2002 11:07:09 -0500, Pete Resnick wrote:
> We seem to be stalled. Would the document editors please tell their status?

IMAP base document...well, everybody should know what's going on there.

MULTIAPPEND is awaiting IESG action.

Just over two months ago, I posted new versions of THREAD and SORT.  There
hasn't been much discussion on the "ITEM FOR DISCUSSION" in these two
documents.

Date: Thu, 30 May 2002 12:37:17 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Stalled?
Sender: [email-masked]

Hi,

--On Thursday, May 30, 2002 11:07 AM -0500 Pete Resnick 
<[email-masked]> wrote:

| We seem to be stalled. Would the document editors please tell their
| status?

ANNOTATE - there are two outstanding issues that I have listed:

COPY and .priv annotations
  Should the copy command copy both .priv and .shared annotations all the 
time? There was a thread on this back in March after -04 came out.

Distinguish between system flags andc keywords in entry names
  Current draft uses e.g. '/message/flags/recent' for flag names, but in 
IMAP the flag name is actuall '\Recent'. Should the '\' prefix appear in 
the annotation entry name or should there be separate entries for system 
flags vs keywords, e.g. '/message/flags/system/recent' or 
'/message/flags/keyword/$mdnsent'? This was discussed at the BAR BOF (I was 
not present) and relayed to me second-hand.

If there are other issues with the current -04 draft please post to the 
list.

-- 
Cyrus Daboo

Date: Thu, 30 May 2002 12:35:05 -0400
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATE/ANNOTATEMORE vendor tokens
Sender: [email-masked]

Hi,

--On Thursday, May 16, 2002 10:03 AM -0400 Ken Murchison <[email-masked]> 
wrote:

| I'm working on a limited scope, special purpose ANNOTATEMORE
| implementation for CMU and I have a question about the naming of vendor
| tokens.  Assuming that a vendor might have a handful of tokens, should
| they be grouped in their own hierarchy, ie:
|
| /mailbox/{mailbox-name}/vendor/cyrus/entry1
| /mailbox/{mailbox-name}/vendor/cyrus/entry2
| /mailbox/{mailbox-name}/vendor/cyrus/entry3
|
| or, should they all be at the same level, ie:
|
| /mailbox/{mailbox-name}/vendor/cyrus.entry1
| /mailbox/{mailbox-name}/vendor/cyrus.entry2
| /mailbox/{mailbox-name}/vendor/cyrus.entry3

I suggest you have vendor/<vendor-name>/<product-name>/<entries>

If the options are global to all products, then you could just skip that 
level, but there would be a potential name clash if you had an entry name 
that later was used as a product name. Perhaps setting the product name to 
'Global' for those would be better.

Ultimately it is up to each vendor as to how to use their own vendor space, 
but from experience I think what I suggest above is a good way to go. I 
could add that as a suggested syntax for the vendor space.

I believe ACAP had the vendor token be the vendor name and product name, 
but that means a vendor has to register separately for each product, as 
opposed to registering a single vendor name and then being free to add 
product names at the next level down in the entry namespace.

-- 
Cyrus Daboo

Date: Thu, 30 May 2002 10:20:29 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Stalled?
Sender: [email-masked]

Pete Resnick wrote:

> We seem to be stalled. Would the document editors please tell their status?

I've sent an update to Conditional Store recently. One or two revisions and it
should be ready to Last Call. Please comment on the draft.

I will send an update to the ACL2 draft in two-three weeks, after I submit two
more drafts (one IMAP related, one not).

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

Date: Thu, 30 May 2002 11:07:09 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Stalled?
Sender: [email-masked]

We seem to be stalled. Would the document editors please tell their status?

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

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-melnikov-imap-condstore-07.txt
Date: Tue, 21 May 2002 07:30:19 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-melnikov-imap-condstore-07.txt
	Pages		: 
	Date		: 20-May-02
	
Often, multiple IMAP clients need to coordinate changes to a common
IMAP mailbox.  Examples include different clients for the same user,
and multiple users accessing shared mailboxes. These clients
need a mechanism to synchronize state changes for messages within the
mailbox. They must be able to guarantee that only one client can change
message state (e.g., message flags or annotations) at any time.  An
example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-imap-condstore-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-melnikov-imap-condstore-07.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-melnikov-imap-condstore-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-melnikov-imap-condstore-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-melnikov-imap-condstore-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Fri, 17 May 2002 10:05:17 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: IMAP Extensions WG <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, Randall Gellens <[email-masked]>, Rob Siemborski <[email-masked]>
Subject: FETCH ANNOTATION / GETANNOTATION response data
Sender: [email-masked]

I've read through both drafts several times, and it appears to me that
the example responses and the grammar for those responses do not match. 
The examples have parenthesis around each entry-att as well as the
complete list, where the grammar only shows parenthesis around the list.

Am I correct in my assessment that there is a discrepancy here, and if
so, which response form is correct?

entry-att = entry SP "(" att-value *(SP att-value) ")"

OR

entry-att = "(" entry SP "(" att-value *(SP att-value) ")" ")"

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

Date: Thu, 16 May 2002 10:03:25 -0400
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE/ANNOTATEMORE vendor tokens
Sender: [email-masked]

Cyrus,

I'm working on a limited scope, special purpose ANNOTATEMORE
implementation for CMU and I have a question about the naming of vendor
tokens.  Assuming that a vendor might have a handful of tokens, should
they be grouped in their own hierarchy, ie:

/mailbox/{mailbox-name}/vendor/cyrus/entry1
/mailbox/{mailbox-name}/vendor/cyrus/entry2
/mailbox/{mailbox-name}/vendor/cyrus/entry3

or, should they all be at the same level, ie:

/mailbox/{mailbox-name}/vendor/cyrus.entry1
/mailbox/{mailbox-name}/vendor/cyrus.entry2
/mailbox/{mailbox-name}/vendor/cyrus.entry3

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

Date: Thu, 09 May 2002 05:25:00 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Neystadt, John" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

"Neystadt, John" wrote:

> > What about an extension to STATUS that returns the number of
> messages having a
> > particular flag. This definitely has applicability beyond VPIM.
> > For example, Cyrus was asking for the way of returning number of
> messages having
> > \Deleted flag and the total size of the deleted messages. This can
> be used
> > together with QUOTA extension to discover how much space can be
> recovered if the
> > user expunge a mailbox.
>
> Ok, to summarize: What you propose is to add new $Important flag and
> provide generic way to count messages marked by certain flag using
> STATUS.
>
> I like this idea and I will incorporate this in next revision of the
> draft.
>
> What about combinations how to obtain counter for both Unseen and
> Important messages? I see two options:
> - introduce boolean syntax in this command (i.e. \Unseen AND NOT
> $Important)
> - use pre-defined shortcuts for few well known combinations like
> current draft proposes (i.e. Unseen-Important)
>
> First way is certainly more generic, but also very complicate both in
> syntax and for server implementations to optimize for. So I would
> still prefer the second...?

For now I would rather do the second, as I am not too eager to spend
time on adding extended parser to STATUS. I don't think a client will be
willing to know, for example, how many messages in a mailbox with both
\Answered and \Deleted flags set.

Alexey

From: "Neystadt, John" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Date: Sun, 5 May 2002 10:53:40 +0300 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F409.F862EBC0
Content-Type: text/plain;
	charset="koi8-r"

> What about an extension to STATUS that returns the number of 
> messages having a
> particular flag. This definitely has applicability beyond VPIM.
> For example, Cyrus was asking for the way of returning number 
> of messages having
> \Deleted flag and the total size of the deleted messages. 
> This can be used
> together with QUOTA extension to discover how much space can 
> be recovered if the
> user expunge a mailbox.

Ok, to summarize: What you propose is to add new $Important flag and provide
generic way to count messages marked by certain flag using STATUS.

I like this idea and I will incorporate this in next revision of the draft. 

What about combinations how to obtain counter for both Unseen and Important
messages? I see two options:
- introduce boolean syntax in this command (i.e. \Unseen AND NOT $Important)
- use pre-defined shortcuts for few well known combinations like current
draft proposes (i.e. Unseen-Important)

First way is certainly more generic, but also very complicate both in syntax
and for server implementations to optimize for. So I would still prefer the
second...?

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

------_=_NextPart_001_01C1F409.F862EBC0
Content-Type: text/html;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dkoi8-r">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [VPIM] Re: I-D =
ACTION:draft-neystadt-imap-status-counters-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; What about an extension to STATUS that returns =
the number of </FONT>
<BR><FONT SIZE=3D2>&gt; messages having a</FONT>
<BR><FONT SIZE=3D2>&gt; particular flag. This definitely has =
applicability beyond VPIM.</FONT>
<BR><FONT SIZE=3D2>&gt; For example, Cyrus was asking for the way of =
returning number </FONT>
<BR><FONT SIZE=3D2>&gt; of messages having</FONT>
<BR><FONT SIZE=3D2>&gt; \Deleted flag and the total size of the deleted =
messages. </FONT>
<BR><FONT SIZE=3D2>&gt; This can be used</FONT>
<BR><FONT SIZE=3D2>&gt; together with QUOTA extension to discover how =
much space can </FONT>
<BR><FONT SIZE=3D2>&gt; be recovered if the</FONT>
<BR><FONT SIZE=3D2>&gt; user expunge a mailbox.</FONT>
</P>

<P><FONT SIZE=3D2>Ok, to summarize: What you propose is to add new =
$Important flag and provide generic way to count messages marked by =
certain flag using STATUS.</FONT></P>

<P><FONT SIZE=3D2>I like this idea and I will incorporate this in next =
revision of the draft. </FONT>
</P>

<P><FONT SIZE=3D2>What about combinations how to obtain counter for =
both Unseen and Important messages? I see two options:</FONT>
<BR><FONT SIZE=3D2>- introduce boolean syntax in this command (i.e. =
\Unseen AND NOT $Important)</FONT>
<BR><FONT SIZE=3D2>- use pre-defined shortcuts for few well known =
combinations like current draft proposes (i.e. Unseen-Important)</FONT>
</P>

<P><FONT SIZE=3D2>First way is certainly more generic, but also very =
complicate both in syntax and for server implementations to optimize =
for. So I would still prefer the second...?</FONT></P>

<P><FONT SIZE=3D2>John Neystadt</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.neystadt.org/john/" =
TARGET=3D"_blank">http://www.neystadt.org/john/</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F409.F862EBC0--

From: "Neystadt, John" <[email-masked]>
To: "'Alexey Melnikov'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Date: Sun, 5 May 2002 10:02:18 +0300 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F402.CB401110
Content-Type: text/plain;
	charset="koi8-r"

> > I think your proposal is very good for Unseen and may be 
> Important (new flag
> > or reuse \Flagged). BTW is \Flagged semantics is really 
> "importance". If I
> > make my server (by Sieve or other mechanism) turn \Flagged 
> on all messages
> > with "Importance: High" header, would that be ok.
> 
> What about "X-Priority: 1 (Highest)" and "Priority: HIGH" 
> headers that are in
> use by the MUA today?

Uh-hu :( You right. My current proposal handles this by "not a client's
problem" way. Namely it leaves to the server disicion of what is "Important"
and what is not. A clever and interoperable server will mark message as
"Important" according to "Importance:" and those ugly de-facto standard
headers.

If however we shift towards search expressions in status, then client will
have to specify all these headers in the command.

Actually both of these solutions are ugly, any other ideas on how to solve
this?

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

------_=_NextPart_001_01C1F402.CB401110
Content-Type: text/html;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dkoi8-r">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: I-D =
ACTION:draft-neystadt-imap-status-counters-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; &gt; I think your proposal is very good for =
Unseen and may be </FONT>
<BR><FONT SIZE=3D2>&gt; Important (new flag</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; or reuse \Flagged). BTW is \Flagged =
semantics is really </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;importance&quot;. If I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; make my server (by Sieve or other =
mechanism) turn \Flagged </FONT>
<BR><FONT SIZE=3D2>&gt; on all messages</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; with &quot;Importance: High&quot; header, =
would that be ok.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What about &quot;X-Priority: 1 (Highest)&quot; =
and &quot;Priority: HIGH&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; headers that are in</FONT>
<BR><FONT SIZE=3D2>&gt; use by the MUA today?</FONT>
</P>

<P><FONT SIZE=3D2>Uh-hu :( You right. My current proposal handles this =
by &quot;not a client's problem&quot; way. Namely it leaves to the =
server disicion of what is &quot;Important&quot; and what is not. A =
clever and interoperable server will mark message as =
&quot;Important&quot; according to &quot;Importance:&quot; and those =
ugly de-facto standard headers.</FONT></P>

<P><FONT SIZE=3D2>If however we shift towards search expressions in =
status, then client will have to specify all these headers in the =
command.</FONT></P>

<P><FONT SIZE=3D2>Actually both of these solutions are ugly, any other =
ideas on how to solve this?</FONT>
</P>

<P><FONT SIZE=3D2>John Neystadt</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.neystadt.org/john/" =
TARGET=3D"_blank">http://www.neystadt.org/john/</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F402.CB401110--

Date: Fri, 03 May 2002 07:37:16 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Arnt Gulbrandsen <[email-masked]>
CC: "Erev, Ari" <[email-masked]>, "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> > Can you suggest a better/quicker way to get this information?
>
> Yes, but you might still decide that a new extension is the best option.
> I too think it might be. The current draft doesn't argue its case very
> well.

One more proposal: If your mailstore supports SIEVE on injection and IMAPFLAGS
SIEVE extension ;-), you can write a SIEVE script that will mark all messages
containing "Important: high" with $Important keyword. Then IMAP client can open a
mailbox and do a search on $Important keyword, that for many servers will be
faster that header search. Even if the messaging server doesn't support SIEVE, you
can have a client that watches a mailbox and does SEARCHes for required content:
 tag SEARCH <n>:* HEADER Importance low HEADER Message-Context text-message

Pay attention that this SEARCH is only performed on new messages (n is the last
processed message). Several servers will be optimized for this type of search.
Then the client can mark all found messages as $Important.

Arnt Gulbrandsen wrote:

> > Note that STATUS has always been designed to provide this "type" of
> > information (message counters) -
>
> Agreed.

> > just not in the detailed manner it is now
> > required when clients need to get the counters "per message-context". So, an
> > enhancement to STATUS seems to me a logical way to achieve this.
>
> If so, it must not be VPIM-specific. Try to tweak the extension so that
> it's useful for other clients, and provide a couple of examples showing
> how non-VPIM clients might use it.

Mark Crispin wrote:

> Also, the more minimal a VPIM extension to IMAP is, the more likely it is
> that you'll get it generally implemented.  For example, if a VPIM
> extension requires only about 15 minutes of programming work, I'm likely
> to do it in my server, just to preclude having to answer an email require
> to do it.  If, on the other hand, an extension requires many hours of
> work, it's much less likely to happen without specific value to us.

What about an extension to STATUS that returns the number of messages having a
particular flag. This definitely has applicability beyond VPIM.
For example, Cyrus was asking for the way of returning number of messages having
\Deleted flag and the total size of the deleted messages. This can be used
together with QUOTA extension to discover how much space can be recovered if the
user expunge a mailbox.

As far as our server is concerned, we already count all messages that don't have
\Seen flag on STATUS command. Adding other flags would be trivial for us.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

I speak for myself only, not for my employer.
__________________________________________

Date: Fri, 03 May 2002 07:34:18 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Vaudreuil, Greg M (Greg)" <[email-masked]>
CC: Mark Crispin <[email-masked]>, John Neystadt <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

"Vaudreuil, Greg M (Greg)" wrote:

> The importance is a sender-indicated message attribute, not a recipient
> indication of a particular level of interest or importance they may wish to
> recall between sessions. We need a flag that is standardized by convention
> between a message deposit process that can set this flag and the many
> different clients that would expect the flag to be there if a message is
> tagged as important.
>
> I think use of a new flag makes plenty of sense for \important.  I don't
> think a flag per message context makes much sense tho.

If you decide to introduce a new flag, don't use \important, as the leading "\"
has special semantic in IMAP and server that don't support it will most likely
refuse to store it. I suggest you use $Important instead. This way you will be
able to store it on a IMAP server that allows for storing of arbitrary keywords.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

I speak for myself only, not for my employer.
__________________________________________

Date: Fri, 03 May 2002 06:54:56 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: "Vaudreuil, Greg M (Greg)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Sender: [email-masked]

Mark Crispin wrote:

> On Sun, 28 Apr 2002 20:54:15 -0600, Vaudreuil, Greg M (Greg) wrote:
> > Is there any objection to a new flag with explicit semantics of importance?
>
> I think that you will find a very strong lack of enthusiasm for adding a flag
> which duplicates the existing functionality of \Flagged and/or SEARCH HEADER.

I agree in general but not in this particular case.
I use Netscape Communicator 4.79 as a mail client. It allows to change priority
of the message (i.e. overwrite X-Priority header) and I use this feature quite a
bit. Unfortunately Netscape stores this value in the local mailbox cache and this
change is lost when I synchronize a mailbox. I would love to see the mail client
being able to store this on a IMAP server. [Netscape people, are you listening
;-)?]

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

I speak for myself only, not for my employer.
__________________________________________

Date: Fri, 03 May 2002 06:38:16 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: John Neystadt <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

Let me through couple more rocks ;-):

John Neystadt wrote:

> I think your proposal is very good for Unseen and may be Important (new flag
> or reuse \Flagged). BTW is \Flagged semantics is really "importance". If I
> make my server (by Sieve or other mechanism) turn \Flagged on all messages
> with "Importance: High" header, would that be ok.

What about "X-Priority: 1 (Highest)" and "Priority: HIGH" headers that are in
use by the MUA today?

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

I speak for myself only, not for my employer.
__________________________________________

To: "Erev, Ari" <[email-masked]>
Cc: "'Arnt Gulbrandsen'" <[email-masked]>, "Neystadt, John" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
From: Simon Josefsson <[email-masked]>
Date: Thu, 02 May 2002 19:26:28 +0200
Lines: 28
Sender: [email-masked]

"Erev, Ari" <[email-masked]> writes:

> According to your example, I believe the client can get the counters
> information this way (12 round trips):
>
> tag SEARCH UNSEEN HEADER Importance high HEADER Message-Context
> voice-message
> tag SEARCH    SEEN HEADER Importance high HEADER Message-Context
> voice-message
> tag SEARCH UNSEEN HEADER Importance low HEADER Message-Context voice-message
> tag SEARCH     SEEN HEADER Importance low  HEADER Message-Context
> voice-message
>
> tag SEARCH UNSEEN HEADER Importance high HEADER Message-Context text-message
> tag SEARCH    SEEN HEADER Importance high HEADER Message-Context
> text-message
> tag SEARCH UNSEEN HEADER Importance low HEADER Message-Context text-message
> tag SEARCH    SEEN HEADER Importance low HEADER Message-Context text-message
>
> tag SEARCH UNSEEN HEADER Importance high HEADER Message-Context fax-message
> tag SEARCH    SEEN HEADER Importance high HEADER Message-Context fax-message
> tag SEARCH UNSEEN HEADER Importance low HEADER Message-Context fax-message
> tag SEARCH    SEEN HEADER Importance low HEADER Message-Context fax-message
>
> Can you suggest a better/quicker way to get this information? 

I see only one round trip.  Send all commands in one operation and
then wait for the responses.

Date: Thu, 2 May 2002 11:36:42 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Erev, Ari" <[email-masked]>
Cc: "Neystadt, John" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Sender: [email-masked]

"Erev, Ari" <[email-masked]>
> Let's assume a mailbox which has (only) 3 types of messages
> (message-contexts). 
> According to your example, I believe the client can get the counters
> information this way (12 round trips):

That's one scary-looking series of commands. However, it translates into
this equally scary prompt:

	Hello, this is your voice-mail system. You have 4 new important
	voice messages, 12 old important voice messages, 3 unimportant new
	voice messages, 4 unimportant old voice messages, 4 new important
	text messages, 12 old important text messages, 3 unimportant new
	text messages, 4 unimportant old text messages, 4 new important
	fax messages, 12 old important fax messages, 3 unimportant new fax
	messages and 4 unimportant old fax messages. Press 1 to...

Performancewise, this does not seem to be a problem. One search must
complete before the start of the sentence, and all 12 searches before the
word 'and'. And that prompt is a great April fool's joke ;)

Seriously, if the prompt contains n numbers, you should need about n
SEARCH commands.  If, as you say, the server selects to optimize for this
task, it should require as little processor time as e.g. SEARCH UNSEEN
does.

> Can you suggest a better/quicker way to get this information?

Yes, but you might still decide that a new extension is the best option.
I too think it might be. The current draft doesn't argue its case very
well.

As I see it, using SEARCH optimally, using the ANNOTATE extension, or a
combination of the two are all worth looking into.

ANNOTATE is a larger extension than STATUS-COUNTERS, but it looks to have
wide support, so that it'll be implemented by many servers. The message
context and importance you're using sound like annotations to my ears, so
ANNOTATE might be a good fit.

> Note that STATUS has always been designed to provide this "type" of
> information (message counters) - 

Agreed.

> just not in the detailed manner it is now
> required when clients need to get the counters "per message-context". So, an
> enhancement to STATUS seems to me a logical way to achieve this.

If so, it must not be VPIM-specific. Try to tweak the extension so that
it's useful for other clients, and provide a couple of examples showing
how non-VPIM clients might use it.

--Arnt

From: "Erev, Ari" <[email-masked]>
To: "'Arnt Gulbrandsen'" <[email-masked]>, "Neystadt, John" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Date: Thu, 2 May 2002 11:11:18 +0300 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F1B0.F00FF400
Content-Type: text/plain;
	charset="iso-8859-1"

Arnt,

I think everybody (including John) agrees that _FUNCTIONALLY_ the current
IMAP provides what is required for a client to get the 'counters'
information - whether it is by using FETCH or SEARCH.

The main point in John proposal is not about functionality - it is about
performance (and possibly scalability).
It allow the counters information (which is required very early in the
session) to be available to the client with minimal round-trips and it
allows the server to optimize for this task - if it selects to do so.

Let's assume a mailbox which has (only) 3 types of messages
(message-contexts). 
According to your example, I believe the client can get the counters
information this way (12 round trips):

tag SEARCH UNSEEN HEADER Importance high HEADER Message-Context
voice-message
tag SEARCH    SEEN HEADER Importance high HEADER Message-Context
voice-message
tag SEARCH UNSEEN HEADER Importance low HEADER Message-Context voice-message
tag SEARCH     SEEN HEADER Importance low  HEADER Message-Context
voice-message

tag SEARCH UNSEEN HEADER Importance high HEADER Message-Context text-message
tag SEARCH    SEEN HEADER Importance high HEADER Message-Context
text-message
tag SEARCH UNSEEN HEADER Importance low HEADER Message-Context text-message
tag SEARCH    SEEN HEADER Importance low HEADER Message-Context text-message

tag SEARCH UNSEEN HEADER Importance high HEADER Message-Context fax-message
tag SEARCH    SEEN HEADER Importance high HEADER Message-Context fax-message
tag SEARCH UNSEEN HEADER Importance low HEADER Message-Context fax-message
tag SEARCH    SEEN HEADER Importance low HEADER Message-Context fax-message

Can you suggest a better/quicker way to get this information? 

Maybe there is an option to skip the last group of 4 by computing it somehow
but anyway - it is obvious that with more "Message-Contexts" this scenario
gets longer and longer - which does not seem to be a good way to achieve
scalability AND  short response time - which is the original requirement!

And so, John proposal suggests to get the required information in ONE
command (STATUS). 
This provides for short response time, and also allows for servers that want
to optimize for this case to do so in whichever way they choose to do so.

Note that STATUS has always been designed to provide this "type" of
information (message counters) - just not in the detailed manner it is now
required when clients need to get the counters "per message-context". So, an
enhancement to STATUS seems to me a logical way to achieve this.

Ari Erev

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]]
Sent: Wednesday, May 01, 2002 10:43 PM
To: Neystadt, John
Cc: [email-masked]'; [email-masked]; [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.
txt

"Neystadt, John" <[email-masked]>
> My extension does not mandate VPIM clients not to work with servers that
> does not implement it. Section 8.2 of the draft says:
...

Why do you specify using FETCH? SEARCH seems better:

	a SELECT mailbox
	b SEARCH UNSEEN
	c SEARCH HEADER Importance: high
	d SEARCH HEADER Message-Context: blah

--Arnt

------_=_NextPart_001_01C1F1B0.F00FF400
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [VPIM] Re: I-D =
ACTION:draft-neystadt-imap-status-counters-00. txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Arnt,</FONT>
</P>

<P><FONT SIZE=3D2>I think everybody (including John) agrees that =
_FUNCTIONALLY_ the current IMAP provides what is required for a client =
to get the 'counters' information - whether it is by using FETCH or =
SEARCH.</FONT></P>

<P><FONT SIZE=3D2>The main point in John proposal is not about =
functionality - it is about performance (and possibly =
scalability).</FONT>
<BR><FONT SIZE=3D2>It allow the counters information (which is required =
very early in the session) to be available to the client with minimal =
round-trips and it allows the server to optimize for this task - if it =
selects to do so.</FONT></P>

<P><FONT SIZE=3D2>Let's assume a mailbox which has (only) 3 types of =
messages (message-contexts). </FONT>
<BR><FONT SIZE=3D2>According to your example, I believe the client can =
get the counters information this way (12 round trips):</FONT>
</P>

<P><FONT SIZE=3D2>tag SEARCH UNSEEN HEADER Importance high HEADER =
Message-Context voice-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH&nbsp;&nbsp;&nbsp; SEEN HEADER Importance =
high HEADER Message-Context voice-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH UNSEEN HEADER Importance low HEADER =
Message-Context voice-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH&nbsp;&nbsp;&nbsp;&nbsp; SEEN HEADER =
Importance low&nbsp; HEADER Message-Context voice-message</FONT>
</P>

<P><FONT SIZE=3D2>tag SEARCH UNSEEN HEADER Importance high HEADER =
Message-Context text-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH&nbsp;&nbsp;&nbsp; SEEN HEADER Importance =
high HEADER Message-Context text-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH UNSEEN HEADER Importance low HEADER =
Message-Context text-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH&nbsp;&nbsp;&nbsp; SEEN HEADER Importance =
low HEADER Message-Context text-message</FONT>
</P>

<P><FONT SIZE=3D2>tag SEARCH UNSEEN HEADER Importance high HEADER =
Message-Context fax-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH&nbsp;&nbsp;&nbsp; SEEN HEADER Importance =
high HEADER Message-Context fax-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH UNSEEN HEADER Importance low HEADER =
Message-Context fax-message</FONT>
<BR><FONT SIZE=3D2>tag SEARCH&nbsp;&nbsp;&nbsp; SEEN HEADER Importance =
low HEADER Message-Context fax-message</FONT>
</P>

<P><FONT SIZE=3D2>Can you suggest a better/quicker way to get this =
information? </FONT>
</P>

<P><FONT SIZE=3D2>Maybe there is an option to skip the last group of 4 =
by computing it somehow but anyway - it is obvious that with more =
&quot;Message-Contexts&quot; this scenario gets longer and longer - =
which does not seem to be a good way to achieve scalability AND&nbsp; =
short response time - which is the original requirement!</FONT></P>

<P><FONT SIZE=3D2>And so, John proposal suggests to get the required =
information in ONE command (STATUS). </FONT>
<BR><FONT SIZE=3D2>This provides for short response time, and also =
allows for servers that want to optimize for this case to do so in =
whichever way they choose to do so.</FONT></P>

<P><FONT SIZE=3D2>Note that STATUS has always been designed to provide =
this &quot;type&quot; of information (message counters) - just not in =
the detailed manner it is now required when clients need to get the =
counters &quot;per message-context&quot;. So, an enhancement to STATUS =
seems to me a logical way to achieve this.</FONT></P>

<P><FONT SIZE=3D2>Ari Erev</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Arnt Gulbrandsen [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, May 01, 2002 10:43 PM</FONT>
<BR><FONT SIZE=3D2>To: Neystadt, John</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]'; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [VPIM] Re: I-D =
ACTION:draft-neystadt-imap-status-counters-00. txt</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&quot;Neystadt, John&quot; =
&lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; My extension does not mandate VPIM clients not =
to work with servers that</FONT>
<BR><FONT SIZE=3D2>&gt; does not implement it. Section 8.2 of the draft =
says:</FONT>
<BR><FONT SIZE=3D2>...</FONT>
</P>

<P><FONT SIZE=3D2>Why do you specify using FETCH? SEARCH seems =
better:</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a SELECT =
mailbox</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>b SEARCH =
UNSEEN</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>c SEARCH =
HEADER Importance: high</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>d SEARCH =
HEADER Message-Context: blah</FONT>
</P>

<P><FONT SIZE=3D2>--Arnt</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F1B0.F00FF400--

Date: Wed, 1 May 2002 21:43:18 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Neystadt, John" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Sender: [email-masked]

"Neystadt, John" <[email-masked]>
> My extension does not mandate VPIM clients not to work with servers that
> does not implement it. Section 8.2 of the draft says:
...

Why do you specify using FETCH? SEARCH seems better:

	a SELECT mailbox
	b SEARCH UNSEEN
	c SEARCH HEADER Importance: high
	d SEARCH HEADER Message-Context: blah

--Arnt

Date: Wed, 1 May 2002 09:59:20 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
To: "Neystadt, John" <[email-masked]>
cc: [email-masked], [email-masked]
Sender: [email-masked]

On Wed, 1 May 2002 19:05:47 +0300 , Neystadt, John wrote:
> This is what the MUAs do today. Basic problem with that is to calculate
> message counters per message-context (MIME header) MUA must download message
> headers of whole mailbox.

As I pointed out before, you do not need to do this.

You can do searches and partial header fetches to reduce greatly the amount of
downloading you must do.  You can also use keyword flags to avoid using the
headers at all.

Please to leverage existing mechanisms as much as possible rather than create
new mechanisms.  This includes design of extensions.  You're much more likely
to get extensions widely deployed if those extensions are built on top of
existing mechanisms, particularly if the extension is as narrowly focused as
this.

From: "Neystadt, John" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Date: Wed, 1 May 2002 19:11:52 +0300 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F12A.E7B517D0
Content-Type: text/plain;
	charset="iso-8859-1"

> I have to agree with Mark's sentiment expressed below.  The 
> whole point of
> using IMAP for Pink Lemonade is there is a large existing 
> base of servers
> and developers.  If we set out to build "VPIM-IMAP", we might 
> as well call
> it son/daughter of IMAP and be done with it.

First of all, some of us develop products who do enhancements for Pink
Lemonde. For example SNAP protocol is such an enhancement that requires
modification of the servers as well.

My extension does not mandate VPIM clients not to work with servers that
does not implement it. Section 8.2 of the draft says:

> 8.2 Client Issues 
>     
>    Is imap server implementation does not support this command, its 
>    logic can be achieved by the following algorithm: 
>     
>    For the given mailbox do: 
>     
>       1. a SELECT mailbox 
>       2. b FETCH 1:* BODY[HEADER (Importance Message-Context)] 
>       3. Calculate the counters from FETCH responses. 

Servers that will not implement this, will burn more CPU and have worse
response time, but other than that that will work.

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

------_=_NextPart_001_01C1F12A.E7B517D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [VPIM] Re: I-D =
ACTION:draft-neystadt-imap-status-counters-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; I have to agree with Mark's sentiment expressed =
below.&nbsp; The </FONT>
<BR><FONT SIZE=3D2>&gt; whole point of</FONT>
<BR><FONT SIZE=3D2>&gt; using IMAP for Pink Lemonade is there is a =
large existing </FONT>
<BR><FONT SIZE=3D2>&gt; base of servers</FONT>
<BR><FONT SIZE=3D2>&gt; and developers.&nbsp; If we set out to build =
&quot;VPIM-IMAP&quot;, we might </FONT>
<BR><FONT SIZE=3D2>&gt; as well call</FONT>
<BR><FONT SIZE=3D2>&gt; it son/daughter of IMAP and be done with =
it.</FONT>
</P>

<P><FONT SIZE=3D2>First of all, some of us develop products who do =
enhancements for Pink Lemonde. For example SNAP protocol is such an =
enhancement that requires modification of the servers as =
well.</FONT></P>

<P><FONT SIZE=3D2>My extension does not mandate VPIM clients not to =
work with servers that does not implement it. Section 8.2 of the draft =
says:</FONT></P>

<P><FONT SIZE=3D2>&gt; 8.2 Client Issues </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Is imap server implementation =
does not support this command, its </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; logic can be achieved by the =
following algorithm: </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; For the given mailbox do: =
</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. a SELECT =
mailbox </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. b FETCH =
1:* BODY[HEADER (Importance Message-Context)] </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. =
Calculate the counters from FETCH responses. </FONT>
</P>

<P><FONT SIZE=3D2>Servers that will not implement this, will burn more =
CPU and have worse response time, but other than that that will =
work.</FONT></P>

<P><FONT SIZE=3D2>John Neystadt</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.neystadt.org/john/" =
TARGET=3D"_blank">http://www.neystadt.org/john/</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F12A.E7B517D0--

From: "Neystadt, John" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Date: Wed, 1 May 2002 19:05:47 +0300 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F12A.0E2B6550
Content-Type: text/plain;
	charset="iso-8859-1"

> Mark's suggestion of having a 
> simple indicator
> to go look at the mailbox in more detail is reasonable for this
> application. 

This is what the MUAs do today. Basic problem with that is to calculate
message counters per message-context (MIME header) MUA must download message
headers of whole mailbox. This can take a while on big mailboxes and
represents considerable overhead for servers.

The idea of status-counters is to have server cache this information and be
able to provide it to MUA in fraction of time and overhead. 

Think for example about telephony MUA, that announces to subscriber "You
have 301 new email messages". This must be down in less than 100ms after
users picks up the phone and not after few secs as it must be now (after
downloading and processing all message headers).

> If you need to do more than that then look to do 
> it outside of
> IMAP - I thought SNAP was supposed to provide a way to get the same
> information as you are proposing adding to STATUS. Why duplicate SNAP
> inside of IMAP? Just let clients interested in that info use 
> SNAP instead.

I rather would say they complement each other. SNAP is away for subscriber
to get notifications when he is off-line. They can be sent to PUA, though
Unix message service or thorugh SMS. When subscriber runs his mail program
he wants to see counters which are most up-to-date. 

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

------_=_NextPart_001_01C1F12A.0E2B6550
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: I-D =
ACTION:draft-neystadt-imap-status-counters-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; Mark's suggestion of having a </FONT>
<BR><FONT SIZE=3D2>&gt; simple indicator</FONT>
<BR><FONT SIZE=3D2>&gt; to go look at the mailbox in more detail is =
reasonable for this</FONT>
<BR><FONT SIZE=3D2>&gt; application. </FONT>
</P>

<P><FONT SIZE=3D2>This is what the MUAs do today. Basic problem with =
that is to calculate message counters per message-context (MIME header) =
MUA must download message headers of whole mailbox. This can take a =
while on big mailboxes and represents considerable overhead for =
servers.</FONT></P>

<P><FONT SIZE=3D2>The idea of status-counters is to have server cache =
this information and be able to provide it to MUA in fraction of time =
and overhead. </FONT></P>

<P><FONT SIZE=3D2>Think for example about telephony MUA, that announces =
to subscriber &quot;You have 301 new email messages&quot;. This must be =
down in less than 100ms after users picks up the phone and not after =
few secs as it must be now (after downloading and processing all =
message headers).</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; If you need to do more than that then look to do =
</FONT>
<BR><FONT SIZE=3D2>&gt; it outside of</FONT>
<BR><FONT SIZE=3D2>&gt; IMAP - I thought SNAP was supposed to provide a =
way to get the same</FONT>
<BR><FONT SIZE=3D2>&gt; information as you are proposing adding to =
STATUS. Why duplicate SNAP</FONT>
<BR><FONT SIZE=3D2>&gt; inside of IMAP? Just let clients interested in =
that info use </FONT>
<BR><FONT SIZE=3D2>&gt; SNAP instead.</FONT>
</P>

<P><FONT SIZE=3D2>I rather would say they complement each other. SNAP =
is away for subscriber to get notifications when he is off-line. They =
can be sent to PUA, though Unix message service or thorugh SMS. When =
subscriber runs his mail program he wants to see counters which are =
most up-to-date. </FONT></P>

<P><FONT SIZE=3D2>John Neystadt</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.neystadt.org/john/" =
TARGET=3D"_blank">http://www.neystadt.org/john/</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F12A.0E2B6550--