Specification upgrades: Determining the way forward?

[ufarooqstatus]

We currently have GossipSub v1.2 specifications that focus on optimally handling large messages. Additionally, there is already a PR for PeerDAS support as GossipSub v1.3.

We need to determine the best approach for proposing further optimizations related to large message handling (v1.2). Here are a few possible options:

1. Update v1.2: Since v1.2 is still an active working draft, we can revise it to create a consolidated document that includes all optimizations for large message handling.

• Pros: This would unify all large message optimizations in one document.
• Cons: Some implementations are already advertising v1.2, and updating the specifications may impact those implementations.

2. Utilize v1.2.x Format for Future (Large Message) Recommendations: We can use v1.2.1 for subsequent recommendations.

• Pros: Simple upgrades within v1.2.
• Cons: Should v1.2.2 conform to all specifications outlined in v1.2.1 as well (or what version number to advertise)?

3. Introduce as v1.4:

• Pros: simple straightforward version upgrades
• Cons: A router may choose not to support 1.3 and still support 1.2 and 1.4. It may require advertising all the supported versions.

[ppopth]

Utilize v1.2.x Format for Future (Large Message) Recommendations: We can use v1.2.1 for subsequent recommendations.

Do we want to be compliant with semver? If so, th v1.2.x seems like a bug fix with no additional features.

Update v1.2: Since v1.2 is still an active working draft, we can revise it to create a consolidated document that includes all optimizations for large message handling.

Since v1.2 includes only IDONTWANT and we are releasing it to the mainnet, if we update v1.2 for new optimizations, it means that we will significantly delay releasing v1.2.