Original text:
applications can choose to make it available to new members in order to allow External Commits. <del> External Commits work like regular Commits, with a few differences: </del>  External Commits MUST contain a "path" field (and is therefore a "full" Commit).  The joiner is added at the leftmost free leaf The proposals included by value in an External Commit MUST meet the following conditions: <del> There MUST be a single ExternalInit proposal </del>  <del> There MUST NOT be any Update proposals </del>  <del> If a Remove proposal is present, then the LeafNode in the "path" field MUST meet the same criteria as the LeafNode in an Update for the removed leaf (see update).  In particular, the "credential" in the LeafNode MUST present a set of identifiers that is acceptable to the application for the removed participant. </del>  External Commits MUST be signed by the new member.  In particular, the signature on the enclosing MLSPlaintext MUST verify using the

Reviewer comments:
The current description of external commits still leaves room for the committer to include various other proposals such as arbitrary proposals that are not Update or Remove proposals (e.g., Adds, RequiredCapability, PSK, etc.). I think we should narrow that down to a specific set of proposals (i.e. an allow list style) to keep the implementation and general protocol complexity low for external commits, both for creation and processing. The way I see it, the new joiner can always issue a follow-up commit for other proposals, but I might be missing important use-cases, so I'd be grateful for feedback on this.
I agree with the intent here. Looking through the list of proposal types, the only other one that seems like it might be useful is PSK -- I could see it being useful to prove that you have a PSK when joining from the outside. If we can add that as an option (probably in parallel to Remove), this seems good to go to me.
Would an External Commit adding yourself contain an Add or an Update Proposal?
It used to contain an proposal, but since that's pretty much redundant with the the commiter has to include, it got optimized away. So an external commit should be handled as if it contained an Add proposal, where the KeyPackage in the Add is instead in the .
Comment by NAME Why RECOMMENDED and not MUST ?

Revised text:
applications can choose to make it available to new members in order to allow External Commits.  <ins> In principle, External Commits work like regular Commits.  However, their content has to meet a specific set of requirements: </ins> External Commits MUST contain a "path" field (and is therefore a "full" Commit).  The joiner is added at the leftmost free leaf The proposals included by value in an External Commit MUST meet the following conditions:  <ins> There MUST be a single ExternalInit proposal. </ins>  <ins> There MAY be a single Remove proposal, where the LeafNode in the "path" field MUST meet the same criteria as the LeafNode in an Update for the removed leaf (see update).  In particular, the "credential" in the LeafNode MUST present a set of identifiers that is acceptable to the application for the removed participant. </ins>  <ins> There MAY be one or more PreSharedKey proposals. There MUST NOT be any other proposals. </ins> External Commits MUST be signed by the new member.  In particular, the signature on the enclosing MLSPlaintext MUST verify using the