Change:
label "KeyPackage" and a content comprising of all of the fields except for the signature field. <del> Note that the "capabilties" field in the "leaf_node" allows MLS session establishment to be safe from downgrade attacks on the parameters described (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </del> <ins> If a client receives a KeyPackage carried within an MLSMessage object, then it MUST verify that the "version" field of the KeyPackage has the same value as the "version" field of the MLSMessage.  The "version" field in the KeyPackage provides an explicit signal of the intended version to the other members of group when they receive the KeyPackage in an Add proposal. The "capabilities" field in the "leaf_node" allows MLS session establishment to be safe from downgrade attacks on the parameters described (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </ins> The "leaf_node_source" field of the LeafNode in a KeyPackage MUST be set to "key_package".

Discussion:
Note that this is a little bit duplicative: There's already a field in KeyPackage. But removing that would require something like sending MLSMessage in Add, which seems unpleasant. We should probably either require that , or just not use MLSMessage for KeyPackage. Likewise, the version field in GroupInfo can probably be removed, since it will be on the outside MLSMessage regardless of whether the GroupInfo is sent bare or in Welcome.
First, we need to add ProtocolVersion to the beginning of MLSMessageContentTBS. Regarding KeyPackage and GroupInfo, the semantics here are subtle. Example: My MLS 1.1 client could send an MLSMessage with MLS version 1.1 to the DS/Directory, which contains a KeyPackage which only advertises MLS version 1.0. Another MLS client which only supports MLS 1.0 could read it with no problem. (I could publish both 1.0 and 1.1 KeyPackages).
The latest commits here address the initial comments about KeyPackage and GroupInfo, and fixes the problem NAME notes about MLSMessageContentTBS. For GroupInfo: I have just removed the field. I don't think there's any ambiguity created by moving it out to the MLSMessage wrapper. For KeyPackage: I have left the field and required it to be the same as the MLSMessage field. The thinking here is that these are saying the same thing to different audiences (the adder and everything else), so they should be consistent. You could allow them to differ if you said that is only to indicate the format/semantics of the inner KeyPackage; then would indicate the actual version in use. So to NAME point, if MLS 1.1 used the same KeyPackage format/semantics as MLS 1.0 (but presumably differed some other way), then you could have . But this seems harder to reason about than just saying "If I don't support the outer version, I can't use this KeyPackage".
I'm confused about what we're trying to do here. The way I understand it is that MLS messages are always sent in the context of a group. That group has a version associated with it via the group context.

I see how it would make sense to add the version field to MLS messages, but I don't see how that version has anything to do with a potential KeyPackage that might or might not be a part of that message. I think the spec already has enough requirements about versions: If the version indicated by an MLSMessage differs from that of the group indicated by the group id, it's invalid. Similarly, if the version of the KeyPackage contained in a given Add proposal doesn't match that of the group in which it's meant to be used, it's invalid. Where exactly do we run into trouble if we don't explicitly relate the version in the framing and that of it's contents? The versions should already be the same, since they have to be the same as that of the group. Regarding the example with the DS: I don't quite understand the setting. As far as I'm aware, uploading or downloading of KeyPackages is not specified in the spec, so even if it happens within an MLS group (maybe the DS and the client are in a group) the KeyPackage would be part of an application message and thus the version of the KeyPackage would be irrelevant as far as the spec is concerned. Please correct me if I'm wrong or if I misunderstand the problem at hand.
Hi Konrad, Not all MLS objects are sent in the context of a group. KeyPackage objects are not. The version number applies to the protocol which specifies the objects, some of which are messages. When some lower level protocol sends an MLSCiphertext or MLSPlaintext message, the MLS client and/or DS could support multiple versions of MLS. The DS can't tell which group is being referenced until it can parse the message. It can't do that until it knows the protocol version, so the protocol and version are typically the first fields. I agree that for MLSCiphertext and MLSPlaintext objects if the version of the message doesn't correspond to the version of the group, that sounds like an invalid message to me. (I don't see when you would put a KeyPackage inside an MLS application message.) Even though uploading and downloading KeyPackage objects is not included in the spec, we need to allow another protocol to do so and give that protocol a reasonable migration path.

If my directory supports KeyPackages in v1.0 and v1.1 format, we should be able to publish both versions until all the v1.0 potential peers have migrated. The format of the KeyPackage objects may be different. Being able to distinguish these so they can be parsed without external help is a basic data-hygiene function.

So to NAME point, if MLS 1.1 used the same KeyPackage format/semantics as MLS 1.0 (but presumably differed some other way), then you could have . But this seems harder to reason about than just saying "If I don't support the outer version, I can't use this KeyPackage". MLSMessage{version=1.1, KeyPackage{version=1.0,...}} is the case I am envisioning. My client supports both MLS version 1.1 and 1.0. My DS supports v1.1 so I always communicate with v1.1, but I publish keypackages in both 1.0 and 1.1 formats.
Thanks for the explanation, that makes the intent a bit clearer to me. However, I still don't see the scenario where something like is a valid message in the context of the MLS spec. I agree that you should be able to publish KeyPackages of multiple versions and that version agility is important. Do I understand correctly, that in the scenario you describe () you're uploading a KeyPackage to the DS? I guess I don't understand why that would be an MLSMessage and not some message in the proprietary protocol you use to upload KeyPackages.
NAME - You don't need to allow for uploading both 1.0 and 1.1 key packages -- you just have the client upload both and . Since there doesn't seem to be a compelling case here for allowing the versions to differ, I'm going to go ahead and merge with the requirement that they be the same.
To enable version agility, we need MLSMessages to indicate what version they are intended for. Since version is included in signature labels, we need to deconflict these two indicators.