RFC 1324

RFC 1324 ✨ A Discussion on Computer Network Conferencing

Okay bestie, let's start with the header 🎀. This is RFC 1324, titled A Discussion on Computer Network Conferencing, written by D. Reed and dated May 1992 🗓️. It's from the Network Working Group, and its status is basically "here's some information" 💖. It doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🙈.

Status of this Memo 📜

Okay, the official-ish part 📜. This memo provides information for the Internet community 💁. It does not specify an Internet standard. Distribution of this memo is unlimited 🌈.

Abstract 💬

This memo is all about getting more people hyped on what's happening in the computer conferencing field ✨. It also throws out ideas about what we should do to formalize this work, so there's a common standard that programmers and everyone else involved can actually build on 🛠️. The goal is to get the computer community talking and spark some good discussion about why this field is worth caring about 🔥.

Introduction 🌱

Network conferencing is just starting to blow up and take advantage of all the modern tech we have now 🚀. Some systems have been around for a hot minute already (BRC - Bitnet Relay Chat and IRC - Internet Relay Chat), but nobody has really tried to bring them together under one protocol 🙃. So now there are different protocols and different systems popping up everywhere, and it's getting super obvious that developers need a standard to follow so they don't have to stress about protocol clashes 😭.

Any conferencing program is probably going to have two main pieces 🧩: (1) a client, which is the program or interface where users type in their commands (I'll be calling it a "client" from here on), and 2) a server, which acts as a multiplexor for all the clients that connect to it. Servers and clients both have other expectations and requirements too, and we'll get into those in more detail later 💅.

Table of Contents 📑

   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
   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 Today 🌍

1.1 Conferencing in general today 💼

Conferences are an integral part of the business world in lots of ways 💼. A conference might be held to reassure staff about company problems (to boost morale 🫶), or a few directors might hold one in an emergency where they need a really carefully considered solution 🚨. Conferences are also the cornerstone of workshops, where groups of people attend to get briefed on new developments 📊. In nearly all of these situations there's a group of 2 or more people, and each one speaks and listens to the others 🗣️. PABXs and other phone system features already let people around the globe conference together at a cost-effective rate 📞. The only place that really lacks any formal conferencing is the internet 😤, even though plenty of unofficial conferencing systems already exist, spanning the globe or running local forums 🌐.

1.2 Talk/phone vs. conferencing 📱

For instant communication between two users on unix and other multiuser systems, interprocess communication is commonly used, either over a network or with other local methods 🖥️. Unix platforms are super diverse, and that has caused just as many problems as all the different operating systems on the net 🙃. Usually folks on Unix machines can't talk to people on VMS or VM machines 💀. It even happens that two Unix hosts can't talk to each other because they're using different talk protocols 😭.

1.3 Advantages of realtime computer conferencing 🚀

A standard for computer conferencing would fix the whole "who is using what computer" problem 🙌. Someone on a VMS or VM machine could talk with one or more people without worrying about whether their counterpart has an account on a compatible machine for whatever communication method they picked 🤝. Email already got there, since most modern mailers on the internet are compliant with RFC822 📬. So it's not unreasonable to expect the same from realtime conferencing, which is supposed to talk as USENet is to email 💬. Although out of those four (4), only email and news have been covered by RFCs 📚.

USENet is a vast resource and super useful for tons of people around the globe 🌍. It does, however, have a really high noise to signal ratio 📢. So it would be unwise to expect much difference in performance from conferencing 🙈.

Realtime computer conferencing opens up a whole new area of usefulness for computers ✨. For students and staff alike, it opens up new possibilities 🎓. In educational institutions with lots of project work in groups of more than 2, students can work from home or other remote places and discuss their project with fellow students, kind of like everyone having a conventional meeting or conference 🏠. The same goes for staff members 🧑‍🏫. For researchers who've relied on email with fellow researchers at many remote institutions, computer conferencing brings the world together right onto their screen, where they can trade ideas and code in real time 🌏💻. Traditionally, a phone teleconference setup was used to reach these goals, and it'll probably stick around for many years to come, video phones included 📞. But with phone conferencing, when people talk over each other, the quality of the discussion gets degraded 😩.

2.0 Goals for what a protocol should provide 🎯

Okay, so when you're designing a protocol for conferencing over computer networks, these are the problems you have to think about 🧠:

2.1 State Information problems 🌀

The number of users in a conference can fluctuate continuously by a big amount over any period of time 🎢. The protocol should endeavour to make these disruptions as smooth as possible, while still keeping that realtime feel ⚡. It's not acceptable to buffer a user who quits for any amount of time 🙅. But at the same time, if a server has network problems connecting to another one, it might be wise to find some way around the continual stream of state messages being passed around, or at least a way to reduce the number 📉.

2.2 Network barriers 🧱

Conference members might be on physical networks that can't directly communicate with each other, like a host on a commercial network talking via a bridge to someone on a network that's directly connected to a network that's directly accessible from theirs 🌉. In this case, the users don't need to use the bridge directly (which is what unix talk requires), because the server on the gateway host gives messages a way to get in and out of the unreachable sections 🚪. There's also a minimal security risk to the network that's otherwise unreachable 🔒.

2.3 User needs 🙋

Users want a few things, and privacy is a big one 👀.

2.3.1 User privacy 🤫

Members of a conference may want to exchange ideas privately, without anyone eavesdropping on them or interrupting the main conference 🙊. To make that work, the protocol should have some support for passing messages directly from one user/client to another 💌.

It's also totally reasonable for a user to want to hide from other users in one way or another, effectively making themself invisible to everyone else 👻.

2.3.2 Realtime Expectations ⏱️

Users are going to expect conferencing to be real time, which demands that the protocol supply quick, efficient, reliable and accurate delivery of a message 🏃‍♀️. Only when all of those requirements are met can a conference system hope to be any use to its users 💯.

2.4 Message Delivery 📮

2.4.1 Deficiencies in using IP only 🙃

When conference servers route messages between each other, figuring out how to route them is a big issue 🗺️. If there was a server for the conference at each domain, it wouldn't be an issue, since you could just do some sort of lookup and find the server for it 🔍. But that's not the case, and unless such a server becomes a standard item on unix machines, it's not reasonable to expect it ever will 🤷‍♀️. So a layer on top of TCP/IP is needed to deliver messages between the conference servers 🧁.

2.4.2 Flexibility 🌊

The routing protocol used should not be inflexible, and it should allow routes to change over time, kind of like RIP does now 🔄. There's no need for a special routing protocol like RIP, though, since that's already part of IP's functionality 🧠. Routing information should be updated automatically when the server receives information via that route, whether it creates or destroys a route ✨.

---

Part 1 of 2 💖 Part 2 is coming up next, so stay tuned, bestie! 🦋

2.4.3 Building a flexible transport protocol on top of existing ones ✨

okay so if this conferencing service gets built on TCP/IP, it's totally possible to make an abstract routing model with zero relation to the TCP/IP model 🦋 but ngl, it's not wise to ignore TCP or IP completely. by building them into the protocol, it's way easier to use their strengths 💪. if the protocol leans too hard on TCP/IP features, it'll also inherit some of their weaknesses 💀. these might feel like background noise, but keep them in mind when you're designing a protocol that's reliable, efficient and useful ✨.

2.5 Network Structure 🌐

2.5.1 Size 📏

the potential userbase of a conferencing system on the internet should not be underestimated 👀. it's therefore desirable for the conferencing system to be as distributed as possible, with as little state information kept as possible 🫶. if we take the IRC network as a guide, with 800 users on 140 servers across some 200 channels, the server was using over 1MB of memory 😭. because conferencing is the kind of thing that runs as a daemon, that memory was hardly ever swapped out. so for this reason, servers should aim to only be authoritative about the required users, channels and servers, and keep up to date information on those 💅.

there's also no requirement that a global conferencing system be built 🌍. still, it's an ideal arena to show off the strengths of the network. it also goes without saying that it shows up a lot of its weaknesses too 🙈.

any protocol that gets developed should operate equally well and efficiently on both a large scale network and a small scale network 👑.

3.0 Usage 🎀

if past usage is any guide, a network-based conferencing system will be mostly used by students 🎓. this isn't as unreasonable as it sounds, since students and student accounts easily form the largest group on the internet 😌. to encourage staff or other adults into this field, it might be prudent to cut down the noise and interference that a bored student (or staff member!) can generate 🙃.

realtime conferencing over computer networks is, however, a super attractive toy for lots of students 🧚. it puts them in touch with the whole world at no extra charge 🌸. they get to build their own character and mask or hide their real self, which is giving main character energy 💜. this is a field that's already been researched, and it's a seriously interesting topic to pursue ✨.

4.0 Setting it up 🛠️

4.1 Installation 📦

the installation and setup of most network utilities and servers isn't something people talk about much. but it's a point worth considering here, after watching how systems like IRC got set up and installed 👀. if the setup is too easy and needs little work, it's not unreasonable to expect students to "install" it in their own accounts, so they can give themselves and their friends this service 💀. there's not a lot that can really be done about this, except to force servers to listen and connect only on certain privileged port(s). that approach needs root intervention or help, though, and it's doubtful whether a service like this should need those steps 🥺.

this problem doesn't come up as often with other network services. they either need huge amounts of disk space to run properly (news), or they need other servers to cooperate before they can work in a full serving role (DNS and its use of name servers is a great example of that) 🧠. of the two, the latter is a good solution, as long as it can be implemented fairly and well 🫶.

4.2 Controlling growth 🌱

is it possible to reasonably control the growth and connectivity of a large realtime conferencing network? 🤔 should it be compared to other facilities like USENet, which is commonly available, very widespread, and has no real central control over who gets news? 📰

5.0 Finding the right protocol 💅

this section covers the points that are central when you're deciding on a protocol. there are a lot of things to think about when you're developing a realtime protocol that's going to serve many users at the same time 🔥.

5.1 Name for protocol 🏷️

names like IRC and ICB have been used in the past to describe the implementations, but this document is aimed at inspiring a protocol that's much more general and useful than those. a better name would reflect that 💖. depending on which network it runs on, the Network Conferencing Protocol (NCP) or the Internet Conferencing Protocol (ICP) would both be suitable names 🦋.

5.2 Responsibilities of conference servers 👑

5.2.1 Message passing 💌

a conferencing server should pass on all messages that aren't destined for itself or its users, getting them to the destination as quickly and efficiently as possible ⚡. to make that happen, the server should not be required to do extensive parsing of the incoming message. instead, it looks at the header and decides from there whether to send it on in the typical gateway/relay fashion, or to parse it and pass it to one or more of its users 🧚.

5.2.2 Who is on? 👀

any conference server should be able to supply (on request) a list of attached user(s). the attached user(s) should have the option of saying whether they want to show up in those lists 🙈.

5.2.3 Who is who? 🕵️‍♀️

all servers should provide some method to identify any known user and to supply details to whoever's making the query, based on the search key they gave 🔍.

5.2.4 Conference security 🔐

conference servers should not run in a way that deliberately records the private conversations of users who rely on the server in some way 🙅‍♀️. it might seem like encrypting the message before sending it to other servers would fix that. but this is better left as an option that's implemented in clients, which lets the users decide how secure they want their conference to be 💜.

5.2.5 Error reporting 🚨

all errors the server runs into during its running life should, one way or another, be reported to the operator(s) responsible for it 😤. this may include sending messages if an operator is online, or logging the error to an error file 📝.

5.2.6 Network Friendliness 🌈

it's really easy for any network-based application to "abuse" the network it's running on 💀. also, in a relay situation, a server can easily get bogged down trying to keep up with just one connection, which drags down performance for everyone relying on it 😩. so it's recommended that user connections be subject to some kind of monitoring and flood control, to stop them dumping huge amounts of spam data and slowing the server down 🛑.

the server should also aim to maximise the packet size of every packet written out to the network 📦. not only does that make the packet/bytes statistics look nice, it also makes the server more efficient, because it spends less time in the system state waiting and doing IO operations like read/write ⏱️. the cost is a fractional decrease in the server's real-time efficiency, and honestly that's a trade-off worth knowing about 🫧.

5.2.7 To ASCII or not to ASCII 🔤

most of the widely used Internet protocols, like SMTP, NNTP and FTP, are built on commands given as ASCII strings. so there's no real reason a conferencing protocol should be any different 🙌. going binary only gives marginal gains, and debugging and testing aren't as easy as they are with ASCII 🥲. still, it's not unreasonable for some part of the protocol to be done in binary 💫.

5.2.8 Queries or messages to a server and replies 💬

for server queries, it's totally acceptable to use ASCII messages made up of words. (any string of characters that doesn't start with a number). replies should be some sort of numeric 🔢. this follows on from 5.2.7, where FTP, NNTP and SMTP all work this way. by reserving numerics just for server replies, there's no confusion about whether a message is going to or coming from a server 💖.

5.3 Responsibilities of clients 🧁

this section talks about the obligations of clients that are connected to a conference server 🫶.

5.3.1 Providing accurate information 🪪

expecting accurate information is kind of foolish 🙃. it doesn't matter for most of the internet, but the people we do want to trace won't give accurate information anyway. a client is expected to provide accurate and valid information to the server it connects to, so that nobody gets confused about who is who 👀. optionally, the server may decide not to trust the information from the client, and use whatever authentication scheme is open to it for that 🔒.

5.3.2 Client as servers 🖥️

if a client is acting as a server and accepting direct connections from other clients, the client should provide information about users, as discussed in 5.2.3 ✨. it's not necessary for a client to handle complex methods of communication like channels and their advanced forms. but they should at least let users send messages to other users 💌.

an example of this kind of program is Xtv, where one or more users can connect to another Xtv client program using Xtv clients 🦋.

in the case of X windows, and maybe in other areas too, one way is to ask the destination user to run a program in a similar manner to unix talk 📞.

5.4 How complex should the protocol be? 🤔

5.4.1 User identification 🆔

when a user signs onto a system that has an implementation of a conferencing protocol, they're usually asked for, or given, some sort of unique key that they can later be referenced by 🔑. in a large system, any key that means something to the users probably won't be enough, and collisions will happen with those keys 😬. so it's therefore suggested that a server generate an identifier for each new user it has 🧚. this identifier must be unique not only in space, but also in time ⏳. it's not reasonable for the user to ever have to be aware of what this identifier is. it should only be known by the servers that need to know 🫶. a system similar to the one used by NNTP/SMTP is a fair implementation of this scheme 💅.

5.4.2 Trees and cycles 🔁

the network's structure is cyclic, forming loops, so it's pretty natural to want the protocol available to users to copy that shape too 🌀. this has several advantages over trees, mainly that the average path between any 2 nodes is shorter 🛣️. a cyclic structure does bring its own problems, though, like getting messages delivered and keeping the connected users and servers up to date 😵‍💫. the main problem with a tree model is that a break in one part of the tree has to be communicated to all the other parts, so the tree still feels realistic 🌳. the catch is that these communications happen pretty often, and a lot of bandwidth gets needlessly generated 💸. a protocol that supports a cyclic graph of its connectivity means breakages do less damage, except when it's a leaf or branch that breaks off 🍃.

5.5 Protocol summary 📋

it's not expected that a protocol meeting all of the demands above will be easy to arrive at or easy to implement 😤. some of those requirements might seem exotic, unnecessary or not worth the effort. but after looking at previous conferencing programs and how they work, you can see plenty of shortcomings that come from taking shortcuts 🙈.

6.0 Security Considerations 🔐

Security issues are not discussed in this memo. 😭 That's a dramatic blank in the spec, so treat it as a serious gap, not a footnote.

7.0 Author's Address 🖋️

   Darren Reed
   4 Pateman Street
   Watsonia, Victoria 3087
   Australia

   Email: avalon@coombs.anu.edu.au