# DISPATCH Virtual Meeting @IETF-110 Monday, 8 March 2021 12:00-14:00 UTC [MeetEcho](https://meetings.conf.meetecho.com/ietf110/?group=dispatch&short=&item=1) [Notes](https://codimd.ietf.org/notes-ietf-110-dispatch) [Jabber](xmpp:dispatch@jabber.ietf.org?join) DISPATCH Meeting ---------------- ### Status and Agenda Bash - Chairs and ADs (5 min) * Kirsty presenting by herself to start off. Please note that the ART AREA of the agenda is sharing of technology, just for information, not for dispatching. * Bron Gondwana taking notes (AGAIN) because I'm a sucker for it, and whoever writes the notes creates the history. ### Date and Time on the Internet (20 min) Presenter: Ujjwal Sharma [draft-ryzokuken-datetime-extended](https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/) [Messages](https://mailarchive.ietf.org/arch/msg/dispatch/ral4HWlVDw8mRRRmvMdSGPtGA0Y/) * Works at a consultancy called Igalia * [sound went bad - took about 2 min to fix] * Described the "Temporal" type, first class timezones and calendars. * Standard 3339 time: datetime+offset * via Jabber: https://datatracker.ietf.org/doc/draft-bormann-cbor-time-tag/ is also coming up this meeting. ### DISCUSSION: * Pete Resnick: can you explain what happened in CALEXT? * Bron: sure - generally positive but want it not to replace 3339, but also there's complexity so we need to spend some time on it and have the right people. * Pete: why do you need to know the details for a point in time? * Bron: maintain context "9am in this calendar system, this day" is different than just an offset. * Carsten: there is work being presented in CBOR (next) for this including an information model and extensions beyond RFC3339 and POSIX. Need to ensure this is well coordinated. * Ujjwal: happy to coordinate, let's talk after. * dkg: (can't get sound) * Ujjwal (replying to jabber chat) - if UTC offset and IANA label don't match any more, the UTC offset is supposed to be the source of truth. The labels can be used by the client implementation to process additional context, but it's not necessary to know the exact point in time. Some implementations might not even care (e.g. if not doing any localisation or dealing with any humans) * Harald Alvestrand: question about which key values would be acceptable. * Ujjwal, would be difficult to add to the set if you need a new RFC every time. * Harald: would argue that the overhead for new stuff is far too low if you use this system - people use too much stuff in that namespace without even telling you how it's supposed to be interpreted. If you want interoperability, you don't want it to be too easy. * Dispatch: Harald suggests WG. * John Klensin: likely needs a WG, involves enough complexity. Getting a little worried about a different time problem - ECMA and Java and ISO standards which are all different. End up with "the nice thing about standards". * Ujjwal: idea in ECMA is to match their format to what the IETF does, so there isn't a need to maintain multiple standards. ECMA isn't the international standard, the ISO document is. * Kirsty (chair): Sounds like there's general agreement that a working group is what's needed, we will take a final decision on the list and just confirm with Patrick as co-chair before officially dispatching as such. The link to the charter is on list too, please take a look and see if you think a BoF is needed as the next step or a WG can begin right away. ### On Media-Types, Content-Types, and related terminology (20 min) Presenter: Carsten Bormann [draft-bormann-core-media-content-type-format](https://datatracker.ietf.org/doc/draft-bormann-core-media-content-type-format/) [Messages](https://mailarchive.ietf.org/arch/msg/dispatch/LIBX0h4sYR0qMgnrYDoQfVxInSA/) * Carsten - presenting slides, lots of RFCs use the media type terms, would be good to have a good reference to point to. * Since this touches just about everything in ART, decided to bring to DISPATCH since CORE isn't chartered for this work. ### Discussion * Mark Nottingham: different places have evolved in different directions. Would like to define terminology, but not more. * Carsten: of course we can do all the things in the documents that use them, but think that defining the ABNF in one place makes it more reusable. * Mark: would like to break the terminology out into a separate document. * Pete Resnick: (oops, I was arguing on Jabber) * Cullen Jennings: unclear how much you want to clarify terminology. Don't think this is ready for dispatch. * Kirsty: what would you like to see? * Two things - a purely terminology doc BCP-like, and extensions very simple and crisp - since lots of things need to interoperate with any change we make. * Carsten: what do you mean by extensions? * Cullen: I don't know, what do YOU mean? * Carsten: only thing new is content format string * Cullen: that's only a new name for a thing which already exists? * Carsten: it's something that new things could also use - it's a general name for things that are extensions. * Cullen: parts that are terminology vs new are hard to tell which is which. Don't think anyone has problems with clarifying terminology, and sometimes defining a term for things we've been using is good - but that's different from creating something which provides more information that transfers over the wire. Both good to do, but not the same thing. * John Klensin: this is dangerous to do in a WG or AD sponsored without a clear charter that says it covers this. Can't do in CORE. * Harald: implications of this document are not simple. Making sure that we don't add extensions without knowing what we're doing is not simple. You have not thought this through, recommend a working group. * Carsten: by saying "this is not simple" you demonstrate that it's needed, because everything should be simple. * Kirsty: the decision we're coming to is there are some questions about scope, a more clear problem statement would be helpful to revisit this and see what the work is that you're trying to do - whether a WG is needed or if the document is a bit more simple. There's general agreement that the work is useful and we'd like to see the work progress, but first we need a more clear problem statement and then we can discuss a working group, or see how simple the doc would be and if it could be AD-sponsored instead. * Kirsty will discuss with Patrick offline to confirm this dispatch result. ### HTTP content negotiation using profiles (10 min) Presenter: Lars G. Svensson [draft-svensson-profiled-representations](https://datatracker.ietf.org/doc/draft-svensson-profiled-representations/) * Presentation - Ruben Verborgh. * APIs will tell you that they're doing JSON, but not mention the specific media type. If clients code against that, they are making assumptions about the JSON, i.e. assuming that there's a field called "username". * A solution is minting very specific content types, but there's value in knowing that it's JSON, or XML, or... there can be multiple dimensions of assumptions. * Today: APIs either over-specified or under-specified. * Proposal: help services indicate what extra constraints they conform to on top of just JSON - and clients discover what constraints are supported. * Allow clients to request specific constraints. * Allow clients to send specific constraints. * Reusing existing RFC - profiles. * Allow clients to keep doing what they are doing and upgrade. ### DISCUSSION * Mark Nottingham: wanted this to come to DISPATCH because there's a lot of unanswered questions about this. * while your usecase is APIs, this seems a generic negotiation mechanism. * Wondering if there are API implementers/practitioners who are asking for this? * Worried about overloading HTTPAPI with this work. * Chris Lemmons: agree on question: does this work outside of HTTP APIs? * Timothy Panton: {bad sound} * Rich Salz: as HTTPAPI co-chair, just figuring out what we're doing, could end up being HTTPAPI but rather it didn't start right away, already got 5 drafts in progress, and a group which is half new to the IETF. * Seeemed much more generic than just APIs. * Kirsty: not hearing any clear idea about what we want to do next - dispatch result is to continue discussion on the list to find next steps. * Ruben: also, see it wider than APIs, this is much more generic. [Patrick Arrives] ## ART AREA Meeting ---------------- ### BoFs, updates and meetings of interest - ADs (5 min) * see slides - lots of interesting things. * Patrick notes again that the ART AREA of the agenda is sharing of technology, just for information, not for dispatching. ### APN: Application-aware Networking (20 min) Presenter: Shuping Peng/Zhenbin Li [draft-peng-apn-scope-gap-analysis](https://datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis) [Messages](https://mailarchive.ietf.org/arch/browse/apn/) * Zhenbin Li presenting * Presenting to dispatch to clarify what APN group does and doesn't do, and invite those interested to join. * Ted Hardie: want to know if it's a tuple you want: application plus user, or if there are groupings that are user specific or application specific that don't care what user it is. * Zhenbin: application always asks for authorization from the network, so you always get an ID for the user. * Kirsty: have to cut discussion here - will take more discussion to list, thanks for presentation. ### qlog (logging for QUIC, HTTP/3 events and other protocols) (20 min) Presenter: Robin Marx [draft-marx-qlog-main-schema](https://datatracker.ietf.org/doc/draft-marx-qlog-main-schema/) [draft-marx-qlog-event-definitions-quic-h3](https://datatracker.ietf.org/doc/draft-marx-qlog-event-definitions-quic-h3/) [Tools](https://qvis.quictools.info) [Messages](https://mailarchive.ietf.org/arch/msg/dispatch/oGFtO7Zypgt_EgpzMu0ZOr7tpUE/) * Robin presenting * Used to be able to use Wireshark to track traffic, but it's harder with QUIC. Similar issues with encrypted APIs. * Idea: have a format to allow both ends to log in a standard format so it's easy to process. * Have built tooling for tracking packets at both ends. * most stacks support it ### DISCUSSION * Phillip Hallam-Baker: want to encrypt my log files. Using QLOG for payload, but encryption whole thing. Incremental encryption. * Mark Nottingham: wondering what having a standard brings to the table? This is done in an ad-hoc or open-source way often. Looks like you already have good market share. Wonder if this has some of the same properties of an API. * Benjamin Schwartz: think we've lost a tradition. IETF used to standardise more file formats. Seems like we've gotten out of the habit. * Will be important to work out the edges of your standards domain - allow non-standard information to be mixed in. * Robin: this is why we're using JSON - easy to add new keys. * Daniel Gillmor: Think there is value in standarising this - we've done APIs and file formats in the past. There's obvious interoperability value here. The process is a place for implementers to think clearly about the impact (including privacy concerns) - identify which fields are more sensitive. Recommend data retention and destruction policies. Recommend you don't log this stuff unless you need it. Scared about automatic retention of gigabytes of log data. Worth discussing best practices. * Kirsty: thank you for the comments, the chat says this is interesting work - so this is a FYI to the group, please continue the discussion and get involved going forward using the links Robin provided. ### SDP Mapping into HTTP structured headers (10 min) Presenter: James Gruessing [draft-gruessing-sdp-http](https://datatracker.ietf.org/doc/draft-gruessing-sdp-http/) [Messages](https://mailarchive.ietf.org/arch/msg/dispatch/a79ROoMZPrrYMKhLc6Ss_mfOjaA/) * James Gruessing presenting * DISPATCHING: jabber suggests WISH, not HTTPAPI. * Eric Rescorla: seems like two things here. Not persuaded that headers are needed, structured format is good. If you need to put it in a header, just base 64 it. * Kirsty: continue lively discussions on list, thanks to James for taking the time to come and present your work here today. ### SIP Extensions for High Availability and Load Balancing for Public Cloud (10 min) Presenter: Jonathan Rosenberg [draft-rosenberg-dispatch-cloudsip](https://datatracker.ietf.org/doc/draft-rosenberg-dispatch-cloudsip/) * Jonathan Rosenberg presenting ### DISCUSSION: * none... no, wait * Jonathan Lennox: how much needs to support this? * A: upstream and downstream need to support it - assume downstream UA is under same admin control as the system that runs the cluster. * Kirsty: will continue discussion on list, thanks. ### AOB ## Summary: * datetime needs a short-term WG, probably a BoF is not needed as it's not controversial - will confirm on list. * media types - simple document, but not as simple as we would hope. Think WG is needed, definitely not AD-sponsored as it's too complex. Will discuss tighter scoping of the problem on list, result of that might be a BOF. * negotiation work - sounds HTTPAPI-destined and more discussion on list required to confirm this. ## AD notes Murray Kucherawy: want to thank Barry for his work and for helping new ADs. Barry Leiba: Thanks Murray and thanks everybody for your support, have enjoyed working with you. Will continue to be WG chair and etc. Thanks. Many more thanks in the jabber.