rfc-editor | 16 Jun 2006 02:41
Favicon

RFC 4551 on IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization


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

        
        RFC 4551

        Title:      IMAP Extension for Conditional STORE 
                    Operation or Quick Flag Changes Resynchronization 
        Author:     A. Melnikov, S. Hole
        Status:     Standards Track
        Date:       June 2006
        Mailbox:    Alexey.Melnikov <at> isode.com, 
                    Steve.Hole <at> messagingdirect.com
        Pages:      25
        Characters: 50265
        Updates:    RFC3501
        See-Also:   

        I-D Tag:    draft-ietf-imapext-condstore-09.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4551.txt

Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
a common IMAP mailbox.  Examples include different clients working on
behalf of 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) at any time.  An
example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.
(Continue reading)

Arnt Gulbrandsen | 22 Jun 2006 15:33
Picon
Favicon
Gravatar

4451


C: a select forbidden (condstore)
S: a NO the ACL says you can't (but I've enabled condstore for you, have 
a nice day)

Right?

Arnt

Dave Cridland | 22 Jun 2006 15:46

Re: 4451


On Thu Jun 22 14:33:26 2006, Arnt Gulbrandsen wrote:
> 
> C: a select forbidden (condstore)
> S: a NO the ACL says you can't (but I've enabled condstore for you, 
> have a nice day)
> 
> Right?

I think that's the correct server behaviour. However, if the client 
said "a select flimble (condstore blurdybloop)", and thus caused a 
BAD, enabling condstore would be incorrect, of course - so you can't 
enable condstore when you see it in the SELECT parameters.

I think the correct client behaviour is not to assume a failed 
command has enabled condstore.

Dave.
--

-- 
Dave Cridland - mailto:dave <at> cridland.net - xmpp:dwd <at> jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Arnt Gulbrandsen | 22 Jun 2006 16:12
Picon
Favicon
Gravatar

Re: 4451


Dave Cridland writes:
> I think that's the correct server behaviour. However, if the client 
> said "a select flimble (condstore blurdybloop)", and thus caused a 
> BAD, enabling condstore would be incorrect, of course - so you can't 
> enable condstore when you see it in the SELECT parameters.

Why not? A BAD command has no postconditions, AFAIK.

Arnt

Alexey Melnikov | 22 Jun 2006 16:19
Favicon

Re: 4451


Arnt Gulbrandsen wrote:

> Dave Cridland writes:
>
>> I think that's the correct server behaviour. However, if the client 
>> said "a select flimble (condstore blurdybloop)", and thus caused a 
>> BAD, enabling condstore would be incorrect, of course - so you can't 
>> enable condstore when you see it in the SELECT parameters.
>
> Why not? A BAD command has no postconditions, AFAIK.

Tagged BAD response means that there was no partial execution of the 
command.

Timo Sirainen | 24 Jun 2006 21:55
Picon
Picon
Favicon

Re: 4451

On Thu, 2006-06-22 at 15:33 +0200, Arnt Gulbrandsen wrote:
> C: a select forbidden (condstore)
> S: a NO the ACL says you can't (but I've enabled condstore for you, have 
> a nice day)

Is there a reason why you're even talking about ACLs here? Wouldn't this
be the same for non-existing mailboxes too?
Arnt Gulbrandsen | 25 Jun 2006 00:32
Picon
Favicon
Gravatar

Re: 4451


Timo Sirainen writes:
> On Thu, 2006-06-22 at 15:33 +0200, Arnt Gulbrandsen wrote:
>>  C: a select forbidden (condstore)
>>  S: a NO the ACL says you can't (but I've enabled condstore for you, 
>>  have a nice day)
>
> Is there a reason why you're even talking about ACLs here?

Not really - I just had to say something.

> Wouldn't this be the same for non-existing mailboxes too?

Should be.

Arnt


Gmane