Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward)

Phillip Hallam-Baker <> Thu, 20 February 2014 19:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C558D1A01D6 for <>; Thu, 20 Feb 2014 11:55:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uviJ6-AiYZgf for <>; Thu, 20 Feb 2014 11:55:08 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::236]) by (Postfix) with ESMTP id 9B6311A01FB for <>; Thu, 20 Feb 2014 11:55:07 -0800 (PST)
Received: by with SMTP id y1so1630251lam.41 for <>; Thu, 20 Feb 2014 11:55:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=18qy2Al9lwSBToIHkoZZRB8y6zBdrT184OuBWO+qhtA=; b=Htn4mJvB10W2aIgVpIFDlW3n9gb4oFBdOzujLSzzRmjKRf+v0eDSkvQFBQHj5FK0fK /htj/Me4dq2i++xuBrS4DrAEbTkS8RsfRPHkXIejAFTia8txJs5d0hxsUNLa1KEIm8xM ywi7moLroPMoGIZ1Qv4O2AvSbcuExticQIrZyIlKUi3RWVEt4MsFQ3n4HD0MujZhdKX9 RnyseZPcaFBlhxbhmDJRflvB0YRVmFLa2Ihj9uak4SB1P1ZWHONw3MWc2fLg9JqL8Jt9 df5s/GzIGhoy/YI+O6ytfVvS+NnMhX3CyxIhpYBe6jRURzY4W+KnxksYYdfhNc7gUNHF 9QgQ==
MIME-Version: 1.0
X-Received: by with SMTP id nx8mr2059823lbb.37.1392926103252; Thu, 20 Feb 2014 11:55:03 -0800 (PST)
Received: by with HTTP; Thu, 20 Feb 2014 11:55:03 -0800 (PST)
In-Reply-To: <7B10598788A345A4A13093E4CE09E8A5@codalogic>
References: <> <> <> <> <> <> <> <357740A8AA0F4316BE630917321FAB4D@codalogic> <B1EBE05A69362F001777F807@cyrus.local> <47BB9131737D42218A6382DEF45BBE2C@codalogic> <> <AF211B67DB3D453D9DE8F8FA53886F73@codalogic> <> <FE06CD427A4044B995F57C4926A1C8C2@codalogic> <> <> <7B10598788A345A4A13093E4CE09E8A5@codalogic>
Date: Thu, 20 Feb 2014 14:55:03 -0500
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Pete Cordell <>
Content-Type: multipart/alternative; boundary="047d7b343d6895457f04f2dbe19f"
Cc: Nico Williams <>, JSON WG <>
Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Feb 2014 19:55:11 -0000

On Thu, Feb 20, 2014 at 2:42 PM, Pete Cordell <>wrote:

> ----- Original Message From: "Nico Williams"
>  My position: we should want extensibility, and it should be explicit
>> (because having every type be implicitly extensible is a PITA for code
>> generation).
> What aspect do you find a PITA?  Supporting both implicit extensibility
> and explicit extensibility is surely harder than just supporting implicit
> extensibility?

The elephant in this room is the X.509 CRITICAL flag.

The idea of the critical flag is that if there is a certificate extension
that an RP MUST understand to understand the certificate correctly it can
be marked critical and processors will reject the certificate rather than
accept it and do the wrong thing.

The problem came when people mistakenly interpreted CRITICAL as being
'important' rather than 'so important that if it is not understood you
should break backwards compatibility'.

So right now there is an X.509 extension that the PKIX specification says
MUST be marked critical and the CABForum certificate specification
explicitly states MAY be marked critical or not critical at the discretion
of the issuing CA.

I faced the same problem in the design of TASS which became the SAML
assertion format with only minor changes. Since I knew that I would not get
people to agree to a critical flag I instead introduced an element
<Conditions> and the rule that an RP MUST understand every condition to
rely on the assertion. It is the exact same mechanism but has not created
any problems as far as I know.

So what I would suggest for JSON is that we apply the same approach:

Anyone can add tags into any structure they like and tags that are not
understood are ignored unless the structure is tagged 'Splunge' in the

Splunge can be any word people like except 'Critical'. Right now the
metaschema says splunge.