Re: [httpapi] Alissa Cooper's Block on charter-ietf-httpapi-00-00: (with BLOCK and COMMENT)

[Alissa Cooper <[e-mail]>]

> On Sep 10, 2020, at 12:31 PM, Barry Leiba <[e-mail]> wrote:
> 
> The -00-01 version of the proposed charter includes Mark's latest
> edits.  Alissa, will you check it and let us know what you think?

It does not address the points below about reviewing the productivity of the group after 6-9 months or about “specific use cases.” Otherwis it looks fine to me.

Thanks,
Alissa

> 
> Thanks,
> Barry
> 
> On Thu, Sep 10, 2020 at 8:44 AM Alissa Cooper <[e-mail]> wrote:
>> 
>> Hi Mark,
>> 
>>> On Sep 9, 2020, at 9:15 PM, Mark Nottingham <[e-mail]> wrote:
>>> 
>>> Hi Alissa (et al),
>>> 
>>> Apologies, I missed many of the previous charter comments (there was some confusion about list creation -- it seems not many people were told), so I'll respond to some previous ones here.
>>> 
>>> (For folks who have just joined the list: this is the IESG's discussion of whether to adopt the WG charter; see <https://datatracker.ietf.org/doc/charter-ietf-httpapi/ballot/> and feel free to chime in).
>>> 
>>>> On 10 Sep 2020, at 12:53 am, Alissa Cooper via Datatracker <[e-mail]> wrote:
>>>> 
>>>> I agree with Martin.
>>> 
>>> Martin's comment was:
>>> 
>>>> from the charter I have no idea what portion of this large problem space constitutes the short-term objectives of this group.
>>> 
>>> As discussed in DISPATCH, this is purposefully not proposed with immediate milestones. To date, we've done some API-related work in the HTTP WG (e.g., Signatures), and in many ways this proposal is simply splitting that work out into a separate group to make it more accessible to its target community.
>>> 
>>> So, to Murray and Roman's comments, yes this is intended to be a standing group -- *if* it is healthy. I would consider it on probation for at least 6-9 months, to see if it's able to have good interaction with the rest of the API community and be productive; if not, as I've said many times I'll be the one most loudly calling for it to be shut down.
>> 
>> I would say we put that in the charter then, so everyone agrees to revisit on the same time frame.
>> 
>>> 
>>> There are a number of potential drafts out there that the group could adopt, but I'd rather see a CfAs happen in the group, rather than as part of the chartering process; that will help form the community and give it ownership over what's going on (and will give it some experience running the CfA process). I gave a talk about API standards and linked to the mailing list last night, and so far the mailing list has almost 20 new members -- many who AFAICT are new to the IETF and also actively practicing in this area.
>>> 
>>> So if the IESG insists, we can add a few initial drafts as milestones, but for the reasons above I have a fairly strong preference not to.
>>> 
>>>> In particular, I am wondering how the WG will define "specific use cases or applications" as referred to where the text says, "this WG will not take on work items for APIs for specific use cases or applications."
>>> 
>>> It says the WG will *not* do those things.
>> 
>> Right, my question is how do you know which things you won’t do?
>> 
>>> 
>>> That text is intended to prevent the WG from defining specific APIs. For example, if someone wants to create a HTTP API for DNS (to use a recent example), this group wouldn't be an appropriate place to do that.
>> 
>> I think for applications it’s clearer, but what is a “specific use case”? To use your example above, let’s say my use case is that I want to be able to digitally sign the contents of HTTP messages. Since that is apparently in scope for the WG, why does it not count as a “specific use case”? I’m not arguing with the limitation, I’m just hoping to have the charter be more expressive in describing the boundary.
>> 
>>> 
>>>> I agree with Magnus that it is unclear whether the third bullet encompasses work that the WG will do or not.
>>> 
>>> The intent there was that the group could talk about proposals for new status codes, but would need to defer their actual standardisation to the HTTP WG (since in HTTP status codes, like methods, are generic and not supposed to be specific to any application or even type of application).
>> 
>> Ok. It shouldn’t be in a bulleted list of what the WG’s outputs will be, but maybe can be described in its own paragraph.
>> 
>> Alissa
>> 
>>> 
>>> I'm open to figuring out another way to do this -- and maybe the charter doesn't need to be so specific (or maybe it needs to be more?). But I think it's generally safer for restricted items like status codes and methods to go through the HTTP WG; we've been burned before on this (e.g., see WEBDAV).
>>> 
>>>> The first sentence is clunky. I would suggest "In addition to its use for web browsing, HTTP is often used for machine-to-machine communication, facilitated by HTTP APIs."
>>> 
>>> Fine by me.
>>> 
>>> Some other responses --
>>> 
>>> Erik K said 'I still think the working group name might be shortened by removing "ttp".'
>>> 
>>> I don't think that would be wise; not only would it remove the reinforcement of the term 'HTTP API' (terminology has been a problem for a while in this area), but it would also conflict with Eran Hammer Lahev's HAPI framework for building HTTP services. I also find that the IETF's penchant for cute names can be confusing and off-putting to outsiders.
>>> 
>>> Éric asks 'Should there also be a link with the CoRE WG?'
>>> 
>>> Definitely not. CORE is not HTTP, and requiring coordination there would be burdensome to both communities. If the IESG is going to insist on coordination between HTTP and CORE, we have a *much* bigger discussion at our feet.
>>> 
>>> Ben wonders about TLS mutual authentication. I suspect that TLS extensions are out of scope for this community, but gauging interest in / requirements for doing it from HTTP APIs here could be useful.
>>> 
>>> Roman asks 'As written, does all HTTP for web browser go to HTTPbis; and machine-to-machine comes here?'
>>> 
>>> That's a rough yardstick;  I expect there to be fairly close communication and coordination between the groups about potential work. This isn't that unusual in the IETF; e.g., I've seen work items go from SECDISPATCH to DISPATCH and then to the HTTP WG, with a fair amount of back-channel coordination between the relevant WG chairs and ADs.
>>> 
>>> I'd also observe that from discussions I've had, this split makes sense to HTTP folks; it might not from a greater distance, but I do think it'll work.
>>> 
>>> Cheers,
>>> 
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>> 
>>