Den 2009-06-15 13:34 skrev Peter Åstrand: > 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.
The point is that the above quote does not apply to _old_ protocol elements such as the ServerInit message. >> 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.) The point is that since it is not specified (and implementations handle it differently) a server has to output ASCII, or there is no telling how it will be displayed by various clients. I have no problem with clients assuming any (ASCII-compatible) encoding, but a server better not generate anything other than plain old ASCII if it wants to interoperate nicely. But the client-side isn't that easy either. If you have a client that assumes UTF-8 in the ServerInit message and breaks the connection if it receives illegal UTF-8, it is not capable of communicating with a server that uses some unfortunate desktop name in some unfortunate encoding... > 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. And I think it is not. He was talking about UTF-8 for _new_ protocol elements, but started by saying that a string in an _old_ protocol element with unspecified encoding is effectively ASCII. Which I think is consistent with my conclusion... > 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. Do you have any insight in the similarities of protocol 3.x and 4.x? Please share your knowledge... 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
