K. H. Wolf Internet Draft University of Ulm Document: draft-wolf-pms-00.txt June 1999 Category: Informational On Presence, Messages, and Subscriptions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The discussion on instant messaging and a presence protocol is very much biased by the features, limitations, and mistakes of existing presence products. This document discusses those mistakes and many commonly heard misunderstandings. The document proposes a more advanced view (not a protocol) to presence systems, merging IM and PP. The discussion can be followed on the IMPP mailing list (impp@iastate.edu). Structure of the Document The document starts by introducing presence services. Skip chapter 3, if you know about online presence and presence services. It then discusses some often heard misunderstandings and their (wrong) conclusions. Finally a new view to IM and PP is proposed. The document does NOT propose a protocol. Definitions are only given as examples. Table of Contents Wolf Informational - Expires December 1999 1 INTERNET-DRAFT On Presence, Messages, and Subscriptions June 1999 1. What Presence Services Do ..........................................2 1.1. Online Status....................................................2 1.2. User Properties..................................................2 1.3. Messaging - Communication........................................3 1.4. Feature Explosion................................................3 2. Wrong Thinking .....................................................3 2.1. Instant Messaging is different from Email........................3 2.2. Messaging is different from Property Updates.....................4 2.3. IMPP [must|must not] use HTTP....................................5 2.4. IMPP is either client-server or peer-to-peer.....................6 2.5. Standardizing the Basic Functionality is Enough..................7 3. Consequences and Proposals .........................................7 3.1. IM can use SMTP..................................................7 3.2. IM can be integrated into the presence protocol..................7 3.3. The protocol should be defined on an abstract level..............8 3.4. Architecture and communication pattern just depend on URLs.......8 4. The Multi-Property Paradigm ........................................8 4.1. Design Goals.....................................................8 4.2. Fundamental Decisions............................................8 4.3. Instant Messages as Property Updates.............................9 4.4. Features and Advantages.........................................10 5. Protocol Syntax Example ...........................................10 5.1. General Message Format..........................................10 5.2. Definitions.....................................................11 5.3. Messages........................................................11 5.4. Encapsulation...................................................12 6. Security Considerations ...........................................12 7. References ........................................................13 8. Acknowledgments ...................................................13 9. Author's Addresses ................................................13 1. What Presence Services Do 1.1. Online Status Online status is the origin of all presence services. Peers subscribe for each other's online status and get notifications when the status changes. The online status can be augmented in various way, e.g. with an additional message, while out of the office, or while disconnected from the internet. 1.2. User Properties User want more information about peers, so other bits of data (called properties) have been added to the online status, most important, the name (real name and/or nickname), in some cases icons, finally Wolf Informational - Expires December 1999 2 INTERNET-DRAFT On Presence, Messages, and Subscriptions June 1999 communication addresses, email and postal. Such information creates the need for access control (ACLs), which turns out to be also a good idea for the online status. All this information can change over time, so it is wise to use the update mechanism developed for the online status also for other properties. This leads to the user/property/subscription-paradigm, a generalization of the simple GET-style access. Basically, presence systems SUBSCRIBE for data and get multiple responses, while the Web is (yet) based on GET and a single response. 1.3. Messaging - Communication Once people notice each other being online, they start talking. Therefore, presence clients include a chat feature (Unix talk-like or IRC-style). Some even include internet phones, and most can start external ones. Some ask for the communication address of the user and peers, others 'magically' find communication addresses digging through the disk to find configuration files. And people want to send each other messages, like emails, but not using the usual SMTP user agent. Messages are to be delivered very quickly. So fast that we talk about instantaneous delivery, hence Instant Messaging. Messages can have a type, in fact MIME-types are favored, so that they even can be multi-part documents, or HTML pages. 1.4. Feature Explosion Once you got your software on many desktops, it is time to offer lots of services to generate traffic to your Web site, whether the original service is related to the Web or not. This is just mentioned to avoid complaints that many features and services of presence clients are missing here. 2. Wrong Thinking The discussion is very much biased by features and limitations of existing presence systems. These systems have been designed 3 years ago, and have grown since then without a major re-design. We know much more about online presence now. This chapter highlights the most common misunderstandings and explains why they are wrong. 2.1. Instant Messaging is different from Email 2.1.1. Arguments heard - IM is faster Wolf Informational - Expires December 1999 3 INTERNET-DRAFT On Presence, Messages, and Subscriptions June 1999 - IM is peer to peer. Email is not. - IM is not store and forward - IM needs more/less features - IM needs features for anonymity Wrong conclusion: IM can not use SMTP. It needs a new protocol. 2.1.2. But IM is not faster than Email. Email just appears to be slower, because most email programs (message user agents, MUAs) check (POP, IMAP) for mail every 15 minutes. Email MUAs just do not pop-up a dialog box when email arrives in the mailbox. Instantaneous email notification (biff, comsat) disappeared during the Internet user's transition from Unix to Windows. IM is only peer to peer, if firewalls want so. If they don't, then IM is peer to proxy to peer, which actually is the same in terms of speed as Email going MUA-MTA-MUA. IM can also be stored and forwarded. An important requirement of IMPP is, that IMs are stored at some place if a peer is not reachable. They shall be forwarded when the party goes online again. Email can be peer to peer. One just has to integrate SMTP client and server into a presence client and they are sending emails directly (if the firewalls allow). Alternatively, it can fall-back to the store and forward mode of operation. IM neither needs more features, nor less than SMTP provides. Leave something out and once you use IM on a large scale you there will be users requesting SMTP features. Anonymizer services exist for FTP, HTTP and SMTP even though the protocols did not explicitly support them. Anonymity can easily be built on top of a protocol as a service. It does not belong into the protocol. Conclusion: IM can use SMTP. 2.2. Messaging is different from Property Updates 2.2.1. Arguments heard - IM is peer to peer, PP is not. - IMs are faster than presence updates. - IMs are messages while updates are responses to requests. - IMs are for a single user, presence information for many. - Systems with millions of users treat IM and PP differently, they can not be wrong. Wolf Informational - Expires December 1999 4 INTERNET-DRAFT On Presence, Messages, and Subscriptions June 1999 Wrong conclusion: IMPP needs 2 protocols. 2.2.2. But IM is not always peer to peer, see 4.1. PP can also be peer to peer. This depends on URLs an where users are hosted, see 4.4. An (obviously) undisputed requirement [2] is that presence information is as rapidly delivered as IM. Presence updates are messages from the server to the client. Updates can be sent - as simple messages (in a message based presence protocol) - as request (in a request-response presence protocol from presence server to presence client, beware firewalls) - as a response to a (long time) outstanding request (firewall compatible, but not firewall friendly, works well BTW). But there is no fundamental difference between an UPDATE message and an SMTP or Instant Message. Both messages and presence information can be aimed at a single user as well as at a group, or the public. Sending messages to a group is a feature users will need. On the other hand messages can also be stored as user properties and being sent (UPDATE/NOTIFY) only to individuals. Millions of users... well, history shows that the number of users is unrelated to the quality of the design. Conclusion: IM can be integrated into the presence protocol. No extra protocol is required (see 6.3). 2.3. IMPP [must|must not] use HTTP Neither is true. The truth is that in the current phase the wire encoding does not matter. The IMPP working group should focus on requirements (which is being done), mechanisms and primitives. The wire encoding does matter for products. It even matters for prototypes, but given a protocol engine for whatever protocol, developers need one day to extract encapsulated IMPP commands. Developing working mechanisms takes much more time. There is no big difference whether the transport protocol is: - native, binary, like X11 - HTTP with binary body - HTTP with XML body - HTTP-content-body with additional XML-body header-field - HTTP-URL-encoded Wolf Informational - Expires December 1999 5 INTERNET-DRAFT On Presence, Messages, and Subscriptions June 1999 - just TCP with XML - SMTP with XML - UDP with HTTP-syntax and XML body - ... An HTTP-alike protocol is not an option anymore. Consider the development of markup languages. HTML-alike markup languages were appearing for some time until XML provided a solid and unifying foundation for new markup languages (RDF, SMIL). We can see the same development in the HTTP-alike protocol area. There will probably be a new HTTP protocol, with elements, designed for re-use by other application protocols. Developing another HTTP/1.x-alike protocol is not worth the effort anymore. Conclusion: The protocol should be defined at an abstract level. Later, encapsulation rules and/or a native protocol can be defined separately. It might even be advantageous to be able to switch the transport mechanism for different applications. Imagine: subscribing HTTP encapsulated while requesting UPDATEs as emails (SMTP encapsulated). There are serious arguments against using HTTP for IMPP [3]. Using HTTP [4] to tunnel other protocols is generally discouraged, except for special cases and under certain conditions. 2.4. IMPP is either client-server or peer-to-peer This is not true. A client-server system can be migrated to a peer to peer system, if URLs are changed. Assumed IMPP uses a client-server (request-response) protocol and users are identified by URLs: Case 1: All users are maintained by a single server. Example: User 1: impp://central.server.com/user1/ User 2: impp://central.server.com/user2/ The IMPP network is a centralized client-server system. This is good for firewalls, because all traffic is initiated from inside. Case 2: Each user runs an IMPP server. Example: User 1: impp://user1.companyA.com/ User 2: impp://user2.companyB.com/ The IMPP network is a peer to peer system, though using a request- response protocol. Case 3: IMPP servers for user groups, e.g. run by the computing center. Example: User 1: impp://people.companyA.com/user1/ User 2: impp://people.companyA.com/user2/ User 3: impp://people.companyB.com/user3/ The IMPP network is peer to peer for users of different companies, but centralized for users of the same company. Wolf Informational - Expires December 1999 6 INTERNET-DRAFT On Presence, Messages, and Subscriptions June 1999 Conclusion: the topology just depends on URLs and on the implementation. An integrated IMPP client/server can do both. The protocol must not prohibit this. 2.5. Standardizing the Basic Functionality is Enough Opinions heard: - IMPP must be designed quickly, so it must be simple. - Applications differ, the common set is small. Wrong conclusions tend to sound like: Online status, name, and an a message format are enough. But: IMPP must not be designed quickly, just to keep up with the development. The protocol does not have be an internet standard for products to be compatible (see HTTP/1.1). IMPP will probably be used by millions. IMPP must be well engineered, even, if it takes time. The basic functionality is enough, if the design is open to allow for extensions (other user properties or even other transport mechanisms). It is not enough, if just a small common set of properties is being defined. Actually, the common set is an empty set. Conclusion: IMPP should not trade in quality for design speed. Implementation experience and inter-working between different implementations needs time. No tight schedule of milestones. 3. Consequences and Proposals This chapter discusses consequences of the conclusions above and proposes what to do. 3.1. IM can use SMTP This means integrating SMTP client and SMTP server into presence clients. Maybe the other way is even better: integrating the presence client into email programs. Add the 'Contacts' list as a 3rd folder where 'Mail' and 'News' already are. 3.2. IM can be integrated into the presence protocol This means that messages are a user property. User send messages by changing their 'message' property as they are changing (usually automatically) the 'online status' property. Messages are delivered Wolf Informational - Expires December 1999 7 INTERNET-DRAFT On Presence, Messages, and Subscriptions June 1999 as UPDATEs on the 'message' property value (see details in chapter 6). 3.3. The protocol should be defined on an abstract level Proposal: Define the protocol without a wire encoding. Request types, methods, objects, addressing, status codes can all be defined independent of the transfer encoding. Define encapsulation rules or a native protocol separately. The encapsulation rules define, whether a status code is "OK" or "200", or 0xC8. 3.4. Architecture and communication pattern just depend on URLs Move away from the model that a user sends a contact list to one server. Proposal: The contact list consists of URLs. The client subscribes for 'online status' of users at different servers depending on the hostname part of the URL. 4. The Multi-Property Paradigm This chapter proposes a design where properties values may have multiple different values. The value returned depends on the requesting user (FETCHER/SUBSCRIBER). This enables integration of messaging with the presence protocol. 4.1. Design Goals 4.1.1. Integrate instant messaging with presence notifications 4.1.2. A purely subscription-based protocol 4.1.3. Avoid privacy problems of peer to peer communication 4.1.4. Leave the architecture and topology question open 4.1.5. As usual: scalability, extensibility, simplicity, security 4.2. Fundamental Decisions 4.2.1. User names directly or indirectly point to servers (URLs) 4.2.2. All properties of a user are maintained by one server 4.2.3. The property value depends on the requesting user (!) 4.2.4. Properties have a history 4.2.5. All communication is based on property changes 4.2.6. Messages are confirmed 4.2.7. Read access uses subscriptions. Simple GET is an exception. 4.2.8. All messages are authenticated Anything that fits the pattern "A:B" where B can be resolved is a URL. So user names will probably be URLs. The IMPP URL does not have be restricted to Latin-1. Email addresses are not flexible enough, and do not contain the information required for the presence protocol. Wolf Informational - Expires December 1999 8 INTERNET-DRAFT On Presence, Messages, and Subscriptions June 1999 6.2.3 and 6.2.4 each create a set of values for properties. Property values turn into sparse arrays. Properties may have different values, depending on who accesses for which time. Access control lists not only control the right to access, but also the value. This is a generalization of ACLs. The software component which is hosting the user properties is called the server, the subscriber is called the client. Both can be integrated into a single program on the user's computer. But there may also be stand-alone clients and stand-alone servers. UPDATE messages travel from server to client. How this is done and which party initiates the communication, depends on the wire encoding (the encapsulation rules). In a decentralized system, messages travel between user's workstations. Proxies may be required for both parties in both directions. For outgoing connections as well as for incoming connections; for messages (including UPDATEs) and confirmations. All firewall problems can be solved by bi-directional IMPP proxies. Receivers always check the authentication of a message against the user name. This might be done using public key signatures on the message hash. The public key is available as a user property. Only the user who controls the URL (user name) can sign with the corresponding secret key. 4.3. Instant Messages as Property Updates Peers subscribe for the 'message' property as they do for the 'online status'. To send a message, users change the value of their 'message' property FOR a user or a group. Only those peers, who subscribed for the property and who have the proper access right (CHANGED- NOTIFICATION) get the UPDATE message. The UPDATE message may carry the property value or may just notify of the event (access right READ missing). If the UPDATE carries the property value, then delivery is as rapid as IM is supposed to be. Example: Assumed the subscriber uses an integrated IMPP client/server, UPDATE carries the property value, the protocol is ASCII-headers-based, like SMTP and HTTP, then (even on the wire) there is almost no difference between an SMTP or IM message and a property UPDATE message. The time dimension lets users access previous property values. Clients do not have to support the history. An access without time specification returns the latest value. Similarly clients do not Wolf Informational - Expires December 1999 9 INTERNET-DRAFT On Presence, Messages, and Subscriptions June 1999 support the user dimension actively. This is only a server issue. Clients request and get a value. The server decides which value based on the ACL. 4.4. Features and Advantages The user dimension is also useful for other properties, e.g. online status, even name. Example: different names for private and professional contacts. The time dimension may also be useful for other properties, e.g. chat. Users joining late into a chat session can get the history. This has been implemented and works very well. No spamming problem, since all messages are based on subscriptions. Users decide, if they want messages. The default case will be subscriptions for messages of members of the contact list. Use email, if you want to send a message to someone who did not subscribe for your messages. Email works for unsolicited messages. Subscribed-IM does not. This might even turn out to be the major difference and the key to success. If there is no major difference between IM and email, then SMTP can be used (see 4.1). Only a single, yet simple protocol. Simple clients must only be able to SUBSCRIBE to properties and receive UPDATEs to provide online status, name, icon, chat, and messaging. The user and time dimensions are transparent to simple clients. Applications which need additional communication channels between users just add a custom property. Example: A telepointing-on-Web- pages component has been implemented. The (Javascript-based) clients just subscribe for the 'telepointer' user properties of peers and get UPDATEs when the positions change. There was no additional code necessary in the server to add this custom type of instant messages. 5. Protocol Syntax Example The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [5]. This is not a complete protocol proposal, is just an example to explain the above. 5.1. General Message Format A request message consists of subject, property, method, user, authentication, method specific attributes, and optional additional- data. Wolf Informational - Expires December 1999 10 INTERNET-DRAFT On Presence, Messages, and Subscriptions June 1999 A response message (confirmation) consists of response-code and additional-data. Additional-data is always accompanied by data-length (number of octets), and data-type (MIME). 5.2. Definitions impp-username = impp-url impp-method = SUBSCRIBE | UNSUBSCRIBE | NOTIFY | GET | PUT impp-property = "status" | "name" | "icon" | "message" | "chat" | "key" | impp-other-property impp-time = HTTP-date | delta-seconds impp-serviceurl = genericurl ; [6] impp-reference = *(VCHAR) impp-signature = ; [7][8] impp-eventtype = UPDATED | DELETED | SUBSCRIBED | UNSUBSCRIBED impp-responsecode = OK | NOT_FOUND | BAD_REQUEST | ACCESS_DENIED | SERVER_ERROR 5.3. Messages Only SUBSCRIBE and NOTIFY here as examples. 5.3.1. Subscribe Message fields: subject = impp-username ; REQUIRED (the target user) property = impp-property ; REQUIRED method = SUBSCRIBE ; REQUIRED user = impp-username ; REQUIRED (the sender) auth = impp-signature ; REQUIRED Attributes: ref = impp-reference ; OPTIONAL (subscription-ID) reply-to = impp-serviceurl ; REQUIRED timeout = impp-time ; OPTIONAL event = impp-eventtype ; OPTIONAL (default: UPDATED) 5.3.2. Notify Message fields: subject = impp-username ; REQUIRED (the target user) property = impp-property ; REQUIRED method = NOTIFY ; REQUIRED user = impp-username ; REQUIRED (the sender=server) auth = impp-signature ; REQUIRED Attributes: ref = impp-reference ; OPTIONAL (subscription-ID) Wolf Informational - Expires December 1999 11 INTERNET-DRAFT On Presence, Messages, and Subscriptions June 1999 event = impp-eventtype ; OPTIONAL (default: UPDATED) additional-data ; OPTIONAL (property value) 5.4. Encapsulation The SUBSCRIBE request for 3 encapsulation variants. The rules section has been omitted. It is rather formal and lengthy. "+" denotes continued lines. 5.4.1. HTTP/TCP-urlencoded | GET /impp?subject=http://people.companyB.com/user3 + &property=status + &method=subscribe + &user=http://people.companyA.com/user1 + &auth= Z2Q1MzQ4a3M5NGpmMzc + &ref=25&timeout=3600&event=update + &reply-to= http://people.companyA.com/impp/ HTTP/1.1 | 5.4.2. HTTP-alike | SUBSCRIBE /user3/status IMPP/1.0 | Host: people.companyB.com | User: impp://people.companyA.com/user1 | Auth: MD5/RSA Z2Q1MzQ4a3M5NGpmMzc | Ref: 25 | Timeout: 3600 | Event: update | Reply-to: impp://people.companyA.com/ | 5.4.3. X11-alike This one can be called a native encoding. But many people prefer the HTTP-alike encoding and call that native. 0x0100, /* protocol version */ 0x0101, /* major opcode, minor opcode=SUBSCRIBE */ 0x0001, 0x00000019 /* event=UPDATE, ref */ 0x0028, "impp://people.companyB.com/user3/status", /* property */ 0x001f, "impp://people.companyA.com/user1" /* sender */ 0x001a, "impp://people.companyA.com/" /* reply-to */ 0x0101, 0x21A8B32DF7E61B75, /* auth version, signature */ 6. Security Considerations Some of the proposals made in this document are induced by privacy and security concerns in the IMPP area. It is hoped that this Wolf Informational - Expires December 1999 12 INTERNET-DRAFT On Presence, Messages, and Subscriptions June 1999 document contributes to a secure design which avoids problems of current online presence systems. None of the ideas presented here is problematic in the sense that it is known to have unresolved issues which may turn into security holes. There might still be yet unknown security problems. The authentication mechanism of a real protocol should follow proven mechanisms in other protocols, e.g. Domain Name System Security Extensions. 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Day, M. Aggarwal, S., Mohr, G., Vincent, J., Instant Messaging / Presence Protocol Requirements, INTERNET-DRAFT, work in progress, draft-ietf-impp-reqts-00.txt, Expires: November 17, 1999. 3 Day, M., "''HTTP Envy'' and Presence Information Protocols", INTERNET-DRAFT, work in progress, draft-day-envy-00.txt, Expires: September 13, 1998. 4 Moore, K., Faltstrom, P., "Using HTTP", INTERNET DRAFT, work in progress, draft-iesg-using-http-00.txt, August 1998. 5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 6 Berners-Lee T., Masinter L., McCahill M., "Uniform Resource Locators (URL)", RFC 1738, Dec 1994. 7 Rivest R., " The MD5 Message-Digest Algorithm", RFC 1321, April 1992. 8 Kaliski, B., Staddon, J., "PKCS #1: RSA Cryptography Specifi- cations, Version 2.0" RFC 2437, October 1998. 8. Acknowledgments Thanks to members of the IMPP working group and to my working group who helped to develop the proposed model. 9. Author's Addresses Klaus H. Wolf Distributed Systems Dept. University of Ulm 89069 Ulm Germany Phone: +49 (731) 502 4145 Email: wolf@informatik.uni-ulm.de Wolf Informational - Expires December 1999 13