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

"Pete Cordell" <petejson@codalogic.com> Thu, 20 February 2014 21:41 UTC

Return-Path: <petejson@codalogic.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 C16231A0213 for <json@ietfa.amsl.com>; Thu, 20 Feb 2014 13:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.537
X-Spam-Level: ***
X-Spam-Status: No, score=3.537 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=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 VNM0aJujE1fy for <json@ietfa.amsl.com>; Thu, 20 Feb 2014 13:40:58 -0800 (PST)
Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) by ietfa.amsl.com (Postfix) with ESMTP id 4236A1A02F1 for <json@ietf.org>; Thu, 20 Feb 2014 13:40:57 -0800 (PST)
Received: (qmail 23283 invoked from network); 20 Feb 2014 21:39:58 +0000
Received: from host81-155-177-242.range81-155.btcentralplus.com (HELO codalogic) (81.155.177.242) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (RC4-MD5 encrypted, authenticated); 20 Feb 2014 21:39:54 +0000
Message-ID: <8D06B5A0FB0D415C8B5AC2D00B55C658@codalogic>
From: "Pete Cordell" <petejson@codalogic.com>
To: "Phillip Hallam-Baker" <hallam@gmail.com>
X-Unsent: 1
References: <CAMm+LwgQkL--CCwEB7xchdZW1_T2U7cRi0GD2qNDpPkacc9qKg@mail.gmail.com>
X-Vipre-Scanned: 02C51D1400683402C51E61
Date: Thu, 20 Feb 2014 21:40:40 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/json/GLJKwtDlLboYI22aheB0P4SkYVI
Cc: Nico Williams <nico@cryptonector.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] Schema Requirements (Was: Re: Nudging the English-language vs. formalisms discussion forward)
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: Thu, 20 Feb 2014 21:41:01 -0000

----- Original Message From: "Phillip Hallam-Baker"
> On Thu, Feb 20, 2014 at 2:42 PM, Pete Cordell :
>
>> ----- 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'.

Sadly I don't think you can write an RFC to prevent stupid people being 
stupid!

> 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
> schema.
>
> Splunge can be any word people like except 'Critical'. Right now the
> metaschema says splunge.

I like SIP's "Require" header, and have used the scheme in a number of 
protocols.  The advantage is that you can get that basic level of 
compatibility testing out the way in the early stages of processing.  An 
example in a JSON message might be:

    "Require": [ "TLS", "deferal#higson|standard" ]

The other benefit is that can be handled at the protocol design level and 
doesn't impact the schema language!

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com