Re: [Wpack] package: URL scheme

I have a bunch of concerns about this approach, but let's start with a fairly major one:

This buries the authority.  If your authority is truly publisher.example, then that should be the authority component.  If you regard the rest as a split between the remainder of the identity of the resource itself and some secondary information about how that resource might be obtained, then you might have something closer to how you might want to structure a URI.

On Thu, Jun 11, 2020, at 08:00, Jeffrey Yasskin wrote:
> Hi all,
> 
> I wanted to raise awareness of a discussion about the URL scheme for 
> addressing resources within bundles 
> (draft-yasskin-wpack-bundled-exchanges).
> 
> We seem to be heading toward a URL of the form 
> package:<encoded-package-url>$<encoded-resource-uri>, which for a 
> package URL of https://distributor.example/package.wbn and resource URI 
> of https://publisher.example/page.html?q=query would lead to a URL of:
> 
> *package:https:,,distributor.example,package.wbn;q=query$https:,,publisher.example/page.html?q=query*
> 
> This arises from several considerations:
> 1. A bundle is served from a URL.
> 2. After a user downloads the bundle, it gets a new URL, often 
> file:///...
> 3. We can also hash the bundle to get a URI that stays stable across 
> transfers.
> 4. Resources inside a bundle are named by URIs (which, since the bundle 
> has an index, are also URLs even if, like urn:uuid:..., they wouldn't 
> normally be locators).
> 5. Once a user downloads a bundle, for web browsers to give its content 
> storage that's persistent across reloads, as requested in 
> https://github.com/WICG/webpackage/issues/498, the content needs to be 
> assigned a non-opaque origin.
> 
> I'm updating one of the documents about this in 
> https://github.com/WICG/webpackage/pull/584 and would welcome comments 
> here or there.
> 
> The URLs are obviously gross, so 
> https://github.com/WICG/webpackage/pull/560 suggests that browsers 
> avoid showing them to users in most cases. 
> 
> We could potentially simplify things if packages named things with just 
> paths instead of full URIs. We'd then name things based on the bundle's 
> origin. However, this loses archiving use cases.
> 
> This is all further discussed in the following documents and issues, 
> but you shouldn't feel responsible to read everything here:
> 
> * 
> https://docs.google.com/document/d/1BYQEi8xkXDAg9lxm3PaoMzEutuQAZi1r8Y0pLaFJQoo/edit#
> * 
> https://chromium-review..googlesource.com/c/chromium/src/+/2226248/7#message-0a3efda5aff84770a1729422a5b26aeca3ee4e80 <https://chromium-review.googlesource.com/c/chromium/src/+/2226248/7#message-0a3efda5aff84770a1729422a5b26aeca3ee4e80>
> * https://github.com/WICG/webpackage/issues/583
> * 
> https://github.com/WICG/webpackage/blob/master/explainers/navigation-to-unsigned-bundles.md#urls-for-bundle-components
> * https://lists.w3.org/Archives/Public/uri/2019Nov/0000.html
> 
> Thanks,
> Jeffrey
> _______________________________________________
> Wpack mailing list
> Wpack@ietf.org
> https://www.ietf.org/mailman/listinfo/wpack
>