14.3 Presence and Instant Messaging

Now let's look at an application that doesn't benefit as clearly or directly from WebDAV. Instant messaging, together with presence information, is a relatively new Internet application. Instant messaging is the ability to send a short message to another person while he or she is online and have that person respond immediately, forming a conversation more than a correspondence. An instant message doesn't get stored for delivery later. Presence information is deeply embedded in instant-messaging applications because the instant message isn't composed, sent, or delivered unless the recipient is online. "Buddy lists" has become a common phrase to describe the lists where people can quickly see which of their contacts are online and decide whether to send an instant message to any of them.

The difference between instant messaging and email isn't very clear and may blur more because email has become nearly instant, and instant messages may be stored like email. Part of the difference seems to be the user interface, which in instant messaging is lightweight and sometimes playful.

Instant messaging has quickly grown to include participation from a large proportion of the Internet population. The application appeared and grew suddenly, and the slow protocol standardization process is only catching up now. Part of the problem in developing standard protocols for this application is that it is complicated. The application involves many different facets, complicated security models, and high-performance requirements.

I'll outline the different pieces of the puzzle first, paying particular attention to how the application is used, because in this case the details of how it is used are especially important in choosing a model for a solution. I'll compare and contrast to existing protocols because in five years of designing instant-messaging protocols, I've heard dozens of people with prior protocol experience say, "Why not just use X?" where X is the existing protocol with which they have experience (including WebDAV but also SMTP, IRC, and others). It's not that simple.

14.3.1 Instant-Messaging Requirements

These are some of the problems and requirements for sending instant messages.

Sending Instant Messages

Users send instant messages to only a small group of "buddies." Contrast this to email, where my contacts list contains 104 entries, and there are easily 100 more people I might send email to in a given month. My buddy list contains only 25 buddies and I only send messages frequently to about 10 of them. To have a satisfactory experience sending an instant message, it must be trivial for me to choose a user and send a quick, informal, and small message. It shouldn't be necessary to go to another application and find an address. Thus, all the instant-messaging clients I've used allow me to choose a user and send an instant message with two mouse clicks (no scrolling if the target is in the top of my buddy list).

Instant messages must be received pretty much instantly. Because it's text (not speech), a delay of a couple of seconds (a fairly large Internet latency for a short message) is acceptable. However, a delay of five seconds or more is unacceptable because it noticeably impedes a back-and-forth conversation. Compare this to SMTP store-and-forward design, where a one- or two-minute email delivery time (over the Internet) is considered fast.

File Sharing

When users discuss and share files, the easiest way to transfer the file (or a link to a file) is with the same application used to discuss the file. That's why email attachments are ubiquitous. However, sending files directly over an instant-messaging protocol can be problematic. The most worrying concern is viruses, but there are also problems with denial-of-service (DoS) attacks, against the server or directly against instant-messaging clients. The current AOL Instant Messaging (IM) client allows users to transfer files directly to one another, but it warns users that before allowing a buddy to send a file even before deciding whether to open the file they should have trust in that buddy. That's because the file transfer reveals the recipient's IP address and opens that system up for an attack. However, the AOL system surely doesn't want the file transfers to pass through the servers, because that would put a large load on servers that have plenty of fast traffic to handle. MSN Messenger also handles direct file transfer to buddies. File sharing is difficult yet necessary. At home, IM users want to share images, sounds, and movies. At work, IM users want to collaborate on and discuss documents.

Multiple Clients

Users want to have IM functionality available at home, at work, at school, and sometimes even on the road. Some cell phones and PDAs interact with instant-messaging systems. Laptops with wireless connectivity frequently have IM clients installed. This leads to a couple of requirements:

• The user needs a server to help synchronize or manage IM addresses, rather than re-enter addresses on many client devices. Many email servers do this today for email clients.

• In addition, the server must help synchronize or enforce permissions. Email doesn't typically involve "white lists" and "black lists" where certain users are forbidden from sending mail but modern IM applications always have this feature.

14.3.2 Presence

Sending an instant message is only worthwhile if the recipient is there to see it. Otherwise, people choose email, which gets stored until the user sees it. Thus, successful instant-messaging applications have been coupled with a way to find out who is online. It's most convenient to see at a glance who is online, rather than query one by one for different buddies. It's also most convenient if I can see immediately when somebody comes online (many client applications notify you with a sound like a chime ringing or a door opening) in case I've been waiting to send somebody a message. The entity getting presence information updates is called a watcher.

Sensitivity of Presence Information

The information about whether I'm online is sensitive information, not for everybody to know (think Internet stalkers). Presence functionality requires a way for the user to decide which watchers can receive their presence information. When a watcher wants to see my presence information for the first time, the system withholds that information until I approve that watcher. If I don't approve of a watcher, the system pretends that I'm always offline (to that watcher). This decision is typically made for the long term: Once I approve a watcher, the system continues to feed that watcher my presence information until I change my mind.

Notice that the ability to hide my presence information from some watchers implies the need for a server. Peer-to-peer instant-messaging applications have been designed and deployed but haven't met with the same success. One reason is that when my client machine is responsible for being a peer in the communication net, publishing my online status directly, forbidden watchers can find out some information based on the reachability of my client machine. If the client machine responds "she's offline" and doesn't respond at all other times, that's too much information. A presence server can do a much better job of pretending, to a watcher I don't like, that I'm completely unreachable all the time. This also implies the need for a server location to help synchronize or manage presence access control information for multiple clients.

Buddy Lists

Now that we've looked at the need to send messages quickly to a small group of people and the need to find out conveniently if those friends are online, the "buddy list" concept seems obvious. My buddy list always shows up in my instant-messaging application, with only a glance required to see who is online and only two mouse clicks required to send an online buddy a message.

Recall the requirement that users can do instant messaging on any device. This implies three important requirements for buddy lists:

• The buddy list should be stored somewhere centrally available, so all my devices can use the same buddy list.

• As a user, I should have a consistent address, so all my buddies can still see my presence even when I change devices.

• It should not be obvious that I've switched devices. If I leave for lunch and my PDA takes over from my PC to receive instant messages, that should not affect how my buddies see my presence or how they send messages (unless I choose to provide that information).

14.3.3 Could WebDAV Do Instant Messaging?

In theory, WebDAV could be used as the basic protocol to provide an instant-messaging service (and this idea has been seriously suggested to me several times in the past). However, instant messaging would have to be painfully shoe-horned into the WebDAV model for this to work. I'll lay out a straw man proposal:

• A special collection on a WebDAV server is designated to be an instant-messaging inbox (as Exchange does with email inboxes). The address of this collection is the IM address for both presence and message delivery.

• A set of properties on that collection could advertise my presence status, which other users would query with PROPFIND.

• Messages can be delivered to this inbox with PUT.

• Properties such as sender and recipient can be added to messages with PROPPATCH.

In theory this sounds reasonable: A WebDAV server is likely to be always online, so it can always advertise the user's presence. However, there are a number of problems:

• How are Web proxies and caches expected to handle these messages? Could they cache instant messages, or does every instant message have to be tagged to prevent caching? There's also a risk that firewalls would block incoming HTTP PUT requests, assuming them to be attacks on internal Web sites.

• How do instant messages get from the user's server to a client application? Would the client application have to be a WebDAV server too, in order to receive PUT requests from their server? WebDAV isn't meant to be lightweight on the server side, so this could be a serious burden for a PDA to be a WebDAV server.

• Using PROPFIND to get a user's presence information works fine the first time, but users want to be notified every time a buddy's status changes. WebDAV has no provision for a live constant connection, for notifications from server to client, or for subscriptions to changing information.

• Once an instant message is sent, the sender should have no ability to change the message. Therefore, the sender can't use PROPPATCH to put the appropriate metadata on the message.

• How are MOVE and COPY useful? There is an expectation that any WebDAV server must be a full WebDAV server, supporting at least MKCOL, MOVE, COPY, PROPFIND, and PROPPATCH, in addition to HTTP methods GET, PUT, POST, and so forth.

Surely another protocol, designed more for lightweight messaging and a trusted connection between a presence/messaging client and server, would have many better characteristics. However, while designing a new protocol for presence and instant messaging, there still seems to be a role for file sharing. WebDAV can usefully be a small piece of a much larger picture.

14.3.4 Appropriate Use of WebDAV

Here are some problems related to instant messaging where WebDAV may be appropriate but only to solve these specific problems and not as a general transport. The benefit to this reuse is that the instant-messaging protocol can specialize in the tasks that are truly special and important to the whole character of instant messaging, without solving all of the file-sharing problems that WebDAV has already solved.

Storing Buddy Lists and Access Control

WebDAV might be a useful way for a number of client devices to share and synchronize the same buddy list and access control lists. The buddy list can be one resource or several resources, as can the ACLs. This model could be used even if the server enforces access control restrictions.

WebDAV locking is surprisingly useful here, to avoid having one client device overwrite the buddy list changes of another client device. Other configuration information, in addition to buddy lists, could be stored centrally in the same collection.

File Sharing

Should files be sent between users by storing them temporarily on a WebDAV repository? With an intermediary like that, some of the security problems of direct file transfer can be mitigated, and it certainly makes the instant-messaging protocol simpler.

Storing Offline Messages

Some instant-messaging servers can store messages for the user while the user is offline. When the client reconnects, the offline messages are all delivered. WebDAV could be used as a storage location for these offline messages so that the instant-messaging client can retrieve the offline messages at leisure. However, offline messages really start to resemble email, so probably an email protocol would be even better for solving this problem.

14.3.5 Lessons Learned

Only Clients Make Requests in WebDAV

WebDAV is more useful for applications where the client is making the requests. There is no standard way for the instant-messaging server to initiate communication to deliver messages to the client instantly. The WebDAV model would require it to wait until the client asks for instant messages. WebDAV is best used for those applications, or those components of applications, where it's most appropriate for the client to initiate requests and receive responses.

While one could imagine turning every WebDAV client into a WebDAV server so that it could also receive incoming messages, this is a complicated approach and probably not worth it for the application of instant messages. First, WebDAV has more functionality than an instant-messaging receiver needs to receive messages, so a simpler protocol might be better. Second, if the instant-messaging sender and receiver can both make WebDAV requests and handle WebDAV responses, then WebDAV has no way of managing or correlating this parallel traffic.

WebDAV Can Be a Component of a Solution

WebDAV has functionality that can solve some parts of the instant-messaging problem. For example, we can choose to store buddy lists on a WebDAV server and transfer files via intermediate storage on a WebDAV server. In contrast, a lightweight connection-oriented messaging protocol can be optimized to handle the delivery and reception of instant messages. The WebDAV component can behave independently of the other parts of the solution there is no need for the messaging protocol to be aware of or interact with the WebDAV component. Breaking down problems like this, reusing existing solutions where most appropriate, is an excellent way to simplify.

Similarly, other protocols can integrate with WebDAV to provide benefits in WebDAV-based applications. For example, Jabber (now being standardized through the IETF as XMPP) is an instant-messaging protocol that can be extended to provide all kinds of subscription/notification services to a custom application [Shigeoka02].

The Storage Model Is a Necessary Feature of WebDAV

Although an instant-message delivery protocol that looked a lot like WebDAV could be written, it would be difficult to make it interoperable. WebDAV applications that PUT WebDAV resources expect them to be there, and be readable, and be the same content that was just placed there. A store-and-forward or drop-box model, where the messages are PUT into a black hole and can't then be retrieved by the sender, may not be a good use of PUT.

Compliance Means All Methods

To be a standards-compliant and interoperable WebDAV server, a server must implement the following functionality:

• All of HTTP, including GET, PUT, POST, HEAD, DELETE, OPTIONS. Also remember HTTP requires ETags (entity tags), ranged requests, and conditional headers.

• All of WebDAV level 1 (everything except locks).

If the server doesn't support all of these, then many existing WebDAV clients won't be able to interoperate. The client may attempt a method to connect to the server and then give up if the server doesn't seem to support WebDAV properly.

Clients can get away with a smaller set of functionality because clients can always choose not to initiate a request that they don't want to have to deal with, but there is still a heavy implementation burden to bear.