Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, John Neystadt <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Tue, 30 Apr 2002 14:48:30 -0400
List-Id: <ietf-imapext.imc.org>

Hi,

--On Friday, April 26, 2002 6:30 PM -0700 Mark Crispin
<[email-masked]> wrote:

| I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as
| much as possible rather than try to extend STATUS.  One thing that you
| could try to do is use STATUS to identify whether a mailbox should be
| subject to more detailed examination with SELECT+SEARCH.  That was the
| original intent behind STATUS; to enable identification of "interesting"
| mailboxes without having to SELECT them.

This is a good point. Here is my take on this:

If the user is only likely to be interested in one or two mailboxes, then
its perfectly feasible to allow EXAMINE+IDLE+SEARCH style notifications to
be done by the client. If you are dealing with tens to hundreds of
mailboxes then status polling is OK, provided there is not too much extra
data in the status response. Mark's suggestion of having a simple indicator
to go look at the mailbox in more detail is reasonable for this
application. 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.

-- 
Cyrus Daboo

Reply-To: <[email-masked]>
From: "Eric Burger" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Date: Tue, 30 Apr 2002 14:13:52 -0400
Importance: Normal
Sender: [email-masked]

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.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Mark Crispin
Sent: Friday, April 26, 2002 9:31 PM
To: John Neystadt
Cc: [email-masked]; [email-masked]
Subject: [VPIM] Re: I-D
ACTION:draft-neystadt-imap-status-counters-00.txt

[snip]
The more that you leverage existing tools, as opposed to requiring the
creation of new tools, the better able you'll be able to deploy.  Ideally,
given 100% leverage, you'll be able to run your VPIM client software
with any IMAP server; you may desire to have a special IMAP server that is
optimized for VPIM, but there is an attraction to being able to plug in
with any server.

What concerns me is the possibility of making VPIM clients excessively
and unnecessarily dependent upon a VPIM-extended server.  This doesn't
mean "thou shalt not extend IMAP for VPIM under any circumstances"!!  It
does, however, suggest that you should leverage aggressively and extend
IMAP only if there's no way to leverage.

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.

Date: Mon, 29 Apr 2002 14:03:17 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Neystadt, John" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

"Neystadt, John" <[email-masked]>
> This is today handled on clients and is used to display counters either in
> folders tree or on some general summary screen. 
> There are two main benefits of moving this logic to server:
> 
> - in order to build them you must screen all message headers in the mailbox,
> this is very slow and traffic intensive if done on client

That sounds as if you're using FETCH HEADER.FIELDS() or something today.
If that's true, I can certaing agree that a change is desirable ;)

However, a SEARCH should avoid network traffic almost completely, cut down
on the amount of the client must do, and be at least as good for the
server. (I'm assuming that on a server, searching for flags will be at
least as fast as downloading all messages - usually quite a bit faster.)

> - server can store the counters and then incrementally update the counters
> when new messages are delivered (in MTA) or expunged and server do different
> clients. This saves much of processing power for servers.

Well, maybe. OTOH, most server authors might not want to write code to
speed unusual special cases, and then the VPIM client has to the slow code
anyway.

If you need an extension, better try to design it so that a lot of clients
will benefit from it and the incentive to implement it is correspondingly
strong.

--Arnt

Date: Mon, 29 Apr 2002 13:51:41 +0200
From: Arnt Gulbrandsen <[email-masked]>
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)" <[email-masked]>
> Is there any objection to a new flag with explicit semantics of importance?
> The meaning of \flagged is private between a client and it's store.  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.

This assumes that current-day clients use \flagged in different ways. Is
that indeed so? Every client I've seen seems to either ignore it or treat
it as a "must look at this message" flag.

--Arnt

Date: Sun, 28 Apr 2002 21:19:05 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
To: "Vaudreuil, Greg M (Greg)" <[email-masked]>
cc: John Neystadt <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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.

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: Mark Crispin <[email-masked]>, John Neystadt <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Date: Sun, 28 Apr 2002 20:54:15 -0600
Sender: [email-masked]

Is there any objection to a new flag with explicit semantics of importance?
The meaning of \flagged is private between a client and it's store.  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.  

Greg V.

-----Original Message-----
From: Mark Crispin [mailto:[email-masked]]
Sent: Friday, April 26, 2002 8:31 PM
To: John Neystadt
Cc: [email-masked]; [email-masked]
Subject: [VPIM] Re: I-D
ACTION:draft-neystadt-imap-status-counters-00.txt

On Fri, 26 Apr 2002, John Neystadt wrote:
> 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 are other uses for
it
> today?

What \Flagged does is client-dependent, but the basic idea is to mark some
kind of "importance" emphasis on the message.  In the original MM program
on the DEC-20, flagged messages were always announced with every new mail
announcement.  In more modern message-browser type programs, flagged
messages are drawn with a box around them or in a bold font or with some
sort of highlighting color to call attention to it.

Since VPIM is essentially a client application, it is perfectly within its
rights to decide that \Flagged means "Important" in the VPIM context, and
to decide that the MDA should turn on \Flagged on all messages which have
"Importance: High" in the header.  In fact, I could see some non-VPIM
users wanting to do that in the MDA.

I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as
much as possible rather than try to extend STATUS.  One thing that you
could try to do is use STATUS to identify whether a mailbox should be
subject to more detailed examination with SELECT+SEARCH.  That was the
original intent behind STATUS; to enable identification of "interesting"
mailboxes without having to SELECT them.

The more that you leverage existing tools, as opposed to requiring the
creation of new tools, the better able you'll be able to deploy.  Ideally,
given 100% leverage, you'll be able to run your VPIM client software
with any IMAP server; you may desire to have a special IMAP server that is
optimized for VPIM, but there is an attraction to being able to plug in
with any server.

What concerns me is the possibility of making VPIM clients excessively
and unnecessarily dependent upon a VPIM-extended server.  This doesn't
mean "thou shalt not extend IMAP for VPIM under any circumstances"!!  It
does, however, suggest that you should leverage aggressively and extend
IMAP only if there's no way to leverage.

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.

-- Mark --

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

"A single glass of champagne imparts a feeling of exhiliaration.  The
nerves are braced; the imagination is agreeably strirred; the wits become
more nimble.  A bottle produces a contrary effect.  Excess causes a
comatose insensibility.  So it is with war; and the quality of both is
best discovered by sipping."  -- Winston Churchill

----------------------------------------------------------
This message was sent to you, since you are subscribed to
[email-masked]. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo

From: "Neystadt, John" <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Date: Sun, 28 Apr 2002 10:27:39 +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_01C1EE86.2D40BBD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> In draft-1, could you the non-ascii junk? I see various =FC and =C6
> characters.

I was told already, I've used winword template that produced this junk =
:(
I'll clean it up.

> It seems unjustified. You mention one application for it, and=20
> it sounds as
> if the code belongs in that IMAP client. If you think that code =
really
> belongs in IMAP servers, I suggest showing more uses in the draft.

This is today handled on clients and is used to display counters either =
in
folders tree or on some general summary screen.=20
There are two main benefits of moving this logic to server:

- in order to build them you must screen all message headers in the =
mailbox,
this is very slow and traffic intensive if done on client
- server can store the counters and then incrementally update the =
counters
when new messages are delivered (in MTA) or expunged and server do =
different
clients. This saves much of processing power for servers.

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

------_=_NextPart_001_01C1EE86.2D40BBD0
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; In draft-1, could you the non-ascii junk? I see =
various =FC and =C6</FONT>
<BR><FONT SIZE=3D2>&gt; characters.</FONT>
</P>

<P><FONT SIZE=3D2>I was told already, I've used winword template that =
produced this junk :( I'll clean it up.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; It seems unjustified. You mention one =
application for it, and </FONT>
<BR><FONT SIZE=3D2>&gt; it sounds as</FONT>
<BR><FONT SIZE=3D2>&gt; if the code belongs in that IMAP client. If you =
think that code really</FONT>
<BR><FONT SIZE=3D2>&gt; belongs in IMAP servers, I suggest showing more =
uses in the draft.</FONT>
</P>

<P><FONT SIZE=3D2>This is today handled on clients and is used to =
display counters either in folders tree or on some general summary =
screen. </FONT></P>

<P><FONT SIZE=3D2>There are two main benefits of moving this logic to =
server:</FONT>
</P>

<P><FONT SIZE=3D2>- in order to build them you must screen all message =
headers in the mailbox, this is very slow and traffic intensive if done =
on client</FONT></P>

<P><FONT SIZE=3D2>- server can store the counters and then =
incrementally update the counters when new messages are delivered (in =
MTA) or expunged and server do different clients. This saves much of =
processing power for servers.</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_01C1EE86.2D40BBD0--

Date: Fri, 26 Apr 2002 18:30:59 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: John Neystadt <[email-masked]>
cc: [email-masked], <[email-masked]>
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Fri, 26 Apr 2002, John Neystadt wrote:
> 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 are other uses for it
> today?

What \Flagged does is client-dependent, but the basic idea is to mark some
kind of "importance" emphasis on the message.  In the original MM program
on the DEC-20, flagged messages were always announced with every new mail
announcement.  In more modern message-browser type programs, flagged
messages are drawn with a box around them or in a bold font or with some
sort of highlighting color to call attention to it.

Since VPIM is essentially a client application, it is perfectly within its
rights to decide that \Flagged means "Important" in the VPIM context, and
to decide that the MDA should turn on \Flagged on all messages which have
"Importance: High" in the header.  In fact, I could see some non-VPIM
users wanting to do that in the MDA.

I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as
much as possible rather than try to extend STATUS.  One thing that you
could try to do is use STATUS to identify whether a mailbox should be
subject to more detailed examination with SELECT+SEARCH.  That was the
original intent behind STATUS; to enable identification of "interesting"
mailboxes without having to SELECT them.

The more that you leverage existing tools, as opposed to requiring the
creation of new tools, the better able you'll be able to deploy.  Ideally,
given 100% leverage, you'll be able to run your VPIM client software
with any IMAP server; you may desire to have a special IMAP server that is
optimized for VPIM, but there is an attraction to being able to plug in
with any server.

What concerns me is the possibility of making VPIM clients excessively
and unnecessarily dependent upon a VPIM-extended server.  This doesn't
mean "thou shalt not extend IMAP for VPIM under any circumstances"!!  It
does, however, suggest that you should leverage aggressively and extend
IMAP only if there's no way to leverage.

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.

-- Mark --

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

"A single glass of champagne imparts a feeling of exhiliaration.  The
nerves are braced; the imagination is agreeably strirred; the wits become
more nimble.  A bottle produces a contrary effect.  Excess causes a
comatose insensibility.  So it is with war; and the quality of both is
best discovered by sipping."  -- Winston Churchill

Date: Fri, 26 Apr 2002 11:18:12 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: John Neystadt <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

John Neystadt <[email-masked]>
> C: STATUS abc COUNTERS[(\Seen AND $Fax-Message) (\Seen AND \Flagged AND
> $Fax-Message) ...]
> 
> This is long and somewhat cumbersome.

That sounds like a few SEARCH commands joined together and renamed to
STATUS. Perhaps using SEARCH (and maybe ANNOTATE) is enough?

SEARCH may not scale as well as STATUS-COUNTERS would, but in this case I
don't think that's a problem:  "You have 1042300533 messages, 32765355 new
and 42523145 important" is a nightmare no matter of efficiently it's
implemented ;)

--Arnt

Date: Fri, 26 Apr 2002 10:53:19 +0200
From: John Neystadt <[email-masked]>
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Hello,

> It certainly does seem to be very much specialized for VPIM, and doesn't
seem
> to make adequate attempt to leverage existing mechanisms.  For example,
why
> not use IMAP keyword flags in association with delivery mechanisms that
set
> those flags, and then just extend STATUS to count other flags besides
\Recent
> and (not) \Seen.

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 are other uses for it
today?

Now there is a problem with Message-Context - since it is an extensible list
of values (new ones can be added ad-hoc) then message flags will have to be
added per each of them each time new values are added. In my proposal server
sends response per all detected Message-Contexts. In your way we will have
to introduce some mechanism for MUA to enumerate them. In additoin flags are
not "typed" so MUA can't distinuigh between say $MDNSent and $Fax-Message
which is confusing.

Another issue is that \Seen changes dynamically. So in order to query for
counter of \Seen fax messgase we will have to pass a boolean expression of
flags to this new STATUS extension. For example:

C: STATUS abc COUNTERS[(\Seen AND $Fax-Message) (\Seen AND \Flagged AND
$Fax-Message) ...]

This is long and somewhat cumbersome.

> > In draft-1, could you the non-ascii junk? I see various | and F
> > characters.
>
> I have to echo this comment; I don't know what produced that junk but it
is
> there and it is annoying.

I apologize again.

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

Date: Thu, 25 Apr 2002 13:05:51 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
To: Arnt Gulbrandsen <[email-masked]>
cc: "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 25 Apr 2002 15:18:01 +0200, Arnt Gulbrandsen wrote:
> "Neystadt, John" <[email-masked]>
> > Until now I did not get a comments regarding matter of the draft.
> >
> > Does it makes sense? What do you think about it?
>
> It seems unjustified. You mention one application for it, and it sounds as
> if the code belongs in that IMAP client. If you think that code really
> belongs in IMAP servers, I suggest showing more uses in the draft.

It certainly does seem to be very much specialized for VPIM, and doesn't seem
to make adequate attempt to leverage existing mechanisms.  For example, why
not use IMAP keyword flags in association with delivery mechanisms that set
those flags, and then just extend STATUS to count other flags besides \Recent
and (not) \Seen.

Regardless of whether this extension is intended for general implementation,
or only for implementation in special VPIM boxes, I think that greater
leveraging of existing IMAP mechanisms is desirable.  In the general
implementation case, it is to create a reason for it to be implemented; in the
VPIM-only cases, it is because there's no harm in doing so.

On the other hand, the intended implementation audience may make a difference
on, for example, whether or not \Flagged can be used to implement "Important".
But that's a minor issue in the overall scope of things.

To summarize: you may have a good case to expand STATUS to return other data;
but you have not (yet) made a good case to create new classes of data since it
is conjectured that the desired information can be represented with existing
data.  In particular, please give strong consideration to using keyword flags.

> In draft-1, could you the non-ascii junk? I see various | and F
> characters.

I have to echo this comment; I don't know what produced that junk but it is
there and it is annoying.

Date: Thu, 25 Apr 2002 15:18:01 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Neystadt, John" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

"Neystadt, John" <[email-masked]>
> Until now I did not get a comments regarding matter of the draft.
> 
> Does it makes sense? What do you think about it?

It seems unjustified. You mention one application for it, and it sounds as
if the code belongs in that IMAP client. If you think that code really
belongs in IMAP servers, I suggest showing more uses in the draft.

In draft-1, could you the non-ascii junk? I see various ü and Æ
characters.

--Arnt

From: "Neystadt, John" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Date: Thu, 25 Apr 2002 15:47:28 +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_01C1EC57.5B5372F0
Content-Type: text/plain;
	charset="koi8-r"

Hi!

Until now I did not get a comments regarding matter of the draft.

Does it makes sense? What do you think about it?

Regards,

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 1:14 PM
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: IMAP4 rev1 u STATUS-COUNTERS Extension
> 	Author(s)	: J. Neystadt
> 	Filename	: draft-neystadt-imap-status-counters-00.txt
> 	Pages		: 7
> 	Date		: 22-Apr-02
> 	
> This document describes STATUS-COUNTERS extension to IMAP4rev1 
> protocol. This extension enables Mail User Agents to retrieve 
> messages counters grouped by message context.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/
> 	draft-neystadt-imap-status-counters-00.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-neystadt-imap-status-counters-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE 
> /internet-drafts/draft-neystadt-imap-status-counters-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

------_=_NextPart_001_01C1EC57.5B5372F0
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>Hi!</FONT>
</P>

<P><FONT SIZE=3D2>Until now I did not get a comments regarding matter =
of the draft.</FONT>
</P>

<P><FONT SIZE=3D2>Does it makes sense? What do you think about =
it?</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</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>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, April 23, 2002 1:14 PM</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: I-D =
ACTION:draft-neystadt-imap-status-counters-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A New Internet-Draft is available from the =
on-line </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts directories.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : IMAP4 =
rev1 u STATUS-COUNTERS Extension</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : J. Neystadt</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-neystadt-imap-status-counters-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 7</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Date&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
22-Apr-02</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; This document describes STATUS-COUNTERS =
extension to IMAP4rev1 </FONT>
<BR><FONT SIZE=3D2>&gt; protocol. This extension enables Mail User =
Agents to retrieve </FONT>
<BR><FONT SIZE=3D2>&gt; messages counters grouped by message =
context.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/</A></FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-neystadt-imap-status-counters-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To remove yourself from the IETF Announcement =
list, send a message to </FONT>
<BR><FONT SIZE=3D2>&gt; ietf-announce-request with the word unsubscribe =
in the body </FONT>
<BR><FONT SIZE=3D2>&gt; of the message.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts are also available by anonymous =
FTP. Login </FONT>
<BR><FONT SIZE=3D2>&gt; with the username</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;anonymous&quot; and a password of your =
e-mail address. After logging in,</FONT>
<BR><FONT SIZE=3D2>&gt; type &quot;cd internet-drafts&quot; and =
then</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;get =
draft-neystadt-imap-status-counters-00.txt&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A list of Internet-Drafts directories can be =
found in</FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT SIZE=3D2>&gt; or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts can also be obtained by =
e-mail.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Send a message to:</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked].</FONT>
<BR><FONT SIZE=3D2>&gt; In the body type:</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FILE =
</FONT>
<BR><FONT SIZE=3D2>&gt; =
/internet-drafts/draft-neystadt-imap-status-counters-00.txt&quot;.</FONT=
>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; NOTE: The mail server at ietf.org can return =
the document in</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded =
form by using the &quot;mpack&quot; utility.&nbsp; To use this</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert =
the command &quot;ENCODING mime&quot; before the =
&quot;FILE&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; =
To decode the response(s), you will need &quot;munpack&quot; or</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant =
mail reader.&nbsp; Different MIME-compliant </FONT>
<BR><FONT SIZE=3D2>&gt; mail readers</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit =
different behavior, especially when dealing with</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;multipart&quot; MIME messages (i.e. documents which have been =
split</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple =
messages), so check your local documentation on</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to =
manipulate these messages.</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Below is the data which will enable a MIME =
compliant mail reader</FONT>
<BR><FONT SIZE=3D2>&gt; implementation to automatically retrieve the =
ASCII version of the</FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Draft.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1EC57.5B5372F0--

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Date: Tue, 23 Apr 2002 07:14:07 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 rev1 û STATUS-COUNTERS Extension
	Author(s)	: J. Neystadt
	Filename	: draft-neystadt-imap-status-counters-00.txt
	Pages		: 7
	Date		: 22-Apr-02
	
This document describes STATUS-COUNTERS extension to IMAP4rev1 
protocol. This extension enables Mail User Agents to retrieve 
messages counters grouped by message context.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-neystadt-imap-status-counters-00.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-neystadt-imap-status-counters-00.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-neystadt-imap-status-counters-00.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 16 Apr 2002 15:17:32 -0400
From: Lawrence Greenfield <[email-masked]>
To: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION   to Proposed Standard
Sender: [email-masked]

   Date: Tue, 16 Apr 2002 05:20:00 -0600
   From: Alexey Melnikov <[email-masked]>
   Organization: ACI WorldWide / MessagingDirect

   Mark Crispin wrote:

   > I believe that the underlying problem is with RFC 2359 (which the
   > IESG has already accepted as a Proposed Standard), and not with
   > the MULTIAPPEND extension.  The section entitled "MULTIAPPEND
   > Interaction with UIDPLUS Extension" in the MULTIAPPEND extension
   > is solely to document how MULTIAPPEND works with RFC 2359.

   IMHO, I think you should keep this section as there is currently no
   revision of RFC 2359.

I agree.  MULTIAPPEND is actually useless to me without UIDPLUS.  I
would be unhappy if the "Interactions with UIDPLUS" section was
removed.

[...]
   I will be happy if MULTIAPPEND clarifies that "m:n" is allowed in
   APPENDUID response. Yes, this follows from the syntax, but this
   might not occur to client impelementors. An example would be handy
   and as well as saying that "m:n" must not be sent by server if m>n.

Yes, I agree with this.  Making this clear is useful and doesn't hurt
the specification in any way.

Larry

Date: Tue, 16 Apr 2002 05:20:00 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION   to Proposed Standard
Sender: [email-masked]

Mark Crispin wrote:

> I have read and considered Alexey's comment.
>
> I believe that the underlying problem is with RFC 2359 (which the IESG has
> already accepted as a Proposed Standard), and not with the MULTIAPPEND
> extension.  The section entitled "MULTIAPPEND Interaction with UIDPLUS
> Extension" in the MULTIAPPEND extension is solely to document how MULTIAPPEND
> works with RFC 2359.

IMHO, I think you should keep this section as there is currently no revision of
RFC 2359.

> If Alexey's concerns are valid, these concerns are with RFC 2359 (as he notes
> in his postscript ("The same problem exists with COPYUID response code
> described in UIDPLUS extension").  If so, then the proper action is to block
> further standards-track advancement of RFC 2359 until this problem is fixed in
> a revision to RFC 2359.  The MULTIAPPEND extension can be published by
> eliminating the entire section entitled "MULTIAPPEND Interaction with UIDPLUS
> Extension", and require that the revision to RFC 2359 document how UIDPLUS
> should work in the MULTIAPPEND extension.
>
> Disclaimer: I do not implement the UIDPLUS extension, so it's of little
> consequence to me if it is blocked.  It is, however, of great consequence if
> MULTIAPPEND is blocked since MULTIAPPEND is a major performace and
> functionality boost.
>
> I am not convinced that Alexey's concerns are valid.
>
> Given his example of
>         a001 OK [APPENDUID 31345 10121:10117] Multiappend completed.
> his possible interpretation of
>         #1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n)
> is forbidden by RFC 2060, section 2.3.1.1:
>    [...]  Unique identifiers are assigned in a strictly ascending
>    fashion in the mailbox; as each message is added to the mailbox it is
>    assigned a higher UID than the message(s) which were added
>    previously.

Ok, you might be right for APPENDUID, but my example still stands for COPYUID, as
there is no guaranty in which order server will perform COPY of a set of messages.
Arguably MULTIAPPEND can be considered as a series of APPENDs in the order
messages were specified. On the other hand MULTIAPPEND is atomic, so server can
assign UIDs in any order it likes ;-).

I will be happy if MULTIAPPEND clarifies that "m:n" is allowed in APPENDUID
response. Yes, this follows from the syntax, but this might not occur to client
impelementors. An example would be handy and as well as saying that "m:n" must not
be sent by server if m>n.

> This text is unchanged in draft-crispin-imapv-16.txt, the proposed update to
> RFC 2060 which is currently in IESG last call.  Consequently, only the
> interpretation:
>         #1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m)
> is valid.
>
> Furthermore, the specific example ("10121:10117") is silly and in all other
> cases in IMAP is exactly equivalent to 10117:10221.
>
> In conclusion, I do not believe that MULTIAPPEND should be blocked for
> publication by this concern;

I didn't say blocked ;-).

> and if this concern triggers any action it should be in the form of a revision
> to RFC 2359.  Nothing in the MULTIAPPEND extension can define the semantics of
> UIDPLUS behavior; such definition
> belongs in the UIDPLUS extension (RFC 2359 or successor).

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

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

Date: Mon, 15 Apr 2002 10:55:57 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION  to Proposed Standard
To: Alexey Melnikov <[email-masked]>
cc: [email-masked], IMAP Extensions WG <[email-masked]>, Lawrence Greenfield <[email-masked]>
Sender: [email-masked]

I have read and considered Alexey's comment.

I believe that the underlying problem is with RFC 2359 (which the IESG has
already accepted as a Proposed Standard), and not with the MULTIAPPEND
extension.  The section entitled "MULTIAPPEND Interaction with UIDPLUS
Extension" in the MULTIAPPEND extension is solely to document how MULTIAPPEND
works with RFC 2359.

If Alexey's concerns are valid, these concerns are with RFC 2359 (as he notes
in his postscript ("The same problem exists with COPYUID response code
described in UIDPLUS extension").  If so, then the proper action is to block
further standards-track advancement of RFC 2359 until this problem is fixed in
a revision to RFC 2359.  The MULTIAPPEND extension can be published by
eliminating the entire section entitled "MULTIAPPEND Interaction with UIDPLUS
Extension", and require that the revision to RFC 2359 document how UIDPLUS
should work in the MULTIAPPEND extension.

Disclaimer: I do not implement the UIDPLUS extension, so it's of little
consequence to me if it is blocked.  It is, however, of great consequence if
MULTIAPPEND is blocked since MULTIAPPEND is a major performace and
functionality boost.

I am not convinced that Alexey's concerns are valid.

Given his example of
	a001 OK [APPENDUID 31345 10121:10117] Multiappend completed.
his possible interpretation of
	#1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n)
is forbidden by RFC 2060, section 2.3.1.1:
   [...]  Unique identifiers are assigned in a strictly ascending
   fashion in the mailbox; as each message is added to the mailbox it is
   assigned a higher UID than the message(s) which were added
   previously.
This text is unchanged in draft-crispin-imapv-16.txt, the proposed update to
RFC 2060 which is currently in IESG last call.  Consequently, only the
interpretation:
	#1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m)
is valid.

Furthermore, the specific example ("10121:10117") is silly and in all other
cases in IMAP is exactly equivalent to 10117:10221.

In conclusion, I do not believe that MULTIAPPEND should be blocked for
publication by this concern; and if this concern triggers any action it should
be in the form of a revision to RFC 2359.  Nothing in the MULTIAPPEND
extension can define the semantics of UIDPLUS behavior; such definition
belongs in the UIDPLUS extension (RFC 2359 or successor).

-- Mark --

Date: Sun, 14 Apr 2002 15:33:35 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
CC: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION  to Proposed Standard
Sender: [email-masked]

The IESG wrote:

> The IESG has received a request to consider INTERNET MESSAGE ACCESS
> PROTOCOL - MULTIAPPEND EXTENSION
> <draft-crispin-imap-multiappend-05.txt> as a Proposed Standard. This
> has been reviewed in the IETF but is not the product of an IETF Working
> Group.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by April 24, 2002.
>
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-05.txt

(I've sent this comment to Mark privately and he suggested that I post the
comment on the imapext mailing list).
I have a comment about MULTIAPPEND document regarding the section that
defines interaction with UIDPLUS extension:

>MULTIAPPEND Interaction with UIDPLUS Extension
>
>   Servers which support both MULTIAPPEND and [UIDPLUS] will have the
>   "resp-code-apnd" rule modified as follows:
>
>   resp-code-apnd  = "APPENDUID" SP nz-number SP set
>
>   That is, the APPENDUID response code returns as many UIDs as there
>   were messages appended in the multiple append.  The UIDs returned
>   should be in the order the articles where appended.  The message set
>   may not contain extraneous UIDs or the symbol "*".

Unfortunately even with restrictions in the last paragraph, the ABNF for
"set" still allows for ambiguous cases.
Set can be a comma delimited list of numbers (e.g. "10117,10118,10119" [case
1: a,b,c]), a range construct (e.g. "10117:10119" [case 2: m:n, m < n] or
"10119:10117" [case 3: "m:n", m >= n]) or a combination of those.
Lets consider the following example. Client appended 4 messages and server
support both MULTIAPPEND and UIDPLUS.
Server can return [case 1]:

a001 OK [APPENDUID 31345 10117,10118,10119,10120,10121] Multiappend
completed.

and this has a well understood semantics, i.e. appended message #1 gets UID
10117, #2 - 10118, ..., #5 - 10121

Some implementations (including CMU Cyrus server) will use "compressed"
representation of this set to minimize amount of data sent across network
[case 2]:
a001 OK [APPENDUID 31345 10117:10121] Multiappend completed.

and this seems to be a logical extension of the previous.

Now, it is not clear what client is supposed to do if the server decides to
return the following [case 3]:

a001 OK [APPENDUID 31345 10121:10117] Multiappend completed.

One possible interpretation:
#1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n)

Another possible interpretation:
#1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m)

I suggest that the case 3 is either explicitly prohibited or the document
clarifies how the client should interpret the result.

Regards,
Alexey Melnikov

P.S. The same problem exists with COPYUID response code described in UIDPLUS
extension.
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

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

Date: Tue, 2 Apr 2002 11:23:22 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Jutta Degener <[email-masked]>
cc: [email-masked]
Subject: Re: ACL 2: Why $ and not / ?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 2 Apr 2002, Jutta Degener wrote:
> Why did <draft-ietf-imapext-acl-03.txt> choose "$" as a
> prefix character and not "/" as in RFC 2244 (ACAP)?

It was more or less selected out of the air.  I originally advocated $,
but I would not quarrel if it became something else.  My main interest is
in there being a formal and unambiguous theory of ACL identifiers (one
which does not overlap the world identifier with a user named "anyone"),
rather than picking a particular character.

-- Mark --

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

Date: Tue, 2 Apr 2002 06:03:10 -0800
From: Jutta Degener <[email-masked]>
To: [email-masked]
Subject: ACL 2: Why $ and not / ?
Sender: [email-masked]

Why did <draft-ietf-imapext-acl-03.txt> choose "$" as a
prefix character and not "/" as in RFC 2244 (ACAP)?

Granted, "/" is fixed as a hierarchy separator in ACAP and
not in IMAP, but isn't it still a _common_ hierarchy separator
in IMAP? It's certainly more popular, and more frequently
excluded from user names, than "$".

Is there a user name scheme that IMAP is trying to support
where identifiers do start with "/"?

If not, wouldn't it be desirable to keep the number of
different user name encoding schemes low and perhaps align
ACL2 with ACAP?

Jutta Degener
<[email-masked]>

Date: Tue, 30 Apr 2002 14:48:30 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, John Neystadt <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

Hi,

--On Friday, April 26, 2002 6:30 PM -0700 Mark Crispin
<[email-masked]> wrote:

| I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as
| much as possible rather than try to extend STATUS.  One thing that you
| could try to do is use STATUS to identify whether a mailbox should be
| subject to more detailed examination with SELECT+SEARCH.  That was the
| original intent behind STATUS; to enable identification of "interesting"
| mailboxes without having to SELECT them.

This is a good point. Here is my take on this:

If the user is only likely to be interested in one or two mailboxes, then
its perfectly feasible to allow EXAMINE+IDLE+SEARCH style notifications to
be done by the client. If you are dealing with tens to hundreds of
mailboxes then status polling is OK, provided there is not too much extra
data in the status response. Mark's suggestion of having a simple indicator
to go look at the mailbox in more detail is reasonable for this
application. 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.

-- 
Cyrus Daboo

Reply-To: <[email-masked]>
From: "Eric Burger" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Date: Tue, 30 Apr 2002 14:13:52 -0400
Importance: Normal
Sender: [email-masked]

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.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Mark Crispin
Sent: Friday, April 26, 2002 9:31 PM
To: John Neystadt
Cc: [email-masked]; [email-masked]
Subject: [VPIM] Re: I-D
ACTION:draft-neystadt-imap-status-counters-00.txt

[snip]
The more that you leverage existing tools, as opposed to requiring the
creation of new tools, the better able you'll be able to deploy.  Ideally,
given 100% leverage, you'll be able to run your VPIM client software
with any IMAP server; you may desire to have a special IMAP server that is
optimized for VPIM, but there is an attraction to being able to plug in
with any server.

What concerns me is the possibility of making VPIM clients excessively
and unnecessarily dependent upon a VPIM-extended server.  This doesn't
mean "thou shalt not extend IMAP for VPIM under any circumstances"!!  It
does, however, suggest that you should leverage aggressively and extend
IMAP only if there's no way to leverage.

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.

Date: Mon, 29 Apr 2002 14:03:17 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Neystadt, John" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

"Neystadt, John" <[email-masked]>
> This is today handled on clients and is used to display counters either in
> folders tree or on some general summary screen. 
> There are two main benefits of moving this logic to server:
> 
> - in order to build them you must screen all message headers in the mailbox,
> this is very slow and traffic intensive if done on client

That sounds as if you're using FETCH HEADER.FIELDS() or something today.
If that's true, I can certaing agree that a change is desirable ;)

However, a SEARCH should avoid network traffic almost completely, cut down
on the amount of the client must do, and be at least as good for the
server. (I'm assuming that on a server, searching for flags will be at
least as fast as downloading all messages - usually quite a bit faster.)

> - server can store the counters and then incrementally update the counters
> when new messages are delivered (in MTA) or expunged and server do different
> clients. This saves much of processing power for servers.

Well, maybe. OTOH, most server authors might not want to write code to
speed unusual special cases, and then the VPIM client has to the slow code
anyway.

If you need an extension, better try to design it so that a lot of clients
will benefit from it and the incentive to implement it is correspondingly
strong.

--Arnt

Date: Mon, 29 Apr 2002 13:51:41 +0200
From: Arnt Gulbrandsen <[email-masked]>
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)" <[email-masked]>
> Is there any objection to a new flag with explicit semantics of importance?
> The meaning of \flagged is private between a client and it's store.  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.

This assumes that current-day clients use \flagged in different ways. Is
that indeed so? Every client I've seen seems to either ignore it or treat
it as a "must look at this message" flag.

--Arnt

Date: Sun, 28 Apr 2002 21:19:05 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
To: "Vaudreuil, Greg M (Greg)" <[email-masked]>
cc: John Neystadt <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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.

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: Mark Crispin <[email-masked]>, John Neystadt <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [VPIM] Re: I-D ACTION:draft-neystadt-imap-status-counters-00. txt
Date: Sun, 28 Apr 2002 20:54:15 -0600
Sender: [email-masked]

Is there any objection to a new flag with explicit semantics of importance?
The meaning of \flagged is private between a client and it's store.  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.  

Greg V.

-----Original Message-----
From: Mark Crispin [mailto:[email-masked]]
Sent: Friday, April 26, 2002 8:31 PM
To: John Neystadt
Cc: [email-masked]; [email-masked]
Subject: [VPIM] Re: I-D
ACTION:draft-neystadt-imap-status-counters-00.txt

On Fri, 26 Apr 2002, John Neystadt wrote:
> 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 are other uses for
it
> today?

What \Flagged does is client-dependent, but the basic idea is to mark some
kind of "importance" emphasis on the message.  In the original MM program
on the DEC-20, flagged messages were always announced with every new mail
announcement.  In more modern message-browser type programs, flagged
messages are drawn with a box around them or in a bold font or with some
sort of highlighting color to call attention to it.

Since VPIM is essentially a client application, it is perfectly within its
rights to decide that \Flagged means "Important" in the VPIM context, and
to decide that the MDA should turn on \Flagged on all messages which have
"Importance: High" in the header.  In fact, I could see some non-VPIM
users wanting to do that in the MDA.

I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as
much as possible rather than try to extend STATUS.  One thing that you
could try to do is use STATUS to identify whether a mailbox should be
subject to more detailed examination with SELECT+SEARCH.  That was the
original intent behind STATUS; to enable identification of "interesting"
mailboxes without having to SELECT them.

The more that you leverage existing tools, as opposed to requiring the
creation of new tools, the better able you'll be able to deploy.  Ideally,
given 100% leverage, you'll be able to run your VPIM client software
with any IMAP server; you may desire to have a special IMAP server that is
optimized for VPIM, but there is an attraction to being able to plug in
with any server.

What concerns me is the possibility of making VPIM clients excessively
and unnecessarily dependent upon a VPIM-extended server.  This doesn't
mean "thou shalt not extend IMAP for VPIM under any circumstances"!!  It
does, however, suggest that you should leverage aggressively and extend
IMAP only if there's no way to leverage.

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.

-- Mark --

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

"A single glass of champagne imparts a feeling of exhiliaration.  The
nerves are braced; the imagination is agreeably strirred; the wits become
more nimble.  A bottle produces a contrary effect.  Excess causes a
comatose insensibility.  So it is with war; and the quality of both is
best discovered by sipping."  -- Winston Churchill

----------------------------------------------------------
This message was sent to you, since you are subscribed to
[email-masked]. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo

From: "Neystadt, John" <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Date: Sun, 28 Apr 2002 10:27:39 +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_01C1EE86.2D40BBD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> In draft-1, could you the non-ascii junk? I see various =FC and =C6
> characters.

I was told already, I've used winword template that produced this junk =
:(
I'll clean it up.

> It seems unjustified. You mention one application for it, and=20
> it sounds as
> if the code belongs in that IMAP client. If you think that code =
really
> belongs in IMAP servers, I suggest showing more uses in the draft.

This is today handled on clients and is used to display counters either =
in
folders tree or on some general summary screen.=20
There are two main benefits of moving this logic to server:

- in order to build them you must screen all message headers in the =
mailbox,
this is very slow and traffic intensive if done on client
- server can store the counters and then incrementally update the =
counters
when new messages are delivered (in MTA) or expunged and server do =
different
clients. This saves much of processing power for servers.

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

------_=_NextPart_001_01C1EE86.2D40BBD0
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; In draft-1, could you the non-ascii junk? I see =
various =FC and =C6</FONT>
<BR><FONT SIZE=3D2>&gt; characters.</FONT>
</P>

<P><FONT SIZE=3D2>I was told already, I've used winword template that =
produced this junk :( I'll clean it up.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; It seems unjustified. You mention one =
application for it, and </FONT>
<BR><FONT SIZE=3D2>&gt; it sounds as</FONT>
<BR><FONT SIZE=3D2>&gt; if the code belongs in that IMAP client. If you =
think that code really</FONT>
<BR><FONT SIZE=3D2>&gt; belongs in IMAP servers, I suggest showing more =
uses in the draft.</FONT>
</P>

<P><FONT SIZE=3D2>This is today handled on clients and is used to =
display counters either in folders tree or on some general summary =
screen. </FONT></P>

<P><FONT SIZE=3D2>There are two main benefits of moving this logic to =
server:</FONT>
</P>

<P><FONT SIZE=3D2>- in order to build them you must screen all message =
headers in the mailbox, this is very slow and traffic intensive if done =
on client</FONT></P>

<P><FONT SIZE=3D2>- server can store the counters and then =
incrementally update the counters when new messages are delivered (in =
MTA) or expunged and server do different clients. This saves much of =
processing power for servers.</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_01C1EE86.2D40BBD0--

Date: Fri, 26 Apr 2002 18:30:59 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: John Neystadt <[email-masked]>
cc: [email-masked], <[email-masked]>
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Fri, 26 Apr 2002, John Neystadt wrote:
> 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 are other uses for it
> today?

What \Flagged does is client-dependent, but the basic idea is to mark some
kind of "importance" emphasis on the message.  In the original MM program
on the DEC-20, flagged messages were always announced with every new mail
announcement.  In more modern message-browser type programs, flagged
messages are drawn with a box around them or in a bold font or with some
sort of highlighting color to call attention to it.

Since VPIM is essentially a client application, it is perfectly within its
rights to decide that \Flagged means "Important" in the VPIM context, and
to decide that the MDA should turn on \Flagged on all messages which have
"Importance: High" in the header.  In fact, I could see some non-VPIM
users wanting to do that in the MDA.

I agree with Arnt Gulbrandsen that you should try to leverage SEARCH as
much as possible rather than try to extend STATUS.  One thing that you
could try to do is use STATUS to identify whether a mailbox should be
subject to more detailed examination with SELECT+SEARCH.  That was the
original intent behind STATUS; to enable identification of "interesting"
mailboxes without having to SELECT them.

The more that you leverage existing tools, as opposed to requiring the
creation of new tools, the better able you'll be able to deploy.  Ideally,
given 100% leverage, you'll be able to run your VPIM client software
with any IMAP server; you may desire to have a special IMAP server that is
optimized for VPIM, but there is an attraction to being able to plug in
with any server.

What concerns me is the possibility of making VPIM clients excessively
and unnecessarily dependent upon a VPIM-extended server.  This doesn't
mean "thou shalt not extend IMAP for VPIM under any circumstances"!!  It
does, however, suggest that you should leverage aggressively and extend
IMAP only if there's no way to leverage.

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.

-- Mark --

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

"A single glass of champagne imparts a feeling of exhiliaration.  The
nerves are braced; the imagination is agreeably strirred; the wits become
more nimble.  A bottle produces a contrary effect.  Excess causes a
comatose insensibility.  So it is with war; and the quality of both is
best discovered by sipping."  -- Winston Churchill

Date: Fri, 26 Apr 2002 11:18:12 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: John Neystadt <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

John Neystadt <[email-masked]>
> C: STATUS abc COUNTERS[(\Seen AND $Fax-Message) (\Seen AND \Flagged AND
> $Fax-Message) ...]
> 
> This is long and somewhat cumbersome.

That sounds like a few SEARCH commands joined together and renamed to
STATUS. Perhaps using SEARCH (and maybe ANNOTATE) is enough?

SEARCH may not scale as well as STATUS-COUNTERS would, but in this case I
don't think that's a problem:  "You have 1042300533 messages, 32765355 new
and 42523145 important" is a nightmare no matter of efficiently it's
implemented ;)

--Arnt

Date: Fri, 26 Apr 2002 10:53:19 +0200
From: John Neystadt <[email-masked]>
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
To: Mark Crispin <[email-masked]>
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Hello,

> It certainly does seem to be very much specialized for VPIM, and doesn't
seem
> to make adequate attempt to leverage existing mechanisms.  For example,
why
> not use IMAP keyword flags in association with delivery mechanisms that
set
> those flags, and then just extend STATUS to count other flags besides
\Recent
> and (not) \Seen.

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 are other uses for it
today?

Now there is a problem with Message-Context - since it is an extensible list
of values (new ones can be added ad-hoc) then message flags will have to be
added per each of them each time new values are added. In my proposal server
sends response per all detected Message-Contexts. In your way we will have
to introduce some mechanism for MUA to enumerate them. In additoin flags are
not "typed" so MUA can't distinuigh between say $MDNSent and $Fax-Message
which is confusing.

Another issue is that \Seen changes dynamically. So in order to query for
counter of \Seen fax messgase we will have to pass a boolean expression of
flags to this new STATUS extension. For example:

C: STATUS abc COUNTERS[(\Seen AND $Fax-Message) (\Seen AND \Flagged AND
$Fax-Message) ...]

This is long and somewhat cumbersome.

> > In draft-1, could you the non-ascii junk? I see various | and F
> > characters.
>
> I have to echo this comment; I don't know what produced that junk but it
is
> there and it is annoying.

I apologize again.

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

Date: Thu, 25 Apr 2002 13:05:51 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
To: Arnt Gulbrandsen <[email-masked]>
cc: "Neystadt, John" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

On Thu, 25 Apr 2002 15:18:01 +0200, Arnt Gulbrandsen wrote:
> "Neystadt, John" <[email-masked]>
> > Until now I did not get a comments regarding matter of the draft.
> >
> > Does it makes sense? What do you think about it?
>
> It seems unjustified. You mention one application for it, and it sounds as
> if the code belongs in that IMAP client. If you think that code really
> belongs in IMAP servers, I suggest showing more uses in the draft.

It certainly does seem to be very much specialized for VPIM, and doesn't seem
to make adequate attempt to leverage existing mechanisms.  For example, why
not use IMAP keyword flags in association with delivery mechanisms that set
those flags, and then just extend STATUS to count other flags besides \Recent
and (not) \Seen.

Regardless of whether this extension is intended for general implementation,
or only for implementation in special VPIM boxes, I think that greater
leveraging of existing IMAP mechanisms is desirable.  In the general
implementation case, it is to create a reason for it to be implemented; in the
VPIM-only cases, it is because there's no harm in doing so.

On the other hand, the intended implementation audience may make a difference
on, for example, whether or not \Flagged can be used to implement "Important".
But that's a minor issue in the overall scope of things.

To summarize: you may have a good case to expand STATUS to return other data;
but you have not (yet) made a good case to create new classes of data since it
is conjectured that the desired information can be represented with existing
data.  In particular, please give strong consideration to using keyword flags.

> In draft-1, could you the non-ascii junk? I see various | and F
> characters.

I have to echo this comment; I don't know what produced that junk but it is
there and it is annoying.

Date: Thu, 25 Apr 2002 15:18:01 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Neystadt, John" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Sender: [email-masked]

"Neystadt, John" <[email-masked]>
> Until now I did not get a comments regarding matter of the draft.
> 
> Does it makes sense? What do you think about it?

It seems unjustified. You mention one application for it, and it sounds as
if the code belongs in that IMAP client. If you think that code really
belongs in IMAP servers, I suggest showing more uses in the draft.

In draft-1, could you the non-ascii junk? I see various ü and Æ
characters.

--Arnt

From: "Neystadt, John" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Date: Thu, 25 Apr 2002 15:47:28 +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_01C1EC57.5B5372F0
Content-Type: text/plain;
	charset="koi8-r"

Hi!

Until now I did not get a comments regarding matter of the draft.

Does it makes sense? What do you think about it?

Regards,

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 1:14 PM
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: IMAP4 rev1 u STATUS-COUNTERS Extension
> 	Author(s)	: J. Neystadt
> 	Filename	: draft-neystadt-imap-status-counters-00.txt
> 	Pages		: 7
> 	Date		: 22-Apr-02
> 	
> This document describes STATUS-COUNTERS extension to IMAP4rev1 
> protocol. This extension enables Mail User Agents to retrieve 
> messages counters grouped by message context.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/
> 	draft-neystadt-imap-status-counters-00.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-neystadt-imap-status-counters-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE 
> /internet-drafts/draft-neystadt-imap-status-counters-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

------_=_NextPart_001_01C1EC57.5B5372F0
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>Hi!</FONT>
</P>

<P><FONT SIZE=3D2>Until now I did not get a comments regarding matter =
of the draft.</FONT>
</P>

<P><FONT SIZE=3D2>Does it makes sense? What do you think about =
it?</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</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>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, April 23, 2002 1:14 PM</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: I-D =
ACTION:draft-neystadt-imap-status-counters-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A New Internet-Draft is available from the =
on-line </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts directories.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : IMAP4 =
rev1 u STATUS-COUNTERS Extension</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : J. Neystadt</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-neystadt-imap-status-counters-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 7</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Date&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
22-Apr-02</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; This document describes STATUS-COUNTERS =
extension to IMAP4rev1 </FONT>
<BR><FONT SIZE=3D2>&gt; protocol. This extension enables Mail User =
Agents to retrieve </FONT>
<BR><FONT SIZE=3D2>&gt; messages counters grouped by message =
context.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/</A></FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
draft-neystadt-imap-status-counters-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To remove yourself from the IETF Announcement =
list, send a message to </FONT>
<BR><FONT SIZE=3D2>&gt; ietf-announce-request with the word unsubscribe =
in the body </FONT>
<BR><FONT SIZE=3D2>&gt; of the message.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts are also available by anonymous =
FTP. Login </FONT>
<BR><FONT SIZE=3D2>&gt; with the username</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;anonymous&quot; and a password of your =
e-mail address. After logging in,</FONT>
<BR><FONT SIZE=3D2>&gt; type &quot;cd internet-drafts&quot; and =
then</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;get =
draft-neystadt-imap-status-counters-00.txt&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A list of Internet-Drafts directories can be =
found in</FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT SIZE=3D2>&gt; or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Drafts can also be obtained by =
e-mail.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Send a message to:</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[email-masked].</FONT>
<BR><FONT SIZE=3D2>&gt; In the body type:</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;FILE =
</FONT>
<BR><FONT SIZE=3D2>&gt; =
/internet-drafts/draft-neystadt-imap-status-counters-00.txt&quot;.</FONT=
>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; NOTE: The mail server at ietf.org can return =
the document in</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded =
form by using the &quot;mpack&quot; utility.&nbsp; To use this</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert =
the command &quot;ENCODING mime&quot; before the =
&quot;FILE&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; =
To decode the response(s), you will need &quot;munpack&quot; or</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant =
mail reader.&nbsp; Different MIME-compliant </FONT>
<BR><FONT SIZE=3D2>&gt; mail readers</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit =
different behavior, especially when dealing with</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;multipart&quot; MIME messages (i.e. documents which have been =
split</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple =
messages), so check your local documentation on</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to =
manipulate these messages.</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Below is the data which will enable a MIME =
compliant mail reader</FONT>
<BR><FONT SIZE=3D2>&gt; implementation to automatically retrieve the =
ASCII version of the</FONT>
<BR><FONT SIZE=3D2>&gt; Internet-Draft.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1EC57.5B5372F0--

To: IETF-Announce: ;
CC: [email-masked], [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-neystadt-imap-status-counters-00.txt
Date: Tue, 23 Apr 2002 07:14:07 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 rev1 û STATUS-COUNTERS Extension
	Author(s)	: J. Neystadt
	Filename	: draft-neystadt-imap-status-counters-00.txt
	Pages		: 7
	Date		: 22-Apr-02
	
This document describes STATUS-COUNTERS extension to IMAP4rev1 
protocol. This extension enables Mail User Agents to retrieve 
messages counters grouped by message context.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-neystadt-imap-status-counters-00.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-neystadt-imap-status-counters-00.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-neystadt-imap-status-counters-00.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 16 Apr 2002 15:17:32 -0400
From: Lawrence Greenfield <[email-masked]>
To: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, [email-masked]
Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION   to Proposed Standard
Sender: [email-masked]

   Date: Tue, 16 Apr 2002 05:20:00 -0600
   From: Alexey Melnikov <[email-masked]>
   Organization: ACI WorldWide / MessagingDirect

   Mark Crispin wrote:

   > I believe that the underlying problem is with RFC 2359 (which the
   > IESG has already accepted as a Proposed Standard), and not with
   > the MULTIAPPEND extension.  The section entitled "MULTIAPPEND
   > Interaction with UIDPLUS Extension" in the MULTIAPPEND extension
   > is solely to document how MULTIAPPEND works with RFC 2359.

   IMHO, I think you should keep this section as there is currently no
   revision of RFC 2359.

I agree.  MULTIAPPEND is actually useless to me without UIDPLUS.  I
would be unhappy if the "Interactions with UIDPLUS" section was
removed.

[...]
   I will be happy if MULTIAPPEND clarifies that "m:n" is allowed in
   APPENDUID response. Yes, this follows from the syntax, but this
   might not occur to client impelementors. An example would be handy
   and as well as saying that "m:n" must not be sent by server if m>n.

Yes, I agree with this.  Making this clear is useful and doesn't hurt
the specification in any way.

Larry

Date: Tue, 16 Apr 2002 05:20:00 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION   to Proposed Standard
Sender: [email-masked]

Mark Crispin wrote:

> I have read and considered Alexey's comment.
>
> I believe that the underlying problem is with RFC 2359 (which the IESG has
> already accepted as a Proposed Standard), and not with the MULTIAPPEND
> extension.  The section entitled "MULTIAPPEND Interaction with UIDPLUS
> Extension" in the MULTIAPPEND extension is solely to document how MULTIAPPEND
> works with RFC 2359.

IMHO, I think you should keep this section as there is currently no revision of
RFC 2359.

> If Alexey's concerns are valid, these concerns are with RFC 2359 (as he notes
> in his postscript ("The same problem exists with COPYUID response code
> described in UIDPLUS extension").  If so, then the proper action is to block
> further standards-track advancement of RFC 2359 until this problem is fixed in
> a revision to RFC 2359.  The MULTIAPPEND extension can be published by
> eliminating the entire section entitled "MULTIAPPEND Interaction with UIDPLUS
> Extension", and require that the revision to RFC 2359 document how UIDPLUS
> should work in the MULTIAPPEND extension.
>
> Disclaimer: I do not implement the UIDPLUS extension, so it's of little
> consequence to me if it is blocked.  It is, however, of great consequence if
> MULTIAPPEND is blocked since MULTIAPPEND is a major performace and
> functionality boost.
>
> I am not convinced that Alexey's concerns are valid.
>
> Given his example of
>         a001 OK [APPENDUID 31345 10121:10117] Multiappend completed.
> his possible interpretation of
>         #1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n)
> is forbidden by RFC 2060, section 2.3.1.1:
>    [...]  Unique identifiers are assigned in a strictly ascending
>    fashion in the mailbox; as each message is added to the mailbox it is
>    assigned a higher UID than the message(s) which were added
>    previously.

Ok, you might be right for APPENDUID, but my example still stands for COPYUID, as
there is no guaranty in which order server will perform COPY of a set of messages.
Arguably MULTIAPPEND can be considered as a series of APPENDs in the order
messages were specified. On the other hand MULTIAPPEND is atomic, so server can
assign UIDs in any order it likes ;-).

I will be happy if MULTIAPPEND clarifies that "m:n" is allowed in APPENDUID
response. Yes, this follows from the syntax, but this might not occur to client
impelementors. An example would be handy and as well as saying that "m:n" must not
be sent by server if m>n.

> This text is unchanged in draft-crispin-imapv-16.txt, the proposed update to
> RFC 2060 which is currently in IESG last call.  Consequently, only the
> interpretation:
>         #1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m)
> is valid.
>
> Furthermore, the specific example ("10121:10117") is silly and in all other
> cases in IMAP is exactly equivalent to 10117:10221.
>
> In conclusion, I do not believe that MULTIAPPEND should be blocked for
> publication by this concern;

I didn't say blocked ;-).

> and if this concern triggers any action it should be in the form of a revision
> to RFC 2359.  Nothing in the MULTIAPPEND extension can define the semantics of
> UIDPLUS behavior; such definition
> belongs in the UIDPLUS extension (RFC 2359 or successor).

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

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

Date: Mon, 15 Apr 2002 10:55:57 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION  to Proposed Standard
To: Alexey Melnikov <[email-masked]>
cc: [email-masked], IMAP Extensions WG <[email-masked]>, Lawrence Greenfield <[email-masked]>
Sender: [email-masked]

I have read and considered Alexey's comment.

I believe that the underlying problem is with RFC 2359 (which the IESG has
already accepted as a Proposed Standard), and not with the MULTIAPPEND
extension.  The section entitled "MULTIAPPEND Interaction with UIDPLUS
Extension" in the MULTIAPPEND extension is solely to document how MULTIAPPEND
works with RFC 2359.

If Alexey's concerns are valid, these concerns are with RFC 2359 (as he notes
in his postscript ("The same problem exists with COPYUID response code
described in UIDPLUS extension").  If so, then the proper action is to block
further standards-track advancement of RFC 2359 until this problem is fixed in
a revision to RFC 2359.  The MULTIAPPEND extension can be published by
eliminating the entire section entitled "MULTIAPPEND Interaction with UIDPLUS
Extension", and require that the revision to RFC 2359 document how UIDPLUS
should work in the MULTIAPPEND extension.

Disclaimer: I do not implement the UIDPLUS extension, so it's of little
consequence to me if it is blocked.  It is, however, of great consequence if
MULTIAPPEND is blocked since MULTIAPPEND is a major performace and
functionality boost.

I am not convinced that Alexey's concerns are valid.

Given his example of
	a001 OK [APPENDUID 31345 10121:10117] Multiappend completed.
his possible interpretation of
	#1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n)
is forbidden by RFC 2060, section 2.3.1.1:
   [...]  Unique identifiers are assigned in a strictly ascending
   fashion in the mailbox; as each message is added to the mailbox it is
   assigned a higher UID than the message(s) which were added
   previously.
This text is unchanged in draft-crispin-imapv-16.txt, the proposed update to
RFC 2060 which is currently in IESG last call.  Consequently, only the
interpretation:
	#1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m)
is valid.

Furthermore, the specific example ("10121:10117") is silly and in all other
cases in IMAP is exactly equivalent to 10117:10221.

In conclusion, I do not believe that MULTIAPPEND should be blocked for
publication by this concern; and if this concern triggers any action it should
be in the form of a revision to RFC 2359.  Nothing in the MULTIAPPEND
extension can define the semantics of UIDPLUS behavior; such definition
belongs in the UIDPLUS extension (RFC 2359 or successor).

-- Mark --

Date: Sun, 14 Apr 2002 15:33:35 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
CC: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: Last Call: INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION  to Proposed Standard
Sender: [email-masked]

The IESG wrote:

> The IESG has received a request to consider INTERNET MESSAGE ACCESS
> PROTOCOL - MULTIAPPEND EXTENSION
> <draft-crispin-imap-multiappend-05.txt> as a Proposed Standard. This
> has been reviewed in the IETF but is not the product of an IETF Working
> Group.
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by April 24, 2002.
>
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-crispin-imap-multiappend-05.txt

(I've sent this comment to Mark privately and he suggested that I post the
comment on the imapext mailing list).
I have a comment about MULTIAPPEND document regarding the section that
defines interaction with UIDPLUS extension:

>MULTIAPPEND Interaction with UIDPLUS Extension
>
>   Servers which support both MULTIAPPEND and [UIDPLUS] will have the
>   "resp-code-apnd" rule modified as follows:
>
>   resp-code-apnd  = "APPENDUID" SP nz-number SP set
>
>   That is, the APPENDUID response code returns as many UIDs as there
>   were messages appended in the multiple append.  The UIDs returned
>   should be in the order the articles where appended.  The message set
>   may not contain extraneous UIDs or the symbol "*".

Unfortunately even with restrictions in the last paragraph, the ABNF for
"set" still allows for ambiguous cases.
Set can be a comma delimited list of numbers (e.g. "10117,10118,10119" [case
1: a,b,c]), a range construct (e.g. "10117:10119" [case 2: m:n, m < n] or
"10119:10117" [case 3: "m:n", m >= n]) or a combination of those.
Lets consider the following example. Client appended 4 messages and server
support both MULTIAPPEND and UIDPLUS.
Server can return [case 1]:

a001 OK [APPENDUID 31345 10117,10118,10119,10120,10121] Multiappend
completed.

and this has a well understood semantics, i.e. appended message #1 gets UID
10117, #2 - 10118, ..., #5 - 10121

Some implementations (including CMU Cyrus server) will use "compressed"
representation of this set to minimize amount of data sent across network
[case 2]:
a001 OK [APPENDUID 31345 10117:10121] Multiappend completed.

and this seems to be a logical extension of the previous.

Now, it is not clear what client is supposed to do if the server decides to
return the following [case 3]:

a001 OK [APPENDUID 31345 10121:10117] Multiappend completed.

One possible interpretation:
#1 gets UID 10121, #2 - 10120, ..., #5 - 10117 (i.e. m, m-1,m-2,...,n)

Another possible interpretation:
#1 gets UID 10117, #2 - 10118, ..., #5 - 10121 (i.e. n, n+1,n+2,...,m)

I suggest that the case 3 is either explicitly prohibited or the document
clarifies how the client should interpret the result.

Regards,
Alexey Melnikov

P.S. The same problem exists with COPYUID response code described in UIDPLUS
extension.
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Richmond, Surrey, UK
Phone: +44 20 8332 4508

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

Date: Tue, 2 Apr 2002 11:23:22 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Jutta Degener <[email-masked]>
cc: [email-masked]
Subject: Re: ACL 2: Why $ and not / ?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 2 Apr 2002, Jutta Degener wrote:
> Why did <draft-ietf-imapext-acl-03.txt> choose "$" as a
> prefix character and not "/" as in RFC 2244 (ACAP)?

It was more or less selected out of the air.  I originally advocated $,
but I would not quarrel if it became something else.  My main interest is
in there being a formal and unambiguous theory of ACL identifiers (one
which does not overlap the world identifier with a user named "anyone"),
rather than picking a particular character.

-- Mark --

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

Date: Tue, 2 Apr 2002 06:03:10 -0800
From: Jutta Degener <[email-masked]>
To: [email-masked]
Subject: ACL 2: Why $ and not / ?
Sender: [email-masked]

Why did <draft-ietf-imapext-acl-03.txt> choose "$" as a
prefix character and not "/" as in RFC 2244 (ACAP)?

Granted, "/" is fixed as a hierarchy separator in ACAP and
not in IMAP, but isn't it still a _common_ hierarchy separator
in IMAP? It's certainly more popular, and more frequently
excluded from user names, than "$".

Is there a user name scheme that IMAP is trying to support
where identifiers do start with "/"?

If not, wouldn't it be desirable to keep the number of
different user name encoding schemes low and perhaps align
ACL2 with ACAP?

Jutta Degener
<[email-masked]>