Would it be useful to know whether the engine thinks the game is over and perhaps thinks itself the winner?  IE handing the scoring phase, perhaps including declarations of the life/death status of groups?
The commands you've listed allow a game to be played through a smart referee, presumably a human, who could handle cases where one engine thinks it has killed a group but another has not (ie an engine bug) and who could really determine such things as the game has endend.  Without these smarts, full automation of a set of games (for learning or competition) may not be possible.  For instance I've seen instances where an engine is trying to make a move the other thinks isn't possible.  This happens in programs using machine learning techniques, depending on how much expertise is coded into the engine.  Handling automated game playing required us in OpenGo to put intelligence into the 'referee' to cope with this -- thus the protocol required some way to tell an engine that it's move is rejected and the game is over (it can cleanup or do what it has to do then)...

Taking a step away from gnugo itself, are these issues you want to concern yourself with?

Also a question: does the protocol include the negotiation of these terms with the engine (ie a request for it's capabilities in the first place, and an ack or something implying it can play to the terms requested) (sorry if this should be obvious in the documentation, but i've not really gone through it...)
jeff

Phil wrote:

So far the minimal GTP command set includes: Boardsize
Komi
Fixed_Handicap
White
Black
Genmove_Black
Genmove_White
Undo (* provisional for now)
Quit What else?