A number of enhancements are possible. Also see the file TODO in
the CVS source distribution, which has further ideas concerning
various aspects of CVS, some of which impact the protocol.
Similarly, the http://www.cvshome.org site, in particular the
Development pages.
The Modified request could be speeded up by sending diffs rather
than entire files. The client would need some way to keep the version
of the file which was originally checked out; probably requiring the use
of "cvs edit" in this case is the most sensible course (the "cvs edit"
could be handled by a package like VC for emacs). This would also allow
local operation of cvs diff without arguments.
The fact that pserver requires an extra network turnaround in
order to perform authentication would be nice to avoid. This relates to
the issue of reporting errors; probably the clean solution is to defer
the error until the client has issued a request which expects a
response. To some extent this might relate to the next item (in terms
of how easy it is to skip a whole bunch of requests until we get to one
that expects a response). I know that the kerberos code doesn't wait in
this fashion, but that probably can cause network deadlocks and perhaps
future problems running over a transport which is more transaction
oriented than TCP. On the other hand I'm not sure it is wise to make
the client conduct a lengthy upload only to find there is an
authentication failure.
The protocol uses an extra network turnaround for protocol negotiation
(valid-requests). It might be nice to avoid this by having the
client be able to send requests and tell the server to ignore them if
they are unrecognized (different requests could produce a fatal error if
unrecognized). To do this there should be a standard syntax for
requests. For example, perhaps all future requests should be a single
line, with mechanisms analogous to Argumentx, or several requests
working together, to provide greater amounts of information. Or there
might be a standard mechanism for counted data (analogous to that used
by Modified) or continuation lines (like a generalized
Argumentx). It would be useful to compare what HTTP is planning
in this area; last I looked they were contemplating something called
Protocol Extension Protocol but I haven't looked at the relevant IETF
documents in any detail. Obviously, we want something as simple as
possible (but no simpler).
The scrambling algorithm in the CVS client and server actually support
more characters than those documented in 4. Password scrambling algorithm.
Someday we are going to either have to document them all (but this is
not as easy as it may look, see below), or (gradually and with adequate
process) phase out the support for other characters in the CVS
implementation. This business of having the feature partly undocumented
isn't a desirable state long-term.
The problem with documenting other characters is that unless we know
what character set is in use, there is no way to make a password
portable from one system to another. For example, a with a circle on
top might have different encodings in different character sets.
It almost works to say that the client picks an arbitrary,
unknown character set (indeed, having the CVS client know what character
set the user has in mind is a hard problem otherwise), and scrambles
according to a certain octet<->octet mapping. There are two problems
with this. One is that the protocol has no way to transmit character 10
decimal (linefeed), and the current server and clients have no way to
handle 0 decimal (NUL). This may cause problems with certain multibyte
character sets, in which octets 10 and 0 will appear in the middle of
other characters. The other problem, which is more minor and possibly
not worth worrying about, is that someone can type a password on one
system and then go to another system which uses a different encoding for
the same characters, and have their password not work.
The restriction to the ISO646 invariant subset is the best approach for
strings which are not particularly significant to users. Passwords are
visible enough that this is somewhat doubtful as applied here. ISO646
does, however, have the virtue (!?) of offending everyone. It is easy
to say "But the $ is right on people's keyboards! Surely we can't
forbid that". From a human factors point of view, that makes quite a
bit of sense. The contrary argument, of course, is that a with a circle
on top, or some of the characters poorly handled by Unicode, are on
someone's keyboard.