Building Blocks for HTTP APIs
charter-ietf-httpapi-01

• Ready for external review (00-00)
• Approve (00-02)

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

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

Erik Kline No Objection

Nothing to add over what's already been said, except I still think the
working group name might be shortened by removing "ttp".

Martin Duke (was Block) No Objection

The github version addresses my DISCUSS.

Murray Kucherawy No Objection

Is this meant to be a standing working group of sorts?

Robert Wilton No Objection

No comments beyond what has already been stated.

Roman Danyliw No Objection

** (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

Éric Vyncke No Objection

Should there also be a link with the CoRE WG ?

(Barry Leiba; former steering group member) Yes

(Alissa Cooper; former steering group member) (was Block) No Objection

Thanks for addressing my comments.

(Benjamin Kaduk; former steering group member) No Objection

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.

(Deborah Brungard; former steering group member) No Objection

(Magnus Westerlund; former steering group member) No Objection

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?

(Martin Vigoureux; former steering group member) No Objection

Hi,

   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