Ballot for draft-ietf-extra-imap-list-metadata
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Interesting idea, thanks for the work. Just a suggestion: also add in the example the LIST-METADATA capability negotiation ?
The document is reading reasonable well and gives understanding of the documented intent. There was one observation that made me consider a DISCUSS. I found no record of an IPR call in the EXTRA WG? This understanding is re-enforced by the shepherd writeup indicating only verbal "no IPR" from the authors. Not sure i looked at the correct WG to understand the IPR paper trail for this document. I was expecting to see a formal call for IPR for this document to all involved WGs, not only a verbal check with the authors.
Thanks for a short and easy to read document. Support Eric Vyncke's COMMENT.
Thank you to Behcet Sarikaya for the GENART review. ** Section 8.1. Nit. This document defines the "LIST-METADATA" IMAP capability to be added to the registry defined in Section 12.1 of [RFC9051]. Section 12.1 of RFC9051 didn’t define the “IMAP Capabilities” registry, it only updated it. RFC3501 created it. For clarity, name the registry this capability is being added to, “IMAP Capabilities”, and say that the reference column should be this document. ** Section 8.2 This section registers the "METADATA" option to be added to the registry defined in Section 9 of [RFC5258]. Section 9 of RFC5282 defines two registries. Please be explicit on which one. Based on the template used, it appears to be “LIST-EXTENDED Options” (https://www.iana.org/assignments/imap-list-extended/imap-list-extended.xhtml#imap-list-extended-1).
'tis been many many years since I've had to speak IMAP, but this does seem like useful functionality. I support Gunter's comment -- IPR calls should be done on-list, as people other than the authors may have IPR which needs to be disclosed (I didn't check the list archives myself, and am relying on Gunter's search)