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

[Michael Slusarz <[e-mail]>]

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

On Mon, Nov 18, 2019, at 20:50, Bron Gondwana wrote:

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

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.

Dovecot response:

• Our previous thoughts: https://mailarchive.ietf.org/arch/msg/extra/9-hEpNOrcJryfMgMYkhrgqSPs8Q" rel="nofollow">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