headers
Internet-Drafts | 1 Apr 2005 22:24
Picon
Favicon

I-D ACTION:draft-ietf-imapext-annotate-13.txt

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		: IMAP ANNOTATE Extension
	Author(s)	: R. Gellens, C. Daboo
	Filename	: draft-ietf-imapext-annotate-13.txt
	Pages		: 41
	Date		: 2005-4-1
	
The ANNOTATE extension to the Internet Message Access Protocol
   permits clients and servers to maintain "metadata" for messages
   stored in an IMAP mailbox.

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 7 Apr 2005 20:05
Favicon

Re: 2086upd comments


Cyrus Daboo wrote:

> In rights table, use 'i' to indicate 'implicit' rights. e.g. for 
> FETCH, the 'r' right is implicit as that is needed to first SELECT the 
> mailbox. Alternatively, provide clear splits in the table for sections 
> based on IMAP state (unauthenticate, authenticated, selected)

I've split the table as you suggested and added the following note:

   Note: for all commands in the selected state the "r" is implied, because
         it is required to SELECT/EXAMINE a mailbox. Servers are not 
required
         to check presence of the "r" right once a mailbox is successfully
         selected.

I think this is the remaining issue I needed to address and I will post 
a new revision of the draft now.

Alexey
Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 7 Apr 2005 20:19
Favicon

Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt


Lisa Dusseault wrote:

> Don't forget the deliverables from the IETF this month, both new 
> drafts  and promised reviews... in addition to the deliverables below, 
> in order  to come up with new milestone dates, I need to get date 
> promises out of  the active draft authors (Cyrus, Randy, Barry, 
> Alexey) for LISTEXT,  ANNOTATE and 2086upd as well as ACL2.
>
> Lisa
>
> On Mar 10, 2005, at 1:53 PM, Lisa Dusseault wrote:
>
>> This is great.  I'll just use this opportunity to extract the  
>> deliverables:
>>  - Lisa to deliver recharter (new milestone dates) for WG
>>  - Alexey to produce new draft of 2086upd addressing last-call and  
>> post-last-call nits
>
Done.

>>  - Cyrus to produce new draft of annotate addressing last call 
>> issues  and incorporating decisions recorded in these minutes
>>  - Alexey and Barry to produce new draft of LISTEXT with no open or  
>> editorial issues remaining, suitable for last call
>>  - Alexey to produce syntax draft for Annotate to use
>
Done (revision -02 is out now, Cyrus is co-authoring).

>>  - Tony Hanson and Barry Leiba to review Chris's Comparator draft
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 8 Apr 2005 21:26
Picon
Favicon

I-D ACTION:draft-ietf-imapext-2086upd-04.txt

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-2086upd-04.txt
	Pages		: 0
	Date		: 2005-4-8
	
The ACL (Access Control List) extension (RFC 2086) of the Internet
   Message Access Protocol (IMAP4rev1) permits mailbox access control
   lists to be manipulated through the IMAP protocol.

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

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-2086upd-04.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Barry Leiba | 11 Apr 2005 19:55
Picon
Favicon

draft-ietf-imapext-list-extensions-12.txt

I have just sent the attached draft to the ID-editor.  It still has
three unresolved issues in it -- look for "[[" in the text
(corresponding to <cref> in the xml source).

I'll repeat them here, with my comments:

1:
      Note 2: When returning the CHILDINFO extended data item, it
      doesn't matter if the submailbox matches the canonical LIST
      pattern or not.  See also example 9 in Section 5.  [[anchor2: Is
      this really what we want?  Why?]]

This seems wrong to me, and I don't remember the discussion behind it.
Resolution of this also affects examples 9 and 10.

2:
   Servers SHOULD ONLY return a non-matching mailbox name along with
   CHILDINFO if at least one matching child is not also being returned.
   That is, servers SHOULD suppress redundant CHILDINFO responses.
   [[anchor3: Should this be a MUST?]]

This makes it a "quality of implementation" issue for the server,
acknowledging that some servers may have difficulty eliminating the
redundant entries (maybe requiring a subsequent pass through the
results to pick them out).  On the other hand, it makes the client do
it.  I'd rather turn it into MUST, but I don't think I can do that
unilaterally.

3:
   "vendor-token" is defined in [ACAP].  [[anchor4: This is an issue in
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark Crispin | 11 Apr 2005 20:06

Re: draft-ietf-imapext-list-extensions-12.txt


On Mon, 11 Apr 2005, Barry Leiba wrote:
>   Servers SHOULD ONLY return a non-matching mailbox name along with
>   CHILDINFO if at least one matching child is not also being returned.
>   That is, servers SHOULD suppress redundant CHILDINFO responses.
>   [[anchor3: Should this be a MUST?]]
> This makes it a "quality of implementation" issue for the server,
> acknowledging that some servers may have difficulty eliminating the
> redundant entries (maybe requiring a subsequent pass through the
> results to pick them out).  On the other hand, it makes the client do
> it.  I'd rather turn it into MUST, but I don't think I can do that
> unilaterally.

Without looking into how it would affect my server, I would still say that 
making it a MUST imposes an "unfunded mandate" on servers that may lead to 
this extension not getting implemented.

It seems to require the server to have a table of what it has sent, and 
for each proposed new item check to see if it is in the table.  Also, what 
if the new item has different status -- this is a particularly nasty 
problem brought about by the bizarre requirement that IMAP allow 
"dual-use" names that are both mailboxes and directories.

Clients, on the other hand, very likely already have a table into which 
they are inserting names from LIST; and as most of these tables tend to be 
sorted there is no particular overhead in dealing with duplicates.

-- Mark --

http://staff.washington.edu/mrc
(Continue reading)

Permalink | Reply | 1 comment |
headers
Barry Leiba | 11 Apr 2005 20:15
Picon
Favicon

Re: draft-ietf-imapext-list-extensions-12.txt


> Clients, on the other hand, very likely already have a table into
> which they are inserting names from LIST; and as most of these tables
> tend to be sorted there is no particular overhead in dealing with
> duplicates.

That's good enough to change my mind; I'm happy leaving it as it is and
taking out the comment.  Unless others want to violently argue, and
given that "SHOULD" is how the discussion had been going, that is what
I'll do, and I'll consider this item closed.

Barry

--
Barry Leiba, Pervasive Computing Technology  (leiba <at> watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 11 Apr 2005 21:42
Picon
Favicon

I-D ACTION:draft-ietf-imapext-list-extensions-12.txt

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

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

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

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 12 Apr 2005 12:16
Favicon

Re: 2086upd comments


Alexey Melnikov wrote:

> Cyrus Daboo wrote:
>
>> Section 6.1.2 - client cannot preserve an unknown tied right, when 
>> changing the known tied right. e.g. if we have tied rights 'r1', and 
>> the client does not understand '1', it must still be able to remove 
>> 'r' (and thus '1') without violating spec.
>
> The client should ask the user if she wants to either set both, or 
> remove both. That was the intent.
> The text is trying to say that the default should be to set both.
> This needs to be clarified.

The current text in -04 is:

   A client implementation that allows a user to read and update ACLs MUST
   preserve unrecognized rights that it doesn't allow the user to change
   when updating the rights. Otherwise the client could risk unintentionally
   removing permissions.

After thinking more about this, maybe the following text would be better:

   A client implementation that allows a user to read and update ACLs MUST
   preserve unrecognized rights that it doesn't allow the user to change.
   For example, if the server ties "r" and "1" and the client doesn't
   understand the "1" right, it should present the user with the choice
   (a dialog or a configuration option) to grant both rights or to revoke
   both rights. If the client can't do that, for example the client is not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Crispin | 20 Apr 2005 03:02

Extensions of ACL Extension (fwd)


I received the following message regarding ACL.  This should go into 
consideration as part of ACL2.

-- Mark --

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

---------- Forwarded message ----------
Date: Mon, 18 Apr 2005 09:36:47 +0200
From: Arnaud Taddei <Arnaud.Taddei <at> Sun.COM>
To: Mark Crispin <MRC <at> CAC.Washington.EDU>
Subject: Extensions of ACL Extension

Hi Mark, again me,

I have very very naive questions on the ACL extension.

Today with the ACL extension you can only manipulate a pair of
information which are:

     * an identifier
     * permissions (which are, btw, exclusively 'CMU' or 'AFS' alike,
       with the famous list of letters 'rlidwka').

Firstly, just at this level this is very painful because I would need to
manipulate a 'triplet' and not a 'pair' of information
(Continue reading)

Permalink | Reply | 0 comments |

Gmane