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

["Bron Gondwana" <[e-mail]>]

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
 [e-mail]