Follow-ups on review comments

proposals/2312-matrix-uri.md

@@ -295,6 +295,19 @@ Client applications SHOULD ask for user confirmation before joining if the user
 is not a joined member in the room nor in its immediate
 [successor or predecessor](https://matrix.org/docs/spec/client_server/latest#module-room-upgrades).
 
+Client applications SHOULD NOT append `action=join` to room URIs and generally
+SHOULD NOT push consumers into joining rooms unless the user's intention
+to join the room can be assumed from the context of the URI. A link
+`<a href="matrix:room/us:example.org?action=join">Join our room</a>` is
+a poorer choice for a webpage compared to
+`<a href="matrix:room/us:example.org">Our room</a>`; on the other hand,
+a message in an obsolete, especially private, room saying
+"We have moved our room elsewhere,
+`<a href="matrix:room/us:example.org?action=join">click to join</a>`"
+is safe to assume that, being in the current room, a user would want to join
+the new room and that there's not much sense in exploring the new room
+without joining it anyway.
+
 The routing query is only allowed with URIs that have path starting with
 `roomid/` to indicate servers that are likely involved in the room (cf.
 [the feature of matrix.to](https://matrix.org/docs/spec/appendices#routing)).
@@ -322,7 +335,7 @@ CS API calls) are collected as follows:
     `GET /profile/@me_in_matrix/...`)
 * Room ID:
   - URI example: `matrix:roomid/rid:example.org` or
-    (decentralised id, future) `!lol823y4bcp3qo4`
+    (decentralised id, future) `matrix:roomid/lol823y4bcp3qo4`
   - Default action: attempt to "open" the room (usually means the client
     at least displays the room timeline at the latest or
     the last remembered position - `GET /rooms/!rid:example.org/...`,