A lot of things need to be considered when designing a new protocol. Versioning is clearly not enough: IP for example has many version fields, but that's not h

A lot of things need to be considered when designing a new protocol. Versioning is clearly not enough: IP for example has many version fields, but that's not helping IPv6's adoption. You may not be able to "replace all the old versions" if your protocol becomes popular, so you need to consider how you will update it anyway. Tags are worth study: If ECN had been implemented as a new IP option instead of appropriating a bit that "everyone should be ignoring" we would've avoided a lot of problems a few years ago. Differentiating between "must implement to operate" and "may implement" is also useful. Sometimes you can add this with a flag or special notation (e.g. PNG and RIFF), but for protocols you can also use negotiation: Telnet's WILL/WON'T/DO/DON'T/CAN/CAN'T system, for example. Specifying failure cases is also good: To make sure people implement reliable systems, I often design into the spec the retry protocol and have a mode (used in interoperation) that causes random failures so they have to implement the retry protocol correctly.