On Fri, Aug 9, 2013 at 2:52 PM, Barry Leiba
<barryleiba(_at_)computer(_dot_)org> 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.
* 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?
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 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.
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/