On Mon, 17 Aug 2009, Peter Rosin wrote:
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
Sorry, my fault.
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.
Back to square 1, then?
BTW, where is this heavy deprecation of tight file transfers
documented?
I'm not sure it is public. In general, the documentation for the Tight
extensions has been confusing at best.
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".
You are correct. I got ProtocolVersion and the reason-string mixed up.
So, could you please tell me your preference wrt the reason-string? Either
way is fine with me!
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".
IMHO, this is just playing with words.
Just to make myself clear, I'm saying that adding the MUST and
SHOULD versions of the text encoding chapter is causing all the
above trouble. I'm still OK with adding less demanding language
that only recommends UTF-8.
In other words, don't solve the problem.
Sigh.
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------
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
