Subject: Re: Announcement: Notifications List
From: Keith Moore <[email-masked]>
To: "Burger, Eric" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 20 Dec 2005 12:35:44 -0500
List-Id: <ietf-imapext.imc.org>

Burger, Eric wrote:
> In Vancouver in the lemonade work group meeting a number of people
> expressed interest in the creation of a list dedicated to the discussion
> of user notification technology.
> 
> This list is for discussions relating to the requirements, definition,
> and directions for message notifications.
> 
> While many requirements are driven by lemonade, there is a broader
> community with interest and expertise that we hope will contribute to
> the discussion here.
> 
> Please keep discussions that relate to lemonade, smtp, simple, etc. on
> their respective lists.

Please do not impose this constraint.  There is already far too much 
tendency for narrowly-focused groups to work in isolation and to ignore 
useful input from parties whose interests are peripheral to the group 
but affected by the group's output.  This in turn causes groups to get 
strong pushback at Last Call which could have been avoided had the group 
not isolated itself.

> Please keep cross-posting to a minimum.  Cross-posting to a number of
> lists will put your message into the spam bucket and will delay or deny
> your message being posted.

If the list manager is going to impose restrictions such as this, it 
would be better if such discussion happened elsewhere than on this list.

Keith

Content-class: urn:content-classes:message
Subject: Announcement: Notifications List
Date: Tue, 20 Dec 2005 10:32:45 -0500
From: "Burger, Eric" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

In Vancouver in the lemonade work group meeting a number of people
expressed interest in the creation of a list dedicated to the discussion
of user notification technology.

This list is for discussions relating to the requirements, definition,
and directions for message notifications.

While many requirements are driven by lemonade, there is a broader
community with interest and expertise that we hope will contribute to
the discussion here.

Please keep discussions that relate to lemonade, smtp, simple, etc. on
their respective lists.

Please keep cross-posting to a minimum.  Cross-posting to a number of
lists will put your message into the spam bucket and will delay or deny
your message being posted.

More information is at 
<https://www1.ietf.org/mailman/listinfo/notifications>

Subject: Re: Fwd: RFC 4314 on IMAP4 Access Control List (ACL) Extension
From: Timo Sirainen <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>, [email-masked]
Date: Tue, 20 Dec 2005 12:13:43 +0200
Sender: [email-masked]

--=-btCBOBW5gi4AS4/j7yZt
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-12-20 at 09:18 +0000, Dave Cridland wrote:
> a) So far, I've not seen any server implementation supporting=20
> multiple mailbox patterns. I noted that this would be relatively=20
> involved to implement server-side myself, but perhaps more tellingly,=20
> although my API supports this, the layer above never actually causes=20
> multiple mailbox patterns to be used. I'm struggling to find a=20
> use-case for multiple mailbox patterns. This may be the nature of a=20
> GUI client, however. (Perhaps if I could "search" for mailboxes by=20
> name, this might occur, but it would be a complex search dialog.)
>=20
> This isn't difficult to implement server-side, but my impression is=20
> that it's possibly more trouble than its worth. I appreciate this has=20
> probably been debated heavily before when this feature was added, but=20
> I'd personally like to gain some idea of what the consensus is.

I don't remember seeing discussion when it was added, but I think I
remember there being a discussion about removing it since it's not so
useful. I'd support removing it. Clients can just send multiple LIST
commands at once if they need multiple patterns.

--=-btCBOBW5gi4AS4/j7yZt
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-btCBOBW5gi4AS4/j7yZt--

Date: Tue, 20 Dec 2005 09:18:23 +0000
Subject: Re: Fwd: RFC 4314 on IMAP4 Access Control List (ACL) Extension
From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Thu Dec 15 01:53:55 2005, Lisa Dusseault wrote:
> Whoohoo!  Now let's get another one done -- LISTEXT reviews, 
> anybody?

Some comments:

1) I found the ABNF strikingly difficult to follow. This is largely 
because it's complex, but also because I spent some ten minutes 
looking for the LIST response, in order to see if I agreed with the 
syntactic rules, and finally realized that the reason I couldn't find 
it is simply that it's not there. Only the payload is, under an ABNF 
rule the name of which I've forgotten. A note at the beginning 
pointing to that rule would be useful.

2) I disagree with the statement that ACAP will never move to Draft. 
I don't think this belongs in a normative section, it's merely an 
opinion, and one which I hope to rectify.

I've not had time to verify the examples - I'll try to do so, but I 
doubt I'll have time before the new year.

I've implemented the complete specification through to API level in a 
client, and performed interoperability testing against a server 
implementation.

I've also sketched out a server implementation to gain some idea of 
where the complexities lie, and avoid the usual crop of comments that 
as a mere client implementor I know nothing.

Some comments:

a) So far, I've not seen any server implementation supporting 
multiple mailbox patterns. I noted that this would be relatively 
involved to implement server-side myself, but perhaps more tellingly, 
although my API supports this, the layer above never actually causes 
multiple mailbox patterns to be used. I'm struggling to find a 
use-case for multiple mailbox patterns. This may be the nature of a 
GUI client, however. (Perhaps if I could "search" for mailboxes by 
name, this might occur, but it would be a complex search dialog.)

This isn't difficult to implement server-side, but my impression is 
that it's possibly more trouble than its worth. I appreciate this has 
probably been debated heavily before when this feature was added, but 
I'd personally like to gain some idea of what the consensus is.

b) RECURSIVEMATCH turns out to be easy, given that it only works on 
SUBSCRIBED, thus making it, in effect, an LSUB equivalent. I suspect 
it would be difficult in a more generic implementation. However, I 
think its value will outweigh its complexity.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 20 Dec 2005 08:51:56 +0000
Subject: Re: Fwd: RFC 4314 on IMAP4 Access Control List (ACL) Extension
From: Dave Cridland <[email-masked]>
To: Arnaud Taddei <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Tue Dec 20 05:25:26 2005, Arnaud Taddei wrote:
> Lisa Dusseault wrote:
> 
>> Whoohoo! Now let's get another one done -- LISTEXT reviews, 
>> anybody?
> 
> Before I come to that, in RFC 4314, I arrived too late on my review 
> of the draft.
> 
> So here is the typos I found but I may be wrong. For the content I 
> will make another mail as I have a couple of problems ...
> 
> Can one review the example of page 6? I read
> 
> C: A002 getacl INBOX/Drafts
> S: * ACL INBOX Fred rwipslxcetda David lrswideta
> S: A002 OK Getacl complete
> 
> But shouldn't it be:
> 
> C: A002 getacl INBOX/Drafts
> S: * ACL INBOX*/Drafts* Fred rwipslxcetda David lrswideta
> S: A002 OK Getacl complete
> 
> 
Indeed, that does appear to be an errata.

> BTW I really dislikes folders below INBOX
> 
> Same thing on page 7 no? I read
> 
> C: A003 Setacl INBOX/Drafts Byron lrswikda
> S: A001 OK Setacl complete
> C: A002 getAcl INBOX/Drafts
> S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
> S: A002 OK Getacl complete
> 
> 
Yep, same.

> On page 11: the sentence:
> 
> The MYRIGHTS command returns the set of rights that the user has to
> mailbox in an untagged MYRIGHTS reply.
> 
> is missing something after 'user has to' ... no?
> 
> 
Well... It's missing "the".

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 20 Dec 2005 06:25:26 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: Fwd: RFC 4314 on IMAP4 Access Control List (ACL) Extension
To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_VqWSSGKZfBxfLeq001foig)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

Lisa Dusseault wrote:

> Whoohoo! Now let's get another one done -- LISTEXT reviews, anybody?

Before I come to that, in RFC 4314, I arrived too late on my review of 
the draft.

So here is the typos I found but I may be wrong. For the content I will 
make another mail as I have a couple of problems ...

Can one review the example of page 6? I read

C: A002 getacl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda David lrswideta
S: A002 OK Getacl complete

But shouldn't it be:

C: A002 getacl INBOX/Drafts
S: * ACL INBOX*/Drafts* Fred rwipslxcetda David lrswideta
S: A002 OK Getacl complete

BTW I really dislikes folders below INBOX

Same thing on page 7 no? I read

C: A003 Setacl INBOX/Drafts Byron lrswikda
S: A001 OK Setacl complete
C: A002 getAcl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
S: A002 OK Getacl complete

But shouldn't it be:

C: A003 Setacl INBOX/Drafts Byron lrswikda
S: A001 OK Setacl complete
C: A002 getAcl INBOX/Drafts
S: * ACL INBOX/Drafts Fred rwipslxcetda Byron lrswikcdeta
S: A002 OK Getacl complete

On page 11: the sentence:

The MYRIGHTS command returns the set of rights that the user has to
mailbox in an untagged MYRIGHTS reply.

is missing something after 'user has to' ... no?

A++

>
> lisa
>
> Begin forwarded message:
>
>     *From: [email-masked]
>     *Date: *December 12, 2005 11:34:06 AM PST
>     *To: [email-masked]
>     *Cc: [email-masked], [email-masked]
>     *Subject: RFC 4314 on IMAP4 Access Control List (ACL) Extension
>     *
>
>     A new Request for Comments is now available in online RFC libraries.
>
>
>     RFC 4314
>
>     Title: IMAP4 Access Control List (ACL) Extension
>     Author(s): A. Melnikov
>     Status: Standards Track
>     Date: December 2005
>     Mailbox: [email-masked]
>     Pages: 27
>     Characters: 56599
>     Obsoletes: 2086
>
>     I-D Tag: draft-ietf-imapext-2086upd-08.txt
>
>     URL: ftp://ftp.rfc-editor.org/in-notes/rfc4314.txt
>
>
>     The Access Control List (ACL) extension (RFC 2086) of the Internet
>     Message Access Protocol (IMAP) permits mailbox access control lists
>     to be retrieved and manipulated through the IMAP protocol.
>
>     This document is a revision of RFC 2086. It defines several new
>     access control rights and clarifies which rights are required for
>     different IMAP commands.
>
>     This document is a product of the Internet Message Access Protocol
>     Extension Working Group of the IETF.
>
>     This is now a Proposed Standard Protocol.
>
>     This document specifies an Internet standards track protocol for the
>     Internet community, and requests discussion and suggestions for
>     improvements. Please refer to the current edition of the "Internet
>     Official Protocol Standards" (STD 1) for the standardization state
>     and status of this protocol. Distribution of this memo is unlimited.
>
>     This announcement is sent to the IETF list and the RFC-DIST list.
>     Requests to be added to or deleted from the IETF distribution list
>     should be sent to [email-masked]. Requests to be
>     added to or deleted from the RFC-DIST distribution list should
>     be sent to [email-masked].
>
>     Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
>     an EMAIL message to [email-masked] with the message body
>     help: ways_to_get_rfcs. For example:
>
>     To: [email-masked]
>     Subject: getting rfcs
>
>     help: ways_to_get_rfcs
>
>     Requests for special distribution should be addressed to either the
>     author of the RFC in question, or to [email-masked].
>     Unless
>     specifically noted otherwise on the RFC itself, all RFCs are for
>     unlimited distribution.
>
>     Submissions for Requests for Comments should be sent to
>     [email-masked]. Please consult RFC 2223, Instructions
>     to RFC
>     Authors, for further information.
>
>
>     Joyce K. Reynolds and Sandy Ginoza
>     USC/Information Sciences Institute
>
>     ...
>
>     Below is the data which will enable a MIME compliant Mail Reader
>     implementation to automatically retrieve the ASCII version
>     of the RFCs.
>     Content-Type: text/plain
>     Content-ID: <[email-masked]>
>
>

-- 
<http://www.sun.com> 	* Arnaud Taddei *
Senior Architect Communications Products

*Sun Microsystems, Inc.*
Phone x13541/+41(22)99904-41
Mobile +41 (0)79 506 1129
Email [email-masked]

--Boundary_(ID_VqWSSGKZfBxfLeq001foig)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Lisa Dusseault wrote:
<blockquote cite="[email-masked]"
 type="cite">Whoohoo! Now let's get another one done -- LISTEXT
reviews, anybody?
  <br>
</blockquote>
Before I come to that, in RFC 4314, I arrived too late on my review of
the draft.<br>
<br>
So here is the typos I found but I may be wrong. For the content I will
make another mail as I have a couple of problems ...<br>
<br>
Can one review the example of page 6? I read<br>
<blockquote>
  <pre><font color="#330099">C: A002 getacl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda David lrswideta
S: A002 OK Getacl complete</font></pre>
</blockquote>
But shouldn't it be:<br>
<blockquote>
  <pre><font color="#330099">C: A002 getacl INBOX/Drafts
S: * ACL INBOX<b>/Drafts</b> Fred rwipslxcetda David lrswideta
S: A002 OK Getacl complete</font></pre>
</blockquote>
BTW I really dislikes folders below INBOX<br>
<br>
Same thing on page 7 no? I read<br>
<blockquote>
  <pre><font color="#330099">C: A003 Setacl INBOX/Drafts Byron lrswikda
S: A001 OK Setacl complete
C: A002 getAcl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
S: A002 OK Getacl complete</font></pre>
</blockquote>
But shouldn't it be:<br>
<blockquote>
  <pre><font color="#330099">C: A003 Setacl INBOX/Drafts Byron lrswikda
S: A001 OK Setacl complete
C: A002 getAcl INBOX/Drafts
S: * ACL INBOX/Drafts Fred rwipslxcetda Byron lrswikcdeta
S: A002 OK Getacl complete</font></pre>
</blockquote>
On page 11: the sentence:<br>
<blockquote>
  <pre><font color="#330099">The MYRIGHTS command returns the set of rights that the user has to
mailbox in an untagged MYRIGHTS reply.</font></pre>
</blockquote>
is missing something after '<font color="#330099"><tt>user has to</tt></font>'
... no?<br>
<br>
A++<br>
<blockquote cite="[email-masked]"
 type="cite"><br>
lisa
  <br>
  <br>
Begin forwarded message:
  <br>
  <br>
  <blockquote><b><!-- 0000,0000,0000 -->From:
    </b><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
    <b><!-- 0000,0000,0000 -->Date:
    </b>December 12, 2005 11:34:06 AM PST
    <br>
    <b><!-- 0000,0000,0000 -->To:
    </b><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
    <b><!-- 0000,0000,0000 -->Cc:
    </b><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>, <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
    <b><!-- 0000,0000,0000 -->Subject: RFC 4314 on
IMAP4 Access Control List (ACL) Extension
    <br>
    </b><br>
    <br>
A new Request for Comments is now available in online RFC libraries.
    <br>
    <br>
    <br>
RFC 4314
    <br>
    <br>
Title: IMAP4 Access Control List (ACL) Extension
    <br>
Author(s): A. Melnikov
    <br>
Status: Standards Track
    <br>
Date: December 2005
    <br>
Mailbox: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
Pages: 27
    <br>
Characters: 56599
    <br>
Obsoletes: 2086
    <br>
    <br>
I-D Tag: draft-ietf-imapext-2086upd-08.txt
    <br>
    <br>
URL: <a class="moz-txt-link-freetext" href="ftp://ftp.rfc-editor.org/in-notes/rfc4314.txt">ftp://ftp.rfc-editor.org/in-notes/rfc4314.txt</a>
    <br>
    <br>
    <br>
The Access Control List (ACL) extension (RFC 2086) of the Internet
    <br>
Message Access Protocol (IMAP) permits mailbox access control lists
    <br>
to be retrieved and manipulated through the IMAP protocol.
    <br>
    <br>
This document is a revision of RFC 2086. It defines several new
    <br>
access control rights and clarifies which rights are required for
    <br>
different IMAP commands.
    <br>
    <br>
This document is a product of the Internet Message Access Protocol
    <br>
Extension Working Group of the IETF.
    <br>
    <br>
This is now a Proposed Standard Protocol.
    <br>
    <br>
This document specifies an Internet standards track protocol for the
    <br>
Internet community, and requests discussion and suggestions for
    <br>
improvements. Please refer to the current edition of the "Internet
    <br>
Official Protocol Standards" (STD 1) for the standardization state
    <br>
and status of this protocol. Distribution of this memo is unlimited.
    <br>
    <br>
This announcement is sent to the IETF list and the RFC-DIST list.
    <br>
Requests to be added to or deleted from the IETF distribution list
    <br>
should be sent to <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>. Requests to be
    <br>
added to or deleted from the RFC-DIST distribution list should
    <br>
be sent to <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>.
    <br>
    <br>
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
    <br>
an EMAIL message to <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> with the message body <br>
help: ways_to_get_rfcs. For example:
    <br>
    <br>
To: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
Subject: getting rfcs
    <br>
    <br>
help: ways_to_get_rfcs
    <br>
    <br>
Requests for special distribution should be addressed to either the
    <br>
author of the RFC in question, or to <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>. Unless
    <br>
specifically noted otherwise on the RFC itself, all RFCs are for
    <br>
unlimited distribution.
    <br>
    <br>
Submissions for Requests for Comments should be sent to
    <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>. Please consult RFC 2223, Instructions to
RFC
    <br>
Authors, for further information.
    <br>
    <br>
    <br>
Joyce K. Reynolds and Sandy Ginoza
    <br>
USC/Information Sciences Institute
    <br>
    <br>
...
    <br>
    <br>
Below is the data which will enable a MIME compliant Mail Reader <br>
implementation to automatically retrieve the ASCII version
    <br>
of the RFCs.
    <br>
Content-Type: text/plain
    <br>
Content-ID: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
    <br>
  </blockquote>
  <br>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<table border="0" cellpadding="0" cellspacing="0" width="450">
  <tbody>
    <tr valign="top">
      <td height="121" width="121"><a href="http://www.sun.com"><img
 moz-do-not-send="true" src="http://www.sun.com/emrkt/sigs/6g_top.gif"
 border="0" height="116" width="121"></a></td>
      <td style="font-family: Arial; font-size: 10px;" height="121"
 width="329"><b> Arnaud Taddei </b><br>
Senior Architect Communications Products<br>
      <br>
      <b>Sun Microsystems, Inc.</b><br>
Phone x13541/+41(22)99904-41<br>
Mobile +41 (0)79 506 1129<br>
Email <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
      </td>
    </tr>
  </tbody>
</table>
</div>
</body>
</html>

--Boundary_(ID_VqWSSGKZfBxfLeq001foig)--

Date: Mon, 19 Dec 2005 16:21:03 -0600
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Cc: Dave Cridland <[email-masked]>, Curtis King <[email-masked]>, [email-masked], Cyrus Daboo <[email-masked]>
Sender: [email-masked]

On 12/7/05 at 1:29 PM -0800, Mark Crispin wrote:

>Many people have forgotten the original IETF credo, coined (I think) 
>by Bob Braden:
>	We reject: kings, presidents and voting.
>	We believe in: rough concensus and running code.

It's usually attributed to Dave Clark.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Content-class: urn:content-classes:message
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
Date: Sun, 18 Dec 2005 20:30:00 -0000
From: "Edward Hibbert" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C60412.12A958B5
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>From my point of view, the most interesting IMAP clients are those which =
are most widely deployed :-).

The following link from Microsoft contains a claim that most IMAP =
clients don't support referrals:

http://tinyurl.com/9yyf3

Which I think I'll take as indicating that Microsoft clients don't. =20

Shame, I was hoping to use referrals.  But if Microsoft clients don't =
support it, that's not an option.

Regards,

Edward.

-----Original Message-----
From: [email-masked] on behalf of Mark Crispin
Sent: Fri 16/12/2005 16:46
To: Edward Hibbert
Cc: [email-masked]
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
=20
On Fri, 16 Dec 2005, Edward Hibbert wrote:
> What about common clients like Thunderbird, Outlook, Outlook Express?

For understandable reasons, Microsoft never uses open source software=20
(other than open source software that it developed) as a matter of =
policy.=20
Outlook and OE *may* support login referrals, though, as Microsoft was =
one=20
of the instigators for referrals.

I don't know what Thunderbird uses, but I doubt that it uses c-client.

I don't consider any of these three to be particularly interesting as =
IMAP=20
clients.  There are much better IMAP clients out there, and most of =
those=20
are open source.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

------_=_NextPart_001_01C60412.12A958B5
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 =
6.5.7638.1">
<TITLE>RE: Support for IMAP LOGIN referrals (RFC2221)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>From my point of view, the most interesting IMAP =
clients are those which are most widely deployed :-).<BR>
<BR>
The following link from Microsoft contains a claim that most IMAP =
clients don't support referrals:<BR>
<BR>
<A HREF=3D"http://tinyurl.com/9yyf3">http://tinyurl.com/9yyf3</A><BR>
<BR>
Which I think I'll take as indicating that Microsoft clients =
don't.&nbsp;<BR>
<BR>
Shame, I was hoping to use referrals.&nbsp; But if Microsoft clients =
don't support it, that's not an option.<BR>
<BR>
Regards,<BR>
<BR>
Edward.<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of Mark Crispin<BR>
Sent: Fri 16/12/2005 16:46<BR>
To: Edward Hibbert<BR>
Cc: [email-masked]<BR>
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)<BR>
<BR>
On Fri, 16 Dec 2005, Edward Hibbert wrote:<BR>
&gt; What about common clients like Thunderbird, Outlook, Outlook =
Express?<BR>
<BR>
For understandable reasons, Microsoft never uses open source =
software<BR>
(other than open source software that it developed) as a matter of =
policy.<BR>
Outlook and OE *may* support login referrals, though, as Microsoft was =
one<BR>
of the instigators for referrals.<BR>
<BR>
I don't know what Thunderbird uses, but I doubt that it uses =
c-client.<BR>
<BR>
I don't consider any of these three to be particularly interesting as =
IMAP<BR>
clients.&nbsp; There are much better IMAP clients out there, and most of =
those<BR>
are open source.<BR>
<BR>
-- Mark --<BR>
<BR>
<A HREF=3D"http://panda.com/mrc">http://panda.com/mrc</A><BR>
Democracy is two wolves and a sheep deciding what to eat for lunch.<BR>
Liberty is a well-armed sheep contesting the vote.<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C60412.12A958B5--

Date: Fri, 16 Dec 2005 18:26:01 +0000
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
From: Dave Cridland <[email-masked]>
To: Edward Hibbert <[email-masked]>
Cc: <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

On Fri Dec 16 16:42:22 2005, Edward Hibbert wrote:
> 
> What about common clients like Thunderbird, Outlook, Outlook 
> Express?
> 
> 
Thunderbird uses the Mozilla Mail/News component - I don't know if 
that supports RFC2221 or not, but based on memory, I don't think it's 
one of the extensions supported. Novell's Evolution, as far as I'm 
aware, does not either.

Since someone from Microsoft wrote RFC2221, and moreover I seem to 
recall that Exchange supports it, one would assume that Outlook 
Express would also support it, but the only way you'll find out is to 
test, I'm afraid. Outlook may, as well, but I believe their IMAP 
implementations are distinct.

My own client, Polymer, does not support RFC2221 - but if there were 
interest, I'd probably put it in.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Fri, 16 Dec 2005 08:46:48 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Edward Hibbert <[email-masked]>
cc: [email-masked]
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
Sender: [email-masked]

On Fri, 16 Dec 2005, Edward Hibbert wrote:
> What about common clients like Thunderbird, Outlook, Outlook Express?

For understandable reasons, Microsoft never uses open source software 
(other than open source software that it developed) as a matter of policy. 
Outlook and OE *may* support login referrals, though, as Microsoft was one 
of the instigators for referrals.

I don't know what Thunderbird uses, but I doubt that it uses c-client.

I don't consider any of these three to be particularly interesting as IMAP 
clients.  There are much better IMAP clients out there, and most of those 
are open source.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Content-class: urn:content-classes:message
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
Date: Fri, 16 Dec 2005 16:42:22 -0000
From: "Edward Hibbert" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

What about common clients like Thunderbird, Outlook, Outlook Express?

Regards,

Edward. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark Crispin
Sent: 16 December 2005 16:40
To: Edward Hibbert
Cc: [email-masked]
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)

On Fri, 16 Dec 2005, Edward Hibbert wrote:
> Jolly good argument for the UW c-client library.  Do any other clients

> use it?

I don't have a list, but I can think of several current and past client
projects which used c-client.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Fri, 16 Dec 2005 08:40:07 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Edward Hibbert <[email-masked]>
cc: [email-masked]
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
Sender: [email-masked]

On Fri, 16 Dec 2005, Edward Hibbert wrote:
> Jolly good argument for the UW c-client library.  Do any other clients
> use it?

I don't have a list, but I can think of several current and past client 
projects which used c-client.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Content-class: urn:content-classes:message
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
Date: Fri, 16 Dec 2005 16:38:33 -0000
From: "Edward Hibbert" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Jolly good argument for the UW c-client library.  Do any other clients
use it?

Edward. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark Crispin
Sent: 16 December 2005 16:36
To: Edward Hibbert
Cc: [email-masked]
Subject: Re: Support for IMAP LOGIN referrals (RFC2221)

On Fri, 16 Dec 2005, Edward Hibbert wrote:
> Does anyone have a list of which clients support this RFC?  I have the

> impression that it's not widely supported, so would welcome definitive

> information on
> *	clients which do
> *	clients which don't
> *	the types of problems which arise with clients which don't.

Pine supports LOGIN referrals, as would any other client that uses the
UW c-client library.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Fri, 16 Dec 2005 08:36:04 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Edward Hibbert <[email-masked]>
cc: [email-masked]
Subject: Re: Support for IMAP LOGIN referrals (RFC2221)
Sender: [email-masked]

On Fri, 16 Dec 2005, Edward Hibbert wrote:
> Does anyone have a list of which clients support this RFC?  I have the
> impression that it's not widely supported, so would welcome definitive
> information on
> *	clients which do
> *	clients which don't
> *	the types of problems which arise with clients which don't.

Pine supports LOGIN referrals, as would any other client that uses the UW 
c-client library.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Content-class: urn:content-classes:message
Subject: Support for IMAP LOGIN referrals (RFC2221)
Date: Fri, 16 Dec 2005 16:17:31 -0000
From: "Edward Hibbert" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6025C.37CD9E6D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Does anyone have a list of which clients support this RFC?  I have the
impression that it's not widely supported, so would welcome definitive
information on=20

*	clients which do
*	clients which don't
*	the types of problems which arise with clients which don't.

Thanks,
=20
Edward Hibbert.

------_=_NextPart_001_01C6025C.37CD9E6D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D836321616-16122005><FONT face=3DArial color=3D#ff00ff =
size=3D2>Does=20
anyone have a list of which clients support this RFC?&nbsp; I have the=20
impression that it's not widely supported, so would welcome definitive=20
information on </FONT></SPAN></DIV>
<UL>
  <LI><SPAN class=3D836321616-16122005><FONT face=3DArial =
color=3D#ff00ff=20
  size=3D2>clients which do</FONT></SPAN></LI>
  <LI><SPAN class=3D836321616-16122005><FONT face=3DArial =
color=3D#ff00ff=20
  size=3D2>clients which don't</FONT></SPAN></LI>
  <LI><SPAN class=3D836321616-16122005><FONT face=3DArial =
color=3D#ff00ff size=3D2>the=20
  types of problems which arise with clients which =
don't.</FONT></SPAN></LI></UL>
<DIV><SPAN class=3D836321616-16122005><FONT face=3DArial color=3D#ff00ff =

size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D836321616-16122005><FONT face=3DArial color=3D#ff00ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D836321616-16122005><FONT face=3DArial color=3D#ff00ff =
size=3D2>Edward=20
Hibbert.</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C6025C.37CD9E6D--

Subject: Re: ANNOTATEMORE update
From: Alexandros Vellis <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Organization: National & Kapodistrian University of Athens
Date: Thu, 15 Dec 2005 11:53:11 +0200
Sender: [email-masked]

Hello,

> > Thus, we would have message *annotations*, and mailbox and server
> > *metadata*.
> 
> I would be fine with a change like this to - what do others think?

I like it. :)

-- 
Alexandros Vellis
[email-masked]

Date: Wed, 14 Dec 2005 21:09:18 -0500
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: RFC 4314 on IMAP4 Access Control List (ACL) Extension
Sender: [email-masked]

Hi Lisa,

--On December 14, 2005 5:53:55 PM -0800 Lisa Dusseault 
<[email-masked]> wrote:

> Whoohoo!  Now let's get another one done -- LISTEXT reviews, anybody?

Can we clarify what people want to do about the ANNOTATEMORE/METADATA vs 
SET/LISTEXT thread? Is there consensus to move forward with a generic SET 
mechanism or not? I'm not sure that that has to affect LISTEXT, but I think 
we need to think it through a bit. For example, given that LISTEXT still 
requires the reference argument for mailbox names, wouldn't that also be 
needed in the SET command for consistency?

-- 
Cyrus Daboo

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Fwd: RFC 4314 on IMAP4 Access Control List (ACL) Extension
Date: Wed, 14 Dec 2005 17:53:55 -0800
Sender: [email-masked]

--Apple-Mail-11--461870765
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Whoohoo!  Now let's get another one done -- LISTEXT reviews, anybody?

lisa

Begin forwarded message:

> From: [email-masked]
> Date: December 12, 2005 11:34:06 AM PST
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: RFC 4314 on IMAP4 Access Control List (ACL) Extension
>
>
> A new Request for Comments is now available in online RFC libraries.
>
>
>         RFC 4314
>
>         Title:      IMAP4 Access Control List (ACL) Extension
>         Author(s):  A. Melnikov
>         Status:     Standards Track
>         Date:       December 2005
>         Mailbox:    [email-masked]
>         Pages:      27
>         Characters: 56599
>         Obsoletes:  2086
>
>         I-D Tag:    draft-ietf-imapext-2086upd-08.txt
>
>         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4314.txt
>
>
> The Access Control List (ACL) extension (RFC 2086) of the Internet
> Message Access Protocol (IMAP) permits mailbox access control lists
> to be retrieved and manipulated through the IMAP protocol.
>
> This document is a revision of RFC 2086.  It defines several new
> access control rights and clarifies which rights are required for
> different IMAP commands.
>
> This document is a product of the Internet Message Access Protocol
> Extension Working Group of the IETF.
>
> This is now a Proposed Standard Protocol.
>
> This document specifies an Internet standards track protocol for the
> Internet community, and requests discussion and suggestions for
> improvements.  Please refer to the current edition of the "Internet
> Official Protocol Standards" (STD 1) for the standardization state
> and status of this protocol.  Distribution of this memo is unlimited.
>
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [email-masked].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [email-masked].
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [email-masked] with the message body
> help: ways_to_get_rfcs.  For example:
>
>         To: [email-masked]
>         Subject: getting rfcs
>
>         help: ways_to_get_rfcs
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  
> Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
> Submissions for Requests for Comments should be sent to
> [email-masked].  Please consult RFC 2223, Instructions to 
> RFC
> Authors, for further information.
>
>
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
>
> ...
>
> Below is the data which will enable a MIME compliant Mail Reader
> implementation to automatically retrieve the ASCII version
> of the RFCs.
> Content-Type: text/plain
> Content-ID: <[email-masked]>

--Apple-Mail-11--461870765
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

Whoohoo!  Now let's get another one done -- LISTEXT reviews, anybody?

lisa

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Date:
</color></bold>December 12, 2005 11:34:06 AM PST

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>[email-masked], [email-masked]

<bold><color><param>0000,0000,0000</param>Subject: </color>RFC 4314 on
IMAP4 Access Control List (ACL) Extension

</bold>

A new Request for Comments is now available in online RFC libraries.

        RFC 4314

        Title:      IMAP4 Access Control List (ACL) Extension

        Author(s):  A. Melnikov

        Status:     Standards Track

        Date:       December 2005

        Mailbox:    [email-masked]

        Pages:      27

        Characters: 56599

        Obsoletes:  2086

        I-D Tag:    draft-ietf-imapext-2086upd-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4314.txt

The Access Control List (ACL) extension (RFC 2086) of the Internet

Message Access Protocol (IMAP) permits mailbox access control lists

to be retrieved and manipulated through the IMAP protocol.

This document is a revision of RFC 2086.  It defines several new

access control rights and clarifies which rights are required for

different IMAP commands.

This document is a product of the Internet Message Access Protocol

Extension Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements.  Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.

Requests to be added to or deleted from the IETF distribution list

should be sent to [email-masked].  Requests to be

added to or deleted from the RFC-DIST distribution list should

be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending

an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs.  For example:

        To: [email-masked]

        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the

author of the RFC in question, or to [email-masked]. 
Unless

specifically noted otherwise on the RFC itself, all RFCs are for

unlimited distribution.

Submissions for Requests for Comments should be sent to

[email-masked].  Please consult RFC 2223, Instructions to
RFC

Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza

USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 

implementation to automatically retrieve the ASCII version

of the RFCs.

Content-Type: text/plain

Content-ID: <<[email-masked]>

</excerpt>
--Apple-Mail-11--461870765--

Date: Fri, 9 Dec 2005 09:44:46 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Moving IDLE to Draft Standard
Cc: Barry Leiba <[email-masked]>, Mark Crispin <[email-masked]>, Timo Sirainen <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> On Thu, 8 Dec 2005, Dave Cridland wrote:
>> The client would have to ACK, which is a transmission, which uses up 
>> battery on mobile devices. This might be a waste of effort, if the 
>> client isn't on NAT.
>
> Agreed; but before that change was put into UW imapd, users of Outlook 
> [Express] with NAT boxes were screwed.  I doubt OE will ever get 
> fixed.

I think what Dave minds is that the workaround is so wide. Ideally, the 
workaround should affect only OE clients behind NAT boxes. However, I 
cannot suggest any (tasteful) way to detect that.

Maybe turn the workaround off when the client uses a LEMONADE extension, 
or if IPv6 is used.

Arnt

To: [email-masked]
Subject: RFC 4314 on IMAP4 Access Control List (ACL) Extension
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Mon, 12 Dec 2005 11:34:06 -0800
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 4314

        Title:      IMAP4 Access Control List (ACL) Extension
        Author(s):  A. Melnikov
        Status:     Standards Track
        Date:       December 2005
        Mailbox:    [email-masked]
        Pages:      27
        Characters: 56599
        Obsoletes:  2086

        I-D Tag:    draft-ietf-imapext-2086upd-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4314.txt

The Access Control List (ACL) extension (RFC 2086) of the Internet
Message Access Protocol (IMAP) permits mailbox access control lists
to be retrieved and manipulated through the IMAP protocol.

This document is a revision of RFC 2086.  It defines several new
access control rights and clarifies which rights are required for
different IMAP commands.

This document is a product of the Internet Message Access Protocol
Extension Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements.  Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--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]>

RETRIEVE: rfc
DOC-ID: rfc4314

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc4314.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--

Date: Thu, 8 Dec 2005 11:49:06 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Timo Sirainen <[email-masked]>, [email-masked], Barry Leiba <[email-masked]>
Subject: Re: Moving IDLE to Draft Standard
Sender: [email-masked]

On Thu, 8 Dec 2005, Dave Cridland wrote:
> The client would have to ACK, which is a transmission, which uses up battery 
> on mobile devices. This might be a waste of effort, if the client isn't on 
> NAT.

Agreed; but before that change was put into UW imapd, users of Outlook 
[Express] with NAT boxes were screwed.  I doubt OE will ever get fixed.

> Like RECONNECT, trying to do much in IDLE to work around this problem is 
> trying to fix something in the application layer that's actually a problem 
> caused by very much lower layers.

Indeed, but that doesn't help in this case.

> All this doesn't argue that "* OK Idling, timeout in 25 minutes" (or whatever 
> UW sends, I forget) is wrong, broken, or anything. I think an informative 
> section reminding client implementors that whilst IDLE, a server may send 
> anything, including OK, NO, or even BAD, is a good idea, and explaining why a 
> server might choose to do so - or a client might choose to break IDLE 
> frequently - is needed. I don't think this affects any existing clients, 
> though, and I also don't think this is normative material.

Agreed.

> The normative bit is saying that the server is allowed to send OK, NO, BAD, 
> etc.

The normative bit is that server is allowed to send ANY untagged response, 
and that the client MUST accept such responses.  A client that only 
expects EXISTS and RECENT is broken.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Thu, 08 Dec 2005 09:09:59 +0000
Subject: Re: Moving IDLE to Draft Standard
From: Dave Cridland <[email-masked]>
To: Timo Sirainen <[email-masked]>
Cc: Mark Crispin <[email-masked]>, <[email-masked]>, Barry Leiba <[email-masked]>
Sender: [email-masked]

On Wed Dec  7 23:18:45 2005, Timo Sirainen wrote:
> On Wed, 2005-12-07 at 20:34 +0000, Dave Cridland wrote:
> > No, that discussion needs to be there, but it's a matter of 
> breaking > up the IDLE with a NOOP every five minutes or so, rather 
> than every > 29.
> > > As far as I'm aware, those firewalls and NATs also reset their 
> timers > whenever the client sends any TCP packet, hence even 
> ACKing > server-sent data counts.
> 
> Has someone tried how this would affect clients? If server sent
> "* OK Still idling" every minute, would clients break out of idle or
> otherwise get confused? Or would there be some other bad side 
> effects?
> 
> 
The client would have to ACK, which is a transmission, which uses up 
battery on mobile devices. This might be a waste of effort, if the 
client isn't on NAT.

The client can probably guess when it's running through a NAT by 
examination of its local address - I've considered putting such code 
in Polymer, but haven't got around to it yet - but it needs to 
minimize the number of IDLE-breaks (as it were - sending something 
like "DONE\r\nA10057 NOOP\r\nA10058 IDLE\r\n") for the same reason. 
Of course, that involves sending more data. I'm really not sure if 
the key factor in mobile device battery life is "a transmission" or 
"a transmitted octet", so I couldn't say if this ends up being worse 
in the worst case.

If a server implementor wants to add an experimental parameter to 
IDLE to indicate how often the server needs to send something, I 
could try some empirical testing across at least one GPRS network.

I actually think the best solution for this particular mess is for 
IMAP to ignore it, at least for now, and for us to examine, and 
obtain good advice on, the various mobility layers over IP (4 and 6). 
I have had a strong suspicion for a while that this would represent 
an excellent solution to these problems, as well as provide 
additional flexibility.

Like RECONNECT, trying to do much in IDLE to work around this problem 
is trying to fix something in the application layer that's actually a 
problem caused by very much lower layers.

All this doesn't argue that "* OK Idling, timeout in 25 minutes" (or 
whatever UW sends, I forget) is wrong, broken, or anything. I think 
an informative section reminding client implementors that whilst 
IDLE, a server may send anything, including OK, NO, or even BAD, is a 
good idea, and explaining why a server might choose to do so - or a 
client might choose to break IDLE frequently - is needed. I don't 
think this affects any existing clients, though, and I also don't 
think this is normative material.

The normative bit is saying that the server is allowed to send OK, 
NO, BAD, etc.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 7 Dec 2005 15:41:42 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: [email-masked]
Subject: Re: Moving IDLE to Draft Standard
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 7 Dec 2005, Barry Leiba wrote:
>>> "* OK Still idling" every minute
>> UW imapd has done this for years, and nobody has complained yet.
> Then should I add an "servers MAY do that", with an explanation of why,
> to the 2177bis spec?

I think so.

-- Mark --

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

Date: Wed, 07 Dec 2005 18:35:51 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Moving IDLE to Draft Standard
Sender: [email-masked]

>> "* OK Still idling" every minute
> 
> UW imapd has done this for years, and nobody has complained yet.

Then should I add an "servers MAY do that", with an explanation of why,
to the 2177bis spec?

Barry

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

Date: Wed, 7 Dec 2005 15:23:45 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Dave Cridland <[email-masked]>, [email-masked], Barry Leiba <[email-masked]>
Subject: Re: Moving IDLE to Draft Standard
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 8 Dec 2005, Timo Sirainen wrote:
> Has someone tried how this would affect clients? If server sent
> "* OK Still idling" every minute, would clients break out of idle or
> otherwise get confused? Or would there be some other bad side effects?

UW imapd has done this for years, and nobody has complained yet.

-- Mark --

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

Subject: Re: Moving IDLE to Draft Standard
From: Timo Sirainen <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], Barry Leiba <[email-masked]>
Date: Thu, 08 Dec 2005 01:18:45 +0200
Sender: [email-masked]

--=-luCYr+eu0CnXLVAfUD0g
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-12-07 at 20:34 +0000, Dave Cridland wrote:
> No, that discussion needs to be there, but it's a matter of breaking=20
> up the IDLE with a NOOP every five minutes or so, rather than every=20
> 29.
>=20
> As far as I'm aware, those firewalls and NATs also reset their timers=20
> whenever the client sends any TCP packet, hence even ACKing=20
> server-sent data counts.

Has someone tried how this would affect clients? If server sent
"* OK Still idling" every minute, would clients break out of idle or
otherwise get confused? Or would there be some other bad side effects?

--=-luCYr+eu0CnXLVAfUD0g
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-luCYr+eu0CnXLVAfUD0g--

To: IMAP Extensions WG <[email-masked]>, IETF-iCalendar <[email-masked]>, WG Chairs <[email-masked]>, WebDAV WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: OT but nice productivity hack: Yubnub to find RFCs, I-Ds and WGs
Date: Wed, 7 Dec 2005 14:10:17 -0800
Sender: [email-masked]

--Apple-Mail-3-1067395383
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

A co-worker (Jared Rhine) pointed me to Yubnub.org a while back.  I 
have grown addicted to it as a Internet command-line to jump straight 
to what I want.  E.g. I use a command like "thes addicted" to quickly 
find thesaurus matches: absorbed, accustomed, attached... :)

There was one IETF-related yubnub command already and I added two more 
very simple ones.

To jump to an RFC: rfc xxxx
	e.g. 'rfc 2822'  (don't forget space)

Internet-Draft Database Search: (shows list with filename substring 
match): ids keyword
	e.g. 'ids dusseault' to find draft-dusseault-caldav-08, but not 
draft-ietf-webdav-rfc2518bis because 'dusseault' isn't in the title of 
that one

To jump to a WG charter: wg wgname
	e.g. 'wg imapext'

Not only do I get to avoid the thesaurus.com web form to find thesaurus 
matches, I also avoid the Yubnub Web form because I've set up Firefox 
so that I can type a Yubnub command line right into the address bar. 
Other possibilities include using the search engine field or a console 
app <http://www.yubnub.org/documentation/describe_installation>.

Fun, fun.  Hope it's useful to you too.  Let me know if you create 
other IETF-related command lines.  I'll blog about it or something so 
as not to spam people again.

Lisa

--Apple-Mail-3-1067395383
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

A co-worker (Jared Rhine) pointed me to Yubnub.org a while back.  I
have grown addicted to it as a Internet command-line to jump straight
to what I want.  E.g. I use a command like "thes addicted" to quickly
find thesaurus matches: absorbed, accustomed, attached... :)   

There was one IETF-related yubnub command already and I added two more
very simple ones.

To jump to an RFC: <bold>rfc</bold> xxxx

	e.g. 'rfc 2822'  (don't forget space)

Internet-Draft Database Search: (shows list with filename substring
match): <bold>ids</bold> keyword

	e.g. 'ids dusseault' to find draft-dusseault-caldav-08, but not
draft-ietf-webdav-rfc2518bis because 'dusseault' isn't in the title of
that one

To jump to a WG charter: <bold>wg </bold>wgname

	e.g. 'wg imapext'

Not only do I get to avoid the thesaurus.com web form to find
thesaurus matches, I also avoid the Yubnub Web form because I've set
up Firefox so that I can type a Yubnub command line right into the
address bar. Other possibilities include using the search engine field
or a console app
<<http://www.yubnub.org/documentation/describe_installation>.

Fun, fun.  Hope it's useful to you too.  Let me know if you create
other IETF-related command lines.  I'll blog about it or something so
as not to spam people again.

Lisa

--Apple-Mail-3-1067395383--

Date: Wed, 7 Dec 2005 13:57:06 -0800
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked], Barry Leiba <[email-masked]>
Subject: Re: Moving IDLE to Draft Standard
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 7 Dec 2005, Dave Cridland wrote:
> I'm assuming you meant "IDLE" here, not "IMAP".

Correct.  The brain farts with age... :-(

> No, that discussion needs to be there, but it's a matter of breaking up the 
> IDLE with a NOOP every five minutes or so, rather than every 29.

Five minutes may be too slow.  Empirical testing in my server led me to 
crank it up to every two minutes.

> As far as I'm aware, those firewalls and NATs also reset their timers 
> whenever the client sends any TCP packet, hence even ACKing server-sent data 
> counts.
>
> Dave.
> --
>          You see things; and you say "Why?"
>  But I dream things that never were; and I say "Why not?"
>   - George Bernard Shaw
>

-- Mark --

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

Date: Wed, 7 Dec 2005 13:29:10 -0800
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Curtis King <[email-masked]>, [email-masked], Cyrus Daboo <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 7 Dec 2005, Dave Cridland wrote:
> Kind of, but not as simple. Tell me, Mark. Which *are* the functionality 
> requests that should have been turned down? Since, as far as I'm aware, only 
> three individuals have implemented anything approaching the full spec, all 
> after the fact, so how were people meant to know? Where was the running code 
> the IETF is so famous for? Had people tried implementing much earlier, I 
> suspect several features in ACAP may well have been dropped. But nobody knew 
> to say no.

You're proving my point.  I gave up on ACAP long before the spec went to 
last call.  I doubt very much that I was the only person who did.

Sadly, while ACAP was being designed, other people were building their own 
solutions to the problem; and having solved their problem, lost interest 
in ACAP.

> I'm not blaming the individuals involved, here, but if an organization 
> commits the time to work on a protocol, it has to follow through with the 
> running code.

The organization also has to pay attention to the individuals who will 
product the running code.  Early on, ACAP deviated from my needs.

> The IETF is good on the rough consensus, but it's getting a bit flakey on the 
> running code. I'd hate to think how many other Proposed Standards haven't 
> even been prototyped.

Too many people who have not (and never will) produced a line of running 
code are participating in the protocol design process.  That has always 
been a problem, even back in ARPAnet days; but in recent years it has 
become much worse.

Many people have forgotten the original IETF credo, coined (I think) by 
Bob Braden:
 	We reject: kings, presidents and voting.
 	We believe in: rough concensus and running code.

The first is gone, and only lip service is paid to the second.

I disagree that we have rough concensus; what we have in the IETF today is 
majority-rules voting.  That is not the same thing.

-- Mark --

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

Date: Wed, 07 Dec 2005 20:34:54 +0000
Subject: Re: Moving IDLE to Draft Standard
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: <[email-masked]>, Barry Leiba <[email-masked]>
Sender: [email-masked]

On Wed Dec  7 19:35:27 2005, Mark Crispin wrote:
> 
> Two issues:
> 
> 1) I don't see any justification for allowing a NO response.  This 
> is
>    something that needs to be cleaned up in the base specification 
> as
>    well.  I suggest that the possibility of a NO be removed.
> 
> 
Agreed.

> 2) There needs to be a discussion about why it may be ill-advised to
>    use IMAP with NAT or other facilities that drop connectivity and
>    depend upon client activity to restore connectivity.
> 
> 
I'm assuming you meant "IDLE" here, not "IMAP".

No, that discussion needs to be there, but it's a matter of breaking 
up the IDLE with a NOOP every five minutes or so, rather than every 
29.

As far as I'm aware, those firewalls and NATs also reset their timers 
whenever the client sends any TCP packet, hence even ACKing 
server-sent data counts.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Cc: Cyrus Daboo <[email-masked]>, [email-masked], Dave Cridland <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: OT: calendaring and component architecture, was Re: Going beyond what we have now
Date: Wed, 7 Dec 2005 12:32:32 -0800
To: Mark Crispin <[email-masked]>
Sender: [email-masked]

On Dec 7, 2005, at 11:05 AM, Mark Crispin wrote:

>
>> I guess the question is whether it would ever be possible to build a 
>> standardized system of component protocols (email, calendar, im, rss 
>> etc) that was sufficient to meet this need.
>
> Sadly, the IETF has failed miserably with calendaring.  In part, I 
> believe that this is because the efforts keep on deviating from 
> "component protocols" and instead attempt to build monoliths that 
> solve all problems.
>
> The more that I see of how the IETF is handling calendaring, the less 
> happy I become.
>
> This is one of the vast areas of work that I allude to above.
>
>
Hey, I hope you'll give the calendaring stuff another chance at some 
point.  I'm the chair of the new calendaring WG, CALSIFY, and although 
it's off to a slow start, there are probably decent reasons for that.  
We have seven implementations of CalDAV for basic calendar access and 
have done several interop tests so far even though it's an individual 
draft (I'm an author, which is why it's not part of the CALSIFY WG, a 
potential conflict of interest I'm not interested in taking on).

I agree with the component based approach overall as one the IETF is 
capable of doing.  Sometimes where we fall down is in the last steps of 
integrating between components so it's not easy, but at least it's 
feasible for us.

Lisa

Date: Wed, 07 Dec 2005 20:24:22 +0000
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Curtis King <[email-masked]>, <[email-masked]>, Cyrus Daboo <[email-masked]>
Sender: [email-masked]

On Wed Dec  7 18:02:46 2005, Mark Crispin wrote:
> On Wed, 7 Dec 2005, Cyrus Daboo wrote:
>> PS Just because ACAP was a failure (and at this point in terms of 
>> adoption that is definitively true), that doesn't mean that the 
>> concepts behind ACAP should be ignored. Anyone that actually got 
>> to use IMSP/ACAP knows well the benefits of server-side storage of 
>> preferences and address book information.
> 
> The concepts were great, and the benefits undeniable.
> 
> The problem was that there was nobody to say "no" when 
> functionality requests went off the deep end.  The "if ACAP doesn't 
> do such-and-such, then ACAP will die" argument won.  As a result 
> ACAP died.
> 
> 
Kind of, but not as simple. Tell me, Mark. Which *are* the 
functionality requests that should have been turned down? Since, as 
far as I'm aware, only three individuals have implemented anything 
approaching the full spec, all after the fact, so how were people 
meant to know? Where was the running code the IETF is so famous for? 
Had people tried implementing much earlier, I suspect several 
features in ACAP may well have been dropped. But nobody knew to say 
no.

(Case in point, you objected at one point to including sorting in 
ACAP at all. Ironically, this is a surviving part of ACAP, being 
comparators, which turned out to be very useful.)

I'm not blaming the individuals involved, here, but if an 
organization commits the time to work on a protocol, it has to follow 
through with the running code.

The IETF is good on the rough consensus, but it's getting a bit 
flakey on the running code. I'd hate to think how many other Proposed 
Standards haven't even been prototyped.

Incidentally, GConf, and other desktop configuration systems, are 
within spitting distance of a full ACAP specification (they tend to 
miss out the ACL support, for instance, and don't offer server-side 
searching at all, but still offer a much finer granularity than 
Pine's config-onna-mailbox does), so arguably, ACAP isn't dead at 
all, but has merely mutated into something utterly useless outside of 
a LAN.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 7 Dec 2005 11:35:27 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Moving IDLE to Draft Standard
Sender: [email-masked]

Two issues:

1) I don't see any justification for allowing a NO response.  This is
    something that needs to be cleaned up in the base specification as
    well.  I suggest that the possibility of a NO be removed.

2) There needs to be a discussion about why it may be ill-advised to
    use IMAP with NAT or other facilities that drop connectivity and
    depend upon client activity to restore connectivity.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 7 Dec 2005 11:05:47 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

On Wed, 7 Dec 2005, Cyrus Daboo wrote:
> Well, I guess this goes to the heart of my point: is IMAP meant to compete 
> with (or at least provide a useful alternative to)  monolithic systems like 
> Exchange or not?

By itself, IMAP most certainly is *NOT* meant to compete with monolithic 
systems such as Exchange.

IMAP may be a component of a larger set of protocols which, together, 
either compete with Exchange or offer a useful alternative to Exchange.

The problem is, rather than build that larger set, we're seeing a tendency 
to try to build up IMAP into a do-everything monolith to compete with 
Exchange by itself.  Such an effort is doomed to failure.

This isn't IMAP's fault; the IETF lacks the ability to build do-everything 
monoliths.  The ability to build a do-everything monolith is the strength 
of entities (such as Microsoft) in which a single direction is determined 
by administrative policy.  IETF, by its nature, can not build a monolith 
since the debate required for such a task will not reach concensus before 
the sun novas.

Put another way: dictatorships are great at building monoliths, 
democracies are great in building clusters of widely-varying components 
and somehow making it all work.  Neither does particularly well at doing 
what the other is good at doing.

> Is it meant to fit in well in a true collaborative 
> environment where email is just one type of data in a system that needs to 
> link multiple data sources of different types together to present users with 
> all their key data in a sensible way?

The same answer as above.

I share the same goal that you state.  I just don't see IMAP as the sole 
solution for this goal.  I see vast areas of work that need to be done 
before we can reach that goal; and that work will require several new 
protocols with a scope at least as large as IMAP's scope.

> Right now IMAP does not meet that need, 
> and we are seeing people like Zimbra (and many others) building their own 
> custom solutions (Exchange alternatives) precisely because that is where 
> things are going - users want that level of integration.

Yes, indeed; but you'll never see the IETF build a Zimbra or Exchange. 
That is simply not its strength.

There is no particular reason why Zimbra or Exchange could not incorporate 
IMAP (or Kerberos, or any other IETF protocol).  In fact, they have (at 
least Exchange has).

Monoliths have leveraged IETF protocols in the past, and will continue to 
do so in the future.  Similarly, there will always be a protracted debate 
between IETF purists and monolith-builders about how the monolith 
implements the IETF protocol (typically focusing on unilateral extensions 
by the monolith-building), ultimately resulting in some form of 
compromise.

This is healthy.  What isn't healthy is the perception as IETF is being in 
competition with the monolith-builders.  GNU religion aside, we're not out 
to kill them, and they aren't out to kill us either.  We need each other.

> I guess the question is whether it would ever be possible to build a 
> standardized system of component protocols (email, calendar, im, rss etc) 
> that was sufficient to meet this need.

Sadly, the IETF has failed miserably with calendaring.  In part, I believe 
that this is because the efforts keep on deviating from "component 
protocols" and instead attempt to build monoliths that solve all problems.

The more that I see of how the IETF is handling calendaring, the less 
happy I become.

This is one of the vast areas of work that I allude to above.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 07 Dec 2005 13:45:00 -0500
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Moving IDLE to Draft Standard
Sender: [email-masked]

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

I'm getting ready to put IDLE on the path to Draft Standard (it'll have
to wait until the base spec gets there, but it can get on the queue).
I've just sent draft-leiba-imap-2177bis-00.txt to the I-D editor, so
watch for it soon; it's attached here for your reading pleasure.  It's
mostly the same as RFC 2177, with editorial changes generated, mostly,
from conversion of the source to use xml2rfc.  I've also updated the
references, and changed the ABNF to the current syntax.  The minor
substantive changes are

   Clarified that ANY response may come from the server during IDLE,
   and gave examples of the most common responses.

   Clarified that anything other than "DONE" is "BAD".

These are both the result of common questions from implementors.

I need to put together an interoperability report.  To that end, please
tell me (you can reply off-list, and I'll summarize responses on the
list) about client and server implementations of IDLE.  Tell me also,
if you have experience using one client implementation with a different
server implementation.

Barry

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

--==========E474E5AD02C1BDEFE85E==========
Content-Type: text/plain; charset=utf-8;
 name="draft-leiba-imap-2177bis-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-leiba-imap-2177bis-00.txt";
 size=14106

Network Working Group                                           B. =
Leiba
Internet-Draft                           IBM T.J. Watson Research =
Center
Obsoletes: 2177 (if approved)                           December 7, =
2005
Expires: June 10, 2006

                           IMAP4 IDLE command
                      draft-leiba-imap-2177bis-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 10, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The Internet Message Access Protocol requires a client to poll the
   server for changes to the selected mailbox (new mail, deletions).
   It's often more desirable to have the server transmit updates to the
   client in real time.  This allows a user to see new mail =
immediately.
   It also helps some real-time applications based on IMAP, which might
   otherwise need to poll extremely often (such as every few seconds).
   (While the spec actually does allow a server to push EXISTS =
responses
   asynchronously, a client can't expect this behaviour and must poll.)

Leiba                     Expires June 10, 2006                 [Page =
1]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

   This document specifies the syntax of an IDLE command, which will
   allow a client to tell the server that it's ready to accept such
   real-time updates.

Note

   This document is intended to be an update to the existing "IDLE"
   extension to the IMAP protocol, available from the RFC repository as
   ftp://ftp.isi.edu/in-notes/rfc2177.txt.

   This document and other IMAP extensions are being discussed on the
   imapext mailing list at mailto:[email-masked].  Subscription
   requests can be sent to
   mailto:[email-masked]?body=3Dsubscribe (send an email
   message with the word "subscribe" in the body).  More information on
   the mailing list along with a WWW archive of back messages is
   available at http://www.imc.org/ietf-imapext/.

Leiba                     Expires June 10, 2006                 [Page =
2]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

Table of Contents

   1. Conventions used in this document  . . . . . . . . . . . . . .   =
4

   2. Specification  . . . . . . . . . . . . . . . . . . . . . . . .   =
5

   3. Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .   =
7

   4. Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . .   =
8

   5. Changes since RFC 2177 . . . . . . . . . . . . . . . . . . . .   =
9

   6. Security Considerations  . . . . . . . . . . . . . . . . . . .  =
10

   7. Normative References . . . . . . . . . . . . . . . . . . . . .  =
10

      Author's Address . . . . . . . . . . . . . . . . . . . . . . .  =
10

      Intellectual Property and Copyright Statements . . . . . . . .  =
11

Leiba                     Expires June 10, 2006                 [Page =
3]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

1.  Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are =
to
   be interpreted as described in [Keywds].

Leiba                     Expires June 10, 2006                 [Page =
4]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

2.  Specification

   IDLE Command

   Arguments:  none

   Responses:  continuation data will be requested; the client sends =
the
               continuation data "DONE" to end the command

   Result:     OK  - IDLE completed after client sent "DONE"

               NO  - failure: the server will not allow the IDLE =
command
                     at this time

               BAD - command unknown or arguments invalid

   The IDLE command may be used with any IMAP4 server implementation
   that returns "IDLE" as one of the supported capabilities to the
   CAPABILITY command.  If the server does not advertise the IDLE
   capability, the client MUST NOT use the IDLE command and must poll
   for mailbox updates.  In particular, the client MUST continue to be
   able to accept unsolicited untagged responses to ANY command (not
   just to the IDLE command), as specified in the base IMAP
   specification.

   The IDLE command is sent from the client to the server when the
   client is ready to accept unsolicited messages from the server.  The
   server requests a response to the IDLE command using the =
continuation
   ("+") response.  The IDLE command remains active until the client
   responds to the continuation, and as long as an IDLE command is
   active, the server is now free to send ANY untagged responses.  IMAP
   servers will frequently send unsolicited responses such as these:

   o  EXISTS, to inform the client about a change in the number of
      messages in the currently-selected mailbox.

   o  EXPUNGE, to inform the client that a message has been expunged.

   o  FETCH, to inform the client about a change in the status of a
      message (usually to convey flag changes).

   o  RECENT, to inform the client that the number of messages with the
      \Recent flag has changed.  This response often accompanies =
EXISTS.

   But note again that what the server may send is not limited to that
   list -- ANY untagged response may appear.

   The IDLE command is terminated by the receipt of a "DONE"

Leiba                     Expires June 10, 2006                 [Page =
5]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

   continuation from the client; such response satisfies the server's
   continuation request.  At that point, the server MAY send any
   remaining queued untagged responses and then MUST immediately send
   the tagged response "OK" to the IDLE command and prepare to process
   other commands.  As in the base specification, the processing of any
   new command may cause the sending of unsolicited untagged responses,
   subject to the ambiguity limitations.  The client MUST NOT send a
   command while the server is waiting for the DONE, since the server
   will not be able to distinguish a command from a continuation.  If
   the server receives anything other than "DONE" from the client, this
   is a protocol violation and the server SHOULD terminate the IDLE
   command with a tagged response of "BAD".

   The server MAY consider a client inactive if it has an IDLE command
   running, and if such a server has an inactivity timeout it MAY log
   the client off implicitly at the end of its timeout period.  Because
   of that, clients using IDLE are advised to terminate the IDLE and =
re-
   issue it at least every 29 minutes to avoid being logged off.  This
   still allows a client to receive immediate mailbox updates even
   though it need only "poll" at half hour intervals.

Leiba                     Expires June 10, 2006                 [Page =
6]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

3.  Example

   The following is an example of an IMAP session using IDLE.

       C: A001 SELECT INBOX
       S: * FLAGS (Deleted Seen)
       S: * 3 EXISTS
       S: * 0 RECENT
       S: * OK [UIDVALIDITY 1]
       S: A001 OK SELECT completed
       C: A002 IDLE
       S: + idling
       ...time passes; another client sets a flag on message 2...
       S: * 2 FETCH (FLAGS (\Seen \Answered \Flagged))
       ...time passes; new mail arrives...
       S: * 4 EXISTS
       C: DONE
       S: A002 OK IDLE terminated
       ...another client expunges message 2 now...
       C: A003 FETCH 4 ALL
       S: * 4 FETCH (...)
       S: A003 OK FETCH completed
       C: A004 IDLE
       S: * 2 EXPUNGE
       S: * 3 EXISTS
       S: + idling
       ...time passes; another client expunges message 3...
       S: * 3 EXPUNGE
       S: * 2 EXISTS
       ...time passes; new mail arrives...
       S: * 3 EXISTS
       C: DONE
       S: A004 OK IDLE terminated
       C: A005 FETCH 3 ALL
       S: * 3 FETCH (...)
       S: A005 OK FETCH completed
       C: A006 IDLE

Leiba                     Expires June 10, 2006                 [Page =
7]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

4.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in [ABNF].  Non-terminals =
referenced
   but not defined below are as defined by [IMAP4].

   command_auth  =3D/  idle
                     ; Valid only in Authenticated or Selected state

   idle          =3D   "IDLE" CRLF "DONE"

Leiba                     Expires June 10, 2006                 [Page =
8]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

5.  Changes since RFC 2177

   1.  Updated references to current versions.

   2.  Updated ABNF to current syntax.

   3.  Added example of unsolicited FETCH response.

   4.  Clarified that ANY response may come from the server during =
IDLE,
       and gave examples of the most common responses.

   5.  Clarified that anything other than "DONE" is "BAD".

Leiba                     Expires June 10, 2006                 [Page =
9]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

6.  Security Considerations

   There are no known security issues with this extension.

7.  Normative References

   [ABNF]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 4234, October 2005.

   [IMAP4]   Crispin, M., "Internet Message Access Protocol - Version
             4rev1", RFC 3501, March 2003.

   [Keywds]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, March 1997.

Author's Address

   Barry Leiba
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532
   US

   Phone: +1 914 784 7941
   Email: [email-masked]

Leiba                     Expires June 10, 2006                [Page =
10]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed =
to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  =
Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use =
of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository =
at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on =
an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =
REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Leiba                     Expires June 10, 2006                [Page =
11]
=0C

--==========E474E5AD02C1BDEFE85E==========--

Date: Wed, 7 Dec 2005 10:02:46 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Curtis King <[email-masked]>, Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

On Wed, 7 Dec 2005, Cyrus Daboo wrote:
> PS Just because ACAP was a failure (and at this point in terms of adoption 
> that is definitively true), that doesn't mean that the concepts behind ACAP 
> should be ignored. Anyone that actually got to use IMSP/ACAP knows well the 
> benefits of server-side storage of preferences and address book information.

The concepts were great, and the benefits undeniable.

The problem was that there was nobody to say "no" when functionality 
requests went off the deep end.  The "if ACAP doesn't do such-and-such, 
then ACAP will die" argument won.  As a result ACAP died.

There is a natural tendency to underestimate the cost of added 
functionality and overestimate its benefits.  Any proposal for additional 
functionality should be compelled to fight for its survival; and survive 
only if its critics can be moved into the "no objection" column.

An example in point is the delayed-sending feature in Lemonade (where I 
was on the "pro" side for added functionality).

It should be considered a danger sign when people stop trying to block new 
functionality.  That means that they've concluded that it is so far over 
the deep end that it'll die on its own, and it's best not to try to save 
it.

Consider this: Pine has had server side preferences and address book for a 
long time.  Yet we have never used IMSP or ACAP.  What Pine does is a 
kludge: these are implemented as IMAP mailboxes.  Nevertheless, it works 
well; so well, that we never looked back once we gave up on ACAP.

I'm afraid that when shared (across applications) addressbooks happen, it 
will be with LDAP (shudder!).  As gruesome as that sounds (and is!) it's 
worth studying the lesson to learn how this seemingly-unintuitive result 
came to be.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 7 Dec 2005 09:30:25 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Curtis King <[email-masked]>, Cyrus Daboo <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

On Wed, 7 Dec 2005, Arnt Gulbrandsen wrote:
> Is anyone actually implementing POP4? Or put more bluntly, how many people 
> are using mail software whose next version may support POP4?
> To my possibly unkind eyes, POP4 looks like another answer to the problems of 
> the nineties, but the author had no time back then, so the answer arrives ten 
> years late. Personally, I think any email access protocol has to accomodate 
> MIME email now - unlike the early nineties.

Arnt,

All of your observations are completely true.  There is no doubt in my 
mind that the "POP4" idea does not have a snowball's chance of hell of 
succeeding, and the person beyond it is (to put it kindly) in need of some 
additional experience.

Nevertheless, the fact that one threat turned out to be of no consequence 
does not mean that the next threat will similarly be of no consequence.

My point was that the "IMAP-killer" will be something simpler and with 
lower barriers to entry, not something more complex and with higher 
barriers to entry.  I pointed to the POP4 idea as an example of what we 
should take seriously, even if the particular example can not be taken 
seriously.

Put another way: IMAP will not die because it is too simple, but it may 
die because it has become too complex and bloated.

I am, in fact, quite swayed by the argument that all the mailbox 
operations should be ripped out of IMAP, so that IMAP can focus on message 
operations.  That has always been my belief.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Cc: [email-masked]
From: Curtis King <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Date: Wed, 7 Dec 2005 16:34:32 +0000
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

On 7-Dec-05, at 2:58 PM, Cyrus Daboo wrote:

>  don't know why people get the impression that we are trying to re- 
> implement ACAP (even with a ;-) at the end of the sentence).

Because it uses the same data model, is a sub-set of ACAP, and solves  
the same problem as ACAP. That's what I gather when I compare drafts  
with ACAP, and I'm not the only one.

>
> PS Just because ACAP was a failure (and at this point in terms of  
> adoption that is definitively true), that doesn't mean that the  
> concepts behind ACAP should be ignored. Anyone that actually got to  
> use IMSP/ACAP knows well the benefits of server-side storage of  
> preferences and address book information. Really this ought to be  
> getting more important as we move into an era where people will  
> have many types of device that need to get to the same set of data  
> in a consistent manner.

I was implying that I would rather implement ACAP than ANNOTATE and  
ANNOTATEMORE because of the all reasons you explained.

I can't remember the amount of times I have heard "it's better to  
have more protocols specific to the task than a general protocol".  
Yet, in practice it sure looks like we take the path of least  
resistance.

ck

Date: Wed, 07 Dec 2005 07:28:33 -0800 (Pacific Standard Time)
From: Anil SRIVASTAVA <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
To: [email-masked]
Reply-to: [email-masked]
Organization: Sun Microsystems [http://www.sun.com]
Accept-Language: English; en
Sender: [email-masked]

Cyrus makes a good point on the intergration of various components like 
Zimbra (and Exchange).  Zimbra is particulary strong in their ability to 
search for messages based on very sophisticated set of message and part 
properties.

Anil

On 2005-12-07/09:42 [-0500], [email-masked] [Cyrus Daboo] wrote:

> 
> Hi Mark,
> 
> --On December 6, 2005 4:58:21 PM -0800 Mark Crispin <[email-masked]>
> wrote:
> 
> > Besides an every-expanding girth at the waist, IMAP is in great danger of
> > becoming unimplementable with existing mail stores.  Rather than its
> > original purpose of exporting a generic mail store from a wide range of
> > existing stores, IMAP is rapidly becoming another Exchange (and doing a
> > miserable job at it).
> 
> Well, I guess this goes to the heart of my point: is IMAP meant to compete
> with (or at least provide a useful alternative to)  monolithic systems like
> Exchange or not? Is it meant to fit in well in a true collaborative
> environment where email is just one type of data in a system that needs to
> link multiple data sources of different types together to present users with
> all their key data in a sensible way? Right now IMAP does not meet that need,
> and we are seeing people like Zimbra (and many others) building their own
> custom solutions (Exchange alternatives) precisely because that is where
> things are going - users want that level of integration.
> 
> I guess the question is whether it would ever be possible to build a
> standardized system of component protocols (email, calendar, im, rss etc) that
> was sufficient to meet this need.
> 
> 

-- 
_______________
Anil SRIVASTAVA
[email-masked]

Date: Wed, 07 Dec 2005 10:07:30 -0500
From: Cyrus Daboo <[email-masked]>
To: Dave Cridland <[email-masked]>, Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Dave,

--On December 6, 2005 9:51:15 PM +0000 Dave Cridland <[email-masked]> 
wrote:

>> Remove all mailbox handling functions from IMAP, and instead manage
>> the mailbox hierarchy through WebDAV - IMAP itself would then just
>> be a 'message access' protocol.
>
> Having notifications about mailbox-level events would suddenly be
> impossible, which is a great shame. But who needs notifications when you
> can have a stateless protocol for altering server state?

Perhaps you've never heard of web-mail? ;-)

-- 
Cyrus Daboo

Date: Wed, 07 Dec 2005 10:06:26 -0500
From: Cyrus Daboo <[email-masked]>
To: Timo Sirainen <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Cyrus Daboo <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Timo,

--On December 7, 2005 2:16:17 PM +0200 Timo Sirainen <[email-masked]> wrote:

> So I think the current SEARCH command is good if machine reads the
> results, but for human readable search results there could be something
> better.
>

Certainly users have been spoilt by web-search and really expect to see 
ranked results and be able to do some level of globbing.

-- 
Cyrus Daboo

Date: Wed, 07 Dec 2005 10:01:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Alexey,

--On December 6, 2005 5:19:53 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> LISTEXT is not enough - you still need a simple GET functionality.
>> Note that LISTEXT is actually more of a query operation now - you can
>> ask for mailboxes that match a particular pattern and set of flags,
>> acl, metadata. That is much more complex than a simple 'give me this
>> data for these mailboxes', which is what GET would be. The complexity
>> in LISTEXT is that a server has to search all the various properties:
>> mailboxes flags (which ought to be easy), ACL and metadata - the later
>> would probably require indexing of the metadata information for
>> efficient queries and I think that is a lot more complexity for a
>> server. Giving serves the ability to separate out a simple 'get'
>> operations from a 'query' operation would be better.
>
> Actually, the server can distinguish between the two by checking for glob
> characters. I don't see a reason for a separate GET command.

OK, that's reasonable.

-- 
Cyrus Daboo

Date: Wed, 07 Dec 2005 09:58:20 -0500
From: Cyrus Daboo <[email-masked]>
To: Curtis King <[email-masked]>, Mark Crispin <[email-masked]>
cc: Dave Cridland <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Curtis,

--On December 7, 2005 10:34:21 AM +0000 Curtis King <[email-masked]> wrote:

>> Quite frankly, I see little of value in ANNOTATE, ANNOTATEMORE, or
>> LISTEXT.  Unlike the Lemonade facilities, there is no compelling
>> need for any of these.
>
> I agree we should be focusing our resources on Lemonade facilities.  Not
> re-implementing ACAP ;)

I don't know why people get the impression that we are trying to 
re-implement ACAP (even with a ;-) at the end of the sentence). ANNOTATE, 
LISTEXT etc are well focused on providing email specific extensions, 
whereas ACAP went far beyond that with arbitrary preferences, address 
books, accounts, contexts etc. The fact that ANNOTATE happens to make 
reference to ACAP by stating it follows the same data model does not mean 
it is re-implementing ACAP itself. If people have that impression then 
perhaps that reference should be removed.

In terms of the value of ANNOTATE etc - well lemonade was a major driving 
force behind ANNOTATE - they wanted per-body part flags. At the meeting in 
Vancouver I asked whether that was still the case, and it was - so lemonade 
does want ANNOTATE. What's more there have also been proposals in lemonade 
to use ANNOTATEMORE for various mailbox properties. There is at least one 
major server that currently ships with ANNOTATEMORE support and that 
actually uses it, albeit only for its own internal mailbox properties. So I 
believe there is justification for both of those.

PS Just because ACAP was a failure (and at this point in terms of adoption 
that is definitively true), that doesn't mean that the concepts behind ACAP 
should be ignored. Anyone that actually got to use IMSP/ACAP knows well the 
benefits of server-side storage of preferences and address book 
information. Really this ought to be getting more important as we move into 
an era where people will have many types of device that need to get to the 
same set of data in a consistent manner.

-- 
Cyrus Daboo

Date: Wed, 07 Dec 2005 09:42:07 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Mark,

--On December 6, 2005 4:58:21 PM -0800 Mark Crispin 
<[email-masked]> wrote:

> Besides an every-expanding girth at the waist, IMAP is in great danger of
> becoming unimplementable with existing mail stores.  Rather than its
> original purpose of exporting a generic mail store from a wide range of
> existing stores, IMAP is rapidly becoming another Exchange (and doing a
> miserable job at it).

Well, I guess this goes to the heart of my point: is IMAP meant to compete 
with (or at least provide a useful alternative to)  monolithic systems like 
Exchange or not? Is it meant to fit in well in a true collaborative 
environment where email is just one type of data in a system that needs to 
link multiple data sources of different types together to present users 
with all their key data in a sensible way? Right now IMAP does not meet 
that need, and we are seeing people like Zimbra (and many others) building 
their own custom solutions (Exchange alternatives) precisely because that 
is where things are going - users want that level of integration.

I guess the question is whether it would ever be possible to build a 
standardized system of component protocols (email, calendar, im, rss etc) 
that was sufficient to meet this need.

-- 
Cyrus Daboo

Date: Wed, 07 Dec 2005 09:27:49 -0500
From: Cyrus Daboo <[email-masked]>
To: Curtis King <[email-masked]>, Cyrus Daboo <[email-masked]>
cc: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Curtis,

--On December 7, 2005 10:46:12 AM +0000 Curtis King <[email-masked]> wrote:

>> The other big reason for doing this in WebDAV is that most desktop
>> OS's have WebDAV file systems clients built-in.
>
> What about other platforms like phones and PDAs ?

Most phones/pdas have http stacks and its a simple matter to implement 
WebDAV on top of that. I already did that for a J2ME device so that it 
could do CalDAV - it was very easy to do - much more so than trying to do 
an IMAP client on the device.

-- 
Cyrus Daboo

Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
From: Timo Sirainen <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Cyrus Daboo <[email-masked]>, Dave Cridland <[email-masked]>
Date: Wed, 07 Dec 2005 14:16:17 +0200
Sender: [email-masked]

On Wed, 2005-12-07 at 12:12 +0100, Arnt Gulbrandsen wrote:
> Timo Sirainen writes:
> > On Tue, 2005-12-06 at 10:55 -0500, Cyrus Daboo wrote:
> >>  Really the place where IMAP needs to catch up is on message 
> >>  searching - specifically the ability to do store-wide searches (or 
> >>  at least a restricted subset of mailboxes) to provide the type of 
> >>  'virtual' mailbox functionality that a lot of desktop clients 
> >>  already support locally.
> ...
> > To get fast searching done in server side, we'd need a new command or 
> > a search attribute to allow servers to do less strict matching, so 
> > they could search mails using some generic indexing tools. Has anyone 
> > thought of doing this?
> 
> I don't see why we'd need this.
> 
> We've implemented server-side virtual folders (draft to come as soon as 
> I'm home, it's fairly simple) and didn't see any need for less strict 
> matching.

My reply didn't actually have anything to do with virtual folders, just
the searching part.

Do there exist any useful algorithms for IMAP servers that can allow
fast searching? I'd like to have "show results as you type the search
keyword" speed.

Cyrus's squat indexes seem to work somewhat well, except it can't handle
search keywords smaller than 4 characters. And since their
implementation doesn't suppport incremental index updates, most people
don't use them at all.

What else could even work? Maybe something could be done with suffix
trees. That's about all I've come across with (although I haven't tried
to look too hard into it..)

Having non-strict requirements for search would allow using lots of
different search algorithms, which would allow giving results faster and
possibly even better. Even if all search keywords are found from
multiple mails, the search engine could order those mails based on some
internal calculations on in which mails the word seems to be more
important..

So I think the current SEARCH command is good if machine reads the
results, but for human readable search results there could be something
better.

Date: Wed, 7 Dec 2005 12:33:16 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Cc: Curtis King <[email-masked]>, Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Curtis King writes:
> On 7-Dec-05, at 12:58 AM, Mark Crispin wrote:
>> Small and simple beats large and complex every time.  If anything  
>> proves to be the IMAP-killer, it will be something like POP4 (see  
>> www.pop4.org).
>
> POP is following the path of LDAP from a simple protocol to a more  
> complex one. POP4 is one more step closer to IMAP.

Is anyone actually implementing POP4? Or put more bluntly, how many 
people are using mail software whose next version may support POP4?

To my possibly unkind eyes, POP4 looks like another answer to the 
problems of the nineties, but the author had no time back then, so the 
answer arrives ten years late. Personally, I think any email access 
protocol has to accomodate MIME email now - unlike the early nineties.

Arnt

Date: Wed, 7 Dec 2005 12:12:48 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Cc: Cyrus Daboo <[email-masked]>, Timo Sirainen <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Timo Sirainen writes:
> On Tue, 2005-12-06 at 10:55 -0500, Cyrus Daboo wrote:
>>  Really the place where IMAP needs to catch up is on message 
>>  searching - specifically the ability to do store-wide searches (or 
>>  at least a restricted subset of mailboxes) to provide the type of 
>>  'virtual' mailbox functionality that a lot of desktop clients 
>>  already support locally.
...
> To get fast searching done in server side, we'd need a new command or 
> a search attribute to allow servers to do less strict matching, so 
> they could search mails using some generic indexing tools. Has anyone 
> thought of doing this?

I don't see why we'd need this.

We've implemented server-side virtual folders (draft to come as soon as 
I'm home, it's fairly simple) and didn't see any need for less strict 
matching.

Arnt

Cc: Dave Cridland <[email-masked]>, [email-masked]
From: Curtis King <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Date: Wed, 7 Dec 2005 10:46:12 +0000
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

On 6-Dec-05, at 3:55 PM, Cyrus Daboo wrote:

> The other big reason for doing this in WebDAV is that most desktop  
> OS's have WebDAV file systems clients built-in.

What about other platforms like phones and PDAs ?

>
> So I guess the bug question I have to ask at the end of all this,  
> is what do people really think about the future of IMAP as it  
> stands right now?

About the same as other protocols for now it does the job good enough  
and parts I don't like aren't enough of a reason to implement  
something else.

ck

Cc: Dave Cridland <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked]
From: Curtis King <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Date: Wed, 7 Dec 2005 10:34:21 +0000
To: Mark Crispin <[email-masked]>
Sender: [email-masked]

On 7-Dec-05, at 12:58 AM, Mark Crispin wrote:

>
> Small and simple beats large and complex every time.  If anything  
> proves to be the IMAP-killer, it will be something like POP4 (see  
> www.pop4.org).

POP is following the path of LDAP from a simple protocol to a more  
complex one. POP4 is one more step closer to IMAP.

>
> Quite frankly, I see little of value in ANNOTATE, ANNOTATEMORE, or  
> LISTEXT.  Unlike the Lemonade facilities, there is no compelling  
> need for any of these.

I agree we should be focusing our resources on Lemonade facilities.  
Not re-implementing ACAP ;)

ck

Date: Tue, 6 Dec 2005 16:58:21 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 6 Dec 2005, Dave Cridland wrote:
> There are more IMAP clients and servers, though.

This is significant.  Until you can answer "why aren't there more ACAP 
clients and servers", you won't be able to answer "why hasn't IMAP kept up 
with ACAP."

My take is that:
  . ACAP is so overengineered that most people look at it, say "forget it",
     and that's that.
  . IMAP has teetered on, but has managed to avoid stepping off, the brink
     of ACAP's deep end.
  . it's already possible to do what ACAP does with existing tools; less
     elegantly, but doable and not all that costly.

Small and simple beats large and complex every time.  If anything proves 
to be the IMAP-killer, it will be something like POP4 (see www.pop4.org).

> The IETF used to use the right tool for the job, and custom build a bespoke 
> protocol to perform a specific task, extending it as the demand for that task 
> changed, and sometimes radically changing the whole thing. When email 
> transfer over FTP got too complex, SMTP was developed - all well before my 
> time. The protocol had to fit the model, in other words. If the protocol 
> didn't fit the model, then the protocol must die. If protocol could be made 
> to fit the model by extending, that it was extended.

I disagree with this categorization.  Back when the IETF used to do things 
well, "interoperability for everyone" was the name of the game.  This, at 
times, sometimes meant that the answer was "no"; because doing what was 
asked would cut someone out of the game, or because the request was 
something that, while nice-seeming on the surface, had a snowball's chance 
of ever being generally implemented.

Today, all we need is for someone to say "blurdybloop protocol must 
support sarasoop or blurdybloop will die" and the entire working group for 
blurdybloop collapses in a withering heap.

Besides an every-expanding girth at the waist, IMAP is in great danger of 
becoming unimplementable with existing mail stores.  Rather than its 
original purpose of exporting a generic mail store from a wide range of 
existing stores, IMAP is rapidly becoming another Exchange (and doing a 
miserable job at it).

Quite frankly, I see little of value in ANNOTATE, ANNOTATEMORE, or 
LISTEXT.  Unlike the Lemonade facilities, there is no compelling need for 
any of these.  Client programmer ease does not constitute "compelling 
need."

-- Mark --

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

Date: Tue, 06 Dec 2005 21:51:15 +0000
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

None of this was intended as a flame in any way, and I should point 
out that I do - really - have the highest respect for the folks in 
this working group, and indeed I've very high respect for anyone who 
takes the time to contribute to the IETF as a whole.

All that said, Cyrus's message was a strong, and radical opinion, and 
I'm assuming he would not have written it seeking platitudes, but the 
strong opinions of others. Please recall that, as an Englishman, I 
have a fully paid up license to omit little smiley faces when I err 
on the side of sarcasm.

Summary: I sympathize with the sentiments, I agree that IMAP's school 
report is "Shows great promise, but could try harder". But you 
shouldn't be doing all that WebDAV, it's strong stuff, highly 
addictive, and I suspect it might be hallucinogenic.

On Tue Dec  6 15:55:13 2005, Cyrus Daboo wrote:
> Proposal: all properties of a mailbox (mailbox flags, status info, 
> acl, metadata/annotations) should be treated the same (note this is 
> pretty much how WebDAV works - so there is an existing example of 
> this type of approach). There would then be three commands (I'm 
> going to use some WebDAV names here just to emphasize the 
> similarity):
> 
> PROPFIND - used to get properties of mailboxes
> PROPPATCH - used to change properties of mailboxes
> PROPQUERY - used to find mailboxes with matching properties 
> (actually there is no direct WebDAV equivalent for this, though the 
> REPORT method is often used to define specific types of property 
> queries)
> 
> 
This is what I've proposed, essentially, with the minor difference 
that PROPQUERY and PROPFIND are identical commands with different 
usages (as Alexey pointed out, LIST with no wildcards can easily be 
fast-tracked).

The big difference is that I'm content to leave them as distinct 
categories of metadata. It happens that this will tend to fit ACL 
boundaries, but really, it's a backward compatibility thing. It also 
actually makes things easier for servers, I think, and doesn't make a 
huge amount of difference to clients.

But yes, STATUS, all that stuff, ends up in LIST, wrapped up in a 
delta/notification system to make things oodles of times more 
efficient, both on and off the wire. I've written one up, I'm just 
going through ABNF and nits and I'll publish it.

> Maybe I've been in the WebDAV world too much of late, but here is 
> another proposal that goes even further:
> 
> Remove all mailbox handling functions from IMAP, and instead manage 
> the mailbox hierarchy through WebDAV - IMAP itself would then just 
> be a 'message access' protocol.

Having notifications about mailbox-level events would suddenly be 
impossible, which is a great shame. But who needs notifications when 
you can have a stateless protocol for altering server state?

> The other big reason for doing this in WebDAV is that most desktop 
> OS's have WebDAV file systems clients built-in. That means a user 
> could manage their mailbox hierarchy directly from the desktop in a 
> familiar manner (though there are some limitations and interop 
> issue with those, but that can easily be fixed).

I don't think unfamiliarity is a problem with MUA interfaces, for 
common actions like these. I could be wrong, but I don't know anyone 
who has a problem knowing how to create an email folder, whether 
we're talking about my parents, or my clients.

>  There is also plenty of existing code for WebDAV clients/servers 
> that could easily be reused for this.
> 
> 
There are more IMAP clients and servers, though.

> Of course there is a slippery path here - its easy to ask why 
> message handling should not also be done in WebDAV, if you do 
> mailboxes. Well maybe that could be done as an alternative 
> mailstore access protocol, but contending with the stateless nature 
> of WebDAV would require careful thought. As we have found with 
> CalDAV (calendaring done through WebDAV) we really need extensions 
> that help with things like notifications and efficient data 
> management for synchronization etc - but that is all doable.
> 
> 
Yes. Hmmm. At the risk of sounding like I'm ranting (partly because I 
am):

Well, my personal favourite response to this kind of idea has always 
been that two key benefits would be that we could recoup 8 bits of 
the TCP header, and firewall retailers would be able to sell us 
pointlessly overpowerful content filters instead. I'm only half 
joking. And that's a generous half.

I've never understood the fascination with trying to make WebDAV the 
sole method of data transfer on the internet, nor why people believe 
that transfer and notifications have to be distinct protocols, rather 
than common features of the same carefully tailored protocol.

CalDAV seems to be gathering momentum, which I think is a terrible 
shame, and I know I'll be shouted down for saying it, and don't take 
this personally, but I think that while it's a step forward for 
interoperable calendaring, in reality, I think it's more of a toddle. 
I can say, "Ah, sweet, it took a step", but I can't say, "Wow, I want 
to use that".

The IETF used to use the right tool for the job, and custom build a 
bespoke protocol to perform a specific task, extending it as the 
demand for that task changed, and sometimes radically changing the 
whole thing. When email transfer over FTP got too complex, SMTP was 
developed - all well before my time. The protocol had to fit the 
model, in other words. If the protocol didn't fit the model, then the 
protocol must die. If protocol could be made to fit the model by 
extending, that it was extended.

Now, it seems we have to bend the task to fit the model designed 
around the protocol. That doesn't feel like good engineering to me. 
It doesn't even feel like a good kludge. The Web works, of course, 
and it works really well for the thing it was originally designed to 
do - publish documents. It just about copes, thanks to rather a lot 
of retrofitting and the luxury of a fast turnover of clients, with 
the dynamic nature of many resources. Perhaps I was, in fact, the 
only one shaking my head in sadness at the sight of people blaming a 
non-functional site on "your browser is too old". Perhaps I'm being a 
stick-in-the-mud for saying that User-Agent interpretation is always, 
always, always a bad thing. But, overall, the turnover of clients has 
mostly kept things working for publishing documents.

But we're not interested in publishing email, we're interested in 
reading it, flagging it, tagging it, sorting it - and being kept 
informed about what others are doing, as well. I'd say the same thing 
with calendars, too, and the shame is that CalDAV will still tick all 
the right boxes with all the right people, and we'll all be using 
CalDAV soon. Still, at least it's interoperable. (Well, if people can 
agree on what iCal really says, anyway).

But there already is a protocol you could have extended, which 
already has notifications, and efficient synchronization, and even 
funky arbitrary metadata. Aim higher.

> Really the place where IMAP needs to catch up is on message 
> searching - specifically the ability to do store-wide searches (or 
> at least a restricted subset of mailboxes) to provide the type of 
> 'virtual' mailbox functionality that a lot of desktop clients 
> already support locally. With the introduction of better OS file 
> system search tools where file content is being indexed and 
> searches happen quickly, user expectations are that the same 
> capabilities should work with their email. Well it does right now 
> if the client caches all the email locally - but that really 
> negates many of the advantages of IMAP in terms of minimizing how 
> much data you do need to keep locally.
> 
> 
Yes, agreed.

Really, IMAP should be up to the capabilities of ACAP by now. IMAP 
has had 8 years to catch up, it should have had server-side arbitrary 
sorting, enumeration, virtual-scrolling, and notifications based on 
that same model from ACAP at least 5 years ago. Add in multi-mailbox 
searching, and you've got some very nifty features.

We should be able to do all this. I can with my addressbook, why 
can't I with my messages? Equally, of course, why can't you with your 
addressbook?

Aside: And here, of course, I'm talking to Cyrus, one of the few 
people who *almost* can. More ironically yet, I'm not using ACAP in 
my client right now. I don't know how you people cope. It's awful. I 
had to reconfigure *everything*. Manually, I mean. It'll take me 
forever to get things back the way they were. Well, until I give up 
on this quaint local-only configuration, at least. It'll never catch 
on. It's a dead idea.

> So I guess the bug question I have to ask at the end of all this, 
> is what do people really think about the future of IMAP as it 
> stands right now?

I think it'll do very well, if we can only shake off this idea that 
we must strive for mediocrity. I think the fundamental concepts of 
IMAP are excellent, and it's a stable foundation we could build a 
really excellent, modern, mail system on. I believe enough people 
actually want to do this that it can happen.

Then again, I'm under the foolish delusion that if you write an ACAP 
server, people will start to take advantage of it, so really, maybe I 
ought to just conentrate on writing a new mail protocol with lots of 
X's in the acronym, and ending in DAV. MaxDAV, anyone? We'll figure 
out what it stands for later. Don't worry about the details, just 
remember, it'll be the Next Big Thing. It'll be ten times worse than 
IMAP is *now*, but that's nothing to worry about. We'll solve the 
efficiency problem later - it's all doable.

Dave.
-- 

Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
From: Timo Sirainen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Dave Cridland <[email-masked]>, [email-masked]
Date: Tue, 06 Dec 2005 21:07:27 +0200
Sender: [email-masked]

--=-BVSTjKe7vHJEYR6o5HU6
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-12-06 at 10:55 -0500, Cyrus Daboo wrote:
> Really the place where IMAP needs to catch up is on message searching -=20
> specifically the ability to do store-wide searches (or at least a=20
> restricted subset of mailboxes) to provide the type of 'virtual' mailbox=20
> functionality that a lot of desktop clients already support locally. With=
=20
> the introduction of better OS file system search tools where file content=
=20
> is being indexed and searches happen quickly, user expectations are that=20
> the same capabilities should work with their email. Well it does right no=
w=20
> if the client caches all the email locally - but that really negates many=
=20
> of the advantages of IMAP in terms of minimizing how much data you do nee=
d=20
> to keep locally.

To get fast searching done in server side, we'd need a new command or a
search attribute to allow servers to do less strict matching, so they
could search mails using some generic indexing tools. Has anyone thought
of doing this?

--=-BVSTjKe7vHJEYR6o5HU6
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-BVSTjKe7vHJEYR6o5HU6--

Date: Tue, 06 Dec 2005 17:19:53 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Cyrus Daboo wrote:

>> Reading metadata would be done by LIST-EXTENDED, both for ACL2 and for
>> METADATA. I believe the extension syntax now defined for LIST-EXTENDED
>> supports this complexity of syntax.
>
> LISTEXT is not enough - you still need a simple GET functionality. 
> Note that LISTEXT is actually more of a query operation now - you can 
> ask for mailboxes that match a particular pattern and set of flags, 
> acl, metadata. That is much more complex than a simple 'give me this 
> data for these mailboxes', which is what GET would be. The complexity 
> in LISTEXT is that a server has to search all the various properties: 
> mailboxes flags (which ought to be easy), ACL and metadata - the later 
> would probably require indexing of the metadata information for 
> efficient queries and I think that is a lot more complexity for a 
> server. Giving serves the ability to separate out a simple 'get' 
> operations from a 'query' operation would be better.

Actually, the server can distinguish between the two by checking for 
glob characters. I don't see a reason for a separate GET command.

Date: Tue, 06 Dec 2005 10:55:13 -0500
From: Cyrus Daboo <[email-masked]>
To: Dave Cridland <[email-masked]>, [email-masked]
Subject: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Dave,

--On December 4, 2005 12:33:10 AM +0000 Dave Cridland <[email-masked]> 
wrote:

> But, if we're going to change the protocol anyway, can we consider
> rewriting the protocol a little more?

I am going to disagree with your proposal because as it stands it does not 
go far enough IMHO. I would rather we leave things as they are or do this 
properly - which actually means replacing both LIST and STATUS as well. I 
think LISTEXT is only a half-hearted attempt at that. So my feeling is 
stick with what we have or go all the way - not part of the way. My 
justification for this follows.

> A01 SET "INBOX" METADATA ...
>
> For ACL2, this would look like:
>
> A02 SET "INBOX" ACL ...

First thing to note: as it is right now ACL2 uses STORE, SET and DELETE, in 
addition to LIST. There are valid reasons for requiring separate commands 
for those, however one could come up with some contorted syntax that would 
emulate all three in a single SET command, but this will require a major 
rewrite of ACL2 behaviour.

> Reading metadata would be done by LIST-EXTENDED, both for ACL2 and for
> METADATA. I believe the extension syntax now defined for LIST-EXTENDED
> supports this complexity of syntax.

LISTEXT is not enough - you still need a simple GET functionality. Note 
that LISTEXT is actually more of a query operation now - you can ask for 
mailboxes that match a particular pattern and set of flags, acl, metadata. 
That is much more complex than a simple 'give me this data for these 
mailboxes', which is what GET would be. The complexity in LISTEXT is that a 
server has to search all the various properties: mailboxes flags (which 
ought to be easy), ACL and metadata - the later would probably require 
indexing of the metadata information for efficient queries and I think that 
is a lot more complexity for a server. Giving serves the ability to 
separate out a simple 'get' operations from a 'query' operation would be 
better.

> This should reduce the number of commands in a session, and therefore the
> number of round-trips, by allowing clients to obtain all the information
> about a set of mailboxes in one command.

The fact is you are not really reducing the number of commands, all you are 
doing is disguising separate commands as one through a 'trick' of syntax. 
The first thing a server would do with SET METATDATA () ACL () is a branch 
to separate code to handle each type given that they will both have very 
different syntax/semantic requirements, and also because they may be 
optional components.

> Incidentally, this simply changes the syntax of ANNOTATEMORE/METADATA and
> potentially ACL2, not the semantics.

If you want to go all the way here is my (radical?) proposal. I am afraid 
some people won't like this but lets face it, IMAP needs to catch up with 
modern innovations in email that have broadened user expectations - fixing 
the mailbox handling is actually a small part of that - more radical 
changes are needed with message handling too.

Proposal: all properties of a mailbox (mailbox flags, status info, acl, 
metadata/annotations) should be treated the same (note this is pretty much 
how WebDAV works - so there is an existing example of this type of 
approach). There would then be three commands (I'm going to use some WebDAV 
names here just to emphasize the similarity):

PROPFIND - used to get properties of mailboxes
PROPPATCH - used to change properties of mailboxes
PROPQUERY - used to find mailboxes with matching properties (actually there 
is no direct WebDAV equivalent for this, though the REPORT method is often 
used to define specific types of property queries)

Note that PROPQUERY would effectively replace LIST and STATUS. ACL and 
METADATA/ANNOTATEMORE would be subsumed into the properties with 
appropriate syntax.

I believe this gives what you want Dave - a single set of commands for 
managing mailbox properties. Of course we still need CREATE, DELETE and 
RENAME for managing the mailboxes themselves.

Maybe I've been in the WebDAV world too much of late, but here is another 
proposal that goes even further:

Remove all mailbox handling functions from IMAP, and instead manage the 
mailbox hierarchy through WebDAV - IMAP itself would then just be a 
'message access' protocol. Why would this make sense? Well the first thing 
to note is that for the most part mailbox operations are stateless (as 
opposed to message operations which do require state to be carried over 
during a 'session'). Thus a stateless protocol like WebDAV could easily be 
used to manage mailboxes without any changes to the user experience or 
expectations.

The other big reason for doing this in WebDAV is that most desktop OS's 
have WebDAV file systems clients built-in. That means a user could manage 
their mailbox hierarchy directly from the desktop in a familiar manner 
(though there are some limitations and interop issue with those, but that 
can easily be fixed). There is also plenty of existing code for WebDAV 
clients/servers that could easily be reused for this.

There are of course a number of disadvantages to this - I'm sure these can 
be enumerated if we want to go further into this discussion.

Of course there is a slippery path here - its easy to ask why message 
handling should not also be done in WebDAV, if you do mailboxes. Well maybe 
that could be done as an alternative mailstore access protocol, but 
contending with the stateless nature of WebDAV would require careful 
thought. As we have found with CalDAV (calendaring done through WebDAV) we 
really need extensions that help with things like notifications and 
efficient data management for synchronization etc - but that is all doable.

Really the place where IMAP needs to catch up is on message searching - 
specifically the ability to do store-wide searches (or at least a 
restricted subset of mailboxes) to provide the type of 'virtual' mailbox 
functionality that a lot of desktop clients already support locally. With 
the introduction of better OS file system search tools where file content 
is being indexed and searches happen quickly, user expectations are that 
the same capabilities should work with their email. Well it does right now 
if the client caches all the email locally - but that really negates many 
of the advantages of IMAP in terms of minimizing how much data you do need 
to keep locally.

Its been my feeling for a while, that despite the widespread deployment of 
IMAP (something which I know a number of people really question), its 
future looks a little murky. I do think that we have gotten too embroiled 
in the attempts to fix things with extensions, and not really looked at the 
big picture of where this needs to go in the long term to really match user 
expectations.  There are many examples of companies that are innovating in 
this space, and its interesting to note that a number of them have simply 
ignored IMAP as a possible solution, even though they have adopted pretty 
much the same 'philosophy' of IMAP in terms of server-based email storage.

So I guess the bug question I have to ask at the end of all this, is what 
do people really think about the future of IMAP as it stands right now?

-- 
Cyrus Daboo

Date: Tue, 6 Dec 2005 18:19:13 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

At 2005-12-04 00:33:10 +0000, [email-masked] wrote:
>
> I'd like to propose that instead of adding additional commands
> for METADATA and, for instance, ACL2, that wherever possible we
> add return options to LIST-EXTENDED instead, and define a single
> SET command.

I like that idea very much.

-- ams

Date: Tue, 6 Dec 2005 18:17:50 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATEMORE update
Sender: [email-masked]

At 2005-12-01 19:09:54 -0500, [email-masked] wrote:
>
> > Thus, we would have message *annotations*, and mailbox and server
> > *metadata*.
> 
> I would be fine with a change like this to - what do others think?

Sounds good to me.

-- ams

Date: Tue, 06 Dec 2005 12:07:28 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: [email-masked]
Subject: Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

[Please excuse me for sending empty reply to the mailing list, was 
caused by mail client crash...]

Dave Cridland wrote:

> Firstly, I'm fine with METADATA as a capability name. I've seen plenty 
> of confusion about ANNOTATEMORE as a name anyway.
>
> But, if we're going to change the protocol anyway, can we consider 
> rewriting the protocol a little more?

I would like to second this opinion.

> It occurs to me that other mailbox attributes fit the model of needing 
> to be able to set them, and retreive them. I'd like to propose that 
> instead of adding additional commands for METADATA and, for instance, 
> ACL2, that wherever possible we add return options to LIST-EXTENDED 
> instead, and define a single SET command.
>
> For METADATA, this would look something like:
>
> A01 SET "INBOX" METADATA ...
>
> For ACL2, this would look like:
>
> A02 SET "INBOX" ACL ...
>
> (Note that SET is probably not descriptive enough. Perhaps CHANGE 
> might be a better name.)
>
> Reading metadata would be done by LIST-EXTENDED, both for ACL2 and for 
> METADATA. I believe the extension syntax now defined for LIST-EXTENDED 
> supports this complexity of syntax.
>
> This should reduce the number of commands in a session, and therefore 
> the number of round-trips, by allowing clients to obtain all the 
> information about a set of mailboxes in one command.
>
> Incidentally, this simply changes the syntax of ANNOTATEMORE/METADATA 
> and potentially ACL2, not the semantics.

From: [email-masked]
Date: Tue, 6 Dec 2005 10:39:17 +0000
Sender: [email-masked]

Date: Sat, 3 Dec 2005 19:05:53 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

For what it's worth, I agree with these comments/suggestions.

On Sun, 4 Dec 2005, Dave Cridland wrote:
> Firstly, I'm fine with METADATA as a capability name. I've seen plenty of 
> confusion about ANNOTATEMORE as a name anyway.
>
> But, if we're going to change the protocol anyway, can we consider rewriting 
> the protocol a little more?
>
> It occurs to me that other mailbox attributes fit the model of needing to be 
> able to set them, and retreive them. I'd like to propose that instead of 
> adding additional commands for METADATA and, for instance, ACL2, that 
> wherever possible we add return options to LIST-EXTENDED instead, and define 
> a single SET command.
>
> For METADATA, this would look something like:
>
> A01 SET "INBOX" METADATA ...
>
> For ACL2, this would look like:
>
> A02 SET "INBOX" ACL ...
>
> (Note that SET is probably not descriptive enough. Perhaps CHANGE might be a 
> better name.)
>
> Reading metadata would be done by LIST-EXTENDED, both for ACL2 and for 
> METADATA. I believe the extension syntax now defined for LIST-EXTENDED 
> supports this complexity of syntax.
>
> This should reduce the number of commands in a session, and therefore the 
> number of round-trips, by allowing clients to obtain all the information 
> about a set of mailboxes in one command.
>
> Incidentally, this simply changes the syntax of ANNOTATEMORE/METADATA and 
> potentially ACL2, not the semantics.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Sun, 04 Dec 2005 00:33:10 +0000
Subject: ANNOTATEMORE/METADATA
From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Firstly, I'm fine with METADATA as a capability name. I've seen 
plenty of confusion about ANNOTATEMORE as a name anyway.

But, if we're going to change the protocol anyway, can we consider 
rewriting the protocol a little more?

It occurs to me that other mailbox attributes fit the model of 
needing to be able to set them, and retreive them. I'd like to 
propose that instead of adding additional commands for METADATA and, 
for instance, ACL2, that wherever possible we add return options to 
LIST-EXTENDED instead, and define a single SET command.

For METADATA, this would look something like:

A01 SET "INBOX" METADATA ...

For ACL2, this would look like:

A02 SET "INBOX" ACL ...

(Note that SET is probably not descriptive enough. Perhaps CHANGE 
might be a better name.)

Reading metadata would be done by LIST-EXTENDED, both for ACL2 and 
for METADATA. I believe the extension syntax now defined for 
LIST-EXTENDED supports this complexity of syntax.

This should reduce the number of commands in a session, and therefore 
the number of round-trips, by allowing clients to obtain all the 
information about a set of mailboxes in one command.

Incidentally, this simply changes the syntax of ANNOTATEMORE/METADATA 
and potentially ACL2, not the semantics.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Fri, 02 Dec 2005 11:22:54 -0500
From: Barry Leiba <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATEMORE update
Sender: [email-masked]

>> Thus, we would have message *annotations*, and mailbox and server
>> *metadata*.
> 
> I would be fine with a change like this to - what do others think?

+1

Barry

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

Date: Thu, 1 Dec 2005 18:18:35 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: "Vaudreuil, Greg M (Greg)" <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: RE: ANNOTATEMORE update
Sender: [email-masked]

On Thu, 1 Dec 2005, Vaudreuil, Greg M (Greg) wrote:
> I find METADATA to be very generic... It does not imply data about the mailbox to me any more than annotations did. How about MBXDATA?

The problem with MBXDATA is that it doesn't cover what is currently called 
"server annotations"

I don't see a problem with an extension called METADATA (and corresponding 
commands) that deals with "mailbox metadata" and "server metadata".

I agree that small-"metadata" should never be used except with "mailbox" 
or "server" preceeding it.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: RE: ANNOTATEMORE update
Date: Thu, 1 Dec 2005 19:56:32 -0600 
Sender: [email-masked]

I find METADATA to be very generic... It does not imply data about the mailbox to me any more than annotations did. How about MBXDATA? 

Greg V.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ken Murchison
Sent: Thursday, December 01, 2005 7:15 PM
To: IMAP Extensions WG
Subject: Re: ANNOTATEMORE update

Mark Crispin wrote:
> 
> Perhaps ANNOTATEMORE can become METADATA, with corresponding 
> GETMETADATA, and SETMETADATA commands and METADATA response.  If this is 
> done, then "meta data" should be purged from the ANNOTATE document (it's 
> only used twice).
> 
> Thus, we would have message *annotations*, and mailbox and server 
> *metadata*.

FWIW, I like Mark's suggestion here.  METADATA seems like a more
accurate term for "additional mailbox info".  When I think of a mailbox
ACL, I think "metadata", not "annotation".

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University

Date: Thu, 01 Dec 2005 19:14:59 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATEMORE update
Sender: [email-masked]

Mark Crispin wrote:
> 
> Perhaps ANNOTATEMORE can become METADATA, with corresponding 
> GETMETADATA, and SETMETADATA commands and METADATA response.  If this is 
> done, then "meta data" should be purged from the ANNOTATE document (it's 
> only used twice).
> 
> Thus, we would have message *annotations*, and mailbox and server 
> *metadata*.

FWIW, I like Mark's suggestion here.  METADATA seems like a more
accurate term for "additional mailbox info".  When I think of a mailbox
ACL, I think "metadata", not "annotation".

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University

Date: Thu, 01 Dec 2005 19:09:54 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATEMORE update
Sender: [email-masked]

Hi Mark,

--On November 29, 2005 4:10:27 PM -0800 Mark Crispin 
<[email-masked]> wrote:

> Perhaps ANNOTATEMORE can become METADATA, with corresponding GETMETADATA,
> and SETMETADATA commands and METADATA response.  If this is done, then
> "meta data" should be purged from the ANNOTATE document (it's only used
> twice).
>
> Thus, we would have message *annotations*, and mailbox and server
> *metadata*.

I would be fine with a change like this to - what do others think?

-- 
Cyrus Daboo

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-15.txt 
Date: Thu, 01 Dec 2005 18:50:01 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba, A. Melnikov
	Filename	: draft-ietf-imapext-list-extensions-15.txt
	Pages		: 39
	Date		: 2005-12-1
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   have added extensions, such as Mailbox Referrals, that have required
   specialized lists we have had to expand the number of list commands,
   since each extension must add its function to both LIST and LSUB, and
   these commands are not, as they are defined, extensible.  If we've
   needed the extensions to work together, we've had to add a set of
   commands to mix the different options, the set increasing in size
   with each new extension.  This document describes an extension to the
   base LIST command that will allow these additions to be done with
   mutually compatible options to the LIST command, avoiding the
   exponential increase in specialized list commands.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-list-extensions-15.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 20 Dec 2005 12:35:44 -0500
From: Keith Moore <[email-masked]>
To: "Burger, Eric" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Announcement: Notifications List
Sender: [email-masked]

Burger, Eric wrote:
> In Vancouver in the lemonade work group meeting a number of people
> expressed interest in the creation of a list dedicated to the discussion
> of user notification technology.
> 
> This list is for discussions relating to the requirements, definition,
> and directions for message notifications.
> 
> While many requirements are driven by lemonade, there is a broader
> community with interest and expertise that we hope will contribute to
> the discussion here.
> 
> Please keep discussions that relate to lemonade, smtp, simple, etc. on
> their respective lists.

Please do not impose this constraint.  There is already far too much 
tendency for narrowly-focused groups to work in isolation and to ignore 
useful input from parties whose interests are peripheral to the group 
but affected by the group's output.  This in turn causes groups to get 
strong pushback at Last Call which could have been avoided had the group 
not isolated itself.

> Please keep cross-posting to a minimum.  Cross-posting to a number of
> lists will put your message into the spam bucket and will delay or deny
> your message being posted.

If the list manager is going to impose restrictions such as this, it 
would be better if such discussion happened elsewhere than on this list.

Keith

Content-class: urn:content-classes:message
Subject: Announcement: Notifications List
Date: Tue, 20 Dec 2005 10:32:45 -0500
From: "Burger, Eric" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

In Vancouver in the lemonade work group meeting a number of people
expressed interest in the creation of a list dedicated to the discussion
of user notification technology.

This list is for discussions relating to the requirements, definition,
and directions for message notifications.

While many requirements are driven by lemonade, there is a broader
community with interest and expertise that we hope will contribute to
the discussion here.

Please keep discussions that relate to lemonade, smtp, simple, etc. on
their respective lists.

Please keep cross-posting to a minimum.  Cross-posting to a number of
lists will put your message into the spam bucket and will delay or deny
your message being posted.

More information is at 
<https://www1.ietf.org/mailman/listinfo/notifications>

Subject: Re: Fwd: RFC 4314 on IMAP4 Access Control List (ACL) Extension
From: Timo Sirainen <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>, [email-masked]
Date: Tue, 20 Dec 2005 12:13:43 +0200
Sender: [email-masked]

--=-btCBOBW5gi4AS4/j7yZt
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-12-20 at 09:18 +0000, Dave Cridland wrote:
> a) So far, I've not seen any server implementation supporting=20
> multiple mailbox patterns. I noted that this would be relatively=20
> involved to implement server-side myself, but perhaps more tellingly,=20
> although my API supports this, the layer above never actually causes=20
> multiple mailbox patterns to be used. I'm struggling to find a=20
> use-case for multiple mailbox patterns. This may be the nature of a=20
> GUI client, however. (Perhaps if I could "search" for mailboxes by=20
> name, this might occur, but it would be a complex search dialog.)
>=20
> This isn't difficult to implement server-side, but my impression is=20
> that it's possibly more trouble than its worth. I appreciate this has=20
> probably been debated heavily before when this feature was added, but=20
> I'd personally like to gain some idea of what the consensus is.

I don't remember seeing discussion when it was added, but I think I
remember there being a discussion about removing it since it's not so
useful. I'd support removing it. Clients can just send multiple LIST
commands at once if they need multiple patterns.

--=-btCBOBW5gi4AS4/j7yZt
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-btCBOBW5gi4AS4/j7yZt--

Date: Tue, 20 Dec 2005 09:18:23 +0000
Subject: Re: Fwd: RFC 4314 on IMAP4 Access Control List (ACL) Extension
From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Thu Dec 15 01:53:55 2005, Lisa Dusseault wrote:
> Whoohoo!  Now let's get another one done -- LISTEXT reviews, 
> anybody?

Some comments:

1) I found the ABNF strikingly difficult to follow. This is largely 
because it's complex, but also because I spent some ten minutes 
looking for the LIST response, in order to see if I agreed with the 
syntactic rules, and finally realized that the reason I couldn't find 
it is simply that it's not there. Only the payload is, under an ABNF 
rule the name of which I've forgotten. A note at the beginning 
pointing to that rule would be useful.

2) I disagree with the statement that ACAP will never move to Draft. 
I don't think this belongs in a normative section, it's merely an 
opinion, and one which I hope to rectify.

I've not had time to verify the examples - I'll try to do so, but I 
doubt I'll have time before the new year.

I've implemented the complete specification through to API level in a 
client, and performed interoperability testing against a server 
implementation.

I've also sketched out a server implementation to gain some idea of 
where the complexities lie, and avoid the usual crop of comments that 
as a mere client implementor I know nothing.

Some comments:

a) So far, I've not seen any server implementation supporting 
multiple mailbox patterns. I noted that this would be relatively 
involved to implement server-side myself, but perhaps more tellingly, 
although my API supports this, the layer above never actually causes 
multiple mailbox patterns to be used. I'm struggling to find a 
use-case for multiple mailbox patterns. This may be the nature of a 
GUI client, however. (Perhaps if I could "search" for mailboxes by 
name, this might occur, but it would be a complex search dialog.)

This isn't difficult to implement server-side, but my impression is 
that it's possibly more trouble than its worth. I appreciate this has 
probably been debated heavily before when this feature was added, but 
I'd personally like to gain some idea of what the consensus is.

b) RECURSIVEMATCH turns out to be easy, given that it only works on 
SUBSCRIBED, thus making it, in effect, an LSUB equivalent. I suspect 
it would be difficult in a more generic implementation. However, I 
think its value will outweigh its complexity.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 20 Dec 2005 08:51:56 +0000
Subject: Re: Fwd: RFC 4314 on IMAP4 Access Control List (ACL) Extension
From: Dave Cridland <[email-masked]>
To: Arnaud Taddei <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Tue Dec 20 05:25:26 2005, Arnaud Taddei wrote:
> Lisa Dusseault wrote:
> 
>> Whoohoo! Now let's get another one done -- LISTEXT reviews, 
>> anybody?
> 
> Before I come to that, in RFC 4314, I arrived too late on my review 
> of the draft.
> 
> So here is the typos I found but I may be wrong. For the content I 
> will make another mail as I have a couple of problems ...
> 
> Can one review the example of page 6? I read
> 
> C: A002 getacl INBOX/Drafts
> S: * ACL INBOX Fred rwipslxcetda David lrswideta
> S: A002 OK Getacl complete
> 
> But shouldn't it be:
> 
> C: A002 getacl INBOX/Drafts
> S: * ACL INBOX*/Drafts* Fred rwipslxcetda David lrswideta
> S: A002 OK Getacl complete
> 
> 
Indeed, that does appear to be an errata.

> BTW I really dislikes folders below INBOX
> 
> Same thing on page 7 no? I read
> 
> C: A003 Setacl INBOX/Drafts Byron lrswikda
> S: A001 OK Setacl complete
> C: A002 getAcl INBOX/Drafts
> S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
> S: A002 OK Getacl complete
> 
> 
Yep, same.

> On page 11: the sentence:
> 
> The MYRIGHTS command returns the set of rights that the user has to
> mailbox in an untagged MYRIGHTS reply.
> 
> is missing something after 'user has to' ... no?
> 
> 
Well... It's missing "the".

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 20 Dec 2005 06:25:26 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: Fwd: RFC 4314 on IMAP4 Access Control List (ACL) Extension
To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_VqWSSGKZfBxfLeq001foig)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

Lisa Dusseault wrote:

> Whoohoo! Now let's get another one done -- LISTEXT reviews, anybody?

Before I come to that, in RFC 4314, I arrived too late on my review of 
the draft.

So here is the typos I found but I may be wrong. For the content I will 
make another mail as I have a couple of problems ...

Can one review the example of page 6? I read

C: A002 getacl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda David lrswideta
S: A002 OK Getacl complete

But shouldn't it be:

C: A002 getacl INBOX/Drafts
S: * ACL INBOX*/Drafts* Fred rwipslxcetda David lrswideta
S: A002 OK Getacl complete

BTW I really dislikes folders below INBOX

Same thing on page 7 no? I read

C: A003 Setacl INBOX/Drafts Byron lrswikda
S: A001 OK Setacl complete
C: A002 getAcl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
S: A002 OK Getacl complete

But shouldn't it be:

C: A003 Setacl INBOX/Drafts Byron lrswikda
S: A001 OK Setacl complete
C: A002 getAcl INBOX/Drafts
S: * ACL INBOX/Drafts Fred rwipslxcetda Byron lrswikcdeta
S: A002 OK Getacl complete

On page 11: the sentence:

The MYRIGHTS command returns the set of rights that the user has to
mailbox in an untagged MYRIGHTS reply.

is missing something after 'user has to' ... no?

A++

>
> lisa
>
> Begin forwarded message:
>
>     *From: [email-masked]
>     *Date: *December 12, 2005 11:34:06 AM PST
>     *To: [email-masked]
>     *Cc: [email-masked], [email-masked]
>     *Subject: RFC 4314 on IMAP4 Access Control List (ACL) Extension
>     *
>
>     A new Request for Comments is now available in online RFC libraries.
>
>
>     RFC 4314
>
>     Title: IMAP4 Access Control List (ACL) Extension
>     Author(s): A. Melnikov
>     Status: Standards Track
>     Date: December 2005
>     Mailbox: [email-masked]
>     Pages: 27
>     Characters: 56599
>     Obsoletes: 2086
>
>     I-D Tag: draft-ietf-imapext-2086upd-08.txt
>
>     URL: ftp://ftp.rfc-editor.org/in-notes/rfc4314.txt
>
>
>     The Access Control List (ACL) extension (RFC 2086) of the Internet
>     Message Access Protocol (IMAP) permits mailbox access control lists
>     to be retrieved and manipulated through the IMAP protocol.
>
>     This document is a revision of RFC 2086. It defines several new
>     access control rights and clarifies which rights are required for
>     different IMAP commands.
>
>     This document is a product of the Internet Message Access Protocol
>     Extension Working Group of the IETF.
>
>     This is now a Proposed Standard Protocol.
>
>     This document specifies an Internet standards track protocol for the
>     Internet community, and requests discussion and suggestions for
>     improvements. Please refer to the current edition of the "Internet
>     Official Protocol Standards" (STD 1) for the standardization state
>     and status of this protocol. Distribution of this memo is unlimited.
>
>     This announcement is sent to the IETF list and the RFC-DIST list.
>     Requests to be added to or deleted from the IETF distribution list
>     should be sent to [email-masked]. Requests to be
>     added to or deleted from the RFC-DIST distribution list should
>     be sent to [email-masked].
>
>     Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
>     an EMAIL message to [email-masked] with the message body
>     help: ways_to_get_rfcs. For example:
>
>     To: [email-masked]
>     Subject: getting rfcs
>
>     help: ways_to_get_rfcs
>
>     Requests for special distribution should be addressed to either the
>     author of the RFC in question, or to [email-masked].
>     Unless
>     specifically noted otherwise on the RFC itself, all RFCs are for
>     unlimited distribution.
>
>     Submissions for Requests for Comments should be sent to
>     [email-masked]. Please consult RFC 2223, Instructions
>     to RFC
>     Authors, for further information.
>
>
>     Joyce K. Reynolds and Sandy Ginoza
>     USC/Information Sciences Institute
>
>     ...
>
>     Below is the data which will enable a MIME compliant Mail Reader
>     implementation to automatically retrieve the ASCII version
>     of the RFCs.
>     Content-Type: text/plain
>     Content-ID: <[email-masked]>
>
>

-- 
<http://www.sun.com> 	* Arnaud Taddei *
Senior Architect Communications Products

*Sun Microsystems, Inc.*
Phone x13541/+41(22)99904-41
Mobile +41 (0)79 506 1129
Email [email-masked]

--Boundary_(ID_VqWSSGKZfBxfLeq001foig)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Lisa Dusseault wrote:
<blockquote cite="[email-masked]"
 type="cite">Whoohoo! Now let's get another one done -- LISTEXT
reviews, anybody?
  <br>
</blockquote>
Before I come to that, in RFC 4314, I arrived too late on my review of
the draft.<br>
<br>
So here is the typos I found but I may be wrong. For the content I will
make another mail as I have a couple of problems ...<br>
<br>
Can one review the example of page 6? I read<br>
<blockquote>
  <pre><font color="#330099">C: A002 getacl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda David lrswideta
S: A002 OK Getacl complete</font></pre>
</blockquote>
But shouldn't it be:<br>
<blockquote>
  <pre><font color="#330099">C: A002 getacl INBOX/Drafts
S: * ACL INBOX<b>/Drafts</b> Fred rwipslxcetda David lrswideta
S: A002 OK Getacl complete</font></pre>
</blockquote>
BTW I really dislikes folders below INBOX<br>
<br>
Same thing on page 7 no? I read<br>
<blockquote>
  <pre><font color="#330099">C: A003 Setacl INBOX/Drafts Byron lrswikda
S: A001 OK Setacl complete
C: A002 getAcl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
S: A002 OK Getacl complete</font></pre>
</blockquote>
But shouldn't it be:<br>
<blockquote>
  <pre><font color="#330099">C: A003 Setacl INBOX/Drafts Byron lrswikda
S: A001 OK Setacl complete
C: A002 getAcl INBOX/Drafts
S: * ACL INBOX/Drafts Fred rwipslxcetda Byron lrswikcdeta
S: A002 OK Getacl complete</font></pre>
</blockquote>
On page 11: the sentence:<br>
<blockquote>
  <pre><font color="#330099">The MYRIGHTS command returns the set of rights that the user has to
mailbox in an untagged MYRIGHTS reply.</font></pre>
</blockquote>
is missing something after '<font color="#330099"><tt>user has to</tt></font>'
... no?<br>
<br>
A++<br>
<blockquote cite="[email-masked]"
 type="cite"><br>
lisa
  <br>
  <br>
Begin forwarded message:
  <br>
  <br>
  <blockquote><b><!-- 0000,0000,0000 -->From:
    </b><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
    <b><!-- 0000,0000,0000 -->Date:
    </b>December 12, 2005 11:34:06 AM PST
    <br>
    <b><!-- 0000,0000,0000 -->To:
    </b><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
    <b><!-- 0000,0000,0000 -->Cc:
    </b><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>, <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
    <b><!-- 0000,0000,0000 -->Subject: RFC 4314 on
IMAP4 Access Control List (ACL) Extension
    <br>
    </b><br>
    <br>
A new Request for Comments is now available in online RFC libraries.
    <br>
    <br>
    <br>
RFC 4314
    <br>
    <br>
Title: IMAP4 Access Control List (ACL) Extension
    <br>
Author(s): A. Melnikov
    <br>
Status: Standards Track
    <br>
Date: December 2005
    <br>
Mailbox: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
Pages: 27
    <br>
Characters: 56599
    <br>
Obsoletes: 2086
    <br>
    <br>
I-D Tag: draft-ietf-imapext-2086upd-08.txt
    <br>
    <br>
URL: <a class="moz-txt-link-freetext" href="ftp://ftp.rfc-editor.org/in-notes/rfc4314.txt">ftp://ftp.rfc-editor.org/in-notes/rfc4314.txt</a>
    <br>
    <br>
    <br>
The Access Control List (ACL) extension (RFC 2086) of the Internet
    <br>
Message Access Protocol (IMAP) permits mailbox access control lists
    <br>
to be retrieved and manipulated through the IMAP protocol.
    <br>
    <br>
This document is a revision of RFC 2086. It defines several new
    <br>
access control rights and clarifies which rights are required for
    <br>
different IMAP commands.
    <br>
    <br>
This document is a product of the Internet Message Access Protocol
    <br>
Extension Working Group of the IETF.
    <br>
    <br>
This is now a Proposed Standard Protocol.
    <br>
    <br>
This document specifies an Internet standards track protocol for the
    <br>
Internet community, and requests discussion and suggestions for
    <br>
improvements. Please refer to the current edition of the "Internet
    <br>
Official Protocol Standards" (STD 1) for the standardization state
    <br>
and status of this protocol. Distribution of this memo is unlimited.
    <br>
    <br>
This announcement is sent to the IETF list and the RFC-DIST list.
    <br>
Requests to be added to or deleted from the IETF distribution list
    <br>
should be sent to <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>. Requests to be
    <br>
added to or deleted from the RFC-DIST distribution list should
    <br>
be sent to <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>.
    <br>
    <br>
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
    <br>
an EMAIL message to <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> with the message body <br>
help: ways_to_get_rfcs. For example:
    <br>
    <br>
To: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    <br>
Subject: getting rfcs
    <br>
    <br>
help: ways_to_get_rfcs
    <br>
    <br>
Requests for special distribution should be addressed to either the
    <br>
author of the RFC in question, or to <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>. Unless
    <br>
specifically noted otherwise on the RFC itself, all RFCs are for
    <br>
unlimited distribution.
    <br>
    <br>
Submissions for Requests for Comments should be sent to
    <br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>. Please consult RFC 2223, Instructions to
RFC
    <br>
Authors, for further information.
    <br>
    <br>
    <br>
Joyce K. Reynolds and Sandy Ginoza
    <br>
USC/Information Sciences Institute
    <br>
    <br>
...
    <br>
    <br>
Below is the data which will enable a MIME compliant Mail Reader <br>
implementation to automatically retrieve the ASCII version
    <br>
of the RFCs.
    <br>
Content-Type: text/plain
    <br>
Content-ID: <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
    <br>
  </blockquote>
  <br>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<table border="0" cellpadding="0" cellspacing="0" width="450">
  <tbody>
    <tr valign="top">
      <td height="121" width="121"><a href="http://www.sun.com"><img
 moz-do-not-send="true" src="http://www.sun.com/emrkt/sigs/6g_top.gif"
 border="0" height="116" width="121"></a></td>
      <td style="font-family: Arial; font-size: 10px;" height="121"
 width="329"><b> Arnaud Taddei </b><br>
Senior Architect Communications Products<br>
      <br>
      <b>Sun Microsystems, Inc.</b><br>
Phone x13541/+41(22)99904-41<br>
Mobile +41 (0)79 506 1129<br>
Email <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
      </td>
    </tr>
  </tbody>
</table>
</div>
</body>
</html>

--Boundary_(ID_VqWSSGKZfBxfLeq001foig)--

Date: Mon, 19 Dec 2005 16:21:03 -0600
To: Mark Crispin <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Cc: Dave Cridland <[email-masked]>, Curtis King <[email-masked]>, [email-masked], Cyrus Daboo <[email-masked]>
Sender: [email-masked]

On 12/7/05 at 1:29 PM -0800, Mark Crispin wrote:

>Many people have forgotten the original IETF credo, coined (I think) 
>by Bob Braden:
>	We reject: kings, presidents and voting.
>	We believe in: rough concensus and running code.

It's usually attributed to Dave Clark.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

Content-class: urn:content-classes:message
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
Date: Sun, 18 Dec 2005 20:30:00 -0000
From: "Edward Hibbert" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C60412.12A958B5
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>From my point of view, the most interesting IMAP clients are those which =
are most widely deployed :-).

The following link from Microsoft contains a claim that most IMAP =
clients don't support referrals:

http://tinyurl.com/9yyf3

Which I think I'll take as indicating that Microsoft clients don't. =20

Shame, I was hoping to use referrals.  But if Microsoft clients don't =
support it, that's not an option.

Regards,

Edward.

-----Original Message-----
From: [email-masked] on behalf of Mark Crispin
Sent: Fri 16/12/2005 16:46
To: Edward Hibbert
Cc: [email-masked]
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
=20
On Fri, 16 Dec 2005, Edward Hibbert wrote:
> What about common clients like Thunderbird, Outlook, Outlook Express?

For understandable reasons, Microsoft never uses open source software=20
(other than open source software that it developed) as a matter of =
policy.=20
Outlook and OE *may* support login referrals, though, as Microsoft was =
one=20
of the instigators for referrals.

I don't know what Thunderbird uses, but I doubt that it uses c-client.

I don't consider any of these three to be particularly interesting as =
IMAP=20
clients.  There are much better IMAP clients out there, and most of =
those=20
are open source.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

------_=_NextPart_001_01C60412.12A958B5
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 =
6.5.7638.1">
<TITLE>RE: Support for IMAP LOGIN referrals (RFC2221)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>From my point of view, the most interesting IMAP =
clients are those which are most widely deployed :-).<BR>
<BR>
The following link from Microsoft contains a claim that most IMAP =
clients don't support referrals:<BR>
<BR>
<A HREF=3D"http://tinyurl.com/9yyf3">http://tinyurl.com/9yyf3</A><BR>
<BR>
Which I think I'll take as indicating that Microsoft clients =
don't.&nbsp;<BR>
<BR>
Shame, I was hoping to use referrals.&nbsp; But if Microsoft clients =
don't support it, that's not an option.<BR>
<BR>
Regards,<BR>
<BR>
Edward.<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of Mark Crispin<BR>
Sent: Fri 16/12/2005 16:46<BR>
To: Edward Hibbert<BR>
Cc: [email-masked]<BR>
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)<BR>
<BR>
On Fri, 16 Dec 2005, Edward Hibbert wrote:<BR>
&gt; What about common clients like Thunderbird, Outlook, Outlook =
Express?<BR>
<BR>
For understandable reasons, Microsoft never uses open source =
software<BR>
(other than open source software that it developed) as a matter of =
policy.<BR>
Outlook and OE *may* support login referrals, though, as Microsoft was =
one<BR>
of the instigators for referrals.<BR>
<BR>
I don't know what Thunderbird uses, but I doubt that it uses =
c-client.<BR>
<BR>
I don't consider any of these three to be particularly interesting as =
IMAP<BR>
clients.&nbsp; There are much better IMAP clients out there, and most of =
those<BR>
are open source.<BR>
<BR>
-- Mark --<BR>
<BR>
<A HREF=3D"http://panda.com/mrc">http://panda.com/mrc</A><BR>
Democracy is two wolves and a sheep deciding what to eat for lunch.<BR>
Liberty is a well-armed sheep contesting the vote.<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C60412.12A958B5--

Date: Fri, 16 Dec 2005 18:26:01 +0000
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
From: Dave Cridland <[email-masked]>
To: Edward Hibbert <[email-masked]>
Cc: <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

On Fri Dec 16 16:42:22 2005, Edward Hibbert wrote:
> 
> What about common clients like Thunderbird, Outlook, Outlook 
> Express?
> 
> 
Thunderbird uses the Mozilla Mail/News component - I don't know if 
that supports RFC2221 or not, but based on memory, I don't think it's 
one of the extensions supported. Novell's Evolution, as far as I'm 
aware, does not either.

Since someone from Microsoft wrote RFC2221, and moreover I seem to 
recall that Exchange supports it, one would assume that Outlook 
Express would also support it, but the only way you'll find out is to 
test, I'm afraid. Outlook may, as well, but I believe their IMAP 
implementations are distinct.

My own client, Polymer, does not support RFC2221 - but if there were 
interest, I'd probably put it in.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Fri, 16 Dec 2005 08:46:48 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Edward Hibbert <[email-masked]>
cc: [email-masked]
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
Sender: [email-masked]

On Fri, 16 Dec 2005, Edward Hibbert wrote:
> What about common clients like Thunderbird, Outlook, Outlook Express?

For understandable reasons, Microsoft never uses open source software 
(other than open source software that it developed) as a matter of policy. 
Outlook and OE *may* support login referrals, though, as Microsoft was one 
of the instigators for referrals.

I don't know what Thunderbird uses, but I doubt that it uses c-client.

I don't consider any of these three to be particularly interesting as IMAP 
clients.  There are much better IMAP clients out there, and most of those 
are open source.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Content-class: urn:content-classes:message
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
Date: Fri, 16 Dec 2005 16:42:22 -0000
From: "Edward Hibbert" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

What about common clients like Thunderbird, Outlook, Outlook Express?

Regards,

Edward. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark Crispin
Sent: 16 December 2005 16:40
To: Edward Hibbert
Cc: [email-masked]
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)

On Fri, 16 Dec 2005, Edward Hibbert wrote:
> Jolly good argument for the UW c-client library.  Do any other clients

> use it?

I don't have a list, but I can think of several current and past client
projects which used c-client.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Fri, 16 Dec 2005 08:40:07 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Edward Hibbert <[email-masked]>
cc: [email-masked]
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
Sender: [email-masked]

On Fri, 16 Dec 2005, Edward Hibbert wrote:
> Jolly good argument for the UW c-client library.  Do any other clients
> use it?

I don't have a list, but I can think of several current and past client 
projects which used c-client.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Content-class: urn:content-classes:message
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
Date: Fri, 16 Dec 2005 16:38:33 -0000
From: "Edward Hibbert" <[email-masked]>
To: "Mark Crispin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Jolly good argument for the UW c-client library.  Do any other clients
use it?

Edward. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark Crispin
Sent: 16 December 2005 16:36
To: Edward Hibbert
Cc: [email-masked]
Subject: Re: Support for IMAP LOGIN referrals (RFC2221)

On Fri, 16 Dec 2005, Edward Hibbert wrote:
> Does anyone have a list of which clients support this RFC?  I have the

> impression that it's not widely supported, so would welcome definitive

> information on
> *	clients which do
> *	clients which don't
> *	the types of problems which arise with clients which don't.

Pine supports LOGIN referrals, as would any other client that uses the
UW c-client library.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Fri, 16 Dec 2005 08:36:04 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Edward Hibbert <[email-masked]>
cc: [email-masked]
Subject: Re: Support for IMAP LOGIN referrals (RFC2221)
Sender: [email-masked]

On Fri, 16 Dec 2005, Edward Hibbert wrote:
> Does anyone have a list of which clients support this RFC?  I have the
> impression that it's not widely supported, so would welcome definitive
> information on
> *	clients which do
> *	clients which don't
> *	the types of problems which arise with clients which don't.

Pine supports LOGIN referrals, as would any other client that uses the UW 
c-client library.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Content-class: urn:content-classes:message
Subject: Support for IMAP LOGIN referrals (RFC2221)
Date: Fri, 16 Dec 2005 16:17:31 -0000
From: "Edward Hibbert" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6025C.37CD9E6D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Does anyone have a list of which clients support this RFC?  I have the
impression that it's not widely supported, so would welcome definitive
information on=20

*	clients which do
*	clients which don't
*	the types of problems which arise with clients which don't.

Thanks,
=20
Edward Hibbert.

------_=_NextPart_001_01C6025C.37CD9E6D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D836321616-16122005><FONT face=3DArial color=3D#ff00ff =
size=3D2>Does=20
anyone have a list of which clients support this RFC?&nbsp; I have the=20
impression that it's not widely supported, so would welcome definitive=20
information on </FONT></SPAN></DIV>
<UL>
  <LI><SPAN class=3D836321616-16122005><FONT face=3DArial =
color=3D#ff00ff=20
  size=3D2>clients which do</FONT></SPAN></LI>
  <LI><SPAN class=3D836321616-16122005><FONT face=3DArial =
color=3D#ff00ff=20
  size=3D2>clients which don't</FONT></SPAN></LI>
  <LI><SPAN class=3D836321616-16122005><FONT face=3DArial =
color=3D#ff00ff size=3D2>the=20
  types of problems which arise with clients which =
don't.</FONT></SPAN></LI></UL>
<DIV><SPAN class=3D836321616-16122005><FONT face=3DArial color=3D#ff00ff =

size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D836321616-16122005><FONT face=3DArial color=3D#ff00ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D836321616-16122005><FONT face=3DArial color=3D#ff00ff =
size=3D2>Edward=20
Hibbert.</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C6025C.37CD9E6D--

Subject: Re: ANNOTATEMORE update
From: Alexandros Vellis <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Organization: National & Kapodistrian University of Athens
Date: Thu, 15 Dec 2005 11:53:11 +0200
Sender: [email-masked]

Hello,

> > Thus, we would have message *annotations*, and mailbox and server
> > *metadata*.
> 
> I would be fine with a change like this to - what do others think?

I like it. :)

-- 
Alexandros Vellis
[email-masked]

Date: Wed, 14 Dec 2005 21:09:18 -0500
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Fwd: RFC 4314 on IMAP4 Access Control List (ACL) Extension
Sender: [email-masked]

Hi Lisa,

--On December 14, 2005 5:53:55 PM -0800 Lisa Dusseault 
<[email-masked]> wrote:

> Whoohoo!  Now let's get another one done -- LISTEXT reviews, anybody?

Can we clarify what people want to do about the ANNOTATEMORE/METADATA vs 
SET/LISTEXT thread? Is there consensus to move forward with a generic SET 
mechanism or not? I'm not sure that that has to affect LISTEXT, but I think 
we need to think it through a bit. For example, given that LISTEXT still 
requires the reference argument for mailbox names, wouldn't that also be 
needed in the SET command for consistency?

-- 
Cyrus Daboo

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Fwd: RFC 4314 on IMAP4 Access Control List (ACL) Extension
Date: Wed, 14 Dec 2005 17:53:55 -0800
Sender: [email-masked]

--Apple-Mail-11--461870765
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Whoohoo!  Now let's get another one done -- LISTEXT reviews, anybody?

lisa

Begin forwarded message:

> From: [email-masked]
> Date: December 12, 2005 11:34:06 AM PST
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: RFC 4314 on IMAP4 Access Control List (ACL) Extension
>
>
> A new Request for Comments is now available in online RFC libraries.
>
>
>         RFC 4314
>
>         Title:      IMAP4 Access Control List (ACL) Extension
>         Author(s):  A. Melnikov
>         Status:     Standards Track
>         Date:       December 2005
>         Mailbox:    [email-masked]
>         Pages:      27
>         Characters: 56599
>         Obsoletes:  2086
>
>         I-D Tag:    draft-ietf-imapext-2086upd-08.txt
>
>         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4314.txt
>
>
> The Access Control List (ACL) extension (RFC 2086) of the Internet
> Message Access Protocol (IMAP) permits mailbox access control lists
> to be retrieved and manipulated through the IMAP protocol.
>
> This document is a revision of RFC 2086.  It defines several new
> access control rights and clarifies which rights are required for
> different IMAP commands.
>
> This document is a product of the Internet Message Access Protocol
> Extension Working Group of the IETF.
>
> This is now a Proposed Standard Protocol.
>
> This document specifies an Internet standards track protocol for the
> Internet community, and requests discussion and suggestions for
> improvements.  Please refer to the current edition of the "Internet
> Official Protocol Standards" (STD 1) for the standardization state
> and status of this protocol.  Distribution of this memo is unlimited.
>
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [email-masked].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [email-masked].
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [email-masked] with the message body
> help: ways_to_get_rfcs.  For example:
>
>         To: [email-masked]
>         Subject: getting rfcs
>
>         help: ways_to_get_rfcs
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  
> Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
> Submissions for Requests for Comments should be sent to
> [email-masked].  Please consult RFC 2223, Instructions to 
> RFC
> Authors, for further information.
>
>
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
>
> ...
>
> Below is the data which will enable a MIME compliant Mail Reader
> implementation to automatically retrieve the ASCII version
> of the RFCs.
> Content-Type: text/plain
> Content-ID: <[email-masked]>

--Apple-Mail-11--461870765
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

Whoohoo!  Now let's get another one done -- LISTEXT reviews, anybody?

lisa

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Date:
</color></bold>December 12, 2005 11:34:06 AM PST

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>[email-masked], [email-masked]

<bold><color><param>0000,0000,0000</param>Subject: </color>RFC 4314 on
IMAP4 Access Control List (ACL) Extension

</bold>

A new Request for Comments is now available in online RFC libraries.

        RFC 4314

        Title:      IMAP4 Access Control List (ACL) Extension

        Author(s):  A. Melnikov

        Status:     Standards Track

        Date:       December 2005

        Mailbox:    [email-masked]

        Pages:      27

        Characters: 56599

        Obsoletes:  2086

        I-D Tag:    draft-ietf-imapext-2086upd-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4314.txt

The Access Control List (ACL) extension (RFC 2086) of the Internet

Message Access Protocol (IMAP) permits mailbox access control lists

to be retrieved and manipulated through the IMAP protocol.

This document is a revision of RFC 2086.  It defines several new

access control rights and clarifies which rights are required for

different IMAP commands.

This document is a product of the Internet Message Access Protocol

Extension Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements.  Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.

Requests to be added to or deleted from the IETF distribution list

should be sent to [email-masked].  Requests to be

added to or deleted from the RFC-DIST distribution list should

be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending

an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs.  For example:

        To: [email-masked]

        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the

author of the RFC in question, or to [email-masked]. 
Unless

specifically noted otherwise on the RFC itself, all RFCs are for

unlimited distribution.

Submissions for Requests for Comments should be sent to

[email-masked].  Please consult RFC 2223, Instructions to
RFC

Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza

USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 

implementation to automatically retrieve the ASCII version

of the RFCs.

Content-Type: text/plain

Content-ID: <<[email-masked]>

</excerpt>
--Apple-Mail-11--461870765--

Date: Fri, 9 Dec 2005 09:44:46 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Moving IDLE to Draft Standard
Cc: Barry Leiba <[email-masked]>, Mark Crispin <[email-masked]>, Timo Sirainen <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> On Thu, 8 Dec 2005, Dave Cridland wrote:
>> The client would have to ACK, which is a transmission, which uses up 
>> battery on mobile devices. This might be a waste of effort, if the 
>> client isn't on NAT.
>
> Agreed; but before that change was put into UW imapd, users of Outlook 
> [Express] with NAT boxes were screwed.  I doubt OE will ever get 
> fixed.

I think what Dave minds is that the workaround is so wide. Ideally, the 
workaround should affect only OE clients behind NAT boxes. However, I 
cannot suggest any (tasteful) way to detect that.

Maybe turn the workaround off when the client uses a LEMONADE extension, 
or if IPv6 is used.

Arnt

To: [email-masked]
Subject: RFC 4314 on IMAP4 Access Control List (ACL) Extension
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Mon, 12 Dec 2005 11:34:06 -0800
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 4314

        Title:      IMAP4 Access Control List (ACL) Extension
        Author(s):  A. Melnikov
        Status:     Standards Track
        Date:       December 2005
        Mailbox:    [email-masked]
        Pages:      27
        Characters: 56599
        Obsoletes:  2086

        I-D Tag:    draft-ietf-imapext-2086upd-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4314.txt

The Access Control List (ACL) extension (RFC 2086) of the Internet
Message Access Protocol (IMAP) permits mailbox access control lists
to be retrieved and manipulated through the IMAP protocol.

This document is a revision of RFC 2086.  It defines several new
access control rights and clarifies which rights are required for
different IMAP commands.

This document is a product of the Internet Message Access Protocol
Extension Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements.  Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--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]>

RETRIEVE: rfc
DOC-ID: rfc4314

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc4314.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--

Date: Thu, 8 Dec 2005 11:49:06 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Timo Sirainen <[email-masked]>, [email-masked], Barry Leiba <[email-masked]>
Subject: Re: Moving IDLE to Draft Standard
Sender: [email-masked]

On Thu, 8 Dec 2005, Dave Cridland wrote:
> The client would have to ACK, which is a transmission, which uses up battery 
> on mobile devices. This might be a waste of effort, if the client isn't on 
> NAT.

Agreed; but before that change was put into UW imapd, users of Outlook 
[Express] with NAT boxes were screwed.  I doubt OE will ever get fixed.

> Like RECONNECT, trying to do much in IDLE to work around this problem is 
> trying to fix something in the application layer that's actually a problem 
> caused by very much lower layers.

Indeed, but that doesn't help in this case.

> All this doesn't argue that "* OK Idling, timeout in 25 minutes" (or whatever 
> UW sends, I forget) is wrong, broken, or anything. I think an informative 
> section reminding client implementors that whilst IDLE, a server may send 
> anything, including OK, NO, or even BAD, is a good idea, and explaining why a 
> server might choose to do so - or a client might choose to break IDLE 
> frequently - is needed. I don't think this affects any existing clients, 
> though, and I also don't think this is normative material.

Agreed.

> The normative bit is saying that the server is allowed to send OK, NO, BAD, 
> etc.

The normative bit is that server is allowed to send ANY untagged response, 
and that the client MUST accept such responses.  A client that only 
expects EXISTS and RECENT is broken.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Thu, 08 Dec 2005 09:09:59 +0000
Subject: Re: Moving IDLE to Draft Standard
From: Dave Cridland <[email-masked]>
To: Timo Sirainen <[email-masked]>
Cc: Mark Crispin <[email-masked]>, <[email-masked]>, Barry Leiba <[email-masked]>
Sender: [email-masked]

On Wed Dec  7 23:18:45 2005, Timo Sirainen wrote:
> On Wed, 2005-12-07 at 20:34 +0000, Dave Cridland wrote:
> > No, that discussion needs to be there, but it's a matter of 
> breaking > up the IDLE with a NOOP every five minutes or so, rather 
> than every > 29.
> > > As far as I'm aware, those firewalls and NATs also reset their 
> timers > whenever the client sends any TCP packet, hence even 
> ACKing > server-sent data counts.
> 
> Has someone tried how this would affect clients? If server sent
> "* OK Still idling" every minute, would clients break out of idle or
> otherwise get confused? Or would there be some other bad side 
> effects?
> 
> 
The client would have to ACK, which is a transmission, which uses up 
battery on mobile devices. This might be a waste of effort, if the 
client isn't on NAT.

The client can probably guess when it's running through a NAT by 
examination of its local address - I've considered putting such code 
in Polymer, but haven't got around to it yet - but it needs to 
minimize the number of IDLE-breaks (as it were - sending something 
like "DONE\r\nA10057 NOOP\r\nA10058 IDLE\r\n") for the same reason. 
Of course, that involves sending more data. I'm really not sure if 
the key factor in mobile device battery life is "a transmission" or 
"a transmitted octet", so I couldn't say if this ends up being worse 
in the worst case.

If a server implementor wants to add an experimental parameter to 
IDLE to indicate how often the server needs to send something, I 
could try some empirical testing across at least one GPRS network.

I actually think the best solution for this particular mess is for 
IMAP to ignore it, at least for now, and for us to examine, and 
obtain good advice on, the various mobility layers over IP (4 and 6). 
I have had a strong suspicion for a while that this would represent 
an excellent solution to these problems, as well as provide 
additional flexibility.

Like RECONNECT, trying to do much in IDLE to work around this problem 
is trying to fix something in the application layer that's actually a 
problem caused by very much lower layers.

All this doesn't argue that "* OK Idling, timeout in 25 minutes" (or 
whatever UW sends, I forget) is wrong, broken, or anything. I think 
an informative section reminding client implementors that whilst 
IDLE, a server may send anything, including OK, NO, or even BAD, is a 
good idea, and explaining why a server might choose to do so - or a 
client might choose to break IDLE frequently - is needed. I don't 
think this affects any existing clients, though, and I also don't 
think this is normative material.

The normative bit is saying that the server is allowed to send OK, 
NO, BAD, etc.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 7 Dec 2005 15:41:42 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: [email-masked]
Subject: Re: Moving IDLE to Draft Standard
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 7 Dec 2005, Barry Leiba wrote:
>>> "* OK Still idling" every minute
>> UW imapd has done this for years, and nobody has complained yet.
> Then should I add an "servers MAY do that", with an explanation of why,
> to the 2177bis spec?

I think so.

-- Mark --

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

Date: Wed, 07 Dec 2005 18:35:51 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Moving IDLE to Draft Standard
Sender: [email-masked]

>> "* OK Still idling" every minute
> 
> UW imapd has done this for years, and nobody has complained yet.

Then should I add an "servers MAY do that", with an explanation of why,
to the 2177bis spec?

Barry

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

Date: Wed, 7 Dec 2005 15:23:45 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Dave Cridland <[email-masked]>, [email-masked], Barry Leiba <[email-masked]>
Subject: Re: Moving IDLE to Draft Standard
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 8 Dec 2005, Timo Sirainen wrote:
> Has someone tried how this would affect clients? If server sent
> "* OK Still idling" every minute, would clients break out of idle or
> otherwise get confused? Or would there be some other bad side effects?

UW imapd has done this for years, and nobody has complained yet.

-- Mark --

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

Subject: Re: Moving IDLE to Draft Standard
From: Timo Sirainen <[email-masked]>
To: Dave Cridland <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked], Barry Leiba <[email-masked]>
Date: Thu, 08 Dec 2005 01:18:45 +0200
Sender: [email-masked]

--=-luCYr+eu0CnXLVAfUD0g
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-12-07 at 20:34 +0000, Dave Cridland wrote:
> No, that discussion needs to be there, but it's a matter of breaking=20
> up the IDLE with a NOOP every five minutes or so, rather than every=20
> 29.
>=20
> As far as I'm aware, those firewalls and NATs also reset their timers=20
> whenever the client sends any TCP packet, hence even ACKing=20
> server-sent data counts.

Has someone tried how this would affect clients? If server sent
"* OK Still idling" every minute, would clients break out of idle or
otherwise get confused? Or would there be some other bad side effects?

--=-luCYr+eu0CnXLVAfUD0g
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-luCYr+eu0CnXLVAfUD0g--

To: IMAP Extensions WG <[email-masked]>, IETF-iCalendar <[email-masked]>, WG Chairs <[email-masked]>, WebDAV WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: OT but nice productivity hack: Yubnub to find RFCs, I-Ds and WGs
Date: Wed, 7 Dec 2005 14:10:17 -0800
Sender: [email-masked]

--Apple-Mail-3-1067395383
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

A co-worker (Jared Rhine) pointed me to Yubnub.org a while back.  I 
have grown addicted to it as a Internet command-line to jump straight 
to what I want.  E.g. I use a command like "thes addicted" to quickly 
find thesaurus matches: absorbed, accustomed, attached... :)

There was one IETF-related yubnub command already and I added two more 
very simple ones.

To jump to an RFC: rfc xxxx
	e.g. 'rfc 2822'  (don't forget space)

Internet-Draft Database Search: (shows list with filename substring 
match): ids keyword
	e.g. 'ids dusseault' to find draft-dusseault-caldav-08, but not 
draft-ietf-webdav-rfc2518bis because 'dusseault' isn't in the title of 
that one

To jump to a WG charter: wg wgname
	e.g. 'wg imapext'

Not only do I get to avoid the thesaurus.com web form to find thesaurus 
matches, I also avoid the Yubnub Web form because I've set up Firefox 
so that I can type a Yubnub command line right into the address bar. 
Other possibilities include using the search engine field or a console 
app <http://www.yubnub.org/documentation/describe_installation>.

Fun, fun.  Hope it's useful to you too.  Let me know if you create 
other IETF-related command lines.  I'll blog about it or something so 
as not to spam people again.

Lisa

--Apple-Mail-3-1067395383
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

A co-worker (Jared Rhine) pointed me to Yubnub.org a while back.  I
have grown addicted to it as a Internet command-line to jump straight
to what I want.  E.g. I use a command like "thes addicted" to quickly
find thesaurus matches: absorbed, accustomed, attached... :)   

There was one IETF-related yubnub command already and I added two more
very simple ones.

To jump to an RFC: <bold>rfc</bold> xxxx

	e.g. 'rfc 2822'  (don't forget space)

Internet-Draft Database Search: (shows list with filename substring
match): <bold>ids</bold> keyword

	e.g. 'ids dusseault' to find draft-dusseault-caldav-08, but not
draft-ietf-webdav-rfc2518bis because 'dusseault' isn't in the title of
that one

To jump to a WG charter: <bold>wg </bold>wgname

	e.g. 'wg imapext'

Not only do I get to avoid the thesaurus.com web form to find
thesaurus matches, I also avoid the Yubnub Web form because I've set
up Firefox so that I can type a Yubnub command line right into the
address bar. Other possibilities include using the search engine field
or a console app
<<http://www.yubnub.org/documentation/describe_installation>.

Fun, fun.  Hope it's useful to you too.  Let me know if you create
other IETF-related command lines.  I'll blog about it or something so
as not to spam people again.

Lisa

--Apple-Mail-3-1067395383--

Date: Wed, 7 Dec 2005 13:57:06 -0800
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked], Barry Leiba <[email-masked]>
Subject: Re: Moving IDLE to Draft Standard
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 7 Dec 2005, Dave Cridland wrote:
> I'm assuming you meant "IDLE" here, not "IMAP".

Correct.  The brain farts with age... :-(

> No, that discussion needs to be there, but it's a matter of breaking up the 
> IDLE with a NOOP every five minutes or so, rather than every 29.

Five minutes may be too slow.  Empirical testing in my server led me to 
crank it up to every two minutes.

> As far as I'm aware, those firewalls and NATs also reset their timers 
> whenever the client sends any TCP packet, hence even ACKing server-sent data 
> counts.
>
> Dave.
> --
>          You see things; and you say "Why?"
>  But I dream things that never were; and I say "Why not?"
>   - George Bernard Shaw
>

-- Mark --

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

Date: Wed, 7 Dec 2005 13:29:10 -0800
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Curtis King <[email-masked]>, [email-masked], Cyrus Daboo <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 7 Dec 2005, Dave Cridland wrote:
> Kind of, but not as simple. Tell me, Mark. Which *are* the functionality 
> requests that should have been turned down? Since, as far as I'm aware, only 
> three individuals have implemented anything approaching the full spec, all 
> after the fact, so how were people meant to know? Where was the running code 
> the IETF is so famous for? Had people tried implementing much earlier, I 
> suspect several features in ACAP may well have been dropped. But nobody knew 
> to say no.

You're proving my point.  I gave up on ACAP long before the spec went to 
last call.  I doubt very much that I was the only person who did.

Sadly, while ACAP was being designed, other people were building their own 
solutions to the problem; and having solved their problem, lost interest 
in ACAP.

> I'm not blaming the individuals involved, here, but if an organization 
> commits the time to work on a protocol, it has to follow through with the 
> running code.

The organization also has to pay attention to the individuals who will 
product the running code.  Early on, ACAP deviated from my needs.

> The IETF is good on the rough consensus, but it's getting a bit flakey on the 
> running code. I'd hate to think how many other Proposed Standards haven't 
> even been prototyped.

Too many people who have not (and never will) produced a line of running 
code are participating in the protocol design process.  That has always 
been a problem, even back in ARPAnet days; but in recent years it has 
become much worse.

Many people have forgotten the original IETF credo, coined (I think) by 
Bob Braden:
 	We reject: kings, presidents and voting.
 	We believe in: rough concensus and running code.

The first is gone, and only lip service is paid to the second.

I disagree that we have rough concensus; what we have in the IETF today is 
majority-rules voting.  That is not the same thing.

-- Mark --

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

Date: Wed, 07 Dec 2005 20:34:54 +0000
Subject: Re: Moving IDLE to Draft Standard
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: <[email-masked]>, Barry Leiba <[email-masked]>
Sender: [email-masked]

On Wed Dec  7 19:35:27 2005, Mark Crispin wrote:
> 
> Two issues:
> 
> 1) I don't see any justification for allowing a NO response.  This 
> is
>    something that needs to be cleaned up in the base specification 
> as
>    well.  I suggest that the possibility of a NO be removed.
> 
> 
Agreed.

> 2) There needs to be a discussion about why it may be ill-advised to
>    use IMAP with NAT or other facilities that drop connectivity and
>    depend upon client activity to restore connectivity.
> 
> 
I'm assuming you meant "IDLE" here, not "IMAP".

No, that discussion needs to be there, but it's a matter of breaking 
up the IDLE with a NOOP every five minutes or so, rather than every 
29.

As far as I'm aware, those firewalls and NATs also reset their timers 
whenever the client sends any TCP packet, hence even ACKing 
server-sent data counts.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Cc: Cyrus Daboo <[email-masked]>, [email-masked], Dave Cridland <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: OT: calendaring and component architecture, was Re: Going beyond what we have now
Date: Wed, 7 Dec 2005 12:32:32 -0800
To: Mark Crispin <[email-masked]>
Sender: [email-masked]

On Dec 7, 2005, at 11:05 AM, Mark Crispin wrote:

>
>> I guess the question is whether it would ever be possible to build a 
>> standardized system of component protocols (email, calendar, im, rss 
>> etc) that was sufficient to meet this need.
>
> Sadly, the IETF has failed miserably with calendaring.  In part, I 
> believe that this is because the efforts keep on deviating from 
> "component protocols" and instead attempt to build monoliths that 
> solve all problems.
>
> The more that I see of how the IETF is handling calendaring, the less 
> happy I become.
>
> This is one of the vast areas of work that I allude to above.
>
>
Hey, I hope you'll give the calendaring stuff another chance at some 
point.  I'm the chair of the new calendaring WG, CALSIFY, and although 
it's off to a slow start, there are probably decent reasons for that.  
We have seven implementations of CalDAV for basic calendar access and 
have done several interop tests so far even though it's an individual 
draft (I'm an author, which is why it's not part of the CALSIFY WG, a 
potential conflict of interest I'm not interested in taking on).

I agree with the component based approach overall as one the IETF is 
capable of doing.  Sometimes where we fall down is in the last steps of 
integrating between components so it's not easy, but at least it's 
feasible for us.

Lisa

Date: Wed, 07 Dec 2005 20:24:22 +0000
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Curtis King <[email-masked]>, <[email-masked]>, Cyrus Daboo <[email-masked]>
Sender: [email-masked]

On Wed Dec  7 18:02:46 2005, Mark Crispin wrote:
> On Wed, 7 Dec 2005, Cyrus Daboo wrote:
>> PS Just because ACAP was a failure (and at this point in terms of 
>> adoption that is definitively true), that doesn't mean that the 
>> concepts behind ACAP should be ignored. Anyone that actually got 
>> to use IMSP/ACAP knows well the benefits of server-side storage of 
>> preferences and address book information.
> 
> The concepts were great, and the benefits undeniable.
> 
> The problem was that there was nobody to say "no" when 
> functionality requests went off the deep end.  The "if ACAP doesn't 
> do such-and-such, then ACAP will die" argument won.  As a result 
> ACAP died.
> 
> 
Kind of, but not as simple. Tell me, Mark. Which *are* the 
functionality requests that should have been turned down? Since, as 
far as I'm aware, only three individuals have implemented anything 
approaching the full spec, all after the fact, so how were people 
meant to know? Where was the running code the IETF is so famous for? 
Had people tried implementing much earlier, I suspect several 
features in ACAP may well have been dropped. But nobody knew to say 
no.

(Case in point, you objected at one point to including sorting in 
ACAP at all. Ironically, this is a surviving part of ACAP, being 
comparators, which turned out to be very useful.)

I'm not blaming the individuals involved, here, but if an 
organization commits the time to work on a protocol, it has to follow 
through with the running code.

The IETF is good on the rough consensus, but it's getting a bit 
flakey on the running code. I'd hate to think how many other Proposed 
Standards haven't even been prototyped.

Incidentally, GConf, and other desktop configuration systems, are 
within spitting distance of a full ACAP specification (they tend to 
miss out the ACL support, for instance, and don't offer server-side 
searching at all, but still offer a much finer granularity than 
Pine's config-onna-mailbox does), so arguably, ACAP isn't dead at 
all, but has merely mutated into something utterly useless outside of 
a LAN.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 7 Dec 2005 11:35:27 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Barry Leiba <[email-masked]>
cc: IMAP extensions Mailing List <[email-masked]>
Subject: Re: Moving IDLE to Draft Standard
Sender: [email-masked]

Two issues:

1) I don't see any justification for allowing a NO response.  This is
    something that needs to be cleaned up in the base specification as
    well.  I suggest that the possibility of a NO be removed.

2) There needs to be a discussion about why it may be ill-advised to
    use IMAP with NAT or other facilities that drop connectivity and
    depend upon client activity to restore connectivity.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 7 Dec 2005 11:05:47 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

On Wed, 7 Dec 2005, Cyrus Daboo wrote:
> Well, I guess this goes to the heart of my point: is IMAP meant to compete 
> with (or at least provide a useful alternative to)  monolithic systems like 
> Exchange or not?

By itself, IMAP most certainly is *NOT* meant to compete with monolithic 
systems such as Exchange.

IMAP may be a component of a larger set of protocols which, together, 
either compete with Exchange or offer a useful alternative to Exchange.

The problem is, rather than build that larger set, we're seeing a tendency 
to try to build up IMAP into a do-everything monolith to compete with 
Exchange by itself.  Such an effort is doomed to failure.

This isn't IMAP's fault; the IETF lacks the ability to build do-everything 
monoliths.  The ability to build a do-everything monolith is the strength 
of entities (such as Microsoft) in which a single direction is determined 
by administrative policy.  IETF, by its nature, can not build a monolith 
since the debate required for such a task will not reach concensus before 
the sun novas.

Put another way: dictatorships are great at building monoliths, 
democracies are great in building clusters of widely-varying components 
and somehow making it all work.  Neither does particularly well at doing 
what the other is good at doing.

> Is it meant to fit in well in a true collaborative 
> environment where email is just one type of data in a system that needs to 
> link multiple data sources of different types together to present users with 
> all their key data in a sensible way?

The same answer as above.

I share the same goal that you state.  I just don't see IMAP as the sole 
solution for this goal.  I see vast areas of work that need to be done 
before we can reach that goal; and that work will require several new 
protocols with a scope at least as large as IMAP's scope.

> Right now IMAP does not meet that need, 
> and we are seeing people like Zimbra (and many others) building their own 
> custom solutions (Exchange alternatives) precisely because that is where 
> things are going - users want that level of integration.

Yes, indeed; but you'll never see the IETF build a Zimbra or Exchange. 
That is simply not its strength.

There is no particular reason why Zimbra or Exchange could not incorporate 
IMAP (or Kerberos, or any other IETF protocol).  In fact, they have (at 
least Exchange has).

Monoliths have leveraged IETF protocols in the past, and will continue to 
do so in the future.  Similarly, there will always be a protracted debate 
between IETF purists and monolith-builders about how the monolith 
implements the IETF protocol (typically focusing on unilateral extensions 
by the monolith-building), ultimately resulting in some form of 
compromise.

This is healthy.  What isn't healthy is the perception as IETF is being in 
competition with the monolith-builders.  GNU religion aside, we're not out 
to kill them, and they aren't out to kill us either.  We need each other.

> I guess the question is whether it would ever be possible to build a 
> standardized system of component protocols (email, calendar, im, rss etc) 
> that was sufficient to meet this need.

Sadly, the IETF has failed miserably with calendaring.  In part, I believe 
that this is because the efforts keep on deviating from "component 
protocols" and instead attempt to build monoliths that solve all problems.

The more that I see of how the IETF is handling calendaring, the less 
happy I become.

This is one of the vast areas of work that I allude to above.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 07 Dec 2005 13:45:00 -0500
From: Barry Leiba <[email-masked]>
To: IMAP extensions Mailing List <[email-masked]>
Subject: Moving IDLE to Draft Standard
Sender: [email-masked]

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

I'm getting ready to put IDLE on the path to Draft Standard (it'll have
to wait until the base spec gets there, but it can get on the queue).
I've just sent draft-leiba-imap-2177bis-00.txt to the I-D editor, so
watch for it soon; it's attached here for your reading pleasure.  It's
mostly the same as RFC 2177, with editorial changes generated, mostly,
from conversion of the source to use xml2rfc.  I've also updated the
references, and changed the ABNF to the current syntax.  The minor
substantive changes are

   Clarified that ANY response may come from the server during IDLE,
   and gave examples of the most common responses.

   Clarified that anything other than "DONE" is "BAD".

These are both the result of common questions from implementors.

I need to put together an interoperability report.  To that end, please
tell me (you can reply off-list, and I'll summarize responses on the
list) about client and server implementations of IDLE.  Tell me also,
if you have experience using one client implementation with a different
server implementation.

Barry

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

--==========E474E5AD02C1BDEFE85E==========
Content-Type: text/plain; charset=utf-8;
 name="draft-leiba-imap-2177bis-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-leiba-imap-2177bis-00.txt";
 size=14106

Network Working Group                                           B. =
Leiba
Internet-Draft                           IBM T.J. Watson Research =
Center
Obsoletes: 2177 (if approved)                           December 7, =
2005
Expires: June 10, 2006

                           IMAP4 IDLE command
                      draft-leiba-imap-2177bis-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 10, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The Internet Message Access Protocol requires a client to poll the
   server for changes to the selected mailbox (new mail, deletions).
   It's often more desirable to have the server transmit updates to the
   client in real time.  This allows a user to see new mail =
immediately.
   It also helps some real-time applications based on IMAP, which might
   otherwise need to poll extremely often (such as every few seconds).
   (While the spec actually does allow a server to push EXISTS =
responses
   asynchronously, a client can't expect this behaviour and must poll.)

Leiba                     Expires June 10, 2006                 [Page =
1]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

   This document specifies the syntax of an IDLE command, which will
   allow a client to tell the server that it's ready to accept such
   real-time updates.

Note

   This document is intended to be an update to the existing "IDLE"
   extension to the IMAP protocol, available from the RFC repository as
   ftp://ftp.isi.edu/in-notes/rfc2177.txt.

   This document and other IMAP extensions are being discussed on the
   imapext mailing list at mailto:[email-masked].  Subscription
   requests can be sent to
   mailto:[email-masked]?body=3Dsubscribe (send an email
   message with the word "subscribe" in the body).  More information on
   the mailing list along with a WWW archive of back messages is
   available at http://www.imc.org/ietf-imapext/.

Leiba                     Expires June 10, 2006                 [Page =
2]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

Table of Contents

   1. Conventions used in this document  . . . . . . . . . . . . . .   =
4

   2. Specification  . . . . . . . . . . . . . . . . . . . . . . . .   =
5

   3. Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .   =
7

   4. Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . .   =
8

   5. Changes since RFC 2177 . . . . . . . . . . . . . . . . . . . .   =
9

   6. Security Considerations  . . . . . . . . . . . . . . . . . . .  =
10

   7. Normative References . . . . . . . . . . . . . . . . . . . . .  =
10

      Author's Address . . . . . . . . . . . . . . . . . . . . . . .  =
10

      Intellectual Property and Copyright Statements . . . . . . . .  =
11

Leiba                     Expires June 10, 2006                 [Page =
3]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

1.  Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are =
to
   be interpreted as described in [Keywds].

Leiba                     Expires June 10, 2006                 [Page =
4]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

2.  Specification

   IDLE Command

   Arguments:  none

   Responses:  continuation data will be requested; the client sends =
the
               continuation data "DONE" to end the command

   Result:     OK  - IDLE completed after client sent "DONE"

               NO  - failure: the server will not allow the IDLE =
command
                     at this time

               BAD - command unknown or arguments invalid

   The IDLE command may be used with any IMAP4 server implementation
   that returns "IDLE" as one of the supported capabilities to the
   CAPABILITY command.  If the server does not advertise the IDLE
   capability, the client MUST NOT use the IDLE command and must poll
   for mailbox updates.  In particular, the client MUST continue to be
   able to accept unsolicited untagged responses to ANY command (not
   just to the IDLE command), as specified in the base IMAP
   specification.

   The IDLE command is sent from the client to the server when the
   client is ready to accept unsolicited messages from the server.  The
   server requests a response to the IDLE command using the =
continuation
   ("+") response.  The IDLE command remains active until the client
   responds to the continuation, and as long as an IDLE command is
   active, the server is now free to send ANY untagged responses.  IMAP
   servers will frequently send unsolicited responses such as these:

   o  EXISTS, to inform the client about a change in the number of
      messages in the currently-selected mailbox.

   o  EXPUNGE, to inform the client that a message has been expunged.

   o  FETCH, to inform the client about a change in the status of a
      message (usually to convey flag changes).

   o  RECENT, to inform the client that the number of messages with the
      \Recent flag has changed.  This response often accompanies =
EXISTS.

   But note again that what the server may send is not limited to that
   list -- ANY untagged response may appear.

   The IDLE command is terminated by the receipt of a "DONE"

Leiba                     Expires June 10, 2006                 [Page =
5]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

   continuation from the client; such response satisfies the server's
   continuation request.  At that point, the server MAY send any
   remaining queued untagged responses and then MUST immediately send
   the tagged response "OK" to the IDLE command and prepare to process
   other commands.  As in the base specification, the processing of any
   new command may cause the sending of unsolicited untagged responses,
   subject to the ambiguity limitations.  The client MUST NOT send a
   command while the server is waiting for the DONE, since the server
   will not be able to distinguish a command from a continuation.  If
   the server receives anything other than "DONE" from the client, this
   is a protocol violation and the server SHOULD terminate the IDLE
   command with a tagged response of "BAD".

   The server MAY consider a client inactive if it has an IDLE command
   running, and if such a server has an inactivity timeout it MAY log
   the client off implicitly at the end of its timeout period.  Because
   of that, clients using IDLE are advised to terminate the IDLE and =
re-
   issue it at least every 29 minutes to avoid being logged off.  This
   still allows a client to receive immediate mailbox updates even
   though it need only "poll" at half hour intervals.

Leiba                     Expires June 10, 2006                 [Page =
6]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

3.  Example

   The following is an example of an IMAP session using IDLE.

       C: A001 SELECT INBOX
       S: * FLAGS (Deleted Seen)
       S: * 3 EXISTS
       S: * 0 RECENT
       S: * OK [UIDVALIDITY 1]
       S: A001 OK SELECT completed
       C: A002 IDLE
       S: + idling
       ...time passes; another client sets a flag on message 2...
       S: * 2 FETCH (FLAGS (\Seen \Answered \Flagged))
       ...time passes; new mail arrives...
       S: * 4 EXISTS
       C: DONE
       S: A002 OK IDLE terminated
       ...another client expunges message 2 now...
       C: A003 FETCH 4 ALL
       S: * 4 FETCH (...)
       S: A003 OK FETCH completed
       C: A004 IDLE
       S: * 2 EXPUNGE
       S: * 3 EXISTS
       S: + idling
       ...time passes; another client expunges message 3...
       S: * 3 EXPUNGE
       S: * 2 EXISTS
       ...time passes; new mail arrives...
       S: * 3 EXISTS
       C: DONE
       S: A004 OK IDLE terminated
       C: A005 FETCH 3 ALL
       S: * 3 FETCH (...)
       S: A005 OK FETCH completed
       C: A006 IDLE

Leiba                     Expires June 10, 2006                 [Page =
7]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

4.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in [ABNF].  Non-terminals =
referenced
   but not defined below are as defined by [IMAP4].

   command_auth  =3D/  idle
                     ; Valid only in Authenticated or Selected state

   idle          =3D   "IDLE" CRLF "DONE"

Leiba                     Expires June 10, 2006                 [Page =
8]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

5.  Changes since RFC 2177

   1.  Updated references to current versions.

   2.  Updated ABNF to current syntax.

   3.  Added example of unsolicited FETCH response.

   4.  Clarified that ANY response may come from the server during =
IDLE,
       and gave examples of the most common responses.

   5.  Clarified that anything other than "DONE" is "BAD".

Leiba                     Expires June 10, 2006                 [Page =
9]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

6.  Security Considerations

   There are no known security issues with this extension.

7.  Normative References

   [ABNF]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 4234, October 2005.

   [IMAP4]   Crispin, M., "Internet Message Access Protocol - Version
             4rev1", RFC 3501, March 2003.

   [Keywds]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, March 1997.

Author's Address

   Barry Leiba
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532
   US

   Phone: +1 914 784 7941
   Email: [email-masked]

Leiba                     Expires June 10, 2006                [Page =
10]
=0C
Internet-Draft             IMAP4 IDLE command              December =
2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed =
to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  =
Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use =
of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository =
at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on =
an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =
REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Leiba                     Expires June 10, 2006                [Page =
11]
=0C

--==========E474E5AD02C1BDEFE85E==========--

Date: Wed, 7 Dec 2005 10:02:46 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Curtis King <[email-masked]>, Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

On Wed, 7 Dec 2005, Cyrus Daboo wrote:
> PS Just because ACAP was a failure (and at this point in terms of adoption 
> that is definitively true), that doesn't mean that the concepts behind ACAP 
> should be ignored. Anyone that actually got to use IMSP/ACAP knows well the 
> benefits of server-side storage of preferences and address book information.

The concepts were great, and the benefits undeniable.

The problem was that there was nobody to say "no" when functionality 
requests went off the deep end.  The "if ACAP doesn't do such-and-such, 
then ACAP will die" argument won.  As a result ACAP died.

There is a natural tendency to underestimate the cost of added 
functionality and overestimate its benefits.  Any proposal for additional 
functionality should be compelled to fight for its survival; and survive 
only if its critics can be moved into the "no objection" column.

An example in point is the delayed-sending feature in Lemonade (where I 
was on the "pro" side for added functionality).

It should be considered a danger sign when people stop trying to block new 
functionality.  That means that they've concluded that it is so far over 
the deep end that it'll die on its own, and it's best not to try to save 
it.

Consider this: Pine has had server side preferences and address book for a 
long time.  Yet we have never used IMSP or ACAP.  What Pine does is a 
kludge: these are implemented as IMAP mailboxes.  Nevertheless, it works 
well; so well, that we never looked back once we gave up on ACAP.

I'm afraid that when shared (across applications) addressbooks happen, it 
will be with LDAP (shudder!).  As gruesome as that sounds (and is!) it's 
worth studying the lesson to learn how this seemingly-unintuitive result 
came to be.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Wed, 7 Dec 2005 09:30:25 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Curtis King <[email-masked]>, Cyrus Daboo <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

On Wed, 7 Dec 2005, Arnt Gulbrandsen wrote:
> Is anyone actually implementing POP4? Or put more bluntly, how many people 
> are using mail software whose next version may support POP4?
> To my possibly unkind eyes, POP4 looks like another answer to the problems of 
> the nineties, but the author had no time back then, so the answer arrives ten 
> years late. Personally, I think any email access protocol has to accomodate 
> MIME email now - unlike the early nineties.

Arnt,

All of your observations are completely true.  There is no doubt in my 
mind that the "POP4" idea does not have a snowball's chance of hell of 
succeeding, and the person beyond it is (to put it kindly) in need of some 
additional experience.

Nevertheless, the fact that one threat turned out to be of no consequence 
does not mean that the next threat will similarly be of no consequence.

My point was that the "IMAP-killer" will be something simpler and with 
lower barriers to entry, not something more complex and with higher 
barriers to entry.  I pointed to the POP4 idea as an example of what we 
should take seriously, even if the particular example can not be taken 
seriously.

Put another way: IMAP will not die because it is too simple, but it may 
die because it has become too complex and bloated.

I am, in fact, quite swayed by the argument that all the mailbox 
operations should be ripped out of IMAP, so that IMAP can focus on message 
operations.  That has always been my belief.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Cc: [email-masked]
From: Curtis King <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Date: Wed, 7 Dec 2005 16:34:32 +0000
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

On 7-Dec-05, at 2:58 PM, Cyrus Daboo wrote:

>  don't know why people get the impression that we are trying to re- 
> implement ACAP (even with a ;-) at the end of the sentence).

Because it uses the same data model, is a sub-set of ACAP, and solves  
the same problem as ACAP. That's what I gather when I compare drafts  
with ACAP, and I'm not the only one.

>
> PS Just because ACAP was a failure (and at this point in terms of  
> adoption that is definitively true), that doesn't mean that the  
> concepts behind ACAP should be ignored. Anyone that actually got to  
> use IMSP/ACAP knows well the benefits of server-side storage of  
> preferences and address book information. Really this ought to be  
> getting more important as we move into an era where people will  
> have many types of device that need to get to the same set of data  
> in a consistent manner.

I was implying that I would rather implement ACAP than ANNOTATE and  
ANNOTATEMORE because of the all reasons you explained.

I can't remember the amount of times I have heard "it's better to  
have more protocols specific to the task than a general protocol".  
Yet, in practice it sure looks like we take the path of least  
resistance.

ck

Date: Wed, 07 Dec 2005 07:28:33 -0800 (Pacific Standard Time)
From: Anil SRIVASTAVA <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
To: [email-masked]
Reply-to: [email-masked]
Organization: Sun Microsystems [http://www.sun.com]
Accept-Language: English; en
Sender: [email-masked]

Cyrus makes a good point on the intergration of various components like 
Zimbra (and Exchange).  Zimbra is particulary strong in their ability to 
search for messages based on very sophisticated set of message and part 
properties.

Anil

On 2005-12-07/09:42 [-0500], [email-masked] [Cyrus Daboo] wrote:

> 
> Hi Mark,
> 
> --On December 6, 2005 4:58:21 PM -0800 Mark Crispin <[email-masked]>
> wrote:
> 
> > Besides an every-expanding girth at the waist, IMAP is in great danger of
> > becoming unimplementable with existing mail stores.  Rather than its
> > original purpose of exporting a generic mail store from a wide range of
> > existing stores, IMAP is rapidly becoming another Exchange (and doing a
> > miserable job at it).
> 
> Well, I guess this goes to the heart of my point: is IMAP meant to compete
> with (or at least provide a useful alternative to)  monolithic systems like
> Exchange or not? Is it meant to fit in well in a true collaborative
> environment where email is just one type of data in a system that needs to
> link multiple data sources of different types together to present users with
> all their key data in a sensible way? Right now IMAP does not meet that need,
> and we are seeing people like Zimbra (and many others) building their own
> custom solutions (Exchange alternatives) precisely because that is where
> things are going - users want that level of integration.
> 
> I guess the question is whether it would ever be possible to build a
> standardized system of component protocols (email, calendar, im, rss etc) that
> was sufficient to meet this need.
> 
> 

-- 
_______________
Anil SRIVASTAVA
[email-masked]

Date: Wed, 07 Dec 2005 10:07:30 -0500
From: Cyrus Daboo <[email-masked]>
To: Dave Cridland <[email-masked]>, Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Dave,

--On December 6, 2005 9:51:15 PM +0000 Dave Cridland <[email-masked]> 
wrote:

>> Remove all mailbox handling functions from IMAP, and instead manage
>> the mailbox hierarchy through WebDAV - IMAP itself would then just
>> be a 'message access' protocol.
>
> Having notifications about mailbox-level events would suddenly be
> impossible, which is a great shame. But who needs notifications when you
> can have a stateless protocol for altering server state?

Perhaps you've never heard of web-mail? ;-)

-- 
Cyrus Daboo

Date: Wed, 07 Dec 2005 10:06:26 -0500
From: Cyrus Daboo <[email-masked]>
To: Timo Sirainen <[email-masked]>, Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Cyrus Daboo <[email-masked]>, Dave Cridland <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Timo,

--On December 7, 2005 2:16:17 PM +0200 Timo Sirainen <[email-masked]> wrote:

> So I think the current SEARCH command is good if machine reads the
> results, but for human readable search results there could be something
> better.
>

Certainly users have been spoilt by web-search and really expect to see 
ranked results and be able to do some level of globbing.

-- 
Cyrus Daboo

Date: Wed, 07 Dec 2005 10:01:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Cyrus Daboo <[email-masked]>
cc: [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Alexey,

--On December 6, 2005 5:19:53 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> LISTEXT is not enough - you still need a simple GET functionality.
>> Note that LISTEXT is actually more of a query operation now - you can
>> ask for mailboxes that match a particular pattern and set of flags,
>> acl, metadata. That is much more complex than a simple 'give me this
>> data for these mailboxes', which is what GET would be. The complexity
>> in LISTEXT is that a server has to search all the various properties:
>> mailboxes flags (which ought to be easy), ACL and metadata - the later
>> would probably require indexing of the metadata information for
>> efficient queries and I think that is a lot more complexity for a
>> server. Giving serves the ability to separate out a simple 'get'
>> operations from a 'query' operation would be better.
>
> Actually, the server can distinguish between the two by checking for glob
> characters. I don't see a reason for a separate GET command.

OK, that's reasonable.

-- 
Cyrus Daboo

Date: Wed, 07 Dec 2005 09:58:20 -0500
From: Cyrus Daboo <[email-masked]>
To: Curtis King <[email-masked]>, Mark Crispin <[email-masked]>
cc: Dave Cridland <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Curtis,

--On December 7, 2005 10:34:21 AM +0000 Curtis King <[email-masked]> wrote:

>> Quite frankly, I see little of value in ANNOTATE, ANNOTATEMORE, or
>> LISTEXT.  Unlike the Lemonade facilities, there is no compelling
>> need for any of these.
>
> I agree we should be focusing our resources on Lemonade facilities.  Not
> re-implementing ACAP ;)

I don't know why people get the impression that we are trying to 
re-implement ACAP (even with a ;-) at the end of the sentence). ANNOTATE, 
LISTEXT etc are well focused on providing email specific extensions, 
whereas ACAP went far beyond that with arbitrary preferences, address 
books, accounts, contexts etc. The fact that ANNOTATE happens to make 
reference to ACAP by stating it follows the same data model does not mean 
it is re-implementing ACAP itself. If people have that impression then 
perhaps that reference should be removed.

In terms of the value of ANNOTATE etc - well lemonade was a major driving 
force behind ANNOTATE - they wanted per-body part flags. At the meeting in 
Vancouver I asked whether that was still the case, and it was - so lemonade 
does want ANNOTATE. What's more there have also been proposals in lemonade 
to use ANNOTATEMORE for various mailbox properties. There is at least one 
major server that currently ships with ANNOTATEMORE support and that 
actually uses it, albeit only for its own internal mailbox properties. So I 
believe there is justification for both of those.

PS Just because ACAP was a failure (and at this point in terms of adoption 
that is definitively true), that doesn't mean that the concepts behind ACAP 
should be ignored. Anyone that actually got to use IMSP/ACAP knows well the 
benefits of server-side storage of preferences and address book 
information. Really this ought to be getting more important as we move into 
an era where people will have many types of device that need to get to the 
same set of data in a consistent manner.

-- 
Cyrus Daboo

Date: Wed, 07 Dec 2005 09:42:07 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Mark,

--On December 6, 2005 4:58:21 PM -0800 Mark Crispin 
<[email-masked]> wrote:

> Besides an every-expanding girth at the waist, IMAP is in great danger of
> becoming unimplementable with existing mail stores.  Rather than its
> original purpose of exporting a generic mail store from a wide range of
> existing stores, IMAP is rapidly becoming another Exchange (and doing a
> miserable job at it).

Well, I guess this goes to the heart of my point: is IMAP meant to compete 
with (or at least provide a useful alternative to)  monolithic systems like 
Exchange or not? Is it meant to fit in well in a true collaborative 
environment where email is just one type of data in a system that needs to 
link multiple data sources of different types together to present users 
with all their key data in a sensible way? Right now IMAP does not meet 
that need, and we are seeing people like Zimbra (and many others) building 
their own custom solutions (Exchange alternatives) precisely because that 
is where things are going - users want that level of integration.

I guess the question is whether it would ever be possible to build a 
standardized system of component protocols (email, calendar, im, rss etc) 
that was sufficient to meet this need.

-- 
Cyrus Daboo

Date: Wed, 07 Dec 2005 09:27:49 -0500
From: Cyrus Daboo <[email-masked]>
To: Curtis King <[email-masked]>, Cyrus Daboo <[email-masked]>
cc: Dave Cridland <[email-masked]>, [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Curtis,

--On December 7, 2005 10:46:12 AM +0000 Curtis King <[email-masked]> wrote:

>> The other big reason for doing this in WebDAV is that most desktop
>> OS's have WebDAV file systems clients built-in.
>
> What about other platforms like phones and PDAs ?

Most phones/pdas have http stacks and its a simple matter to implement 
WebDAV on top of that. I already did that for a J2ME device so that it 
could do CalDAV - it was very easy to do - much more so than trying to do 
an IMAP client on the device.

-- 
Cyrus Daboo

Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
From: Timo Sirainen <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Cyrus Daboo <[email-masked]>, Dave Cridland <[email-masked]>
Date: Wed, 07 Dec 2005 14:16:17 +0200
Sender: [email-masked]

On Wed, 2005-12-07 at 12:12 +0100, Arnt Gulbrandsen wrote:
> Timo Sirainen writes:
> > On Tue, 2005-12-06 at 10:55 -0500, Cyrus Daboo wrote:
> >>  Really the place where IMAP needs to catch up is on message 
> >>  searching - specifically the ability to do store-wide searches (or 
> >>  at least a restricted subset of mailboxes) to provide the type of 
> >>  'virtual' mailbox functionality that a lot of desktop clients 
> >>  already support locally.
> ...
> > To get fast searching done in server side, we'd need a new command or 
> > a search attribute to allow servers to do less strict matching, so 
> > they could search mails using some generic indexing tools. Has anyone 
> > thought of doing this?
> 
> I don't see why we'd need this.
> 
> We've implemented server-side virtual folders (draft to come as soon as 
> I'm home, it's fairly simple) and didn't see any need for less strict 
> matching.

My reply didn't actually have anything to do with virtual folders, just
the searching part.

Do there exist any useful algorithms for IMAP servers that can allow
fast searching? I'd like to have "show results as you type the search
keyword" speed.

Cyrus's squat indexes seem to work somewhat well, except it can't handle
search keywords smaller than 4 characters. And since their
implementation doesn't suppport incremental index updates, most people
don't use them at all.

What else could even work? Maybe something could be done with suffix
trees. That's about all I've come across with (although I haven't tried
to look too hard into it..)

Having non-strict requirements for search would allow using lots of
different search algorithms, which would allow giving results faster and
possibly even better. Even if all search keywords are found from
multiple mails, the search engine could order those mails based on some
internal calculations on in which mails the word seems to be more
important..

So I think the current SEARCH command is good if machine reads the
results, but for human readable search results there could be something
better.

Date: Wed, 7 Dec 2005 12:33:16 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Cc: Curtis King <[email-masked]>, Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Curtis King writes:
> On 7-Dec-05, at 12:58 AM, Mark Crispin wrote:
>> Small and simple beats large and complex every time.  If anything  
>> proves to be the IMAP-killer, it will be something like POP4 (see  
>> www.pop4.org).
>
> POP is following the path of LDAP from a simple protocol to a more  
> complex one. POP4 is one more step closer to IMAP.

Is anyone actually implementing POP4? Or put more bluntly, how many 
people are using mail software whose next version may support POP4?

To my possibly unkind eyes, POP4 looks like another answer to the 
problems of the nineties, but the author had no time back then, so the 
answer arrives ten years late. Personally, I think any email access 
protocol has to accomodate MIME email now - unlike the early nineties.

Arnt

Date: Wed, 7 Dec 2005 12:12:48 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Cc: Cyrus Daboo <[email-masked]>, Timo Sirainen <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Timo Sirainen writes:
> On Tue, 2005-12-06 at 10:55 -0500, Cyrus Daboo wrote:
>>  Really the place where IMAP needs to catch up is on message 
>>  searching - specifically the ability to do store-wide searches (or 
>>  at least a restricted subset of mailboxes) to provide the type of 
>>  'virtual' mailbox functionality that a lot of desktop clients 
>>  already support locally.
...
> To get fast searching done in server side, we'd need a new command or 
> a search attribute to allow servers to do less strict matching, so 
> they could search mails using some generic indexing tools. Has anyone 
> thought of doing this?

I don't see why we'd need this.

We've implemented server-side virtual folders (draft to come as soon as 
I'm home, it's fairly simple) and didn't see any need for less strict 
matching.

Arnt

Cc: Dave Cridland <[email-masked]>, [email-masked]
From: Curtis King <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Date: Wed, 7 Dec 2005 10:46:12 +0000
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

On 6-Dec-05, at 3:55 PM, Cyrus Daboo wrote:

> The other big reason for doing this in WebDAV is that most desktop  
> OS's have WebDAV file systems clients built-in.

What about other platforms like phones and PDAs ?

>
> So I guess the bug question I have to ask at the end of all this,  
> is what do people really think about the future of IMAP as it  
> stands right now?

About the same as other protocols for now it does the job good enough  
and parts I don't like aren't enough of a reason to implement  
something else.

ck

Cc: Dave Cridland <[email-masked]>, Cyrus Daboo <[email-masked]>, [email-masked]
From: Curtis King <[email-masked]>
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Date: Wed, 7 Dec 2005 10:34:21 +0000
To: Mark Crispin <[email-masked]>
Sender: [email-masked]

On 7-Dec-05, at 12:58 AM, Mark Crispin wrote:

>
> Small and simple beats large and complex every time.  If anything  
> proves to be the IMAP-killer, it will be something like POP4 (see  
> www.pop4.org).

POP is following the path of LDAP from a simple protocol to a more  
complex one. POP4 is one more step closer to IMAP.

>
> Quite frankly, I see little of value in ANNOTATE, ANNOTATEMORE, or  
> LISTEXT.  Unlike the Lemonade facilities, there is no compelling  
> need for any of these.

I agree we should be focusing our resources on Lemonade facilities.  
Not re-implementing ACAP ;)

ck

Date: Tue, 6 Dec 2005 16:58:21 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 6 Dec 2005, Dave Cridland wrote:
> There are more IMAP clients and servers, though.

This is significant.  Until you can answer "why aren't there more ACAP 
clients and servers", you won't be able to answer "why hasn't IMAP kept up 
with ACAP."

My take is that:
  . ACAP is so overengineered that most people look at it, say "forget it",
     and that's that.
  . IMAP has teetered on, but has managed to avoid stepping off, the brink
     of ACAP's deep end.
  . it's already possible to do what ACAP does with existing tools; less
     elegantly, but doable and not all that costly.

Small and simple beats large and complex every time.  If anything proves 
to be the IMAP-killer, it will be something like POP4 (see www.pop4.org).

> The IETF used to use the right tool for the job, and custom build a bespoke 
> protocol to perform a specific task, extending it as the demand for that task 
> changed, and sometimes radically changing the whole thing. When email 
> transfer over FTP got too complex, SMTP was developed - all well before my 
> time. The protocol had to fit the model, in other words. If the protocol 
> didn't fit the model, then the protocol must die. If protocol could be made 
> to fit the model by extending, that it was extended.

I disagree with this categorization.  Back when the IETF used to do things 
well, "interoperability for everyone" was the name of the game.  This, at 
times, sometimes meant that the answer was "no"; because doing what was 
asked would cut someone out of the game, or because the request was 
something that, while nice-seeming on the surface, had a snowball's chance 
of ever being generally implemented.

Today, all we need is for someone to say "blurdybloop protocol must 
support sarasoop or blurdybloop will die" and the entire working group for 
blurdybloop collapses in a withering heap.

Besides an every-expanding girth at the waist, IMAP is in great danger of 
becoming unimplementable with existing mail stores.  Rather than its 
original purpose of exporting a generic mail store from a wide range of 
existing stores, IMAP is rapidly becoming another Exchange (and doing a 
miserable job at it).

Quite frankly, I see little of value in ANNOTATE, ANNOTATEMORE, or 
LISTEXT.  Unlike the Lemonade facilities, there is no compelling need for 
any of these.  Client programmer ease does not constitute "compelling 
need."

-- Mark --

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

Date: Tue, 06 Dec 2005 21:51:15 +0000
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
From: Dave Cridland <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

None of this was intended as a flame in any way, and I should point 
out that I do - really - have the highest respect for the folks in 
this working group, and indeed I've very high respect for anyone who 
takes the time to contribute to the IETF as a whole.

All that said, Cyrus's message was a strong, and radical opinion, and 
I'm assuming he would not have written it seeking platitudes, but the 
strong opinions of others. Please recall that, as an Englishman, I 
have a fully paid up license to omit little smiley faces when I err 
on the side of sarcasm.

Summary: I sympathize with the sentiments, I agree that IMAP's school 
report is "Shows great promise, but could try harder". But you 
shouldn't be doing all that WebDAV, it's strong stuff, highly 
addictive, and I suspect it might be hallucinogenic.

On Tue Dec  6 15:55:13 2005, Cyrus Daboo wrote:
> Proposal: all properties of a mailbox (mailbox flags, status info, 
> acl, metadata/annotations) should be treated the same (note this is 
> pretty much how WebDAV works - so there is an existing example of 
> this type of approach). There would then be three commands (I'm 
> going to use some WebDAV names here just to emphasize the 
> similarity):
> 
> PROPFIND - used to get properties of mailboxes
> PROPPATCH - used to change properties of mailboxes
> PROPQUERY - used to find mailboxes with matching properties 
> (actually there is no direct WebDAV equivalent for this, though the 
> REPORT method is often used to define specific types of property 
> queries)
> 
> 
This is what I've proposed, essentially, with the minor difference 
that PROPQUERY and PROPFIND are identical commands with different 
usages (as Alexey pointed out, LIST with no wildcards can easily be 
fast-tracked).

The big difference is that I'm content to leave them as distinct 
categories of metadata. It happens that this will tend to fit ACL 
boundaries, but really, it's a backward compatibility thing. It also 
actually makes things easier for servers, I think, and doesn't make a 
huge amount of difference to clients.

But yes, STATUS, all that stuff, ends up in LIST, wrapped up in a 
delta/notification system to make things oodles of times more 
efficient, both on and off the wire. I've written one up, I'm just 
going through ABNF and nits and I'll publish it.

> Maybe I've been in the WebDAV world too much of late, but here is 
> another proposal that goes even further:
> 
> Remove all mailbox handling functions from IMAP, and instead manage 
> the mailbox hierarchy through WebDAV - IMAP itself would then just 
> be a 'message access' protocol.

Having notifications about mailbox-level events would suddenly be 
impossible, which is a great shame. But who needs notifications when 
you can have a stateless protocol for altering server state?

> The other big reason for doing this in WebDAV is that most desktop 
> OS's have WebDAV file systems clients built-in. That means a user 
> could manage their mailbox hierarchy directly from the desktop in a 
> familiar manner (though there are some limitations and interop 
> issue with those, but that can easily be fixed).

I don't think unfamiliarity is a problem with MUA interfaces, for 
common actions like these. I could be wrong, but I don't know anyone 
who has a problem knowing how to create an email folder, whether 
we're talking about my parents, or my clients.

>  There is also plenty of existing code for WebDAV clients/servers 
> that could easily be reused for this.
> 
> 
There are more IMAP clients and servers, though.

> Of course there is a slippery path here - its easy to ask why 
> message handling should not also be done in WebDAV, if you do 
> mailboxes. Well maybe that could be done as an alternative 
> mailstore access protocol, but contending with the stateless nature 
> of WebDAV would require careful thought. As we have found with 
> CalDAV (calendaring done through WebDAV) we really need extensions 
> that help with things like notifications and efficient data 
> management for synchronization etc - but that is all doable.
> 
> 
Yes. Hmmm. At the risk of sounding like I'm ranting (partly because I 
am):

Well, my personal favourite response to this kind of idea has always 
been that two key benefits would be that we could recoup 8 bits of 
the TCP header, and firewall retailers would be able to sell us 
pointlessly overpowerful content filters instead. I'm only half 
joking. And that's a generous half.

I've never understood the fascination with trying to make WebDAV the 
sole method of data transfer on the internet, nor why people believe 
that transfer and notifications have to be distinct protocols, rather 
than common features of the same carefully tailored protocol.

CalDAV seems to be gathering momentum, which I think is a terrible 
shame, and I know I'll be shouted down for saying it, and don't take 
this personally, but I think that while it's a step forward for 
interoperable calendaring, in reality, I think it's more of a toddle. 
I can say, "Ah, sweet, it took a step", but I can't say, "Wow, I want 
to use that".

The IETF used to use the right tool for the job, and custom build a 
bespoke protocol to perform a specific task, extending it as the 
demand for that task changed, and sometimes radically changing the 
whole thing. When email transfer over FTP got too complex, SMTP was 
developed - all well before my time. The protocol had to fit the 
model, in other words. If the protocol didn't fit the model, then the 
protocol must die. If protocol could be made to fit the model by 
extending, that it was extended.

Now, it seems we have to bend the task to fit the model designed 
around the protocol. That doesn't feel like good engineering to me. 
It doesn't even feel like a good kludge. The Web works, of course, 
and it works really well for the thing it was originally designed to 
do - publish documents. It just about copes, thanks to rather a lot 
of retrofitting and the luxury of a fast turnover of clients, with 
the dynamic nature of many resources. Perhaps I was, in fact, the 
only one shaking my head in sadness at the sight of people blaming a 
non-functional site on "your browser is too old". Perhaps I'm being a 
stick-in-the-mud for saying that User-Agent interpretation is always, 
always, always a bad thing. But, overall, the turnover of clients has 
mostly kept things working for publishing documents.

But we're not interested in publishing email, we're interested in 
reading it, flagging it, tagging it, sorting it - and being kept 
informed about what others are doing, as well. I'd say the same thing 
with calendars, too, and the shame is that CalDAV will still tick all 
the right boxes with all the right people, and we'll all be using 
CalDAV soon. Still, at least it's interoperable. (Well, if people can 
agree on what iCal really says, anyway).

But there already is a protocol you could have extended, which 
already has notifications, and efficient synchronization, and even 
funky arbitrary metadata. Aim higher.

> Really the place where IMAP needs to catch up is on message 
> searching - specifically the ability to do store-wide searches (or 
> at least a restricted subset of mailboxes) to provide the type of 
> 'virtual' mailbox functionality that a lot of desktop clients 
> already support locally. With the introduction of better OS file 
> system search tools where file content is being indexed and 
> searches happen quickly, user expectations are that the same 
> capabilities should work with their email. Well it does right now 
> if the client caches all the email locally - but that really 
> negates many of the advantages of IMAP in terms of minimizing how 
> much data you do need to keep locally.
> 
> 
Yes, agreed.

Really, IMAP should be up to the capabilities of ACAP by now. IMAP 
has had 8 years to catch up, it should have had server-side arbitrary 
sorting, enumeration, virtual-scrolling, and notifications based on 
that same model from ACAP at least 5 years ago. Add in multi-mailbox 
searching, and you've got some very nifty features.

We should be able to do all this. I can with my addressbook, why 
can't I with my messages? Equally, of course, why can't you with your 
addressbook?

Aside: And here, of course, I'm talking to Cyrus, one of the few 
people who *almost* can. More ironically yet, I'm not using ACAP in 
my client right now. I don't know how you people cope. It's awful. I 
had to reconfigure *everything*. Manually, I mean. It'll take me 
forever to get things back the way they were. Well, until I give up 
on this quaint local-only configuration, at least. It'll never catch 
on. It's a dead idea.

> So I guess the bug question I have to ask at the end of all this, 
> is what do people really think about the future of IMAP as it 
> stands right now?

I think it'll do very well, if we can only shake off this idea that 
we must strive for mediocrity. I think the fundamental concepts of 
IMAP are excellent, and it's a stable foundation we could build a 
really excellent, modern, mail system on. I believe enough people 
actually want to do this that it can happen.

Then again, I'm under the foolish delusion that if you write an ACAP 
server, people will start to take advantage of it, so really, maybe I 
ought to just conentrate on writing a new mail protocol with lots of 
X's in the acronym, and ending in DAV. MaxDAV, anyone? We'll figure 
out what it stands for later. Don't worry about the details, just 
remember, it'll be the Next Big Thing. It'll be ten times worse than 
IMAP is *now*, but that's nothing to worry about. We'll solve the 
efficiency problem later - it's all doable.

Dave.
-- 

Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
From: Timo Sirainen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: Dave Cridland <[email-masked]>, [email-masked]
Date: Tue, 06 Dec 2005 21:07:27 +0200
Sender: [email-masked]

--=-BVSTjKe7vHJEYR6o5HU6
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-12-06 at 10:55 -0500, Cyrus Daboo wrote:
> Really the place where IMAP needs to catch up is on message searching -=20
> specifically the ability to do store-wide searches (or at least a=20
> restricted subset of mailboxes) to provide the type of 'virtual' mailbox=20
> functionality that a lot of desktop clients already support locally. With=
=20
> the introduction of better OS file system search tools where file content=
=20
> is being indexed and searches happen quickly, user expectations are that=20
> the same capabilities should work with their email. Well it does right no=
w=20
> if the client caches all the email locally - but that really negates many=
=20
> of the advantages of IMAP in terms of minimizing how much data you do nee=
d=20
> to keep locally.

To get fast searching done in server side, we'd need a new command or a
search attribute to allow servers to do less strict matching, so they
could search mails using some generic indexing tools. Has anyone thought
of doing this?

--=-BVSTjKe7vHJEYR6o5HU6
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-BVSTjKe7vHJEYR6o5HU6--

Date: Tue, 06 Dec 2005 17:19:53 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: [email-masked]
Subject: Re: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Cyrus Daboo wrote:

>> Reading metadata would be done by LIST-EXTENDED, both for ACL2 and for
>> METADATA. I believe the extension syntax now defined for LIST-EXTENDED
>> supports this complexity of syntax.
>
> LISTEXT is not enough - you still need a simple GET functionality. 
> Note that LISTEXT is actually more of a query operation now - you can 
> ask for mailboxes that match a particular pattern and set of flags, 
> acl, metadata. That is much more complex than a simple 'give me this 
> data for these mailboxes', which is what GET would be. The complexity 
> in LISTEXT is that a server has to search all the various properties: 
> mailboxes flags (which ought to be easy), ACL and metadata - the later 
> would probably require indexing of the metadata information for 
> efficient queries and I think that is a lot more complexity for a 
> server. Giving serves the ability to separate out a simple 'get' 
> operations from a 'query' operation would be better.

Actually, the server can distinguish between the two by checking for 
glob characters. I don't see a reason for a separate GET command.

Date: Tue, 06 Dec 2005 10:55:13 -0500
From: Cyrus Daboo <[email-masked]>
To: Dave Cridland <[email-masked]>, [email-masked]
Subject: Going beyond what we have now, was Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

Hi Dave,

--On December 4, 2005 12:33:10 AM +0000 Dave Cridland <[email-masked]> 
wrote:

> But, if we're going to change the protocol anyway, can we consider
> rewriting the protocol a little more?

I am going to disagree with your proposal because as it stands it does not 
go far enough IMHO. I would rather we leave things as they are or do this 
properly - which actually means replacing both LIST and STATUS as well. I 
think LISTEXT is only a half-hearted attempt at that. So my feeling is 
stick with what we have or go all the way - not part of the way. My 
justification for this follows.

> A01 SET "INBOX" METADATA ...
>
> For ACL2, this would look like:
>
> A02 SET "INBOX" ACL ...

First thing to note: as it is right now ACL2 uses STORE, SET and DELETE, in 
addition to LIST. There are valid reasons for requiring separate commands 
for those, however one could come up with some contorted syntax that would 
emulate all three in a single SET command, but this will require a major 
rewrite of ACL2 behaviour.

> Reading metadata would be done by LIST-EXTENDED, both for ACL2 and for
> METADATA. I believe the extension syntax now defined for LIST-EXTENDED
> supports this complexity of syntax.

LISTEXT is not enough - you still need a simple GET functionality. Note 
that LISTEXT is actually more of a query operation now - you can ask for 
mailboxes that match a particular pattern and set of flags, acl, metadata. 
That is much more complex than a simple 'give me this data for these 
mailboxes', which is what GET would be. The complexity in LISTEXT is that a 
server has to search all the various properties: mailboxes flags (which 
ought to be easy), ACL and metadata - the later would probably require 
indexing of the metadata information for efficient queries and I think that 
is a lot more complexity for a server. Giving serves the ability to 
separate out a simple 'get' operations from a 'query' operation would be 
better.

> This should reduce the number of commands in a session, and therefore the
> number of round-trips, by allowing clients to obtain all the information
> about a set of mailboxes in one command.

The fact is you are not really reducing the number of commands, all you are 
doing is disguising separate commands as one through a 'trick' of syntax. 
The first thing a server would do with SET METATDATA () ACL () is a branch 
to separate code to handle each type given that they will both have very 
different syntax/semantic requirements, and also because they may be 
optional components.

> Incidentally, this simply changes the syntax of ANNOTATEMORE/METADATA and
> potentially ACL2, not the semantics.

If you want to go all the way here is my (radical?) proposal. I am afraid 
some people won't like this but lets face it, IMAP needs to catch up with 
modern innovations in email that have broadened user expectations - fixing 
the mailbox handling is actually a small part of that - more radical 
changes are needed with message handling too.

Proposal: all properties of a mailbox (mailbox flags, status info, acl, 
metadata/annotations) should be treated the same (note this is pretty much 
how WebDAV works - so there is an existing example of this type of 
approach). There would then be three commands (I'm going to use some WebDAV 
names here just to emphasize the similarity):

PROPFIND - used to get properties of mailboxes
PROPPATCH - used to change properties of mailboxes
PROPQUERY - used to find mailboxes with matching properties (actually there 
is no direct WebDAV equivalent for this, though the REPORT method is often 
used to define specific types of property queries)

Note that PROPQUERY would effectively replace LIST and STATUS. ACL and 
METADATA/ANNOTATEMORE would be subsumed into the properties with 
appropriate syntax.

I believe this gives what you want Dave - a single set of commands for 
managing mailbox properties. Of course we still need CREATE, DELETE and 
RENAME for managing the mailboxes themselves.

Maybe I've been in the WebDAV world too much of late, but here is another 
proposal that goes even further:

Remove all mailbox handling functions from IMAP, and instead manage the 
mailbox hierarchy through WebDAV - IMAP itself would then just be a 
'message access' protocol. Why would this make sense? Well the first thing 
to note is that for the most part mailbox operations are stateless (as 
opposed to message operations which do require state to be carried over 
during a 'session'). Thus a stateless protocol like WebDAV could easily be 
used to manage mailboxes without any changes to the user experience or 
expectations.

The other big reason for doing this in WebDAV is that most desktop OS's 
have WebDAV file systems clients built-in. That means a user could manage 
their mailbox hierarchy directly from the desktop in a familiar manner 
(though there are some limitations and interop issue with those, but that 
can easily be fixed). There is also plenty of existing code for WebDAV 
clients/servers that could easily be reused for this.

There are of course a number of disadvantages to this - I'm sure these can 
be enumerated if we want to go further into this discussion.

Of course there is a slippery path here - its easy to ask why message 
handling should not also be done in WebDAV, if you do mailboxes. Well maybe 
that could be done as an alternative mailstore access protocol, but 
contending with the stateless nature of WebDAV would require careful 
thought. As we have found with CalDAV (calendaring done through WebDAV) we 
really need extensions that help with things like notifications and 
efficient data management for synchronization etc - but that is all doable.

Really the place where IMAP needs to catch up is on message searching - 
specifically the ability to do store-wide searches (or at least a 
restricted subset of mailboxes) to provide the type of 'virtual' mailbox 
functionality that a lot of desktop clients already support locally. With 
the introduction of better OS file system search tools where file content 
is being indexed and searches happen quickly, user expectations are that 
the same capabilities should work with their email. Well it does right now 
if the client caches all the email locally - but that really negates many 
of the advantages of IMAP in terms of minimizing how much data you do need 
to keep locally.

Its been my feeling for a while, that despite the widespread deployment of 
IMAP (something which I know a number of people really question), its 
future looks a little murky. I do think that we have gotten too embroiled 
in the attempts to fix things with extensions, and not really looked at the 
big picture of where this needs to go in the long term to really match user 
expectations.  There are many examples of companies that are innovating in 
this space, and its interesting to note that a number of them have simply 
ignored IMAP as a possible solution, even though they have adopted pretty 
much the same 'philosophy' of IMAP in terms of server-based email storage.

So I guess the bug question I have to ask at the end of all this, is what 
do people really think about the future of IMAP as it stands right now?

-- 
Cyrus Daboo

Date: Tue, 6 Dec 2005 18:19:13 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

At 2005-12-04 00:33:10 +0000, [email-masked] wrote:
>
> I'd like to propose that instead of adding additional commands
> for METADATA and, for instance, ACL2, that wherever possible we
> add return options to LIST-EXTENDED instead, and define a single
> SET command.

I like that idea very much.

-- ams

Date: Tue, 6 Dec 2005 18:17:50 +0530
From: Abhijit Menon-Sen <[email-masked]>
To: [email-masked]
Subject: Re: ANNOTATEMORE update
Sender: [email-masked]

At 2005-12-01 19:09:54 -0500, [email-masked] wrote:
>
> > Thus, we would have message *annotations*, and mailbox and server
> > *metadata*.
> 
> I would be fine with a change like this to - what do others think?

Sounds good to me.

-- ams

Date: Tue, 06 Dec 2005 12:07:28 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: [email-masked]
Subject: Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

[Please excuse me for sending empty reply to the mailing list, was 
caused by mail client crash...]

Dave Cridland wrote:

> Firstly, I'm fine with METADATA as a capability name. I've seen plenty 
> of confusion about ANNOTATEMORE as a name anyway.
>
> But, if we're going to change the protocol anyway, can we consider 
> rewriting the protocol a little more?

I would like to second this opinion.

> It occurs to me that other mailbox attributes fit the model of needing 
> to be able to set them, and retreive them. I'd like to propose that 
> instead of adding additional commands for METADATA and, for instance, 
> ACL2, that wherever possible we add return options to LIST-EXTENDED 
> instead, and define a single SET command.
>
> For METADATA, this would look something like:
>
> A01 SET "INBOX" METADATA ...
>
> For ACL2, this would look like:
>
> A02 SET "INBOX" ACL ...
>
> (Note that SET is probably not descriptive enough. Perhaps CHANGE 
> might be a better name.)
>
> Reading metadata would be done by LIST-EXTENDED, both for ACL2 and for 
> METADATA. I believe the extension syntax now defined for LIST-EXTENDED 
> supports this complexity of syntax.
>
> This should reduce the number of commands in a session, and therefore 
> the number of round-trips, by allowing clients to obtain all the 
> information about a set of mailboxes in one command.
>
> Incidentally, this simply changes the syntax of ANNOTATEMORE/METADATA 
> and potentially ACL2, not the semantics.

From: [email-masked]
Date: Tue, 6 Dec 2005 10:39:17 +0000
Sender: [email-masked]

Date: Sat, 3 Dec 2005 19:05:53 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: [email-masked]
Subject: Re: ANNOTATEMORE/METADATA
Sender: [email-masked]

For what it's worth, I agree with these comments/suggestions.

On Sun, 4 Dec 2005, Dave Cridland wrote:
> Firstly, I'm fine with METADATA as a capability name. I've seen plenty of 
> confusion about ANNOTATEMORE as a name anyway.
>
> But, if we're going to change the protocol anyway, can we consider rewriting 
> the protocol a little more?
>
> It occurs to me that other mailbox attributes fit the model of needing to be 
> able to set them, and retreive them. I'd like to propose that instead of 
> adding additional commands for METADATA and, for instance, ACL2, that 
> wherever possible we add return options to LIST-EXTENDED instead, and define 
> a single SET command.
>
> For METADATA, this would look something like:
>
> A01 SET "INBOX" METADATA ...
>
> For ACL2, this would look like:
>
> A02 SET "INBOX" ACL ...
>
> (Note that SET is probably not descriptive enough. Perhaps CHANGE might be a 
> better name.)
>
> Reading metadata would be done by LIST-EXTENDED, both for ACL2 and for 
> METADATA. I believe the extension syntax now defined for LIST-EXTENDED 
> supports this complexity of syntax.
>
> This should reduce the number of commands in a session, and therefore the 
> number of round-trips, by allowing clients to obtain all the information 
> about a set of mailboxes in one command.
>
> Incidentally, this simply changes the syntax of ANNOTATEMORE/METADATA and 
> potentially ACL2, not the semantics.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Sun, 04 Dec 2005 00:33:10 +0000
Subject: ANNOTATEMORE/METADATA
From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Firstly, I'm fine with METADATA as a capability name. I've seen 
plenty of confusion about ANNOTATEMORE as a name anyway.

But, if we're going to change the protocol anyway, can we consider 
rewriting the protocol a little more?

It occurs to me that other mailbox attributes fit the model of 
needing to be able to set them, and retreive them. I'd like to 
propose that instead of adding additional commands for METADATA and, 
for instance, ACL2, that wherever possible we add return options to 
LIST-EXTENDED instead, and define a single SET command.

For METADATA, this would look something like:

A01 SET "INBOX" METADATA ...

For ACL2, this would look like:

A02 SET "INBOX" ACL ...

(Note that SET is probably not descriptive enough. Perhaps CHANGE 
might be a better name.)

Reading metadata would be done by LIST-EXTENDED, both for ACL2 and 
for METADATA. I believe the extension syntax now defined for 
LIST-EXTENDED supports this complexity of syntax.

This should reduce the number of commands in a session, and therefore 
the number of round-trips, by allowing clients to obtain all the 
information about a set of mailboxes in one command.

Incidentally, this simply changes the syntax of ANNOTATEMORE/METADATA 
and potentially ACL2, not the semantics.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Fri, 02 Dec 2005 11:22:54 -0500
From: Barry Leiba <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATEMORE update
Sender: [email-masked]

>> Thus, we would have message *annotations*, and mailbox and server
>> *metadata*.
> 
> I would be fine with a change like this to - what do others think?

+1

Barry

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

Date: Thu, 1 Dec 2005 18:18:35 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: "Vaudreuil, Greg M (Greg)" <[email-masked]>
cc: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: RE: ANNOTATEMORE update
Sender: [email-masked]

On Thu, 1 Dec 2005, Vaudreuil, Greg M (Greg) wrote:
> I find METADATA to be very generic... It does not imply data about the mailbox to me any more than annotations did. How about MBXDATA?

The problem with MBXDATA is that it doesn't cover what is currently called 
"server annotations"

I don't see a problem with an extension called METADATA (and corresponding 
commands) that deals with "mailbox metadata" and "server metadata".

I agree that small-"metadata" should never be used except with "mailbox" 
or "server" preceeding it.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: Ken Murchison <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: RE: ANNOTATEMORE update
Date: Thu, 1 Dec 2005 19:56:32 -0600 
Sender: [email-masked]

I find METADATA to be very generic... It does not imply data about the mailbox to me any more than annotations did. How about MBXDATA? 

Greg V.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ken Murchison
Sent: Thursday, December 01, 2005 7:15 PM
To: IMAP Extensions WG
Subject: Re: ANNOTATEMORE update

Mark Crispin wrote:
> 
> Perhaps ANNOTATEMORE can become METADATA, with corresponding 
> GETMETADATA, and SETMETADATA commands and METADATA response.  If this is 
> done, then "meta data" should be purged from the ANNOTATE document (it's 
> only used twice).
> 
> Thus, we would have message *annotations*, and mailbox and server 
> *metadata*.

FWIW, I like Mark's suggestion here.  METADATA seems like a more
accurate term for "additional mailbox info".  When I think of a mailbox
ACL, I think "metadata", not "annotation".

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University

Date: Thu, 01 Dec 2005 19:14:59 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATEMORE update
Sender: [email-masked]

Mark Crispin wrote:
> 
> Perhaps ANNOTATEMORE can become METADATA, with corresponding 
> GETMETADATA, and SETMETADATA commands and METADATA response.  If this is 
> done, then "meta data" should be purged from the ANNOTATE document (it's 
> only used twice).
> 
> Thus, we would have message *annotations*, and mailbox and server 
> *metadata*.

FWIW, I like Mark's suggestion here.  METADATA seems like a more
accurate term for "additional mailbox info".  When I think of a mailbox
ACL, I think "metadata", not "annotation".

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University

Date: Thu, 01 Dec 2005 19:09:54 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATEMORE update
Sender: [email-masked]

Hi Mark,

--On November 29, 2005 4:10:27 PM -0800 Mark Crispin 
<[email-masked]> wrote:

> Perhaps ANNOTATEMORE can become METADATA, with corresponding GETMETADATA,
> and SETMETADATA commands and METADATA response.  If this is done, then
> "meta data" should be purged from the ANNOTATE document (it's only used
> twice).
>
> Thus, we would have message *annotations*, and mailbox and server
> *metadata*.

I would be fine with a change like this to - what do others think?

-- 
Cyrus Daboo

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-list-extensions-15.txt 
Date: Thu, 01 Dec 2005 18:50:01 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 LIST Command Extensions
	Author(s)	: B. Leiba, A. Melnikov
	Filename	: draft-ietf-imapext-list-extensions-15.txt
	Pages		: 39
	Date		: 2005-12-1
	
IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
   have added extensions, such as Mailbox Referrals, that have required
   specialized lists we have had to expand the number of list commands,
   since each extension must add its function to both LIST and LSUB, and
   these commands are not, as they are defined, extensible.  If we've
   needed the extensions to work together, we've had to add a set of
   commands to mix the different options, the set increasing in size
   with each new extension.  This document describes an extension to the
   base LIST command that will allow these additions to be done with
   mutually compatible options to the LIST command, avoiding the
   exponential increase in specialized list commands.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-list-extensions-15.txt

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

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

--OtherAccess--

--NextPart--