[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
- [AVTCORE] [Errata Rejected] RFC4103 (5032) RFC Errata System