Re: Alternative Header Compression Update..

[Michael Sweet <[e-mail]>]

James,

On Jul 9, 2013, at 8:40 PM, James M Snell <[e-mail]> wrote:
> ...
> This details an alternative scheme that ditches the differential
> encoding and the reference set, uses a fixed range of header table
> indices (0x00-FF), and uses a least-recently-written eviction strategy
> without renumbering. This approach is significantly less complicated
> to implement at the cost of only a small handful of additional bytes
> on the wire.


Actually, I think the typed encoding will probably yield enough savings to offset any increase in size, for example the date header going from 29 octets to ~6 in the variable integer encoding (or 8/11 for the RFC 2579 encoding - see below).

I like the 256-entry single header table approach.  Of course, I have some feedback... :)

1. Would be nice if you could just include the Unsigned Variable Length Integer Syntax section from the other header compression draft wholesale so this draft stands on its own. Add a notice at the beginning "(This is copied from draft-ietf-httpbis-header-compression-NN)" so people know it is the same encoding.  Then the reference to it becomes informative.

2. Would also be nice to use the same figure format as the compression and http2 drafts... (see below)

3. Representing timestamps as milliseconds since the traditional UNIX epoch is problematic since it requires support for large integers (at least 42 bits to get us to the traditional 2038 end year, more if you want to keep going past then...) and AFAIK isn't widely used in standards for actual representation of a date/time. RFC 2579 defines a DateAndTime format that is 8 (UTC) or 11 (local time) octets long and is easy to map to/from typical OS APIs without the use of large integers. Granted, it doesn't give you more than 10ths of seconds, but I think that should be enough for HTTP. (We use this format in IPP - I'd rename "Timestamp" to "DateAndTime" if you decide to make this change...)

4. I'm not super-keen on grouping the headers into 4 bins ahead of time, since that increases encoder storage requirements.  Also, there isn't a way to just replace the value for an existing indexed header in your current draft.  Perhaps a hybrid approach where the indexed representation can have 1-to-64 indexes and the others encode a single name/value?  Something like this:

    Non-Indexed Literal Representation
    (Name Length > 0)

      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | 0   0 |   Name Length (6+)    |
    +-------+-----------------------+
    | Name String                   |
    +---+---+---+-------------------+
    | Value Type| Value Length (5+) |
    +-----------+-------------------+
    | Value String                  |
    +-------------------------------+


    Indexed Literal Representation
    (Name Length > 0)

      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | 0   1 |   Name Length (6+)    |
    +-------+-----------------------+
    | Name String                   |
    +---+---+---+-------------------+
    | Value Type| Value Length (5+) |
    +-----------+-------------------+
    | Value String                  |
    +-------------------------------+


    Indexed Representation
    (Count = 1 to 64)

      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | 1   0 |   Count - 1 (6)       |
    +-------+-----------------------+
    | Name/Value Index 1 (8)        |
    ...                          ....
    | Name/Value Index N (8)        |
    +-------------------------------+


    Indexed Literal Replacement Representation
    (Name Length > 0 to replace name and value)

      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | 1   1 |   Name Length (6+)    |
    +-------+-----------------------+
    | Name String                   |
    +-------------------------------+
    | Index (8)                     |
    +---+---+---+-------------------+
    | Value Type| Value Length (5+) |
    +-----------+-------------------+
    | Value String                  |
    +-------------------------------+


    Indexed Literal Replacement Representation
    (Name Length = 0 to just replace value)

      0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | 1   1 | 0   0   0   0   0   0 |
    +-------+-----------------------+
    | Index (8)                     |
    +---+---+---+-------------------+
    | Value Type| Value Length (5+) |
    +-----------+-------------------+
    | Value String                  |
    +-------------------------------+

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair