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 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








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