Ballot for draft-ietf-jmap-core
Yes
No Objection
Note: This ballot was opened for revision 14 and is now closed.
"Trusting AD"
Thanks for addressing my discuss and comment points.
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.
Thank you for addressing my comments on version 14.
Thank you for addressing my DISCUSS (and COMMENT!) points!
Thank you for addressing my DISCUSS
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?