Below is a draft of our proposed whiteboarding JEP. We are
still working on
a number of additional use cases. We recently switched from
a PubSub
implementation to XMPP component model this one is not as
developed as the
original pubsub design. Synchronization is handled by the
server component.
Signaling of the whiteboarding startup, would likely be via
modification to
the user's presence.
when creating a whiteboard, you can specify a JID to obtain
the permissions..
Our intent is to automatically use the perms from the MUC
room since that is
the most like use case for group whiteboarding.
boyd
JEP-0XXX: SVG Whiteboarding over XMPP
This JEP defines a protocol for providing Scalable Vector
Graphics based
whiteboarding over XMPP. It supports both peer and server
based
whiteboarding.
JEP Information
Status: Experimental
Type: Standards Track
Number: 00
Version: 0.1
Last Updated: 2006-03-19
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, JEP-0060, Scalable Vector Graphics
Superseded By: None
Short Name: whiteboard
Schema for whiteboard: <http://
jabber.org/protocol/whiteboard.xsd>
Registry: <http://www.jabber.org/registrar/whiteboard-pubsub.html
>
Author Information
Brian Raymond
brian.raymond je.jfcom.mil
Boyd Fletcher
boyd.fletcherje.jfcom.mil
Michael Bishop
michael.bishopje.jfcom.mil
Legal Notice
This Jabber Enhancement Proposal is copyright 1999 - 2006 by
the Jabber
Software Foundation (JSF) and is in full conformance with
the JSF's
Intellectual Property Rights Policy
<http:
//www.jabber.org/jsf/ipr-policy.shtml>. This material
may be
distributed only subject to the terms and conditions set
forth in the
Creative Commons Attribution License
(<http:
//creativecommons.org/licenses/by/2.5/>).
Discussion Venue
The preferred venue for discussion of this document is the
Standards-JIG
discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig&
gt;.
Relation to XMPP
The Extensible Messaging and Presence Protocol (XMPP) is
defined in the XMPP
Core (RFC 3920) and XMPP IM (RFC 3921) specifications
contributed by the
Jabber Software Foundation to the Internet Standards
Process, which is
managed by the Internet Engineering Task Force in accordance
with RFC 2026.
Any protocol defined in this JEP has been developed outside
the Internet
Standards Process and is to be understood as an extension to
XMPP rather
than as an evolution, development, or modification of XMPP
itself.
Conformance Terms
The keywords "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL
NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", and
"OPTIONAL" in
this document are to be interpreted as described in RFC
2119.
1. Introduction
Whiteboarding has traditionally been handled by the T.120
family of
standards however they do not provide the flexibility or
light weight
operations that can be accomplished using new protocols for
both rendering
of content and transport. This Jabber Enhancement Proposal
describes two
methods of whiteboarding using XMPP with a common whiteboard
protocol.
1)One-to-One & Multi-User whiteboarding using XMPP text
chat and MUC
2)Multi-User whiteboarding with a remote XMPP entity.
T World Wide Web Consortium's (W3C) Scalable Vector
Graphics (SVG) standard
is used as the data exchange standard for whiteboard
elements.
2. Glossary
Term
Definition
SVG
Scalable Vector Graphics is an XML based language from the
World Wide Web
Consortium (W3C) for describing two dimensional graphics.
SVG Tiny
SVG profile suitable for Cell Phones
SVG Basic
SVG Profile suitable for PDAs
CRUD
Create, Read, Update, Delete.
MUC
Multi-User Chat (JEP-045)
3. Requirements
The protocol defined herein addresses the following
requirements
1.Enable an XMPP entity to establish a whiteboard session.
2.Enable an XMPP entity to share that whiteboard session
with other XMPP
entities.
3.Enable an XMPP entity to join a whiteboard session and
retrieve the
current whiteboard.
4.Enable an XMPP entity to create, delete, and updated SVG
items on the
whiteboard.
5.Enable an XMPP entity to create, delete, and update pages
and layers in
the whiteboard
6.Enable an XMPP entity to set non-graphical properties on
the whiteboard.
4. Concepts and Approach
4.1 Data Management
There are a multiple methods that can be used to manage
the
whiteboarding data for a session. This JEP focuses on the
following:
1.Direct connections between XMPP entities (Peer
connections)
Whiteboarding directly between some number of clients may be
supported by
simply sending an action and the whiteboard payload to all
clients. This
allows for whiteboarding between clients without any
whiteboard specific
server side support with direct connections or through MUC.
The whiteboard
data in this model will be transferred in it's own
namespaced element
qualified by the 'http://jabber.o
rg/protocol/whiteboard' namespace.
2.Server Component A whiteboard component may be used as a
broker in a
client-server model and provide persistence for the
whiteboard and
supporting data.
4.2 Whiteboard Structure
The whiteboard is structured using the following
hierarchical model, it
is defined bottom up for context:
1.SVG Element An actual snippet of SVG data.
2.Layer A layer is a grouping of SVG elements.
3.Group of Layers Groups some number of layers together to
form a page.
4.Group of Pages A group of pages is the root of the
whiteboard.
Of the preceding constructs, all clients MUST support SVG
Elements, multiple
layers, and multiple pages. SVG elements MUST be contained
within layers,
and layers MUST be contained within pages.
The events for a whiteboard session are <action/>
elements that specify a
³type² attribute:
Action type
Dsecription
create_whiteboard
Creates a whiteboard session
refresh_whiteboard
Request all of the current whiteboard elements.
create_page
Creates a new page within an existing whiteboard session
delete_page
Deletes a page
create_layer
Creates a new layer within an existing page
delete_layer
Deletes a layer
create_element
Creates a new SVG element in an existing layer
delete_element
Deletes an SVG element
update_element
Updates some number of attributes in existing elements
4.3 Process Flow
The process for establishing and using a whiteboard
session with peers
is as follows:
1.XMPP entity advertises whiteboard to clients. Most often
this is a chat or
a MUC room.
2.Users perform actions in the whiteboarding session by
communicating with
peers.
5. Protocol
5.1 Whiteboard Data Representation
The whiteboard data requires a minimum compliance with
the Scalable
Vector Graphics 1.1 Tiny Profile elements (SVGT)
specification from the W3C..
The format of the SVG elements is not covered in this
document. Implementors
should refer to the appropriate W3C document on the SVG
element
descriotions. The whiteboard does not use SVG documents as a
whole but
rather the elements themselves wrapped in a namespaced
element qualified by
the http://www.w3.org/2000/svg
namespace. The actual whiteboard data and the
means by which actions are expressed are separated to
provide the
flexibility to add transports with within or outside of XMPP
without
impacting the whiteboard data itself.
Example 2: Standard SVG element representing a rectangle
<svg xmlns='http://www.w3.org/2000
/svg>
<rect fill-opacity=²1² stroke=²black² id=²3² x=²152²
y=²97² width=²172²
height=²108² transform=²translate(0.0, 0.0) scale(1.0, 1.0)
rotate(0.0,
238.0, 151.0)² fill=²gray² svgx:cx=²238.0² svgx:cy=²151.0²
svgx:mx=²0.0²
svgx:my=²0.0² svgx:sx=²1.0² svgx:sy=²1.0² svgx:t=²0.0²
pointer-events=²visible² />
</svg>
5.3 Pages and Layers
Pages and Layers are higher level whiteboard constructs
that allow SVG
elements to be grouped into layers and then into groups on
pages. This
allows for the whiteboard to be organized to some degree, a
good example
being a layer containing a picture that is then marked up
using another
layer to capture all annotations.
Pages and layers are expressed as actions within peer
connections and
they MUST follow the whiteboard strucutre[reference]
outlined within this
JEP.
5.4 Ordering of elements
Ordering of all of the whiteboard elements (e.g nodes,
items) is
important so the whiteboard client can draw the elements in
the correct
order thus producing the same representation of the
whiteboard for all
clients. The ³afterId² attribute uses the ID of the element
that it comes
after in the whiteboard and this attribute MUST be present
on all whiteboard
data elements. The ³afterId² attribute MUST also be present
in the PubSub
(collection) node configuration for all pages and layers.
The PubSub service
MUST guarantee that the afterIds are unique within a given
PubSub
collection.
NOTE: Currently PubSub does not natively support the
ordering of elements of
the tree however this is currently being drafted and
submitted for inclusion
in the specification so that the logic of maintaining the
order can be moved
to the server where it is more efficient and robust.
6. Use Cases
The following use cases demonstrate a whiteboard session
between two
XMPP entities.
Example 3: XMPP Entity creates whiteboard
<message xmlns="jabber:client"
id="msg1"
to="gertrudeshakespeare.org/shallow"
xml:lang="en" type="chat">
<action type="create_whiteboard"
id="SVG01"
xmlns="http://jabber.o
rg/protocol/whiteboard"/>
</message>
Example 4: XMPP Entity creates first page of whiteboard
<message xmlns="jabber:client"
id="msg2"
to="gertrudeshakespeare.org/shallow"
xml:lang="en" type="chat">
<action type="create_page"
xmlns="http://jabber.o
rg/protocol/whiteboard"
id=²page1²>
</action>
</message>
Example 5: XMPP Entity specifies background
<message xmlns="jabber:client"
id="1lN0F-27"
to="gertrudeshakespeare.org/shallow"
xml:lang="en" type="chat">
<action type="create_element"
xmlns="http://jabber.o
rg/protocol/whiteboard">
<element tagName="rect"
namespace="http://www.w3.org/2000/svg
"
parentId="SVGWB-02F3A290-3AFC-B6E4-F584-E96401C79D82&
quot; pageId="page1"
id="SVGWB-5D4C0F98-3590-D781-2850-EBE6F7424B5A"
x="-1000%" y="-1000%"
fill="white" width="3000%"
height="3000%"/>
<type>background</type>
</action>
</message>
The background for the page is specified as an SVG element
with a special
type. This allows backgrounds to be simply colors as this
one, images, or
other content that can be inline or linked in using SVG.
Example 6: XMPP Entity creates first layer of whiteboard
(Update)
<message xmlns="jabber:client"
id="1lN0F-28"
to="gertrudeshakespeare.org/shallow"
xml:lang="en"
type="chat"><action
type="create_element" xmlns="http://je.jfcom.mil/action
">
<element tagName="g" namespace="http://www.w3.org/2000/svg
"
afterId="SVGWB-5D4C0F98-3590-D781-2850-EBE6F7424B5A&q
uot;
parentId="SVGWB-02F3A290-3AFC-B6E4-F584-E96401C79D82&
quot;
pageId="SVGWB-02F3A290-3AFC-B6E4-F584-E96401C79D82&qu
ot;
id="SVGWB-F15E6B4C-CE8B-D108-2F30-EEEB9EC9954E"&
gt;
<attribute name="svgx:name"
namespace="http://je.jfcom.mil/svgx
"
value="default_layer"/>
<attribute name="svgx:type"
namespace="http://je.jfcom.mil/svgx
"
value="layer"/>
<attribute name="id"
value="SVGWB-F15E6B4C-CE8B-D108-2F30-EEEB9EC9954E&quo
t;/>
<attribute name="pointer-events"
value="none"/>
</element>
</action></message>
7. Error Conditions
The table below details the error conditions and meanings in
the context of
Whiteboarding
(At the moment there aren't any whiteboard specifics
errors, leaving this
here as a place holder)
Table 1: Error Conditions
Condition
Cause
The other error conditions specified in XMPP Core MAY be
returned as well.
8. Implementation Notes
9. Recommendations
10. Security Considerations
Secuirty of the whiteboarding sessions is managed within the
capabilties of
PubSub. Implementations MAY enforce additional privacy or
security policies
for authorization purposes however those are outside of the
scope of this
document.
11. IANA Considerations
This JEP requires no interaction with the Internet Assigned
Numbers
Authority (IANA)
12. Jabber Registrar Considerations
12.1 Protocol Namespaces
(Maybe)
The Jabber Registrar [11] shall include
'http://j
abber.org/protocol/pubsub#whiteboard' in its registry
of protocol
namespaces.
13.XML Schema
<?xml version="1.0"
encoding="UTF-8"?>
<xs:schema elementFormDefault="qualified"
targetNamespace="http://je.jfcom.mil/action
"
xmlns:ac="http://je.jfcom.mil/action
"
xmlns s=&q
uot;http://www.w3.org/20
01/XMLSchema">
<!-- Describes the "type" attribute of
the "action" element. The "type"
element should only be one of the described values.
Example: <action
type="create_element"></action>
-->
<xs:simpleType name="actionType">
<xs:restriction base="xs:string">
<xs:enumeration
value="create_element"/>
<xs:enumeration
value="create_page"/>
<xs:enumeration
value="create_whiteboard"/>
<xs:enumeration
value="delete_element"/>
<xs:enumeration
value="delete_page"/>
<xs:enumeration
value="load_whiteboard"/>
<xs:enumeration
value="move_element"/>
<xs:enumeration
value="switch_page"/>
<xs:enumeration
value="update_element"/>
<xs:enumeration
value="update_element_text"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType
name="elementTextType">
<xs:sequence>
<xs:element name="text"
type="xs:string" minOccurs="0"
maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="afterId"
type="xs:string"/>
<xs:attribute name="file"
type="xs:string"/>
<xs:attribute name="id"
type="xs:string"/>
<xs:attribute name="pageId"
type="xs:string"/>
<xs:attribute name="parentId"
type="xs:string"/>
<xs:attribute name="type"
type="xs:string"/>
</xs:complexType>
<!-- Similar to the "elementType" except
it describes the ID of an
entire
document. (ID of the root "SVG"
element).
-->
<xs:complexType name="pageType">
<xs:attribute name="id"
type="xs:string"/>
<xs:attribute name="afterId"
type="xs:string"/>
</xs:complexType>
<!-- Describes the main "action" element
which has the "type" attribute,
any
number of sub-elements "element" of
"elementType" or any number of
sub-
elements "page" of
"pageType". There must be at least one of
either
"element" or "page".
Example:
<action
type="create_element">
<element tagName="rect">
<attribute name="id"
value="0"/>
<attribute name="x"
value="0"/>
<attribute name="y"
value="0"/>
<attribute name="width"
value="10"/>
<attribute name="height"
value="10"/>
</element>
</action>
-->
<xs:element name="action">
<xs:complexType>
<xs:sequence>
<xs:element name="page"
type="ac:pageType"
minOccurs="0"
maxOccurs="unbounded"/>
<xs:element
name="elementText"
type="ac:elementTextType"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="reorder"
type="xs:boolean"/>
<xs:attribute name="type"
type="ac:actionType"
use="required"/>
<xs:attribute name="id"
type="xs:string"/>
<xs:attribute name="jid"
type="xs:string"/>
</xs:complexType>
</xs:element>
</xs:schema>
14. Notes
1.
2.Scalable Vector Graphics (SVG) Standard, World Wide Web
Consortium (W3C),
http://www.w3.org/Grap
hics/SVG
15. Revision History
|