Re: JFV and Common Structure specifications
"Poul-Henning Kamp" <phk@phk.freebsd.dk> Tue, 22 November 2016 09:57 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 [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 392F0129CE6
for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>;
Tue, 22 Nov 2016 01:57:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level:
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001,
RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=ham 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 b8VdBWonAqOL
for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>;
Tue, 22 Nov 2016 01:57:11 -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 0A6C2129CEB
for <httpbisa-archive-bis2Juki@lists.ietf.org>;
Tue, 22 Nov 2016 01:57:10 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80)
(envelope-from <ietf-http-wg-request@listhub.w3.org>)
id 1c97kK-0000zz-Ce
for ietf-http-wg-dist@listhub.w3.org; Tue, 22 Nov 2016 09:52:12 +0000
Resent-Date: Tue, 22 Nov 2016 09:52:12 +0000
Resent-Message-Id: <E1c97kK-0000zz-Ce@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79])
by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128)
(Exim 4.80) (envelope-from <phk@phk.freebsd.dk>) id 1c97kE-0000xm-5g
for ietf-http-wg@listhub.w3.org; Tue, 22 Nov 2016 09:52:06 +0000
Received: from phk.freebsd.dk ([130.225.244.222])
by mimas.w3.org with esmtp (Exim 4.84_2)
(envelope-from <phk@phk.freebsd.dk>) id 1c97k8-0002g6-2L
for ietf-http-wg@w3.org; Tue, 22 Nov 2016 09:52:00 +0000
Received: from critter.freebsd.dk (unknown [192.168.55.3])
by phk.freebsd.dk (Postfix) with ESMTP id 495B02738B;
Tue, 22 Nov 2016 09:51:36 +0000 (UTC)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id uAM9pZOY065744;
Tue, 22 Nov 2016 09:51:35 GMT (envelope-from phk@phk.freebsd.dk)
To: Mark Nottingham <mnot@mnot.net>
cc: Martin Thomson <martin.thomson@gmail.com>,
HTTP Working Group <ietf-http-wg@w3.org>,
Patrick McManus <mcmanus@ducksong.com>
In-reply-to: <E5207840-A825-43B5-B42F-6C56314EA703@mnot.net>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
References: <3A206EA7-57FB-4913-BC08-445BD2EFA783@mnot.net>
<CABkgnnV8=2_sR-B-6e9Haxi+4M4DF4V7f3CWCVvXDHNN_SkTKw@mail.gmail.com>
<98329.1479720181@critter.freebsd.dk>
<CABkgnnVqH6TPi0OJ5iecYBj2gRich+DMLnxxQJcw9Qn6n-JPBA@mail.gmail.com>
<65242.1479800991@critter.freebsd.dk>
<E5207840-A825-43B5-B42F-6C56314EA703@mnot.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <65742.1479808295.1@critter.freebsd.dk>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 22 Nov 2016 09:51:35 +0000
Message-ID: <65743.1479808295@critter.freebsd.dk>
Received-SPF: none client-ip=130.225.244.222; envelope-from=phk@phk.freebsd.dk;
helo=phk.freebsd.dk
X-W3C-Hub-Spam-Status: No, score=-6.8
X-W3C-Hub-Spam-Report: AWL=0.063, BAYES_00=-1.9, RP_MATCHES_RCVD=-2.999,
W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c97k8-0002g6-2L 770cb712576d8bf161a66d502b543315
X-Original-To: ietf-http-wg@w3.org
Subject: Re: JFV and Common Structure specifications
Archived-At: <http://www.w3.org/mid/65743.1479808295@critter.freebsd.dk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32957
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>
-------- In message <E5207840-A825-43B5-B42F-6C56314EA703@mnot.net>et>, Mark Nottingham writes: >Adding features like recursion has a real cost in complexity, cognitive >load, bugs and security. All of these things add friction to a standard, >and can make or break it. That's not to say that we shouldn't do it, but >dismissing these concerns with a catchphrase isn't going to be >sufficient (at least for me). I would hope not! But I still think it is a very important distinction to make when we are talking about a general purpose data structure. The inspiration for my CS analysis was your own complaint about needing a dozen bespoke parsers. I am just trying to replace one more parser than you were thinking about, when you said that. Some people want to pass a MYPRIV: header with a dictionary of dictionaries of lists from one side of their web-app to the other, and that is their choice. Our opinion and policies does not, should not and will not count. Today we see people resort to base64(JSON) or even base64(gzip(JSON)) to scratch that itch, both of which rob us of the chance to improve serialization efficiency. If we make CS, *as a data structure*, support general depth, they will have the choice of using that instead, and if we do our job right, HPACKng/H3 will do a better job moving their data. If we are really lucky, somebody will write a JS and PHP package, give it a fancy name and people will start using that instead. But giving CS that generality does not mean we have to use it ourselves. As I have said repeatedly, I am totally down with a severe restriction, or preferably outright ban, on recursion in the HTTP headers we put into IETF documents. But I see absolutely no advantages for us or anybody else, in trying to impose that policy on everybody else, by delivering CS as a less capable tool[1]. > E.g., given that headers themselves are constrained (effectively, >a list of tuples with semantics around combination, naming, etc.), >should we remove the "policy" from them and make it a bucket of >bytes? Or is that too focused on a policy of byte-based computing? I sort of tried to push for something like that during the rush to H2, but back then there seemed to be no appetite for it. I would far prefer if a HTTP message consisted of four onion layers instead of just header/body like today: 1. Routing information (Host/authority, URL up to '?' and session-id) All load-balancers will need to look at. 2. Transport headers (I-M-S, Vary, Range, Content-Encoding, Transport-Encoding) Endpoints and proxies also needs these 3. End-to-end metadata (Content-Type, Cookies, MYPRIV: from above) Application only 4. End-to-end data (the message body) Applications only (In that model: No CS-recursion in layer 2, free for all in 3.) >Adding features like recursion has a real cost in complexity, >cognitive load, bugs and security. Absolutely true. But if by being more general and usable you can prevent having to have two standards to pay attention to, the net benefit is very big. Poul-Henning [1] In my very extensive study of computing history, I have _never_ found an instance where that strategy worked for anybody, and computing today is litered with examples of the opposite: C++ vs C, PHP vs Perl, AMD64 architecture vs Itanic, GPL/GCC vs CLANG, and so on. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
- JFV and Common Structure specifications Mark Nottingham
- Re: JFV and Common Structure specifications Martin Thomson
- Re: JFV and Common Structure specifications Poul-Henning Kamp
- Re: JFV and Common Structure specifications Martin Thomson
- Re: JFV and Common Structure specifications Poul-Henning Kamp
- Re: JFV and Common Structure specifications Mark Nottingham
- Re: JFV and Common Structure specifications Poul-Henning Kamp
- Re: JFV and Common Structure specifications Martin Thomson
- Re: JFV and Common Structure specifications Matthew Kerwin
- Re: JFV and Common Structure specifications Poul-Henning Kamp
- Re: JFV and Common Structure specifications Julian Reschke
- Re: JFV and Common Structure specifications Poul-Henning Kamp
- Re: JFV and Common Structure specifications Julian Reschke
- Re: JFV and Common Structure specifications Poul-Henning Kamp
- Re: JFV and Common Structure specifications Mark Nottingham
- Re: JFV and Common Structure specifications Mark Nottingham