[rtcweb] [Editorial Errata Reported] RFC8832 (8848)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 20 March 2026 07:38 UTC

Return-Path: <wwwrun@rfcpa.rfc-editor.org>
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@mail2.ietf.org
Received: from rfcpa.rfc-editor.org (unknown [167.172.21.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 823CECE99B20; Fri, 20 Mar 2026 00:38:10 -0700 (PDT)
Received: by rfcpa.rfc-editor.org (Postfix, from userid 461) id 678D02C7314; Fri, 20 Mar 2026 00:38:10 -0700 (PDT)
To: rfc-editor@rfc-editor.org
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20260320073810.678D02C7314@rfcpa.rfc-editor.org>
Date: Fri, 20 Mar 2026 00:38:10 -0700
Message-ID-Hash: 6FQPSJEUJOND2Y3Z2GJERX4E2M2DUOVT
X-Message-ID-Hash: 6FQPSJEUJOND2Y3Z2GJERX4E2M2DUOVT
X-MailFrom: wwwrun@rfcpa.rfc-editor.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtcweb.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: jc.yan.2003@gmail.com, randell-ietf@jesup.org, tuexen@fh-muenster.de, rtcweb@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [rtcweb] [Editorial Errata Reported] RFC8832 (8848)
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/iPq-4T-Gk23ujgFnqiGnXOFo5YY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Owner: <mailto:rtcweb-owner@ietf.org>
List-Post: <mailto:rtcweb@ietf.org>
List-Subscribe: <mailto:rtcweb-join@ietf.org>
List-Unsubscribe: <mailto:rtcweb-leave@ietf.org>

The following errata report has been submitted for RFC8832,
"WebRTC Data Channel Establishment Protocol".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8848

--------------------------------------
Type: Editorial
Reported by: JC Yan <jc.yan.2003@gmail.com>

Section: 5.2

Original Text
-------------
   This message is sent in response to a DATA_CHANNEL_OPEN_RESPONSE
   message.  It is sent on the stream used for user messages using the
   data channel.  Reception of this message tells the opener that the
   data channel setup handshake is complete.

Corrected Text
--------------
   This message is sent in response to a DATA_CHANNEL_OPEN message.  
   It is sent on the stream used for user messages using the data 
   channel. Reception of this message tells the opener that the
   data channel setup handshake is complete.

Notes
-----
RFC 8832 defines only two message types: DATA_CHANNEL_OPEN (0x03) and DATA_CHANNEL_ACK (0x02). There is no DATA_CHANNEL_OPEN_RESPONSE message defined anywhere in the document. The reference appears in early drafts of the protocol (draft-jesup-rtcweb-data-protocol-00, March 2012), which defined a DATA_CHANNEL_OPEN_RESPONSE (msg_type 1) as a separate message. This seems to have been replaced with DATA_CHANNEL_ACK. Section 6 (Procedures) correctly describes the ACK as a response to the OPEN message, confirming this is an editorial oversight.

Instructions:
-------------
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8832 (draft-ietf-rtcweb-data-protocol-09)
--------------------------------------
Title               : WebRTC Data Channel Establishment Protocol
Publication Date    : January 2021
Author(s)           : R. Jesup, S. Loreto, M. Tüxen
Category            : PROPOSED STANDARD
Source              : Real-Time Communication in WEB-browsers
Stream              : IETF
Verifying Party     : IESG