Re: Last Call: <draft-bormann-cbor-04.txt> (Concise Binary Object Representation (CBOR)) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 6, 2013 at 11:41 AM, Joe Hildebrand <hildjj@xxxxxxxxxxx> wrote:
On 7/29/13 4:54 AM, "Phillip Hallam-Baker" <hallam@xxxxxxxxx> wrote:

>There are existing specs that does what CBOR does just as well that have
>actual users.

Some of these were approached, and none of them thought that having a
standard for their format was worth the amount of heartache that dealing
with the IETF would entail.  If you can get one of those communities
interested, that would be cool.

> There are requirements that the individuals proposing this chose not to
>address.

Re-enumerating those for this discussion might be useful.

The issue here is whether this proposal should be an IETF Proposed STANDARD.

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

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.

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.


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. 

2) No support for tag compression.

3) No support for decimal floating point.

4) Its all or nothing, no layering.


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.

That is why I designed a system where a single reader can read binary and text without the need for any additional state (beyond tracking how the current item is encoded.)


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. 

--
Website: http://hallambaker.com/

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]