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.hoffman@xxxxxxxx> wrote:
On May 22, 2013, at 9:14 AM, Phillip Hallam-Baker <hallam@xxxxxxxxx> wrote: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 we can all agree that *A* binary format would be useful and that two dozen are not useful.
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@xxxxxxxx> 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@xxxxxxxxxxxx> 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 orFirst, Proposed Standard is just that: a proposal. It does not
> 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.
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.
No one is circumventing anything. The JSON working group is not
> 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.
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/