On Wed, May 27, 2015 at 10:38 AM, Andrew Newton <andy@xxxxxx> wrote:
On Tue, May 26, 2015 at 3:50 PM, Carsten Bormann <cabo@xxxxxxx> wrote:
You and I agree here. I favor whatever it takes to make CDDL a viable normative reference, so long as it doesn't preclude other efforts.
At this point I have schema driven tools for the following encodings:
* RFC822 style headers (works for RFC documented HTTP, SMTP headers)
* RFC821 style command
* JSON
* ASN.1
* TLS
* DNS
* XMLSchema[*]
* Goedel meta-synthesizer
None of these use a syntax that looks remotely like the encodings they target, nor do I find the slightest use for the ASN.1 or XML schema languages. I developed my first encoder after getting fed up of having to edit XML Schema by hand for the SAML 1.0 spec.
Right now only a few of the tools share the same input language but they all look pretty similar except for the DNS parser. JSON is obviously better for highly nested structures than RFC822 but it isn't difficult to subset.
In recent years there has been a trend towards using YANG at the lower levels in the stack and I think that is a good approach at the transport layer down. But the features that make YANG useful at that layer make it less appropriate for the application layer and above where the objective is to make the mapping between the protocol data structures and the implementation data languages as simple and straightforward as possibles.
Right now most JSON Web Services are layered on top of HTTP which means that we have the following encodings involved:
RFC821 [Method line]
RFC822 [Headers]
MIME-ish [Chunked Encoding]
JSON [Payload]
And that is going to be where a large fraction of Web Services are going to be for the next couple of decades. But the fact is that we can convert the entire stack into JSON without any change to the semantics. And if we use JSON-B or JSON-C we get improved efficiency as well.
One of the odd features of Web Services is that even though we have to do all that implementation work above, almost none of it provides any payoff from an architectural point of view. Yes 'in theory' it is possible to route HTTP messages as if they are multiparty transactions and this is what SOAP tried to support. But the cost of making that work was to insert a whole new framing layer for SOAP which made the HTTP layer redundant.
If we get the DNS client-resolver link fixed so it is practical to make multiple requests in one round trip request, it is a simple matter to define a DNS record that says 'this Web Service available over the HTTP binding and the J-Binding using encoding X'
Note however that people who write and deploy Web services are not going to support two syntaxes for the same protocol and thus make a transition strategy possible unless providing support for the two stacks is completely transparent and automatic.
What I am getting to here is that if we want to have a cleaner, simpler Internet some time in the future, we should be looking at approaches that allow us to remove the unnecessary variations in encoding at some point. We really should be looking at ways to reduce the number of encodings, not varying them to no benefit.