[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
>> 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
>> 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.
>> 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
>> Don't force additional requirements (such as XSLT processors) onto
>> clients unless absolutely necessary.
>> 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 : 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
>> 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) , OASIS , the
>> International Telecommunication Union (ITU) , and the Dublin
>> Core Metadata Initiative (DCMI) .
>> 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
>> Examples of re-using existing Jabber protocols include Stream
>> Initiation  (which re-uses Feature Negotiation ) 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  (which makes use of RFC 1928 )
>> and Common Alerting Protocol (CAP) over XMPP  (which defines a
>> way to send Common Alerting Protocol  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
>> 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.
>> 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  shall keep track of certain parameters and values,
>> rather than to explicitly limit them in the protocol itself.
>> Whereas the old Agent Information  and Jabber Browsing 
>> protocols defined certain hardcoded values for entity types and
>> categories, Service Discovery has left that function up to the
>> XMPP Registrar. Similarly, Stream Initiation  defines a
>> registry for its profiles, Advanced Message Processing 
>> 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 .
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.
Jabber: darco at deepdarc.com
eMail: darco at deepdarc.com
More information about the Standards