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

[Paul Kyzivat <[e-mail]>]

Roman & Christer,

Before you all get off in the weeds, please note that this errata only 
proposes to change *one word*: from "answer" to "offer". You all seem to 
be discussing other issues with the text.

	Thanks,
	Paul

On 8/16/23 10:25 AM, Christer Holmberg wrote:
> Hi,
> 
> I agree with Roman.
> 
> Also, the suggested new text is confusing:
> 
> “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. “
> 
> You never have to add fmtp parameters to an answer just because a media 
> format is present in the offer. It is only if you accept the media 
> format in the answer that you might have to include fmtp parameters, for 
> the accepted media format, in the answer. And, sometimes those fmtp 
> parameters must have the same values, as indicated in the original text.
> 
> Regards,
> 
> Christer
> 
> *From:*mmusic <[e-mail]> *On Behalf Of *Roman Shpount
> *Sent:* Saturday, 12 August 2023 1.31
> *To:* Paul Kyzivat <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [MMUSIC] [Technical Errata Reported] RFC3264 (7597)
> 
> I think the errata is wrong, and the original text is correct.
> 
> All it is saying is that for some format parameters, if the media FORMAT 
> is present in the answer, then FORMAT PARAMETERS with the same values 
> must be present in the answer.
> 
> For instance, if "a=fmtp:97 mode=20" is present for payload 97 ILBC in 
> the offer, like this:
> 
> a=rtpmap:97 iLBC/8000
> a=fmtp:97 mode=20
> 
> Then, if payload 97 is present in the answer, "a=fmtp:97 mode=20" must 
> be present in the answer as well, like this:
> 
> a=rtpmap:97 iLBC/8000
> a=fmtp:97 mode=20
> 
> These parameters are not negotiated and part of the payload definition.
> 
> Best Regards,
> 
> _____________
> Roman Shpount
> 
> On Fri, Aug 11, 2023 at 5:13 PM Paul Kyzivat <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     The problem reported here, and the correction, seem valid to me.
> 
>              Thanks,
>              Paul
> 
>     On 8/11/23 10:59 AM, RFC Errata System wrote:
>      > 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
>     <https://www.rfc-editor.org/errata/eid7597>
>      >
>      > --------------------------------------
>      > Type: Technical
>      > Reported by: Hugo Tunius <[e-mail] <mailto:[e-mail]>>
>      >
>      > 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
>      >
>      > _______________________________________________
>      > mmusic mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
> 
>     _______________________________________________
>     mmusic mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>