Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter

Phillip Hallam-Baker <hallam@gmail.com> Sat, 15 March 2014 00:30 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A149D1A012A for <json@ietfa.amsl.com>; Fri, 14 Mar 2014 17:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ejKRO5AM7tLl for <json@ietfa.amsl.com>; Fri, 14 Mar 2014 17:30:44 -0700 (PDT)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 65D3D1A0121 for <json@ietf.org>; Fri, 14 Mar 2014 17:30:44 -0700 (PDT)
Received: by mail-qg0-f44.google.com with SMTP id a108so9542031qge.3 for <json@ietf.org>; Fri, 14 Mar 2014 17:30:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NlnkaCsreGtd8rseebFr5lWPA3Z1zaLapPcPVuj+zr8=; b=06g0BoE5i7LFiTwW2Uk+npD1/owGaUCkOJPw/YDH/N9vkWPivxfmqJhaRs9STvlu+x wYOfvPHEXp4AjaA1nabm0MrZUx46i2GrE3j82nMHpQfa5G8fPHpR0/6aCt2PTPra3aV8 iFsxqNwKinnjm0IowpjYOYez1OiZ2SWAhDHKYq8a8GhV2mGrf+a/0f4+niWgI9akpa+q D006aLaOCKtWOBb5HjQN5lW4COi/kbnxNdPbqM9QS6YmdeOmux4qpSzaY/M5n+Zis8sB 9N/UKVWGMnigXeDF1er3/l1a4ILNrQRA3u4BqExvExvv1897c9Li5SmK7oQKrm5YyWs+ WqnQ==
MIME-Version: 1.0
X-Received: by 10.224.131.193 with SMTP id y1mr13284677qas.86.1394843437273; Fri, 14 Mar 2014 17:30:37 -0700 (PDT)
Received: by 10.140.96.107 with HTTP; Fri, 14 Mar 2014 17:30:37 -0700 (PDT)
In-Reply-To: <CAHBU6itv0q7ZTrran+dKTcUxoSxNHYnND7yLmSPF35--iUMA+w@mail.gmail.com>
References: <53238F2E.5010105@cisco.com> <CAHBU6itv0q7ZTrran+dKTcUxoSxNHYnND7yLmSPF35--iUMA+w@mail.gmail.com>
Date: Fri, 14 Mar 2014 20:30:37 -0400
Message-ID: <CAMm+Lwi6Ha0r55vb3VNsgz40Bds6HYZ-aM9u-JwyVmoRDuZaWw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: multipart/alternative; boundary="047d7b676c3c98992504f49a4b18"
Archived-At: http://mailarchive.ietf.org/arch/msg/json/JkwxpzXe2XgUmMOfcYh8aHf7E_U
Cc: IETF JSON WG <json@ietf.org>, Matt Miller <mamille2@cisco.com>
Subject: Re: [Json] Call for WG Consensus on Whether or Not to Adopt Nomenclature Document(s) in the Charter
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Mar 2014 00:30:46 -0000

On Fri, Mar 14, 2014 at 7:27 PM, Tim Bray <tbray@textuality.com> wrote:

> I'm generally opposed to this work item on the basis that nobody has
> provided an example of an existing RFC that would clearly be improved by
> the availability of such a thing.
>

I think RFC 6962 could be improved substantially with some greater
adherence to some structure.

Like many JSON Web services, message data is split between the message
contents and the URL.

More importantly, I would like to kill all the parts of the document that
specify the TLS data format (using a schema) and replace them with JSON
structures. But that isn't going to be possible without a better way to
define structures.

I don't think it is just a JSON issue though. While implementing TRANS I
added support for the TLV format to the parser. I have not yet added it to
any of the encoder or decoder libraries though.

It is pretty clear that the proposers of CT are only interested in
addressing notary services for the certificate application and so they are
obsessed with size and compactness. Which is fine. But I certainly don't
wish to carry that data encoding into any other notary application. So
being able to write a schema that allows the data structures to be rendered
in the legacy TLS encoding and in JSON becomes quite important.


-- 
Website: http://hallambaker.com/