A proposal to form a SIG to develop a protocol for whiteboarding over Jabber.
WARNING: This document has been obsoleted by the XMPP Standards Foundation. Implementation of the protocol described herein is not recommended. Developers desiring similar functionality should implement the protocol that supersedes this one (if any).
Series: XEP
Number: 0010
Publisher: XMPP Standards Foundation
Status:
Obsolete
Type:
SIG Formation
Version: 1.1
Last Updated: 2002-05-08
Approving Body: XMPP Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name:
Wiki Page: <http://wiki.jabber.org/index.php/Whiteboarding SIG (XEP-0010)>
Email:
niklas@protocol7.com
JabberID:
nikgus@jabber.org
The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.
Errata may be sent to <editor@xmpp.org>.
1. Introduction
2. Deliverables
2.1. Requirements
2.2. Analysis of existing work
2.3. Graphics data format
2.4. Jabber protocol
Notes
Revision History
Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value.
There exists today a protocol draft for sending streaming XPM over Jabber [1]. XPM is a bitmap format, which makes it well-suited for certain applications (e.g., smaller drawings and sketches). However, significant changes in an XPM image will require sending large amounts of XML data (even with the compression described in the protocol draft). Also, for example, XPM does not scale without loss of resolution, nor does it support metadata. In addition, the current draft specifies the data format only, not the way the data will be sent or handled by Jabber servers and clients.
Therefore, the Whiteboard SIG should develop a standard way of handling whiteboards in Jabber and a format for data transfer. This might be based on vector graphics, bitmap data, or a combination of these two. In addition, the protocol should work in the context of both regular messaging and conferencing. The protocol for whiteboarding during conferencing might depend on the new protocol proposal to come from the Conferencing SIG [2].
The Whiteboarding SIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):
A set of requirements that the proposed protocol should fulfill.
There are today at least four different attempts [3] [4] [5] to create a whiteboarding protocol in Jabber. The Whiteboarding SIG should evaluate them all and see which features of each are worth keeping.
One or more data formats for the graphics data, presented both as a description and as a DTD or XML schema.
The actual protocol for how the graphics data is sent over Jabber. This will also include an analysis of any associated functionality that must be performed by Jabber servers and clients.
1. XPM over Jabber (http://docs.jabber.org/draft-proto/html/sxpm.html)
2. Conferencing protocol draft (http://jabber.org/?oid=1538)
3. Distributed SVG documents (http://www.jabber.org/?oid=1025)
4. SVG over Jabber (http://www.protocol7.com/jabber/whiteboard_proposal.txt)
5. Jabberzilla Whiteboard (http://jabberzilla.mozdev.org/)
END