SETTINGS frames as header blocks?

Hi all,

I have a radical suggestion for the SETTINGS frame: rather than serializing
it as a sequence of (id, value) pairs, where id and value are 8- and 32-bit
integers, respectively, use a header block, as in HEADERS/PUSH_PROMISE/
CONTINUATION. This offers the following benefits:

   -

   Extensibility: By allowing setting names to be arbitrary strings, users
   can introduce custom settings without worrying about collisions in a
   255-element namespace, and without having to maintain some sort of registry.
    -

   Expressiveness: String values allow complex settings to be encoded -
   this has been widely, and successfully, used in HTTP headers (e.g. the Link
   header <http://tools.ietf.org/html/rfc5988#section-5.5> and the
cache-control
   headers <http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9>
   ).
    -

   Simplicity: Making SETTINGS values more expressive would allow the new
   ALTSVC frame to become a setting, rather than a separate frame, since it
   confers only fire-and-forget connection-level metadata. In fact, it could
   follow the format of the Alt-Svc HTTP
header<http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-01#section-3>.
   Other extensions to the protocol can be added the same way, just as
   Alt-Svc was added to HTTP/1.1 - in contrast, "extension" frame types are
   a non-starter, since implementations are required to error out when
   receiving an unrecognized frame type.

There is also a semantic argument to be made: just as HEADERS frames
express request/response-level metadata, SETTINGS frames express
connection-level metadata (in fact, HTTP/1.1, which lacks the latter
mechanism, has made use of header fields on individual requests to express
properties about the connection as a whole, e.g. Alt-Svc and the hop-by-hop
headers, like Connection and Upgrade).

Adding header-table-size, enable-push, max-concurrent-streams, and
initial-window-size to the initial static HPACK table (or even maintaining
a separate compression context and static table) should allow us to achieve
a final SETTINGS frame size comparable to the current serialization format.
I've been contributing to hyper <https://github.com/lukasa/hyper>, a Python
client implementation, lately, and I'd be happy to give this proposal a
whirl in a branch and report back with before-and-after benchmarks.

Apologies if the above has been proposed before - I wasn't able to find
anything in a search of the archives, but I may have missed something.

Best,
Alek