During the November IETF meeting, I received an appeal from Phillip
Hallam-Baker to the publication of CBOR, RFC 7049, on the Standards
Track. (Procedural note: The appeal was, at this point, to me as the
responsible AD, and has not gone to the IESG.) Phill is questioning
the process; specifically, Phill's appeal is as follows:
-------------------------- start --------------------------
My issue here is more than a preference for one encoding over another,
the manner in which CBOR was made a standard has negated the value of
having it being proposed as a standard.
There are already five JSON in binary encodings in widespread use.
CBOR offers no particular advantages over any of the existing schemes
and the authors have never been willing to explain why a different
encoding is desirable.
An IETF standard would have had the advantage of being a single choice
that people could use but only if it was capable of meeting all the
requirements that might be raised and only if it was genuinely
supported by IETF consensus.
Using the individual submission process to shortcut the process
suggests that you don't consider the technical differences between
encodings very important. An encoding is a foundational piece f work
that requires an open process because other people are going to be
building on it.
- CBOR is more complex than JSON and introduces a different data
model. It reintroduces features such as definite/indefinite length
encodings that have already been found to be defective in ASN.1.
- CBOR is an alternative to JSON encoding and not as many people
supported on the APPs list, a simple extension that adds in the
functionality of length delimited strings and binary blobs.
- CBOR does not support compression of tags or strings and there is no
way in which it can be extended to support this capability. It can
however be extended to support new intrinsic types such as a new type
of integer or float. Which is precisely the type of extensibility JSON
rejects.
Had there been an open process, those of us who had requirements and
code that depended on the requirements could have raised them and
there would have been a possibility of a single output from the work.
Instead CBOR does nothing to address the problem of multiple encoding
options and only adds another option on the table.
--------------------------- end ---------------------------
I've taken an unusually long time to resolve this, and for that delay
I apologize and appreciate Phill's patience on -- his appeal did come
in within the two-month appeal window after the approval announcement.
As I evaluated the appeal, I reviewed every message in the discussion
threads. In the end, my conclusion is that I support the appeal. I
think that Phill is right that we should have had open discussion of
the design criteria before considering a specific proposal for an
encoding. The result of not having done that was that we approved an
encoding scheme that meets certain use cases and design goals, without
having first discussed what use cases and design goals the community
might want to have covered.
I think it's important for ADs to consider, when deciding to sponsor
non-working-group documents, whether a broader design discussion is
appropriate. I believe that I made a mistake in not considering that
for this case.
As to a remedy, I do not see that changing the status of RFC 7049 --
for example, moving it from Standards Track to Experimental -- would
be in the best interest of the IETF at this point. CBOR had a good
deal of interest when it was proposed, and that interest has continued
and is resulting in implementations (see http://cbor.io/impls.html for
one list of what's going on with respect to CBOR implementations). A
change to RFC 7049 now would not likely change anything, and would
result in time wasted in moving it back to Standards Track at a
suitable time.
I thank Phill for persisting in pointing out what I missed, and I
intend to consider this more strongly in future decisions about
sponsoring potential standards.
Barry, Applications AD