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

[Paul Kyzivat <[e-mail]>]

Roman,

On 8/16/23 11:28 AM, Roman Shpount wrote:
> Paul,
> 
> The word change proposed in the errata is incorrect. The original text 
> is correct, and the sentence currently correctly refers to "answer".

OK. I just looked again and I see the point you are making. I agree.

	Sorry,
	Paul

> The rest of what Christer and I wrote is just an explanation of why.
> 
> Best Regards,
> _____________
> Roman Shpount
> 
> 
> On Wed, Aug 16, 2023 at 11:24 AM Paul Kyzivat <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     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]
>     <mailto:[e-mail]>> *On Behalf Of *Roman Shpount
>      > *Sent:* Saturday, 12 August 2023 1.31
>      > *To:* Paul Kyzivat <[e-mail]
>     <mailto:[e-mail]>>
>      > *Cc:* [e-mail] <mailto:[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]>
>      > <mailto:[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>
>      >     <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]>
>     <mailto:[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]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>      >      > https://www.ietf.org/mailman/listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>      >     <https://www.ietf.org/mailman/listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>>
>      >
>      >     _______________________________________________
>      >     mmusic mailing list
>      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      > https://www.ietf.org/mailman/listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>      >     <https://www.ietf.org/mailman/listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>>
>      >
>