[PATCH xorg-docs 7/9] Move XDMCP extension spec to lib/libXdmcp
Gaetan Nadon
memsize at videotron.ca
Thu Sep 9 14:56:47 PDT 2010
Following the DocBook conversion.
Signed-off-by: Gaetan Nadon <memsize at videotron.ca>
---
Makefile.am | 1 -
specs/XDMCP/xdmcp.ms | 2177 --------------------------------------------------
2 files changed, 0 insertions(+), 2178 deletions(-)
delete mode 100644 specs/XDMCP/xdmcp.ms
diff --git a/Makefile.am b/Makefile.am
index 2931b18..3014ccb 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -43,7 +43,6 @@ EXTRA_DIST = \
specs/SIAddresses/localuser.txt \
specs/SIAddresses/README \
specs/specindex.html \
- specs/XDMCP/xdmcp.ms \
specs/Xext/AppGroup.mif \
specs/Xext/lbxalg.mif \
specs/Xext/lbx.book \
diff --git a/specs/XDMCP/xdmcp.ms b/specs/XDMCP/xdmcp.ms
deleted file mode 100644
index a237beb..0000000
--- a/specs/XDMCP/xdmcp.ms
+++ /dev/null
@@ -1,2177 +0,0 @@
-.\" Use eqn, tbl, and -ms
-.\" $Xorg: xdmcp.ms,v 1.3 2000/08/17 19:42:20 cpqbld Exp $
-.\" $XdotOrg: xc/doc/specs/XDMCP/xdmcp.ms,v 1.2 2004/04/23 18:42:16 eich Exp $
-.\" $Xorg: xdmcp.ms,v 1.3 2000/08/17 19:42:20 cpqbld Exp $
-.EQ
-delim @@
-define oc % "\\fR{\\fP" %
-define cc % "\\fR}\\fP" %
-.EN
-.de PT
-..
-.de BT
-..
-.ps 11
-.nr PS 11
-\&
-.sp 8
-.ce 7
-\s+2\fBX Display Manager Control Protocol\fP\s-2
-
-\s+1\fBVersion 1.1
-
-X.Org Standard
-
-X Version 11, Release 6.8\fP\s-1
-.sp 4
-.ce 5
-\s-1Keith Packard
-
-X Consortium
-Laboratory for Computer Science
-Massachusetts Institute of Technology\s+1
-.bp
-.br
-\&
-.sp 15
-Copyright \(co 1989, 2004 The Open Group
-.sp 3
-.LP
-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:
-.LP
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-.LP
-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.
-.LP
-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.
-.LP
-.sp 3
-\fIX Window System\fP is a trademark of The Open Group.
-.de PT
-.ie o .tl 'XDMCP''X Display Manager Control Protocol '
-.el .tl 'X Display Manager Control Protocol ''XDMCP'
-..
-.bp 1
-.de BT
-.tl ''\fB % \fP''
-..
-.NH 1
-Purpose and Goals
-.XS
-\*(SN Purpose and Goals
-.XE
-.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
-.PN fork/exec
-sequence on the host.)
-An X terminal (screen, keyboard, mouse, processor, network interface)
-is a prime example of an autonomous display.
-.LP
-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:
-.IP \(bu 5
-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.
-.IP \(bu 5
-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.
-.IP \(bu 5
-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.
-.LP
-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.
-.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.
-.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:
-.IP \(bu 5
-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.
-.IP \(bu 5
-It should be possible for the display and the login service to negotiate the
-authorization mechanism to be used for the standard X protocol.
-.IP \(bu 5
-It should be possible to provide the same level of security in verifying the
-login service as is provided by the negotiated authorization mechanism.
-.IP \(bu 5
-Because there are no firm standards yet in the area of security,
-XDMCP must be flexible enough to accomodate a variety of security mechanisms.
-.NH 1
-Overview of the Protocol
-.XS
-\*(SN Overview of the Protocol
-.XE
-.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.
-.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.
-.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.
-.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.
-.NH 1
-Data Types
-.XS
-\*(SN Data Types
-.XE
-.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.
-.TS H
-lw(1.25i) lw(.75i) lw(3.5i).
-_
-.sp 6p
-.B
-Type Name Length (Bytes) Description
-.sp 6p
-_
-.sp 6p
-.R
-.TH
-CARD8 1 A single byte unsigned integer
-CARD16 2 Two byte unsigned integer
-CARD32 4 Four byte unsigned integer
-ARRAY8 n+2 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
-ARRAY16 2*m+1 This is a CARD8 (m) which specifies the
- number of CARD16 values to follow
-ARRAY32 4*l+1 This is a CARD8 (l) which specifies the
- number of CARD32 values to follow
-ARRAYofARRAY8 ? This is a CARD8 which specifies the
- number of ARRAY8 values to follow.
-.sp 6p
-_
-.TE
-.NH 1
-Packet Format
-.XS
-\*(SN Packet Format
-.XE
-.LP
-All XDMCP packets have the following information:
-.TS
-lw(1.25i) lw(.75i) lw(3.5i).
-_
-.sp 6p
-.B
-Length (Bytes) Field Type Description
-.sp 6p
-_
-.R
-2 CARD16 version number
-2 CARD16 opcode packet header
-2 CARD16 n = length of remaining data in bytes
-
-n ??? packet-specific data
-.sp 6p
-_
-.TE
-.LP
-The fields are as follows:
-.IP \(bu 5
-Version number
-.IP
-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).
-.IP \(bu 5
-Opcode
-.IP
-This specifies what step of the protocol this packet represents and should
-contain one of the following values (encoding provided in section below):
-.PN BroadcastQuery ,
-.PN Query ,
-.PN IndirectQuery ,
-.PN ForwardQuery ,
-.PN Willing ,
-.PN Unwilling ,
-.PN Request ,
-.PN Accept ,
-.PN Decline ,
-.PN Manage ,
-.PN Refuse ,
-.PN Failed ,
-.PN KeepAlive ,
-or
-.PN Alive .
-.IP \(bu 5
-Length of data in bytes
-.IP
-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.
-.LP
-Packets should be checked to make sure that they satisfy the following
-conditions:
-.IP 1. 5
-They must contain valid opcodes.
-.IP 2. 5
-The length of the remaining data should correspond to the sum of the
-lengths of the individual remaining data items.
-.IP 3. 5
-The opcode should be expected (a finite state diagram is given
-in a later section).
-.IP 4. 5
-If the packet is of type
-.PN Manage
-or
-.PN Refuse ,
-the Session ID should match the value sent in the preceding
-.PN Accept
-packet.
-.NH 1
-Protocol
-.XS
-\*(SN Protocol
-.XE
-.LP
-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.
-.LP
-.PN Query
-.br
-.PN BroadcastQuery
-.br
-.PN IndirectQuery
-.RS
-Display \(-> Manager
-.br
-Additional Fields:
-.RS
-\fIAuthentication Names\fP: ARRAYofARRAY8
-.RS
-Specifies a list of authentication names that the display supports.
-The manager will choose one of these and return it in the
-.PN Willing
-packet.
-.RE
-.RE
-Semantics:
-.RS
-A
-.PN Query
-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
-.PN Willing
-if it is willing to service the display or
-.PN Unwilling
-if it is not.
-.LP
-A
-.PN BroadcastQuery
-packet is similar to the
-.PN Query
-packet except that it is intended to be received by all hosts on the network
-(or subnetwork). However, unlike
-.PN Query
-requests, hosts that are not willing to service the display
-should simply ignore
-.PN BroadcastQuery
-requests.
-.LP
-An
-.PN IndirectQuery
-packet is sent to a well known manager that forwards
-the request to a larger collection of secondary managers using
-.PN ForwardQuery
-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
-.PN Willing
-packet in response to this packet.
-.LP
-Each packet type has slightly different semantics:
-.IP \(bu 5
-The
-.PN Query
-packet is destined only for a single host.
-If the display is instructed to
-.PN Query
-multiple managers, it will send multiple
-.PN Query
-packets. The
-.PN Query
-packet also demands a response from the manager, either
-.PN Willing
-or
-.PN Unwilling .
-.IP \(bu 5
-The
-.PN BroadcastQuery
-packet is sent to many hosts.
-Each manager that receives this packet will not respond with an
-.PN Unwilling
-packet.
-.IP \(bu 5
-The
-.PN IndirectQuery
-packet is sent to only one manager with the request
-that the request be forwarded to a larger list of managers using
-.PN ForwardQuery
-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
-.PN BroadcastQuery except that
-.PN BroadcastQuery
-is not forwarded.
-.RE
-Valid Responses:
-.RS
-.PN Willing ,
-.PN Unwilling
-.RE
-Problems/Solutions:
-.RS
-Problem:
-.RS
-Not all managers receive the query packet.
-.RE
-.RS
-Indication:
-.RS
-None if
-.PN BroadcastQuery
-or
-.PN IndirectQuery
-was sent, else failure to receive
-.PN Willing .
-.RE
-Solution:
-.RS
-Repeatedly send the packet while waiting for user to choose a manager.
-.RE
-.RE
-.RE
-Timeout/Retransmission policy:
-.RS
-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.
-.RE
-.RE
-.LP
-.PN ForwardQuery
-.RS
-Primary Manager \(-> Secondary Manager
-.br
-Additional Fields:
-.RS
-\fIClient Address\fP: ARRAY8
-.RS
-Specifies the network address of the client display.
-.RE
-\fIClient Port\fP: ARRAY8
-.RS
-Specifies an identification of the client task on the client display.
-.RE
-\fIAuthentication Names\fP: ARRAYofARRAY8
-.RS
-Is a duplicate of Authentication Names array that was received
-in the
-.PN IndirectQuery
-packet.
-.RE
-.RE
-Semantics:
-.RS
-When primary manager receives a
-.PN IndirectQuery
-packet, it is responsible for sending
-.PN ForwardQuery
-packets to an appropriate list of
-managers that can provide service to the display using the same network
-type as the one the original
-.PN IndirectQuery
-packet was received from.
-The Client Address and Client Port fields must contain an
-address that the secondary manager can use to reach the display also using
-this same network. Each secondary manager sends a
-.PN Willing
-packet to the display if it is willing to provide service.
-.LP
-.PN ForwardQuery
-packets are similar to
-.PN BroadcastQuery
-packets in that managers that are not willing to service
-particular displays should not send a
-.PN Unwilling
-packet.
-.RE
-Valid Responses:
-.RS
-.PN Willing
-.RE
-Problems/Solutions:
-.RS
-Identical to
-.PN BroadcastQuery
-.RE
-Timeout/Retransmission policy:
-.RS
-Like all packets sent from a manager, this packet should never be
-retransmitted.
-.RE
-.RE
-.LP
-.PN Willing
-.RS
-Manager \(-> Display
-.br
-Additional Fields:
-.RS
-\fIAuthentication Name\fP: ARRAY8
-.RS
-Specifies the authentication method, selected from the list offered in the
-.PN Query ,
-.PN BroadcastQuery ,
-or
-.PN IndirectQuery
-packet that the manger expects the display to use in the subsequent
-.PN Request
-packet.
-This choice should remain as constant as feasible so that displays that
-send multiple
-.PN Query
-packets can use the Authentication Name from any
-.PN Willing
-packet that arrives.
-.LP
-The display is free to ignore managers that request an insufficient level
-of authentication.
-.RE
-\fIHostname\fP: ARRAY8
-.RS
-Is a human readable string describing the host from which the packet was sent.
-The protocol specifies no interpretation of the data in this field.
-.RE
-\fIStatus\fP: ARRAY8
-.RS
-Is a human readable string describing the status of the host. This could
-include load average/number of users connected or other information. The
-protocol specifies no interpretation of the data in this field.
-.RE
-.RE
-Semantics:
-.RS
-A
-.PN Willing
-packet is sent by managers that may service connections from
-this display. It is sent in response to either a
-.PN Query ,
-.PN BroadcastQuery ,
-or
-.PN ForwardQuery
-but does not imply a commitment to provide service
-(for example, it may later decide that it has accepted enough
-connections already).
-.RE
-Problems/Solutions:
-.RS
-Problem:
-.RS
-.PN Willing
-not received by the display.
-.br
-Indication:
-.RS
-None if
-.PN BroadcastQuery
-or
-.PN IndirectQuery
-was sent, else failure to receive
-.PN Willing .
-.RE
-Solution:
-.RS
-The display should continue to send the query until a response is received.
-.RE
-.RE
-.RE
-Timeout/Retransmission policy:
-.RS
-Like all packets sent from the manager to the display, this packet should
-never be retransmitted.
-.RE
-.RE
-.LP
-.PN Unwilling
-.RS
-Manager \(-> Display
-.br
-Additional Fields:
-.RS
-The Hostname and Status fields as in the
-.PN Willing
-packet.
-The Status field should indicate to the user a reason
-for the refusal of service.
-.RE
-Semantics:
-.RS
-An
-.PN Unwilling
-packet is sent by managers in response to direct
-.PN Query
-requests (as opposed to
-.PN BroadcastQuery
-or
-.PN IndirectQuery
-requests) if the manager will not accept requests for management.
-This is typically sent by managers that wish to only service
-particular displays or that handle a limited number of displays at once.
-.RE
-Problems/Solutions:
-.RS
-Problem:
-.RS
-.PN Unwilling
-not received by the display.
-.br
-Indication:
-.RS
-Display fails to receive
-.PN Unwilling .
-.RE
-Solution:
-.RS
-The display should continue to send
-.PN Query
-messages until a response is received.
-.RE
-.RE
-.RE
-Timeout/Retransmission policy:
-.RS
-Like all packets sent from the manager to the display, this packet should
-never be retransmitted.
-.RE
-.RE
-.LP
-.PN Request
-.br
-.RS
-Display \(-> Manager
-.br
-Additional Fields:
-.RS
-\fIDisplay Number\fP: CARD16
-.RS
-Specifies the index of this particular server for the host
-on which the display is resident.
-This value will be zero for most autonomous displays.
-.RE
-\fIConnection Types\fP: ARRAY16
-.RS
-Specifies an array indicating the stream services accepted by the display.
-If the high-order byte in a particular entry is zero, the low-order byte
-corresponds to an X-protocol host family type.
-.RE
-\fIConnection Addresses\fP: ARRAYofARRAY8
-.RS
-For each connection type in the previous array, the corresponding entry in
-this array indicates the network address of the display device.
-.RE
-\fIAuthentication Name\fP: ARRAY8
-.br
-\fIAuthentication Data\fP: ARRAY8
-.RS
-Specifies the authentication protocol that the display expects
-the manager to validate itself with. The Authentication Data is
-expected to contain data that the manager will interpret, modify
-and use to authenticate itself.
-.RE
-\fIAuthorization Names\fP: ARRAYofARRAY8
-.RS
-Specifies which types of authorization the display supports. The
-manager may decide to reject displays with which it cannot perform
-authorization.
-.RE
-\fIManufacturer Display ID\fP: ARRAY8
-.RS
-Can be used by the manager to determine how to decrypt the
-Authentication Data field in this packet. See the section below on
-Manufacturer Display ID Format.
-.RE
-.RE
-Semantics:
-.RS
-A
-.PN Request
-packet is sent by a display to a specific host to request a
-session ID in preparation for a establishing a connection. If the manager
-is willing to service a connection to this display, it should return an
-.PN Accept
-packet with a valid session ID and should be ready for a subsequent
-.PN Manage
-request. Otherwise, it should return a
-.PN Decline
-packet.
-.RE
-Valid Responses:
-.RS
-.PN Accept ,
-.PN Decline
-.RE
-Problems/Solutions:
-.RS
-Problem:
-.RS
-Request not received by manager.
-.br
-Indication:
-.RS
-Display timeout waiting for response.
-.RE
-Solution:
-.RS
-Display resends
-.PN Request
-message.
-.RE
-.RE
-Problem:
-.RS
-Message received out of order by manager.
-.br
-Indication:
-.RS
-None.
-.RE
-Solution:
-.RS
-Each time a
-.PN Request
-is sent, the manager sends the Session ID
-associated with the next session in the
-.PN Accept .
-If that next session is not yet started,
-the manager will simply resend with the same Session ID.
-If the session is in progress, the manager will reply
-with a new Session ID; in which case, the
-.PN Accept
-will be discarded by the display.
-.RE
-.RE
-.RE
-Timeout/Retransmission policy:
-.RS
-Timeout after 2 seconds, exponential backoff to 32 seconds.
-After no more than 126 seconds, give up and report an error to the user.
-.RE
-.RE
-.LP
-.PN Accept
-.RS
-Manager \(-> Display
-.br
-Additional Fields:
-.RS
-\fISession ID\fP: CARD32
-.RS
-Identifies the session that can be started by the manager.
-.RE
-\fIAuthentication Name\fP: ARRAY8
-.br
-\fIAuthentication Data\fP: ARRAY8
-.RS
-Is the data sent back to the display to authenticate the manager.
-If the Authentication Data is not the value expected by the display, it
-should terminate the protocol at this point and display an error to the user.
-.RE
-\fIAuthorization Name\fP: ARRAY8
-.br
-\fIAuthorization Data\fP: ARRAY8
-.RS
-Is the data sent to the display to indicate the type of authorization the
-manager will be using in the first call to
-.PN XOpenDisplay
-after the
-.PN Manage
-packet is received.
-.RE
-.RE
-Semantics:
-.RS
-An
-.PN Accept
-packet is sent by a manager in response to a
-.PN Request
-packet if the manager is willing to establish a connection for the display.
-The Session ID is used to identify this connection from any preceding
-ones and will be used by the display in its subsequent
-.PN Manage
-packet.
-The Session ID is a 32-bit number that is incremented each time an
-.PN Accept
-packet is sent as it must be unique over a reasonably long period of time.
-.LP
-If the authentication information is invalid, a
-.PN Decline
-packet will be returned with an appropriate
-.PN Status
-message.
-.RE
-Problems/Solutions:
-.RS
-Problem:
-.RS
-.PN Accept
-or
-.PN Decline
-not received by display.
-.br
-Indication:
-.RS
-Display timeout waiting for response to
-.PN Request .
-.RE
-Solution:
-.RS
-Display resends
-.PN Request
-message.
-.RE
-.RE
-Problem:
-.RS
-Message received out of order by display.
-.br
-Indication:
-.RS
-Display receives
-.PN Accept
-after
-.PN Manage
-has been sent.
-.RE
-Solution:
-.RS
-Display discards
-.PN Accept
-messages after it has sent a
-.PN Manage
-message.
-.RE
-.RE
-.RE
-Timeout/Retransmission policy:
-.RS
-Like all packets sent from the manager to the display, this packet should
-never be retransmitted.
-.RE
-.RE
-.LP
-.PN Decline
-.RS
-Manager \(-> Display
-.br
-Additional Fields:
-.RS
-\fIStatus\fP: ARRAY8
-.RS
-Is a human readable string indicating the reason for refusal of
-service.
-.RE
-\fIAuthentication Name\fP:
-ARRAY8
-.br
-\fIAuthentication Data\fP:
-ARRAY8
-.RS
-Is the data sent back to the display to authenticate the manager. If the
-Authentication Data is not the value expected by the display, it
-should terminate the protocol at this point and display an error to the user.
-.RE
-.RE
-Semantics:
-.RS
-A
-.PN Decline
-packet is sent by a manager in response to a
-.PN Request
-packet if the manager is unwilling to establish a connection for the
-display.
-This is allowed even if the manager had responded
-.PN Willing
-to a previous query.
-.RE
-Problems/Solutions:
-.RS
-Same as for
-.PN Accept .
-.RE
-Timeout/Retransmission policy:
-.RS
-Like all packets sent from a manager to a display, this packet should never
-be retransmitted.
-.RE
-.RE
-.LP
-.PN Manage
-.RS
-Display \(-> Manager
-.br
-Additional Fields:
-.RS
-\fISession ID\fP: CARD32
-.RS
-Should contain the nonzero session ID returned in the
-.PN Accept
-packet.
-.RE
-\fIDisplay Number\fP: CARD16
-.RS
-Must match the value sent in the previous
-.PN Request
-packet.
-.RE
-\fIDisplay Class\fP: ARRAY8
-.RS
-Specifies the class of the display.
-See the Display Class Format section,
-which discusses the format of this field.
-.RE
-.RE
-Semantics:
-.RS
-A
-.PN Manage
-packet is sent by a display to ask the manager to begin a
-session on the display. If the Session ID is correct the manager
-should open a connection; otherwise, it should respond with a
-.PN Refuse
-or
-.PN Failed
-packet, unless the Session ID matches a currently
-running session or a session that has not yet successfully opened the
-display but has not given up the attempt. In this latter case, the
-.PN Manage
-packet should be ignored.
-This will work as stream connections give positive success indication
-to both halves of the stream, and positive failure indication
-to the connection initiator (which will eventually generate a
-.PN Failed
-packet).
-.RE
-Valid Responses:
-.RS
-X connection with correct auth info,
-.PN Refuse ,
-.PN Failed .
-.RE
-Problems/Solutions:
-.RS
-Problem:
-.RS
-.PN Manage
-not received by manager.
-.br
-Indication:
-.RS
-Display timeout waiting for response.
-.RE
-Solution:
-.RS
-Display resends
-.PN Manage
-message.
-.RE
-.RE
-Problem:
-.RS
-.PN Manage
-received out of order by manager.
-.br
-Indication:
-.RS
-Session already in progress with matching Session ID.
-.RE
-Solution:
-.RS
-.PN Manage
-packet ignored.
-.RE
-Indication:
-.RS
-Session ID does not match next Session ID.
-.RE
-Solution:
-.RS
-.PN Refuse
-message is sent.
-.RE
-.RE
-Problem:
-.RS
-Display cannot be opened on selected stream.
-.br
-Indication:
-.RS
-Display connection setup fails.
-.RE
-Solution:
-.RS
-.PN Failed
-message is sent including a human readable reason.
-.RE
-.RE
-Problem:
-.RS
-Display open does not succeed before a second manage packet is received
-because of a timeout occuring in the display.
-.br
-Indication:
-.RS
-.PN Manage
-packet received with Session ID matching the session
-attempting to connect to the display.
-.RE
-Solution:
-.RS
-.PN Manage
-packet is ignored. As the stream connection will either
-succeed, which will result in an active session, or the stream will
-eventually give up hope of connecting and send a
-.PN Failed
-packet; no response to this
-.PN Manage
-packet is necessary.
-.RE
-.RE
-.RE
-Timeout/Retransmission policy:
-.RS
-Timeout after 2 seconds, exponential backoff to 32 seconds. After no more
-than 126 seconds, give up and report an error to the user.
-.RE
-.RE
-.LP
-.PN Refuse
-.RS
-Manager \(-> Display
-.br
-Additional Fields:
-.RS
-\fISession ID\fP: CARD32
-.RS
-Should be set to the Session ID received in the
-.PN Manage
-packet.
-.RE
-.RE
-Semantics:
-.RS
-A
-.PN Refuse
-packet is sent by a manager when the Session ID received in the
-.PN Manage
-packet does not match the current Session ID.
-The display should assume that it received an old
-.PN Accept
-packet and should resend its
-.PN Request
-packet.
-.RE
-Problems/Solutions:
-.RS
-Problem:
-.RS
-Error message is lost.
-.br
-Indication:
-.RS
-Display times out waiting for
-new connection,
-.PN Refuse
-or
-.PN Failed .
-.RE
-Solution:
-.RS
-Display resends
-.PN Manage
-message.
-.RE
-.RE
-.RE
-Timeout/Retransmission policy:
-.RS
-Like all packets sent from a manager to a display, this packet should never be
-retransmitted.
-.RE
-.RE
-.LP
-.PN Failed
-.RS
-Manager \(-> Display
-.br
-Additional Fields:
-.RS
-\fISession ID\fP: CARD32
-.RS
-Should be set to the Session ID received in the
-.PN Manage
-packet.
-.RE
-\fIStatus\fP: ARRAY8
-.RS
-Is a human readable string indicating the reason for failure.
-.RE
-.RE
-Semantics:
-.RS
-A
-.PN Failed
-packet is sent by a manager when it has problems establishing
-the initial X connection in response to the
-.PN Manage
-packet.
-.RE
-Problems/Solutions
-.RS
-Same as for
-.PN Refuse .
-.RE
-.RE
-.LP
-.PN KeepAlive
-.RS
-Display \(-> Manager
-.br
-Additional Fields:
-.RS
-\fIDisplay Number\fP: CARD16
-.RS
-Set to the display index for the display host.
-.RE
-.RE
-.RS
-\fISession ID\fP: CARD32
-.RS
-Should be set to the Session ID received in the
-.PN Manage
-packet during the negotiation for the current session.
-.RE
-.RE
-Sematics:
-.RS
-A
-.PN KeepAlive
-packet can be sent at any time during the session by a
-display to discover if the manager is running.
-The manager should respond with
-.PN Alive
-whenever it receives this type of packet.
-.LP
-This allows the display to discover when the manager host
-is no longer running.
-A display is not required to send
-.PN KeepAlive
-packets and, upon lack of receipt of
-.PN Alive
-packets, is not required to perform any specific action.
-.LP
-The expected use of this packet is to terminate an active session when the
-manager host or network link fails. The display should keep track of the
-time since any packet has been received from the manager host and use
-.PN KeepAlive
-packets when a substantial time has elapsed since the
-most recent packet.
-.RE
-Valid Responses:
-.RS
-.PN Alive
-.RE
-Problems/Solutions:
-.RS
-Problem:
-.RS
-Manager does not receive the packet or display does not receive the response.
-.RE
-.RS
-Indication:
-.RS
-No
-.PN Alive
-packet is returned.
-.RE
-Solution:
-.RS
-Retransmit the packet with an exponential backoff; start at 2 seconds and
-assume the host is not up after no less than 30 seconds.
-.RE
-.RE
-.RE
-.RE
-.LP
-.PN Alive
-.RS
-Manager \(-> Display
-.br
-Additional Fields:
-.RS
-\fISession Running\fP: CARD8
-.RS
-Indicates that the session identified by Session ID is
-currently active. The value is zero if no session is active
-or one if a session
-is active.
-.RE
-\fISession ID\fP: CARD32
-.RS
-Specifies the ID of the currently running session; if any.
-When no session is active this field should be zero.
-.RE
-.RE
-Semantics:
-.RS
-An
-.PN Alive
-packet is sent in response to a
-.PN KeepAlive
-request.
-If a session is currently active on the display, the manager includes the
-Session ID in the packet. The display can use this information to
-determine the status of the manager.
-.RE
-.RE
-.NH 1
-Session Termination
-.XS
-\*(SN Session Termination
-.XE
-.LP
-When the session is over, the initial connection with the display (the one
-that acknowledges the
-.PN Manage
-packet) will be closed by the manager.
-If only a single session was active on the display,
-all other connections should be closed by the display
-and the display should be reset. If multiple sessions
-are active simultaneously and the display can identify which connections
-belong to the terminated sesssion, those connections should be closed.
-Otherwise, all connections should be closed and the display reset only when
-all sessions have been terminated (that is, all initial connections closed).
-.LP
-The session may also be terminated at any time by the display if the
-managing host no longer responds to
-.PN KeepAlive
-packets.
-The exact time-outs for sending
-.PN KeepAlive
-packets is not specified in this protocol as the trade off
-should not be fixed between loading an otherwise idle system with spurious
-.PN KeepAlive
-packets and not noticing that the manager host is down for a long time.
-.NH 1
-State Diagrams
-.XS
-\*(SN State Diagrams
-.XE
-.LP
-The following state diagrams are designed to cover all actions of both
-the display and the manager. Any packet that is received out-of-sequence
-will be ignored.
-.LP
-Display:
-.RS
-.sp
-.LP
-\fIstart\fP:
-.RS
-User-requested connect to one host \(-> \fIquery\fP
-.br
-User-requested connect to some host \(-> \fIbroadcast\fP
-.br
-User-requested connect to site host-list \(-> \fIindirect\fP
-.RE
-.sp
-.LP
-\fIquery\fP:
-.RS
-Send
-.PN Query
-packet
-.br
-\(-> \fIcollect-query\fP
-.RE
-.sp
-.LP
-\fIcollect-query\fP:
-.RS
-Receive
-.PN Willing
-\(-> \fIstart-connection\fP
-.br
-Receive
-.PN Unwilling
-\(-> \fIstop-connection\fP
-.br
-Timeout \(-> \fIquery\fP
-.RE
-.sp
-.LP
-\fIbroadcast\fP:
-.RS
-Send
-.PN BroadcastQuery
-packet
-.br
-\(-> \fIcollect-broadcast-query\fP
-.RE
-.sp
-.LP
-\fIcollect-broadcast-query\fP:
-.RS
-Receive
-.PN Willing
-\(-> \fIupdate-broadcast-willing\fP
-.br
-User-requested connect to one host \(-> \fIstart-connection\fP
-.br
-Timeout \(-> \fIbroadcast\fP
-.RE
-.sp
-.LP
-\fIupdate-broadcast-willing\fP:
-.RS
-Add new host to the host list presented to the user
-.br
-\(-> \fIcollect-broadcast-query\fP
-.RE
-.sp
-.LP
-\fIindirect\fP:
-.RS
-Send
-.PN IndirectQuery
-packet
-.br
-\(-> \fIcollect-indirect-query\fP
-.RE
-.sp
-.LP
-\fIcollect-indirect-query\fP:
-.RS
-Receive
-.PN Willing
-\(-> \fIupdate-indirect-willing\fP
-.br
-User-requested connect to one host \(-> \fIstart-connection\fP
-.br
-Timeout \(-> \fIindirect\fP
-.RE
-.sp
-.LP
-\fIupdate-indirect-willing\fP:
-.RS
-Add new host to the host list presented to the user
-.br
-\(-> \fIcollect-indirect-query\fP
-.RE
-.sp
-.LP
-\fIstart-connection\fP:
-.RS
-Send
-.PN Request
-packet
-.br
-\(-> \fIawait-request-response\fP
-.RE
-.sp
-.LP
-\fIawait-request-response\fP:
-.RS
-Receive
-.PN Accept
-\(-> \fImanage\fP
-.br
-Receive
-.PN Decline
-\(-> \fIstop-connection\fP
-.br
-Timeout \(-> \fIstart-connection\fP
-.RE
-.sp
-.LP
-\fImanage\fP:
-.RS
-Save Session ID
-.br
-Send
-.PN Manage
-packet with Session ID
-.br
-\(-> \fIawait-manage-response\fP
-.RE
-.sp
-.LP
-\fIawait-manage-response\fP:
-.RS
-Receive
-.PN XOpenDisplay :
-\(-> \fIrun-session\fP
-.br
-Receive
-.PN Refuse
-with matching Session ID \(-> \fIstart-connection\fP
-.br
-Receive
-.PN Failed
-with matching Session ID \(-> \fIstop-connection\fP
-.br
-Timeout \(-> \fImanage\fP
-.RE
-.sp
-.LP
-\fIstop-connection\fP:
-.RS
-Display cause of termination to user
-.br
-\(-> \fIstart\fP
-.RE
-.sp
-.LP
-\fIrun-session\fP:
-.RS
-Decide to send
-.PN KeepAlive
-packet \(-> \fIkeep-alive\fP
-.br
-Await close of first display connection
-.br
-\(-> \fIreset-display\fP
-.RE
-.sp
-.LP
-\fIkeep-alive\fP:
-.RS
-Send
-.PN KeepAlive
-packet with current Session ID
-.br
-\(-> \fIawait-alive\fP
-.RE
-.sp
-.LP
-\fIawait-alive\fP:
-.RS
-Receive
-.PN Alive
-with matching Session ID \(-> \fIrun-session\fP
-.br
-Receive
-.PN Alive
-with nonmatching Session ID
-or FALSE Session Running \(-> \fIreset-display\fP
-.br
-Final timeout without receiving
-.PN Alive
-packet \(-> \fIreset-display\fP
-.br
-Timeout \(-> \fIkeep-alive\fP
-.RE
-.sp
-.LP
-\fIreset-display\fP:
-.RS
-(if possible) \(-> close all display connections associated with this session
-.br
-Last session \(-> close all display connections
-.br
-\(-> \fIstart\fP
-.RE
-.RE
-.LP
-Manager:
-.RS
-.sp
-.LP
-\fIidle\fP:
-.RS
-Receive
-.PN Query
-\(-> \fIquery-respond\fP
-.br
-Receive
-.PN BroadcastQuery
-\(-> \fIbroadcast-respond\fP
-.br
-Receive
-.PN IndirectQuery
-\(-> \fIindirect-respond\fP
-.br
-Receive
-.PN ForwardQuery
-\(-> \fIforward-respond\fP
-.br
-Receive
-.PN Request
-\(-> \fIrequest-respond\fP
-.br
-Receive
-.PN Manage
-\(-> \fImanage\fP
-.br
-An active session terminates \(-> \fIfinish-session\fP
-.br
-Receive
-.PN KeepAlive
-\(-> \fIsend-alive\fP
-.br
-\(-> \fIidle\fP
-.RE
-.sp
-.LP
-\fIquery-respond\fP:
-.RS
-If willing to manage \(-> \fIsend-willing\fP
-.br
-\(-> \fIsend-unwilling\fP
-.RE
-.sp
-.LP
-\fIbroadcast-respond\fP:
-.RS
-If willing to manage \(-> \fIsend-willing\fP
-.br
-\(-> \fIidle\fP
-.RE
-.sp
-.LP
-\fIindirect-respond\fP:
-.RS
-Send
-.PN ForwardQuery
-packets to all managers on redirect list
-.br
-If willing to manage \(-> \fIsend-willing\fP
-.br
-\(-> \fIidle\fP
-.RE
-.sp
-.LP
-\fIforward-respond\fP:
-.RS
-Decode destination address, if willing to manage \(-> \fIsend-willing\fP
-.br
-\(-> \fIidle\fP
-.RE
-.sp
-.LP
-\fIsend-willing\fP:
-.RS
-Send
-.PN Willing
-packet
-.br
-\(-> \fIidle\fP
-.RE
-.sp
-.LP
-\fIsend-unwilling\fP:
-.RS
-Send
-.PN Unwilling
-packet
-.br
-\(-> \fIidle\fP
-.RE
-.sp
-.LP
-\fIrequest-respond\fP:
-.RS
-If manager is willing to allow a session on display \(-> \fIaccept-session\fP
-.br
-\(-> \fIdecline-session\fP
-.RE
-.sp
-.LP
-\fIaccept-session\fP:
-.RS
-Generate Session ID and save Session ID, display address, and
-display number somewhere
-.br
-Send
-.PN Accept
-packet
-.br
-\(-> \fIidle\fP
-.RE
-.sp
-.LP
-\fIdecline-session\fP:
-.RS
-Send
-.PN Decline
-packet
-.br
-\(-> \fIidle\fP
-.RE
-.sp
-.LP
-\fImanage\fP:
-.RS
-If Session ID matches saved Session ID \(-> \fIrun-session\fP
-.br
-If Session ID matches Session ID of session in process of
-starting up, or currently active session \(-> \fIidle\fP
-.br
-\(-> \fIrefuse\fP
-.RE
-.sp
-.LP
-\fIrefuse\fP:
-.RS
-Send
-.PN Refuse
-packet
-.br
-\(->
-\fIidle\fP
-.RE
-.sp
-.LP
-\fIrun-session\fP:
-.RS
-Terminate any session in progress
-.br
-.PN XOpenDisplay
-.br
-Open display succeeds \(->
-\fIstart-session\fP
-.br
-\(->
-\fIfailed\fP
-.RE
-.sp
-.LP
-\fIfailed\fP:
-.RS
-Send
-.PN Failed
-packet
-.br
-\(-> \fIidle\fP
-.RE
-.sp
-.LP
-\fIstart-session\fP:
-.RS
-Start a new session
-.br
-\(-> \fIidle\fP
-.RE
-.sp
-.LP
-\fIfinish-session\fP:
-.RS
-.PN XCloseDisplay
-.br
-\(-> \fIidle\fP
-.RE
-.sp
-.LP
-\fIsend-alive\fP:
-.RS
-Send
-.PN Alive
-packet containing current status
-.br
-\(-> \fIidle\fP
-.RE
-.RE
-.NH 1
-Protocol Encoding
-.XS
-\*(SN Protocol Encoding
-.XE
-.LP
-When XDMCP is implemented on top of the Internet User Datagram Protocol (UDP),
-port number 177 is to be used. When using UDP over IPv4, Broadcast Query
-packets are sent via UDP broadcast. When using UDP over IPv6, Broadcast Query
-packets are sent via multicast, either to an address in the IANA registered
-XDMCP multicast address range of FF0\fIX\fP:0:0:0:0:0:0:12B
-(where the \fIX\fP is replaced by a valid scope id) or to a locally assigned
-multicast address. The version number in all packets will be 1.
-Packet opcodes are 16-bit integers.
-.RS
-.TS
-l l.
-_
-.sp 6p
-.B
-Packet Name Encoding
-.sp 6p
-_
-.sp 6p
-.R
-T{
-.PN BroadcastQuery
-T} T{
-1
-T}
-T{
-.PN Query
-T} T{
-2
-T}
-T{
-.PN IndirectQuery
-T} T{
-3
-T}
-T{
-.PN ForwardQuery
-T} T{
-4
-T}
-T{
-.PN Willing
-T} T{
-5
-T}
-T{
-.PN Unwilling
-T} T{
-6
-T}
-T{
-.PN Request
-T} T{
-7
-T}
-T{
-.PN Accept
-T} T{
-8
-T}
-T{
-.PN Decline
-T} T{
-9
-T}
-T{
-.PN Manage
-T} T{
-10
-T}
-T{
-.PN Refuse
-T} T{
-11
-T}
-T{
-.PN Failed
-T} T{
-12
-T}
-T{
-.PN KeepAlive
-T} T{
-13\(dg
-T}
-T{
-.PN Alive
-T} T{
-14\(dg
-T}
-.sp 6p
-_
-.TE
-.RE
-.FS \(dg
-A previous version of this document incorrectly reversed the opcodes of
-.PN Alive
-and
-.PN KeepAlive .
-.FE
-.LP
-Per packet information follows:
-.LP
-.Ds 0
-.TA .2i .75i 1.75i 2.5i
-.ta .2i .75i 1.75i 2.5i
-.PN Query
-.PN BroadcastQuery
-.PN IndirectQuery
-.sp 3p
- 2 CARD16 version number (always 1)
- 2 CARD16 opcode (always Query, BroadcastQuery or IndirectQuery)
- 2 CARD16 length
- 1 CARD8 number of Authentication Names sent (m)
- 2 CARD16 length of first Authentication Name (m\d\s-21\s+2\u)
- m\d\s-21\s+2\u CARD8 first Authentication Name
- \&... Other Authentication Names
-.De
-Note that these three packets are identical except for the opcode field.
-.LP
-.Ds 0
-.TA .2i .75i 1.75i 2.5i
-.ta .2i .75i 1.75i 2.5i
-.PN ForwardQuery
-.sp 3p
- 2 CARD16 version number (always 1)
- 2 CARD16 opcode (always ForwardQuery)
- 2 CARD16 length
- 2 CARD16 length of Client Address (m)
- m CARD8 Client Address
- 2 CARD16 length of Client Port (n)
- n CARD8 Client Port
- 1 CARD8 number of Authentication Names sent (o)
- 2 CARD16 length of first Authentication Name (o\d\s-21\s+2\u)
- o\d\s-21\s+2\u CARD8 first Authentication Name
- \&... Other Authentication Names
-.De
-.LP
-.Ds 0
-.TA .2i .75i 1.75i 2.5i
-.ta .2i .75i 1.75i 2.5i
-.PN Willing
-.sp 3p
- 2 CARD16 version number (always 1)
- 2 CARD16 opcode (always Willing)
- 2 CARD16 length (6 + m + n + o)
- 2 CARD16 Length of Authentication Name (m)
- m CARD8 Authentication Name
- 2 CARD16 Hostname length (n)
- n CARD8 Hostname
- 2 CARD16 Status length (o)
- o CARD8 Status
-.De
-.LP
-.Ds 0
-.TA .2i .75i 1.75i 2.5i
-.ta .2i .75i 1.75i 2.5i
-.PN Unwilling
-.sp 3p
- 2 CARD16 version number (always 1)
- 2 CARD16 opcode (always Unwilling)
- 2 CARD16 length (4 + m + n)
- 2 CARD16 Hostname length (m)
- m CARD8 Hostname
- 2 CARD16 Status length (n)
- n CARD8 Status
-.De
-.LP
-.Ds 0
-.TA .2i .75i 1.75i 2.5i
-.ta .2i .75i 1.75i 2.5i
-.PN Request
-.sp 3p
- 2 CARD16 version number (always 1)
- 2 CARD16 opcode (always Request)
- 2 CARD16 length
- 2 CARD16 Display Number
- 1 CARD8 Count of Connection Types (m)
- 2 \(mu m CARD16 Connection Types
- 1 CARD8 Count of Connection Addresses (n)
- 2 CARD16 Length of first Connection Address (n\s-2\d1\u\s+2)
- n\s-2\d1\u\s+2 CARD8 First Connection Address
- \&... Other connection addresses
- 2 CARD16 Length of Authentication Name (o)
- o CARD8 Authentication Name
- 2 CARD16 Length of Authentication Data (p)
- p CARD8 Authentication Data
- 1 CARD8 Count of Authorization Names (q)
- 2 CARD16 Length of first Authorization Name (q\s-2\d1\u\s+2)
- q\s-2\d1\u\s+2 CARD8 First Authorization Name
- \&... Other authorization names
- 2 CARD16 Length of Manufacturer Display ID (r)
- r CARD8 Manufacturer Display ID
-.De
-.LP
-.Ds 0
-.TA .2i .75i 1.75i 2.5i
-.ta .2i .75i 1.75i 2.5i
-.PN Accept
-.sp 3p
- 2 CARD16 version number (always 1)
- 2 CARD16 opcode (always Accept)
- 2 CARD16 length (12 + n + m + o + p)
- 4 CARD32 Session ID
- 2 CARD16 Length of Authentication Name (n)
- n CARD8 Authentication Name
- 2 CARD16 Length of Authentication Data (m)
- m CARD8 Authentication Data
- 2 CARD16 Length of Authorization Name (o)
- o CARD8 Authorization Name
- 2 CARD16 Length of Authorization Data (p)
- p CARD8 Authorization Data
-.De
-.LP
-.Ds 0
-.TA .2i .75i 1.75i 2.5i
-.ta .2i .75i 1.75i 2.5i
-.PN Decline
-.sp 3p
- 2 CARD16 version number (always 1)
- 2 CARD16 opcode (always Decline)
- 2 CARD16 length (6 + m + n + o)
- 2 CARD16 Length of Status (m)
- m CARD8 Status
- 2 CARD16 Length of Authentication Name (n)
- n CARD8 Authentication Name
- 2 CARD16 Length of Authentication Data (o)
- o CARD8 Authentication Data
-.De
-.LP
-.Ds 0
-.TA .2i .75i 1.75i 2.5i
-.ta .2i .75i 1.75i 2.5i
-.PN Manage
-.sp 3p
- 2 CARD16 version number (always 1)
- 2 CARD16 opcode (always Manage)
- 2 CARD16 length (8 + m)
- 4 CARD32 Session ID
- 2 CARD16 Display Number
- 2 CARD16 Length of Display Class (m)
- m CARD8 Display Class
-.De
-.LP
-.Ds 0
-.TA .2i .75i 1.75i 2.5i
-.ta .2i .75i 1.75i 2.5i
-.PN Refuse
-.sp 3p
- 2 CARD16 version number (always 1)
- 2 CARD16 opcode (always Refuse)
- 2 CARD16 length (4)
- 4 CARD32 Session ID
-.De
-.LP
-.Ds 0
-.TA .2i .75i 1.75i 2.5i
-.ta .2i .75i 1.75i 2.5i
-.PN Failed
-.sp 3p
- 2 CARD16 version number (always 1)
- 2 CARD16 opcode (always Failed)
- 2 CARD16 length (6 + m)
- 4 CARD32 Session ID
- 2 CARD16 Length of Status (m)
- m CARD8 Status
-.De
-.LP
-.Ds 0
-.TA .2i .75i 1.75i 2.5i
-.ta .2i .75i 1.75i 2.5i
-.PN KeepAlive
-.sp 3p
- 2 CARD16 version number (always 1)
- 2 CARD16 opcode (always KeepAlive)
- 2 CARD16 length (6)
- 2 CARD16 Display Number
- 4 CARD32 Session ID
-.De
-.LP
-.Ds 0
-.TA .2i .75i 1.75i 2.5i
-.ta .2i .75i 1.75i 2.5i
-.PN Alive
-.sp 3p
- 2 CARD16 version number (always 1)
- 2 CARD16 opcode (always Alive)
- 2 CARD16 length (5)
- 1 CARD8 Session Running (0: not running 1: running)
- 4 CARD32 Session ID (0: not running)
-.De
-.NH 1
-Display Class Format
-.XS
-\*(SN Display Class Format
-.XE
-.LP
-The Display Class field of the
-.PN Manage
-packet is used by the display manager to collect common sorts of
-displays into manageable groups. This field is a string encoded of
-ISO-LATIN-1 characters in the following format:
-.LP
-.Ds
-\fIManufacturerID\fP\^-\^\fIModelNumber\fP
-.De
-.LP
-Both elements of this string must exclude characters of the set { \fB-\fP,
-\&\fB.\fP, \fB:\fP, \fB*\fP, \fB?\fP, \fI<space>\fP }.
-The ManufacturerID is a string that should be registered
-with the X Consortium.
-The ModelNumber is designed to identify characteristics of the display
-within the manufacturer's product line.
-This string should be documented in the users manual for the
-particular device and should probably not be specifiable by the
-display user to avoid unexpected configuration errors.
-.NH 1
-Manufacturer Display ID Format
-.XS
-\*(SN Manufacturer Display ID Format
-.XE
-.LP
-To authenticate the manager, the display and manager will share a private
-key.
-The manager, then, must be able to discover which key to use for a
-particular device.
-The Manufacturer Display ID field of the
-.PN Request
-packet is intended for this purpose. Typically, the manager host will
-contain a map between this number and the key. This field is intended to be
-unique per display, possibly the ethernet address of the display in the form:
-.LP
-.Ds
--Ethernet-8:0:2b:a:f:d2
-.De
-.LP
-It can also be a string of the form:
-.LP
-.Ds
-\fIManufacturerID\fP\^-\^\fIModelNumber\fP\^-\^\fISerialNumber\fP
-.De
-.LP
-The ManufacturerID, ModelNumber and SerialNumber are encoded using
-ISO-LATIN-1 characters, excluding { \fB-\fP,
-\&\fB.\fP, \fB*\fP, \fB?\fP, \fI<space>\fP }
-.LP
-When the display is shipped to a customer, it should include both the
-Manufacturer Display ID and the private key in the documentation set.
-This information should not be modifiable by the display user.
-.NH 1
-Authentication
-.XS
-\*(SN Authentication
-.XE
-.LP
-In an environment where authentication is not needed, XDMCP can disable
-authentication by having the display send empty Authentication Name
-and Authentication Data fields in the
-.PN Request
-packet.
-In this case, the manager will not attempt to authenticate itself.
-Other authentication protocols may be developed, depending on local needs.
-.LP
-In an unsecure environment, the display must be able to verify that the
-source of the various packets is a trusted manager. These packets will
-contain authentication information. As an example of such a system, the
-following discussion describes the "XDM-AUTHENTICATION-1" authentication
-system. This system uses a 56-bit shared private key, and 64 bits of
-authentication data. An associated example X authorization protocol
-"XDM-AUTHORIZATION-1" will also be discussed. The 56-bit key is represented
-as a 64-bit number in network order (big endian). This means that the first
-octet in the representation will be zero. When incrementing a 64-bit value,
-the 8 octets of data will be interpreted in network order (big endian).
-That is, the last octet will be incremented, subsequent carries propogate
-towards the first octet.
-.IP \(bu 5
-Assumptions
-.RS
-.IP 1. 5
-The display and manager share a private key. This key could be programmed
-into the display by the manufacturer and shipped with the unit. It must not
-be available from the display itself, but should allow the value to be
-modified in some way. The system administrator would be responsible for
-managing a database of terminal keys.
-.IP 2. 5
-The display can generate random authentication numbers.
-.RE
-.LP
-Some definitions first:
-.EQ
-oc D cc sup kappa mark = "encryption of plain text " D " by key " kappa
-.EN C
-.EQ
-oc DELTA cc * sup kappa lineup = "decryption of crypto text " DELTA " with key " kappa
-.EN C
-.EQ
-{ tau } lineup = "private key shared by display and manager"
-.EN C
-.EQ
-rho lineup = "64 bit random number generated by display"
-.EN C
-.EQ
-alpha lineup = "authentication data in XDMCP packets"
-.EN C
-.EQ
-sigma lineup = "per-session private key, generated by manager"
-.EN C
-.EQ
-beta lineup = "authorization data"
-.EN
-.LP
-Encryption will use the Data Encryption Standard (DES, FIPS 46-3); blocks
-shorter than 64 bits will be zero-filled
-on the right to 64 bits. Blocks longer than 64 bits will use block chaining:
-.EQ
-oc { D } cc sup kappa lineup = oc { D sub 1 } cc sup kappa " "
-oc { D sub 2 } " " xor " " oc { D sub 1 } cc sup kappa cc sup kappa
-.EN
-.LP
-The display generates the first authentication data in the
-.PN Request
-packet:
-.EQ
-alpha sub roman Request mark = oc rho cc sup tau
-.EN
-.LP
-For the
-.PN Accept
-packet, the manager decrypts the initial message and returns
- at alpha sub roman Accept@:
-.EQ
-rho lineup = oc alpha sub roman Request cc * sup tau
-.EN C
-.EQ
-alpha sub roman Accept lineup = oc rho + 1 cc sup tau
-.EN
-.LP
-The
-.PN Accept
-packet also contains the authorization intended for use by
-the X server. A description of authorization type ``XDM-AUTHORIZATION-1''
-follows.
-.LP
-The
-.PN Accept
-packet contains the authorization name
-``XDM-AUTHORIZATION-1''. The authorization data is the string:
-.EQ
-beta sub Accept mark = oc sigma cc sup tau
-.EN
-.LP
-To create authorization information for connection setup with the X server
-using the XDM-AUTHORIZATION-1 authorization protocol, the client computes the
-following:
-.EQ
-N mark = "X client identifier"
-.EN C
-.EQ
-T lineup = "Current time in seconds on client host (32 bits)"
-.EN
-.EQ C
-beta lineup = oc rho N T cc sup sigma
-.EN
-.LP
-For TCP connections @N@ is 48 bits long and contains the 32-bit IPv4 address of
-the client host followed by the 16-bit port number of the client socket.
-Formats for other connections must be registered.
-The resulting value, @beta@, is 192 bits of authorization data that is sent
-in the connection setup to the server. The server receives the packet,
-decrypts the contents. To accept the connection, the following must hold:
-.IP \(bu 5
- at rho@ must match the value generated for the most recent XDMCP negotiation.
-.IP \(bu 5
- at T@ must be within 1200 seconds of the internally stored time. If no time
-been received before, the current time is set to @T at .
-.IP \(bu 5
-No packet containing the same pair (@N@, @T@) can have been received
-in the last 1200 seconds (20 minutes).
-.bp
-.EH ''''
-.OH ''''
-.EF ''''
-.OF ''''
-.TC
--
1.6.0.4
More information about the xorg-devel
mailing list