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

Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.

Mirja K├╝hlewind (was No Objection) Discuss

Discuss (2019-02-21 for -14)
Sorry, I earlier forgot one point I would like to quickly discuss:

The jmap service name registration only requests registration for tcp while H/3 could be used as well which will work over udp. Maybe it would be more future-proof to also add an entry for udp?

Further, there is a note that says that this registration will change an existing entry. Please note that for removing the existing entry, IANA might still need to contact the original assignee to ask for approval. However, this is just a processing issue and shouldn't lead to a real problem.

And finally a comment related to my above note about H/3, the document talks two times about "keeping the TCP connection open". To be future proof, I would maybe recommend to change the wording to "keeping the transport connection open".
Comment (2019-02-21 for -14)
Thanks for addressing the TSV-ART comments (and thanks to Allison for the review)!

One question regarding sec 9.4.1.:
How long should IANA wait for comments before the registration is performed?

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)
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"

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

Terry Manderson No Record