Presented at: TERENA-NORDUnet
Networking Conference 1999
Full name of authors: Jacob Palme,
Organizational affiliation: Stockholm University
SE-11530 Stockholm, Sweden
Phone: +46-8-664 77 48
URL in HTML format: http://cmc.dsv.su.se/talkback/talking-back.html
URL in PDF format:
Abstract: While e-mail and netnews support interaction between users,
typical WWW communication is uni-directional -- from the web page creator
to the reader, but with no facility for talkback from the reader to the creator
or between readers. This paper discusses how talkback can be added to the
WWW and presents how this is implemented in the KOM
Status of development.
Two or more people can exchange information in both directions. Note that
this is people-to-people interaction, not human-computer-interaction.
Web page readers can reply to web pages, and discuss the web pages with other
readers of the same web page. Note: The word "annotation" is often
used for what in this paper is named "talkback".
The three largest applications on the Internet are:
The main difference between WWW on one side, and e-mail/netnews, on the other
hand, is that WWW is mainly used for unidirectional publication of information,
while e-mail and netnews are mainly used for interactions between users. E-mail
and netnews has the following two primary functions which are not generally
available on the WWW:
Send a message which comments on a previous message, written by someone else,
often to all recipients of the previous message.
Many people can submit to the same group of recipients (mailing lists, newsgroups).
There have been many attempts at providing talkback in the WWW. Here are
Since the HTTP/HTML protocols, combined with forms, can be used as a fairly
general-purpose application interface, they can of course also be used to
provide interface to applications which provide interactivity between people.
Examples of this is forums (web-based,
non-same-time conferencing systems), chat
(same-time text interaction), web-based e-mail, like for example Hotmail
and MUD (multi-user adventure games).
The talkback facility in these systems is limited to users of these special
services. Usually, talkback is only possible between those users who connect
to one single server. Talkback is thus not very well integrated in the normal
WWW structure of a vast distributed data base of documents with hyperlinks
not only within servers, but also between servers.
A few experiments have been made in providing talkback directly in web pages.
The most common method is to append, at the end of an ordinary web page, a
talkback button, and lists or links to responses. A reader of such web pages
can thus send in their responses, and have these responses added to the web
For the following reasons, I think that the moon is made of green
cheese ... ...
Another variant only puts a single
button at the bottom of a web page, which links to a place where this web
page is discussed. This variant does not intrude on the primary contents of
the web page as much as where the discussion is put inside the web page itself.
Talkback facilities can be provided through two different methods:
As is shown by the table above, there are serious problems with both methods.
An ideal talkback facility should combine
the following services:
Web page owners can insert talkback into their pages, this talkback is then
available to everyone who reads this web page. This is similar to what is
named Local talkback service in the table above.
Users interested in talkback can subscribe to a talkback service, and they
will then be able to enter forums on any web page. This is similar to what
is named Universal talkback services in
the table above. But the talk back servers are interconnected, so that all
readers of each web page share one single forum area for that web page.
These two services are combined, so that the forum area provided with a Local
talkback service is the same as that provided by the Universal
Sometimes, it might be suitable to have a joint forum area for a set of related
web pages, instead of a separate forum area for each page.
Sometimes, an organization might want to have a Universal
talkback service, but only available for members or employees of
A universal service is not easy to implement. Since a fundamental principle
of the Internet is that nothing should rely on one single universal server,
a distributed, standardized protocol is needed. This protocol should provide
the following services:
Access for local talkback services, so that a web page owner can add talkback
to his/her web pages.
Global access which can locate the talkback areas for one particular web
page (or a set of related web pages). This requires some kind of directory
data base, which given a web page URI, can locate the talkback area for that
The talkback areas might be stored in conjunction with the web page(s) they
are connected with. But it is natural, in the WWW, to have the talkback areas
distributed, so that every author of a talkback message can provide his talkback
message as a web page on a local web server. A central area for each web page
might then only store links to all talkback for this particular page. It might
also store cached copies of the talkback pages.
In an earlier research project, Web4Groups,
we implemented a simple service of this kind, but this system was experimental
and never achieved production quality.
We are working on a new implementation in the KOM
2000 system. KOM 2000 is a distributed service of interconnected KOM 2000-servers.
Each KOM 2000 server stores the items submitted by its local users. Each server
can also hold multiple forums, both those connected to ordinary web pages
and those not connected to a particular web page. The forums can be of different
kinds, such as open to everyone, closed for members only, open to members
of another group; moderated or allowing every member to write in the area.
A beta version of KOM 2000 is
already available on the web.
Items in the data base are of primarily three kinds:
Documents (pages, messages).
Forums (discussion areas).
Each item (user, document, forum) has
A URL associated with a file, just as for ordinary web pages. This is, like
all URLs, a globally unique identification of this item.
A title, which is a user-friendly name, not limited by the limitations of
the URL syntax. This name is not guaranteed to be globally unique.
With each user is associated a private area, an inbox and an outbox, and
lists of forums to which this user is associated as member or as organizer.
With each forum is associated
a list of contributions in HTML format.
a list of members. Different members can have different roles, such as ordinary
member and organizer of this forum.
a list of subactivities.
Example of data base structure within one server:
The data base is distributed: Users submit their contributions to their localKOM
2000 server, but forums can be available to users at multiple servers. Each
forum is located in one server. Every user has a home server, and accesses
all information through his/her home server. This means that the actual URL
seen by the user when accessing an object at the server cmc.dsv.su.se from
a user at the home server foo.bar.net
can be http://foo.bar.net/cmc.dsv.su.se/flowers/tropical/1,
where http://foo.bar.net/ is the home
server of this user, and cmc.dsv.su.se/flowers/tropical/1
is the identification of the object. The local server of this user will retrieve
the object from its home server.
This, unfortunately, means that the URL to access the same forum differs
for different members. However, IETF has standardized a facility called Uniform
Resourch Names (URN). When web browser support URNs, look up of a web page
is a two step process. First the URN is used in a URN server. This server
will return a URL, where the actual document is placed. The intention with
this service is that the URN need not change when a document is moved, and
that the URN server can provide links to the nearest copy for each user, for
documents which are mirrored on different sites. But URNs can probably be
used to overcome the problem above. The URN server can be designed to give
each user access to an object through his preferred groupware, which is exactly
what we need. Another possible solution might be a plug-in to web browsers.
To reduce access times, a copy of every object is stored at every server,
where there is a recipient to this object. These copies can be removed to
save space. If a user needs a document which has been removed, it can be fetched
from the master server for this document. One can compare with Usenet News,
which also copies articles to all servers. But our design has two advantages,
compared to Usenet News:
Copies are not sent to servers where there is no reader of them. Replication
is set up automatically when a reader starts subscribing to a forum. Usenet
News cannot do this, because it has no list of the subscribers of the newsgroups.
If an object has been purged to save space, it can be fetched from a master
server. In Usenet News, there is no automatic way of getting a copy of a purged
A master copy is stored at the server of the creator of the object, a shadow
copy at the server of the forum and the server of every member of the forum.
Thus, for example, an object may have three locations:
The protocol between groupware servers contains operations like:
The protocol uses the ticket method for access control. This means that anyone
who has a certain access right is given a ticket, which is a randomly generated
key. For example, members of a forum have the ticket for that forum, and when
they retrieve a list of the contributions to the forum, they get the tickets
for each contribution, which they then can use to download the contribution.
The advantage with this method is that no central certificate server is needed.
And setting up certificate servers has been a major stumbling block in getting
security systems working. We may however add use of encryption methods for
authentication, signatures and seals to increase the security.
When this is written, we have not yet developed the directory system. We
have agreed with a major search engine provider, that they will set up the
directory. They will set up a directory, which given a web page, can find
a discussion forum for that web page. The directory will not be limited to
KOM 2000, it will be able to store discussions using other groupwares than
KOM 2000 too.
There will be a protocol for the groupware servers to communicate with the
directory system. Main operations in this protocol will be:
The format for these operations will be the same format which is used when
a user fills in and submits a form on a web page. This means that also other
groupware servers than KOM 2000 can report forums. Their owners can do this
manually, by filling in a form on a web page, even if they have not implemented
the protocol in their software.
The directory should of course also be distributed, based on an existing
directory structure like LDAP or DNS, but our first implementation will employ
a centralised directory only.
David R., 1995, 1998: