On Thu, 11 Jun 2009, Daniel P. Berrange wrote:
Having a security type named UTF-8, which simply allowed the client
to select the "real" security type right after it would perhaps not be
so difficult.
I've never much liked the idea of stealing security types to negotiate
non-security related features myself. It is pretty trivial to implement
the DesktopName encoding. So if we did it with a pseudo-encoding, the
serverinit message would still be ASCII, but would recommend that the
server send a DesktopName message with the UTF-8 encoded name version.
This is certainly possible and should work. But it's a lof of work: We
need to specify the different cases and the new pseudo encoding, all VNC
implementations needs to add support for it, all code that deals with
desktop names needs to observe if the pseudo encoding is active or not etc
etc. We would also be incompatible with "new standard RFB protocol".
What's the motivation for doing all this? Why isn't it good enough just to
define the desktop name as UTF-8, as RealVNC recommends, and be done with
it?
Rgds,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
tigervnc-rfbproto mailing list
tigervnc-rfbproto@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
