Den 2009-08-17 11:45 skrev Peter Åstrand: >>>> No we didn't, we agreed on that for the desktop name. >>> >>> Refresh my memory - which other strings are sent as "ANSI CODE PAGE"? >> >> Username and password in the VeNCrypt extension. There are some strings >> in the gii extension. The tight file transfer extension sends filenames. >> And I'm sure I'm forgetting at least some string, that was just off the >> top of my head... > > But neither on those are in the protocol at this point. And the tight > file transfer is heavily deprecated, even by TightVNC.
You better check that, as gii is in the spec. You continue to ignore and look past everything that smells like a problem, which is not very comforting. You seem too eager to add UTF-8 to the spec. And I'd say they are all in the "protocol", just not in our specification of the protocol, so it's still a problem in my book. If we add this language now, we will erect a barrier making it harder to add those other protocol extensions to our spec. I think the burden should be on those trying to do new things (which is to specify UTF-8 for all strings) and not on those documenting existing extensions/behaviours. Oh, and there are also strings in the SASL extension. I think it would be worth more to have SASL, VeNCrypt and Tight file transfer documented (even if deprecated) in the spec than to add some language about UTF-8. BTW, where is this heavy deprecation of tight file transfers documented? >> Nailing to ASCII is worse than nailing to UTF-8. Both make our spec >> incompatible with existing implementations. We have to allow for >> implementations to do whatever non-UTF-8 thingy they have been >> doing, but still recommend against it. > > I would say: Don't give people rope. If we start documenting that full > UTF-8 intl:ed strings are allowed in, say, ProtocolVersion, I'm sure we > will soon se a server that presents itself as RFB 003.008übuñtü or > something like that... Come on, that's a stupid argument since ProtocolVersion is specified as ASCII and to be 12 characters long. And to be in a very specific format. By "everybody". >>> We are not. It's just that clients that relied on recieving the >>> DesktopName in something else than UTF-8 was "on their own" and >>> relied on unspecified protocol behaviour. >> >> Reversing that argument is so easy, Xvnc were "on its own" when it relied >> on unspecified protocol behaviour... > > True, but you can't avoid the fact that the UTF-8 variant is, currently, > transmitted over the wire. True, but you can't avoid the fact that some implementations expect, currently, that the data instead should have been transmitted using CP-1252, or ISO 8859-1, or etc... Today, when there is encoding disconnect, it is the fault of noone (except the spec). If we now start to specify one thing as correct, we will shift the balance and make everybody in the UTF-8 camp "right". And everybody else "wrong". I don't think that's fair. But I still think we can specify one thing as "superior". By doing that the alternative options are no longer "wrong", just "inferior". >>> Strange language. We are not forbidden any clients. It's true that a >>> few clients could theoretically start rendering the names >>> incorrectly, but... >> >> But we seriously do not want to divide the RFB community (any further), >> and we are doing that if we say "MUST use UTF-8". With a MUST in there, >> anything else is not acceptable, hence "illegal" by our spec. > > I see no problem with that our document is somewhat stricter than the > RealVNC one, when it comes to previously undefined things. In that we differ. Cheers, Peter ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
