Enhance definition how to do the handshake

Currently the text says

3.2. Server Response

The response is an OTA_PingRS document.

As mandated by OTA, the content of the EchoData element must be identical to what the client sent.

The server must add to the response a Warning element with Type 11 and Status ALPINEBITS_HANDSHAKE. The content of this element must be the intersection between the client announced versions, actions and capabilities and what the server actually supports.

If a server receives a handshake request with a version he doesn’t support or doesn’t know, the server is allowed to reject the message with an error and a textual description about version incompatibility. This error is thrown by only checking the X-AlpineBits-ClientProtocolVersion.

For better compatibility the server may not directly reject the connection based on the header information, but trying to fulfill the handshake by checking if he supports one of the versions indicated by the client. The answer would be an intersection of common versions in order to give a more specific answer to the client. In that case compatibility between client and server is found within the handshake on the first connection.

In any case this is also valid for the OTA_Ping. If the server supports the version, but no intersection other than OTA_Ping is found, a server should answer to be exclusively compatible with OTA_Ping. This implies there are no common actions between client and server. Otherwise the server should not reply supporting this version at all.

This leads to problems as most servers do not implement the handshake in the same way. So the client is forced to do a try and error loop to find a common version.

The proposal therefore is to deny the possibility to only check the X-AlpineBits-ClientProtocolVersion.