Barry,
Could you please answer the questions I put to you privately:
* Will CBOR become the default binary JSON encoding?
* Will other IETF WGs be expected to adopt CBOR as their binary encoding?
* Will you consider publishing alternative binary encodings of JSON?
I accept that there are circumstances where an individual submission is
appropriate. But I do not think that something that is designed to be built
on by other IETF Working Groups is appropriate for individual submission.
Adding a media type or a PKIX feature or HTTP header are all case where
individual submission to Proposed STANDARD is quite appropriate. CBOR is
not.
The test I think should apply here is the dog food test: Is anyone else
going to be expected to eat the product.
In this case we have a specification that I am likely going to have to
argue against as flawed in every WG which might use it. Which is likely to
mean a lot of unnecessary WG effort, IESG effort and appeals.
Most of us here have experience of using ASN.1, XML and JSON. Most of us
have had a considerable amount of unnecessary pain as a result of ASN.1 and
XML. The Web Services world would probably have taken off much quicker if
there has been some debate and discussion before the decision was taken to
turn XML into the standard for data exchange.
Here we have a situation where you have decided to take a short cut on a
decision that could hardly be more fundamental to the design of network
protocols and handed the whole design process off to two individuals to
make a design decision in private.
For example, take the following messages from the CBOR authors:
On Wed, May 22, 2013 at 12:16 PM, Paul Hoffman
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org>
wrote:
On May 22, 2013, at 9:14 AM, Phillip Hallam-Baker
<hallam(_at_)gmail(_dot_)com>
wrote:
I think we can all agree that *A* binary format would be useful and that
two dozen are not useful.
Nope, that is patently absurd. That would only be true if everyone agreed
on all the design goals and decisions for the one binary format, and that
clearly cannot happen.
I think that one binary format for JSON data structures is an eminently
achievable goal. There is a limited design space, the JSON model covers
almost all necessary data types, the main exception being binary blobs.
At the very most there might be space for one, two or three binary
encodings for use in IETF protocols. But isn't the notion that binary
encodings become like EAP authentication methods and we end up with two
dozen what is really absurd?
On Wed, May 22, 2013 at 6:42 PM, Tony Finch <dot(_at_)dotat(_dot_)at> wrote:
Why not BSON or BJSON or UBJSON or MsgPack or ... ?
I never did see that question answered on the list. To be clear, there are
reasons why I don't think the formats Tony suggests cannot become a
universal standard but those objections also apply to CBOR which also has
the problem of not being based on the JSON data model.
The reason that I don't find putting the reasons in the draft an acceptable
substitute to answering the three people who raised the point is that it
was a cop out. Paul and Carsten gave their design rationale unilaterally
and were not prepared to have their decisions challenged.
Neither Paul nor Carsten have ever been noted for ranting about why XML and
ASN.1 are broken. Which I see as a problem because to do a better job than
those two, you really have to understand why those projects went so badly
wrong.
ASN.1 came very close to getting it right but they only did extensibility
as an afterthought and the way they ended up handling it means that you
can't use ASN.1 without a code writing tool which means that you can't use
it from Perl, Python etc. unless someone has written the tool for those.
XML might have been the solution but the XML design team was charged with
writing a document markup language that could be defined using SGML DTD and
data markup only needs about 5% of the features in XML as a result.
On Wed, Aug 7, 2013 at 4:03 AM, Barry Leiba
<barryleiba(_at_)computer(_dot_)org> wrote:
A couple of procedural points here:
The issue here is whether this proposal should be an IETF Proposed
STANDARD.
...
Usually when the IETF publishes an algorithm it is given INFORMATIONAL or
EXPERIMENTAL status. That is what originally happened with JSON, RFC 4627
has INFORMATIONAL status despite the fact that at the time it was written
there was a lot of implementation.
First, Proposed Standard is just that: a proposal. It does not
require implementations. It requires that it be "generally stable,
has resolved known design choices, is believed to be well-understood,
has received significant community review, and appears to enjoy enough
community interest to be considered valuable." That's from RFC 2026,
Section 4.1.1, which goes on to say, "Usually, neither implementation
nor operational experience is required for the designation of a
specification as a Proposed Standard."
I believe that CBOR qualifies, which is why I agreed to AD-sponsor it.
In the process, I'm looking to see if we have rough consensus that
all this is the case. Your substantive comments on the document, as
well as those of others, should address those points (as some of your
comments indeed do).
Second, RFC 4627 is Informational because it was not meant to be the
standard definition of JSON. It was meant only to register the media
type. But one thing led to another, and it did become the referenced
definition, which is why the JSON working group is working on fixing
its gaps and moving it to Standards Track.
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.
Barry, Applications AD
--
Website: http://hallambaker.com/