Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!bruce!labtam!timr
From: timr@labtam.oz (Tim Roper)
Newsgroups: comp.windows.x
Subject: XDMCP does not allow desired policy for BroadcastQuery's
Message-ID: <2144@labtam.oz>
Date: 27 Feb 90 06:18:48 GMT
Organization: Labtam Limited., Melbourne, Australia
Lines: 47

The BroadcastQuery (and Query) packets could usefully contain the
Manufacturer Display ID.  This is to allow policies to be a function
of the display.

One such policy is for multiple xdm(1)s on the same
network to decide whether to respond with a Willing or to ignore
a BroadcastQuery.  I know that the Request packet contains this
information but suggest that this is too late.

Consider a network containing two or more compute/file servers and
some number of X terminals.  Some of the terminal users want (and/or
are allowed) to login to one file server and the other users to the
other server.  So xdm runs on both file servers.  For convenience
(ie. laziness) we want all terminals to use BroadcastQuery and to
have xdm on the file servers to know, as a matter of policy, which
BroadcastQuery's to respond to (with Willing).  For example, we could
use the existence of an entry in Xkeys.

In the absence of this information and hence the ability to implement
such policy both xdm's are responding to all BroadcastQuery's.  If the
wrong one is received first the subsequent Request packet is
Decline'd (to to absence of an Xkeys entry) if XDM-AUTHENTICATION-1 is
being used.  If MIT-MAGIC-COOKIE-1 is being used the Request is
Accept'ed but the subsequent user authentication fails (unless the
user just happens to have an account on that file server).

An example which is not a consequence of admitted laziness can be constructed
by generalising the above example.  On a given network there is a number
of file servers any of which may be used by a certain class of X terminal
(eg. student lab) and a number of file servers which may be used by another
class (eg. staff terminals).  The policy for the student file servers
and terminals is to accept requests depending on load.  So the student terminals
use BroadcastQuery and wait for a Willing response from a student file server.
with sufficiently low load.  Because the staff file servers don't want to
respond they would like to know which terminal is querying.

We could have a mapping of IP address to Manufacturer Display ID and could
even generate it from /etc/ethers given the -Ethernet-... scheme of
assigning the IDs.  But this is (a) ugly and (b) breaks down in the
presence of dynamic IP address assignment.

An alternative is for the X terminal to collect all replies to its
BroadcastQuery and attempt a Request to each Willing host.  Perhaps this
is what was intended?  (It is not what is implemented in the sample server,
but that that is not definitive of course).

-Tim.