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

["Murray S. Kucherawy" <[e-mail]>]

Ping, everybody.

-MSK, ART AD

On Mon, Oct 30, 2023 at 11:18 PM Lynne Bartholomew <[e-mail]>
wrote:

> Hi, Justin and Cullen.
>
> Justin, many thanks for your replies to our questions and for the
> GoogleDocs page!
>
> Cullen, no worries; thanks for letting us know.
>
> Justin, we have some follow-up questions for you:
>
> Regarding our question 1) (definition of "MID") and your reply:
>
> > [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.
>
>
> We changed "(mid) property" to "(MID) property", but we see "mid property"
> (as opposed to "MID property") used throughout this document; that's why we
> attempted to distinguish "mid" from "MID" (we see "MID value" used
> throughout).  Please confirm that there won't be any confusion as related
> to "mid" versus "MID".
>
> = = = = =
>
> Regarding this question and your reply:
>
> >> 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.
>
>
> Thank you for clarifying.  The links in the HTML and PDF files now steer
> to Sections 4 and 5 of RFC 8854 instead of Sections 4 and 5 of this
> document.
>
> = = = = =
>
> Regarding this question and your reply:
>
> >   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.
>
> We found that a Version 18.4.0 (September 2023) is now available.  We
> downloaded a copy of the latest version and searched for "Coordination of
> Video Orientation (CVO)".  The text appears to be the same in 18.4.0 as it
> is in 18.1.0, so we updated the listing as 18.4.0 accordingly.  Please let
> us know any concerns.
>
> FYI -- we will check the versioning again just prior to publication, and
> if it has changed again, we will again check for "Coordination of Video
> Orientation (CVO)"; if no apparent changes to text, we will ask you if we
> can update the listing to reflect the latest at the time of publication.
>
> = = = = =
>
> Regarding this question and your reply:
>
> > 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.
>
> We cited the relevant sections in RFC 8866 and listed RFC 8866 in the
> Informative References section.  Please let us know if it should be
> Normative instead (in which case we'll need AD approval).
>
> = = = = =
>
> Regarding question 24)b):
>
> "BUNDLE" vs. "bundle":  Apologies; we should not have asked this
> question.  Because "BUNDLE" is used quite a bit in recent RFCs (e.g., RFCs
> 8843 and 9143) and it appears that this document matches the context of the
> other RFCs, we did not make any updates.  For example, "BUNDLE-tag" is
> never lowercased in published RFCs.
>
>
> Does "OK" here mean "OK to leave as is"?
>
> > 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.
>
> = = = = =
>
> Regarding our question 24)c) and your reply re. option names:  We don't
> know if "createOffer/createAnswer options" or "encrypt option" should have
> quotes around the option names.  Please let us know whether or not these
> option types need quotes.
>
> > [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.
>
>
> = = = = =
>
> The latest files are posted here (please refresh your browser):
>
>    https://www.rfc-editor.org/authors/rfc9429.txt
>    https://www.rfc-editor.org/authors/rfc9429.pdf
>    https://www.rfc-editor.org/authors/rfc9429.html
>    https://www.rfc-editor.org/authors/rfc9429.xml
>    https://www.rfc-editor.org/authors/rfc9429-diff.html
>    https://www.rfc-editor.org/authors/rfc9429-rfcdiff.html
>    https://www.rfc-editor.org/authors/rfc9429-auth48diff.html
>
>    https://www.rfc-editor.org/authors/rfc9429-xmldiff1.html
>    https://www.rfc-editor.org/authors/rfc9429-xmldiff2.html
>
> Thanks again!
>
> RFC Editor/lb
>
>
> > On Oct 29, 2023, at 7:12 AM, Cullen Jennings <[e-mail]> wrote:
> >
> >
> >
> >> On Oct 27, 2023, at 11:42 PM, Murray S. Kucherawy <[e-mail]>
> wrote:
> >>
> >> Justin, or chairs: Would you like to delegate the completion of AUTH48
> to someone else?
> >>
> >
> > I am doing review but may not happen until IETF. Sorry
>
> > On Oct 28, 2023, at 12:31 PM, Justin Uberti <[e-mail]> wrote:
> >
> > 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
>
>
>