Subject: Re: ACL2: rights required for different IMAP command
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Date: Fri, 28 Jun 2002 05:05:01 -0600
List-Id: <ietf-imapext.imc.org>

I haven't heard any public comments on this topic! (See some comments below)

Alexey Melnikov wrote:

> As you will see in the new revision, I've added a new section that
> describes in details which rights should be checked to implement
> different IMAP commands, which rights are mandatory and which are
> optional.
> Here is what left unresolved:
>
>     SUBSCRIBE - "l" right is required only if the server checks for
> mailbox existence
>            when performing SUBSCRIBE.
>
> Allow if the user has "r" right?
>
>     GETACL - "a" right on the mailbox.
>
>      CDC IntraStore: "a".
>      CMU: "r", "a", admin or owner.
>      MD: "r" or "a" or owner.
>
> No consensus if "r" should be allowed. John would prefer not to use "r",
> but he is fine if somebody insists on using it. The main argument
> against allowing "r" for GETACL is that in this case GETACL can
> possibly disclose some identifiers existing on the mail system to an
> authenticated user with read access.
> On the other hand "r" is used for a mailbox metadata and seems
> appropriate.
>
>     LISTRIGHTS - Same as GETACL? or just "r"?
>
>     GETQUOTA - no rights required
> CMU server checks if the user belongs to administrators, I don't know
> why
>
>     SETQUOTA - "a" right

> Some implementations allows to set quota when the user has "r" right as
> well. Should we allow that?

As a result of my private exchange with Vladimir, I am going to remove the
requirement to use "a" for SETQUOTA, because it operates on a quota root,
that is not necessary a mailbox. Instead this will be "implementation
dependent".

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

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-thread-11.txt
Date: Tue, 25 Jun 2002 07:03:39 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-thread-11.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-thread-11.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-thread-11.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-sort-10.txt
Date: Tue, 25 Jun 2002 07:03:35 -0400
Sender: [email-masked]

--NextPart

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-10.txt
	Pages		: 10
	Date		: 24-Jun-02
	
This document describes an experimental server-based sorting
extension to the IMAP4rev1 protocol, as implemented by the University
of Washington's IMAP toolkit.  This extension provides substantial
performance improvements for IMAP clients which offer sorted views.
A server which supports this extension indicates this with a
capability name of 'SORT'.  Client implementations SHOULD accept any
capability name which begins with 'SORT' as indicating support for
the extension described in this document.  This provides for future
upwards-compatible extensions.
At the time of this document was written, the IMAP Extensions Working
Group (IETF-IMAPEXT) was considering upwards-compatible additions to
the SORT extension described in this document, tenatively called the
SORT2 extension.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-sort-10.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-sort-10.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-sort-10.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-thread-10.txt
Date: Mon, 24 Jun 2002 07:48:28 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-thread-10.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-thread-10.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-thread-10.txt

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

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

--OtherAccess--

--NextPart--

To: IMAP Interest Groups: ;
Subject: IMAP Channel Draft version 2 released
Organization: ACI Worldwide - Advanced Technology Group
Date: Tue, 18 Jun 2002 16:28:11 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

I've pushed version 02 of the Channel draft to the ID editor. Early
access can be had at:

        http://atg.aciworldwide.com/draft-nerenberg-imap-channel-02.txt

Diffs from version 01:

  Changed <channel-set> to use <section-spec> instead of <section-text>.
  This allows retrieval of headers and MIME structure.
  
  <channel-data> returns a <section-spec>, not <nz-number> (to match
  <channel> syntax).
  
  Add missing SP tokens to grammar.
  
  Grammar fix to allow foo: as a valid URI in a request.
  
  Add UID CHANNEL.
  
  Clarify response when client issues a command with an unsupported scheme.
  
  Add section on command sequencing.
  
  Note arbitrary ordering of untagged responses.
  
  Replace URI-reference with absoluteURI. The IMAP server can't maintain
  the state required to deal with relative URIs. This also solves an
  ambiguity between parsing "NIL" as <nil> or as a relative URI.

--lyndon

                            _
        12 + 144 + 20 + 3(\/4)                2
        ----------------------  +  5(11)  =  9  +  0
                  7
A dozen, a gross and a score,
Plus three times the square root of four,
        Divided by seven,
        Plus five times eleven,
Equals nine squared plus zero, no more!

Date: Fri, 14 Jun 2002 07:40:26 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lyndon Nerenberg <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

Lyndon Nerenberg wrote:

> > My experience with writing parsers in non-blocking or asynchronous IO model
> > (i.e. when read from the socket may return that literal was not completely
> > received by TCP stack) tells that it is a pain in the ass to write a parser for
> > any command that uses literals. Why? Because you have to save state if there is
> > not enough data.
>
> This argument doesn't hold. You can get a short read anywhere, not
> just inside a literal.

Well, I guess I should have explained our architecture in the first place.
In our IMAP server we have two levels of parsing. The low level parser always
guaranties that the server has a full text line till CRLF before it hands over the
line to the high level parser. This is based on one very good property of IMAP
protocol: any protocol line is terminated with CRLF, whether it is CRLF at the end of
the command, after "}" in literals or in the middle of a RFC822 message. Thus, in our
architecture low level parser always guaranties that we never get a short read while
parsing a quoted string. That is not true for literals. So, after this clarification,
my argument still holds. (I know of no other sane way of parsing IMAP with non
blocking IO that doesn't use something like our low level parser).

> And I would argue that literals are the
> *easiest* string form to deal with: you already know how much data to
> read therefore you don't need to keep any state on the data stream
> itself, just a counter that you decrement as you read in the bytes.

Not just this state. Counter is the least of the problems. I was talking about the
current state of the command parser.
For example, when parsing arguments of a SEARCH (or a FETCH) command, the parser can
be several levels down parsing nested SEARCH criteria when it encounters a literal.
Now there are couple choices how to deal with this:
 1). throw away already constructed search state and reparse SEARCH command as soon
as the literal is fully received
or
 2). save the current search state and switch to literal receiving mode.

Both cases will require saving some non-trivial state, but 1) , IMHO, is inefficient,
especially if there are several literals.

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

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

Date: Fri, 14 Jun 2002 04:53:01 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights    associated with READ-WRITE response code)
Sender: [email-masked]

Tim Showalter wrote:

> > How about a single ACL command with subcommands?
>
> Not a bad idea; better than SETACL2.

That is fine with me. What about the syntax after ACL <subcommand>? Are
people happy with my proposal.

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

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

Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights   associated with READ-WRITE response code)
From: Tim Showalter <[email-masked]>
To: [email-masked]
Date: 13 Jun 2002 14:15:39 -0600
Sender: [email-masked]

> How about a single ACL command with subcommands?

Not a bad idea; better than SETACL2.

Tim

Date: Thu, 13 Jun 2002 12:40:01 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights   associated with READ-WRITE response code)
To: Tim Showalter <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 13 Jun 2002 13:04:27 -0600, Tim Showalter wrote:
> I like the proposed identifier format; it's cleaner than what we had
> before.  If I were implementing an ACL server from scratch I would want
> to use something like that.

Great!

> But there's running ACL code out there that doesn't work that way.  In
> order for a sane upgrade path for Cyrus (and its progeny) the ACL2
> commands will have to be supported seperately; in order to make these
> work in some sane way, we'll need some seperate syntax.

In case it was unclear; I have no objection whatsoever to a different set of
commands for ACL2.

I always felt that instead of the current GETACL, LISTRIGHTS, and MYRIGHTS
commands, we should use an extended form of LIST.  But LIST extensions seems
to have fallen by the wayside, sigh.

How about a single ACL command with subcommands?

SETACL 		=> ACL STORE
DELETEACL	=> ACL DELETE
REPLACEACL	=> ACL SET
GETACL		=> ACL GET
LISTRIGHTS	=> ACL LIST
MYRIGHTS	=> ACL FETCH

ACL FETCH is slightly different than MYRIGHTS in that it takes an identifier
as an argument and returns the rights for that identifier (?? is this
desirable??).

Or perhaps there could be an ACL CHECK that, given an identifier and a set of
right, returns whether or not that identifier has those rights.  I suspect
that ACL CHECK may be more useful.

Date: Thu, 13 Jun 2002 11:21:24 -0700
From: Lawrence Greenfield <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Mark Crispin <[email-masked]>, Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

--On Thursday, June 13, 2002 5:20 AM -0600 Alexey Melnikov 
<[email-masked]> wrote:

> Lawrence Greenfield wrote:
>
>> Another possibility is for ACL to recommend that servers implementing
>> ACL just not return either READ-ONLY or READ-WRITE in response to a
>> SELECT.
>
> I think this breaks compliance with RFC 2060.

No, the RFC merely says "SHOULD prefix the text" with "[READ-WRITE]".

So it's clearly legal to not return either READ-ONLY or READ-WRITE.

So my proposal is that EXAMINE must return "[READ-ONLY]".
SELECT must not return "[READ-WRITE]"; may return "[READ-ONLY]" if all 
rights are off.

Larry

Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights   associated with READ-WRITE response code)
From: Tim Showalter <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Date: 13 Jun 2002 13:04:27 -0600
Sender: [email-masked]

On Thu, 2002-06-13 at 04:54, Alexey Melnikov wrote:
> 
> Lawrence Greenfield wrote:
> 
> > If you feel the need to deprecate the old ACL commands, can we just
> > name them something else?
> 
> Does it really matter? Syntax is almost identical and the difference can
> be codified with the couple if statements.

We *will* confuse people, almost immediately.  Certainly no one here, as
we read the specs; but there are a lot of people that don't, and there
are a lot of people that like to leave mandatory () off of lists.

I like the proposed identifier format; it's cleaner than what we had
before.  If I were implementing an ACL server from scratch I would want
to use something like that.

But there's running ACL code out there that doesn't work that way.  In
order for a sane upgrade path for Cyrus (and its progeny) the ACL2
commands will have to be supported seperately; in order to make these
work in some sane way, we'll need some seperate syntax.

> >  I don't see the need to be so cute about
> > our upgrades when we have an infinite number of bits that will make it
> > blatantly obvious what versions we're using.

I agree with this.

Tim

Organization: ACI Worldwide - Advanced Technology Group
To: Alexey Melnikov <[email-masked]>
cc: Rob Siemborski <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights" 
Date: Thu, 13 Jun 2002 11:37:39 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> My experience with writing parsers in non-blocking or asynchronous IO model
> (i.e. when read from the socket may return that literal was not completely
> received by TCP stack) tells that it is a pain in the ass to write a parser for
> any command that uses literals. Why? Because you have to save state if there is
> not enough data.

This argument doesn't hold. You can get a short read anywhere, not
just inside a literal. And I would argue that literals are the
*easiest* string form to deal with: you already know how much data to
read therefore you don't need to keep any state on the data stream
itself, just a counter that you decrement as you read in the bytes.

--lyndon

I think 3B2 code deserves its own place in hell.  Poring over the ESS#5 code,
someone found that there were lots of strcmp(p, "f(") == 0 checks (I may have
gotten the exact string wrong but it's close).  It took us a while to figure
out why.  Apparently, location 0 on the 3b had the 3 bytes 'f' '(' '\0',
someone noticed that when programs blew up they were pointing to "f(", and
the worlds most amazing kludge for detecting nil pointers was born.
                        -- Dave Presotto

Date: Thu, 13 Jun 2002 10:43:30 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code)
Sender: [email-masked]

Hi,

--On  Mark Crispin <[email-masked]> wrote:

| I could understand you making a distinction between web mail programs that
| only do local mail, and web mail programs that only do IMAP.  But we have
| at least one example (WebPine) of a program that (at least in theory) can
| do both, and I doubt that WebPine is the only (or even the first) such
| program.

There are a number of webmail solutions that use PHP scripting on the 
webserver. In most cases they will use the IMAP implementation in PHP which 
is c-client based, so all of those fall into the same category - they can 
do both native mailstore access and IMAP mailstore access if desired.

-- 
Cyrus Daboo

Date: Thu, 13 Jun 2002 08:10:05 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: Lawrence Greenfield <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of   rightsassociated with READ-WRITE response code)
Sender: [email-masked]

Mark Crispin wrote:

> On Thu, 13 Jun 2002 04:59:25 -0600, Alexey Melnikov wrote:
> > Also as Vladimir pointed out in his private email to me, ACL2 implementation
> > can treat <identifier> as user=<identifier>, if the implementation prohibits
> > the creation of users with special names or names with "=".
>
> What does this mean?
>
> Would an identifier such as xxx be canonicalized to user=xxx form?

Yes, unless it is one of the "specials".

> If not, how is a client to know what xxx means?

If an identifier is not allowed to have "=", then each identifier without "=" in
it is automatically treated equal to user=xxx form.
If an identifier contains "=", it must be either "user=yyy" or "group=zzz",
otherwise it is illegal.

> Also, wouldn't this conflict with
> future assignment of special identifiers?

Of course it will. But the server is not required to implement a future revision.

I am not saying that this is the perfect solution (maybe not even recommended).

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

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

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights   associated with READ-WRITE response code)
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Thu, 13 Jun 2002 06:50:23 -0700
Sender: [email-masked]

On Thu, 13 Jun 2002 06:21:32 -0700 (PDT)
  Mark Crispin <[email-masked]> wrote:
> On Thu, 13 Jun 2002 06:08:37 -0700, Vladimir A. Butenko wrote:
> > I have seen a small util that implements POP3 via an IMAP server. Should 
> >we
> > ALWAYS think about POP3 server as "a gateway from POP3 protocol to an 
> >IMAP
> > server"? I hope not. Please note that not only CGatePro WebMail, but many
> > other products implement WebMail "natively" - i.e. as yet another service
> > working with the mailstore, alongside POP3 and IMAP services.
> 
> That distinction does not always make sense.
> 
> WebPine software uses IMAP as a back end.  But there is no reason why it 
> has to.  It uses the c-client library, which supports IMAP, POP, NNTP, and 
> local mail stores.  A small change to the string supplied in a mail_open() > call transforms it from a "non-native" to a "native" system.
> 
> So I don't see how you can say that CGatePro WebMail is "real" and WebPine 
> is "not real" web mail.

Do you always ignore the ":-)" signs? If I have to, I will explain - I was 
joking/teasing/kidding. Anything that starts is "real". Anything that fails 
to start is "real", too.

I was talking (seriously) about the difference of "native" implementations 
and "gateway"-type implementations. If there are several "native" 
applications (i.e. serveral applications directly addressing something - 
mailstore in our case), then there is a need to document the functionality 
and semantics of that "something".

Then, even if there were ONE application (protocol) and other applications 
(protocols) would be implemented as "gateways", STILL there is a need to 
document the semantics of that underlying "something". And as a sample I 
used the current state of the LDAP protocol - which is still the only 
available protocol for Directory store, but w/o a doc describing directory 
store semantics, all implementations ended up being "slightly different".

> Can CGatePro WebMail be configured to use an IMAP back end?  If so, how is 
> it any different from WebPine?  Does the default configuration magically 
> change a program from "real" to "not real"?

It's irrelevant - see above, please. A sense of humor is not a sin, and it 
can be used sometimes, don't you think so?

> If not (CGatePro WebMail can not be configured to use an IMAP back end), 
> than
> are you arguing that a "real" web mail program is one that is a restricted
> subset of a "not real" web mail program?

:-)

> I could understand you making a distinction between web mail programs that
> only do local mail, and web mail programs that only do IMAP.  But we have 
> at
> least one example (WebPine) of a program that (at least in theory) can do
> both, and I doubt that WebPine is the only (or even the first) such 
> program.

:-)) Mark, there was no attempt to say that something is better and 
something is worse. That was a JOKE!!! Please look at this sign carefully: 
":-)" It means - I'm kidding, I'm joking, I'm making (trying to make) you 
smile, it does not mean "Mark, you stuff does not fly". It does.

Sincerely,
Vladimir

Date: Thu, 13 Jun 2002 06:21:32 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights   associated with READ-WRITE response code)
To: "Vladimir A. Butenko" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Thu, 13 Jun 2002 06:08:37 -0700, Vladimir A. Butenko wrote:
> I have seen a small util that implements POP3 via an IMAP server. Should we
> ALWAYS think about POP3 server as "a gateway from POP3 protocol to an IMAP
> server"? I hope not. Please note that not only CGatePro WebMail, but many
> other products implement WebMail "natively" - i.e. as yet another service
> working with the mailstore, alongside POP3 and IMAP services.

That distinction does not always make sense.

WebPine software uses IMAP as a back end.  But there is no reason why it has
to.  It uses the c-client library, which supports IMAP, POP, NNTP, and local
mail stores.  A small change to the string supplied in a mail_open() call
transforms it from a "non-native" to a "native" system.

So I don't see how you can say that CGatePro WebMail is "real" and WebPine is
"not real" web mail.

Can CGatePro WebMail be configured to use an IMAP back end?  If so, how is it
any different from WebPine?  Does the default configuration magically change a
program from "real" to "not real"?

If not (CGatePro WebMail can not be configured to use an IMAP back end), than
are you arguing that a "real" web mail program is one that is a restricted
subset of a "not real" web mail program?

I could understand you making a distinction between web mail programs that
only do local mail, and web mail programs that only do IMAP.  But we have at
least one example (WebPine) of a program that (at least in theory) can do
both, and I doubt that WebPine is the only (or even the first) such program.

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights   associated with READ-WRITE response code)
To: Alexey Melnikov <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
Cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Thu, 13 Jun 2002 06:08:37 -0700
Sender: [email-masked]

On Thu, 13 Jun 2002 05:00:36 -0600
  Alexey Melnikov <[email-masked]> wrote:
> > > Oh, and I don't "dislike WebMail".  After all, UW has a WebMail product 
> >of
> > > its own (WebPine).  WebMail done right!  :-)
> >
> > If it's done via IMAP, it's not WebMail :-)
> 
> We are just disagreeing on terms. I though about WebMail as IMAP to HTTP
> gateway.

I have seen a small util that implements POP3 via an IMAP server. Should we 
ALWAYS think about POP3 server as "a gateway from POP3 protocol to an IMAP 
server"? I hope not. Please note that not only CGatePro WebMail, but many 
other products implement WebMail "natively" - i.e. as yet another service 
working with the mailstore, alongside POP3 and IMAP services.

On the other hand, it is possible to abandon the concept of "mailstore" 
completely, and express everything in terms of IMAP - even if the protocol 
does NOT use IMAP.

I.e. the POP3 standard whould say: 
  
    RETR
      operation that retrieves message body (that same thing that is 
retrieved
      with the IMAP BODY[] command) and sends it to the client in the same
      format that is used in the IMAP APPEND command literal parameter, 
ending
      with a dot and "escaped" in the same manner as it is escaped in 
SMTP...

True, it can be done - but does it make sense?

A perfect example of such an approach is the LDAP standards. Thanks God, 
mail
things are in much better shape, but LDAP presents a perfect example of the 
mess created with that "misture" of protocol description and "store/object" 
semantics. The semantics of Directory database/store has to be retrieved 
from various parts of the LDAP protocol description, and is not clearly 
specified ANYWHERE (in the RFC tree, I'm not talking about X.500). The 
result - you CANNOT find any 2 LDAP servers that use the store with the same 
semantics.

That's why I'd always vote for separate standards that explain the object 
store semantics (mail, directory, whatever) - and separate standards that 
specify communication protocol used to access those objects/store elements.

> Regards,
> Alexey Melnikov

Sincerely,
Vladimir

Date: Thu, 13 Jun 2002 06:08:58 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of  rightsassociated with READ-WRITE response code)
To: Alexey Melnikov <[email-masked]>
cc: Lawrence Greenfield <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Thu, 13 Jun 2002 04:59:25 -0600, Alexey Melnikov wrote:
> Also as Vladimir pointed out in his private email to me, ACL2 implementation
> can treat <identifier> as user=<identifier>, if the implementation prohibits
> the creation of users with special names or names with "=".

What does this mean?

Would an identifier such as xxx be canonicalized to user=xxx form?  If not,
how is a client to know what xxx means?  Also, wouldn't this conflict with
future assignment of special identifiers?

Date: Thu, 13 Jun 2002 05:22:47 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: Lawrence Greenfield <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi,
>
> --On Saturday, June 8, 2002 1:26 PM -0400 Lawrence Greenfield
> <[email-masked]> wrote:
>
> | This is fine with me, though this doesn't appear to totally agree with
> | the text in the IMAP draft (section 6.3.1):
> |
> |       Read-only access through SELECT differs from the EXAMINE command
> |       in that certain read-only mailboxes MAY permit the change of
> |       permanent state on a per-user (as opposed to global) basis.
> |       Netnews messages marked in a server-based .newsrc file are an
> |       example of such per-user permanent state that can be modified
> |       with read-only mailboxes.

This seems to imply that a server that implements only per-user system flags,
must ignore "swt" for the purpose of deciding if READ-WRITE should be returned?

What is the sane way of describing this?

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

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

Date: Thu, 13 Jun 2002 05:20:55 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lawrence Greenfield <[email-masked]>
CC: Mark Crispin <[email-masked]>, Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

Lawrence Greenfield wrote:

> Another possibility is for ACL to recommend that servers implementing
> ACL just not return either READ-ONLY or READ-WRITE in response to a
> SELECT.

I think this breaks compliance with RFC 2060.

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

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

Date: Thu, 13 Jun 2002 05:00:36 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Vladimir A. Butenko" <[email-masked]>
CC: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights   associated with READ-WRITE response code)
Sender: [email-masked]

> > Oh, and I don't "dislike WebMail".  After all, UW has a WebMail product of
> > its own (WebPine).  WebMail done right!  :-)
>
> If it's done via IMAP, it's not WebMail :-)

We are just disagreeing on terms. I though about WebMail as IMAP to HTTP
gateway.

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

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

Date: Thu, 13 Jun 2002 04:59:25 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lawrence Greenfield <[email-masked]>
CC: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of  rightsassociated with READ-WRITE response code)
Sender: [email-masked]

Mark Crispin wrote:

> I also am amazed by the argument that the new system of identifiers
> "throws away a large amount of interoperable code".
>
> char *acl_to_acl2 (char *id)
> {
>   char *ret;
>   if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id);
>   else {
>     ret = (char *) malloc (5 + strlen (id) + 1);
>     sprintf (ret,"user=%s",id);
>   }
>   return ret;
> }
>
> char *acl2_to_acl (char *id)
> {
>   char *ret;
>   if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id);
>   else if (strncmp (id,5,"user=")
>     strcpy (ret = (char *) malloc (strlen (id + 5) + 1),id + 5)
>   else ret = 0;
>   return ret;
> }
>
> OK, I admit this is a bit too simple-minded, but it makes the point.

Exactly.

Also as Vladimir pointed out in his private email to me, ACL2 implementation
can treat <identifier> as user=<identifier>, if the implementation prohibits
the creation of users with special names or names with "=".

Larry, our ACL implementations are almost identical, I don't believe there
will be so match work.

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

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

Date: Thu, 13 Jun 2002 04:54:58 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lawrence Greenfield <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights   associated with READ-WRITE response code)
Sender: [email-masked]

Lawrence Greenfield wrote:

> If you feel the need to deprecate the old ACL commands, can we just
> name them something else?

Does it really matter? Syntax is almost identical and the difference can
be codified with the couple if statements.

>  I don't see the need to be so cute about
> our upgrades when we have an infinite number of bits that will make it
> blatantly obvious what versions we're using.

Just for the record, I don't care if ACL2 uses same command names with
slightly modified syntax or we just give these new commands new names. I
will be very reluctant to change command syntax further (remember, our
server also implements ACL and we have exactly the same set of issues),
unless it give a real benefit.

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

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

Date: Thu, 13 Jun 2002 04:45:32 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lawrence Greenfield <[email-masked]>
CC: Simon Josefsson <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

Lawrence Greenfield wrote:

>    From: Simon Josefsson <[email-masked]>
>    Date: Wed, 12 Jun 2002 20:52:11 +0200
>
>    Alexey Melnikov <[email-masked]> writes:
>
>    > I've noticed yesterday that ABNF for "rights" was defined as "astring",
>    > not just "quoted".
>    > Anybody objects to changing this to quoted, because I don't see that
>    > "rights" will ever contain control or 8bit characters.
>
>    Sounds fine.  I've always disliked having different ways of expressing
>    the same thing, making things simpler is a good idea.  Atom is perhaps
>    even better.
>
> No, atoms aren't sufficient.  "rights" can be the empty string.  Atoms
> can't express the empty string.

Oops, you are right. However my argument about non blocking parser stands. See
my other reply.

> I see no reason to constain rights to quoted strings.  I think having
> them as strings makes sense---they are strings---and in IMAP we have
> up to three ways of expressing a string.  Instead of simplifying
> things, it'll complicated the lexical and syntatic levels of IMAP even
> more.

Not really. Instead of writing one function that accept any kind of string, you
can write a new function that allows only quoted strings and make the first call
the second.

A particular implementation (;-)) may choose to accept both types of strings
when only quoted is allowed and this is fine.

> If you want to remove all ways of expressing strings in IMAP besides
> literals, well, fine, but that's a different argument.

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

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

Date: Thu, 13 Jun 2002 04:39:27 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Meeting?
Sender: [email-masked]

Pete Resnick wrote:

> Well, life is back to this list. Do we have enough to discuss and
> have enough people going that I should set up a session in Yokohama?
> (I will be there.)

I suggest we don't meet this time, but we meet in November.
Neither myself, nor Mark, nor Larry will be there.

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

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

Date: Wed, 12 Jun 2002 20:51:14 +0100
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: SETACL/DELETEACL questions (was Re: ACL2: set of rights associated  with  READ-WRITE response code)
Sender: [email-masked]

Mark Crispin wrote:

> On Tue, 11 Jun 2002 15:21:49 -0600, Alexey Melnikov wrote:
> > > What should a server do if it receives a SETACL which can not be performed
> > > without doing a DELETEACL of some other identifier/rights pair?  [Think of
> > > what would become a "chgrp" in UNIX]
> > Server is allowed to do that. It must return new ACL in an unsolicited ACL
> > response anyway.
>
> How is it indicated to the client that this will happen *before* doing the
> SETACL?

I don't know any way currently.

> We're talking about client and end user surprise here.  Such surprises will
> generate complaints.

We don't have too many choices really. Either the server says NO to an operation
or it says OK, but updates client's view with unsolicited ACL response. Am I
missing anything?

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

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

Date: Wed, 12 Jun 2002 20:49:49 +0100
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Rob Siemborski <[email-masked]>
CC: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

Mark Crispin wrote:

> On Wed, 12 Jun 2002 12:23:52 -0400 (EDT), Rob Siemborski wrote:
> > Is there a compelling reason for this?
>
> Simplicity.  Why allow in the syntax something that is meaningless?

Correct. Also see my comment below.

> > Unless I'm missing something,
> > nothing in the IMAP base spec that can be a quoted string is disallowed
> > from being a literal
>
> You missed the internaldate argument to APPEND.

   string          = quoted / literal

ANNOTATATE extension, for example, uses "quoted" instead of "astring" for entry
names.
See below why it is a very good thing, IMHO.

> > Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but
> > why be different?  I could easily see implementations that make heavy use
> > of literals missing this special case.

It is not about the bandwidth, but about simplicity of implementation.

My experience with writing parsers in non-blocking or asynchronous IO model
(i.e. when read from the socket may return that literal was not completely
received by TCP stack) tells that it is a pain in the ass to write a parser for
any command that uses literals. Why? Because you have to save state if there is
not enough data. Dealing with "quoted" or atoms is a bit easier.
So, for a server implementing only ACL2 and using async IO, this change will
help.

If a server also implements ACL it has to accept "astring" anyway. So CMU
implementation doesn't have to change.

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

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

Date: Wed, 12 Jun 2002 20:25:03 +0100
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

Mark Crispin wrote:

> On Wed, 12 Jun 2002 06:58:42 -0600, Alexey Melnikov wrote:
> > I've noticed yesterday that ABNF for "rights" was defined as "astring",
> > not just "quoted".
> > Anybody objects to changing this to quoted, because I don't see that
> > "rights" will ever contain control or 8bit characters.
>
> By that argument, rights should be an atom instead of quoted.  It is possible
> to restrict from astring to atom, but not from quoted to atom, so if atom is
> the right thing this has to be done now.

That is even better.

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

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

Date: Wed, 12 Jun 2002 20:15:18 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 12 Jun 2002, Lawrence Greenfield wrote:
> I think defining new, entirely different identifiers throws away a
> large amount of interoperable code that already exists.  This is a
> silly response to the fear that someone, somewhere, has usernames
> starting with $ that they will need to use with IMAP ACLs.

It isn't just user names starting with $.  It's also the "anyone" user
name.

It is certainly not "silly" to worry that an extension to a protocol
arbitarily establishes a limitation that is not in the base specification.
RFC 2086 made a mistake by assuming that identifier == username.

The new system of identifiers makes more sense than RFC 2086 (or the
proposed $ kludge), and is a clean functional superset.  The whole point
of ACL2 is to fix the numerous deficiencies in RFC 2086.  That entire
effort would be wasted by a misguided effort to be "compatible".

I also am amazed by the argument that the new system of identifiers
"throws away a large amount of interoperable code".

char *acl_to_acl2 (char *id)
{
  char *ret;
  if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id);
  else {
    ret = (char *) malloc (5 + strlen (id) + 1);
    sprintf (ret,"user=%s",id);
  }
  return ret;
}

char *acl2_to_acl (char *id)
{
  char *ret;
  if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id);
  else if (strncmp (id,5,"user=")
    strcpy (ret = (char *) malloc (strlen (id + 5) + 1),id + 5)
  else ret = 0;
  return ret;
}

OK, I admit this is a bit too simple-minded, but it makes the point.

Date: Wed, 12 Jun 2002 19:47:04 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 12 Jun 2002, Lawrence Greenfield wrote:
> No, atoms aren't sufficient.  "rights" can be the empty string.  Atoms
> can't express the empty string.

OK, in that case, then it should remain astring.

-- Mark --

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

Date: Wed, 12 Jun 2002 22:46:13 -0400
From: Lawrence Greenfield <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: "Vladimir A. Butenko" <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
Sender: [email-masked]

If you feel the need to deprecate the old ACL commands, can we just
name them something else?  I don't see the need to be so cute about
our upgrades when we have an infinite number of bits that will make it
blatantly obvious what versions we're using.

I think defining new, entirely different identifiers throws away a
large amount of interoperable code that already exists.  This is a
silly response to the fear that someone, somewhere, has usernames
starting with $ that they will need to use with IMAP ACLs.

Larry

Date: Wed, 12 Jun 2002 22:36:23 -0400
From: Lawrence Greenfield <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

   From: Simon Josefsson <[email-masked]>
   Date: Wed, 12 Jun 2002 20:52:11 +0200

   Alexey Melnikov <[email-masked]> writes:

   > I've noticed yesterday that ABNF for "rights" was defined as "astring",
   > not just "quoted".
   > Anybody objects to changing this to quoted, because I don't see that
   > "rights" will ever contain control or 8bit characters.

   Sounds fine.  I've always disliked having different ways of expressing
   the same thing, making things simpler is a good idea.  Atom is perhaps
   even better.

No, atoms aren't sufficient.  "rights" can be the empty string.  Atoms
can't express the empty string.

I see no reason to constain rights to quoted strings.  I think having
them as strings makes sense---they are strings---and in IMAP we have
up to three ways of expressing a string.  Instead of simplifying
things, it'll complicated the lexical and syntatic levels of IMAP even
more.

If you want to remove all ways of expressing strings in IMAP besides
literals, well, fine, but that's a different argument.

Larry

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
To: Cyrus Daboo <[email-masked]>, Lyndon Nerenberg <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 14:50:05 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 17:43:38 -0400
  Cyrus Daboo <[email-masked]> wrote:
> Hi,

[skipped]

> | Yes, right. But the fact that many clients need to open many connections
> | to the server forces you to set that limit pretty high. Our docs suggest
> | 5-10. That's why reducing the number of IMAP connections each client
> | requires can also improve system protection.
> 
> Right - but your solution requires a change to the protocol with support 
> from both servers AND clients. If clients choose not to use the new 
> mechanism then it won't be of any benefit. So why not try and get clients 
> to change their existing usage pattern first - what justifications have 
> you had from client writers as to why so many connections are needed? If 
> we can understand what demands exist on the client that justify this, we 
> can make sure that any protocol changes really will make a difference.

Sure. Imagine a client that ALWAYS works via its own cache. It's a 
requirement and just take it so. I do understand that it is possible to 
create clients that do not use local cache (and your client is a very good 
sample), but there are OTHER clients and other approaches. Either we have to 
say now - "clients that use local caches are BAD and must be killed", or we 
have to think about supporting them more effectively.

If you think about a client that provides you access to your entire 
mailstore - with a cache or without, you can come to the same requirement. 
"3-pane clients" are not the only clients that exist. And clients that can 
open a separate window for each mailbox are not the only clients that need 
to know about several mailboxes at the same time. You either say that those 
clients do not and should not exist, or you may want to agree that they a 
right to exist and in this case the proposed extension (actually designed to 
support such a client) makes some sense.

> -- 
> Cyrus Daboo

Sincerely,
Vladimir

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
To: Lyndon Nerenberg <[email-masked]>, "Vladimir A. Butenko " <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 14:43:37 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 15:40:04 -0600
  Lyndon Nerenberg <[email-masked]> wrote:
> > Also, if a client does not complain when a server drops its "IDLE" 
> > connection, but instead reconnects, selects the same mailbox and 
> >re-enters 
> > the IDLE state - what will be the difference (besides even bigger load on 
> > the server)?
> 
> "idle" and "IDLE" are not the same thing. I was specifically talking
> about "idle" sessions. An IMAP session doing "IDLE" is not "idle."

  From the very beginning I was talking about not the BROKEN clients (that 
just forget to open some connections - as it happened a lot in Netscape 
Messenger), but about clients that NEED to keep those connections open, 
because they need to "stay in synch" with several mailboxes. It implies that 
there is an IDLE command pending there or that those clients send NOOP or 
something to get the updates. And the proposed extension targets exactly 
this situation - it allows to get rid of "synching" connections and get that 
same information in one, "main" connection that can be used to perform 
"active actions".

> --lyndon

Sincerely,
Vladimir

Date: Wed, 12 Jun 2002 17:43:38 -0400
From: Cyrus Daboo <[email-masked]>
To: "Vladimir A. Butenko" <[email-masked]>, Lyndon Nerenberg <[email-masked]>
cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
Sender: [email-masked]

Hi,

--On  "Vladimir A. Butenko" <[email-masked]> wrote:

|> I've come across a number of servers that d have that option. Its
|> probably  a good idea to have something like that just from a security
|> standpoint -  if I know I can attack your server by opening lots of
|> connections on it  from my machine, that becomes an interesting denial
|> of service  possibility.
|
| Yes, right. But the fact that many clients need to open many connections
| to the server forces you to set that limit pretty high. Our docs suggest
| 5-10. That's why reducing the number of IMAP connections each client
| requires can also improve system protection.

Right - but your solution requires a change to the protocol with support 
from both servers AND clients. If clients choose not to use the new 
mechanism then it won't be of any benefit. So why not try and get clients 
to change their existing usage pattern first - what justifications have you 
had from client writers as to why so many connections are needed? If we can 
understand what demands exist on the client that justify this, we can make 
sure that any protocol changes really will make a difference.

-- 
Cyrus Daboo

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
To: Cyrus Daboo <[email-masked]>, Lyndon Nerenberg <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 14:39:40 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 17:36:09 -0400
  Cyrus Daboo <[email-masked]> wrote:
> Hi,
> 
> --On  "Vladimir A. Butenko" <[email-masked]> wrote:
> 
> | This would be called a "broken server". The client has all rights to
> | assume that the server would not break a connection unless a server has 
> a
> | non-client related problem. A server that closes connections because it
> | is just "too busy" falls in the category of the servers that simply
> | "cannot be used under this type of load".
> 
> Then you need to be clearer about specifying the load capability of the 
> server when using IMAP - in your case specify the load in terms of the 
> number of allowed IMAP connections rather than the total number of users.

That's what we always do in our responses to various large-scale RFPs. Those 
who compose the RFPs tend to put "we need a server to handle X users" and it 
takes a lot of time to explain that the pure number of users does not mean 
much, that we must look at the avg user profile, etc. We have a customer 
that has 4.5mln users on a single server - so what? On the other end, we 
often have to deploy a 4-10 server cluster to handle some sites with just 
100,000 users. BTW, in both cases the IMAP is the main protocol. The # of 
concurrent IMAP connections is just one thing, of course, there are many 
others - but it is an important thing, and whatever can be done to decrease 
the # of connections each user needs is a Good Thing.

> -- 
> Cyrus Daboo

Sincerely,
Vladimir

Organization: ACI Worldwide - Advanced Technology Group
To: "Vladimir A. Butenko" <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
Date: Wed, 12 Jun 2002 15:40:04 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> Also, if a client does not complain when a server drops its "IDLE" 
> connection, but instead reconnects, selects the same mailbox and re-enters 
> the IDLE state - what will be the difference (besides even bigger load on 
> the server)?

"idle" and "IDLE" are not the same thing. I was specifically talking
about "idle" sessions. An IMAP session doing "IDLE" is not "idle."

--lyndon

Pieces of eight, pieces of eight, pieces of nine. Parroty error.

Date: Wed, 12 Jun 2002 17:36:09 -0400
From: Cyrus Daboo <[email-masked]>
To: "Vladimir A. Butenko" <[email-masked]>, Lyndon Nerenberg <[email-masked]>
cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
Sender: [email-masked]

Hi,

--On  "Vladimir A. Butenko" <[email-masked]> wrote:

| This would be called a "broken server". The client has all rights to
| assume that the server would not break a connection unless a server has a
| non-client related problem. A server that closes connections because it
| is just "too busy" falls in the category of the servers that simply
| "cannot be used under this type of load".

Then you need to be clearer about specifying the load capability of the 
server when using IMAP - in your case specify the load in terms of the 
number of allowed IMAP connections rather than the total number of users.

-- 
Cyrus Daboo

Organization: ACI Worldwide - Advanced Technology Group
To: Cyrus Daboo <[email-masked]>
cc: "Vladimir A. Butenko" <[email-masked]>, Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
Date: Wed, 12 Jun 2002 15:35:56 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> How do you then deal with clients that have an 'automatically re-connect 
> when server connection dies' mode? 

By swearing a lot.

> In that mode the client will simply 
> re-connect as soon as you kill their connection.

Most clients these days will hopefully defer that open until they
have actual work to do. In general, clients that cache intelligently
also tend to use connections intelligently. I'm all for "natural
selection" here.

> Another solution is to have a server admin configurable option to limit the 
> maximum number of connections from any one client machine. Provided you 
> ensure that the admin can't set this below, say 3, that might help. I've 
> come across a number of servers that d have that option. Its probably a 
> good idea to have something like that just from a security standpoint - if 
> I know I can attack your server by opening lots of connections on it from 
> my machine, that becomes an interesting denial of service possibility.

If the client is "smart" (see above) this will have little overall
impact (compared to LRUing idle connections). If the client is stupid,
this will just increase the thrash level as the client closes existing
connections to (needlessly) open a new connection to grab something
that could have been obtained over one of the existing connections.
It will then close the new connection to make room to re-open the old
connection. This constant thrashing of TCP sessions tends to put a
much higher load on server OSes than just maintaining existing idle
connections.

--lyndon

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
To: Cyrus Daboo <[email-masked]>, Lyndon Nerenberg <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 14:32:32 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 17:28:24 -0400
  Cyrus Daboo <[email-masked]> wrote:
> Hi,
> 
> --On  Lyndon Nerenberg <[email-masked]> wrote:
> 
> | If your server can't scale to 100K+ connections then you should have
> | it close down old connections on an LRU basis to cap the total
> | connection count at something the server *can* handle. You don't
> | need protocol modifications to solve this problem. (Especially
> | since, as you stated earlier, "most of the connections are idle.")
> 
> How do you then deal with clients that have an 'automatically re-connect 
> when server connection dies' mode? In that mode the client will simply 
> re-connect as soon as you kill their connection.

Exactly.

> Another solution is to have a server admin configurable option to limit 
> the maximum number of connections from any one client machine. Provided 
> you ensure that the admin can't set this below, say 3, that might help. 

We do have this option. So, if the client mailer NEEDS 4 connections and the 
server rejects it - what do we get? Yes, right - a call to the support 
center. Then imagine a customer like Charter that has more than 1mln users 
and you get the idea that "or, it's your client fault" would not be an 
acceptable answer for those sites.

> I've come across a number of servers that d have that option. Its probably 
> a good idea to have something like that just from a security standpoint - 
> if I know I can attack your server by opening lots of connections on it 
> from my machine, that becomes an interesting denial of service 
> possibility.

Yes, right. But the fact that many clients need to open many connections to 
the server forces you to set that limit pretty high. Our docs suggest 5-10. 
That's why reducing the number of IMAP connections each client requires can 
also improve system protection.

> -- 
> Cyrus Daboo

Sincerely,
Vladimir

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
To: Lyndon Nerenberg <[email-masked]>, "Vladimir A. Butenko " <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 14:28:27 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 15:19:35 -0600
  Lyndon Nerenberg <[email-masked]> wrote:
> If your server can't scale to 100K+ connections then you should have
> it close down old connections on an LRU basis to cap the total
> connection count at something the server *can* handle. You don't
> need protocol modifications to solve this problem. (Especially
> since, as you stated earlier, "most of the connections are idle.")

This would be called a "broken server". The client has all rights to assume 
that the server would not break a connection unless a server has a 
non-client related problem. A server that closes connections because it is 
just "too busy" falls in the category of the servers that simply "cannot be 
used under this type of load".

Also, if a client does not complain when a server drops its "IDLE" 
connection, but instead reconnects, selects the same mailbox and re-enters 
the IDLE state - what will be the difference (besides even bigger load on 
the server)?

> --lyndon

Sincerely,
Vladimir

Date: Wed, 12 Jun 2002 17:28:24 -0400
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
Sender: [email-masked]

Hi,

--On  Lyndon Nerenberg <[email-masked]> wrote:

| If your server can't scale to 100K+ connections then you should have
| it close down old connections on an LRU basis to cap the total
| connection count at something the server *can* handle. You don't
| need protocol modifications to solve this problem. (Especially
| since, as you stated earlier, "most of the connections are idle.")

How do you then deal with clients that have an 'automatically re-connect 
when server connection dies' mode? In that mode the client will simply 
re-connect as soon as you kill their connection.

Another solution is to have a server admin configurable option to limit the 
maximum number of connections from any one client machine. Provided you 
ensure that the admin can't set this below, say 3, that might help. I've 
come across a number of servers that d have that option. Its probably a 
good idea to have something like that just from a security standpoint - if 
I know I can attack your server by opening lots of connections on it from 
my machine, that becomes an interesting denial of service possibility.

-- 
Cyrus Daboo

Organization: ACI Worldwide - Advanced Technology Group
To: "Vladimir A. Butenko" <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
Date: Wed, 12 Jun 2002 15:19:35 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

If your server can't scale to 100K+ connections then you should have
it close down old connections on an LRU basis to cap the total
connection count at something the server *can* handle. You don't
need protocol modifications to solve this problem. (Especially
since, as you stated earlier, "most of the connections are idle.")

--lyndon

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability
To: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 13:39:16 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 16:13:28 -0400
  Cyrus Daboo <[email-masked]> wrote:
> Hi,
> 
> --On  "Vladimir A. Butenko" <[email-masked]> wrote:
> 
> | The main problem with MANY IMAP clients is the number of IMAP 
> connections
> | they keep open. While it may be not the case with the non-GUI clients,
> | GUI clients tend to keep an open connection for each mailbox the user
> | opened. Thus, a 10,000 active users often open 100,000 connections to a
> | server, and this is not good, because: a) each connection require a
> | socket on the server, and many systems "do not work very well" when they
> | need to handle 100,000 open sockets. But we often meet a req to support
> | 30,000 concurrent users - and 300,000 connections is definitely "too
> | many".
> 
> I think you are overstating this - are you really saying that an IMAP 
> client typically has 10 connections open to a single server when the user 
> is logged in?

It all depends on your interpretation of the word "typically" :-). We did 
see that sometimes clients (I do not want to point fingers right now) that 
ended up with many open connections after you copy/move messages, and there 
are also clients where "keeping the cache current for all mailboxes" is a 
must and the authors use it as the explanation why so many connections need 
to be opened.

While right now we definitely do not see that 1:10 ration I mentioned, the 
fact that we saw those things and the fact that we do not believe that those 
clients become less popular, and the fact that more and more people put most 
of their docs on mail servers, ending up with dozens of mailboxes in each 
account - makes us try to find a solution BEFORE it becomes a unsolvable 
problem.

> Lets face it, most clients with the typical three-pane view 
> limit the number of mailboxes the user has open. Even with our client that 
> allows multiple windows for mailboxes, I very much doubt anyone gets close 
> to 10. Remember, that connections are costly on the client-side too.

OK. Just try Netscape Messenger. It's not a client we worry about, but you 
will get the idea :-(

> | b) in many server implementations each connection reequires a
> | thread (at least, if not a process), and each thread needs a stack, and
> | if 100K stacks are used, 10,000 connections would require 1GB of VRAM 
> for
> | stacks (not tha bad), but 100,000 connections would require 10GB of VRAM
> | - and this makes the server life "difficult" - when deployed on a 32-bit
> | system.
> 
> This is a server design issue. For this kind of scalability simply use a 
> fixed thread pool, and service connections with that. You don't have to 
> have one thread per connection. Given that an IMAP connection is idle for 
> significant periods of time, this is a reasonable thing to do.

That's true. But thread stacks can be solved this way, while excessive 
number of connections will still be there. Try this test: make a simple test 
program that measures the performance of basic OS operations, then make that 
program open 100,000 sockets and measure the same things again. You can get 
very interesting results under Solaris 7, for example (they did address this 
in Solaris 8). 

> | of the implementations should only benefit: the client should use may
> | "SELECT" commands to switch between mailboxes (instead of using many
> | connections), but since the "WATCH" command would keep the mailbox in 
> the
> | "parsed" stage, the price for those additional "SELECTs" should be
> | virtually zero.
> 
> This approach will effectively deprecate the use of sequence numbers and 
> require clients to maintain full UID caches for all messages in all the 
> mailboxes it is watching. The watched responses will have to return 
> message info using UIDs.

This approach can be used EXACTLY for those clients that ALREADY do this. 
While I understand that this is not what IMAP authors and "good IMAP" client 
authors (like yourself) had in their minds, many popular clients DO MAINTAIN 
those caches, and this is a fact of live. If a client does not maintain the 
caches and does not care about synching them - it won't use those 
extensions, that's it. But if it does, it will work much more effectively 
with those extensions.

  
> I think a better approach (if you really want to force one connection to 
> handle multiple mailboxes) is to introduce a MULTISELECT command that lets 
> you have more than one mailbox selected - in that mode all of the 
> responses from the server would include the mailbox name as part of the 
> response, so it would be possible to correlate responses with each 
> selected mailbox. This would allow sequence number access for all 
> mailboxes as well as using UIDs.

I've mentioned this in my previous letter. I think that this is a much more 
radical change of the protocol. We can implement it easily, but it will 
unlikely have any real usage: a client that relies on such functionality 
would need a completely different code to support "old" IMAP servers. While 
the proposed extension adds only few things to the protocol, and it won't 
take a lot of additional code to support servers that do not have this 
extension (that code would just open a separate connection, do SELECT, then 
IDLE and get all updates)

Again, my letter was just to see if anyone is interested. We now have that 
extension in any case, I just wanted to know if it makes sense to document 
it so other vendors can implement it, too - and if the client vendors find 
it useful. If not - then it's less work for us :-)

> Cyrus Daboo

Sincerely,
Vladimir

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 13:13:33 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 11:23:28 -0700 (PDT)
  Mark Crispin <[email-masked]> wrote:
> Without deprecating Vladimir's efforts, he is not the only one who is 
> working
> on "push" type technology for mailbox updates.
> 
> I'd rather not say too much about my efforts at this point since I only 
> have a toy implementation.  The basic idea is that it is a notification
> mechanism in which a client (not necessarily an IMAP client) asks a
> notification server to be delivered events on a certain object identifier,
> and event generators  for the particular object identifier spam the
> notification server with events. 
>  Of course, it's actually a lot more complicated than this.
> 
> It is not impossible to implement an IMAP extension that uses an interface
> very much like Vladimir's (or even identical), if in the long run it is
> determined to be desirable to have access to the mechanism via IMAP.

I think we look at this issue from different points of view. The proposed 
extension, indeed, can be viewed as a particular case of a more generic 
"Notification service", but I was talking about the IMAP protocol itself and 
the changes/extensions that we may have to implement in that protocol to 
meet the modern requirements.

The IMAP protocol fits well when a "single-view" client is used. There the 
concept of "going from one mailbox to a different one" is well addressed by 
the use of the SELECT command. Modern, "multiple-view" clients use a 
different concept. They often use "one window-one session-one SELECT" 
approach and have to maintain many connections to work with many "views". 
While the current IMAP protocol can be (and is) successfully used by those 
clients, it causes scalability problems that I've mentioned. And because 
most clients are used by mortals that still have just two hands (at max) and 
one single-threaded brain (at max), most of those connections are sitting 
idle, with all action taking place at only one connection at any given 
moment.

This leads to the idea to support those multiple-view clients with just one 
connection. One method would be to get rid of the "Selected" state at all, 
giving the client ability to work with any message in any mailbox at any 
time - but this would definitely result in a completely new protocol that 
would just use many IMAP portions. What we are using is a much more moderate 
change - those "WATCH" extensions. I cannot say now how well they work for 
multiple-view clients, but we hope that in 3-4 months the installed base of 
those clients will be well in hundred thousands, so we hope to have more 
"reallife" experience with it (it would be too bold to estimate that a new 
client will get such an audience so quickly, but that client is not a real 
one - it's a MAPI connector for MS OUTLOOK, thus this conservative estimate 
- less than 1% of our current users).

Please note that there is no NEW "push" technology proposed here. All used 
technologies already exist in IMAP - with or without the IDLE extension. But 
in the basic IMAP the server reports updates only for one, "selected" 
mailbox, while with the proposed extension updates are reported for any set 
of mailboxes (besides the currently selected mailbox). So, the proposed 
thing is a much less generic one than your "notification server", and it is 
completely IMAP-specific, and uses the already existing technologies and the 
IMAP ideology.
The message actions (read/copy/store) still can be used only from the 
"selected state", but the client can stay in sync with all mailboxes without 
keeping those "watching" connections.

Depending on the type of mailbox store used, the extension may be very 
easily implemented. In CommuniGate Pro it took about 100 lines of code - 
total.

Sincerely,
Vladimir

Date: Wed, 12 Jun 2002 16:13:28 -0400
From: Cyrus Daboo <[email-masked]>
To: "Vladimir A. Butenko" <[email-masked]>, Mark Crispin <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability
Sender: [email-masked]

Hi,

--On  "Vladimir A. Butenko" <[email-masked]> wrote:

| The main problem with MANY IMAP clients is the number of IMAP connections
| they keep open. While it may be not the case with the non-GUI clients,
| GUI clients tend to keep an open connection for each mailbox the user
| opened. Thus, a 10,000 active users often open 100,000 connections to a
| server, and this is not good, because: a) each connection require a
| socket on the server, and many systems "do not work very well" when they
| need to handle 100,000 open sockets. But we often meet a req to support
| 30,000 concurrent users - and 300,000 connections is definitely "too
| many".

I think you are overstating this - are you really saying that an IMAP 
client typically has 10 connections open to a single server when the user 
is logged in? Lets face it, most clients with the typical three-pane view 
limit the number of mailboxes the user has open. Even with our client that 
allows multiple windows for mailboxes, I very much doubt anyone gets close 
to 10. Remember, that connections are costly on the client-side too.

| b) in many server implementations each connection reequires a
| thread (at least, if not a process), and each thread needs a stack, and
| if 100K stacks are used, 10,000 connections would require 1GB of VRAM for
| stacks (not tha bad), but 100,000 connections would require 10GB of VRAM
| - and this makes the server life "difficult" - when deployed on a 32-bit
| system.

This is a server design issue. For this kind of scalability simply use a 
fixed thread pool, and service connections with that. You don't have to 
have one thread per connection. Given that an IMAP connection is idle for 
significant periods of time, this is a reasonable thing to do.

| It looks like this extension allows to design a client that can open only
| one IMAP connection to the server, but still "stay in synch" with several
| mailboxes. This should decrease the server load for large sites, and most
| of the implementations should only benefit: the client should use may
| "SELECT" commands to switch between mailboxes (instead of using many
| connections), but since the "WATCH" command would keep the mailbox in the
| "parsed" stage, the price for those additional "SELECTs" should be
| virtually zero.

This approach will effectively deprecate the use of sequence numbers and 
require clients to maintain full UID caches for all messages in all the 
mailboxes it is watching. The watched responses will have to return message 
info using UIDs.

I think a better approach (if you really want to force one connection to 
handle multiple mailboxes) is to introduce a MULTISELECT command that lets 
you have more than one mailbox selected - in that mode all of the responses 
from the server would include the mailbox name as part of the response, so 
it would be possible to correlate responses with each selected mailbox. 
This would allow sequence number access for all mailboxes as well as using 
UIDs.

-- 
Cyrus Daboo

Date: Wed, 12 Jun 2002 16:04:09 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: re: New topic: Extensions to impove IMAP scalability
Sender: [email-masked]

Hi,

--On  Mark Crispin <[email-masked]> wrote:

| Without deprecating Vladimir's efforts, he is not the only one who is
| working on "push" type technology for mailbox updates.
|
| I'd rather not say too much about my efforts at this point since I only
| have a toy implementation.  The basic idea is that it is a notification
| mechanism in which a client (not necessarily an IMAP client) asks a
| notification server to be delivered events on a certain object
| identifier, and event generators for the particular object identifier
| spam the notification server with events.  Of course, it's actually a lot
| more complicated than this.

Oh great - yet another notification protocol proposal! All previous efforts 
in this area seem to have failed. I hope your solution can survive!

To be honest with you, at this point I strongly believe that this type of 
notification should be integrated into presence protocols - I'd like my 
'buddy' list to also tell me when new mail is present in a mailbox, and for 
the mailbox to send me an instant message with a summary of the new mail 
content. So why not piggy back this on impp?

-- 
Cyrus Daboo

Date: Wed, 12 Jun 2002 12:24:14 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Meeting?
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 12 Jun 2002 14:12:53 -0500, Pete Resnick wrote:
> Well, life is back to this list. Do we have enough to discuss and
> have enough people going that I should set up a session in Yokohama?
> (I will be there.)

Yokohama is just 4 1/2 weeks from now.  The likelihood of getting reasonably
priced airfare ($500) and lodging (6000 - 8000 yen/night) for Japan is
vanishing this close to the travel date.

For the next IETF, can we discuss the go/no-go question a bit earlier, such as
when the first announcements are made?

Our state government has a major budget crisis, and we're a state university.
Non-essential travel for any of us is out of the question.  Given that I have
personal business in Japan, and that nothing else at the Yokohama IETF seems
related to anything that I'm doing, any travel request from me to go to
Yokohama will be picked over with a fine-toothed comb.

So, (with considerable regret) I ask that there NOT be an IMAPEXT meeting at
Yokohama.

Date: Wed, 12 Jun 2002 14:12:53 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Meeting?
Sender: [email-masked]

Well, life is back to this list. Do we have enough to discuss and 
have enough people going that I should set up a session in Yokohama? 
(I will be there.)

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

Date: Wed, 12 Jun 2002 12:01:52 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: ACL2 backwards compatibility
To: Simon Josefsson <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 12 Jun 2002 20:59:38 +0200, Simon Josefsson wrote:
> Can a server support both ACL and ACL2?  The latest draft indicate
> that ACL and ACL2 is incompatible.  How do the server know whether the
> client is using ACL or ACL2?

Alexey's latest proposals (basically a superset of what I proposed) will
accomplish a server being able to do both ACL and ACL2.  There is different
command syntax for ACL and ACL2 commands, and that can be used by the server
to determine ACL vs. ACL2 semantics.

An ACL server should be able to add ACL2 support without too much difficulty.
An ACL2 server may find it difficult or impossible to add ACL.

I purpose to implement ACL2 only.

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
To: Arnt Gulbrandsen <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 11:58:47 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 20:28:07 +0200
  Arnt Gulbrandsen <[email-masked]> wrote:
> I have the impression that today, a "mailstore" is something that talks
> IMAP, LMTP and often a few other protocols.

You can think of it as you want. I prefer to call the "mailstore" some 
internal mail server component that implements certain functions, in the 
same way as the Directory is some database - with some well-defined 
semantics.
If you want to include the components that implement various protocols into 
what you call "mailstore" - it's OK, but that internal component is still 
there. In the same way as the Directory semantics is always there, while 
LDAP is just a protocol that allows you to access that store, with its 
semantics - and there can be other ways to access the same store.

Even if you use some legacy design and your IMAP, POP, SMTP, etc. components 
all have their own code, so they use just the same file system (or a 
database) - LOGICALLY, there is still a "mailstore" - something that stores 
the messages and allows certain operations with them - and that semantics 
DOES NOT DEPEND on the protocol used to access that mailstore.

CommuniGate Pro (and, I'm sure some other servers) allow you to open any 
mailbox via POP3 using some special "username". For example, you can specify
"mailbox#username" and open that mailbox in your POP3 session. Make one more 
step - if you access "foreign mailbox" in IMAP using ~username/mailboxname 
"mailbox" name, then it would be logical (though not required, of course) to 
allow the POP server to access the same mailbox if you specify the 
"~username/mailboxname#youraccount" and "yourpassword". Definitely you need 
to have access rights for that ~username/mailboxname to open that mailbox. 
Most likely - the "r" right in the IMAP ACL terms. And to delete messages 
there - also some right. And the POP3 server must mark those messages as 
"read" (or \Seen) on RETR - if you have the "s" right. 

Does it have anything to do with the IMAP *protocol*? No. 

There is a much less exotic sample - WebMail. The *NATIVE* WebMail that 
works directly with the mailstore, not a "WebMail GUI" on top of IMAP or 
POP. It needs to deal with all those things - and it has nothing to do with 
IMAP.

> IMHO that's a good state of affairs. I'm sure there are arguments for
> adding more stuff, but doing that makes me think of RFC 1925.

There is already a draft for Server-side Rules (or, probably, it has already 
become an RFC?). If my Rule specifies that the message that meets this and 
that criteria should be stored in the ~secretary/ImportantNotes mailbox - 
what should be my rights for that mailbox? Should that standard refer to the 
IMAP ACL RFC? Why - it has nothing to do with IMAP *protocol*?

Message UIDs should be generated by those components that store messages in 
mailboxes. The UIDs must be numbers in the strict ascending order. Where is 
the standard that tells delivery agent developers to implement it that way? 
The same applies to the requirement to store the INTERNALDATE values there. 
Yes, it is mentioned in the IMAP standard, but why should Delivery Agent 
developers look into any IMAP standard? Result - the POP3 also has UIDs, but 
they are "completely different UIDs" - they may be non-numeric, and they may 
be non-ascending, so all POP3 clients implementing the "leave on server" 
options must remember all UIDs that they have "seen" in the mailbox (instead 
of remembering UIDValidity and the last UID or UIDNEXT in the IMAP terms).

You do not want the IMAP standard to talk about the details of the TCP 
implementation, right? And it would be very strange if the FTP RFC would 
refer to the IMAP RFC for the details of the TCP semantics, right? The TCP 
is the "backbone", it's some thing that many higher-level protocols use and 
it is documented separately. The fact that an IMAP client built into a cell 
phone may implement IMAP and TCP in one piece of code does not make a 
difference. The fact that many existing IMAP, POP3, SMTP servers implement 
certain mailstore semantics inside their protocol-specific code does not 
make that semantics "tied up" to a certain protocol or service. It should be 
documented separately.

  
> --Arnt

Sincerely,
Vladimir

To: [email-masked]
Subject: ACL2 backwards compatibility
From: Simon Josefsson <[email-masked]>
Date: Wed, 12 Jun 2002 20:59:38 +0200
Lines: 6
Sender: [email-masked]

Can a server support both ACL and ACL2?  The latest draft indicate
that ACL and ACL2 is incompatible.  How do the server know whether the
client is using ACL or ACL2?

Perhaps this is already taken care of in the document, if so I'm sorry
to have read it sloppily.

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
From: Simon Josefsson <[email-masked]>
Date: Wed, 12 Jun 2002 20:52:11 +0200
Lines: 10
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> I've noticed yesterday that ABNF for "rights" was defined as "astring",
> not just "quoted".
> Anybody objects to changing this to quoted, because I don't see that
> "rights" will ever contain control or 8bit characters.

Sounds fine.  I've always disliked having different ways of expressing
the same thing, making things simpler is a good idea.  Atom is perhaps
even better.

Date: Wed, 12 Jun 2002 11:23:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: New topic: Extensions to impove IMAP scalability
To: "Vladimir A. Butenko" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Without deprecating Vladimir's efforts, he is not the only one who is working
on "push" type technology for mailbox updates.

I'd rather not say too much about my efforts at this point since I only have a
toy implementation.  The basic idea is that it is a notification mechanism in
which a client (not necessarily an IMAP client) asks a notification server to
be delivered events on a certain object identifier, and event generators for
the particular object identifier spam the notification server with events.  Of
course, it's actually a lot more complicated than this.

It is not impossible to implement an IMAP extension that uses an interface
very much like Vladimir's (or even identical), if in the long run it is
determined to be desirable to have access to the mechanism via IMAP.

Date: Wed, 12 Jun 2002 20:28:07 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Vladimir A. Butenko" <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
Sender: [email-masked]

I have the impression that today, a "mailstore" is something that talks
IMAP, LMTP and often a few other protocols.

IMHO that's a good state of affairs. I'm sure there are arguments for
adding more stuff, but doing that makes me think of RFC 1925.

--Arnt

From: "Vladimir A. Butenko" <[email-masked]>
Subject: New topic: Extensions to impove IMAP scalability
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 10:24:38 -0700
Sender: [email-masked]

We are about to release the new version of CommuniGate Pro that will inlcude 
several extensions that have not been discussed anywhere: they will be used 
by our own client. But at least one of those extensions may be of some 
general interest, since we implemented it to improve the scalability.

We now deploy more and more systems (both single-server and clustered) in 
Universities and corporations where IMAP is the main access method (WebMail 
is great, Mark, do not forget that! - but IMAP is great, too :-).

The main problem with MANY IMAP clients is the number of IMAP connections 
they keep open. While it may be not the case with the non-GUI clients, GUI 
clients tend to keep an open connection for each mailbox the user opened. 
Thus, a 10,000 active users often open 100,000 connections to a server, and 
this is not good, because:
a) each connection require a socket on the server, and many systems "do not 
work very well" when they need to handle 100,000 open sockets. But we often 
meet a req to support 30,000 concurrent users - and 300,000 connections is 
definitely "too many".
b) in many server implementations each connection reequires a thread (at 
least, if not a process), and each thread needs a stack, and if 100K stacks 
are used, 10,000 connections would require 1GB of VRAM for stacks (not tha 
bad), but 100,000 connections would require 10GB of VRAM - and this makes 
the server life "difficult" - when deployed on a 32-bit system.

So, our goal was to make minimal additions to the IMAP protocol - additions 
that would make it possible to "keep in sync" with many mailboxes, while 
still using just one IMAP connection. There is no formal document for that, 
so I'm trying to provide informal description:

Commands:
   WATCH ON <mailboxname>
This command sets a "watcher" on the specified mailbox. ACL: must be the 
same as for the EXAMINE command, and for synching puposes, the command 
should be sent when the <mailboxname> mailbox is selected by this IMAP 
session.

   WATCH OFF <mailboxname>
This command removes the watcher from the specified mailbox. When the 
session ends, all watchers are removed automatically, so this command is 
useful mostly for mailbox removing/renaming operations on the servers that 
do not allow you to move/delete a mailbox if is being "opened" by anyone.

Responses.
  Whenever an untagged response can be returned, the following responses can 
appear:
   * WATCH <mailboxname> <flag fetch response>
   * WATCH <mailboxname> <expunge response>

Where the <flag fetch> and <expunge> responses are the same responses as 
used in the "normal" IMAP session. For example:

* WATCH Trash 10 EXPUNGE
* WATCH Trash 11 EXPUNGE
* WATCH Trash 12 EXPUNGE

If the current mailbox name (name specified in the "Select" command) is the 
same as the name in one of the WATCH commands, "WATCH" responses for that 
mailbox are not sent (to avoid duplicates, since they are sent as regular 
IMAP untagged reponses). If the names are different (but in reality they 
point to the same mailbox), the responses are sent.

It looks like this extension allows to design a client that can open only 
one IMAP connection to the server, but still "stay in synch" with several 
mailboxes. This should decrease the server load for large sites, and most of 
the implementations should only benefit: the client should use may "SELECT" 
commands to switch between mailboxes (instead of using many connections), 
but since the "WATCH" command would keep the mailbox in the "parsed" stage, 
the price for those additional "SELECTs" should be virtually zero.

If there is any interest in such an extension, we can try to create a formal 
draft.

Sincerely,
Vladimir

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 10:00:14 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 09:53:09 -0700 (PDT)
  Mark Crispin <[email-masked]> wrote:
> I have a great deal of sympathy for many of Vladimir's arguments, 
> particularly
> from an architectural point of view.  I have argued many of these things
> myself for many years.
> 
> >From a practical point of view, however, I don't think that any of these
> should delay ACL2.

Let's be realistic. Even if someone would agree to create such a "mailstore" 
standard, it would take at least 1-2 months to create the first draft. Then 
it will take at least 3-6 months to discuss it, since it definitely should 
agree (at least, in main points) with the current, popular implementations. 
So, if this standard is to appear, it will take at least 9 months (as 
usual). And if it appears, many standards has to be rewritten to remove the 
parts that would be included into the new standard. Rewriting the new ACL 
standard would be a very small part of that job. 

So - I do not see any reason to delay the ACL2 release either.

> Oh, and I don't "dislike WebMail".  After all, UW has a WebMail product of 
> its own (WebPine).  WebMail done right!  :-)

If it's done via IMAP, it's not WebMail :-)

Sincerely,
Vladimir

Date: Wed, 12 Jun 2002 09:53:09 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
To: "Vladimir A. Butenko" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

I have a great deal of sympathy for many of Vladimir's arguments, particularly
from an architectural point of view.  I have argued many of these things
myself for many years.

>From a practical point of view, however, I don't think that any of these
should delay ACL2.

Oh, and I don't "dislike WebMail".  After all, UW has a WebMail product of its
own (WebPine).  WebMail done right!  :-)

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
To: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 09:46:29 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 08:42:28 -0700 (PDT)
  Mark Crispin <[email-masked]> wrote:
> It should be obvious, but I support Alexey's proposal.
> 
> This will make it possible to implement both ACL and ACL2 in a 
> straighforward
> manner, while not leaving ACL2 hampered with warts from needless ACL
> compatibility.

I have just sent my comments on the new draft to Alexey, hopefully he will 
have time to remove the most foolish of my remarks and share it with the 
group. I strongly support this new, more mature ACL standard, but I'd like 
to bring up the issue that I have already mentioned in my previous letter to 
Alexey:

Most of those things have NOTHING to do with IMAP. Both the IMAP basic 
standard and some of its standard extensions are talking about 2 different 
things: about the "mailbox store" and its semantics (that has nothing to do 
with the IMAP as the protocol) and the IMAP itself - the protocol that 
provides access to that mailbox store and its functions, but should not care 
about many "behind the scene" details of the mailbox store functionality.

I do understand that it's a big work to do, but - IMHO - all of us will 
benefit from a new, additional set of standards, the "mailbox store" 
standards that will address many issues that originated in the first IMAP 
implementations, but have nothing to do with the protocol itself:
* concept of a mailbox
* concept of a mailbox heirarchy
* concept of message UIDs and mailbox UIDVALIDITY settings
* concept of message flags
* concept of mailbox operations ("append", "remove marked")
* concept of "foreign mailbox" access
* concept of mailbox ACLs
* concept of concurrent mailbox usage
* etc.

The IMAP standards can just ref to those standards, specifying only the 
syntax and IMAP-specific details, and not touching the "backend", mailstore 
specific details. This would allow us to rewrite the POP3 standard, too - 
since most modern implementations use the same mailstore for POP3 and IMAP, 
and there is no standard that specifies how these two interact (messages 
retrieved with POP3 RETR are marked with the \SEEN flag, while message 
retrieved with TOP are not marked, if POP3 QUIT does "EXPUNGE" or deletes 
only those messages that this POP3 session marked as "DELETED", how POP3 
should deal with messages that have been deleted in a concurrent session, 
etc.).

While SMTP standard won't gain much from such a "mailstore" standard, 
"delivery agents" may gain a lot, especially those that provide Automated 
Rules - those Rules can store message in different mailboxes in the the 
mailstore, add flags, etc.

In spite of the fact that I know how Mark dislikes WebMail :-), I have to 
mention it, too: WebMail has become a de-facto standard - and it must use 
the same mailstore as IMAP/POP/maildelivery agents use. W/o the mailstore 
standard, there can be no "standard" for WebMail, but if we require that 
WebMail must use the "standard-based" mailstore, interaction between WebMail 
and IMAP becomes a no-brainer, and it becomes obvious what this or that 
WebMail operation does and how it will be seen in an IMAP session opened to 
the same mailstore, and vice versa.

Not that I feel myself able to create such a standard, but I'd definitely 
support and help anyone who is brave enough to invest his/her time and 
talent into such a beast.

Sincerely,
Vladimir

Date: Wed, 12 Jun 2002 12:35:39 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

On Wed, 12 Jun 2002, Mark Crispin wrote:

> > Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but
> > why be different?  I could easily see implementations that make heavy use
> > of literals missing this special case.
>
> I agree that changing from astring to quoted may seem silly, but what about
> from astring to atom?

Restricting from astring to atom is fine by me (since the I agree that
the likelyhood of control characters is low).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 235 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ UBLS++++$ P+++$ L++(+++) E W+ N- o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-- b++ DI+++ G e h r y?
------END GEEK CODE BLOCK-----

Date: Wed, 12 Jun 2002 09:28:02 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
To: Rob Siemborski <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 12 Jun 2002 12:23:52 -0400 (EDT), Rob Siemborski wrote:
> Is there a compelling reason for this?

Simplicity.  Why allow in the syntax something that is meaningless?

> Unless I'm missing something,
> nothing in the IMAP base spec that can be a quoted string is disallowed
> from being a literal

You missed the internaldate argument to APPEND.

> Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but
> why be different?  I could easily see implementations that make heavy use
> of literals missing this special case.

I agree that changing from astring to quoted may seem silly, but what about
from astring to atom?

Date: Wed, 12 Jun 2002 09:25:20 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: ACL2: Proposal to change ABNF for "rights"
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 12 Jun 2002 06:58:42 -0600, Alexey Melnikov wrote:
> I've noticed yesterday that ABNF for "rights" was defined as "astring",
> not just "quoted".
> Anybody objects to changing this to quoted, because I don't see that
> "rights" will ever contain control or 8bit characters.

By that argument, rights should be an atom instead of quoted.  It is possible
to restrict from astring to atom, but not from quoted to atom, so if atom is
the right thing this has to be done now.

Date: Wed, 12 Jun 2002 12:23:52 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

On Wed, 12 Jun 2002, Alexey Melnikov wrote:

> Anybody objects to changing this to quoted, because I don't see that
> "rights" will ever contain control or 8bit characters.
> Effectively this will prohibit the following:
>
> C: A001 SETACL ~/Mail/saved smith {2}
> C: cp
>
> Comments?

Is there a compelling reason for this?  Unless I'm missing something,
nothing in the IMAP base spec that can be a quoted string is disallowed
from being a literal (e.g.  nothing is just a quoted, it's always atleast
a string).

Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but
why be different?  I could easily see implementations that make heavy use
of literals missing this special case.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 235 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ UBLS++++$ P+++$ L++(+++) E W+ N- o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-- b++ DI+++ G e h r y?
------END GEEK CODE BLOCK-----

Date: Wed, 12 Jun 2002 06:58:42 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

I've noticed yesterday that ABNF for "rights" was defined as "astring",
not just "quoted".
Anybody objects to changing this to quoted, because I don't see that
"rights" will ever contain control or 8bit characters.
Effectively this will prohibit the following:

C: A001 SETACL ~/Mail/saved smith {2}
C: cp

Comments?

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

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

Date: Wed, 12 Jun 2002 08:42:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
Sender: [email-masked]

It should be obvious, but I support Alexey's proposal.

This will make it possible to implement both ACL and ACL2 in a straighforward
manner, while not leaving ACL2 hampered with warts from needless ACL
compatibility.

Date: Wed, 12 Jun 2002 08:37:46 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: SETACL/DELETEACL questions (was Re: ACL2: set of rights associated with  READ-WRITE response code)
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Tue, 11 Jun 2002 15:21:49 -0600, Alexey Melnikov wrote:
> > What should a server do if it receives a SETACL which can not be performed
> > without doing a DELETEACL of some other identifier/rights pair?  [Think of
> > what would become a "chgrp" in UNIX]
> Server is allowed to do that. It must return new ACL in an unsolicited ACL
> response anyway.

How is it indicated to the client that this will happen *before* doing the
SETACL?

We're talking about client and end user surprise here.  Such surprises will
generate complaints.

Date: Wed, 12 Jun 2002 03:33:50 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: SETACL and tied-rights
Sender: [email-masked]

Mark Crispin wrote:

>    [...] If rights are tied in an
>    implementation, the implementation must be conservative in granting
>    rights in response to SETACL commands--unless all rights in a tied
>    set are specified, none of that set should be included in the ACL
>    entry for that identifier.  A client may discover the set of rights
>    which may be granted to a given identifier in the ACL for a given
>    mailbox by using the LISTRIGHTS command.
>
> This was in RFC 2086 as well.
>
> Do we really want these semantics?
>
> The effect of this is that it is mandatory to do a LISTRIGHTS prior to any
> SETACL (and multiple LISTRIGHTS prior to any REPLACEACL), since otherwise
> there is no way for a client to know how to grant a particular right to an
> identifier.
>
> Presumably, the reason for these semantics is so a client can review the
> impact of granting a particular right if it's tied to another.  But will
> any client actually do this?  Or will clients just blindly do the
> LISTRIGHTS to get the necessary incantation for SETACL?
>
> What I see is no savings of work for a client which cares about any side
> effects due to tied-rights, but a lot of extra work for clients which do
> not care.

I tend to agree. I would rather have a new response code LISTRIGHTS that is
returned in NO response to SETACL command.
Imagine that the client wants to grant "cp" rights to a user "smith". The
client instead of doing:

               C: A001 LISTRIGHTS ~/Mail/saved smith
               S: * LISTRIGHTS ~/Mail/saved smith la r swi cdext
               S: A001 OK Listrights completed
               C: A002 SETACL ~/Mail/saved smith cdextp
               S: A002 OK Setacl complete

will do the following (this assumes that the server doesn't want to grant a
right unless all tied rights are specified by the client):

               C: A001 SETACL ~/Mail/saved smith cp
               S: A001 NO [LISTRIGHTS la r swi cdext] No some rights are tied,
specify both
               C: A002 SETACL ~/Mail/saved smith cdextp
               S: A002 OK Setacl complete
               C: A002 LISTRIGHTS ~/Mail/saved smith

and if the server sets all tied rights automatically if at least one of them
is specified (not recommended by the document but still possible):

               C: A001 SETACL ~/Mail/saved smith cp
               S: * ACL ~/Mail/saved smith cdextp
               S: A001 OK Setacl complete

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

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

Date: Wed, 12 Jun 2002 02:48:21 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
CC: Mark Crispin <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
Subject: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
Sender: [email-masked]

Mark Crispin wrote:

> Alexey sent me a copy of his latest group.  This document has some truly
> amazing progress, and Alexey deserves to be congratulated.
>
> A suggestion, and some questions:
>
> The $ stuff is getting complicated.  How about this instead:
>
> Eliminate $ entirely, and define "identifier" as one of:
>         anyone
>         authuser
>         owner
>         administrators
>         user=<xxx>
>         group=<xxx>
> All other identifier names are reserved for future definition in an
> extension or revision to the ACL2 specification.

As Larry pointed out, this will break existing ACL implementations that treat
these identifiers differently (probably all of them).
However we can achieve this if we change syntax of ACL2 commands. Personally I
am reluctant to change syntax drastically, I would very match like to keep
existing parser as is. However, in Minneapolis we agreed to do another change:
support multiple mailboxes in an ACL command (allow for mailboxes with
wildcards or even several mailboxes). [Please, speak up now if you don't agree
with this!!!] So, I need to tweak the syntax for ACL2 commands anyway in order
to achieve this.
So, I propose:

1). We change syntax of ACL commands (and possibly responses) a little bit:

In all ACL commands mailbox is replaced with mailbox_list that is enclosed in
"(" and ")". This will allow to unambiguously distinguish between ACL and
ACL2. And this is a small change in an ACL parser, IMHO.

   acl_data        = "ACL" SPACE mailbox_list *(SPACE identifier SPACE rights)

   deleteacl       = "DELETEACL" SPACE mailbox_list SPACE identifier

   getacl          = "GETACL" SPACE mailbox_list

   listrights      = "LISTRIGHTS" SPACE mailbox_list SPACE identifier

   replaceacl      = "REPLACEACL" SPACE mailbox_list *(SPACE identifier SPACE
rights)

   setacl          = "SETACL" SPACE mailbox_list SPACE identifier SPACE
mod_rights

   mailbox_list = "(" 1*mailbox ")"
                         ;; mailbox may contain pattern matching characters *
and %

ACL and LISTRIGHTS responses must be replaced with ACL2 and LISTRIGHTS2:

   acl_data        = "ACL2" SPACE mailbox *(SPACE identifier SPACE rights)

   listrights_data = "LISTRIGHTS2" SPACE mailbox SPACE identifier
                           SPACE rights *(SPACE rights)

These responses have exactly the same syntax as ACL and LISTRIGTHS, but
"identifier" here has ACL2 syntax as proposed by Mark.

2). Go with Mark's proposal

In order to do that, I want to hear from people who've implemented ACL and
willing to implement ACL that they agree to go along.

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

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

Date: Tue, 11 Jun 2002 15:21:49 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: SETACL/DELETEACL questions (was Re: ACL2: set of rights associated with  READ-WRITE response code)
Sender: [email-masked]

Mark Crispin wrote:

> What should a server do if it receives a SETACL which can not be performed
> without doing a DELETEACL of some other identifier/rights pair?  [Think of
> what would become a "chgrp" in UNIX]

Server is allowed to do that. It must return new ACL in an unsolicited ACL
response anyway.

> What should a server do if it receives a DELETEACL but the identifier can
> not be deleted? Is it alright to treat it as a SETACL with server-defined

> default rights?

The server can either fail with NO (for example, in our implementation we
don't allow to delete the last ACL entry on a mailbox) response or do as you
describe (i.e. modify some other ACL(s) as well and return OK).

> In particular, on UNIX I would probably treat a DELETEACL
> of $anyone to mean "set $anyone to empty rights", of $group=<xxx> to mean
> "set $group=<xxx> to same as $anyone", and of $owner to "all rights of
> $anyone and $group=<xx> plus a".  Is this alright?

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

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

Date: Tue, 11 Jun 2002 13:37:42 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: SETACL and tied-rights
Organization: Networks & Distributed Computing
Sender: [email-masked]

   [...] If rights are tied in an
   implementation, the implementation must be conservative in granting
   rights in response to SETACL commands--unless all rights in a tied
   set are specified, none of that set should be included in the ACL
   entry for that identifier.  A client may discover the set of rights
   which may be granted to a given identifier in the ACL for a given
   mailbox by using the LISTRIGHTS command.

This was in RFC 2086 as well.

Do we really want these semantics?

The effect of this is that it is mandatory to do a LISTRIGHTS prior to any
SETACL (and multiple LISTRIGHTS prior to any REPLACEACL), since otherwise
there is no way for a client to know how to grant a particular right to an
identifier.

Presumably, the reason for these semantics is so a client can review the
impact of granting a particular right if it's tied to another.  But will
any client actually do this?  Or will clients just blindly do the
LISTRIGHTS to get the necessary incantation for SETACL?

What I see is no savings of work for a client which cares about any side
effects due to tied-rights, but a lot of extra work for clients which do
not care.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-04.txt
Date: Mon, 10 Jun 2002 07:18:49 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-acl-04.txt
	Pages		: 9
	Date		: 06-Jun-02
	
The ACL extension of the Internet Message Access Protocol [IMAP4]
permits access control lists to be manipulated through the IMAP
protocol.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-acl-04.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-acl-04.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-acl-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Sat, 8 Jun 2002 10:45:43 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
To: Lawrence Greenfield <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Sat, 8 Jun 2002 13:43:44 -0400, Lawrence Greenfield wrote:
> Do we know of any existing clients that use READ-ONLY/READ-WRITE for
> anything?  What do they use them for?  What's the benefit of sending
> this back to the client?

Pine checks the READ-ONLY flag in quite a few places.

The best way to think about READ-ONLY is that it means you can't do anything
to the mailbox that someone else would see.  You can, however, alter any flags
listed as PERMANENTFLAGS.

I think matching that to the i and e bits sounds right, although the swt bits
may affect things if they are PERMANENTFLAGS.

By the way, the definition of the w right should be called "write flags"
instead of "write".  It's too late to change it now, but the i right should
really be the w right, and the current w right should be something like f.

Date: Sat, 8 Jun 2002 13:43:44 -0400
From: Lawrence Greenfield <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>, Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

   Date: Sat, 08 Jun 2002 13:40:15 -0400
   From: Cyrus Daboo <[email-masked]>
[...]
   OK, this implies then that READ-ONLY should be returned if both the 'i' and 
   'e' bits are off, irrespective of the 's', 'w' and 't' bits which only 
   control flag state. 'i' and 'e' actually control the content of the 
   mailbox. So how about this:

       The server MUST include a READ-ONLY prefix in the tagged OK response to
       a SELECT command if both the 'i' and 'e' ACL rights are off for the
       current user. The server SHOULD include a READ-WRITE prefix in the
       tagged OK response if either the 'i' or 'e' ACL rights is on for the
       current user.

   This fits in with the base-spec requirement of SHOULD for READ-WRITE and 
   MUST for READ-ONLY.

Do we know of any existing clients that use READ-ONLY/READ-WRITE for
anything?  What do they use them for?  What's the benefit of sending
this back to the client?

Larry

Date: Sat, 08 Jun 2002 13:40:15 -0400
From: Cyrus Daboo <[email-masked]>
To: Lawrence Greenfield <[email-masked]>, Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

Hi,

--On Saturday, June 8, 2002 1:26 PM -0400 Lawrence Greenfield 
<[email-masked]> wrote:

| This is fine with me, though this doesn't appear to totally agree with
| the text in the IMAP draft (section 6.3.1):
|
|       Read-only access through SELECT differs from the EXAMINE command
|       in that certain read-only mailboxes MAY permit the change of
|       permanent state on a per-user (as opposed to global) basis.
|       Netnews messages marked in a server-based .newsrc file are an
|       example of such per-user permanent state that can be modified
|       with read-only mailboxes.
|
| Another possibility is for ACL to recommend that servers implementing
| ACL just not return either READ-ONLY or READ-WRITE in response to a
| SELECT.

OK, this implies then that READ-ONLY should be returned if both the 'i' and 
'e' bits are off, irrespective of the 's', 'w' and 't' bits which only 
control flag state. 'i' and 'e' actually control the content of the 
mailbox. So how about this:

    The server MUST include a READ-ONLY prefix in the tagged OK response to
    a SELECT command if both the 'i' and 'e' ACL rights are off for the
    current user. The server SHOULD include a READ-WRITE prefix in the
    tagged OK response if either the 'i' or 'e' ACL rights is on for the
    current user.

This fits in with the base-spec requirement of SHOULD for READ-WRITE and 
MUST for READ-ONLY.

-- 
Cyrus Daboo

Date: Sat, 8 Jun 2002 13:26:26 -0400
From: Lawrence Greenfield <[email-masked]>
To: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

   Date: Sat, 08 Jun 2002 13:16:47 -0400
   From: Cyrus Daboo <[email-masked]>
[...]
   Therefore I argue that READ-WRITE status should appear whenever any ACL bit 
   that controls a change in the masilbox content is on. i.e.

   read_write = 's' || 'w' || 'i' || 't' || 'e';

   If all of those are off then the mailbox is READ-ONLY.

This is fine with me, though this doesn't appear to totally agree with
the text in the IMAP draft (section 6.3.1):

      Read-only access through SELECT differs from the EXAMINE command
      in that certain read-only mailboxes MAY permit the change of
      permanent state on a per-user (as opposed to global) basis.
      Netnews messages marked in a server-based .newsrc file are an
      example of such per-user permanent state that can be modified
      with read-only mailboxes.

Another possibility is for ACL to recommend that servers implementing
ACL just not return either READ-ONLY or READ-WRITE in response to a
SELECT.

Larry

Date: Sat, 08 Jun 2002 13:16:47 -0400
From: Cyrus Daboo <[email-masked]>
To: Lawrence Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

Hi,

--On Friday, June 7, 2002 2:50 PM -0400 Lawrence Greenfield 
<[email-masked]> wrote:

| What Alexey is referring to here is a fairly minor problem, the
| [READ-ONLY] and [READ-WRITE] status responses.  These responses are
| basically useless since they don't convey any information to the
| client.  Does "READ-WRITE" mean "able to modify everything"?  "able
| to modify at least one thing"?  ACL gives the client a much better
| notion of what operations are likely to succeed.
|
| ACL2 should just recommend one interpretation and tie READ-WRITE to a
| particular right.  It's not a big deal.

You need to consider READ-WRITE/READ-ONLY in the context of non-ACL aware 
clients. A non-ACL client will likely use that indicator to determine what 
commands to enable in its UI when that mailbox is open. e.g. for a 
READ-ONLY mailbox the client will disable flag changing commands, expunge, 
prevent drag and drop of messages into the mailbox pane etc.

The problem arises when some ACL bits are on and others are not. For 
example if 'w' is off, but 'i' is on, and 'w' controls the R-W/R-O status, 
then the mailbox will appear as READ-ONLY. Non-ACL clients might then 
disable the ability to copy into or append to that mailbox, even though 
that is allowed by the ACL 'i' bit. This is bad as it prevents the user 
from being able to do a valid operation. If the status were reported as 
READ-WRITE, then copy/append would be enabled for the user and would work 
fine. In this case the 'negative' aspect is that the flag change commands 
would be enabled but fail with a NO response when the user attempts it. I 
regard this as the lesser of two evils in that valid commands can at least 
be executed and there is a reasonable failure mode for non-valid commands.

Therefore I argue that READ-WRITE status should appear whenever any ACL bit 
that controls a change in the masilbox content is on. i.e.

read_write = 's' || 'w' || 'i' || 't' || 'e';

If all of those are off then the mailbox is READ-ONLY.

-- 
Cyrus Daboo

Date: Fri, 7 Jun 2002 13:32:10 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Fri, 7 Jun 2002, Lawrence Greenfield wrote:
> Such a change would be completely incompatible with existing ACL
> implementations, which already have widespread adaption and good
> interoperability.

We are talking about ACL2, not ACL.

I can assure you that if I implemented ACL in UW imapd (and c-client/Pine)
in the way that made the most sense for us, the result would be completely
non-interoperable.  It would break existing implementations which expect
the Cyrus type of interpretation, and create an incredible mess.

It would also be completely compliant with RFC 2086.

Fortunately, I am not the sort of person who deliberately does harmful
things to break a specification.  I have put off implementing ACL in UW
imapd in the hope of having a fixed specification.

The whole point of ACL2 is to create an interoperable specification that
we can all live with, and give it a different name so that we won't have
interoperability problems with ACL.

It may be necessary to have a switch (or different commands) so a client
of a server that supports both ACL and ACL2 can say "I want ACL2
semantics."  That's fine.

But, please!!, let's get it right this time.  Or we will end up with
multiple compliant non-interoperable implementations.

-- Mark --

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

Date: Fri, 7 Jun 2002 14:55:11 -0400
From: Lawrence Greenfield <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

   Date: Thu, 6 Jun 2002 13:24:42 -0700 (Pacific Daylight Time)
   From: Mark Crispin <[email-masked]>

   Eliminate $ entirely, and define "identifier" as one of:
	   anyone
	   authuser
	   owner
	   administrators
	   user=<xxx>
	   group=<xxx>
   All other identifier names are reserved for future definition in an
   extension or revision to the ACL2 specification.

Such a change would be completely incompatible with existing ACL
implementations, which already have widespread adaption and good
interoperability.

Larry

Date: Fri, 7 Jun 2002 14:50:32 -0400
From: Lawrence Greenfield <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

   Date: Thu, 6 Jun 2002 05:53:18 -0700 (PDT)
   From: Mark Crispin <[email-masked]>

   On Thu, 06 Jun 2002 03:46:14 -0600, Alexey Melnikov wrote:
   > Cyrus, Communigate and CDC IntraStore are completely different
   > implementations of the ACL RFC and they all behave differently!

   Yes, and if UW imapd implemented RFC 2086 there would have been a fourth
   completely different implementation that would have been even more different
   than the other three.

What Alexey is referring to here is a fairly minor problem, the
[READ-ONLY] and [READ-WRITE] status responses.  These responses are
basically useless since they don't convey any information to the
client.  Does "READ-WRITE" mean "able to modify everything"?  "able
to modify at least one thing"?  ACL gives the client a much better
notion of what operations are likely to succeed.

ACL2 should just recommend one interpretation and tie READ-WRITE to a
particular right.  It's not a big deal.

Larry

Date: Fri, 7 Jun 2002 10:52:04 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
To: Steve Hole <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Fri, 7 Jun 2002 11:47:16 -0700, Steve Hole wrote:
> > Eliminate $ entirely, and define "identifier" as one of:
> > 	anyone
> > 	authuser
> > 	owner
> > 	administrators
> > 	user=<xxx>
> > 	group=<xxx>
> > All other identifier names are reserved for future definition in an
> > extension or revision to the ACL2 specification.
> This is precisely what we arrived at in the "authid" acap dataset class as
> well.   As I wrote authid, I think it's a good idea.

Cool!  We're starting to get convergence!

This would indeed remove many of the problems that I have with RFC 2086.  I
would be happy to withdraw my earlier proposal (in Alexey's draft) in favor of
this one.

From: Steve Hole <[email-masked]>
Date: Fri, 7 Jun 2002 11:47:16 -0700
To: Mark Crispin <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Thu, 6 Jun 2002 13:24:42 -0700 (Pacific Daylight Time) Mark Crispin 
<[email-masked]> wrote:

> Eliminate $ entirely, and define "identifier" as one of:
> 	anyone
> 	authuser
> 	owner
> 	administrators
> 	user=<xxx>
> 	group=<xxx>
> All other identifier names are reserved for future definition in an
> extension or revision to the ACL2 specification.

This is precisely what we arrived at in the "authid" acap dataset class as 
well.   As I wrote authid, I think it's a good idea.

Cheers.
---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Thu, 6 Jun 2002 13:24:42 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Organization: Networks & Distributed Computing
Sender: [email-masked]

Alexey sent me a copy of his latest group.  This document has some truly
amazing progress, and Alexey deserves to be congratulated.

A suggestion, and some questions:

The $ stuff is getting complicated.  How about this instead:

Eliminate $ entirely, and define "identifier" as one of:
	anyone
	authuser
	owner
	administrators
	user=<xxx>
	group=<xxx>
All other identifier names are reserved for future definition in an
extension or revision to the ACL2 specification.

What should a server do if it receives a SETACL which can not be performed
without doing a DELETEACL of some other identifier/rights pair?  [Think of
what would become a "chgrp" in UNIX]

What should a server do if it receives a DELETEACL but the identifier can
not be deleted?  Is it alright to treat it as a SETACL with server-defined
default rights?  In particular, on UNIX I would probably treat a DELETEACL
of $anyone to mean "set $anyone to empty rights", of $group=<xxx> to mean
"set $group=<xxx> to same as $anyone", and of $owner to "all rights of
$anyone and $group=<xx> plus a".  Is this alright?

-- Mark --

Date: Thu, 6 Jun 2002 05:53:18 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: ACL2: set of rights associated with READ-WRITE response code
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Thu, 06 Jun 2002 03:46:14 -0600, Alexey Melnikov wrote:
> Cyrus, Communigate and CDC IntraStore are completely different
> implementations of the ACL RFC and they all behave differently!

Yes, and if UW imapd implemented RFC 2086 there would have been a fourth
completely different implementation that would have been even more different
than the other three.

I'm worried that we've still not solved the fundamental problems in RFC 2086.

Date: Thu, 06 Jun 2002 03:46:14 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

I did a bit of research and found out the following:

Cyrus and MessagingDirect server: if either "w" or "t" are allowed for
the current user,
  server reports READ-WRITE
Communigate: when the user has "s" right.
CDC IntraStore: when the user has "w" right.

Cyrus, Communigate and CDC IntraStore are completely different
implementations of the ACL RFC and they all behave differently!

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

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

Date: Thu, 06 Jun 2002 03:45:55 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: ACL2: rights required for different IMAP command
Sender: [email-masked]

As you will see in the new revision, I've added a new section that
describes in details which rights should be checked to implement
different IMAP commands, which rights are mandatory and which are
optional.
Here is what left unresolved:

    SUBSCRIBE - "l" right is required only if the server checks for
mailbox existence
           when performing SUBSCRIBE.

Allow if the user has "r" right?

    GETACL - "a" right on the mailbox.

     CDC IntraStore: "a".
     CMU: "r", "a", admin or owner.
     MD: "r" or "a" or owner.

No consensus if "r" should be allowed. John would prefer not to use "r",
but he is fine if somebody insists on using it. The main argument
against allowing "r" for GETACL is that in this case GETACL can
possibly disclose some identifiers existing on the mail system to an
authenticated user with read access.
On the other hand "r" is used for a mailbox metadata and seems
appropriate.

    LISTRIGHTS - Same as GETACL? or just "r"?

    GETQUOTA - no rights required
CMU server checks if the user belongs to administrators, I don't know
why

    SETQUOTA - "a" right

Some implementations allows to set quota when the user has "r" right as
well. Should we allow that?

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

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

Date: Thu, 06 Jun 2002 03:43:05 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: ACL2: escape character for special identifiers and groups.
Sender: [email-masked]

This is a list of comments on the issue I've got during IMAPEXT lunch at
Minneapolis IETF (in no particular order, I hope it is not too intricate
to understand):

Could use "$$" prefix for user names beginning "$" and "$-" for user
names beginning from "-".

Escape or reject?
   No group starting with "$-" or "$$" (John).

   Use "\" as escape character for leading "$" or "-"?

   Alternatively we can change syntax of all ACL commands (Chris)

   Chris objects to escape mechanism, he prefers to reject.

We couldn't reach any consensus on the matter and I was asked to post a
question to the mailing list if any existing server ACL implementation
is using "$" as a leading character in usernames.
The only thing was clear that the participants were reluctant to change
syntax of ACL commands, as they would rather reuse existing IMAP ACL
parsers.

As Jutta pointed out in her recent post we can use "/" instead of "$".
This might work, as probably none of the existing ACL implementations
will accept usernames with "/" character.

Alexey

Date: Thu, 06 Jun 2002 03:37:46 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: New revision of ACL2
Sender: [email-masked]

I've submitted a new revision of ACL2 to the draft editor. There are
four major groups of open issues left in the document. These issues can
be shortly described as follows:
1). escape character for special identifiers and groups.
2). rights required for different IMAP commands.
3). set of rights associated with READ-WRITE response code.
4). changing ACLs for a list of mailboxes.

I will post a separate message for each group of issues.

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

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

From: "Barry Leiba" <[email-masked]>
To: "IMAP extensions Mailing List" <[email-masked]>
Subject: Re: Stalled?
Date: Mon, 3 Jun 2002 10:42:41 -0400
Sender: [email-masked]

I will get a List Extensions update out within the next couple of days.

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

Date: Fri, 28 Jun 2002 05:05:01 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: rights required for different IMAP command
Sender: [email-masked]

I haven't heard any public comments on this topic! (See some comments below)

Alexey Melnikov wrote:

> As you will see in the new revision, I've added a new section that
> describes in details which rights should be checked to implement
> different IMAP commands, which rights are mandatory and which are
> optional.
> Here is what left unresolved:
>
>     SUBSCRIBE - "l" right is required only if the server checks for
> mailbox existence
>            when performing SUBSCRIBE.
>
> Allow if the user has "r" right?
>
>     GETACL - "a" right on the mailbox.
>
>      CDC IntraStore: "a".
>      CMU: "r", "a", admin or owner.
>      MD: "r" or "a" or owner.
>
> No consensus if "r" should be allowed. John would prefer not to use "r",
> but he is fine if somebody insists on using it. The main argument
> against allowing "r" for GETACL is that in this case GETACL can
> possibly disclose some identifiers existing on the mail system to an
> authenticated user with read access.
> On the other hand "r" is used for a mailbox metadata and seems
> appropriate.
>
>     LISTRIGHTS - Same as GETACL? or just "r"?
>
>     GETQUOTA - no rights required
> CMU server checks if the user belongs to administrators, I don't know
> why
>
>     SETQUOTA - "a" right

> Some implementations allows to set quota when the user has "r" right as
> well. Should we allow that?

As a result of my private exchange with Vladimir, I am going to remove the
requirement to use "a" for SETQUOTA, because it operates on a quota root,
that is not necessary a mailbox. Instead this will be "implementation
dependent".

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

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-thread-11.txt
Date: Tue, 25 Jun 2002 07:03:39 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-thread-11.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-thread-11.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-thread-11.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-sort-10.txt
Date: Tue, 25 Jun 2002 07:03:35 -0400
Sender: [email-masked]

--NextPart

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

	Title		: INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-10.txt
	Pages		: 10
	Date		: 24-Jun-02
	
This document describes an experimental server-based sorting
extension to the IMAP4rev1 protocol, as implemented by the University
of Washington's IMAP toolkit.  This extension provides substantial
performance improvements for IMAP clients which offer sorted views.
A server which supports this extension indicates this with a
capability name of 'SORT'.  Client implementations SHOULD accept any
capability name which begins with 'SORT' as indicating support for
the extension described in this document.  This provides for future
upwards-compatible extensions.
At the time of this document was written, the IMAP Extensions Working
Group (IETF-IMAPEXT) was considering upwards-compatible additions to
the SORT extension described in this document, tenatively called the
SORT2 extension.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-sort-10.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-sort-10.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-sort-10.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-thread-10.txt
Date: Mon, 24 Jun 2002 07:48:28 -0400
Sender: [email-masked]

--NextPart

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

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

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-thread-10.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-thread-10.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-thread-10.txt

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

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

--OtherAccess--

--NextPart--

To: IMAP Interest Groups: ;
Subject: IMAP Channel Draft version 2 released
Organization: ACI Worldwide - Advanced Technology Group
Date: Tue, 18 Jun 2002 16:28:11 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

I've pushed version 02 of the Channel draft to the ID editor. Early
access can be had at:

        http://atg.aciworldwide.com/draft-nerenberg-imap-channel-02.txt

Diffs from version 01:

  Changed <channel-set> to use <section-spec> instead of <section-text>.
  This allows retrieval of headers and MIME structure.
  
  <channel-data> returns a <section-spec>, not <nz-number> (to match
  <channel> syntax).
  
  Add missing SP tokens to grammar.
  
  Grammar fix to allow foo: as a valid URI in a request.
  
  Add UID CHANNEL.
  
  Clarify response when client issues a command with an unsupported scheme.
  
  Add section on command sequencing.
  
  Note arbitrary ordering of untagged responses.
  
  Replace URI-reference with absoluteURI. The IMAP server can't maintain
  the state required to deal with relative URIs. This also solves an
  ambiguity between parsing "NIL" as <nil> or as a relative URI.

--lyndon

                            _
        12 + 144 + 20 + 3(\/4)                2
        ----------------------  +  5(11)  =  9  +  0
                  7
A dozen, a gross and a score,
Plus three times the square root of four,
        Divided by seven,
        Plus five times eleven,
Equals nine squared plus zero, no more!

Date: Fri, 14 Jun 2002 07:40:26 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lyndon Nerenberg <[email-masked]>
CC: Rob Siemborski <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

Lyndon Nerenberg wrote:

> > My experience with writing parsers in non-blocking or asynchronous IO model
> > (i.e. when read from the socket may return that literal was not completely
> > received by TCP stack) tells that it is a pain in the ass to write a parser for
> > any command that uses literals. Why? Because you have to save state if there is
> > not enough data.
>
> This argument doesn't hold. You can get a short read anywhere, not
> just inside a literal.

Well, I guess I should have explained our architecture in the first place.
In our IMAP server we have two levels of parsing. The low level parser always
guaranties that the server has a full text line till CRLF before it hands over the
line to the high level parser. This is based on one very good property of IMAP
protocol: any protocol line is terminated with CRLF, whether it is CRLF at the end of
the command, after "}" in literals or in the middle of a RFC822 message. Thus, in our
architecture low level parser always guaranties that we never get a short read while
parsing a quoted string. That is not true for literals. So, after this clarification,
my argument still holds. (I know of no other sane way of parsing IMAP with non
blocking IO that doesn't use something like our low level parser).

> And I would argue that literals are the
> *easiest* string form to deal with: you already know how much data to
> read therefore you don't need to keep any state on the data stream
> itself, just a counter that you decrement as you read in the bytes.

Not just this state. Counter is the least of the problems. I was talking about the
current state of the command parser.
For example, when parsing arguments of a SEARCH (or a FETCH) command, the parser can
be several levels down parsing nested SEARCH criteria when it encounters a literal.
Now there are couple choices how to deal with this:
 1). throw away already constructed search state and reparse SEARCH command as soon
as the literal is fully received
or
 2). save the current search state and switch to literal receiving mode.

Both cases will require saving some non-trivial state, but 1) , IMHO, is inefficient,
especially if there are several literals.

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

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

Date: Fri, 14 Jun 2002 04:53:01 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights    associated with READ-WRITE response code)
Sender: [email-masked]

Tim Showalter wrote:

> > How about a single ACL command with subcommands?
>
> Not a bad idea; better than SETACL2.

That is fine with me. What about the syntax after ACL <subcommand>? Are
people happy with my proposal.

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

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

Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights   associated with READ-WRITE response code)
From: Tim Showalter <[email-masked]>
To: [email-masked]
Date: 13 Jun 2002 14:15:39 -0600
Sender: [email-masked]

> How about a single ACL command with subcommands?

Not a bad idea; better than SETACL2.

Tim

Date: Thu, 13 Jun 2002 12:40:01 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights   associated with READ-WRITE response code)
To: Tim Showalter <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 13 Jun 2002 13:04:27 -0600, Tim Showalter wrote:
> I like the proposed identifier format; it's cleaner than what we had
> before.  If I were implementing an ACL server from scratch I would want
> to use something like that.

Great!

> But there's running ACL code out there that doesn't work that way.  In
> order for a sane upgrade path for Cyrus (and its progeny) the ACL2
> commands will have to be supported seperately; in order to make these
> work in some sane way, we'll need some seperate syntax.

In case it was unclear; I have no objection whatsoever to a different set of
commands for ACL2.

I always felt that instead of the current GETACL, LISTRIGHTS, and MYRIGHTS
commands, we should use an extended form of LIST.  But LIST extensions seems
to have fallen by the wayside, sigh.

How about a single ACL command with subcommands?

SETACL 		=> ACL STORE
DELETEACL	=> ACL DELETE
REPLACEACL	=> ACL SET
GETACL		=> ACL GET
LISTRIGHTS	=> ACL LIST
MYRIGHTS	=> ACL FETCH

ACL FETCH is slightly different than MYRIGHTS in that it takes an identifier
as an argument and returns the rights for that identifier (?? is this
desirable??).

Or perhaps there could be an ACL CHECK that, given an identifier and a set of
right, returns whether or not that identifier has those rights.  I suspect
that ACL CHECK may be more useful.

Date: Thu, 13 Jun 2002 11:21:24 -0700
From: Lawrence Greenfield <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Mark Crispin <[email-masked]>, Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

--On Thursday, June 13, 2002 5:20 AM -0600 Alexey Melnikov 
<[email-masked]> wrote:

> Lawrence Greenfield wrote:
>
>> Another possibility is for ACL to recommend that servers implementing
>> ACL just not return either READ-ONLY or READ-WRITE in response to a
>> SELECT.
>
> I think this breaks compliance with RFC 2060.

No, the RFC merely says "SHOULD prefix the text" with "[READ-WRITE]".

So it's clearly legal to not return either READ-ONLY or READ-WRITE.

So my proposal is that EXAMINE must return "[READ-ONLY]".
SELECT must not return "[READ-WRITE]"; may return "[READ-ONLY]" if all 
rights are off.

Larry

Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights   associated with READ-WRITE response code)
From: Tim Showalter <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Date: 13 Jun 2002 13:04:27 -0600
Sender: [email-masked]

On Thu, 2002-06-13 at 04:54, Alexey Melnikov wrote:
> 
> Lawrence Greenfield wrote:
> 
> > If you feel the need to deprecate the old ACL commands, can we just
> > name them something else?
> 
> Does it really matter? Syntax is almost identical and the difference can
> be codified with the couple if statements.

We *will* confuse people, almost immediately.  Certainly no one here, as
we read the specs; but there are a lot of people that don't, and there
are a lot of people that like to leave mandatory () off of lists.

I like the proposed identifier format; it's cleaner than what we had
before.  If I were implementing an ACL server from scratch I would want
to use something like that.

But there's running ACL code out there that doesn't work that way.  In
order for a sane upgrade path for Cyrus (and its progeny) the ACL2
commands will have to be supported seperately; in order to make these
work in some sane way, we'll need some seperate syntax.

> >  I don't see the need to be so cute about
> > our upgrades when we have an infinite number of bits that will make it
> > blatantly obvious what versions we're using.

I agree with this.

Tim

Organization: ACI Worldwide - Advanced Technology Group
To: Alexey Melnikov <[email-masked]>
cc: Rob Siemborski <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights" 
Date: Thu, 13 Jun 2002 11:37:39 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> My experience with writing parsers in non-blocking or asynchronous IO model
> (i.e. when read from the socket may return that literal was not completely
> received by TCP stack) tells that it is a pain in the ass to write a parser for
> any command that uses literals. Why? Because you have to save state if there is
> not enough data.

This argument doesn't hold. You can get a short read anywhere, not
just inside a literal. And I would argue that literals are the
*easiest* string form to deal with: you already know how much data to
read therefore you don't need to keep any state on the data stream
itself, just a counter that you decrement as you read in the bytes.

--lyndon

I think 3B2 code deserves its own place in hell.  Poring over the ESS#5 code,
someone found that there were lots of strcmp(p, "f(") == 0 checks (I may have
gotten the exact string wrong but it's close).  It took us a while to figure
out why.  Apparently, location 0 on the 3b had the 3 bytes 'f' '(' '\0',
someone noticed that when programs blew up they were pointing to "f(", and
the worlds most amazing kludge for detecting nil pointers was born.
                        -- Dave Presotto

Date: Thu, 13 Jun 2002 10:43:30 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights associated with READ-WRITE response code)
Sender: [email-masked]

Hi,

--On  Mark Crispin <[email-masked]> wrote:

| I could understand you making a distinction between web mail programs that
| only do local mail, and web mail programs that only do IMAP.  But we have
| at least one example (WebPine) of a program that (at least in theory) can
| do both, and I doubt that WebPine is the only (or even the first) such
| program.

There are a number of webmail solutions that use PHP scripting on the 
webserver. In most cases they will use the IMAP implementation in PHP which 
is c-client based, so all of those fall into the same category - they can 
do both native mailstore access and IMAP mailstore access if desired.

-- 
Cyrus Daboo

Date: Thu, 13 Jun 2002 08:10:05 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: Lawrence Greenfield <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of   rightsassociated with READ-WRITE response code)
Sender: [email-masked]

Mark Crispin wrote:

> On Thu, 13 Jun 2002 04:59:25 -0600, Alexey Melnikov wrote:
> > Also as Vladimir pointed out in his private email to me, ACL2 implementation
> > can treat <identifier> as user=<identifier>, if the implementation prohibits
> > the creation of users with special names or names with "=".
>
> What does this mean?
>
> Would an identifier such as xxx be canonicalized to user=xxx form?

Yes, unless it is one of the "specials".

> If not, how is a client to know what xxx means?

If an identifier is not allowed to have "=", then each identifier without "=" in
it is automatically treated equal to user=xxx form.
If an identifier contains "=", it must be either "user=yyy" or "group=zzz",
otherwise it is illegal.

> Also, wouldn't this conflict with
> future assignment of special identifiers?

Of course it will. But the server is not required to implement a future revision.

I am not saying that this is the perfect solution (maybe not even recommended).

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

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

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights   associated with READ-WRITE response code)
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Thu, 13 Jun 2002 06:50:23 -0700
Sender: [email-masked]

On Thu, 13 Jun 2002 06:21:32 -0700 (PDT)
  Mark Crispin <[email-masked]> wrote:
> On Thu, 13 Jun 2002 06:08:37 -0700, Vladimir A. Butenko wrote:
> > I have seen a small util that implements POP3 via an IMAP server. Should 
> >we
> > ALWAYS think about POP3 server as "a gateway from POP3 protocol to an 
> >IMAP
> > server"? I hope not. Please note that not only CGatePro WebMail, but many
> > other products implement WebMail "natively" - i.e. as yet another service
> > working with the mailstore, alongside POP3 and IMAP services.
> 
> That distinction does not always make sense.
> 
> WebPine software uses IMAP as a back end.  But there is no reason why it 
> has to.  It uses the c-client library, which supports IMAP, POP, NNTP, and 
> local mail stores.  A small change to the string supplied in a mail_open() > call transforms it from a "non-native" to a "native" system.
> 
> So I don't see how you can say that CGatePro WebMail is "real" and WebPine 
> is "not real" web mail.

Do you always ignore the ":-)" signs? If I have to, I will explain - I was 
joking/teasing/kidding. Anything that starts is "real". Anything that fails 
to start is "real", too.

I was talking (seriously) about the difference of "native" implementations 
and "gateway"-type implementations. If there are several "native" 
applications (i.e. serveral applications directly addressing something - 
mailstore in our case), then there is a need to document the functionality 
and semantics of that "something".

Then, even if there were ONE application (protocol) and other applications 
(protocols) would be implemented as "gateways", STILL there is a need to 
document the semantics of that underlying "something". And as a sample I 
used the current state of the LDAP protocol - which is still the only 
available protocol for Directory store, but w/o a doc describing directory 
store semantics, all implementations ended up being "slightly different".

> Can CGatePro WebMail be configured to use an IMAP back end?  If so, how is 
> it any different from WebPine?  Does the default configuration magically 
> change a program from "real" to "not real"?

It's irrelevant - see above, please. A sense of humor is not a sin, and it 
can be used sometimes, don't you think so?

> If not (CGatePro WebMail can not be configured to use an IMAP back end), 
> than
> are you arguing that a "real" web mail program is one that is a restricted
> subset of a "not real" web mail program?

:-)

> I could understand you making a distinction between web mail programs that
> only do local mail, and web mail programs that only do IMAP.  But we have 
> at
> least one example (WebPine) of a program that (at least in theory) can do
> both, and I doubt that WebPine is the only (or even the first) such 
> program.

:-)) Mark, there was no attempt to say that something is better and 
something is worse. That was a JOKE!!! Please look at this sign carefully: 
":-)" It means - I'm kidding, I'm joking, I'm making (trying to make) you 
smile, it does not mean "Mark, you stuff does not fly". It does.

Sincerely,
Vladimir

Date: Thu, 13 Jun 2002 06:21:32 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights   associated with READ-WRITE response code)
To: "Vladimir A. Butenko" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Thu, 13 Jun 2002 06:08:37 -0700, Vladimir A. Butenko wrote:
> I have seen a small util that implements POP3 via an IMAP server. Should we
> ALWAYS think about POP3 server as "a gateway from POP3 protocol to an IMAP
> server"? I hope not. Please note that not only CGatePro WebMail, but many
> other products implement WebMail "natively" - i.e. as yet another service
> working with the mailstore, alongside POP3 and IMAP services.

That distinction does not always make sense.

WebPine software uses IMAP as a back end.  But there is no reason why it has
to.  It uses the c-client library, which supports IMAP, POP, NNTP, and local
mail stores.  A small change to the string supplied in a mail_open() call
transforms it from a "non-native" to a "native" system.

So I don't see how you can say that CGatePro WebMail is "real" and WebPine is
"not real" web mail.

Can CGatePro WebMail be configured to use an IMAP back end?  If so, how is it
any different from WebPine?  Does the default configuration magically change a
program from "real" to "not real"?

If not (CGatePro WebMail can not be configured to use an IMAP back end), than
are you arguing that a "real" web mail program is one that is a restricted
subset of a "not real" web mail program?

I could understand you making a distinction between web mail programs that
only do local mail, and web mail programs that only do IMAP.  But we have at
least one example (WebPine) of a program that (at least in theory) can do
both, and I doubt that WebPine is the only (or even the first) such program.

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights   associated with READ-WRITE response code)
To: Alexey Melnikov <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
Cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Thu, 13 Jun 2002 06:08:37 -0700
Sender: [email-masked]

On Thu, 13 Jun 2002 05:00:36 -0600
  Alexey Melnikov <[email-masked]> wrote:
> > > Oh, and I don't "dislike WebMail".  After all, UW has a WebMail product 
> >of
> > > its own (WebPine).  WebMail done right!  :-)
> >
> > If it's done via IMAP, it's not WebMail :-)
> 
> We are just disagreeing on terms. I though about WebMail as IMAP to HTTP
> gateway.

I have seen a small util that implements POP3 via an IMAP server. Should we 
ALWAYS think about POP3 server as "a gateway from POP3 protocol to an IMAP 
server"? I hope not. Please note that not only CGatePro WebMail, but many 
other products implement WebMail "natively" - i.e. as yet another service 
working with the mailstore, alongside POP3 and IMAP services.

On the other hand, it is possible to abandon the concept of "mailstore" 
completely, and express everything in terms of IMAP - even if the protocol 
does NOT use IMAP.

I.e. the POP3 standard whould say: 
  
    RETR
      operation that retrieves message body (that same thing that is 
retrieved
      with the IMAP BODY[] command) and sends it to the client in the same
      format that is used in the IMAP APPEND command literal parameter, 
ending
      with a dot and "escaped" in the same manner as it is escaped in 
SMTP...

True, it can be done - but does it make sense?

A perfect example of such an approach is the LDAP standards. Thanks God, 
mail
things are in much better shape, but LDAP presents a perfect example of the 
mess created with that "misture" of protocol description and "store/object" 
semantics. The semantics of Directory database/store has to be retrieved 
from various parts of the LDAP protocol description, and is not clearly 
specified ANYWHERE (in the RFC tree, I'm not talking about X.500). The 
result - you CANNOT find any 2 LDAP servers that use the store with the same 
semantics.

That's why I'd always vote for separate standards that explain the object 
store semantics (mail, directory, whatever) - and separate standards that 
specify communication protocol used to access those objects/store elements.

> Regards,
> Alexey Melnikov

Sincerely,
Vladimir

Date: Thu, 13 Jun 2002 06:08:58 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of  rightsassociated with READ-WRITE response code)
To: Alexey Melnikov <[email-masked]>
cc: Lawrence Greenfield <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Thu, 13 Jun 2002 04:59:25 -0600, Alexey Melnikov wrote:
> Also as Vladimir pointed out in his private email to me, ACL2 implementation
> can treat <identifier> as user=<identifier>, if the implementation prohibits
> the creation of users with special names or names with "=".

What does this mean?

Would an identifier such as xxx be canonicalized to user=xxx form?  If not,
how is a client to know what xxx means?  Also, wouldn't this conflict with
future assignment of special identifiers?

Date: Thu, 13 Jun 2002 05:22:47 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: Lawrence Greenfield <[email-masked]>, Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi,
>
> --On Saturday, June 8, 2002 1:26 PM -0400 Lawrence Greenfield
> <[email-masked]> wrote:
>
> | This is fine with me, though this doesn't appear to totally agree with
> | the text in the IMAP draft (section 6.3.1):
> |
> |       Read-only access through SELECT differs from the EXAMINE command
> |       in that certain read-only mailboxes MAY permit the change of
> |       permanent state on a per-user (as opposed to global) basis.
> |       Netnews messages marked in a server-based .newsrc file are an
> |       example of such per-user permanent state that can be modified
> |       with read-only mailboxes.

This seems to imply that a server that implements only per-user system flags,
must ignore "swt" for the purpose of deciding if READ-WRITE should be returned?

What is the sane way of describing this?

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

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

Date: Thu, 13 Jun 2002 05:20:55 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lawrence Greenfield <[email-masked]>
CC: Mark Crispin <[email-masked]>, Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

Lawrence Greenfield wrote:

> Another possibility is for ACL to recommend that servers implementing
> ACL just not return either READ-ONLY or READ-WRITE in response to a
> SELECT.

I think this breaks compliance with RFC 2060.

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

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

Date: Thu, 13 Jun 2002 05:00:36 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: "Vladimir A. Butenko" <[email-masked]>
CC: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set ofrights   associated with READ-WRITE response code)
Sender: [email-masked]

> > Oh, and I don't "dislike WebMail".  After all, UW has a WebMail product of
> > its own (WebPine).  WebMail done right!  :-)
>
> If it's done via IMAP, it's not WebMail :-)

We are just disagreeing on terms. I though about WebMail as IMAP to HTTP
gateway.

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

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

Date: Thu, 13 Jun 2002 04:59:25 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lawrence Greenfield <[email-masked]>
CC: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of  rightsassociated with READ-WRITE response code)
Sender: [email-masked]

Mark Crispin wrote:

> I also am amazed by the argument that the new system of identifiers
> "throws away a large amount of interoperable code".
>
> char *acl_to_acl2 (char *id)
> {
>   char *ret;
>   if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id);
>   else {
>     ret = (char *) malloc (5 + strlen (id) + 1);
>     sprintf (ret,"user=%s",id);
>   }
>   return ret;
> }
>
> char *acl2_to_acl (char *id)
> {
>   char *ret;
>   if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id);
>   else if (strncmp (id,5,"user=")
>     strcpy (ret = (char *) malloc (strlen (id + 5) + 1),id + 5)
>   else ret = 0;
>   return ret;
> }
>
> OK, I admit this is a bit too simple-minded, but it makes the point.

Exactly.

Also as Vladimir pointed out in his private email to me, ACL2 implementation
can treat <identifier> as user=<identifier>, if the implementation prohibits
the creation of users with special names or names with "=".

Larry, our ACL implementations are almost identical, I don't believe there
will be so match work.

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

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

Date: Thu, 13 Jun 2002 04:54:58 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lawrence Greenfield <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights   associated with READ-WRITE response code)
Sender: [email-masked]

Lawrence Greenfield wrote:

> If you feel the need to deprecate the old ACL commands, can we just
> name them something else?

Does it really matter? Syntax is almost identical and the difference can
be codified with the couple if statements.

>  I don't see the need to be so cute about
> our upgrades when we have an infinite number of bits that will make it
> blatantly obvious what versions we're using.

Just for the record, I don't care if ACL2 uses same command names with
slightly modified syntax or we just give these new commands new names. I
will be very reluctant to change command syntax further (remember, our
server also implements ACL and we have exactly the same set of issues),
unless it give a real benefit.

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

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

Date: Thu, 13 Jun 2002 04:45:32 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Lawrence Greenfield <[email-masked]>
CC: Simon Josefsson <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

Lawrence Greenfield wrote:

>    From: Simon Josefsson <[email-masked]>
>    Date: Wed, 12 Jun 2002 20:52:11 +0200
>
>    Alexey Melnikov <[email-masked]> writes:
>
>    > I've noticed yesterday that ABNF for "rights" was defined as "astring",
>    > not just "quoted".
>    > Anybody objects to changing this to quoted, because I don't see that
>    > "rights" will ever contain control or 8bit characters.
>
>    Sounds fine.  I've always disliked having different ways of expressing
>    the same thing, making things simpler is a good idea.  Atom is perhaps
>    even better.
>
> No, atoms aren't sufficient.  "rights" can be the empty string.  Atoms
> can't express the empty string.

Oops, you are right. However my argument about non blocking parser stands. See
my other reply.

> I see no reason to constain rights to quoted strings.  I think having
> them as strings makes sense---they are strings---and in IMAP we have
> up to three ways of expressing a string.  Instead of simplifying
> things, it'll complicated the lexical and syntatic levels of IMAP even
> more.

Not really. Instead of writing one function that accept any kind of string, you
can write a new function that allows only quoted strings and make the first call
the second.

A particular implementation (;-)) may choose to accept both types of strings
when only quoted is allowed and this is fine.

> If you want to remove all ways of expressing strings in IMAP besides
> literals, well, fine, but that's a different argument.

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

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

Date: Thu, 13 Jun 2002 04:39:27 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Meeting?
Sender: [email-masked]

Pete Resnick wrote:

> Well, life is back to this list. Do we have enough to discuss and
> have enough people going that I should set up a session in Yokohama?
> (I will be there.)

I suggest we don't meet this time, but we meet in November.
Neither myself, nor Mark, nor Larry will be there.

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

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

Date: Wed, 12 Jun 2002 20:51:14 +0100
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: SETACL/DELETEACL questions (was Re: ACL2: set of rights associated  with  READ-WRITE response code)
Sender: [email-masked]

Mark Crispin wrote:

> On Tue, 11 Jun 2002 15:21:49 -0600, Alexey Melnikov wrote:
> > > What should a server do if it receives a SETACL which can not be performed
> > > without doing a DELETEACL of some other identifier/rights pair?  [Think of
> > > what would become a "chgrp" in UNIX]
> > Server is allowed to do that. It must return new ACL in an unsolicited ACL
> > response anyway.
>
> How is it indicated to the client that this will happen *before* doing the
> SETACL?

I don't know any way currently.

> We're talking about client and end user surprise here.  Such surprises will
> generate complaints.

We don't have too many choices really. Either the server says NO to an operation
or it says OK, but updates client's view with unsolicited ACL response. Am I
missing anything?

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

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

Date: Wed, 12 Jun 2002 20:49:49 +0100
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Rob Siemborski <[email-masked]>
CC: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

Mark Crispin wrote:

> On Wed, 12 Jun 2002 12:23:52 -0400 (EDT), Rob Siemborski wrote:
> > Is there a compelling reason for this?
>
> Simplicity.  Why allow in the syntax something that is meaningless?

Correct. Also see my comment below.

> > Unless I'm missing something,
> > nothing in the IMAP base spec that can be a quoted string is disallowed
> > from being a literal
>
> You missed the internaldate argument to APPEND.

   string          = quoted / literal

ANNOTATATE extension, for example, uses "quoted" instead of "astring" for entry
names.
See below why it is a very good thing, IMHO.

> > Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but
> > why be different?  I could easily see implementations that make heavy use
> > of literals missing this special case.

It is not about the bandwidth, but about simplicity of implementation.

My experience with writing parsers in non-blocking or asynchronous IO model
(i.e. when read from the socket may return that literal was not completely
received by TCP stack) tells that it is a pain in the ass to write a parser for
any command that uses literals. Why? Because you have to save state if there is
not enough data. Dealing with "quoted" or atoms is a bit easier.
So, for a server implementing only ACL2 and using async IO, this change will
help.

If a server also implements ACL it has to accept "astring" anyway. So CMU
implementation doesn't have to change.

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

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

Date: Wed, 12 Jun 2002 20:25:03 +0100
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

Mark Crispin wrote:

> On Wed, 12 Jun 2002 06:58:42 -0600, Alexey Melnikov wrote:
> > I've noticed yesterday that ABNF for "rights" was defined as "astring",
> > not just "quoted".
> > Anybody objects to changing this to quoted, because I don't see that
> > "rights" will ever contain control or 8bit characters.
>
> By that argument, rights should be an atom instead of quoted.  It is possible
> to restrict from astring to atom, but not from quoted to atom, so if atom is
> the right thing this has to be done now.

That is even better.

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

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

Date: Wed, 12 Jun 2002 20:15:18 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights associated with READ-WRITE response code)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 12 Jun 2002, Lawrence Greenfield wrote:
> I think defining new, entirely different identifiers throws away a
> large amount of interoperable code that already exists.  This is a
> silly response to the fear that someone, somewhere, has usernames
> starting with $ that they will need to use with IMAP ACLs.

It isn't just user names starting with $.  It's also the "anyone" user
name.

It is certainly not "silly" to worry that an extension to a protocol
arbitarily establishes a limitation that is not in the base specification.
RFC 2086 made a mistake by assuming that identifier == username.

The new system of identifiers makes more sense than RFC 2086 (or the
proposed $ kludge), and is a clean functional superset.  The whole point
of ACL2 is to fix the numerous deficiencies in RFC 2086.  That entire
effort would be wasted by a misguided effort to be "compatible".

I also am amazed by the argument that the new system of identifiers
"throws away a large amount of interoperable code".

char *acl_to_acl2 (char *id)
{
  char *ret;
  if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id);
  else {
    ret = (char *) malloc (5 + strlen (id) + 1);
    sprintf (ret,"user=%s",id);
  }
  return ret;
}

char *acl2_to_acl (char *id)
{
  char *ret;
  if (!strcmp (id,"anyone")) ret = strcpy ((char *) malloc (7),id);
  else if (strncmp (id,5,"user=")
    strcpy (ret = (char *) malloc (strlen (id + 5) + 1),id + 5)
  else ret = 0;
  return ret;
}

OK, I admit this is a bit too simple-minded, but it makes the point.

Date: Wed, 12 Jun 2002 19:47:04 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 12 Jun 2002, Lawrence Greenfield wrote:
> No, atoms aren't sufficient.  "rights" can be the empty string.  Atoms
> can't express the empty string.

OK, in that case, then it should remain astring.

-- Mark --

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

Date: Wed, 12 Jun 2002 22:46:13 -0400
From: Lawrence Greenfield <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: "Vladimir A. Butenko" <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
Sender: [email-masked]

If you feel the need to deprecate the old ACL commands, can we just
name them something else?  I don't see the need to be so cute about
our upgrades when we have an infinite number of bits that will make it
blatantly obvious what versions we're using.

I think defining new, entirely different identifiers throws away a
large amount of interoperable code that already exists.  This is a
silly response to the fear that someone, somewhere, has usernames
starting with $ that they will need to use with IMAP ACLs.

Larry

Date: Wed, 12 Jun 2002 22:36:23 -0400
From: Lawrence Greenfield <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Simon Josefsson <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

   From: Simon Josefsson <[email-masked]>
   Date: Wed, 12 Jun 2002 20:52:11 +0200

   Alexey Melnikov <[email-masked]> writes:

   > I've noticed yesterday that ABNF for "rights" was defined as "astring",
   > not just "quoted".
   > Anybody objects to changing this to quoted, because I don't see that
   > "rights" will ever contain control or 8bit characters.

   Sounds fine.  I've always disliked having different ways of expressing
   the same thing, making things simpler is a good idea.  Atom is perhaps
   even better.

No, atoms aren't sufficient.  "rights" can be the empty string.  Atoms
can't express the empty string.

I see no reason to constain rights to quoted strings.  I think having
them as strings makes sense---they are strings---and in IMAP we have
up to three ways of expressing a string.  Instead of simplifying
things, it'll complicated the lexical and syntatic levels of IMAP even
more.

If you want to remove all ways of expressing strings in IMAP besides
literals, well, fine, but that's a different argument.

Larry

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
To: Cyrus Daboo <[email-masked]>, Lyndon Nerenberg <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 14:50:05 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 17:43:38 -0400
  Cyrus Daboo <[email-masked]> wrote:
> Hi,

[skipped]

> | Yes, right. But the fact that many clients need to open many connections
> | to the server forces you to set that limit pretty high. Our docs suggest
> | 5-10. That's why reducing the number of IMAP connections each client
> | requires can also improve system protection.
> 
> Right - but your solution requires a change to the protocol with support 
> from both servers AND clients. If clients choose not to use the new 
> mechanism then it won't be of any benefit. So why not try and get clients 
> to change their existing usage pattern first - what justifications have 
> you had from client writers as to why so many connections are needed? If 
> we can understand what demands exist on the client that justify this, we 
> can make sure that any protocol changes really will make a difference.

Sure. Imagine a client that ALWAYS works via its own cache. It's a 
requirement and just take it so. I do understand that it is possible to 
create clients that do not use local cache (and your client is a very good 
sample), but there are OTHER clients and other approaches. Either we have to 
say now - "clients that use local caches are BAD and must be killed", or we 
have to think about supporting them more effectively.

If you think about a client that provides you access to your entire 
mailstore - with a cache or without, you can come to the same requirement. 
"3-pane clients" are not the only clients that exist. And clients that can 
open a separate window for each mailbox are not the only clients that need 
to know about several mailboxes at the same time. You either say that those 
clients do not and should not exist, or you may want to agree that they a 
right to exist and in this case the proposed extension (actually designed to 
support such a client) makes some sense.

> -- 
> Cyrus Daboo

Sincerely,
Vladimir

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
To: Lyndon Nerenberg <[email-masked]>, "Vladimir A. Butenko " <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 14:43:37 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 15:40:04 -0600
  Lyndon Nerenberg <[email-masked]> wrote:
> > Also, if a client does not complain when a server drops its "IDLE" 
> > connection, but instead reconnects, selects the same mailbox and 
> >re-enters 
> > the IDLE state - what will be the difference (besides even bigger load on 
> > the server)?
> 
> "idle" and "IDLE" are not the same thing. I was specifically talking
> about "idle" sessions. An IMAP session doing "IDLE" is not "idle."

  From the very beginning I was talking about not the BROKEN clients (that 
just forget to open some connections - as it happened a lot in Netscape 
Messenger), but about clients that NEED to keep those connections open, 
because they need to "stay in synch" with several mailboxes. It implies that 
there is an IDLE command pending there or that those clients send NOOP or 
something to get the updates. And the proposed extension targets exactly 
this situation - it allows to get rid of "synching" connections and get that 
same information in one, "main" connection that can be used to perform 
"active actions".

> --lyndon

Sincerely,
Vladimir

Date: Wed, 12 Jun 2002 17:43:38 -0400
From: Cyrus Daboo <[email-masked]>
To: "Vladimir A. Butenko" <[email-masked]>, Lyndon Nerenberg <[email-masked]>
cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
Sender: [email-masked]

Hi,

--On  "Vladimir A. Butenko" <[email-masked]> wrote:

|> I've come across a number of servers that d have that option. Its
|> probably  a good idea to have something like that just from a security
|> standpoint -  if I know I can attack your server by opening lots of
|> connections on it  from my machine, that becomes an interesting denial
|> of service  possibility.
|
| Yes, right. But the fact that many clients need to open many connections
| to the server forces you to set that limit pretty high. Our docs suggest
| 5-10. That's why reducing the number of IMAP connections each client
| requires can also improve system protection.

Right - but your solution requires a change to the protocol with support 
from both servers AND clients. If clients choose not to use the new 
mechanism then it won't be of any benefit. So why not try and get clients 
to change their existing usage pattern first - what justifications have you 
had from client writers as to why so many connections are needed? If we can 
understand what demands exist on the client that justify this, we can make 
sure that any protocol changes really will make a difference.

-- 
Cyrus Daboo

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
To: Cyrus Daboo <[email-masked]>, Lyndon Nerenberg <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 14:39:40 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 17:36:09 -0400
  Cyrus Daboo <[email-masked]> wrote:
> Hi,
> 
> --On  "Vladimir A. Butenko" <[email-masked]> wrote:
> 
> | This would be called a "broken server". The client has all rights to
> | assume that the server would not break a connection unless a server has 
> a
> | non-client related problem. A server that closes connections because it
> | is just "too busy" falls in the category of the servers that simply
> | "cannot be used under this type of load".
> 
> Then you need to be clearer about specifying the load capability of the 
> server when using IMAP - in your case specify the load in terms of the 
> number of allowed IMAP connections rather than the total number of users.

That's what we always do in our responses to various large-scale RFPs. Those 
who compose the RFPs tend to put "we need a server to handle X users" and it 
takes a lot of time to explain that the pure number of users does not mean 
much, that we must look at the avg user profile, etc. We have a customer 
that has 4.5mln users on a single server - so what? On the other end, we 
often have to deploy a 4-10 server cluster to handle some sites with just 
100,000 users. BTW, in both cases the IMAP is the main protocol. The # of 
concurrent IMAP connections is just one thing, of course, there are many 
others - but it is an important thing, and whatever can be done to decrease 
the # of connections each user needs is a Good Thing.

> -- 
> Cyrus Daboo

Sincerely,
Vladimir

Organization: ACI Worldwide - Advanced Technology Group
To: "Vladimir A. Butenko" <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
Date: Wed, 12 Jun 2002 15:40:04 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> Also, if a client does not complain when a server drops its "IDLE" 
> connection, but instead reconnects, selects the same mailbox and re-enters 
> the IDLE state - what will be the difference (besides even bigger load on 
> the server)?

"idle" and "IDLE" are not the same thing. I was specifically talking
about "idle" sessions. An IMAP session doing "IDLE" is not "idle."

--lyndon

Pieces of eight, pieces of eight, pieces of nine. Parroty error.

Date: Wed, 12 Jun 2002 17:36:09 -0400
From: Cyrus Daboo <[email-masked]>
To: "Vladimir A. Butenko" <[email-masked]>, Lyndon Nerenberg <[email-masked]>
cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
Sender: [email-masked]

Hi,

--On  "Vladimir A. Butenko" <[email-masked]> wrote:

| This would be called a "broken server". The client has all rights to
| assume that the server would not break a connection unless a server has a
| non-client related problem. A server that closes connections because it
| is just "too busy" falls in the category of the servers that simply
| "cannot be used under this type of load".

Then you need to be clearer about specifying the load capability of the 
server when using IMAP - in your case specify the load in terms of the 
number of allowed IMAP connections rather than the total number of users.

-- 
Cyrus Daboo

Organization: ACI Worldwide - Advanced Technology Group
To: Cyrus Daboo <[email-masked]>
cc: "Vladimir A. Butenko" <[email-masked]>, Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
Date: Wed, 12 Jun 2002 15:35:56 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

> How do you then deal with clients that have an 'automatically re-connect 
> when server connection dies' mode? 

By swearing a lot.

> In that mode the client will simply 
> re-connect as soon as you kill their connection.

Most clients these days will hopefully defer that open until they
have actual work to do. In general, clients that cache intelligently
also tend to use connections intelligently. I'm all for "natural
selection" here.

> Another solution is to have a server admin configurable option to limit the 
> maximum number of connections from any one client machine. Provided you 
> ensure that the admin can't set this below, say 3, that might help. I've 
> come across a number of servers that d have that option. Its probably a 
> good idea to have something like that just from a security standpoint - if 
> I know I can attack your server by opening lots of connections on it from 
> my machine, that becomes an interesting denial of service possibility.

If the client is "smart" (see above) this will have little overall
impact (compared to LRUing idle connections). If the client is stupid,
this will just increase the thrash level as the client closes existing
connections to (needlessly) open a new connection to grab something
that could have been obtained over one of the existing connections.
It will then close the new connection to make room to re-open the old
connection. This constant thrashing of TCP sessions tends to put a
much higher load on server OSes than just maintaining existing idle
connections.

--lyndon

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
To: Cyrus Daboo <[email-masked]>, Lyndon Nerenberg <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 14:32:32 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 17:28:24 -0400
  Cyrus Daboo <[email-masked]> wrote:
> Hi,
> 
> --On  Lyndon Nerenberg <[email-masked]> wrote:
> 
> | If your server can't scale to 100K+ connections then you should have
> | it close down old connections on an LRU basis to cap the total
> | connection count at something the server *can* handle. You don't
> | need protocol modifications to solve this problem. (Especially
> | since, as you stated earlier, "most of the connections are idle.")
> 
> How do you then deal with clients that have an 'automatically re-connect 
> when server connection dies' mode? In that mode the client will simply 
> re-connect as soon as you kill their connection.

Exactly.

> Another solution is to have a server admin configurable option to limit 
> the maximum number of connections from any one client machine. Provided 
> you ensure that the admin can't set this below, say 3, that might help. 

We do have this option. So, if the client mailer NEEDS 4 connections and the 
server rejects it - what do we get? Yes, right - a call to the support 
center. Then imagine a customer like Charter that has more than 1mln users 
and you get the idea that "or, it's your client fault" would not be an 
acceptable answer for those sites.

> I've come across a number of servers that d have that option. Its probably 
> a good idea to have something like that just from a security standpoint - 
> if I know I can attack your server by opening lots of connections on it 
> from my machine, that becomes an interesting denial of service 
> possibility.

Yes, right. But the fact that many clients need to open many connections to 
the server forces you to set that limit pretty high. Our docs suggest 5-10. 
That's why reducing the number of IMAP connections each client requires can 
also improve system protection.

> -- 
> Cyrus Daboo

Sincerely,
Vladimir

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
To: Lyndon Nerenberg <[email-masked]>, "Vladimir A. Butenko " <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 14:28:27 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 15:19:35 -0600
  Lyndon Nerenberg <[email-masked]> wrote:
> If your server can't scale to 100K+ connections then you should have
> it close down old connections on an LRU basis to cap the total
> connection count at something the server *can* handle. You don't
> need protocol modifications to solve this problem. (Especially
> since, as you stated earlier, "most of the connections are idle.")

This would be called a "broken server". The client has all rights to assume 
that the server would not break a connection unless a server has a 
non-client related problem. A server that closes connections because it is 
just "too busy" falls in the category of the servers that simply "cannot be 
used under this type of load".

Also, if a client does not complain when a server drops its "IDLE" 
connection, but instead reconnects, selects the same mailbox and re-enters 
the IDLE state - what will be the difference (besides even bigger load on 
the server)?

> --lyndon

Sincerely,
Vladimir

Date: Wed, 12 Jun 2002 17:28:24 -0400
From: Cyrus Daboo <[email-masked]>
To: Lyndon Nerenberg <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
Sender: [email-masked]

Hi,

--On  Lyndon Nerenberg <[email-masked]> wrote:

| If your server can't scale to 100K+ connections then you should have
| it close down old connections on an LRU basis to cap the total
| connection count at something the server *can* handle. You don't
| need protocol modifications to solve this problem. (Especially
| since, as you stated earlier, "most of the connections are idle.")

How do you then deal with clients that have an 'automatically re-connect 
when server connection dies' mode? In that mode the client will simply 
re-connect as soon as you kill their connection.

Another solution is to have a server admin configurable option to limit the 
maximum number of connections from any one client machine. Provided you 
ensure that the admin can't set this below, say 3, that might help. I've 
come across a number of servers that d have that option. Its probably a 
good idea to have something like that just from a security standpoint - if 
I know I can attack your server by opening lots of connections on it from 
my machine, that becomes an interesting denial of service possibility.

-- 
Cyrus Daboo

Organization: ACI Worldwide - Advanced Technology Group
To: "Vladimir A. Butenko" <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability 
Date: Wed, 12 Jun 2002 15:19:35 -0600
From: Lyndon Nerenberg <[email-masked]>
Sender: [email-masked]

If your server can't scale to 100K+ connections then you should have
it close down old connections on an LRU basis to cap the total
connection count at something the server *can* handle. You don't
need protocol modifications to solve this problem. (Especially
since, as you stated earlier, "most of the connections are idle.")

--lyndon

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability
To: Cyrus Daboo <[email-masked]>, Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 13:39:16 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 16:13:28 -0400
  Cyrus Daboo <[email-masked]> wrote:
> Hi,
> 
> --On  "Vladimir A. Butenko" <[email-masked]> wrote:
> 
> | The main problem with MANY IMAP clients is the number of IMAP 
> connections
> | they keep open. While it may be not the case with the non-GUI clients,
> | GUI clients tend to keep an open connection for each mailbox the user
> | opened. Thus, a 10,000 active users often open 100,000 connections to a
> | server, and this is not good, because: a) each connection require a
> | socket on the server, and many systems "do not work very well" when they
> | need to handle 100,000 open sockets. But we often meet a req to support
> | 30,000 concurrent users - and 300,000 connections is definitely "too
> | many".
> 
> I think you are overstating this - are you really saying that an IMAP 
> client typically has 10 connections open to a single server when the user 
> is logged in?

It all depends on your interpretation of the word "typically" :-). We did 
see that sometimes clients (I do not want to point fingers right now) that 
ended up with many open connections after you copy/move messages, and there 
are also clients where "keeping the cache current for all mailboxes" is a 
must and the authors use it as the explanation why so many connections need 
to be opened.

While right now we definitely do not see that 1:10 ration I mentioned, the 
fact that we saw those things and the fact that we do not believe that those 
clients become less popular, and the fact that more and more people put most 
of their docs on mail servers, ending up with dozens of mailboxes in each 
account - makes us try to find a solution BEFORE it becomes a unsolvable 
problem.

> Lets face it, most clients with the typical three-pane view 
> limit the number of mailboxes the user has open. Even with our client that 
> allows multiple windows for mailboxes, I very much doubt anyone gets close 
> to 10. Remember, that connections are costly on the client-side too.

OK. Just try Netscape Messenger. It's not a client we worry about, but you 
will get the idea :-(

> | b) in many server implementations each connection reequires a
> | thread (at least, if not a process), and each thread needs a stack, and
> | if 100K stacks are used, 10,000 connections would require 1GB of VRAM 
> for
> | stacks (not tha bad), but 100,000 connections would require 10GB of VRAM
> | - and this makes the server life "difficult" - when deployed on a 32-bit
> | system.
> 
> This is a server design issue. For this kind of scalability simply use a 
> fixed thread pool, and service connections with that. You don't have to 
> have one thread per connection. Given that an IMAP connection is idle for 
> significant periods of time, this is a reasonable thing to do.

That's true. But thread stacks can be solved this way, while excessive 
number of connections will still be there. Try this test: make a simple test 
program that measures the performance of basic OS operations, then make that 
program open 100,000 sockets and measure the same things again. You can get 
very interesting results under Solaris 7, for example (they did address this 
in Solaris 8). 

> | of the implementations should only benefit: the client should use may
> | "SELECT" commands to switch between mailboxes (instead of using many
> | connections), but since the "WATCH" command would keep the mailbox in 
> the
> | "parsed" stage, the price for those additional "SELECTs" should be
> | virtually zero.
> 
> This approach will effectively deprecate the use of sequence numbers and 
> require clients to maintain full UID caches for all messages in all the 
> mailboxes it is watching. The watched responses will have to return 
> message info using UIDs.

This approach can be used EXACTLY for those clients that ALREADY do this. 
While I understand that this is not what IMAP authors and "good IMAP" client 
authors (like yourself) had in their minds, many popular clients DO MAINTAIN 
those caches, and this is a fact of live. If a client does not maintain the 
caches and does not care about synching them - it won't use those 
extensions, that's it. But if it does, it will work much more effectively 
with those extensions.

  
> I think a better approach (if you really want to force one connection to 
> handle multiple mailboxes) is to introduce a MULTISELECT command that lets 
> you have more than one mailbox selected - in that mode all of the 
> responses from the server would include the mailbox name as part of the 
> response, so it would be possible to correlate responses with each 
> selected mailbox. This would allow sequence number access for all 
> mailboxes as well as using UIDs.

I've mentioned this in my previous letter. I think that this is a much more 
radical change of the protocol. We can implement it easily, but it will 
unlikely have any real usage: a client that relies on such functionality 
would need a completely different code to support "old" IMAP servers. While 
the proposed extension adds only few things to the protocol, and it won't 
take a lot of additional code to support servers that do not have this 
extension (that code would just open a separate connection, do SELECT, then 
IDLE and get all updates)

Again, my letter was just to see if anyone is interested. We now have that 
extension in any case, I just wanted to know if it makes sense to document 
it so other vendors can implement it, too - and if the client vendors find 
it useful. If not - then it's less work for us :-)

> Cyrus Daboo

Sincerely,
Vladimir

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 13:13:33 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 11:23:28 -0700 (PDT)
  Mark Crispin <[email-masked]> wrote:
> Without deprecating Vladimir's efforts, he is not the only one who is 
> working
> on "push" type technology for mailbox updates.
> 
> I'd rather not say too much about my efforts at this point since I only 
> have a toy implementation.  The basic idea is that it is a notification
> mechanism in which a client (not necessarily an IMAP client) asks a
> notification server to be delivered events on a certain object identifier,
> and event generators  for the particular object identifier spam the
> notification server with events. 
>  Of course, it's actually a lot more complicated than this.
> 
> It is not impossible to implement an IMAP extension that uses an interface
> very much like Vladimir's (or even identical), if in the long run it is
> determined to be desirable to have access to the mechanism via IMAP.

I think we look at this issue from different points of view. The proposed 
extension, indeed, can be viewed as a particular case of a more generic 
"Notification service", but I was talking about the IMAP protocol itself and 
the changes/extensions that we may have to implement in that protocol to 
meet the modern requirements.

The IMAP protocol fits well when a "single-view" client is used. There the 
concept of "going from one mailbox to a different one" is well addressed by 
the use of the SELECT command. Modern, "multiple-view" clients use a 
different concept. They often use "one window-one session-one SELECT" 
approach and have to maintain many connections to work with many "views". 
While the current IMAP protocol can be (and is) successfully used by those 
clients, it causes scalability problems that I've mentioned. And because 
most clients are used by mortals that still have just two hands (at max) and 
one single-threaded brain (at max), most of those connections are sitting 
idle, with all action taking place at only one connection at any given 
moment.

This leads to the idea to support those multiple-view clients with just one 
connection. One method would be to get rid of the "Selected" state at all, 
giving the client ability to work with any message in any mailbox at any 
time - but this would definitely result in a completely new protocol that 
would just use many IMAP portions. What we are using is a much more moderate 
change - those "WATCH" extensions. I cannot say now how well they work for 
multiple-view clients, but we hope that in 3-4 months the installed base of 
those clients will be well in hundred thousands, so we hope to have more 
"reallife" experience with it (it would be too bold to estimate that a new 
client will get such an audience so quickly, but that client is not a real 
one - it's a MAPI connector for MS OUTLOOK, thus this conservative estimate 
- less than 1% of our current users).

Please note that there is no NEW "push" technology proposed here. All used 
technologies already exist in IMAP - with or without the IDLE extension. But 
in the basic IMAP the server reports updates only for one, "selected" 
mailbox, while with the proposed extension updates are reported for any set 
of mailboxes (besides the currently selected mailbox). So, the proposed 
thing is a much less generic one than your "notification server", and it is 
completely IMAP-specific, and uses the already existing technologies and the 
IMAP ideology.
The message actions (read/copy/store) still can be used only from the 
"selected state", but the client can stay in sync with all mailboxes without 
keeping those "watching" connections.

Depending on the type of mailbox store used, the extension may be very 
easily implemented. In CommuniGate Pro it took about 100 lines of code - 
total.

Sincerely,
Vladimir

Date: Wed, 12 Jun 2002 16:13:28 -0400
From: Cyrus Daboo <[email-masked]>
To: "Vladimir A. Butenko" <[email-masked]>, Mark Crispin <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: New topic: Extensions to impove IMAP scalability
Sender: [email-masked]

Hi,

--On  "Vladimir A. Butenko" <[email-masked]> wrote:

| The main problem with MANY IMAP clients is the number of IMAP connections
| they keep open. While it may be not the case with the non-GUI clients,
| GUI clients tend to keep an open connection for each mailbox the user
| opened. Thus, a 10,000 active users often open 100,000 connections to a
| server, and this is not good, because: a) each connection require a
| socket on the server, and many systems "do not work very well" when they
| need to handle 100,000 open sockets. But we often meet a req to support
| 30,000 concurrent users - and 300,000 connections is definitely "too
| many".

I think you are overstating this - are you really saying that an IMAP 
client typically has 10 connections open to a single server when the user 
is logged in? Lets face it, most clients with the typical three-pane view 
limit the number of mailboxes the user has open. Even with our client that 
allows multiple windows for mailboxes, I very much doubt anyone gets close 
to 10. Remember, that connections are costly on the client-side too.

| b) in many server implementations each connection reequires a
| thread (at least, if not a process), and each thread needs a stack, and
| if 100K stacks are used, 10,000 connections would require 1GB of VRAM for
| stacks (not tha bad), but 100,000 connections would require 10GB of VRAM
| - and this makes the server life "difficult" - when deployed on a 32-bit
| system.

This is a server design issue. For this kind of scalability simply use a 
fixed thread pool, and service connections with that. You don't have to 
have one thread per connection. Given that an IMAP connection is idle for 
significant periods of time, this is a reasonable thing to do.

| It looks like this extension allows to design a client that can open only
| one IMAP connection to the server, but still "stay in synch" with several
| mailboxes. This should decrease the server load for large sites, and most
| of the implementations should only benefit: the client should use may
| "SELECT" commands to switch between mailboxes (instead of using many
| connections), but since the "WATCH" command would keep the mailbox in the
| "parsed" stage, the price for those additional "SELECTs" should be
| virtually zero.

This approach will effectively deprecate the use of sequence numbers and 
require clients to maintain full UID caches for all messages in all the 
mailboxes it is watching. The watched responses will have to return message 
info using UIDs.

I think a better approach (if you really want to force one connection to 
handle multiple mailboxes) is to introduce a MULTISELECT command that lets 
you have more than one mailbox selected - in that mode all of the responses 
from the server would include the mailbox name as part of the response, so 
it would be possible to correlate responses with each selected mailbox. 
This would allow sequence number access for all mailboxes as well as using 
UIDs.

-- 
Cyrus Daboo

Date: Wed, 12 Jun 2002 16:04:09 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: re: New topic: Extensions to impove IMAP scalability
Sender: [email-masked]

Hi,

--On  Mark Crispin <[email-masked]> wrote:

| Without deprecating Vladimir's efforts, he is not the only one who is
| working on "push" type technology for mailbox updates.
|
| I'd rather not say too much about my efforts at this point since I only
| have a toy implementation.  The basic idea is that it is a notification
| mechanism in which a client (not necessarily an IMAP client) asks a
| notification server to be delivered events on a certain object
| identifier, and event generators for the particular object identifier
| spam the notification server with events.  Of course, it's actually a lot
| more complicated than this.

Oh great - yet another notification protocol proposal! All previous efforts 
in this area seem to have failed. I hope your solution can survive!

To be honest with you, at this point I strongly believe that this type of 
notification should be integrated into presence protocols - I'd like my 
'buddy' list to also tell me when new mail is present in a mailbox, and for 
the mailbox to send me an instant message with a summary of the new mail 
content. So why not piggy back this on impp?

-- 
Cyrus Daboo

Date: Wed, 12 Jun 2002 12:24:14 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Meeting?
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 12 Jun 2002 14:12:53 -0500, Pete Resnick wrote:
> Well, life is back to this list. Do we have enough to discuss and
> have enough people going that I should set up a session in Yokohama?
> (I will be there.)

Yokohama is just 4 1/2 weeks from now.  The likelihood of getting reasonably
priced airfare ($500) and lodging (6000 - 8000 yen/night) for Japan is
vanishing this close to the travel date.

For the next IETF, can we discuss the go/no-go question a bit earlier, such as
when the first announcements are made?

Our state government has a major budget crisis, and we're a state university.
Non-essential travel for any of us is out of the question.  Given that I have
personal business in Japan, and that nothing else at the Yokohama IETF seems
related to anything that I'm doing, any travel request from me to go to
Yokohama will be picked over with a fine-toothed comb.

So, (with considerable regret) I ask that there NOT be an IMAPEXT meeting at
Yokohama.

Date: Wed, 12 Jun 2002 14:12:53 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Meeting?
Sender: [email-masked]

Well, life is back to this list. Do we have enough to discuss and 
have enough people going that I should set up a session in Yokohama? 
(I will be there.)

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

Date: Wed, 12 Jun 2002 12:01:52 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: ACL2 backwards compatibility
To: Simon Josefsson <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

On Wed, 12 Jun 2002 20:59:38 +0200, Simon Josefsson wrote:
> Can a server support both ACL and ACL2?  The latest draft indicate
> that ACL and ACL2 is incompatible.  How do the server know whether the
> client is using ACL or ACL2?

Alexey's latest proposals (basically a superset of what I proposed) will
accomplish a server being able to do both ACL and ACL2.  There is different
command syntax for ACL and ACL2 commands, and that can be used by the server
to determine ACL vs. ACL2 semantics.

An ACL server should be able to add ACL2 support without too much difficulty.
An ACL2 server may find it difficult or impossible to add ACL.

I purpose to implement ACL2 only.

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
To: Arnt Gulbrandsen <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 11:58:47 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 20:28:07 +0200
  Arnt Gulbrandsen <[email-masked]> wrote:
> I have the impression that today, a "mailstore" is something that talks
> IMAP, LMTP and often a few other protocols.

You can think of it as you want. I prefer to call the "mailstore" some 
internal mail server component that implements certain functions, in the 
same way as the Directory is some database - with some well-defined 
semantics.
If you want to include the components that implement various protocols into 
what you call "mailstore" - it's OK, but that internal component is still 
there. In the same way as the Directory semantics is always there, while 
LDAP is just a protocol that allows you to access that store, with its 
semantics - and there can be other ways to access the same store.

Even if you use some legacy design and your IMAP, POP, SMTP, etc. components 
all have their own code, so they use just the same file system (or a 
database) - LOGICALLY, there is still a "mailstore" - something that stores 
the messages and allows certain operations with them - and that semantics 
DOES NOT DEPEND on the protocol used to access that mailstore.

CommuniGate Pro (and, I'm sure some other servers) allow you to open any 
mailbox via POP3 using some special "username". For example, you can specify
"mailbox#username" and open that mailbox in your POP3 session. Make one more 
step - if you access "foreign mailbox" in IMAP using ~username/mailboxname 
"mailbox" name, then it would be logical (though not required, of course) to 
allow the POP server to access the same mailbox if you specify the 
"~username/mailboxname#youraccount" and "yourpassword". Definitely you need 
to have access rights for that ~username/mailboxname to open that mailbox. 
Most likely - the "r" right in the IMAP ACL terms. And to delete messages 
there - also some right. And the POP3 server must mark those messages as 
"read" (or \Seen) on RETR - if you have the "s" right. 

Does it have anything to do with the IMAP *protocol*? No. 

There is a much less exotic sample - WebMail. The *NATIVE* WebMail that 
works directly with the mailstore, not a "WebMail GUI" on top of IMAP or 
POP. It needs to deal with all those things - and it has nothing to do with 
IMAP.

> IMHO that's a good state of affairs. I'm sure there are arguments for
> adding more stuff, but doing that makes me think of RFC 1925.

There is already a draft for Server-side Rules (or, probably, it has already 
become an RFC?). If my Rule specifies that the message that meets this and 
that criteria should be stored in the ~secretary/ImportantNotes mailbox - 
what should be my rights for that mailbox? Should that standard refer to the 
IMAP ACL RFC? Why - it has nothing to do with IMAP *protocol*?

Message UIDs should be generated by those components that store messages in 
mailboxes. The UIDs must be numbers in the strict ascending order. Where is 
the standard that tells delivery agent developers to implement it that way? 
The same applies to the requirement to store the INTERNALDATE values there. 
Yes, it is mentioned in the IMAP standard, but why should Delivery Agent 
developers look into any IMAP standard? Result - the POP3 also has UIDs, but 
they are "completely different UIDs" - they may be non-numeric, and they may 
be non-ascending, so all POP3 clients implementing the "leave on server" 
options must remember all UIDs that they have "seen" in the mailbox (instead 
of remembering UIDValidity and the last UID or UIDNEXT in the IMAP terms).

You do not want the IMAP standard to talk about the details of the TCP 
implementation, right? And it would be very strange if the FTP RFC would 
refer to the IMAP RFC for the details of the TCP semantics, right? The TCP 
is the "backbone", it's some thing that many higher-level protocols use and 
it is documented separately. The fact that an IMAP client built into a cell 
phone may implement IMAP and TCP in one piece of code does not make a 
difference. The fact that many existing IMAP, POP3, SMTP servers implement 
certain mailstore semantics inside their protocol-specific code does not 
make that semantics "tied up" to a certain protocol or service. It should be 
documented separately.

  
> --Arnt

Sincerely,
Vladimir

To: [email-masked]
Subject: ACL2 backwards compatibility
From: Simon Josefsson <[email-masked]>
Date: Wed, 12 Jun 2002 20:59:38 +0200
Lines: 6
Sender: [email-masked]

Can a server support both ACL and ACL2?  The latest draft indicate
that ACL and ACL2 is incompatible.  How do the server know whether the
client is using ACL or ACL2?

Perhaps this is already taken care of in the document, if so I'm sorry
to have read it sloppily.

To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
From: Simon Josefsson <[email-masked]>
Date: Wed, 12 Jun 2002 20:52:11 +0200
Lines: 10
Sender: [email-masked]

Alexey Melnikov <[email-masked]> writes:

> I've noticed yesterday that ABNF for "rights" was defined as "astring",
> not just "quoted".
> Anybody objects to changing this to quoted, because I don't see that
> "rights" will ever contain control or 8bit characters.

Sounds fine.  I've always disliked having different ways of expressing
the same thing, making things simpler is a good idea.  Atom is perhaps
even better.

Date: Wed, 12 Jun 2002 11:23:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: New topic: Extensions to impove IMAP scalability
To: "Vladimir A. Butenko" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Without deprecating Vladimir's efforts, he is not the only one who is working
on "push" type technology for mailbox updates.

I'd rather not say too much about my efforts at this point since I only have a
toy implementation.  The basic idea is that it is a notification mechanism in
which a client (not necessarily an IMAP client) asks a notification server to
be delivered events on a certain object identifier, and event generators for
the particular object identifier spam the notification server with events.  Of
course, it's actually a lot more complicated than this.

It is not impossible to implement an IMAP extension that uses an interface
very much like Vladimir's (or even identical), if in the long run it is
determined to be desirable to have access to the mechanism via IMAP.

Date: Wed, 12 Jun 2002 20:28:07 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: "Vladimir A. Butenko" <[email-masked]>
Cc: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
Sender: [email-masked]

I have the impression that today, a "mailstore" is something that talks
IMAP, LMTP and often a few other protocols.

IMHO that's a good state of affairs. I'm sure there are arguments for
adding more stuff, but doing that makes me think of RFC 1925.

--Arnt

From: "Vladimir A. Butenko" <[email-masked]>
Subject: New topic: Extensions to impove IMAP scalability
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 10:24:38 -0700
Sender: [email-masked]

We are about to release the new version of CommuniGate Pro that will inlcude 
several extensions that have not been discussed anywhere: they will be used 
by our own client. But at least one of those extensions may be of some 
general interest, since we implemented it to improve the scalability.

We now deploy more and more systems (both single-server and clustered) in 
Universities and corporations where IMAP is the main access method (WebMail 
is great, Mark, do not forget that! - but IMAP is great, too :-).

The main problem with MANY IMAP clients is the number of IMAP connections 
they keep open. While it may be not the case with the non-GUI clients, GUI 
clients tend to keep an open connection for each mailbox the user opened. 
Thus, a 10,000 active users often open 100,000 connections to a server, and 
this is not good, because:
a) each connection require a socket on the server, and many systems "do not 
work very well" when they need to handle 100,000 open sockets. But we often 
meet a req to support 30,000 concurrent users - and 300,000 connections is 
definitely "too many".
b) in many server implementations each connection reequires a thread (at 
least, if not a process), and each thread needs a stack, and if 100K stacks 
are used, 10,000 connections would require 1GB of VRAM for stacks (not tha 
bad), but 100,000 connections would require 10GB of VRAM - and this makes 
the server life "difficult" - when deployed on a 32-bit system.

So, our goal was to make minimal additions to the IMAP protocol - additions 
that would make it possible to "keep in sync" with many mailboxes, while 
still using just one IMAP connection. There is no formal document for that, 
so I'm trying to provide informal description:

Commands:
   WATCH ON <mailboxname>
This command sets a "watcher" on the specified mailbox. ACL: must be the 
same as for the EXAMINE command, and for synching puposes, the command 
should be sent when the <mailboxname> mailbox is selected by this IMAP 
session.

   WATCH OFF <mailboxname>
This command removes the watcher from the specified mailbox. When the 
session ends, all watchers are removed automatically, so this command is 
useful mostly for mailbox removing/renaming operations on the servers that 
do not allow you to move/delete a mailbox if is being "opened" by anyone.

Responses.
  Whenever an untagged response can be returned, the following responses can 
appear:
   * WATCH <mailboxname> <flag fetch response>
   * WATCH <mailboxname> <expunge response>

Where the <flag fetch> and <expunge> responses are the same responses as 
used in the "normal" IMAP session. For example:

* WATCH Trash 10 EXPUNGE
* WATCH Trash 11 EXPUNGE
* WATCH Trash 12 EXPUNGE

If the current mailbox name (name specified in the "Select" command) is the 
same as the name in one of the WATCH commands, "WATCH" responses for that 
mailbox are not sent (to avoid duplicates, since they are sent as regular 
IMAP untagged reponses). If the names are different (but in reality they 
point to the same mailbox), the responses are sent.

It looks like this extension allows to design a client that can open only 
one IMAP connection to the server, but still "stay in synch" with several 
mailboxes. This should decrease the server load for large sites, and most of 
the implementations should only benefit: the client should use may "SELECT" 
commands to switch between mailboxes (instead of using many connections), 
but since the "WATCH" command would keep the mailbox in the "parsed" stage, 
the price for those additional "SELECTs" should be virtually zero.

If there is any interest in such an extension, we can try to create a formal 
draft.

Sincerely,
Vladimir

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
To: Mark Crispin <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 10:00:14 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 09:53:09 -0700 (PDT)
  Mark Crispin <[email-masked]> wrote:
> I have a great deal of sympathy for many of Vladimir's arguments, 
> particularly
> from an architectural point of view.  I have argued many of these things
> myself for many years.
> 
> >From a practical point of view, however, I don't think that any of these
> should delay ACL2.

Let's be realistic. Even if someone would agree to create such a "mailstore" 
standard, it would take at least 1-2 months to create the first draft. Then 
it will take at least 3-6 months to discuss it, since it definitely should 
agree (at least, in main points) with the current, popular implementations. 
So, if this standard is to appear, it will take at least 9 months (as 
usual). And if it appears, many standards has to be rewritten to remove the 
parts that would be included into the new standard. Rewriting the new ACL 
standard would be a very small part of that job. 

So - I do not see any reason to delay the ACL2 release either.

> Oh, and I don't "dislike WebMail".  After all, UW has a WebMail product of 
> its own (WebPine).  WebMail done right!  :-)

If it's done via IMAP, it's not WebMail :-)

Sincerely,
Vladimir

Date: Wed, 12 Jun 2002 09:53:09 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
To: "Vladimir A. Butenko" <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

I have a great deal of sympathy for many of Vladimir's arguments, particularly
from an architectural point of view.  I have argued many of these things
myself for many years.

>From a practical point of view, however, I don't think that any of these
should delay ACL2.

Oh, and I don't "dislike WebMail".  After all, UW has a WebMail product of its
own (WebPine).  WebMail done right!  :-)

From: "Vladimir A. Butenko" <[email-masked]>
Subject: Re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
To: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Wed, 12 Jun 2002 09:46:29 -0700
Sender: [email-masked]

On Wed, 12 Jun 2002 08:42:28 -0700 (PDT)
  Mark Crispin <[email-masked]> wrote:
> It should be obvious, but I support Alexey's proposal.
> 
> This will make it possible to implement both ACL and ACL2 in a 
> straighforward
> manner, while not leaving ACL2 hampered with warts from needless ACL
> compatibility.

I have just sent my comments on the new draft to Alexey, hopefully he will 
have time to remove the most foolish of my remarks and share it with the 
group. I strongly support this new, more mature ACL standard, but I'd like 
to bring up the issue that I have already mentioned in my previous letter to 
Alexey:

Most of those things have NOTHING to do with IMAP. Both the IMAP basic 
standard and some of its standard extensions are talking about 2 different 
things: about the "mailbox store" and its semantics (that has nothing to do 
with the IMAP as the protocol) and the IMAP itself - the protocol that 
provides access to that mailbox store and its functions, but should not care 
about many "behind the scene" details of the mailbox store functionality.

I do understand that it's a big work to do, but - IMHO - all of us will 
benefit from a new, additional set of standards, the "mailbox store" 
standards that will address many issues that originated in the first IMAP 
implementations, but have nothing to do with the protocol itself:
* concept of a mailbox
* concept of a mailbox heirarchy
* concept of message UIDs and mailbox UIDVALIDITY settings
* concept of message flags
* concept of mailbox operations ("append", "remove marked")
* concept of "foreign mailbox" access
* concept of mailbox ACLs
* concept of concurrent mailbox usage
* etc.

The IMAP standards can just ref to those standards, specifying only the 
syntax and IMAP-specific details, and not touching the "backend", mailstore 
specific details. This would allow us to rewrite the POP3 standard, too - 
since most modern implementations use the same mailstore for POP3 and IMAP, 
and there is no standard that specifies how these two interact (messages 
retrieved with POP3 RETR are marked with the \SEEN flag, while message 
retrieved with TOP are not marked, if POP3 QUIT does "EXPUNGE" or deletes 
only those messages that this POP3 session marked as "DELETED", how POP3 
should deal with messages that have been deleted in a concurrent session, 
etc.).

While SMTP standard won't gain much from such a "mailstore" standard, 
"delivery agents" may gain a lot, especially those that provide Automated 
Rules - those Rules can store message in different mailboxes in the the 
mailstore, add flags, etc.

In spite of the fact that I know how Mark dislikes WebMail :-), I have to 
mention it, too: WebMail has become a de-facto standard - and it must use 
the same mailstore as IMAP/POP/maildelivery agents use. W/o the mailstore 
standard, there can be no "standard" for WebMail, but if we require that 
WebMail must use the "standard-based" mailstore, interaction between WebMail 
and IMAP becomes a no-brainer, and it becomes obvious what this or that 
WebMail operation does and how it will be seen in an IMAP session opened to 
the same mailstore, and vice versa.

Not that I feel myself able to create such a standard, but I'd definitely 
support and help anyone who is brave enough to invest his/her time and 
talent into such a beast.

Sincerely,
Vladimir

Date: Wed, 12 Jun 2002 12:35:39 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

On Wed, 12 Jun 2002, Mark Crispin wrote:

> > Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but
> > why be different?  I could easily see implementations that make heavy use
> > of literals missing this special case.
>
> I agree that changing from astring to quoted may seem silly, but what about
> from astring to atom?

Restricting from astring to atom is fine by me (since the I agree that
the likelyhood of control characters is low).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 235 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ UBLS++++$ P+++$ L++(+++) E W+ N- o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-- b++ DI+++ G e h r y?
------END GEEK CODE BLOCK-----

Date: Wed, 12 Jun 2002 09:28:02 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
To: Rob Siemborski <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 12 Jun 2002 12:23:52 -0400 (EDT), Rob Siemborski wrote:
> Is there a compelling reason for this?

Simplicity.  Why allow in the syntax something that is meaningless?

> Unless I'm missing something,
> nothing in the IMAP base spec that can be a quoted string is disallowed
> from being a literal

You missed the internaldate argument to APPEND.

> Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but
> why be different?  I could easily see implementations that make heavy use
> of literals missing this special case.

I agree that changing from astring to quoted may seem silly, but what about
from astring to atom?

Date: Wed, 12 Jun 2002 09:25:20 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: ACL2: Proposal to change ABNF for "rights"
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Wed, 12 Jun 2002 06:58:42 -0600, Alexey Melnikov wrote:
> I've noticed yesterday that ABNF for "rights" was defined as "astring",
> not just "quoted".
> Anybody objects to changing this to quoted, because I don't see that
> "rights" will ever contain control or 8bit characters.

By that argument, rights should be an atom instead of quoted.  It is possible
to restrict from astring to atom, but not from quoted to atom, so if atom is
the right thing this has to be done now.

Date: Wed, 12 Jun 2002 12:23:52 -0400 (EDT)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

On Wed, 12 Jun 2002, Alexey Melnikov wrote:

> Anybody objects to changing this to quoted, because I don't see that
> "rights" will ever contain control or 8bit characters.
> Effectively this will prohibit the following:
>
> C: A001 SETACL ~/Mail/saved smith {2}
> C: cp
>
> Comments?

Is there a compelling reason for this?  Unless I'm missing something,
nothing in the IMAP base spec that can be a quoted string is disallowed
from being a literal (e.g.  nothing is just a quoted, it's always atleast
a string).

Sure, it costs atleast another byte of bandwidth (2 with LITERAL+), but
why be different?  I could easily see implementations that make heavy use
of literals missing this special case.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski | Andrew Systems Group * Research Systems Programmer
PGP:0x5CE32FCC | Cyert Hall 235 * [email-masked] * 412.268.7456
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ UBLS++++$ P+++$ L++(+++) E W+ N- o? K-
w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-- b++ DI+++ G e h r y?
------END GEEK CODE BLOCK-----

Date: Wed, 12 Jun 2002 06:58:42 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: ACL2: Proposal to change ABNF for "rights"
Sender: [email-masked]

I've noticed yesterday that ABNF for "rights" was defined as "astring",
not just "quoted".
Anybody objects to changing this to quoted, because I don't see that
"rights" will ever contain control or 8bit characters.
Effectively this will prohibit the following:

C: A001 SETACL ~/Mail/saved smith {2}
C: cp

Comments?

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

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

Date: Wed, 12 Jun 2002 08:42:28 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
Sender: [email-masked]

It should be obvious, but I support Alexey's proposal.

This will make it possible to implement both ACL and ACL2 in a straighforward
manner, while not leaving ACL2 hampered with warts from needless ACL
compatibility.

Date: Wed, 12 Jun 2002 08:37:46 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: SETACL/DELETEACL questions (was Re: ACL2: set of rights associated with  READ-WRITE response code)
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Tue, 11 Jun 2002 15:21:49 -0600, Alexey Melnikov wrote:
> > What should a server do if it receives a SETACL which can not be performed
> > without doing a DELETEACL of some other identifier/rights pair?  [Think of
> > what would become a "chgrp" in UNIX]
> Server is allowed to do that. It must return new ACL in an unsolicited ACL
> response anyway.

How is it indicated to the client that this will happen *before* doing the
SETACL?

We're talking about client and end user surprise here.  Such surprises will
generate complaints.

Date: Wed, 12 Jun 2002 03:33:50 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: SETACL and tied-rights
Sender: [email-masked]

Mark Crispin wrote:

>    [...] If rights are tied in an
>    implementation, the implementation must be conservative in granting
>    rights in response to SETACL commands--unless all rights in a tied
>    set are specified, none of that set should be included in the ACL
>    entry for that identifier.  A client may discover the set of rights
>    which may be granted to a given identifier in the ACL for a given
>    mailbox by using the LISTRIGHTS command.
>
> This was in RFC 2086 as well.
>
> Do we really want these semantics?
>
> The effect of this is that it is mandatory to do a LISTRIGHTS prior to any
> SETACL (and multiple LISTRIGHTS prior to any REPLACEACL), since otherwise
> there is no way for a client to know how to grant a particular right to an
> identifier.
>
> Presumably, the reason for these semantics is so a client can review the
> impact of granting a particular right if it's tied to another.  But will
> any client actually do this?  Or will clients just blindly do the
> LISTRIGHTS to get the necessary incantation for SETACL?
>
> What I see is no savings of work for a client which cares about any side
> effects due to tied-rights, but a lot of extra work for clients which do
> not care.

I tend to agree. I would rather have a new response code LISTRIGHTS that is
returned in NO response to SETACL command.
Imagine that the client wants to grant "cp" rights to a user "smith". The
client instead of doing:

               C: A001 LISTRIGHTS ~/Mail/saved smith
               S: * LISTRIGHTS ~/Mail/saved smith la r swi cdext
               S: A001 OK Listrights completed
               C: A002 SETACL ~/Mail/saved smith cdextp
               S: A002 OK Setacl complete

will do the following (this assumes that the server doesn't want to grant a
right unless all tied rights are specified by the client):

               C: A001 SETACL ~/Mail/saved smith cp
               S: A001 NO [LISTRIGHTS la r swi cdext] No some rights are tied,
specify both
               C: A002 SETACL ~/Mail/saved smith cdextp
               S: A002 OK Setacl complete
               C: A002 LISTRIGHTS ~/Mail/saved smith

and if the server sets all tied rights automatically if at least one of them
is specified (not recommended by the document but still possible):

               C: A001 SETACL ~/Mail/saved smith cp
               S: * ACL ~/Mail/saved smith cdextp
               S: A001 OK Setacl complete

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

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

Date: Wed, 12 Jun 2002 02:48:21 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
CC: Mark Crispin <[email-masked]>, "Vladimir A. Butenko" <[email-masked]>
Subject: Identifiers and ACL2 command syntax (was Re: ACL2: set of rights  associated with READ-WRITE response code)
Sender: [email-masked]

Mark Crispin wrote:

> Alexey sent me a copy of his latest group.  This document has some truly
> amazing progress, and Alexey deserves to be congratulated.
>
> A suggestion, and some questions:
>
> The $ stuff is getting complicated.  How about this instead:
>
> Eliminate $ entirely, and define "identifier" as one of:
>         anyone
>         authuser
>         owner
>         administrators
>         user=<xxx>
>         group=<xxx>
> All other identifier names are reserved for future definition in an
> extension or revision to the ACL2 specification.

As Larry pointed out, this will break existing ACL implementations that treat
these identifiers differently (probably all of them).
However we can achieve this if we change syntax of ACL2 commands. Personally I
am reluctant to change syntax drastically, I would very match like to keep
existing parser as is. However, in Minneapolis we agreed to do another change:
support multiple mailboxes in an ACL command (allow for mailboxes with
wildcards or even several mailboxes). [Please, speak up now if you don't agree
with this!!!] So, I need to tweak the syntax for ACL2 commands anyway in order
to achieve this.
So, I propose:

1). We change syntax of ACL commands (and possibly responses) a little bit:

In all ACL commands mailbox is replaced with mailbox_list that is enclosed in
"(" and ")". This will allow to unambiguously distinguish between ACL and
ACL2. And this is a small change in an ACL parser, IMHO.

   acl_data        = "ACL" SPACE mailbox_list *(SPACE identifier SPACE rights)

   deleteacl       = "DELETEACL" SPACE mailbox_list SPACE identifier

   getacl          = "GETACL" SPACE mailbox_list

   listrights      = "LISTRIGHTS" SPACE mailbox_list SPACE identifier

   replaceacl      = "REPLACEACL" SPACE mailbox_list *(SPACE identifier SPACE
rights)

   setacl          = "SETACL" SPACE mailbox_list SPACE identifier SPACE
mod_rights

   mailbox_list = "(" 1*mailbox ")"
                         ;; mailbox may contain pattern matching characters *
and %

ACL and LISTRIGHTS responses must be replaced with ACL2 and LISTRIGHTS2:

   acl_data        = "ACL2" SPACE mailbox *(SPACE identifier SPACE rights)

   listrights_data = "LISTRIGHTS2" SPACE mailbox SPACE identifier
                           SPACE rights *(SPACE rights)

These responses have exactly the same syntax as ACL and LISTRIGTHS, but
"identifier" here has ACL2 syntax as proposed by Mark.

2). Go with Mark's proposal

In order to do that, I want to hear from people who've implemented ACL and
willing to implement ACL that they agree to go along.

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

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

Date: Tue, 11 Jun 2002 15:21:49 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Mark Crispin <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: SETACL/DELETEACL questions (was Re: ACL2: set of rights associated with  READ-WRITE response code)
Sender: [email-masked]

Mark Crispin wrote:

> What should a server do if it receives a SETACL which can not be performed
> without doing a DELETEACL of some other identifier/rights pair?  [Think of
> what would become a "chgrp" in UNIX]

Server is allowed to do that. It must return new ACL in an unsolicited ACL
response anyway.

> What should a server do if it receives a DELETEACL but the identifier can
> not be deleted? Is it alright to treat it as a SETACL with server-defined

> default rights?

The server can either fail with NO (for example, in our implementation we
don't allow to delete the last ACL entry on a mailbox) response or do as you
describe (i.e. modify some other ACL(s) as well and return OK).

> In particular, on UNIX I would probably treat a DELETEACL
> of $anyone to mean "set $anyone to empty rights", of $group=<xxx> to mean
> "set $group=<xxx> to same as $anyone", and of $owner to "all rights of
> $anyone and $group=<xx> plus a".  Is this alright?

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

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

Date: Tue, 11 Jun 2002 13:37:42 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: SETACL and tied-rights
Organization: Networks & Distributed Computing
Sender: [email-masked]

   [...] If rights are tied in an
   implementation, the implementation must be conservative in granting
   rights in response to SETACL commands--unless all rights in a tied
   set are specified, none of that set should be included in the ACL
   entry for that identifier.  A client may discover the set of rights
   which may be granted to a given identifier in the ACL for a given
   mailbox by using the LISTRIGHTS command.

This was in RFC 2086 as well.

Do we really want these semantics?

The effect of this is that it is mandatory to do a LISTRIGHTS prior to any
SETACL (and multiple LISTRIGHTS prior to any REPLACEACL), since otherwise
there is no way for a client to know how to grant a particular right to an
identifier.

Presumably, the reason for these semantics is so a client can review the
impact of granting a particular right if it's tied to another.  But will
any client actually do this?  Or will clients just blindly do the
LISTRIGHTS to get the necessary incantation for SETACL?

What I see is no savings of work for a client which cares about any side
effects due to tied-rights, but a lot of extra work for clients which do
not care.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-acl-04.txt
Date: Mon, 10 Jun 2002 07:18:49 -0400
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-acl-04.txt
	Pages		: 9
	Date		: 06-Jun-02
	
The ACL extension of the Internet Message Access Protocol [IMAP4]
permits access control lists to be manipulated through the IMAP
protocol.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-acl-04.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-acl-04.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-acl-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Sat, 8 Jun 2002 10:45:43 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
To: Lawrence Greenfield <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Sat, 8 Jun 2002 13:43:44 -0400, Lawrence Greenfield wrote:
> Do we know of any existing clients that use READ-ONLY/READ-WRITE for
> anything?  What do they use them for?  What's the benefit of sending
> this back to the client?

Pine checks the READ-ONLY flag in quite a few places.

The best way to think about READ-ONLY is that it means you can't do anything
to the mailbox that someone else would see.  You can, however, alter any flags
listed as PERMANENTFLAGS.

I think matching that to the i and e bits sounds right, although the swt bits
may affect things if they are PERMANENTFLAGS.

By the way, the definition of the w right should be called "write flags"
instead of "write".  It's too late to change it now, but the i right should
really be the w right, and the current w right should be something like f.

Date: Sat, 8 Jun 2002 13:43:44 -0400
From: Lawrence Greenfield <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>, Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

   Date: Sat, 08 Jun 2002 13:40:15 -0400
   From: Cyrus Daboo <[email-masked]>
[...]
   OK, this implies then that READ-ONLY should be returned if both the 'i' and 
   'e' bits are off, irrespective of the 's', 'w' and 't' bits which only 
   control flag state. 'i' and 'e' actually control the content of the 
   mailbox. So how about this:

       The server MUST include a READ-ONLY prefix in the tagged OK response to
       a SELECT command if both the 'i' and 'e' ACL rights are off for the
       current user. The server SHOULD include a READ-WRITE prefix in the
       tagged OK response if either the 'i' or 'e' ACL rights is on for the
       current user.

   This fits in with the base-spec requirement of SHOULD for READ-WRITE and 
   MUST for READ-ONLY.

Do we know of any existing clients that use READ-ONLY/READ-WRITE for
anything?  What do they use them for?  What's the benefit of sending
this back to the client?

Larry

Date: Sat, 08 Jun 2002 13:40:15 -0400
From: Cyrus Daboo <[email-masked]>
To: Lawrence Greenfield <[email-masked]>, Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

Hi,

--On Saturday, June 8, 2002 1:26 PM -0400 Lawrence Greenfield 
<[email-masked]> wrote:

| This is fine with me, though this doesn't appear to totally agree with
| the text in the IMAP draft (section 6.3.1):
|
|       Read-only access through SELECT differs from the EXAMINE command
|       in that certain read-only mailboxes MAY permit the change of
|       permanent state on a per-user (as opposed to global) basis.
|       Netnews messages marked in a server-based .newsrc file are an
|       example of such per-user permanent state that can be modified
|       with read-only mailboxes.
|
| Another possibility is for ACL to recommend that servers implementing
| ACL just not return either READ-ONLY or READ-WRITE in response to a
| SELECT.

OK, this implies then that READ-ONLY should be returned if both the 'i' and 
'e' bits are off, irrespective of the 's', 'w' and 't' bits which only 
control flag state. 'i' and 'e' actually control the content of the 
mailbox. So how about this:

    The server MUST include a READ-ONLY prefix in the tagged OK response to
    a SELECT command if both the 'i' and 'e' ACL rights are off for the
    current user. The server SHOULD include a READ-WRITE prefix in the
    tagged OK response if either the 'i' or 'e' ACL rights is on for the
    current user.

This fits in with the base-spec requirement of SHOULD for READ-WRITE and 
MUST for READ-ONLY.

-- 
Cyrus Daboo

Date: Sat, 8 Jun 2002 13:26:26 -0400
From: Lawrence Greenfield <[email-masked]>
To: Mark Crispin <[email-masked]>, Alexey Melnikov <[email-masked]>, Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

   Date: Sat, 08 Jun 2002 13:16:47 -0400
   From: Cyrus Daboo <[email-masked]>
[...]
   Therefore I argue that READ-WRITE status should appear whenever any ACL bit 
   that controls a change in the masilbox content is on. i.e.

   read_write = 's' || 'w' || 'i' || 't' || 'e';

   If all of those are off then the mailbox is READ-ONLY.

This is fine with me, though this doesn't appear to totally agree with
the text in the IMAP draft (section 6.3.1):

      Read-only access through SELECT differs from the EXAMINE command
      in that certain read-only mailboxes MAY permit the change of
      permanent state on a per-user (as opposed to global) basis.
      Netnews messages marked in a server-based .newsrc file are an
      example of such per-user permanent state that can be modified
      with read-only mailboxes.

Another possibility is for ACL to recommend that servers implementing
ACL just not return either READ-ONLY or READ-WRITE in response to a
SELECT.

Larry

Date: Sat, 08 Jun 2002 13:16:47 -0400
From: Cyrus Daboo <[email-masked]>
To: Lawrence Greenfield <[email-masked]>, Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

Hi,

--On Friday, June 7, 2002 2:50 PM -0400 Lawrence Greenfield 
<[email-masked]> wrote:

| What Alexey is referring to here is a fairly minor problem, the
| [READ-ONLY] and [READ-WRITE] status responses.  These responses are
| basically useless since they don't convey any information to the
| client.  Does "READ-WRITE" mean "able to modify everything"?  "able
| to modify at least one thing"?  ACL gives the client a much better
| notion of what operations are likely to succeed.
|
| ACL2 should just recommend one interpretation and tie READ-WRITE to a
| particular right.  It's not a big deal.

You need to consider READ-WRITE/READ-ONLY in the context of non-ACL aware 
clients. A non-ACL client will likely use that indicator to determine what 
commands to enable in its UI when that mailbox is open. e.g. for a 
READ-ONLY mailbox the client will disable flag changing commands, expunge, 
prevent drag and drop of messages into the mailbox pane etc.

The problem arises when some ACL bits are on and others are not. For 
example if 'w' is off, but 'i' is on, and 'w' controls the R-W/R-O status, 
then the mailbox will appear as READ-ONLY. Non-ACL clients might then 
disable the ability to copy into or append to that mailbox, even though 
that is allowed by the ACL 'i' bit. This is bad as it prevents the user 
from being able to do a valid operation. If the status were reported as 
READ-WRITE, then copy/append would be enabled for the user and would work 
fine. In this case the 'negative' aspect is that the flag change commands 
would be enabled but fail with a NO response when the user attempts it. I 
regard this as the lesser of two evils in that valid commands can at least 
be executed and there is a reasonable failure mode for non-valid commands.

Therefore I argue that READ-WRITE status should appear whenever any ACL bit 
that controls a change in the masilbox content is on. i.e.

read_write = 's' || 'w' || 'i' || 't' || 'e';

If all of those are off then the mailbox is READ-ONLY.

-- 
Cyrus Daboo

Date: Fri, 7 Jun 2002 13:32:10 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lawrence Greenfield <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Fri, 7 Jun 2002, Lawrence Greenfield wrote:
> Such a change would be completely incompatible with existing ACL
> implementations, which already have widespread adaption and good
> interoperability.

We are talking about ACL2, not ACL.

I can assure you that if I implemented ACL in UW imapd (and c-client/Pine)
in the way that made the most sense for us, the result would be completely
non-interoperable.  It would break existing implementations which expect
the Cyrus type of interpretation, and create an incredible mess.

It would also be completely compliant with RFC 2086.

Fortunately, I am not the sort of person who deliberately does harmful
things to break a specification.  I have put off implementing ACL in UW
imapd in the hope of having a fixed specification.

The whole point of ACL2 is to create an interoperable specification that
we can all live with, and give it a different name so that we won't have
interoperability problems with ACL.

It may be necessary to have a switch (or different commands) so a client
of a server that supports both ACL and ACL2 can say "I want ACL2
semantics."  That's fine.

But, please!!, let's get it right this time.  Or we will end up with
multiple compliant non-interoperable implementations.

-- Mark --

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

Date: Fri, 7 Jun 2002 14:55:11 -0400
From: Lawrence Greenfield <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

   Date: Thu, 6 Jun 2002 13:24:42 -0700 (Pacific Daylight Time)
   From: Mark Crispin <[email-masked]>

   Eliminate $ entirely, and define "identifier" as one of:
	   anyone
	   authuser
	   owner
	   administrators
	   user=<xxx>
	   group=<xxx>
   All other identifier names are reserved for future definition in an
   extension or revision to the ACL2 specification.

Such a change would be completely incompatible with existing ACL
implementations, which already have widespread adaption and good
interoperability.

Larry

Date: Fri, 7 Jun 2002 14:50:32 -0400
From: Lawrence Greenfield <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Mark Crispin <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

   Date: Thu, 6 Jun 2002 05:53:18 -0700 (PDT)
   From: Mark Crispin <[email-masked]>

   On Thu, 06 Jun 2002 03:46:14 -0600, Alexey Melnikov wrote:
   > Cyrus, Communigate and CDC IntraStore are completely different
   > implementations of the ACL RFC and they all behave differently!

   Yes, and if UW imapd implemented RFC 2086 there would have been a fourth
   completely different implementation that would have been even more different
   than the other three.

What Alexey is referring to here is a fairly minor problem, the
[READ-ONLY] and [READ-WRITE] status responses.  These responses are
basically useless since they don't convey any information to the
client.  Does "READ-WRITE" mean "able to modify everything"?  "able
to modify at least one thing"?  ACL gives the client a much better
notion of what operations are likely to succeed.

ACL2 should just recommend one interpretation and tie READ-WRITE to a
particular right.  It's not a big deal.

Larry

Date: Fri, 7 Jun 2002 10:52:04 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
To: Steve Hole <[email-masked]>
cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Fri, 7 Jun 2002 11:47:16 -0700, Steve Hole wrote:
> > Eliminate $ entirely, and define "identifier" as one of:
> > 	anyone
> > 	authuser
> > 	owner
> > 	administrators
> > 	user=<xxx>
> > 	group=<xxx>
> > All other identifier names are reserved for future definition in an
> > extension or revision to the ACL2 specification.
> This is precisely what we arrived at in the "authid" acap dataset class as
> well.   As I wrote authid, I think it's a good idea.

Cool!  We're starting to get convergence!

This would indeed remove many of the problems that I have with RFC 2086.  I
would be happy to withdraw my earlier proposal (in Alexey's draft) in favor of
this one.

From: Steve Hole <[email-masked]>
Date: Fri, 7 Jun 2002 11:47:16 -0700
To: Mark Crispin <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Thu, 6 Jun 2002 13:24:42 -0700 (Pacific Daylight Time) Mark Crispin 
<[email-masked]> wrote:

> Eliminate $ entirely, and define "identifier" as one of:
> 	anyone
> 	authuser
> 	owner
> 	administrators
> 	user=<xxx>
> 	group=<xxx>
> All other identifier names are reserved for future definition in an
> extension or revision to the ACL2 specification.

This is precisely what we arrived at in the "authid" acap dataset class as 
well.   As I wrote authid, I think it's a good idea.

Cheers.
---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[email-masked]>
Phone: 780-424-4922

Date: Thu, 6 Jun 2002 13:24:42 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2: set of rights associated with READ-WRITE response code
Organization: Networks & Distributed Computing
Sender: [email-masked]

Alexey sent me a copy of his latest group.  This document has some truly
amazing progress, and Alexey deserves to be congratulated.

A suggestion, and some questions:

The $ stuff is getting complicated.  How about this instead:

Eliminate $ entirely, and define "identifier" as one of:
	anyone
	authuser
	owner
	administrators
	user=<xxx>
	group=<xxx>
All other identifier names are reserved for future definition in an
extension or revision to the ACL2 specification.

What should a server do if it receives a SETACL which can not be performed
without doing a DELETEACL of some other identifier/rights pair?  [Think of
what would become a "chgrp" in UNIX]

What should a server do if it receives a DELETEACL but the identifier can
not be deleted?  Is it alright to treat it as a SETACL with server-defined
default rights?  In particular, on UNIX I would probably treat a DELETEACL
of $anyone to mean "set $anyone to empty rights", of $group=<xxx> to mean
"set $group=<xxx> to same as $anyone", and of $owner to "all rights of
$anyone and $group=<xx> plus a".  Is this alright?

-- Mark --

Date: Thu, 6 Jun 2002 05:53:18 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Subject: re: ACL2: set of rights associated with READ-WRITE response code
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Thu, 06 Jun 2002 03:46:14 -0600, Alexey Melnikov wrote:
> Cyrus, Communigate and CDC IntraStore are completely different
> implementations of the ACL RFC and they all behave differently!

Yes, and if UW imapd implemented RFC 2086 there would have been a fourth
completely different implementation that would have been even more different
than the other three.

I'm worried that we've still not solved the fundamental problems in RFC 2086.

Date: Thu, 06 Jun 2002 03:46:14 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: ACL2: set of rights associated with READ-WRITE response code
Sender: [email-masked]

I did a bit of research and found out the following:

Cyrus and MessagingDirect server: if either "w" or "t" are allowed for
the current user,
  server reports READ-WRITE
Communigate: when the user has "s" right.
CDC IntraStore: when the user has "w" right.

Cyrus, Communigate and CDC IntraStore are completely different
implementations of the ACL RFC and they all behave differently!

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

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

Date: Thu, 06 Jun 2002 03:45:55 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: ACL2: rights required for different IMAP command
Sender: [email-masked]

As you will see in the new revision, I've added a new section that
describes in details which rights should be checked to implement
different IMAP commands, which rights are mandatory and which are
optional.
Here is what left unresolved:

    SUBSCRIBE - "l" right is required only if the server checks for
mailbox existence
           when performing SUBSCRIBE.

Allow if the user has "r" right?

    GETACL - "a" right on the mailbox.

     CDC IntraStore: "a".
     CMU: "r", "a", admin or owner.
     MD: "r" or "a" or owner.

No consensus if "r" should be allowed. John would prefer not to use "r",
but he is fine if somebody insists on using it. The main argument
against allowing "r" for GETACL is that in this case GETACL can
possibly disclose some identifiers existing on the mail system to an
authenticated user with read access.
On the other hand "r" is used for a mailbox metadata and seems
appropriate.

    LISTRIGHTS - Same as GETACL? or just "r"?

    GETQUOTA - no rights required
CMU server checks if the user belongs to administrators, I don't know
why

    SETQUOTA - "a" right

Some implementations allows to set quota when the user has "r" right as
well. Should we allow that?

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

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

Date: Thu, 06 Jun 2002 03:43:05 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: ACL2: escape character for special identifiers and groups.
Sender: [email-masked]

This is a list of comments on the issue I've got during IMAPEXT lunch at
Minneapolis IETF (in no particular order, I hope it is not too intricate
to understand):

Could use "$$" prefix for user names beginning "$" and "$-" for user
names beginning from "-".

Escape or reject?
   No group starting with "$-" or "$$" (John).

   Use "\" as escape character for leading "$" or "-"?

   Alternatively we can change syntax of all ACL commands (Chris)

   Chris objects to escape mechanism, he prefers to reject.

We couldn't reach any consensus on the matter and I was asked to post a
question to the mailing list if any existing server ACL implementation
is using "$" as a leading character in usernames.
The only thing was clear that the participants were reluctant to change
syntax of ACL commands, as they would rather reuse existing IMAP ACL
parsers.

As Jutta pointed out in her recent post we can use "/" instead of "$".
This might work, as probably none of the existing ACL implementations
will accept usernames with "/" character.

Alexey

Date: Thu, 06 Jun 2002 03:37:46 -0600
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: New revision of ACL2
Sender: [email-masked]

I've submitted a new revision of ACL2 to the draft editor. There are
four major groups of open issues left in the document. These issues can
be shortly described as follows:
1). escape character for special identifiers and groups.
2). rights required for different IMAP commands.
3). set of rights associated with READ-WRITE response code.
4). changing ACLs for a list of mailboxes.

I will post a separate message for each group of issues.

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

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

From: "Barry Leiba" <[email-masked]>
To: "IMAP extensions Mailing List" <[email-masked]>
Subject: Re: Stalled?
Date: Mon, 3 Jun 2002 10:42:41 -0400
Sender: [email-masked]

I will get a List Extensions update out within the next couple of days.

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