mailing list archives

Hello,

From RFC4551 Introduction: "The server MUST guarantee that each STORE
command performed on the same mailbox ... will get a different mod-sequence
value."

Can someone explain why the uniqueness requirement is necessary for the
modification sequence?  If two metadata items/messages are modified
transactionally and share the same mod-sequence I don't really see any way
that will break any of the proposed IMAP protocol changes for CONDSTORE (as
long as they are updated atomically and a client can't sync between when a
first item gets a mod-sequence and a second item gets the same
mod-sequence).

Thanks for your time,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20120320/f2e27c24/attachment.html>

> From RFC4551 Introduction: "The server MUST guarantee that each STORE
> command performed on the same mailbox ... will get a different
> mod-sequence value."
> 
> Can someone explain why the uniqueness requirement is necessary for
> the modification sequence? If two metadata items/messages are
> modified transactionally and share the same mod-sequence I don't
> really see any way that will break any of the proposed IMAP protocol
> changes for CONDSTORE (as long as they are updated atomically and a
> client can't sync between when a first item gets a mod-sequence and
> a second item gets the same mod-sequence).

I *think* that you're incorrectly interpreting "each STORE command" as
"each message affected by a STORE command".  The following command is
one STORE command, not ten:

   A001 STORE 1:10 +FLAGS (\Deleted)

Your single transactional modification of those ten messages is allowed
to use the same mod-sequence value.

- Dan

On Tue, Mar 20, 2012 at 1:42 PM, Dan Karp <dkarp@zimbra.com> wrote:

> > From RFC4551 Introduction: "The server MUST guarantee that each STORE
> > command performed on the same mailbox ... will get a different
> > mod-sequence value."
> >
> > Can someone explain why the uniqueness requirement is necessary for
> > the modification sequence? If two metadata items/messages are
> > modified transactionally and share the same mod-sequence I don't
> > really see any way that will break any of the proposed IMAP protocol
> > changes for CONDSTORE (as long as they are updated atomically and a
> > client can't sync between when a first item gets a mod-sequence and
> > a second item gets the same mod-sequence).
>
> I *think* that you're incorrectly interpreting "each STORE command" as
> "each message affected by a STORE command".  The following command is
> one STORE command, not ten:
>
>   A001 STORE 1:10 +FLAGS (\Deleted)
>
> Your single transactional modification of those ten messages is allowed
> to use the same mod-sequence value.
>

Ok that's fine for STORE but what about other actions that may modify
multiple messages at once (say inserting/deleting mails from the mailbox
OOB with IMAP).  Sounds like what really the RFC is getting at is that each
MODSEQ value must be a transactional state, that clients will always see
all changes for a given MODSEQ (i.e. multiple FETCH MODSEQ should always
return the same results, nothing new).

For example, conversely, if that single "STORE 1:10 +FLAGS (\Deleted)" used
the same MODSEQ for all 10 messages and the client could "FETCH MODSEQ"
multiple times while the modification was executing and see new results on
subsequent attempts, that should be disallowed.

Thanks.


>
> - Dan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20120320/6300ca38/attachment.html>

On 20/03/2012 20:42, Dan Karp wrote:
>>  From RFC4551 Introduction: "The server MUST guarantee that each STORE
>> command performed on the same mailbox ... will get a different
>> mod-sequence value."
>>
>> Can someone explain why the uniqueness requirement is necessary for
>> the modification sequence? If two metadata items/messages are
>> modified transactionally and share the same mod-sequence I don't
>> really see any way that will break any of the proposed IMAP protocol
>> changes for CONDSTORE (as long as they are updated atomically and a
>> client can't sync between when a first item gets a mod-sequence and
>> a second item gets the same mod-sequence).
> I *think* that you're incorrectly interpreting "each STORE command" as
> "each message affected by a STORE command".  The following command is
> one STORE command, not ten:
>
>     A001 STORE 1:10 +FLAGS (\Deleted)
>
> Your single transactional modification of those ten messages is allowed
> to use the same mod-sequence value.
This is correct.

As long as no client ever gets to see MODSEQ 1000 for two different
states (such as another client's half-completed command and the same
command fully completed), everything is fine.

Arnt

On Wed, Mar 21, 2012, at 11:17 AM, Arnt Gulbrandsen wrote:
> As long as no client ever gets to see MODSEQ 1000 for two different
> states (such as another client's half-completed command and the same
> command fully completed), everything is fine.

That's certainly how I see it.  In the extreme, you could even lazily
allocate MODSEQ only when a client requests the information (including,
obviously, a MODSEQ enabled client doing a change and expecting a new
HIGHESTMODSEQ in the response)

But any non-MODSEQ based access to the store could not bump it at all,
so long as the next time a MODSEQ enabled client connected, the MODSEQ
got allocated to all changed things since then.

At least, I can't see how any client could know the difference, or be
right in caring.  The only points in time it can know about are right
now, and last time it did a read and got a MODSEQ out of it.  Ordering
of the MODSEQs within that are unimportant (to this particular client)

Bron.
-- 
  Bron Gondwana
  brong@fastmail.fm

On 03/21/2012 02:01 PM, Bron Gondwana wrote:
> But any non-MODSEQ based access to the store could not bump it at all,
> so long as the next time a MODSEQ enabled client connected, the MODSEQ
> got allocated to all changed things since then.

Now you have a 64-bit number which changes seldom and a single-bit
variable per message which goes to one for any change and to zero for
any modseq allocation. That does not make much sense to me.

Arnt

On Wed, Mar 21, 2012, at 03:43 PM, Arnt Gulbrandsen wrote:
> On 03/21/2012 02:01 PM, Bron Gondwana wrote:
> > But any non-MODSEQ based access to the store could not bump it at all,
> > so long as the next time a MODSEQ enabled client connected, the MODSEQ
> > got allocated to all changed things since then.
> 
> Now you have a 64-bit number which changes seldom and a single-bit
> variable per message which goes to one for any change and to zero for
> any modseq allocation. That does not make much sense to me.

No - it's pretty silly for sure.  But if you're writing a server which
serves a Maildir which may also be updated by local clients which are
totally IMAP unaware, you're basically restricted to noticing that
"the following things changed".

Bron.
-- 
  Bron Gondwana
  brong@fastmail.fm