HTTP profile for TLS 1.3 0-RTT early data?

Has anyone started working on an I-D for an HTTP (HTTP 1.1 and HTTP/2)
profile for TLS 1.3 0-RTT early data usage?  We've talked about it briefly
in meetings, but it seems like a work area that may need progress soon
before people start implementing things differently.  This same profile
same likely applies to early data for HTTP-over-QUIC as well.

Some topics to cover seem to be:

1) What HTTP requests can be safely sent by clients over 0-RTT early data
(with the inherent replay-ability and security considerations) ?  Mark
started some discussion here:  https://mnot.github.io/I-D/httpbis-retry/

2) An HTTP response status code for "Early data not supported for request:
retry request with 1-RTT".  This will be needed for cases where an HTTP
server isn't doing TLS termination and thus may have accepted early data
but still want to force the client to always send the request via 1-RTT
(eg, for a POST method).  This is especially critical if clients and
servers make different choices for how to handle #1.  This may want some
general considerations around how it is better to reject early data during
the handshake, but not all server implementations will be able to do this.

3) Being very explicit on how to handle early data that is rejected and
forced to be resent following connection establishment (ie, when the server
forces a client into 1-RTT mode by rejecting the early data).  A worst case
would be if a server actually handled the early data anyways but the client
thought the server had rejected it.  In HTTP/1.1 this could result in them
being off-by-one in requests/responses (and could lead to some HTTP Request
Smuggling style bugs and vulnerabilities.)

4) Perhaps a general HTTP request header for indicating that requests were
received via 0RTT early data (such as Cloudflare's "Cf-0rtt-Unique"
header).  This would be useful for both load balancers communicating to
application servers, as well as for CDNs communicating to origin servers.
This would presumably interact with #2 in cases where the appserver or
origin wanted to force a client to retry via 1-RTT.

5) ...  I'm sure there is more ...

Without some agreed on behaviors this could quickly become a mess.  For
example, if some clients decide to send POSTs via early data while some
servers assume clients will never do this and return 403 errors out of
paranoia.

Best, Erik