Re: [dispatch] A WG for HTTP API Building Blocks

[Mark Nottingham <[e-mail]>]

It's not necessary to have a mechanical process for determining what group something best belongs in; it's negotiated between the various stakeholders, following any guidance in the RFCs and charters as appropriate. As I mentioned to Lucas, we already encounter this sort of situation in other places (e.g., deciding whether a particular HTTP/3 extension belongs in the QUIC WG, the HTTP WG, or another WG dedicated to that extension's use case).

Cheers,


> On 16 Jul 2020, at 7:00 pm, Michael Toomim <[e-mail]> wrote:
> 
> Thanks Mark, but my question wasn't about how to get a particular proposal adopted.  I'm trying to find clarity on how we would distinguish these two working groups.
> 
> The purpose of these two examples (one current proposal, one historical) is just to give us something concrete to deliberate.  Are these examples of HTTP work, or HTTP API work?
> 
> Distinguishing these groups seems important because they are so similar.  If we have trouble identifying which group should take which work right now, when nothing is at stake, I could imagine difficulties at scale.  I'd love to find some clear criteria.
> 
>> On Jul 16, 2020, at 1:09 AM, Mark Nottingham <[e-mail]> wrote:
>> 
>> Great example. 
>> 
>> I think that if you got HTTP WG folks excited about BRAID and some folks putting their hands up to implement it there, it would take it on. So far, the reaction has been of interest, but I'm not sure we're quite to the point where we'll adopt it; personally I'm still looking for more people to say 'yes, I want to implement that' and/or 'yes, I have a use case for that.' That may still happen, in time.
>> 
>> If not, and we had an HTTP APIs WG, you could take it there and see if you could get traction with that community; since it's not defining new methods or status codes, and it doesn't necessarily need browser implementation to be useful, that should work.
>> 
>> There's one proviso, however; if the HTTP WG thought it was a bad idea (e.g., actively harmful, bad for HTTP, conflicting with other work, or just a bad starting point for work) it wouldn't be good for the HTTP APIs WG to take it on, because that would be 'venue shopping.'
>> 
>> Does that help? 
>> 
>> 
>> 
>>> On 16 Jul 2020, at 5:56 pm, Michael Toomim <[e-mail]> wrote:
>>> 
>>> I also see value in recruiting API developers and consumers, but (like Lucas) I struggle to distinguish whether a particular proposal "foo" would be demarcated as HTTP vs. HTTP API.
>>> 
>>> As a present example, how do we classify the Braid proposal?
>>> 
>>>  https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http
>>> 
>>> On the one hand, we could describe it as "push-update for REST APIs", and then put it into the HTTP API bucket.
>>> 
>>> But on the other, Braid also applies to browsers and proxies, where it improves caching, reduces network traffic, and allows pages to update automatically without a reload button.  That sounds like core HTTP.
>>> 
>>> Historical examples could also be interesting.  How do we classify HTTP Live Streaming?
>>> 
>>>  https://tools.ietf.org/html/rfc8216
>>> 
>>> This is an API standard, which does not need special browser support.  However, most mobile browsers (but not desktop) now have native implementations for better performance.  Does that make it HTTP core?
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
> 

--
Mark Nottingham   https://www.mnot.net/