+ *
+ * If new message types are added, the protocol version MUST be changed,
+ * so that a client knows, from the negotiated protocol version, what
+ * messages can be sent to the server.
+ *
+ * If the format of an existing message type is changed, the protocol
+ * version MUST be changed, so that each side knows, from the negotiated
+ * protocol version, what format should be used.
+ *
+ * The RPCAP_MSG_ERROR format MUST not change, as it's used to, among
+ * other things, report "incorrect version number" errors, where, if
+ * the format changed, the sender of the message might not know what
+ * versions the recipient would understand, or might know a version
+ * they support (the version number they sent) but might not know
+ * the format of the message in that version.
+ *
+ * Other message versions SHOULD not change, as that would complicate
+ * the process of interpreting the message, making it version-dependent.
+ * Introducing a new message with a new format is preferable.
+ *
+ * Version negotiation is done as part of the authentication process:
+ *
+ * The client sends an authentication request, with a version number
+ * of 0. All servers must accept authentication requests with a version
+ * number of 0, even if they don't support version 0 for any other
+ * requests.
+ *
+ * The server attempts to authenticate the client. If that succeeds,
+ * older servers - which only support version 0 - will send an
+ * authentication reply with no payload. Newer servers - which might
+ * support other versions - will send an authentication reply with
+ * a payload giving the minimum and maximum versions it supports.
+ *
+ * The client attempts to find the largest version number that is
+ * in both its range of supported versions and the server's supported
+ * versions. If it fails, it gives up; otherwise, it uses that version.