On 8/6/13 11:34 AM, "Phillip Hallam-Baker" <hallam(_at_)gmail(_dot_)com> wrote:
The issue here is whether this proposal should be an IETF Proposed
STANDARD.
standards-track != standard, right?
I think that is nuts and I would think it just as much nuts if it was my
proposal. We have no real world implementation experience by which I mean
using it in a protocol and not writing some python
When I parse your words closely, I see you calling the idea "nuts", but
the emotional reaction I had was that you had called *me* "nuts".
Regardless, this seems a little out of proportion to what I thought was a
relatively polite attempt at dialog. I'm worried that this kind of
interaction is exactly the sort of thing that scares new communities away
from participating here.
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.
I would argue that if 4627 had received the more-thorough review that
would have come from being on standards track, it might not have had as
many problems as we're finding that it does.
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.
First, this isn't JSON, even though interop with JSON was a goal.
Second, if the JSON wg wanted to recharter with a broader mission that
included CBOR and other similar protocols, that might be interesting to
me. I don't get the sense from what I've seen in that group that there
would be enough energy for that, but that is obviously not for me to
decide.
Third, I think I said in my long message that I wouldn't mind having a
working group look at this, so I'm not sure why you'd accuse me of
circumventing process here.
For the record, the issues I see are:
1) This is an entirely new encoding and semantics. It is not JSON in
binary which is what we actually need.
To me, it appears to be a proper superset of the parts of JSON that are
safe to use.
2) No support for tag compression.
That's an interesting requirement, and one that I think could be added to
the design if there were others that felt motivated to help. I think I
can see a way that it could be added later: create a new tag that precedes
a map of string-to-int conversions.
However, my intuition is that this wouldn't have radically better behavior
than gzip, and so I'd like to see some numbers to prove that the
complexity was worthwhile.
3) No support for decimal floating point.
Section 2.4.3 describes decimal fractions. Can you describe what other
behavior you'd like? Or are you arguing that you'd like to see that moved
to being a core type?
4) Its all or nothing, no layering.
Could you say more about that? I see the tagging system as being exactly
a layering system, where you are explicitly invited to ignore any tag you
don't implement.
The first one is my main complaint. I want to be able to use the binary
and text JSON encodings interchangeably and not have the upper layers to
have to bother with it at all.
I think I understand this. I could see where my CBOR event-based parser
could also take JSON in, and generate the exact same events. I might even
do that as a proof of concept. Could you say more about what in CBOR you
think violates this?
Understandably, some type information will be lost converting
CBOR-to-JSON, but that will be true for anything that we come up with in
this space, I think.
What I like in JSON is the lack of features and the fact that JSON covers
95% of all my needs as is. All I want to add in to get to 100% features
are the ability to encode floating point without loss and the ability to
efficiently encode binary blobs.
I'd add dates to this, but I mostly agree with you. CBOR, to me, was
close enough to what I wanted, explained in a way that made it easy to
implement, and I could ignore the bits that I didn't need for my use
cases. I got over the fact that it was different than what I had
originally wanted, that it has some complexifying features like streaming
(added at the request of the community), and that we couldn't get any of
the existing players in the space to bring their work to us.
--
Joe Hildebrand