Re: [Wpack] package: URL scheme

Ted Hardie <ted.ietf@gmail.com> Wed, 10 June 2020 22:44 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: wpack@ietfa.amsl.com
Delivered-To: wpack@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA253A1580 for <wpack@ietfa.amsl.com>; Wed, 10 Jun 2020 15:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXGMzaCvVlhU for <wpack@ietfa.amsl.com>; Wed, 10 Jun 2020 15:43:59 -0700 (PDT)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD023A157F for <wpack@ietf.org>; Wed, 10 Jun 2020 15:43:59 -0700 (PDT)
Received: by mail-oi1-x22c.google.com with SMTP id 25so3617238oiy.13 for <wpack@ietf.org>; Wed, 10 Jun 2020 15:43:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eEs44vOb5MuITNM8DyRZ8sNr7iceHcIGCdz2mIy7qxU=; b=GRHvQnzqDI22hpFbxd8PrbJqH7xuFU4lKhMsb432JTFuFIhPXh+zvcwadOlOuLN/Xi k/C2YXlfZn/WvB8ytdLQHL0MFq+w7Ktq6wreqmuHb1ev9a4noDxlhSOU723whnkoTtDd IgDy+P2WqkBuku88FQQAnTxlL7n32jQNBfdqG8XEPjRw2+KUT12TDKESGh7X83uvrVqH awvFOt04h6WGEnJeWF9D2UfLX/z4PuIVap2Qrl3OyqXpoY8u4oxuIG6Y8gL47wsxOff1 bTQYOgrUfXEBTou6xK1E40aoObnWX1m/jrFGx0XTG4Cld8/rnamReigBfwAj85SRUy2y xVXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eEs44vOb5MuITNM8DyRZ8sNr7iceHcIGCdz2mIy7qxU=; b=k1SOAKzdwVU9KPCzOnURElR4IIz4g7snnVLMM6Ju0ybfucM6G9FJTRw7idDJtOpEvT QJsV8/1+SGhHAgBe/hXuLLrdUiXzdUo0uEJtPa3dWGqgs04nC5ATNSu1GZ/XcrWtuzIi 1HinuvHj2Gva8uAgItGyMIvQ8KN0zGnaWedvVM9kQu6foZjNYbUUtKbZoC9mI1YrMaS6 mI7Xtj52ErsOj4lJvKRF091+QFTzVoXkmHGxjY3B+k9pwmkPKbIlZQksqAkF9q8cejTA y4xAX/ozLf67di+rhvHi29bv45yBQKgWy/p91fVj76UudsUeGQb17uXCvY1BPo7q0QVO Ozpg==
X-Gm-Message-State: AOAM530emm5OidYLZg7v7IHN8NLHhYncGct7LxRFskcjxNm8S68Ar8yT VFmdOrSGzD95M09aESMuj5QFkgHHmflGYnLC2uM=
X-Google-Smtp-Source: ABdhPJyAJXoivAKOZTawduSr7FWxnZwR0YCjOlp2Sqzv8maaTuGC/fScC3R3qaIP9dxpxMlTSdXRuQoTZoBCGwXiy0g=
X-Received: by 2002:aca:80f:: with SMTP id 15mr3545218oii.167.1591829039014; Wed, 10 Jun 2020 15:43:59 -0700 (PDT)
MIME-Version: 1.0
References: <CANh-dXndPaue3zAADhpc+wyNb8dxs=nVKOAp1n=6SMCKoUe=eQ@mail.gmail.com>
In-Reply-To: <CANh-dXndPaue3zAADhpc+wyNb8dxs=nVKOAp1n=6SMCKoUe=eQ@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 10 Jun 2020 15:43:32 -0700
Message-ID: <CA+9kkMAPqvXUwq3XqeqzkurmPbMVvR3bc_YPG6xQK0PUS4em-Q@mail.gmail.com>
To: Jeffrey Yasskin <jyasskin=40google.com@dmarc.ietf.org>
Cc: WPACK List <wpack@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000069e6cf05a7c29423"
Archived-At: <https://mailarchive.ietf.org/arch/msg/wpack/VI0l8ridBBO9VXIGIeWlW6Rb8LI>
Subject: Re: [Wpack] package: URL scheme
X-BeenThere: wpack@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Web Packaging <wpack.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wpack>, <mailto:wpack-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wpack/>
List-Post: <mailto:wpack@ietf.org>
List-Help: <mailto:wpack-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wpack>, <mailto:wpack-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2020 22:44:02 -0000

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, 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
>