[Standards-JIG] New version of chess game protocol

Robert B Quattlebaum, Jr. darco at deepdarc.com
Wed Oct 18 18:52:49 UTC 2006

On Oct 9, 2006, at 11:27 PM, Michal vorner Vaner wrote:
>> Similar to how the workgroups protocol works if a chat room
>> is needed in a game the game server component will create the room  
>> and
>> give its address to all the participants (i.e.  
>> chess34 at muc.jabber.org)
> Well, if you have the game component, you can do the resending from
> there, since (as I said before), muc is not well suited for games, it
> can do only messages, it alters presence and is for text chats.

Why would using a MUC for communicating game moves (and possibly  
associated commentary) be a misuse of MUC? It seems like a perfectly  
appropriate use of such a facility. It is so compelling to me that I  
am having a really difficult time trying to imagine the benefits of  
rolling our own solution when it seems a solution to the "spectator"  
problem is all but solved.

You mention that MUC is not suitable because an implementation may  
not allow <iq> stanzas to be sent (although several do) and may  
mangle <presence> stanzas (although most don't), but I don't think  
either of those are show-stoppers. I don't see any reason why this  
protocol should require <iq>'s to be sent at all, except for service  

I think that using MUC is also more in line XEP-0134, Protocol Design  
Guidelines. I think sections 2.2 (Keep clients simple), 2.3 (Re-Use  
Existing Protocols), and 2.7 (Stay Flexible) are especially relevant  
in this case:
>> 2.2 Keep Clients Simple
>> Background
>> Almost all Jabber technologies are implemented in a client-server  
>> architecture. While that's not necessary (and there do exist some  
>> peer-to-peer applications of XMPP), it usually makes good sense.  
>> Among other things, a client-server architecture has enabled the  
>> Jabber community to force most of the complexity onto servers and  
>> components, thus keeping clients relatively simple. This principle  
>> has served the Jabber community well since the very beginning, and  
>> forms an important basis for further innovation.
>> Meaning
>> The principle of "keep clients simple" has many implications,  
>> among them:
>> Don't multiply protocols beyond necessity (the more protocols you  
>> define, the harder it is to write a client).
>> Degrade gracefully so that simpler or older clients can still  
>> participate in the network.
>> If intensive processing is required, make a server or component do  
>> it.
>> Don't force additional requirements (such as XSLT processors) onto  
>> clients unless absolutely necessary.
>> Examples
>> One good example of keeping clients simple is the presence stanza:  
>> the client has only to send <presence/> and the server takes care  
>> of presence probes, broadcasts, and appropriate routing decisions.  
>> Another example is Multi-User Chat [14]: although the protocol  
>> involves some complexity, it was written so that older clients can  
>> join and participate in MUC rooms even if they don't understand  
>> the more advanced MUC extensions.
>> 2.3 Re-Use Existing Protocols
>> Background
>> The Jabber community has been developing wire protocols for XML  
>> streaming, presence, and instant messaging since 1999. In that  
>> time, members of the community have defined a number of building  
>> blocks that can be used as the basis for further development.  
>> Furthermore, many smart people have created open protocols within  
>> other standards development organizations, including the IETF, the  
>> World Wide Web Consortium (W3C) [15], OASIS [16], the  
>> International Telecommunication Union (ITU) [17], and the Dublin  
>> Core Metadata Initiative (DCMI) [18].
>> Meaning
>> Good protocol designers "stand on the shoulders of giants" by re- 
>> using protocols that have been defined within the JSF and within  
>> other standards development organizations. That does not mean we  
>> don't define new protocols, because sometimes that is necessary.  
>> However, we are aware of work completed by others and we make use  
>> of it, especially when that work is outside the Jabber community's  
>> core competence areas (e.g., security or multimedia data formats  
>> rather than XML streaming, presence, and real-time messaging).  
>> Furthermore, the JSF prefers to re-use open protocols wherever  
>> possible. Finally, just as with XMPP, so also with XMPP extensions  
>> defined through the JSF: do not modify existing schemas (e.g.,  
>> adding new elements and attributes) except through the XMPP  
>> extension process; instead, define extensions in a separate  
>> namespace).
>> Examples
>> Examples of re-using existing Jabber protocols include Stream  
>> Initiation [19] (which re-uses Feature Negotiation [20]) and  
>> XEP-0126: Invisibility (which re-uses the privacy lists protocol  
>> defined in XMPP IM). Examples of re-using non-Jabber protocols  
>> include SOCKS5 Bytestreams [21] (which makes use of RFC 1928 [22])  
>> and Common Alerting Protocol (CAP) over XMPP [23] (which defines a  
>> way to send Common Alerting Protocol [24] data via Jabber). Here  
>> again XEP-0071 provides an example: it re-uses XHTML 1.0 (an open  
>> protocol developed by a recognized standards development  
>> organization) rather than RTF (a closed protocol under the control  
>> of the Microsoft Corporation).
>> 2.7 Stay Flexible
>> Background
>> The need for explicit definition must be balanced against the need  
>> for flexibility. A completely rigid protocol may break under  
>> stress or when conditions change, whereas a more flexible protocol  
>> may bend and adapt. Knowing when to be explicit and when to be  
>> flexible is a key to good protocol design.
>> Meaning
>> In general, a protocol needs to define the skeleton of  
>> functionality, but not necessarily specific parameters or values  
>> to be used within a certain domain. In order to allow for growth  
>> and change, it often makes sense to specify that the XMPP  
>> Registrar [34] shall keep track of certain parameters and values,  
>> rather than to explicitly limit them in the protocol itself.
>> Examples
>> Whereas the old Agent Information [35] and Jabber Browsing [36]  
>> protocols defined certain hardcoded values for entity types and  
>> categories, Service Discovery has left that function up to the  
>> XMPP Registrar. Similarly, Stream Initiation [37] defines a  
>> registry for its profiles, Advanced Message Processing [38]  
>> defines registries for processing conditions and actions, and a  
>> number of XMPP Extension Protocols register FORM_TYPE values as  
>> specified in Field Standardization for Data Forms [39].

There may be benefits to creating a game-specific version of MUC for  
things like this that would not crop the history of a game for  
spectators who arrive mid-game, but I urge you to allow this protocol  
to take place in a normal MUC as a baseline because MUC servers are  
widely deployed and game servers are not.

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

More information about the Standards mailing list