Minutes IETF109: dispatch
minutes-109-dispatch-00

# DISPATCH Virtual Meeting @IETF-109

Monday, 16 November 2020
05:00-07:00 UTC

[MeetEcho](https://meetings.conf.meetecho.com/ietf109/?group=dispatch&short=&item=1)

[Notes](https://codimd.ietf.org/notes-ietf-109-dispatch)

[Jabber](xmpp:dispatch@jabber.ietf.org?join)

DISPATCH Meeting
----------------

### Status and Agenda Bash - Chairs and ADs (15 min)
Ben is leaving DISPATCH chair and introducing new chair, Kirsty Paine NCSC.
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)
[Draft](https://datatracker.ietf.org/doc/draft-muthusamy-dispatch-haptics/)

* 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.

Questions:

Tim Bray:
* Q: wanted to hear some scenarios where you would send haptics data by itself
* 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 it.

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 group.

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 happen. * 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
simultaneously. * 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)
[Draft](https://datatracker.ietf.org/doc/draft-murillo-whip/)

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.

Proposal:
* 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 implementable.

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)
[Draft](https://datatracker.ietf.org/doc/draft-melnikov-iana-reg-forwarded/)

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.

Questions:

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 protection.
* 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 dmarc. * 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.

Alexey:
* 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 then.

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.