Rob Osbornesonu Aggarwallisa Lippertpeter Beebeemartin CalSynleon WongMicrosoft Corporation 2000 Abstract: This document details the RVP protocol and its related scenarios, and is designed to provide references to those third-party developers who need to interact with Microsoft Exchange Instant Messaging. table of Contents
Summary Overview Protocol Protocol Method Authentication Header
New RVP header return code XML document type Definition MIME payload reference
Summary Exchange Instant Messaging (IM) has become a very popular new communication means on the Internet. The power comes from the following user needs: Users want to immediately know if another user is online, when another user is notified, or "Real Time" Send a message. These are special circumstances in the main issues involved on the Internet. According to the design, the RVP protocol is used to transmit notifications and messages on a set of loosely coupled (combined) servers, and can meet the needs of the user, transmit notifications in a safe, reliable and retractable manner. RVP includes a client-server and server-server interaction. The upcoming Microsoft® Exchange 2000 Server includes instant messaging services based on RVP wired protocol. This document describes the RVP protocol and its related scenarios, and is designed to provide references to third-party developers that need to interact with Microsoft Exchange Instant Messaging. For further information, these developers can use Exchange Instant Messaging SDK, where the RVP protocol elements have an in-depth description. Any comments or questions should be sent to the author. The RVP protocol is related to the work made by Internet Engineering Task Force Instant Messaging and Presence Protocol Working Group, IMPP. RVP does not intend to compete with IMPP, but by providing an existing implementation method to further facilitate the design process.
Overview According to the design, RVP protocols are used to establish subscriptions between tissue and a set of loosely coupled (combined) organizations and transmit notifications and messages. These tissues can be largely scalable multi-server operation mode, or a small single server operation mode. RVP is a strict extension of HTTP / 1.1. Because RVP uses extended HTTP, you can use existing flexible and excellent technologies such as firewall support and proxy. In addition, the requirements for basic authentication and redirection have been resolved in HTTP.
Profile Introduction RVP-specific information is typically transmitted with new methods, or by specifying RVP namespaces in data in the XML format of the HTTP protocol element. This uses XML so that the RVP server can coexist with the HTTP server. XML is used to provide flexibility and scalability. Arcons RVP enables WATCHERS (Observers) to get Presence Information (existing information) and Presentities, and send Instant Messages to Instant Inbox (instant inbox) in current domains or different domains. In order to do this, Exchange 2000 Server uses the following architecture. For the definition of these uppercase terms, see the article listed in the Reference section: [Model] and [IMPP-REQTS]. Figure 1. The architecture of Exchange 2000 Server is composed of a Presentity, a Watcher, and / or an Instant Inbox. The router is used as the main contact point of all entities, and is used to determine which local server is responsible for a particular client. The router can redirect requests or requests. The local server is responsible for maintaining the current Presence Information for any presentity to which it is specified, and is responsible for any Notification (notification) that changes the currentity current online status to any Subscriber (subscriber). Any Instant Message for Presentity is initially sent to the appropriate local server. The client is used simultaneously as Presentity and Instant Inbox of a particular PrincipalL (main body). The client also controls any subscription requests for PRINCIPAL possible. General interactions For a client to find a corresponding server (such as its presentity update presence information, or send instant message to instant inbox), it must first find the domain's domain name server (DNS) SRV record. The domain may be a domain that contains the presentity, or a domain that contains another Presentity. Find the SRV record will return the host name responsible for the server in this domain. If the SRV record in this domain is not available, the client will find DNS A records for the IM server. Then, the client is connected to the domain server, as if it is the target local server, and send the request to the domain server. If this server is a local server, it will process the request. However, if this server is a router, it either a proxy request, either use the HTTP to notify the client to connect to a specific local server. The client can quickly cache the request for the target local server for a period of time to increase the speed of subsequent requests. This interaction between servers is ready for a very flexible organizational topology. The client can find Presence Information and send Instant Messages between the domain. Each organization can create their own topologies based on their needs. For example, a small organization that only has hundreds of clients can use a server to act as a router / local server. A large organization with hundreds of clients can use load balancing and directory search to control access to their multiple routers and local servers. Addressing addressing is done by using the URL. These URL consist of a node hierarchy, each node represents an entity.
The entity can be a combination of Presentity, Watcher, Instant Inbox, or all three. This hierarchy can be organized to combine different entities. For example, you can combine all personnel Principal, as shown below: http://im.somain.com/instmsg/aliases/aaronc http://im.somain.com/instmsg/aliases/Sherrih Another example is The stock information is combined, as follows: http://im.somain.com/information/stock/companya http://im.somain.com/information/stock/companyb is like, you can use the printer or mobile phone The device is combined, as follows: http://im.somain.com/devices/printers/floor1prn http://im.somain.com/devices/cellphones/555-1234 URL has two types: logic URL And physics URL. Logic URL is the default type that determines the domain where the node is located. For example, an email address like beverlyj@domain1.com can be mapped to a logical URL http://im.domain1.com/instmsg/aliases/beverlyj. The physical URL can be the same as the logic URL, or which server is responsible for additional information for the entity. Use physical URLs when the router is reactive to a request for a particular entity. For example, if the email address garrettv@domain2.com is in a domain with a router and several local servers, you can redirect any request to the router to the physical url http://imhome1.domain2.com/instmsg /local/im.domain2.com/instmsg/aliases/garrettv. This physical URL is then used to access nodes located at the local server imain1.domain2.com. Authentication entities can authenticate their local servers, but do not require this. Each request can include user credentials, using the HTTP sentence method to verify the identity of the entity to the actual processing request. For more information, see the part titled authentication. When receiving a request for modifying information, the server that processes the request must verify the identity and check any access control list (ACL) item, which may prevent the completion of the request. For more information, see the part titled ACL. RVP provides a return code in the HTTP format to indicate insufficient access. Example RVP protocol has a variety of practical purposes. However, the examples in this document are related to instant messaging and existence because these examples are recognized by this technology. The RVP protocol can be used for such applications, they need to subscribe, and provide when the events occur, such as the execution of the stock order, and the completion of a process is exhausted.
Protocol method RVP protocol supports many different protocol methods: Subscribe, Unsubscribe, Subscriptions, PropFind, Proppatch, Notify, ACLs, and other methods. The Subscribe Subscribe method is taken from the General Event Notification Architecture (GENA) library, which has established a subscription to a resource. Watcher can receive notifications for the notification of this resource or change in this resource property. For example, a RVP Watcher can issue a Subscribe request to receive the online state of Principals on the contact list of Presentity. This Watcher is notified when these Principals's online status changes. Subscribe to the ID Presence Service (existing service) must return a subscription-id header for each successful subscription. This header contains a unique number of subscriptions and can be referenced by Presence Service and Watcher in future interactions involving subscriptions. Rent-rented subscriptions can be static (permanent, unless explicitly deleted by UNSUBSCRIBE [Undo Subscription]) or rented (temporary). Because Exchange 2000 Server does not accept static subscriptions, it will return an error response. For rent subscriptions, no explicit updated subscriptions will expire, thus keep the subscription "related" status of the resource. For example, a Watcher can subscribe to a day time for Presentity. If the Watcher remains offline after establishing this subscription, the subscription will expire, and Presentity's Presence Service will not overhead for a unwanted subscription. The Subscription-Lifetime header in the Subscribe request for Presence Service indicates a living period (in seconds) of a rental subscription. If the Presence Service responds to the rental subscription request, the subscription will expire after this time interval (to manage the load, the Resence Service can select a differently requested survival). The Subscription-Lifetime header in response indicates that subscription is permanent. To refresh the rental subscription, Watcher is published in the new Subscribe request by using the subscription-id and subscription-lifetime headers. Notification Types Any RVP node can act as a notification receiver - that is, the target of the notification. For example, when a RVP Presentity is logged in, any notification can be sent to the principal's URL (such as http://im.example.com/instmsg/aliases/deriks) by the RVP entity (such as RVP Presence Service or RVP Principals). Subscribe can be made on the notification receiver. A group node (such as http://im.example.com/groups/recycling) can act as a notification receiver. Then, the group can subscribe to this node. The notification sent to the receiver node is passed to the subscriber of the receiver. The RVP entity may also also need notifications for other node properties.
