Re: JFV and Common Structure specifications

Julian Reschke <> Wed, 23 November 2016 17:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCDCC129F0E for <>; Wed, 23 Nov 2016 09:53:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.398
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UAp48so8sJ5x for <>; Wed, 23 Nov 2016 09:53:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BED5B12A24E for <>; Wed, 23 Nov 2016 09:52:43 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c9beT-0007yI-4B for; Wed, 23 Nov 2016 17:48:09 +0000
Resent-Date: Wed, 23 Nov 2016 17:48:09 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c9be9-0007qr-7x for; Wed, 23 Nov 2016 17:47:49 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1c9be1-0007qG-OL for; Wed, 23 Nov 2016 17:47:44 +0000
Received: from [] ([]) by (mrgmx001 []) with ESMTPSA (Nemesis) id 0LpsIh-1cdQ4R3Gcx-00ffU8; Wed, 23 Nov 2016 18:47:00 +0100
To: Mark Nottingham <>, HTTP Working Group <>
References: <>
Cc: Patrick McManus <>
From: Julian Reschke <>
Message-ID: <>
Date: Wed, 23 Nov 2016 18:46:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:AnpfUD2PtmXBk+QQPR+FAQ16SKFTeujQCsGHYGWEET0Rp9E53gD O8ItNdAfbL282EZlqfumdHmst3c7YN/FUL14FPzKQLDOTxjVm09/6hhONTaryuNhK+cWG2H ktZ/xl5z1iNmjMEia0D1VirJwIg9ZlIOFtKj1IEmuj1apBmhyaqpYhZL7/g5bHzJxxQ0pF3 QvtrO+Sg6VJ1mZkXvC+aA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:1HKIw1otBvo=:CF3lbuq4GZRYasQQKcvIE2 ff0i4yunLNFCW/IoxG6iGSbKUvqXGL4pe9pEE4sNF3jcyuyePGWB5WKlY154rSJw6JaMQKXgm 4XBTJ4NNvVNIHcU2TVpFSuFq/OqtgNtv24o/MIw7+tvR2MYNd9W/S90MRXg72K5bRQ1lGeIIf B2Bb1C2WdlPLd0WzSLurMYWZ2p4GE647ai3fweMriBFDIXpRyLAXxB7zqdmfkErspHay4ot6Q ygWpj5YZ6GjyEzH6UGVlin4YOb37x4SWYcFZp9wxuEF5jjr9VvfUKe9+RL1lyEZEVdzzRS/Sf xnhlKBgwqekl5cjhVkmhlvSeyZL5Y4wxa0/ynapXXcOG5SGNHYST+VYD9O5/LQ6thzZvo00mp gFvYnreQdINkbwDeCJ/kQGwUQ17VZlNa0oyeccgVr0Hk0ua8SC9inXAcHa1HHA8HLIxJqtwzP k0dJr3GQiceUk1N5iBB1MN4YiLzA6CbOZ24R5kIlwXV7TCbnjYMbCaPz2T2lZNn7j8ZSpxZpB /wjJExY46iAnmKhocyepWsxhOx35UgqH2N3hnjyi44W+qM83002ZZo7pCUmXJhnsxrcgImN6j 4n5yJdHcyplL8+m7t/Po1kl7ZNWuVgKQZ6jDzbDQQreOrHtWWOfAQVJqqCD/56IJ9tOO91MMq O8NoExSKVE79N7ibAfMzKCoq0UbUlvudxPy3Od/41rEBXG9Go/fMCaSVdZ2t4Iq/ZR71+nfU2 yacvBkmcz/OmRXwZdrG3cxjKgk1ddH5H4coBcj5aDtCdu1Xd3GJSmSpU53UjiKOQ8oVt075rD uHz2J0wVfO8Gvo0FgKJAIglZodJ9g==
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.6
X-W3C-Hub-Spam-Report: AWL=-0.016, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c9be1-0007qG-OL eea410a66df5d5e9cbd205a0418392f0
Subject: Re: JFV and Common Structure specifications
Archived-At: <>
X-Mailing-List: <> archive/latest/32972
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 2016-11-21 03:38, Mark Nottingham wrote:
> In Seoul, we discussed both of these specs:
> Draft minutes:
> The feeling in the room was that we should abandon the JFV draft and adopt the structure draft in its place, with the understanding that it better reflected our current thinking in this area.
> If you have concerns about this, please bring them up on list ASAP; otherwise we'll proceed.

I'm +1 on anything that helps us to improve the current situation.

That said, we need to keep in mind that at least one of the arguments 
brought up against JSON applies to this proposal as well -- if we 
consider the underlying data model to be a dictionary, we'll have to 
figure out what to do when that parameter occurs multiple times.

Things are relatively simple when the parser controls this (it can do 
one of take first/take last/abort), but it'll get harder with streaming 

Best regards, Julian