Subject: Re: [imapext] WGLC on QRESYNC, Ending 6th December.

From: Dave Cridland <[email-masked]>
Date: Wed, 4 Dec 2013 08:41:26 +0000

Reminder: This WGLC closes in just two days.

If you have reviewed the draft, and have no comments, please let us know.

If you have not reviewed the draft, please do so.

On Fri, Nov 22, 2013 at 1:54 PM, Dave Cridland <[email-masked]> wrote:

> Folks,
>
> This begins a two week last call period for
> draft-ietf-qresync-rfc5162bis-03.txt.  Please submit any comments you have
> on or before 6th December 2013.
>
> I know we have some reviews in progress, we'll deal with the results of
> those as they arrive.
>
> Thanks,
>
> Dave.
> (Ex Cathedra)
>

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 06 Dec 2013 10:59:46 +1100

I'm sorry I haven't taken the time to do a really thorough reading of
the latest draft earlier!

I've noted a couple of spots that I should double-check the Cyrus
implementation.

I notice that METADATA/ANNOTATE-EXPERIMENT-1 aren't addressed at all.
That certainly makes things simpler, but for those of us who _do_
implement it... I'm just treating it exactly like like flags - any
change to anything updates the entire message MODSEQ.  We're not
keeping separate MODSEQ values on annotations (yet).

I only have one significant worry - and it starts in section 3.2.  The
UNCHANGEDSINCE atomicity requirements are only on a single keyword at a
time.

So starting here:

"If the mod-sequence of any metadata item on the message is equal to or
less than... then the requested operation is performed"

My reading of that (any rather than every) is that you could do this:

C: TAG STORE 5 (UNCHANGED SINCE 5674) +FLAGS.SILENT ($FlagA $FlagB)

on a server which stores separate per-flag modseq, and get this
response:

S: * 5 FETCH (UID 23 MODSEQ (5801) FLAGS ($FlagA))

S: TAG OK [MODIFIED 5] Conditional Store failed

Where $FlagA gets set, but another session had set/removed $FlagB
already.

-----

Here's a real world example.  A client uses the following keywords:
Junk NotJunk JunkRecorded.  When it marks a message a junk it sets both
JunkRecorded and ONLY ONE of Junk or NotJunk.

A brand new mailbox has one message.

S: * 1 FETCH (UID 1 MODSEQ (1) FLAGS ())

The first client marks the message as Junk

C: a01 STORE 1 (UNCHANGED SINCE 1) +FLAGS (Junk JunkRecorded)

S: * 1 FETCH (UID 1 MODSEQ (2) FLAGS (Junk JunkRecorded))

S: TAG OK Conditional Store completed

And a second client marks the message as NonJunk

C: a01 STORE 1 (UNCHANGED SINCE 1) +FLAGS (NonJunk JunkRecorded)

S: * 1 FETCH (UID 1 MODSEQ (3) FLAGS (Junk JunkRecorded NonJunk))

S: TAG OK [Modified 1] Conditional Store failed

.... clearly the end result is bogus - but this is what I see as the
logical result of allowing partial metadata updates to succeed
"atomically" when other metadata was unchanged.  In this case the
'NonJunk' flag was unchanged since MODSEQ 1 - and the 'JunkRecorded'
flag, which was supposed to protect against this problem, has failed.

Am I reading it wrong?

I would be a lot more comfortable if all metadata about a message was
unchanged if ANY of the requested operations were disallowed by the
UNCHANGEDSINCE rule.

(none of this applies in Cyrus, which only stores on MODSEQ per
message... but I still worry)

Regards,

Bron.

On Wed, Dec 4, 2013, at 07:41 PM, Dave Cridland wrote:

If you have reviewed the draft, and have no comments, please let us
know.

On Fri, Nov 22, 2013 at 1:54 PM, Dave Cridland <[1][email-masked]>
wrote:

Folks,

This begins a two week last call period for
draft-ietf-qresync-rfc5162bis-03.txt.  Please submit any comments you
have on or before 6th December 2013.

Thanks,

Dave.
(Ex Cathedra)

_______________________________________________

imapext mailing list

[2][email-masked]

[3]https://www.ietf.org/mailman/listinfo/imapext

--
Bron Gondwana
[email-masked]

References

1. mailto:[email-masked]
2. mailto:[email-masked]
3. https://www.ietf.org/mailman/listinfo/imapext

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Dec 2013 11:03:02 +0000

Hi Bron,
Thank you for your comments.

> keeping separate MODSEQ values on annotations (yet).

There seem to be an emerging consensus that a mailbox metadata change 
should update mailbox's HIGHESTMODSEQ (ANNOTATE-EXPERIMENT-1 is already 
covered, at least that was the intent), so I will do this change to the 
document.

  [I will reply to the rest of your review separately]

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 14 Dec 2013 23:33:55 +0000

On 05/12/2013 23:59, Bron Gondwana wrote:

> I only have one significant worry - and it starts in section 3.2. 
> /*The UNCHANGEDSINCE atomicity requirements are only on a single 
> keyword at a time.*/
> So starting here:
> "If the mod-sequence of any metadata item on the message is equal to 
> or less than... then the requested operation is performed"
Thank you for pointing this out. I agree that this is wrong, I think it 
should read:

   If the mod-sequence of every metadata item of the message affected by 
the STORE/UID STORE is equal to or less ...

> on a server which stores separate per-flag modseq, and get this response:
> Where $FlagA gets set, but another session had set/removed $FlagB already.
> -----
> Junk NotJunk JunkRecorded.  When it marks a message a junk it sets 
> both JunkRecorded and ONLY ONE of Junk or NotJunk.
As per above, I think only affected metadata items should be considered.

---

From: Bron Gondwana <[email-masked]>
Date: Sun, 15 Dec 2013 11:18:06 +1100

On Sun, Dec 15, 2013, at 10:33 AM, Alexey Melnikov wrote:

So starting here:

That works for me.

As per above, I think only affected metadata items should be
considered.

I'm happy with that as the hard requirement.  Of course if a server
checks everything and rejects, it's just less efficient - because the
client has to re-fetch all the metadata before trying to apply the
change.  It won't break things.  We're talking something which is
(hopefully) very rare anyway - but it's important to fail safe :)

Bron.

--
Bron Gondwana
[email-masked]