IETF Logo Mail Archive

[MMUSIC] [Technical Errata Reported] RFC3264 (7597)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 11 August 2023 14:59 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C18C15152B for <mmusic@ietfa.amsl.com>; Fri, 11 Aug 2023 07:59:25 -0700 (PDT)
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 NzcxXNV6Ba2n for <mmusic@ietfa.amsl.com>; Fri, 11 Aug 2023 07:59:22 -0700 (PDT)
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 03D1BC14CF0D for <mmusic@ietf.org>; Fri, 11 Aug 2023 07:59:21 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id B37CAE76BE; Fri, 11 Aug 2023 07:59:21 -0700 (PDT)
To: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, superuser@gmail.com, francesca.palombini@ericsson.com, bo.burman@ericsson.com, fandreas@cisco.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: h@tunius.se, mmusic@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20230811145921.B37CAE76BE@rfcpa.amsl.com>
Date: Fri, 11 Aug 2023 07:59:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/B05q17gy7awvgeV4cL8X6XwTkI4>
Subject: [MMUSIC] [Technical Errata Reported] RFC3264 (7597)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Aug 2023 14:59:25 -0000

The following errata report has been submitted for RFC3264,
"An Offer/Answer Model with Session Description Protocol (SDP)".

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

--------------------------------------
Type: Technical
Reported by: Hugo Tunius <h@tunius.se>

Section: 6.1

Original Text
-------------
   The interpretation of fmtp parameters in an offer depends on the
   parameters.  In many cases, those parameters describe specific
   configurations of the media format, and should therefore be processed
   as the media format value itself would be.  This means that the same
   fmtp parameters with the same values MUST be present in the answer if
   the media format they describe is present in the answer.  Other fmtp
   parameters are more like parameters, for which it is perfectly
   acceptable for each agent to use different values.  In that case, the
   answer MAY contain fmtp parameters, and those MAY have the same
   values as those in the offer, or they MAY be different.  SDP
   extensions that define new parameters SHOULD specify the proper
   interpretation in offer/answer.

Corrected Text
--------------
   The interpretation of fmtp parameters in an offer depends on the
   parameters.  In many cases, those parameters describe specific
   configurations of the media format, and should therefore be processed
   as the media format value itself would be.  This means that the same
   fmtp parameters with the same values MUST be present in the answer if
   the media format they describe is present in the offer.  Other fmtp
   parameters are more like parameters, for which it is perfectly
   acceptable for each agent to use different values.  In that case, the
   answer MAY contain fmtp parameters, and those MAY have the same
   values as those in the offer, or they MAY be different.  SDP
   extensions that define new parameters SHOULD specify the proper
   interpretation in offer/answer.

Notes
-----
This indicated that the same fmtp parameters with the same values MUST be present in the answer if the media format they describe is present in the **answer**.

I believe the second instance of **answer** should be replace with **offer**, otherwise the quoted text does not makes sense I think.

Instructions:
-------------
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. 

--------------------------------------
RFC3264 (draft-ietf-mmusic-sdp-offer-answer-02)
--------------------------------------
Title               : An Offer/Answer Model with Session Description Protocol (SDP)
Publication Date    : June 2002
Author(s)           : J. Rosenberg, H. Schulzrinne
Category            : PROPOSED STANDARD
Source              : Multiparty Multimedia Session Control RAI
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

v2.23.0 | Report a Bug | By Email