[AVTCORE] [Errata Rejected] RFC4103 (5032)

RFC Errata System <rfc-editor@rfc-editor.org> Tue, 07 November 2023 09:22 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B573C17C52E; Tue, 7 Nov 2023 01:22:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.532
X-Spam-Level:
X-Spam-Status: No, score=0.532 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, 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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnQcY0POGlRo; Tue, 7 Nov 2023 01:22:40 -0800 (PST)
Received: from rfcpa.amsl.com (unknown [50.223.129.200]) (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 A3C6DC110D2D; Tue, 7 Nov 2023 01:21:42 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 7E79AAB208; Tue, 7 Nov 2023 01:21:42 -0800 (PST)
To: gunnar.hellstrom@omnitor.se, gunnar.hellstrom@omnitor.se, paulej@packetizer.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: francesca.palombini@ericsson.com, iesg@ietf.org, avt@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20231107092142.7E79AAB208@rfcpa.amsl.com>
Date: Tue, 07 Nov 2023 01:21:42 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/l96wOnHMOoy9TGRUb_l3FgTmvcs>
Subject: [AVTCORE] [Errata Rejected] RFC4103 (5032)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2023 09:22:44 -0000

The following errata report has been rejected for RFC4103,
"RTP Payload for Text Conversation".

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

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
Date Reported: 2017-06-07
Rejected by: Francesca Palombini (IESG)

Section: 5.2

Original Text
-------------
After an idle period, the transmitter SHOULD set the M-bit to one in
the first packet with new text.

Corrected Text
--------------
After an idle period, the transmitter SHOULD set the M-bit to one in
the first packet with new text.

A number of approaches can be taken for how to compose the initial
packets in the session, and the packets sent at resumption after an
idle period. In order to harmonize transmitter behavior, and fulfill
requirements in RFC 2198[3] and RFC 4102[9], transmitters SHOULD
apply the following mechanism:  Initially in the session and at 
resumption of transmission after an idle period, when redundancy is
used, the packets to send SHOULD contain the same level of redundancy
as specified for the session. If redundant data for the specified
number of generations is not available for transmission, empty 
T140blocks SHOULD be inserted in the packet for transmission to make
it contain the specified level of redundancy. 

Notes
-----
RFC 4103 does not exactly specify how to compose the first packets in the session and the packets after an idle period, when redundancy is used in the session. 

Even if receivers should be prepared to decode any valid packet composition, it eases interoperability when transmitters behave consistently. 

RFC 2198 requires that the redundant format must carry at least the primary and one redundant level. RFC 4102 requires that if different compositions of the payloads in the packet is to be used, then each combination needs to be assigned its own payload type number. Assuming that that includes use of varying levels of redundancy with the same payload in the redundant data, these requirements lead to the recommendation to use the approach documented in the corrected text.
 --VERIFIER NOTES-- 
Your comment is not in scope for errata reports, which are meant to collect errors in the documents, things that were actual errors at publication and that would have been fixed at that time had the working group or document authors noticed them -- they were just missed. What you've reported goes beyond what can be done in errata. The change, therefore, if it is to be applied needs to be achieved through a consensus document.

--------------------------------------
RFC4103 (draft-ietf-avt-rfc2793bis-09)
--------------------------------------
Title               : RTP Payload for Text Conversation
Publication Date    : June 2005
Author(s)           : G. Hellstrom, P. Jones
Category            : PROPOSED STANDARD
Source              : Audio/Video Transport
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG