FYI. I wasn't aware that the RFB protocol had been RFC'd. I've already submitted the request for the ClientRedirect pseudo encoding assignment.
I think that it would make sense to define the VeNCrypt extensions in the RFC as well. Currently VeNCrypt has it's primary secType number assigned but is noted as a "historical assignment", most likely because the subTypes haven't been formally documented (which is pretty much complete). -brian ---------- Forwarded message ---------- From: Tristan Richardson <t...@realvnc.com> Date: Mon, Jun 6, 2011 at 5:04 AM Subject: Re: pseudo encoding request To: Brian Hinz <bph...@users.sourceforge.net> Hi Brian Since RFB is now RFC 6143, all assignments are via the IANA registries. See http://www.iana.org/protocols/ You can apply for assignments at http://www.iana.org/cgi-bin/assignments.pl Cheers Tristan Brian Hinz wrote: > Hi, > > I'd like to request a new pseudo encoding number be allocated. The > encoding > name would be "ClientRedirect" and this encoding would allow the server to > send a framebuffer update message to the client that instructs the client > to > disconnect and re-connect on a different port (and possibly different > host). > The idea was discussed on the tigervnc-rfbproto list and the following > suggestion was put forth by Daniel Berrange: > > Declare the that pseduo encoding's x, y, width & height fields are > unused and should be set to 0. They are then followed by a payload > that looks something like this: > > =================== =================== > =================================== > No. of bytes Type Description > =================== =================== > =================================== > 2 U16 *port-number* > 4 U32 *hostname-len* > hostname-string U8 array *hostname-string* (UTF8) > 4 U32 *x509subject-len* > x509subject-string U8 array *x509subject-string* (UTF8) > =================== =================== > =================================== > > > Passing of a (optional) x509subject-string is an idea I borrow from > SPICE. Normally when connecting to a VNC server that uses x509 certs, > an important security step is to match the x509 hostname field against > the initial hostname that the VNC client was given by the user. > > During relocation though, this isn't possible, so instead the relocation > message would include the expected x509 subject string. The client can > then validate that instead of the hostname during relocation. Of course > this string would be empty if x509 was irrelevant for the current security > types. > > Apparently QEMU already supports this feature with spice, and I was > looking to do something similar, so it would be nice to get something > standardized before we end up with multiple unofficial protocol > extensions floating around. > > Thanks! > > -brian > _______________________________________________ > VNC-List mailing list > vnc-l...@realvnc.com > To remove yourself from the list visit: > http://www.realvnc.com/mailman/listinfo/vnc-list >
------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2
_______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
