[Standards-JIG] New version of chess game protocol

Thu Oct 5 13:44:49 CDT 2006

Hello Mridul!

On Oct 2, 2006, at 4:06 PM, Mridul wrote:

> 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 these.

Simple: XEP-0091, jabber:x:delay

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

I personally know of a four player version of chess which is  
absolutely fascinating to play. However, I believe that it is patented.

> 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.

I thought about doing this when I came up with my "back of the  
napkin" chess protocol a while back. However, after looking into it a  
bit more closely, these notations would require a somewhat more  
complicated parser to interpret. The protocol should be as simple as  
possible to encourage implementation, and I think that using Forsyth- 
Edwards notation would add an unnecessary level of implementation  
complexity to the bare minimum chess client. Perhaps we could  
recommend for the client to include the Forsyth-Edwards notion in the  
<body> element?

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

Move numbers I think is a good idea. This would allow clients to  
perform some basic sanity checking.

> 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).

I agree. I think that MUC rooms should be used for this purpose. This  
would allow side chatting, logging, moderation, etc. It also follows  
the spirit of XEP-0143.

__________________
Robert Quattlebaum
Jabber: darco at deepdarc.com
eMail:  darco at deepdarc.com
www:    http://www.deepdarc.com/