On Wed, Aug 12, 2009 at 01:09:34PM +0200, Peter Rosin wrote: > Den 2009-08-12 11:05 skrev Peter Åstrand: > > On Mon, 27 Jul 2009, Peter Rosin wrote: > >> My take on this is that you (Cendio?) wants to say "all strings > >> MUST/SHOULD be UTF-8 unless otherwise specified". I don't get > >> why you feel that there is need for such strong wording? > > > > Because unspecified encodings are a major problem (as this > > discussion indicates). > > You can have strong wording w/o using MUST/SHOULD. And the > encoding will not end up being specified in /the/ spec just > because we specify it in our spec, so the encoding will be > unspecified regardless of how we word it in our spec. It > would be a lying to say MUST/SHOULD.
MUST and SHOULD words are good idea to specify requirements levels. They are used in every RFC and specified in RFC 2119. As Peter Astrand pointed vague definitions are pure evil. Good example is the official RFB specification... > >> If I have a server and I want it to say "Skåne" if I know UTF-8 > >> is supported by the client and "Skane" otherwise (since perhaps > >> I really really detest the looks of "Sk&%ne", but still > >> strongly dislike "Skane"), I must have a way to automatically > >> determine if UTF-8 is supported. > > > > Just make sure you are using updated clients. Current clients > > cannot corretly display a non-ASCII way in any sane way in any case. > > You are evading the issue. > > Why should I as a server operator deside what client someone > else is using? Isn't that the whole point of using something > like the RFB spec in the first place? > > And exactly, current clients cannot use non-ASCII, and I think > that it will be a *long* time until all that baggage go away. > RealVNC isn't exactly known to spend much love on their free > offer for example. You are absolutely right. > > I'm starting to believe that we won't reach full consensus in a near > > future. > > Seems so. Well, it would be nice to reach the full consensus soon otherwise we have unclear specification. > > Perhaps it's time to vote? > > Vote? That's silly in matters such as these. Who is allowed > to vote? Why should some bystander count as much as someone > who has a clue? How does a simple ay/nay indicate it someone > has a clue or not? > > One vote for every applied patch seems about fair to me. Or > count lines (or words) of original work, but that's harder. I > think I "own" more than 50% of the "shares" by many metrics. > See how silly it gets? > > But sure, "vote" me out all you wish. After all, I don't > even have commit rights, so who do I think I am? I also don't think the vote is a good idea. If I watch this thread correctly there are two points of view: 1. one side would like to fire away all non-UTF-8 strings, which means the older software will become incompatible (bad) 2. another side would like to use unclear specification, which means the problem will be never solved (bad) In my opinion the best solution will be to create new pseudo encoding called "UTF-8". If one side doesn't support UTF-8 strings it means that strings will be in old format (which effectivelly means unspecified encoding). If both sides declare that they support UTF-8 all strings will be sent in UTF-8. We should also declare that all new software MUST send strings in ASCII if it doesn't support UTF-8 or in UTF-8. Regards, Adam -- Adam Tkac, Red Hat, Inc. ------------------------------------------------------------------------------ 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
