[dispatch] Bron's Large Email problem

[Michael Richardson <[e-mail]>]

Having just watched DISPATCH from 2022-07-25, I want to encourage Bron and
others to continue work on this problem.

It seems that we ought to spin up a ML for this discussion: we could write a
clearer problem statement and come back to dispatch.  It might be trivially
enough a solution that it will fit into another WG, or AD-sponsor.

I had to slow down my playback to catch what Mark Nottingham said.
(that's a cool thing... black background... floating head.)
I think that he said:
   * prone to over-engineering
   * the most obvious way to do this is fragment identifiers
   ( http://foo.example/bar#IDENTIFIER )
Alas, the chat is not recorded by the youtube version.

I agree that URI fragments are probably the right answer, but there is
probably many details of the encoding that matter.  (I'd base64 some CBOR...)

I also wonder about a relationship to TIGRESS.
I agree with EKR about the security properties.

--- scope questions that the ML might address

Over the past 15 years, I've done lots of work with virtual (machine)
appliances, and needed to throw around multi-tens-of-gigabyte VM images,
often across oceans.

There was a point where I figured out that pushing from my Ottawa DC
to my NJ data center was twice as fast as pushing it to Montreal first, and
from NJ it was significantly faster getting the data to San Jose, even though
the path to San Jose appeared to go through NJ.
Given that it sometimes take more than an hour to get the file out of my
office, and time zones and the like, I often don't need it to arrive
instantly.

I think that last time that Bron mentioned this work (I feel it was more than
one IETF ago, but...) that being able to move the files closer to the
consumer(s) in the "background" was a thing he also cared about.
I think that the emailable enables a market for this kind of service.
(Yeah, it's a dotcom I'd want to work in)

I would like my mail server (located on-prem) to know enough about these
links that it could actually start the download sooner for me.

Much of this is significantly enabled by knowing the file is encrypted.

I come back to thinking about UUCP here :-)

So question to me is about how we can both:
  a) make the URI as ubiquitous as HTTP(S)
  b) embui it with magical properties so that things that know what it is can
  recognize they can connect to the nearest hub rather than across the planet.

ni: links come to mind.  The whole URI resolver problem comes to mind.
(Was it just a market failure, or was there also something technical that we
got wrong)

Maybe it's just a question of multipart/alternative of external-body entities.
I can also imagine MTAs that rewrite the URL as it passes through them, but
I'm really un-enthusiastic about that, as it will break signatures, whether
S/MIME, PGP or DKIM.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide