On Wed, May 27, 2015 at 10:38 AM, Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:
On Tue, May 26, 2015 at 3:50 PM, Carsten Bormann <cabo(_at_)tzi(_dot_)org>
wrote:
For now, CDDL is a good way to discuss the draft, much better than
lobbing around large quantities of ambiguous English prose.
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.