The JSON Meta Application Protocol (JMAP)
RFC 8620
Note: This ballot was opened for revision 14 and is now closed.
(Alexey Melnikov) Yes
(Ignas Bagdonas) No Objection
Deborah Brungard No Objection
(Ben Campbell) No Objection
Comment (2019-03-05 for -15)
Thank you for addressing my comments on version 14.
Alissa Cooper (was Discuss) No Objection
Comment (2019-03-04 for -15)
Thank you for addressing my DISCUSS questions. Original COMMENT is below. = Section 1.1 = Please use the RFC 8174 boilerplate instead of the RFC 2119 boilerplate. = Section 2= s/To avoid conflict, the identifiers for these MUST be a URL with a domain owned by the vendor./To avoid conflict, an identifier for a vendor-specific extension MUST be a URL with a domain owned by the vendor./ = Section 8 = Depending on the outcome of the discussion related to the DISCUSS point above, I think it would be appropriate to describe or even normatively require client ID construction such that client IDs are opaque and can change over time at the client's choosing.
(Spencer Dawkins) No Objection
Benjamin Kaduk (was Discuss) No Objection
Comment (2019-03-08 for -16)
No email
send info
send info
Thank you for addressing my DISCUSS (and COMMENT!) points!
(Suresh Krishnan) No Objection
Warren Kumari No Objection
Comment (2019-02-20 for -14)
No email
send info
send info
"Trusting AD"
(Mirja Kühlewind) (was Discuss, No Objection) No Objection
Comment (2019-03-23)
Thanks for considering my discuss! Thanks for addressing the TSV-ART comments (and thanks to Allison for the review)! ---------------------------- Old comment (for the record): ---------------------------- One question regarding sec 9.4.1.: How long should IANA wait for comments before the registration is performed?
(Eric Rescorla) (was No Record, Discuss) No Objection
Comment (2019-03-06 for -15)
No email
send info
send info
Thank you for addressing my DISCUSS
Alvaro Retana No Objection
(Adam Roach) (was Discuss) No Objection
Comment (2019-03-01 for -15)
Thanks for addressing my discuss and comment points.