Network Working Group Rob Osborne INTERNET DRAFT Sonu Aggarwal Leon Wong Expires: December 2000 Peter Beebee Martin Calsyn Lisa Lippert Microsoft Corporation RVP: A Presence and Instant Messaging Protocol 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 The list of Internet-Draft Shadow Directories can be accessed at 2. 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. 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 reflects the actual Microsoft Exchange 2000 implementation. Osborne et al [Page 1] RVP June 2000 3. Contents 1. Status of this Document ................................... 1 2. Abstract .................................................. 1 3. Contents .................................................. 2 4. Overview .................................................. 3 5. Protocol Introduction ..................................... 4 5.1 Architecture ......................................... 4 5.1.1 General Interaction .............................. 5 5.1.2 Addressing ....................................... 5 5.2 Authentication ....................................... 6 5.3 Examples ............................................. 6 6. Protocol Methods .......................................... 6 6.1 SUBSCRIBE ............................................ 6 6.1.1 Subscribtion Ids ................................. 7 6.1.2 Leased subscriptions ............................. 7 6.1.3 Notification types ............................... 7 6.1.4 Notification delivery ............................ 8 6.1.5 Changing/discarding subscriptions ................ 8 6.1.6 Response ......................................... 9 6.1.7 Examples ......................................... 9 6.1.7.1 Login Subscription .......................... 9 6.1.7.2 Property subscription ....................... 10 6.2 UNSUBSCRIBE .......................................... 11 6.2.1 Example .......................................... 11 6.3 SUBSCRIPTIONS ........................................ 11 6.3.1 Example .......................................... 12 6.4 PROPFIND ............................................. 13 6.4.1 Example .......................................... 13 6.5 PROPPATCH ............................................ 14 6.5.1 Example .......................................... 15 6.5.2 Implementation considerations .................... 16 6.6 NOTIFY ............................................... 17 6.6.1 Examples ......................................... 18 6.7 ACL .................................................. 24 6.7.1 Access rights .................................... 24 6.7.2 Principals ....................................... 25 6.7.2.1 Credentials ................................. 25 6.7.2.2 ntlm ........................................ 25 6.7.2.3 digest ...................................... 26 6.7.2.4 assertion ................................... 26 6.7.2.5 internal .................................... 26 6.7.2.6 any ......................................... 26 6.7.3 Examples ......................................... 26 6.8 Other methods ........................................ 28 7. Authentication ............................................ 28 7.1 NT Lan Manager (NTLM) ................................ 29 7.2 Digest Access Authentication ......................... 29 7.3 Example .............................................. 29 8. Headers ................................................... 30 8.1 Existing DAV/HTTP headers ............................ 30 8.2 RVP headers .......................................... 30 9. Return codes .............................................. 31 Osborne et al [Page 2] RVP June 2000 10. XML Document Type Definition ............................. 32 10.1 RVP elements ......................................... 32 10.1.1 State ........................................... 33 10.1.2 leased-value .................................... 33 10.1.3 default-value ................................... 33 10.1.4 value ........................................... 33 10.1.5 online .......................................... 33 10.1.6 offline ......................................... 33 10.1.7 away ............................................ 33 10.1.8 busy ............................................ 33 10.1.9 back-soon . ..................................... 34 10.1.10 on-phone ...................................... 34 10.1.11 at-lunch ...................................... 34 10.1.12 view-id ....................................... 34 10.1.13 principal ..................................... 34 10.1.14 rvp-principal ................................. 34 10.1.15 email ... ..................................... 34 10.1.16 mobile-state .................................. 34 10.1.17 mobile-description ............................ 34 10.1.18 notification .................................. 35 10.1.19 propnotification .............................. 35 10.1.20 message ....................................... 35 10.1.21 notification-from ............................. 35 10.1.22 notification-to ............................... 35 10.1.23 msgbody ....................................... 35 10.1.24 contact ....................................... 35 10.1.25 description ................................... 35 10.1.26 mime-data ..................................... 36 11. MIME Payloads ............................................ 36 11.1 Instant Message ...................................... 36 11.2 Typing Message ....................................... 36 11.3 Application Invites .................................. 36 12. References ............................................... 37 13. AuthorÆs Addresses ....................................... 37 4. 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. 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. 5. Protocol Introduction RVP-specific information is general transferred in new methods or by specifying the RVP namespace in XML-formatted data within the Osborne et al [Page 3] RVP June 2000 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. 5.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. 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. Osborne et al [Page 4] RVP June 2000 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. 5.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. 5.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 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: Osborne et al [Page 5] RVP June 2000 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. 5.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. 5.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 reaching a certain value, process completion, and inventory alerts. 6. Protocol Methods 6.1 SUBSCRIBE Osborne et al [Page 6] RVP June 2000 The SUBSCRIBE method, adopted from General Event Notification Architecture Base 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. 6.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. 6.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. 6.1.3 Notification types 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- Osborne et al [Page 7] RVP June 2000 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). 6.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. Such notifications are delivered through NOTIFY requests. (In the above example, the PRESENCE SERVICE makes a NOTIFY request to the WATCHER.) 6.1.5 Changing/discarding subscriptions Osborne et al [Page 8] RVP June 2000 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. 6.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. 6.1.7 Examples 6.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 RVP-Notifications-Version: 1.0 Host: imhome1.acme.com Content-Length: 0 RVP-From-Principal: http://im.acme.com/instmsg/aliases/bruceb Osborne et al [Page 9] RVP June 2000 >> Response HTTP/1.1 200 Successful Subscription-Id: 98210 Subscription-Lifetime: 14400 RVP-Notifications-Version: 1.0 6.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 0 Osborne et al [Page 10] RVP June 2000 HTTP/1.1.200.Successful 6.2 UNSUBSCRIBE The UNSUBSCRIBE method 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. 6.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 6.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. SUBSCRIPTIONS use the new RVP XML elements ôsubscriptionsö, ôsubscriptionö, ôsubscription-idö, ôtimeoutö, and ôrvp- principalö. Osborne et al [Page 11] RVP June 2000 6.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 6.4 PROPFIND Osborne et al [Page 12] RVP June 2000 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). 6.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 [Page 13] RVP June 2000 >>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 6.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 [Page 14] RVP June 2000 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. 6.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 [Page 15] RVP June 2000 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 6.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 [Page 16] RVP June 2000 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. 6.6 NOTIFY The NOTIFY RVP method 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 Osborne et al [Page 17] RVP June 2000 such as ôhttp://im.example.com/groups/rec-cyclingö; the group node need not SUBSCRIBE to any other node. 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ö. 6.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. Osborne et al [Page 18] RVP June 2000 >>Request 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 Osborne et al [Page 19] RVP June 2000 >>Response 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 [Page 20] RVP June 2000 >>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 Osborne et al [Page 21] RVP June 2000 03/24/98 Signed for by A Ortega WATCHER opens a connection to www.package.com >>> 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, ôA Ortegaö 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 A Ortega Osborne et al [Page 22] RVP June 2000 12345 CDNOW 100 any street, anytown, USA 111-555-1212 Andy Ortega 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 A Ortega (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 Osborne et al [Page 23] RVP June 2000 (WATCHER closes connection) 6.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 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/ 6.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 Osborne et al [Page 24] RVP June 2000 Purpose: To determine who is allowed to subscribe to properties and notifications using unrecognized callbacks Values: None 6.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 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ö. 6.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 ôö) 6.7.2.2 ntlm Definition: Osborne et al [Page 25] RVP June 2000 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 6.7.2.3 digest Definition: Purpose: To indicate that a PRINCIPAL must satisfy a digest challenge from the PRESENCE SERVICE. The PRESENCE SERVICE should not check for the specified PRINCIPALÆs existence when the ACL is set. Values: none 6.7.2.4 assertion Definition: Purpose: To indicate that a PRINCIPAL doesnÆt need to present credentials to prove itÆs identity. Values: none 6.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 6.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. 6.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 Osborne et al [Page 26] RVP June 2000 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 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/ Osborne et al [Page 27] RVP June 2000 http://im.acme.com/instmsg/a liases/bruceb 6.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. 7. 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. Osborne et al [Page 28] RVP June 2000 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. 7.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. 7.2 Digest Access Authentication 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. 7.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 Osborne et al [Page 29] RVP June 2000 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 HTTP/1.1 200 Successful Subscription-Id: 98210 Subscription-Lifetime: 14400 RVP-Notifications-Version: 1.0 8.0 Headers 8.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. 8.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 is contained in SUBSCRIBE method, and gives a URL for async NOTIFY callbacks for subscription notifications. Subscription-Id Osborne et al [Page 30] RVP June 2000 This header is contained in SUBSCRIBE requests/responses, and NOTIFY, and UNSUBSCRIBE requests. It gives the unique identifier for a subscription. Subscription-Lifetime This 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 is contained in a SUBSCRIBE method; it indicates the type of notifications desired. 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. 9. 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, Osborne et al [Page 31] RVP June 2000 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 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. 10. 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 10.1 RVP elements The elements provided by RVP are as follows: Osborne et al [Page 32] RVP June 2000 10.1.1 state Definition: Parent: DAV: Purpose: To indicate the current state information for the node. 10.1.2 leased-value Definition: Parent: Purpose: To indicate the current leased values status 10.1.3 default-value Definition: Parent: Purpose: To indicate the current default status of the node (currently one of ô ö or ) 10.1.4 value Definition: Parent: Purpose: To indicate the current status of the node (currently one of ô ö or ) 10.1.5 online Definition: Parent: | Purpose: To indicate the online status 10.1.6 offline Definition: Parent: | Purpose: To indicate the offline status 10.1.7 away Definition: Parent: | Purpose: To indicate the away status 10.1.8 busy Definition: Parent: | Purpose: To indicate the busy status Osborne et al [Page 33] RVP June 2000 10.1.9 back-soon Definition: Parent: | Purpose: To indicate the back soon status 10.1.10 on-phone Definition: Parent: | Purpose: To indicate the on the phone status 10.1.11 at-lunch Definition: Parent: | Purpose: To indicate the at lunch status 10.1.12 view-id Definition: Parent: Purpose: A unique identifier for updates to a node 10.1.13 principal Definition: Parent: Purpose: Container for details about the PRINCIPAL 10.1.14 rvp-principal Definition: Parent Purpose: To detail the logical URL for a PRINCIPAL 10.1.15 email Definition: Parent: DAV: Purpose: Contains details of the PRINCIPALÆs email address 10.1.16 mobile-state Definition: Parent: DAV: Purpose: Determines if PRINCIPALÆs mobile is online 10.1.17 mobile-description Definition: Parent: DAV: Osborne et al [Page 34] RVP June 2000 Purpose: Description of PRINCIPALÆs mobile (e.g. Cell phone number) 10.1.18 notification Description: Parent: None Purpose: To indicate an instant message, or update to PRINCIPALÆs state has occurred 10.1.19 propnotification Description: Parent: Purpose: To indicate a change in PRINCIPALÆs state 10.1.20 message Description: Parent: Purpose: To indicate that a instant message has been sent, or received 10.1.21 notification-from Description: Parent: | Purpose: To indicate who the notification or message is from 10.1.22 notification-to Description: Parent: | Purpose: To indication who the notification or message is destined for 10.1.23 msgbody Definition: Parent: Purpose: Contains the MIME encoded message that needs to be sent 10.1.24 contact Definition: Parent: | Purpose: To detail how to contact the PRINCIPAL 10.1.25 description Osborne et al [Page 35] RVP June 2000 Definition: Parent: Purpose: To describe the contact 10.1.26 mime-data Definition: Parent: Purpose: Contains the actual Instant Message to be sent or received. 11 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. 11.1 Instant Message 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: 11.2 Typing Message This is used to indicate that a PRINCIPAL is typing. In Microsoft Exchange 2000 these are sent every four seconds. 11.3 Application Invites This is used when a request to start an application occurs. ¨ 2000 Microsoft Corporation. All Rights Reserved. 12. 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, RFC 2778. [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee, æHypertext Transfer Protocol û HTTP/1.1Æ, RFC 2068 [WEBDAV-ACL] E. Sedlar and G. Clemm, "WebDAV ACL Protocol", INTERNET-DRAFT , May 2000 [IMPP-REQTS] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, ôInstant Messaging / Presence Protocol Requirementsö, RFC 2779 13. 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 Osborne et al [Page 37] RVP June 2000 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 Redmond, WA 98052 Email: lisal@microsoft.com Osborne et al [Page 38]