Subject: [Extra] In favour of OBJECTID being inculded in IMAP4REV2 - please reply by Friday!

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 18 Nov 2019 20:50:41 +1100

In today's EXTRA meeting at IETF106, I argued in favour of including OBJECTID into IMAP4REV2. I'm arguing again here.

Please comment on this thread - both in favour and particularly if you're against this.

Ideally, if you could reply to this email by *8am Friday Nov 22 Singapore time* then the guidance will be in place before Alexey and Barry have their editing session.

I think having OBJECTID required is valuable because:
* it allows much better caching on clients
* many servers already have a unique ID stored internally for each item

Also - if your server doesn't store a value and doesn't have anywhere to cache it, it can fall back to this algorithm:

 - MAILBOXID: digest(mboxname,uidvalidity)
 - EMAILID: digest(mboxname,uidvalidity,uid)
 - THREADID: NIL

Or if it does have a way to cache, it can do that, and then keep the first value on copy/rename - since that value can never be used again. And if you lose the cache, you lose the cache - and it's not the end of the world, because the new value calculated from the new mboxname/uidvalidity[/uid] will also be unique.

In the minutes I suggested THREADID == EMAILID, so every email is its own thread (which is legal) but RFC8474 does allow for NIL, and that's probably better (client knows that the server isn't threading).

I'd like to see this included in imap4rev2 and I think it won't disadvantage implementation significantly, but will make new clients better over time. (and as Neil pointed out, you already need it for JMAP).

Cheers,

Bron.

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

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 20 Nov 2019 18:49:34 +1100

I was reminded off list that the final text in RFC8474 made it MUST be the same value, so it's not as easy as all that to have the objectid change on MOVE or RENAME and be totally compliant.

Some options:
1) insist on remaining exactly compliant.
2) include RFC8474 naming and behaviour in IMAP4REV2 but weaken the MUSTs around keeping IDs the same.
3) OK, leave OBJECTID as optional and don't include it in IMAP4REV2.

Opinions?

Bron.

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 20 Nov 2019 15:55:26 +0800

> 2) include RFC8474 naming and behaviour in IMAP4REV2 but weaken the MUSTs around keeping IDs the same.

I am not in favour of this. It basically removes the whole point of OBJECTID. If it's mandatory, you need to implement it properly. Either mandatory or not is fine (I'd prefer it in, but worth consulting implementors), but let's not change its semantics.

Neil.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 20 Nov 2019 12:47:14 +0100

On Wednesday 20 November 2019 08:55:26 CET, Neil Jenkins wrote:
> I am not in favour of this. It basically removes the whole 
> point of OBJECTID. If it's mandatory, you need to implement it 
> properly. Either mandatory or not is fine (I'd prefer it in, but 
> worth consulting implementors), but let's not change its 
> semantics.

Does it really remove the whole point? I see two kinds of MUSTs:

  Two equal IDs MUST refer to they same object
  Two different IDs MUST refer to different objects

The former has to be a MUST, but the latter could be downgraded to SHOULD 
and still leave significant value.... unless I'm overlooking something?

Arnt

---

From: Michael Slusarz <[email-masked]>
Date: Wed, 20 Nov 2019 10:58:41 -0700 (MST)

On November 20, 2019 12:49 AM Bron Gondwana <[email-masked]> wrote:

Some options:

Dovecot response:

Our previous thoughts: https://mailarchive.ietf.org/arch/msg/extra/9-hEpNOrcJryfMgMYkhrgqSPs8Q

New thoughts: MAILBOXID/EMAILID is ok for rev2

Dovecot already tracks this internally, so we have work-in-progress code to expose this already

Agree that MAILBOXID/EMAILID should not be "fake", but should be persistent - a server should do this right, rather than trying to fake it with on-demand digest generation.  So I think this is a vote for #1 of Bron's options.  This requirement (assigning a non-ephemeral uniqueid per message/mailbox) doesn't seem any more onerous than keeping a UID associated with a specific message.

THREADID comment from Timo (so he can expand on this, if needed): "I wonder if it would be ok to have MAILBOXID and EMAILID in the base spec, while THREADID would exist only if OBJECTID capability exists. Slightly nicer than just returning NILs as THREADIDs."

michael

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 22 Nov 2019 14:10:32 +1100

Thanks Michael,

I've discussed this with Alexey and Barry today, and we've decided not to *require* OBJECTID in the base spec, but to add a section of "recommended other extensions" to the base spec which mentions the benefits of implementing OBJECTID.

Bron.

>  * Our previous thoughts: https://mailarchive.ietf.org/arch/msg/extra/9-hEpNOrcJryfMgMYkhrgqSPs8Q
>  * New thoughts: MAILBOXID/EMAILID is ok for rev2
>  * Dovecot already tracks this internally, so we have work-in-progress code to expose this already
>  * Agree that MAILBOXID/EMAILID should not be "fake", but should be persistent - a server should do this right, rather than trying to fake it with on-demand digest generation. So I think this is a vote for #1 of Bron's options. This requirement (assigning a non-ephemeral uniqueid per message/mailbox) doesn't seem any more onerous than keeping a UID associated with a specific message.
>  * THREADID comment from Timo (so he can expand on this, if needed): "I wonder if it would be ok to have MAILBOXID and EMAILID in the base spec, while THREADID would exist only if OBJECTID capability exists. Slightly nicer than just returning NILs as THREADIDs."
> michael 
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
>