Change:
value: Note that the "membership_tag" only needs to be computed for <del> MLSPlaintext messages that will be sent over the wire, and isn't needed for those that will be encrypted and transmitted as MLSCiphertext messages. </del> <ins> MLSPlaintext messages that will be sent over the wire ("wire_format == mls_plaintext").  It isn't needed for messages that will be encrypted and transmitted as MLSCiphertext messages ("wire_format == mls_ciphertext"). </ins> 9.2.

Discussion:
NAME pointed out to me that there's currently no way for a DS to distinguish between MLSPlaintext and MLSCiphertext messages. Obviously, an application could provide a flag on the outside of a message, but there are a few relatively minor benefits to including a flag in MLS: Signing the flag authenticates the sender's intent Including the flag in the transcript confirms that all group members got it in the same format Including the flag in the struct provides a clear signal as to whether the needs to be present/verified Since these benefits are pretty minor, I could kind of go either way on whether to make this change. But it seemed worth writing up a PR to see what the change would look like.
My original intention was not for the DS to distinguish the message types, but also for a receiving client. Even if there's a group policy that dictates whether to encrypt handshake messages, the client won't know how to parse a message, because the fields on plaintext and ciphertext are not aligned in the two structs. So I think fixing that would be the low-hanging fruit. That being said, I agree with NAME that it would be neat to have a flag that signals the encryption status, but also communicates the sender's intent in a cryptographically authenticated manner.
I agree with your reasoning and I think it's worthwhile doing. The only part that is not straight forward for me is this: If the sender is of type the also doesn't need to be present for an . This should either be clarified, or we could have a third wire format for external senders.
Re: -- there isn't an sender type, but there are and . You're correct that in both of those cases, the shouldn't be populated. The signal in this PR helps distinguish the two cases when .
Discussed at 20211004 interim, merge.
Here's the Weekly Digest for : - - Last week 18 issues were created. Of these, 3 issues have been closed and 15 issues are still open.

:greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 5 comments. - - Last week, 10 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 4 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: :bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .