[Gen-art] Genart last call review of draft-ietf-extra-imap-objectid-03

[Pete Resnick <[e-mail]>]

Reviewer: Pete Resnick
Review result: Almost Ready

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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

Summary:

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:

OLD
    the backends will not use the same identifiers for different objects

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

§8.3

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

§5

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")