Subject: Updated Binary Optimized Header Encoding Draft

From: James M Snell <[email-masked]>
Date: Wed, 3 Oct 2012 10:07:54 -0700

FYI.. I have submitted an updated draft for the proposed Binary Optimized
Header Encoding mechanism for the http2 effort.

  http://www.ietf.org/id/draft-snell-httpbis-bohe-01.txt

A number of fairly significant changes have been made:

  1. The codepage identifier for registered header tokens has been removed.
  2. The Per-header flags field has been removed and replaced with specific
individual bits to indicate character-based values and multiple values
  3. Value lengths have been increased from max 16-bit length to a max
22-bit length.

The encoding itself remains just as compact with these changes. With the
http version header field, for example, requiring no more than 6
uncompressed bytes to represent.

As always, feedback is more than welcome.

- James

---

From: Jeroen de Borst <[email-masked]>
Date: Thu, 4 Oct 2012 04:02:16 +0000

This is very similar to what was done in WAP (WSP 1.x specifically).

See section 8.4 in http://www.wapforum.org/tech/documents/WAP-203-WSP-20000504-a.pdf

Does this have to be re-invented? Are there significant benefits?

Thanks,
Jeroen

From: James M Snell [mailto:[email-masked]]
Sent: Wednesday, October 03, 2012 10:08 AM
To: [email-masked]
Subject: Updated Binary Optimized Header Encoding Draft

FYI.. I have submitted an updated draft for the proposed Binary Optimized Header Encoding mechanism for the http2 effort.

  1. The codepage identifier for registered header tokens has been removed.
  2. The Per-header flags field has been removed and replaced with specific individual bits to indicate character-based values and multiple values
  3. Value lengths have been increased from max 16-bit length to a max 22-bit length.

The encoding itself remains just as compact with these changes. With the http version header field, for example, requiring no more than 6 uncompressed bytes to represent.

- James

---

From: Ashok Kumar <[email-masked]>
Date: Thu, 4 Oct 2012 10:34:46 +0530

So according to this, if you need multiple binary encoded values, then the
values themselves can't contain NUL. If they do, then does framing layer
take responsibility of escaping it or base-64 encode the entire value?

Also, since its very common that clients get updated/upgraded almost (or
should I say atleast) once a month, and servers/proxies get upgraded only
when there are some critical patches, how do the two agree on registered
headers? (this example may be wrong, but let's say, x-forwarded-for becomes
Forwarded), What is the behavior if the client/server is sending an ID
which is beyond what the host knows?

On Thu, Oct 4, 2012 at 9:32 AM, Jeroen de Borst <[email-masked]> wrote:

>  This is very similar to what was done in WAP (WSP 1.x specifically).****
>
> ** **
>
> See section 8.4 in
> http://www.wapforum.org/tech/documents/WAP-203-WSP-20000504-a.pdf****
>
> ** **
>
> Does this have to be re-invented? Are there significant benefits?****
>
> ** **
>
> Thanks,****
>
> Jeroen****
>
> ** **
>
> ** **
>
> *From:* James M Snell [mailto:[email-masked]]
> *Sent:* Wednesday, October 03, 2012 10:08 AM
> *To:* [email-masked]
> *Subject:* Updated Binary Optimized Header Encoding Draft****
>
> ** **
>
> Header Encoding mechanism for the http2 effort. ****
>
> ** **
>
>   http://www.ietf.org/id/draft-snell-httpbis-bohe-01.txt****
>
> ** **
>
> A number of fairly significant changes have been made:****
>
> ** **
>
> ****
>   2. The Per-header flags field has been removed and replaced with
> specific individual bits to indicate character-based values and multiple
> values****
>
> 22-bit length. ****
> ** **
> uncompressed bytes to represent.****
>
> ** **
>
> As always, feedback is more than welcome.****
>
> ** **
>
> - James****
>

-- 
.- ... .... --- -.-

---

From: James M Snell <[email-masked]>
Date: Thu, 4 Oct 2012 12:08:46 -0700

> take responsibility of escaping it or base-64 encode the entire value?
Yes, that is one existing limitation of this mechanism that I have not
entirely worked out a great solution for.

fwiw, I'm not yet convinced that bohe is something we absolutely need, I
submitted the draft to contribute concrete thoughts to the overall
discussion. There are certainly many such details that would need to be
considered.

> which is beyond what the host knows?

The integer values for each header would be established via (and assigned
by) the IANA registry. The behavior when an unknown ID is encountered is no
different than when an unknown header is included in a http/1.1 request or
response. Generally, they will be ignored and passed through untouched.

- James

>>   1. The codepage identifier for registered header tokens has been
>> removed.****
>>