[PATCH] Document the r/R semantics for initial connection handshake
ajax at redhat.com
Wed Dec 14 11:48:02 PST 2011
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
@@ -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
<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,
More information about the xorg-devel