As per Relevance of the word computer, we have this rfc below:
Network Working Group D.
Request for Comments: 1324 May 1992
A Discussion on Computer Network
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This memo is intended to make more people aware of the
developments in the Computer Conferencing field as well as
forward ideas on what should be done to formalize this work so
there is a common standard for programmers and others who
involved in this field to work with. It is also the intention
this memo to stimulate the computer community and generate
useful discussion about the merits of this field
Computer network conferencing is just now starting to grow and
advantage of the modern technology that is available. Although
are some systems which have been around for some time (BRC -
Relay Chat and IRC - Internet Relay Chat), there has not been
real move to bring them together under a single protocol. This
led to various protocols and different systems coming to life.
these different systems continue to pop up, it is becoming
obvious that there is need of a standard in this area for
to follow without the need of worrying about protocol clashes
In any implementation of a conferencing program, there are likely
be two main components: (1) a client program or interface which
enter commands into (hereafter referred to as a "client") and 2)
server program which acts as a multiplexor for various clients
connect to it. There are other expectations and requirements for
servers and clients which are mentioned in more detail later
Table of
1.0 Network Conferencing Today........................... 2
1.1 Conferencing in general today........................ 2
1.2 Talk/phone vs. conferencing.......................... 3
1.3 Advantages of realtime network conferencing.......... 3
2.0 Goals for what a protocol should provide............. 4
Reed [Page 1]
RFC 1324 Computer Network Conferencing May 1992
2.1 State Information problems........................... 4
2.2 Network barriers..................................... 4
2.3 User needs........................................... 4
2.3.1 User privacy......................................... 4
2.3.2 Realtime Expectations................................ 5
2.4 Message Delivery..................................... 5
2.4.1 Deficiencies in using IP only........................ 5
2.4.2 Flexibility.......................................... 5
2.4.3 Building a flexible transport protocol............... 5
2.5 Network Structure.................................... 5
2.5.1 Size................................................. 5
3.0 Usage................................................ 6
4.0 Setting it up........................................ 6
4.1 Installation......................................... 6
4.2 Controlling growth................................... 7
5.0 Finding the *right* protocol......................... 7
5.1 Name for protocol.................................... 7
5.2 Responsibilities of conference servers............... 7
5.2.1 Message passing...................................... 7
5.2.2 Who is on?........................................... 7
5.2.3 Who is who?.......................................... 8
5.2.4 Conference security.................................. 8
5.2.5 Error reporting...................................... 8
5.2.6 Network Friendliness................................. 8
5.2.7 To ASCII or not to ASCII............................. 8
5.2.8 Queries or messages to a server and replies.......... 9
5.3 Responsibilities of clients.......................... 9
5.3.1 Providing accurate information....................... 9
5.3.2 Client as servers.................................... 9
5.4 How complex should the protocol be?................. 10
5.4.1 User identification................................. 10
5.4.2 Trees and cycles.................................... 10
5.5 Protocol summary.................................... 10
6.0 Security Considerations............................. 10
7.0 Author's Address.................................... 11
1.0 NETWORK CONFERENCING
1.1 Conferencing in general
Conferences today are an integral part of the business world in
ways. A conference may be held to reassure staff about
problems (boost moral) or may be held by a few directors in
emergency situation where a carefully considered solution is needed
Conferences also form the cornerstone of workshops held where
groups of people, who attend, are to be briefed on new developments
In nearly all of these situations, there will be a group of 2
more, where each speaks and listens to others. There exist PABXs
Reed [Page 2]
RFC 1324 Computer Network Conferencing May 1992
other features of the telephone system which provide for
between people around the globe at a cost effective rate. The
place which really lacks any formal form of conferencing is
internet, although many unofficial conferencing systems
exist, spanning the globe or providing local forums
1.2 Talk/phone vs.
To provide instantaneous communication between two users on unix
other multiuser systems, interprocess communication is commonly
either over a network or other local methods. The diversity of
platforms has introduced as many problems as the presence of
operating systems on the net. Commonly, those on Unix based
are unable to talk to those on VMS or VM machines. The occasion
arises where two Unix hosts are unable to talk to each other due
different talk protocols
1.3 Advantages of realtime computer
By providing a standard for computer conferencing, it
eliminate the problem of who is using what computer. This will
that someone from a VMS or VM machine can talk with one or
people without having to worry whether their counterpart has
account on a compatible machine for their choice of communication
Electronic mail (email) has already reached this position with
modern mailers on the internet being compliant with RFC822. It
therefore not unreasonable to expect this of realtime
which is to talk as USENet is to email; although of those four (4),
only email and news have been covered by RFCs
USENet is a vast resource and immensely useful for many people
the globe. It does, however suffer from a high noise to signal ratio
It would be unwise to expect much difference in performance
conferencing
By providing the means for realtime computer conferencing, it
up a whole new area of usefulness to computers. For both students
staff alike, it opens up new possibilities. In
institutions where there is a high level of project work with
of more than 2, it means that students can work from home or
remote places and discuss their project with their fellow students
a manner which would be similar to all students having a
meeting or conference. This same situation also applies to
members. For those who have previously relied on email
fellow researchers in many remote institutions, computer
brings the world together, onto the researchers screen where they
trade ideas and code in real time. Traditionally to achieve
goals, the phone would have been used and a teleconference setup
Reed [Page 3]
RFC 1324 Computer Network Conferencing May 1992
it will probably remain so for many years to come with video
too. However, with phone conferencing, when people talk over
other, the quality of the discussion is degraded
2.0 Goals for what a protocol should
In producing a protocol for conferencing over computer networks,
following problems must be considered
2.1 State Information
The number of users who are a part of the conference may
continuously by a large amount over any given period of time.
protocol should endevour to make disruptions such as these as
as possible but at the same time, keep the realtime feel in
conference. It is not acceptable to buffer a user who quits for
given time but at the same time, if a server has network
with connecting to another one, it may be wise to find some
around the continual stream of state messages that are passed - or -
at least a way to reduce the number
2.2 Network
Members of a conference may be on physical networks which
directly communicate with each other, such as those used from a
on a commercial network talking via a bridge to someone from
network directly connected to a network directly accessible
theirs. So in this case, the users involved have no need to
use the bridge (as required by unix talk) since the server on
gateway host provides a way for messages to be passed in and out
the unreachable sections. In this case also, there is a
security risk to the network which is otherwise unreachable
2.3 User
2.3.1 User
Members of a conference may wish to exchange ideas privately
fear of others eavesdropping or interrupting the current conference
To facilitate this, there should be some support by the protocol
pass messages from one user/client directly to another
It is also reasonable for a user to want to be able to hide in
way or another from other users, effectively making
invisible to other users
Reed [Page 4]
RFC 1324 Computer Network Conferencing May 1992
2.3.2 Realtime
Users will expect conferencing to be real time, giving the
demanding that the protocol supply a quick, efficient, reliable
accurate delivery of a message. Only when these requirements are
can a conference system hope to be of any use to its users
2.4 Message
2.4.1 Deficiencies in using IP
In routing between conference servers, the problem of
messages is an important issue. If there was a server for
conference at each domain, this wouldn't be an issue, one
simply do some sort of lookup and find the server for it. This is
the case and unless such a server becomes a standard item for
machines, it is not reasonable to expect it to ever be so. Thus
need for a layer on top of TCP/IP is needed to deliver
between the servers for the conference
2.4.2
The routing protocol used should not be inflexible and should
for routes to change over time in much the same way as RIP does now
However, there is no need for a special routing protocol such as
since this is already part of IP's functionality. Routing
should be updated automatically when the server receives
via that route whether it creates or destroys a route
2.4.3 Building a flexible transport protocol on top of existing
If such a conferencing service is built upon TCP/IP, it is
possible to build an abstract routing model which has no relation
the TCP/IP model. However, it is not wise to ignore the presence
either TCP or IP since by integrating them into the protocol, it
easier to use their strengths. If the protocol relies too heavily
TCP/IP features, it will also inherit some of its weaknesses.
maybe taken for granted, but it is worth keeping them in mind
designing a protocol to be both reliable, efficient and useful
2.5 Network
2.5.1
The potential userbase of a conferencing system using the
should not be underestimated. It is therefore desirable that
conferencing system should be as distributed as possible, and
little state information kept as possible. If the IRC network
Reed [Page 5]
RFC 1324 Computer Network Conferencing May 1992
taken as a guide, with 800 users on 140 servers in some 200 channels
the server was using over 1MB of memory. Due to the nature
conferencing and the server being run as a daemon, this memory
hardly ever swapped out. For this reason, servers should aim to
be authoritive about required users, channels and servers and keep
to date information on these
There is also no requirement that a global conferencing system
built, although it is an ideal arena to show the strengths of
network. It also goes without saying that it shows up a lot of
weaknesses too
Any protocol which is developed should operate equally well
efficiently on both a large scale network and on a small
network
3.0
If past usage is any guide, then a network based conferencing
will be largely used by mostly students. This is not as
as it may sound since students and student accounts easily form
largest body on the internet. To encourage staff or other adults
this field, it might be prudent to reduce the amount of noise
interfearance a bored student (or staff member!) can generate
Realtime conferencing via computer networks is, however, a
attractive toy to many students. It puts them in touch with the
at no extra charge to them. They are able to construct their
character and mask or hide their real self. This is a field which
already been researched and is an interesting topic to pursue
4.0 Setting it
4.1
The installation and setup of most network utilities/servers is
something that is commonly discussed. It is, however, a point
considering here after observations made on the setup
installation of systems such as IRC. If the setup is too easy
requires little work, it is not unreasonable to expect students
"install" it in their own accounts to provide themselves and
with this service. There is little that can really be done about
except to force servers to listen and connect only to a
priveledged port(s). This need, however, requires root
or aid and it is doubtful whether a service such as this
require such steps
Reed [Page 6]
RFC 1324 Computer Network Conferencing May 1992
This problem is not often encountered with other network
since they either require large amounts of disk space to be
properly (news) or require the co-operation of other servers
they work in a full serving role (DNS and use of name servers is
good example of this). Of the two, the latter is a good solution
it can be implemented fairly and well
4.2 Controlling
Is it possible to reasonably control the growth and connectivity of
large realtime conferencing network? Should it be compared to
facilities such as USENet which is commonly available and
widespread with no real central control over who gets news
5.0 Finding the *right*
This section deals with points which are central issues when
upon a protocol. There are many points to consider when developing
realtime protocol which is going to provide a service to many
simultaneously
5.1 Name for
Although names such as IRC and ICB have been used in the past
describe the implementation provided, this document is aimed
stimulating a protocol which is much more general and useful
these. A better name would reflect this. Depending on what network
is implemented on, the Network Conferencing Protocol (NCP) or
Internet Conferencing Protocol (ICP) are two suitable names
5.2 Responsibilities of conference
5.2.1 Message
A conferencing server should pass on all messages not destined
itself or its users to the destination as quickly and efficiently
possible. To this end, the server should not be required to
extensive parsing of the incoming message, but rather, look at
header and decide from there whether to send it on in the
gateway/relay fashion or parse it and pass it to one or more of
users
5.2.2 Who is on
Any conference server should be able to supply (on request) a list
attached user(s). The attached user(s) should have the option
being able to say whether they wish to show up in such lists
Reed [Page 7]
RFC 1324 Computer Network Conferencing May 1992
5.2.3 Who is who
All servers should provide *some* method to identify any known
and supply details to the person making the query based on the
key given
5.2.4 Conference
Conference servers should not run in such a manner that
deliberately record the private conversation(s) of users which
relying on the server in some way. It might seem that encrypting
message before transmission to other servers in some way would
this, but this is better left as an option which is implemented
clients and thus leaves it to the users to decide how secure
want their conference to be
5.2.5 Error
All errors that the server encounters in its running life should
way or another be reported to the operator(s) which are
for this. This may include sending messages if an operator is
or logging it to an error file
5.2.6 Network
It is quite easy for any network based application to "abuse"
network it is running on. Also in a relay situation, it is
possible that a server will become bogged down trying to keep up
just one connection and reduces the performance on an overall
to all users relying on it. It is therefore recommended that
connections be subject to some sort of monitoring and flood
to stop them dumping large amounts of spurious data and causing
server to slow down
The server should also aim to maximise the packet size of all
written out to the network. Not only does this make the packet/
statistics look nice, but also increases the efficiency of the
by reducing the time it spends in the system state waiting/doing
operations such as read/write. The cost here is a fractional
in the real-time efficiency of the server
5.2.7 To ASCII or not to
Given that most of the widely used Internet protocols such as SMTP
NNTP and FTP are all based on commands which are given via
strings, there seems no reason why a conferencing protocol should
any different. The gains from going to binary are marginal
debugging/testing is not as easy as with ASCII. However, it is
Reed [Page 8]
RFC 1324 Computer Network Conferencing May 1992
unreasonable for some part of the protocol to be done in binary
5.2.8 Queries or messages to a server and
For implementation of server queries, it is quite acceptable to
ASCII messages which are made up of words. (Any string of
which doesn't start with a number). Replies should be some sort
numeric. This is a follow on from from 5.2.7 where all of FTP,
and SMTP work in this manner. By reserving numerics *just* for
replies, there can be no confusion about whether the message is
to or from a server
5.3 Responsibilities of
This section discusses the obligations of clients which are
to a conference server
5.3.1 Providing accurate
Expecting accurate information is foolish, it matters not for most
the internet, but those that we do wish to trace wont give
information. A client is expected to provide accurate and
information to the server it connects to so that confusion about
is who is not a problem. Optionally, the server may decide to
trust the information from the client and use some
scheme that is open to it for such
5.3.2 Client as
If a client is acting as a server and accepting direct
from other clients, the client should provide information about
as discussed in 5.2.3. It is not necessary that a client be able
handle complex methods of communication such as channels and
advanced forms, but they should at least provide users with
able to send messages to other users
An example of this type of program might be Xtv where one or
users can connect to another Xtv client program using Xtv clients
In the case of X windows and perhaps in other areas, one it to
the destination user to run a program in a similar manner to
talk
Reed [Page 9]
RFC 1324 Computer Network Conferencing May 1992
5.4 How complex should the protocol be
5.4.1 User
When a user signs onto a system that has an implementation of
conferencing protocol, they are usually asked or given some sort
unique key by which they are later able to be referenced by. In
large system, it may be such that any key which has meaning to
user(s) will not be sufficient and that collisions will occur
such. It is therefore suggested that a server generate an
for each new user it has. This identifier must not only be unique
space, but also time. It is not reasonable for the user to ever
to be aware of what this identifier is, it should only be known
servers which *need* to know. A similar system to that used
NNTP/SMTP is a fair implementation of such a scheme
5.4.2 Trees and
Due to the structure of the network being cyclic or forming loops,
is quite natural to want to emulate this within the protocol that
available for users. This has several advantages over trees,
the average path between any 2 nodes being shorter. A
structure also poses many problems in getting messages delivered
keeping the connected users and servers up to date. The main
with using the tree model is that a break in one part of the
needs to be communicated to all other parts of the tree to keep
sort of realism about it. The problem here is that
communications happen quite often and a lot of bandwidth
needlessly generated. By implementing a protocol which supports
cyclic graph of its connectivity, breakages are less damaging
when it is a leaf or branch that breaks off
5.5 Protocol
It is not expected that any protocol that meets the above
will be either easy to arrive at or easy to implement. Some of
above requirements may seem to be exotic, unnecessary or not
the effort. After viewing previous conferencing programs and how
work, many short comings can be seen in taking shortcuts
6.0 Security
Security issues are not discussed in this memo
Reed [Page 10]
RFC 1324 Computer Network Conferencing May 1992
7.0 Author's
Darren
4 Pateman
Watsonia, Victoria 3087
Email: avalon@coombs.anu.edu.
Reed [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
