On Fri, 12 Jun 2009, Peter Rosin wrote:
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?
Again quoting http://article.gmane.org/gmane.network.vnc.realvnc.general/25076:
"In practice desktop names are currently ASCII-only, but new standard RFB protocol elements all use UTF-8 for string data. I'd recommend that third-party encodings, etc also use UTF-8 for string data for consistency.
Cheers, -- Wez @ RealVNC Ltd"
I have no trouble having the string in the new DesktopName pseudo-encoding always be UTF-8.
Good.
It's all those other strings that currently is ASCII only
In the RealVNC protocol specification, ASCII is specified in only two cases:
* The ProtocolVersion. * The "reason-string" (1) (if number-of-security-types is zero). Latin-1 is specified only in the *CutText case.The desktop name have no encoding specified. (The "reason-string" (2) of the SecurityResult also have no encoding specified.)
What I'm suggesting is we start using UTF-8 in "all" cases where no encoding is specified.
I think this is consistent with what James Weatherall suggests. Since no previous encoding was specified, we are not breaking any earlier specification.
The ProtocolVersion can be left as ASCII. The "reason-string" (1) could be either left as ASCII or "upgraded" to UTF-8; either way is fine with me. I don't think this is a large issue.
This leaves us with *CutText, which is specified as Latin-1. If we simply change to UTF-8, we are violating earlier specs and implementations. I guess RealVNC doesn't have this problem with the "new standard RFB protocol" since they are raising the protocol number. In this particular case, I guess we need a new pseudo encoding or similar. But by limiting it to only *CutText, we will stay as close to the new RealVNC as possible. Also, the current clipboard protocol is very limited. Probably, the best approach is to change to UTF-8 while redesigning it. This can be done later.
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
