Subject: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes

From: Kirsty P <[email-masked]>
Date: Mon, 26 Jul 2021 21:30:55 +0000

Firstly, many thanks to each of our presenters for bringing their work to DISPATCH today! And thanks too to every attendee who helped us towards a DISPATCH outcome for each of the items - we appreciated your participation, especially when the virtual format makes things harder to take the 'mood of a room'.

Preliminary outcomes from DISPATCH at IETF 111 (now being confirmed on list) were recorded as follows:

  1.  JWS Clear Text JSON Signature Option: chairs did not hear support for the IETF taking on this work at this time; dispatch will not recommend doing so.
  2.  image/webp mime-type registration: Murray Kucherawy is deciding between expert review and AD sponsorship.
  3.  NICER (usage profile of ICE): ADs to determine if "ice-revisited" as a broader topic for a WG would be right, or if this would be better in MMUSIC as a standalone item.
  4.  SDP Security Descriptions is NOT RECOMMENDED and Historic: consensus was sub-optimal. There was support for revisiting the space currently standardised by SDP, but not on direction (whether to do a deprecation with/without replacement). Future paths suggested included: mmusic, a new WG, more work required for it to be ready, or a BoF (said in chat) to vet the idea further.
  5.  The “large file in email” problem: recommend new WG, charter to be drafted and shared on dispatch list for further discussion.

For info, the draft minutes are also available at: https://codimd.ietf.org/notes-ietf-111-dispatch?view
A copy has been uploaded to: https://datatracker.ietf.org/doc/minutes-111-dispatch/

Please email the chairs (dispatch-chairs) with any corrections or omissions - and thanks once again for your dispatching energy!

Kirsty

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation. Refer any FOIA queries to [email-masked]. All material is UK Crown Copyright ©

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 27 Jul 2021 21:58:05 +1000

On Tue, Jul 27, 2021, at 07:30, Kirsty P wrote:

> The “large file in email” problem: recommend new WG, charter to be drafted and shared on dispatch list for further discussion.

Thanks Kirsty.  I'm happy to help with developing a charter.

I've also added discussion of this topic to the JMAP working group, since we had time in our agenda, and working out how to handle large files will be in scope across all our datatypes that allow attached data (at least email, calendar events, contacts and tasks for far!)

This will be in the second hour of the end of the final session on Tuesday: 

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: westhawk <[email-masked]>
Date: Tue, 27 Jul 2021 14:13:36 +0200

> On 26 Jul 2021, at 23:30, Kirsty P <Kirsty.p=[email-masked]> wrote:
> 
> SDP Security Descriptions is NOT RECOMMENDED and Historic: consensus was sub-optimal. There was support for revisiting the space currently standardised by SDP, but not on direction (whether to do a deprecation with/without replacement). Future paths suggested included: mmusic, a new WG, more work required for it to be ready, or a BoF (said in chat) to vet the idea further.
My sense is that there was a rough consensus around a goal to make it possible to deprecate SDES - but the required steps were unclear.

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Jul 2021 09:38:27 -0400

--On Monday, July 26, 2021 21:30 +0000 Kirsty P
<Kirsty.p=[email-masked]> wrote:

>...
>   5.  The "large file in email" problem: recommend new WG,
> charter to be drafted and shared on dispatch list for further
> discussion.

Kirsty,

If one includes the chat discussions as well as what was said
over audio or video, that is not the impression I came away
with.  Specifically, there were comments from several people
that we have been down this path before, including with
message/external-body (went nowhere and raised security issues)
and various URI approaches with which results have been poor (I
think the term used was "terrible"), at least as soon as the
mail crosses the Internet rather than sender and recipient being
on the same platform.

As I understood those discussions, there was a strong case made
that any effort, even a charter, should include or be preceded
by a systematic review of what has been attempted already and
the reasons those efforts faired to gain traction.  If we do not
do that, we are almost certain to repeat old mistakes.

thanks.
   john

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 28 Jul 2021 06:18:13 +1000

> do that, we are almost certain to repeat old mistakes.

Thanks John.  I would agree that we've been down approximately similar paths before.  I'd also argue that the need hasn't gone away, and that I pretty clearly demonstrated that the major email services are all "solving" this problem in their own separate ways - and in a way that puts undue burden on end-user email recipients.

I would expect that the chartering effort would include a review of past attempts as well as of existing solutions to the problem!  While the standard approach attempts may not have gained traction, non-standard work arounds certainly have gained traction in the intervening time, so if we do nothing we are also repeating a mistake, which is to encourage non-standard and incompatible alternatives to proliferate.

Regards,

Bron.