Re: [apps-discuss] Concise Binary Object Representation (CBOR)

["Paul E. Jones" <[e-mail]>]

There are actually several XML binary encodings defined today.  But I assume
the one to which you refer is the one in the W3C called Efficient XML
Interchange (EXI).  I looked into that and compared the various compression
results against a vanilla compression algorithm (namely, zlib).  I recorded
the results here:

http://www.packetizer.com/xml/papers/xml_compression_results.pdf

 

Basically, using EXI would reduce the size of messages and the more the
encoder knew about the schema, the better it would do... for small messages.
What was interesting is that the results I got rather consistently showed
that zlib would outperform most other binary encodings for messages of about
1K or larger.  However, l don't really want an encoding that requires the
encoder to be aware of a specific schema.  It might change tomorrow or next
year.

 

Zlib worked well since much of the data being compressed was, of course,
text.  And text compresses pretty well.  It just has a fairly large
footprint that is visible with smaller messages.

 

The "no schema" variant of EXI did pretty well on small messages, so I think
if COBR can achieve compression at a comparable rate or better, that would
be great.  Now, it was mentioned elsewhere in the thread (and I'll admit
I've not read the draft) that streaming might be an issue.  Steaming is not
an issue with EXI (at least not with the "no schema" variant), as new tags
are encoded into the binary output as they are first seen.

 

ASN.1 PER did an really good job at compressing data.  Some of the ASN.1
syntax can be a bit hairy, but the encoding was small.  And it worked well
since the data it was encoding was binary data, too.  With most of the newer
protocols, binary optimization is a challenge because the protocols use so
much text (media types, URLs, etc.)  So, if COBR will exist mainly to
compress text data, it will not compress too well.  I assume it is being
introduced to produce a tight wire encoding of (largely) binary data.

 

Paul

 

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, May 22, 2013 12:14 PM
To: Paul Hoffman
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR)

 

Meh...

 

I think we can all agree that *A* binary format would be useful and that two
dozen are not useful. The whole problem is how to convince people to use one
particular scheme rather than the alternatives.

 

ASN.1 has a decent binary encoding. The problem is that it also has some
terrible ones and the ASN.1 schema language was designed by a committee.

 

Text encodings do have problems. Floating Point values do not round trip
from IEEE floating point representations without special handling so the
format causes a loss in precision that can cause real trouble in scientific
work. And nobody likes base64 encoding binary values.

 

 

I would like to have available a BER like encoding for JSON. But this
proposal seems to be something rather different.

 

There is also the XML binary encoding effort that took place. They had a
competition and everything. And at the end the only real use for the work
was that it shut up the constant carping from people complaining that Web
Services in XML were verbose.

 

 

On Wed, May 22, 2013 at 12:00 PM, Paul Hoffman <[e-mail]>
wrote:

On May 22, 2013, at 8:47 AM, James M Snell <[e-mail]> wrote:

> At first read it looks interesting, and can definitely see that a lot
> of thought was put into the design. There have, however, been a number
> of previous attempts at alternative compact binary representations (or
> at least discussions) that did not seem to really go anywhere.

We did ours differently than others: we started with an ordered set of
design goals and stuck to them. That means that our early arguments about
changes / bikeshedcolors had something we could compare against, and it make
coming up with a solution much more tractable.


> What is
> the current implementation status of this? Are there implementations
> available or any existing plans to use this new format in a specific
> app or spec?

Both Carsten and I did versions (in Ruby and Python) to make sure the spec
made sense and the examples worked. At least one other member of this list
has apparently done a version in JavaScript.


> I'm largely just curious about the context and motivation
> behind this...

There are many contexts. It might be useful in CORE and other
constrained-environment work. It might be useful for the next protocols that
need a compact binary representation and the WG doesn't want to fight over
the specific features. If the design goals fit your needs (and we actually
met them...), then it's useful to have it be widely available.


--Paul Hoffman
_______________________________________________
apps-discuss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/apps-discuss





 

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