You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: extensions/extensions-negotiation.md
+42-22Lines changed: 42 additions & 22 deletions
Original file line number
Diff line number
Diff line change
@@ -4,9 +4,9 @@
4
4
5
5
This document defines a Stratum V2 extension to negotiate support for other protocol extensions between clients and servers.
6
6
7
-
The mechanism allows clients to request support for a list of extensions immediately after the `SetupConnection` message exchange. The server responds with either:
7
+
The mechanism allows either clients or servers to initiate a request for extension support immediately after the `SetupConnection` message exchange. The receiving party responds with either:
8
8
-`RequestExtensions.Success`, listing the supported extensions.
9
-
-`RequestExtensions.Error`, listing the unsupported extensions.
9
+
-`RequestExtensions.Error`, listing the unsupported extensions and extensions required by the receiver.
10
10
11
11
This negotiation ensures that both parties can establish a common set of features before exchanging further protocol messages.
After the successful `SetupConnection` exchange, clients MUST send a `RequestExtensions` message to indicate the extensions they wish to use. The server responds with:
21
+
After the successful SetupConnection exchange, either party (client or server) MAY send a RequestExtensions message to indicate the extensions they wish to use. The receiving party responds with:
22
22
-`RequestExtensions.Success`, confirming which extensions are supported.
| request_id | U16 | Unique identifier for pairing the response. |
82
+
| unsupported_extensions | SEQ0_64K[U16]| List of unsupported extension identifiers. |
83
+
| requested_extensions | SEQ0_64K[U16]| List of extension identifiers the receiver requires but were not requested by the sender. |
74
84
75
85
---
76
86
@@ -87,11 +97,12 @@ Clients MUST NOT use any features from extensions that are not confirmed as supp
87
97
## 4. Implementation Notes
88
98
89
99
1. **Error Handling**:
90
-
- Servers MUST respond with `RequestExtensions.Error` if none of the requested extensions are supported.
91
-
- Servers MAY include an empty `unsupported_extensions` field in the error message if no extensions are explicitly unsupported.
100
+
- Receivers MUST respond with `RequestExtensions.Error` if none of the requested extensions are supported.
101
+
- If the receiver **requires** certain extensions but they were not included in the request, it MUST list them in the `requested_extensions` field of `RequestExtensions.Error`.
92
102
93
103
2. **Ordering**:
94
104
- The `RequestExtensions` message MUST be sent immediately after `SetupConnection.Success` and before any other protocol-specific messages.
105
+
- The response to `RequestExtensions` MUST be received before proceeding with any further protocol-specific messages.
95
106
96
107
#### 3. **Backward Compatibility**:
97
108
- **Server Behavior**:
@@ -110,3 +121,12 @@ This ensures clients can handle servers that do not implement extensions negotia
110
121
Client <--- RequestExtensions.Success [0x0002] ---- Server
111
122
```
112
123
The client now knows that extension `0x0003` is not supported and must adapt its behavior accordingly.
124
+
125
+
126
+
5. **Example Use Case with Server Requesting Extensions**:
127
+
A server requiring extension `0x0005`, but the client did not include it in its request:
128
+
```
129
+
Client --- RequestExtensions [0x0002, 0x0003] ---> Server
130
+
Client <--- RequestExtensions.Error [unsupported: 0x0003, requested: 0x0005] ---- Server
131
+
```
132
+
The client now knows that the server requires extension `0x0005` and MAY choose to retry with a modified request.
0 commit comments