--Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of W. Brian
Blevins
Sent: Tuesday, 15 January 2002 2:29 AM
To: ATT Email List
Subject: Re: RFB Protocol
Hi Jonathan,
> Date: Sun, 13 Jan 2002 14:15:36 +
> From: Jonathan Morton <[EMAIL PROTECTED]&
Andrew,
> I work on the win32 platform, and is my preferred development environment.
> I also have a NetBSD/alpha box, a RH 7.2 box, and a Palm m100.
:) Sorry, I jumped the gun a bit. Don't mind me.
Glad to see another attempt at focussing the diverse VNC developments,
I've posted on the subje
as many channels as the server supports.
Thanks for the feedback.
Andrew
- Original Message -
From: "Wayne Throop" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, January 14, 2002 6:21 PM
Subject
ent: Monday, January 14, 2002 9:39 PM
Subject: RE: RFB Protocol
> Hi,
>
> I think that clients should be thin, but the server shouldn't, meaning
that
> features like fonts, bitmap caching, server side updating, etc, should
be
> done as long as the client support it using some sort
t;[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 15, 2002 4:04 AM
Subject: Re: RFB Protocol
> The SecureVNC notes at SourceForge mention targeting both Win32 and POSIX
systems..
>
> In any case, the protocol issue
sage -
From: "Illtud Daniel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 15, 2002 3:30 AM
Subject: Re: RFB Protocol
> ...which mentions Visual Studio .NET - so would I be right in
/2002 January 14 11:30
Subject: Re: RFB Protocol
: Andrew van der Stock wrote:
: >
: > I've been working for some time on VNC 4.0 (or something). The documentation
: > for this is at:
: >
: > http://www.evilsecurity.com/vnc/
:
: ...which mentions Visual Studio .NET - so would I
Andrew van der Stock wrote:
>
> I've been working for some time on VNC 4.0 (or something). The documentation
> for this is at:
>
> http://www.evilsecurity.com/vnc/
...which mentions Visual Studio .NET - so would I be right in
assuming that this won't be x-platform?
--
Illtud Daniel
Hi Jonathan,
> Date: Sun, 13 Jan 2002 14:15:36 +
> From: Jonathan Morton <[EMAIL PROTECTED]>
> Subject: Re: RFB Protocol
>
> >Does someone know, why RFB which is not fixed message size protocol (when it
> >comes to screen updates) is not defined the Following w
Shay;
-Original Message-
From: Andrew van der Stock [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 14, 2002 1:48 AM
To: [EMAIL PROTECTED]
Subject: Re: RFB Protocol
I've been working for some time on VNC 4.0 (or something). The documentation
for this is at:
http://www.evilsecuri
: Major features of 4.0: [.. (or something) ..]
Sounds very cool... a couple of comments immediately spring to mind.
No scaling?
Are there implementations for sound on linux, unix, and windows?
I hope that the client is able to tell the server the size of
the tile cache, so that "not in cache"
nal Message -
From: "Jonathan Morton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 14, 2002 2:20 AM
Subject: RE: RFB Protocol
> >Ahm, can we change it?, I mean it's not SUCH a big change and I'm sure
that
> >all of us will supp
>Ahm, can we change it?, I mean it's not SUCH a big change and I'm sure that
>all of us will support it. And we can always maintain backward
>compatibility.
How? Think about all the massive set of software already using the old system.
Don't answer that. I've already thought of a way that does
PROTECTED]
Subject: Re: RFB Protocol
>Does someone know, why RFB which is not fixed message size protocol
>(when it comes to screen updates) is not defined the Following way:
>
>[CARD32 MessageSize]
>[Message[MessageSize]]
>
>Why the protocol does not contain a Message Size fiel
>Does someone know, why RFB which is not fixed message size protocol (when it
>comes to screen updates) is not defined the Following way:
>
>[CARD32 MessageSize]
>[Message[MessageSize]]
>
>Why the protocol does not contain a Message Size field as the 1st member?
Lack of foresight, probably. The
re.
best regards,
Stig
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Andrew van der
> Stock
> Sent: Monday, July 16, 2001 5:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: RFB Protocol 4.0 - encodings wanted
>
>
&g
-
From: Bryan A. Pendleton [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 16, 2001 1:43 PM
To: [EMAIL PROTECTED]
Subject: Re: RFB Protocol 4.0 - encodings wanted
On Tue, 17 Jul 2001, Andrew van der Stock wrote:
> I'd certainly like to be included in your version 5.0 protocol.
> Every
On Tue, 17 Jul 2001, Andrew van der Stock wrote:
> I'd certainly like to be included in your version 5.0 protocol.
> Everything should be backward compatible, ie a 3.0 client should be
> able to authenticate to a 5.0 server, as long as the 5.0 server allows
> it.
I'm not sure what AT&T has in mi
ll current optional extensions and encodings are gathered into one
reference
Desired new features:
* opaque blob authenticator for Kerberos, OpenSSL, etc
Andrew
- Original Message -
From: "Jonathan Morton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 1
ole value proposition.
Andrew
- Original Message -
From: "Stig A. Olsen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 16, 2001 8:50 PM
Subject: RE: RFB Protocol 4.0 - encodings wanted
> Just a side note here: My company has just released a new
MAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 12:10 AM
Subject: RE: RFB Protocol 4.0 - encodings wanted
> Where can I get the docs for RFB 4.0/5.0 ? And
> Can we add a request in the RFB protocol to query for the pointer/keyboard
> state ? ie x,y coor
, July 16, 2001 3:51 AM
To: [EMAIL PROTECTED]
Subject: RE: RFB Protocol 4.0 - encodings wanted
Just a side note here: My company has just released a new software version
for our videoconferencing equipment that support a VNC client (RFB 3.3).
Since VNC is GPL we naturally had to handcode everything
ssage-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tristan
> Richardson
> Sent: Monday, July 16, 2001 11:58 AM
> To: Andrew van der Stock; [EMAIL PROTECTED]
> Subject: Re: RFB Protocol 4.0 - encodings wanted
>
>
> We already use RFB version 4.x in some
>We already use RFB version 4.x in some of our projects. We're now developing
>version 5.0 of the protocol which is a substantial change from the version 3
>protocols. It would be good to coordinate over what version number you choose
>for your new protocol so that we don't release incompatible
Stock; [EMAIL PROTECTED]
Subject: Re: RFB Protocol 4.0 - encodings wanted
We already use RFB version 4.x in some of our projects. We're now
developing version 5.0 of the protocol which is a substantial change from
the version 3 protocols. It would be good to coordinate over what version
numbe
We already use RFB version 4.x in some of our projects. We're now developing
version 5.0 of the protocol which is a substantial change from the version 3
protocols. It would be good to coordinate over what version number you choose
for your new protocol so that we don't release incompatible prot
>I'd like to see all the other encodings documented, including
>the Tridia ones.
I'm already working on this, and it'll go up on my site when I've
caught up with the original ORL documentation. From that point, I'll
add new information as I get hold of and understand it sufficiently.
Bonus po
Hi,
If you are really trying to do a "4.0" RFB, could you drop in the
additional scaling/resolution capabilities that were added for PalmVNC?
I'd like to see these extended for use in other servers/clients... I get
many requests basically asking for this to be put in, but I can only
work with the
>I'd like to see all the other encodings documented, including
>the Tridia ones.
Already searched (only for fun) and not found without looking
into the code.
>* Two new RFB authentication mechanisms
>- an uprated version of the current #2 mechanism that doesn't involve
>reversible passwords at e
29 matches
Mail list logo
