Subject: FW: [VPIM] I-D ACTION:draft-burger-imap-chanuse-00.txt
From: "Eric Burger" <[email-masked]>
To: <[email-masked]>, "IETF UM" <[email-masked]>, <[email-masked]>
Date: Thu, 28 Feb 2002 18:52:58 -0500
List-Id: <ietf-imapext.imc.org>

This draft may be of interest to your groups.

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

	Title		: IMAP CHANNEL Use Cases
	Author(s)	: E. Burger
	Filename	: draft-burger-imap-chanuse-00.txt
	Pages		: 7
	Date		: 27-Feb-02

This document describes different use cases for using the IMAP
CHANNEL facility.
Discussion of this and related drafts are on the IMAP Voice list.
To subscribe, send the message 'subscribe' to
[email-masked] .

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-burger-imap-chanuse-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-burger-imap-chanuse-00.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-burger-imap-chanuse-00.txt".

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

Date: Wed, 27 Feb 2002 10:59:57 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: I-D ACTION:draft-daboo-imap-annotatemore-00.txt (fwd)
Sender: [email-masked]

FYI The following draft is a private submission that describes an
annotation extension that allows annotations on mailboxes and the server
and is meant to be a complement to the message annotation draft.

Any comments are welcome...

---------- Forwarded Message ----------
Date: Wednesday, February 27, 2002 7:23 AM -0500
From: [email-masked]
To: IETF-Announce
Subject: I-D ACTION:draft-daboo-imap-annotatemore-00.txt

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

	Title		: IMAP ANNOTATEMORE Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-imap-annotatemore-00.txt
	Pages		: 14
	Date		: 26-Feb-02
	
The ANNOTATEMORE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' on IMAP4
servers.  This document describes two 'profiles' for mailbox and
server metadata.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-daboo-imap-annotatemore-00.txt".

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

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

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

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

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

Reply-To: <[email-masked]>
From: "Eric Burger" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, "Jutta Degener" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: More SORT keys
Date: Sun, 24 Feb 2002 12:03:46 -0500
Importance: Normal
Sender: [email-masked]

That's fine, so long as we use messagehint as an example, as it WILL be
used.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Cyrus Daboo
Sent: Thursday, December 13, 2001 6:30 PM
To: Jutta Degener
Cc: [email-masked]
Subject: Re: More SORT keys

--On Thursday, December 13, 2001 3:12 PM -0800 Jutta Degener
<[email-masked]> wrote:

> Maybe, rather than defining an specific extended feature set associated
> with a SORT2 capability, we could do something along the lines of a
> SORT=FOO,BAR,BAZ capability?
>
> Then new drafts that only define specific sorting rules can define SORT
> capabilities (e.g., "MESSAGEHINT") that a server can announce without
> requiring an update to SORT itself.
>
> Just an idea.

I think that would be a fine solution. The question is whether this group
would want to define any of these now, or simply require the the current
sort document to indicate that this extensibility is possible.

--
Cyrus Daboo

To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-vaudreuil-um-issues-00.txt
Date: Fri, 22 Feb 2002 06:20:56 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Messaging profile for telephone-based Messaging 
                          clients
	Author(s)	: G. Vaudreuil
	Filename	: draft-vaudreuil-um-issues-00.txt
	Pages		: 12
	Date		: 21-Feb-02
	
This document discussed issues and requirements for a profile of the 
IMAP 4, message submission, and notification protocols for use by 
telephone user interfaces delivering the traditional voice mail user 
experience.  Experience with IMAP 4 and voice mail systems has shown 
quite a few limitations that may be addressed by protocol extensions and 
standardized conventions between clients and servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vaudreuil-um-issues-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-vaudreuil-um-issues-00.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-vaudreuil-um-issues-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-vaudreuil-um-issues-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Thu, 21 Feb 2002 21:23:20 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: more on ACL2
To: Lawrence Greenfield <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Fri, 22 Feb 2002 00:19:40 -0500, Lawrence Greenfield wrote:
> I disagree with almost all of the below.  All of these complicate
> existing ACL implementations.  Many of them aren't even possible for
> servers that have external authentication or authorization sources
> that aren't tightly coupled to the IMAP server.

Somehow, we must fix the missing functionality in IMAP ACL.  Failure will
result in multiple incompatible IMAP ACL specifications.  IESG has already
said that this will prevent the standardization of any IMAP ACL specification.

Complexity has a cost, but this complexity is necessary in order to make ACL
generic enough to be implementable on some platforms.  We must pay this cost
now, because in the past not enough attention was paid to multi-platform
implementability.

My proposal is an attempt to define the missing functionality in a manner
which (1) is generic and not specific to any particular operating system, (2)
does not create any new mandates for existing AFS-based implementations.  I
have not seen any other proposal that addresses the problem.  I would be very
happy to see a counter-proposal which also addresses the problem.

Date: Fri, 22 Feb 2002 00:19:40 -0500
From: Lawrence Greenfield <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: more on ACL2
Sender: [email-masked]

I disagree with almost all of the below.  All of these complicate
existing ACL implementations.  Many of them aren't even possible for
servers that have external authentication or authorization sources
that aren't tightly coupled to the IMAP server.

Larry

   Date: Thu, 21 Feb 2002 16:00:10 -0800 (PST) From: Mark Crispin
   <[email-masked]>

   There needs to be a way to identify, per-mailbox, what identifiers
   are valid.

   There needs to be a way to change the identifier of an existing
   ACL.

   There needs to be a way to know if an ACL can be added or an
   existing ACL can be removed.  Consider a fixed number of ACLs which
   can be modified (and their identifiers altered), but no ACL can be
   added or removed.

   A lot of this may be done by means of clever naming, but that
   naming scheme needs to be standardized.  I'm starting to think that
   a "$" prefix isn't really the right thing, that instead, we need
   some sort of type=value identifier.

   GETACL does not distinguish between tied and untied rights.  This
   is because of its syntax.  Better to follow the rest of IMAP and
   use S-expression type syntax for all ACLs, e.g.
	   "(" identifier SPACE rights *(SPACE rights) ")" Example:
    C: A002 GETACL INBOX S: * ACL INBOX (user=fred l r
    wipsextda)(group=staff l r)(anyone l) S: A002 OK GETACL completed

   Note, however, that I can not use "user=".  I really need two
   different kinds of groups, one which is per-mailbox and one which
   is global.  Also, it's important that anonymous *NOT* be part of
   anyone.

Date: Thu, 21 Feb 2002 16:00:10 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: more on ACL2
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

There needs to be a way to identify, per-mailbox, what identifiers are valid.

There needs to be a way to change the identifier of an existing ACL.

There needs to be a way to know if an ACL can be added or an existing ACL can
be removed.  Consider a fixed number of ACLs which can be modified (and their
identifiers altered), but no ACL can be added or removed.

A lot of this may be done by means of clever naming, but that naming scheme
needs to be standardized.  I'm starting to think that a "$" prefix isn't
really the right thing, that instead, we need some sort of type=value
identifier.

GETACL does not distinguish between tied and untied rights.  This is because
of its syntax.  Better to follow the rest of IMAP and use S-expression type
syntax for all ACLs, e.g.
	"(" identifier SPACE rights *(SPACE rights) ")"
Example:
 C: A002 GETACL INBOX
 S: * ACL INBOX (user=fred l r wipsextda)(group=staff l r)(anyone l)
 S: A002 OK GETACL completed

Note, however, that I can not use "user=".  I really need two different kinds
of groups, one which is per-mailbox and one which is global.  Also, it's
important that anonymous *NOT* be part of anyone.

Date: Thu, 21 Feb 2002 11:24:42 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Do we need to meet?
Sender: [email-masked]

Hi,

--On Thursday, February 21, 2002 12:16 AM -0700 Alexey Melnikov
<[email-masked]> wrote:

> What happened to mailbox annotations and "ACL ids to Friendly Names" (the
> draft that Chris was working on)?

I will be submitting a draft on mailbox and server annotations before the
deadline for new drafts tomorrow. I was waiting on comments on the message
annotate draft before proceeding with this as it does depend on some
aspects of message annotations (though it doesn't require implementing
message annotations to do mailbox/server annotations). This will be a
private submission since its not on the IMAPext charter. I will also be
updating the message annotation document before the cut-off for existing
drafts. At that point we need to decide on the last-call status.

-- 
Cyrus Daboo

Date: Thu, 21 Feb 2002 00:16:47 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Do we need to meet?
Sender: [email-masked]

Pete Resnick wrote:

> On 2/14/02 at 5:11 PM -0600, I wrote:
>
> >It looks to me that ANNOTATE is getting close. CONDSTORE doesn't
> >seem to have too much in the way of open issues. I'm not sure what
> >the state of ACL is. Do we have reason to meet in Minneapolis or not?
>
> I will take this silence to mean that we don't have to meet. Any objections?

I guess everybody want to go to Japan instead of Minneapolis ;-).
I have more unresolved issues with ACL and CONDSTORE I will submit to the
mailing list shortly.
I would like to ask people to share their opinion whether these documents are
ready for Last Call.

What happened to mailbox annotations and "ACL ids to Friendly Names" (the draft
that Chris was working on)?

I will be attending Minneapolis anyway, so I am curious who is going to attend.
Please reply privately.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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-acl-03.txt
Date: Thu, 21 Feb 2002 07:01:33 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-acl-03.txt
	Pages		: 9
	Date		: 20-Feb-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-03.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-03.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-03.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-03.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 20 Feb 2002 21:45:44 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: ACL2
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Since ACL2 can be incompatible from ACL, we should define a replacement
identifier for "anyone" that does not conflict with a login id of "anyone".
As matters stand now, the text:
   [...] The identifier "anyone" is reserved to
   refer to the universal identity (all authentications, including
   anonymous).  All user name strings accepted by the LOGIN or
   AUTHENTICATE commands to authenticate to the IMAP server are reserved
   as identifiers for the corresponding user.
is self-contradictory.

Delete "PARTIAL" as a permitted operation of the "r" right.  PARTIAL is a
deprecated feature of RFC1730 which should now be extinct.

The "d" right should first be described as "RFC 2086 compatible delete right"
and then its semantics listed.  Unfortunately, the given semantics don't work.
What if one or more of the "x", "e", or "t" rights can not be set or cleared?
Suggest changing the MUST to SHOULD.  Consider deprecating the "d" right
entirely for an ACL2-only server.

Paragraph describing negative rights should make it clear that a negative
right is not the same thing as a DELETACL.

ACL2=MOST-SPECIFIC is a big improvement.  Is ACL2=UNION really still
necessary?  Wouldn't it be better to do this in the semantics of the naming?

Note that the addition of ACL2=MOST-SPECIFIC renders certain parts of my
proposed naming system moot.  However, there are other part of it which remain
desirable, including:
 . new commands to access and define groups
 . separate "world" vs. "anonymous" access

Date: Wed, 20 Feb 2002 17:45:33 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Arnt Gulbrandsen <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2 backward compatability
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov <[email-masked]>
> > IMHO, only if a particular server implementation uses "$" prefix for groups and
> > other special identifiers.
>
> The draft lists the incompatibilities; should it also explictly recommend
> that servers advertise "ACL" if these incompatibilities don't apply in
> that server's case?

I've just added this to the version 03 I've sent yesterday.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

Date: Wed, 20 Feb 2002 11:06:54 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: Do we need to meet?
Sender: [email-masked]

On 2/14/02 at 5:11 PM -0600, I wrote:

>It looks to me that ANNOTATE is getting close. CONDSTORE doesn't 
>seem to have too much in the way of open issues. I'm not sure what 
>the state of ACL is. Do we have reason to meet in Minneapolis or not?

I will take this silence to mean that we don't have to meet. Any objections?

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

Date: Fri, 15 Feb 2002 19:02:14 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2 backward compatability
Sender: [email-masked]

Alexey Melnikov <[email-masked]>
> IMHO, only if a particular server implementation uses "$" prefix for groups and
> other special identifiers.

The draft lists the incompatibilities; should it also explictly recommend
that servers advertise "ACL" if these incompatibilities don't apply in
that server's case?

--Arnt

Date: Fri, 15 Feb 2002 10:31:02 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2 backward compatability
Sender: [email-masked]

Cyrus Daboo wrote:

> I think the current ACL2 draft has backwards compatibility with the old ACL
> draft wrt the the defined ACL bits. So should the current draft require
> servers to also advertise 'ACL' in the capability response as well as
> ACL2=xxx to allow existing ACL clients to interoperate? I would argue yes.

IMHO, only if a particular server implementation uses "$" prefix for groups and
other special identifiers.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

Date: Fri, 15 Feb 2002 10:51:29 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ACL2 backward compatability
Sender: [email-masked]

I think the current ACL2 draft has backwards compatibility with the old ACL
draft wrt the the defined ACL bits. So should the current draft require
servers to also advertise 'ACL' in the capability response as well as
ACL2=xxx to allow existing ACL clients to interoperate? I would argue yes.

-- 
Cyrus Daboo

Date: Fri, 15 Feb 2002 10:48:52 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ACL and STATUS
Sender: [email-masked]

The current ACL rfc and the latest draft for the updated version don't
indicate which ACL bit controls the behaviour of the STATUS command. I
would guess that at least read 'r' access is required in order to get
status information on a mailbox. Can we have STATUS explicitly listed as
one of the commands available for the 'r' bit?

The other option would be to allow status with only the 'l' bit, which
currently allows LIST/LSUB for a mailbox. If we ever get around to
extending list, I believe one of the proposals did have list returning the
equivalent of status information, so there might be some awkward
interaction with ACL on that.

-- 
Cyrus Daboo

Date: Thu, 14 Feb 2002 17:11:11 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Do we need to meet?
Sender: [email-masked]

It looks to me that ANNOTATE is getting close. CONDSTORE doesn't seem 
to have too much in the way of open issues. I'm not sure what the 
state of ACL is. Do we have reason to meet in Minneapolis or not?

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

Date: Tue, 05 Feb 2002 16:02:03 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: Re: I-D ACTION:draft-melnikov-imap-condstore-06.txt
Sender: [email-masked]

This is the second revision submitted this year.

Changes from -05 to -06:
      1.  Replaced "/message/flags/system" with "/message/flags" to
          match ANNOTATE draft.
      2.  Extended FETCH/SEARCH/SORT syntax to allow for specifying
          whether an operation should be performed on a shared or a private
          annotation (or both).
      3.  Corrected several examples.

Changes from -04 to -05:
      1.  Added support for SORT extension.
      2.  Multiple language/spelling fixes by Randall Gellens.

There is one major open issue left:
    MODSEQ fetch response as the result of STORE/UID STORE of a flag in any IMAP
session: what _type_ of modseq should be returned: private, shared, both? This is
related to the change 2) between 05 and 06.

Comments?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

Date: Tue, 05 Feb 2002 11:00:10 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-02.txt
Sender: [email-masked]

A new revision is out. Major changes in this version:

1). Changed ACL capability name to ACL2=<access calculation rule ID>
Added registry for the rules. Described two rules: UNION (union of the positive minus union of negative),
MOST-SPECIFIC (most specific identifier describes the rights).

2). Added "t" right for performing STORE \Deleted. Changed "d" to be a macro for "x", "t" and "e".

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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-acl-02.txt
Date: Tue, 05 Feb 2002 09:51:46 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-acl-02.txt
	Pages		: 9
	Date		: 04-Feb-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-02.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-02.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-02.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-02.txt

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

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

--OtherAccess--

--NextPart--

Reply-To: <[email-masked]>
From: "Eric Burger" <[email-masked]>
To: <[email-masked]>, "IETF UM" <[email-masked]>, <[email-masked]>
Subject: FW: [VPIM] I-D ACTION:draft-burger-imap-chanuse-00.txt
Date: Thu, 28 Feb 2002 18:52:58 -0500
Importance: Normal
Sender: [email-masked]

This is a multi-part message in MIME format.
This draft may be of interest to your groups.

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

	Title		: IMAP CHANNEL Use Cases
	Author(s)	: E. Burger
	Filename	: draft-burger-imap-chanuse-00.txt
	Pages		: 7
	Date		: 27-Feb-02

This document describes different use cases for using the IMAP
CHANNEL facility.
Discussion of this and related drafts are on the IMAP Voice list.
To subscribe, send the message 'subscribe' to
[email-masked] .

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-burger-imap-chanuse-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-burger-imap-chanuse-00.txt".

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

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

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-burger-imap-chanuse-00.txt".

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

Date: Wed, 27 Feb 2002 10:59:57 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: I-D ACTION:draft-daboo-imap-annotatemore-00.txt (fwd)
Sender: [email-masked]

FYI The following draft is a private submission that describes an
annotation extension that allows annotations on mailboxes and the server
and is meant to be a complement to the message annotation draft.

Any comments are welcome...

---------- Forwarded Message ----------
Date: Wednesday, February 27, 2002 7:23 AM -0500
From: [email-masked]
To: IETF-Announce
Subject: I-D ACTION:draft-daboo-imap-annotatemore-00.txt

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

	Title		: IMAP ANNOTATEMORE Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-imap-annotatemore-00.txt
	Pages		: 14
	Date		: 26-Feb-02
	
The ANNOTATEMORE extension to the Internet Message Access Protocol
[IMAP4] permits clients and servers to maintain 'metadata' on IMAP4
servers.  This document describes two 'profiles' for mailbox and
server metadata.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-daboo-imap-annotatemore-00.txt".

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

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

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

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

---------- End Forwarded Message ----------

-- 
Cyrus Daboo

Reply-To: <[email-masked]>
From: "Eric Burger" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, "Jutta Degener" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: More SORT keys
Date: Sun, 24 Feb 2002 12:03:46 -0500
Importance: Normal
Sender: [email-masked]

That's fine, so long as we use messagehint as an example, as it WILL be
used.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Cyrus Daboo
Sent: Thursday, December 13, 2001 6:30 PM
To: Jutta Degener
Cc: [email-masked]
Subject: Re: More SORT keys

--On Thursday, December 13, 2001 3:12 PM -0800 Jutta Degener
<[email-masked]> wrote:

> Maybe, rather than defining an specific extended feature set associated
> with a SORT2 capability, we could do something along the lines of a
> SORT=FOO,BAR,BAZ capability?
>
> Then new drafts that only define specific sorting rules can define SORT
> capabilities (e.g., "MESSAGEHINT") that a server can announce without
> requiring an update to SORT itself.
>
> Just an idea.

I think that would be a fine solution. The question is whether this group
would want to define any of these now, or simply require the the current
sort document to indicate that this extensibility is possible.

--
Cyrus Daboo

To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-vaudreuil-um-issues-00.txt
Date: Fri, 22 Feb 2002 06:20:56 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Messaging profile for telephone-based Messaging 
                          clients
	Author(s)	: G. Vaudreuil
	Filename	: draft-vaudreuil-um-issues-00.txt
	Pages		: 12
	Date		: 21-Feb-02
	
This document discussed issues and requirements for a profile of the 
IMAP 4, message submission, and notification protocols for use by 
telephone user interfaces delivering the traditional voice mail user 
experience.  Experience with IMAP 4 and voice mail systems has shown 
quite a few limitations that may be addressed by protocol extensions and 
standardized conventions between clients and servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vaudreuil-um-issues-00.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-vaudreuil-um-issues-00.txt".

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-vaudreuil-um-issues-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-vaudreuil-um-issues-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Thu, 21 Feb 2002 21:23:20 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: Re: more on ACL2
To: Lawrence Greenfield <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On Fri, 22 Feb 2002 00:19:40 -0500, Lawrence Greenfield wrote:
> I disagree with almost all of the below.  All of these complicate
> existing ACL implementations.  Many of them aren't even possible for
> servers that have external authentication or authorization sources
> that aren't tightly coupled to the IMAP server.

Somehow, we must fix the missing functionality in IMAP ACL.  Failure will
result in multiple incompatible IMAP ACL specifications.  IESG has already
said that this will prevent the standardization of any IMAP ACL specification.

Complexity has a cost, but this complexity is necessary in order to make ACL
generic enough to be implementable on some platforms.  We must pay this cost
now, because in the past not enough attention was paid to multi-platform
implementability.

My proposal is an attempt to define the missing functionality in a manner
which (1) is generic and not specific to any particular operating system, (2)
does not create any new mandates for existing AFS-based implementations.  I
have not seen any other proposal that addresses the problem.  I would be very
happy to see a counter-proposal which also addresses the problem.

Date: Fri, 22 Feb 2002 00:19:40 -0500
From: Lawrence Greenfield <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: more on ACL2
Sender: [email-masked]

I disagree with almost all of the below.  All of these complicate
existing ACL implementations.  Many of them aren't even possible for
servers that have external authentication or authorization sources
that aren't tightly coupled to the IMAP server.

Larry

   Date: Thu, 21 Feb 2002 16:00:10 -0800 (PST) From: Mark Crispin
   <[email-masked]>

   There needs to be a way to identify, per-mailbox, what identifiers
   are valid.

   There needs to be a way to change the identifier of an existing
   ACL.

   There needs to be a way to know if an ACL can be added or an
   existing ACL can be removed.  Consider a fixed number of ACLs which
   can be modified (and their identifiers altered), but no ACL can be
   added or removed.

   A lot of this may be done by means of clever naming, but that
   naming scheme needs to be standardized.  I'm starting to think that
   a "$" prefix isn't really the right thing, that instead, we need
   some sort of type=value identifier.

   GETACL does not distinguish between tied and untied rights.  This
   is because of its syntax.  Better to follow the rest of IMAP and
   use S-expression type syntax for all ACLs, e.g.
	   "(" identifier SPACE rights *(SPACE rights) ")" Example:
    C: A002 GETACL INBOX S: * ACL INBOX (user=fred l r
    wipsextda)(group=staff l r)(anyone l) S: A002 OK GETACL completed

   Note, however, that I can not use "user=".  I really need two
   different kinds of groups, one which is per-mailbox and one which
   is global.  Also, it's important that anonymous *NOT* be part of
   anyone.

Date: Thu, 21 Feb 2002 16:00:10 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: more on ACL2
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

There needs to be a way to identify, per-mailbox, what identifiers are valid.

There needs to be a way to change the identifier of an existing ACL.

There needs to be a way to know if an ACL can be added or an existing ACL can
be removed.  Consider a fixed number of ACLs which can be modified (and their
identifiers altered), but no ACL can be added or removed.

A lot of this may be done by means of clever naming, but that naming scheme
needs to be standardized.  I'm starting to think that a "$" prefix isn't
really the right thing, that instead, we need some sort of type=value
identifier.

GETACL does not distinguish between tied and untied rights.  This is because
of its syntax.  Better to follow the rest of IMAP and use S-expression type
syntax for all ACLs, e.g.
	"(" identifier SPACE rights *(SPACE rights) ")"
Example:
 C: A002 GETACL INBOX
 S: * ACL INBOX (user=fred l r wipsextda)(group=staff l r)(anyone l)
 S: A002 OK GETACL completed

Note, however, that I can not use "user=".  I really need two different kinds
of groups, one which is per-mailbox and one which is global.  Also, it's
important that anonymous *NOT* be part of anyone.

Date: Thu, 21 Feb 2002 11:24:42 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Do we need to meet?
Sender: [email-masked]

Hi,

--On Thursday, February 21, 2002 12:16 AM -0700 Alexey Melnikov
<[email-masked]> wrote:

> What happened to mailbox annotations and "ACL ids to Friendly Names" (the
> draft that Chris was working on)?

I will be submitting a draft on mailbox and server annotations before the
deadline for new drafts tomorrow. I was waiting on comments on the message
annotate draft before proceeding with this as it does depend on some
aspects of message annotations (though it doesn't require implementing
message annotations to do mailbox/server annotations). This will be a
private submission since its not on the IMAPext charter. I will also be
updating the message annotation document before the cut-off for existing
drafts. At that point we need to decide on the last-call status.

-- 
Cyrus Daboo

Date: Thu, 21 Feb 2002 00:16:47 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Pete Resnick <[email-masked]>
CC: [email-masked]
Subject: Re: Do we need to meet?
Sender: [email-masked]

Pete Resnick wrote:

> On 2/14/02 at 5:11 PM -0600, I wrote:
>
> >It looks to me that ANNOTATE is getting close. CONDSTORE doesn't
> >seem to have too much in the way of open issues. I'm not sure what
> >the state of ACL is. Do we have reason to meet in Minneapolis or not?
>
> I will take this silence to mean that we don't have to meet. Any objections?

I guess everybody want to go to Japan instead of Minneapolis ;-).
I have more unresolved issues with ACL and CONDSTORE I will submit to the
mailing list shortly.
I would like to ask people to share their opinion whether these documents are
ready for Last Call.

What happened to mailbox annotations and "ACL ids to Friendly Names" (the draft
that Chris was working on)?

I will be attending Minneapolis anyway, so I am curious who is going to attend.
Please reply privately.

Regards,
Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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-acl-03.txt
Date: Thu, 21 Feb 2002 07:01:33 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-acl-03.txt
	Pages		: 9
	Date		: 20-Feb-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-03.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-03.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-03.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-03.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 20 Feb 2002 21:45:44 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: ACL2
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Since ACL2 can be incompatible from ACL, we should define a replacement
identifier for "anyone" that does not conflict with a login id of "anyone".
As matters stand now, the text:
   [...] The identifier "anyone" is reserved to
   refer to the universal identity (all authentications, including
   anonymous).  All user name strings accepted by the LOGIN or
   AUTHENTICATE commands to authenticate to the IMAP server are reserved
   as identifiers for the corresponding user.
is self-contradictory.

Delete "PARTIAL" as a permitted operation of the "r" right.  PARTIAL is a
deprecated feature of RFC1730 which should now be extinct.

The "d" right should first be described as "RFC 2086 compatible delete right"
and then its semantics listed.  Unfortunately, the given semantics don't work.
What if one or more of the "x", "e", or "t" rights can not be set or cleared?
Suggest changing the MUST to SHOULD.  Consider deprecating the "d" right
entirely for an ACL2-only server.

Paragraph describing negative rights should make it clear that a negative
right is not the same thing as a DELETACL.

ACL2=MOST-SPECIFIC is a big improvement.  Is ACL2=UNION really still
necessary?  Wouldn't it be better to do this in the semantics of the naming?

Note that the addition of ACL2=MOST-SPECIFIC renders certain parts of my
proposed naming system moot.  However, there are other part of it which remain
desirable, including:
 . new commands to access and define groups
 . separate "world" vs. "anonymous" access

Date: Wed, 20 Feb 2002 17:45:33 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Arnt Gulbrandsen <[email-masked]>
CC: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2 backward compatability
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov <[email-masked]>
> > IMHO, only if a particular server implementation uses "$" prefix for groups and
> > other special identifiers.
>
> The draft lists the incompatibilities; should it also explictly recommend
> that servers advertise "ACL" if these incompatibilities don't apply in
> that server's case?

I've just added this to the version 03 I've sent yesterday.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

Date: Wed, 20 Feb 2002 11:06:54 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: Do we need to meet?
Sender: [email-masked]

On 2/14/02 at 5:11 PM -0600, I wrote:

>It looks to me that ANNOTATE is getting close. CONDSTORE doesn't 
>seem to have too much in the way of open issues. I'm not sure what 
>the state of ACL is. Do we have reason to meet in Minneapolis or not?

I will take this silence to mean that we don't have to meet. Any objections?

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

Date: Fri, 15 Feb 2002 19:02:14 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2 backward compatability
Sender: [email-masked]

Alexey Melnikov <[email-masked]>
> IMHO, only if a particular server implementation uses "$" prefix for groups and
> other special identifiers.

The draft lists the incompatibilities; should it also explictly recommend
that servers advertise "ACL" if these incompatibilities don't apply in
that server's case?

--Arnt

Date: Fri, 15 Feb 2002 10:31:02 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: ACL2 backward compatability
Sender: [email-masked]

Cyrus Daboo wrote:

> I think the current ACL2 draft has backwards compatibility with the old ACL
> draft wrt the the defined ACL bits. So should the current draft require
> servers to also advertise 'ACL' in the capability response as well as
> ACL2=xxx to allow existing ACL clients to interoperate? I would argue yes.

IMHO, only if a particular server implementation uses "$" prefix for groups and
other special identifiers.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

Date: Fri, 15 Feb 2002 10:51:29 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ACL2 backward compatability
Sender: [email-masked]

I think the current ACL2 draft has backwards compatibility with the old ACL
draft wrt the the defined ACL bits. So should the current draft require
servers to also advertise 'ACL' in the capability response as well as
ACL2=xxx to allow existing ACL clients to interoperate? I would argue yes.

-- 
Cyrus Daboo

Date: Fri, 15 Feb 2002 10:48:52 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ACL and STATUS
Sender: [email-masked]

The current ACL rfc and the latest draft for the updated version don't
indicate which ACL bit controls the behaviour of the STATUS command. I
would guess that at least read 'r' access is required in order to get
status information on a mailbox. Can we have STATUS explicitly listed as
one of the commands available for the 'r' bit?

The other option would be to allow status with only the 'l' bit, which
currently allows LIST/LSUB for a mailbox. If we ever get around to
extending list, I believe one of the proposals did have list returning the
equivalent of status information, so there might be some awkward
interaction with ACL on that.

-- 
Cyrus Daboo

Date: Thu, 14 Feb 2002 17:11:11 -0600
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Do we need to meet?
Sender: [email-masked]

It looks to me that ANNOTATE is getting close. CONDSTORE doesn't seem 
to have too much in the way of open issues. I'm not sure what the 
state of ACL is. Do we have reason to meet in Minneapolis or not?

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

Date: Tue, 05 Feb 2002 16:02:03 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: IMAP Extensions WG <[email-masked]>
Subject: Re: I-D ACTION:draft-melnikov-imap-condstore-06.txt
Sender: [email-masked]

This is the second revision submitted this year.

Changes from -05 to -06:
      1.  Replaced "/message/flags/system" with "/message/flags" to
          match ANNOTATE draft.
      2.  Extended FETCH/SEARCH/SORT syntax to allow for specifying
          whether an operation should be performed on a shared or a private
          annotation (or both).
      3.  Corrected several examples.

Changes from -04 to -05:
      1.  Added support for SORT extension.
      2.  Multiple language/spelling fixes by Randall Gellens.

There is one major open issue left:
    MODSEQ fetch response as the result of STORE/UID STORE of a flag in any IMAP
session: what _type_ of modseq should be returned: private, shared, both? This is
related to the change 2) between 05 and 06.

Comments?

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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

Date: Tue, 05 Feb 2002 11:00:10 -0700
From: Alexey Melnikov <[email-masked]>
Organization: ACI WorldWide / MessagingDirect
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-acl-02.txt
Sender: [email-masked]

A new revision is out. Major changes in this version:

1). Changed ACL capability name to ACL2=<access calculation rule ID>
Added registry for the rules. Described two rules: UNION (union of the positive minus union of negative),
MOST-SPECIFIC (most specific identifier describes the rights).

2). Added "t" right for performing STORE \Deleted. Changed "d" to be a macro for "x", "t" and "e".

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

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-acl-02.txt
Date: Tue, 05 Feb 2002 09:51:46 -0500
Sender: [email-masked]

--NextPart

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

	Title		: IMAP4 ACL extension
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-imapext-acl-02.txt
	Pages		: 9
	Date		: 04-Feb-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-02.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-02.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-02.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-02.txt

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

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

--OtherAccess--

--NextPart--