On Fri, Aug 9, 2013 at 2:52 PM, Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote:
> * 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.
Expected by whom? By me? No. By the IESG? No. Whom else are you asking?
> * Will other IETF WGs be expected to adopt CBOR as their binary encoding?
Actually I just want it in writing because my past experience of a similar platform type spec was that it was just another option for developers right up to the point where it was published when I found myself in a BOF where the members were being told that they 'had' to use the IETF platform for their work because that is what had been 'decided'.
Understand here that I am not accusing you Barry of doing that but you won't be AD forever.
> * 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.
During the discussions there was a clear subset who wanted to have JSON plus length encoded binary blobs/unicode strings as opposed to CBOR. Would publication of CBOR as a proposed standard make it less likely that such a proposal would be acceptable to you?
> I accept that there are circumstances where an individual submission isWe actually do that all the time. As I said in my other response,
> 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.
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.
I don't see DMARC as being the same as CBOR.
DMARC is primarily a mechanism that has standalone value that is built on top of S/MIME. CBOR is a proposal that has no value unless other people choose to build on top of it.
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.
The proposers have maintained full proprietary control of the spec at all times. They are the only arbiters of what they consider to be the appropriate design goals. I don't consider the opportunity to state my complaints to be participation.
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?
I think that nothing should be described as an IETF Proposed STANDARD unless the IETF proposes to use it. I know that the process document is loosey-goosey on this but I think that until someone takes CBOR and uses it as a part of a mousetrap that it isn't going to be an IETF proposed standard regardless of what it says on the RFC.
Publishing a fully specified but untried proposal as EXPERIMENTAL would seem to me to be exactly the right course for this type of thing. It is what we are currently doing in HTTP Authentication mechanisms. If any get traction they can be promoted to Proposed Standard.
I think that the bar to getting something published as a static document should be pretty low. But the bar for standards track is a little different.
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?
I think that the design goals have to be decided with respect to use cases. I have use cases driven by running code. I don't know what the use cases are that drive the CBOR design requirements. All I know is that whenever a proposal is made that Carsten and Paul don't like their response is 'that is not one of our design goals'.
It might well be that there is a need for more than one binary encoding. It is possible that my desire to have a binary encoding that can be formally shown to be equivalent to JSON is not what people want. It might be that people really do want to have a binary encoding that has the rich type system of CBOR. There might even be more niches that need to be filled.
But my preferred process would be this
1) Publish any proposal that is fully described as Experimental
2) Wait
3) When the first WG that is going to use a binary encoding of JSON is ready to emit a specification, revisit the question of which format(s) to make a standard. If there are multiple groups that have decided to use different formats we should find out why and if there are sound reasons, that might lead to yet another format or it might mean that there really is a need for more than one. If there are multiple groups that have all chosen the same one then we have a winner. If there is only one group, well make their choice Proposed Standard and see if path dependence kicks in.
Website: http://hallambaker.com/