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

[Bron Gondwana <[e-mail]>]

On Tue, Jul 3, 2018, at 20:34, Alexey Melnikov wrote:

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?

Sure thing :)

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?

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

    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?

Sure.

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]

Fixed!  Ta for noticing.

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?

Well, no more than anything is.

Any considerations for hash migration?

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

    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.

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

I think the reference to RFC 5256 is Normative, as it is required in

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" rel="nofollow">https://github.com/ietfextra/draft-gondwana-imap-uniqueid/commit/a3ea8193a0e7bffb21d81fc30a074bf8a1d7ae7a

Cheers,

Bron.

--

  Bron Gondwana, CEO, FastMail Pty Ltd

  [e-mail]