Subject: Re: [Wpack] Call for adoption of draft-yasskin-wpack-bundled-exchanges

From: Dave Lawrence <[email-masked]>
Date: Tue, 6 Apr 2021 17:07:22 -0400

Larry Masinter wrote:
> There are problems you are not solving because they're not in your
> charter or in your use cases, and not addressed by your initial
> starting point, and you've adopted some additional requirements around
> fitting into the existing web "security model" that I think are
> unattainable.

This is potentially a very interesting area of work, Larry, and
perhaps it is indeed something the group should be looking at in more
detail.  Would you please expand on these thoughts, and address
whether any of the issues you see somehow preclude aspects of the work
already done?  We might not be able to address all possible use cases,
but does the additional set of use cases that you see somehow end up
harmed by moving forward with what we have?

> I think the IETF needs another look at MIME multipart for
> multipart/related, multipart/form-data, multipart/signed,
> multipart/alternative and I'd hoped when I first heard of WPACK that
> you'd take those (and their use cases) on.

We'd certainly welcome a draft, even skeletal, that captured some of
your ideas here so that the group could review.

---

From: Sean Turner <[email-masked]>
Date: Wed, 14 Apr 2021 09:28:22 -0400

Hi! At our IETF 110 session, the sense of the room was that there was interest in adopting draft-yasskin-wpack-bundled-exchanges-04 as the starting point for a WG I-D. While we had less participantion on the mailing list during the WG call for adoption, we nevertheless feel there is enough interest to adopt draft-yasskin-wpack-bundled-exchanges-04. We will ask the authors to submit draft-yasskin-wpack-bundled-exchanges-04 as a WG I-D. We will established a GItHub repo for the I-D and shared it with the WG.

Cheers,
Dave & Sean

> On Mar 15, 2021, at 20:53, Sean Turner <[email-masked]> wrote:
> 
> Based on interest expressed at IETF 110, this email starts the call for adoption of draft-yasskin-wpack-bundled-exchanges. The I-D can be found here:
> 
>  https://datatracker.ietf.org/doc/draft-yasskin-wpack-bundled-exchanges/
> 
> This adoption call will run until March 30, 2021 at 2359 UTC. Please indicate whether or not you would like to see this I-D adopted as a WG item. Note that this is an adoption call for the draft as a starting point for the bundle format.
> 
> Thanks,
> 
> spt (for the chairs)

---

From: Larry Masinter <[email-masked]>
Date: Sun, 18 Apr 2021 15:08:38 -0700

> This is potentially a very interesting area of work, Larry, and perhaps it
is
> indeed something the group should be looking at in more detail.  Would you
> please expand on these thoughts, and address whether any of the issues
> you see somehow preclude aspects of the work already done?  We might
> not be able to address all possible use cases, but does the additional set
of
> use cases that you see somehow end up harmed by moving forward with
> what we have?
> 
> We'd certainly welcome a draft, even skeletal, that captured some of your
> ideas here so that the group could review.

Can a Yasskin-bundeled-exchange be used as the basis for replacing MIME
multipart
In use cases that are deployed?
In use cases that were intended (but didn't work out for various reasons)?

Here's an outline with a few examples

Mulripart/related
   Intended for: save web page to disk, send web-site/page by email, file
sharing
   Drawbacks:   Lacked a clear means of ensuring the package is "complete"
and
     could be experienced offline and without any data leaking.
Multipart/form-data
    Intended for: returning values from forms that include non-text data
   Drawbacks: doesn't define associated metadata for time-based media
Multipart/alternative
    Intended for: Sending different representations in a single message so
the
     receiver can select (forwarding content negotiation)
   Drawbacks: MIME types are insufficient for describing Capabilities,
Characteristics, Preferences
      No standards for minimum capability to assume.
Multipart/signed  
     Intended for: sending signed email
    Drawbacks: lack of deployed infrastructure

Many of the use cases involve email or file sharing.
They are also about the web, not only because of the same
supporting standards (HTML, CSS, URL, JavaScript) but also
in the overlapping use cases between http/email/shared 
drive/rsync/git

This not all the MIME multipart/ types, definitely not all of their use
cases.
Not all of the use cases are equally important, but a comparison
would be warranted.
 --
https://LarryMasinter.net  https://Interlisp.org

---

From: Larry Masinter <[email-masked]>
Date: Tue, 27 Apr 2021 10:12:04 -0700

Another use case I hope you will consider is how to repackage web pages that
use "data:" URLs, or guidance for when that is not advisable.

(RFC 2397)
--
https://LarryMasinter.net https://interlisp.org

> -----Original Message-----
> From: Larry Masinter <[email-masked]> On Behalf Of Larry Masinter
> Sent: Sunday, April 18, 2021 3:09 PM
> To: 'Dave Lawrence' <[email-masked]>
> Cc: 'WPACK List' <[email-masked]>
> Subject: RE: [Wpack] Call for adoption of draft-yasskin-wpack-bundled-
> exchanges
> 
> >
> > Larry Masinter wrote:
> > > starting point, and you've adopted some additional requirements
> > > around fitting into the existing web "security model" that I think
> > > are unattainable.
> >
> > perhaps it
> > indeed something the group should be looking at in more detail.  Would
> > you please expand on these thoughts, and address whether any of the
> > issues you see somehow preclude aspects of the work already done?  We
> > might not be able to address all possible use cases, but does the
> > additional set
> of
> multipart In use cases that are deployed?
the
> They are also about the web, not only because of the same supporting
> standards (HTML, CSS, URL, JavaScript) but also in the overlapping use
cases
> between http/email/shared drive/rsync/git
> 
cases.
> Not all of the use cases are equally important, but a comparison would be
> warranted.
>  --