Web Packaging
charter-ietf-wpack-01

Interesting work to be done. As I have some non-blocking comments/questions (see below), I have entered a 'no objection' but this is mostly a 'yes'.

Suggest to replace 'Three examples to" by 'Three use cases to" in the first goal.

Unsure whether "Constraints on how clients load the formats" can be parsed as a goal.

No mention of interaction with other IETF WG.

May I assume that WPACK also encompass the naming / retrieval of those web package ?

Nit " above properties. * Support", insert a CRLF ?

Nit: should "DRM" be expanded ?

No objection to external review, but I think there are some issues we need to
see addressed prior to approval.


> * A low likelihood that the new format increases centralization or power
> imbalances on the web.

I'm glad to see this in the charter. I would really like to see this bullet
point expanded to more clearly cover the three different categories of
specific concerns described in section 4.1 of draft-iab-escape-report (or,
alternately, cite that document for further detail).

> Note that consensus is required both for changes to the current protocol
> mechanisms and retention of current mechanisms

I think this presumes a bit too much. Although the adoption of the initial
candidate documents may be highly likely, this text clearly implies that
their adoption is a fait accompli.

> In particular, because
> something is in the initial document set (consisting of
> draft-yasskin-wpack-use-cases, draft-yasskin-wpack-bundled-exchanges, and
> draft-yasskin-http-origin-signed-responses)

I also think we really need clearly-defined milestones here. Particularly,
seeing draft-yasskin-wpack-use-cases in the list of candidate documents,
I believe we need to clearly indicate whether the WG intends to publish
a use case document, especially in the context of the IESG statement at
https://ietf.org/about/groups/iesg/statements/support-documents/
If the intention *is* to publish the document, indicating that such
is the case (and why) will help during IESG review of such a document.

"* A low likelihood that the new format increases centralization or power
imbalances on the web. See discussion of this in
<https://datatracker.ietf.org/doc/draft-iab-escape-report/>"

Unlike the other goals listed, it's hard to see how this is actionable. Will the WG make design decisions differently whether this is in the charter or not? If this working group were designing a system architecture or a protocol with an architecture that implied relationships prone to centralization would need to be created or strengthened for deployment purposes, perhaps this would be an appropriate goal. But the scope here is to specify a format that will be used in the context of the existing web with all of its existing centralization and power imbalances derived from the economic properties of the businesses operating within it. To me, stating this goal is sort of like saying we'll try not to throw kindling on a forest fire that is already propelled by gale force winds. We can say we'll do that, but what actually happens won't be determined by whether we do it or not.

   * A low likelihood that the new format increases centralization or power
      imbalances on the web.

I don’t have much confidence that this can reasonably be achieved in reality, but I have no objection to having it listed as a goal.

   In particular, because
   something is in the initial document set (consisting of
   <list of drafts> does not imply

I suggest that the complaint about this part could be best addressed by not listing the drafts in the charter and by saying it this way:

NEW
   In particular, because
   something is in an initial working group draft does not imply
END

It would be good to reference ESCAPE somehow.

I have some questions.

Does there exist an easy way to resolve the clash between this primary and non-goal?
Primary goal:
* The ability to create an unsigned snapshot of a web page without the
cooperation of its publisher.

Non-goal: 
* A way to distribute the private portions of a website. For example, WPACK
might define a way to distribute a messaging application but wouldn't
define a way to distribute individual messages without a direct connection to
the messaging application's origin server.

So the issue I wonder over, is that if I as a user decide to snapshot a web-page that contains some server-side dynamically generated resources. To my understanding that would result in that dynamically user specific generated content would be captured. How does this relate to the above non-goal. Or are these two different usages of the targeted solution. One to allow snap shoting what one actually provided, and another a configuration for distributing a part of a web-site? 

The above thought lead to the question: Is it at all possible to prevent a user from sharing their private content if using this mechanism? Will the packager be able to determine what is private and what is not so that the user can select between a snapshot and sharing the general part of a web-site? 

Next: 

Relationship to Other WGs and SDOs

WPACK will work with the W3C and WHATWG to identify the existing security and
privacy models for the web, and to ensure those SDOs can define how this format
is used by web browsers. 

Will calling WHATWG an SDO create any issues for the IETF? WhatWG is to my knowledge an Industry Forum.

Similar as Suresh, I'm uncertain how this goal would impact the format:

"Allow the format to be used in self-extracting executables."

Actually the list of goals seems to list a quite large variety of different aspects on various levels of depth. It not clear to me if all this needs to be in the charter. If there is agreement about what the group wants to do that good of course but (as the one mentioned above) if it's not clear how a goal would actually impact the technical work/format, it not fully clear to me why it is listed in the charter.

This item seems oddly specific 

"* Allow the format to be used in self-extracting executables." 

but it is not clear to me that this is a property of the format. Can you clarify a bit what the format needs to do to meet this?

Like Adam, Alissa, and Barry I would love to see a bit more elucidation of the "avoid centralization" aspect of the charter.