would cause confusion when handshaking a connection and break cross-compatibility between implementations. The list of encoding and security types was maintained by RealVNC Ltd and is separate from the protocol specification so that new types can be added without requiring the specification to be reissued. Since December 2012, the list went to IANA. A community version of the RFB protocol specification which aims to document all existing extensions is hosted by the TigerVNC project. Encoding types Since encodings are part of the negotiation, some of the encodings below are pseudo-encodings used to advertise the ability to handle a certain extension. Of the publicly-defined picture-based encodings, the most efficient ones are the Tight encoding types. Two types of encodings are defined by TightVNC: Tight Encoding, a mixture of rectangle, palette and gradient filling with zlib and JPEG, plus a Zlib-plus-filter "basic compression". Tight PNG Encoding, Tight encoding with basic compression replaced with PNG data. H.264 has been researched for encoding RFB data, but the preliminary results (using Open H.264 format) were described as lackluster by a TurboVNC developer. It does become more efficient with fewer I-frames (keyframes), but CPU utilization remains a problem. Limitations In terms of transferring clipboard data, "there is currently no way to transfer text outside the Latin-1 character set". A common pseudo-encoding extension solves the problem by using UTF-8 in an extended format. The VNC protocol is pixel based. Although this leads to great flexibility (i.e. any type of desktop can be displayed), it is often less efficient than solutions that have a better understanding of the underlying graphic layout like X11 or desktop such as RDP. Those protocols send graphic primitives or high level commands in a simpler form (e.g. open window), whereas RFB just sends the raw pixel data, albeit compressed. The VNC protocol expresses mouse button state in a single byte, as binary up/down. This limits the number of mouse buttons to eight (effectively 7 given convention of button 0 meaning "disabled"). Many modern mice enumerate 9 or more buttons, leading to forward/back buttons having no effect over RFB. A "GII" extension solves this problem. See also Comparison of remote desktop software NX technology and Xpra for efficient remote X Window System connections SPICE References External links RFC 6143: The Remote Framebuffer Protocol (describes Version 3.8) The RFB Protocol - Version 3.8 (2010-11-26) The RFB Protocol - Version 3.7 (2003-08-12) The RFB Protocol -