[PATCH] Document the r/R semantics for initial connection handshake

[Adam Jackson]

Signed-off-by: Adam Jackson <ajax at redhat.com>
---
 specs/sect1-9.xml |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/specs/sect1-9.xml b/specs/sect1-9.xml
index edc2971..7e5896c 100644
--- a/specs/sect1-9.xml
+++ b/specs/sect1-9.xml
@@ -1157,10 +1157,17 @@ the X protocol can be built on top of any reliable byte stream.
 The client must send an initial byte of data to identify the byte order to be
 employed.
 <indexterm zone="byte-order"><primary>Byte order</primary></indexterm>
-The value of the byte must be octal 102 or 154.
-The value 102 (ASCII uppercase B) means values are transmitted most significant
-byte first, and value 154 (ASCII lowercase l) means values are transmitted
-least significant byte first.
+The octal value 102 (ASCII uppercase B) means values are transmitted most
+significant byte first, and octal value 154 (ASCII lowercase l) means values
+are transmitted least significant byte first.  All servers must support
+receiving these values; all clients must support sending these values.  The
+server may optionally support receiving octal values 122 (ASCII uppercase R)
+and 162 (ASCII lowercase r); these are like B and l respectively, with the
+additional semantics that the client shall be treated as a remote client,
+and local-only extensions will be disabled.  If the server does not support
+this optional feature it must disconnect any client requesting it; forwarding
+proxies are expected to handle this transparently by falling back to the
+appropriate B or l value.
 Except where explicitly noted in the protocol,
 all 16-bit and 32-bit quantities sent by the client must be transmitted with
 this byte order,
-- 
1.7.6.4