Internet Draft INTERNET-DRAFT Florencio Mazzoldi flo@networkprojects.com Network Projects, Inc. Athanassios Diacakis thanos@networkprojects.com Network Projects, Inc. Expires: 15th December 2000 15th June 2000 An Architecture and Protocol for Presence and Instant Messaging draft-networkprojects-impp-proposal-01.txt 1. Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Please send comments to the authors or to the impp@iastate.edu discussion list. Copyright (C) The Internet Society (2000). All Rights Reserved. 2. Abstract There is a growing number of people, on the Internet and elsewhere, that are interested in knowing when others are available, in order to communicate with them. A system that provides this information is known as Presence Service. Instant Messaging is the ability to communicate with someone in a rapid, conversational fashion. This usually involves short text messages, but it may be extended in different ways. This draft is a response to the efforts of the Instant Messaging and Presence Protocol (IMPP) group. It describes an architecture and protocols for Presence and Instant Messaging that meet the requirements of [RFC 2779]. This draft covers the basic functional modules needed to provide Presence and Instant Messaging services. It also provides the semantics for the interactions among this set of functional modules, along with the data format of the information exchanged. 3. Background Existing offerings to the Presence and Instant Messaging audience are based on a set of proprietary products with little or no interoperability among them. Since interoperability was deemed to be important, the Instant Messaging and Presence Protocol Working Group was tasked to produce an Internet Standard for Presence and Instant Messaging. The group has issued several documents detailing the requirements [RFC 2779] and model [RFC 2778], but there has not been a consensus about the standard, or a comprehensive proposal yet. This document assumes the reader is familiar with [RFC 2778] and [RFC 2779]. 4. Table of Contents 5. About this document 5.1. Terminology 5.2. How To Read This Document 6. System Architecture 6.1. Presence Architecture 6.2. Instant Messaging Architecture 6.3. Intra-domain Clustering 6.4. Extensibility 6.5. Security 6.5.1. Internet Limitations 6.5.2. Security Levels 6.5.2.1. Default Security Overview 6.5.2.2. High Security Overview 6.6. Namespace 6.6.1. Identifiers 6.6.2. Name Resolution 7. Protocol Specification 7.1. Transport Layer 7.1.1. Connection 7.1.2. Data Representation 7.2. Operation Layer 7.2.1. Connection Model 8. Presence Operation Layer 8.1. Presence Information 8.2. Presence Privacy Controls 9. Instant Messaging Operation Layer 9.1. Instant Message size and format 9.2. Instant Messaging Access Control 9.3. USER AGENT - IM Server Interaction 10. Operations 10.1. Transaction IDs 10.2. Error handling 10.3. Presence Operations 10.3.1. Connection 10.3.1.1. Connect 10.3.1.2. Disconnect 10.3.2. Subscription Management 10.3.2.1. Subscribe 10.3.2.2. Unsubscribe 10.3.3. Presentity Information Propagation 10.3.3.1. Set Presence 10.3.3.2. Get Presence 10.3.4. Access Control List Management 10.3.4.1. Update Access Control List 10.3.4.2. Get Access Control List 10.3.5. WATCHER Information Management 10.3.5.1. Get Watchers 10.4. Instant Messaging Operations 10.4.1. Opening and Closing the Instant Inbox 10.4.1.1. Open Inbox 10.4.1.2. Close Inbox 10.4.2. Sending and Receiving Messages 10.4.2.1. Send Message 10.4.3. Authorization Management 10.4.3.1. Authorization Request 10.4.4. Access Control List Management 10.4.4.1. Update Access Control List 10.4.4.2. Get Access Control List Appendix A: Document Type Definition and Valid Commands A.1. Presence Service Command DTD A.2. Instant Messaging Service Command DTD Appendix B: Error Codes Appendix C: References Appendix D: Authors' Addresses 5. Terminology [RFC 2778] and [RFC 2779] define the terminology for the presence and instant messaging fields. Please refer to those documents for a complete glossary of the UPPER CASED terms. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 6. System Architecture The Presence and Instant Messaging architecture is composed of several functional entities or modules that communicate among themselves. Although those entities MUST be able to operate on different physical locations, it is envisaged that some of them will often be located together. 6.1. Presence Architecture The Presence Servers provide the distributed PRESENCE SERVICE. Each Presence Server is responsible for a set of PRINCIPALS. PRINCIPALS can publish their PRESENCE INFORMATION through their Presence Servers. USER AGENTS represent those PRINCIPALS. USER AGENTS are only required to connect to their Presence Servers and need not connect to other USER AGENTS. +-------------------+ +-------------------+ | PRESENCE SERVER |<-------->| PRESENCE SERVER | +-------------------+ +-------------------+ ^ ^ ^ ^ | | | | | | | | v v v v +--------+ +--------+ +--------+ +--------+ | UA | | UA | | UA | | UA | +--------+ +--------+ +--------+ +--------+ Figure 1. Presence Architecture Presence Servers SHOULD NOT be aware of each other until the time they need to communicate. At that time, they discover the other Presence Server address through the Name Resolution Service. For example, this situation could arise should a WATCHER on one Presence Server needs to observe a PRESENTITY residing on other server. 6.2. Instant Messaging Architecture The architecture of the INSTANT MESSAGING SERVICE is very similar to that of the PRESENCE SERVICE. Each Instant Messaging Server (IM Server) is responsible for a set of PRINCIPALS. PRINCIPALS send and receive messages to and from their IM Servers (through their USER AGENTS). IM Servers forward messages for PRINCIPALS that they are not responsible for to their respective IM Servers. +--------------------+ +--------------------+ | IM SERVER |<--->| IM SERVER | +--------------------+ +--------------------+ ^ ^ ^ ^ | | | | v v v v +--------+ +--------+ +--------+ +--------+ | UA | | UA | | UA | | UA | +--------+ +--------+ +--------+ +--------+ Figure 2. Instant Messaging Architecture IM Servers SHOULD NOT be aware of each other until the time they need to communicate. At that time, they discover the other IM Server address through the Name Resolution Service. 6.3. Intra-domain Clustering For scalability, availability or other reasons, several Presence or IM Servers may be necessary to server PRINCIPALS of the same domain. As the implementation details of such a setup do not affect interoperability, this subject is beyond the scope of this document. 6.4. Extensibility Although the Architecture described in this draft is generic, there are some aspects of this Presence and Instant Messaging Protocol that do not meet the requirements of certain devices or networks where presence and instant messaging will play a major role. For instance, the connection model described in Section 7.2.1. may not be suitable for wireless and mobile networks. Recognizing the importance of supporting those devices and networks and, furthermore, anticipating that it would be difficult at best to design a "one-size-fits-all" solution, it is clear that for all those cases, a different set of protocols MAY need to be defined with the special needs of each device or network in mind. For the wireless devices, for instance, the Transport Layer Security [TLS] is not an optimal security scheme, so for this case other protocol may be considered, implementing Wireless Transport Layer Security [WTLS]. To enable coexistence of different protocols, and still maintain the connectivity with the Servers described in this document, GATEWAYS will be utilized. A GATEWAY is as an entity that behaves as a USER AGENT from the perspective of a Presence or IM Server, but acts as a server for clients with different protocols on its other side. GATEWAYS translate between protocols, allowing a seamless integration of any present or future device or network. The basic structure of the interaction model in this case is shown in Figure 3. +-----------------+ +------------------+ | PRESENCE SERVER | | IM SERVER | +-----------------+ +------------------+ ^ ^ | | v v +----------------------------+ | GATEWAY SERVER | +----------------------------+ ^ ^ | | v v +----------+ +---------------+ | WIRELESS | | OTHER DEVICES | | DEVICES | | AND NETWORKS | +----------+ +---------------+ Figure 3. Extensibility through Gateway Servers The major requirement for the creation of GATEWAYS is that they MUST preserve the semantics of the USER AGENT interface towards the Presence and IM Servers. For instance, since the acknowledgement of a message indicates that the message has been received at its final destination, the GATEWAY MUST NOT acknowledge the delivery of the message if it intends to store and forward it when the recipient becomes available. 6.5. Security [RFC 2779] sets out several security requirements for IMPP. Some of the security requirements are stated explicitly as "security requirements", e.g. the ones related to the privacy of messages. Others are less explicit, such as the ones related to access control, where authentication is required. In this document we address those requirements, in most cases, without resorting to strong cryptography. Although the resulting system could be more "secure", we consider the security level provided to be higher than other systems we use everyday such as SMTP email, thus making it suitable for most, yet not all, applications. At the same time we recognize the requirement of stronger security and we are working to produce a system with a more comprehensive security solution. We expect to have additional documentation available shortly. 6.5.1 Internet Limitations The Presence and Instant Messaging Architecture utilizes parts of the existing Internet infrastructure. Thus, there are some instances where it can only be as secure as those underlying parts. We cannot and will not address all the security problems of the Internet in this document. That is beyond the scope of this group and it would also duplicate the efforts of various other groups in the IETF and elsewhere. Instead in this document we have: a) addressed the security issues that directly and clearly pertain to Presence and Instant Messaging only. b) designed the system in such a way that the effects of any attacks on the underlying Internet mechanisms are minimized and the requirements of [RFC 2779] are still met. c) assumed that eventually there will be more secure solutions to existing systems. For example, DNS lookup is used to determine the location of a given PRINCIPAL'S Presence Server. In this way, it is made possible for an attacker through DNS spoofing to redirect the querying party to a different (spoofed) Presence Server. As standards such as DNS SEC are implemented, this type of attack would become irrelevant. 6.6. Namespace 6.6.1. Identifiers The PRINCIPAL IDENTIFIERS have the format of email addresses, as described in [RFC 822]. Email addresses are ideal IDENTIFIERS as they provide a simple and elegant solution that reuses existing infrastructure, have a federated administration, can utilize the existing security (including certification) infrastructure, and last but not least, usability tests suggest that end-users prefer them over other addressing schemes. An IDENTIFIER SHOULD correspond to an underlying email address. There are no hard requirements that point to this, but the end-users preferences and the certification authorities practices would make a strong case for this. The IDENTIFIERS may or may not be the same for the PRESENCE SERVICE and the IM SERVICE. 6.6.2 Name Resolution Should two PRINCIPALS, each using a different Presence or IM Server, need to communicate, their corresponding Servers will need to locate each other, given the IDENTIFIERS of the PRINCIPALS. By using the email address as the IDENTIFIER, the system would be able to reuse the existing Domain Name Services to achieve this. If the domain of the two PRINCIPALS is the same, and they are handled by different servers, there needs to be a protocol to allow the servers to interact. As previously stated, this protocol is not in the scope of the current document. The Name Resolution Service consists of a Primary and a Secondary lookup. The Primary lookup is done through a DNS SRV RR. Since not all the DNS server implementations support SRV entries, a Secondary lookup needs to be in place for the cases where the DNS SRV fails. This Secondary lookup is also performed through DNS, but it will look up the A record instead. The Primary lookup uses a DNS SRV entry which indicates "tcp" as the protocol. For the Presence Servers "impp-ps" is used as the service name, whereas "impp-ims" is used for the IM Servers. The Secondary lookup takes the domain of the PRINCIPAL and prepends "impp-ps" for the Presence Servers, and "impp-ims" for the IM Servers. Then a DNS query of the A record of the resulting name is performed. For instance, if an entity is looking for the Presence Server serving the domain "networkprojects.com" and the DNS Server that holds that domain does not support SRV entries, there should be in that DNS Server an A record for "impp-ps.networkprojects.com". 7. Protocol Specification The protocols for Presence and Instant Messaging are composed of two layers: the Transport and the Operation Layers. On the lower end, the Transport Layer provides the basic transport mechanism. On the higher level, the Operation Layer specifies the message exchange sequences among the different modules to perform the required functions. The Operation Layer uses the services provided by the Transport Layer. 7.1. Transport Layer 7.1.1. Connection All the communications for the protocols will be TCP-based. TCP's characteristics that make it desirable are its reliability features, the fact that it is already implemented in all major operating systems and it is extensively supported by firewalls. Presence Servers SHOULD listen to port 8341 and IM Servers SHOULD listen to port 8342. Note: Those port assignments are temporary and arbitrary. Naturally we'd need to go through the IANA channels to get the ports assigned. Once the Transport Layer connection is established, it will carry all the communication between the corresponding two modules. The connections between USER AGENTS and servers will be maintained until either: - the USER AGENT or server decide to disconnect; or - the connection drops due to an error The connections between servers SHOULD be established on an as- needed basis. Implementations MAY leave connections open in order to re-use them with the same server, or close them to re-use the network resources to communicate with different servers. For the devices and networks that do not support long-lived connections, refer to Section 6.4. 7.1.2. Data Representation The Presence and Instant Messaging Protocol is composed of a set of Commands that are interchanged between different entities. The Commands MUST be valid documents as defined in [XML]. The XML Document Type Definition for the valid commands can be found in Appendix A. For example, a valid Command might be:7.2. Operation Layer To achieve a desired effect, usually a set of Commands must be exchanged between two entities, in a particular order. This set of Commands comprises an Operation. The Operation Layer describes those Operations, and specifies the semantics of each Operation and the sequences of events that each MUST follow. Unless otherwise specified, the Operations are synchronous in nature. Thus, if a reply is needed for a Command, the Operation will wait for a defined amount of time, after which it will assume a failure in the Operation. Multiple Operations can be occurring at the same time, over the same Transport Layer connection. The Operation Layer for Presence is different than the one for Messaging. We will discuss them separately in Sections 8 and 9. 7.2.1. Connection Model A connection at the Operation Layer is necessary for the for a USER AGENT to interact with a Presence or IM Server, or for Servers to interact among themselves. A TCP connection at the Transport Layer does not imply a connection at the Operation Layer. Connection at the Operation Layer though, does imply a connection at the Transport Layer. In order to establish a connection in the Operation Layer, the Connect Operation needs to be performed, authenticating the interacting modules. When a USER AGENT connects to a server it will authenticate itself by sending across its credentials, in this case a email address and a password. When two servers connect to each other, they do not exchange credentials. Instead, when a server receives information from another server regarding a certain PRINCIPAL, it must verify that the PRINCIPAL does indeed belong to that server. This is done by performing a name resolution on the PRINCIPALS IDENTIFIER and determining whether there is a match on the IP address of the sender. The Operation Layer connection between the two entities will remain open until either entity issues a Disconnect operation, the lower level TCP connection drops, or either entity fails. Note: a connection at the Operation Layer between a USER AGENT and Presence Server does not imply PRESENCE INFORMATION change. It only indicates that the USER AGENT can communicate with the PRESENCE SERVICE. Similarly, a connection at the Operation Layer between a USER AGENT and an IM Server does not imply that its INSTANT INBOX is OPEN. 8. Presence Operation Layer This section discusses the PRESENCE INFORMATION and the Access Control mechanisms for the PRESENCE SERVICE. It finishes with the generic interaction among USER AGENTS and Presence Servers. 8.1. Presence Information As described in [RFC 2778], each PRESENTITY may publish several PRESENCE TUPLES. A PRESENCE TUPLE indicates whether the PRINCIPAL is available on a certain device with a certain communication address. The PRESENCE TUPLE also contains a "preference" attribute which indicates how the PRINCIPAL would prefer to be contacted. One of the addresses in the PRESENTITY INFORMATION will typically be of the type "im", and will correspond to an INSTANT MESSAGING INBOX, used by the IM Servers. A PRINCIPAL can selectively disseminate their PRESENCE INFORMATION through the use of a Privacy Control List. This list specifies who may have access to which part of the PRINCIPAL'S PRESENCE INFORMATION. This is described in detail in the next section. Additionally, a PRINCIPAL may want to publish different PRESENCE INFORMATION to different WATCHERs or groups of WATCHERs. For this reason, each PRESENCE TUPLE can have multiple versions. When a PRINCIPAL publishes a given PRESENCE TUPLE, they must specify which version they are publishing and that PRESENCE TUPLE will get propagated according to the PRINCIPAL'S Privacy Controls. Each PRESENTITY MAY maintain several different connections with its Presence Server at the same time. For instance one may maintain a connection for a home computer, a work computer and a wireless PDA. Note: For the PRESENCE SERVICE to recognize a PRINCIPAL within its domain, the Presence Server must have the necessary information to authenticate the PRINCIPAL upon Connection. It is outside the scope of this document as to how the two parties exchange this information. 8.2. Presence Privacy Controls Each PRESENTITY's PRESENCE INFORMATION is shared with the rest of the world according to the ACCESS RULES defined in the PRESENTITY's Privacy Control List. The Privacy Control List is composed by a set of rules. Each rule specifies how one or more PRESENCE TUPLES are shared with one or more WATCHERS. A rule contains the following information: - WATCHER: The WATCHER attribute may indicate individual WATCHERS, domain names or the wildcard "*". This latter case denotes that the rule applies to every WATCHER that has no specific rules for the current PRESENCE TUPLE. - PRESENCE TUPLE Type: Allows the WATCHER to access the PRESENCE TUPLES that contain PRESENCE INFORMATION for the specified communication type. The value of this field can also be the wildcard "*" to indicate "All types". This can be further narrowed down through the "PRESENCE TUPLE Address" field. - PRESENCE TUPLE Address: Allows the WATCHER to access the PRESENCE TUPLES that contain PRESENCE INFORMATION that pertain to the specified communication address. The value of this field can also be the wildcard "*" to indicate "All Types". This can be further narrowed down through the "PRESENCE TUPLE Type" field. - Version: the version of the PRESENCE TUPLE that this rule refers. This allows the publication of different versions of a PRESENCE TUPLE for different audiences. - Permission: indicates whether the WATCHER or group of WATCHERs can access the Element. There are three possible values for the Permission attribute: - Grant: Allow access to the PRESENCE TUPLE - Deny: Do not allow access to the PRESENCE TUPLE - Request: Indicates to the PRESENCE SERVICE that it should verify with the PRINCIPAL whether it should GRANT or DENY access to the PRESENCE TUPLE. Since the more than one rule might apply for a given situation, the following is applied to determine precedence: - More "specific" rules are evaluated before less "specific" rules. - The order for determining the "specificity" is WATCHER, Type, Address. For example the rule "All WATCHERS can have access to im:thanos@networkprojects.com" is more generic than the rule "dougie@networkprojects.com can have access to All presence information". - Once a rule is found to be applicable, that rule is applied and the process stops. 9. Instant Messaging Operation Layer This section discusses the INSTANT MESSAGE size and format, the Privacy Control mechanisms for the INSTANT MESSAGING SERVICE, and the generic interactions among USER AGENTS and IM Servers. 9.1 Instant Message size and format This protocol does not put any limits on the size of INSTANT MESSAGES. Individual implementations MAY chose to do so, depending on their requirements. An arbitrary limit would serve little purpose as size is very relative. For example, a 100kb voice message would be considered small on a 100Mbit LAN and "big" on a 9.6Kbit GSM data connection. An alternative to an arbitrary limit would be a negotiated limit, yet that would present increased overhead. The common message format uses MIME headers and encoding to transport the message payload. This allows interoperability with existing MIME systems, re-use of existing MIME standards, support for internationalization, and provides extensibility. End-to-end message security can be optionally provided through S/MIME. 9.2 Instant Messaging Access Control IM Servers provide the means for PRINCIPALS to control who can send INSTANT MESSAGES to their INSTANT INBOX, by defining a set of Access Control Rules. Each row in this Access Control List is a rule that defines whether a PRINCIPAL may or may not send INSTANT MESSAGEs to the INSTANT INBOX the PRINCIPAL is connected to. Also, the rules specify who may or may not ask authorization to send INSTANT MESSAGES to an INSTANT INBOX. Each row contains the following information: - PRINCIPAL: It may indicate individual PRINCIPALs, domain names or the wildcard "*". This latter case denotes that the rule applies to every PRINCIPAL that has no specific rules for the current INSTANT INBOX. - Permission: indicates whether the PRINCIPAL can send INSTANT MESSAGES or request authorizations to send INSTANT MESSAGES to the INSTANT INBOX. There are three possible values for the Permission attribute: - Grant: Accept INSTANT MESSAGES or Authorization Requests from the sender. - Deny: Not accept INSTANT MESSAGES or requests from the sender. - Request: Not accept INSTANT MESSAGES from the sender, but accept Authorization Requests. Specific rules regarding PRINCIPALS precede the domain specific rules, and domain specific rules precede the everyone ("*") rules. In order for a PRINCIPAL to be able to send an INSTANT MESSAGE to an INSTANT INBOX, it must have Grant permission over that inbox. In the cases of Request and Deny, the INSTANT MESSAGE will not be delivered. However, if the PRINCIPAL has Request permission, it will be able to send an authorization request to start sending messages. If this request is accepted by the owner of the INSTANT INBOX, the rule for that PRINCIPAL will be changed to Grant, and messages will be received. If the request is not granted, the PRINCIPAL may remain with Request permission, or it may change to Deny. 9.3. USER AGENT - IM Server Interaction To start interacting with the IM Server, the USER AGENTS need to issue the Connect Operation. This will authenticate them and the USER AGENT will issue an Open Inbox operation, to start receiving messages. From then on, the IM Server may issue Receive Message Operations for INSTANT MESSAGES received for that INSTANT INBOX. Also, after the connection has been established, the USER AGENT can perform any other operation. For the complete detailed list of Operations refer to Section 10.4. When the PRINCIPAL wishes to stop receiving messages, it will issue a Close Inbox operation. Even after this is done, and although no messages will be accepted for that INSTANT INBOX by the IM Server, all the rest of the Operations may be issued, because the USER AGENT is still connected to the IM Server. When the PRINCIPAL wishes to disconnect from the IM Server, it will issue a Disconnect Operation. No Operations may be performed after the Disconnect Operation. A potential privacy issue arises when users can send a message an INSTANT INBOX to determine whether it is OPEN or CLOSED. In this way they can figure out, with a fairly high confidence level, part of the PRINCIPAL'S PRESENCE INFORMATION. This problem also exists with other communication media. For example, one can always ring a given telephone number, regardless of the corresponding PRESENCE INFORMATION. This problem is solved by having the USER AGENT "bounce" INSTANT MESSAGES from entities that should think that the INSTANT INBOX is closed. This could also be done at the server level by having the Instant Messaging Server co-operate with the Presence Server. However, such implementation issues are beyond the scope of this document. Note: For the INSTANT MESSAGING SERVICE to recognize a PRINCIPAL within its domain, the Instant Messaging Server must have the necessary information to authenticate the PRINCIPAL upon Connection. It is outside the scope of this document as to how the two parties exchange this information. 10. Operations This section describes the Operations for the Presence and Instant Messaging Operation Layers. They are divided into Operation Groupings, consisting of one or several Operations. Each Operation is described as a sequence of Command exchanges between the different communication modules. Each message exchanged is an XML element. This element has an attribute for the Protocol Version and the Transaction ID. Inside the element, the first element indicates the Type of the command. For a list of the possible Types, along with the specific syntax of each, please refer to Appendix A. In turn, each Command parameter will be briefly explained in the Operations they are used. Note: The Command names will be enclosed by <>. 10.1. Transaction IDs Each Operation in a functional module is given a Transaction ID. This Transaction ID is included in each Command sent to the other module. Since an operation may result in several command interchanges, and several operations may be taking place at the same time, IDs indicate what operation they belong to. Thus, all the commands for the same operation should carry the same Transaction ID. Transaction IDs are composed of two parts. The first one identifies the initiator of the Operation, and the second identifies the Operation ID within that party. The identifier of the initiator of the Operation will be "T" if the initiator is the module that opened the connection; and "F" if it is not. Each functional module starts with an Operation ID of 1, incrementing with each Operation initiated by it. If it reaches 2^32-1, it wraps around to 1 again. A valid Transaction ID would then be T12, indicating that it belongs to the 12th Operation initiated by the party that opened the connection. 10.2. Error handling In several cases, the initiator of an Operation needs to be certain that the Operation was carried out successfully. This is particularly true in Operations that concern permanent information (as the Access Control List or a Subscription Request). For those cases, Commands are used to show that the other party has processed the previous command correctly. For error reporting, Commands are utilized. This Command has two fields: - Error Code: specifies the type of error occurred. For a list of error codes see Appendix B. - Error Info: a textual description of the error, or other additional information. If the Sender of a Command that needs or other type of response does not receive it in a configurable amount of time it must assume with Error Code: Destination Unreachable. Also, in the cases where there needs to be a Name Resolution performed, and the domain is not found, a Command with Error Code Unknown Domain will be returned. In most of the Operations of Presence and IM, the Servers need to resolve PRESENTITIes or INSTANT INBOXes given their IDENTIFIER. In the cases where the IDENTIFIER cannot be resolved a Command is usually returned with Error Code Presentity Unknown or Inbox Unknown. Note that this model forces the Operations to be idempotent, i.e. the final result on the system does not change with the amount of times the operation is executed. It is easy to see that a USER AGENT may start an Operation, the Server execute it successfully, and the connection failing before the USER AGENT receives the . Under this scenario, the USER AGENT would timeout and consider the Operation failed. Thus, it would issue it again as soon as connection is reestablished. 10.3. Presence Operations 10.3.1. Connection 10.3.1.1. Connect The Connect Operation will establish the communications between a USER AGENT and a Presence Server. It lets the system authenticate the PRINCIPAL. The main interchange of Commands is: (1) The ENTITY sends the command to its Presence Server (2) The Presence Server answers with an if successful, a otherwise. The possible error codes are: - Authentication Failed - Presentity Unknown (3) The Presence Servers will send Commands for the SUBSCRIPTIONS of that PRINCIPAL 10.3.1.2. Disconnect To terminate the communications among the ENTITY and the Presence Server, the USER AGENT needs to issue a Disconnect Operation. (1) The ENTITY sends a Command There is no need for the Presence Server to answer. This operation has the same effect that a connection failure, so there is no need to request a specific acknowledgement that it was performed. USER AGENTS SHOULD perform Set Presence Operations to set the status unavailable for the addresses reported through this medium before issuing Disconnect Operations. If this is not performed, the Presence Servers will execute an equivalent Set Presence Operation on behalf of the PRESENTITY. It is understood that this restricts the flexibility on the PRESENCE INFORMATION maintained by the system, so future versions of the protocol should address this issue. 10.3.2. Subscription Management 10.3.2.1. Subscribe The Subscribe Operation is issued by an ENTITY when it is interested in receiving NOTIFICATIONS about PRESENCE INFORMATION changes of a PRESENTITY. The specific Command Interchange is: (2) +-----------------+ ----> +-----------------+ | Presence | <---- | Presence | | Server | (3) | Server | +-----------------+ <---- +-----------------+ ^ | | (7) | ^ (1) | | (4) | (8) (5) | | (6) | v v v | +------------+ +------------+ | WATCHER | | PRESENTITY | +------------+ +------------+ Figure 4: Subscribe Operation (1) The WATCHER sends a Command to the Presence Server. This command shows the IDENTIFIER of the PRESENTITY and the Elements (see Section 9.2.) it wants to subscribe to. If the PRESENTITY pertains to the same Presence Server, it checks the PRESENTITY's Access Control List for the WATCHER and the Elements requested. The access control algorithm can return: - Grant, and a list of Elements granted - Deny, and a list of Elements denied - Request, and a list of Elements that require authorization For the Elements with Permission Request, go to (5), (6) and (8). For all the rest go to (8). (2) The Presence Server will send a Command to the remote Presence Server. This request carries the IDENTIFIER of the WATCHER requesting the subscription, the IDENTIFIER of the PRESENTITY, and the Elements. The Remote Presence Server will check the PRESENTITY's Access Control List for the WATCHER and the Elements required. The access control algorithm can return: - Grant, and a list of Elements granted - Deny, and a list of Elements denied - Request, and a list of Elements that require authorization If there are any Elements with Permission Request, go to step (3) and asynchronously to (5). For all other ones go to step (7). (3) The Remote Presence Server responds with a Command, with "Request" as the permission and a list of Elements, showing that the PRESENTITY needs to be contacted to grant access for those Elements. (4) The Presence Server sends a Command to the ENTITY, with "Request" as the permission and the list of Elements. (5) When the PRESENTITY is Connected, its Presence Server sends a Command, showing the WATCHER that wishes to subscribe, together with the Elements it wants to subscribe to. (6) The PRESENTITY responds with a Command, either Granting or Denying the request for each Element. (7) The Remote Presence Server sends a Command to the Presence Server with the list received. (8) The Presence Server sends a Command to the WATCHER, with the result of the Subscription Operation. For those Elements with Permission Grant, the WATCHER will receive NOTIFICATIONS when they change. 10.3.2.2. Unsubscribe The Unsubscribe Operation is issued by a WATCHER when it wishes to stop receiving NOTIFICATIONS about updates on some Element of a PRESENTITY. The sequence of Command interactions is: +-----------------+ (2) +-----------------+ | Presence | ----> | Presence | | Server | <---- | Server | +-----------------+ (3) +-----------------+ ^ | (1) | | (4) | v +------------+ | WATCHER | +------------+ Figure 5: Unsubscribe Operation (1) The WATCHER sends an Command to the Presence Server. This command shows the IDENTIFIER of the PRESENTITY and the Elements it wants to unsubscribe from If the PRESENTITY pertains to the same Server, it checks the subscriptions for the PRESENTITY, and go to step (4) (2) The Presence Server sends a Command to the remote Presence Server. This request carries the IDENTIFIER of the WATCHER requesting the end of the subscription, the IDENTIFIER of the PRESENTITY, and the Elements. (3) The Remote Presence Server checks the subscriptions and either sends an Command if the subscriptions were removed, or a with the following Error Codes: - Inexistent Subscription (4) The Presence Server sends an Command to the WATCHER if the Removal was successful, or a , with the same error codes as (3). 10.3.3. Presentity Information Propagation 10.3.3.1. Set Presence When a PRESENTITY wants to change its PRESENCE INFORMATION, it performs a Set Presence Operation in the Presence Server. This Operation is used to propagate that INSTANT MESSAGING INBOXes are open or closed. The Command exchange for this Operation is: (1) the PRESENTITY sends a Command to the Presence Server with all the PRESENCE INFORMATION TUPLES corresponding to this connection. This command does not need acknowledgement, since a fail to perform the operation would typically mean that the connection to the server is (or will be shortly) dropped, obliging the PRESENTITY to reconnect anyway (2) asynchronously, the Presence Server sends an Command to all the SUBSCRIBERS that have SUBSCRIPTIONS on any of the data changed and are currently connected. This Command also does not require acknowledgement (3) asynchronously, the Presence Server sends an Command to all the servers with SUBSCRIBERS with SUBSCRIPTIONs on the changed information 10.3.3.2. Get Presence The Get Presence Operation is used by USER AGENTs to FETCH all or part of the PRESENCE INFORMATION of a PRESENTITY. The steps to perform the Operation are similar to those of the Subscribe Operation: (2) +-----------------+ ----> +-----------------+ | Presence | <---- | Presence | | Server | (3) | Server | +-----------------+ <---- +-----------------+ ^ | | (7) | ^ (1) | | (4) | (8) (5) | | (6) | v v v | +------------+ +------------+ | FETCHER | | PRESENTITY | +------------+ +------------+ Figure 6: Get Presence Operation (1) The FETCHER sends a Command to the Presence Server. This command shows the IDENTIFIER of the PRESENTITY and the Elements (see Section 9.2.) it wants to fetch. If the PRESENTITY pertains to the same Presence Server, it checks the PRESENTITY's Access Control List for the FETCHER and the Elements requested. In addition, it checks for the version of the PRESENCE TUPLES that this FETCHER is allowed to have access to. The access control algorithm can return: - Grant, and a list of Elements granted - Deny, and a list of Elements denied - Request, and a list of Elements that require authorization For the Elements with Permission Request, go to (5), (6) and (8). For all the rest go to (8). (2) The Presence Server will send a Command to the remote Presence Server. This request carries the IDENTIFIER of the FETCHER requesting the fetch, the IDENTIFIER of the PRESENTITY, and the Elements. The Remote Presence Server will check the PRESENTITY's Access Control List for the FETCHER, the version of the PRESENCE TUPLE and the Elements required. The access control algorithm can return: - Grant, and a list of Elements granted - Deny, and a list of Elements denied - Request, and a list of Elements that require authorization If there are any Elements with Permission Request, go to step (3) and asynchronously to (5). If not, go to step (7). (3) The Remote Presence Server responds with a Command, with "Request" as the permission and a list of Elements, showing that the PRESENTITY needs to be contacted to grant access for those Elements. The Command will also carry the PRESENCE INFORMATION granted and the list of Denied Elements. (4) The Presence Server sends a Command to the FETCHER, with the same information of (3). (5) When the PRESENTITY is Connected, its Presence Server sends a Command, showing the FETCHER that wishes to retrieve the PRESENCE INFORMATION, together with the Elements it wants to fetch and require authorization. (6) The PRESENTITY responds with a Command, either Granting or Denying the request for each Element. (7) The Remote Presence Server sends a Command to the Presence Server with the PRESENCE INFORMATION granted and the list of Denied Elements. (8) The Presence Server sends the Command to the FETCHER. The Command will carry the PRESENCE INFORMATION granted and the list of Denied and Request Elements (if applicable). 10.3.4. Access Control List Management 10.3.4.1. Update Access Control List The Access Control List is the medium through which the PRINCIPAL grants or denies access to its PRESENTITY INFORMATION. The Update Access Control List Operation is designed to manage that list. The list consists of Access Control rules. There are three possible functions to perform on this list: Add, Remove or Update a rule. In the case of Add, the rule MUST NOT conflict with any rule already in the list. For Update and Delete, there MUST be a rule with the same WATCHER, Element (address type or specific communication address) and version. The command exchange for this operation is: (1) The USER AGENT sends an command to the Presence Server, with the required Function, and the attributes of the row it needs to Add, Remove or Update. For Add and Update, the WATCHER, the Element, the version and the Permission need to be specified; for Remove the Permission may be omitted. (2) The Presence Server answers with if successful, otherwise. The possible Error Codes are: - Inexistent Rule (for Update or Delete) - Duplicate Rule (for Add) (3) If the rule Denies the Subscription of a WATCHER to an Element it is currently subscribed to, (3.1) If the WATCHER is not handled by the PRESENTITY's Presence Server, (3.1.1) the Presence Server sends a to the Presence Server of the WATCHER, with the WATCHER IDENTIFIER and the Element of the revoked subscription (3.1.2) The Presence Server of the WATCHER removes the subscription and sends an to the Presence Server of the PRESENTITY if it was successful, or a otherwise. The possible error codes are: - Inexistent Subscription (3.1.3) Asynchronously, when the WATCHER is Connected, the Presence Server of the WATCHER sends a command to the WATCHER with the Element of the revoked subscription (3.2) If the WATCHER is handled by the PRESENTITY's Presence Server, (3.2.1) Asynchronously, when the WATCHER is Connected, the Presence Server sends a Command to the WATCHER with the Element of the revoked subscription 10.3.4.2. Get Access Control List The Get Access Control List Operation lets the USER AGENT retrieve information about the rules it has specified in its Access Control list. Since the list of Access Control that a PRESENTITY may have specified could be large, the Operation allows the USER AGENT to specify the rules it is interested in. The Command Exchange is: (1) The USER AGENT sends a Command to the Presence Server. Within the Command it can specify: - WATCHER: The specific WATCHER or group of WATCHERS in a domain. In case no value is applied then the attribute is assumed to have a value of "*" which indicates All WATCHERS. - PRESENCE TUPLE: The specific communication address, or a type of communication address. In case no value is specified then the attribute is assumed to have a value of "*" which indicates all communication addresses of all types. - Version: The specific version of a PRESENCE TUPLE. In case no value is specified then the attribute is assumed to have a value of "*" which indicates all versions. - Permission: The specific permission of a PRESENCE TUPLE. Values can be "Grant", "Deny" or "Request". In case no value is specified then the attribute is assumed to have a value of "*" which indicates all permissions. (2) The Presence Server answers with an Command, with all the rows matching the request. For example a Command with: - WATCHER: * - PRESENCE TUPLE: im@flo@networkprojects.com - Version: * - Permission: "Grant" Will return all the WATCHERS (individual and group of WATCHERS - domains) that are allowed to have access ("GRANT") to all the versions ("*") of the PRESENCE TUPLE specified by the communication address: im@im@flo@networkprojects.com. 10.3.5. WATCHER Information Management 10.3.5.1. Get Watchers This Operation lets the PRESENTITY retrieve information about its WATCHERS. Since in some cases the list of WATCHERS for a PRESENTITY may be large, the Operation allows the USER AGENT to specify exactly what it is interested in. The Command exchange in this case is: (1) USER AGENT sends a Command to the Presence Server. Within this command it may specify - the Type of WATCHER: SUBSCRIBER or FETCHER - WATCHER: the specific WATCHER or a domain. In the case of domain, the Operation will look for all the WATCHERS in the specified domain. - the Watch Date Begin: the beginning date when the FETCH was performed, or the SUBSCRIPTION placed - the Watch Date End: the last date when the FETCH was performed, or the SUBSCRIPTION placed - the Maximum Amount of Results to return (2) The Presence Server responds with the Command with the information requested 10.4. Instant Messaging Operations This section details the specific Operations that Instant Messaging Servers and USER AGENTS MUST support. With respect to user Connection, they are performed the same way as in the PRESENCE SERVICE, thus we will not repeat them. 10.4.1. Opening and Closing the Instant Inbox Once connected, for a USER AGENT to start receiving the Instant Messages for an INSTANT MESSAGING INBOX it needs to open it. To stop receiving messages, it needs to Close it. 10.4.1.1. Open Inbox The Command exchange for this operation is: (1) The USER AGENT sends an Command to the IM Server No is needed, since the authentication is performed in the Connect Operation. 10.4.1.2. Close Inbox The Command exchange for Close Inbox operation is: (1) The USER AGENT sends an Command to the Instant Messaging Server No is needed. 10.4.2. Sending and Receiving Messages 10.4.2.1. Send Message The sending of messages is synchronous. That implies that if the sender receives an , then the message has successfully reached final destination. The command exchange for this Operation is: (1) A USER AGENT sends a Command to its IM Server (2) The IM Server resolves the RECEIVER IDENTIFIER If the RECEIVER is not local to the IM Server then go to (8) Else If the IDENTIFIER could not be resolved the IM Server sends a Command to the SENDER, with the Error Code: - Domain Unknown (3) The IM Server checks for existence of the RECEIVER's INSTANT INBOX ADDRESS, its Access Control List, and if the INSTANT INBOX is OPEN. If the INSTANT INBOX ADDRESS exists, the SENDER has permission to send messages to it and the INBOX is OPEN , go to (5) (4) The IM Server replies with a to the USER AGENT of the SENDER with the Error Code: - Permission Denied - Inbox Unknown - Destination Unreachable Stop. (5) The RECEIVER's IM Server sends a Command to the USER AGENT of the RECEIVER (6) The USER AGENT of the RECEIVER sends an command to the IM Server if the message was successfully received. The USER AGENT MAY also send a message with Error Code: - Destination Unreachable for the cases where the RECEIVER does not want to communicate with the SENDER at that particular time. This is important not to reveal PRESENCE INFORMATION when not wanted. (7) The IM Server sends an or a Command to the SENDER's USER AGENT if the or the Command from (6) was received in a timely fashion. If not it sends a command with the Error Code: - Destination Unreachable Stop. (8) The SENDER's IM Server sends a Command to the RECEIVER's IM Server (9) The RECEIVER IM Server checks for existence of the RECEIVER's INSTANT INBOX ADDRESS, its Access Control List, and if the INSTANT INBOX is OPEN. If the INSTANT INBOX ADDRESS exists, the SENDER has permission to send messages to it and the INBOX is OPEN , go to (12) (10) The RECEIVER's IM Server replies with a to the SENDER's IM Server with the Error Code: - Permission Denied - Inbox Unknown - Destination Unreachable (11) The IM Server sends a Command to the SENDER's USER AGENT with the Error Code received from (10). Stop. (12) The RECEIVER's IM Server sends a Command to the USER AGENT of the RECEIVER (13) The USER AGENT of the RECEIVER sends an command to the RECEIVER's IM Server if the message was successfully received. The USER AGENT MAY also send a message with Error Code: - Destination Unreachable for the cases where the RECEIVER does not want to communicate with the SENDER at that particular time. This is important not to reveal PRESENCE INFORMATION when not wanted. (14) The RECEIVER's IM Server sends an or a Command to the SENDER's IM Server if the or the Command from (13) was received in a timely fashion. If not it sends a command with the Error Code: - Destination Unreachable (15) The SENDER IM Server sends an or a Command to the SENDER's USER AGENT if the or the Command from (14) was received in a timely fashion. If not it sends a command with the Error Code: - Destination Unreachable Stop. 10.4.3. Authorization Management 10.4.3.1. Authorization Request This Operation is used by USER AGENTS to request ability to send messages to an INSTANT INBOX. If the Permission for a PRINCIPAL to an INSTANT INBOX is Request, then this Operation is designed to allow the INSTANT INBOX owner to change that to either Grant or Deny. The message exchange sequence is: (1) The USER AGENT of the SENDER sends a Command to its IM Server. (2) The IM Server verifies if the INSTANT INBOX the request is targeted to is local. If the INSTANT INBOX is not local, go to (8) If the IDENTIFIER for the INSTANT INBOX could not be resolved to an IM Server address, the IM Server sends a command to the USER AGENT of the SENDER with the Error Code: - Unreachable Domain. (3) The IM Server checks the Access Control List of the INSTANT INBOX. If the Permission for the SENDER is: - Grant, reply with an with Grant as Permission - Deny, reply with an with Deny as Permission - Request, go to (4) (4) The IM Server sends an command to the USER AGENT of the SENDER (5) Asynchronously, when the owner of the INSTANT INBOX is Connected, the IM Server sends a Command to the owner, specifying the SENER's IDENTIFIER. (6) The USER AGENT of the owner of the INSTANT INBOX responds with a Command and Permission Grant or Deny. (7) The IM Server forwards the Command to the USER AGENT of the SENDER. Stop. (8) The IM Server of the SENDER sends the Command to the IM Server of the INSTANT INBOX. (9) The IM Server of the INSTANT INBOX checks the Access Control List of the INSTANT INBOX. If the Permission for the SENDER is: - Grant, reply with an with Grant as permission in (10) - Deny, reply with a with Deny as permission in (10) - Request, go to (12) (10) The IM Server of the INSTANT INBOX sends the reply to the IM Server of the SENDER (11) The IM Server of the SENDER forwards the to the USER AGENT of the SENDER Stop. (12) The IM Server of the INSTANT INBOX sends an command to the IM Server of the SENDER. (13) The IM Server sends an command to the USER AGENT of the SENDER. (14) Asynchronously, when the owner of the INSTANT INBOX is Connected, its IM Server sends a Command to the owner, specifying the SENDER's IDENTIFIER. (15) The USER AGENT of the owner of the INSTANT INBOX responds with a Command and Permission Grant or Deny. (16) The INSTANT INBOX's IM Server forwards the Command to the IM Server of the SENDER. (17) The IM Server of the SENDER forwards the Command to the USER AGENT of the SENDER. Stop. 10.4.4. Access Control List Management 10.4.4.1. Update Access Control List The Update Access Control List Operation is designed to manage the Access Control List. There are three possible functions to perform on the list: Add, Remove or Update a rule. In the case of Add, the rule MUST NOT conflict with any rule already in the list. For Update and Delete, there MUST be a rule with the same PRINCIPAL. The command exchange for this operation is: (1) The USER AGENT sends an command to the IM Server, with the required Function, and the attributes of the row it needs to Add, Remove or Update. For Add and Update the attributes necessary are PRINCIPAL and Permission, while for Remove, only PRINCIPAL is needed. (2) The Presence Server answers with if successful, otherwise. The possible Error Codes are: - Inexistent Rule (for Update or Delete) - Duplicate Rule (for Add) 10.4.4.2. Get Access Control List The Get Access Control List Operation lets the USER AGENT retrieve information about the rules it has specified in its Access Control List. Since the list of Access Control that a PRESENTITY may have specified could be large, the Operation allows the USER AGENT to specify the rules it is interested in. The Command Exchange is: (1) The USER AGENT sends a Command to the IM Server. Within the Command it can specify: - PRINCIPAL: The specific PRINCIPAL or group of PRINCIPALS in a domain. In case no value is specified then the attribute is assumed to have a value of "*" which indicates All PRINCIPALS. - Permission: The specific permission for access to an INSTANT INBOX. Values can be "Grant", "Deny" or "Request". In case no value is specified then the attribute is assumed to have a value of "*" which indicates all permissions. (2) The IM Server answers with an Command, with all the rows matching the request. Appendix A: Document Type Definition and Valid Commands This appendix shows the XML DTDs both for Presence and Instant Messaging. A.1. Presence Service Command DTD A.2. Instant Messaging Service Command DTD Appendix B: Error Codes Common: - Domain Unknown - Destination Unreachable - Authentication Failed - Inexistent Rule - Duplicate Rule Presence: - Presentity Unknown - Inexistent Subscription Instant Messaging: - Permission Denied - Inbox Unknown Appendix C: References [RFC 822] David H. Crocker, "Standard for the format of ARPA Internet text messages", RFC 822, University of Delaware, August 1982. [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, Harvard University, March 1997. [RFC 2778] M. Day, J. Rosenberg, "A Model for Presence and Instant Messaging". draft-ietf-impp-model-03.txt. Internet Draft, work in progress. Lotus; Bell Labs. June 1999. [RFC 2779] M. Day, S. Aggarawal, G. Mohr, J. Vincent, "Instant Messaging / Presence Protocol Requirements." draft-ietf-impp-reqts- 03.txt. Internet Draft, work in progress. Lotus; Microsoft; Activerse; Arepa. June, 1999. [WTLS] WAP Forum, Wireless Transaction Protocol Specification, 11.6.1999 < http://www.wapforum.org/> [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, Standards Track, Certicom, January 1999. [XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup Language (XML) 1.0." W3C Recommendation REC-xml-19980210, February 1998. Appendix D: Authors' Addresses Florencio Mazzoldi flo@networkprojects.com Network Projects Inc. 4516 Henry St., Suite 113 Pittsburgh, PA 15213 Telephone: (412) 681 6950 Athanassios Diacakis thanos@networkprojects.com Network Projects Inc. 4516 Henry St., Suite 113 Pittsburgh, PA 15213 Telephone: (412) 681 6950 Acknowledgments Many thanks to Yannis Pavlidis for his valuable contributions to this document.