BCP56 defined best practice for how standards-based protocols that wanted to use HTTP "as a substrate" should do so, and was informed by efforts at the time -- being ~2001, IPP.
Since then, things moved on quite a bit, and it's started to become really common for people to build APIs on HTTP, and then want to standardise them. However, the common practice of using something like OpenAPI/Swagger to define a bunch of fixed paths isn't really suitable for standards use, both because of clashes with ArchWWW as well as BCP190.
So, I started a revision, BCP56bis, which tries to guide people towards best (or at least least harmful) practices. That has been adopted by the HTTP Working Group (so I'm acting as an editor on this draft, not a chair).
It's important to understand the audience here -- a typical IETF protocol that wants to use HTTP is more often than not being put together by people who are NOT Web developers, and don't even have a minimal amount of knowledge about how the Web actually works internalised.
This is a work-in-progress (see open issues), but I thought the TAG might be interested in providing feedback.
I'm happy to answer questions here, or you can open issues on our repo (one GitHub issue per, and note the contribution policy).
OpenedFeb 20, 2018
BCP56 defined best practice for how standards-based protocols that wanted to use HTTP "as a substrate" should do so, and was informed by efforts at the time -- being ~2001, IPP.
Since then, things moved on quite a bit, and it's started to become really common for people to build APIs on HTTP, and then want to standardise them. However, the common practice of using something like OpenAPI/Swagger to define a bunch of fixed paths isn't really suitable for standards use, both because of clashes with ArchWWW as well as BCP190.
So, I started a revision, BCP56bis, which tries to guide people towards best (or at least least harmful) practices. That has been adopted by the HTTP Working Group (so I'm acting as an editor on this draft, not a chair).
It's important to understand the audience here -- a typical IETF protocol that wants to use HTTP is more often than not being put together by people who are NOT Web developers, and don't even have a minimal amount of knowledge about how the Web actually works internalised.
This is a work-in-progress (see open issues), but I thought the TAG might be interested in providing feedback.
I'm happy to answer questions here, or you can open issues on our repo (one GitHub issue per, and note the contribution policy).
Thanks!