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