* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dispatch Status Pages

Dispatch (Active WG)
Art Area: Barry Leiba, Murray Kucherawy | 2009-Apr-14 —  

IETF-108 dispatch minutes

Session 2020-07-27 1100-1240: Room 1 - Audio stream - dispatch chatroom


minutes-108-dispatch-01 minutes

          # DISPATCH Virtual Meeting @IETF-108
          Monday, July 27, 2020, 11:00-12:40 UTC
          The chairs would like to thank Bron Gondwana for taking notes and Brian
          Rosen for scribing Jabber.
          Ted Hardie presented the proposed [RFC 3405
          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
          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)
          ### Proposed HTTP API Buiding Blocks WG - Mark Nottingham (20 min)
          ### JSON Path - Carsten Borman (20 min)
          Discussion: Should this be a candidate for the proposed HTTP API WG?
          ### SFrame - TBD (20 min)
          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
          * **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
          * **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
          * **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
          * **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?
          Thanks everybody!

Generated from PyHt script /wg/dispatch/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -