Absolutely - the server and clients exchange information at the beginning of the session about their capabilities, and both are required to degrade gracefully. The more features that are there, the more efficient the network connection.
Just let me know a section you want to work on, or things that would really help: * documenting all the current display protocols in Augmented BNF form (see RFC2234 for more details). The current textual information in the draft (and the RFB 3.3 document) is insufficient for a clean-room re-implementation. We shouldn't require the client or server code hanging around to make another client or server. http://www.faqs.org/rfcs/rfc2234.html The current stuff is in Word as it's an excellent word munger. I'm happy to be the editor and accept text in pretty much any format (prefer just plain text e-mail) until near the end, when the challenge for me is to convert the draft into a pure-text document (Word, docbook SGML, XML, KWrite, Postscript, PDF, etc are not acceptable formats for IETF submission). Andrew ----- Original Message ----- From: "Erlichmen, Shay" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 14, 2002 9:39 PM Subject: RE: RFB Protocol > Hi, > > I think that clients should be thin, but the server shouldn't, meaning that > features like fonts, bitmap caching, server side updating, etc, should be > done as long as the client support it using some sort of extension > mechanism. > What ever you need you got my help. > > Regards, > - Shay; > > > > -----Original Message----- > From: Andrew van der Stock [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 14, 2002 1:48 AM > To: [EMAIL PROTECTED] > Subject: Re: RFB Protocol > > > I've been working for some time on VNC 4.0 (or something). The documentation > for this is at: > > http://www.evilsecurity.com/vnc/ > > Major features of 4.0: > > * Backwards compatible for authentication, so no new tcp ports required > * "Channels" - sound, file transfers, local printers, clipboard, etc out of > the box > * client and server informational event channel - allows dynamic > re-configuration notifications (ie new input device, or display resolution / > depth changes without restarting the protocol) > * Orthagonal - you can create multiple channels of the same type (ie two > display channels to allow dual head support, etc) > * Security - my original focus - uses the The Secure Remote Password > Protocol, the most provably secure shared secret authentication mechanism > (RFC 2945), but is also pluggable using a blob authenticator, so allows NTLM > / Kerberos / RADIUS / PAM / PKI authenticators without limitation > * footprint: modular & scalable - All channels and verbs can be excluded so > clients do not have to implement all features, allowing a very small (even > smaller than today) clients, ie view only clients with minimal capabilities. > Obviously, some combinations are less than useful, but for othagonality, I > am leaving it as is > * improved wire security - allows for 3DES and AES encryption out of the box > (without known keys), other encryption algorithms as desired (per channel > only; crypto becomes tractably breakable if lots of small packets with known > start bytes flow past an attacker, see Enigma, AirSnort et al for > demonstrable proof of this) > * improved wire speed - can indicate per verb or per channel that > compression is required (bzip and gzip out of the box) > * Will allow multiple binds to the same port for different screens, ie joe:1 > and bill:2 can still work over port 5900 > * Self-describing; all verbs are able to be tested for validity, allowing > the client and server to implement grammar checkers before executing the > incoming streams (mutual distrust model) > * String display (why send a 2000 - 18000 byte image when a 30 byte string > will do if both share a similar font?) > * tile cache (indicates to the client that the next verb will contain a tile > with a known hash number, and in future the server will simply state for > that tile hash to be displayed at location x,y) - this is memory / storage > dependant - *really* thin clients don't have to implement this, or can > choose to implement very small caches. > > Things I'm still to work on: > > * support for rootless windows (ie applications are hosted by the local > window manager) but I know where I can find the VNC client/server patches > for this support, and it's just a matter of documenting it > * Unicode string support (it's time to enter the real world, the world does > not speak ASCII) > * finishing the dang thing :) > > Cons of 4.0 > > Protocol is not backwards compatible with 3.x (unavoidable), but due to the > way I've forced 4.x clients to contain at least a stub of 3.x authentication > along with 3.x compatible initial authentication, this is not a problem. The > incompatibility is ameriolated by using whereever possible features that > already exist from various clients (tight, tridia, Palm), with the same > protocol stream after the verb. The major change for an existing product > wishing to support the new protocol is a new authenticator and a new > protocol interpreter / grammar checker (which should be simpler than today's > and tractable using Yacc etc for the language purists). If they are clever, > they can support 3.x and 4.x verbs simultaneously with the same input / > drawing code, and then slowly add code to support more of the new 4.x > features (remember - it's all optional, so as you get around to it, it'll > continue working with previous versions of 4.x clients or servers). > > I must get around to finishing it. Willing to accept help :-) > > Andrew > > > ----- Original Message ----- > From: "Jonathan Morton" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, January 14, 2002 2:20 AM > Subject: RE: RFB Protocol > > > > >Ahm, can we change it?, I mean it's not SUCH a big change and I'm > > >sure > that > > >all of us will support it. And we can always maintain backward > > >compatibility. > > > > How? Think about all the massive set of software already using the > > old > system. > > > > Don't answer that. I've already thought of a way that does this along > > with a whole bundle of other stuff. Documenting and implementing it > > would be a royal pain, however, which I don't have timme for. :( > > > > -- > > -------------------------------------------------------------- > > from: Jonathan "Chromatix" Morton > > mail: [EMAIL PROTECTED] (not for attachments) > > website: http://www.chromatix.uklinux.net/vnc/ > > geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- > > O-- > M++$ > > V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ > > y+(*) > > tagline: The key to knowledge is not to rely on people to teach you it. > > --------------------------------------------------------------------- > > To unsubscribe, mail [EMAIL PROTECTED] with the line: > > 'unsubscribe vnc-list' in the message BODY > > See also: http://www.uk.research.att.com/vnc/intouch.html > > --------------------------------------------------------------------- > --------------------------------------------------------------------- > To unsubscribe, mail [EMAIL PROTECTED] with the line: > 'unsubscribe vnc-list' in the message BODY See also: > http://www.uk.research.att.com/vnc/intouch.html > --------------------------------------------------------------------- > --------------------------------------------------------------------- > To unsubscribe, mail [EMAIL PROTECTED] with the line: > 'unsubscribe vnc-list' in the message BODY > See also: http://www.uk.research.att.com/vnc/intouch.html > --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
