How and when is the rsmp version determined?

[emiltin]

If both site and supervisor supports multiple version, and sends them in their Version messages when connecting, when and how is that actual rsmp version agreed?

site sends 3.1.1 and 3.1.2 supervisor responds with 3.1.2 and 3.1.3

what rsmp shuld be used and how do the site/supervisor determine it, and how do the site and supervisor agree on it?

[otterdahl]

In your example 3.1.2 is the latest supported version which both communicating parties supports, so this is the version which is used. In the chapter RSMP/SXL Version it is says: If both communicating systems support several RSMP versions it is always the latest version that should be used.

All communication sent/recieved after the version message exchange uses the corresponding version.

[otterdahl]

This could be written more clearly in the specifcation

[emiltin]

so the site and the supervisor each looks at the versions and determines the latest version that both sides support, and assumes this is used?

after the supervisor determines 3.1.2 should be used, it then sends 3.1.2 and 3.1.3. what's the purpose of sending a version (3.1.3) that can never be used? wouldn't it be clearer to just send 3.1.2 and wait for the site to acknowledge this?

[emiltin]

related to #38

[otterdahl]

I agree that it is not neccecary, but it can be useful to know from a debugging perspective. Perhaps someone uses the wrong version and no matching version can be found. It could be good to know which versions the supervisor supports.

[emiltin]

that makes sense. but I miss a clear indication of what version is actually picked. If one side picks the wrong version, there is no way to tell from the communication exchanged during the connection sequence.

[emiltin]

i think it would be good to add a field 'version_used' in the version message that the supervisor responds with. that would make it explicit what version is picked, and the site can acknowledge that.

[emiltin]

Working on supporting json validation of different rsmp core and sxl version, I noted that the rsmp gem was picking the latest version by sorting alphabetically. This works for version strings like "3.1.4" and "3.1.5", but breaks when you have e.g "3.1.9" and "3.1.10". This will be fixed in the rsmp by using the Gem class which have helpers for comparing semantic versions string.

I think this examples supports the argument for being explicit about what version is really used, by including a field like 'version_used in the responding Version message. Other rsmp implemantations could potentially have similar issues with picking the correct version, which would mean you end up with the two sides using different version without knowing it.

[emiltin]

Here's how the Gem class sorts version strings: https://github.com/rubygems/rubygems/blob/1aa8033952d4eda5ca131039822f9548166ab507/lib/rubygems/version.rb#L336-L361 The point is that it's not as straight-forward as trivial as one might think, and therefore there is a potential that one side will get it wrong. Let's be explicit about the versions agreed. Being explicit also means the site does not have to deal with this kind of version sorting. The supervisor pickes the version and informs the site, which then just have to acknowledge it.

[emiltin]

I should add that version negotiation only happens for the rsmp version. The sxl version is simply stated by the site, and the supervisor is expected to accept it. Not sure why it's designed this way.

[otterdahl]

I've added a suggestion the draft

[otterdahl]

I'm closing this. Feel free to open this issue again if you have any feedback on the draft