On 8/10/13 5:00 PM, Dave Crocker wrote: > > One of the reasons we find groups choosing to avoid the IETF's > standards process is its unpredictability. Our processes must be stable, but people have different reasons for articulating concern. 2026 is not meant to be the singular criteria. In fact we have for a long time accepted the additional questions that form a working group, as well. And unpredictability is part and parcel of standards activity: you can't buy a standard at the IETF, which is what predictability implies, if taken to extremes. And people not familiar with the IETF often take it to extremes. A perfect example was Tim Berners-Lee who wanted to standardize HTML, but didn't want to give up control of the specification. It just doesn't work that way. Now that we're done with generalities, I'll just chime in and say that the spec in question seems perfectly fine to advance as a Proposed Standard. I do wonder whether CBOR is better than compressed JSON, but I understand that in this context CPU may be a limiting factor. There is an architectural question hiding here: when we use CBOR in various protocols, we may be optimizing for the wrong set of devices overall. Conversely, we may be optimizing for just the right devices since the so-called Internet of Things that are low end devices will outnumber other devices. Which is it? Either way, it seems to me we can't answer without CBOR or something like it, so... let's have it, then. Eliot