From nobody Wed Jun 10 15:00:26 2020 Return-Path: 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 A1E503A10F9 for ; Wed, 10 Jun 2020 15:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 680ZxaTKMwBm for ; Wed, 10 Jun 2020 15:00:17 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 1E6313A1554 for ; Wed, 10 Jun 2020 15:00:17 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id l17so3687063qki.9 for ; Wed, 10 Jun 2020 15:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=e3ICSjnRHLCqq5ulz7jOHscFFTXAeMTIRmg3Fb0u7DM=; b=aYkAIK7njON/AWJZ0MLzvG7mCR6bEFBwxKaW2j8efoE0JVVf2vfq4IX5zC2gahI0/4 2UpnEKjCV/RkdWF8ZAP18bgsk8mppnxeJ94bIHGsJrjknhqP15CGAa8IhsA/vvQqS2bi oyPAEcMdPtM1+hipFPFEcnzpgJzM4jF/OI+5/W7Yxm5egAWTd/bYWm1YsV6Jj3vtBlQQ oBqZhoKfGIz0ms6pu9ySPQRr+ueGffyU/T83EmMcpsTqoHbeOoDw77GXGBZQkdD+B7je wzpvmbNVJiNN4cJDLxOtL1KL7qPEjzkQzEI+bP5R/cMPMY5Bpsk473U9VKvElOpi58L4 qgEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=e3ICSjnRHLCqq5ulz7jOHscFFTXAeMTIRmg3Fb0u7DM=; b=mRiIR8k4nQEi2TDW5+310AAzSDOVDMp8W3JeHRzGl71dDWxpBpqfNpgjX/2tB6PTF8 YM4+AnuzlZmWGsT+BaZS5o7cC6OW4erNUa/Wwo7a25rivQ8v2MYyRkskKkYfprjcsDJN un/A9zJtKdEWZsdAJECV1sgPHeSUeQ4vMqnQNm6DWH/+K4iEWIUayIvYNO9U4sFpneQH 9t8UduQiAAz6dx4Z4xGhfjzRYlgXlbey1ISRuG3Z9PdjhSf3JVZ7ChNapi/a4w3qgJOw /nHnEswNci4CVGq5U69QkgmQPrfYDP5D37jJ+yU3913Zn92AMyWs4xOyKDji0YO2M40D 6Orw== X-Gm-Message-State: AOAM530/szzrpxD62CJCpiTryoTnbPKuQ8HfMAJqMQ48MQpUg3rXMLOI 1xwdqG+Xz6ZQsEyBUzJdT+iV3I5TNJZ+/IGLDp/RhRSSwPo= X-Google-Smtp-Source: ABdhPJwKbumLSHJRu5r112j6xBkW1Px6PTlmBY05G/Ajgeik1WeNCmNzZqY5lQBIKEwR/SJY4v1GPhP0h9dfNzEXHXg= X-Received: by 2002:a37:e110:: with SMTP id c16mr5514970qkm.38.1591826413669; Wed, 10 Jun 2020 15:00:13 -0700 (PDT) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Wed, 10 Jun 2020 15:00:01 -0700 Message-ID: To: WPACK List Content-Type: multipart/alternative; boundary="000000000000eee29d05a7c1f791" Archived-At: Subject: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 22:00:20 -0000 --000000000000eee29d05a7c1f791 Content-Type: text/plain; charset="UTF-8" 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:$, 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://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 --000000000000eee29d05a7c1f791 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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>$&l= t;encoded-resource-uri>, which for a package URL of https://distributor.example/package.wbn= and resource URI of https://publisher.example/page.html?q=3Dquery would lead to a URL o= f:

package:https:,,distributor.example,package.wbn;q=3Dquer= y$https:,,publisher.example/page.html?q=3Dquery

This= arises from several considerations:
1. A bundle is served f= rom=C2=A0a URL.
2. After a user downloads the bundle, it gets= a new URL, often file:///...
3. We can also hash the bundle to g= et 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 co= ntent storage that's persistent across reloads, as requested in=C2=A0https://github.com/= WICG/webpackage/issues/498, the content needs to be assigned a non-opaq= ue origin.

I'm updating one of the = documents about this in=C2=A0https://github.com/WICG/webpackage/pull/584=C2=A0and would we= lcome comments here or there.

The URLs are obviously= gross, so=C2=A0htt= ps://github.com/WICG/webpackage/pull/560=C2=A0suggests that browsers av= oid showing them to users in most cases.=C2=A0

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 o= rigin. 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:

=
*=C2=A0https://chromium-review= .googlesource.com/c/chromium/src/+/2226248/7#message-0a3efda5aff84770a17294= 22a5b26aeca3ee4e80

Thanks,
Jeffrey
--000000000000eee29d05a7c1f791-- From nobody Wed Jun 10 15:44:03 2020 Return-Path: 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 ; 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 ; 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 ; Wed, 10 Jun 2020 15:43:59 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id 25so3617238oiy.13 for ; 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: In-Reply-To: From: Ted Hardie Date: Wed, 10 Jun 2020 15:43:32 -0700 Message-ID: To: Jeffrey Yasskin Cc: WPACK List Content-Type: multipart/alternative; boundary="00000000000069e6cf05a7c29423" Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 22:44:02 -0000 --00000000000069e6cf05a7c29423 Content-Type: text/plain; charset="UTF-8" Hi Jeffrey, On Wed, Jun 10, 2020 at 3:00 PM 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:$, 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://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 > --00000000000069e6cf05a7c29423 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeffrey,

On Wed, Jun 10, 2020 at 3:= 00 PM Jeffrey Yasskin <jyasskin=3D40google.com@dmarc.ietf.org> wrote:
Hi all,

=
I wanted to raise awareness of a discussion about the URL scheme for a= ddressing resources within bundles (draft-yasskin-wpack-bundled-exchanges).=

We seem to be heading toward a URL of the form pa= ckage:<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=3Dquery would lead to a URL of:=

package:https:,,distributor.example,package.wbn;q=3Dquery$= https:,,publisher.example/page.html?q=3Dquery

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 b=
e
   percent-encoded before the URI is formed.
Wouldn't that apply to a couple of the delimiters in t= he package example above, e.g. the=C2=A0 ":" in "https:"= ;?=C2=A0 If so, that seems like it would change the display form a bit (tho= ugh not the basic idea).=C2=A0 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,

T= ed Hardie


This arises from = several considerations:
1. A bundle is served from=C2=A0a UR= L.
2. After a user downloads the bundle, it gets a new URL, o= ften 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. O= nce a user downloads a bundle, for web browsers to give its content storage= that's persistent across reloads, as requested in=C2=A0https://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=C2=A0https://github.com/WICG/webpackage/pull/58= 4=C2=A0and would welcome comments here or there.

The URLs are obviously gross, so=C2=A0https://github.com/WICG/webpackage/pu= ll/560=C2=A0suggests that browsers avoid showing them to users in most = cases.=C2=A0

We could potentially simplify things = if packages named things with just paths instead of full URIs. We'd the= n name things based on the bundle's origin. However, this loses archivi= ng use cases.

_______________________________________________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack
--00000000000069e6cf05a7c29423-- From nobody Thu Jun 11 11:39:33 2020 Return-Path: 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 8C1AA3A0DCD for ; Thu, 11 Jun 2020 11:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 PY2G5Pczkmpo for ; Thu, 11 Jun 2020 11:39:29 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 C4C163A0DB7 for ; Thu, 11 Jun 2020 11:39:29 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id r18so2883906pgk.11 for ; Thu, 11 Jun 2020 11:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=A6UCyP46XJcU/rId8qZLvog7yz8pqYPBQZDB9XEkBMM=; b=E7tYIWwoS9MR1MauzH9P+xK67flOxn/IFcBcz1DFPiLwKsu26M5eL5/6UrUYTm9rRZ 0bdT1a7mY/Ho57Cb9flI4un949SyQhL9MB/kVkzePTDteXwb6OgegO0/I3oeg3htFe5H frp/KS6rmSxo4FwfhU52+KG+EZBcmBGyna87sj058nxdGkZN9HynRGascP7pdI4mSf/C GOwJwT5dvQUi1FHKsfeseJ3JlQprzb7W8aSFYA+w3iDEKEkcgcFoOJjg1M0UzYDy5YkB mg8uX4XrKjpC+JmWVWRBif5zQm1kB/f/c0eUum4E0lvs9kV1aiUPwDkBnvTLT4Dvy0D9 mnAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=A6UCyP46XJcU/rId8qZLvog7yz8pqYPBQZDB9XEkBMM=; b=S1hYurAGml7HGyyqFnuOPC3Bsdwpu8vZNjeD+U+2i1i+KsXqqKGvW6vj6T39pfrWuC 8vu5/hWH/6d8IblVTkK7htAEBDN9FJUEt+f5Hp6tedkYyR0230LCEwYbJadxJ8m02srn 56FaB/sbbVIxfP19QNI96YF8GMikz+OHTAf+BdFWkz2JsztbMBtEWrow0hS7jt1BaAef zY2GCqmdBybKwKbVlQNAj6VAhY9clKg3c5BTz7TAt6C93BLJlpm8HywjzP+b1B9Izz69 WTqXnbKmfEbKJfUG2avuElIda0ykmRmHr7UVIRvvAdIHhgZc3zxjXJ5X3/nyu5QtiZlo CmDQ== X-Gm-Message-State: AOAM532nrKdsHwNRPmFvvuDFBzwhHovC8gcLuWxa+YFJm8xTyYuTRF37 V2ebUpBRrLO2y/bdjubtgfo= X-Google-Smtp-Source: ABdhPJxD/gy/pm+8up2MrfLw67sdjp1lS8k1wZMiuWQ2nlf8K0RDtiZhOHxu+91C9Sf6kT3n2ACclA== X-Received: by 2002:a65:4241:: with SMTP id d1mr8004320pgq.307.1591900768348; Thu, 11 Jun 2020 11:39:28 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id c2sm3836056pfi.71.2020.06.11.11.39.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2020 11:39:27 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Ted Hardie'" , "'Jeffrey Yasskin'" Cc: "'WPACK List'" References: In-Reply-To: Date: Thu, 11 Jun 2020 11:39:28 -0700 Message-ID: <032201d6401f$a3e58460$ebb08d20$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0323_01D63FE4.F78796C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJUN3n7f7U8Tm8IyhTb0CDwyv1MGgItZykDp8VIKZA= Content-Language: en-us Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 18:39:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0323_01D63FE4.F78796C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think this would work and avoid some of the squirrely awkward = encodings , for / etc =20 =20 pkg+https://distributor.example/package.wbn#cid=3Dhttps://publisher.examp= le?q=3Dquery=20 =20 Define pkg+originalscheme to always returning an application/wbn = content-type which accepts a fragment identifier which identifies the = package component. =20 This form avoids encoding or transforming any part of the original = except the scheme and the fragment identifier. =20 You can even apply fragment identifier to the publisher URL. =20 =20 From: Wpack On Behalf Of Ted Hardie Sent: Wednesday, June 10, 2020 3:44 PM To: Jeffrey Yasskin Cc: WPACK List Subject: Re: [Wpack] package: URL scheme =20 Hi Jeffrey, =20 On Wed, Jun 10, 2020 at 3:00 PM Jeffrey Yasskin = > wrote: Hi all, =20 I wanted to raise awareness of a discussion about the URL scheme for = addressing resources within bundles = (draft-yasskin-wpack-bundled-exchanges). =20 We seem to be heading toward a URL of the form = package:$, which for a = package URL of https://distributor.example/package.wbn and resource URI = of https://publisher.example/page.html?q=3Dquery would lead to a URL of: package:https:,,distributor.example,package.wbn;q=3Dquery$https:,,publish= er.example/page.html?q=3Dquery =20 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. =20 regards, =20 Ted Hardie =20 =20 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. =20 I'm updating one of the documents about this in = https://github.com/WICG/webpackage/pull/584 and would welcome comments = here or there. =20 The URLs are obviously gross, so = https://github.com/WICG/webpackage/pull/560 suggests that browsers avoid = showing them to users in most cases.=20 =20 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. =20 This is all further discussed in the following documents and issues, but = you shouldn't feel responsible to read everything here: =20 * = https://docs.google.com/document/d/1BYQEi8xkXDAg9lxm3PaoMzEutuQAZi1r8Y0pL= aFJQoo/edit# = =20 * = https://chromium-review..googlesource.com/c/chromium/src/+/2226248/7#mess= age-0a3efda5aff84770a1729422a5b26aeca3ee4e80 = =20 * https://github.com/WICG/webpackage/issues/583 * = https://github.com/WICG/webpackage/blob/master/explainers/navigation-to-u= nsigned-bundles.md#urls-for-bundle-components * https://lists.w3.org/Archives/Public/uri/2019Nov/0000.html =20 Thanks, Jeffrey _______________________________________________ Wpack mailing list Wpack@ietf.org =20 https://www.ietf.org/mailman/listinfo/wpack ------=_NextPart_000_0323_01D63FE4.F78796C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I think = this would work and avoid some of the squirrely awkward encodings , for = / etc

 

 

= pkg+https://distributor.example/package.wbn#cid=3Dhttps://publisher.examp= le?q=3Dquery

 

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=3D40google.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=3D40google.com@dmarc.ietf.org> wrote:

RFC 3986, section 2.2 = notes:

=C2=A0=C2=A0 If data for a URI =
component would conflict with a =
reserved
=C2=A0=C2=A0 character's purpose as a =
delimiter, then the conflicting data must =
be
=C2=A0=C2=A0 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 an= d would welcome comments here or there.

 

The URLs are obviously gross, so https://github.com/WICG/webpackage/pull/560 su= ggests 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.

 

_______________________________________________
Wpac= k mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack

------=_NextPart_000_0323_01D63FE4.F78796C0-- From nobody Thu Jun 11 11:47:42 2020 Return-Path: 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 B8CAE3A0D34 for ; Thu, 11 Jun 2020 11:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 F5xYMVaxr0Hy for ; Thu, 11 Jun 2020 11:47:39 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 2B5E03A0D2F for ; Thu, 11 Jun 2020 11:47:39 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id w9so5377548qtv.3 for ; Thu, 11 Jun 2020 11:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kISE8zrJeeIzTbtnNssRe4uzTSYSzLsm06Ijvd8GQgM=; b=Kzp5EdZ0t8rdn+eekXDmNxfPkfH2KZeUk+3AbUhqzBB/gfEwOlPQjX1Gg9mvoAUX2G vPTcuyAjzClvdn36Nntr/qWkvL8rI+fMoe1gveYS9uRYLNF3BGNnX9YY/2Vtl50Rn4oL wAJROV7lv1pgC65hlO0S8sSWzHoA3cw+AiO2o= 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=kISE8zrJeeIzTbtnNssRe4uzTSYSzLsm06Ijvd8GQgM=; b=RAMIe2ZDtLSYZtNH1/QLLGafnLhZ4jqC0JjCA13zDdIeu35lZLmmak9iY0lfr406J2 /MlGN9KA73otf1kOV4/o49y+3y6KymNZKme1R9c6Rp2qpVbGqVhYdQjKL0jV/7y5usXS ebrUfzknGfakytM7MPhRgOkx8/HMxryEkreybbSIJ7wl/ItNQDG+ObvxVXiuFx4WJGxk 2R71V9THJjSwa4mee2/Rn6Yfl+aF2CVYjy9qTIrOEXyO2CKNFxylXI9iF+x4BuvfWXh7 aXtVNAjTVmoe/rFc9Q7q1wXdaGW8v467/saT4H8AXtbVf7J2UbuH/ugOoMfqsXSqAOIT CHBw== X-Gm-Message-State: AOAM530lxGwcu5LSIMkYB5yW696XMK91DVK4sJKy13T6KwuBdMEpWMrP SUXGS6gsZ7BW+d3CoZF51TJHMPWHdXgIJAFr2ZvQ0Q== X-Google-Smtp-Source: ABdhPJz5Q4WByiL9gOJ12B/YUNOYN59+NSfWy1rH6q1HJsZIJ1A0HsU0WGg5ysedAxZDd526r32mCJDnv1B2Qpvf3hU= X-Received: by 2002:ac8:4e81:: with SMTP id 1mr10548631qtp.364.1591901257669; Thu, 11 Jun 2020 11:47:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Thu, 11 Jun 2020 11:47:25 -0700 Message-ID: To: Ted Hardie Cc: Jeffrey Yasskin , WPACK List Content-Type: multipart/alternative; boundary="000000000000fbbd6005a7d3647b" Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 18:47:41 -0000 --000000000000fbbd6005a7d3647b Content-Type: text/plain; charset="UTF-8" On Wed, Jun 10, 2020, 3:44 PM Ted Hardie wrote: > Hi Jeffrey, > > On Wed, Jun 10, 2020 at 3:00 PM Jeffrey Yasskin 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:$, 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 > I looked at that, and I think it's ok to leave the `:` unescaped. Specifically, since `:` is only used as a delimiter to separate the scheme, the later `:`s in the package and resource URLs don't conflict. blob: URLs already do this, and go a bit farther in leaving their `/`s unescaped too. We could probably get away without escaping the `/`s here too: the origin-finding algorithm would split on `$` instead of looking for the first `/`, but I worry that it would be easier to write bugs in that case, which could give packaged resources access to their distributor's storage. Jeffrey --000000000000fbbd6005a7d3647b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 10, 2020, 3:44 PM Ted Hardie <= ted.ietf@gmail.com<= /a>> wrote:

On Wed, Jun 10, 2020 at 3:00 PM Jeffrey Yassk= in <jyasskin=3D40google.com@dmarc.ietf.org> wrote:
Hi a= ll,

I wanted to raise awareness of a discussion about th= e URL scheme for addressing resources within bundles (draft-yasskin-wpack-b= undled-exchanges).

We seem to be heading toward a = URL of the form package:<encoded-package-url>$<encoded-resource-ur= i>, which for a package URL of https://distributor.example= /package.wbn and resource URI of https://publisher.= example/page.html?q=3Dquery would lead to a URL of:

pac= kage:https:,,distributor.example,package.wbn;q=3Dquery$https:,,publisher.ex= ample/page.html?q=3Dquery

RFC 398= 6, section 2.2 notes:
   If data for a URI component would c=
onflict with a reserved
   character's purpose as a delimiter, then the conflicting data must b=
e
   percent-encoded before the URI is formed.
Wouldn't that apply to a couple of the delimiters in t= he package example above, e.g. the=C2=A0 ":" in "https:"= ;?=C2=A0 If so, that seems like it would change the display form a bit (tho= ugh not the basic idea).=C2=A0 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,

T= ed Hardie
<= br>
I looked at that, and I think it's ok to lea= ve the `:` unescaped. Specifically, since `:` is only used as a delimiter t= o separate the scheme, the later `:`s in the package and resource URLs don&= #39;t conflict. blob: U= RLs already do this, and go a bit farther in leaving their `/`s unescap= ed too.

We could probabl= y get away without escaping the `/`s here too: the origin-finding algorithm= would split on `$` instead of looking for the first `/`, but I worry that = it would be easier to write bugs in that case, which could give packaged re= sources access to their distributor's storage.
<= br>
Jeffrey
--000000000000fbbd6005a7d3647b-- From nobody Thu Jun 11 12:00:07 2020 Return-Path: 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 94E6B3A0F12 for ; Thu, 11 Jun 2020 11:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 PFouxhOsKBNN for ; Thu, 11 Jun 2020 11:59:57 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 AC1183A0AA3 for ; Thu, 11 Jun 2020 11:59:47 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id q8so6610718qkm.12 for ; Thu, 11 Jun 2020 11:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GAR10bruQWU+FLxtk4icuKknzyALPdezjcTnmk9OO3M=; b=ZEqFS4R4k/MJ1bvsswUAy+rJpATagdfsjl5NhJOaLwPEV3y2/gRX08E09G1vOATvNT RuZ/btEPBZlNT6bS2AVzdc7gS5TcQS4q6E0fcS3c0cXJb0w5qxta2OAdn5h4NCxSYDJO bcQiJ5cinecziSgn2N6SNAConZNc7yDuzDkQpG/nvlYLdOca8qwpsKTNNi15kTwP5NyB acx1BP+Y4LLTZ6OEfOOkVuGvfPJBj+Uz5+7B00cXG7zVN9aDCX+FDMI7JRQknmDqBdF9 gYkOwgouc+Z/iuZ20FFMrXgKEJxOsOE5/MPhSsQVm+iHROWF1Zw6IPSW5FeglMvQOIgT DO2w== 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=GAR10bruQWU+FLxtk4icuKknzyALPdezjcTnmk9OO3M=; b=rdoHw2W2Hpi0xvQhTB3l0svmirzZBxzW6mrnSfM4iJU8qEuvdJOS79IZrip51yzhyL y6f85Tf8xLttW1GFBMps0AGHdZV2WB0hHWyax3S6W5tLDEsWxAKvu432BHGqIaFu5qeF tgaSC0WsJPLmhlnJNOcV/eZ94TnJXTsm1ae/xnnUCvB2eCtkminRBeMBncr+4N1eppBt 7BNW5y+nCV9M5jnu0/LDjCNHCGbAtBBQDxJ8vY54/aT9tfZo7aileBV3URrOxHuov5ZU KDVFMPYJfwWovJXvuC6eGHJLKmxzXyAP8Uyku7gSm2TZVRl34gpKQEp3Fu9neYIYwE7i goGQ== X-Gm-Message-State: AOAM5309bHkt+yBUk6khQCXtQ2QIkLYWpyvt9OP0aldIUhosjC3q/CKP 9QFrW7jbfOQEkyIWykMjDsdzXsU5Q1JJQwxycbguCQ== X-Google-Smtp-Source: ABdhPJy0wogkZwZFS4Gq7udDua4L0z/7vIctZX2Z5RLH1eWpN5noemC9ey3N9T5D3nGE4Juxt0m+99QRQecNscKB5uY= X-Received: by 2002:a37:e110:: with SMTP id c16mr10251830qkm.38.1591901986219; Thu, 11 Jun 2020 11:59:46 -0700 (PDT) MIME-Version: 1.0 References: <032201d6401f$a3e58460$ebb08d20$@acm.org> In-Reply-To: <032201d6401f$a3e58460$ebb08d20$@acm.org> From: Jeffrey Yasskin Date: Thu, 11 Jun 2020 11:59:34 -0700 Message-ID: To: Larry Masinter Cc: Ted Hardie , WPACK List Content-Type: multipart/alternative; boundary="000000000000686cdf05a7d390f3" Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 19:00:06 -0000 --000000000000686cdf05a7d390f3 Content-Type: text/plain; charset="UTF-8" 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 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 *On Behalf Of *Ted Hardie > *Sent:* Wednesday, June 10, 2020 3:44 PM > *To:* Jeffrey Yasskin > *Cc:* WPACK List > *Subject:* Re: [Wpack] package: URL scheme > > > > Hi Jeffrey, > > > > On Wed, Jun 10, 2020 at 3:00 PM Jeffrey Yasskin 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:$, 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://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 > > --000000000000686cdf05a7d390f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This use of a fragment matches the way the TAG's = packaging draft identified subresources:=C2=A0https://www.w3.or= g/TR/2015/WD-web-packaging-20150115/#fragment-identifiers. I have some = discussion of the option at=C2=A0https://docs.google.com/document/d/1BYQEi8xkXDAg9lxm3PaoMzEutuQAZi1r8Y= 0pLaFJQoo/edit#heading=3Dh.jkcl1u8boyar, but I realize I didn't inc= lude the part that worries me most there:

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

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

I think thi= s would work and avoid some of the squirrely awkward encodings , for / etc<= u>

=C2=A0

=C2=A0

pkg+https://distributor.example/package.wbn#cid=3Dh= ttps://publisher.example?q=3Dquery

=C2=A0

Define pkg+originalsche= me to always returning an application/wbn content-type which accepts a frag= ment identifier which identifies the package component.

=C2=A0

This fo= rm avoids encoding or transforming any part of the original except the sche= me and the fragment identifier.

= =C2=A0

You can even apply fragment ide= ntifier to the publisher URL.

=C2=A0

=C2=A0

=C2= =A0

Hi Jeffrey,

=C2=A0

On Wed, Jun 10, 2020 at 3:00 PM Jeffrey Yasskin <jyasskin=3D= 40google.c= om@dmarc.ietf.org> wrote:

Hi all,

<= u>=C2=A0

I wanted to raise = awareness of a discussion about the URL scheme for addressing resources wit= hin bundles (draft-yasskin-wpack-bundled-exchanges).

=C2=A0

We seem to be heading toward a URL of the form package:<enco= ded-package-url>$<encoded-resource-uri>, which for a package URL o= f htt= ps://distributor.example/package.wbn and resource URI of https://publi= sher.example/page.html?q=3Dquery would lead to a URL of:<= /p>


package:https:,,distributor.example,= package.wbn;q=3Dquery$https:,,publisher.example/page.html?q=3Dquery<= /u>

=C2=A0

RFC 3986, section 2.2 notes:= 

=C2=A0=C2=A0 If data for a URI component wou=
ld conflict with a reserved
=C2=A0=C2=A0 character&=
#39;s purpose as a delimiter, then the conflicting data must be
=C2=A0=C2=A0 percent-encoded before the URI is formed.<=
u>

Wouldn't that apply to a = couple of the delimiters in the package example above, e.g. the=C2=A0 "= ;:" in "https:"?=C2=A0 If so, that seems like it would chang= e the display form a bit (though not the basic idea).=C2=A0 If that is need= ed, I think it reinforces the notion that showing these to users or expecti= ng the users to grok them is a non-starter.

=C2=A0

regards,

=C2= =A0

Ted Hardie

=C2=A0

=C2=A0

This arises from several considerations:

1. A bundle is served from=C2=A0a U= RL.

2. After a user down= loads 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, s= ince the bundle has an index, are also URLs even if, like urn:uuid:..., the= y 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= =C2=A0https://github..com/WICG/webpackage/issues/498, the content need= s to be assigned a non-opaque origin.

=C2=A0

I&= #39;m updating one of the documents about this in=C2=A0https://github.com/WI= CG/webpackage/pull/584=C2=A0and would welcome comments here or there.

=C2=A0

<= div>

The URLs are obviously gross, so=C2=A0https://git= hub.com/WICG/webpackage/pull/560=C2=A0suggests that browsers avoid show= ing them to users in most cases.=C2=A0

=C2=A0

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.

=C2=A0

_________________________________= ______________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo= /wpack

--000000000000686cdf05a7d390f3-- From nobody Thu Jun 11 14:07:28 2020 Return-Path: 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 9E5B13A08E1 for ; Thu, 11 Jun 2020 14:07:26 -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 VWHOGUP_UQEy for ; Thu, 11 Jun 2020 14:07:24 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 CA0843A08DB for ; Thu, 11 Jun 2020 14:07:24 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id p70so6709771oic.12 for ; Thu, 11 Jun 2020 14:07:24 -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=+m5ri6waean7hoFr7XmJCp0PdsARpVSJlaeQluXCro0=; b=ga5oyxoKnA8JRzG1pUTy22o91L6t14X/Qi5WPd8Y8g3KXZjmHo/GOAeBgAu78rDOST gtdEzDZFbyiGhQQg4aCZzdCoIdHU14gLRUCa5ow8Yxqbb6qzgxRo7+rpx4RgxlupsdYb AdP1jKkhOYbthc2W3S3b0Xs40XTmDUq36GTb4bzRDFxQGf/+Cqhkr+BSIPyoNSzDMLBD OwWaB8eSO9+C8Gpmh1EynSZ7jENp5xS1w571/i18Y5pHRd13xxHhv63OqcoasSxW+a/L 8N+b+cDOTcTTh5fUw8TwuhkIHW76Iu3FDKjbRo4vbHAZ6Y01fovvi7JqPso6I3nOAiA3 s+wQ== 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=+m5ri6waean7hoFr7XmJCp0PdsARpVSJlaeQluXCro0=; b=XUBDxnLl0AelEFKAj6H6MoMmSwNXpETjd5uorQgQGFJWUQLHb2mRoCQSgbhRO/75SA bwcvQbcjLFwEME3IisWYFSDxrrTLg13MyNQRjSEws4yoXv3FWFBUnwhmmf0ImYo+1ajP BHVEAJznNALK9hsXTFvuZ25ILuyU78zypZG3WbxYGAJywzR8+B5ssja8lYlMxonsxeAU cjWSXSquy+Bnl+FeDvwHmilDkioWPfevYydsyzECF8GTQYl4SkV28icAC0mmhYVMFODl cUnjPzb2TgqHSdKg3G/vF8PDps3lnvyCn7EGTbs92EWSb8Po3UtLdHmn3VZ8zf3wLDBR M9+w== X-Gm-Message-State: AOAM5310oE1ExxVx6mM1Z5pAnE5TrIJwd93X70npQiVZuhMXu1O+cml9 X2bsggNR+kIyKC+Q0F5IeiYgql37hMQhdlcshJbt4A== X-Google-Smtp-Source: ABdhPJyy5O2WIX/V4trfAQq4THMluc2+jUE1ZqxLd0/10P/tLNCw8XLSBHk3Wpu+AYPOGb3RFpHIsYzbPAnwO1cFJRM= X-Received: by 2002:a54:4795:: with SMTP id o21mr7508734oic.74.1591909644059; Thu, 11 Jun 2020 14:07:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Thu, 11 Jun 2020 14:06:57 -0700 Message-ID: To: Jeffrey Yasskin Cc: Jeffrey Yasskin , WPACK List Content-Type: multipart/alternative; boundary="000000000000d949c205a7d55864" Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 21:07:27 -0000 --000000000000d949c205a7d55864 Content-Type: text/plain; charset="UTF-8" Howdy, On Thu, Jun 11, 2020 at 11:47 AM Jeffrey Yasskin wrote: > On Wed, Jun 10, 2020, 3:44 PM Ted Hardie wrote: > >> Hi Jeffrey, >> >> On Wed, Jun 10, 2020 at 3:00 PM Jeffrey Yasskin > 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:$, 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 >> > > I looked at that, and I think it's ok to leave the `:` unescaped. > Specifically, since `:` is only used as a delimiter to separate the scheme, > the later `:`s in the package and resource URLs don't conflict. blob: URLs > already do this, and go a bit > farther in leaving their `/`s unescaped too. > It's certainly the case that some schemes permit ":" after the scheme to be presented unescaped (URNs require one, separating the NID from NSS). My concern here is really that these constructions, including the later ":"s , are actually being used in ways that might be read as conflicting with their original purpose as delimiters. "https:" occurs multiple times with contextual cues on meaning, in essence. That might be okay, but I think the percent encoded version might match expected practice bit better. It's unreadable to the end user, but I think that true either way. Is your concern with that approach that the origin-matching code might have forgiving algorithms for matching against percent-encoded elements of URIs? regards, Ted > > We could probably get away without escaping the `/`s here too: the > origin-finding algorithm would split on `$` instead of looking for the > first `/`, but I worry that it would be easier to write bugs in that case, > which could give packaged resources access to their distributor's storage. > > > Jeffrey > --000000000000d949c205a7d55864 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Thu, Jun 11, 2020 at 11:47 A= M Jeffrey Yasskin <jyasskin@chr= omium.org> wrote:
On Wed, Jun 10, 2020, 3:44 PM Ted = Hardie <ted.ietf= @gmail.com> wrote:
Hi Jeffrey,

On Wed, Jun 10,= 2020 at 3:00 PM Jeffrey Yasskin <jyasskin=3D40google.com@dmarc= .ietf.org> wrote:
Hi all,

I wanted to raise aw= areness of a discussion about the URL scheme for addressing resources withi= n 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=3Dquery would lea= d to a URL of:

package:https:,,distributor.example,package.= wbn;q=3Dquery$https:,,publisher.example/page.html?q=3Dquery

RFC 3986, section 2.2 notes:
   I=
f data for a URI component would conflict with a reserved
   character's purpose as a delimiter, then the conflicting data must b=
e
   percent-encoded before the URI is formed.
Wouldn't that apply to a couple of the delimiters in t= he package example above, e.g. the=C2=A0 ":" in "https:"= ;?=C2=A0 If so, that seems like it would change the display form a bit (tho= ugh not the basic idea).=C2=A0 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,

T= ed Hardie
<= br>
I looked at that, and I think it's ok to lea= ve the `:` unescaped. Specifically, since `:` is only used as a delimiter t= o separate the scheme, the later `:`s in the package and resource URLs don&= #39;t conflict. blob: URLs already do this, and go a bit farther in leaving= their `/`s unescaped too.

It's certainly the case that some schemes permit ":" after = the scheme to be presented unescaped (URNs require one, separating the NID = from NSS).=C2=A0 My concern here is really that these constructions, includ= ing the later ":"s , are actually being used in ways that might b= e read as conflicting with their original purpose as delimiters.=C2=A0 &quo= t;https:" occurs multiple times with contextual cues on meaning, in es= sence.=C2=A0 That might be okay, but I think the percent encoded version mi= ght match expected practice=C2=A0 bit better.=C2=A0 It's unreadable to = the end user, but I think that true either way.

Is your concern with that approach that the origin-matching code might h= ave forgiving=C2=A0 algorithms for matching against percent-encoded element= s of URIs?

regards,

Ted
=C2=A0
=

We could probably get away without escaping the `/`s here too: the or= igin-finding algorithm would split on `$` instead of looking for the first = `/`, but I worry that it would be easier to write bugs in that case, which = could give packaged resources access to their distributor's storage.


=C2=A0
=

Jeffrey
--000000000000d949c205a7d55864-- From nobody Thu Jun 11 14:33:20 2020 Return-Path: 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 D0FC93A0A26 for ; Thu, 11 Jun 2020 14:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 49Un_maqPKhe for ; Thu, 11 Jun 2020 14:33:17 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 E07A03A0A21 for ; Thu, 11 Jun 2020 14:33:16 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id y9so3446263qvs.4 for ; Thu, 11 Jun 2020 14:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/Rv9pZ2ytZfygWbN8M9hhor2/ZwUHWhCHwkjrpB9Jsc=; b=P7mFuhq1cMgvJZRmY4EJpKPuuyvp5uVSemX6qbwBhqarAsP6UAtNk/99ADj3k8h2XB J4lypjPs4Tb/w1J3VzD7TTeMSoJ277SLUa3JiEz5WGPTId4dmkgSMYVqzaFIk+MpYJ2D 29ElvlTsguL5FfhaAsIqceIBn8PacDk20Nrlk= 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=/Rv9pZ2ytZfygWbN8M9hhor2/ZwUHWhCHwkjrpB9Jsc=; b=mVJZ4sQxJR4CKuDobmV1kvLhO04szeP/wgd1cpyqaAvJlnTmWPy/cSUdnCtb07Ny5x Xoen0bT3DJ3x4bgms81lIJHowYdO94Rf8p6gG7GllBAV/m3QZ4mwXssoIw5+CtLc6olR X+mrtQYr4YgsFc6pYAwYQEeIE7HUqqMMmdUIO95Vd+cHdQjLxTvTuwNfkXbSEgU/o6fA jMVJ8L0DOFGcUdHuWo7fMH80KFi5LAS6J7eNuTAjS7q8beekHqCeLycUNceUJP+FrwQ3 4N1zZhcEbJbl1nXods/gc3lFt5R5lIpkiZT+HnfeO2UuHpBjou2/QJJOPwnmOtR+YVlX sV9A== X-Gm-Message-State: AOAM5327/11/oyOOnJwPfrznHbsOesqvAlXqFM7C8/Ko705+LZsjfwq/ +WdZSEOgZv70vBagbXrtEATnuY0WqYtzO/CkbNZTZg== X-Google-Smtp-Source: ABdhPJyB4+VO31fOiG9+AIv0cvFY5cxHMJPS3IGWIPqpinNiqRfXDRz3Pl2ivogVDAm5PxNUZ2pDNSMktz4PiMb2fNM= X-Received: by 2002:ac8:4e81:: with SMTP id 1mr6422qtp.364.1591911194854; Thu, 11 Jun 2020 14:33:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeffrey Yasskin Date: Thu, 11 Jun 2020 14:33:03 -0700 Message-ID: To: Ted Hardie Cc: Jeffrey Yasskin , Jeffrey Yasskin , WPACK List Content-Type: multipart/alternative; boundary="000000000000490e1e05a7d5b521" Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 21:33:19 -0000 --000000000000490e1e05a7d5b521 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 11, 2020 at 2:07 PM Ted Hardie wrote: > Howdy, > > On Thu, Jun 11, 2020 at 11:47 AM Jeffrey Yasskin > wrote: > >> On Wed, Jun 10, 2020, 3:44 PM Ted Hardie wrote: >> >>> Hi Jeffrey, >>> >>> On Wed, Jun 10, 2020 at 3:00 PM Jeffrey Yasskin >> 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:$, 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 >>> >> >> I looked at that, and I think it's ok to leave the `:` unescaped. >> Specifically, since `:` is only used as a delimiter to separate the scheme, >> the later `:`s in the package and resource URLs don't conflict. blob: >> URLs already do this, and go a >> bit farther in leaving their `/`s unescaped too. >> > > It's certainly the case that some schemes permit ":" after the scheme to > be presented unescaped (URNs require one, separating the NID from NSS). My > concern here is really that these constructions, including the later ":"s , > are actually being used in ways that might be read as conflicting with > their original purpose as delimiters. "https:" occurs multiple times with > contextual cues on meaning, in essence. That might be okay, but I think > the percent encoded version might match expected practice bit better. > It's unreadable to the end user, but I think that true either way. > > Is your concern with that approach that the origin-matching code might > have forgiving algorithms for matching against percent-encoded elements of > URIs? > I think there are two questions here: 1) Do we need to encode the embedded ":"s at all? 2) Should we encode by replacing with subdelimiters ( https://tools.ietf.org/html/rfc3986#section-2.2), or by percent-encoding? I'm fairly neutral on encoding ":"s at all. I think it's unnecessary, but not particularly harmful. On percent-encoding vs replacement, I think there are several levels of readability. It's true that we shouldn't expect end-users to read these at all (and that Larry's suggestion is a win on that front), but when developers are trying to debug problems, I think 'package:https!,,' is easier to check than 'package:https%3A%2F%2F'. I'm not currently worried that origin-matching code will be too forgiving about percent-encoded elements, and I don't think that worry would distinguish our proposals. Even my current proposal can result in percent-encoding inside the origin: a bundle distributed from ` https://example/path;param/bundle` would have resource URLs starting with `package:https:,,example,path%3Bparam,bundle$` to distinguish it from the bundle at `https://example/path?param/bundle`. Jeffrey --000000000000490e1e05a7d5b521 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 11, 2020 at 2:07 PM Ted Hardi= e <ted.ietf@gmail.com> wrot= e:
Howdy,

On Thu, Jun 11, 2= 020 at 11:47 AM Jeffrey Yasskin <jyasskin@chromium.org> wrote:
On W= ed, Jun 10, 2020, 3:44 PM Ted Hardie <ted.ietf@gmail.com> wrote:
H= i Jeffrey,

On Wed, Jun 10, 2020 at 3:00 PM Jeffrey Yasskin <jyasski= n=3D40google.com@dmarc.ietf.org> wrote:
Hi all,

I wanted to raise awareness of a discussion about the URL scheme f= or addressing resources within bundles (draft-yasskin-wpack-bundled-exchang= es).

We seem to be heading toward a URL of the for= m package:<encoded-package-url>$<encoded-resource-uri>, which f= or a package URL of https://distributor.example/package.wbn and resource URI of https://publisher.example/page.h= tml?q=3Dquery would lead to a URL of:

package:https:,,d= istributor.example,package.wbn;q=3Dquery$https:,,publisher.example/page.htm= l?q=3Dquery

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 b=
e
   percent-encoded before the URI is formed.
Wouldn't that apply to a couple of the delimiters in t= he package example above, e.g. the=C2=A0 ":" in "https:"= ;?=C2=A0 If so, that seems like it would change the display form a bit (tho= ugh not the basic idea).=C2=A0 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,

T= ed Hardie
<= br>
I looked at that, and I think it's ok to lea= ve the `:` unescaped. Specifically, since `:` is only used as a delimiter t= o separate the scheme, the later `:`s in the package and resource URLs don&= #39;t conflict. blob: URLs already do this, and go a bit farther in leaving= their `/`s unescaped too.

It's certainly the case that some schemes permit ":" after = the scheme to be presented unescaped (URNs require one, separating the NID = from NSS).=C2=A0 My concern here is really that these constructions, includ= ing the later ":"s , are actually being used in ways that might b= e read as conflicting with their original purpose as delimiters.=C2=A0 &quo= t;https:" occurs multiple times with contextual cues on meaning, in es= sence.=C2=A0 That might be okay, but I think the percent encoded version mi= ght match expected practice=C2=A0 bit better.=C2=A0 It's unreadable to = the end user, but I think that true either way.

Is your concern with that approach that the origin-matching code might h= ave forgiving=C2=A0 algorithms for matching against percent-encoded element= s of URIs?

I think there = are two questions here:

1) Do we need to encode th= e embedded ":"s at all?
2) Should we encode by replacin= g with subdelimiters=C2=A0(https://tools.ietf.org/html/rfc3986#section-2.2), or by per= cent-encoding?

I'm fairly neutral on encoding = ":"s at all. I think it's unnecessary, but not particularly h= armful.

On percent-encoding vs replacement, I thin= k there are several levels of readability. It's true that we shouldn= 9;t expect end-users to read these at all (and that Larry's suggestion = is a win on that front), but when developers are trying to debug problems, = I think 'package:https!,,' is easier to check than 'package:htt= ps%3A%2F%2F'.

I'm not currently worried th= at origin-matching code will be too forgiving about percent-encoded element= s, and I don't think that worry would distinguish our proposals. Even m= y current proposal can result in percent-encoding inside the origin: a bund= le distributed from `https:/= /example/path;param/bundle` would have resource URLs starting with `pac= kage:https:,,example,path%3Bparam,bundle$` to distinguish it from the bundl= e at `https://example/path?p= aram/bundle`.

Jeffrey
--000000000000490e1e05a7d5b521-- From nobody Thu Jun 11 14:36:39 2020 Return-Path: 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 B94B73A0A3E for ; Thu, 11 Jun 2020 14:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZRkkvNzblo5N for ; Thu, 11 Jun 2020 14:36:34 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 3AF773A0A4D for ; Thu, 11 Jun 2020 14:36:28 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id s135so2421941pgs.2 for ; Thu, 11 Jun 2020 14:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=r3mrK9ne2hPucB2JPfa8YSZxH9ouZOK/FTeub77gLYo=; b=ojPGEQvK1uZngSSd1NATZoCKDx+ObrFVxUrIJzRAD5F75a068+VSM31v0kW+7RShiL 527/fYQfhMOBGfqH8QpLksXLgUw2HpIN0nXO/+nNROCh6sAkGmekN/9rGdQuT3u3XFyE dB2LEuNupAp6fca5uow1AV6c61QFEcPzVrNRIK8vb1blyMM5vue5E8lCe2yeonKQq5ts qo5pp96w8+IG2gByT5M5BiM1yPr29gkk7hNqvT9v+bYh1rNITpTI10CBqjkgWTGd9seR ZSvrw6YnBUSxNl7oQlIqBIXo1o078ywI5G8vIruLiwVW9DqX/i8GlxT1+T7AJXiHxnBv p8mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=r3mrK9ne2hPucB2JPfa8YSZxH9ouZOK/FTeub77gLYo=; b=N6zOyFKmsump+5mgM/7tDH9+Re57jvLepYV6kSNkJdG4bEZUlwPC7jbPgigtsBPpXI zO5jd4WEhwLf38z2YHAZMjYWzcSNsjgJIi29vRFMy64V9Olp5ccFT+83kjgftUXaDhll 8XT5TqXPyFJGH0T56K9CGBJnUWHSy8I7tP+NPiMJX1iyRMpNl3XfQ+Y/4/HuHpLsUGuZ Ip3+pUawtpNTE0lXFyG4pn8tu9pwegA8DSDYpZe7KJeuQUuvGIr2JpLqIuCy6GW++aDB dbnmUOAFk506l7BHLWweh+YYYeS9xHIRTqJiYMOXyU25boDD82bRJFPoR2h+42zn6YF9 ZkEg== X-Gm-Message-State: AOAM533Aq9bYl8doB0J0GP+GY7C8V4Dmb4Fa3odZcW0Uqu3GFnj/UADR PMxDgs4VbzmLwcKzhwDhZL0= X-Google-Smtp-Source: ABdhPJyBeE6NgeNbb3mcfirIZTeY2RaqBvY+XGySk3maQoMEwVa4YtlKGvqYP+NwL0lbdKKyxDzRNA== X-Received: by 2002:a63:124a:: with SMTP id 10mr8158166pgs.336.1591911387309; Thu, 11 Jun 2020 14:36:27 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id r1sm3514857pgb.37.2020.06.11.14.36.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2020 14:36:26 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Ted Hardie'" , "'Jeffrey Yasskin'" Cc: "'Jeffrey Yasskin'" , "'WPACK List'" References: In-Reply-To: Date: Thu, 11 Jun 2020 14:36:27 -0700 Message-ID: <001101d64038$5d4aae90$17e00bb0$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01D63FFD.B0EC24B0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJUN3n7f7U8Tm8IyhTb0CDwyv1MGgItZykDAg2C2bYAlbsRWaexez8g Content-Language: en-us Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 21:36:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0012_01D63FFD.B0EC24B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The bigger problem is that WHATWG=E2=80=99s URL living standard has = forked from the IETF specifications, where there is no visible plan for = reconciliation. The specs aren=E2=80=99t so wildly different, but the = devil=E2=80=99s in the details. -- https://LarryMasinter.net =20 ------=_NextPart_000_0012_01D63FFD.B0EC24B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The bigger problem is that WHATWG=E2=80=99s URL living = standard has forked from the IETF specifications, where there is no = visible plan for reconciliation. The specs aren=E2=80=99t so wildly = different, but the devil=E2=80=99s in the details.

--

https://LarryMasinter.net=C2=A0 =

------=_NextPart_000_0012_01D63FFD.B0EC24B0-- From nobody Thu Jun 11 17:02:01 2020 Return-Path: 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 332393A0C88 for ; Thu, 11 Jun 2020 17:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=f1aFv3Hv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G9qE0A1G 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 PjMx-9kzHw4b for ; Thu, 11 Jun 2020 17:01:51 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4937D3A0CB2 for ; Thu, 11 Jun 2020 17:01:50 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 9FB5B44A for ; Thu, 11 Jun 2020 20:01:49 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 11 Jun 2020 20:01:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=AZqj/jWN7b9WPQNRY7AyNjWKPb6vBx7 Io8blWoZfFMU=; b=f1aFv3HvSztxcN9SC0aCKQScmm0qVtbDQhBoPqzxDaUcn2B mvScJ59ySt6qth/f01zTlJrXVwjiZHHneGX60bnm0QMNrVO8FASo8o2oNGgK7b/X rvUDFL3f4YDl7sAhfvqWcpoSyHJMPq6V3Tspj+UOXsACs4pJpzKBdsG2P2zNCQ03 rUXcIVW4gPCaVolN96minBiK86MBR7AyqqQdsN1PPCJJ+xIPHYWXTZys5BtD5+jp Pvgl/3B9VFYyL+dmodS5TryM87cThOzyRqaiRA3EWwPkIHLN5We7p5/vcmvD4GKY 36HJywJeu3kpxQ7MW2kEIjCqOCf4/u2HodgZGGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=AZqj/j WN7b9WPQNRY7AyNjWKPb6vBx7Io8blWoZfFMU=; b=G9qE0A1GR5qzMhd2wLuZsY /yblYrgwo/9+KAE0FK23D7Fbdfri/2fvmIdHPVd7/JjnY1wUZ/Qz7b007BdUqU2c dtwW6cy5vHN4PbgEPKu7rzh1LMTv7d2GRIm16hJFpXcUshLbW9I0dDbqSnz2o1CO 7/ZKDxq5xMx9Yk/6j2hivJ1adKtXN38JP6zr1Gtte7Wa8RCzLaebiS4UH/9WQkuH FkfgfC0ADZU4D+Uws3x5fczZjgZu++lwQxznB87kNImNUvXFHmIpA/8UqsWKI8Da 6uM0xR99XXY4SgSnXm/JMPJZpqBI0PCRJFF/sW6CAZa4l6hSHeev5zisNY9NZB8Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeitddgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepueeggeeuveeugfelteffvdevkeeuheetleeghfehkeekfeekiedu feefveelheelnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpghhoohhglhgvrdgtoh hmpdhgohhoghhlvghsohhurhgtvgdrtghomhdpfiefrdhorhhgpdhivghtfhdrohhrghen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslh hofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EC36EE00A9; Thu, 11 Jun 2020 20:01:48 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990 Mime-Version: 1.0 Message-Id: <97bcac95-c220-41ae-b957-d93fc57f4a74@www.fastmail.com> In-Reply-To: References: Date: Fri, 12 Jun 2020 10:01:29 +1000 From: "Martin Thomson" To: wpack@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 00:01:59 -0000 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:$, 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://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 > From nobody Thu Jun 11 17:33:45 2020 Return-Path: X-Original-To: wpack@ietf.org Delivered-To: wpack@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DC03A0CAA; Thu, 11 Jun 2020 17:33:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: wpack@ietf.org, sean@sn3rd.com, superuser@gmail.com, wpack-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159192202242.6811.18151777402748553815@ietfa.amsl.com> Date: Thu, 11 Jun 2020 17:33:42 -0700 Archived-At: Subject: [Wpack] wpack - New Meeting Session Request for IETF 108 X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 00:33:43 -0000 A new meeting session request has just been submitted by Sean Turner, a Chair of the wpack working group. --------------------------------------------------------- Working Group Name: Web Packaging Area Name: Applications and Real-Time Area Session Requester: Sean Turner Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: Conflicts to Avoid: Chair Conflict: add dnsop dprive tls mls quic Technology Overlap: httpbis dispatch secdispatch saag acme People who must be present: Sean Turner Murray Kucherawy David C Lawrence Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jun 11 17:34:48 2020 Return-Path: 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 3DBF83A0CAB for ; Thu, 11 Jun 2020 17:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=sn3rd.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 2FcvMMtxr8gl for ; Thu, 11 Jun 2020 17:34:45 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 E41AD3A0CAA for ; Thu, 11 Jun 2020 17:34:44 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id b27so7497142qka.4 for ; Thu, 11 Jun 2020 17:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=GuAzcRqGyBf2CXExriVHrJYoWYd+IWTlwLuz1c2BZKY=; b=AuHHV83GRnI5Y5CMhIiZq++9SLcBzKZBarZD/j8xmOoMuoJ4FfcsgLll0Z0gZPOjg8 3leJ45VmpNkw2osshPpKuVm+mVvQTlIr4nwau2DUV8Ro49baRb4zSXdnXGuuB6DfYi2W PdpNcGt5zDvOYsVIYQCCrnSQbpeCwIMz3C8BY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=GuAzcRqGyBf2CXExriVHrJYoWYd+IWTlwLuz1c2BZKY=; b=LoCbsXyavFBxLOX5ovkWIiERtaOXCyGeSiZn39NTSATX2x51DGssmAFCfImHhL/cco kzmQhZ8gkqUpPfNJ8U3V/s7sQMGfKp37Epaeje+PwWkTFMVoboup1u2YCDxGPPP0hBHA vWZBFTiHpjuUOVHQc/P8Vft9BbDqkzrDhjzwAXPk5MVEdWCiuKi2sPb35QVtFaY5V+GV aK+oPRxh/5zVVLuyNuW73sHTO+qiZ3iF1eokthMBpccWzTE9qHCsa/4YDpt5JVXj0ugB p8RWPwIwhXMOsm3JyMKkI8yfB0Np0F8TCTbi97EKJIXUMvbZEyyuk4/zLqIn9HlpTDGP JrTA== X-Gm-Message-State: AOAM530xJGhNBQ4W6tRcAq+LYp3cYVsr+DC4HNduYpTy8HfcVf6rTEga cI+uNXZHzWIi1Ei3tC5xBoevtnaMq2w= X-Google-Smtp-Source: ABdhPJwVnAgTqyfTiGK5d72PmoYS8EeFI0cxnKCkCGEC4A3KbsvXB/jLxEfAfeb0tk0gONNQqtPuyw== X-Received: by 2002:a37:668d:: with SMTP id a135mr584675qkc.131.1591922083011; Thu, 11 Jun 2020 17:34:43 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id q34sm3441451qtd.89.2020.06.11.17.34.42 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2020 17:34:42 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 11 Jun 2020 20:34:41 -0400 References: <159192202242.6811.18151777402748553815@ietfa.amsl.com> To: WPACK List In-Reply-To: <159192202242.6811.18151777402748553815@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Wpack] wpack - New Meeting Session Request for IETF 108 X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 00:34:46 -0000 Hi! I went ahead and requested a session. If we end up not needing it, we = can always cancel it. spt > On Jun 11, 2020, at 20:33, IETF Meeting Session Request Tool = wrote: >=20 >=20 >=20 > A new meeting session request has just been submitted by Sean Turner, = a Chair of the wpack working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: Web Packaging > Area Name: Applications and Real-Time Area > Session Requester: Sean Turner >=20 >=20 > Number of Sessions: 1 > Length of Session(s): 50 Minutes > Number of Attendees:=20 > Conflicts to Avoid:=20 > Chair Conflict: add dnsop dprive tls mls quic > Technology Overlap: httpbis dispatch secdispatch saag acme >=20 >=20 >=20 >=20 >=20 >=20 > People who must be present: > Sean Turner > Murray Kucherawy > David C Lawrence >=20 > Resources Requested: >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 >=20 From nobody Thu Jun 11 17:47:34 2020 Return-Path: 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 2E9D03A0CD3 for ; Thu, 11 Jun 2020 17:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 SlbS9PbcSTDA for ; Thu, 11 Jun 2020 17:47:31 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 D78633A0CCB for ; Thu, 11 Jun 2020 17:47:31 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id l63so1065621pge.12 for ; Thu, 11 Jun 2020 17:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=7jMbzTdXPn6BpQ88SjahCrVaW7C6zPSIHT8pQPnhLHc=; b=gBUVd62cRcLbmfWJX7TwmYh+pQzojGXXSDCcN+Sz0srMa3fEmneyDEpXqrwO10srnM GFKIw86vXq3yAqmvvB+fptTuxcE0INbdBLwVFqRB39BqTrWDF5nKvZuYHLtTvLzbrtAz OhCFr/6F9K+q4g6RfMj0eM0A4xEP9em3TSJv45Q5ls1A8owi+ZNWtcx5oZ9IVwv5oDhh fUV2utfQV5nkUiRRWxrVPQ6QCersAxbFkMxG27hUXasAxSy5YAirXsGhQdO/EC0Th3b7 U08jhPSELU141MX3mD/ZsCdWKZ7Ypz1g5/lHgCg5NC0j9bpNh+8k2oLsc/5ndx1taKYQ yEqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=7jMbzTdXPn6BpQ88SjahCrVaW7C6zPSIHT8pQPnhLHc=; b=mb7znSt0cFQ3l0tGxS8dxCEbxmt0hg2Syj8OlrejST5DyKzyW6ck66Sxp7GZ/JA/Ec 29YGBWaHVzMpKODHekgl1KakEArEh1m+cU0c0US1MSsa2k59vD84nbC1RF1kepyk/kZd x5h4TEt2Z8H+yrn4B/w1jtMRLqqXQsT28YAetU4iaxDA6G+Pb7xS57pmVapryjjAqKTj 16Fv6JuIRVKcvcHMn9sgGHrgU5YqNf3/Fdgd1grdRlENK38FAAnKI0OMtoRXraCWQsPe rc+TdnK7lRwo+uvUbX6X7yE7EFJIzW68SpPIYduPLvPM5RU4YhavciHRSkIpDbsNCU0r ongw== X-Gm-Message-State: AOAM530pUeINC43t4nKqX5w2peeQw9H7HA88R85D5pmrS+y/PWLZBGMG 4PGbNuAKC8k0Vouuaa1Nats= X-Google-Smtp-Source: ABdhPJy+H0IBP+O2t9pebsk6YT7TU32c3hK98M6ViCnpfqtlxUcxVYGQRDP1rV6PweXw/jqX9wwEzg== X-Received: by 2002:a63:e24c:: with SMTP id y12mr3230963pgj.224.1591922851179; Thu, 11 Jun 2020 17:47:31 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id i191sm4397123pfe.99.2020.06.11.17.47.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2020 17:47:30 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Martin Thomson'" , References: <97bcac95-c220-41ae-b957-d93fc57f4a74@www.fastmail.com> In-Reply-To: <97bcac95-c220-41ae-b957-d93fc57f4a74@www.fastmail.com> Date: Thu, 11 Jun 2020 17:47:32 -0700 Message-ID: <005b01d64053$0ece6980$2c6b3c80$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJUN3n7f7U8Tm8IyhTb0CDwyv1MGgIYWzNap8dyEdA= Content-Language: en-us Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 00:47:33 -0000 PDF allows embedded files. There was a requirement to allow URLs pointing to embedded files and to allow identification of fragments.. >From https://tools.ietf.org/html/rfc8118#section-3 Fragment identifiers ef= Identifies the embedded file where the parameter string matches a file specification dictionary in the EmbeddedFiles name tree. If the "ef" parameter is not at the end of the fragment identifier, then the rest of the fragment identifier (after the ampersand or hash delimiter) is applied to the embedded file according to its own media type. This allows identification of content within the embedded file (which itself might be a PDF file) NOTE: When attempting to open a PDF file that is not from a trusted source, the processor may choose to prompt the user or even prevent the file from being opened. There was no need to define a new scheme. Sorry I'd forgotten about this. -- https://LarryMasinter.net https://going-remote.info From nobody Fri Jun 12 05:34:29 2020 Return-Path: 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 8D81D3A0F9C for ; Fri, 12 Jun 2020 05:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=cdt.org 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 FmJOD1JlI5LZ for ; Fri, 12 Jun 2020 05:34:26 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 0C94C3A0F9B for ; Fri, 12 Jun 2020 05:34:26 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id c12so6926188qtq.11 for ; Fri, 12 Jun 2020 05:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=vY/AkeJeJWGs+ynRAOti3ICM9t411slruW9ew31bBYc=; b=Z4hfjwQNaLi9W4HyWKN+sYvzENbs4+dcP7dCQJ7Hn9regrErAfUspslFkpemfDe0B4 73qbTiKbzDPgq6dcOpcNGl7gspKHV0DfpkwuvEVkPrmgkSebC20ZOF07kLaMgQrIM829 1zKfM3Oe2qU2PzJ3UhXQ2tB6d+6UxPtUKoNjc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=vY/AkeJeJWGs+ynRAOti3ICM9t411slruW9ew31bBYc=; b=Mrkpp/w0DtqfyklYh5IY+T7IoG0ZtV7QMTwGhe8jkI9gbSM8sKc8gSBbiBZCZyAxnN uZWXBw9Eq4m3pfXYsawfA3szVmOpAp/MHHgqFYYArlvhSMTAp7jg1UzeZ9a5X2LtMqyd 1NIm3HECoe8YORLT+VfTwGOi4AKI3NlUeLfxjFjdzhTONgiZhCYYa729JJ43YC6Cv7Wa GuhjAURuHUGKYIgPNWwGwnnF1bLK+Vs45SWxCZLRELeU59Bgp2cXsYhFunC1pk8CZrHY 26LpLn/Z9NEFG7YGBMhzLMhp9JRHLNQFmZHui3RLU0R0ZB2NJUyt48r4KPbSOMlmq0gm IbjQ== X-Gm-Message-State: AOAM531U0Qo6lUvtHdt0stMHfj/4s6Iq0zGt08cxRaSjXjbhAkBKcvby vvjTLGRmJhMRRRoOwRxVQA0fAAf0f+8= X-Google-Smtp-Source: ABdhPJwR6ign1eBuvpZHQXGP+4kG/eju1IlYKbO0VAg52Y8gj+gPE3JEHVHPYd1Uma3fAQBX8vqpqg== X-Received: by 2002:ac8:24b3:: with SMTP id s48mr2796887qts.383.1591965264468; Fri, 12 Jun 2020 05:34:24 -0700 (PDT) Received: from Mallorys-MacBook-Air.local (c-73-163-188-207.hsd1.dc.comcast.net. [73.163.188.207]) by smtp.gmail.com with ESMTPSA id o6sm4249247qkh.28.2020.06.12.05.34.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jun 2020 05:34:23 -0700 (PDT) To: Martin Thomson , wpack@ietf.org References: <97bcac95-c220-41ae-b957-d93fc57f4a74@www.fastmail.com> From: Mallory Knodel Message-ID: <105d4247-02d7-694b-74cf-9fd0d5e5bc7e@cdt.org> Date: Fri, 12 Jun 2020 08:34:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Thunderbird/77.0 MIME-Version: 1.0 In-Reply-To: <97bcac95-c220-41ae-b957-d93fc57f4a74@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 12:34:28 -0000 On 6/11/20 8:01 PM, Martin Thomson wrote: > 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. Agree that the user needs an indication of publisher, and that hiding the URL is unhelpful to the user. Simplification sounds like the right thing to do, because too much information can have the same effect as none. -Mallory > On Thu, Jun 11, 2020, at 08:00, Jeffrey Yasskin wrote: > > 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://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 -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 From nobody Fri Jun 12 08:20:14 2020 Return-Path: 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 4C6CE3A0C45 for ; Fri, 12 Jun 2020 08:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 un_75PxQkqz0 for ; Fri, 12 Jun 2020 08:20:12 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 6AAE63A0C51 for ; Fri, 12 Jun 2020 08:20:10 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id d6so3984363pjs.3 for ; Fri, 12 Jun 2020 08:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=aaL3AaKOVh3RgatIEKOSNGTJh2RLXV7lp6o5jUy6OA0=; b=lYKTWmqA6Sq7GC8wz5n/IwRPcYSVic7qoIDi7mjnJ+gN63wNg2QTIZqi0ba3iMa3qN IcK4vgBJA1qjLhYnvQxfaARG+gomN+FfivYxf80jg6ZyEgVZZQ6//hoV/Tlgb5pDcGVA mBrPCuf1vrfbLgJqaW2PPSmXT8/djRzbQoy9tPyDOhGSIkuppHuAubCY6pX8CadYTIP7 o6xOvKrStdwxwJhiLwnQ9OFDyWkBsg/sCMB2bXuqZ/JPmoglQ4J4WbA9Yfu2blQpKgL3 h4AGoN8Kln1o+SeX5V5wM5+bbGy2LJRGfs0wKoQr9hE2SUjrnPpe6rL1wOIHXFTwmcZ+ gpLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=aaL3AaKOVh3RgatIEKOSNGTJh2RLXV7lp6o5jUy6OA0=; b=Kx63j/T8K+JCSXaN0svGY3U9q0lEaEnvBg27EBFeHB0RsmVK7iKAwxyR/X99LvWmxM kZq5SHHu+6Vj5UmjCHC87g2DbpZQ6KG5V2ePxUr4izqsqjSKp/wYSGlEB5ui3IZD/zg0 ngrGfsGg2Dj7NFYryb5W8NxO55zJ5XFc7bYQ/5zPD73ZZ2AJ90suQ7ewgZdBiryiksNP f0WwHZV3ZH2/d+raOGDAymGB2JS2rGLZY0hOnMGI2tn5UoUAdrq2ryVO1saAXDTfOlpo LHParATCq/j9QnanTOB0EgyicZavAuOm2tiJBd5N+WEyYwarn6caDF9wBkzrr7WAXEtc ObDw== X-Gm-Message-State: AOAM530Byr6ifgbwgkM/zIIip3qEaMW7EEm913cn/b7AR0/dO58llSAe DBu9u4dSZpnxaMgven6KxGM= X-Google-Smtp-Source: ABdhPJxNnQxiUnK/4jjztboC8eJ/NM0u2TmNWMUqil04rLJymd0KJaVnfHihayIasH9H1jjdwaDzJg== X-Received: by 2002:a17:90a:b903:: with SMTP id p3mr14088828pjr.4.1591975209718; Fri, 12 Jun 2020 08:20:09 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id a7sm5604237pjd.2.2020.06.12.08.20.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 08:20:08 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Mallory Knodel'" , "'Martin Thomson'" , References: <97bcac95-c220-41ae-b957-d93fc57f4a74@www.fastmail.com> <105d4247-02d7-694b-74cf-9fd0d5e5bc7e@cdt.org> In-Reply-To: <105d4247-02d7-694b-74cf-9fd0d5e5bc7e@cdt.org> Date: Fri, 12 Jun 2020 08:20:07 -0700 Message-ID: <006c01d640cc$f5445310$dfccf930$@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJUN3n7f7U8Tm8IyhTb0CDwyv1MGgIYWzNaAXJcRLCnvNFAYA== Content-Language: en-us Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 15:20:13 -0000 In the archival use case, isn't the distributer the authority, not the publisher? The publisher could be long gone. > -----Original Message----- > From: Wpack On Behalf Of Mallory Knodel > Sent: Friday, June 12, 2020 5:34 AM > To: Martin Thomson ; wpack@ietf.org > Subject: Re: [Wpack] package: URL scheme > > On 6/11/20 8:01 PM, Martin Thomson wrote: > > > 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. > > Agree that the user needs an indication of publisher, and that hiding the URL > is unhelpful to the user. Simplification sounds like the right thing to do, > because too much information can have the same effect as none. > > -Mallory > > > On Thu, Jun 11, 2020, at 08:00, Jeffrey Yasskin wrote: > > > > 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/1BYQEi8xkXDAg9lxm3PaoMzEutuQAZi > 1r8Y > > 0pLaFJQoo/edit# > > * > > https://chromium- > review..googlesource.com/c/chromium/src/+/2226248/7#m > > essage-0a3efda5aff84770a1729422a5b26aeca3ee4e80 > > review.googlesource.com/c/chromium/src/+/2226248/7#m > > essage-0a3efda5aff84770a1729422a5b26aeca3ee4e80> > > * https://github.com/WICG/webpackage/issues/583 > > * > > > https://github.com/WICG/webpackage/blob/master/explainers/navigation-t > > o-unsigned-bundles.md#urls-for-bundle-components > > * https://lists.w3.org/Archives/Public/uri/2019Nov/0000.html > > -- > Mallory Knodel > CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 > 65A3 B240 BCD9 B071 0C32 A271 BD3C C780 > > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack From nobody Fri Jun 12 16:07:52 2020 Return-Path: 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 40D8E3A1640 for ; Fri, 12 Jun 2020 16:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 N4_Un5oAo7SK for ; Fri, 12 Jun 2020 16:07:49 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 E86DF3A163F for ; Fri, 12 Jun 2020 16:07:48 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id f18so10679877qkh.1 for ; Fri, 12 Jun 2020 16:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Su3G6DdQfQeO9o8IDfCmQuyIBkMJbgtujDUr04gmsCc=; b=eq3uS7dc9axh7jtzYg/LDnhH8G/wDGOyDwyUHP+UxvwVuL5SdKLOmIneLQLTIo7MAs LcQSzVOCwREYc/ubQcq/Fb2fWRXGeG6+pPNxLth7ObMeIepFkIhMDMuaQJdjMc6+XMWm QRidFee/VFVzkxJVMrM2UJWRW8m6N9YbvQXRg= 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=Su3G6DdQfQeO9o8IDfCmQuyIBkMJbgtujDUr04gmsCc=; b=r0Zzd8I5Zdl+OEuGrbsVE0sbamKLigmGTBCsKb/VA407j2Q0BAbJwTBBZuB8bQ49mb 1oAgbFo8zhW7LKHpW2wCxhukovFFpwZUrEz9oYUH9DqKI19y+c+nuxvq8AxfVHmMveh7 G7N11/iMFc4hHRidoR+uJRD4K7HuwlnsP/Nn4MkZvdzn63Ma1IUKq2P4OM//aQvi62gr NCOXKZb4mef9qvQPTQfPKNoUYXsN20ZJcUdd6Mh4gScMLVVEmmV5pMRN3+0Wz+xDJYOc /gGoODVkBK6gK0j/b8dbqBalwsvMvMa+EtILj3Hnfq5Su9suH8DVjRouZnmwmOHcPsb7 IU7w== X-Gm-Message-State: AOAM532eLl7/rqR9aNnhlBCcOPKwB8rmISG9oGNqiIe1Naz3x9ivvEVu wUoMU7i826sWG+vycLz301i20YzniIUmsqguhZBswA== X-Google-Smtp-Source: ABdhPJzrgLszZLZevdiK9hE61w5KtuvYhkqeWZRpp3fD9hqyNl0aX0y4UHeIq2DmSRP/nmPFbW3Tjwt5gauCv2F6V8k= X-Received: by 2002:a37:61d6:: with SMTP id v205mr4964587qkb.447.1592003267134; Fri, 12 Jun 2020 16:07:47 -0700 (PDT) MIME-Version: 1.0 References: <97bcac95-c220-41ae-b957-d93fc57f4a74@www.fastmail.com> In-Reply-To: <97bcac95-c220-41ae-b957-d93fc57f4a74@www.fastmail.com> From: Jeffrey Yasskin Date: Fri, 12 Jun 2020 16:07:35 -0700 Message-ID: To: Martin Thomson , mknodel@cdt.org Cc: WPACK List Content-Type: multipart/alternative; boundary="000000000000388a3505a7eb25e0" Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 23:07:51 -0000 --000000000000388a3505a7eb25e0 Content-Type: text/plain; charset="UTF-8" Hi Martin and Mallory, As Larry mentioned, when the bundle is unsigned, it's the entity serving the bundle -- distributor.example here -- who has the ability to change the content, so they're probably the "true" authority. They're quoting the original publisher of the content, but there's no way for the user to verify that the quote is accurate. Do you support the general goal of giving pairwise-distinct origins to all of: 1. https://foo.example/page.html 2. https://bar.example/page.html 3. A resource in the bundle at https://foo.example/bundle.wbn named https://bar.example/page.html. 4. A resource in the bundle at https://foo.example/bundle.wbn named https://quux.example/page.html. 5. A resource in the bundle at https://foo.example/otherbundle.wbn named https://bar.example/page.html. If we say (1) and (3) get the same origin, it means the result can't help the Internet Archive serve their pages more safely, and we force (3), (4), and (5) to have the same origins. If we say (2) and (3) get the same origin, we break the entire web origin security model. :-D If we say (3) and (4) get the same origin, it means that El Paquete Semanal couldn't safely put multiple websites into the same bundle without risking them stepping on each other's storage. It could put them in separate files, but then they'd have trouble linking to each other. If we say (3) and (5) get the same origin, it means that if an archive stores multiple versions of the same website, but those versions use storage differently, users couldn't easily try more than one version. Abandoning some of these use cases definitely makes the URL design easier, if there's consensus to go that direction. However, if we want to keep the use cases, and we want to put the bundle's server in the authority position of the URL, we get something like Larry's suggestion: pkg+ https://foo.example/bundle.wbn?query#https://bar.example/page.html?q=query%23fragment. To give (3)-(5) distinct origins, the origin algorithm for pkg+https needs to take the fragment into account, returning something like ("pkg+https", "foo.example/bundle.wbn?query#https://bar.example", null, null). This design also makes it possible to resolve relative URLs relative to a pkg+https:// base URL, and it gives what's probably the wrong answer, moving relative to the bundle instead of the active subresource. That's probably ok: links inside a bundle need to explicitly search the bundle so that absolute references search the bundle first. If we want to prevent package URLs from being used as base URLs, we could move to something like "package: https://foo.example/bundle.wbn?query#https://bar.example/page.html?q=query%23fragment", which has a similar syntax to blob: URLs and is still more readable than my original proposal. Jeffrey On Thu, Jun 11, 2020 at 5:02 PM Martin Thomson wrote: > 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:$, 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 > > > > _______________________________________________ > Wpack mailing list > Wpack@ietf.org > https://www.ietf.org/mailman/listinfo/wpack > --000000000000388a3505a7eb25e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin and Mallory,

As La= rry mentioned, when the bundle is unsigned, it's the entity serving the= bundle -- distributor.example here -- who has the ability to change the co= ntent, so they're probably the "true" authority. They're = quoting the original publisher of the content, but there's no way for t= he user to verify that the quote is accurate.

Do y= ou support the general goal of giving pairwise-distinct origins to all of:<= /div>

=

If we say (1) and (3) get the same origin, it means the= result can't help the Internet Archive serve their pages more safely, = and we force (3), (4), and (5) to have the same origins.
If we say (2) and (3) get the same origin, we break the entire web origi= n security model. :-D
If we say (3) and (4) get the sa= me origin, it means that El Paquete Semanal couldn't safely put multipl= e websites into the same bundle without risking them stepping on each other= 's storage. It could put them in separate files, but then they'd ha= ve trouble linking to each other.
If we say (3) and (5) get t= he same origin, it means that if an archive stores multiple versions of the= same website, but those versions use storage differently, users couldn'= ;t easily try more than one version.

Abandoning so= me of these use cases definitely makes the URL design easier, if there'= s consensus to go that direction.

However, if we w= ant to keep the use cases, and we want to put the bundle's server in th= e authority position of the URL, we get something like Larry's suggesti= on: pkg+https://foo.example/bundle.wbn?query#https= ://bar.example/page.html?q=3Dquery%23fragment. To give (3)-(5) distinct= origins, the origin algori= thm for pkg+https needs to take the fragment into account, returning so= mething like ("pkg+https", "foo.example/bundle.wbn?query#https://bar.example", null, null). Th= is design also makes it possible to resolve relative URLs relative to a pkg= +https:// base URL, and it gives what's probably the wrong answer,=C2= =A0moving relative to the bundle instead of the active subresource. That= 9;s probably=C2=A0ok: links inside a bundle need to explicitly search the b= undle so that absolute references search the bundle first.

If we want to prevent package URLs from being used as base URLs, w= e could move to something like "package:https= ://foo.example/bundle.wbn?query#https://bar.example/page.html?q=3Dquery%23f= ragment", which has a similar syntax to blob: URLs and is still mo= re readable than my original proposal.

Jeffrey
On T= hu, Jun 11, 2020 at 5:02 PM Martin Thomson <mt@lowentropy.net> wrote:
I have a bunch of concerns about this approach, b= ut let's start with a fairly major one:

This buries the authority.=C2=A0 If your authority is truly publisher.examp= le, then that should be the authority component.=C2=A0 If you regard the re= st as a split between the remainder of the identity of the resource itself = and some secondary information about how that resource might be obtained, t= hen you might have something closer to how you might want to structure a UR= I.

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 <= br> > 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>, whic= h for a
> package URL of https://distributor.example/package.wbn and resource URI
> of https://publisher.example/page.html?q=3Dquery would lead to a URL of:
>
> *package:https:,,distributor.example,package.wbn;q=3Dquery$https:,,pub= lisher.example/page.html?q=3Dquery*
>
> 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 <= br> > transfers.
> 4. Resources inside a bundle are named by URIs (which, since the bundl= e
> has an index, are also URLs even if, like urn:uuid:..., they wouldn= 9;t
> normally be locators).
> 5. Once a user downloads a bundle, for web browsers to give its conten= t
> 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 sugg= ests that browsers
> avoid showing them to users in most cases.
>
> We could potentially simplify things if packages named things with jus= t
> paths instead of full URIs. We'd then name things based on the bun= dle's
> origin. However, this loses archiving use cases.
>
> This is all further discussed in the following documents and issues, <= br> > but you shouldn't feel responsible to read everything here:
>
> *
> https://do= cs.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#messag= e-0a3efda5aff84770a1729422a5b26aeca3ee4e80>
> * https://github.com/WICG/webpackage/issues/583
> *
> https://github.com/WICG/webpackage/blob/master/expla= iners/navigation-to-unsigned-bundles.md#urls-for-bundle-components
> * https://lists.w3.org/Archives/Publi= c/uri/2019Nov/0000.html
>
> Thanks,
> Jeffrey
> _______________________________________________
> Wpack mailing list
> Wpack@ietf.org=
> https://www.ietf.org/mailman/listinfo/wpack
>

_______________________________________________
Wpack mailing list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack
--000000000000388a3505a7eb25e0-- From nobody Sat Jun 13 20:40:50 2020 Return-Path: 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 C3A383A09F6 for ; Sat, 13 Jun 2020 20:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.402 X-Spam-Level: X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 esVscOeQreP1 for ; Sat, 13 Jun 2020 20:40:47 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 9CC603A09F4 for ; Sat, 13 Jun 2020 20:40:47 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id d8so5390254plo.12 for ; Sat, 13 Jun 2020 20:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=JeG9nl3KuDgY0k2C8SkDVmvutAOzjLbpwQir+DpGKCQ=; b=m+4EqiDZ3jzzjwSZwJbCEpR59dGxchJI9FfowdNWMsVFRDsI28hQVWgAeAMw7/8Cd7 0j6HFeWm/wOO0csdftKoI17ilDQMgenl3HpDw2hbakDFKW2/Uqr+w6E5V0xLdN0P7v7E RwCBasDmEUqsvJ57pErvIWb01hDhsOlLgKgPf43dCHwXDJ/MTMyU96K50LgvqRoMNVD2 BhR6B/uQUfSncHRHvtgJ5D71I+l8DBCX5MMdsTEEsErNHDFF1ktb9KswVhX7oSfRmoY4 Cc8E6RlIl0yX9dP1wF/mPH8ldScPv1SBMIkIUtxVbAPhLqsh/kSnBk3wIpPL2C6zc4/5 2VPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=JeG9nl3KuDgY0k2C8SkDVmvutAOzjLbpwQir+DpGKCQ=; b=BZJ+ua01NUxw+p3vjL/3uHNb8xXC1aOuRNFRNDH2VAjnzI1w5x/tvDHHW1admxggq6 HptQu3kfaA5aNm+4Luulbs/caq3uMlYbSHR3q/rv6kw5wVYLokTmaTqKxrl+16PJrrh5 z1muUPA/AV8GvhRrTl/2L0whSJ5cUq7fVheAhMJVsdX4KNVRm5EiysEYZzzxH3BBB+/Q Kd4zj36EwlKVPOPKA83psFh83eQvV5VRSnN1b9L39I753Zwy62NDlpeU5uCNOMb/yO32 COdVeMK/X0FHOteyhQcW+NcU5UaSmoOls/NzDa5T8376Y3tbOWxrb+sfjgCmZZX++6m6 zI8Q== X-Gm-Message-State: AOAM532/2CaMYLgpD36C3wV0ES3kulCOXFJ5b7Ur8F69cURNGLMECq2x iTR/saSbHT4DD4/d5FJAWSUVU/5YBrM= X-Google-Smtp-Source: ABdhPJy2z6pTEz34URu/tsC4eP/K/mzRK02BozI1k2ijF+EI3iefHt5NJDEJqvRonBFzSCZ0WtZ2fQ== X-Received: by 2002:a17:902:ab98:: with SMTP id f24mr2564203plr.154.1592106046810; Sat, 13 Jun 2020 20:40:46 -0700 (PDT) Received: from TVPC (c-67-169-101-78.hsd1.ca.comcast.net. [67.169.101.78]) by smtp.gmail.com with ESMTPSA id iq19sm8674218pjb.48.2020.06.13.20.40.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jun 2020 20:40:45 -0700 (PDT) Sender: Larry Masinter From: Larry Masinter X-Google-Original-From: "Larry Masinter" To: "'Jeffrey Yasskin'" , "'Martin Thomson'" , Cc: "'WPACK List'" References: <97bcac95-c220-41ae-b957-d93fc57f4a74@www.fastmail.com> In-Reply-To: Date: Sat, 13 Jun 2020 20:40:45 -0700 Message-ID: <006801d641fd$96c67c50$c45374f0$@acm.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0069_01D641C2.EA68DCD0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJUN3n7f7U8Tm8IyhTb0CDwyv1MGgIYWzNaAfVnaKynuv/JoA== Content-Language: en-us Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2020 03:40:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0069_01D641C2.EA68DCD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The problem I keep coming back to is that there is no firm line between = the =E2=80=9Carchival=E2=80=9D case and the immediate use case. As soon as you get a representation of the publisher=E2=80=99s resource, = it could change.=20 I looked through all of the links you provided and couldn=E2=80=99t find = any definition of what a =E2=80=9Csigned bundle=E2=80=9D is, or at least what is a = bundle that isn=E2=80=99t =E2=80=9Cunsigned=E2=80=9D. Who signs what, when? And what happens over time with a signed bundle when sites change, certs expire? How are signatures validated? =20 You should look at https://url.spec.whatwg.org/#url-rendering for the = rules you=E2=80=99ll need to modify to get your =E2=80=9Caddress = bar=E2=80=99 conventions. =3D=3D https://LarryMasinter.net = https://going-remote.info =20 From: Wpack On Behalf Of Jeffrey Yasskin Sent: Friday, June 12, 2020 4:08 PM To: Martin Thomson ; mknodel@cdt.org Cc: WPACK List Subject: Re: [Wpack] package: URL scheme =20 Hi Martin and Mallory, =20 As Larry mentioned, when the bundle is unsigned, it's the entity serving = the bundle -- distributor.example here -- who has the ability to change = the content, so they're probably the "true" authority. They're quoting = the original publisher of the content, but there's no way for the user = to verify that the quote is accurate. =20 Do you support the general goal of giving pairwise-distinct origins to = all of: =20 1. https://foo.example/page.html 2. https://bar.example/page.html 3. A resource in the bundle at https://foo.example/bundle.wbn named = https://bar.example/page.html. 4. A resource in the bundle at https://foo.example/bundle.wbn named = https://quux.example/page.html. 5. A resource in the bundle at https://foo.example/otherbundle.wbn named = https://bar.example/page.html. =20 If we say (1) and (3) get the same origin, it means the result can't = help the Internet Archive serve their pages more safely, and we force = (3), (4), and (5) to have the same origins. If we say (2) and (3) get the same origin, we break the entire web = origin security model. :-D If we say (3) and (4) get the same origin, it means that El Paquete = Semanal couldn't safely put multiple websites into the same bundle = without risking them stepping on each other's storage. It could put them = in separate files, but then they'd have trouble linking to each other. If we say (3) and (5) get the same origin, it means that if an archive = stores multiple versions of the same website, but those versions use = storage differently, users couldn't easily try more than one version. =20 Abandoning some of these use cases definitely makes the URL design = easier, if there's consensus to go that direction. =20 However, if we want to keep the use cases, and we want to put the = bundle's server in the authority position of the URL, we get something = like Larry's suggestion: = pkg+https://foo.example/bundle.wbn?query#https://bar.example/page.html?q=3D= query%23fragment. To give (3)-(5) distinct origins, the origin algorithm = for pkg+https needs to take the = fragment into account, returning something like ("pkg+https", = "foo.example/bundle.wbn?query#https://bar.example", null, null). This = design also makes it possible to resolve relative URLs relative to a = pkg+https:// base URL, and it gives what's probably the wrong answer, = moving relative to the bundle instead of the active subresource. That's = probably ok: links inside a bundle need to explicitly search the bundle = so that absolute references search the bundle first. =20 If we want to prevent package URLs from being used as base URLs, we = could move to something like = "package:https://foo.example/bundle.wbn?query#https://bar.example/page.ht= ml?q=3Dquery%23fragment", which has a similar syntax to blob: URLs and = is still more readable than my original proposal. =20 Jeffrey =20 On Thu, Jun 11, 2020 at 5:02 PM Martin Thomson > wrote: 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, >=20 > I wanted to raise awareness of a discussion about the URL scheme for=20 > addressing resources within bundles=20 > (draft-yasskin-wpack-bundled-exchanges). >=20 > We seem to be heading toward a URL of the form=20 > package:$, which for a=20 > package URL of https://distributor.example/package.wbn and resource = URI=20 > of https://publisher.example/page.html?q=3Dquery would lead to a URL = of: >=20 > = *package:https:,,distributor.example,package.wbn;q=3Dquery$https:,,publis= her.example/page.html?q=3Dquery* >=20 > 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=20 > file:///... > 3. We can also hash the bundle to get a URI that stays stable across=20 > transfers. > 4. Resources inside a bundle are named by URIs (which, since the = bundle=20 > has an index, are also URLs even if, like urn:uuid:..., they wouldn't=20 > normally be locators). > 5. Once a user downloads a bundle, for web browsers to give its = content=20 > storage that's persistent across reloads, as requested in=20 > https://github.com/WICG/webpackage/issues/498, the content needs to be = > assigned a non-opaque origin. >=20 > I'm updating one of the documents about this in=20 > https://github.com/WICG/webpackage/pull/584 and would welcome comments = > here or there. >=20 > The URLs are obviously gross, so=20 > https://github.com/WICG/webpackage/pull/560 suggests that browsers=20 > avoid showing them to users in most cases.=20 >=20 > We could potentially simplify things if packages named things with = just=20 > paths instead of full URIs. We'd then name things based on the = bundle's=20 > origin. However, this loses archiving use cases. >=20 > This is all further discussed in the following documents and issues,=20 > but you shouldn't feel responsible to read everything here: >=20 > *=20 > = https://docs.google.com/document/d/1BYQEi8xkXDAg9lxm3PaoMzEutuQAZi1r8Y0pL= aFJQoo/edit# = =20 > *=20 > = https://chromium-review.googlesource.com/c/chromium/src/+/2226248/7#messa= ge-0a3efda5aff84770a1729422a5b26aeca3ee4e80 < =20 https://chromium-review.googlesource.com/c/chromium/src/+/2226248/7#messa= ge-0a3efda5aff84770a1729422a5b26aeca3ee4e80> > * https://github.com/WICG/webpackage/issues/583 > *=20 > = https://github.com/WICG/webpackage/blob/master/explainers/navigation-to-u= nsigned-bundles.md#urls-for-bundle-components > * https://lists.w3.org/Archives/Public/uri/2019Nov/0000.html >=20 > Thanks, > Jeffrey > _______________________________________________ > Wpack mailing list > Wpack@ietf.org =20 > https://www.ietf.org/mailman/listinfo/wpack > _______________________________________________ Wpack mailing list Wpack@ietf.org =20 https://www.ietf.org/mailman/listinfo/wpack ------=_NextPart_000_0069_01D641C2.EA68DCD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The problem I keep coming back = to is that there is no firm line between the =E2=80=9Carchival=E2=80=9D = case and the immediate use case.

As = soon as you get a representation of the publisher=E2=80=99s resource, it = could change.

I looked through all = of the links you provided and couldn=E2=80=99t find any definition
of = what a =E2=80=9Csigned bundle=E2=80=9D is, or at least what is a bundle = that isn=E2=80=99t =E2=80=9Cunsigned=E2=80=9D.

Who signs what, when? And what happens over time with = a signed bundle
when sites change, certs expire? How are signatures = validated?

 

You should look at https://url.spec.what= wg.org/#url-rendering for the rules you=E2=80=99ll need to modify to = get your =E2=80=9Caddress bar=E2=80=99 conventions.

=3D=3D

https://LarryMasinter.net https://going-remote.info

 

From: Wpack = <wpack-bounces@ietf.org> On Behalf Of Jeffrey = Yasskin
Sent: Friday, June 12, 2020 4:08 PM
To: = Martin Thomson <mt@lowentropy.net>; mknodel@cdt.org
Cc: = WPACK List <wpack@ietf.org>
Subject: Re: [Wpack] = package: URL scheme

 

Hi = Martin and Mallory,

 

As Larry mentioned, when the bundle is unsigned, it's = the entity serving the bundle -- distributor.example here -- who has the = ability to change the content, so they're probably the "true" = authority. They're quoting the original publisher of the content, but = there's no way for the user to verify that the quote is = accurate.

 

Do you support the general goal of giving = pairwise-distinct origins to all of:

 

 

If we say (1) and (3) get the same origin, it means = the result can't help the Internet Archive serve their pages more = safely, and we force (3), (4), and (5) to have the same = origins.

If we say (2) and = (3) get the same origin, we break the entire web origin security model. = :-D

If we say (3) and (4) = get the same origin, it means that El Paquete Semanal couldn't safely = put multiple websites into the same bundle without risking them stepping = on each other's storage. It could put them in separate files, but then = they'd have trouble linking to each other.

If we say (3) and (5) get the same origin, it means = that if an archive stores multiple versions of the same website, but = those versions use storage differently, users couldn't easily try more = than one version.

 

Abandoning some of these use cases definitely makes = the URL design easier, if there's consensus to go that = direction.

 

However, if we want to keep the use cases, and we want = to put the bundle's server in the authority position of the URL, we get = something like Larry's suggestion: pkg+https://foo.example/bundle.wbn?query#https://bar.= example/page.html?q=3Dquery%23fragment. To give (3)-(5) distinct = origins, the origin = algorithm for pkg+https needs to take the fragment into account, = returning something like ("pkg+https", = "foo.example/bundle.wbn?query#https://bar.example", null, null). = This design also makes it possible to resolve relative URLs relative to = a pkg+https:// base URL, and it gives what's probably the wrong = answer, moving relative to the bundle instead of the active = subresource. That's probably ok: links inside a bundle need to = explicitly search the bundle so that absolute references search the = bundle first.

 

If we want to prevent package URLs from being used as = base URLs, we could move to something like "package:https://foo.example/bundle.wbn?query#https://bar.= example/page.html?q=3Dquery%23fragment", which has a similar = syntax to blob: URLs and is still more readable than my original = proposal.

 

Jeffrey

 

On = Thu, Jun 11, 2020 at 5:02 PM Martin Thomson <mt@lowentropy.net> = wrote:

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=3Dquery = would lead to a URL of:
>
> = *package:https:,,distributor.example,package.wbn;q=3Dquery$https:,,publis= her.example/page.html?q=3Dquery*
>
> 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/1BYQEi8xkXDAg9lxm3Pa= oMzEutuQAZi1r8Y0pLaFJQoo/edit#
> *
> = https://chromium-review.googlesource.com/c/chromium/src/+/2226248/7#message-0a3= efda5aff84770a1729422a5b26aeca3ee4e80 <

 

https://chromium-rev= iew.googlesource.com/c/chromium/src/+/2226248/7#message-0a3efda5aff84770a= 1729422a5b26aeca3ee4e80>
> * https://github.com/WICG/webpackage/issues/583
&g= t; *
> https://github.com/WICG/webpackage/blob/master/explaine= rs/navigation-to-unsigned-bundles.md#urls-for-bundle-components
&g= t; * https://lists.w3.org/Archives/Public/uri/2019Nov/0000.h= tml
>
> Thanks,
> Jeffrey
> = _______________________________________________
> Wpack mailing = list
> Wpack@ietf.org
> https://www.ietf.org/mailman/listinfo/wpack
>=

_______________________________________________
Wpack mailing = list
Wpack@ietf.org
https://www.ietf.org/mailman/listinfo/wpack

------=_NextPart_000_0069_01D641C2.EA68DCD0-- From nobody Sun Jun 14 18:38:19 2020 Return-Path: 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 4CE1A3A07E7 for ; Sun, 14 Jun 2020 18:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=JZaWh4G7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AD9N0TxO 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 ND4vxXigFocM for ; Sun, 14 Jun 2020 18:38:15 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988C33A085B for ; Sun, 14 Jun 2020 18:38:13 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id B23B93FB; Sun, 14 Jun 2020 21:38:12 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Sun, 14 Jun 2020 21:38:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=GmBWWK9xc235D7u0cpMDdoxs/4kv iaqSMCsRP0/o2Go=; b=JZaWh4G7tai2KVFjLoiwMhXN95MoTxjeEJYu2D/oTurI NRlpH4qlt9FGXVk7sYxq2SODB5ia5d26AdURr4TXJolkhlEoChCBhLbPjhlEqTcu bIQmEC5e9CvDoKxxdf5NsIf6OlNxjfLHn0kKdJJHPa8fKDdrZ1Ua1Fx3v0c3jnDi xBa0D2UJuA1BRMzmb0BPf1sSkqu5P0jCOcTrSkFLudjHCd+HyfcTknJl4x/yWxIJ 7bSFplZsksQHMjh3rouGn26J0zfdPT94jgsaob/HK2FbW5IvzIpEwQA9NO/29JQO WvmZzRaVpbPIuhBPky+BptCy3m7WWfgpdV7Xh6aICQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=GmBWWK 9xc235D7u0cpMDdoxs/4kviaqSMCsRP0/o2Go=; b=AD9N0TxOR/20hFkaJ+O4Ix AtjK9l3lFAnevOuyMolEx3juGdIRXqCMEELuyEEYebVIytJqCDZsH9BldjkSe7Wi A3dFu+uJMfixBoJmCxp0IoT3pNn7y5U41t5qZT4emiSZDInHQ0xNYfcYQpI07hgg g2hhfnymYoen4UfcwkKNlrpfWoojxEu1VSPkJle5UH82ZzXK3XsRUgIkV33ME9sW f/Xm1hiQLX1ck5UP8Jkc1opaeJjHgde8d/NYaqBT7HzBz5LQdW9g2orfUMTv2ImZ 41lt+J1tzOoa8jurjjieIdmx166u16lNm0lvbpvoS0WAkauM9zLiHOL4wUc6wkpQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeijedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhephfdtfedtjeeivdetkeevgfdtieethffhgfetvdejieekkeetvdev ffdtvefggeefnecuffhomhgrihhnpehhthhmlhhqqhhuvghrhidvfehfrhgrghhmvghnth drthhopdifhhgrthifghdrohhrghdpvgigrghmphhlvgdrtghomhenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhoph ihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0C2E0E00A8; Sun, 14 Jun 2020 21:38:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <97bcac95-c220-41ae-b957-d93fc57f4a74@www.fastmail.com> Date: Mon, 15 Jun 2020 11:37:25 +1000 From: "Martin Thomson" To: "Jeffrey Yasskin" , mknodel@cdt.org Cc: "WPACK List" Content-Type: text/plain Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 01:38:17 -0000 On Sat, Jun 13, 2020, at 09:07, Jeffrey Yasskin wrote: > 1. https://foo.example/page.html > 2. https://bar.example/page.html > 3. A resource in the bundle at https://foo.example/bundle.wbn named > https://bar.example/page.html. > 4. A resource in the bundle at https://foo.example/bundle.wbn named > https://quux.example/page.html. > 5. A resource in the bundle at https://foo.example/otherbundle.wbn > named https://bar.example/page.html. > > If we say (1) and (3) get the same origin, it means the result can't > help the Internet Archive serve their pages more safely, and we force > (3), (4), and (5) to have the same origins. Yes, I think that having 1 and 3 being distinct is an important property. I tend to stop at this point and not try to add too much more, but there you go. > If we say (2) and (3) get the same origin, we break the entire web > origin security model. :-D (1) and (2) more so. Part of what we're trying to do is find a way to bring (2) and (3) closer (and (5) too). That doesn't necessarily need to mean that we treat them identically. Though we might find a path to doing so. > If we say (3) and (4) get the same origin, it means that El Paquete > Semanal couldn't safely put multiple websites into the same bundle > without risking them stepping on each other's storage. It could put > them in separate files, but then they'd have trouble linking to each > other. What cannot be solved with one level of abstraction might be solved with two. If the distinctive characteristic of a bundle is that it creates a new origin, then a bundle that contains other bundles can be used to isolate content from different origins. The El Paquete Semanal as a whole could be assembled from multiple bundles from different "real" origins. As you say, that complicates the process of inter-origin references. Say the El Paquete Semanal bundle was served by non-determined means, then you can't rely on having a shared identifier for the outer bundle, unless you have some means of minting one. (This is a case where you can't refer to the outer bundle from the inner one using content identification, for reasons that I hope are obvious.) So you mint one (a signing key might suffice) and then you can refer from one inner bundle to another inner bundle via that identifier. The reference chain might become convoluted, but I don't see a need to constrain URL design to fit that use case. As long as references are possible, then we can work on making it more usable. If you have siteA.example and siteB.example served from bundle.example from distributor.example, then my hope would be that your inter-site references are of the form: ://siteX.example/ I say that because while siteA and siteB might expect to be served from the same meta-bundle, there shouldn't need to be a strong binding to that situation. If one is and the other not, then I would hope that the identifiers would support that without requiring strong changes. > If we say (3) and (5) get the same origin, it means that if an archive > stores multiple versions of the same website, but those versions use > storage differently, users couldn't easily try more than one version. I think that this is a key question. My assertion is that maintaining a clean abstraction for bundles is important and that would dictate having (3) and (5) distinct. At least initially. Mechanisms that allow transfer of state or content between origins might allow an upgrade to occur from (3) to (5). > Abandoning some of these use cases definitely makes the URL design > easier, if there's consensus to go that direction. > > However, if we want to keep the use cases, and we want to put the > bundle's server in the authority position of the URL, we get something > like Larry's suggestion: > pkg+https://foo.example/bundle.wbn?query#https://bar.example/page.html?q=query%23fragment. To give (3)-(5) distinct origins, the origin algorithm for pkg+https needs to take the fragment into account, returning something like ("pkg+https", "foo.example/bundle.wbn?query#https://bar.example", null, null). This design also makes it possible to resolve relative URLs relative to a pkg+https:// base URL, and it gives what's probably the wrong answer, moving relative to the bundle instead of the active subresource. That's probably ok: links inside a bundle need to explicitly search the bundle so that absolute references search the bundle first. Rather than try to work the identity of the serving entity into the origin, it might be better to look to the limits of the origin concept. We're seeing browsers move more toward placing origins within a greater context. Double-keying storage by top-level browsing context shows us how maybe the origin isn't able to capture the entire context. The same might apply here. Maybe it is important that this bundle originally came from foo.example, but it might not be important to the concept of the origin model. Relative references within a bundle should be simple and possible, but I fear that expecting fragments to support that is likely to run afoul of all sorts of existing expectations. Using fragments for bundles is likely good if you don't want to mint a new URI scheme, but if you are in the business of defining a new scheme, then go for it. If you are defining a new media type, then the fragment can do whatever you like. With no new URI scheme needed: https://foo.example/bundle.wbn?query# Similarly, once you are defining a new URI scheme, then you have a lot of options available. The URI standard is perhaps unnecessarily narrow in its definition of authority, but there's a lot of room for creative interpretation: a registered name doesn't need to be domain name, and there are no real mechanism that ensure that it is "registered" (whatever that means). pkg:///page.html?q=query%23fragment The definition of origin necessarily becomes more flexible. Rather than insist on the reduction to a simple tuple for an origin, we should regard these having a same-origin comparison operation, which sometimes allow two origins to be regarded the same, even with vastly different inputs. The reduction to a tuple is useful, but potentially quite confining. If pkg:// and https:// happen to be same origin because we decide that is useful (and safe), then we should be free to define that as we choose, within the constraints of the origin tuple or not. Despite it being quite clearly invalid for domain name and port, this is completely valid URI if we so choose: . That doesn't mean that it couldn't be same-origin with , but it might be a little tricky to reduce to an origin tuple. From nobody Mon Jun 15 11:17:13 2020 Return-Path: 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 3D4243A0887 for ; Mon, 15 Jun 2020 11:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 c33c_KVn7zb1 for ; Mon, 15 Jun 2020 11:17:09 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 A48823A089C for ; Mon, 15 Jun 2020 11:17:09 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id d27so13411512qtg.4 for ; Mon, 15 Jun 2020 11:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qzud+dls6AaR6w8tw5zFm0wVR+KOtt9JvdXmQycdLOc=; b=VfnLAwYIkckPr2rZ+eHxetVHAVlbu358Yf3GxYuupwkpXoGdRckibo1MYpoeSq4ELM 8rcqd5c1CHlr41/hpc/Z8KDWBXt0+X1WnFT9eTCy1BxTJ85YL8fu72uKEaP92joli0Yg TfMyBLyNV3DRu89NanuvP8Ley/5RkQhC+b1Ro= 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=qzud+dls6AaR6w8tw5zFm0wVR+KOtt9JvdXmQycdLOc=; b=d7mhE9lVgDmZo8W/YxV01nRwUajzN0eqsE3TPjZxL8qscpYlJlgrDExOTwqoXExuIp tn3hy/hcDWsSVhwkFl6r6bFNzjs0WBhZQ2vzNzKpJzEAd4pjSLZZPSHXqUKv95/535wV aMUwQhsgQbuEKgWjYIPyuNfbhYWOI0gsPjdVJF/WE1us8wz6xzBD71shTd/MWFG8DMoq FqZGSDRglYX+7vAa7oKB/BYcQHt1WMaE1u7TpINWnKjlFydB3yBLiOI5CXaX7CXMZGS2 +03t00PGGkm+kzrM0ax8My6njA3qgDt8jwIISKc3LRowYBrGB8PrIZ1oo0G9NOrHspU+ rLcA== X-Gm-Message-State: AOAM530jp4I+PCwVwuo4oCW8PZsRJxwhrA57epiyyauXLqK/HoeEhyDe 8ww3LvUhgQ87wahA2BTc+lvtgSC3fskTH+qi/CRZ3w== X-Google-Smtp-Source: ABdhPJysdKr3+smUBDIwJsTJQoC0vBOwqcJPXPhT+3ymZDsTokKMpYVW35BnaZtmSWyJ1/kUHQXVPKWHi/KqB4QWBSo= X-Received: by 2002:aed:33c1:: with SMTP id v59mr17408250qtd.250.1592245028185; Mon, 15 Jun 2020 11:17:08 -0700 (PDT) MIME-Version: 1.0 References: <97bcac95-c220-41ae-b957-d93fc57f4a74@www.fastmail.com> In-Reply-To: From: Jeffrey Yasskin Date: Mon, 15 Jun 2020 11:16:56 -0700 Message-ID: To: Martin Thomson Cc: Jeffrey Yasskin , mknodel@cdt.org, WPACK List Content-Type: multipart/alternative; boundary="0000000000004d684f05a8236f5a" Archived-At: Subject: Re: [Wpack] package: URL scheme X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 18:17:12 -0000 --0000000000004d684f05a8236f5a Content-Type: text/plain; charset="UTF-8" Replies inline. On Sun, Jun 14, 2020 at 6:38 PM Martin Thomson wrote: > On Sat, Jun 13, 2020, at 09:07, Jeffrey Yasskin wrote: > > 1. https://foo.example/page.html > > 2. https://bar.example/page.html > > 3. A resource in the bundle at https://foo.example/bundle.wbn named > > https://bar.example/page.html. > > 4. A resource in the bundle at https://foo.example/bundle.wbn named > > https://quux.example/page.html. > > 5. A resource in the bundle at https://foo.example/otherbundle.wbn > > named https://bar.example/page.html. > > > > If we say (1) and (3) get the same origin, it means the result can't > > help the Internet Archive serve their pages more safely, and we force > > (3), (4), and (5) to have the same origins. > > Yes, I think that having 1 and 3 being distinct is an important property. > I tend to stop at this point and not try to add too much more, but there > you go. > I think distinguishing (1) and (3) requires a new scheme. > If we say (2) and (3) get the same origin, we break the entire web > > origin security model. :-D > > (1) and (2) more so. > > Part of what we're trying to do is find a way to bring (2) and (3) closer > (and (5) too). That doesn't necessarily need to mean that we treat them > identically. Though we might find a path to doing so. > I think the signing or transfer effort described in draft-thomson-wpack-content-origin and draft-yasskin-http-origin-signed-responses tries to get (2) and (3) closer together, but here I'm focusing on use cases that don't need the browser to recognize (2) and (3) as related at all. > If we say (3) and (4) get the same origin, it means that El Paquete > > Semanal couldn't safely put multiple websites into the same bundle > > without risking them stepping on each other's storage. It could put > > them in separate files, but then they'd have trouble linking to each > > other. > > What cannot be solved with one level of abstraction might be solved with > two. > > If the distinctive characteristic of a bundle is that it creates a new > origin, then a bundle that contains other bundles can be used to isolate > content from different origins. The El Paquete Semanal as a whole could be > assembled from multiple bundles from different "real" origins. > > As you say, that complicates the process of inter-origin references. Say > the El Paquete Semanal bundle was served by non-determined means, then you > can't rely on having a shared identifier for the outer bundle, unless you > have some means of minting one. (This is a case where you can't refer to > the outer bundle from the inner one using content identification, for > reasons that I hope are obvious.) So you mint one (a signing key might > suffice) and then you can refer from one inner bundle to another inner > bundle via that identifier. > > The reference chain might become convoluted, but I don't see a need to > constrain URL design to fit that use case. As long as references are > possible, then we can work on making it more usable. If you have > siteA.example and siteB.example served from bundle.example from > distributor.example, then my hope would be that your inter-site references > are of the form: > > ://siteX.example/ distributor.example, but the latter might be best left implied> > > I say that because while siteA and siteB might expect to be served from > the same meta-bundle, there shouldn't need to be a strong binding to that > situation. If one is and the other not, then I would hope that the > identifiers would support that without requiring strong changes. > There's a downside that this still requires rewriting all the cross-origin links inside the documents, but as El Paquete Semanal is already rewriting links to put everything on a filesystem, maybe that's not a big problem. I'm curious what you think the hint could look like. You've sketched it in the path area, but these URLs also have paths, so we'd need something to separate the two parts of the path in the same way my first attempt separated two parts of the authority. > If we say (3) and (5) get the same origin, it means that if an archive > > stores multiple versions of the same website, but those versions use > > storage differently, users couldn't easily try more than one version. > > I think that this is a key question. My assertion is that maintaining a > clean abstraction for bundles is important and that would dictate having > (3) and (5) distinct. At least initially. Mechanisms that allow transfer > of state or content between origins might allow an upgrade to occur from > (3) to (5). > > > Abandoning some of these use cases definitely makes the URL design > > easier, if there's consensus to go that direction. > > > > However, if we want to keep the use cases, and we want to put the > > bundle's server in the authority position of the URL, we get something > > like Larry's suggestion: > > pkg+ > https://foo.example/bundle.wbn?query#https://bar.example/page.html?q=query%23fragment. > To give (3)-(5) distinct origins, the origin algorithm < > https://url.spec.whatwg.org/#origin> for pkg+https needs to take the > fragment into account, returning something like ("pkg+https", > "foo.example/bundle.wbn?query#https://bar.example", null, null). This > design also makes it possible to resolve relative URLs relative to a > pkg+https:// base URL, and it gives what's probably the wrong answer, > moving relative to the bundle instead of the active subresource. That's > probably ok: links inside a bundle need to explicitly search the bundle so > that absolute references search the bundle first. > > Rather than try to work the identity of the serving entity into the > origin, it might be better to look to the limits of the origin concept. > We're seeing browsers move more toward placing origins within a greater > context. Double-keying storage by top-level browsing context shows us how > maybe the origin isn't able to capture the entire context. The same might > apply here. Maybe it is important that this bundle originally came from > foo.example, but it might not be important to the concept of the origin > model. > This is an interesting point: we could use the new storage keys being created by https://github.com/privacycg/storage-partitioning to declare that an environment settings object with a bundle attached uses a storage key derived from both the bundle's URL and the subresource's URL, instead of trying to encapsulate both into a single origin. Relative references within a bundle should be simple and possible, but I > fear that expecting fragments to support that is likely to run afoul of all > sorts of existing expectations. Using fragments for bundles is likely good > if you don't want to mint a new URI scheme, but if you are in the business > of defining a new scheme, then go for it. > > If you are defining a new media type, then the fragment can do whatever > you like. With no new URI scheme needed: > > https://foo.example/bundle.wbn?query# don't expect internal references to work> > > Similarly, once you are defining a new URI scheme, then you have a lot of > options available. The URI standard is perhaps unnecessarily narrow in its > definition of authority, but there's a lot of room for creative > interpretation: a registered name doesn't need to be domain name, and there > are no real mechanism that ensure that it is "registered" (whatever that > means). > > pkg:// bar.example>/page.html?q=query%23fragment > This is how I got to package:https:,,distributor.example,package.wbn;q=query$https:,,publisher.example/page.html?q=query (or package://...). It claims that the "authority" for a subresource inside a bundle consists of both the bundle's location and the subresource's origin. arcp:// did the same, but without the subresource's origin, which would have the effect of unifying (3) and (4). The definition of origin necessarily becomes more flexible. Rather than > insist on the reduction to a simple tuple for an origin, we should regard > these having a same-origin comparison operation, which sometimes allow two > origins to be regarded the same, even with vastly different inputs. The > reduction to a tuple is useful, but potentially quite confining. > > If pkg:// and https:// happen to be same origin because we > decide that is useful (and safe), then we should be free to define that as > we choose, within the constraints of the origin tuple or not. > > Despite it being quite clearly invalid for domain name and port, this is > completely valid URI if we so choose: . That doesn't mean > that it couldn't be same-origin with , but it might > be a little tricky to reduce to an origin tuple. > I don't mind diverging from the origin-tuple concept, but so far I haven't found a need to. Thanks, Jeffrey --0000000000004d684f05a8236f5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Replies inline.=C2=A0

On Sun, Jun 14, 2020 at 6:38 PM = Martin Thomson <mt@lowentropy.net> wrote:
On= Sat, Jun 13, 2020, at 09:07, Jeffrey Yasskin wrote:
> 1. https://foo.example/page.html
> 2. https://bar.example/page.html
> 3. A resource in the bundle at https://foo.example/bundle.wbn= named
> https://bar.example/page.html.
> 4. A resource in the bundle at https://foo.example/bundle.wbn= named
> https://quux.example/page.html.
> 5. A resource in the bundle at https://foo.example/otherbund= le.wbn
> named https://bar.example/page.html.
>
> If we say (1) and (3) get the same origin, it means the result can'= ;t
> help the Internet Archive serve their pages more safely, and we force =
> (3), (4), and (5) to have the same origins.

Yes, I think that having 1 and 3 being distinct is an important property.= =C2=A0 I tend to stop at this point and not try to add too much more, but t= here you go.

I think distinguishing (1)= and (3) requires a new scheme.

> If we say (2) and (3) get the same origin, we break the entire web > origin security model. :-D

(1) and (2) more so.

Part of what we're trying to do is find a way to bring (2) and (3) clos= er (and (5) too). That doesn't necessarily need to mean that we treat t= hem identically.=C2=A0 Though we might find a path to doing so.

I think the signing or transfer effort described i= n=C2=A0draft-thomson-wpack-content-origin and=C2=A0draft-yasskin-http-origi= n-signed-responses tries to get (2) and (3) closer together, but here I'= ;m focusing on use cases that don't need the browser to recognize (2) a= nd (3) as related at all.

> If we say (3) and (4) get the same origin, it means that El Paquete > Semanal couldn't safely put multiple websites into the same bundle=
> without risking them stepping on each other's storage. It could pu= t
> them in separate files, but then they'd have trouble linking to ea= ch
> other.

What cannot be solved with one level of abstraction might be solved with tw= o.

If the distinctive characteristic of a bundle is that it creates a new orig= in, then a bundle that contains other bundles can be used to isolate conten= t from different origins.=C2=A0 The El Paquete Semanal as a whole could be = assembled from multiple bundles from different "real" origins.
As you say, that complicates the process of inter-origin references.=C2=A0 = Say the El Paquete Semanal bundle was served by non-determined means, then = you can't rely on having a shared identifier for the outer bundle, unle= ss you have some means of minting one.=C2=A0 (This is a case where you can&= #39;t refer to the outer bundle from the inner one using content identifica= tion, for reasons that I hope are obvious.)=C2=A0 So you mint one (a signin= g key might suffice) and then you can refer from one inner bundle to anothe= r inner bundle via that identifier.

The reference chain might become convoluted, but I don't see a need to = constrain URL design to fit that use case.=C2=A0 As long as references are = possible, then we can work on making it more usable.=C2=A0 If you have site= A.example and siteB.example served from bundle.example from distributor.exa= mple, then my hope would be that your inter-site references are of the form= :

<something>://siteX.example/<a hint that mentions bundle.example a= nd maybe distributor.example, but the latter might be best left implied>=

I say that because while siteA and siteB might expect to be served from the= same meta-bundle, there shouldn't need to be a strong binding to that = situation.=C2=A0 If one is and the other not, then I would hope that the id= entifiers would support that without requiring strong changes.

There's a downside that this still requires rew= riting all the cross-origin links inside the documents, but as El Paquete S= emanal is already rewriting links to put everything on a filesystem, maybe = that's not a big problem.

I'm curious what= you think the hint could look like. You've sketched it in the path are= a, but these URLs also have paths, so we'd need something to separate t= he two parts of the path in the same way my first attempt separated two par= ts of the authority.=C2=A0

> If we say (3) and (5) get the same origin, it means that if an archive=
> stores multiple versions of the same website, but those versions use <= br> > storage differently, users couldn't easily try more than one versi= on.

I think that this is a key question.=C2=A0 My assertion is that maintaining= a clean abstraction for bundles is important and that would dictate having= (3) and (5) distinct.=C2=A0 At least initially.=C2=A0 Mechanisms that allo= w transfer of state or content between origins might allow an upgrade to oc= cur from (3) to (5).

> Abandoning some of these use cases definitely makes the URL design > easier, if there's consensus to go that direction.
>
> However, if we want to keep the use cases, and we want to put the
> bundle's server in the authority position of the URL, we get somet= hing
> like Larry's suggestion:
> pkg+http= s://foo.example/bundle.wbn?query#https://bar.example/page.html?q=3Dquery%23= fragment. To give (3)-(5) distinct origins, the origin algorithm <https://url.spec.whatwg.org/#origin> for pkg+https needs to = take the fragment into account, returning something like ("pkg+https&q= uot;, "foo.example/bundle.wbn?query#https://bar.example", null, nul= l). This design also makes it possible to resolve relative URLs relative to= a pkg+https:// base URL, and it gives what's probably the wrong answer= , moving relative to the bundle instead of the active subresource. That'= ;s probably ok: links inside a bundle need to explicitly search the bundle = so that absolute references search the bundle first.

Rather than try to work the identity of the serving entity into the origin,= it might be better to look to the limits of the origin concept.=C2=A0 We&#= 39;re seeing browsers move more toward placing origins within a greater con= text.=C2=A0 Double-keying storage by top-level browsing context shows us ho= w maybe the origin isn't able to capture the entire context.=C2=A0 The = same might apply here.=C2=A0 Maybe it is important that this bundle origina= lly came from foo.example, but it might not be important to the concept of = the origin model.

This is an interestin= g point: we could use the new storage keys=C2=A0being created by=C2=A0https://github.com/privacycg/st= orage-partitioning=C2=A0to declare that an environment settings object = with a bundle attached uses a storage key derived from both the bundle'= s URL and the subresource's=C2=A0URL, instead of trying to encapsulate = both into a single origin.

Relative references within a bundle should be simple and possible, but I fe= ar that expecting fragments to support that is likely to run afoul of all s= orts of existing expectations.=C2=A0 Using fragments for bundles is likely = good if you don't want to mint a new URI scheme, but if you are in the = business of defining a new scheme, then go for it.

If you are defining a new media type, then the fragment can do whatever you= like.=C2=A0 With no new URI scheme needed:

https://foo.example/bundle.wbn?query#<use whatever you f= eel like, but don't expect internal references to work>

Similarly, once you are defining a new URI scheme, then you have a lot of o= ptions available.=C2=A0 The URI standard is perhaps unnecessarily narrow in= its definition of authority, but there's a lot of room for creative in= terpretation: a registered name doesn't need to be domain name, and the= re are no real mechanism that ensure that it is "registered" (wha= tever that means).

pkg://<the authority for the above bundle, which might not be bar.exampl= e>/page.html?q=3Dquery%23fragment

Th= is is how I got to=C2=A0package:https:,,distributor.example,package.wbn;q= =3Dquery$https:,,publisher.example/page.html?q=3Dquery (or package://...). = It claims that the "authority" for a subresource inside a bundle = consists of both the bundle's location and the subresource's origin= . arcp:// did the same, but without the subresource's origin, which wou= ld have the effect of unifying (3) and (4).

The definition of origin necessarily becomes more flexible.=C2=A0 Rather th= an insist on the reduction to a simple tuple for an origin, we should regar= d these having a same-origin comparison operation, which sometimes allow tw= o origins to be regarded the same, even with vastly different inputs.=C2=A0= The reduction to a tuple is useful, but potentially quite confining.

If pkg://<bar> and https://<foo> happen to be same origin becau= se we decide that is useful (and safe), then we should be free to define th= at as we choose, within the constraints of the origin tuple or not.

Despite it being quite clearly invalid for domain name and port, this is co= mpletely valid URI if we so choose: <pkg://$:1000000/>. That doesn= 9;t mean that it couldn't be same-origin with <https://example.com/&g= t;, but it might be a little tricky to reduce to an origin tuple.

I don't mind diverging from the origin-tuple= concept, but so far I haven't found a need to.

Thanks,
Jeffrey=C2=A0
--0000000000004d684f05a8236f5a-- From nobody Mon Jun 22 21:13:11 2020 Return-Path: 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 1C3983A1734 for ; Mon, 22 Jun 2020 21:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=sn3rd.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 vAyy8o1MVwb4 for ; Mon, 22 Jun 2020 21:13:08 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 DE3EB3A1735 for ; Mon, 22 Jun 2020 21:13:07 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id l6so14036006qkc.6 for ; Mon, 22 Jun 2020 21:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=D9ulxBectyoTeBb9XGLzWLLuc7GnJt8WApQtEP5uwsg=; b=ZIPmGicawxmw7tPQiZdRpLpLFPHYsPwK769TqdRBVV7C8BFgXSqdUsJ/xTnEmkJxEX VMJb8tg7ENoSjr8wmYp6NBk25Bx5QpJrrFgk/rr9Q2ZtHltmdQf7jFaj0/rItFgZaa+r UefSkjSoXWRSKl3J/XHIJyVH8nvLfhac2nB08= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=D9ulxBectyoTeBb9XGLzWLLuc7GnJt8WApQtEP5uwsg=; b=sPp5VW37jhEkmaUuBw5OWZMMsvIgfVk1PZnk0YpVTYS2Ably3SosHkdnSvuo0Nph3b /nGNPaUUtSlmSxx62ujbJ1j9SmCUitihSjwwV+4XgnClNX9KF9+6OPAvCifF8s/t5OPz mzu+/LxUP4gg9JxPYiDe783XCJIgHx1YhN7vWE6hQ+IR1lWKW/t0R+ghxrpDi0CJQ6aS wOi9a/gjooqb+ATGaau0Vxg0V+wLa8hGlip27Ol1y6heYBKW04BuAp0CvJGdIUdMxQlI mhZsolWSPKCo9MvFDe7G00NIvfnJTjcOLptn8/GkNTbBdfG0ge5rYzA/IbhMlMTZDtmd KOTw== X-Gm-Message-State: AOAM530fDug6dTrXp74PE6+YkcUjNK3myn0NnkHVhIvEBM1O1SDGJkpJ 2yUcBv9SQTsTbYeiRguAeBMWB0I4SoE= X-Google-Smtp-Source: ABdhPJzjMoqkhVr0nqCB6/n7QG4ecPNWUM0Aao5/0K3Ryyk8nBeGXAR62McrYOMaHIdUg0OwpHkWFA== X-Received: by 2002:a37:4f4f:: with SMTP id d76mr19464618qkb.40.1592885586756; Mon, 22 Jun 2020 21:13:06 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id g145sm5846311qke.17.2020.06.22.21.13.05 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2020 21:13:06 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_DB6A67B2-8310-4DA8-8A94-E7AF0BA78180" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <4EF46447-4304-4415-B4B4-955E2ADB96E7@sn3rd.com> References: <159251992201.11993.15942540018989542642@ietfa.amsl.com> To: WPACK List Date: Tue, 23 Jun 2020 00:13:04 -0400 X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Wpack] Fwd: Nomcom 2020-2021 Final Call For Volunteers X-BeenThere: wpack@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Web Packaging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 04:13:10 -0000 --Apple-Mail=_DB6A67B2-8310-4DA8-8A94-E7AF0BA78180 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In case you are not on the IETF discuss list. spt > Begin forwarded message: >=20 > From: NomCom Chair 2020 > Subject: Nomcom 2020-2021 Final Call For Volunteers > Date: June 18, 2020 at 18:38:42 EDT > To: "IETF Announcement List" > Cc: ietf@ietf.org >=20 > Hi IETFers, > We're down to the last week of accepting NomCom volunteers. And I need = more! Lots more! >=20 > I have 64. I'd really like to get another 100 names. Hopefully, some = of you are checking the volunteer box on IETF 108 registration. But I = don't have anything from canceled IETF 107 registration, and the NomCom = question wasn't asked on IETF 106. So I need a flood of volunteers to = come in over the next week. > Barbara > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The IETF NomCom appoints people to fill the open slots on the LLC, = IETF Trust, the IAB, and the IESG. >=20 > Ten voting members for the NomCom are selected in a verifiably random = way from a pool of volunteers. The more volunteers, the better chance we = have of choosing a random yet representative cross section of the IETF = population. >=20 > The details of the operation of the NomCom can be found in BCP 10 (RFC = 8713). RFC 3797 details the selection algorithm. >=20 > Special for this year (and only this year), we also have RFC 8788 = (one-off update to RFC 8713 / BCP 10) to tell us who is eligible to = volunteer: >=20 > Members of the IETF community must have attended at least three = of > the last five in-person IETF meetings in order to volunteer. >=20 > The five meetings are the five most recent in-person meetings = that > ended prior to the date on which the solicitation for NomCom > volunteers was submitted for distribution to the IETF community. > Because no IETF 107 in-person meeting was held, for the 2020-2021 > Nominating Committee those five meetings are IETFs > 102 [Montreal, Canada; July 2018], > 103 [Bangkok, Thailand; November 2018], > 104 [Prague, Czech Republic; March 2019], > 105 [Montreal, Canada; July 2019], and=20 > 106 [Singapore; November 2019]. >=20 > Keep in mind that eligibility is based on in-person attendance at the = five listed meetings. You can check your eligibility at: = https://www.ietf.org/registration/nomcom.py. >=20 > If you qualify, please volunteer. Before you decide to volunteer, = please remember that anyone appointed to this NomCom will not be = considered as a candidate for any of the positions that the 2020 - 2021 = NomCom is responsible for filling. >=20 > People commonly volunteer by ticking the box on IETF registration = forms. The IETF 106 form did not ask whether people were willing to = volunteer. IETF 107 did ask, but all those registrations were canceled. = I have asked the Secretariat if it is possible to get the list if = volunteers from canceled IETF 107 registrations. If that list is = available, I will contact all who are verified as eligible. But given = the uncertainty of this process, I would encourage people to volunteer = directly (see the bottom of this email for instructions). Thank you for = volunteering! >=20 > The list of people and posts whose terms end with the March 2021 IETF = meeting, and thus the positions for which this NomCom is responsible, = are >=20 > IETF Trust: > Joel Halpern >=20 > LLC: > Maja Andjelkovic >=20 > IAB: > Jari Arkko > Jeff Tantsura > Mark Nottingham > Stephen Farrell > Wes Hardaker > Zhenbin Li >=20 > IESG: > Alissa Cooper, IETF Chair/GEN AD > Alvaro Retana, RTG AD > Barry Leiba, ART AD > Deborah Brungard, RTG AD > =C3=89ric Vyncke, INT AD > Magnus Westerlund, TSV AD > Roman Danyliw, SEC AD > Warren Kumari, OPS AD >=20 > All appointments are for 2 years. The Routing area has 3 ADs and the = General area has 1; all other areas have 2 ADs. Thus, all areas (that = have more than one AD) have at least one continuing AD. >=20 > The primary activity for this NomCom will begin in July 2020 and = should be completed in January 2021. The NomCom will have regularly = scheduled conference calls to ensure progress. There will be activities = to collect requirements from the community, review candidate = questionnaires, review feedback from community members about candidates, = and talk to candidates. >=20 > While being a NomCom member does require some time commitment it is = also a very rewarding experience. >=20 > As a member of the NomCom it is very important that you be willing and = able to attend either videoconference or in-person meetings (which may = not happen) during 14-20 November (IETF 109 - Bangkok) to conduct = interviews. Videoconference attendance will be supported whether or not = there are in-person meetings. Orientation and setting of the NomCom = schedule will be done by videoconference during the week 20-24 July = (exact time and date to be determined after NomCom membership is = finalized on July 12), the week prior to IETF 108. Being at IETF 110 = (Prague) is not essential. >=20 > Please volunteer by sending me an email before 23:59 UTC June 24, = 2020, as follows: >=20 > To: nomcom-chair-2020@ietf.org > Subject: NomCom 2020-21 Volunteer >=20 > Please include the following information in the email body: >=20 > Your Full Name:=20 > // as you write it on the IETF registration form >=20 > Current Primary Affiliation: > // Typically what goes in the Company field > // in the IETF Registration Form >=20 > Emails:=20 > // All email addresses used to register for the past 5 IETF meetings > // Preferred email address first >=20 > Telephone:=20 > // For confirmation if selected >=20 > You should expect an email response from me within 5 business days = stating whether or not you are qualified. If you don't receive this = response, please re-send your email with the tag "RESEND"" added to the = subject line. >=20 > If you are not yet sure if you would like to volunteer, please = consider that NomCom members play a very important role in shaping the = leadership of the IETF. Questions by email or voice are welcome. = Volunteering for the NomCom is a great way to contribute to the IETF! >=20 > You can find a detailed timeline on the NomCom web site at: > https://datatracker.ietf.org/nomcom/2020/ >=20 > I will be publishing a more detailed target timetable, as well as = details of the randomness seeds to be used for the RFC 3797 selection = process, within the next few weeks. >=20 > Thank you! >=20 > Barbara Stark > bs7652 at att dot com > nomcom-chair-2020 at ietf dot org >=20 --Apple-Mail=_DB6A67B2-8310-4DA8-8A94-E7AF0BA78180 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In = case you are not on the IETF discuss list.

spt

Begin = forwarded message:

From: = NomCom Chair 2020 <nomcom-chair-2020@ietf.org>
Subject: = Nomcom 2020-2021 = Final Call For Volunteers
Date: = June 18, 2020 at 18:38:42 = EDT
To: = "IETF Announcement List" <ietf-announce@ietf.org>
Cc: ietf@ietf.org

Hi IETFers,
We're= down to the last week of accepting NomCom volunteers. And I need more! = Lots more!

I have 64. I'd really like to = get another 100 names. Hopefully, some of you are checking the volunteer = box on IETF 108 registration. But I don't have anything from canceled = IETF 107 registration, and the NomCom question wasn't asked on IETF 106. = So I need a flood of volunteers to come in over the next week.
Barbara
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DThe IETF NomCom appoints people to fill the open slots on = the LLC, IETF Trust, the IAB, and the IESG.

Ten voting members for the NomCom are selected in a = verifiably random way from a pool of volunteers. The more volunteers, = the better chance we have of choosing a random yet representative cross = section of the IETF population.

The details = of the operation of the NomCom can be found in BCP 10 (RFC 8713). RFC = 3797 details the selection algorithm.

Special= for this year (and only this year), we also have RFC 8788 (one-off = update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer:

     Members of the = IETF community must have attended at least three of
=      the last five in-person IETF meetings in = order to volunteer.

=      The five meetings are the five most recent = in-person meetings that
=      ended prior to the date on which the = solicitation for NomCom
=      volunteers was submitted for distribution = to the IETF community.
=      Because no IETF 107 in-person meeting was = held, for the 2020-2021
=      Nominating Committee those five meetings = are IETFs
       102 = [Montreal, Canada; July 2018],
=        103 [Bangkok, Thailand; = November 2018],
=        104 [Prague, Czech Republic; = March 2019],
=        105 [Montreal, Canada; July = 2019], and
       106 = [Singapore; November 2019].

Keep in mind = that eligibility is based on in-person attendance at the five listed = meetings. You can check your eligibility at: https://www.ietf.org/registration/nomcom.py.

If you qualify, please volunteer. Before you = decide to volunteer, please remember that anyone appointed to this = NomCom will not be considered as a candidate for any of the positions = that the 2020 - 2021 NomCom is responsible for filling.

People commonly volunteer by ticking the box on IETF = registration forms. The IETF 106 form did not ask whether people were = willing to volunteer. IETF 107 did ask, but all those registrations were = canceled. I have asked the Secretariat if it is possible to get the list = if volunteers from canceled IETF 107 registrations. If that list is = available, I will contact all who are verified as eligible. But given = the uncertainty of this process, I would encourage people to volunteer = directly (see the bottom of this email for instructions). Thank you for = volunteering!

The list of people and posts = whose terms end with the March 2021 IETF meeting, and thus the positions = for which this NomCom is responsible, are

IETF Trust:
   Joel Halpern

LLC:
   Maja = Andjelkovic

IAB:
=    Jari Arkko
   Jeff = Tantsura
   Mark Nottingham
=    Stephen Farrell
   Wes = Hardaker
   Zhenbin Li

IESG:
   Alissa Cooper, IETF = Chair/GEN AD
   Alvaro Retana, RTG AD
   Barry Leiba, ART AD
=    Deborah Brungard, RTG AD
=    =C3=89ric Vyncke, INT AD
=    Magnus Westerlund, TSV AD
=    Roman Danyliw, SEC AD
=    Warren Kumari, OPS AD

All = appointments are for 2 years. The Routing area has 3 ADs and the General = area has 1; all other areas have 2 ADs. Thus, all areas (that have more = than one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 = and should be completed in January 2021.  The NomCom will have = regularly scheduled conference calls to ensure progress. There will be = activities to collect requirements from the community, review candidate = questionnaires, review feedback from community members about candidates, = and talk to candidates.

While being a = NomCom member does require some time commitment it is also a very = rewarding experience.

As a member of the = NomCom it is very important that you be willing and able to attend = either videoconference or in-person meetings (which may not happen) = during 14-20 November (IETF 109 - Bangkok) to conduct interviews. = Videoconference attendance will be supported whether or not there are = in-person meetings. Orientation and setting of the NomCom schedule will = be done by videoconference during the week 20-24 July (exact time and = date to be determined after NomCom membership is finalized on July 12), = the week prior to IETF 108.  Being at IETF 110 (Prague) is not = essential.

Please volunteer by sending me = an email before 23:59 UTC June 24, 2020, as follows:

To: nomcom-chair-2020@ietf.org
Subject: NomCom = 2020-21 Volunteer

Please include the = following information in the email body:

Your= Full Name:
   // as you write it on the = IETF registration form

Current Primary = Affiliation:
   // Typically what goes in = the Company field
   // in the IETF = Registration Form

Emails:
=   // All email addresses used to register for the past 5 IETF = meetings
  // Preferred email address first

Telephone:
=    // For confirmation if selected

You should expect an email response from me within 5 business = days stating whether or not you are qualified.  If you don't = receive this response, please re-send your email with the tag "RESEND"" = added to the subject line.

If you are not = yet sure if you would like to volunteer, please consider that NomCom = members play a very important role in shaping the leadership of the = IETF.  Questions by email or voice are welcome. Volunteering for = the NomCom is a great way to contribute to the IETF!

You can find a detailed timeline on the NomCom web site = at:
   https://datatracker.ietf.org/nomcom/2020/
I will be publishing a more detailed target timetable, as = well as details of the randomness seeds to be used for the RFC 3797 = selection process, within the next few weeks.

Thank you!

Barbara Stark
bs7652 at att dot com
nomcom-chair-2020 at ietf = dot org


= --Apple-Mail=_DB6A67B2-8310-4DA8-8A94-E7AF0BA78180--