Subject: [Extra] Protocol Action: 'IMAP Extension for object identifiers' to Proposed Standard (draft-ietf-extra-imap-objectid-08.txt)

From: The IESG <[email-masked]>
Date: Mon, 06 Aug 2018 09:11:41 -0700

The IESG has approved the following document:
- 'IMAP Extension for object identifiers'
  (draft-ietf-extra-imap-objectid-08.txt) as Proposed Standard

This document is the product of the Email mailstore and eXtensions To Revise
or Amend Working Group.

The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/

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 document is based on 2 similar private extensions by Gmail and Dovecot.
  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

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 14 Aug 2018 02:35:45 -0400

Advance notice, I'm going to ask (either during auth48 or beforehand if there's a possibility) to add the following section to this document, based on feedback received on the mailing list which I failed to include, and based on reading Mark Nottingham's blog about interpreting requirements and what to do if you see something which the RFC says "MUST NOT" happen:

https://www.mnot.net/blog/2018/07/31/read_rfc

Sorry about the late notice!

I'm thinking something like this...

=====

Section: Advice to client implementers

In cases of server failure and disaster recovery, or misbehaving servers, it is  possible that a client will be sent invalid information (e.g. identical objectids, or objectids which have changed where they MUST NOT change according to this document).

In a case where a client detects inconsistent objectid responses from a server, it SHOULD fall back to relying on RFC3501 guarantees. For simplicity, a client MAY choose instead discard its entire cache  and resync all state from the server.

Client authors protecting against server misbehavior MUST ensure that their design can not get into an infinite loop of discarding cache and fetching the same data repeatedly without user interaction.

=====

Regards,

Bron.

On Tue, Aug 7, 2018, at 02:11, The IESG wrote:
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
> 

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Lynne Bartholomew <[email-masked]>
Date: Tue, 14 Aug 2018 08:23:34 -0700

Dear Bron,

Thank you for the heads-up.  We have flagged this in our database record for this document; it will be addressed when the document is edited.

RFC Editor/lb