Skip to main content

Minutes IETF110: wpack
minutes-110-wpack-00

Meeting Minutes Web Packaging (wpack) WG
Date and time 2021-03-12 14:30
Title Minutes IETF110: wpack
State Active
Other versions plain text
Last updated 2021-03-20

minutes-110-wpack-00
# WPACK@IETF110

Chairs: Sean Turner, David Lawrence
Responsible AD: Francesca Palombini

Notes taker: Chris Lemmons

jabber logs: https://www.ietf.org/jabber/logs/wpack/2021-03-12.html

## Logistics

### Time

FRIDAY, March 12, 2021 @ 1530-1630 UTC

### Meeting Information

Meetecho (a/v and chat):
https://meetings.conf.meetecho.com/ietf110/?group=wpack&short=&item=1

Audio (only):
http://mp3.conf.meetecho.com/ietf110/wpack/1.m3u

CodiMD (notes):
https://codimd.ietf.org/notes-ietf-110-wpack

## Agenda

### Administrivia - Chairs (Sean Turner, David Lawrence)

### Work Towards Adopting Web Bundles

Presenter: Jeffrey Yasskin (50min)
Presentation: TBD
I-D:
https://www.ietf.org/archive/id/draft-yasskin-wpack-bundled-exchanges-03.txt
Repo:
https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html

#### Slide 9

Daniel Ehrenberg: The motivation for removing some of these features is to
reduce the scope to increase the adoption. There is particular concern around
how content-blockers will work in this context.

Martin Thomson: I think this is the right sort of thing to be thinking about
right now. But a narrowly targeted thing is more likely to be successful here.
If we cut a little too deep, we always have the opportunity to define something
more specific later, possibly with a different MIME type.

Can you talk about the current state of how people expect to use the bundle or
pull things out of them.

Jeffrey: Chrome is working on an origin trial that loads somewhat incautiously.
It lets you use a bundle for sub-resources. The likely eventual answer is a
sort of loading map that intercepts requests. Bundles probably have internal
references as well.

Martin: The fetchmaps concept is important. The idea is that when a page
requests one url, the browser can replace the url directly, possibly with one
in a bundle.

Daniel: Bundles allow incremental loading, this is really important, but not
fully fleshed out at this point.

Jeff: We haven't pinned down the details on how bundles and caching interact.

#### Slide 10

Martin: Are there any ordering requirements for these fallback URLs?

Jeff: No ordering requirements in particular, other than the fact that you have
to wait for it to be transmitted.

Martin: No structural constraints?

Jeff: No.

Martin: So what special behavior is associated with the fallback url?

Daniel: Different use cases are going to have very different semantics for this
fallback url. We have discussion of fallback semantics, but it is going to vary
based on the use case. I think that's why it would be a good thing to remove
this from the draft. There are a lot of valid points in this design space,
though.

David: We're discussing refining the document, but we haven't adopted it.
Perhaps we can focus our attention on whether we want to adopt it?

#### Discussion

Show of hands: Should we formally adopt this draft as a working group document?
Raised Hands: 12
Unraised Hands: 2
Total People: 27

Show of hands: Do you OBJECT to adopting this document?
Raised Hands: 0
Unraised Hands: 9
Total People: 26

Chairs will take it back WG adoption to list. Will also move the datatracker
status to be "Candidate for WG Adoption".

David: I will get the GitHub repo set up.

PSnyder (from Jabber, voiced at mic by dkg): Brave (and Eyeo I believe, but I
don't mean to speak for them) have both stated serious concerns with the
implications for opinionated / "blocking" clients. Others who do content
blocking have registered similar concerns on the original GH issue I filed. I
know JY and MT have found those concerns either mistaken, or a cost worth the
benefit from the proposal, or similar. I don't mean to re-litigate that here
(at least not in this text field 🙂 ). But I just wanted to re-note that the
folks who are most invested in / concerned with content blocking are the folks
who have raised the loudest concerns. Some of the previously noted rejections
or responses to those concerns are from vendors who do (relatively) less
blocking in their products. Again, I don't mean to re-argue the specific
concerns here, only that I hope the group will consider the content blocking
concerns going forward, and will solicit / invite input from the content
blocking folks with the content blocking concerns 🙂

Daniel: One aspect of the content-blocking concerns is whether a bundle should
represent a single page on the web. This differs from the idea of sub-resource
loading which is more granulal. There are different concerns that I'm
attempting to address with some of these PRs. Do these removals help work
toward your goals?

Pete Snyder: Yes, they do.

Martin Thompson: Let's be clear: this is a starting point. Pete and others have
expressed concern that we do something bad for semantic availability type
features. There are risks. We could design something very, very bad for those
use cases and we need to work through those things. Indexes at the end makes it
easy to change contents of bundles, for example.

Pete: i think there is a core for the sub resource loading that is great, and
being able to split the sub-resource case from the document case seems valuable

Jeff: Let's get a sense of the room on these four issues. How do people feel
about removing the fallback url.

Martin: The idea of a fallback is interesting. It's largely for compatibility
reasons. It provides an escape hatch for simpler clients. I don't feel this use
case as acutely. We should discuss whether it should be metadata or sections or
something else and it can enable a variety of use cases.

Jeff: The reason for a primary url is when you navigate to the bundle itself
and need to know what to load.

Martin: Lots of ways to skin this cat.

Jeff: Only reason not to move this is because it prevents us from using it for
fallback.

Martin: If you think of a referencing infrastructure can refer to either a
bundled or non-bundled resource, we don't need this.

Jeff: Hum?

Daniel: Keep in mind, these things can move to another document. Just because
we remove it from here, we can still move it into a separate document.

Show of Hands: Should we merge in PR 617 into the draft for initial submission
as a wg doc? Raised Hands: 5 Unraised Hands: 2 Total People: 26 Sense of the
room: Quiet positive hum

Jeff: Should we remove content negotiation?

Daniel: If you're thinking about subresource loading, this adds more
complexity. For the content-blocking story, this really comes back to
separating subresource loading cases from whole website cases. Offline usage is
really a separate question.

Martin: This one is hard because I can see the value in multiple image sizes or
multiple languages. Having all the different CSS for small and large screens
instead of the single factor that is often delivered can be useful. I'm on the
fence. why would we keep this?

Jeff: You mentioned reasons to keep it. But more speculatively, when the server
would check something like Sec-Fetch headers and wants to constrain things,
then it could use that to block content from within the bundle. But more often,
it's for offline uses.

Martin: Can we do CORS with bundles? I'm not sure it's possible at all.

Daniel: CORS are in response headers. Could we do it that way?

Martin: But you would have to put that in an OPTIONS request.

Daniel: We have two kinds of index sections. You could have a basic bundle with
nothing negotiated and an advanced bundle with this additional content
negotiation.

Jeff: I'm not a huge fan of two different section types. But we _could_ do it
that way. Hum?

from the chat: Psynder: yes, removing content negotiation here is important. 1)
it makes it more likely we'll maintain the benefits of blocking (less likely to
fetch multiple versions of the same resource), 2) it makes personalization less
likely (though def not impossible of course)

Sean Turner: The discussion in the chat suggests that we could adopt the -04
and then decide how we want to make changes at that point. We can merge these
at any point. No objections from the participants.

Martin: re: negotiation. Thinking about the image case... perhaps we don't need
content negotiation for image selection. We can just have clients downscale
images if they need to because we're already sending all the bytes to start
with. Things like translations need this negotiation more. Sites might do
"negotiation" after the fact via scripting, though.

Show of Hands: Should PR 618 to remove content negotiation be merged for the WG
doc? Raised Hands: 5 Unraised Hands: 4 Total People: 26 Sense of the room:
Pretty even, warrants more discussion on list.

Jeff: Should we move the manifest section out of the core?

Martin: I think a manifest is another sort of top level thing you might want to
go looking for. The question of whether you use a dedicated section for it or
whether it's just another thing that is just annotated as manifest is
important. Different use cases are going to need different sorts of manifests.

Jeff: So move it out so we can have different kinds of manifests for different
kinds of use cases?

Martin: Yes.

Jeff: The current system relies on content negotiation. If we remove that, then
this will face challenges.

Sean: We're running out of time, so we're going to have to take some of this to
the list.

Daniel: What about an interim?

Sean: We can take it to the list, but I was thinking the same thing.

Show of Hands: Interesting in an interim
Raised Hands: 9
Unraised Hands: 1
Total People: 26