Re: Tight Extension + VeNCrypt Extension

[Peter R. <pe...@ly...>]

Hi Constantin,

Den 2008-12-27 07:26 skrev Constantin Kaplinsky:
> Hello Peter,
> 
>>>>>> Peter Rosin wrote:
> 
>>>> So, the only way to enable both extensions is to start with the
>>>> Tight extension and then move on to the VeNCrypt extension. However,
>>>> in order to do that, the server needs to specify the four char
>>>> vendor/eigth char name tags for the VeNCrypt security type when the
>>>> Tight extension lists the available security types. I suggest using
>>>> "VENC" for vendor and "VENCRYPT" as the name of the extension.
> 
>>> Should I reserve the corresponding codes/signatures to make sure
>>> TightVNC will not use the codes for other purposes?
> 
>> Yes, please reserve these codes/signatures.
> 
> We are preparing a document with information on reserved codes and
> signatures. How should I list the "VENCRYPT" signature? Is it used as a
> tunneling or as an authentication type? What is the corresponding code?

It is used as an authentication type and the code is 19, as listed in
the current rfbproto.pdf.

At least that's how I tied VeNCrypt and Tight together, that seemed
to be the best match to me.

Perhaps you should also think about how other "new" security types
should be handled. E.g. 18 - TLS and the very fresh 20 - SASL only
just registered and not even listen in the current rfbproto.pdf yet.
I think it would be good to reserve all authentication types below
256 for security types that has been registered in rfbproto.pdf.
But there will always be the question of what to put in name/vendor
for "new stuff" anyway so registration with the tight project will
still be required. However, it would be unfortunate to have the
numbering from rfbproto.pdf clash with the tight numbering.

Cheers,
Peter