Abbreviation form for HTTP JSON Header Field Values?
Kazuho Oku <kazuhooku@gmail.com> Fri, 22 January 2016 07:32 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 (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3F1AC3E3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 21 Jan 2016 23:32:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.003
X-Spam-Level:
X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 jzM1kVTLiJRZ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 21 Jan 2016 23:32:42 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2E91AC3E2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 21 Jan 2016 23:32:42 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aMW8l-0000V5-Ja for ietf-http-wg-dist@listhub.w3.org; Fri, 22 Jan 2016 07:28:15 +0000
Resent-Date: Fri, 22 Jan 2016 07:28:15 +0000
Resent-Message-Id: <E1aMW8l-0000V5-Ja@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1aMW8d-0000UK-Uw for ietf-http-wg@listhub.w3.org; Fri, 22 Jan 2016 07:28:07 +0000
Received: from mail-wm0-f42.google.com ([74.125.82.42]) by maggie.w3.org with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1aMW8b-0008GQ-3z for ietf-http-wg@w3.org; Fri, 22 Jan 2016 07:28:07 +0000
Received: by mail-wm0-f42.google.com with SMTP id l65so249337098wmf.1 for <ietf-http-wg@w3.org>; Thu, 21 Jan 2016 23:27:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=g55Fp6mH/s/Tb8JgGv8mG9+CgzQ7oRsixgmnUOr/jQw=; b=cax2+y93U5kOdnEuU8fgJyGDSv+5rIXeSQgXvZDIuTC3mfOQw+WpTlQngS2NA3Mwxn Ycib+BiBIfZewxuWbxjduAWSJ9wiR6ftTS3odn1LZhkpgjX/mTbtrAyfxs7TOTnvrsbU eW33SwydteLA4yc2Bixvv1BRvmIyc80OiUzXbxAHlTURZMo0TjfbtCI8EZQ+KyGZXOgd BCJDi3kzC4bzmyL9Y1NO5mH9JHYxgABipnZXNZ+5HGdVOfNwL/9EN9A6lW8R4adWyplD TUkRgjnGhatgeC2XezJnM/AXxyHtSk7mJ5tts/cuwSL/B7wtEqGooU5TqUZo5aSeH5Gs bFcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=g55Fp6mH/s/Tb8JgGv8mG9+CgzQ7oRsixgmnUOr/jQw=; b=PsYQV7bq1mVAnol6C3+pHsVRRM/owjCEpo2X8RbZikxOxpU0Jg+8umjdmZ3sFvcOIO fAyNjY01hPeZ/I7dTJynEpYVKHDhvpVAk77k5HNePZK3UgsEHmVSY9H56dMvBsIQd+7j ZuPJ97vPbcx1yMOh9T/CbJ7KqQyXFa71H3cKC5kKFTsnQGtBrqshgzdh6/NnEjBOqVUU BH9OQW7GqY6xjhxRCSGrdzfHrhp+TRKPXqWR+mTKoPFryhR0YmjHtSA9Iw6anyMRzkDo Wpxt2mSrDhBIwrYtb0BoMldcilNCO0Y9AQ8G5x3SAttFcEZ8H2H2gxdFoGCZIbYCe2Iy hn6A==
X-Gm-Message-State: AG10YORAYZ0eNkLege6RWJcCYnzPvqoCSGUezkMEjepXtjcFhw52/zmeY58ISx1j1HsJTX9PpgvgmTsY+714aQ==
MIME-Version: 1.0
X-Received: by 10.28.172.193 with SMTP id v184mr1982431wme.94.1453447658453; Thu, 21 Jan 2016 23:27:38 -0800 (PST)
Received: by 10.194.235.163 with HTTP; Thu, 21 Jan 2016 23:27:38 -0800 (PST)
Date: Fri, 22 Jan 2016 16:27:38 +0900
Message-ID: <CANatvzwXfz5vYi-QAdExuQJTAa5zyXE5CTQ7WgHy1RgUn-StzA@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Stefan Eissing <stefan.eissing@greenbytes.de>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=74.125.82.42; envelope-from=kazuhooku@gmail.com; helo=mail-wm0-f42.google.com
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.817, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1aMW8b-0008GQ-3z dea73164f21a688997e06049a6de25a3
X-Original-To: ietf-http-wg@w3.org
Subject: Abbreviation form for HTTP JSON Header Field Values?
Archived-At: <http://www.w3.org/mid/CANatvzwXfz5vYi-QAdExuQJTAa5zyXE5CTQ7WgHy1RgUn-StzA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/30995
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>
Dear Mr. Julian F. Reschke, Thank you for writing the HTTP JFV draft. I love the concept, and would love to see it being used in all the future header definitions once the JFV draft gets standardized. And regarding the draft, is there any work to introduce abbreviation form? I assume the biggest argument against JFV is that it cannot encode simple things (i.e. objects mostly conveying default values) as simple as in case we use tailor-made ABNF to define the syntax, and think that having an abbreviation form defined in JFV (either as a requirement or as an optional feature) will be a good thing to do. Specifically, I would like to see the following transformations defined: * rule 1) a single-element hash MAY be transformed to the value of the single element if all of the following conditions are met: * the semantics state that the element is the only required element * the type of the element is not a hash * rule 2) a single-element array MAY be represented with the single element if the following condition is met: * the type of the element is not an array With the rules, I believe it is possible reduce the redundancy imposed by using JSON, while preserving the good aspects of JFV. In the rest of the document, I will describe what made me believe such abbreviation form should be defined and the impact on the decoder for having the abbrevation form defined within the spec. Examples using popular HTTP headers are also provided. My Use-Case --- The reason I would like to see abbreviation forms in JFV comes from the discussion with Stefan on how to define the `cache-digest` header. Now, the disagreement between Stefan and me (please refer to https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0154.html) is whether if we should encode a required component (in our case, the digest value) outside of the attribute key-value pairs (option A), or if we should define the component as a required element of the attributes (option B). Examples below show the headers encoded using the two options. Each three semantically corresponds to the other three. ``` Option A: cache-digest: base64encodedgcs cache-digest: base64encodedgcs; path="/foo" cache-digest: base64encodedgcs; path="/foo", anothergcs; path="/foo"; type="if-modified-since" Option B: cache-digest: fresh="base64encodedgcs" cache-digest: fresh="base64encodedgcs"; path="/foo" cache-digest: fresh="base64encodedgcs"; if-modified-since="anothergcs"; path="/foo" ``` As is shown in the examples, in the case of `cache-digest` header, option A yields a more concise output in simple cases, while option B yields smaller output in complex cases due to the fact that it is possible to contain more than one GCS in a single set of atttributes. In other words, this is a trade-off issue; and per my understanding the current draft of JFV does not address the problem. The draft always enforces the use of key-value pairs in this case. Therefore, I anticipate that in the future we might see similiar arguments for not using JFV when we are to define a new header. Going back to the case of cache-digest header, ideally I would like see the entry of the header to have the following characteristics: * a cache-digest entry conveys one or more digests, together with attributes that limit the scope of the contained digest (e.g. domain, path) * a digest is a base64-encoded bit-field of various algorithms (e.g. GCS, Bloom filter), representing cache resources that fall into certain category (e.g. fresh, stale-with-if-modified-since-header) And the characteristics lead to a header like the following when JFV is used, which look even more redundant for the simple cases. ``` cache-digest: { "digest" : [ { "value" : "base64encodedgcs" }, // omitted defaults: category=fresh, encoding=gcs ] } cache-digest: { "digest" : [ { "value" : "base64encodedgcs" }, // omitted defaults: category=fresh, encoding=gcs ], "path" : "/foo" } cache-digest: { "digest" : [ { "value" : "base64encodedgcs" }, // omitted defaults: category=fresh, encoding=gcs { "value" : "anothergcs", category="if-modified-since" } // omitted defaults: encoding=gcs ], "path" : "/foo" } ``` But if the aforementioned transformations were permitted within the JFV spec, the headers will become much simpler with the transformations applied: ``` cache-digest: "base64encodedgcs" cache-digest: { "digest": "base64encodedgcs", "path" : "/foo" } cache-digest: { "digest": [ "base64encodedgcs", { "value" : "anothergcs", category="if-modified-since" } "path" : "/foo" } ``` In this example, the transformations yield a header representation comparable to tailor-made ABNF (option A) for the simplest cases (as shown in the first of the three headers). Impact on the Decoding-side --- Now that it has been shown that (at least in our case) defining the transformations yield to a more concise output for simple use-cases, let's move on to consider how large the impact of implementing such transformations will be on the decoding-side. Actually, the application-specific part of the decoder does not become complex at all by adding support for the abbreviation form. This is because the reverse transformations can be implemented at the points where type checks were performed. All the thing that the decoder needs to do for supporting the abbreviation form is to convert the value to the non-abbreviated type if it is not, instead of throwing a decoding error. As an example, the diff that adds support for the abbreviation form to the decoder that handles the previously-defined cache-digest header can be found at https://gist.github.com/kazuho/c84fa23b26c606e55533/revisions#diff-b071c075a9788be737d99e9159092db8. Other Examples --- Consider using JFV for encoding the `Content-Type` header. Without abbreviation form, it would look like: Content-Type: { "type": "text/html" } Content-Type: { "type": "text/html", "charset": "utf-8" } With the abbrevation form, it can be like: Content-Type: "text/html" Content-Type: { "type": "text/html", "charset": "utf-8" } Consider using JFV for encoding the `Accept-Encoding` header. Without abbreviation form, it would look like: Accept-Encoding: { "encoding": "compress" }, { "encoding": "gzip" } Accept-Encoding: { "encoding": "gzip" }, { "encoding": "identity", "q": 0.5 }, { "encoding": "*", "q": 0 } With the abbreviation form, it can be like: Accept-Encoding: "compress", "gzip" Accept-Encoding: "gzip", { "encoding": "identity", "q": 0.5 }, { "encoding": "*", "q": 0 } As can be seen from the examples, if we support abbreviation form in JFV it is possible to encode simple headers as simple as they are now. Conclusion --- Please consider supporting some kind of abbreviation form in JFV; I believe that it would make JFV more attractive to the users, since with abbreviation it is possible to offer both simplicity (for simple cases) and extensibility (of JSON) at the same time. -- Kazuho Oku
- Re: Abbreviation form for HTTP JSON Header Field … Kazuho Oku
- Re: Abbreviation form for HTTP JSON Header Field … Poul-Henning Kamp
- Re: Abbreviation form for HTTP JSON Header Field … Carsten Bormann
- Re: Abbreviation form for HTTP JSON Header Field … Martin Thomson
- Abbreviation form for HTTP JSON Header Field Valu… Kazuho Oku
- Re: Abbreviation form for HTTP JSON Header Field … Julian Reschke
- Re: Abbreviation form for HTTP JSON Header Field … Kazuho Oku
- Re: Abbreviation form for HTTP JSON Header Field … Julian Reschke
- Re: Abbreviation form for HTTP JSON Header Field … Julian Reschke