The Improving Go Servers Consortium Protocol
                - draft eigth -

        The goal of the IGSCP is to add functionalities that lack on the actual IGS protocol.
        These new features will be added without disturbing the other clients.
        We will try to keep a maximum of compatibility with the standard IGS protocol.
        This can be done with two standard IGS commands: 'tell' and 'chatter'.



        Future versions of the protocol should guarantee to keep compatibility
        with previous versions, so that clients that are not updated still work.
        A client can implement only a part of the IGSCP functionalities. Actual families
        are: INFO, MARK, XMARK, SETUP, MOVE, CONTROL.
        It's up to the programmer to implement the behaviour of the client (for
        example a teacher can approve each move of the pupil manually, or
        automatically then use 'undo' if the move is bad).

        General syntax:

        It will be easy to parse for the client. It is "line oriented" : A
        command start with a '#' and finish with a 'eol' (platform dependent).
        A command must be contained in one line. The maximum length of a line on
        IGS is actually 256, but the client should not send so much.
        (To not disturb non-compatible clients, lines should not be more
        than 80 chars in my opinion.)
        The protocol is case-sensitive (since IGS is)

        The command is fully qualified path of names separated by a semi-colon.
        After that there can be 0 or more parameters separated by spaces.
        #A(:B...)<space>param(<space>param...)

        Names of command must contain only alpha-numeric characters:
        [a-z][A-Z][0-9][_] (or [\w\d]+ in regexp)

        Names of parameters can contain any printable non-space character(\S in regexp).
        If a parameter contains spaces, it must be double-quoted (" ")


  I.  IGSCP service commands

  1) INFO (tell)

  #INFO:REQUEST:VERSION request the IGSCP version used by another client.
  #INFO:VERSION <param> give the version of the protocol used:
                        IGSCP-X.Y where X is major number and Y minor number
  #INFO:REQUEST:CLIENT  request a client identification.
  #INFO:CLIENT  <param> give the client identification
                        (can be the same as the 'id' command of IGS)
  #INFO:REQUEST:PHOTO   request a picture of the player
  #INFO:PHOTO   <url>   give the URL where to find the photography.
                        (use 'none' if no URL is available)
  #INFO:REQUEST:FEATURES ask what families the client supports
  #INFO:FEATURES <fam> <fam> ....
                        family can be one of : CONTROL MOVE MARK XMARK
                        (support INFO is mandatory)
  #INFO:NOT_IMPLEMENTED The reply to a INFO:REQUEST: that is not implemented


  II. Improving the "teach" mode of IGS

  We can improve the teach mode in 2 ways:

  1) CONTROL (tell)
  Add the notion of 'pupil' in addition of the 'teacher' and the 'observers'.
  An observer can ask the teacher for the control to put moves on the board.
  When he has it, he becomes a 'pupil' and can put moves on the board.
  These moves are sent to the teacher who can approve the move before sent
  to the server.(client dependent)
  The teacher can take the control at any time, and gives it to any pupil he wants.
  All these commands will be implemented using 'tell' between the teacher and the pupil.


 commands:                      parameters:

#CONTROL:COLOR                  WHITE
#CONTROL:REQUEST                BLACK
                                BOTH
                                OFF

#MOVE                   standard sgf move W[xx]


ex:

#CONTROL:REQUEST BLACK (pupil or observer requests control for playing as black from the teacher)
#CONTROL:REQUEST OFF (pupil control has been revoked)


  2) Markups (chatter)
  Allows the teacher to put/remove/move marks on the board.
  We will use the standard SGF[4] properties.
  These commands will be implemented using the 'chatter' command when available, otherwise 'kibitz'.
  When a move is made, all marks are removed. Marks does not appear again when a 'undo' is made.

Three families:
MARK:  CR, LB, MA, SQ, TR
XMARK: AR, DD, LN, SL
SETUP: AE, AW, AB



#MARK:ADD XX[aa](XX[aa]...)
 a series of markup is only one parameter (no space needed)

#MARK:REMOVE  aa (aa...)
 Note: The properties CR, MA, SL, SQ and TR must be unique, it is illegal to have two or more
 of these markups on the same point. The sender omits the markup specification "XX" for
 these properties and simply give the coordinates "aa" only. The receiver should be able to
 remove the mark from the given spot for both syntax variants.For XMARK, the first point determines
 which is to be removed.

#MARK.REMOVE all
 Remove all marks at a time.

#MARK:MOVE aa(:xx) bb(:yy)
 Here there can be only one mark at a time, an there are 2 parameters: source and destination.

 ex: move an arrow
   #MARK:MOVE dd:jd jd:jj