Code change:
the GroupContext. This extension lists the extensions and proposal types that must be <del> supported by all members of the group.  For new members, it is enforced by existing members during the application of Add commits. Existing members should of course be in compliance already.  In order to ensure this continues to be the case even as the group's extensions can be updated, a GroupContextExtensions proposal is invalid if it contains a "required_capabilities" extension that requires capabilities not supported by all current members. </del> <ins> supported by all members of the group.  The "default" proposal and extension types defined in this document are assumed to be implemented by all clients, and need not be listed in RequiredCapabilities in order to be safely used. For new members, support for required capabilities is enforced by existing members during the application of Add commits.  Existing members should of course be in compliance already.  In order to ensure this continues to be the case even as the group's extensions can be updated, a GroupContextExtensions proposal is invalid if it contains a "required_capabilities" extension that requires non- default capabilities not supported by all current members. </ins> 10.2.

Related discussion:
text: cc NAME
Looks good to me, thanks!
Comment by NAME Maybe add a sentence saying this means there is no repudiation of messages?
I would prefer not to say anything like that here, because the degree to which signature implies non-repudiation depends on a bunch of context for how the signature keys are managed. Clearly if you have long term or certified keys, then yes, there's a pretty high degree of non-repudiation. But people are also interested in configuring MLS to be deniable, e.g., by exchanging signature keys over a deniable channel. So I would propose closing this with no action.
Ah, that is a very good point. In my head I was thinking signature means proof of key and key is proven to person. But that might certainly not be the case here.
The description of is clear that proposals defined in the RFC are not to be included because they are considered standard, however there is no such clarification around extensions. In general, extension requirements are not all that clear because in several places (such as Lifetime) it is mentioned that an extension must be included, however they are all listed as recommended rather than required in the table. It also raises a question in that if an extension is required to be implemented as part of the specification, and required in every KeyPackage, should it just be a field rather than an extension?
Even that is not quite clear to me. At least to me it doesn't follow from Section 10.1. The last one at least, I can shed some light on, as we had this discussion before and I was arguing the same thing. From what I remember, the argument was the keeping it an extension rather than a field would force implementers to implement the Extension mechanism. I don't have a super strong opinion here, but I seem to remember that that's what it boiled down to. I generally agree, though, that some things around RequiredCapabilities (RC) and Capabilities in general is unclear. I discussed this with NAME and here are some examples/questions that came up: If a group doesn't have an RC extension, can we assume that all extensions/proposals in the spec are supported by everyone, or do we have to check all KeyPackages? Do we want all extensions/proposals in the spec to be MTI and thus implicitly supported by everyone?