JSON Meta Application Protocol
draft-ietf-jmap-core-17

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)
Thank you for addressing my DISCUSS (and COMMENT!) points!

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2019-02-20 for -14)
"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)
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.

Martin Vigoureux No Objection