[MMUSIC] [Errata Rejected] RFC3264 (7597)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 09 May 2024 20:30 UTC

To: h@tunius.se, jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240509203055.B452233CD1@rfcpa.amsl.com>
Date: Thu, 09 May 2024 13:30:55 -0700
Message-ID-Hash: DARYEHDSZEWZBZPKED5EHRXR37N3XW2E
CC: orie@transmute.industries, iesg@ietf.org, mmusic@ietf.org, rfc-editor@rfc-editor.org
Precedence: list
Subject: [MMUSIC] [Errata Rejected] RFC3264 (7597)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/-MLibPtclVuZNVqGtzPuAVqPoaU>

The following errata report has been rejected 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

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

Reported by: Hugo Tunius <h@tunius.se>
Date Reported: 2023-08-11
Rejected by: Orie Steele (IESG)

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.
--VERIFIER NOTES--
See https://mailarchive.ietf.org/arch/msg/mmusic/jDXva6XmGQ4Z6_PUW_TxhZp0-Hc/

--------------------------------------
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
Stream : IETF

[MMUSIC] [Errata Rejected] RFC3264 (7597) RFC Errata System