Benjamin Carlyle http 2.0 expression of interest

This is an individual submission towards the http/2.0 protocol.
My background is mostly in highly available soft real-time m2m use cases
for http, rather strict browser-centric or Web-centric use cases. Http/1.1
provides a good basis for these use cases but has a number of deficiencies
I would hope could be corrected for the new protocol revision.

#1 Message level signatures
Transport level security provides privacy and non repudiation at the
penalty of denying intermediaries the right to inspect messages and
otherwise be involved in a transaction. Message level security measures
could bring about specific benefits for http in relation to REST and
practical use cases. For example:
A signed representation could be returned by a cache without introducing
man in the middle attacks, particularly if the intermediaries are able to
add their own metadata to an envelope that contains the original unmodified
and signed body and headers from the origin server.
A signed request could eliminate the need for existing authentication
mechanisms and allow a message to be authenticated without the need for
additional round trips between client and server.
Signed messages could be inspected by firewalls to prevent requests being
sent that contravene local policy.
An encrypted response that can be read only by its intended recipients
could in theory even be returned to arbitrary clients without needing to
first authenticate them.
I think that signatures would significantly simplify m2m use cases.
Encryption may also be of use, although it is less important in my
particular use cases.
Transport level encryption can work against goal of allowing intermediates
to inspect and be involved in transactions.

#2 Canonical form or info set
The signature and encryption issues may be the tip of a larger
canonicalization ice berg. HTTP has traditionally allowed new headers a
level of freedom in defining both semantics and parsing rules. As we move
forwards perhaps it is time to place some limits on this.

#3 Out of order responses and heartbeat capability
Modifying http to be able to make efficient use of a single TCP connection
is I think a priority for many members of this list, and is something that
SPDY has been specifically developed to address. I would like to expand on
this with the specific notion of heartbeats to be able to reliably answer
the question: Is my connection alive or dead? If the connection is dead the
client will want to know as quickly as possible so that it can connect to a
redundant instance of the server.
In my use cases I often want positive confirmation that my connection is
still valid approximately every four seconds, plus assurances from
intermediates that they are also seeing heartbeats. For long poll use cases
this can be taken care of by requesting a short timeout in requests and for
long database transactions a slow response can be replaced by an
asynchronous interaction, but it would be helpful to have the server send
regular updates on the processing status for a given request. A regular
high priority OPTIONS * request may suffice to solve this problem.

#4 consider replacing internet media type identification model
A bit of a wishlist item, but mostly self explanatory. As far as m2m use
cases go a typical company might need to mint dozens or more media types
for internal use without coordination with the IANA, and it would be good
to allow a url that refers to the type's specification or allow a
combination of centrally registered tokens and urls as per RFC 5988's link
relation registry.

#5 A must understand model
Currently if a new feature is added to http requests that must be
understood servers the client must use a new http method to ensure that a
server who does not understand will reject the request. Perhaps it is time
to introduce a more refined model. My thinking is a must understand header
that consists of tokens/urls stating special requirements the server must
fulfil before accepting the message for processing. The client could
include an additional header that indicates its own supported features to
allow the server to tailor its own processing or potentially reject the
request.

#6 An idempotent POST
It would be helpful to have a way to idempotently POST new state. My
preference would be for the client to be able to supply a unique identifier
as part of its request that can be used by the server to ignore repeated
instances of the message, preferably as a uuid or guid in uri form or other
unique uris.

That's probably enough of a wishlist for my first post to this list.
Comments/criticism welcome.

Benjamin