IMAP Extension for Object Identifiers
draft-ietf-extra-imap-objectid-08

Thank you for writing this - I'm really not an IMAP person, but the document seems to me to be useful and clear.

I do have a question - this is either for my education or something that needs fixing / clarification :-)
Section 4.  MAILBOXID object identifier
"The server SHOULD NOT change MAILBOXID when renaming a folder, as this loses the main benefit of having a unique identifier."
All of the above things in this section talk about keeping the MAILBOXID the same when doing things to the *mailbox*, this one instead talks about *folder*; what is the difference between mailbox and folder? I did spend some time looking and found:
"IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders." (RFC3501) - this didn't enlighten me much :-) Are the terms interchangeable here? If so, I'd suggest sticking with one term.
(Again, I'm not an IMAP person, this may all be obvious to those schooled in the art )

Section 4.1.  New response code for CREATE
Syntax: "MAILBOXID" SP "(" <objectid> ")"
Again, this may be obvious to IMAP people, but you may want to mention ABNF somewhere before this section (it is down in Section 7)

Tiny nit:
10.  IANA Considerations
For the second you say "with a Reference of [[THIS RFC]]." but not for the first - may be worth making them the same (hey, I did say 'twas a nit!)

Section 5.2:

"The THREADID data item is an objectid which uniquely identifies a set
   of messages which the server believes should be grouped together when
   presented.
	...
The server SHOULD return the same THREADID for related messages even
   if they are in different mailboxes."

"related" seems like a broader characterization than "messages which the server believes should be grouped together when presented," but I'm assuming they are meant to be equivalent. I think it would help to clarify this in the second sentence, i.e., that messages that would appear threaded if they were in the same mailbox SHOULD return the same THREADID even if they are in different mailboxes.

Section 8.1:

s/from the following set of 64 codepoints. a-z, A-Z, 0-9, '_', '-'./from the following set of 64 codepoints: a-z, A-Z, 0-9, '_', '-'./

This is pretty exciting to see; I hope that all of this, specifically
THREADID, gains traction!

Please use the RFC 8174 boilerplate instead of a custom variant.

Section 4

nit: s/invarients/invariants/

Section 5.3

Is this valid ABNF without quotes around the literals, SP, and whatnot?

Section 7

The comment lines seem to have been wrapped badly for some of these
stanzas.

Section 11

   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.  As the IDs are
   generated by the server, it will be possible to migrate to a new hash
   by just creating new IDs with the new algorithm. [...]

Perhaps reword to "by just using the new algorithm when creating new IDs";
the current wording could be misread to imply that the server should even
regenerate new IDs for existing messages (which is forbidden).

I guess we don't really need to discuss the case of a malicious server that
reuses IDs or returns incomplete search results, in this context.  But if 
we did, there are several things that could be said.

Section 13.1

Server-assigned sequence numbers can have some operational challenges with
respect to power outages, crashes, restore from backup, and the like, and
ensuring that the number is in fact globally unique.  I guess for this case
it's less catastrophic than it is for, e.g., leaf reuse in hash-based
signatures (RFC 8391), so maybe the risk does not need to be called out.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D7116



IMPORTANT
S 11.
>      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.
>   
>      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 don't understand this text. How does the client know whether a
digest was sued.

COMMENTS
S 7.
>      IMAP ABNF extensions [RFC4466] specifications.
>   
>      Except as noted otherwise, all alphabetic characters are case-
>      insensitive.  The use of upper- or lowercase characters to define
>      token strings is for editorial clarity only.  Implementations MUST
>      accept these strings in a case-insensitive fashion.

For clarity: IDs are not case insensitive, right? Because otherwise
the text below about differing  in case doesn't make sense.


S 8.1.
>   
>      o  ids which contain only digits
>   
>      o  ids which differ only by ASCII case (A vs a)
>   
>      o  the specific sequence of 3 characters NIL

Nit. Do you want to quote "NIL"?

The document has implementation considerations section - thank you for that. In the context of IETF 102 plenary discussions on running code - what would be the status and interoperability of existing implementations, if any? Could that be added to the abvementioned section?

The shepherd write-up says "7. There have been no IPR disclosures for this spec." which does not really answer point 7...