libxdmcp: Changes to 'upstream-unstable'
.gitignore | 70
A8Eq.c | 49
AA16.c | 51
AA32.c | 51
AA8.c | 51
Alloc.c | 79 -
AofA8.c | 51
Array.c | 247 +++
CA8.c | 48
CmpKey.c | 49
DA16.c | 46
DA32.c | 44
DA8.c | 44
DAofA8.c | 50
DecKey.c | 49
Fill.c | 14
Flush.c | 9
GenKey.c | 74
INSTALL | 236 ---
IncKey.c | 49
Key.c | 102 +
Makefile.am | 64
RA16.c | 70
RA32.c | 70
RA8.c | 70
RAofA8.c | 73
RC16.c | 50
RC32.c | 54
RC8.c | 45
RHead.c | 46
RR.c | 42
RaA16.c | 51
RaA32.c | 51
RaA8.c | 51
RaAoA8.c | 51
Read.c | 244 +++
Unwrap.c | 5
WA16.c | 49
WA32.c | 49
WA8.c | 49
WAofA8.c | 49
WC16.c | 50
WC32.c | 53
WC8.c | 49
Whead.c | 64
Wrap.c | 5
Wrap.h | 4
Wraphelp.c | 5
Write.c | 151 ++
configure.ac | 28
doc/.gitignore | 5
doc/Makefile.am | 64
doc/xdmcp.xml | 3895 ++++++++++++++++++++++++++++++++++++++++++++++++++++
include/X11/Xdmcp.h | 27
54 files changed, 4812 insertions(+), 2284 deletions(-)
New commits:
commit 7db29ff43eb3cdcbfe77c35ecc78c7ca3ddba595
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date: Fri Oct 29 15:13:16 2010 -0700
libXdmcp 1.1.0
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
diff --git a/configure.ac b/configure.ac
index 7585365..5de378a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,8 @@ dnl
dnl Process this file with autoconf to create configure.
AC_PREREQ([2.60])
-AC_INIT(libXdmcp, 1.0.3, [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg],libXdmcp)
+AC_INIT([libXdmcp], [1.1.0],
+ [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [libXdmcp])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit fef4451fa3c55dcf81e7eee7ca001c57e301a150
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date: Wed Oct 27 23:01:49 2010 -0700
Remove AC_PROG_CC & AC_PROG_INSTALL that XORG_DEFAULT_OPTIONS already call
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
diff --git a/configure.ac b/configure.ac
index 576fc2d..7585365 100644
--- a/configure.ac
+++ b/configure.ac
@@ -38,8 +38,6 @@ XORG_WITH_XMLTO(0.0.20)
XORG_WITH_FOP
XORG_CHECK_SGML_DOCTOOLS(1.5)
-AC_PROG_CC
-AC_PROG_INSTALL
AC_PROG_LN_S
AC_LIBTOOL_WIN32_DLL
AM_PROG_LIBTOOL
commit 21c9f93bb5200dda0bfdd05b928c19829f23d646
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Tue Aug 3 15:28:51 2010 -0400
config: require xorg-macros minimum of 1.10 for XORG_CHECK_SGML_DOCTOOLS
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/configure.ac b/configure.ac
index a49d9c2..576fc2d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -28,10 +28,10 @@ AM_MAINTAINER_MODE
AM_CONFIG_HEADER(config.h)
-# Require xorg-macros: XORG_DEFAULT_OPTIONS
+# Require xorg-macros minimum of 1.10 for HAVE_STYLESHEETS in XORG_CHECK_SGML_DOCTOOLS
m4_ifndef([XORG_MACROS_VERSION],
- [m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])])
-XORG_MACROS_VERSION(1.3)
+ [m4_fatal([must install xorg-macros 1.10 or later before running autoconf/autogen])])
+XORG_MACROS_VERSION(1.10)
XORG_DEFAULT_OPTIONS
XORG_ENABLE_DOCS
XORG_WITH_XMLTO(0.0.20)
commit adaf75c9aac6ca77b26379cc5e451728d9f1a78b
Author: Matt Dew <matt@osource.org>
Date: Sun Aug 1 14:23:18 2010 -0400
specs: replace troff source with docbook-xml source
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/Makefile.am b/Makefile.am
index fd16ccc..c3b85aa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,3 +1,5 @@
+SUBDIRS=doc
+
lib_LTLIBRARIES = libXdmcp.la
AM_CPPFLAGS = -I${top_srcdir}/include
diff --git a/configure.ac b/configure.ac
index 9582762..a49d9c2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -33,6 +33,10 @@ m4_ifndef([XORG_MACROS_VERSION],
[m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])])
XORG_MACROS_VERSION(1.3)
XORG_DEFAULT_OPTIONS
+XORG_ENABLE_DOCS
+XORG_WITH_XMLTO(0.0.20)
+XORG_WITH_FOP
+XORG_CHECK_SGML_DOCTOOLS(1.5)
AC_PROG_CC
AC_PROG_INSTALL
@@ -61,4 +65,5 @@ XORG_WITH_LINT
XORG_LINT_LIBRARY([Xdmcp])
AC_OUTPUT([Makefile
+ doc/Makefile
xdmcp.pc])
diff --git a/doc/.gitignore b/doc/.gitignore
new file mode 100644
index 0000000..09b6a89
--- /dev/null
+++ b/doc/.gitignore
@@ -0,0 +1,5 @@
+*.html
+*.ps
+*.pdf
+*.txt
+*.css
diff --git a/doc/Makefile.am b/doc/Makefile.am
new file mode 100644
index 0000000..c2aa671
--- /dev/null
+++ b/doc/Makefile.am
@@ -0,0 +1,64 @@
+#
+# Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+#
+
+if ENABLE_DOCS
+doc_sources = xdmcp.xml
+dist_doc_DATA = $(doc_sources)
+
+if HAVE_XMLTO
+doc_DATA = $(doc_sources:.xml=.html)
+
+if HAVE_FOP
+doc_DATA += $(doc_sources:.xml=.ps) $(doc_sources:.xml=.pdf)
+endif
+
+if HAVE_XMLTO_TEXT
+doc_DATA += $(doc_sources:.xml=.txt)
+endif
+
+if HAVE_STYLESHEETS
+XMLTO_FLAGS = -m $(XSL_STYLESHEET)
+
+doc_DATA += xorg.css
+xorg.css: $(STYLESHEET_SRCDIR)/xorg.css
+ $(AM_V_GEN)cp -pf $(STYLESHEET_SRCDIR)/xorg.css $@
+endif
+
+CLEANFILES = $(doc_DATA)
+
+SUFFIXES = .xml .ps .pdf .txt .html
+
+.xml.txt:
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) txt $<
+
+.xml.html:
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) xhtml-nochunks $<
+
+.xml.pdf:
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) --with-fop pdf $<
+
+.xml.ps:
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) --with-fop ps $<
+
+endif HAVE_XMLTO
+endif ENABLE_DOCS
diff --git a/doc/xdmcp.xml b/doc/xdmcp.xml
new file mode 100644
index 0000000..22bccc6
--- /dev/null
+++ b/doc/xdmcp.xml
@@ -0,0 +1,3895 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+ "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd";>
+
+<book id="xdmcp">
+
+<bookinfo>
+ <title>X Display Manager Control Protocol</title>
+ <subtitle>X.Org Standard</subtitle>
+ <releaseinfo>Version 1.1</releaseinfo>
+ <authorgroup>
+ <author>
+ <firstname>Keith</firstname><surname>Packard</surname>
+ <affiliation><orgname>
+X Consortium,
+Laboratory for Computer Science,
+Massachusetts Institute of Technology
+ </orgname></affiliation>
+ </author>
+ </authorgroup>
+
+ <copyright><year>1989</year><holder>The Open Group</holder></copyright>
+ <copyright><year>2004</year><holder>The Open Group</holder></copyright>
+ <productnumber>X Version 11, Release 6.8</productnumber>
+
+<legalnotice>
+
+
+
+<para>
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+</para>
+<para>
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+</para>
+<para>
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+</para>
+<para>
+Except as contained in this notice, the name of The Open Group shall not be
+used in advertising or otherwise to promote the sale, use or other dealings
+in this Software without prior written authorization from The Open Group.
+</para>
+
+<para>
+<emphasis remap='I'>X Window System</emphasis> is a trademark of The Open Group.
+</para>
+</legalnotice>
+</bookinfo>
+
+<chapter id="TITLE">
+<title>TITLE</title>
+<sect1 id="Purpose_and_Goals">
+<title>Purpose and Goals</title>
+<!-- .XS -->
+<!-- (SN Purpose and Goals -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The purpose of the X Display Manager Control Protocol (XDMCP)
+is to provide a uniform mechanism for an autonomous
+display to request login service from a remote host.
+By autonomous, we mean
+the display consists of hardware and processes that are independent of any
+particular host where login service is desired. (For example, the server
+cannot simply be started by a
+<function>fork/exec</function>
+sequence on the host.)
+An X terminal (screen, keyboard, mouse, processor, network interface)
+is a prime example of an autonomous display.
+</para>
+
+<para>
+From the point of view of the end user, it is very important to make
+autonomous displays as easy to use as traditional hardwired character
+terminals. Specifically, you can typically just power on a hardwired
+terminal and be greeted with a login prompt. The same should be possible
+with autonomous displays. However, in a network environment with multiple
+hosts, the end user may want to choose which host(s) to connect to. In an
+environment with many displays and many hosts, a site administrator may want
+to associate particular collections of hosts with particular displays. We
+would like to support the following options:
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+The display has a single, fixed host to which it should connect. It should be
+possible to power on the display and receive a login prompt, without user
+intervention.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Any one of several hosts on a network or subnetwork may be acceptable
+for accepting login from the display.
+(For example, the user's file systems can be mounted onto
+any such host, providing comparable environments.) It should be possible
+for the display to broadcast to find such hosts and to have the display
+either automatically choose a host or present the possible hosts to the
+user for selection.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+The display has a fixed set of hosts that it can connect to. It should be
+possible for the display to have that set stored in RAM, but it should also be
+possible for a site administrator to be able to maintain host sets for a
+large number of displays using a centralized facility, without having to
+interact (physically or electronically) with each individual display.
+Particular hosts should be allowed to refuse login service, based on
+whatever local criteria are desired.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+The control protocol should be designed in such a way that it can be used over
+a reasonable variety of communication transport layers. In fact, it is quite
+desirable if every major network protocol family that supports the standard X
+protocol is also capable of supporting XDMCP, because the end result of XDMCP
+negotiation will be standard X protocol connections to the display.
+However, because the number of displays per host may be large,
+a connection-based protocol appears less desirable
+than a connection-less protocol. For this reason the protocol is designed
+to use datagram services with the display responsible for sequencing and
+retransmission.
+</para>
+<para>
+<!-- .LP -->
+To keep the burden on displays at a minimum (because display cost is not
+a factor that can be ignored), it is desirable that displays not be required
+to maintain permanent state (across power cycles) for the purposes
+of the control protocol,
+and it is desirable to keep required state at a minimum while the
+display is powered on.
+</para>
+<para>
+<!-- .LP -->
+Security is an important consideration and must be an integral part of the
+design. The important security goals in the context of XDMCP are:
+</para>
+<itemizedlist>
+ <listitem>
+ <para>
+It should be possible for the display to verify that it is communicating
+with a legitimate host login service. Because the user will present
+credentials (for example, password) to this service,
+it is important to avoid spoof attacks.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+It should be possible for the display and the login service to negotiate the
+authorization mechanism to be used for the standard X protocol.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+It should be possible to provide the same level of security in verifying the
+login service as is provided by the negotiated authorization mechanism.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Because there are no firm standards yet in the area of security,
+XDMCP must be flexible enough to accomodate a variety of security mechanisms.
+ </para>
+ </listitem>
+</itemizedlist>
+</sect1>
+
+<sect1 id="Overview_of_the_Protocol">
+<title>Overview of the Protocol</title>
+<!-- .XS -->
+<!-- (SN Overview of the Protocol -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+XDMCP is designed to provide authenticated access to display management
+services for remote displays. A new network server, called a \fIDisplay
+Manager\fP, will use XDMCP to communicate with displays to negotiate the
+startup of X sessions. The protocol allows the display to authenticate the
+manager. It also allows most of the configuration information to be
+centralized with the manager and to ease the burden of system administration
+in a large network of displays.
+The essential goal is to provide plug-and-play
+services similar to those provided in the familiar mainframe/terminal world.
+</para>
+<para>
+<!-- .LP -->
+Displays may be turned off by the user at any time. Any existing session
+running on a display that has been turned off must be identifiable. This
+is made possible by requiring a three-way handshake to start a session. If
+the handshake succeeds, any existing session is terminated immediately and a
+new session started. There is the problem (at least with TCP) that
+connections may not be closed when the display is turned off. In most
+environments, the manager should reduce this problem by periodically XSync'ing
+on its own connection, perhaps every five to ten minutes, and terminating the
+session if its own connection ever closes.
+</para>
+<para>
+<!-- .LP -->
+Displays should not be required to retain permanent state for purposes of
+the control protocol. One solution to packets received out of sequence
+would be to use monotonically increasing message identifiers in each message
+to allow both sides to ignore messages that arrive out-of-sequence. For
+this to work, displays would at a minimum have to increment a stable crash
+count each time they are powered on and use that number as part of a
+larger sequence number. But if displays cannot retain permanent state this
+cannot work. Instead, the manager assumes the responsibility for permanent
+state by generating unique numbers that identify a particular session and
+the protocol simply ignores packets that correspond to an invalid session.
+</para>
+<para>
+<!-- .LP -->
+The Manager must not be responsible for packet reception. To prevent the
+Manager from becoming stuck because of a hostile display, no portion of the
+protocol requires the Manager to retransmit a packet. Part of this means
+that any valid packet that the Manager does receive must be
+acknowledged in some way to prevent the display from continuously resending
+packets. The display can keep the protocol running as it will always know
+when the Manager has received (at least one copy of) a packet. On the
+Manager side, this means that any packet may be received more than once (if
+the response was lost) and duplicates must be ignored.
+</para>
+</sect1>
+
+<sect1 id="Data_Types">
+<title>Data Types</title>
+<!-- .XS -->
+<!-- (SN Data Types -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+XDMCP packets contain several types of data. Integer values are always
+stored most significant byte first in the packet ("Big Endian" order).
+As XDMCP will not be used to transport large quantities of data, this
+restriction will not substantially hamper the efficiency of any
+implementation. Also, no padding of any sort will occur within the packets.
+</para>
+
+<informaltable frame="none">
+ <tgroup cols='3' align='left'>
+ <colspec colname='c1' colsep="0"/>
+ <colspec colname='c2' colsep="0"/>
+ <colspec colname='c3' colsep="0"/>
+ <thead>
+ <row>
+ <entry>Type Name</entry>
+ <entry>Length (Bytes)</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row rowsep="0">
+ <entry>CARD8</entry>
+ <entry>1</entry>
+ <entry>A single byte unsigned integer</entry>
+ </row>
+ <row rowsep="0">
+ <entry>CARD16</entry>
+ <entry>2</entry>
+ <entry>Two byte unsigned integer</entry>
+ </row>
+ <row rowsep="0">
+ <entry>CARD32</entry>
+ <entry>4</entry>
+ <entry>Four byte unsigned integer</entry>
+ </row>
+ <row rowsep="0">
+ <entry>ARRAY8</entry>
+ <entry>n+2</entry>
+ <entry>
+This is actually a CARD16 followed by
+a collection of CARD8. The value of the CARD16
+field (n) specifies the number of CARD8 values to follow
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry>ARRAY16</entry>
+ <entry>2*m+1</entry>
+ <entry>
+This is a CARD8 (m) which specifies the
+number of CARD16 values to follow
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry>ARRAY32</entry>
+ <entry>4*l+1</entry>
+ <entry>
+This is a CARD8 (l) which specifies the
+number of CARD32 values to follow
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry>ARRAYofARRAY8</entry>
+ <entry>?</entry>
+ <entry>
+This is a CARD8 which specifies the
+number of ARRAY8 values to follow.
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+</informaltable>
+</sect1>
+
+<sect1 id="Packet_Format">
+<title>Packet Format</title>
+<!-- .XS -->
+<!-- (SN Packet Format -->
+<!-- .XE -->
+<para>
+All XDMCP packets have the following information:
+</para>
+
+<informaltable frame="none">
+ <tgroup cols='3' align='left'>
+ <colspec colname='c1' colsep="0"/>
+ <colspec colname='c2' colsep="0"/>
+ <colspec colname='c3' colsep="0"/>
+ <thead>
+ <row>
+ <entry>Length (Bytes)</entry>
+ <entry>Field Type</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row rowsep="0">
+ <entry>2</entry>
+ <entry>CARD16</entry>
+ <entry>version number</entry>
+ </row>
+ <row rowsep="0">
+ <entry>2</entry>
+ <entry>CARD16</entry>
+ <entry>opcode packet header</entry>
+ </row>
+ <row rowsep="0">
+ <entry>2</entry>
+ <entry>CARD16</entry>
+ <entry>n = length of remaining data in bytes</entry>
+ </row>
+ <row rowsep="0">
+ <entry>n</entry>
+ <entry>???</entry>
+ <entry>packet-specific data</entry>
+ </row>
+ </tbody>
+ </tgroup>
+</informaltable>
+
+<para>
+<!-- .LP -->
+The fields are as follows:
+</para>
+
+<variablelist>
+ <varlistentry>
+ <term>Version number</term>
+ <listitem>
+ <para>
+This specifies the version of XDMCP that generated this packet in
+case changes in this protocol are required. Displays and
+managers may choose to support older versions for compatibility.
+This field will initially be one (1).
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Opcode</term>
+ <listitem>
+ <para>
+This specifies what step of the protocol this packet represents and should
+contain one of the following values (encoding provided in section below):
+<emphasis role="bold">BroadcastQuery</emphasis>,
+<emphasis role="bold">Query</emphasis>,
+<emphasis role="bold">IndirectQuery</emphasis>,
+<emphasis role="bold">ForwardQuery</emphasis>,
+<emphasis role="bold">Willing</emphasis>,
+<emphasis role="bold">Unwilling</emphasis>,
+<emphasis role="bold">Request</emphasis>,
+<emphasis role="bold">Accept</emphasis>,
+<emphasis role="bold">Decline</emphasis>,
+<emphasis role="bold">Manage</emphasis>,
+<emphasis role="bold">Refuse</emphasis>,
+<emphasis role="bold">Failed</emphasis>,
+<emphasis role="bold">KeepAlive</emphasis>
+or
+<emphasis role="bold">Alive</emphasis>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Length of data in bytes</term>
+ <listitem>
+ <para>
+This specifies the length of the information following the first 6 bytes.
+Each packet-type has a different format and will need to be separately
+length-checked against this value. Because every data item has either an
+explicit or implicit length, this can be easily accomplished.
+Packets that have too little or too much data should be ignored.
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
+<para>
+Packets should be checked to make sure that they satisfy the following
+conditions:
+</para>
+
+<orderedlist>
+ <listitem>
+ <para>
+They must contain valid opcodes.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+The length of the remaining data should correspond to the sum of the
+lengths of the individual remaining data items.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+The opcode should be expected (a finite state diagram is given
+in a later section).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+If the packet is of type
+<emphasis role="bold">Manage</emphasis> or
+<emphasis role="bold">Refuse</emphasis>,
+the Session ID should match the value sent in the preceding
+<emphasis role="bold">Accept</emphasis> packet.
+ </para>
+ </listitem>
+</orderedlist>
+</sect1>
+
+<sect1 id="Protocol">
+<title>Protocol</title>
+<!-- .XS -->
+<!-- (SN Protocol -->
+<!-- .XE -->
+<para>
+Each of the opcodes is described below. Because a given packet type is only
+ever sent one way, each packet description below indicates the direction.
+Most of the packets have additional information included beyond the
+description above. The additional information is appended to the packet
+header in the order described without padding, and the length field is
+computed accordingly.
+</para>
+
+<informaltable frame="none">
+ <tgroup cols='10' align='left'>
+ <colspec colname='col1' colsep="0" colwidth="1*"/>
+ <colspec colname='col2' colsep="0" colwidth="1*"/>
+ <colspec colname='col3' colsep="0" colwidth="1*"/>
+ <colspec colname='col4' colsep="0" colwidth="1*"/>
+ <colspec colname='col5' colsep="0" colwidth="1*"/>
+ <colspec colname='col6' colsep="0" colwidth="1*"/>
+ <colspec colname='col7' colsep="0" colwidth="1*"/>
+ <colspec colname='col8' colsep="0" colwidth="1*"/>
+ <colspec colname='col9' colsep="0" colwidth="1*"/>
+ <colspec colname='col10' colsep="0" colwidth="1*"/>
+ <spanspec namest="col1" nameend="col10" spanname="col1_on" align="left"/>
+ <spanspec namest="col2" nameend="col10" spanname="col2_on" align="left"/>
+ <spanspec namest="col3" nameend="col10" spanname="col3_on" align="left"/>
+ <spanspec namest="col4" nameend="col10" spanname="col4_on" align="left"/>
+ <spanspec namest="col5" nameend="col10" spanname="col5_on" align="left"/>
+ <tbody>
+ <row rowsep="0">
+ <entry spanname="col1_on"><emphasis role="bold">Query</emphasis></entry>
+ </row>
+ <row rowsep="0">
+ <entry spanname="col1_on"><emphasis role="bold">BroadcastQuery</emphasis></entry>
+ </row>
+ <row rowsep="0">
+ <entry spanname="col1_on"><emphasis role="bold">IndirectQuery</emphasis></entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry spanname="col2_on">Display -> Manager</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry spanname="col2_on">Additional Fields:</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col3_on">
+<emphasis>Authentication Names</emphasis>: ARRAYofARRAY8
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col4_on">
+Specifies a list of authentication names that the display supports. The
+manager will choose one of these and return it in the
+<emphasis role="bold">Willing</emphasis> packet.
+ </entry>
+ </row>
+<!-- AAAAAAAAAAAAA -->
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry>Semantics</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col4_on">
+<para>
+A <function>Query</function>
+packet is sent from the display to a specific host to ask if
+that host is willing to provide management services to this display. The
+host should respond with
+<function>Willing</function>
+if it is willing to service the display or
+<function>Unwilling</function>
+if it is not.
+</para>
+
+<para>
+A
+<function>BroadcastQuery</function>
+packet is similar to the
+<function>Query</function>
+packet except that it is intended to be received by all hosts on the network
+(or subnetwork). However, unlike
+<function>Query</function>
+requests, hosts that are not willing to service the display
+should simply ignore
+<function>BroadcastQuery</function>
+requests.
+</para>
+
+<para>
+An
+<function>IndirectQuery</function>
+packet is sent to a well known manager that forwards
+the request to a larger collection of secondary managers using
+<function>ForwardQuery</function>
+packets.
+In this way, the collection of managers that respond can be grouped
+on other than network boundaries; the use of a central manager reduces
+system administrative overhead.
+The primary manager may also send a
+<function>Willing</function>
+packet in response to this packet.
+</para>
+
+<para>
+Each packet type has slightly different semantics:
+</para>
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col5_on">
+<para>
+The
+<function>Query</function>
+packet is destined only for a single host.
+If the display is instructed to
+<function>Query</function>
+multiple managers, it will send multiple
+<function>Query</function>
+packets. The
+<function>Query</function>
+packet also demands a response from the manager, either
+<function>Willing</function>
+or
+<function>Unwilling</function>.
+ </para>
+ <para>
+The
+<function>BroadcastQuery</function>
+packet is sent to many hosts.
+Each manager that receives this packet will not respond with an
+<function>Unwilling</function>
+packet.
+ </para>
+ <para>
+The
+<function>IndirectQuery</function>
+packet is sent to only one manager with the request
+that the request be forwarded to a larger list of managers using
+<function>ForwardQuery</function>
+packets. This list is expected to be maintained at one
+central site to reduce administrative overhead.
+The function of this packet type is similar to
+<function>BroadcastQuery except that</function>
+<function>BroadcastQuery</function>
+is not forwarded.
+ </para>
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col4_on">Valid Responses:</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col3_on">
+<function>Willing</function>,
+<function>Unwilling</function>
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col4_on">Problems/Solutions:</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col3_on">Problem:</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col4_on">
+<para>Not all managers receive the query packet.</para>
+<para>Indication:</para>
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col5_on">
+None if
+<function>BroadcastQuery</function>
+or
+<function>IndirectQuery</function>
+was sent, else failure to receive
+<function>Willing</function>.
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col4_on">Solution:</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col5_on">
+Repeatedly send the packet while waiting for user to choose a manager.
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col3_on">
+Timeout/Retransmission policy:
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col4_on">
+An exponential backoff algorithm should be used here to reduce network load
+for long-standing idle displays. Start at 2 seconds, back off by factors of
+2 to 32 seconds, and discontinue retransmit after 126 seconds. The display
+should reset the timeout when user-input is detected. In this way, the
+display will wakeup when touched by the user.
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry spanname="col1_on">
+<function>ForwardQuery</function>
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry spanname="col2_on">
+<para>Primary Manager -> Secondary Manager</para>
+<para>Additional Fields:</para>
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col3_on">
+<emphasis remap='I'>Client Address</emphasis>: ARRAY8
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col4_on">
+Specifies the network address of the client display.
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col3_on">
+<emphasis remap='I'>Client Port</emphasis>: ARRAY8
+ </entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry spanname="col4_on">
+Specifies an identification of the client task on the client display.
+ </entry>
+ </row>
+ <row rowsep="0">
Reply to: