Last Call Review of draft-ietf-extra-imap-objectid-03

Request Review of draft-ietf-extra-imap-objectid
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-07-13
Requested 2018-06-29
Authors Bron Gondwana
Draft last updated 2018-07-14
Completed reviews Secdir Last Call review of -04 by Chris Lonvick (diff)
Genart Last Call review of -03 by Pete Resnick (diff)
Genart Telechat review of -06 by Pete Resnick (diff)
Assignment Reviewer Pete Resnick
State Completed
Review review-ietf-extra-imap-objectid-03-genart-lc-resnick-2018-07-14
Reviewed rev. 03 (document currently at 08)
Review result Almost Ready
Review completed: 2018-07-14


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-extra-imap-objectid-03
Reviewer: Pete Resnick
Review Date: 2018-07-14
IETF LC End Date: 2018-07-13
IESG Telechat date: Not scheduled for a telechat


I've got a few concerns about the document, but it is almost ready. I hope these can be addressed easily. (Also, my apologies for being a day late, though hopefully not a dollar short. I also apologize for being a GenART reviewer who happens to know the topic area, but hasn't been following the WG; you would have had an easier time with someone else.  ;-) )

Major issues:

§4 ¶2

I don't believe this ought to be a SHOULD. While the document explains that this allows for disaster recovery, I don't understand what sort of disaster would allow the server to preserve UIDVALIDITY and name, yet not be able to preserve MAILBOXID. If you're talking about things like re-building a crashed disk, that doesn't justify downgrading the MUST: Even though 5321 says that the server MUST take responsibility for the message after delivering the 200, if lightning strikes immediately after writing the message to disk and scrapes just those sectors, that's not something that an implementer SHOULD anticipate.

This sort of softening also has the horrible side-effect (as do many other things in IMAP) of not allowing a client to properly depend on the feature: If a server is permitted, for whatever reasons it believes are really strongly justified, reset MAILBOXIDs, clients will have to keep using name + UIDVALIDITY, even if the capability is advertised. That's bogus.

Please either explain the justification for this SHOULD better, or simply change it to a MUST and remove the bit about disaster recovery.

§4 ¶5

Why would this be allowed? If you can't preserve MAILBOXID across RENAMEs, there's no point in advertising this capability.

§5.1 ¶2

See above on §4 ¶2.

Minor issues:

§5.1 ¶3&4

I think you need to add an explanation here that there is no way to use MAILBOXID with a STORE command or other similar ones, and there never will be a way (unless you really want to be able to all occurrences of a message across all mailboxes). Maybe this goes in §9.

§8.2 ¶2

Why isn't it advisable (or even RECOMMENDED) that *all* object identifiers (not just MAILBOXID) be globally unique? Seems like the recommendation applies to all of them.

In the example, it is plausible that an OBJECTID proxy could rewrite identifiers to avoid conflicts (e.g., append "-from-servername" to each identifier). So I think it would be clearer to say:

    the backends will not use the same identifiers for different objects

    different objects never use the same identifiers, even if backend system have identifiers that collide


I'm not clear on the SHOULDs in this section. These seem like perfectly good operational guidance statements, but not interoperability requirements. I say lowercase them.

Nits/editorial comments: 

§1 ¶3

s/If a mailbox is successfully renamed, the client knows/If a mailbox is successfully renamed by a client, that client will know


No need for the sentence at the top of this section. Just go right to 5.1.

§5.2 ¶5

The sentence is ungrammatical ("to in all")