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

["Pete Cordell" <[e-mail]>]

----- 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