draft-ietf-httpbis-header-structure-00 for general structured data

Ian Clelland <iclelland@google.com> Thu, 22 December 2016 16:20 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 90625129A95 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 22 Dec 2016 08:20:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fArLMt1s3PzN for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 22 Dec 2016 08:20:46 -0800 (PST)
Received: from frink.w3.org (frink.w3.org []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4AC12954D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 22 Dec 2016 08:20:45 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cK649-0006AI-9l for ietf-http-wg-dist@listhub.w3.org; Thu, 22 Dec 2016 16:18:01 +0000
Resent-Date: Thu, 22 Dec 2016 16:18:01 +0000
Resent-Message-Id: <E1cK649-0006AI-9l@frink.w3.org>
Received: from mimas.w3.org ([]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <iclelland@google.com>) id 1cK641-00069S-4p for ietf-http-wg@listhub.w3.org; Thu, 22 Dec 2016 16:17:53 +0000
Received: from mail-yb0-f175.google.com ([]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <iclelland@google.com>) id 1cK63y-0007HD-Iq for ietf-http-wg@w3.org; Thu, 22 Dec 2016 16:17:52 +0000
Received: by mail-yb0-f175.google.com with SMTP id 84so15244565ybe.3 for <ietf-http-wg@w3.org>; Thu, 22 Dec 2016 08:17:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=fXTRimtOg2vAxUvc7FYtlKbI86XwtwYaVuVxzJERI+M=; b=axvpCA2rakSWHC5lcTWzOLPyNa2t8C9NdVmwENKxKqeAC6zGMd9zwvqLrY7dqglnPD UbiaS7PwG2wMOid4grV39vsloxjyurDMhQ4aJ+5b8CZYmtLIVv0N2hbS+0Vx7JtuOe/V q2yc0Emp6JDbx2KLHipXfVvNzFDVjkgajCRSyGCawBqoTzSqUeKEihQW3bsVcx01nIFh p9F6hL1Byd2/SDIgWgOGj4ldgLvTdAqLhe1WEqPtkPSk60UDXXdTx8/LN34SbQKQLO1n 0ng/Lu8PEBBShOis/NTJnqC6tl6WeYS71HHB2EzOurQXf/wyRCFahd6BIKaKrLxk4d5b Dc9A==
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:cc; bh=fXTRimtOg2vAxUvc7FYtlKbI86XwtwYaVuVxzJERI+M=; b=oXicrwodDBkYoB68b3j53fOMAznOk0OL9gis/1T2Zk5/arnlUsom8+ItJJ/DQFACgv vCasZcUbfoz/b6Cb7Lpxi+xsP6oiEeeqGQgEBufCUPMj9dQQNbuo+rLR8ef/ibutP2tm fvF7npLV0jRlxqo/PCKZ2jhIt67HM2wYIS+li/W72chxBKr7oqbm3Hazidp3VBdtbBq4 UVGQRm227DG9FlxVrWjTpzZSkcCW7Q6sKZzQQJLERn+K71WKU8/UVxsu0YC0h7ymGL8R 6VHBdS33NSvduYpT6h4D+pcUzlDFv+KrJjBzDMMfKDaFsyMn+nHvZlG+P8639Dxzjvzp MaoA==
X-Gm-Message-State: AIkVDXInis5ykuw09CRcXO7kCMNQBAX0L06Mu3ltDRG127jraSN4PjJjQcR1PxX4iT41WVDIWaQ1+nv2gMWSbwMt
X-Received: by with SMTP id d192mr7354034ybh.84.1482423444133; Thu, 22 Dec 2016 08:17:24 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 22 Dec 2016 08:17:03 -0800 (PST)
From: Ian Clelland <iclelland@google.com>
Date: Thu, 22 Dec 2016 11:17:03 -0500
Message-ID: <CAK_TSXLJcDkUCpn5f79DBtnGjjPLtb1fEv_-Akfg4cPbboFVvg@mail.gmail.com>
To: ietf-http-wg@w3.org
Cc: Poul-Henning Kamp <phk@varnish-cache.org>
Content-Type: multipart/alternative; boundary=94eb2c0a876ecbf8340544419a0f
Received-SPF: pass client-ip=; envelope-from=iclelland@google.com; helo=mail-yb0-f175.google.com
X-W3C-Hub-Spam-Status: No, score=-5.7
X-W3C-Hub-Spam-Report: AWL=2.411, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cK63y-0007HD-Iq b6aa8953d2257520b97661b2ffdd57ec
X-Original-To: ietf-http-wg@w3.org
Subject: draft-ietf-httpbis-header-structure-00 for general structured data
Archived-At: <http://www.w3.org/mid/CAK_TSXLJcDkUCpn5f79DBtnGjjPLtb1fEv_-Akfg4cPbboFVvg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33222
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Sorry I'm late to the discussion here; I had previously been looking at
using JFV to design a new application-layer header for declaring feature
policies for HTML documents, and I'm now looking at CS in the same light.

The semantics of the header probably aren't important here; what is
important is that I'm encoding a whitelist of URLs, and associating each
list with a string.

With JFV, I'd declare a policy with a header value like this:

{"feature1": ["http://origin1","http://origin2"]], "feature2": ["
http://origin3"quot;, "http://origin4"], "feature3": []}

With CS, I'm not seeing an elegant way to express the same idea; the lack
of a general way to express a sequence of values in particular makes
representing such a whitelist awkward.

Trying my best to shoehorn this structure into CS, I do notice that nothing
in the grammar or the text says that duplicate identifiers in an
<h1_element> aren't allowed, so I suppose I could write something like this:


(The o= is semantically meaningless here, but appears to be required by the
grammar, as URLs can't be used as identifiers)

It's possible, if a bit awkward, to read this as a dictionary of lists,
where 'feature3' maps to an empty list.

Is this the best I'd be able to do? With the current proposed grammar,
maybe it's just not possible (or not an intended use) to put arbitrary
structure data into a CS header. Maybe the best thing to do is to put the
JSON string into an h1_unicode_string and leave it there.

On the other hand, even without allowing full recursion, it would be useful
to define an alternate production for <h1_value> that allowed a sequence of
other <h1_values> in its place. Without that (though maybe even with it,) I
just can't see using the CS syntax for this application.

Ian Clelland