Merge 1.1.0 changes back to master.
diff --git a/src/chapters/configuring.xml b/src/chapters/configuring.xml
index 41543b9..295e7ac 100644
--- a/src/chapters/configuring.xml
+++ b/src/chapters/configuring.xml
@@ -1809,6 +1809,46 @@
                                     </variablelist>
                                 </entry>
                             </row>
+                            <row>
+                                <entry><parameter>timezone</parameter></entry>
+                                <entry>
+                                    <para><indexterm>
+                                            <primary>RDP</primary>
+                                            <secondary>timezone</secondary>
+                                        </indexterm>The timezone that the client
+                                    should send to the server for configuring the
+                                    local time display of that server.  The
+                                    format of the timezone is in the standard
+                                    IANA key zone format, which is the format
+                                    used in UNIX/Linux.  This will be converted
+                                    by RDP into the correct format for Windows.
+                                    </para>
+                                    <para>The timezone is detected and will be
+                                    passed to the server during the handshake
+                                    phase of the connection, and may used by
+                                    protocols, like RDP, that support it.  This
+                                    parameter can be used to override the value
+                                    detected and passed during the handshake, or
+                                    can be used in situations where guacd does
+                                    not support passing the timezone parameter
+                                    during the handshake phase (guacd versions
+                                    prior to 1.1.0).</para>
+                                    <para>Support for forwarding the client
+                                    timezone varies by RDP server implementation.
+                                    For example, with Windows, support for
+                                    forwarding timezones is only present in
+                                    Windows Server with Remote Desktop Services
+                                    (RDS, formerly known as Terminal Services)
+                                    installed.  Windows Server installations in
+                                    admin mode, along with Windows workstation
+                                    versions, do not allow the timezone to be
+                                    forwarded.  Other server implementations,
+                                    for example, xrdp, may not implement this
+                                    feature at all.  Consult the documentation
+                                    for the RDP server to determine whether or
+                                    not this feature is supported.</para>
+                                </entry>
+                            </row>
                         </tbody>
                     </tgroup>
                 </informaltable>
@@ -3394,6 +3434,40 @@
                                         SSH clients.</para>
                                 </entry>
                             </row>
+                            <row>
+                                <entry><parameter>timezone</parameter></entry>
+                                <entry>
+                                    <para>
+                                        <indexterm>
+                                            <primary>SSH</primary>
+                                            <secondary>timezone</secondary>
+                                        </indexterm>This parameter allows you
+                                        to control the timezone that is sent
+                                        to the server over the SSH connection,
+                                        which will change the way local time is
+                                        displayed on the server.</para>
+                                    <para>
+                                        The mechanism used to do this over SSH
+                                        connections is by setting the
+                                        <envar>TZ</envar> variable on the SSH
+                                        connection to the timezone specified by
+                                        this parameter.  This means that the SSH
+                                        server must allow the <envar>TZ</envar>
+                                        variable to be set/overriden - many SSH
+                                        server implementations have this disabled
+                                        by default.  To get this to work, you may
+                                        need to modify the configuration of the
+                                        SSH server and explicitly allow for
+                                        <envar>TZ</envar> to be set/overriden.
+                                    </para>
+                                    <para>
+                                        The available values of this parameter are
+                                        standard IANA key zone format timezones,
+                                        and the value will be sent directly to
+                                        the server in this format.
+                                    </para>
+                                </entry>
+                            </row>
                         </tbody>
                     </tgroup>
                 </informaltable>
diff --git a/src/chapters/protocol.xml b/src/chapters/protocol.xml
index 450c529..0ddb85c 100644
--- a/src/chapters/protocol.xml
+++ b/src/chapters/protocol.xml
@@ -57,29 +57,123 @@
             <programlisting>6.select,3.vnc;</programlisting>
         </informalexample>
         <para>After receiving the "select" instruction, the server will load the associated client
-            support and respond with a list of accepted parameter names using an "args"
-            instruction:</para>
+            support and respond with its protocol version and a list of accepted parameter names
+            using an "args" instruction:</para>
         <informalexample>
-            <programlisting>4.args,8.hostname,4.port,8.password,13.swap-red-blue,9.read-only;</programlisting>
+            <programlisting>4.args,13.VERSION_1_1_0,8.hostname,4.port,8.password,13.swap-red-blue,9.read-only;</programlisting>
         </informalexample>
+        <para>The protocol version is used to negotiate compatibility between differing
+            versions of client and server, allowing the two sides to negotiate the highest
+            supported version and enable or disable features associated with that version.
+            Older versions of the Guacamole Client that do not support this instruction
+            will silently ignore it as an empty connection parameter.  Valid protocol versions
+            are as follows:<informaltable frame="all">
+                <tgroup cols="3">
+                    <colspec colname="c1" colnum="1" colwidth="1.25*"/>
+                    <colspec colname="c2" colnum="2" colwidth="3.25*"/>
+                    <colspec colname="c3" colnum="3" colwidth="9*"/>
+                    <thead>
+                        <row>
+                            <entry>Version</entry>
+                            <entry>Value</entry>
+                            <entry>Description</entry>
+                        </row>
+                    </thead>
+                    <tbody>
+                        <row>
+                            <entry>1.0.0</entry>
+                            <entry><constant>VERSION_1_0_0</constant></entry>
+                            <entry>This is the default version and applies to any
+                            versions prior to 1.1.0.  Version 1.0.0 of the protocol
+                            does not support protocol negotiation, and requires that
+                            the handshake instructions are delivered in a certain
+                            order, and that they are present (even if empty).</entry>
+                        </row>
+                        <row>
+                            <entry>1.1.0</entry>
+                            <entry><constant>VERSION_1_1_0</constant></entry>
+                            <entry>Protocol version 1.1.0 introduces support for
+                            protocol version negotiation, arbitrary order of the
+                            handshake instructions, and support for passing the
+                            timezone instruction during the handshake.</entry>
+                        </row>
+                    </tbody>
+                </tgroup>
+            </informaltable>
+        </para>
         <para>After receiving the list of arguments, the client is required to respond with the list
             of supported audio, video, and image mimetypes, the optimal display size and resolution,
-            and the values for all arguments available, even if blank. If any of these requirements
-            are left out, the connection will close:</para>
+            and the values for all arguments available, even if blank.</para>
         <informalexample>
-            <programlisting>4.size,4.1024,3.768,2.96;
+            <programlisting>
+4.size,4.1024,3.768,2.96;
 5.audio,9.audio/ogg;
 5.video;
 5.image,9.image/png,10.image/jpeg;
-7.connect,9.localhost,4.5900,0.,0.,0.;</programlisting>
+8.timezone,16.America/New_York;
+7.connect,13.VERSION_1_1_0,9.localhost,4.5900,0.,0.,0.;</programlisting>
         </informalexample>
         <para>For clarity, we've put each instruction on its own line, but in the real protocol, no
             newlines exist between instructions. In fact, if there is anything after an instruction
             other than the start of a new instruction, the connection is closed.</para>
-        <para>Here, the client is specifying that the optimal display size is 1024x768 at 96 DPI and
-            it supports Ogg Vorbis audio, but no video, and can accept both PNG and JPEG images. It
-            wants to connect to localhost at port 5900, and is leaving the three other parameters
-            blank.</para>
+        <para>The following are valid instructions during the handshake:</para>
+        <informaltable frame="all">
+            <indexterm>
+                <primary>handshake</primary>
+                <secondary>instructions</secondary>
+            </indexterm>
+            <tgroup cols="2">
+                <colspec colname="c1" colnum="1" colwidth="1*"/>
+                <colspec colname="c2" colnum="2" colwidth="3.55*"/>
+                <thead>
+                    <row>
+                        <entry>Instruction name</entry>
+                        <entry>Description</entry>
+                    </row>
+                </thead>
+                <tbody>
+                    <row>
+                        <entry><parameter>audio</parameter></entry>
+                        <entry><para>The audio codec(s) supported by the client.  In the example
+                            above the client is specifying audio/ogg as the supported codec.</para>
+                        </entry>
+                    </row>
+                    <row>
+                        <entry><parameter>connect</parameter></entry>
+                        <entry><para>This is the final instruction of the handshake, terminating
+                            the handshake and indicating that the connection should continue.
+                            This instruction has as its parameters values for the connection
+                            parameters sent by the server in the <constant>args</constant>
+                            instruction.  In the example above, this is connection to localhost
+                            on port 5900, with no values for the last three connection parameters.
+                        </para></entry>
+                    </row>
+                    <row>
+                        <entry><parameter>image</parameter></entry>
+                        <entry><para>The image formats that the client supports, in order of
+                            preference.  The client in the example above is supporting both PNG
+                            and JPEG.</para></entry>
+                    </row>
+                    <row>
+                        <entry><parameter>timezone</parameter></entry>
+                        <entry><para>The timezone of the client, in IANA zone key format.  More
+                            information on this instruction is available in
+                            <xref linkend="configuring-guacamole"/>, under documentation related
+                            to the <constant>timezone</constant> connection parameters for the
+                            protocols that support it.</para>
+                        </entry>
+                    </row>
+                    <row>
+                        <entry><parameter>video</parameter></entry>
+                        <entry><para>The video codec(s) supported by the client.  The above example
+                            is a client that does not support any video codecs.</para></entry>
+                    </row>
+                </tbody>
+            </tgroup>
+        </informaltable>
+        <para>The order of the instructions sent by the client in the handshake is arbitrary, with
+            the exception that the final instruction, connect, will end the handshake and attempt
+            to start the connection.</para>
         <para>Once these instructions have been sent by the client, the server will attempt to
             initialize the connection with the parameters received and, if successful, respond with
             a "ready" instruction. This instruction contains the ID of the new client connection and
diff --git a/src/references/instructions/client/handshake/audio.xml b/src/references/instructions/client/handshake/audio.xml
index 36b4d8d..d1b9a27 100644
--- a/src/references/instructions/client/handshake/audio.xml
+++ b/src/references/instructions/client/handshake/audio.xml
@@ -9,6 +9,5 @@
     </indexterm>
     <para>Specifies which audio mimetypes are supported by the client. Each
         parameter must be a single mimetype, listed in order of client
-        preference, with the optimal mimetype being the first parameter. This is
-        the third instruction sent during the handshake phase.</para>
+        preference, with the optimal mimetype being the first parameter.</para>
 </section>
\ No newline at end of file
diff --git a/src/references/instructions/client/handshake/image.xml b/src/references/instructions/client/handshake/image.xml
index 1cd680e..f50477b 100644
--- a/src/references/instructions/client/handshake/image.xml
+++ b/src/references/instructions/client/handshake/image.xml
@@ -8,7 +8,7 @@
     </indexterm>
     <para>Specifies which image mimetypes are supported by the client. Each parameter must be a
         single mimetype, listed in order of client preference, with the optimal mimetype being the
-        first parameter. This is the fifth instruction sent during the handshake phase.</para>
+        first parameter.</para>
     <para>It is expected that the supported mimetypes will include at least "image/png" and
         "image/jpeg", and the server <emphasis>may</emphasis> safely assume that these mimetypes are
         supported, even if they are absent from the handshake.</para>
diff --git a/src/references/instructions/client/handshake/size.xml b/src/references/instructions/client/handshake/size.xml
index 9069e70..3041236 100644
--- a/src/references/instructions/client/handshake/size.xml
+++ b/src/references/instructions/client/handshake/size.xml
@@ -7,8 +7,7 @@
     <indexterm>
         <primary>size</primary>
     </indexterm>
-    <para>Specifies the client's optimal screen size and resolution. This is the second instruction
-        sent during the handshake phase.</para>
+    <para>Specifies the client's optimal screen size and resolution.</para>
     <variablelist>
         <varlistentry>
             <term><parameter>width</parameter></term>
diff --git a/src/references/instructions/client/handshake/timezone.xml b/src/references/instructions/client/handshake/timezone.xml
new file mode 100644
index 0000000..eea4fe2
--- /dev/null
+++ b/src/references/instructions/client/handshake/timezone.xml
@@ -0,0 +1,23 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<section xml:id="timezone-handshake-instruction"
+    xmlns="http://docbook.org/ns/docbook" version="5.0" xml:lang="en"
+    xmlns:xi="http://www.w3.org/2001/XInclude">
+    <title>timezone</title>
+    <indexterm>
+        <primary>timezone</primary>
+    </indexterm>
+    <para>Specifies the timezone of the client system, in IANA zone key format.
+        This is a single-value parameter, and may be used by protocols to
+        set the timezone on the remote computer, if the remote system allows
+        the timezone to be configured.  This instruction is optional.</para>
+    <variablelist>
+        <varlistentry>
+            <term><parameter>timezone</parameter></term>
+            <listiem>
+                <para>A valid IANA time zone key that indicates the time zone
+                that the client is currently using.</para>
+            </listiem>
+        </varlistentry>
+    </variablelist>
+</section>
\ No newline at end of file
diff --git a/src/references/instructions/client/handshake/video.xml b/src/references/instructions/client/handshake/video.xml
index affb1c9..71bc3db 100644
--- a/src/references/instructions/client/handshake/video.xml
+++ b/src/references/instructions/client/handshake/video.xml
@@ -9,6 +9,5 @@
     </indexterm>
     <para>Specifies which video mimetypes are supported by the client. Each
         parameter must be a single mimetype, listed in order of client
-        preference, with the optimal mimetype being the first parameter. This is
-        the fourth instruction sent during the handshake phase.</para>
+        preference, with the optimal mimetype being the first parameter.</para>
 </section>
\ No newline at end of file
diff --git a/src/references/instructions/server/handshake/args.xml b/src/references/instructions/server/handshake/args.xml
index d9740d5..0e27698 100644
--- a/src/references/instructions/server/handshake/args.xml
+++ b/src/references/instructions/server/handshake/args.xml
@@ -9,9 +9,16 @@
     <para>Reports the expected format of the argument list for the protocol
         requested by the client. This message can be sent by the server during
         the handshake phase only.</para>
-    <para>The parameters of the args instruction are the names of all parameters
-        accepted by the server for the protocol in selected by the client, in
-        order. The client's responding connect instruction must the values of
-        each of these parameters in the same order.</para>
+    <para>The first parameter of this instruction will be the protocol version
+        supported by the server.  This is used to negotiate protocol
+        compatibility between the client and the server, with the highest
+        supported protocol by both sides being chosen.  Versions of Guacamole
+        prior to 1.1.0 do not support protocol version negotiation, and will
+        silently ignore this instruction.</para>
+    <para>The remaining parameters of the args instruction are the names of all
+        connection parameters accepted by the server for the protocol selected
+        by the client, in order. The client's responding connect instruction
+        must contain the values of each of these parameters in the same order.
+    </para>
 
 </section>
diff --git a/src/references/protocol.xml b/src/references/protocol.xml
index 8ea27e1..0c98df5 100644
--- a/src/references/protocol.xml
+++ b/src/references/protocol.xml
@@ -80,6 +80,7 @@
         <xi:include href="instructions/client/handshake/image.xml"/>
         <xi:include href="instructions/client/handshake/select.xml"/>
         <xi:include href="instructions/client/handshake/size.xml"/>
+        <xi:include href="instructions/client/handshake/timezone.xml"/>
         <xi:include href="instructions/client/handshake/video.xml"/>
     </section>
     <section xml:id="server-handshake-instructions">