I think it would make more sense to have an http-core spec.
The basics of serving http as an api.
- no sessions
 - no authentication
 - no streaming apis
 - always async (if you want blocking calls, do it yourself.  none of this bolted on broken async that servlet has)
 - no filters (this is just wrappers of the request or the response, and can be genericized)
 - no listeners (pointless specialization, keep it generic)
 - no url-pattern mappings (there's countless ways to map a request to an internal feature, let the users control how they want it)
 - request is an interface (not an abstract class)
 - response is an interface (not an abstract class)
 - no complex war or ear magic
 - no classloader isolation concerns
 - no auto discovery of components
 - no external configuration (xml, json, etc)
 - entirely programmatic
 
This low level http api would be sufficient to build REST, Servlet, or whatever (grpc?) on top of.
The responsibilities of the http-api impls would be to handle the connections, the exchanges, the http/2+ streams, etc.
Transport concerns, compression, etc.