W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: bohe and delta experimentation...

From: Nico Williams <nico@cryptonector.com>
Date: Wed, 16 Jan 2013 17:20:59 -0600
Message-ID: <CAK3OfOhdO069HvCTP4aJVqcyC8sxKgzh4gwvVpsab4BxCH7vhw@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Wed, Jan 16, 2013 at 5:10 PM, James M Snell <jasnell@gmail.com> wrote:
> On Wed, Jan 16, 2013 at 2:47 PM, Nico Williams <nico@cryptonector.com>
> wrote:

> One of the nice thing about the strawman encoding I used is that it is a
> field-for-field representation of the RFC3339 timestamp. It encodes exactly
> the same information and can represent the full range of dates supported by
> the date-time construct. Other variations may shave off one or two
> additional bytes but either lose information or are far more limited in the
> values they can express. Suppose we decided to adjust the millisecond field
> to 10 bits as you suggest we have a worse case of 9-bytes, best case of 6.
> Seems like a reasonable compromise to me.

The variations I mentioned also encode the same information without
losing anything at all.  The downside of going the julian day or
seconds since epoch approaches is that they require more computation,
but I think we can burn those CPU cycles since they won't incur many
cache misses -- it's fast and saves bytes on the wire where it

The question is: is it worth the trouble?  I don't have an answer to
that, but I'm inclined to say that yes, we should represent dates/time
in an already very small format.

>> Where cookies bear encrypted session state you won't be able to
>> compress them at all.  And it's not like the server can't do the
>> effort to set maximally-compressed cookies -- it should!  IMO: leave
>> cookies alone.
> Yeah, that's what I suspect also. Allowing for binary cookie values can
> allow us to avoid extra bits on the wire but compression here typically
> doesn't help for these at all, regardless of how optimized our code tree is.

Right, because cookies are mostly either randomly generated crap or
encrypted state, and those can't compress *at all*.
Received on Wednesday, 16 January 2013 23:21:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC