Early Review of draft-ralston-mimi-protocol-02
review-ralston-mimi-protocol-02-httpdir-early-nottingham-2024-03-12-00

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).