[Standards-JIG] New version of chess game protocol

Mridul mridul at sun.com
Mon Oct 2 23:06:44 UTC 2006

Michal vorner Vaner wrote:
> Hello,
> there is a new version of the chess game protocol in the inbox.
> http://www.jabber.org/jeps/inbox/chess.html
> If you want to have a look, I would be delighted to hear opinions.
> Thank you


  Some thoughts on this proto-jep , and also on gamesessions (in the 
context of this proposal).

gamesessions :

1) Who creates the gid ?
If it is the responsibility of the client , then how can it be expected 
to be unique ?
 From my understanding , gid will identify a game to which others could 
potentially connect - so shouldn't this not be assigned by the server ?

2) "One to one game, with spectators" - In the context of chess games , 
which is essentially falling under this category :

Are the client's supposed to take care of it ? Or do the spectators 
connect to the component/server and view a game ?
It would be heavy if the client has to manage spectating - imagine 
kasparov vs anand game :-)
Also , how about acl's for this ? (tutor session/class similar to muc , etc)
Actually , I did not see anything about how a client would initiate a 
spectating session for a game in the proposal.
Typically , spectating involves side chatter : some of which is also 
visible to the players , and some of which are not : makes all the more 
sense to move it out of the control of the client.

chess :

1) Time related attributes.
There are a whole series of timing considerations in chess games : sec 
per move , fischer time control , primary/secondary/etc time controls of 
time per x moves , etc : and different UI's support different subsets of 

2) There are variations of chess where more than 2 players play - this 
is not handled by the spec I believe (refer to 3).

3) There are a large number of variants of chess - refer here for a 
small list : http://www.chessclub.com/helpcenter/tips/wild.html
There should be some way to negotiate this.

4) Considering that you already have (3) above , I think the ruleset 
attribute could be modified for this - the current rules mentioned are 
not really very useful imo ...

5) There is a standard way to represent chess positions : FEN 
(http://en.wikipedia.org/wiki/Forsyth-Edwards_Notation) for normal chess 
, X-FEN(http://en.wikipedia.org/wiki/X-FEN) and shredder FEN for fischer 
random chess - not sure about other variants.
Similarly , for communicating games , there is a PGN standard format.
It would make sense not to invent another format - all UI's I know 
support FEN already.
Btw , the 'piece' attribute could be considered broken from a chess 
point of view actually.

6) Maybe I did not get this point ... but who manages a game ?
The gamesessions seems to indicate that 1 to 1 games would be managed by 
the players themselves ... in which case , time synchronization , 
checking of rules , etc have to be managed by the client ?
If not , then how are the errors , timeouts , etc to be sent ?

7) Might be useful to add a move number to gameflow. Also , it does not 
consider extra semantics necessary for (3) above ...

8) I am not very sure of the client's managing spectating ... might make 
more sense for the server or external component to manage this (I 
mention this under gamesessions actually).

9) Other ideas which are currently available in most online chess server :
a) Adjournment of game ?
b) Retrieving a move list to continue a previously adjourned game
c) Browsing game history.
d) Examine a game (could have multiple users modifying the board).

If I am not wrong , the protocol's of most of the online chess servers 
are public (a search showed me icc format : 
ftp://ftp.chessclub.com/pub/icc/formats/formats.txt , I am sure fics , 
others will also have their formats out there somewhere)... so it would 
help us to take a look at what they support and what they allow.
We may not want to model all of it , but should be reasonably flexible 
to allow the jep to be used for supporting these as required.

Wanted to comment only about the time thingy ... but became a much 
bigger mail than I expected :-)


More information about the Standards mailing list