> * Will CBOR become the default binary JSON encoding? That would be up to the implementors. If they like it, they will implement it and use it in other protocols. No one is suggesting at this point that there be any specific direction about that -- it's being proposed as one possible tool. > * Will other IETF WGs be expected to adopt CBOR as their binary encoding? Expected by whom? By me? No. By the IESG? No. Whom else are you asking? > * Will you consider publishing alternative binary encodings of JSON? Again, as you asked *me*, I'll take the "you" in the question as referring to me. Of course I will consider that. My criteria will be the same as they are for all requests to sponsor documents: I have to think it's sensible and useful, I have to see reasonable community support for publishing, and a good level of review that convinces me that it meets the guidelines for its intended status. We have to be able to get something that can meaningfully be called IETF consensus. > 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. We actually do that all the time. As I said in my other response, AD-sponsorship is not a fast or easy path for a document, skirting reasonable process by not giving it to a working group. For simple registrations and such, keeping things lightweight makes sense. But for something such as this (or DMARC, which I'm also considering AD-sponsoring), I expect a good deal of support and review -- arguably *more* than we have had with many working group documents. CBOR was discussed quite a bit on the apps-discuss list and is now being discussed on the main IETF list. It doesn't get more open than this. And, I'll repeat what I've said before: there are no "short cuts" being taken here. To the rest of the community: Does anyone else think it is not appropriate to publish CBOR as a Proposed Standard, and see who uses it? > 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. Yes, I see your arguments, and I appreciate them. We need that kind of input. I'll let the authors continue to address your comments as they see they need to. But I'll also ask the rest of the community... To the rest of the community: What is your view of Phill's technical arguments with CBOR? Do you agree that CBOR is flawed? Now, as I see it, a main argument you have, Phill, is that *no* new binary encoding should be proposed as a standard without a working group to study what's there, what's needed, what the goals should be, and what the right approach is to fulfilling those goals. Am I correct? With that model, the answer that your goals are valid but are different to ours... would not be a valid one -- we would have to agree on the goals, and only develop a standard that met that agreement. Am I correct? To the rest of the community: Do you agree with that concern? Do you think such an analysis and selection of common goals, leading to one (or perhaps two) new binary encodings being proposed is what we should be doing? Or is it acceptable to have work such as CBOR proposed without that analysis? Barry