Subject: [Extra] RFC on proposed RFC - CREATEDMODSEQ

From: Bron Gondwana <[email-masked]>
Date: Sat, 30 Jun 2018 14:13:03 +1000

Hi All,

I'm working on a doc (and implementation) for an extension to RFC7162 -
CREATEDMODSEQ.  It adds said field on both mailboxes and emails.
CREATEDMODSEQ will reference OBJECTID, and has the following properties:
1) When a mailbox is created, it gets the same CREATEDMODSEQ as the
   HIGHESTMODSEQ at time of creation (either == 1, or if the mailstore
   uses a single modseq counter for everything on a user, the next
   modseq for that user)
2) When a mailbox gets renamed, it retains the same CREATEDMODSEQ (so
   long as the MAILBOXID stays the same, it MUST, otherwise it SHOULD)
3) When an email is created, it gets the same CREATEDMODSEQ as the
   MODSEQ (== next modseq on that mailbox)
4) When an email is copied/moved, it depends on store behaviour - if
   mailboxes have different HIGHESTMODSEQ counters then it gets a new
   CREATEDMODSEQ for the new mailbox - but if they're part of the same
   modseq namespace, then it keeps the original CREATEDMODSEQ.
5) If an email gets a flag update only, the CREATEDMODSEQ MUST NOT
   be updated.
CREATEDMODSEQ becomes a STATUS response at the mailbox level.

CREATEDMODSEQ becomes a FETCH response at the email level.

I'd be very happy to see suggestions for different names so that they're
not confusable...
Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 30 Jun 2018 14:30:36 +1000

One more thing - I'm planning to reference the REPLACE extension with a
general statement along the lines of:
The server MAY set the CREATEDMODSEQ to a value lower than the MODSEQ on
an email in the case where it knows that it's an update to an existing
message rather than a new message, for example servers implementing the
REPLACE extension SHOULD retain the CREATEDMODSEQ of the replaced
message on the newly created message.
This means that a replacement of an existing draft with a new draft
won't look like a brand new message.
NOTE: I haven't thought about this maybe as much as I need to... so let me know if I'm being silly here...
Cheers,

Bron.

On Sat, Jun 30, 2018, at 14:13, Bron Gondwana wrote:
> Hi All,
> 
> I'm working on a doc (and implementation) for an extension to RFC7162
> - CREATEDMODSEQ.  It adds said field on both mailboxes and emails.
> CREATEDMODSEQ will reference OBJECTID, and has the following
> properties:> 
>    modseq for that user)> 
>    long as the MAILBOXID stays the same, it MUST, otherwise it SHOULD)> 
>    MODSEQ (== next modseq on that mailbox)> 
>    modseq namespace, then it keeps the original CREATEDMODSEQ.> 
> 5) If an email gets a flag update only, the CREATEDMODSEQ MUST NOT be
>    updated.> 
> I'd be very happy to see suggestions for different names so that
> they're not confusable...> 
> Cheers,
> 
> Bron.
> 
> --
> _________________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 30 Jun 2018 15:02:03 +0300

On 30 Jun 2018, at 7.13, Bron Gondwana <[email-masked]> wrote:
> 
> I'm working on a doc (and implementation) for an extension to RFC7162 - CREATEDMODSEQ.  It adds said field on both mailboxes and emails. 

What's your planned use case(s) for this? I can't really think of any.

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 30 Jun 2018 23:26:42 +1000

On Sat, Jun 30, 2018, at 22:02, Timo Sirainen wrote:
> On 30 Jun 2018, at 7.13, Bron Gondwana <[email-masked]> wrote:>> 
>> - CREATEDMODSEQ.  It adds said field on both mailboxes and emails.> 
So the main use-case I'm working with at the moment is "phone client
wants to create a notification to user of new mail, but NOT throw up a
new mail notification if the user just moved an email from Inbox to a
notified folder in another client".  So the phone client needs to be
able to distinguish "this message has newly arrived in the mailstore" vs
"this message has just been updated in some way".  This piece of data is
also being used in JMAP to underly the calculation for whether a message
(or thread) should be in the added or changed result.
And likewise for mailboxes, the createdmodseq on mailboxes is used to
distingish between "got renamed" and "newly created".
Bron.

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 1 Jul 2018 02:11:28 +0300

On 30 Jun 2018, at 16.26, Bron Gondwana <[email-masked]> wrote:
>> On 30 Jun 2018, at 7.13, Bron Gondwana <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> So the main use-case I'm working with at the moment is "phone client wants to create a notification to user of new mail, but NOT throw up a new mail notification if the user just moved an email from Inbox to a notified folder in another client".  So the phone client needs to be able to distinguish "this message has newly arrived in the mailstore" vs "this message has just been updated in some way".

This requires the global modseq space for it to work. Also, an alternative to this feature might be to just auto-add some $Copied / $Moved keyword..

> This piece of data is also being used in JMAP to underly the calculation for whether a message (or thread) should be in the added or changed result.

I tried quickly looking at the jmap spec to see what exactly these meant, but didn't find it. So I guess copying/moving would be better as "changed" then?  Again for the same reason of not showing notifications of copied/moved mails?

> And likewise for mailboxes, the createdmodseq on mailboxes is used to distingish between "got renamed" and "newly created".

Nice, but again I don't really see how clients would use this.