Den 2009-06-11 18:06 skrev Daniel P. Berrange:
> On Thu, Jun 11, 2009 at 05:00:52PM +0200, Peter Rosin wrote:
>> Den 2009-06-11 12:15 skrev Daniel P. Berrange:
>>> On Thu, Jun 11, 2009 at 11:15:14AM +0200, Peter Rosin wrote:
>>>> Having a security type named UTF-8, which simply allowed the client
>>>> to select the "real" security type right after it would perhaps not be
>>>> so difficult.
>>> I've never much liked the idea of stealing security types to negotiate
>>> non-security related features myself. It is pretty trivial to implement
>>> the DesktopName encoding. So if we did it with a pseudo-encoding, the
>>> serverinit message would still be ASCII, but would recommend that the
>>> server send a DesktopName message with the UTF-8 encoded name version.
>> Right, the UTF-8 extension as a pseudo-encoding is adequate. +1
>>
>> Question is if this UTF-8 extension should affect anything other than
>> the ServerInit and {Client|Server}CutText messages.
>
> The transition should affect all RFB messages containing strings IMHO,
> whether defined now or in the future.
Hmm, hmm, hmm... There are strings involoved in some security types,
e.g. the VeNCrypt-Plain authentication, where you send username and
password. SASL also handles a bunch of strings.
SASL is new enough that we can perhaps retrofit it to be UTF-8,
but VeNCrypt has been out there a couple of years...
>> I.e. should DesktopName be assumed to be ASCII only until UTF-8 has
>> been seen by the client or should DesktopName always be UTF-8?
>
> As was noted earlier in this thread, existing server impls use pretty
> much anything as their charset, but typically their OS native encoding.
> So I think we have to take account of that for initial state, and thus
> the spec should say something like
>
>
> "The initial RFB character encoding for all strings is 7-bit ASCII.
> Clients and servers receiving strings with 8-bit high characters,
> may choose to interpret them according to their default locale,
> or strip the 8-bit high characters.
Not true, the *CutText messages are ISO 8859-1.
> Clients supporting UNICODE should advertise the UTF-8 pseudo
> encoding. A server supporting UNICODE will respond with an empty
> framebuffer update with this encoding type. At this point all future
> strings transmitted shall be in UTF-8 encoding. A client or server
> receiving invalid UTF-8 data should terminate the connection."
Why does the framebuffer update need to be empty? Why not allow the
pseudo-rect to be passed as (one of) the first rect(s) of the first
update?
I think strings might benefit from being kept in some other encoding at
times, we should perhaps have some wording that allows extensions that
are aware of the (future) UTF-8 pseudo-encoding to override it and keep
its strings in e.g. ASCII. How about:
"The initial RFB character encoding for all strings is 7-bit ASCII,
unless otherwise specified. Clients and servers receiving strings
with 8-bit high characters where 7-bit ASCII is expected, may
choose to interpret them according to their default locale, or
strip the 8-bit high characters.
Clients supporting UNICODE should advertise the UTF-8 pseudo
encoding. A server supporting UNICODE will respond with an empty
pseudo rectangle with this encoding type. At this point all future
strings transmitted shall be in UTF-8 encoding, unless it is
explicitely specified that the UTF-8 pseudo encoding does not
affect the string. A client or server receiving invalid UTF-8
data should terminate the connection."
But "strip" is a bit unclear in the first paragraph. Do you mean
remove the entire character or do you mean zero out the high bit?
If you mean "zero out the high bit", care must be taken with
at least some values in the range 0x80-0x9f...
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
