having a version number (first!) rarely wastes more than a few
bytes, and if you turn out to need it, you really need it.
I see the arguments for assigning the port "now" - but the
version number issue clearly points out why assigning the port
before thinking a bit might have been a mistake :-)
I am not resistant to the idea of adding a version number if that is what
you/IESG want to do, but I did think about it before posting the internet
draft and decided against it (i.e., the offer to put it in was _not_ an
afterthought). Just to gently push back on being simplistic about it at
the "what harm can a few bytes do" level, the counterarguments are:
(1) This is intended to be used, primarily, over UDP,
with TCP as a fallback for long strings (or when UDP
responses don't appear in a reasonable period of time).
A few extra bytes may shift some uses into TCP, and that
would be unfortunate if it isn't necessary.
(2) I note that the "one string in, one string out"
model used here has been successfully used in the
Internet, and the ARPANet before it, for over 25 years.
It is not exactly a new concept that requires extensive
testing.
(3) Similarly, the response code model is directly based
on the one used in FTP, from which the one used in SMTP
and other protocols is derived. We've got more than 30
years of experience with that one.
(4) While I think I know enough to do it, specifying a
version number in a way that makes it actually useful
for subsequent generations of a protocol is not
straightforward. Indeed, for a protocol this simple, it
is probably more complex than any other aspect of the
specification. The consequences of "put in a version
number" without adequate consideration of its
implications have been throughly illustrated by the
debacle over the version number header in MIME.