The PRF Protocol
draft-prf-protocol-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Venti | ||
| Last updated | 2026-05-10 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-prf-protocol-01
Independent Submission V. QwQ
Internet-Draft 10 May 2026
Intended status: Informational
Expires: 11 November 2026
The PRF Protocol
draft-prf-protocol-01
Abstract
This document describes the PRF protocol ("Prf is Reversed Frp"), a
lightweight, binary-length-prefixed TCP relay messaging protocol.
PRF enables peer-to-peer tunneling of TCP connections through a
public middle relay node, originally designed for Minecraft
multiplayer sessions behind NAT or firewall environments. The
protocol defines three roles - Server, Client, and Middle - and a set
of four wireframe message types for room registration, connection
requests, worker handoff, and direct Minecraft client handshake
parsing.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 November 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
QwQ Expires 11 November 2026 [Page 1]
Internet-Draft PRF Protocol May 2026
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
3. Wire Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Byte Order . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Primitive Types . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Integer (int32) . . . . . . . . . . . . . . . . . . . 4
3.2.2. String . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.3. Byte Array (bytes) . . . . . . . . . . . . . . . . . 4
4. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Type "S" - Server Registration . . . . . . . . . . . . . 5
4.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Format . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 5
4.1.4. Reconnection . . . . . . . . . . . . . . . . . . . . 5
4.1.5. Polling . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Type "C" - Client Connection Request . . . . . . . . . . 6
4.2.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.2. Format . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Type "W" - Worker Handoff . . . . . . . . . . . . . . . . 7
4.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.2. Format . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.3. Response . . . . . . . . . . . . . . . . . . . . . . 7
4.3.4. HAProxy PROXY Protocol Header . . . . . . . . . . . . 7
4.4. Type null - Untyped Raw Stream Inspection . . . . . . . . 8
4.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 8
4.4.2. Recognized Format: Minecraft Client Handshake . . . . 8
4.4.3. Room ID Extraction . . . . . . . . . . . . . . . . . 9
4.4.4. Failure Handling . . . . . . . . . . . . . . . . . . 9
5. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 9
6. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Server Registration and Client Connection . . . . . . . . 11
6.2. Untyped Raw Stream Inspection (e.g., Minecraft Client) . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
10. Normative References . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
QwQ Expires 11 November 2026 [Page 2]
Internet-Draft PRF Protocol May 2026
1. Introduction
PRF is a custom application-layer protocol that operates over raw TCP
sockets. It is designed to facilitate TCP port forwarding between
peers that cannot directly connect to each other due to network
constraints, such as Network Address Translation (NAT) or firewall
restrictions. A publicly accessible middle relay node brokers
connections between a Server (which hosts a service) and a Client
(which wishes to access that service).
The protocol does not provide encryption, authentication, or
integrity protection. It is intended for use in trusted or low-risk
environments where the primary concern is connectivity rather than
confidentiality.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Roles
The PRF protocol defines three distinct roles:
*Server (Mode 1):* The party that hosts the actual service (e.g., a
Minecraft server). It registers a room identifier with the Middle
node and waits for incoming Client connections to be forwarded.
*Client (Mode 2):* The party that wishes to access the Server's
service. It sends a connection request to the Middle node
specifying a room identifier.
*Middle (Mode 3):* A publicly accessible relay node that brokers
connections between Servers and Clients. It maintains a mapping
of room identifiers to registered Servers and pending Client
connections.
2. Protocol Overview
PRF is a request-response protocol in which all communication flows
through the Middle node. The Server registers with the Middle and
then polls for pending Client connections. The Client sends a
connection request to the Middle. When a Client is matched with a
Server, the Middle assigns a Client Worker Identifier (CW-ID) and
notifies the Server. The Server then initiates a worker connection
back to the Middle to claim the Client, after which a bidirectional
TCP tunnel is established.
QwQ Expires 11 November 2026 [Page 3]
Internet-Draft PRF Protocol May 2026
The protocol also defines a null-type mode in which no type
identifier is sent. In this mode, the Middle node inspects the raw
initial bytes of the TCP stream to determine routing. One recognized
payload format in this mode is the Minecraft client handshake packet,
making the protocol compatible with native Minecraft clients without
requiring the PRF Client tool.
3. Wire Format
3.1. Byte Order
All multi-byte numeric fields are transmitted in network byte order
(big-endian).
3.2. Primitive Types
3.2.1. Integer (int32)
A 32-bit signed integer encoded in 4 bytes, big-endian. The maximum
value is 2,147,483,647.
3.2.2. String
A string is encoded as a length-prefixed sequence of UTF-8 bytes:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (int32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data (UTF-8 bytes) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length field specifies the number of UTF-8 bytes that follow.
3.2.3. Byte Array (bytes)
A byte array is encoded identically to a String, with a 4-byte length
prefix followed by the raw bytes. Unlike String, the payload of a
byte array is not assumed to be valid UTF-8.
4. Message Types
Every message sent to the Middle node begins with a type identifier
field, which is a length-prefixed string containing one of the
following four values. The type identifier determines how the
remainder of the message is parsed.
QwQ Expires 11 November 2026 [Page 4]
Internet-Draft PRF Protocol May 2026
4.1. Type "S" - Server Registration
4.1.1. Purpose
Sent by the Server to register a room identifier with the Middle
node.
4.1.2. Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ("S") | Room ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Room ID (UTF-8 bytes) ... |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field is the UTF-8 string "S". The Room ID is a UTF-8
string of at most 30 bytes identifying the room.
4.1.3. Response
Upon receiving a Type "S" message, the Middle node sends a response
string.
*Success vs. Failure:* The first character of the response string
determines the outcome. A response beginning with > (U+003E)
indicates success; any other response indicates failure. The
remainder of the string is a server-defined, internationalized (i18n)
message that MAY be displayed to the user but MUST NOT be used for
protocol-level decision making.
4.1.4. Reconnection
If the Room ID ends with the character v (U+0076, case-insensitive)
and the room ID is already registered, the Middle node evicts the
existing Server registration and replaces it with the new connection.
The evicted Server receives the string "EXIT" (without a leading type
identifier) on its poll channel, indicating that it should terminate.
4.1.5. Polling
After successful registration, the Server enters a polling loop. The
Middle node sends a String (without a leading type identifier) to the
Server at intervals of up to 5 seconds:
QwQ Expires 11 November 2026 [Page 5]
Internet-Draft PRF Protocol May 2026
* An empty string ("") serves as a keepalive signal; the Server
takes no action.
* A non-empty string is a CW-ID (Client Worker Identifier) of the
form CW<n>, where <n> is a decimal integer. The Server MUST spawn
a streamer to handle this Client connection by sending a Type "W"
message.
4.2. Type "C" - Client Connection Request
4.2.1. Purpose
Sent by the Client to request a connection to a room identified by
its Room ID.
4.2.2. Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ("C") | Room ID (String, max 30) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field is the UTF-8 string "C". The Room ID is the
identifier of the target room, at most 30 bytes.
4.2.3. Response
Upon receiving a Type "C" message, the Middle node sends a response
string.
*Success vs. Failure:* The first character of the response string
determines the outcome. A response beginning with > (U+003E)
indicates success; any other response indicates failure. The
remainder of the string is a server-defined, internationalized (i18n)
message that MAY be displayed to the user but MUST NOT be used for
protocol-level decision making.
If the response indicates success, the Client SHOULD proceed to
establish a bidirectional tunnel.
QwQ Expires 11 November 2026 [Page 6]
Internet-Draft PRF Protocol May 2026
4.3. Type "W" - Worker Handoff
4.3.1. Purpose
Sent by the Server's streamer to claim a pending Client connection.
4.3.2. Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type ("W") | CW-ID (String, max 30) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type field is the UTF-8 string "W". The CW-ID field is the
Client Worker Identifier previously received from the Middle during
polling.
4.3.3. Response
Upon receiving a Type "W" message, the Middle node sends a response
string.
*Success vs. Failure:* The first character of the response string
determines the outcome. A response beginning with > (U+003E)
indicates success; any other response indicates failure. The
remainder of the string is a server-defined, internationalized (i18n)
message that MAY be displayed to the user but MUST NOT be used for
protocol-level decision making.
On success, a bidirectional tunnel is established between this
streamer's socket and the corresponding Client's socket. The
response message MAY contain the IP address of the connected Client
as informational text.
4.3.4. HAProxy PROXY Protocol Header
If the room identifier starts with the character V (U+0056, case-
insensitive), the Middle node prepends a HAProxy PROXY protocol
version 1 header [PROXY] to the Client-to-Server direction of the
tunnel before bridging. The header has the following format:
PROXY TCP4 <client-ip> 192.0.2.1 10000 10000\r\n
QwQ Expires 11 November 2026 [Page 7]
Internet-Draft PRF Protocol May 2026
Where <client-ip> is the actual IP address of the Client. The
destination address and port are placeholders (192.0.2.1:10000).
This mechanism allows the target service to obtain the real Client IP
address.
4.4. Type null - Untyped Raw Stream Inspection
4.4.1. Purpose
When a connection arrives at the Middle node without a leading type
identifier string, the Middle enters an untyped raw stream inspection
mode. Rather than rejecting the connection, the Middle reads the
initial bytes from the TCP stream and attempts to identify a
recognized payload format. If a format is recognized, the Middle
extracts routing information (the room identifier) and bridges the
connection; if not, the connection is terminated with an error.
This is not a general-purpose passthrough - it is a protocol-defined
extension point that allows PRF to interoperate with existing
application protocols without requiring a PRF-specific client. The
specific format described below is the Minecraft client handshake,
which PRF happens to be compatible with by design.
4.4.2. Recognized Format: Minecraft Client Handshake
The Minecraft client handshake packet is one payload format
recognized in the null-type mode. When the Middle identifies this
format, it extracts a room identifier from the Server Name Indication
(SNI) hostname carried in the packet.
The packet format is defined by the Minecraft protocol. Within PRF,
the relevant fields are:
QwQ Expires 11 November 2026 [Page 8]
Internet-Draft PRF Protocol May 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Packet Length (VarInt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet ID = 0x00 (Byte) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version (VarInt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Name Length (VarInt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Name (UTF-8 bytes) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port (Unsigned Short) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next State (VarInt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Total Packet Length MUST be at least 10 bytes and at most 100
bytes. The Packet ID MUST be 0x00 (Handshake). The Server Name
Length MUST be at least 5.
4.4.3. Room ID Extraction
The Middle node extracts the subdomain from the Server Name (SNI)
hostname by taking all characters before the first . (U+002E)
character. For example, if the SNI is myroom.relay.example.com, the
extracted room ID is myroom.
The full handshake packet is buffered and forwarded unmodified to the
target Server after the tunnel is established.
4.4.4. Failure Handling
If the room ID cannot be found, the Middle node sends a Minecraft
Disconnect/Login packet (Packet ID 0x00) to the Client with a JSON
reason string in the format:
{"text":"<reason>"}
This terminates the Client connection with an appropriate error
message displayed in the Minecraft client.
5. Protocol Constants
The following constants are defined by the PRF protocol:
QwQ Expires 11 November 2026 [Page 9]
Internet-Draft PRF Protocol May 2026
+===================+===========+===============================+
| Constant | Value | Description |
+===================+===========+===============================+
| Maximum Room ID | 30 bytes | Maximum UTF-8 byte length of |
| Length | | a room/server identifier |
+-------------------+-----------+-------------------------------+
| Maximum Response | 100 bytes | Maximum UTF-8 byte length of |
| Length | | a Middle response string |
+-------------------+-----------+-------------------------------+
| Minimum MC Packet | 10 bytes | Minimum Minecraft handshake |
| Length | | packet total length |
+-------------------+-----------+-------------------------------+
| Maximum MC Packet | 100 bytes | Maximum Minecraft handshake |
| Length | | packet total length |
+-------------------+-----------+-------------------------------+
| Minimum Server | 5 bytes | Minimum SNI hostname length |
| Name Length | | |
+-------------------+-----------+-------------------------------+
| Maximum VarInt | 5 | Maximum bytes for a single |
| Bytes | | VarInt encoding |
+-------------------+-----------+-------------------------------+
| Poll Interval | 5 seconds | Interval at which the Server |
| | | polls for new CW-IDs |
+-------------------+-----------+-------------------------------+
| Initial Read | 5 seconds | Middle socket read timeout |
| Timeout | | for type detection |
+-------------------+-----------+-------------------------------+
| Reconnect Delay | 10 | Delay before a Server |
| | seconds | reconnects after disconnect |
+-------------------+-----------+-------------------------------+
| Streamer Bridge | 10 | Delay before a MiddleStreamer |
| Delay | seconds | begins bridging data |
+-------------------+-----------+-------------------------------+
| CW-ID Prefix | "CW" | Prefix for Client Worker |
| | | Identifiers |
+-------------------+-----------+-------------------------------+
| PROXY destination | 192.0.2.1 | Placeholder destination IP in |
| address | | PROXY header |
+-------------------+-----------+-------------------------------+
| PROXY destination | 10000 | Placeholder destination port |
| port | | in PROXY header |
+-------------------+-----------+-------------------------------+
Table 1
QwQ Expires 11 November 2026 [Page 10]
Internet-Draft PRF Protocol May 2026
6. Protocol Flow
6.1. Server Registration and Client Connection
The following diagram illustrates the normal protocol flow for a
Server registering and a Client connecting:
Server Middle Client
| | |
|--- "S" + roomId ------------>| |
|<-- ">success" ---------------| |
| | |
| |<-- "C" + roomId -------------|
| |--- ">success" -------------->|
| | |
|<-- "CW0" (poll) -------------| |
|--- "W" + "CW0" ------------->| |
|<-- ">success (<ip>)" ---------| |
| | |
|<================== Bidirectional Tunnel ===================>|
| (raw TCP relay) | (raw TCP relay) |
6.2. Untyped Raw Stream Inspection (e.g., Minecraft Client)
Native Client Middle Server
| | |
|--- MC Handshake ------------>| |
| (SNI: myroom.relay.example.com) | |
| |--- extracts roomId="myroom" |
| |--- assigns CW-ID |
| | |
| |--- "CW0" (poll) ------------>|
| |<-- "W" + "CW0" --------------|
| | |
|<================== Bidirectional Tunnel ===================>|
| (handshake forwarded) | (handshake forwarded) |
7. Security Considerations
The PRF protocol as defined in this document does not provide any
form of encryption, authentication, or integrity protection. All
data, including room identifiers, is transmitted in cleartext over
TCP. The following security implications should be considered:
* *Traffic Interception:* Any party on the network path can read all
tunneled data, including the room identifier and any application-
layer content.
QwQ Expires 11 November 2026 [Page 11]
Internet-Draft PRF Protocol May 2026
* *Traffic Injection:* Without integrity protection, an attacker can
inject or modify packets in transit.
* *Room ID Enumeration:* Room identifiers are transmitted in
cleartext and can be observed or guessed by an attacker, allowing
unauthorized connection to a Server.
* *No Server Authentication:* Clients have no cryptographic means to
verify that they are connecting to the intended Server or through
a legitimate Middle node.
* *No Client Authentication:* Servers accept connections from any
Client that provides the correct room identifier.
PRF is designed to provide no additional security guarantees beyond
those offered by the underlying transport. The protocol itself does
not perform encryption, authentication, content inspection, or access
control. Consequently, the overall security of a PRF-tunneled
connection depends entirely on the security properties of the
application-layer protocol carried within the tunnel.
Implementations and deployments SHOULD ensure that the tunneled
protocol provides its own encryption and authentication if
confidentiality and integrity are required.
8. IANA Considerations
This document has no IANA actions.
--- back
9. Acknowledgements
The PRF protocol name is a playful backronym: "Prf is Reversed Frp,"
referencing the frp (Fast Reverse Proxy) tool that inspired its
design.
10. Normative References
[PROXY] HAProxy Technologies, "HAProxy Proxy Protocol", 2011,
<https://www.haproxy.org/download/1.8/doc/proxy-
protocol.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
QwQ Expires 11 November 2026 [Page 12]
Internet-Draft PRF Protocol May 2026
Author's Address
Venti QwQ
Email: huzpsb@qq.com
QwQ Expires 11 November 2026 [Page 13]