-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Control protocol version frame #42
Comments
I have to admit I am puzzled - can't we just utf8-encode an ascii typical version number, like version = "0.1.0".encode("utf-8") and similarly version = version_frame.decode("utf-8") Or does utf-8 produce so much overhead? or just go with |
I would use ASCII encoding, which should be easily available in virtually every language. I thought about encoding, but forgot to write it... |
Ok, sounds reasonable. Would we then also make the same restriction on the Recipient and Sender Names, and Namespaces, that it needs to go with ascii encoding? Or do we want to allow anyone to use almost any symbols for their Component Names, with utf-8? |
In the PR, I required a bytes sequence, except byte value 46, which corresponds to a period in ASCII. For the Routing it does not matter, how the names are formatted and whether they are formatted at all, as long as they do not contain a byte with value 46. |
I would have said an unsigned integer made of 1 byte (255 versions), or maybe 2 bytes (major+minor version). I would not have encoded strings into the version at all - why go to the complexity (and need to specify the encoding, then)? |
How do we encode the version in the control protocol version frame?
We could use an ever increasing binary number, using the whole frame.
In python it would be simple:
A universal implementation would be:
The text was updated successfully, but these errors were encountered: