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(_at_)gmail(_dot_)com>wrote:
On Wed, Aug 7, 2013 at 1:03 AM, Barry Leiba
<barryleiba(_at_)computer(_dot_)org>wrote:
Using the individual submissions track as a way to circumvent working
group
process when there is an actual IETF JSON working group seems completely
wrong to me.
No one is circumventing anything. The JSON working group is not
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/