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

[Larry Masinter <[e-mail]>]

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 <[e-mail]> On Behalf Of Larry Masinter
> Sent: Sunday, April 18, 2021 3:09 PM
> To: 'Dave Lawrence' <[e-mail]>
> Cc: 'WPACK List' <[e-mail]>
> Subject: RE: [Wpack] Call for adoption of draft-yasskin-wpack-bundled-
> exchanges
> 
> >
> > 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.
> 
> 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
>