Re: Updated Binary Optimized Header Encoding Draft

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 <J.deBorst@f5.com> 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:jasnell@gmail.com]
> *Sent:* Wednesday, October 03, 2012 10:08 AM
> *To:* ietf-http-wg@w3.org
> *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. ****
>
> ** **
>
>   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****
>



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