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

There was just recently a question about sub-resource access. I asked about using byte-range retrieval.
The answer was that cross-resource compression was important. If you have a bundle with parts A and B such that compression C(A+B) is smaller than C(A) + C(B) then byte ranges would not help. I don't mean to argue this now, but just to point out an example where the relative priorities for different use cases affect an important part of the fundamental part of the design. 
Of course you are aware that the details of how well non-HTTP distribution and privacy considerations interact with the support of various business models based on tracking end users.

I asked about analyzing the use cases for MIME mutipart in the web:

Multipart/related (mht -- for email and archive),
multipart/form-data (for submitting forms including data)
multipart/alternative (for sending data with support  for (offline) content negotiation
multipart/byte-ranges (for responding to range requests)

How would you do these using bundled-exchanges method? And why is it better (or worse) than MIME-multipart?

At the time, MIME multipart was chosen not because it was optimal for any of its use cases but because it was adequate and well-understood.

As far as laissez-faire goes, the working group charter is a published plan. It is the agreement about your work, and it has milestones in
https://datatracker.ietf.org/wg/wpack/about/ that imply a simultaneous adoption of four drafts.

Why aren’t you following your own published plan? Did circumstances change? 
If these were independent documents, then FCFS might be a reasonable method. But they are not. The use cases and requirements do not depend on the mechanism, but the converse is not true.
--
https://LarryMasinter.net https://interlisp.org

> -----Original Message-----
> From: Sean Turner <sean@sn3rd.com>
> Sent: Tuesday, March 23, 2021 6:07 AM
> To: Larry Masinter <LMM@acm.org>
> Cc: Mark Nottingham <mnot@mnot.net>; WPACK List <wpack@ietf.org>
> Subject: Re: [Wpack] Call for adoption of draft-yasskin-wpack-bundled-
> exchanges
> 
> Larry,
> 
> It is possible that I am way more laissez-faire than most about adopting I-Ds. I
> tend to think that clearing the initial hurdle of getting any I-D into the WG will
> help other I-Ds get into the WG. Again, the bundle I-D is just a starting point
> that is not going to race ahead of the other I-Ds and will be informed by the
> use cases I-D regardless of with the use cases I-D is adopted. And, I am also
> pretty happy to start a WG adoption call for that I-D right after this current I-D
> completes, i.e., in about a weeks time.
> 
> spt
> 
> > On Mar 20, 2021, at 00:40, Larry Masinter <LMM@acm.org> wrote:
> >
> > Shouldn't you adopt the use cases first? The scope of activities and the
> "Expected Performance" (section 3) are critical.
> > The use cases I had expected that an IETF "Web Packaging" working group
> to work on would include would be the ones that led to mime multipart:
> > Multipart/related, multipart/form-data, multipart/alternative,
> > multipart/byte-ranges Each has its own set of requirements,
> >
> > --
> > https://LarryMasinter.net https://interlisp.org
> >
> >> -----Original Message-----
> >> From: Wpack <wpack-bounces@ietf.org> On Behalf Of Sean Turner
> >> Sent: Friday, March 19, 2021 7:52 PM
> >> To: Mark Nottingham <mnot@mnot.net>
> >> Cc: WPACK List <wpack@ietf.org>
> >> Subject: Re: [Wpack] Call for adoption of
> >> draft-yasskin-wpack-bundled- exchanges
> >>
> >> Mark,
> >>
> >> You make a good point about the need for the additional I-Ds, because
> >> the charter’s milestones actually call out 3 other I-Ds that address
> >> the signing mechanism as well as privacy and security. To be blunt,
> >> these other I-Ds have not yet been submitted. There was some
> >> security-related text in the bundle document that was removed and
> >> Martin Thomson had a content-based origin I-D. I am cautiously
> >> optimistic that getting the bundling I-D adopted will encourage the
> >> other I-Ds to surface because I strongly suspect that progress on the
> >> bundling I-D is likely to grind to a halt without those I-Ds. I do
> >> not think that the milestones, which are also a good year out of date
> >> at this point, should hold us back from adopting the bundling I-D. But, the
> entire set of I- Ds is required- it is the pact we made the IESG to get to done.
> >>
> >> spt
> >>
> >>> On Mar 16, 2021, at 00:59, Mark Nottingham <mnot@mnot.net> wrote:
> >>>
> >>> Hi Sean,
> >>>
> >>> I don't have access to minutes of the meeting yet, so this may have
> >>> already
> >> been answered --
> >>>
> >>> The charter says that a use cases document, a privacy analysis
> >>> document,
> >> and a security analysis document will be adopted at the same time as
> >> the bundling document. What's their status?
> >>>
> >>> Cheers,
> >>>
> >>>
> >>>> On 16 Mar 2021, at 11:53 am, Sean Turner <sean@sn3rd.com> 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)
> >>>> _______________________________________________
> >>>> Wpack mailing list
> >>>> Wpack@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/wpack
> >>>
> >>> --
> >>> Mark Nottingham   https://www.mnot.net/
> >>>
> >>
> >> _______________________________________________
> >> Wpack mailing list
> >> Wpack@ietf.org
> >> https://www.ietf.org/mailman/listinfo/wpack
> >