--- gtp2-spec-draft1.tex	Fri Jul 12 16:04:48 2002
+++ gtp2-spec-draft2.tex	Sat Oct 12 20:39:42 2002
@@ -4,20 +4,20 @@
 \begin{document}
 
 \begin{titlepage}
-  \title{Specification of the Go Text Protocol, version 2, draft 1}
-  \date{July, 2002}
+  \title{Specification of the Go Text Protocol, version 2, draft 2}
+  \date{October, 2002}
   \author{Gunnar Farneb{\"a}ck}
   \maketitle
   \vfill
   \begin{center}
-  %FIXME: Do URL better.
-    http://www.lysator.liu.se/${}_{\tilde{}}\,$gunnar/gtp
+    \texttt{http://www.lysator.liu.se/\raisebox{-3pt}{\~}gunnar/gtp}
   \end{center}
   \vfill
   \begin{center}
     \textbf{\huge This is a draft only.}  
   \end{center}
   \vfill
+  %FIXME: Is GFDL invoked correctly?
   Permission is granted to make and distribute verbatim or modified
   copies of this specification provided that the terms of the GNU Free
   Documentation License (section \ref{sec:gfdl}) are respected.
@@ -30,8 +30,16 @@
 \section{Introduction}
 This document gives a specification of the Go Text Protocol (GTP),
 version 2.
+
 \subsection{Purpose of the Protocol}
 
+The intention of GTP is to provide a flexible and easy to implement
+communication protocol for go programs. The main purpose is to allow
+two programs to play each other but it is also useful for regression
+testing and communication with a GUI or a go server. Most use cases
+require an external support program, but this can be shared between
+all programs with GTP support.
+
 \subsection{History}
 The Go Text Protocol was developed within the GNU Go project,
 initially to create a framework for automated regression testing and
@@ -44,8 +52,56 @@
 version 2.
 
 \subsection{Communication Model}
+\label{sec:communication-model}
+The protocol is asymmetric and involves two parties, which we call
+controller and engine. The controller is typically some kind of
+arbiter or relay and the engine is typically a go playing program. All
+communication is initiated by the controller in form of commands, to
+which the engine responds.
+
+The communication channel is assumed to be free from errors (i.e.\ 
+those are handled at a lower level). Examples are UNIX pipes or TCP/IP
+connections. The latter can also be established over an error prone
+modem connection by using PPP (Point to Point Protocol) as a transport
+layer.
+
 \subsection{Typical Use Cases}
-\subsection{Terminology}
+%FIXME: Better layout?
+\begin{enumerate}
+\item Regression testing. \\
+  controller (regression script) --- engine \\
+  The controller sets up a board position and asks the engine to e.g.\ 
+  generate a move.
+  
+\item Human vs program. \\
+  controller (GUI) --- engine \\
+  The controller relays moves between the human and the engine and
+  asks the engine to generate moves.
+  
+\item Program vs program with arbiter. \\
+  engine 1 --- controller (arbiter) --- engine 2 \\
+  The controller relays moves between the two engines and alternately
+  asks the engines to generate moves. This involves two different GTP
+  channels, the first between the controller and engine 1, and the
+  second between the controller and engine 2. There is no direct
+  communication between the two engines. The controller dictates board
+  size, komi, etc.
+    
+\item Program vs program without arbiter. \\
+  The same as above except that engine 1 includes the controller
+  functionality and the first GTP link is shortcut.
+    
+\item Connection between go server and program. \\
+  go server --- controller (relay) --- engine \\
+  The controller talks to a go server using whatever protocol is
+  needed and listens for match requests. When one arrives it accepts
+  it, starts the go engine and issues GTP commands to set up board
+  size, komi, etc.\ and if a game is restarted it also sets up the
+  position. Then it relays moves between the server and the engine and
+  asks the engine to generate new moves when it is in turn.
+\end{enumerate}
+
+% \subsection{Terminology}
 
 \subsection{Reference Implementation}
 The reference implementation for GTP version 2 is GNU Go version 3.4.
@@ -53,7 +109,7 @@
 reference implementation decides the correct behaviour. Notice,
 however, that any command available in GNU Go 3.4, but not included in
 this specification (full list in section \ref{sec:commands}), is to be
-considered as a private extension (see section
+considered a private extension (see section
 \ref{sec:private-extensions}).
 
 Temporary comment: GNU Go 3.4 is currently under development and GTP
@@ -247,8 +303,7 @@
 
 \item \textbf{float} \\
   A \texttt{float} is a floating point number representable by a 32
-  bit IEEE ???  float. Only the "simple" representation is allowed.
-  (FIXME: rewrite)
+  bit IEEE 754 float.
 
 \item \textbf{string} \\
   A \texttt{string} is a sequence of printable, non-whitespace
@@ -256,9 +311,9 @@
 
 \item \textbf{vertex} \\
   A \texttt{vertex} is a board coordinate consisting of one letter and
-  one number, or the string ``pass'', as defined in section
-  \ref{sec:board-coordinates}.  Vertices are not case sensitive.
-  Examples: ``B13'', ``j11''.
+  one number, as defined in section \ref{sec:board-coordinates}, or
+  the string ``pass''. Vertices are not case sensitive.  Examples:
+  ``B13'', ``j11''.
   
 \item \textbf{color} \\
   A \texttt{color} is one of the strings ``white'' or ``w'' to denote
@@ -268,7 +323,7 @@
 \item \textbf{move} \\
   A \texttt{move} is the combination of one \texttt{color} and one
   \texttt{vertex}, separated by space. Moves are not case sensitive.
-  Examples: ``white h10'', ``B F5'', ``w pass''.
+  Examples: ``white~h10'', ``B~F5'', ``w~pass''.
 
 \item \textbf{boolean} \\
   A \texttt{boolean} is one of the strings ``false'' and ``true''.
@@ -330,7 +385,8 @@
 
 \begin{itemize}
 \item \texttt{id} is an optional \texttt{int} and must be the same
-  number as in the corresponding command.
+  number as in the corresponding command. It may be omitted if and
+  only if it was omitted in the command.
 \item \texttt{response} is some collection of entities, separated by
   space or a single LF, the composition of which varies with the
   command.  The response may be empty.
@@ -345,16 +401,24 @@
 
 \begin{itemize}
 \item \texttt{id} is an optional \texttt{int} and must be the same
-  number as in the corresponding command
-\item \texttt{error\_message} is a \texttt{string*}.
+  number as in the corresponding command. It may be omitted if and
+  only if it was omitted in the command.
+\item \texttt{error\_message} is a \texttt{string*\&}.
 \end{itemize}
 
 \subsection{Standard Error Messages}
+\label{sec:standard-error-messages}
+
+If the engine receives an unknown or unimplemented command, use the
+error message ``unknown~command''. Some commands fail in certain cases
+with standardized error messages. Those are listed in the command
+descriptions in section \ref{sec:list-of-all-commands}. For other
+failures the engine can freely choose error message.
 
 
 \newpage
 \section{Important Concepts}
-FIXME: Rename chapter?
+%FIXME: Rename chapter?
 
 \subsection{Handicap Placement}
 
@@ -430,29 +494,15 @@
 With free placement the handicap stones are set as chosen by the
 controller or by one of the engines (for normal tournament use the
 engine playing the black stones would make the choice). The smallest
-number of handicap stones is 2. The maximum number requires some
-discussion. Let the board size be $N$ and thus the number of vertices $N^2$.
+number of handicap stones is 2. The highest number is one less the
+number of vertices on the board. However, when the number of handicap
+stones becomes very high there is no benefit in additional stones.
+Therefore, when asked to choose handicap placement, an engine is
+allowed to return a smaller number of stones than requested. This
+provision should only be used if the requested number of stones is so
+high that a smaller number of stones is believed to guarantee that the
+engine cannot possibly lose against any opponent.
 
-The theoretical upper limit for the number of handicap stones is $N^2-1$,
-but since this would leave all stones in atari, black is clearly better
-off with fewer stones. In fact, for sufficiently large (but smaller than
-$N^2-1$) handicaps, black can arrange the stones so that white cannot
-possibly form a single living group even if black passes for the entire
-game. In particular, with $N^2/2$ stones, black can trivially place the
-stones in a chessboard pattern so that white does not have a single
-legal move.
-
-With this in mind, we do allow up to $N^2-1$ handicap stones. However,
-an engine asked to choose placement of handicap stones is allowed to
-place a smaller number of stones than the one requested, if this is
-larger than some threshold. To be more precise, let $m$ be the
-threshold and $n$ the requested number of handicap stones. If $n>=m$,
-the engine must place $m$ handicap stones and if $n<m$, the engine
-must place $n$ handicap stones. The value of $m$ is determined by the
-engine and may vary with the board size. It is recommended that every
-engine has a threshold of at least 40 for 19x19, unless it is totally
-convinced that there is some smaller number for which it cannot
-possibly lose against any opponent.
 
 \subsection{Time Handling}
 \label{sec:time-handling}
@@ -465,14 +515,15 @@
 \item Byo yomi time $b$,
 \item Byo yomi stones $s$.
 \end{itemize}
-The semantics is that the clock is first set to $m$. The engine has no
-requirements on the number of stones while this time is running. When
-it is up, the clock is reset to $b$ and the engine has to play $s$
-stones before this time is up. When $s$ stones have been played, the
-clock is reset to $b$, regardless of remaining time. Then the engine
-has to play another $s$ stones before the time is up. This procedure
-repeats until the game is over. If an engine fails to play $s$ stones
-before its byo yomi time is up, it loses on time.
+The semantics is that the clock is first set to $m$. The
+engine has no requirements on the number of stones while this time is
+running. When it is up, the clock is reset to $b$ and the
+engine has to play $s$ stones before this time is up. When $s$ stones
+have been played, the clock is reset to $b$, regardless of
+remaining time. Then the engine has to play another $s$ stones before
+the time is up. This procedure repeats until the game is over. If an
+engine fails to play $s$ stones before its byo yomi time is up, it
+loses on time.
 
 Setting $m=0$ means that the engine immediately starts in byo yomi.
 Setting $b=0$ means that if the main time is up before the game is
@@ -480,7 +531,34 @@
 limits.
 
 \subsection{Scoring}
+\label{sec:scoring}
+
+Depending on the exact choice of rules (see also section
+\ref{sec:missing-features}), scoring a finished game may be more or
+less complex. With a few exceptions it is critical to determine which
+stones are dead and which are alive. Sometimes it is also necessary to
+distinguish between life in seki and independent life.
+
+This protocol provides two commands to query the engines about score
+and group status. They are both valid only when the game is finished.
+
+The first command, \texttt{final\_score}, asks for the engine's
+opinion about the score. The result is returned as a string of the
+form \texttt{W+2.5} if white wins, \texttt{B+31} if black wins, and
+just \texttt{0} if the game ends in a draw. The number in the result
+is of course the difference between the number of points for each
+player, including komi.
+
+The second command, \texttt{final\_status\_list}, is used to query an
+engine about the status of the stones. This command takes a string
+argument which may be one of \texttt{alive}, \texttt{seki}, and
+\texttt{dead}. The result is reported by listing all stones having the
+requested status. The list is organized with one string per line. If
+an engine cannot distinguish between life in seki and independent
+life, all those stones should be reported as alive.
 
+The protocol does not include any support for resolving disagreement
+about status or score.
 
 
 \newpage
@@ -519,7 +597,7 @@
 \section{Commands}
 \label{sec:commands}
 \subsection{Required Commands}
-All implementations are required to support the following commands.
+All implementations are required to support the following commands:
 
 \begin{verbatim}
 protocol_version
@@ -539,18 +617,22 @@
 \subsubsection{Tournament}
 The tournament subset adds the commands:
 \begin{verbatim}
-fixed_handicap, place_free_handicap, set_free_handicap
+fixed_handicap
+place_free_handicap
+set_free_handicap
 \end{verbatim}
 
 
 \subsubsection{Regression}
 The regression subset adds the commands:
 \begin{verbatim}
-loadsgf, reg_genmove
+loadsgf
+reg_genmove
 \end{verbatim}
 
 
 \subsection{List of All Commands}
+\label{sec:list-of-all-commands}
 
 \subsubsection{Adminstrative Commands}
 
@@ -565,6 +647,7 @@
     comments &  For this specification 2.
   \end{tabularx}
 
+\newpage
 \item \textbf{name} \\
   \begin{tabularx}{\linewidth}{lX}
     arguments & none \\
@@ -633,11 +716,12 @@
     arguments & \texttt{size} \\
     & \texttt{int size} - New size of the board. \\
     effects & The board size is changed.
-              The board configuration, number of captured, and move
+                The board configuration, number of captured stones, and move
               history become arbitrary. \\
     output &  none \\
-    fails &   If the engine cannot handle the new size, fails with
-              the error message "unacceptable size". \\
+    fails &     Syntax error. If the engine cannot handle the new
+                size, fails with the error message
+                "unacceptable~size". \\
     comments & In GTP version 1 this command also did the work of
                \texttt{clear\_board}. This may or may not be true for
                implementations of GTP version 2. Thus the controller must
@@ -675,8 +759,8 @@
     effects &   Handicap stones are placed on the board according to the
                 specification in section \ref{sec:fixed-handicap-placement}.\\
     output &    \texttt{vertices} \\
-    & \texttt{vertex* vertices}  - A list of the vertices where handicap stones
-               have been placed. \\
+    & \texttt{vertex* vertices}  - A list of the vertices where
+                handicap stones have been placed. \\
     fails &    syntax error, invalid number of stones, board not empty \\
     comments & This command is only valid if the board is empty.
                See section \ref{sec:fixed-handicap-placement} for
@@ -685,7 +769,7 @@
                history.
   \end{tabularx}
 
-
+\newpage
 \item \textbf{place\_free\_handicap} \\
   \begin{tabularx}{\linewidth}{lX}
     arguments & \texttt{number\_of\_stones} \\
@@ -694,9 +778,10 @@
                 engine prefers. See also section
                 \ref{sec:free-handicap-placement}. \\ 
     output &    \texttt{vertices} \\
-    & \texttt{vertex* vertices}  - A list of the vertices where handicap stones
-               have been placed.\\
-    fails &    syntax error, invalid number of stones, board not empty \\
+    & \texttt{vertex* vertices}  - A list of the vertices where
+                handicap stones have been placed.\\
+    fails &     syntax error, invalid number of stones, board not
+                empty, bad vertex list \\
     comments & This command is only valid if the board is empty.
                The engine may place fewer than the requested number of
                stones on the board under certain circumstances, as
@@ -704,7 +789,7 @@
                The controller can check this by 
                counting the number of vertices in the response.
                The handicap stones are \emph{not} included in the move
-               history. \\
+                history. Vertices must not be repeated or include ``pass''. \\
   \end{tabularx}
 
 \item \textbf{set\_free\_handicap} \\
@@ -714,13 +799,13 @@
                stones should be placed on the board. \\
     effects &  Handicap stones are placed on the vertices as requested. \\
     output &   none \\
-    fails &    syntax error, board not empty \\
+    fails &     syntax error, board not empty, bad vertex list \\
     comments & This command is only valid if the board is empty.
                The list must have at least two elements and no more than
                the number of board vertices minus one.
                The engine must accept the handicap placement.
                The handicap stones are \emph{not} included in the move
-               history.
+                history. Vertices must not be repeated or include ``pass''.
   \end{tabularx}
 \end{itemize}
 
@@ -735,10 +820,13 @@
                 vertex. The number of captured stones is updated if needed 
                 and the move is added to the move history. \\
     output &    none \\
-    fails &     syntax error, illegal move \\
-    comments & 
+    fails &     syntax error, illegal move. In the latter case, fails
+                with the error message ``illegal~move''. \\
+    comments &  Consecutive moves of the same color are not considered
+                illegal from the protocol point of view.
   \end{tabularx}
 
+\newpage
 \item \textbf{genmove} \\
   \begin{tabularx}{\linewidth}{lX}
     arguments & \texttt{color} \\
@@ -750,7 +838,11 @@
     & \texttt{vertex$|$string vertex} - Vertex where the move was
                 played or the string ``resign''. \\
     fails &     never \\
-    comments & 
+    comments &  Notice that ``pass'' is a valid vertex and should
+                be returned if the engine wants to pass. Use
+                ``resign'' if you want to give up the game. The
+                controller is allowed to use this command for either
+                color, regardless who played the last move.
   \end{tabularx}
 
 \item \textbf{undo} \\
@@ -761,7 +853,7 @@
                 is removed from the move history.\\
     output &    none \\
     fails &     If the engine is unable to take back the last move, fails
-                with the error message "unable to undo".\\
+                with the error message "cannot~undo".\\
     comments &  If you want to take back multiple moves, use this command
                 multiple times.
                 The engine may fail to undo if the move history is empty or
@@ -791,6 +883,7 @@
                 gives no provision for negotiation of the time settings.
   \end{tabularx}
 
+\newpage
 \item \textbf{time\_left} \\
   \begin{tabularx}{\linewidth}{lX}
     arguments & \texttt{color time stones} \\
@@ -806,29 +899,35 @@
 
 \item \textbf{final\_score} \\
   \begin{tabularx}{\linewidth}{lX}
-    arguments &  \\
-    effects &    \\
-    output &     \\
-    fails &      \\
-  comments & 
+    arguments &  none \\
+    effects &    none \\
+    output &     \texttt{score}\\
+    & \texttt{string score} - Score as described in section
+                              \ref{sec:scoring}. \\
+    fails &      If the engine is unable to determine the score, fails
+                 with error message ``cannot~score''. \\
+    comments &   If the engine never is able to determine the score,
+                 leave the command unimplemented.
   \end{tabularx}
 
-\item \textbf{final\_status} \\
-  \begin{tabularx}{\linewidth}{lX}
-    arguments &  \\
-    effects &    \\
-    output &     \\
-    fails &      \\
-  comments & 
-  \end{tabularx}
+% \item \textbf{final\_status} \\
+%   \begin{tabularx}{\linewidth}{lX}
+%     arguments &  \\
+%     effects &    \\
+%     output &     \\
+%     fails &      \\
+%   comments & 
+%   \end{tabularx}
 
 \item \textbf{final\_status\_list} \\
   \begin{tabularx}{\linewidth}{lX}
-    arguments &  \\
-    effects &    \\
-    output &     \\
-    fails &      \\
-  comments & 
+    arguments &  \texttt{status} \\
+    & \texttt{string status} - Requested status. \\
+    effects &    none \\
+    output &     \texttt{stones} \\
+    & \texttt{vertex*\& stones} - Stones with the requested status. \\
+    fails &      syntax error \\
+    comments &   See section \ref{sec:scoring} for details. \\
   \end{tabularx}
 \end{itemize}
 
@@ -837,20 +936,43 @@
 \begin{itemize}
 \item \textbf{loadsgf} \\
   \begin{tabularx}{\linewidth}{lX}
-    arguments &  \\
-    effects &    \\
-    output &     \\
-    fails &      \\
-  comments & 
+    arguments &  \texttt{filename move\_number} \\
+    & \texttt{string filename} - Name of an sgf file. \\
+    & \texttt{int move\_number} - Optional move number. \\
+    effects &    Board size and komi are set to the values given in
+                 the sgf file. Board configuration, number of
+                 captured stones, and move history are found by
+                 replaying the game record up to the position before
+                 \texttt{move\_number} or until the end if omitted. \\
+    output &     none \\
+    fails &      Syntax error. If the file does not exist or cannot be
+                 read in because it is broken in some way, fails with
+                 the error message ``cannot~load~file''. \\
+    comments &   Due to the syntactical limitations of this protocol,
+                 the filename cannot include spaces, hash signs (\#),
+                 or control characters. The command requires the
+                 controller and the engine to share file system, or at
+                 least that the controller has sufficient knowledge
+                 about the file system of the engine. If
+                 \texttt{move\_number} is larger than the number of
+                 moves in the file, read until the end of the file.
+                 This command has no support for sgf files with
+                 variations or game collections. \\ 
   \end{tabularx}
 
 \item \textbf{reg\_genmove} \\
   \begin{tabularx}{\linewidth}{lX}
-    arguments &  \\
-    effects &    \\
-    output &     \\
-    fails &      \\
-  comments & 
+    arguments & \texttt{color} \\
+    & \texttt{color color} - Color for which to generate a move. \\
+    effects &   none \\
+    output &    \texttt{vertex} \\
+    & \texttt{vertex$|$string vertex} - Vertex where the engine would
+                want to play a move or the string ``resign''. \\
+    fails &     never \\
+    comments &  This command differs from \texttt{genmove} in that it
+                does not play the generated move. It is also advisable
+                to turn off any move randomization since that may
+                cause meaningless regression fluctuations.
   \end{tabularx}
 \end{itemize}
 
@@ -952,16 +1074,23 @@
 \begin{itemize}
 \item \textbf{showboard} \\
   \begin{tabularx}{\linewidth}{lX}
-    arguments &  \\
-    effects &    \\
-    output &     \\
-    fails &      \\
-  comments & 
+    arguments &  none \\
+    effects &    none \\
+    output &     \texttt{board} \\
+    & \texttt{string*\& board} - A diagram of the board position. \\
+    fails &      never \\
+    comments &   The engine may draw the board as it likes. It is,
+                 however, required to place the coordinates as
+                 described in section \ref{sec:board-coordinates}.
+                 This command is only intended to help humans with
+                 debugging and the output should never need to be
+                 parsed by another program.
   \end{tabularx}
 \end{itemize}
 
 \newpage
 \section{Example}
+%FIXME: Missing, maybe remove.
 
 \newpage
 \section{Comments on  the Specification}
@@ -997,6 +1126,10 @@
 \subsection{Detail Comments}
 
 \begin{itemize}
+\item \textbf{\ref{sec:communication-model} Communication Model}\\
+  That the controller initiates all communication does not imply that
+  it has to set up the communication \emph{channel}.
+
 \item \textbf{\ref{sec:character-set} Character Set}\\
   ASCII specifies characters in the interval 0--127, some of which are
   control characters. ``Other characters'' refer to characters in the
@@ -1035,7 +1168,8 @@
   considered significant enough.
 
   This coordinate convention is identical to the one used on IGS and
-  many other go servers, as well as by the Go Modem Protocol.
+  many other go servers, and is also used in the specification of the
+  Go Modem Protocol.
   
 \item \textbf{\ref{sec:simple-entities} Simple Entities} \\
   The only purpose of the \texttt{float} entity is to specify komi
@@ -1059,10 +1193,57 @@
   that every \texttt{x*} has the same length. I.e., there may be
   varying number of elements on each line.
   
+\item \textbf{\ref{sec:standard-error-messages} Standard Error Messages} \\
+  Failures can be divided into two classes. In the first class we have
+  syntactically incorrect commands and other failures of the
+  controller to follow the specification. In the second class we have
+  technical limitations of the engine, which the controller cannot
+  easily foresee in advance.
+  
+  Only failures in the second class have standard error messages, on
+  the assumption that these are the only ones the controller need to
+  take action on. Failures in the first class indicate programming
+  errors and will require debugging. Thus those error messages may
+  freely be chosen to best help the debugging.
+
 \item \textbf{\ref{sec:fixed-handicap-placement} Fixed Handicap Placement} \\
   This fixed handicap placement is compatible with the Go Modem
   Protocol and many go servers.
 
+\item \textbf{\ref{sec:free-handicap-placement} Free Handicap Placement} \\
+  Filling all vertices but one with handicap stones leave them in
+  atari and is obviously not attractive for black. Moreover black has
+  the trivial placement of half the number of stones in a chessboard
+  pattern which leaves white without a single legal move. It is also
+  possible to place a smaller number of stones than that so that white
+  cannot possibly form a single living group. Thus there clearly
+  exists thresholds above which it is not meaningful to add more
+  stones.
+  
+  With this in mind it is recommended that every engine has a
+  threshold of at least 40 stones for 19x19 and a proportional number
+  for other board sizes. Extremely weak engines are recommended to
+  provide handicap placements all the way up to the full chessboard
+  pattern.
+  
+\item \textbf{\ref{sec:time-handling} Time Handling} \\
+  The controller is responsible for measuring time and deciding
+  whether an engine has run out of time. The information given by the
+  \texttt{time\_settings} and \texttt{time\_left} commands is only to
+  guide the engines about how fast they need to play.
+  
+\item \textbf{\ref{sec:scoring} Scoring} \\
+  With most rulesets scoring is difficult for computer programs. Only
+  sophisticated engines can be expected to have reliable scoring while
+  many engines probably will not implement the scoring commands at
+  all. A controller is recommended to have external methods available
+  to decide the winner (e.g.\ an independent trusted program or a
+  human reviewer) but there is no reason to invoke them if both
+  engines implement the scoring commands and agree about the result.
+
+  The format of the score string is identical to the RE property in
+  SGF FF[4].
+  
 \item \textbf{\ref{sec:state-variables} State Variables} \\
   An engine which never uses some state for anything does not have to
   keep track of it just because it should. The point of the rule is
@@ -1093,6 +1274,7 @@
 \end{itemize}
 
 \subsection{Missing Features}
+\label{sec:missing-features}
 
 \begin{enumerate}
 \item \textbf{Ruleset Commands and Scoring Options}\\
@@ -1116,7 +1298,7 @@
   it is desirable to have this functionality in the protocol, but it
   is worth waiting for a well thought through design of the commands.
 
-\item \textbf{Introspective Commands}
+\item \textbf{Introspective Commands} \\
   GNU Go includes a large number of commands to query the board, e.g.\ 
   list legal moves, find connected strings, count liberties, and so
   on. These can be useful when writing a ``stupid'' user interface
@@ -1151,6 +1333,8 @@
 
 \newpage
 \section{Credits}
+
+%FIXME: Missing
 
 \newpage
 \section{GNU Free Documentation License}