[rfbhackers] Comments on RFB 4.0 draft

[Tim J. <ml...@tj...>]

Hi...

A few comments on the RFB 4.0 draft:

- is there a good reason not to use SSL/TLS for encryption and possibly also 
as an authentication option? The SSL handshake could take place after the 
authentication mechanism has been negotiated.

- instead of using VendorIDs I would propose to use URIs, similar to the use 
in XML DTDs or Java package names. This would prevent the possibility of 
name clashes.

- IMHO transmitting real-time sound over TCP is not a good idea, especially 
with lower bandwidth. Skips in audio data are very unpleasant for the user 
and getting audio right over TCP can be very difficult. RTP is already there 
and could be used as well.

- I think RFB should be seen in context of SIP. SIP/SDP can establish 
connections and negotiate protocols (like having RFB and RTP in a single 
session). Microsoft seems to use it for audio (and a few other things like 
video) with RDP as well, at least for VoIP.

- several of the other channel types duplicate the functionality of existing 
RFCs. If you initiate the session using SIP and SDP printers could be 
accessed using IPP, files using HTTP/WebDAV. There is no need to create 
subprotocols in RFB for that. When SSL/TLS is used all these protocols 
(except RTP) could use the same security layer.

- the text encoding sounds somewhat dangerous to me as there may be different 
font renders on the system (for example one that supports kerning and one 
that doesnt) or fonts with the same name but slightly different outlines. 
IMHO caching of bitmaps/glyphs should be sufficient.

bye...