< draft-uberti-rtcweb-rfc8829bis-00.txt   draft-uberti-rtcweb-rfc8829bis-01.txt >
Network Working Group J. Uberti Network Working Group J. Uberti
Internet-Draft Clubhouse Internet-Draft Clubhouse
Obsoletes: 8829 (if approved) C. Jennings Obsoletes: 8829 (if approved) C. Jennings
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: 11 January 2022 E. Rescorla, Ed. Expires: 28 April 2022 E. Rescorla, Ed.
Mozilla Mozilla
10 July 2021 25 October 2021
JavaScript Session Establishment Protocol (JSEP) JavaScript Session Establishment Protocol (JSEP)
draft-uberti-rtcweb-rfc8829bis-00 draft-uberti-rtcweb-rfc8829bis-01
Abstract Abstract
This document describes the mechanisms for allowing a JavaScript This document describes the mechanisms for allowing a JavaScript
application to control the signaling plane of a multimedia session application to control the signaling plane of a multimedia session
via the interface specified in the W3C RTCPeerConnection API and via the interface specified in the W3C RTCPeerConnection API and
discusses how this relates to existing signaling protocols. discusses how this relates to existing signaling protocols.
This specification obsoletes RFC 8829. This specification obsoletes RFC 8829.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 January 2022. This Internet-Draft will expire on 28 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 7, line 7 skipping to change at page 7, line 7
increases the amount of work that the application needs to do; it increases the amount of work that the application needs to do; it
needs to know how to generate session descriptions from capabilities, needs to know how to generate session descriptions from capabilities,
and especially how to generate the correct answer from an arbitrary and especially how to generate the correct answer from an arbitrary
offer and the supported capabilities. While this could certainly be offer and the supported capabilities. While this could certainly be
addressed by using a library like the one mentioned above, it addressed by using a library like the one mentioned above, it
basically forces the use of said library even for a simple example. basically forces the use of said library even for a simple example.
Providing createOffer/createAnswer avoids this problem. Providing createOffer/createAnswer avoids this problem.
1.3. Changes from RFC 8829 1.3. Changes from RFC 8829
When [RFC8829] was published, an inconsistency regarding BUNDLE When [RFC8829] was published, inconsistencies regarding BUNDLE
[RFC8843] operation was identified concerning both the specification [RFC8843] operation were identified with regard to both the
text as well as implementation behavior. The former concern was specification text as well as implementation behavior. The former
addressed via an update to [RFC8843]. For the latter concern, it was concern was addressed via an update to [RFC8843]. For the latter
observed that some implementations implemented the "max-bundle" concern, it was observed that some implementations implemented the
bundle policy by assuming that bundling had already been negotiated, "max-bundle" bundle policy defined in [RFC8829] by assuming that
rather than marking "m=" sections as bundle-only as indicated by bundling had already been negotiated, rather than marking "m="
[RFC8829]. In order to prevent unexpected changes to applications sections as bundle-only as indicated by the specification. In order
relying on the pre-standard behavior, the decision was made to to prevent unexpected changes to applications relying on the pre-
deprecate the use of "max-bundle" and instead introduce a new "must- standard behavior, the decision was made to deprecate "max-bundle"
bundle" policy that, when selected, provides the correct behavior. and instead introduce an identically defined "must-bundle" policy
that, when selected, provides the behavior originally specified by
[RFC8829].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Semantics and Syntax 3. Semantics and Syntax
skipping to change at page 49, line 5 skipping to change at page 49, line 5
will be bundled into a preceding non-bundle-only media "m=" will be bundled into a preceding non-bundle-only media "m="
section. section.
The "a=group:BUNDLE" attribute MUST include the MID identifiers The "a=group:BUNDLE" attribute MUST include the MID identifiers
specified in the bundle group in the most recent answer, minus any specified in the bundle group in the most recent answer, minus any
"m=" sections that have been marked as rejected, plus any newly added "m=" sections that have been marked as rejected, plus any newly added
or re-enabled "m=" sections. In other words, the bundle attribute or re-enabled "m=" sections. In other words, the bundle attribute
MUST contain all "m=" sections that were previously bundled, as long MUST contain all "m=" sections that were previously bundled, as long
as they are still alive, as well as any new "m=" sections. as they are still alive, as well as any new "m=" sections.
Note that if bundling has been negotiated, unbundling is no longer
possible, and media sections will not be marked as bundle-only. This
is by design, but could cause issues in the rare case of sending a
subsequent offer as an initial offer to a non-bundle-aware endpoint
via Third Party Call Control (3PCC).
"a=group:LS" attributes are generated in the same way as for initial "a=group:LS" attributes are generated in the same way as for initial
offers, with the additional stipulation that any lip sync groups that offers, with the additional stipulation that any lip sync groups that
were present in the most recent answer MUST continue to exist and were present in the most recent answer MUST continue to exist and
MUST contain any previously existing MID identifiers, as long as the MUST contain any previously existing MID identifiers, as long as the
identified "m=" sections still exist and are not rejected, and the identified "m=" sections still exist and are not rejected, and the
group still contains at least two MID identifiers. This ensures that group still contains at least two MID identifiers. This ensures that
any synchronized "recvonly" "m=" sections continue to be synchronized any synchronized "recvonly" "m=" sections continue to be synchronized
in the new offer. in the new offer.
5.2.3. Options Handling 5.2.3. Options Handling
 End of changes. 6 change blocks. 
15 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/