# DISPATCH Virtual Meeting @IETF-108 Monday, July 27, 2020, 11:00-12:40 UTC Summary ------- The chairs would like to thank Bron Gondwana for taking notes and Brian Rosen for scribing Jabber. Ted Hardie presented the proposed [RFC 3405 Update](https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/). The sense of the room was to recommend the draft to be AD-sponsored. This is subject to confirmation on the mailing list. Barry agreed to sponsor it once consensus is confirmed. Carsten Bormann presented [JSON Path](https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/). There is considerable interest in the work, and people think this might be a good candidate for a focused working group. Carsten will propose charter text to be discussed on the list. (Some discussion might occur on a separate JSON Path list, but the charter discussion will eventually come back to DISPATCH) Mark Nottingham proposed a charter for a new working group to focus on HTTP API building blocks. There was general interest in the room for forming the group. The charter seemed mostly right, but needs some refinement to the scoping language, to be discussed on the list. People generally felt this could be chartered without a BoF, but reserved that decision until after the charter refinement discussion. Emad Omara presented [Secure Frames](https://datatracker.ietf.org/doc/draft-omara-sframe/). People were generally positive about this work, and thought it would be a good candidate for a focused mini-wg. People have been kicking around a charter off-list. The next step is to bring the charter discussion to the DISPATCH list. There were no ART Area discussion topics. The chairs plugged meetings coming up later in the week that were likely to be of interest to ART area participants. There was no AOB. Detailed notes follow: # AGENDA: DISPATCH Meeting ---------------- ### Status and Agenda Bash - Chairs and ADs (10 min) ### RFC 3405 Update - Ted Hardie (15 min) [Draft](https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/) ### Proposed HTTP API Buiding Blocks WG - Mark Nottingham (20 min) [Proposed Charter](https://mailarchive.ietf.org/arch/msg/dispatch/pWx1SgjZS4R3nzXEK-jE6xqOqUc) ### JSON Path - Carsten Borman (20 min) Discussion: Should this be a candidate for the proposed HTTP API WG? [Draft](https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/) ### SFrame - TBD (20 min) [Draft](https://datatracker.ietf.org/doc/draft-omara-sframe/) ART AREA Meeting ---------------- ### BoFs and meetings of interest - ADs (10 min) ### AOB # MINUTES ## Meetecho issues: * wanting to send media vs audio confusion * failure to ask for audio when sending video. * 35 seconds is a long time for a hum! * cancellation of people due to reflow (ALSO can't re-add people to the queue) * confusion about what's sending and people turning off video when they meant to turn it on, etc. * hard to know when supposed to be talking. Ben running slides, Patrick running queue. Lots of description of background: bluesheets, how to use Meetecho, discussion of Notewell. ## Ted Hardie: rfc3405 update: * Now you've read it, the entire text of the draft is in the slides. ### Discussion: * **Ben**: suggested maybe in this group, maybe AD sponsored. What do people think? * **Ted**: Happy with either. * **John Klensin**: meta question - assumption was that it's pretty much dead? Is it in active use? * **Ted**: in active use even though not actively being changed - but someone wanted to register something in it. * **John**: OK - don't have more to say * **Barry Leiba**: (AD) would like to hear from people who think we should NOT handle it in the group and have it AD sponsored. Why not handled by group? * **Patrick**: amount of last call would be similar either way - anticipate 4 week if AD or 2 weeks WG + 2 weeks IETF if via working group. Concern is whether this group has critical mass of people. * From Jabber: AD sponsored +1 +1 +1 * **Richard Barnes** via Jabber: DISPATCH doesn't do documents. Barry: charter does allow simple registration documents, this is a little more. There's already an appeal on this! * **Jon Peterson**: DISPATCH can dispatch to AD, often the right idea is to do that. * **Mark Nottingham**: DISPATCH is preferable to spinning up a WG, AD is prefereable to DISPATCH. * **Robert Sparks**: DISPATCH is for dispatching, what starts as a simple thing spins up to taking on lots of work and next thing you know it's hard to to focus on new things. * **Cullen Jennings**: agree with Sparks, this is a mistake. * **Spencer Dawkins**: where do you expect the discussion to happen? Dispatch or IETF list? * ((Phillip Hallam-Baker **: (audio problems) - typed ### Hum 2: Should we NOT progress this draft? Result: Pianissimo Does anybody want to speak as to why we shouldn't progress this draft? ### Hum 3: that dispatch should adopt as a work item Result: Piano ### Hum 4: Should be AD Sponsored Result: Forte * **Ben**: need to take to the list and make sure ADs will agree to sponsor. * **Barry**: happy to go with consensus and AD sponsor it. Will put into 4 week last call once we have confirmed consensus. ## HTTP BUILDING BLOCKS API: Mark Nottingham * Mark having audio and video issues. Trying a different browser. Trying again later ## JSONPath standardi\[sz]ation - Carsten Bormann * **Jabber**: JSON-WG makes more sense than CBOR - this has nothing to do with. * **Mark Nottingham**: if there are many users out there, it's bound to break. Should we call it something other than JSONPath? If we change the name, should we change the format too so it's clearly not the same thing? Agree new working group or JSON group make sense, not CBOR. New HTTP group might be OK, but this might not be the best piece of work for it to take early. * **Brian Rosen**: I really need this - gonna work on it! Don't care where it is, anything but CBOR. * **Keith Moore** via Jabber: essential to be clear whether documenting existing practice, or desirable practice. Might not be possible to do both. * **Martin Thomson** via Jabber: making JSON Pointer good might be more tractable. * **Cullen Jennings**: should be a nrom that working group. Proposal should include a charter for a new working group. Think we should work on scope for that charter. * **Glyn Normington**: is we had a standard, it could be used for comparison to existing implementations - it won't effect end users if we document something, just that they can compare against it. * **Sean Turner**: could just write an informational draft to document things. * **Ben**: think we should discuss charter and then decide where it goes. * **Spencer Dawkins**: should discussion happen on dispatch, or start a new mailing list anyway? * **Ben**: start on dispatch, move to a new list if the traffic gets high. * **Carsten**: will write request for a mailing list and get the proponents to put together a charter proposal over the next few weeks. * **Cullen Jennings**: happy to prepare a mailing list for the discussion, charter work should happen on dispatch (because there are chairs to call consensus!) * **Patrick**: agree - let's work on charter in dispatch. * **Ben**: does anyone want to say "should go to a BOF?". Nobody did. * **Various**: might want to say "needs a BOF" after the charter is proposed! * **Alexander Mayrhofer**: complex enough that it might be worth sending to a BOF. Already been waiting 13 years, another little while won't hurt. Can we do an interim BOF? * **Brian Rosen**: don't think a BOF is necessary here unless we get into a fight over what's in the charter. If we do get held up in discussion about how to get going, then a BOF is useful. Hope that doesn't happen. * **Phillip Hallam-Baker**: can't see that a BOF actually helps. Would be useful if there were two competing schemes, but given that scope of work, can't see what a BOF adds. ## HTTP BUILDING BLOCKS API: Mark Nottingham Suggesting a working group with no concrete deliverables yet! Need to bring some new people into the IETF. * **Pete Resnick**: Question about interest - are you getting interest from both providers and users of APIs? What level of interest? * **Mark**: hearing a lot from peopel who have specs that they think might be interesting. A bit from those in the industry who work on API teams at companies. They currently talk amongst themselves in other communities, but might come here. * **Rich Salz**: are we too late? * **Mark**: couldn't have done it earlier, too fragmented. Poeple feeling enough pain now. People redo their APIs occasionally, so they could switch. * **Mark**: separation from HTTP working group - low layer implementers vs this. * **Discussion in Jabber**: OpenAPI/RAML/etc. Swagger. * **Martin Thomson**: WS* issues. * **Mark**: vendors with market power doing architectural astronautics. Making things too middleware focused is a thing. * **Bron**: we can't do earlier - question is should we do it now or later? Think now is probably better. * **Eric Rescorla**: Impression of API people - don't want to screw with headers or status codes - want to do it all the XHR. How much do you think is in scope for 2d (best practices) * **Mark**: nothing at the start. Maybe more over time. Things like best practies for paging through data for example. Discussion will continue offline. * **Ben**: hearing interest in the group and nobody saying charter is wrong. * **Brian Rosen**: think we could pick a couple of things (versioning, etc) and make them initial charter items. Let's get going! Very optimistic. * **Harald Alvestrand**: every attempt I've seen for APIs without descriptive languages fails. elephant in the room is what WHATWG is doing. * **Mark**: that's APIs for within browsers, which is NOT in scope for this working group. * **Harald**: then charter is unclear to me. * **Mark**: see item 1, machine to machine communication is goal. * **Ben**: either way, way forward is the same. ## SFRAME - Emad Omara Where should it go? * **Richard Barnes**: valuable work, questions about subframes need to be nailed down. There's a charter that's been kicked around. Small focused working group is good. * **Colin Perkins**: suprised work isn't being done in AVTCore group which has experience in these things. Supportive of work, but it should be there. * **Emad**: idea was to make it protocol agnostic, key management out of band. * **Bernard Aboba**: think there's a lot of use for this work. Will have better scaling properties than other things. * **Eric Rescorla**: generally positive on this. Like that this emphasises the need for end-to-end keying. Most of the things it needs are not AV. * **Jonathan Lennox**: think a new working group is good. Needs people from AVTCore, but also others. ## ART OVERVIEW - Ben Lots of interesting things happening through the week, show up! ## Any Other Business? No! Thanks everybody!