[Wpack] Broadening the WPACK WG charter

[Daniel Ehrenberg <[e-mail]>]

Hi WPACK WG,

I'm very excited by the Web Bundle format being developed in this WG, to
represent a bundle of HTTP responses. It has the potential to meet a lot
of different needs! Some use cases I'm especially interested in are:
- Subresource loading (related to what's described in
https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md
, potentially with subsetting as in
https://docs.google.com/document/d/11t4Ix2bvF1_ZCV9HKfafGfWu82zbOD7aUhZ_FyDAgmA/edit#
)
- A format to use within JavaScript/Web tooling across a build pipeline,
to represent the whole static part of an application
- A way to configure web servers to serve a static directory with the
appropriate HTTP headers as well as for serving dynamic subsets of
bundles

I wrote a gist with my rough thoughts pulling together various aspects
of Web Bundle applications at
https://gist.github.com/littledan/e01801001c277b0be03b1ca54788505e .
I've been discussing it with different web platform and tooling
stakeholders, and finding broadly shared interest in meeting these goals
with a format like Web Bundles.

However, I'm not quite sure how to interpret this group's charter. The
charter's streaming and random access design goals are definitely
important for the use cases I mentioned. However, I don't know if my
goals are in alignment with those of this group: subresource loading is
explicitly identified as nice-to-have, and build tooling and serving are
not identified. It is great to consider concrete use cases to evaluate
and refine the design, but fortunately, in this case, it seems like
there is little contradiction among the needs of different applications.
The architecture of bundle sections is nicely extensible and can be
applied to meet different purposes. So I'm not sure if it's necessary to
make a hierarchy placing some use cases above others.

How would people feel about generalizing the charter to focus less on
*why* the WPACK WG wants to define a Web Bundle, and instead broaden to
*what* the group is trying to define (a general-purpose, extensible file
format for a bundle of HTTP responses which meets certain properties)?
This way, we can bring people into the coalition who might have
different motivations for representing this information, and develop a
more widely adopted standard to solve this common, reoccurring problem.

Thanks,
Dan