Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti-rtcweb-rfc8829bis-05> for your review

[Justin Uberti <[e-mail]>]

OK! Thanks for the thorough review, I paged all the necessary context back
in and have addressed each point below.

I have also written up these notes in an online document at
https://docs.google.com/document/d/1c57nLyxjr7nThUEA4CMgDZQMShlT9dEtczlAWUUcbKU/edit
for easy reference.

On Tue, Oct 10, 2023 at 2:32 PM <[e-mail]> wrote:

> Authors,
>
> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
>
> 1) <!-- [rfced] Section 3.4.1:  Would you like to expand "MID" as
> "Media Identification" per RFC 9143?  (We ask this question, and a
> few similar questions later on, because this bis document provides an
> opportunity to make minor editorial improvements.)
>
> Original:
>  However, in
>  certain cases where an "m=" section has been rejected, as discussed
>  in Section 5.2.2 below, that "m=" section will be "recycled" and
>  associated with a new RtpTransceiver with a new MID value.
>
> Suggested:
>  However, in
>  certain cases where an "m=" section has been rejected, as discussed
>  in Section 5.2.2 below, that "m=" section will be "recycled" and
>  associated with a new RtpTransceiver with a new Media Identification
>  (MID) value. -->
>

[JRU] In the prior paragraph the term is already expanded to "media
identification (mid)". I suggest simply using "(MID)" in that sentence,
which should be sufficient.

>
>
> 2) <!-- [rfced] Section 3.5.2.1:  We do not see "non-JSEP endpoint" or
> "non-JSEP" mentioned in Section 5.10.  Please confirm that this
> citation is correct and will be clear to readers.
>
> Original:
>  The MID is a "media stream identification" value, as defined in
>  [RFC5888], Section 4, which provides a more robust way to identify
>  the "m=" section in the session description, using the MID of the
>  associated RtpTransceiver object (which may have been locally
>  generated by the answerer when interacting with a non-JSEP endpoint
>  that does not support the MID attribute, as discussed in Section 5.10
>  below). -->
>

[JRU] The citation refers to this bullet in S 5.10 bullet: "Associate the
found or created RtpTransceiver with the "m=" section by setting the value
of the RtpTransceiver's mid property to the MID of the "m=" section, and
establish a mapping between the transceiver and the index of the "m="
section. If the "m=" section does not include a MID (i.e., the remote
endpoint does not support the MID extension), generate a value for the
RtpTransceiver mid property, following the guidance for "a=mid" mentioned
in Section 5.2.1."


>
>
> 3) <!-- [rfced] Section 3.5.5:  As RFC 8829 was published two years ago,
> please confirm that the following text is still applicable today.
>
> Original:
>  While this specification formally relies on [RFC8445], at the time of
>  its publication, the majority of WebRTC implementations support the
>  version of ICE described in [RFC5245]. -->


[JRU] I checked and I believe this guidance is still valid; Chrome still
does not offer the "ice2" attribute.

>
>
> 4) <!-- [rfced] Section 4.1.1:  We see that a few paragraphs earlier in
> this section "preferred policy regarding use of" as written in
> RFC 8829 was changed to "preferred policy regarding the use of".
> Because that sentence and the one listed here are close together, the
> change in one place but not the other seemed to stand out a bit.
> We updated as noted below.  Please let us know any concerns.
>
> Original:
>  The application can specify its preferred policy regarding use of
>  RTP/RTCP multiplexing [RFC5761] using one of the following policies:
>
> Currently:
>  The application can specify its preferred policy regarding the use
>  of RTP/RTCP multiplexing [RFC5761] using one of the following
>  policies: -->
>

[JRU] Good catch.


>
>
> 5) <!-- [rfced] Sections 4.1.8 and 4.1.9:  We see two instances of
> "specification that defines the given SDP line" and one instance of
> "RFC that specifies the given SDP line".  Would you like these to be
> made to match (i.e., either the more general "specification" or the
> more specific "RFC")?
>
> (We assume that, in the case of the second sentence, RFCs are the
> only type of specification that will define a given SDP line.)
>
> Original:
>  In the initial offer, the generated SDP will contain all desired
>  functionality for the session (functionality that is supported but
>  not desired by default may be omitted); for each SDP line, the
>  generation of the SDP will follow the process defined for generating
>  an initial offer from the specification that defines the given SDP
>  line.
> ...
>  For each
>  existing stream, the generation of each SDP line MUST follow the
>  process defined for generating an updated offer from the RFC that
>  specifies the given SDP line.
> ...
>  As an answer, the generated SDP will contain a specific configuration
>  that specifies how the media plane should be established; for each
>  SDP line, the generation of the SDP MUST follow the process defined
>  for generating an answer from the specification that defines the
>  given SDP line. -->


[JRU] Given this is the only use of "the RFC" in the document, I'd prefer
changing that one instance to "the specification".

>
>
> 6) <!-- [rfced] Sections 5.2.1 and 5.3.1:  Please confirm that
> "Sections 4 and 5" means "Sections 4 and 5 of this document" and not
> "Sections 4 and 5 of [RFC8854]".
>
> Original:
>  The FEC mechanisms that MUST be supported are
>  specified in [RFC8854], Section 7, and specific usage for each
>  media type is outlined in Sections 4 and 5.
> ...
>  The FEC mechanisms that
>  MUST be supported are specified in [RFC8854], Section 7, and
>  specific usage for each media type is outlined in Sections 4 and
>  5. -->


[JRU] No, these citations are intended to reference the specified sections
in RFC 8854.



>
>
> 7) <!-- [rfced] Section 5.2.1:  RFC 8841 does not have a Section 4.2.2.
> As Section 4.4.2 of RFC 8841 contains the indicated information, we
> changed "4.2.2" to "4.4.2".  Please let us know if this is incorrect.
>
> Original:
>  The
>  <fmt> value MUST be set to "webrtc-datachannel" as specified in
>  [RFC8841], Section 4.2.2.
>
> Currently:
>  The
>  <fmt> value MUST be set to "webrtc-datachannel" as specified in
>  [RFC8841], Section 4.4.2. -->


[JRU] This change is correct.


>
>
> 8) <!-- [rfced] Section 5.2.3.1:  We do not see any mention of ufrag or
> pwd attributes in Section 4.4.3.1.1 of RFC 8839.  Please confirm that
> this citation (as opposed to, say, Section 4.4.1.1.1 of RFC 8839) is
> correct and will be clear to readers.
>
> Original:
>  If the IceRestart option is specified, with a value of "true", the
>  offer MUST indicate an ICE restart by generating new ICE ufrag and
>  pwd attributes, as specified in [RFC8839], Section 4.4.3.1.1. -->
>
>
[JRU] ood catch. I think the citation should be changed to 4.4.1.1.1.


>
> 9) <!-- [rfced] Section 5.2.3.2:  Because of "For codecs that have their
> own ..." in these sentences, we changed "that codec" to "those
> codecs".  Please let us know if this is incorrect (e.g., perhaps
> "such codecs" or "a given codec" was intended?).
>
> Original:
>  For codecs that have their own internal silence suppression
>  support, the appropriate fmtp parameters for that codec MUST be
>  specified to indicate that silence suppression for received audio is
>  desired.
> ...
>  For
>  codecs that have their own internal silence suppression support, the
>  appropriate fmtp parameters for that codec MUST be specified to
>  indicate that silence suppression for received audio is not desired.
>
> Currently:
>  For codecs that have their own internal silence suppression
>  support, the appropriate fmtp parameters for those codecs MUST be
>  specified to indicate that silence suppression for received audio is
>  desired.
> ...
>  For
>  codecs that have their own internal silence suppression support, the
>  appropriate fmtp parameters for those codecs MUST be specified to
>  indicate that silence suppression for received audio is not desired. -->
>
>
> [JRU] Good catch. I think I prefer "each codec" or perhaps "each such
codec" rather than "those codecs" as the example given in the following
sentence. is for an individual codec.


> 10) <!-- [rfced] Section 5.3.1:  Should 'semantics of "BUNDLE"' be
> 'semantics "BUNDLE"' per the next sentence and Section 5.2.1?
>
> Original (the next sentence is included for context):
>  If "a=group" attributes with semantics of "BUNDLE" are offered,
>  corresponding session-level "a=group" attributes MUST be added as
>  specified in [RFC5888].  These attributes MUST have semantics
>  "BUNDLE" and MUST include all mid identifiers from the offered bundle
>  groups that have not been rejected. -->
>

[JRU] Agreed, we should make this consistent and remove "of".


>
>
> 11) <!-- [rfced] Section 5.3.3:  We only see one subsection and one
> option in Section 5.3.3 (as compared to the two subsections and
> two options provided in Section 5.2.3).  Please confirm that "options
> are" is correct and will be clear to readers.
>
> Original:
>  The following options are supported in RTCAnswerOptions.
>
> Perhaps:
>  The following option is supported in RTCAnswerOptions. -->
>

[JRU] Good catch. Please change this to the singular.


>
> 12) <!-- [rfced] Section 5.8.1: Should "mids" be "MIDs" or perhaps "MID
> value" as used elsewhere in this document?
>
> Original:
>  *  Any "a=group" lines are parsed as specified in [RFC5888],
>     Section 5, and the group's semantics and mids are stored. -->
>

[JRU] Yes, please change accordingly.

>
>
> 13) <!-- [rfced] Section 5.10:  We see that "local implementation" in
> version -04 of this document was changed to "local application"
> in several places in version -05.  Please confirm that this
> remaining instance of "local implementation" is correct.
>
> Original:
>  -  For each specified fmtp parameter that is supported by the
>     local implementation, enable them on the associated media
>     formats. -->
>

[JRU] Good catch. This should also be adjusted to "local application".


>
>
> 14) <!-- [rfced] Section 5.10:  The initial-capitalized "Maximum" reads
> oddly here, as it doesn't seem to be part of the abbreviation
> (although we see the same definition in RFCs 3890 and 8859, as
> opposed to RFC 6364).  Could we rephrase as follows?
>
> Original:
>  -  For any specified "TIAS" ("Transport Independent Application
>     Specific Maximum") bandwidth value, set this value as a
>     constraint on the maximum RTP bitrate to be used when sending
>     media, as specified in [RFC3890].
>
> Possibly:
>  -  For any specified "TIAS" ("Transport Independent Application
>     Specific (maximum)") bandwidth value, set this value as a
>     constraint on the maximum RTP bitrate to be used when sending
>     media, as specified in [RFC3890]. -->


[JRU] Sounds good.


>
>
> 15) <!--[rfced] Section 5.11: Please review that "[RFC8839], Section
> 4.4.3.1" is
> the correct section here, relevant to "discard any associated ICE
> components".
>
> Original:
>    *  If the "m=" section has been rejected (i.e., the <port> value is
>       set to zero in the answer), stop any reception or transmission of
>       media for this section, and, unless a non-rejected "m=" section is
>       bundled with this "m=" section, discard any associated ICE
>       components, as described in [RFC8839], Section 4.4.3.1.
> -->
>

[JRU] That is the correct section, although I agree the ref isn't totally
clear. The reference is to the bullet "If the offer/answer exchange removed
a data stream, or an answer rejected an offered data stream, an agent MUST
flush the valid list for that data stream. It MUST also terminate any STUN
transactions in progress for that data stream.", which indirectly talks
about discarding ICE components via its mention of "flush[ing] the valid
list" and "terminat[ing] any STUN transactions".


>
> 16) <!-- [rfced] Section 7.2:  We found 3 unquoted instances of "a=..."
> parameters in running text.  As all other such entries appear to be
> quoted, we quoted these as well.  Please let us know any objections.
>
> Side question:  Should 'setup:passive' be '"a=setup:passive"'?
>
> Original:
>  In addition to the new "m="
>  sections for video, both of which are offering FEC and one of which
>  is offering simulcast, note the increment of the version number in
>  the "o=" line; changes to the "c=" line, indicating the local
>  candidate that was selected; and the inclusion of gathered candidates
>  as a=candidate lines.
> ...
>  In addition to the
>  acceptance of the video "m=" sections, the use of a=recvonly to
>  indicate one-way video, and the use of a=imageattr to limit the
>  received resolution, note the use of setup:passive to maintain the
>  existing DTLS roles.
>
> Currently:
>  In addition to the new "m="
>  sections for video, both of which are offering FEC and one of which
>  is offering simulcast, note the increment of the version number in
>  the "o=" line; changes to the "c=" line, indicating the local
>  candidate that was selected; and the inclusion of gathered candidates
>  as "a=candidate" lines.
> ...
>  In addition to the
>  acceptance of the video "m=" sections, the use of "a=recvonly" to
>  indicate one-way video, and the use of "a=imageattr" to limit the
>  received resolution, note the use of setup:passive to maintain the
>  existing DTLS roles. -->


[JRU] Good catch. Let's also go with "a=setup:passive".


>
>
> 17) <!-- [rfced] Section 8:  As we see that the two instances of "we" in
> RFC 8829 were changed to "this specification" and "one", we changed
> "your" to "an application's", per the next sentence.  Please let us
> know if this is incorrect.
>
> Original (the next sentence is included for context):
>  Thus,
>  for instance, it is not possible to prevent the remote peer from
>  learning your public IP address by removing server-reflexive
>  candidates.  Applications that wish to conceal their public IP
>  address MUST instead configure the ICE agent to use only relay
>  candidates.
>
> Currently:
>  Thus,
>  for instance, it is not possible to prevent the remote peer from
>  learning an application's public IP address by removing server-
>  reflexive candidates.  Applications that wish to conceal their public
>  IP address MUST instead configure the ICE agent to use only relay
>  candidates. -->
>

[JRU] Sounds good.


>
>
> 18) <!-- [rfced] The following Normative References have been obsoleted.
> Would you like to update the following and point to the newer RFCs?
>
>  RFC 4566 (obsoleted by RFC 8866) (Please see also
>    <https://github.com/rtcweb-wg/jsep/issues/925>.)
>
>    If you want to cite RFC 8866 instead, it appears that
>    '"RTP/AVP" (defined in [RFC4566], Section 8.2.2)' would need to be
>    changed to '"RTP/AVP" (defined in [RFC8866], Section 8.2.3)', due
>    to a new Section 8.2.1 ("Registration Procedure") that was added
>    in RFC 8866.
>
>    Two complications related to citing RFC 8866 would be that
>    (1) Section 6 in RFC 8866 was broken out into quite a few
>    subsections and (2) we see that in RFC 8866 "k=" is listed as
>    obsolete (so it's not clear to us whether or not that change would
>    impact the two instances of "k=" that we see in this document).
>
>    Even though citing RFC 8866 might not be worthwhile, we thought
>    that we should point it out all the same.
>

[JRU] Thanks for pointing this out. I tend to think we should leave things
as-is given the numerous RFC4566 refs in this document, but I could be
persuaded if you've already done the legwork here and think the changes are
safe.

>
>
>  RFC 5285 (obsoleted by RFC 8285) (Please see also
>    <https://github.com/rtcweb-wg/jsep/issues/898>.)
>
>    If you want to cite RFC 8285 instead of RFC 5285, it appears that
>    the two instances of "[RFC5285], Section 6" might need to be
>    changed to "[RFC8285], Section 7", due to a new Section 6 ("SDP
>    Signaling for Support of Mixed One-Byte and Two-Byte Header
>    Extensions") that was added in RFC 8285.
>

[JRU] I think we'd probably need to make additional changes here to use
this new SDP signaling, so I don't recommend making this update at this
time.

>
>
>  RFC 6347 (obsoleted by RFC 9147) (Could the two instances of
>    "DTLS [RFC6347]" in this document be changed to
>    "DTLS 1.2 [RFC6347] or DTLS 1.3 [RFC9147]"?) -->
>

[JRU] This is probably safe, but I'd really like Eric to weigh in here
before making either change.


>
>
> 19) <!-- [rfced] Informative References:  The provided URL for
> [W3C.webrtc] steers to a page with a red banner that says "This
> version is outdated!"  As the latest version also mentions the
> RTCPeerConnection interface, may we update as follows?
>
> Original:
>  [W3C.webrtc]
>             Jennings, C., Ed., Boström, H., Ed., and J. Bruaroey, Ed.,
>             "WebRTC 1.0: Real-time Communication Between Browsers",
>             World Wide Web Consortium Recommendation, January 2021,
>             <https://www.w3.org/TR/2021/REC-webrtc-20210126/>.
>
> Perhaps:
>  [W3C.webrtc]
>             Jennings, C., Ed., Castelli, F., Ed., Boström, H., Ed.,
>             and J-I. Bruaroey, Ed., "WebRTC: Real-time Communication
>             in Browsers", W3C Recommendation, 6 March 2023,
>             <https://www.w3.org/TR/2023/REC-webrtc-20230306/>. -->
>
>
[JRU] Sounds good.



> 20) <!-- [rfced] Informative References:  The listing for [TS26.114]
> appears to be out of date.  As we also see "Coordination of Video
> Orientation (CVO)" discussed in a downloaded copy of Release 18,
> may we update as suggested?
>
> Original:
>  [TS26.114] 3GPP, "3rd Generation Partnership Project; Technical
>             Specification Group Services and System Aspects; IP
>             Multimedia Subsystem (IMS); Multimedia Telephony; Media
>             handling and interaction (Release 16)", 3GPP TS 26.114
>             V16.3.0, September 2019,
>             <https://www.3gpp.org/DynaReport/26114.htm>.
>
> Suggested:
>  [TS26.114] 3GPP, "3rd Generation Partnership Project; Technical
>             Specification Group Services and System Aspects; IP
>             Multimedia Subsystem (IMS); Multimedia Telephony; Media
>             handling and interaction (Release 18)", 3GPP TS 26.114
>             V18.1.0, December 2022,
>             <https://www.3gpp.org/DynaReport/26114.htm>. -->
>
>
[JRU] Sounds good.

>
> 21) <!-- [rfced] Table 1 (Appendix A):  We could not find any of the five
> attributes listed below in Section 9 of RFC 4566.  Should Section 6
> of RFC 4566 be cited instead (or, if you wish to cite RFC 8866
> instead, a specific subsection of its Section 6, e.g., Section 6.7.1
> of RFC 8866 for "recvonly")?
>
> Original (dashed lines broken to avoid confusion with XML comments):
>  | recvonly                | Section 9 of [RFC4566]   |
>  +- - - - - - - - - - - - -+- - - - - - - - - - - - - +
>  | sendrecv                | Section 9 of [RFC4566]   |
>  +- - - - - - - - - - - - -+- - - - - - - - - - - - - +
>  | sendonly                | Section 9 of [RFC4566]   |
>  +- - - - - - - - - - - - -+- - - - - - - - - - - - - +
>  | inactive                | Section 9 of [RFC4566]   |
>  +- - - - - - - - - - - - -+- - - - - - - - - - - - - +
>  | fmtp                    | Section 9 of [RFC4566]   | -->



[JRU] Hmm. It looks like the ABNF info for these attribs is not actually
present in 4566, so we'd have to cite 8866 instead. If we don't do that,
referring to 4566 S 6 seems like the next best option.

>
>
> 22) <!-- [rfced] Acknowledgements:  As this document doesn't appear to
> represent significant changes to RFC 8829, should the instances of
> "this document" be "RFC 8829 (and, by extension, this document)"?
>
> Original:
>  Harald Alvestrand, Taylor Brandstetter, Suhas Nandakumar, and Peter
>  Thatcher provided significant text for this document.  Bernard Aboba,
>  Adam Bergkvist, Jan-Ivar Bruaroey, Dan Burnett, Ben Campbell, Alissa
>  Cooper, Richard Ejzak, Stefan Håkansson, Ted Hardie, Christer
>  Holmberg, Andrew Hutton, Randell Jesup, Matthew Kaufman, Anant
>  Narayanan, Adam Roach, Robert Sparks, Neil Stratford, Martin Thomson,
>  Sean Turner, and Magnus Westerlund all provided valuable feedback on
>  this document. -->
>

[JRU] I would have gone with "RFC 8829 (and thereby, this document)", but
your suggested text is also fine.

>
>
> 23) <!-- [rfced] Per our current process, please review the "Inclusive
> Language" portion of the online Style Guide at
> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
> and let us know if any changes are needed.
>
> For example, please consider whether the following should be updated:
>
>  whitespace ("where leading whitespace indicates ...")
>
>  he, his, him, and her (in the context of the long-used
>    Bob (/ Carol / Ted /) Alice examples)
>
> In addition, please consider whether "traditional" ("in traditional
> SIP") should be updated for clarity.  While the NIST website
> (<
> https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1
> >)
> indicates that "traditional" is potentially biased, it is also
> ambiguous.  "Traditional" is a subjective term, as it is not the same
> for everyone. -->
>

[JRU] This was previously discussed during IESG review and was deemed a
reasonable usage of the term. I don't think any changes are needed here.

>
>
> 24) <!-- [rfced] Please let us know if any changes are needed for the
> following:
>
> a) The following terms were used inconsistently in this document.
> We chose to use the latter forms.  Please let us know any objections.
>
>  a "m=" (1 instance) / an "m=" (22 instances) (per RFC 8829)
>
>  SDP Offer / SDP offer (1 instance each in original)
>    ("SDP offer" was used more often in Cluster 238 (the "RTCWEB"
>     cluster), and we only see "SDP answer" in this document.)
>
>  set to null (2 instances in original) /
>    set to "null" (4 instances in original)
>
>  Source RTP stream (1 instance) / Source RTP Stream (4 instances)


[JRU] Sounds good, except for the "null" case, where I think quoted "null"
is potentially confusing. We should change all instances to unquoted null.

>
> b) The following terms appear to be used inconsistently in this
> document.  Please let us know which form is preferred.
>
>  BUNDLE (3 instances in Section 1.3 and one newly capitalized
>    instance in Section 4.1.1) / bundle (28 instances in text)
>
>  For example, we see this mixed usage ("use of BUNDLE", "to
>  negotiate bundle", "accepting bundle") in Section 4.1.1:
>
>   The application can specify its preferred policy regarding the use of
>   BUNDLE, the multiplexing mechanism defined in [RFC9143].  Regardless
>   of policy, the application will always try to negotiate bundle onto a
>   single transport and will offer a single bundle group across all "m="
>   sections; use of this single transport is contingent upon the
>   answerer accepting bundle.
>
>  We see that "bundle group" and "bundle policy" are used consistently.
>

[JRU] Lowercase bundle is preferred, as it's not an acronym.


>
>
>  CN codecs (1 instance in Section 5.3.3.1) /
>    "CN" codecs (2 instances in Section 5.2.3.2)
>    (We also found this inconsistency in RFC 8829.)
>

[JRU] OK.

>
>
>  Full Trickle (Section 4.1.17) / full trickle (mode) (Section 7.2)
>    (We also see "Half Trickle" in this document.  However, we see
>    "half trickle" and "full trickle" in RFC 8838, and "Half Trickle"
>    and "Full Trickle" in RFC 8840.)
>

[JRU] RFC 8838 is authoritative on these terms, so I agree with following
its usage (i.e., lowercase).

>
>
>  ICE-lite / ice-lite
>    ("endpoints that use ICE-lite", "the presence of ice-lite")
>
>    (Perhaps 'the presence of an "a=ice-lite" line'?)
>

[JRU] The former should remain as ICE-lite. For the latter, let's switch to
your suggested text.


>
>
>  mid identifiers (2 instances) / MID identifiers (3 instances)
>
>    (This question was also asked during AUTH48 for RFC 8829 and
>    appears to apply to this document and RFC 8829 only.  Please see
>    <https://github.com/rtcweb-wg/jsep/issues/959>, and let us know
>    how the capitalization of this term should be made consistent.)
>

[JRU] Capitalized MID should be used.


>
>
>  port value / <port> value (e.g., "default port value of 9 (Discard)",
>    "default <port> value of 9 (Discard)")


[JRU] Agreed with the bracketed form.



>
>  (We also see 2 instances of "SCTP port value".)


[JRU] These should be left as-is.


>
>
> c) Quoting of terms:
>
> We see that most option names are quoted (e.g., '"trickle" option',
> '"ice2" option', '"VoiceActivityDetection" option').  Would you like
> to put quotes around "IceRestart" ('"IceRestart" option') as well?
>
> We also see the unquoted "VoiceActivityDetection parameter" in
> Section 5.3.3.1; could this be changed to '"VoiceActivityDetection"
> option'?
>

[JRU] Where we refer to something in SDP, we should use quotes (e.g.,
"ice2"). However, for API identifiers, (e.g., VoiceActivityDetection,
IceRestart), I think unquoted is clearer.

>
>
> Should quoting of named media formats and directions be consistent?
> For example, we see
>
>  "rtx" media format
>  send media format
>  "send" and "recv" directions
>  a "recvonly" direction
>  a recvonly direction
>  mark the "m=" section associated with the sender as recvonly (if
>    transceiver.direction is sendrecv) or as inactive (if
>    transceiver.direction is sendonly)
>  sendrecv or sendonly direction
>  offered as "sendonly"
>  marked as sendonly/inactive
>  marks them as sendonly
>  creating recvonly transceivers
>  If the "m=" section is sendrecv or recvonly
>  handled as recvonly -->
>
>

[JRU] We should quote "sendrecv", "sendonly", "recvonly", and "inactive",
as well as other SDPisms like "rtx". "Send" and "recv" on their own should
not be quoted; the sentence with "send" and "recv" directions should
probably just be reworded as follows:

Old:
...  with "send" and "recv" directions reversed if it was a remote answer.

New:

... with the direction reversed if it was a remote answer.



> Thank you.
>
> RFC Editor/lb/ar
>
>
> On Oct 10, 2023, [e-mail] wrote:
>
> *****IMPORTANT*****
>
> Updated 2023/10/10
>
> RFC Author(s):
> --------------
>
> Instructions for Completing AUTH48
>
> Your document has now entered AUTH48.  Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> *  RFC Editor questions
>
>   Please review and resolve any questions raised by the RFC Editor
>   that have been included in the XML file as comments marked as
>   follows:
>
>   <!-- [rfced] ... -->
>
>   These questions will also be sent in a subsequent email.
>
> *  Changes submitted by coauthors
>
>   Please ensure that you review any changes submitted by your
>   coauthors.  We assume that if you do not speak up that you
>   agree to changes submitted by your coauthors.
>
> *  Content
>
>   Please review the full content of the document, as this cannot
>   change once the RFC is published.  Please pay particular attention to:
>   - IANA considerations updates (if applicable)
>   - contact information
>   - references
>
> *  Copyright notices and legends
>
>   Please review the copyright notice and legends as defined in
>   RFC 5378 and the Trust Legal Provisions
>   (TLP – https://trustee.ietf.org/license-info/).
>
> *  Semantic markup
>
>   Please review the markup in the XML file to ensure that elements of
>   content are correctly tagged.  For example, ensure that <sourcecode>
>   and <artwork> are set correctly.  See details at
>   <https://authors.ietf.org/rfcxml-vocabulary>.
>
> *  Formatted output
>
>   Please review the PDF, HTML, and TXT files to ensure that the
>   formatted output, as generated from the markup in the XML file, is
>   reasonable.  Please note that the TXT will have formatting
>   limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
>
>   *  your coauthors
>
>   *  [e-mail] (the RPC team)
>
>   *  other document participants, depending on the stream (e.g.,
>      IETF Stream participants are your working group chairs, the
>      responsible ADs, and the document shepherd).
>
>   *  [e-mail], which is a new archival mailing list
>      to preserve AUTH48 conversations; it is not an active discussion
>      list:
>
>     *  More info:
>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>
>     *  The archive itself:
>        https://mailarchive.ietf.org/arch/browse/auth48archive/
>
>     *  Note: If only absolutely necessary, you may temporarily opt out
>        of the archiving of messages (e.g., to discuss a sensitive matter).
>        If needed, please add a note at the top of the message that you
>        have dropped the address. When the discussion is concluded,
>        [e-mail] will be re-added to the CC list and
>        its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes.  Information about stream managers can be found in
> the FAQ.  Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
>   https://www.rfc-editor.org/authors/rfc9429.xml
>   https://www.rfc-editor.org/authors/rfc9429.html
>   https://www.rfc-editor.org/authors/rfc9429.pdf
>   https://www.rfc-editor.org/authors/rfc9429.txt
>
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9429-diff.html
>   https://www.rfc-editor.org/authors/rfc9429-rfcdiff.html (side by side)
>
> Diff of the XML:
>   https://www.rfc-editor.org/authors/rfc9429-xmldiff1.html
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
>   https://www.rfc-editor.org/auth48/rfc9429
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9429 (draft-uberti-rtcweb-rfc8829bis-05)
>
> Title            : JavaScript Session Establishment Protocol (JSEP)
> Author(s)        : J. Uberti, C. Jennings, E. Rescorla, Ed.
> WG Chair(s)      : Sean Turner, Ted Hardie
> Area Director(s) : Murray Kucherawy, Francesca Palombini
>