* 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-109 dispatch minutes

Session 2020-11-16 1200-1400: Room 1 - dispatch chatroom


minutes-109-dispatch-00 minutes

          # DISPATCH Virtual Meeting @IETF-109
          Monday, 16 November 2020
          05:00-07:00 UTC
          DISPATCH Meeting
          ### Status and Agenda Bash - Chairs and ADs (15 min)
          Ben is leaving DISPATCH chair and introducing new chair, Kirsty Paine
          Patrick notes that Ben has done an excellent job as DISPATCH chair and
          gives a virtual round of applause.
          ### A Few Words from our ADs - (5 min)
          Barry speaks and asks for a moment of silence to remember Jim Schaad.
          He also introduces the new chair (Kirsty Paine) and thanks the outgoing
          chair (Ben Campbell).
          ### The 'haptics' Top-level Media Type - Yeshwant (30 min)
          * Haptics refers to a generation of touch-related sensations in a device
          or interface
          * often used in consumer devices to provide feedback to users,
          e.g. vibrations as notifications, virtual keyboards
          * v-01 of the draft was uploaded 15th November to address comments
          received on v-00. Updates:
          * Justification:
              * There hasn't been a top level registration for haptics.  They are
              a good thing to have in parallel with audio tracks.
              * Also becoming part of ISO mp4 format.
              * Envision mp4 files with just haptics tracks in them.
              * Haptics are in billions of devices now.
              * application/ is not suitable.
          * Security Considerations:
              * it's media that gets rendered, so security profile is the rendering,
              similar to video and audio.
          MeetEcho chat:
              * Richard Barnes: this seems fine. just AD-sponsor it msk / barry :)
              * John L: It’s clearly worth having, my only question is to be
              sure we understand mixed haptics+video, haptics+audio, etc.
              * Bron Gondwana: concur - might be worth suggesting that we go
              through the remaining slides faster to see if there's anything else
              in here that we need to see to decide where the work should go,
              but I'm already sold on the concept
              * Martin Thomson: (to John L) it seems reasonable to consider the
              "primary" modality as the top-level type. So if you are showing video
              and the haptics is supplementary, use video. As he is saying now.
          * General support for this in the chat.
          Tim Bray:
          * Q: wanted to hear some scenarios where you would send haptics data by
          * A: streaming games, send haptic data by itself to a controller, will
          have no audio or video.
          * A: wirelessly connected body suit, for example.  There are companies
          making these now.  12-24 actuators.
          * A: pre-cache effects for games.
          Magnus Westerlund:
          * Q: Does this top level type mean we update rfc 6381?
          * A: haven't read that in detail.  Once mp4 is standardised next year,
          then it would need to be updated.
          * Q: please look at it some more and see if you need to update from/to
          Patrick (as chair):
          * Please remember to be responsive to the dispatch question!  Our goal
          is to work out where to do the work, not necessarily what the work is!
          Larry Mastinter:
          * Q: haptics/blah rather than application/blah.
          * Q: software will need to know about haptics as a top level mime-type
          rather than just treating it as a standard audio channel.
          * A: haptics works kind of differently to audio.  It will be a third
          track in an mp4 file.
          * A: there may need to be changes made to the mp4 engine in software,
          but that's the same as any progression of a standard
          * e.g. ahap file is a JSON file, very descriptive: at offset through
          the timeline, do X.  Can't really do that with an audio format.
          Discussion about -> where to do the work.
          * in Jabber chat: AD sponsored vs Working Group.
          Jana Iyengar:
          * Q: {for ADs and dispatch chairs} is there anyone else interested?
          Are they willing to engage at the IETF?  Where it lands depends on who
          the other interested parties are.
          * A: there is an IEEE effort which is ongoing. P1918.111.  Finalising the
          coding standard now.
          * A: many academic institutions and companies active there.
          * A: Apple is quite active in MPEG.  David Singer.
          * A: Haptics industry forum is 50 companies.
          Spencer Dawkins:
          * Via chat - this a top-level registration, so maybe a short-lived
          working group is appropriate.
          * Does anyone disagree with doing a short-lived working group?
          * Patrick: Barry has offered to AD sponsor, would appreciate him to
          respond to.
          Richard Barnes:
          * Think it's natural AD sponser, shouldn't waste effort on a working
          Pete Resnick:
          * {will type, no audio}
          * Don't think WG is necessary, AD sponsored would be reasonable.
          Mo Zanaty:
          * Q: Top level type makes sense.  Regarding dispatch, do you plan do to
          more than just the type?  Standardise subtypes in IETF, etc. ?
          * A: At least two types being standardised elsewhere.  Others could
          * Q: spacial haptics
          * A: that's phase 2!
          Sephan Wenger:
          * Supportive of top-level
          * As IETF liason to MPEG.  This isn't the most active thing at MPEG,
          but not the quietest either, lots of industry interest.
          Barry Leiba (AD):
          * Primary discussion will be on media types list.  Don't think we need
          a WG, but want to defer to community.  Good with that.
          * Murray is a media type reviewer.
          Murray Kucherawy (AD):
          * Happy to be the AD that sponsors if the community wants.
          Cullen Jennings:
          * Think we should do this.
          * There are complicated tradeoffs.  audio+video already makes things
          complicated.  There's no way to make this draft meet all our rules
          * We already have experienced media people say this work shouldn't happen
          at the IETF - do we want that discussion to happen on the IETF-wide
          last-call list?
          WRAP UP:
          * Ben Campbell (chair) -> based on Cullen's last comment, the dispatch
          conversation needs to continue.  Discussion among chairs and ADs.
          Don't hear a resolution right now.
          * Patrick McManus (chair) -> agree, need more discussion
          * Barry Leiba (AD) -> ADs can sponsor whatever they like, but the reason
          for dispatch is to hear from the community.  Message to Yeshwant: we're
          going to do the work, just depends where!
          * Yeshwant: thank you, expect to hear from you soon.
          ### WebRTC-HTTP ingestion protocol - Sergio (30 min)
          The problem:
          * WebRTC has no standard signaling protocol, we need a reference
          signalling protocol so each streaming service doesn't have to implement
          its own.
          * HTTP POST session with ICE consent freshness RFC7675 and DTLS teardown.
          Server only needs to implement ICE lite, encoder must implement full ICE.
          Patrick: before we open the queue, do you have opinion about where to
          dispatch to?
          Sergio: it's pretty simple, wherever it can go fast!  Don't want it to
          grow more complex.
          ## Discussion:
          Bernard Aboba:
          * Q: why does it need to be standardised? Looks very simple.
          * A: hardware encoder, want to say "please implement to work with more
          than one service" - if not a standard then it won't be used
          Harald Alvestrand:
          * Q: think this makes perfect sense.  The point of having a document is
          to have a stable online reference.  That's a good idea.  Tried to do this
          with Cullen ages ago, and it failed to gain traction.  Probably because
          they tried to incomporate it in the spec.
          * Suggest informational publication as AD sponsored.
          * A: Idea is have it in OBS or in hardware, so common spec allows people
          to be more comfortable when implementing something.  Now, need to talk
          to each vendor.
          Victor Vasiliev:
          * Q: about implementation experience, especially for non-web clients.
          * A: implemented in own systems and in web.  Have it in an OBS fork,
          trying to get taken upstream.
          * A: talking to hardware encoders.
          * Q: urls are just https?  A: yes
          Timothy Panton:
          * Needs another round of discussion for detail, but looks very
          Johnathan Lennox:
          * Q: is this feature equivalent to RTMP as-used?  Appears to be a
          replacement for RTMP.  Doesn't look very extensible.
          * A: Goal is not to replace RTMP or similar.  There will be use for
          different things.
          * If you use RTMP you are adding delay, buffering, etc.  Doesn't support
          OPUS, so need to transacode.
          * Q: but are there things that would be currently done with RTMP if you
          wanted to switch to this?
          * A: goal is to have webrtc from end to end.
          * A: if you wanted to stream a conference via CDN...
          Patrick (chair):
          * Q: how much do you expect IETF to work on this, vs static document
          that needs to be published?
          * A: there are some open points, e.g. control over disconnection.
          Don't expect much more work.
          Ted Hardie:
          * Want to go back to requirements slide: two things which maybe mean we
          need a working group:
          * 1. server assumed not to be behind a NAT.
          * 2. supports load balancing and redirections.
          * If there's a subset of these requirements where it's true, publish it
          as informational.  If you want a signaling protocol that will handle load
          balancing and redirection, then there's more going on than you could do
          at AD sponsored.
          * No objection to working group to work through this, but would need to
          remove that complexity!
          * A: what mean by load balancing, is just HTTP redirection.  Not full
          load balancing.
          Mo Zanaty:
          * Q: why do you think this has anything to do with injestion?
          Think there'd be a bigger demand for receiving, you need an app.
          * Q: why can't smart displays just hit a URI?
          * A: need to talk to different people.  For ingest need to talk to
          encoder people, etc.
          * A: solution may be similar, but prefer to handle independently.
          Agree this is something that's also needed.
          NEXT STEPS:
          * Patrick: think this work needs to be done.  Discussion of a charter
          for a small working group.
          * Sergio: OK. Yep.
          ART AREA Meeting
          ### BoFs and meetings of interest - ADs (10 min)
          * emailcore and asdf (and httpcore and sframe) all newly chartered.
          Carsten Bormann:
          * jsonpath is new as well, format for xpath-things like JSON.
          Pete Resnick:
          * gendispatch: only item on agenda is update to 7221 (rfc about how
          working groups adopt/unadopt documents)
          ### IANA Registration of Content-Type Header Field Parameter  -
          Bernie/Alexey (30 min)
          Alexey presenting.
          Working in LAMPS on header protection for S/MIME and PGP.
          Just encapsulating is unclear whether it's a forwarded message or an
          encapsulated message.
          John Levine:
          * {audio issues}
          Bron Gondwana:
          * Prefer option 2.  Content Disposition feels like exactly what this is.
          Seems like something that could be generally useful.
          Daniel Gillmor:
          * Q: been trying to figure out how to use this in terms of header
          * We can't tell old clients who don't know about it to respect it this
          way.  By definition, deployed clients will keep treating it that way.
          * Fine with any of these ways of doing it, doesn't solve problem of
          interacting with legacy client though.  Not sure this is the right spot,
          but any of the proposals feel fine.
          John Levine:
          * Another use case is mailing lists and dmarc.  One thing tried was
          wrapping messages like this with an outside header that does the list
          * Agree that current behaviour of MUAs with wrapped messages is poor.
          Making 'message/encapsulated' is likely to be worse!
          * Not a hill planning to die on!
          Harald Alvestrand:
          * feel like old man yelling at cloud.
          * message/signed was never intended for forwarding, so MUAs that display
          this as forwarded are buggy.  We can tell them to fix the bug, or add
          more markers that mean the same thing.  Can we just get the bug fixed?
          Phillip Hallam-Baker:
          * I support doing something on this.  Think everyone who's played with
          S/MIME has proposed something of the sort.  The problem is always that
          the legacy clients don't do what they should.
          * There's two types of headers: content headers and routing headers.
          SMTP smooshed them together.  Maybe we need to disentangle the two.
          * sorry still waking up!  Will review the comments.  If you're interested,
          please come to LAMPS tomorrow.
          ### AOB
          10 minutes available if you want.
          Bron Gondwana: RFC3339 extension
          * Javascript notation format is looking for a standard serialisation.
          Harald Alvestrand:
          * We should have done this in the 90s!  It was a mistake not to do it
          Neil Jenkins:
          * we do need a serialisation format
          Where to discuss: calsify or tzdata lists, but probably calsify is best.
          Patrick: saying goodbye to Ben
          * Main thing is reaching out to people with no idea how all this works
          and integrating them!  Thanks Ben
          * Ben turned on his video and we all waved at our screens.

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