Original text:
(see external-senders-extension).  The "content_type" of the message MUST be "proposal". <del> "new_member": The signature key in the LeafNode in the Commit's path (see joining-via-external-commits).  The "content_type" of the message MUST be "commit". </del>  Recipients of an MLSMessage MUST verify the signature with the key depending on the "sender_type" of the sender as described above. 13.1.8. Add and Remove proposals can be constructed and sent to the group by <del> a party that is outside the group, indicated by an "external" SenderType.  This is useful in cases where, for example, an automated service might propose to remove a member of a group who has been inactive for a long time, or propose adding a newly-hired staff </del>  member to a group representing a real-world team. ReInit proposals can also be sent to the group by an "external" to the clients within a group and can only be used if the "external_senders" extension is present in the group's GroupContext.  An external proposal MUST be sent as an MLSPlaintext object, since the sender will not have the keys necessary to construct an MLSCiphertext object. the external init secret as described in external-initialization. The sender type for the MLSPlaintext encapsulating the External <del> Commit MUST be "new_member" </del>  External Commits come in two "flavors" - a "join" commit that adds the sender to the group or a "resync" commit that replaces a member's

Reviewer comments:
Add new newproposalmember SenderType and rename newmember to newcommit_member. This restores the External Proposal Add functionality which was present in the protocol for some years but clarifies how the authorization and signing takes place in this case.
Interim 2022-06-02: Could punt to extensions, but this is partly just because we moved a little too fast on the removal No objections to reverting Once conflicts and comments resolved, good to merge
LGTM, though would still prefer etc. One minor suggestion to lock down the content.

Revised text:
(see external-senders-extension).  The "content_type" of the message MUST be "proposal".  <ins> "new_member_commit": The signature key in the LeafNode in the Commit's path (see joining-via-external-commits).  The "content_type" of the message MUST be "commit". "new_member_proposal": The signature key in the LeafNode in the KeyPackage embedded in an External Add Proposal.  The "content_type" of the message MUST be "proposal"and the "proposal_type" of the Proposal MUST be "add". </ins> Recipients of an MLSMessage MUST verify the signature with the key depending on the "sender_type" of the sender as described above. 13.1.8. Add and Remove proposals can be constructed and sent to the group by  <ins> a party that is outside the group in two cases.  One case, indicated by an "external" SenderType is useful in cases where, for example, an automated service might propose to remove a member of a group who has been inactive for a long time, or propose adding a newly-hired staff </ins> member to a group representing a real-world team. ReInit proposals can also be sent to the group by an "external" to the clients within a group and can only be used if the "external_senders" extension is present in the group's GroupContext. <ins> The other case, indicated by a "new_member_proposal" SenderType is useful when existing members of the group can independently authorize the addition of an MLS client proposing it be added to the group. External proposals which are not authorized are considered invalid. </ins> An external proposal MUST be sent as an MLSPlaintext object, since the sender will not have the keys necessary to construct an MLSCiphertext object. the external init secret as described in external-initialization. The sender type for the MLSPlaintext encapsulating the External  <ins> Commit MUST be "new_member_commit" </ins> External Commits come in two "flavors" - a "join" commit that adds the sender to the group or a "resync" commit that replaces a member's