Nov 11, 2021 · Jan 23, 2024 · Jan 23, 2024 · Jan 23, 2024 · Jan 28, 2024 · Jan 28, 2024
diff --git a/index.bs b/index.bs
 </table>


 # Feedback from the protocol # {#feedback-from-the-protocol}
 ## Feedback from the protocol## {#feedback-from-the-protocol}

 When [=the WebSocket connection is established=], the user agent must [=queue a task=] to run these
 steps:
 <dfn export>WebSocket task source</dfn>.


 # Ping and Pong frames # {#ping-and-pong-frames}

 <cite>The WebSocket protocol</cite> defines Ping and Pong frames that can be used for keep-alive,
 heart-beats, network status probing, latency instrumentation, and so forth. These are not currently
 exposed in the API.

 User agents may send ping and unsolicited pong frames as desired, for example in an attempt to
 maintain local network NAT mappings, to detect failed connections, or to display latency metrics to
 the user. User agents must not use pings or unsolicited pongs to aid the server; it is assumed that
 servers will solicit pongs whenever appropriate for the server's needs.

 <!-- v2: we'll probably add a way to make the client send pings and automatically terminate the
 connection if they don't get a pong within an author-provided timeout; see
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264 -->


 # The {{CloseEvent}} interface # {#the-closeevent-interface}
 ## The {{CloseEvent}} interface ## {#the-closeevent-interface}

 {{WebSocket}} objects use the {{CloseEvent}} interface for their {{WebSocket/close}} events:

     {{WebSocketStream/closed}} promise will resolve, depending on the type of [=this=].
   </dl>


 # Ping and Pong frames # {#ping-and-pong-frames}

 <cite>The WebSocket protocol</cite> defines Ping and Pong frames that can be used for keep-alive,
 heart-beats, network status probing, latency instrumentation, and so forth. These are not currently
 exposed in the API.

 User agents may send ping and unsolicited pong frames as desired, for example in an attempt to
 maintain local network NAT mappings, to detect failed connections, or to display latency metrics to
 the user. User agents must not use pings or unsolicited pongs to aid the server; it is assumed that
 servers will solicit pongs whenever appropriate for the server's needs.

 <!-- v2: we'll probably add a way to make the client send pings and automatically terminate the
 connection if they don't get a pong within an author-provided timeout; see
 https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264 -->



 <h2 id="acks" class="no-num">Acknowledgments</h2>

 Until the creation of this standard in 2021, the text here was maintained in the <a
Original file line number	Diff line number	Diff line change
Expand Up		@@ -495,7 +495,7 @@ that must be supported, as [=event handler IDL attributes=], by all objects impl
		</table>


		# Feedback from the protocol # {#feedback-from-the-protocol}
		## Feedback from the protocol## {#feedback-from-the-protocol}

		When [=the WebSocket connection is established=], the user agent must [=queue a task=] to run these
		steps:
Expand DownExpand Up		@@ -636,23 +636,8 @@ The [=task source=] for all [=tasks=] <a lt="queue a task">queued</a> in this se
		<dfn export>WebSocket task source</dfn>.


		# Ping and Pong frames # {#ping-and-pong-frames}

		<cite>The WebSocket protocol</cite> defines Ping and Pong frames that can be used for keep-alive,
		heart-beats, network status probing, latency instrumentation, and so forth. These are not currently
		exposed in the API.

		User agents may send ping and unsolicited pong frames as desired, for example in an attempt to
		maintain local network NAT mappings, to detect failed connections, or to display latency metrics to
		the user. User agents must not use pings or unsolicited pongs to aid the server; it is assumed that
		servers will solicit pongs whenever appropriate for the server's needs.

		<!-- v2: we'll probably add a way to make the client send pings and automatically terminate the
		connection if they don't get a pong within an author-provided timeout; see
		https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264 -->


		# The {{CloseEvent}} interface # {#the-closeevent-interface}
		## The {{CloseEvent}} interface ## {#the-closeevent-interface}

		{{WebSocket}} objects use the {{CloseEvent}} interface for their {{WebSocket/close}} events:

Expand DownExpand Up		@@ -1303,6 +1288,24 @@ To <dfn>close the WebSocket</dfn> for a {WebSocket} or {WebSocketStream} [=this=
		{{WebSocketStream/closed}} promise will resolve, depending on the type of [=this=].
		</dl>


		# Ping and Pong frames # {#ping-and-pong-frames}

		<cite>The WebSocket protocol</cite> defines Ping and Pong frames that can be used for keep-alive,
		heart-beats, network status probing, latency instrumentation, and so forth. These are not currently
		exposed in the API.

		User agents may send ping and unsolicited pong frames as desired, for example in an attempt to
		maintain local network NAT mappings, to detect failed connections, or to display latency metrics to
		the user. User agents must not use pings or unsolicited pongs to aid the server; it is assumed that
		servers will solicit pongs whenever appropriate for the server's needs.

		<!-- v2: we'll probably add a way to make the client send pings and automatically terminate the
		connection if they don't get a pong within an author-provided timeout; see
		https://www.w3.org/Bugs/Public/show_bug.cgi?id=17264 -->



		<h2 id="acks" class="no-num">Acknowledgments</h2>

		Until the creation of this standard in 2021, the text here was maintained in the <a
Expand Down