Resent-Date: Wed, 29 May 2013 16:32:36 +0000
Resent-Message-Id: <E1UhjIi-0003Kq-Dw@frink.w3.org>
MIME-Version: 1.0
Date: Wed, 29 May 2013 12:31:40 -0400
Message-ID: <CAMm+LwjTFm3prX2emJxWpZKfnRzgvvK+H9Rgz1AAoXBTQd=kTw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=089e01184dd4a59f0804ddddeacd
Received-SPF: pass client-ip=74.125.82.175; envelope-from=hallam@gmail.com;
 helo=mail-we0-f175.google.com
Subject: HTTP in JSON Binary Encoding / Data Model
Archived-At: <http://www.w3.org/mid/CAMm+LwjTFm3prX2emJxWpZKfnRzgvvK+H9Rgz1AAoXBTQd=kTw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--089e01184dd4a59f0804ddddeacd
Content-Type: text/plain; charset=ISO-8859-1

Sorry for throwing this in at the last minute. But I think there are
advantages to this scheme that make it likely that people will tread this
path in the future regardless of what decision the WG comes to on HTTP
encoding. I did consult with Mark Nottingham before throwing this in here.


The idea that prompted this proposal was Hoffman and Bormann's CBOR
proposal which defines a subset that provides a binary encoding of JSON. It
seemed to me that many of the ideas raised in the HTTP encoding debate
would be relevant to binary JSON. I also realized that to be useful in a
Web Services context, any scheme would need something like the HTTP chunked
transport encoding.

The primary value of a binary encoding for JSON would be that it avoids the
need to base64 encode binary blobs, a problem that gets a lot worse when
nested binary structures are involved and the 33% overhead per pass rises
exponentially.


So imagine for the sake of argument we have an encoding for JSON that:

* Is easy to convert existing JSON parsers/emitters to read/write
* Is as compact as the JSON specification and with the same data model
* Supports compression of strings to tag codes
* Supports binary blobs of data
* Supports chunked encoding of binary data and strings


Such an encoding would have obvious advantage in Web Services applications
that deal with large chunks of binary data. Instead of having to switch
encodings or pass binary data as links, all the data can be managed in one
framework.

Now imagine that the Web Service could use the same encoding for the HTTP
framing layer and the application layer. Instead of needing separate HTTP
and application stacks, it is now easy to combine both in to a single
scheme. This is the part of the ASN.1 vision that was brilliant. It was the
implementation of ASN.1 that sucked.

In this model HTTP headers would become JSON tags. Since JSON tags are
simply strings, a mechanism that allowed codes to be substituted for
strings would allow compression of both.


Proposing a scheme that meets these requirements is not difficult and I
propose to have one sometime next week. There are many other existing
proposals including BJSON which is heavily used in MongoDB. And there is a
whole set of arguments around the limitations that JSON imposes because it
is not possible to convert between binary and decimal representations of
floating point numbers without loss of precision which is a show stopper
for scientific applications.

For the sake of this argument assume that such an encoding can be devised
that offers comparable space/time efficiency to other encoding proposals.


This approach would be a huge win for Web Services. It would also provide
an easy and consistent way to represent HTTP headers in JavaScript and
other scripting languages so there are advantages to the browser side as
well.

The main problem is the time factor. Now is not the time to restart the
coding discussion from scratch. But that is not the only area that this
proposal would affect. The much bigger impact would be on the data model
used to describe HTTP headers. If the group chooses a data model for HTTP
headers that is aligned with the JavaScript data model and so has a
convenient conversion into and out of JSON, it will be possible to adopt a
binary encoding of JSON in Web Services applications at a later date.


-- 
Website: http://hallambaker.com/

--089e01184dd4a59f0804ddddeacd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry for throwing this in at the last minute. But I think=
 there are advantages to this scheme that make it likely that people will t=
read this path in the future regardless of what decision the WG comes to on=
 HTTP encoding. I did consult with Mark Nottingham before throwing this in =
here.<div>
<br><div><br></div><div style>The idea that prompted this proposal was Hoff=
man and Bormann&#39;s CBOR proposal which defines a subset that provides a =
binary encoding of JSON. It seemed to me that many of the ideas raised in t=
he HTTP encoding debate would be relevant to binary JSON. I also realized t=
hat to be useful in a Web Services context, any scheme would need something=
 like the HTTP chunked transport encoding.</div>
<div style><br></div><div style>The primary value of a binary encoding for =
JSON would be that it avoids the need to base64 encode binary blobs, a prob=
lem that gets a lot worse when nested binary structures are involved and th=
e 33% overhead per pass rises exponentially.</div>
<div style><br></div><div style><br></div><div style>So imagine for the sak=
e of argument we have an encoding for JSON that:</div><div style><br></div>=
<div style>* Is easy to convert existing JSON parsers/emitters to read/writ=
e</div>
<div style>* Is as compact as the JSON specification and with the same data=
 model</div><div style>* Supports compression of strings to tag codes</div>=
<div style>* Supports binary blobs of data</div><div style>* Supports chunk=
ed encoding of binary data and strings</div>
<div><br></div><div><div><br></div><div style>Such an encoding would have o=
bvious advantage in Web Services applications that deal with large chunks o=
f binary data. Instead of having to switch encodings or pass binary data as=
 links, all the data can be managed in one framework.=A0</div>
<div><br></div><div style>Now imagine that the Web Service could use the sa=
me encoding for the HTTP framing layer and the application layer. Instead o=
f needing separate HTTP and application stacks, it is now easy to combine b=
oth in to a single scheme. This is the part of the ASN.1 vision that was br=
illiant. It was the implementation of ASN.1 that sucked.</div>
<div style><br></div><div style>In this model HTTP headers would become JSO=
N tags. Since JSON tags are simply strings, a mechanism that allowed codes =
to be substituted for strings would allow compression of both.</div><div st=
yle>
<br></div><div style><br></div><div style>Proposing a scheme that meets the=
se requirements is not difficult and I propose to have one sometime next we=
ek. There are many other existing proposals including BJSON which is heavil=
y used in MongoDB. And there is a whole set of arguments around the limitat=
ions that JSON imposes because it is not possible to convert between binary=
 and decimal representations of floating point numbers without loss of prec=
ision which is a show stopper for scientific applications.=A0</div>
<div style><br></div><div style>For the sake of this argument assume that s=
uch an encoding can be devised that offers comparable space/time efficiency=
 to other encoding proposals.=A0</div><div style><br></div><div><br></div>
<div style>This approach would be a huge win for Web Services. It would als=
o provide an easy and consistent way to represent HTTP headers in JavaScrip=
t and other scripting languages so there are advantages to the browser side=
 as well.</div>
<div style><br></div><div style>The main problem is the time factor. Now is=
 not the time to restart the coding discussion from scratch. But that is no=
t the only area that this proposal would affect. The much bigger impact wou=
ld be on the data model used to describe HTTP headers. If the group chooses=
 a data model for HTTP headers that is aligned with the JavaScript data mod=
el and so has a convenient conversion into and out of JSON, it will be poss=
ible to adopt a binary encoding of JSON in Web Services applications at a l=
ater date.</div>
<div style><br></div><div><br></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/">http://hallambaker.com/</a><br>
</div></div></div>

--089e01184dd4a59f0804ddddeacd--