[Wpack] Interaction between MATHMESH and WPACK
Phillip Hallam-Baker <phill@hallambaker.com> Thu, 07 November 2019 20:44 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: wpack@ietfa.amsl.com
Delivered-To: wpack@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A84F120975; Thu, 7 Nov 2019 12:44:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level:
X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=no autolearn_force=no
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 cgf8JItfUOkU; Thu, 7 Nov 2019 12:44:28 -0800 (PST)
Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) (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 D0CD912095E; Thu, 7 Nov 2019 12:44:27 -0800 (PST)
Received: by mail-ot1-f46.google.com with SMTP id z6so3256205otb.2; Thu, 07 Nov 2019 12:44:27 -0800 (PST)
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=Eld5JYuRxwrEWp6DFQ0j6hEMJp8QtGoie15pRJ2KaqI=; b=cVCa4SkvATpJnf1qHUon3dXhsjEox0nh22rGWCcApfwznOnSHDhMd3eNT6IernTYdI IMWGa0pAtVWqqT1HKpNnW+3N4fSyld4wT7sJZe5RILT5z9r1Sp+pl6TXxB5hMHzgaxmB +V5I5FeT5Eal0acG6PUtMi/U+g6/8Crt9qBRX5lhevHARt7gWnXDefIe64HNQoopBm7A XuqAyUFsdc36AzDvVAlyzxkBUiSDLu9nq6Ium83Wto1Vza/Gm/DrpS8YPZYkVRPeiq0D wPV8/bYjqUBVBd6i9XPHD+Vuxk8ffcXV2IBW8zImXkh2OVKp+Mlo0/ONpEOS1EGUVfBx AeUA==
X-Gm-Message-State: APjAAAVGM+4biQ0VK4Ad8tfr7NMcAEzjcWRLNakKWR13eSgkyjADU9FZ 6V8z420o9rtblSYXBvIGYahIvetxAAE0bewamhPlhxRv
X-Google-Smtp-Source: APXvYqyNOsBQAI5EpYIxlpzWRz/NIubVVlhNfNqYoDkCOwK4PG7JdoBRmWxJh6/e+UGFTJcnHrw3FaxUJGzBeodijYw=
X-Received: by 2002:a9d:6b90:: with SMTP id b16mr4865310otq.37.1573159466664; Thu, 07 Nov 2019 12:44:26 -0800 (PST)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 07 Nov 2019 15:44:16 -0500
Message-ID: <CAMm+LwhveTLE0YEW65hZYygBMpX99TOOZSjoeGov8CjKarb3+w@mail.gmail.com>
To: wpack@ietf.org, mathmesh@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002f86870596c7bbe1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/wpack/56J7h-JN6L507mZDkxMUNhSvkvY>
Subject: [Wpack] Interaction between MATHMESH and WPACK
X-BeenThere: wpack@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Web Packaging <wpack.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wpack>, <mailto:wpack-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wpack/>
List-Post: <mailto:wpack@ietf.org>
List-Help: <mailto:wpack-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wpack>, <mailto:wpack-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2019 20:44:29 -0000
Given that we have two BOFs that are considering similar technology proposals, it seems to me that we should consider whether we need to have two new formats or whether one can do both. To that end, I would like to encourage some discussion of these issues prior to Singapore. In particular, I would like to see if a common approach is feasible. Otherwise, the risk is we end up having to support two new formats. Looking at the various WPACK proposals, I can see two possible paths. One is to work out some way to cram what is wanted into ZIP or MHTML. The objective being 'code reuse'. Which is great in theory but only if it is possible to reuse the existing code. Re-use of existing design is considerably less appealing and especially so if we end up needing to do backwards compatibility etc. This also applies to the attempt to reuse parts of HTML. I stopped being active in HTML when we were still trying to move from 1.0 to 1.1. It was already clear that RFC822 header syntax was a major constraint but it was too late to change that decision without a complete redesign. Which we couldn't even get to in HTTP/2 and are only just starting to look at for HTTP/3. WPACK should attempt to hit the target where it is going to be in the future, not where it is now. Some of us have been through signing headers in the world of DKIM. It was necessary but it certainly wasn't at all pleasant. So what I would like to see WPACK do for its own sake even if it is never taken up in the world of HTTP, is to introduce the structured separation of headers into functional units that we wanted in HTTP/1.1 (Simon Spero tried) but couldn't do. In other words instead of Connection: Keep-Alive Content-Type: text/html Date: blah Content-Encoding: gzip We should have had (using JSON for clarity but at the time it was S-expressions being discussed) Connection: Keep-Alive Date: blah Content-Meta { "type":"text/html" "Content-Encoding" : "gzip" } If we had had this type of separation, HTTP/1.1 would have been a lot easier. The protocol headers can and do change in transit. But if the content metadata had been collected together in one place it should actually be unmolested end-to-end unless the content itself had been changed. It does present the material in a form that allows it to be signed. I don't think the choice of JSON or CBOR is particularly consequential. But the browser is going to have a JSON parser which is why I focus on that. Providing a ZIP like capability does not require us to go any further than content metadata. But WPACK potentially requires a bit more as we are not just looking to display the content to the user, we want to push it into their browser cache. And so it is not just the content and associated metadata that are at issue here, it is also the binding of that data to the resource identifier. So what we are looking at is actually something more like: Resource { "uri" : "http://example.com/fred.html" "expires" : "2019-dec-01: blah" "Content-Meta" : { "type":"text/html" "Content-Encoding" : "gzip" } And this could potentially be signed separately in certain contexts.
- [Wpack] Interaction between MATHMESH and WPACK Phillip Hallam-Baker