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

[Ballot comment]
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?

[Ballot comment]
Thanks for the work that went into defining this mechanism -- it seems like a
very useful optimization. I have a few minor comments.

---------------------------------------------------------------------------

§7:

>    resp-text-code =/ "MAILBOXID" SP "(" objectid ")"
>            ; incorporated before the expansion rule of
>            ;  atom [SP 1*<any TEXT-CHAR except "]">]
>            ; that appears in [@!RFC3501]

The "<" and ">" in the preceding text should be replaced with literal
less-than and greater-than symbols.

---------------------------------------------------------------------------

§8.1:

>  An objectid is a string of 1 to 255 characters from the following set
>  of 64 codepoints. a-z, A-Z, 0-9, '_', '-'.

It would probably be helpful for implementors if this section indicated that
these are the same characters used by the "base64url" encoding defined in RFC
4648. Doing so will let implementors know that they can use existing
implementations of base64url to convert the output of a hash function into a
syntactically valid objectid.

---------------------------------------------------------------------------

§11:

>  The use of a digest for ID generation may be used as proof that a
>  particular sequence of bytes was seen by the server, however this is
>  only a risk if IDs are leaked to clients who don't have permission to
>  fetch the data directly.  Servers that are expected to handle highly
>  sensitive data should consider using a ID generation mechanism which
>  doesn't derive from a digest.

Couldn't this be addressed with a per-user salt value rather than a non-digest
identifier?

[Ballot comment]
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"?

[Ballot comment]
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, '_', '-'./

[Ballot comment]
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.

[Ballot comment]
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 "("  ")"
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!)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-extra-imap-objectid-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Internet Message Access Protocol (IMAP) Capabilities Registry located at:

https://www.iana.org/assignments/imap-capabilities/

a single, new capability name will be added as follows:

Capability Name: OBJECTID
Reference: [ RFC-to-be ]

Second, in the IMAP Response Codes registry located at:

https://www.iana.org/assignments/imap-response-codes/

a single, new Response Code is to be added to the registry as follows:

Response Code: MAILBOXID
Reference: [ RFC-to-be ]
Status description:

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-07-13):

From: The IESG
To: IETF-Announce
CC: Jiankang Yao , extra@ietf.org, yaojk@cnnic.cn, extra-chairs@ietf.org, alexey.melnikov@isode.com, draft-ietf-extra-imap-objectid@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IMAP Extension for object identifiers) to Proposed Standard


The IESG has received a request from the Email mailstore and eXtensions To
Revise or Amend WG (extra) to consider the following document: - 'IMAP
Extension for object identifiers'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-07-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document updates RFC3501 (IMAP4rev1) with persistent identifiers
  on mailboxes and messages to allow clients to more efficiently re-use
  cached data when resources have changed location on the server.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/ballot/


No IPR declarations have been submitted directly on this I-D.

Document Shepherd Write-Up for draft-ietf-extra-imap-objectid

1. This document is being requested as a Proposed Standard because it
updates an existing PROPOSED STANDARD (RFC3501).
The request type is indicated in the title page header.

2.

Technical Summary

This document updates RFC3501 (IMAP4rev1) with persistent identifiers
  on mailboxes and messages to allow clients to more efficiently re-use
  cached data when resources have changed location on the server.

Working Group Summary

  The EXTRA WG meeting in IETF 101 had detailed discussion about this draft. The editor had updated it accordingly.
  Before WGLC, several experts reviewed the draft in detail. All identified issues were reflected in the new version of the
  draft. During WGLC, a minor issue was identified and fixed in the new version.
  The WG has looked throught this document in detail.

Document Quality

  The document is in good shape and is ready to be published.
  The WG hopes to move this document quickly as IMAP4rev2 may want to include it.

Personnel

  Document Shepherd - Jiankang Yao (EXTRA co-chair)
  Responsible Area Director - Alexey Melnikov


3. The Document Shepherd has read the document through in detail and
think that it is ready to go.

4. There has no concerns.

5. There is no review required for the document by other areas, it's
very self-contained.

6. There are no concerns with this document that IESG should be aware of.

7. There have been no IPR disclosures for this spec.

8. There have been no IPR disclosures for this spec.

9. The WG consensus is very solid, while not everybody spoke, it was
clear that the entire group understood and agreed with the idea and
the method chosen.

10. There has been no discontent.

11. The ID nits tool shows the following:

No issues found here.

Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--).


12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. This RFC updates RFC3501.
RFC3501 has been listed on the title page header, listed in the abstract.
In the introduction, there has only one sentence which mentions

" [RFC3501] defines that a mailbox can be uniquely
  referenced by its name and UIDVALIDITY, and a message within that
  mailbox can be uniquely referenced by its mailbox (name +
  UIDVALIDITY) and UID."

but it does not clearly indicates which part of RFC3501 is updated by this document.
I think that the author might need to clarify it in the introduction of the future new version.


17. The IANA considerations ask for the following two items to be added to the registry:

  IANA is requested to add "OBJECTID" to the "IMAP Capabilities"
  IANA is requested to add "MAILBOXID" to the "IMAP Response Codes"
 

18. None of the IANA registries mentioned require Expert Review.

19. The formal sections are simple enough that eyeball reading
was sufficient to validate them.