Shepherd writeup
rfc8474-08

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.
Back