Subject: [Extra] AD review of draft-ietf-extra-imap-objectid-03

From: Alexey Melnikov <[email-masked]>
Date: Tue, 3 Jul 2018 11:33:44 +0100

Hi all,
This document is in a good state, so I've started the IETF LC on it.

In the meantime, here are some comments for discussion:

Last para of Section 1:

    This extension also adds an optional thread identifier (THREADID) to
    messages, which can be used by the server to indicate messages which
    it has identified to be related.

Can you provide any advice here for a server implementation that doesn't 
implement THREAD extension?

2nd para of Section 5.1:

    The server SHOULD return the same EMAILID for the same UID triple.
    As with MAILBOXID above, this is almost a MUST, but allows for the
    possibility of loss of OBJECTID data in disaster recovery without

Did you mean EMAILID above?

    having to change UIDVALIDITY.

Next to the last para in Section 5.2:

    THREADID is optional, if the server is unable to calculate
    relationships between messages,

Or if THREAD extension is not supported? Maybe call this out explicitly?

    it MUST return NIL to in all FETCH
    responses for the THREADID data item, and a SEARCH for THREADID MUST
    NOT match any messages.

In Section 7:

    fetch-threadid-resp = "THREADID" SP "(" objectid ")" / "THREADID NIL
    ; follows tagged-ext production from [RFC4466]

This is not syntactally valid (missing terminating <">). I think it 
should be:

    fetch-threadid-resp = "THREADID" SP "(" objectid ")" / "THREADID" SP NIL
    ; follows tagged-ext production from [RFC4466]

In Section 11, 2nd and 3rd paras:

    If a digest is used for ID generation, it must have a collision
    resistent property, so server implementations are advised to monitor
    current security research and choose secure digests.

This all sounds nice, but is it actually actionable?

Any considerations for hash migration?

    The use of a digest for ID generation may be used as proof that a
    particular sequence of bytes was seen by the server.

I think you might want to expand on what actions should be taken or what 
conclusions should be done here.

I think the reference to RFC 5256 is Normative, as it is required in 
order to understand threading.

Best Regards,
Alexey

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 05 Jul 2018 03:01:35 -0400

> implement THREAD extension?

Sure thing :)

> Did you mean EMAILID above?

No, but as the wording is unclear and confusing, I've just ditched it.

> Or if THREAD extension is not supported? Maybe call this out explicitly?

Sure.

>     ; follows tagged-ext production from [RFC4466]

Fixed!  Ta for noticing.

> This all sounds nice, but is it actually actionable?

Well, no more than anything is.

> Any considerations for hash migration?

luckily it's pretty easy :)  But have added some text.

> conclusions should be done here.

Ick... yeah, it's hard to give general advice.  Digest is handy in a bunch of situations, but enumerating all possible risks is tricky.

> order to understand threading.

Easy peasy!

Thanks Alexey,

Version -04 attached.  Sadly the draft submission tool is currently closed in anticipation of IETF102, so I can't submit it yet.  The commit is in git as well:

https://github.com/ietfextra/draft-gondwana-imap-uniqueid/commit/a3ea8193a0e7bffb21d81fc30a074bf8a1d7ae7a

Cheers,

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