diff --git a/protocol/river-window-management-v1.xml b/protocol/river-window-management-v1.xml
index 34f2a1a..7bae942 100644
--- a/protocol/river-window-management-v1.xml
+++ b/protocol/river-window-management-v1.xml
@@ -87,7 +87,7 @@ SPDX-License-Identifier: ISC
       manage sequence in between, for example during interactive move/resize of
       windows or if a window independently changes its own dimensions.
 
-      To summarize the main loop of this protocol is as follows:
+      To summarize, the main loop of this protocol is as follows:
 
       1. The server sends events indicating all changes since the last
          manage sequence followed by the manage_start event.
@@ -666,33 +666,30 @@ SPDX-License-Identifier: ISC
       <arg name="surface" type="object" interface="wl_surface"/>
     </request>
 
-    <event name="move_requested">
-      <description summary="the window requested interactive move">
+    <event name="pointer_move_requested">
+      <description summary="window requested interactive pointer move">
         This event informs the window manager that the window has requested to
-        be interactively moved using the pointer. The seat argument indicates
-        the seat for the move and the serial argument identifies the input event
-        (e.g. pointer button press or touch) that started the move.
+        be interactively moved using the pointer. The seat argument indicates the
+        seat for the move.
 
         The xdg-shell protocol for example allows windows to request that an
         interactive move be started, perhaps when a client-side rendered
         titlebar is dragged.
 
-        The window manager may use the river_seat_v1.op_start_serial request to
+        The window manager may use the river_seat_v1.op_start_pointer request to
         interactively move the window or ignore this event entirely.
 
         This event will be followed by a manage_start event after all other new
         state has been sent by the server.
       </description>
       <arg name="seat" type="object" interface="river_seat_v1"/>
-      <arg name="serial" type="uint"/>
     </event>
 
-    <event name="resize_requested">
-      <description summary="the window requested interactive resize">
+    <event name="pointer_resize_requested">
+      <description summary="window requested interactive pointer resize">
         This event informs the window manager that the window has requested to
         be interactively resized using the pointer. The seat argument indicates
-        the seat for the resize and the serial argument identifies the input
-        event (e.g. pointer button press or touch) that started the resize.
+        the seat for the resize.
 
         The edges argument indicates which edges the window has requested to be
         resized from. The edges argument will never be none and will never have
@@ -702,14 +699,13 @@ SPDX-License-Identifier: ISC
         interactive resize be started, perhaps when the corner of client-side
         rendered decorations is dragged.
 
-        The window manager may use the river_seat_v1.op_start_serial request to
+        The window manager may use the river_seat_v1.op_start_pointer request to
         interactively resize the window or ignore this event entirely.
 
         This event will be followed by a manage_start event after all other new
         state has been sent by the server.
       </description>
       <arg name="seat" type="object" interface="river_seat_v1"/>
-      <arg name="serial" type="uint"/>
       <arg name="edges" type="uint" enum="edges"/>
     </event>
 
@@ -1424,44 +1420,21 @@ SPDX-License-Identifier: ISC
       <arg name="shell_surface" type="object" interface="river_shell_surface_v1"/>
     </event>
 
-    <request name="op_start_serial">
-      <description summary="start an interactive operation with a serial">
-        Start an interactive seat operation with a serial from either the
-        river_window_v1.move_requested or river_window_v1.resize_requested
-        event.
-
-        During the operation, op_delta events will be sent based on input
-        corresponding to the provided serial (e.g. pointer or touch input).
-
-        The window manager may use this operation to implement interactive
-        move/resize of windows by setting the position of windows and proposing
-        dimensions based off of the op_delta events.
-
-        The operation continues until the pointer button, touch point or similar
-        corresponding to the given serial is released or the op_end request is
-        made and applied during a manage sequence.
-
-        This request is ignored if an operation is already in progress for a
-        given river_seat_v1.
-
-        This request modifies window management state and may only be made as
-        part of a manage sequence, see the river_window_manager_v1 description.
-      </description>
-      <arg name="serial" type="uint"/>
-    </request>
-
     <request name="op_start_pointer">
       <description summary="start an interactive pointer operation">
         Start an interactive pointer operation. During the operation, op_delta
         events will be sent based on pointer input.
 
+        When all pointer buttons are released, the op_release event is sent.
+
+        The pointer operation continues until the op_end request is made during
+        a manage sequence and that manage sequence is finished.
+
         The window manager may use this operation to implement interactive
         move/resize of windows by setting the position of windows and proposing
         dimensions based off of the op_delta events.
 
-        The pointer operation continues until the op_end request is made during
-        a manage sequence and that manage sequence is finished. This request is
-        ignored if an operation is already in progress.
+        This request is ignored if an operation is already in progress.
 
         This request modifies window management state and may only be made as
         part of a manage sequence, see the river_window_manager_v1 description.
@@ -1472,11 +1445,29 @@ SPDX-License-Identifier: ISC
       <description summary="total cumulative motion since op start">
         This event indicates the total change in position since the start of the
         operation of the pointer/touch point/etc.
+
+        This event will be followed by a manage_start event after all other new
+        state has been sent by the server.
       </description>
       <arg name="dx" type="int" summary="total change in x"/>
       <arg name="dy" type="int" summary="total change in y"/>
     </event>
 
+    <event name="op_release">
+      <description summary="operation input has been released">
+        The input driving the current interactive operation has been released.
+        For a pointer op for example, all pointer buttons have been released.
+
+        Depending on the op type, op_delta events may continue to be sent until
+        the op is ended with the op_end request.
+
+        This event is sent at most once during an interactive operation.
+
+        This event will be followed by a manage_start event after all other new
+        state has been sent by the server.
+      </description>
+    </event>
+
     <request name="op_end">
       <description summary="end an interactive operation">
         End an interactive operation.
@@ -1547,19 +1538,6 @@ SPDX-License-Identifier: ISC
       <entry name="mod5" value="128"/>
     </enum>
 
-    <request name="get_xkb_binding">
-      <description summary="define a new xkbcommon key binding">
-        Define a key binding in terms of an xkbcommon keysym and other
-        configurable properties.
-
-        The new key binding is not enabled until initial configuration is
-        completed and the enable request is made during a manage sequence.
-      </description>
-      <arg name="id" type="new_id" interface="river_xkb_binding_v1"/>
-      <arg name="keysym" type="uint" summary="an xkbcommon keysym"/>
-      <arg name="modifiers" type="uint" enum="modifiers"/>
-    </request>
-
     <request name="get_pointer_binding">
       <description summary="define a new pointer binding">
         Define a pointer binding in terms of a pointer button, modifiers, and
@@ -1577,115 +1555,6 @@ SPDX-License-Identifier: ISC
     </request>
   </interface>
 
-  <interface name="river_xkb_binding_v1" version="1">
-    <description summary="configure a xkb key binding, receive trigger events">
-      This object allows the window manager to configure a xkbcommon key binding
-      and receive events when the key binding is triggered.
-
-      The new key binding is not enabled until the enable request is made during
-      a manage sequence.
-
-      Normally, all key events are sent to the surface with keyboard focus by
-      the compositor. Key events that trigger a key binding are not sent to the
-      surface with keyboard focus.
-
-      If multiple key bindings would be triggered by a single physical key event
-      on the compositor side, it is compositor policy which key binding(s) will
-      receive press/release events or if all of the matched key bindings receive
-      press/release events.
-
-      Key bindings might be matched by the same physical key event due to shared
-      keysym and modifiers. The layout override feature may also cause the same
-      physical key event to trigger two key bindings with different keysyms and
-      different layout overrides configured.
-    </description>
-
-    <request name="destroy" type="destructor">
-      <description summary="destroy the xkb binding object">
-        This request indicates that the client will no longer use the xkb key
-        binding object and that it may be safely destroyed.
-      </description>
-    </request>
-
-    <request name="set_layout_override">
-      <description summary="override currently active xkb layout">
-        Specify an xkb layout that should be used to translate key events for
-        the purpose of triggering this key binding irrespective of the currently
-        active xkb layout.
-
-        The layout argument is a 0-indexed xkbcommon layout number for the
-        keyboard that generated the key event.
-
-        If this request is never made, the currently active xkb layout of the
-        keyboard that generated the key event will be used.
-
-        This request modifies window management state and may only be made as
-        part of a manage sequence, see the river_window_manager_v1 description.
-      </description>
-      <arg name="layout" type="uint" summary="0-indexed xkbcommon layout"/>
-    </request>
-
-    <request name="enable">
-      <description summary="enable the key binding">
-        This request should be made after all initial configuration has been
-        completed and the window manager wishes the key binding to be able to be
-        triggered.
-
-        This request modifies window management state and may only be made as
-        part of a manage sequence, see the river_window_manager_v1 description.
-      </description>
-    </request>
-
-    <request name="disable">
-      <description summary="disable the key binding">
-        This request may be used to temporarily disable the key binding. It may
-        be later re-enabled with the enable request.
-
-        This request modifies window management state and may only be made as
-        part of a manage sequence, see the river_window_manager_v1 description.
-      </description>
-    </request>
-
-    <event name="pressed">
-      <description summary="the key triggering the binding has been pressed">
-        This event indicates that the physical key triggering the binding has
-        been pressed.
-
-        This event will be followed by a manage_start event after all other new
-        state has been sent by the server.
-
-        The compositor should wait for the manage sequence to complete before
-        processing further input events. This allows the window manager client
-        to, for example, modify key bindings and keyboard focus without racing
-        against future input events. The window manager should of course respond
-        as soon as possible as the capacity of the compositor to buffer incoming
-        input events is finite.
-      </description>
-    </event>
-
-    <event name="released">
-      <description summary="the key triggering the binding has been released">
-        This event indicates that the physical key triggering the binding has
-        been released.
-
-        Releasing the modifiers for the binding without releasing the "main"
-        physical key that produces the bound keysym does not trigger the release
-        event. This event is sent when the "main" key is released, even if the
-        modifiers have changed since the pressed event.
-
-        This event will be followed by a manage_start event after all other new
-        state has been sent by the server.
-
-        The compositor should wait for the manage sequence to complete before
-        processing further input events. This allows the window manager client
-        to, for example, modify key bindings and keyboard focus without racing
-        against future input events. The window manager should of course respond
-        as soon as possible as the capacity of the compositor to buffer incoming
-        input events is finite.
-      </description>
-    </event>
-  </interface>
-
   <interface name="river_pointer_binding_v1" version="1">
     <description summary="configure a pointer binding, receive trigger events">
       This object allows the window manager to configure a pointer binding and