Den 2009-06-29 09:07 skrev Peter Åstrand: > On Fri, 26 Jun 2009, Peter Rosin wrote: > >>> Without a poll or something like that we'll never know how many uses >>> "strange" desktop names today, but my guess is that it's something >>> like 1 out of 10000 or so. Speaking of "many" just doesn't feels right. >> >> You are now talking specifically about the desktop name in the >> ServerInit message. The patch talked about *all* strings (that do not >> explicitely mention any encoding, i.e. all but *CutText if memory >> serves me). > > 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. 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". >>> I disagree. Replacing non-ASCII characters with ASCII ones may cause >>> confusion or even security problems. If characters are to be >>> replaced, it is critical that this is visible to the user. (If I >>> remember correctly, this is pointed out in the Unicode book). A >>> replacement character such as a box or something like that can used >>> (this is what Microsoft Word does), but no such character is >>> available in ASCII. But the UTF-8 way should work good enough, since >>> sequences such as "Ã¥" are very rare in practice. This is a good >>> property of UTF-8, and this is by design. >> >> You brought up security. What if I, using CP-1252, write: >> HELGEÅ… (hex 48 45 4C 47 45 C5 85) >> That will come out like this in a UTF-8 client: >> HELGEŅ > > 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. The VeNCrypt strings are not unlikely to be CP-1252 though, since the first implementation is for Windows. >> The UTF-8 extension could be signalled by the server by sending the >> desktop name twice with a zero in between. >> >> 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? The RealVNC 4.X protocol is in the shadows, and this is for 3.x. Why does this need to be compatible? And I'm curious, in what way do you think it isn't compatible? I agree though, in that it isn't exactly elegant... Cheers, Peter ------------------------------------------------------------------------------ _______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
