headers
Internet-Drafts | 1 Dec 2003 21:29
Picon
Favicon

I-D ACTION:draft-ietf-imapext-condstore-05.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 Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-ietf-imapext-condstore-05.txt
	Pages		: 16
	Date		: 2003-12-1
	
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
a common IMAP mailbox. Examples include different clients working on behalfof the same user, and multiple
users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for
messages within the mailbox. They must be able to guarantee that only one client can change message state
(e.g., message flags or annotations) at any time.  An example of such an application is use of an IMAP
mailbox as a message queue with multiple dequeueing clients.

The Conditional Store facility provides a protected update mechanism for message state information that
can detect and resolve conflicts between multiple writing mail clients.

This document defines an extension to IMAP (RFC 3501).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-05.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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 4 Dec 2003 21:38
Picon
Favicon

I-D ACTION:draft-ietf-imapext-sort-14.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		: INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSION
	Author(s)	: M. Crispin, K. Murchison
	Filename	: draft-ietf-imapext-sort-14.txt
	Pages		: 19
	Date		: 2003-12-4
	
This document describes the base-level server-based sorting and
threading extensions to the [IMAP] protocol.  These extensions
provide substantial performance improvements for IMAP clients which
offer sorted and threaded views.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-14.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-14.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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 5 Dec 2003 21:28
Picon
Favicon

I-D ACTION:draft-siemborski-imap-sasl-initial-response-02.txt

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

	Title		: IMAP Extension for SASL Initial Client Response
	Author(s)	: R. Siemborski
	Filename	: draft-siemborski-imap-sasl-initial-response-02.txt
	Pages		: 8
	Date		: 2003-12-5
	
To date, the Internet Message Access Protocol (IMAP) has used a
Simple Authentication and Security Layer (SASL) profile which always
required at least one complete round trip for an authentication, as
it did not support an initial client response argument.  This
additional round trip at the beginning of the session is
undesirable, especially when round trip costs are high.

This document defines an extension to IMAP which allows clients and
servers to avoid this round trip by allowing an initial client
response argument to the IMAP AUTHENTICATE command.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-siemborski-imap-sasl-initial-response-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-siemborski-imap-sasl-initial-response-02.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 8 Dec 2003 20:02
Picon
Favicon

Protocol Action: 'IMAP Extension for Conditional STORE operation' to Proposed Standard


The IESG has approved following document:

- 'IMAP Extension for Conditional STORE operation '
   <draft-ietf-imapext-condstore-05.txt> as a Proposed Standard

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

The IESG contact persons are Ned Freed and Ted Hardie.

Technical Summary

    Often, multiple IMAP clients need to coordinate changes to a common
    IMAP mailbox.  Examples include different clients for the same user,
    and multiple users accessing shared mailboxes. These clients
    need a mechanism to synchronize state changes for messages within the
    mailbox. They must be able to guarantee that only one client can 
change
    message state (e.g., message flags or annotations) at any time.  An
    example of such an application is use of an IMAP mailbox as a message
    queue with multiple dequeueing clients.

    The Conditional Store facility provides a protected update mechanism 
    for message state information that can detect and resolve conflicts 
    between multiple writing mail clients.

Working Group Summary

    This document is a product of the imapext working group.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rob Siemborski | 10 Dec 2003 23:19
Picon

Re: Yet another ACL Strawman


I realize I probably originally posted this at a bad time, directly after
everyone was returning from the IETF meeting... But are there further
comments/compliments/flames?

Is this something we are interested in pursuing or are we too far down our
current path already?

-Rob

On Fri, 14 Nov 2003, Rob Siemborski wrote:

>
> After the IMAPext meeting I spoke with some people and got to thinking if
> there was a way we could come up with a way to do IMAP sharing that will
> satisfy both the enterprise people who need detailed ACL support, and those
> who feel the need to implement permissions with limited backend support
> (e.g. UNIX file permissions).  Ideally, such a mechanism would be simple to
> implement and not have complexity problems getting past the IESG.
>
> I'd like to propose the following as a strawman INSTEAD of the
> current ACL2 draft (or whatever ACL2 became after the last round of
> comments):
>
> Create an ACL+ capability that does the following:
>
>   * Can only be advertised if ACL is advertised
>   * adds the x (DELETE mailbox), t (set \Deleted), and e (EXPUNGE)
> bits to ACL, and redefines the 'd' bit to "x && t && e" (like ACL2)
>
(Continue reading)

Permalink | Reply | 14 comments |
headers
Mark Crispin | 11 Dec 2003 04:34

Re: Yet another ACL Strawman


Hi Rob -

I've meant to answer your message, but I've kept on putting it off.

I observed some time ago that the issue isn't about ACL (access control
lists) but rather about access control.

Your proposal is a variation of something that I suggested quite some time
ago, which is to have a lightweight form of access control (which you call
PERMISSIONS), and ACL as a heavyweight form.  A server could support both,
so there would need to be some set of mapping and conflict resolution
rules.  At the time, this was opposed on the grounds that for many people,
lightweight would be good enough and it would preclude the widespread
deployment of ACL.

I am willing to revisit the issue.  However, I think that the people who
want a lightweight form should define what is in (and more importantly,
what is absent from!!) the lightweight form.

I agree with the desire to "do the minimum required to fix ACL".  I don't
think that it's quite as small as you'd like.  In particular I don't think
that a "fix" to ACL would leave UNION as the only access calculation rule.

Also, just as eliminating the need to support non-ACL access control
models in ACL2 would simplify ACL2, so would the elimination of RFC 2086
compatibility.

With this in mind, here's what I would consider a good alterative to the
current ACL2 document:
(Continue reading)

Permalink | Reply | 13 comments |
headers
Rob Siemborski | 20 Dec 2003 18:07
Picon

Re: Yet another ACL Strawman


On Wed, 10 Dec 2003, Mark Crispin wrote:

> I agree with the desire to "do the minimum required to fix ACL".  I don't
> think that it's quite as small as you'd like.  In particular I don't think
> that a "fix" to ACL would leave UNION as the only access calculation rule.

I'm willing to discuss this, the initial proposal didn't address it at
all, really.

> Also, just as eliminating the need to support non-ACL access control
> models in ACL2 would simplify ACL2, so would the elimination of RFC 2086
> compatibility.

I'm not convinced that this "simplifies" ACL2 much, other than eliminating
the need to tie the 'd' right.

> 1) We all agree that RFC 2086 is broken.  ACL is dead, long live ACL2 and
> PERMISSIONS.

I think we all agree that 2086 is broken now, or we wouldn't be talking
about ACL2.

> 2) ACL2 will not attempt to be compatible with RFC 2086.  It should be a
> redesign, and do what's right:
>  . I contend that MOST-SPECIFIC should be the *only* access calculation
>    rule, on the grounds that it makes ACLs easier for clients and users to
>    understand, and allows the removal of negative rights from the
>    specification.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Mark Crispin | 24 Dec 2003 23:38

Re: Yet another ACL Strawman


On Sat, 20 Dec 2003, Rob Siemborski wrote:
> > Also, just as eliminating the need to support non-ACL access control
> > models in ACL2 would simplify ACL2, so would the elimination of RFC 2086
> > compatibility.
> I'm not convinced that this "simplifies" ACL2 much, other than eliminating
> the need to tie the 'd' right.

If we have PERMISSIONS as a separate entity from ACL2, we can eliminate
tied rights in ACL2.  That is, a server that implements ACL2 must
implement all ACL2 rights as discreet entities.  Given that ACL2 is "all
or not at all", it can be made much simpler; and given that PERMISSIONS
exists as a lighter-weight model, it's alright that ACL2 be "all or not
all all".

> >  . I contend that MOST-SPECIFIC should be the *only* access calculation
> >    rule
> This makes it very hard or even impossible for a server to upgrade from
> ACL (using UNION).  To do so, you would need to calculate the rights at a
> given moment in time, and then re-advertise them.

I don't think that's really the case.  The server should be able to
calculate the ACL2 equivalent of ACL rights fairly easily.  Backwards
calculation will be harder to do reversibly, but the point is that we're
not trying to make that be perfect.

> > 4) The design of the lightweight mechanism should not preclude a server
> > implementation being able to support both lightweight and ACL2.
> I would hope that any server implementing ACL2 would be able to trivially
> implement any sort of "lightweight" system.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Pete Resnick | 28 Dec 2003 22:12

IMAP URL update?


On the LEMONADE list, Alexey mentioned that some folks had been 
talking about an update to the IMAP URL spec (RFC 2192) which would, 
perhaps among other things, add syntax to allow byte ranges for 
partial messages. Is anyone currently working on that or planning to 
work on it? I would like to refer to it in a document I am working on 
for LEMONADE.

pr
--

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 0 comments |
headers
Pete Resnick | 28 Dec 2003 22:14

Shall we meet in Seoul?


Who is going to be able to make it to Seoul? Do we have items about 
which we need to meet? Would a multicast session make a difference?

pr
--

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

Gmane