You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

60 lines
4.2 KiB

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<title>Whiteboarding SIG</title>
<abstract>A proposal to form a SIG to develop a protocol for whiteboarding over Jabber.</abstract>
<type>SIG Formation</type>
<remark>Changed Status to Obsolete per approval of XEP-0019.</remark>
<remark>Initial release</remark>
<section1 topic='Introduction'>
<p>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.</p>
<p>There exists today a protocol draft for sending streaming XPM over Jabber. 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.</p>
<p>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.</p>
<section1 topic='Deliverables'>
<p>The Whiteboarding SIG should produce the following deliverables (these deliverables will be presented to the Jabber Council):</p>
<section2 topic='Requirements'>
<p>A set of requirements that the proposed protocol should fulfill.</p>
<section2 topic='Analysis of existing work'>
<p>There are today at least four different attempts <note>"Distributed SVG documents" (formerly at</note> <note>SVG over Jabber (<link url=""></link>)</note> <note>Jabberzilla Whiteboard (<link url=""></link>)</note> to create a whiteboarding protocol in Jabber. The Whiteboarding SIG should evaluate them all and see which features of each are worth keeping.</p>
<section2 topic='Graphics data format'>
<p>One or more data formats for the graphics data, presented both as a description and as a DTD or XML schema.</p>
<section2 topic='Jabber protocol'>
<p>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.</p>