Den 2009-06-12 10:22 skrev Peter Åstrand: > 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?
RealVNC didn't recommend that the clipboard text in the *CutText messages and the string in the ServerInit message should be UTF-8, did they? I have no trouble having the string in the new DesktopName pseudo-encoding always be UTF-8. It's all those other strings that currently is ASCII only (or Latin-1 in the case of *CutText) if you want it to work properly. Cheers, Peter ------------------------------------------------------------------------------ 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