Building Blocks for HTTP APIs

Note: This ballot was opened for revision 00-00 and is now closed.

Ballot question: "Is this charter ready for external review?"

Barry Leiba Yes

Deborah Brungard No Objection

Alissa Cooper (was Block) No Objection

Comment (2020-09-11 for -00-02)
Thanks for addressing my comments.

Roman Danyliw No Objection

Comment (2020-09-09 for -00-00)
** (Like Martin and Alissa) I’m having trouble discriminating what work comes to HTTPbis as opposed to this proposed WG.  As written, does all HTTP for web browser go to HTTPbis; and machine-to-machine comes here?  

** Per “Proposals for new HTTP status codes, methods, or other generic extensions, to be considered by the HTTP Working Group”, why would this WG propose new work for HTTPbis, instead of doing it?

** How do when know when this WG is done?

** Can the initial milestones please be added

Martin Duke (was Block) No Objection

Comment (2020-09-10 for -00-01)
The github version addresses my DISCUSS.

Benjamin Kaduk No Objection

Comment (2020-09-09 for -00-00)
Not much to add that hasn't already been covered by my fellow ADs.
It's particularly hard to gauge the expected scope with no milestones listed.

One point, though: machine-to-machine API usage is likely to make heavy
use of (TLS) mutual authentication, and the stalwart documentation for
authenticating TLS servers (RFC 6125) explicitly disclaims coverage of
authentication of TLS clients.  There may be a gap in this area that could use
filling and I wonder if the right people would be here to work on plugging it.

Erik Kline No Objection

Comment (2020-09-09 for -00-00)
No email
send info
Nothing to add over what's already been said, except I still think the
working group name might be shortened by removing "ttp".

Murray Kucherawy No Objection

Comment (2020-09-01 for -00-00)
No email
send info
Is this meant to be a standing working group of sorts?

Martin Vigoureux No Objection

Comment (2020-09-10 for -00-00)

   New work items can be added after a Call for Adoption on the working group
   mailing list and consultation with the Area Director.
It is unclear to me whether those new work items are items in scope of the current charter or out of the current scope.
In the latter case I would tend to think that a rechartering process is the way to handle that.

Thank you

Éric Vyncke No Objection

Comment (2020-09-08 for -00-00)
Should there also be a link with the CoRE WG ?

Magnus Westerlund No Objection

Comment (2020-09-07 for -00-00)
I find this bullet creating some questions:

    • Proposals for new HTTP status codes, methods, or other generic
        extensions, to be considered by the HTTP Working Group

As this is output. So this is basically a WG consensus proposal (Internet Draft) in HTTPAPI that is then thrown over the fence to the HTTPbis WG for consideration? In this consideration then it is up to the HTTPbis WG to do what ever they feel about this proposal? And the status in HTTPbis will basically that this is from the HTTPAPI WG and have the level of consensus it had. Is there a need to actually move this bullet from the output list to instead detail how the HTTPAPI WG can propose chagnes in HTTPbis WG scope and establish its WG consensus prior to handing it over? Also are this expected to be technical solutions or primarily an problem solving idea for further development with solid use case(s) and requirements from HTTPAPI?

Robert Wilton No Objection

Comment (2020-09-10 for -00-00)
No email
send info
No comments beyond what has already been stated.