Re: [Wpack] package: URL scheme

This use of a fragment matches the way the TAG's packaging draft identified
subresources:
https://www.w3.org/TR/2015/WD-web-packaging-20150115/#fragment-identifiers.
I have some discussion of the option at
https://docs.google.com/document/d/1BYQEi8xkXDAg9lxm3PaoMzEutuQAZi1r8Y0pLaFJQoo/edit#heading=h.jkcl1u8boyar,
but I realize I didn't include the part that worries me most there:

We need to make the nested URL contribute to the resource's origin, or else
when folks create a bundle of multiple sites for distribution together,
their storage will collide. Including part of the fragment into the origin
would be novel and potentially break assumptions and cause bugs. However,
it could be the best option anyway.

Jeffrey

On Thu, Jun 11, 2020 at 11:39 AM Larry Masinter <LMM@acm.org> wrote:

> I think this would work and avoid some of the squirrely awkward encodings
> , for / etc
>
>
>
>
>
> pkg+
> https://distributor.example/package.wbn#cid=https://publisher.example?q=query
>
>
>
> Define pkg+originalscheme to always returning an application/wbn
> content-type which accepts a fragment identifier which identifies the
> package component.
>
>
>
> This form avoids encoding or transforming any part of the original except
> the scheme and the fragment identifier.
>
>
>
> You can even apply fragment identifier to the publisher URL.
>
>
>
>
>
> *From:* Wpack <wpack-bounces@ietf.org> *On Behalf Of *Ted Hardie
> *Sent:* Wednesday, June 10, 2020 3:44 PM
> *To:* Jeffrey Yasskin <jyasskin=40google.com@dmarc.ietf.org>
> *Cc:* WPACK List <wpack@ietf.org>
> *Subject:* Re: [Wpack] package: URL scheme
>
>
>
> Hi Jeffrey,
>
>
>
> On Wed, Jun 10, 2020 at 3:00 PM Jeffrey Yasskin <jyasskin=
> 40google.com@dmarc.ietf.org> 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*
>
>
>
> RFC 3986, section 2.2 notes:
>
>    If data for a URI component would conflict with a reserved
>
>    character's purpose as a delimiter, then the conflicting data must be
>
>    percent-encoded before the URI is formed.
>
> Wouldn't that apply to a couple of the delimiters in the package example
> above, e.g. the  ":" in "https:"?  If so, that seems like it would change
> the display form a bit (though not the basic idea).  If that is needed, I
> think it reinforces the notion that showing these to users or expecting the
> users to grok them is a non-starter.
>
>
>
> regards,
>
>
>
> Ted Hardie
>
>
>
>
>
> 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
> <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://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
>
>