On 8/6/13 11:34 AM, "Phillip Hallam-Baker" <hallam@xxxxxxxxx> 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