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

[Roman Shpount <[e-mail]>]

Paul,

The word change proposed in the errata is incorrect. The original text is
correct, and the sentence currently correctly refers to "answer".

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]> 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]> *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>
> >
>
>