The point is that there would BE discussion. Consensus is not enough, the process has to be open. A consensus formed by keeping people out of the room is no consensus at all.
Though if the discussion was of the form 'this was already decided' then that effort would be a farce as well.
What we need for 90% of IETF specifications is nothing more than an easy way to extend JSON to encode binary blobs without BASE64 encoding. Just that, nothing more. Instead we have a reinvention of ASN.1 without a schema.
When I say nothing more, I don't mean the rest would be 'nice to have' or harmless, I mean that it is positively harmful.
I want to be able to mix binary and text forms of the JSON encoding in the same object. For example, we have part A that collects JSON datagrams from B and C and puts a wrapper round them. This is a very common requirement in a network protocol (and one of the things that XML was meant to do but is horrible at). If we can mix and match Text/Binary JSON this is very simple, the packager can just include the input from B and C into its output stream as opaque blobs without having to decide whether to convert them to make the inner format compatible with the outer wrapper or each other.
The way that we normally decide issues as important as a data encoding format is to have an open competition where multiple proposals can be made by anyone with an idea. That is how W3C managed the binary encoding of XML and how the HTTP 2.0 compression issue is being addressed. The process for CBOR has been that Carsten writes a spec and then Paul Hoffman acts as Czar deciding which requirements are to go in it.
At any rate, I have an open source tool on source forge now that generates an Internet Draft, Examples and sample code from a simple abstract schema. It currently uses JSON coding but I will be adding a binary encoding, hence my interest.
I would be happy to add an IETF Proposed Standard binary encoding that had been the result of an open process.
On Wed, Aug 7, 2013 at 4:28 AM, Murray S. Kucherawy <superuser@xxxxxxxxx> wrote:
On Wed, Aug 7, 2013 at 1:03 AM, Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote:
> Using the individual submissions track as a way to circumvent working group> process when there is an actual IETF JSON working group seems completelyNo one is circumventing anything. The JSON working group is not
> wrong to me.
chartered to deal with this or other documents like it, and we won't
be rechartering it to do so any time soon. And remember that any time
I'm sponsoring a document as AD, part of what I'm doing is what
working group chairs do in a working group: judging rough consensus on
the document's content and the issues that concern whether it's
intended status is appropriate. If you (and/or others) can show that
there are solid reasons that this should not be a Proposed Standard,
or if I do not see rough consensus to publish it, I will not bring it
to the rest of the IESG.
I would add that CBOR has already seen enough interest and feedback that I believe it would pass a call for adoption in APPSAWG, and be processed there onto the standards track. That would make Barry's job quite a bit easier, since it would then be our job to host the discussion and record consensus in that context. It would also get a shorter IETF Last Call.
Instead, it's going what is for all intents and purposes a tougher route. I'm not suggesting we derail its progress to do it the other way, but it does suggest to me that the route it's following is hardly a shortcut or bypass of some kind.
-MSK
Website: http://hallambaker.com/