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