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

Reply via email to