Rob Osborne Sonu Aggarwal Leon Wong Peter Beebee Martin Calsyn Lisa Lippert Microsoft Corporation RVP: A Presence and Instant Messaging Protocol 1. Abstract Instant Messaging has recently emerged as a new and highly popular medium of communication over the Internet, driven by the desire of individuals to know instantly whether another individual is online, to be notified when another individual arrives online, and to send messages in ‘real time’. These are all special cases of the more general problem of Internet-wide notification. The RVP protocol, is designed to enable such notifications and messages across a loosely coupled (federated) constellation of servers. RVP is designed to address the need for notification in a secure, reliable and scaleable fashion. RVP encompasses the client-server and server-server interactions. The forthcoming release of Microsoft Exchange 2000 includes an Instant Messaging service, based on the RVP protocol. This draft contains details of the RVP wire protocol, and its associated XML schema. This document is intended as a reference for third party developers who wish to interoperate with Exchange Instant Messaging. Those wishing to interoperate may also use the Exchange Instant Messaging SDK, which abstracts RVP protocol elements for developers, and will be available at http://msdn.microsoft.com/exchange/ starting around Microsoft Exchange 2000 release in the first half of 2000. Any comments or questions should be directed to the authors, see the Author’s Addresses section RVP is related to the work done by the IETF Instant Messaging and Presence Protocol Working group (IMPP). This protocol is not intended to compete with the IMPP effort, but to inform the design process with an existing implementation. This document is an update to draft-calsyn-rvp-01 “A Presence Notification Protocol”, [RVP-CALSYN], that reflects the actual Microsoft Exchange 2000 implementation. The presentation, distribution or other dissemination of the information contained herein by Microsoft is not a license, either expressly or impliedly, to any intellectual property owned or controlled by Microsoft. This document and the information contained herein is provided on an "AS IS" basis and MICROSOFT DISCLAIMS ALL WARRANTIES, EXPRESS Osborne et al 1 RVP OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OFTHE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL MICROSOFT BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY MANNER RELATING TO THIS DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. 2. Contents 1. Abstract ................................................... 1 2. Contents ................................................... 2 3. Overview ................................................... 3 4. Protocol Introduction ...................................... 4 4.1 Architecture .......................................... 4 4.1.1 General Interaction ............................... 5 4.1.2 Addressing ........................................ 5 4.2 Authentication ........................................ 6 4.3 Examples .............................................. 6 5. Protocol Methods ........................................... 7 5.1 SUBSCRIBE ............................................. 7 5.1.1 Subscribtion Ids .................................. 7 5.1.2 Leased subscriptions .............................. 7 5.1.3 Notification types ................................ 8 5.1.4 Notification delivery ............................. 8 5.1.5 Changing/discarding subscriptions ................. 9 5.1.6 Response .......................................... 9 5.1.7 Examples .......................................... 9 5.1.7.1 Login Subscription ........................... 9 5.1.7.2 Property subscription ....................... 10 5.2 UNSUBSCRIBE .......................................... 11 5.2.1 Example .......................................... 11 5.3 SUBSCRIPTIONS ........................................ 11 5.3.1 Example .......................................... 12 5.4 PROPFIND ............................................. 13 5.4.1 Example .......................................... 13 5.5 PROPPATCH ............................................ 14 5.5.1 Example .......................................... 15 5.5.2 Implementation considerations .................... 17 5.6 NOTIFY ............................................... 18 5.6.1 Examples ......................................... 19 5.7 ACL .................................................. 24 5.7.1 Access rights .................................... 24 5.7.2 Principals ....................................... 25 5.7.2.1 Credentials ................................. 25 5.7.2.2 ntlm ........................................ 26 5.7.2.3 digest ...................................... 26 5.7.2.4 assertion ................................... 26 Osborne et al 2 RVP 5.7.2.5 internal .................................... 26 5.7.2.6 any ......................................... 26 5.7.3 Examples ......................................... 27 5.8 Other methods ........................................ 28 6. Authentication ............................................ 29 6.1 NT Lan Manager (NTLM) ................................ 29 6.2 Digest Access Authentication ......................... 29 6.3 Example .............................................. 29 7. Headers ................................................... 30 7.1 Existing DAV/HTTP headers ............................ 30 7.2 RVP headers .......................................... 31 8. Return codes .............................................. 31 9. XML Document Type Definition .............................. 32 9.1 RVP elements ......................................... 33 9.1.1 State ............................................ 33 9.1.2 leased-value ..................................... 33 9.1.3 default-value .................................... 33 9.1.4 value ............................................ 33 9.1.5 online ........................................... 33 9.1.6 offline .......................................... 33 9.1.7 away ............................................. 34 9.1.8 busy ............................................. 34 9.1.9 back-soon . ...................................... 34 9.1.10 on-phone ...................................... 34 9.1.11 at-lunch ...................................... 34 9.1.12 view-id ....................................... 34 9.1.13 principal ..................................... 34 9.1.14 rvp-principal ................................. 34 9.1.15 email ... ..................................... 34 9.1.16 mobile-state .................................. 35 9.1.17 mobile-description ............................ 35 9.1.18 notification .................................. 35 9.1.19 propnotification .............................. 35 9.1.20 message ....................................... 35 9.1.21 notification-from ............................. 35 9.1.22 notification-to ............................... 35 9.1.23 msgbody ....................................... 35 9.1.24 contact ....................................... 36 9.1.25 description ................................... 36 9.1.26 mime-data ..................................... 36 10. MIME Payloads ............................................ 36 10.1 Instant Message ...................................... 36 10.2 Typing Message ....................................... 36 10.3 Application Invites .................................. 37 11. References ............................................... 37 12. Author’s Addresses ....................................... 38 3. Overview RVP is designed to enable subscriptions and notifications within an organization, and across a loosely coupled (federated) constellation of organizations. These organizations may contain large, scalable server farms, or may be small one-server operations. Osborne et al 3 RVP RVP is a strict extension of HTTP/1.1. Being used on HTTP allows RVP to leverage existing flexible and well-known technologies, such as Firewall support, and Proxies. Also the requirements of basic Authentication and Redirection have already been addressed within HTTP. 4. Protocol Introduction RVP-specific information is general transferred in new methods or by specifying the RVP namespace in XML-formatted data within the XML body of an HTTP protocol element. Use of XML in this way allows an RVP server to coexist with an HTTP server. XML is used in order to provide flexibility and extensibility. 4.1 Architecture RVP allows for WATCHERs to obtain PRESENCE INFORMATION, for PRESENTITYs to determine what WATCHERs are obtaining it’s PRESENCE INFORMATION, and send INSTANT MESSAGEs to an INSTANT MESSAGE INBOX within the current or different domain. To accomplish this the architecture within Microsoft Exchange 2000 can be as follows (see [MODEL] and [IMPP-REQTS] for definitions of the capitalized terms): ----------Domain A---------- ----------Domain B---------- | | | | | -------- | | | | |Router| | | | | -------- | | | | | | | | | | | | ---------- ---------- | | ---------- | | | Home | | Home | | | | Home | | | |Server 1| |Server n| | | | Server | | | ---------- ---------- | | ---------- | | | | | | | | | | ---------- ---------- | | |Firewall|--|Firewall| | | ---------- ---------- | | | | | | | | | | ------------ ------------| | ------------ ------------| | | Client 1 | | Client n || | | Client 1 | | Client n || | ------------ ------------| | ------------ ------------| | | | | ---------------------------- ---------------------------- In the above diagram a Client consists of a PRESENTITY, WATCHER, and/or an INSTANT INBOX. The Router is used as the main contact point for all entities, and is used to determine which Home Server is responsible for a certain Client. It is possible for the Router to redirect, or proxy the requests. Osborne et al 4 RVP The Home Server is responsible for maintaining the current PRESENCE INFORMATION for any PRESENTITY’s assigned to it, and for issuing any NOTIFICATIONs of changes to a PRESENTITY’s current online state to any SUBSCRIBERs. Any INSTANT MESSAGEs destined for a PRESENTITY must initially be sent to the appropriate Home Server. The Client is used as both a PRESENTITY, and an INSTANT INBOX for a particular PRINCIPAL. Also the Client controls any SUBSCRIPTIONs that a PRINCIPAL may wish to issue. 4.1.1 General Interaction For a Client to find the appropriate server to carry out actions such as update it’s PRESENTITY’s PRESENCE INFORMATION, or send an INSTANT MESSAGE to an INSTANT INBOX, it must first carry out a DNS SRV record lookup for the domain. The domain could be the domain containing the PRESENTITY, or that of another PRESENTITY. The SRV record lookup returns the hostname of the server responsible for that domain. If the domain SRV record is not available, then the DNS A record for the IM server is looked up. The Client then connects to this server as if it was the destination Home Server, sending it the request. If the server were a Home Server, it would handle the request. If the server was a Router, it would either proxy the request, or use HTTP redirection to notify the Client to connect to a specific Home Server. To improve speed of later requests, the Client can cache the destination server for some time. This interaction allows for federation amongst very flexible organizational topologies. A Client is able to find out the PRESENCE INFORMATION, and send INSTANT MESSAGES across domains. Also organizations can create their own topologies based on their requirements. For example a small organization with only a few hundred Clients could only have one server acting as the Router/Home Server. A larger organization with several hundred thousand Clients, can use a combination of load balancing, and directory lookups to control access to it’s multiple Routers and Home Servers. 4.1.2 Addressing Addressing is achieved by the use of URLs. These URLs consists of a hierarchy of nodes, with each node representing an entity. This entity may be a PRESENTITY, WATCHER or INSTANT INBOX, or a combination of all three. This hierarchy can be organized so that different entities are grouped together. For example all human PRINCIPALS could be grouped together as follows: http://im.somedomain.com/instmsg/aliases/roberto http://im.somedomain.com/instmsg/aliases/lorrainec Osborne et al 5 RVP Another example would be to group stock information as follows: http://im.somedomain.com/information/stock/companyA http://im.somedomain.com/information/stock/companyB Also devices such as printers, or cell phones could be grouped as follows: http://im.somedomain.com/devices/printers/floor1prn http://im.somedomain.com/devices/cellphones/555-1234 There are two types of URL, logical and physical. A logical URL is the default that should be used, and determines which domain that node is located. For example, one possible mapping of an email address andyo@domain1.com maps to the logical URL of http://im.domain1.com/instmsg/aliases/andyo. A physical URL may be the same as a logical URL, or it could provide extra information as to which Home Server is responsible for the entity. A physical URL is used when a Router redirects requests for a certain entity. For example, if the email address kevinf@domain2.com is within a domain with a Router and several Home Servers, any requests to the Router would be redirected to the physical URL http://imhome1.domain2.com/instmsg/local/im.domain2.com/instmsg/a liases/kevinf. This physical URL would then be used to access the node at the Home Server imhome1.domain2.com. 4.2 Authentication Users may authenticate to their Home Server, but this is not required. Each request may contain user credentials, using HTTP syntax, in order to authenticate the user to the server that will actually process the request. See section 5.0 Authentication, for more information. Upon receiving a request for the modification of information, the server processing the request must validate the authentication and honor any access control list entries, which might gate the completion of the request. See section 4.7 on the ACL method for more information. Return codes in HTTP style are provided for indicating insufficient access rights. 4.3 Examples Throughout this document, several examples have been given, almost all relate to Instant Messaging and Presence. However this is not the only use to which RVP can be applied, and is only presented, as it is a well-understood application. RVP could be used for many other uses that require subscriptions, and notification of when an event has occurred, such as a stock price Osborne et al 6 RVP reaching a certain value, process completion, and inventory alerts. 5. Protocol Methods 5.1 SUBSCRIBE The SUBSCRIBE method, adopted from General Event Notification Architecture Base [GENA] establishes subscriptions of a WATCHER to a resource; the WATCHER can receive notifications intended for that resource or notifications of property changes on that resource. For example, an RVP WATCHER will SUBSCRIBE to the online status of PRINCIPALs on the PRESENTITY’s contact list; the WATCHER is notified when the online status of these PRINCIPALs changes. 5.1.1 Subscription IDs PRESENCE SERVICEs must return a Subscription-Id header with successful subscriptions. The header contains a number unique to that subscription, and must be referenced in all future interactions involving that subscription, both by the PRESENCE SERVICE and the WATCHER. 5.1.2 Leased subscriptions Subscriptions can be static (permanent, unless explicitly removed by an UNSUBSCRIBE) or leased (temporary). The Microsoft Exchange 2000 implementation does not accept static subscriptions, and will return an error response. Leased subscriptions are used to keep subscriptions on a resource “relevant”: subscriptions that are not explicitly renewed expire. For example, a WATCHER may subscribe to a PRESENTITY’s online status for a period of 1 day; if the WATCHER remains offline for an extended period after establishing this subscription, the subscription expires and the PRESENTITY’s PRESENCE SERVICE does not incur any overhead to maintain an unneeded subscription. The Subscription-Lifetime header in a SUBSCRIBE request to a PRESENCE SERVICE indicates the lifetime for a leased subscription in seconds. If the PRESENCE SERVICE response to a leased subscription request includes a Subscription-Lifetime header then the subscription will expire after this interval of time. (To manage load, a PRESENCE SERVICE may choose a lifetime different from the one requested.) The absence of a Subscription-Lifetime header in the response indicates that the subscription is permanent. To refresh a leased subscription, WATCHERs issue new SUBSCRIBE requests with the Subscription-Id and the Subscription-Lifetime headers. 5.1.3 Notification types Osborne et al 7 RVP Any RVP node can serve as a notification sink: a destination for notifications. For example, when an RVP PRESENTITY logs on, the PRINCIPAL’s URL (e.g. http://im.example.com/instmsg/aliases/stevem”) can be sent arbitrary notifications, by other RVP entities (e.g. RVP PRESENCE SERVICE or PRINCIPALs). Subscriptions can be made on notification sinks: A group node such as http://im.example.com/groups/rec- cycling can act as a notification sink; members of the group would subscribe to this node. Notifications to the sink node are passed along to subscribers of that sink. RVP entities may also wish to be notified of property changes at other nodes. For example, if PRINCIPAL A has PRINCIPAL B on her contact list, A will subscribe to the properties of PRINCIPAL B (which includes PRINCIPAL B’s “online-status” property), so that A can be notified when the “online-status” property changes. The Notification-Type header in a SUBSCRIBE request lets the requester specify whether it is interested in subscribing to property changes at the destination node (if the header value is update/propchange) or in general notifications at the destination node sink (if the header value is pragma/notify). 5.1.4 Notification delivery To request asynchronous callbacks, a Call-Back header is provided with the URL for the resource that will receive the callback. The callback URL may be either the PRINCIPAL’s Public URL, or one hosted by the WATCHER itself. The Public URL is used to allow notifications to be routed through the PRESENCE SERVICE. The callback hosted by the WATCHER itself is used to allow notifications to be routed from the PRESENCE SERVICE to the WATCHER. For example, the WATCHER on machine stevem1.example.com may SUBSCRIBE to http://im.example.com/instmsg/aliases/stevem and provide a Call-Back that looks like http://198.176.154.132:1234. The WATCHER may also SUBSCRIBE to http://im.acme.com/instmsg/aliases/bruceb and provide a Call-Back of http://im.example.com/instmsg/aliases/stevem. The difference in the form of the Call-Back (i.e. IP address vs URL) is to ensure that any requests from outside the domain, do not attempt to connect to the client directly. Any changes to Bruce’s properties will result in a notification being sent to http://im.example.com/instmsg/aliases/stevem. Also any Instant Messages will be sent to this same node. When im.example.com receives any notifications for this node, it will route them to the Call-Back of http:// 198.176.154.132:1234. This ensures that only the PRESENTITY’s Home Server is aware of it’s IP address, and all notifications are routed through it. Osborne et al 8 RVP Such notifications are delivered through NOTIFY requests. (In the above example, the PRESENCE SERVICE makes a NOTIFY request to the WATCHER.) 5.1.5 Changing/discarding subscriptions To change a subscription’s characteristics other than it’s lifetime, a WATCHER must UNSUBSCRIBE then SUBSCRIBE with the new settings. RVP servers must not discard subscriptions that it determines are duplicates of each other; such subscriptions are independently managed by their Subscription-Id. 5.1.6 Response In response to a successful SUBSCRIBE for a Notification-Type of pragma/notify, the PRESENCE SERVICE will return a response code of 200 – Successful. The response headers contain details of the successful subscription, including the Subscription-Id and the Subscription-Lifetime which may be different than that requested. In response to a successful SUBSCRIBE for a Notification-Type of update/propchange, the PRESENCE SERVICE will return a response code of 207 – Multi Status. The response headers will contain the details of the successful subscription, as described above. There may also be an XML body containing the current values for the properties requested. When refreshing a lease, a successful response from the PRESENCE SERVICE will return a response code of 200 – Successful. Again, this will contain details of the Subscription-Id and the Subscription-Lifetime which may be different than that requested. 5.1.7 Examples 5.1.7.1 Login Subscription When a PRESENTITY logs on, it may create a “local node” and an associated URL. For example, suppose a PRINCIPAL http://im.acme.com/instmsg/aliases/bruceb runs a PRESENTITY on machine 198.176.154.132. When the PRESENTITY logs on, it creates a local node http://198.176.154.132:1234. Assuming the PRINCIPAL is hosted on server “im.acme.com”, the PRESENTITY would set up a “login subscription” to the node http://im.acme.com/instmsg/aliases/bruceb , specifying the local node as the callback. >> Request SUBSCRIBE /instmsg/aliases/bruceb HTTP/1.1 Subscription-Lifetime: 14400 Notification-Type: pragma/notify Call-Back: http://198.176.154.132:1234 Osborne et al 9 RVP RVP-Notifications-Version: 1.0 Host: imhome1.acme.com Content-Length: 0 RVP-From-Principal: http://im.acme.com/instmsg/aliases/bruceb >> Response HTTP/1.1 200 Successful Subscription-Id: 98210 Subscription-Lifetime: 14400 RVP-Notifications-Version: 1.0 5.1.7.2 Property Subscription In this example, the PRINCIPAL in the above example makes a permanent subscription to the properties of node http://im.example.com/instmsg/aliases/stevem. In this example the Call-back is the logical URL of the subscriber – bruceb. This allows for greater protection, but does mean that bruceb has to have SUBSCRIBEd to his logical node on im.acme.com to have the property updates forwarded. >> Request SUBSCRIBE http://im.example.com/instmsg/aliases/stevem HTTP/1.1 Subscription-Lifetime: 14400 Notification-Type: update/propchange Call-Back: http://im.acme.com/instmsg/aliases/bruceb RVP-Notifications-Version: 1.0 Host: im.example.com Content-Length: 0 RVP-From-Principal: http://im.acme.com/instmsg/aliases/bruceb >> Response HTTP/1.1 207 Multi-Status Subscription-Id: 79 Subscription-Lifetime: 14400 Content-Type: text/xml Content-Length: XXXX RVP-Notifications-Version: 1.0 http://im.example.com/instmsg/aliases/stevem Steve stevem@example.com Osborne et al 10 RVP 0 HTTP/1.1.200.Successful 5.2 UNSUBSCRIBE The UNSUBSCRIBE method, adopted from [GENA], is used to remove subscriptions established using SUBSCRIBE requests. The Subscription-Id is used to specify uniquely which subscription should be cancelled. It is up to the PRESENCE SERVICE implementation to decide who can cancel subscriptions. 5.2.1 Example A WATCHER decides that they no longer to wish receive updates for a stock. >> Request UNSUBSCRIBE /stock/companyA HTTP/1.1 Host: im.stockquotes.com RVP-Notifications-Version: 1.0 RVP-From-Principal: http://im.acme.com/instmsg/aliases/bruceb Subscription-Id: 1234 Content-Length: 0 >> Response HTTP/1.1 200 Successful RVP-Notifications-Version: 1.0 5.3 SUBSCRIPTIONS The SUBSCRIPTIONS method, a new RVP method, fetches a list of active subscriptions on a node at a server. Possible uses include viewing membership of distribution lists or RVP PRESENTITYs viewing the list of WATCHERs watching their online status. The request contains the Notification-Type of the subscriptions (update/propchange or pragma/notify) that the requester is interested in (this was the Notification-Type sent in the corresponding SUBSCRIBE calls to establish each subscription). The reply contains a list of subscriptions in the XML body. Each subscription contains the Subscription-Id of the subscription, the subscriber URL (if available), and the time remaining, in seconds, for that subscription. Osborne et al 11 RVP SUBSCRIPTIONS use the new RVP XML elements “subscriptions”, “subscription”, “subscription-id”, “timeout”, and “rvp- principal”. 5.3.1 Example >>Request SUBSCRIPTIONS /lists/sales-event HTTP/1.1 Host: im.example.com RVP-Notifications-Version: 1.0 Notification-Type: update/propchange RVP-From-Principal: http://im.acme.com/instmsg/aliases/bruceb >>Response HTTP/1.1 200 Successful RVP-Notifications-Version: 1.0 Content-Type: text/xml Content-Length: XXXX 456 http://im.example.com/instmsg/aliases/bruceb http://im.example.com/instmsg/aliase s/bruceb 4789 http://im.example.com/instmsg/aliases/stevem 6656 http://im.example.com/instmsg/aliase s/stevem 8752 Osborne et al 12 RVP 5.4 PROPFIND The PROPFIND DAV method is used to get a node’s properties. Properties contain tuples of PRESENCE INFORMATION, such as the online status, or the display name of the represented PRINCIPAL. For RVP, the PROPFIND method is used to get other PRINCIPAL’s online status from their respective home servers. This method may also be used to fetch other properties an RVP implementation may maintain, such as persistent contact lists stored on servers. The PROPFIND method retrieves properties defined on the requested URL. A PRESENTITY submits a propfind XML element in the body of the request method describing what information is being requested. It is possible to request particular property values, all property values, or a list of the names of the resource’s properties. A PRESENTITY must submit a body with at least one property. If there is an error retrieving a property then a proper error result MUST be included in the response. A request to retrieve the value of a property that does not exist is an error and MUST be noted, if the response uses a multistatus XML element, with a response XML element that contains a 404 Not Found status value. Each response XML element MUST contain an href XML element that identifies the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a resource with internal members are returned as a flat list whose order of entries is not significant. While DAV allows PROPFINDs at depths 0, 1, or “infinity”, with “infinity” being the default, RVP requires a depth header of 0. This is due to difficulties in supporting this for namespaces implemented in a distributed fashion. If the Depth header is not present or depth argument is not 0, RVP PRESENCE SERVICEs return status code 412 (Precondition Failed). 5.4.1 Example The following example retrieves the displayname property of an RVP PRESENTITY. >>Request PROPFIND /instmsg/aliases/stevem HTTP/1.1 Host: im.example.com RVP-Notifications-Version: 1.0 RVP-From-Principal: http://im.example.com/instmsg/aliases/stevem Depth: 0 Content-type: text/xml Content-Length: XXXX Osborne et al 13 RVP >>Response HTTP/1.1 207 Multi-Status Content-Type: text/xml Content-Length: XXXX RVP-Notifications-Version: 1.0 http://im.example.com/instmsg/aliases/stevem Steve Morgan HTTP/1.1 200 OK 5.5 PROPPATCH The PROPPATCH DAV method is used to set a node’s properties. For RVP, this method can be used to set a PRINCIPAL’s online status on a PRESENCE SERVICE or to set other properties maintained by an RVP implementation. For example, when a PRESENTITY “logs on”, the PRESENTITY will issue a PROPPATCH to the PRESENTITY’s home server to set the “online-status” property to “online”. RVP introduces the notion of “leased properties”. Leased property values automatically reset to a default value after a timeout period. They can be used to implement buddy list online status – a PRESENTITY’s online status can reset itself to the offline state unless refreshed. This is useful for scenarios involving client crashes, network failures, etc. that necessitate resetting a PRESENTITY’s status to offline. All RVP properties can have leased values, though RVP implementations may disallow leasing the values of particular properties. Osborne et al 14 RVP PRESENTITYs get and set leased values in the exact same fashion as they do regular DAV properties - it is up to the PRESENCE SERVICE to recognize and interpret leased values and enforce their behavior An RVP PRESENCE SERVICE may decline to set a property value if the requested timeout is not permitted by its admin policy. As there may be multiple PRESENTITYs setting properties for a certain node (i.e. User logs in from multiple machines), the XML schema allows for a view identifier element to be specified in the PROPPATCH requests and responses. This allows state changes to be replicated amongst all PRESENTITYs, and certain states to be specific to a PRESENTITY. For example if a PRINCIPAL has multiple PRESENTITYs logged in, any state changes to be “busy”, or “out to lunch”, will result in all PRESENTITYs being notified of this status change. However if a certain PRESENTITY became offline or idle, then no other PRESENTITYs would be notified of this status change, and the PRINCIPAL would remain online at a different PRESENTITY. When a PROPPATCH request does not contain a view identifier, a successful response will include one. This identifier is unique to that leased property, and any subsequent PROPPATCH requests that specify the view identifier. If all leased properties, with that view identifier, expire then it is no longer valid and should not be used. 5.5.1 Example This example sets the “online-status” value of an RVP PRESENTITY to “online”, for an interval of 1 hour. Unless the property is subsequently reset by the PRESENTITY, the PRESENCE SERVICE will revert the “online” value to “offline” after 1 hour. >>Request: PROPPATCH /instmsg/aliases/stevem HTTP/1.1 Host: im.example.com RVP-Notifications-Version: 1.0 RVP-From-Principal: http://im.example.com/instmsg/aliases/stevem Content-Type: text/xml Content-Length: XXXX Osborne et al 15 RVP 3600 >>Response: HTTP/1.1 207 Multi-Status RVP-Notifications-Version: 1.0 Content-Type: text/xml Content-Length: XXXX http://im.example.com/instmsg/aliases/stevem 3600 3577 HTTP/1.1 200 OK 5.5.2 Implementation considerations An RVP PRESENTITY will use the PROPPATCH method, with leased values, to keep its online-status property “online”. The PRESENTITY will use some timeout value, t, which will make the Osborne et al 16 RVP PRESENCE SERVICE revert the online-status property to “offline” after t has elapsed. If the PRINCIPAL continues to be “logged in” at the PRESENTITY, the PRESENTITY should refresh the online-status property by issuing another PROPPATCH before t has expired, and getting a new lease for interval t on the property. Therefore, if t=30 minutes, the PRESENTITY should issue another PROPPATCH at ~29 minutes. Otherwise, if the PRESENTITY issues a PROPPATCH at 30 minutes, there is a chance that the new PROPPATCH will reach the PRESENCE SERVICE just after the first lease expires. In this case, any subscribers to the PRINCIPAL’s online status (e.g. all WATCHERs who have this PRINCIPAL on their contact list) would get spurious notifications – one for the PRINCIPAL logging off, and another one just after for the PRINCIPAL logging back on. Several considerations determine the appropriate value of t that should be used. If the PRESENTITY were to OUT OF CONTACT (e.g. the PRESENTITY computer crashes), the PRESENCE SERVICE has no way of knowing that the PRESENTITY has gone down, and the PRINCIPAL’s online-status property would remain online until the lease expires. Thus, t bounds the time interval for which WATCHERs continue to see the PRINCIPAL as “online”, even though the PRINCIPAL is offline. Keeping status “fresh” at WATCHER’s contact lists requires that t be small – ideally close to 0. However, if the PRINCIPAL is logged on, the PRESENTITY must reissue PROPPATCHes at intervals less than t, to maintain online status. Thus, every logged-in PRESENTITY consumes resources at a PRESENCE SERVICE; the PRESENTITY effectively “pings” the PRESENCE SERVICE at intervals less than t. This also generates network traffic, even under “idle” conditions. For a PRESENCE SERVICE with thousands of PRESENTITYs logged on, this load can be considerable. To keep the ping load under control, t should be kept as large as possible without degrading the PRINCIPAL experience. The Microsoft Exchange 2000 Instant Messaging implementation uses an interval of 20 minutes. 5.6 NOTIFY The NOTIFY RVP method, adopted from [GENA], sends asynchronous notifications to an RVP node – a “notification sink”. When a WATCHER A issues a SUBSCRIBE to property changes on another PRINCIPAL B, via a Home Server, WATCHER A receives NOTIFY requests of property changes to PRINCIPAL B. NOTIFYs can also be issued without prior subscriptions being established. For instance, assuming the correct access control permissions, any entity can send a NOTIFY message to a group node such as “http://im.example.com/groups/rec-cycling”; the group node need not SUBSCRIBE to any other node. Osborne et al 17 RVP A “notification” XML element in the request body contains the notification data. Within an intranet, NOTIFY will be commonly used by home servers to send notifications to their INSTANT MESSAGE INBOXs. NOTIFY will also be used by PRESENCE SERVICEs to send online status changes for PRESENTITYs hosted by them to other PRESENCE SERVICES. As the sender of a NOTIFY may require acknowledgement of delivery, the successful response will be issued once delivery has been completed. To determine when the sender of a NOTIFY is satisfied delivery has been completed and an acknowledgement is required, a new header field RVP-Ack-Type exists. This can contain the following information. SingleHop: This indicates the sender only wishes acknowledgement when the initial receiver (e.g. Home server) receives the NOTIFY. DeepOr: This indicates the sender only wishes acknowledgement when one of the final destinations receives the NOTIFY. An example of this use is when a user sends an INSTANT MESSAGE to a principal, or a printer runs out of paper and requires that one of the system administrators are notified. DeepAnd: This indicates the sender only wishes acknowledgement when all of the final destinations receive the NOTIFY. An example of this use is when sending to a group or distribution list, and there are multiple WATCHERs awaiting NOTIFYs. Also in the request, an additional field is the RVP-Hop-Count. This is a 1-based indication how many hops have occurred to produce this request. E.g. Client->Server RVP-Hop-Count = 1 Server->Server RVP-Hop-Count = 2 Server->Client RVP-Hop-Count = 3 NOTIFY uses new RVP XML elements -- “Message”, “propnotification”, “notification-from”, “notification-to”, “contact”, “description”, “msgbody” and “mime-data”. 5.6.1 Examples Sending an Instant Message A PRESENTITY “http://im.example.com/instmsg/aliases/stevem” sends an instant message to an INSTANT MESSAGE INBOX of “http://im.acmewidgets.com/instmsg/aliases/bruceb. >>Request Osborne et al 18 RVP NOTIFY /instmsg/aliases/bruceb HTTP/1.1 Host: im.acmewidgets.com RVP-Notifications-Version: 1.0 RVP-Ack-Type: DeepOr RVP-Hop-Count: 1 RVP-From-Principal: http://im.example.com/instmsg/aliases/stevem Content-Type: text/xml Content-length: XXXX http://im.example.com/instms g/aliases/stevem Steve Morgan http://im.acmewidgets.com/in stmsg/aliases/bruceb bruce >>Response Osborne et al 19 RVP HTTP/1.1 200 Successful RVP-Notifications-Version: 1.0 Sending notification of PRINCIPAL property changes A PRINCIPAL “http://im.example.com/instmsg/aliases/stevem” is on the contact list of “http://im.acmewidgets.com/users/bruceb, and “bruceb” has subscribed to the online status of “stevem”. When “stevem” logs on, a NOTIFY is sent to “bruceb”: >>Request NOTIFY / HTTP/1.1 RVP-Hop-Count: 2 RVP-Notifications-Version: 1.0 Host: 128.1.1.11 Content-Length: XXXX Content-Type: text/xml RVP-From-Principal: im.example.com http://im.example.com/instmsg/a liases/stevem http://im.acmewidgets.com/instm sg/aliases/bruceb Osborne et al 20 RVP >>Response HTTP/1.1 200 Successful RVP-Notifications-Version: 1.0 Notification application: Package tracking Here is another NOTIFY example, but more complex. The application is the package tracker. Shipment data is expressed as XML data structures on the web server. The WATCHER is interested in being notified when the package has been delivered. In addition, “shipment events” notifications are also defined by an XML schema. The total shipment record or “manifest” is set of information which includes a collection of “shipment events”. “Shipment Event” DTD snippet: eventType( “PICKUP” | “HUB_TRANSITION” | “DELIVERY” ) eventTime( #PCDATA) eventDate( #PCDATA) eventComment( #PCDATA) mEvent ( eventType, eventTime, eventDate, eventComment) “manifest” DTD snippet: mTrackNo( #PCDATA) pName (#PCDATA) pAddress(#PCDATA) pPhone(#PCDATA) mShipper ( pName, pAddress, pPhone ) mDestination (pName, pAddress, pPhone ) manifest(mTrackNo, mShipper, mDestination, mEvent+) In this example, the notification schema is mEvent or “shipment event”. The fact that mEvent is a component of “manifest” is convenient, but not necessary. The server will provide the manifest record ( which is the actual content here) along with the event notification. TrackNo: 12345 The package data resides on www.package.com The event that we are delivering is: DELIVER 13:45 PST 03/24/98 Signed for by J Cohen WATCHER opens a connection to www.package.com Osborne et al 21 RVP >>> WATCHER->PRESENCE SERVICE SUBSCRIBE http://www.package.com/shipments/12345/delivery_status/ HTTP/1.1 Host: www.package.com RVP-Notifications-Version: 1.0 Notification-Type: pragma/notify Call-Back: http://shipper.com:5150/ RVP-From-Principal: http://shipper.com/instmsg/aliases/bruceb >>> PRESENCE SERVICE->WATCHER HTTP/1.1 200 Successful RVP-Hop-Count: 1 RVP-Notifications-Version: 1.0 Server: Big_Database/1.0 Subscription-Id: 9A504 (PRESENCE SERVICE closes connection) … time elapses, package is delivered, “J Cohen” signs for it. PRESENCE SERVICE opens a connection to “call-back:” http://shipper.com:5150/ >>> PRESENCE SERVICE->WATCHER NOTIFY / HTTP/1.1 Host: shipper.com:5150 RVP-Notifications-Version: 1.0 RVP-Ack-Type: DeepOr Subscription-Id: 9A504 Content-Type: text/xml Content-Length: xxxx DELIVER 13:45 PST 03/24/98 Signed for by J Cohen 12345 CDNOW 100 any street, anytown, USA Osborne et al 22 RVP 111-555-1212 Josh Cohen 100 any other street, anyother town, USA 999-555-1212 PICKUP 13:45 PST 03/2 0/98 Picked up from CDNOW shipping room HUB_TRANSITION 09:45 PST 03/21/98 Dropped, smashed DELIVER 13:45 PST 03/24/98 Signed for by J Cohen (end of notification data from notification PRESENCE SERVICE to WATCHER) >>> WATCHER->PRESENCE SERVICE HTTP/1.1 200 Successful RVP-Notifications-Version: 1.0 Server: PackageClient/1.0 (WATCHER closes connection) 5.7 ACL This is based on WEBDAV ACL specification [WEBDAV-ACL], and has a few additions to the XML schema. An access control list (ACL) is used to determine who can access, and update information on a Osborne et al 23 RVP node. An example of its use is to restrict the ability for a WATCHER to see if a PRESENTITY is “online”. The namespace for RVP ACL is slightly different than that for WEBDAV-ACL, as several elements are not required, or several new ones have been added. The namespace is http://schemas.microsoft.com/rvp/acl/ 5.7.1 Access rights The elements that define rights that are supported are read, write, readacl, writeacl, and all. The access rights that are not supported are writeowner, delete, createchild and deletechild. The new access right elements have a parent of either allow or deny, and are specified below. Name: send-to Purpose: The send-to right determines who is allowed to send “NOTIFY” methods to a given node. Values: none Name: presence Purpose: To determine who is allowed access to presence information Values: None Name: list Purpose: To determine who is allowed to list properties Values: None Name: receive-from Purpose: To determine who is allowed to receive notifications and subscription notifications Values: None Name: subscriptions Purpose: To determine who is allowed to access the list of subscriptions Values: None Name: subscribe-others Purpose: To determine who is allowed to subscribe to properties and notifications using unrecognized callbacks Values: None 5.7.2 Principals All PRINCIPALs within RVP have a unique identifier, which is their logical URL. To identifier this PRINCIPAL within the ACL, each tag pair must contain one and only Osborne et al 24 RVP one child, and one and only one child. Name: rvp-principal Parent: Purpose: To encapsulate an RVP URL, and to keep it distinct from any other PRINCIPAL representation—whatever that may be. Values: Any valid RVP PRINCIPAL identifier. (Either a PRINCIPAL identifier like “http://im.acme.com/instmsg/bruceb” or an PRESENCE SERVICE identifier like “im.acme.com.”) Null values are not permitted. White space surrounding an RVP PRINCIPAL identifier will be stripped by the PRESENCE SERVICE. The PRESENCE SERVICE will never generate white space in an . It is important to note that there is no form of “Principal inheritance” (i.e. im.example.com is not a superset of http://im.example.com/instmsg/bruceb) If a PRINCIPAL connects using credentials other than those listed as acceptable in the element, either explicitly or implicitly (as part of an element,) the PRINCIPAL should be treated as if the PRINCIPAL wasn’t listed in the ACL at all. If no credentials are specified, or if is null, the ACL manipulation must be rejected with a “400 credentials not specified”. 5.7.2.1 credentials Definition: Parent: Purpose: To uniquely identify the credentials a PRINCIPAL must present. Values: Any set of one or more valid credentials identifiers (currently any combination of “ ” or “”) 5.7.2.2 ntlm Definition: Purpose: To indicate that a PRINCIPAL must satisfy an NTLM challenge from the PRESENCE SERVICE. The PRESENCE SERVICE should not check for the specified PRINCIPAL’s existence when the ACL is set. Values: none 5.7.2.3 digest Definition: Purpose: To indicate that a PRINCIPAL must satisfy a digest challenge from the PRESENCE SERVICE. The PRESENCE Osborne et al 25 RVP SERVICE should not check for the specified PRINCIPAL’s existence when the ACL is set. Values: none 5.7.2.4 assertion Definition: Purpose: To indicate that a PRINCIPAL doesn’t need to present credentials to prove it’s identity. Values: none 5.7.2.5 internal Definition: Purpose: To indicate that a PRINCIPAL must prove its identity via some PRESENCE SERVICE dependent out-of-band mechanism Values: none 5.7.2.6 any Definition: Purpose: To indicate that a PRINCIPAL presenting any valid credentials should be considered to be this PRINCIPAL. Values: none AllAuthPrincipals, a generic aggregate PRINCIPAL which represents all PRINCIPALs who have provided some form of authentication is redundant with the identifier, and is not supported. 5.7.3 Examples When a PRESENTITY starts it needs to obtain the ACLs for the current PRINCIPAL. The following example shows that all WATCHERs are allowed to be notified of the PRINCIPALs presence, and send notifications except for http://im.example.com/instmsg/aliases/steveb. It also shows that the PRINCIPAL known by http://im.acme.com/instmsg/aliases/bruceb is allowed all rights to his own node. >>Request ACL /instmsg/aliases/bruceb HTTP/1.1 RVP-Notifications-Version: 1.0 Host: im.acme.com Content-Length: 0 RVP-From-Principal: http://im.acme.com/instmsg/aliases/bruceb >> Response Osborne et al 26 RVP HTTP/1.1 200 Successful Content-Type: text/xml Content-Length: XXXX RVP-Notifications-Version: 1.0 none http://im.example.com/instmsg/ali ases/steveb/ http://im.acme.com/instmsg/a liases/bruceb Osborne et al 27 RVP 5.8 Other methods The HTTP methods of GET, HEAD, POST, PUT are not supported, and should return 501 – Not Implemented if received. The DAV methods of COPY, MOVE, LOCK, UNLOCK, OPTIONS are also not supported. COPY, and MOVE should return error code 405 – Method not allowed. LOCK, UNLOCK and OPTIONS should return error code 501 – Not Implemented if received. 6. Authentication Authentication is achieved within RVP by use HTTP/1.1 methods. This allows for the PRESENCE SERVICE to deny access to a protected resource by returning a status code of “401 Unauthorized”, and at least one WWW-Authenticate headers specifying a scheme that will allow authorization. Within RVP, two schemes are allowed; NTLM (NT Lan Manager) and Digest Access Authentication. RVP uses HTTP challenge-response authentication mechanism, which allows the PRESENCE SERVICE to provide the PRESENTITY with the allowed authentication types. The PRESENTITY is then expected to retry based on the authentication information returned. 6.1 NT Lan Manager (NTLM). This authentication scheme is provided by Microsoft Exchange 2000 to allow a secure method of authenticating a PRESENTITY as the username and password do not travel across the network in the clear. More detailed information on NTLM is available at http://msdn.microsoft.com. 6.2 Digest Access Authentication Osborne et al 28 RVP This authentication scheme verifies that both parties share a secret (i.e. A password), without communicating this secret in the clear. For more detailed information on Digest Access Authentication, see RFC 2617 – HTTP Authentication: Basic and Digest Access Authentication. This authentication scheme can be used by clients on non-NTLM capable platforms, such as UNIX. 6.3 Example The following example shows the requests and responses that allow a PRESENTITY to authenticate a subscription to their own node. As in the example for SUBSCRIBE, the PRINCIPAL is known as http://im.acme.com/instmsg/aliases/bruceb. This example shows the server denying the initial request, and specifying that the available authentication schemes are NTLM and Digest. The client then issues a second request using NTLM authentication. >> Request SUBSCRIBE /instmsg/aliases/bruceb HTTP/1.1 Subscription-Lifetime: 14400 Notification-Type: pragma/notify Call-Back: http://198.176.154.132:1234 RVP-Notifications-Version: 1.0 Host: imhome1.acme.com Content-Length: 0 RVP-From-Principal: http://im.acme.com/instmsg/aliases/bruceb >> Response HTTP/1.1 401 Access Denied WWW-Authenticate: Negotiate WWW-Authenticate: NTLM WWW-Authenticate: Digest qop="auth", realm="im.acme.com", nonce="78a8ffeeb123458a400358100000b4d0ed33ae239123441b44896487fe da" Content-Type: text/html Content-Length: XXXX RVP-Notifications-Version: 1.0 >> Request SUBSCRIBE /instmsg/aliases/bruceb HTTP/1.1 Subscription-Lifetime: 14400 Notification-Type: pragma/notify Call-Back: http://198.176.154.132:1234 RVP-Notifications-Version: 1.0 Host: imhome1.acme.com Content-Length: 0 Authorization: NTLM TlRMTVNTUAADABCDGAAYAF4AAAAYABgAdgAAAAAAAABABCDDgAOAEAAAAAQABAATg AAAAAAAACOAAAABYKAgHIAbwBiAGUAcgB0AG8AUgBPAEIARQBS >> Response Osborne et al 29 RVP HTTP/1.1 200 Successful Subscription-Id: 98210 Subscription-Lifetime: 14400 RVP-Notifications-Version: 1.0 7.0 Headers 7.1 Existing DAV/HTTP headers Implementations may ignore all DAV-specific headers unless otherwise mentioned. DAV header Since the current version of the protocol is only partially DAV- compliant, this header is never returned by servers and is ignored in requests. Depth header This is only supported with depth value of 0 in the PROPFIND method, where it is required. 7.2 New RVP headers RVP-Notifications-Version This is the version number of the notifications protocol. Every request and response must include this header. Call-Back This header, adopted from [GENA], is contained in SUBSCRIBE method, and gives a URL for async NOTIFY callbacks for subscription notifications. Subscription-Id This header, adopted from [GENA], is contained in SUBSCRIBE requests/responses, and NOTIFY, and UNSUBSCRIBE requests. It gives the unique identifier for a subscription. Subscription-Lifetime This is adopted from [GENA], and is used in the SUBSCRIBE method, it indicates the requested (in the request) and actual (in the response) subscription timeouts (if the subscription is leased). Notification-Type This header, adopted from [GENA], is contained in a SUBSCRIBE method; it indicates the type of notifications desired (within the GENA framework). Osborne et al 30 RVP Values can be update/propchange or pragma/notify, and is extensible to other values. RVP-Ack-Type This determines when the sender of a NOTIFY is satisfied delivery has been completed and an acknowledgement is required. It can have the values SingleHop, DeepOr, or DeepAnd. RVP-Hop-Count This is used to indicate how many hops (including the source of the NOTIFY, i.e. initially set to 1) have occurred to produce this request. RVP-From-Principal Indicates where the method originates, and is typically the logical URL of the sender. 8. Return codes RVP uses several existing HTTP return codes, and several from DAV. The return codes that are generally used are as follows. 200 Successful This is used to indicate that the request has been successfully carried out. 207 Multi-Status The default 207 (Multi-Status) is normally received is response to a PROPPATCH, or PROPFIND. Its body is a text/xml HTTP entity that contains a single XML element called multistatus, which contains a set of XML elements called response which contain 200, 300, 400, and 500 series status codes generated during the method invocation. 302 Object moved This is used to indicate that the requested node is not maintained by that server. The response will include the new URL for that node. A response of this type is typically received is response to a request to a Router. 401 Access denied When attempting to access a node that is protected, the PRESENCE SERVICE will respond with this return code. The response headers will contain details of available authorization schemes. 412 Precondition Failed Osborne et al 31 RVP The request could not be applied to the requested node. An example of its use is when attempting to send an Instant Message to a PRINCIPAL who is no longer available. 500 Internal Server Error An example of this use is when a PRINCIPAL has left a discussion with multiple PRINCIPALs. When the PRINCIPALs INSTANT MESSAGE INBOX receives a notification for this session, it would use this return code. The sender of the INSTANT MESSAGE would then be able to indicate that the PRINCIPAL has left the conversation. 9. XML Document Type Definition DAV elements The elements that are used from DAV are as follows: set prop timeout displayname subscription subscription-id href subscriptions multistatus response propstat propertyupdate 9.1 RVP elements The elements provided by RVP are as follows: 9.1.1 state Definition: Parent: DAV: Purpose: To indicate the current state information for the node. 9.1.2 leased-value Definition: Parent: Purpose: To indicate the current leased values status 9.1.3 default-value Definition: Parent: Osborne et al 32 RVP Purpose: To indicate the current default status of the node (currently one of “ ” or ) 9.1.4 value Definition: Parent: Purpose: To indicate the current status of the node (currently one of “ ” or ) 9.1.5 online Definition: Parent: | Purpose: To indicate the online status 9.1.6 offline Definition: Parent: | Purpose: To indicate the offline status 9.1.7 away Definition: Parent: | Purpose: To indicate the away status 9.1.8 busy Definition: Parent: | Purpose: To indicate the busy status 9.1.9 back-soon Definition: Parent: | Purpose: To indicate the back soon status 9.1.10 on-phone Definition: Parent: | Purpose: To indicate the on the phone status 9.1.11 at-lunch Definition: Parent: | Purpose: To indicate the at lunch status Osborne et al 33 RVP 9.1.12 view-id Definition: Parent: Purpose: A unique identifier for updates to a node 9.1.13 principal Definition: Parent: Purpose: Container for details about the PRINCIPAL 9.1.14 rvp-principal Definition: Parent Purpose: To detail the logical URL for a PRINCIPAL 9.1.15 email Definition: Parent: DAV: Purpose: Contains details of the PRINCIPAL’s email address 9.1.16 mobile-state Definition: Parent: DAV: Purpose: Determines if PRINCIPAL’s mobile is online 9.1.17 mobile-description Definition: Parent: DAV: Purpose: Description of PRINCIPAL’s mobile (e.g. Cell phone number) 9.1.18 notification Definition: Parent: None Purpose: To indicate an instant message, or update to PRINCIPAL’s state has occurred 9.1.19 propnotification Definition: Parent: Purpose: To indicate a change in PRINCIPAL’s state 9.1.20 message Osborne et al 34 RVP Definition: Parent: Purpose: To indicate that a instant message has been sent, or received 9.1.21 notification-from Definition: Parent: | Purpose: To indicate who the notification or message is from 9.1.22 notification-to Definition: Parent: | Purpose: To indication who the notification or message is destined for 9.1.23 msgbody Definition: Parent: Purpose: Contains the MIME encoded message that needs to be sent 9.1.24 contact Definition: Parent: | Purpose: To detail how to contact the PRINCIPAL 9.1.25 description Definition: Parent: Purpose: To describe the contact 9.1.26 mime-data Definition: Parent: Purpose: Contains the actual Instant Message to be sent or received. 10 MIME Payloads The are three types of payloads that can be delivered within the mime-data of an notification. The following are details of each of these payloads. 10.1 Instant Message Osborne et al 35 RVP This is the most common type of payload, and is typically used to send some text between two PRINCIPALs. The mime-data would be as follows: 10.2 Typing Message This is used to indicate that a PRINCIPAL is typing. In Microsoft Exchange 2000 these are sent every four seconds. 10.3 Application Invites This is used when a request to start an application occurs. © 2000 Microsoft Corporation. All Rights Reserved. 11. References [WEBDAV] Y. Goland, E. Whitehead, A. Faizi, S. Carter and D. Jensen, "HTTP Extensions for Distributed Authoring - WEBDAV", RFC 2518 [MODEL] M. Day, J. Rosenberg, and H. Sugano, "A Model for Presence and Instant Messaging," work in progress, draft-ietf- impp-model-03.txt. Osborne et al 36 RVP [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee, ‘Hypertext Transfer Protocol – HTTP/1.1’, RFC 2068 [WEBDAV-ACL] Leach P. J. and Goland Y. Y., "WebDAV ACL Protocol", INTERNET-DRAFT , November 1997 [RVP-CALSYN] M. Calsyn, L. Dusseault and G. Mohr, “A Presence Notification Protocol”, INTERNET DRAFT , September 1998 [IMPP-REQTS] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, “Instant Messaging / Presence Protocol Requirements”, INTERNET DRAFT [GENA] J. Cohen, S. Aggarwal, and Y. Y. Goland, “General Event Notification Architecture Base”, INTERNET DRAFT , June 1998 12. Author's Addresses Rob Osborne Microsoft Corporation One Microsoft Way, Redmond, WA 98052 Email: roberto@microsoft.com Sonu Aggarwal Microsoft Corporation One Microsoft Way Redmond, WA 98052 Email: sonuag@microsoft.com Leon Wong Microsoft Corporation One Microsoft Way Redmond, WA 98052 Email: leonw@microsoft.com Peter Beebee Microsoft Corporation One Microsoft Way Redmond, WA 98052 Email: peterbee@microsoft.com Martin Calsyn Microsoft Corporation One Microsoft Way Redmond, WA 98052 Email: martinca@microsoft.com Lisa Lippert Microsoft Corporation One Microsoft Way Osborne et al 37 RVP Redmond, WA 98052 Email: lisal@microsoft.com Osborne et al 38