Ballot for draft-ietf-httpapi-api-catalog
Yes
No Objection
No Record
Summary: Needs 3 more YES or NO OBJECTION positions to pass.
Thanks to Joey Salazar for her secdir review!
# Internet AD comments for draft-ietf-httpapi-api-catalog-06 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Nits ### S5.1, S5.5 * "./well-known/api-catalog" -> "/.well-known/api-catalog" ? * "https://www.example.net/./well-known/api-catalog" -> "https://www.example.net/.well-known/api-catalog" ? I may have misunderstood if these are intentional, as opposed to simply looking like typos...
# Gunter Van de Velde, RTG AD, comments for draft-ietf-httpapi-api-catalog-06 # Thanks for this document. It outlines a useful procedure. # I only got one non-blocking minor comment. In the document sometimes "API catalog" is used and sometimes "API Catalog ". I suspect that a consistent upper/lower case for catalog is intended?
# Éric Vyncke, INT AD, comments for raft-ietf-httpapi-api-catalog-06 Thank you for the work put into this document. As a frequent API user, this can only help developpers, thank you. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Darrel Miller for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Abstract In `APIs published by a given organisation or individual`, I wonder how can an individual publish an API, their server can of course but a human being ? What about simply "published API" ? ## Section 1 Very similar to my above comment, `An organisation or individual may ` ;-) Why not simply "application" or "server" ? ## Section 1.1 Suggest to add `human-readable documentation` in the examples of the appendix. ## Section 5.3 Wrong reference in `Section 4.1 below ` as 4.1 cannot be 'below' section 5.3 ;-) ## Section 4 I find this section really/too much open for a proposed standard as `Some suitable API Catalog document formats include` is followed by 6 possible ways and this list is not even exhaustive. Does it mean that implementations must support all ways ? All references in the bulleted list should be normative and not informative. ## Section 5.4 s/Heath/Availability/ as health also covers integrity and applicability. ## For the IETF tools-team Not for the authors, but it would be nice to have https://datatracker.ietf.org/.well-known/api-catalog ;-)