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

[Paul Kyzivat <[e-mail]>]

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
> 
> --------------------------------------
> Type: Technical
> Reported by: Hugo Tunius <[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]
> https://www.ietf.org/mailman/listinfo/mmusic