This page lists many of the factors we may care about, when we look at TheMedium for communication.
You could theoretically make IRC out of e-mail transport. Or you could pop e-mail messages up onto the screen, like instant messages tend to.
For the purpose of federating, I want to drop off some reference links:
What I propose is to split the characteristics into two parts - first is the technical characteristics of a communication tool (this is like a set of axioms), the second is the part about fitting of a tool for a particular purpose. For example 'interruptabillity' and 'sheduling' would go into the technical part and 'group size' and 'formality' into the other part of the list. Then the excersise would be to deduce the use characteristics from the technical axioms. --ZbigniewLukasiak
I'm not so sure- because the UserInterface, while constrained by the technology, can greatly warp it.
For example, the "interruptable" bit can be done with e-mail, or pretty much any of these technologies. Instantly interruptable- that's a little different. Then it depends on if it's a pull or push technology.
You could make IRC out of e-mail, if you wanted to, because they are both push technologies.
You could (ug!) make e-mail out of IRC.
But UserInterface is technical, and can be analyzed even if it is harder to do than the low level protocols. I try to do it on my page about synchronous and asynchronous communication http://zby.aster.net.pl/kwiki/kwiki.cgi?SynVersusAsyn. The difference there is nearly only the interface, on the low level email is indistinguishable from InstantMessaging.
Well, wait- The difference between "technical characteristics" and "fitting for a particular purpose" aren't so clear to me.
For instance, scheduling referred to- "Do you have to schedule to communicate?" So, like, in IRC, you sort of have to schedule. You sort of don't have to schedule.
E-mail, you never have to schedule.
Do we want to call this a "technical characteristic", or place it in the "fitting for particular purposes" bag?
I don't know; I'm trying to understand the distinction you are wanting to make.
Perhaps I should have started with stating the goal of this excercise. I see it in helping the IM programmers so that when they could concentrate on a lesser number of features because they would knew that the others can be deduced from those allready implemented. So when you don't know if some feature is reducible leave it as an axiom.
I've added "Presence," in response to reading some of DouglasGalbi's paper.
I'd also like to find a way to fit in some of the ideas that the CommBot suggests: Like, how in the future, we'll probably tell our programs, "I'm available for talking about X, or Y, but not Z, or anything else, unless it's an emergency."
Just a few links: JEP-01xx: Virtual Presence Protocol - a protocol for adding Jabber based IM to web (and in particular for wikis), LLuna an implementation, and Slasdot discussing LLuna. I think this can be a great project and my amateur analisis suggest that combination of IM and wiki can be the one of the most powerful communication tools.
See also ThoughtStorms:TomCoatesTwoDimensions