Charter: explain relationship with WPACK

[samuelweiler]

https://w3c.github.io/miniapp/charters/wg-2020.html

Make it clear how this relates to WPACK work and why a separate standard is required.

[zhangyongjing]

see update in #83

[xfq]

Should we close this issue given that #83 has been merged?

[zhangyongjing]

Should we close this issue given that #83 has been merged?

I believe so.

[xfq]

@samuelweiler can you check https://w3c.github.io/miniapp/charters/wg-2020.html#scope to see if #83 answers your comment?

[samuelweiler]

@xfq, I want to see more technical detail about what WPAC and WebAppManifest are missing. (e.g. merely being "not a web page" doesn't mean that WPACK couldn't package it, necessarily.) Do you have any deeper analysis of what is missing?

Also, this paragraph is poorly written.

[xfq]

Do you have any deeper analysis of what is missing?

You can have a look at the explainer of the Packaging spec: https://github.com/w3c/miniapp/blob/gh-pages/specs/packaging/docs/explainer.md , which contains a comparison with other packaging technologies, including WPACK.

Also, this paragraph is poorly written.

Any specific suggestion on the text?

[samuelweiler]

@jyasskin. Do you concur that WPACK is not suitable for MiniApp packaging?

[jyasskin]

WPACK isn't finished, so I wouldn't try to convince the MiniApp folks that it's definitely suitable, but I also wouldn't conclude at this point that it's definitely not suitable. Some thoughts to consider:

1. Do MiniApps have globally-unique names? Maybe that's the appID? If so, we can probably find a way to name their subresources with URLs, which would probably handle the "a web origin is always assumed" objection. The format WPACK is developing doesn't assume that the URLs that name resources are retrievable over the internet, even though some of its use cases do.

2. Is there any metadata that needs to be attached to MiniApp resources? For example, might a resource have its own CSP? Does the execution environment need to know the Content-Type of a resource independently of its context? If so, HTTP response headers are a good way to attach that. I don't see a specification for the page1.json files, which might be where that information is stashed in the ZIP-based format.

3. Is there any use in letting a MiniApp host load an app while it downloads? That sort of incremental loading is prevented by using ZIP, which stores the authoritative resource names at the end. WPACK's format puts the index at the beginning to allow incremental loading, but this has the downside of making it harder to incrementally add to a package.

4. WPACK bundles probably won't wind up embedding signatures into HTTP headers, but also probably won't use CMS/PKCS#7.

Maybe we can try to keep communication open to see if the tradeoffs change as both groups make progress?

[jyasskin]

The IETF WPACK WG's chartering process encountered a similar question about how it would interact with generic HTTP signing. The charter wound up threading the needle by including "The WPACK working group will work closely with the HTTPbis working group, in particular WPACK will attempt to reuse HTTPBIS work on HTTP signing."

Would it make sense for the MiniApps charter to say that the WG will consider reusing WPACK formats if those turn out to be the best option for the MiniApps goals?

[samuelweiler]

Thank you very much, @jyasskin!

[zhangyongjing]

WPACK isn't finished, so I wouldn't try to convince the MiniApp folks that it's definitely suitable, but I also wouldn't conclude at this point that it's definitely not suitable. Some thoughts to consider:

1. Do MiniApps have globally-unique names? Maybe that's the appID? If so, we can probably find a way to name their subresources with URLs, which would probably handle the "a web origin is always assumed" objection. The format WPACK is developing doesn't assume that the URLs that name resources are retrievable over the internet, even though some of its use cases do.

Yes, a MiniApp has an unique ID appID, but it's not defined as a URL. MiniApp URI is a seperate topic still under discussion.
A subresources inside a MiniApp package can be accessed using relative uri i.e. the path member in the manifest.

2. Is there any metadata that needs to be attached to MiniApp resources? For example, might a resource have its own CSP? Does the execution environment need to know the Content-Type of a resource independently of its context? If so, HTTP response headers are a good way to attach that. I don't see a specification for the page1.json files, which might be where that information is stashed in the ZIP-based format.

I assume most metadata associated with a MiniApp is captured in the manifest file, which can be further enriched if needed. The page-specific json file is to be specified. The content is expected to be a subset of the manifest file, such as the window configuration of the particular page that should override the global configuration in the manifest.

3. Is there any use in letting a MiniApp host load an app while it downloads? That sort of incremental loading is prevented by using ZIP, which stores the authoritative resource names at the end. WPACK's format puts the index at the beginning to allow incremental loading, but this has the downside of making it harder to incrementally add to a package.

There are some 'sub-packaging' machanisms used in existing implementations to optimize the loading performance of a MiniApp. The general idea is to divide a big pacakge into a base package and several additional sub-packages. It's not yet captured in the current spec, but should be considered later when the baseline is stable.

4. WPACK bundles probably won't wind up embedding signatures into HTTP headers, but also probably won't use CMS/PKCS#7.

Maybe we can try to keep communication open to see if the tradeoffs change as both groups make progress?

Sure we can keep communication and see opportunities of collaboration.

Above are just my two cents. Other CG colleagues are welcome to comment. Thanks.

[ylafon]

After analysing this, I didn't see current use cases that would mandate the use of WPACK (but nothing against its use either). If the need of some use cases of WPACK surface, then of course reusing it instead of creating a similar but not compatible solution would be good.
Like: Is there a need to distinguish publisher and distributor for that package? Is there a need to ensure integrity if distributed without https?
It will depend also on the discussions and solution used to address deep linking into mini apps, so it is an open subject.

[xfq]

Should we update the charter about communication with WPACK folks? Or can we close this issue?

[ylafon]

To me, there is no need for WPACK unless some characteristics of it becomes needed in the design of the packaging format.
I would drop it from the charter, and let the WG decide if they need something here or not. No need to formalise relationships that will probably not exist. So I am for closing this.
Thanks,

[xfq]

Closing per https://www.w3.org/2020/11/19-miniapp-minutes.html#t03