I think you're right about older clients connecting to newer servers -- it'd
be okay to just require a newer client version. I *would* prefer that the
newer client be backwards compatible with older servers, though. It'd be a
pain to have to keep multiple client versions around just because you
weren't always using the same server. (For example, I have machines running
both the most recent version of "official" VNC, and the slightly older
TightVNC-hacked server. Right now I can use the same client to access both,
without difficulty.)
-----Original Message-----
From: Bryan A. Pendleton [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 16, 2001 1:43 PM
To: [EMAIL PROTECTED]
Subject: Re: RFB Protocol 4.0 - encodings wanted
On Tue, 17 Jul 2001, Andrew van der Stock wrote:
> I'd certainly like to be included in your version 5.0 protocol.
> Everything should be backward compatible, ie a 3.0 client should be
> able to authenticate to a 5.0 server, as long as the 5.0 server allows
> it.
I'm not sure what AT&T has in mind, though I'm somewhat disappointed to
hear there's a 4.0 spec somewhere that I've never gotten a chance to see.
That aside, I'm not sure full backward compatibility is really
appropriate. The driving force here is the VNC-sec process we're trying to
get going. An important tenant of security is that it's properly
addressed, and put _in_the_right_place_. The last statement is nearly
mutually exclusive with backward compatibility to the existing protocol.
Another issue at odds with backward compatibility is being light weight.
That's something VNC shines with right now, but could quickly become a
problem if serious work is done to make new versions exceptionally
backward compatible. Not to mention the difficulty in analyzing the code
to show that it's even mildly secure.
VNC clients are small and easy to download. It might make more sense to
force users to upgrade their clients to get new functionality, and just
make sure that part of the process is a concerted effort to overhaul
existing clients quickly.
Backward compatibility is what gave us such wonders as Windows 2000, which
has numerous command-line-environment induced long file name problems.
They're blissfully hidden from most types of users, but they're still
there. And you'd better bet there are 10s of thousands of lines of code in
existence today just to deal with those cases. Let's not bring that future
on ourselves - it destroys much of what is great about the VNC concept.
--
Bryan Pendleton
ICQ #2680952
Phone: (650)714-7827
"The root of all knowledge lies within, but knowledge is useless unless it
is collected and shared."
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
