On Mon, 29 Jun 2009, Peter Rosin wrote:
There are no other strings without encoding. Well, except the
"reason-string" of the SecurityResult, but that could be considered a typo,
since the other "reason-string" is defined as ASCII).
I thought we were in the process of collecting docs for various
extensions.
Good point, but it might make sense to focus on the core. This issue is
complicated even without bringing in all extensions.
There are strings in the gii extension. There are strings in the
VeNCrypt security type (the Plain sub-type). There are strings in
the SASL security type (don't know if those are reqired to be
international though). Perhaps others that I'm not aware of, that
was just off the top of my head.
All these extensions have existing implementations, and to my
knowledge the available specs all fail to mention any encoding
and would therefore be covered by the "UTF-8 fallback".
But isn't that a good thing? UTF-8 is basically the default in the world
we are living in today. If some extension wants some other encoding this
is surely fine, but then they need to specify what they want.
If we would emit a "standard" or "fallback" encoding, this problem would
come back again and again.
Which VNC servers can generate desktop names with CP-1252?
Here's one example:
http://www.ggi-project.org/documentation/libggi/current/display-vnc.7.html
But that one is minor and can probably be ignored.
If you say so. Then the conclusion is that there are no major VNC servers
which generates CP-1252 names, so your argument that we would have a
security problem with CP-1252 servers is moot.
The VeNCrypt strings are not unlikely to be CP-1252 though, since the
first implementation is for Windows.
AFAICT, VeNCrypt is not yet defined in our spec. So this is not a problem.
They day when we are adding it we may or may not want to specify a
"non-standard" encoding.
I.e. skara\0skåra
-1. It's ugly and not compatible with current Xvnc:s and probably not with
RealVNC 4.X rfb proto.
In what way is it not compatible with current Xvnc:s?
Normal Xvnc:s running on normal systems generates UTF-8 desktop names
today. Documenting that desktop name should be UTF-8 would merely document
the current behaviour (and extending it to clients and other servers as
well).
If we choose some other standard/extensions, current Xvnc:s would not be
compatible with our spec, if you use non-ASCII desktop names.
I agree though, in that it isn't exactly elegant...
In that case, perhaps you can accept our suggested solution; just specify
UTF-8 and be done with it?
Best regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------
_______________________________________________
tigervnc-rfbproto mailing list
tigervnc-rfbproto@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
