This is an early HTTP Directorate review. See our review guidlines at <https://httpwg.org/admin/directorate/>.

I understand that this document is still changing rapidly and not yet complete; by undertaking an early review, we hope to be able to point out issues, promote discussion, and give feedback before they become too difficult to change.

My main feedback is that I wonder about the resource modelling of a room in this protocol; just as in object oriented programming, HTTP interface design is largely about figuring out how to model the components of your program. 

In the example well-known file, rooms are parameters to operations, rather than operations being performed on rooms. I wonder (but don't know) if there has been a lost opportunity here -- e.g., to GET the state of a room, its participants, and so forth. 

I understand that the cryptographic requirements of MIMI make modelling things as GETs is more difficult here, but it does seem that features like negotiation (for acceptable ciphersuites and capabilities) _might_ leverage or extend already-existing HTTP mechanisms, rather than being embedded in application-specific payload parameters. 

This is food for thought, more than anything; I'm happy to have a chat with the authors about potential ways they could get more value out of using HTTP.

Other things I noticed (all relatively minor, except for perhaps the first):

* I don't see any discussion of why a new 'mimi' URI scheme is required. See <https://www.rfc-editor.org/rfc/rfc9205.html#name-considering-uri-schemes>.

* 4.1 seems to refer to HTTP as a 'transport layer'. Besides the transport/application split, HTTP is a _transfer_ protocol; characterising it as a transport is turning it into a "tunnel", which is not using the protocol well (unless that's the specific intent, e.g., like MASQUE). I'd suggest using terminology more carefully here, because some in the community are sticklers for this.

* 4.1 states that the 'target provider is indicated using a Host header'. This is specified at the wrong layer of abstraction -- you probably want to use terminology like 'the target URI's authority', or connect it to the origin concept (RFC 9110 section 4.3.1).

* Don't reuse the From header like this; it's not interoperable. Use an application-specific one. Don't call it From-Host; make it specific to _your_ application unless it's genuinely reusable in other applications.

* Section 5.2 and following subsections don't specify content types for requests or responses. 

* See <https://httpwg.org/admin/editors/style-guide> for guidlines about editing HTTP-related specifications (especially examples; having some on-the-wire examples would be very helpful).