[hybi] [Technical Errata Reported] RFC6455 (7608)

RFC Errata System <rfc-editor@rfc-editor.org> Sat, 19 August 2023 04:51 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 09C4AC14CF05 for <hybi@ietfa.amsl.com>; Fri, 18 Aug 2023 21:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.533
X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_HELO_SOFTFAIL=0.732, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wL6RdIkIpidg for <hybi@ietfa.amsl.com>; Fri, 18 Aug 2023 21:51:17 -0700 (PDT)
Received: from rfcpa.amsl.com (unknown []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F924C14CEFC for <hybi@ietf.org>; Fri, 18 Aug 2023 21:51:17 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id F240E7FDE0; Fri, 18 Aug 2023 21:51:16 -0700 (PDT)
To: ifette+ietf@google.com, Alexey.Melnikov@isode.com, superuser@gmail.com, francesca.palombini@ericsson.com, Salvatore.Loreto@ericsson.com, Gabriel.Montenegro@microsoft.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: esmond.pitt@bigpond.com, hybi@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20230819045116.F240E7FDE0@rfcpa.amsl.com>
Date: Fri, 18 Aug 2023 21:51:16 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/78BR5mUEp5ukkUXyCIKNNZyNwws>
Subject: [hybi] [Technical Errata Reported] RFC6455 (7608)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Aug 2023 04:51:21 -0000

The following errata report has been submitted for RFC6455,
"The WebSocket Protocol".

You may review the report below and at:

Type: Technical
Reported by: Esmond Pitt <esmond.pitt@bigpond.com>

Section: 7.1.1

Original Text
The underlying TCP connection, in most normal cases, SHOULD be closed
   first by the server, so that it holds the TIME_WAIT state and not the
   client (as this would prevent it from re-opening the connection for 2
   maximum segment lifetimes (2MSL), while there is no corresponding
   server impact as a TIME_WAIT connection is immediately reopened upon
   a new SYN with a higher seq number).  

Corrected Text
The underlying TCP connection, in most normal cases, SHOULD be closed
   first by the server, so that the TIME_WAIT occurs at the
   client, not at the server.  

1. There is no such thing as a 'TIME_WAIT connection'.
2. TCP connections are never reused.
3. It is better for the TIME_WAIT *port* states to accumulate at the clients rather than at the server, as this distributes them among the client base and avoids possible resource exhaustion at the server (NB *not* port exhaustion, as the server is only using one port).
4. The part about 'as this would prevent it [the client] from re-opening the connection' is only true if the client is using a fixed local port number, which never works anyway.
5. The part about ' a TIME_WAIT connection is immediately reopened upon
   a new SYN with a higher seq number' is nonsense.

This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17)
Title               : The WebSocket Protocol
Publication Date    : December 2011
Author(s)           : I. Fette, A. Melnikov
Category            : PROPOSED STANDARD
Source              : BiDirectional or Server-Initiated HTTP APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG