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