Minutes IETF108: dispatch
minutes-108-dispatch-01

# 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!