Re: [Wpack] Factoring out some parts of the Web Bundle format

Why don't you use HTTP range retrieval to access parts of a  bundle? 
It's OK not to have URLs for the parts without an explicit reification.

It seemed to work for PDF.

--
https://LarryMasinter.net https://interlisp.org

> -----Original Message-----
> From: Wpack <wpack-bounces@ietf.org> On Behalf Of Daniel Ehrenberg
> Sent: Friday, February 19, 2021 11:54 AM
> To: wpack@ietf.org
> Subject: Re: [Wpack] Factoring out some parts of the Web Bundle format
> 
> On 2020-12-01 15:47, Daniel Ehrenberg wrote:
> > Hi WPACK WG,
> >
> > As I mentioned in the message "Broadening the WPACK WG charter", I'm
> > very interested in Web Bundles for subresource loading, e.g.,
> >
> https://github.com/WICG/webpackage/blob/master/explainers/subresourc
> e-
> > loading.md . The Web Bundle format has a great architecture, in terms
> > of having an extensible set of sections, to permit various different
> > usage profiles.
> > This WG could use take advantage of this architecture in order to
> > define a cleanly layered format. In particular, a few features are not
> > used for subresource loading:
> > - primary URL: not meaningful, as the bundle is not being navigated to
> > - manifest section: not used, similarly--the manifest should be linked
> > from the document which includes the subresources
> > - variants: not recommended, as content negotiation should be done
> > when deciding which bundle to include, to avoid wasteful downloads
> >
> > I think we can factor each of these features out from the core Web
> > Bundles Internet-Draft and put them into a separate Internet-Draft
> > which indicates how to use bundles to represent whole pages, much like
> > the "signatures" section was recently removed from the Web Bundles
> draft.
> > For this, I would suggest:
> > - The primary URL should be located in a separate, optional section,
> > like the manifest section.
> > - The primary URL and manifest sections should be factored out into
> > this other draft
> > - For variants, the story is a bit trickier, since it is integrated
> > into the responses section. Honestly, I'm having trouble understanding
> > the motivation for Web Bundle's variants support, e.g., what use cases
> > it is meant to satisfy. Some kinds of negotiation (e.g., with Client
> > Hints or
> > UA) extends outside of the variants model, if I understand correctly.
> > Is there something else we can do to future-proof the binary format
> > for this support, rather than including this particular format in the
> > core RFC?
> >
> > There are other additional sections which may be useful for some
> > applications. For example, within build tooling, a section could be
> > added to represent the dependency graph among subresources. So, Web
> > Bundles with this modified factoring would represent an excellent
> > basis for a variety of uses.
> >
> > What do you think?
> >
> > Thanks,
> > Dan
> 
> I've filed a few PRs against Jeffrey's draft proposal to make these
changes
> [1][2][3]. What do you think? Should we follow up on this topic in the
> upcoming IETF 110 WPACK WG meeting?
> 
> Dan
> 
> [1] https://github.com/WICG/webpackage/pull/617
> [2] https://github.com/WICG/webpackage/pull/618
> [3] https://github.com/WICG/webpackage/pull/619
> 
> _______________________________________________
> Wpack mailing list
> Wpack@ietf.org
> https://www.ietf.org/mailman/listinfo/wpack