On Mon, 15 Jun 2009, Peter Rosin wrote:
* 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 disagree. In principle, the encoding could even be something else than
ASCII.
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.
In that case, pretty much any server is broken. AFAIK, no server
explicitly strips non-ASCII characters.
Clients should prepare for any kind of desktop name, even if they cannot
display it correctly.
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...
Why on earth should a client break the connection just because the desktop
name looks strange?
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...
Even though current implementations are "effectively ASCII" we can safely
upgrade to UTF-8. Besides, he did recommend UTF-8 for "third party
encodings etc", and this was in a RFB 3.X context.
Do you have any insight in the similarities of protocol 3.x and 4.x?
Please share your knowledge...
As I understand it, the "new standard RFB protocol" is internal to
RealVNC. Many years ago, there was another RFB 4.0 proto spec floating
around, but I don't think they have anything in common. I have no more
information than this.
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
