Abstract <del> "Regular expressions" (regexps) are a set of related, widely implemented pattern languages used in data modeling formats and query languages that is available in many dialects.  This specification defines an interoperable flavor of regexps, I-Regexp. The present version -02 of this document is a more streamlined update of the original trial balloon, meant to determine whether this approach is useful for the JSONPath WG. </del>  1.  Data modeling formats (YANG, CDDL) as well as query languages (jsonpath) often need a regular expression (regexp) sublanguage. There are many dialects of regular expressions in use in platforms, Also, features of the target dialect such as capture groups may be triggered inadvertently, reducing performance. <del> The present specification defines an interoperable regexp flavor for matching, I-Regexp.  This flavor is a subset of XSD regexps.  It also comes with defined rules for converting the regexp into common parsing regexp dialects. 2. I-Regexps should handle the vast majority of practical cases where a matching regexp is needed in a data model specification or a query language expression. A brief survey of published RFCs yielded the regexp patterns in Appendix A (with no attempt at completeness).  These should be covered by I-Regexps, both syntactically and with their intended semantics. 3. </del>  XSD Regexps are relatively easy to implement or map to widely implemented parsing regexp dialects, with a small number of notable specification for the "flex" tool; this is intended to be close to "d", "p{L}", "w" in an ASCII subset.) <del> 4. The syntax of I-Regexp is defined by the ABNF specification in iregexp-abnf. This syntax is a subset of that of XSD2; the semantics of all the constructs allowed by this ABNF grammar are the same as those in XSD2. About a third of the complexity of this ABNF grammar comes from going into details on the Unicode IsCategory classes.  Additional complexity stems from the way hyphens can be used inside character classes to denote ranges; the grammar deliberately excludes questionable usage such as "/[a-z-A-Z]/". *Issue*: This is essentially XSD regexp without character class subtraction and multi-character escapes.  There might be further potential for simplification in IsBlock (leave out) and possibly in the rather large part for IsCategory as well.  The ABNF has been automatically generated and maybe could use some polishing. The ABNF has been verified against rfcs, but a wider corpus of regular expressions should be examined. 5. (TBD; these mappings need to be thoroughly verified.) 5.1. Any I-Regexp also is an XSD Regexp XSD2, so the mapping is an identity function. 5.2. Perform the following steps on an I-Regexp to obtain an ECMAScript regexp ECMA-262: Replace any dots (".") outside character classes (first alternative of "charClass" production) by "[^nr]". Envelope the result in "^" and "$". Note that where a regexp literal is required, this needs to enclose the actual regexp in "/". The performance can be increased by turning parenthesized regexps (production "atom") into "(?:...)" constructions. 5.3. Perform the same steps as in toESreg to obtain a valid regexp in PCRE PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is: Envelope the result in "A" and "z". Again, the performance can be increased by turning parenthesized regexps (production "atom") into "(?:...)" constructions. 5.4. (Please submit the mapping needed for your favorite kind of regexp.) 6. </del>  This document makes no requests of IANA. <del> 7. </del>  TBD

This has had the motivation and background material moved into new sections after the syntax and semantics. The opening section have been RFC-i-fied a bit, with one MUST each for syntax and semantics.

Abstract  <ins> This document specifies I-Regexp, a flavor of regular expressions that is limited in scope with the goal of interoperation across many different regular-expression libraries. </ins> 1. <ins> The present specification defines an interoperable regular expression flavor, I-Regexp. This document uses the abbreviation "regexp" for regular expression. "I-Regexp" is used as a noun meaning a character string which conforms to the requirements in this specification; the plural is "I-Regexps". I-Regexp does not provide advanced regexp features such as capture groups or backreferences.  It supports only a Boolean matching capability, i.e. testing whether a given regexp matches a given piece of text. I-Regexp is a subset of XSD regexps. This document includes rules for converting I-Regexps for use with several well-known regexp libraries. 2. I-Regexps should handle the vast majority of practical cases where a matching regexp is needed in a data model specification or a query language expression. A brief survey of published RFCs yielded the regexp patterns in Appendix A (with no attempt at completeness).  These should be covered by I-Regexps, both syntactically and with their intended semantics. 3. An I-Regexp MUST conform to the ABNF specification in iregexp-abnf. This is essentially XSD regexp without character class subtraction and multi-character escapes. *Issue*: There might be further potential for simplification in IsBlock (leave out) and possibly in the rather large part for IsCategory as well.  The ABNF has been automatically generated and maybe could use some polishing.  The ABNF has been verified against rfcs, but a wider corpus of regular expressions should be examined.  About a third of the complexity of this ABNF grammar comes from going into details on the Unicode IsCategory classes. Additional complexity stems from the way hyphens can be used inside character classes to denote ranges; the grammar deliberately excludes questionable usage such as "/[a-z-A-Z]/". 4. This syntax is a subset of that of XSD2.  Implementations which interpret I-Regexps MUST yield Boolean results as specified in XSD2. 5. (TBD; these mappings need to be thoroughly verified.) 5.1. Any I-Regexp also is an XSD Regexp XSD2, so the mapping is an identity function. 5.2. Perform the following steps on an I-Regexp to obtain an ECMAScript regexp ECMA-262: Replace any dots (".") outside character classes (first alternative of "charClass" production) by "[^nr]". Envelope the result in "^" and "$". Note that where a regexp literal is required, this needs to enclose the actual regexp in "/". The performance can be increased by turning parenthesized regexps (production "atom") into "(?:...)" constructions. 5.3. Perform the same steps as in toESreg to obtain a valid regexp in PCRE PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is: Envelope the result in "A" and "z". Again, the performance can be increased by turning parenthesized regexps (production "atom") into "(?:...)" constructions. 5.4. (Please submit the mapping needed for your favorite kind of regexp.) 6. </ins> Data modeling formats (YANG, CDDL) as well as query languages (jsonpath) often need a regular expression (regexp) sublanguage. There are many dialects of regular expressions in use in platforms, Also, features of the target dialect such as capture groups may be triggered inadvertently, reducing performance.  <ins> 6.1. </ins> XSD Regexps are relatively easy to implement or map to widely implemented parsing regexp dialects, with a small number of notable specification for the "flex" tool; this is intended to be close to "d", "p{L}", "w" in an ASCII subset.)  <ins> 7. </ins> This document makes no requests of IANA.  <ins> 8. </ins> TBD


"[^]", which according to this grammar would parse as a positive character class containing the single character "^". <del> This is essentially XSD regexp without character class subtraction and multi-character escapes such as "s", "S", and "w". </del>  An I-Regexp implementation MUST be a complete implementation of this limited subset.  In particular, full Unicode support is REQUIRED; the regexp flavors.  Thus, they are omitted from I-Regexp. Not all regexp implementations support accesses to Unicode tables <del> that enable executing on constructs such as "p{IsCoptic}", although the "p"/"P" feature in general is now quite widely available.  While in principle it's possible to translate these into codepoint-range matches, this also requires access to those tables.  Thus, regexp libraries in severely constrained environments may not be able to support I-Regexp conformance. </del>  7.

I think it is better to support script names than block names for and . Unicode block names are not supported by regexp implementations an interoperable way. Block names as specified in URL allow ASCII alpha-numerics, hyphens and spec. Unicode says these names are supposed to be matched using URL (which says to ignore case, whitespace, underscore, hyphens, and any initial prefix string "is"). But implementations don't do this and compare names using a wide variety of different rules (as partially described by "Unicode blocks" section of https://www.regular-URL). Usage of block names can easily be replaced by ranges. Furthermore, block names are not covered by the Unicode stability policy. Scripts names don't have such a wide range of characters (there are also 4-char short script names) and scripts are generally preferable to blocks for regexps as explained here: URL Script is in the minimal list of properties that Unicode requires but block is not URL
Thank you! Very useful input. We are having an interim meeting (per web conference) of the JSONPath WG at this very moment; I'll look at this later today.
I just looked again at XSD and see that sadly it doesn't support scripts in . Every major regex implementation that I am aware of that does Unicode and does support scripts (Go, PCRE, Java, C#, Ruby). So if XSD compatibility is crucial (not sure why it would be at this point), my suggestion would be just to get rid of blocks. One could argue that supporting only the general category in is consistent with not supporting character set intersection/difference: once you have multiple things (e.g. script and category), you really need to be able to have intersections/differences of them.

"[^]", which according to this grammar would parse as a positive character class containing the single character "^".  <ins> This is essentially XSD regexp without character class subtraction, without multi-character escapes such as "s", "S", and "w", and without Unicode blocks. </ins> An I-Regexp implementation MUST be a complete implementation of this limited subset.  In particular, full Unicode support is REQUIRED; the regexp flavors.  Thus, they are omitted from I-Regexp. Not all regexp implementations support accesses to Unicode tables  <ins> that enable executing constructs such as "p{Nd}", although the "p"/"P" feature in general is now quite widely available.  While in principle it's possible to translate these into character-class matches, this also requires access to those tables.  Thus, regexp libraries in severely constrained environments may not be able to support I-Regexp conformance. </ins> 7.


This specification describes an interoperable regular expression flavor, I-Regexp. <del> This document uses the abbreviation "regexp" for what are usually called regular expressions in programming.  "I-Regexp" is used as a noun meaning a character string which conforms to the requirements in this specification; the plural is "I-Regexps". I-Regexp does not provide advanced regexp features such as capture groups, lookahead, or backreferences.  It supports only a Boolean matching capability, i.e., testing whether a given regexp matches a given piece of text. </del>  I-Regexp supports the entire repertoire of Unicode characters. <del> I-Regexp is a subset of XSD regexps XSD-2. </del>  <del> This document includes rules for converting I-Regexps for use with several well-known regexp libraries. </del>  1.1.  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in matching regexp is needed in a data model specification or a query language expression. <del> A brief survey of published RFCs yielded the regexp patterns in Appendix A (with no attempt at completeness).  With certain exceptions as discussed there, these should be covered by I-Regexps, both syntactically and with their intended semantics. </del>  3. 5. <del> (TBD; these mappings need to be further verified in implementation work.) </del>  5.1.  Any I-Regexp also is an XSD Regexp XSD-2, so the mapping is an identity function. this specification an implementation of XSD 1.0 regexps is equivalent to an implementation of XSD 1.1 regexps. <del> 5.2. </del>  Perform the following steps on an I-Regexp to obtain an ECMAScript regexp ECMA-262: Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/". <del> 5.3. </del>  Perform the same steps as in toESreg to obtain a valid regexp in PCRE PCRE2, the Go programming language RE2, and the Ruby programming

Signed-off-by: Tim Bray Based on our email thread with James, and a couple of minor editorial touch-ups.
LGTM, thanks.

This specification describes an interoperable regular expression flavor, I-Regexp.  <ins> I-Regexp does not provide advanced regular expression features such as capture groups, lookahead, or backreferences.  It supports only a Boolean matching capability, i.e., testing whether a given regular expression matches a given piece of text. </ins> I-Regexp supports the entire repertoire of Unicode characters.  <ins> I-Regexp is a subset of XSD regular expressions XSD-2. </ins>  <ins> This document includes guidance for converting I-Regexps for use with several well-known regular expression idioms. </ins> 1.1. <ins> This document uses the abbreviation "regexp" for what are usually called regular expressions in programming.  "I-Regexp" is used as a noun meaning a character string which conforms to the requirements in this specification; the plural is "I-Regexps". </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in matching regexp is needed in a data model specification or a query language expression.  <ins> The editors of this document conducted a survey of the regexp syntax used in published RFCs.  All examples found there should be covered by I-Regexps, both syntactically and with their intended semantics. The exception is the use of multi-character escapes, for which workaround guidance is provided in mapping. </ins> 3. 5.  <ins> The material in this section is non-normative, provided as guidance to developers who want to use I-Regexps in the context of other regular expression dialects. </ins> 5.1. <ins> Common multi-character escapes (MCEs), and character classes built around them, which are not supported in I-Regexp, can usually be replaced as shown in tbl-sub. Note that the semantics of "d" in XSD regular expressions is that of "p{Nd}"; however, this would include all Unicode characters that are digits in various writing systems, which is almost certainly not what is required in IETF publications. The construct "p{IsBasicLatin}" is essentially a reference to legacy ASCII, it can be replaced by the character class "[u0000-u007f]". 5.2. </ins> Any I-Regexp also is an XSD Regexp XSD-2, so the mapping is an identity function. this specification an implementation of XSD 1.0 regexps is equivalent to an implementation of XSD 1.1 regexps.  <ins> 5.3. </ins> Perform the following steps on an I-Regexp to obtain an ECMAScript regexp ECMA-262: Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/".  <ins> 5.4. </ins> Perform the same steps as in toESreg to obtain a valid regexp in PCRE PCRE2, the Go programming language RE2, and the Ruby programming


For any dots (".") outside character classes (first alternative of "charClass" production): replace dot by "[^nr]". <del> Envelope the result in "^" and "$". </del>  Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/". PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is: <del> Enclose the regexp in "A" and "z". </del>  6.

Clarifications in conversion to platform regexps.
Looks plausible but I don't know these regexps well enough to approve.

For any dots (".") outside character classes (first alternative of "charClass" production): replace dot by "[^nr]".  <ins> Envelope the result in "^(?:" and ")$". The ECMAScript regexp is to be interpreted as a Unicode pattern ("u" flag; see Section 21.2.2 "Pattern Semantics" of ECMA-262). </ins> Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/". PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is:  <ins> Enclose the regexp in "A(?:" and ")z". </ins> 6.


1. <del> The present specification defines an interoperable regular expression </del>  flavor, I-Regexp. This document uses the abbreviation "regexp" for what are usually matching capability, i.e., testing whether a given regexp matches a given piece of text.  I-Regexp is a subset of XSD regexps XSD-2. This document includes rules for converting I-Regexps for use with BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  2. I-Regexps should handle the vast majority of practical cases where a character class containing the single character "^". This is essentially XSD regexp without character class subtraction <del> and multi-character escapes. </del>  An I-Regexp implementation MUST be a complete implementation of this limited subset.  In particular, full Unicode support is REQUIRED; the such as ASCII and MUST support the Unicode character property set in character classes. <del> : The ABNF has been automatically generated and maybe could use some further polishing.  The ABNF has been verified against rfcs, but a wider corpus of regular expressions will need to be examined.  Note that about a third of the complexity of this ABNF grammar comes from going into details on the Unicode IsCategory classes.  Additional complexity stems from the way hyphens can be used inside character classes to denote ranges; the grammar deliberately excludes questionable usage such as "/[a-z-A-Z]/". </del> 4. This syntax is a subset of that of XSD-2.  Implementations which Envelope the result in "^" and "$". <del> Note that where a regexp literal is required, this needs to enclose the actual regexp in "/". The performance of an ECMAScript matcher can be increased by turning parenthesized regexps (last choice in production "atom") into "(?:...)" constructions. </del>  5.3. PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is: <del> Envelope the result in "A" and "z". Again, the performance can be increased by turning parenthesized regexps (production "atom") into "(?:...)" constructions. 5.4. (Please submit the mapping needed for your favorite kind of regexp.) </del>  6. <del> Data modeling formats (YANG, CDDL) as well as query languages (jsonpath) often need a regular expression (regexp) sublanguage. There are many dialects of regular expressions in use in platforms, programming languages, and data modeling formats. </del> While regular expressions originally were intended to describe a <del> formal language, i.e., to provide a Boolean matching function, they have turned into parsing functions for many applications, with capture groups, greedy/lazy/possessive variants, etc.  Language features such as backreferences allow specifying languages that actually are context-free (Chomsky type 2) instead of the regular languages (Chomsky type 3) that regular expressions are named for. YANG (RFC7950) and CDDL (RFC8610) have adopted the regexp language from W3C Schema XSD-2.  XSD regexp is a pure matching language, i.e., XSD regexps can be used to match a string against them and yield a simple true or false result.  XSD regexps are not as widely implemented as programming language regexp dialects such as those of Perl, Python, Ruby, Go RE2, or JavaScript (ECMAScript) ECMA-262.  The latter are often in a state of continuous development; in the best case (ECMAScript) there is a complete specification which however is highly complex (Section 21.2 of ECMA-262 comprises 62 pages) and evolves on a yearly timeline, with significant additions.  Regexp dialects such as PCRE PCRE2 have evolved to cover a common set of functions available in parsing regexp dialects, offered in a widely available library. With continuing accretion of complex features, parsing regexp libraries have become susceptible to bugs and performance degradation, in particular those that can be exploited in Denial of Service (DoS) attacks.  The library RE2 that is compatible with Go language regexps strives to be immune to DoS attacks, making it attractive to applications such as query languages where an attacker could control the input.  The problem remains that other bugs in such libraries can lead to exploitable vulnerabilities; at the time of writing, the Common Vulnerabilities and Exposures (CVE) system has 131 entries that mention the word "regex" REGEX-CVE (not all, but many of which are such bugs, with 23 matches for arbitrary code execution). Implementations of YANG and CDDL often struggle with providing true XSD regexps; some instead cheat by providing one of the parsing regexp varieties, sometimes without even advertising this fact. A matching regexp that does not use the more complex XSD features (subsetting) can usually be converted into a parsing regexp of many dialects by simply surrounding it with anchors of that dialect (e.g., "^" or "A" and "$" or "z").  If the original matching regexps exceed the envelope of compatibility between dialects, this can lead to interoperability problems, or, worse, security vulnerabilities. Also, features of the target dialect such as capture groups may be triggered inadvertently, reducing performance. </del>  6.1. XSD regexps are relatively easy to implement or map to widely <del> implemented parsing regexp dialects, with a small number of notable exceptions: </del>  Character class subtraction.  This is a very useful feature in many specifications, but it is unfortunately mostly absent from <del> parsing regexp dialects. Discussion: This absence can often be addressed by translating character class subtraction into positive character classes (possibly requiring significant expansion) and/or inserting negative lookahead assertions (which are not universally supported by regexp libraries, most notably not by RE2 RE2).  This specification therefore opts for leaving out character class subtraction. </del>  Multi-character escapes.  "d", "w", "s" and their uppercase <del> equivalents (complement classes) exhibit a large amount of variation between regexp flavors.  (E.g., predefined character classes such as "w" may be meant to be ASCII only, or they may encompass all letters and digits defined in Unicode.  The latter is usually of interest in the application of query languages to text in human languages, while the former is of interest to a subset of applications in data model specifications.) Unicode.  While there is no doubt that a regexp flavor meant to last needs to be Unicode enabled, there are a number of aspects of this that need discussion.  Not all regexp implementations that one might want to map I-Regexps into will support accesses to Unicode tables that enable executing on constructs such as "p{IsCoptic}", for mapping into such implementations, translation needs to be provided.  Fortunately, the "p"/"P" feature in general is now quite widely available. Discussion: The ASCII focus can partially be addressed by adding a constraint outside the regexp that the matched text has to be ASCII in the first place.  This often is all that is needed where regexps are used to define lexical elements of a computer language.  This reduces the size of the Unicode tables required in such a constrained implementation considerably.  (In rfcs, RFC 6643 contains a lone instance of "p{IsBasicLatin}{0,255}", which is needed to describe a transition from a legacy character set to Unicode.  RFC2622 contains "[[:digit:]]", "[[:alpha:]]", "[[:alnum:]]", albeit in a specification for the "flex" tool; this is intended to be close to "d", "p{L}", "w" in an ASCII subset.) </del>  7. 8. <del> As discussed in background, more complex regexp libraries are likely to contain exploitable bugs leading to crashes and remote code execution.  There is also the problem that such libraries often have hard to predict performance characteristics, leading to attack vectors that overload an implementation by matching against an expensive attacker-controlled regexp. </del>  I-Regexps have been designed to allow implementation in a way that is resilient to both threats; this objective needs to be addressed

Implemented the changes as suggested in Issue
The purpose of this issue is to start discussion about how to turn this into a completed draft to send to the IESG. Perhaps the most important issue is how much of the explanatory and motivational material to leave in. There is a case to be made for taking all of it out, so you get a nice short RFC that just says what I-Regexp is. So here's my initial straw-person proposal on what should be removed and changed: Remove the "issues" para in Section 3. Section 5.2, 5.3, remove the trailing note about improving performance. This is an implementation artifact, no? Section 6. Replace with a single short paragraph somewhat as follows: "While regular expressions originally were intended to describe a formal language, i.e., to provide a Boolean matching function, they have turned into parsing functions for many applications. With this accretion of features, parsing regexp libraries have become susceptible to bugs and performance degradation, in particular those that can be exploited in Denial of Service (DoS) attacks in the case where an attacker controls the regex submitted for processing. I-Regexp is designed to offer interoperability, and to be less vulnerable to such attacks, with the trade-off that its only function is to offer a boolean response as to whether a character sequence is matched by a regex. [ If we really feel that other parts of this discussion add value, they could migrate into an appendix.] 6.1 - cut this down, retaining the first para of the first bullet point, the first sentence of the second bullet point, and that's all. The Unicode discussion can migrate into Appendix A.
Resolved by

1.  <ins> This specification describes an interoperable regular expression </ins> flavor, I-Regexp. This document uses the abbreviation "regexp" for what are usually matching capability, i.e., testing whether a given regexp matches a given piece of text. <ins> I-Regexp supports the entire repertoire of Unicode characters. </ins> I-Regexp is a subset of XSD regexps XSD-2. This document includes rules for converting I-Regexps for use with BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> The grammatical rules in this document are to be interpreted as ABNF, as described in RFC5234. </ins> 2. I-Regexps should handle the vast majority of practical cases where a character class containing the single character "^". This is essentially XSD regexp without character class subtraction  <ins> and multi-character escapes such as "s", "S", and "w". </ins> An I-Regexp implementation MUST be a complete implementation of this limited subset.  In particular, full Unicode support is REQUIRED; the such as ASCII and MUST support the Unicode character property set in character classes.  4. This syntax is a subset of that of XSD-2.  Implementations which Envelope the result in "^" and "$".  <ins> Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/". </ins> 5.3. PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is:  <ins> Enclose the regexp in "A" and "z". </ins> 6.  While regular expressions originally were intended to describe a  <ins> formal language to support a Boolean matching function, they have been enhanced with parsing functions that support the extraction and replacement of arbitrary portions of the matched text.  With this accretion of features, parsing regexp libraries have become more susceptible to bugs and surprising performance degradations which can be exploited in Denial of Service attacks by an attacker who controls the regexp submitted for processing.  I-Regexp is designed to offer interoperability, and to be less vulnerable to such attacks, with the trade-off that its only function is to offer a boolean response as to whether a character sequence is matched by a regexp. </ins> 6.1. XSD regexps are relatively easy to implement or map to widely  <ins> implemented parsing regexp dialects, with these notable exceptions: </ins> Character class subtraction.  This is a very useful feature in many specifications, but it is unfortunately mostly absent from  <ins> parsing regexp dialects.  Thus, it is omitted from I-Regexp. </ins> Multi-character escapes.  "d", "w", "s" and their uppercase  <ins> complement classes exhibit a large amount of variation between regexp flavors.  Thus, they are omitted from I-Regexp. Not all regexp implementations support accesses to Unicode tables that enable executing on constructs such as "p{IsCoptic}", although the "p"/"P" feature in general is now quite widely available.  While in principle it's possible to translate these into codepoint-range matches, this also requires access to those tables.  Thus, regexp libraries in severely constrained environments may not be able to support I-Regexp conformance. </ins> 7. 8.  <ins> As discussed in background, more complex regexp libraries may contain exploitable bugs leading to crashes and remote code execution.  There is also the problem that such libraries often have hard-to-predict performance characteristics, leading to attacks that overload an implementation by matching against an expensive attacker-controlled regexp. </ins> I-Regexps have been designed to allow implementation in a way that is resilient to both threats; this objective needs to be addressed


the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME must be generated in <del> accordance with draft-rescorla-random-cname-00.  [OPEN ISSUE: How are CNAMEs specified for MSTs?  Are they randomly generated for each MediaStream?  If so, can two MediaStreams be synced?] </del>  If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in "a=ice-lite" Note that when BUNDLE is used, any additional attributes that are <del> added MUST follow the advice in I-D.nandakumar-mmusic-sdp-mux- attributes on how those attributes interact with BUNDLE. </del>  5.2.2.

Justin, what are you looking for me to do here?
? This is ancient.
it seems this was dealt with long ago. I have no idea why it says I assigned it to EKR and hour ago ?
12) [rfced] Section 4.1.8.1: We had trouble with this sentence. If neither suggestion below is correct, please clarify. Original: While this could also be done with a "sendonly" pranswer, followed by a "sendrecv" answer, the initial pranswer leaves the offer-answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer, if followed by a "sendrecv" answer the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time. Suggestion : While this could also be done with a "sendonly" pranswer followed by a "sendrecv" answer, the initial pranswer leaves the offer/answer exchange open, which means that the caller cannot send an updated offer during this time.
suggestion seems right
From EMAIL: Question 1: Should this be interpreted literally, to mean "the next call, and only the next call to createOffer will generate new ICE credentials"? If so, there are various situations wherein one could encounter unexpected behavior. For example: Before createOffer is called, a remote offer is received that triggers an ICE restart. Should the next call to createOffer trigger another, superfluous ICE restart? createOffer is called twice, without setting the local description (and kicking off a new gathering phase). Should the second call generate new credentials, or only the first? I would propose a slight change, such as: "this will cause subsequent calls to createOffer to generate new ICE credentials, until a new gathering phase has started." This would more clearly represent the intent of the original rule, in my opinion. Question 2: The next paragraph states "Any changes to the ICE candidate policy also affect the next gathering phase, in similar fashion to the server changes described above." Does this mean that changes to the candidate policy will also cause an ICE restart, according to the same rules? I assume so, but figure it's worth asking.
On , any changes should set a needs-ice-restart bit, which is only cleared by setLD with new ICE credentials (although, possibly only by setLD + setRD, since the setLD could be rolled back) On , if the ICE policy is being made more restrictive, no ICE restart is needed. Obviously if less restrictive, then the needs-ice-restart bit will be set.
Both you proposed resolutions look good to me

the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME must be generated in  <ins> accordance with RFC7022.  [OPEN ISSUE: How are CNAMEs specified for MSTs?  Are they randomly generated for each MediaStream?  If so, can two MediaStreams be synced?] </ins> If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in "a=ice-lite" Note that when BUNDLE is used, any additional attributes that are  <ins> added MUST follow the advice in I-D.ietf-mmusic-sdp-mux-attributes on how those attributes interact with BUNDLE. </ins> 5.2.2.


values. In addition, various RFCs put different conditions on the format of <del> offers versus answers.  For example, a offer may propose an arbitrary number of media streams (i.e. m= sections), but an answer must contain the exact same number as the offer. </del>  Lastly, while the exact media parameters are only known only after an offer and an answer have been exchanged, it is possible for the in response to changes in the ICE configuration. When a new gathering phase starts, the ICE Agent will notify the <del> application that gathering is occurring through a callback.  Then, when each new ICE candidate becomes available, the ICE Agent will supply it to the application via an additional callback; these candidates will also automatically be added to the local session description.  Finally, when all candidates have been gathered, a callback will be dispatched to signal that the gathering process is complete. </del>  Note that gathering phases only gather the candidates needed by new/recycled/restarting m= lines; other m= lines continue to use to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.  If there are candidates in the pool, they SHOULD be handed to the application immediately via <del> the ICE candidate callback.  If the pool becomes depleted, either </del>  because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the remaining candidates are gathered as usual. 5.3.3. <del> The createOffer method takes as a parameter an RTCAnswerOptions </del>  object.  Special processing is performed when generating a SDP description if the following constraints are present. Changes MUST NOT be silently ignored. The following elements of the SDP media description MUST NOT be <del> changed between the createOffer and the setLocalDescription, since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </del>  The number, type and port number of m= lines. The set of ICE candidates and their parameters (a=candidate).  The following modifications, if done by the browser to a description between createOffer/createAnswer and the setLocalDescription, MUST be honored by the browser:

Editorial suggestions, if helpful use, if not just close the PR.
fine with me to merge this
LGTM

values. In addition, various RFCs put different conditions on the format of  <ins> offers versus answers.  For example, an offer may propose an arbitrary number of media streams (i.e. m= sections), but an answer must contain the exact same number as the offer. </ins> Lastly, while the exact media parameters are only known only after an offer and an answer have been exchanged, it is possible for the in response to changes in the ICE configuration. When a new gathering phase starts, the ICE Agent will notify the  <ins> application that gathering is occurring through an event.  Then, when each new ICE candidate becomes available, the ICE Agent will supply it to the application via an additional event; these candidates will also automatically be added to the local session description. Finally, when all candidates have been gathered, an event will be dispatched to signal that the gathering process is complete. </ins> Note that gathering phases only gather the candidates needed by new/recycled/restarting m= lines; other m= lines continue to use to gather the needed ICE candidates, it SHOULD start by checking if any candidates are available in the pool.  If there are candidates in the pool, they SHOULD be handed to the application immediately via  <ins> the ICE candidate event.  If the pool becomes depleted, either </ins> because a larger-than-expected number of ICE components is used, or because the pool has not had enough time to gather candidates, the remaining candidates are gathered as usual. 5.3.3.  <ins> The createAnswer method takes as a parameter an RTCAnswerOptions </ins> object.  Special processing is performed when generating a SDP description if the following constraints are present. Changes MUST NOT be silently ignored. The following elements of the SDP media description MUST NOT be  <ins> changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </ins> The number, type and port number of m= lines. The set of ICE candidates and their parameters (a=candidate). <ins> The DTLS fingerprint(s) (a=fingerprint). </ins> The following modifications, if done by the browser to a description between createOffer/createAnswer and the setLocalDescription, MUST be honored by the browser:


JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer API.  The <del> application then uses that offer to set up its local config via the setLocalDescription API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription API. </del>  To complete the offer/answer exchange, the remote party uses the createAnswer API to generate an appropriate answer, applies it using decoupling of the ICE and signaling state machines allows it to accommodate either model. <del> Through its abstraction of signaling, the JSEP approach does require the application to be aware of the signaling process.  While the application does not need to understand the contents of session descriptions to set up a call, the application must call the right APIs at the right times, convert the session descriptions and ICE information into the defined messages of its chosen signaling protocol, and perform the reverse conversion on the messages it receives from the other side. </del>  One way to make life easier for the application is to provide a JavaScript library that hides this complexity from the developer; willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; some parameters are <del> declarative, and the remote side MUST either accept them or reject </del>  them altogether.  An example of such a parameter is the TLS fingerprints RFC8122 as used in the context of DTLS RFC6347; these fingerprints are calculated based on the local certificate(s) offered RFC8839.  Note that this field does not contain an "a=" prefix, as indicated in the following example: <del> The IceCandidate object contains a field to indicate which ICE ufrag it is associated with, as defined in RFC8839.  This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts.  If this field is absent in a received IceCandidate (perhaps when communicating with a non-JSEP endpoint), the most recently received session description is assumed. </del>  The IceCandidate object also contains fields to indicate which "m=" section it is associated with, which can be identified in one of two 3.6.1. <del> The receiver will first intersect any known local limits (e.g., hardware decoder capabilities, local policy) to determine the </del>  absolute minimum and maximum sizes it can receive.  If there are no known local limits, the "a=imageattr" attribute SHOULD be omitted. If these local limits preclude receiving any video, i.e., the The createOffer method generates a blob of SDP that contains an offer per RFC3264 with the supported configurations for the session, including descriptions of the media added to this PeerConnection, the <del> codec/RTP/RTCP options supported by this implementation, and any candidates that have been gathered by the ICE agent.  An options </del>  parameter may be supplied to provide additional control over the generated offer.  This options parameter allows an application to trigger an ICE restart, for the purpose of reestablishing 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 <del> an initial offer from the document that specifies the given SDP line. The exact handling of initial offer generation is detailed in </del>  sec.initial-offers below. In the event createOffer is called after the session is established, 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 <del> for generating an answer from the document that specifies the given SDP line.  The exact handling of answer generation is detailed in sec.generating-an-answer below. </del>  Session descriptions generated by createAnswer MUST be immediately usable by setLocalDescription; like createOffer, the returned

…or already fixed. NAME Change in normative text (previous ART AD requested it), please review.
LGTM, approved.
eom
LGTMOne minor comment.

JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer API.  The  <ins> application then uses that offer to set up its local configuration via the setLocalDescription API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription API. </ins> To complete the offer/answer exchange, the remote party uses the createAnswer API to generate an appropriate answer, applies it using decoupling of the ICE and signaling state machines allows it to accommodate either model.  <ins> Although it abstracts signaling, the JSEP approach requires that the application be aware of the signaling process.  While the application does not need to understand the contents of session descriptions to set up a call, the application must call the right APIs at the right times, convert the session descriptions and ICE information into the defined messages of its chosen signaling protocol, and perform the reverse conversion on the messages it receives from the other side. </ins> One way to make life easier for the application is to provide a JavaScript library that hides this complexity from the developer; willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; some parameters are  <ins> declarative, and the remote side must either accept them or reject </ins> them altogether.  An example of such a parameter is the TLS fingerprints RFC8122 as used in the context of DTLS RFC6347; these fingerprints are calculated based on the local certificate(s) offered RFC8839.  Note that this field does not contain an "a=" prefix, as indicated in the following example:  <ins> The IceCandidate object contains a field to indicate which ICE username fragment (ufrag) it is associated with, as defined in RFC8839.  This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts.  If this field is absent in a received IceCandidate (perhaps when communicating with a non-JSEP endpoint), the most recently received session description is assumed. </ins> The IceCandidate object also contains fields to indicate which "m=" section it is associated with, which can be identified in one of two 3.6.1.  <ins> The receiver will first combine any known local limits (e.g., hardware decoder capabilities or local policy) to determine the </ins> absolute minimum and maximum sizes it can receive.  If there are no known local limits, the "a=imageattr" attribute SHOULD be omitted. If these local limits preclude receiving any video, i.e., the The createOffer method generates a blob of SDP that contains an offer per RFC3264 with the supported configurations for the session, including descriptions of the media added to this PeerConnection, the  <ins> codec, RTP, and RTCP options supported by this implementation, and any candidates that have been gathered by the ICE agent.  An options </ins> parameter may be supplied to provide additional control over the generated offer.  This options parameter allows an application to trigger an ICE restart, for the purpose of reestablishing 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  <ins> an initial offer from the specification that defines the given SDP line.  The exact handling of initial offer generation is detailed in </ins> sec.initial-offers below. In the event createOffer is called after the session is established, 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  <ins> for generating an answer from the specification that defines the given SDP line.  The exact handling of answer generation is detailed in sec.generating-an-answer below. </ins> Session descriptions generated by createAnswer MUST be immediately usable by setLocalDescription; like createOffer, the returned


lists each desired encoding, and no "recv" simulcast stream description.  The "m=" section will also include an "a=rid" attribute for each encoding, as specified in RFC8851; the use of Restriction <del> Identifiers (RIDs) allows the individual encodings to be disambiguated even though they are all part of the same "m=" section. </del>  3.8. Once the proper "m=" section or sections are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the "m=" section(s) and further processing of the RTP/RTCP is done at the <del> RtpTransceiver level.  This includes using RID RFC8851 to distinguish between multiple encoded streams, as well as to determine which </del>  Source RTP stream should be repaired by a given redundancy RTP stream.

This also adds in a sentence about using the MID header extension in outgoing streams, which was previously omitted despite there being a corresponding sentence for incoming streams.
The comment "[rfced] Please let us know if any changes are needed for the..." should also be removed.
AUTH48 on this document started with sixty [rfced] questions sent to the authors (NAME NAME NAME 2020 July 7. These questions were added as GitHub issues through . Follow on issues were created (in particular, splitting issues and ) to isolate some of the questions and to review normative text (). When PR is merged, all AUTH48 [rfced] questions will have been addressed, but there are some remaining XML comments that need to be removed.
This is sort of nuts but LGTM

lists each desired encoding, and no "recv" simulcast stream description.  The "m=" section will also include an "a=rid" attribute for each encoding, as specified in RFC8851; the use of Restriction  <ins> Identifiers (RIDs, also called rid-ids or RtpStreamIds) allows the individual encodings to be disambiguated even though they are all part of the same "m=" section. </ins> 3.8. Once the proper "m=" section or sections are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the "m=" section(s) and further processing of the RTP/RTCP is done at the  <ins> RtpTransceiver level.  This includes using the RID mechanism RFC8851 and its associated RtpStreamId and RepairedRtpStreamId identifiers to distinguish between multiple encoded streams and determine which </ins> Source RTP stream should be repaired by a given redundancy RTP stream.


additional offer/answer exchanges. Regarding ICE RFC8445, JSEP decouples the ICE state machine from the <del> overall signaling state machine, as the ICE state machine must remain in the JSEP implementation, because only the implementation has the </del>  necessary knowledge of candidates and other transport information. Performing this separation provides additional flexibility in protocols that decouple session descriptions from transport.  For provisional answers. In RFC3264, the constraint at the signaling level is that only one <del> offer can be outstanding for a given session, but at the media stack level, a new offer can be generated at any point.  For example, when using SIP for signaling, if one offer is sent and is then canceled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer.  To support this, the JSEP media layer can provide an offer via the createOffer method whenever the JavaScript application needs one for the signaling.  The answerer can send back zero or more provisional answers and then finally end the offer/answer exchange by sending a final answer.  The state machine for this is as follows: </del>  Aside from these state transitions, there is no other difference between the handling of provisional ("pranswer") and final ("answer") The createAnswer method generates a blob of SDP that contains an SDP answer per RFC3264 with the supported configuration for the session that is compatible with the parameters supplied in the most recent <del> call to setRemoteDescription, which MUST have been called prior to calling createAnswer.  Like createOffer, the returned blob contains descriptions of the media added to this PeerConnection, the codec/RTP/RTCP options negotiated for this session, and any </del>  candidates that have been gathered by the ICE agent.  An options parameter may be supplied to provide additional control over the generated answer. section. Each "m=" section, provided it is not marked as bundle-only, MUST <del> generate a unique set of ICE credentials and gather its own unique set of ICE candidates.  Bundle-only "m=" sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. </del>  For DTLS, all "m=" sections MUST use any and all certificates that have been specified for the PeerConnection; as a result, they MUST The example in sec.detailed-example shows a more involved case of "LS" group generation. <del> The next step is to generate "m=" sections for each "m=" section that is present in the remote offer, as specified in RFC3264.  For the purposes of this discussion, any session-level attributes in the </del>  offer that are also valid as media-level attributes are considered to be present in each "m=" section.  Each offered "m=" section will have an associated RtpTransceiver, as described in sec.applying-a-remote-

This includes Removing my postal address. Mozilla closed that office. small editorial changes Removing bogus whitespace.
NAME PTAL
NAME I think I've got your changes and we are ready to land?
LGTM

additional offer/answer exchanges. Regarding ICE RFC8445, JSEP decouples the ICE state machine from the  <ins> overall signaling state machine.  The ICE state machine must remain in the JSEP implementation because only the implementation has the </ins> necessary knowledge of candidates and other transport information. Performing this separation provides additional flexibility in protocols that decouple session descriptions from transport.  For provisional answers. In RFC3264, the constraint at the signaling level is that only one  <ins> offer can be outstanding for a given session, but at the JSEP level, a new offer can be generated at any point.  For example, when using SIP for signaling, if one offer is sent and is then canceled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer.  To support this, the JSEP media layer can provide an offer via the createOffer method whenever the JavaScript application needs one for the signaling.  The answerer can send back zero or more provisional answers and then finally end the offer/answer exchange by sending a final answer.  The state machine for this is as follows: </ins> Aside from these state transitions, there is no other difference between the handling of provisional ("pranswer") and final ("answer") The createAnswer method generates a blob of SDP that contains an SDP answer per RFC3264 with the supported configuration for the session that is compatible with the parameters supplied in the most recent  <ins> call to setRemoteDescription; setRemoteDescription MUST have been called prior to calling createAnswer.  Like createOffer, the returned blob contains descriptions of the media added to this PeerConnection, the codec/RTP/RTCP options negotiated for this session, and any </ins> candidates that have been gathered by the ICE agent.  An options parameter may be supplied to provide additional control over the generated answer. section. Each "m=" section, provided it is not marked as bundle-only, MUST  <ins> contain a unique set of ICE credentials and a unique set of ICE candidates.  Bundle-only "m=" sections MUST NOT contain any ICE credentials and MUST NOT gather any candidates. </ins> For DTLS, all "m=" sections MUST use any and all certificates that have been specified for the PeerConnection; as a result, they MUST The example in sec.detailed-example shows a more involved case of "LS" group generation.  <ins> The next step is to generate a "m=" section for each "m=" section that is present in the remote offer, as specified in RFC3264.  For the purposes of this discussion, any session-level attributes in the </ins> offer that are also valid as media-level attributes are considered to be present in each "m=" section.  Each offered "m=" section will have an associated RtpTransceiver, as described in sec.applying-a-remote-


Otherwise, the new remote candidate or end-of-candidates indication is supplied to the ICE agent.  In the case of a new remote candidate, <del> connectivity checks will be sent to the new candidate. </del>  4.1.20.

is supplied to the ICE agent. In the case of a new remote candidate, connectivity checks will be sent to the new candidate. However, if you do this prior to setLD() this will not cause connectivity checks to be sent, right?
That is correct.
Do you think we should change the text to say that? Perhaps "In the case of a new remote candidate, connectivity checks will be sent to the new candidate as soon as setLD(answer) is called, or immediately if it has been called already."
Something like that seems like a good idea. It won't always be setLD with an answer though.
maybe just add ", assuming setLocalDescription has already been called to initialize the ICE gathering process."

Otherwise, the new remote candidate or end-of-candidates indication is supplied to the ICE agent.  In the case of a new remote candidate,  <ins> connectivity checks will be sent to the new candidate, assuming setLocalDescription has already been called to initialize the ICE gathering process. </ins> 4.1.20.


1.3. <del> When [RFC8829] was published, an inconsistency regarding BUNDLE RFC8843 operation was identified concerning both the specification text as well as implementation behavior.  The former concern was addressed via an update to RFC8843.  For the latter concern, it was observed that some implementations implemented the "max-bundle" bundle policy by assuming that bundling had already been negotiated, rather than marking "m=" sections as bundle-only as indicated by RFC8829.  In order to prevent unexpected changes to applications relying on the pre-standard behavior, the decision was made to deprecate the use of "max-bundle" and instead introduce a new "must- bundle" policy that, when selected, provides the correct behavior. </del>  2. MUST contain all "m=" sections that were previously bundled, as long as they are still alive, as well as any new "m=" sections.  "a=group:LS" attributes are generated in the same way as for initial offers, with the additional stipulation that any lip sync groups that were present in the most recent answer MUST continue to exist and

This includes the changes requested at IETF 111 (summarized in URL), which are: modified text in S 1.3 (requested by NAME to spell out that "must-bundle" is the behavior formerly known as "max-bundle" added brief discussion of interaction of BUNDLE and TPCC (requested by NAME
FYI NAME
LGTM.
Should we add a reference to rfc8843bis? The rest looks good.
LGTMLGTM

1.3.  <ins> When RFC8829 was published, inconsistencies regarding BUNDLE RFC8843 operation were identified with regard to both the specification text as well as implementation behavior.  The former concern was addressed via an update to RFC8843.  For the latter concern, it was observed that some implementations implemented the "max-bundle" bundle policy defined in RFC8829 by assuming that bundling had already been negotiated, rather than marking "m=" sections as bundle-only as indicated by the specification.  In order to prevent unexpected changes to applications relying on the pre-standard behavior, the decision was made to deprecate "max-bundle" and instead introduce an identically defined "must-bundle" policy that, when selected, provides the behavior originally specified by RFC8829. </ins> 2. MUST contain all "m=" sections that were previously bundled, as long as they are still alive, as well as any new "m=" sections. <ins> 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). </ins> "a=group:LS" attributes are generated in the same way as for initial offers, with the additional stipulation that any lip sync groups that were present in the most recent answer MUST continue to exist and


1.3. <del> When RFC8829 was published, inconsistencies regarding BUNDLE RFC9143 </del>  operation were identified with regard to both the specification text as well as implementation behavior.  The former concern was addressed <del> via an update to RFC9143.  For the latter concern, it was observed that some implementations implemented the "max-bundle" bundle policy defined in RFC8829 by assuming that bundling had already been negotiated, rather than marking "m=" sections as bundle-only as indicated by the specification.  In order to prevent unexpected changes to applications relying on the pre-standard behavior, the decision was made to deprecate "max-bundle" and instead introduce an identically defined "must-bundle" policy that, when selected, provides the behavior originally specified by RFC8829. </del>  2.

Addressing .
LGTM modulo the change below. NAME NAME Reviewer: Qin Wu Review result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. RFC8829 defines JSEP protocol and describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API. This document is RFC8829bis and provides update to RFC8829 to address inconsistency between JSEP and SDP BUNDLE protocol. Major issue: I am not against deprecating "max-bundle" and replacing it with “must-bundle”, but Since there is inconsistency between JSEP and SDP BUNDLE protocol, regarding bundle-only "m=", I think it is the fault of both JSEP and SDP BUNDLE protocol. the best way is both JSEP and SDP BUNDLE protocol should make bis documents in parallel, to make sure consistently issues get resolved. The draft said: “ The former concern was addressed via an update to [RFC9143] ” Where is the document specifying update to RFC9143? Without RFC9143bis to be proposed on the same table, I am not sure how we can prevent inconsistency issue between this RFC8829bis and the future RFC9143bis from happening again. Minor issue: The draft said: “ When [RFC8829] was published, inconsistencies regarding BUNDLE [RFC9143] operation were identified with regard to both the specification text as well as implementation behavior. ” What is the difference between specification text and implementation behavior? Why specification text can not specify the standard behavior for the endpoints implementation? RFC8829 said: “ JSEP prescribes that said "m=" sections should use port zero and add an "a=bundle-only" attribute in initial offers, but not in answers or subsequent offers. BUNDLE prescribes that these "m=" sections should be marked as described in the previous point, but in all offers and answers. Most current browsers do not mark any "m=" sections with port zero and instead use the same port for all bundled "m=" sections; some others follow the JSEP behavior ” If both JSEP protocol and SDP BUNDEL protocol define consistent standard behavior, browser implementation follows standard behavior defined in JSEP and SDP BUNDEL protocol, implementation inconsistency will automatically go away, no?

1.3.  <ins> When RFC8829 was published, inconsistencies regarding BUNDLE RFC8843 </ins> operation were identified with regard to both the specification text as well as implementation behavior.  The former concern was addressed  <ins> via an update to BUNDLE (see RFC9143).  For the latter concern, it was observed that some implementations implemented the "max-bundle" bundle policy defined in RFC8829 by assuming that bundling had already been negotiated, rather than marking "m=" sections as bundle- only as indicated by the BUNDLE specification.  In order to prevent unexpected changes to applications relying on the pre-standard behavior, the decision was made to deprecate "max-bundle" and instead introduce an identically defined "must-bundle" policy that, when selected, provides the behavior originally specified by RFC8829. </ins> 2.


However, to provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP and be serialized out to SDP.  If future <del> specifications agree on a JSON format for session descriptions, we could easily enable this object to generate and consume that JSON. </del>  As detailed below, most applications should be able to treat the SessionDescriptions produced and consumed by these various API calls <del> as opaque blobs; that is, the application will not need to read or change them. </del>  3.4. In order to give the application control over various common session parameters, JSEP provides control surfaces that tell the JSEP <del> implementation how to generate session descriptions.  This avoids the need for JavaScript to modify session descriptions in most cases. </del>  Changes to these objects result in changes to the session descriptions generated by subsequent createOffer/createAnswer calls. MUST be used for identification; otherwise, the "m=" section index is used instead. <del> Implementations MUST be prepared to receive objects with some fields missing, as mentioned above. </del>  3.5.3. implemented by some implementations according to an earlier, pre- standard definition (in which, for example, no "m=" sections were marked as bundle-only).  As a result, "max-bundle" is considered <del> deprecated, and new applications should use the "must-bundle" policy instead. </del>  The application can specify its preferred policy regarding use of RTP/RTCP multiplexing RFC5761 using one of the following policies: new parameters and sends a reject message back to the offerer.  Now, the offerer, and possibly the answerer as well, needs to return to a "stable" state and the previous local/remote description.  To support <del> this, we introduce the concept of "rollback", which discards any proposed changes to the session, returning the state machine to the "stable" state.  A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or setRemoteDescription. </del>  4.1.11. untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious <del> ones.  This is particularly relevant when we consider the SDP that is passed to setLocalDescription.  While correct API usage requires that the application pass in SDP that was derived from createOffer or </del>  createAnswer, there is no guarantee that applications do so.  The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead.

Explain more about use of max-bundle by implementations Explain sess-id limits Remove use of "we" throughout

However, to provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP and be serialized out to SDP.  If future  <ins> specifications agree on a JSON format for session descriptions, this object could be enhanced to generate and consume that JSON. </ins> As detailed below, most applications should be able to treat the SessionDescriptions produced and consumed by these various API calls  <ins> as opaque blobs; that is, the application will not need to parse or understand them. </ins> 3.4. In order to give the application control over various common session parameters, JSEP provides control surfaces that tell the JSEP  <ins> implementation how to generate session descriptions.  In most cases, this removes the need for applications to modify session descriptions after they are created. </ins> Changes to these objects result in changes to the session descriptions generated by subsequent createOffer/createAnswer calls. MUST be used for identification; otherwise, the "m=" section index is used instead.  <ins> Other than the "m=" section index, all IceCandidate fields are optional, and implementations MUST NOT reject a candidate simply because an optional field is missing. </ins> 3.5.3. implemented by some implementations according to an earlier, pre- standard definition (in which, for example, no "m=" sections were marked as bundle-only).  As a result, "max-bundle" is considered  <ins> deprecated, and implementations compliant with this specification SHOULD ignore attempts by the application to select this bundle policy (although some phase-out period may be necessary to avoid application breakage). </ins> The application can specify its preferred policy regarding use of RTP/RTCP multiplexing RFC5761 using one of the following policies: new parameters and sends a reject message back to the offerer.  Now, the offerer, and possibly the answerer as well, needs to return to a "stable" state and the previous local/remote description.  To support  <ins> this, this specification introduces the concept of "rollback", which discards any proposed changes to the session, returning the state machine to the "stable" state.  A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or setRemoteDescription. </ins> 4.1.11. untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious  <ins> ones.  This is particularly relevant when one considers the SDP that is passed to setLocalDescription.  While correct API usage requires that the application pass in SDP that was derived from createOffer or </ins> createAnswer, there is no guarantee that applications do so.  The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead.


application request, and therefore the default candidate pool size MUST be zero. <del> Lastly, the application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic- sdp-bundle-negotiation.  By specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together.  The set of available policies is as follows: </del>  The application will BUNDLE all media streams of the same type together.  That is, if there are multiple audio and multiple video candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy endpoints. <del> Similar to max-bundle, but RTCP candidates are not gathered.  This policy reduces the candidates that must be gathered to the absolute minimum, but will not be compatible with legacy endpoints that do not support RTCP mux. </del> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST be set to "balanced".  4.1.2. The createOffer method generates a blob of SDP that contains a immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded. <del> Any changes to the BUNDLE policy take effect immediately, i.e. any future tracks added to the PeerConnection will have their bundle-only state marked accordingly. </del>  This call may result in a change to the state of the ICE Agent, and may result in a change to media state if it results in connectivity "active" role is RECOMMENDED. If present in the offer, an "a=rtcp-mux" line, as specified in <del> RFC5761, Section 5.1.1. </del>  If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5. This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE <del> is used in full trickle mode with a policy of max-bundle-and-rtcp-mux and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's browser initiating the session to Bob's browser.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server. </del>  The SDP for |offer-B1| looks like:

Justin, this isn't done, but PTAL and see if you think it's going in the right direction.
looks on right path to me
My only issue with this is what happens if you get an offer that does not do mux, I think it should be accepted regardless of what this is set to. I think this should be purely about what is generated in offer. Other than that it looks good.
We should discuss this on today's call. Justin and I spent a while on it last time and one of the relevant arguments was consistency. Specifically, say you have two endpoints, one of which is old (i.e., pre-WebRTC) and doesn't support mux at all and the other of which is set to "require", i.e., only do mux. With the current text, any attempt between these two to communicate will fail. If you only apply these polices to the offer, however: If the old endpoint is the offerer, then it will not offer mux but the WebRTC endpoint will accept it and the call will succeed. If the new endpoint is the offerer, then it will only provide mux candidates and the call will fail in a fairly ugly fashion. The point being that the current text allows you to fail fast.
lgtm
Push -f due to rebase screwup. Cullen and I discussed this PR and he is unconvinced that we should fail when the offer does not include mux but the answerer has set "require". In the interest of landing the rest of this, I have added an issue and an open issue section in the draft. URL Cullen, Justin, if this is acceptable LMK and I will merge this PR in.
This seems fine to me - good topic to discuss in Dallas, if we are still of two minds at that point.
NAME can you confirm this matches your expectations?
LGTM and this open issue is not a huge deal one way or the other
Cullen thinks it should accept and non-mux. EKR and Justin currently believe it should reject the offer.
Original text: when acting as answerer will reject any m= section that does not provide an "a=rtcp-mux" attribute.
LGTM at IETF 92
open issue in text to be removed

application request, and therefore the default candidate pool size MUST be zero.  <ins> The application can specify its preferred policy regarding use of BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp- bundle-negotiation.  By specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together.  The set of available policies is as follows: </ins> The application will BUNDLE all media streams of the same type together.  That is, if there are multiple audio and multiple video candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy endpoints.  As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default BUNDLE policy MUST be set to "balanced". <ins> The application can specify its preferred policy regarding use of RTP/RTCP multiplexing RFC5761 using one of the following policies: The browser will gather both RTP and RTCP candidates but also will offer "a=rtcp-mux", thus allowing for compatibility with either multiplexing or non-multiplexing endpoints. The browser will only gather RTP candidates.  [[OPEN ISSUE: how should the answerer behave.  https://github.com/rtcweb-wg/jsep/ issues/114]] This halves the number of candidates that the offerer needs to gather. </ins> 4.1.2. The createOffer method generates a blob of SDP that contains a immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded.  <ins> The BUNDLE and RTCP-multiplexing policies MUST NOT be changed after the construction of the PeerConnection. </ins> This call may result in a change to the state of the ICE Agent, and may result in a change to media state if it results in connectivity "active" role is RECOMMENDED. If present in the offer, an "a=rtcp-mux" line, as specified in  <ins> RFC5761, Section 5.1.1.  If the "require" RTCP multiplexing policy is set and no "a=rtcp-mux" line is present in the offer, then the m=line MUST be marked as rejected by setting the port in the m= line to zero, as indicated in RFC3264, Section 6. </ins> If present in the offer, an "a=rtcp-rsize" line, as specified in RFC5506, Section 5. This section shows a typical example of a session between two browsers setting up an audio channel and a data channel.  Trickle ICE  <ins> is used in full trickle mode with a bundle policy of max-bundle, an RTCP mux policy of require, and a single TURN server.  Later, two video flows, one for the presenter and one for screen sharing, are added to the session.  This example shows Alice's browser initiating the session to Bob's browser.  The messages from Alice's JS to Bob's JS are assumed to flow over some signaling protocol via a web server. </ins> The SDP for |offer-B1| looks like:


"sendrecv" from RFC4566 MUST be implemented to signal information about media direction. <del> RFC5576 MUST be implemented to signal RTP SSRC values. </del>  RFC4585 MUST be implemented to signal RTCP based feedback. RFC5506 MUST be implemented to signal reduced-size RTCP messages.  RFC3556 with bandwidth modifiers MAY be supported for specifying RTCP bandwidth as a fraction of the media bandwidth, RTCP fraction allocated to the senders and setting maximum media bit-rate An "a=sendrecv" line, as specified in RFC3264, Section 5.1. For each supported codec, "a=rtpmap" and "a=fmtp" lines, as <del> specified in RFC4566, Section 6.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see </del>  Section 3) and I-D.ietf-rtcweb-video (see Section 5). If this m= section is for media with configurable frame sizes, payload type of the primary codec, as specified in RFC4588, Section 8.1. <del> For each supported FEC mechanism, a corresponding "a=rtpmap" line indicating the desired FEC codec. </del>  "a=ice-ufrag" and "a=ice-passwd" lines, as specified in RFC5245, Section 15.4. the primary and RTX SSRCs. If FEC is supported for this media type, another "a=ssrc" line <del> with the FEC SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FEC" and including the primary and FEC SSRCs. </del>  [OPEN ISSUE: Handling of a=imageattr] For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and <del> RFC3264, Section 6.1.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5).  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </del>  If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the "a=fmtp" line that references the payload type of the primary codec, as specified in RFC4588, Section 8.1. <del> For each supported FEC mechanism that is present in the offer, a corresponding "a=rtpmap" line indicating the desired FEC codec. </del>  "a=ice-ufrag" and "a=ice-passwd" lines, as specified in RFC5245, Section 15.4. If a local MediaStreamTrack has been associated, and FEC has been negotiated for this m= section, another "a=ssrc" line with the FEC <del> SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FEC" and including the primary and FEC SSRCs. </del>  [OPEN ISSUE: Handling of a=imageattr]

This looks basically good. I see one missing reference and some places where I think the text might read better. Feel free to ignore my advice on the text, but you should probably fix the reference
PTAL
LGTM
Depends on resolution of FEC on mailing list
This will be dealt with in a future rev.
Justin, where are we here? Should I unmark this discuss?
Unmark as discuss since we need a proposal to discuss first (which I have the action for)
Action to write draft here listing FEC mechanisms that are MTI
Draft completed; now we just need JSEP to refer to uberti-rtcweb-fec.

"sendrecv" from RFC4566 MUST be implemented to signal information about media direction.  <ins> RFC5576 MUST be implemented to signal RTP SSRC values and grouping semantics. </ins> RFC4585 MUST be implemented to signal RTCP based feedback. RFC5506 MUST be implemented to signal reduced-size RTCP messages. <ins> RFC4588 MUST be implemented to signal RTX payload type associations. </ins> RFC3556 with bandwidth modifiers MAY be supported for specifying RTCP bandwidth as a fraction of the media bandwidth, RTCP fraction allocated to the senders and setting maximum media bit-rate An "a=sendrecv" line, as specified in RFC3264, Section 5.1. For each supported codec, "a=rtpmap" and "a=fmtp" lines, as  <ins> specified in RFC4566, Section 6.  The audio and video codecs that MUST be supported are specified in I-D.ietf-rtcweb-audio (see </ins> Section 3) and I-D.ietf-rtcweb-video (see Section 5). If this m= section is for media with configurable frame sizes, payload type of the primary codec, as specified in RFC4588, Section 8.1.  <ins> For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6.  The FEC mechanisms that MUST be supported are specified in I-D.ietf-rtcweb-fec, Section 6, and specific usage for each media type is outlined in Sections 4 and 5. </ins> "a=ice-ufrag" and "a=ice-passwd" lines, as specified in RFC5245, Section 15.4. the primary and RTX SSRCs. If FEC is supported for this media type, another "a=ssrc" line  <ins> with the FEC SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </ins> [OPEN ISSUE: Handling of a=imageattr] For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and  <ins> RFC3264, Section 6.1.  The audio and video codecs that MUST be supported are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5).  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </ins> If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the "a=fmtp" line that references the payload type of the primary codec, as specified in RFC4588, Section 8.1.  <ins> For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6.  The FEC mechanisms that MUST be supported are specified in I-D.ietf-rtcweb-fec, Section 6, and specific usage for each media type is outlined in Sections 4 and 5. </ins> "a=ice-ufrag" and "a=ice-passwd" lines, as specified in RFC5245, Section 15.4. If a local MediaStreamTrack has been associated, and FEC has been negotiated for this m= section, another "a=ssrc" line with the FEC  <ins> SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </ins> [OPEN ISSUE: Handling of a=imageattr]


The "s=" and "t=" lines MUST stay the same. <del> Each "m=" and c=" line MUST be filled in with the port and address of the default candidate for the m= section, as described in RFC5245, Section 4.3.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above.  [TODO: update profile UDP/TCP per default candidate] </del>  Each "a=mid" line MUST stay the same. The createOffer method takes as a parameter an RTCOfferOptions object.  Special processing is performed when generating a SDP <del> description if the following constraints are present. </del>  5.2.3.1. 5.3.2.  5.3.3. The createAnswer method takes as a parameter an RTCAnswerOptions <del> object.  Special processing is performed when generating a SDP description if the following constraints are present. </del>  5.3.3.1. <del> Handling of the "VoiceActivityDetection" option in answers is the same as is indicated for offers in sec.voiceactivitydetection1. </del>  5.4. Remove or reorder codecs (m=) <del> The following parameters may be controlled by constraints passed into </del>  createOffer/createAnswer.  As an open issue, these changes may also be be performed by manipulating the SDP returned from createOffer/ createAnswer, as indicated above, as long as the capabilities of the

Also fix a bunch of TODOs and a few places where text was obsolete. NAME NAME
I suspect we might need to say a bit more in this section this but this all looks good good so LGTM

The "s=" and "t=" lines MUST stay the same.  <ins> Each "m=" and c=" line MUST be filled in with the port, protocol, and address of the default candidate for the m= section, as described in RFC5245, Section 4.3.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is currently active or not.  Note that if RTCP multiplexing is being offered, but not yet active, the default RTCP candidate MUST be used, as indicated in RFC5761, section 5.1.3.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described above. </ins> Each "a=mid" line MUST stay the same. The createOffer method takes as a parameter an RTCOfferOptions object.  Special processing is performed when generating a SDP  <ins> description if the following options are present. </ins> 5.2.3.1. 5.3.2. <ins> When createAnswer is called a second (or later) time, or is called after a local description has already been installed, the processing is somewhat different than for an initial answer. If the initial answer was not applied using setLocalDescription, meaning the PeerConnection is still in the "have-remote-offer" state, the steps for generating an initial answer should be followed, subject to the following restriction: The fields of the "o=" line MUST stay the same except for the <session-version> field, which MUST increment if the session description changes in any way from the previously generated answer. If any session description was previously supplied to setLocalDescription, an answer is generated by following the steps in the "have-remote-offer" state above, along with these exceptions: The "s=" and "t=" lines MUST stay the same. Each "m=" and c=" line MUST be filled in with the port and address of the default candidate for the m= section, as described in RFC5245, Section 4.3.  Note, however, that the m= line protocol need not match the default candidate, because this protocol value must instead match what was supplied in the offer, as described above.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is enabled in the answer.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described in the initial answer section above. Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. Within each m= section, for each candidate that has been gathered during the most recent gathering phase (see sec.ice-gather- overview), an "a=candidate" line MUST be added, as specified in RFC5245, Section 4.3., paragraph 3.  If candidate gathering for the section has completed, an "a=end-of-candidates" attribute MUST be added, as described in I-D.ietf-mmusic-trickle-ice, Section 9.3. For MediaStreamTracks that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same. </ins> 5.3.3. The createAnswer method takes as a parameter an RTCAnswerOptions  <ins> object.  The set of parameters for RTCAnswerOptions is different than those supported in RTCOfferOptions; the OfferToReceiveAudio, OfferToReceiveVideo, and IceRestart options mentioned in sec.options- handling1 are meaningless in the context of generating an answer, as there is no need to generate extra m= lines in an answer, and ICE credentials will automatically be changed for all m= lines where the offerer chose to perform ICE restart. The following options are supported in RTCAnswerOptions. </ins> 5.3.3.1.  <ins> Silence suppression in the answer is handled as described in sec.voiceactivitydetection1. </ins> 5.4. Remove or reorder codecs (m=)  <ins> The following parameters may be controlled by options passed into </ins> createOffer/createAnswer.  As an open issue, these changes may also be be performed by manipulating the SDP returned from createOffer/ createAnswer, as indicated above, as long as the capabilities of the