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

From: Sean Turner <[email-masked]>
Date: Mon, 15 Mar 2021 20:53:23 -0400

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: Jeffrey Yasskin <[email-masked]>
Date: Mon, 15 Mar 2021 17:59:58 -0700

I, predictably, support the WG adopting my draft and continuing to develop
it toward consensus.

Jeffrey

On Mon, Mar 15, 2021, 5:53 PM 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:
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpack
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 16 Mar 2021 15:59:53 +1100

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 <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Daniel Ehrenberg <[email-masked]>
Date: Tue, 16 Mar 2021 23:16:57 +0100

I support the WG adopting the document, with the understanding that the
WG will soon consider making the kinds of significant changes that we
discussed in IETF 110 (e.g., #617, #618, #619 in Jeffrey's GitHub repo,
and possibly a corresponding name change from "Web Bundles" to "bundled
responses").

As for use cases and privacy/security analysis: I have a fairly
different set of use cases in mind compared to Jeffrey's use cases
document. I've tried to write about these, including implications for
privacy, at https://github.com/WICG/resource-bundles (though based on
recent feedback, I'm planning on making significant changes). However,
as Martin has pointed out, this repository is a bit wordy and not quite
to the point of what is relevant for IETF. If someone could suggest some
examples to follow on how to write these documents, I can work on them
in the coming months.

Is it OK for the WG to adopt just the main document for now, with the
goal to draft and adopt those other supporting documents in the coming
months, well before sending it all off to IESG?

Dan

On 2021-03-16 01:53, Sean Turner 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:
> 
> 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: Sean Turner <[email-masked]>
Date: Fri, 19 Mar 2021 22:51:31 -0400

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 <[email-masked]> wrote:
> 
> Hi Sean,
>

---

From: Larry Masinter <[email-masked]>
Date: Fri, 19 Mar 2021 21:40:57 -0700

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 <[email-masked]> On Behalf Of Sean Turner
> Sent: Friday, March 19, 2021 7:52 PM
> To: Mark Nottingham <[email-masked]>
> Cc: WPACK List <[email-masked]>
> 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
> 
> > 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,
> >
> >
> >> 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: Jeffrey Yasskin <[email-masked]>
Date: Mon, 22 Mar 2021 09:15:44 -0700

We have an I-D for use cases, at
https://tools.ietf.org/html/draft-yasskin-wpack-use-cases-01. I think it's
ready for adoption, at least as a starting point for future work.

Jeffrey

On Fri, Mar 19, 2021 at 9:41 PM Larry Masinter <[email-masked]> 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:
> > > I don't have access to minutes of the meeting yet, so this may have
> already
> > been answered --
> > >
> for
> indicate

---

From: Jeffrey Yasskin <[email-masked]>
Date: Mon, 22 Mar 2021 14:57:59 -0700

My understanding of the charter discussion was that we expected to need
separate documents on privacy and security because signing-as-other-origins
has such a big effect on the web origin model. It could make sense to hold
up adoption of the signing document on those drafts being started.

However, bundling without signing has a more localized effect, which should
fit in the single document's privacy and security considerations section.
We should continue to improve that section in the same way we plan to
improve the rest of the draft.

A use cases document
<https://tools.ietf.org/html/draft-yasskin-wpack-use-cases-01> is ready for
adoption. It has, historically, not attracted much discussion from the
people who asked me to write it, but if having it adopted by the WG would
attract more interest, I'm all for it. I see Daniel also has some concrete
changes to propose, I think especially around promoting
https://wicg.github.io/webpackage/draft-yasskin-wpack-use-cases.html#name-subresource-bundling
to "essential". I think it's easier to tell whether the WG supports that
sort of change after we adopt the document.

Jeffrey

On Fri, Mar 19, 2021 at 7:51 PM Sean Turner <[email-masked]> wrote:

> 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
>
> already been answered --

---

From: Daniel Ehrenberg <[email-masked]>
Date: Mon, 22 Mar 2021 23:20:22 +0100

I'd have an easier time supporting the adoption of the use cases
document if it did not prioritize use cases which depend on signed
bundles. Maybe we should split the use cases document, and produce one
which focuses only on unsigned bundle use cases and requirements. This
could clarify the more limited issues in terms of privacy and security
for the unsigned case. In addition to expressing the importance of
subresource loading, I'd add further use cases which are not currently
reflected (around tooling and serving conventions, which may have the
biggest developer experience impact, even if it's not something that
clients will receive directly).

I will be happy to draft these proposals for changes, though it will
probably take me a few months to find the time to do so properly. I'd
like to learn more about how to write the kinds of use case documents
that IETF tends to produce. Could anyone recommend any examples to
reference?

Thanks,
Dan

On 2021-03-22 22:57, Jeffrey Yasskin wrote:
> My understanding of the charter discussion was that we expected to
> need separate documents on privacy and security because
> signing-as-other-origins has such a big effect on the web origin
> model. It could make sense to hold up adoption of the signing document
> on those drafts being started.
> 
> However, bundling without signing has a more localized effect, which
> should fit in the single document's privacy and security
> considerations section. We should continue to improve that section in
> the same way we plan to improve the rest of the draft.
> 
> A use cases document [1] is ready for adoption. It has, historically,
> not attracted much discussion from the people who asked me to write
> it, but if having it adopted by the WG would attract more interest,
> I'm all for it. I see Daniel also has some concrete changes to
> propose, I think especially around promoting
> to "essential". I think it's easier to tell whether the WG supports
> that sort of change after we adopt the document.
> 
> Jeffrey
> 
>> 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
>>
>>> 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,
>>>
>>>
>>>> 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:
>>>>
>>>>
>>
>>>> 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)
> Links:
> ------
> [1] https://tools.ietf.org/html/draft-yasskin-wpack-use-cases-01

---

From: Sean Turner <[email-masked]>
Date: Tue, 23 Mar 2021 09:06:48 -0400

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 <[email-masked]> wrote:
>

---

From: Larry Masinter <[email-masked]>
Date: Tue, 23 Mar 2021 23:10:59 -0700

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

> From: Sean Turner <[email-masked]>
> Sent: Tuesday, March 23, 2021 6:07 AM
> To: Larry Masinter <[email-masked]>
> Cc: Mark Nottingham <[email-masked]>; WPACK List <[email-masked]>
> 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
> 
> > 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,
> >
> > --
> >> 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
> >> 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
> >>
> >>> document,
> >> and a security analysis document will be adopted at the same time as
> >> the bundling document. What's their status?
> >>>
> >>> Cheers,
> >>>
> >>>
> >>>> 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: "Martin Thomson" <[email-masked]>
Date: Thu, 25 Mar 2021 16:17:17 +1100

Let's do it.

I would like to see Dan's proposals adopted (mostly), and probably more than that, but as I said at the meeting, I have confidence that Jeffrey will do the right thing.  We should continue chatting.

---

From: Kinuko Yasuda <[email-masked]>
Date: Mon, 29 Mar 2021 13:02:29 +0900

I support this.

I'd be happy to see this format and Dan's proposals will eventually have a
good convergence, but I also believe that it's important to have the common
base format for further discussion, and Jeffrey has been making a
great judgement on addressing various discussion points.

On Thu, Mar 25, 2021 at 2:17 PM Martin Thomson <[email-masked]> wrote:

> Let's do it.
>
> I would like to see Dan's proposals adopted (mostly), and probably more
> than that, but as I said at the meeting, I have confidence that Jeffrey
> will do the right thing.  We should continue chatting.
>