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

          <?xml.version="1.0"?>
          <d:multistatus xmlns:d="DAV:"
          xmlns:r="http://schemas.microsoft.com/rvp/">
               <d:response>
                    <d:href>
                            http://im.example.com/instmsg/aliases/stevem
                    </d:href>
                    <d:propstat>
                            <d:prop>
                                    <r:state><r:offline/></r:state>
                                    <d:displayname>Steve</d:displayname>
                                    <r:email>stevem@example.com</r:email>

       Osborne et al                                                       10

                                        RVP

                                    <r:mobile-state>0</r:mobile-state>
                                    <r:mobile-description>
                                    </r:mobile-description>
                            </d:prop>
                            <d:status>HTTP/1.1.200.Successful</d:status>
                    </d:propstat>
               </d:response>
          </d:multistatus>

       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

          <?xml version="1.0"?>
          <Z:subscriptions xmlns:D="DAV:"
          xmlns:Z=http://schemas.microsoft.com/rvp/
          xmlns:A=http://schemas.Microsoft.com/rvp/acl>
               <Z:subscription>
                       <Z:subscription-id> 456 </Z:subscription-id>
                       <D:href>
                               http://im.example.com/instmsg/aliases/bruceb
                       </D:href>
                       <A:principal>
                               <A:rvp-principal>
                                       http://im.example.com/instmsg/aliase
                               s/bruceb
                               </A:rvp-principal>
                       </A:principal>
                       <D:timeout> 4789 </D:timeout>
               </Z:subscription>
               <Z:subscription>
                       <D:href>
                            http://im.example.com/instmsg/aliases/stevem
                       </D:href>
                       <Z:subscription-id> 6656 </Z:subscription-id>
                       <A:principal>
                               <A:rvp-principal>
                                       http://im.example.com/instmsg/aliase
                               s/stevem
                               <A:rvp-principal>
                       </A:principal>
                       <D:timeout> 8752 </D:timeout>
               </Z:subscription>
          </Z:subscriptions>

       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


          <?xml version="1.0" ?>
          <D:propfind xmlns:D="DAV:"
          xmlns:Z="http://schemas.microsoft.com/rvp/">
               <D:prop>
                       <D:displayname/>
               </D:prop>
          </D:propfind>

          >>Response

          HTTP/1.1 207 Multi-Status
          Content-Type: text/xml
          Content-Length: XXXX
          RVP-Notifications-Version: 1.0

          <?xml version="1.0" ?>
          <D:multistatus xmlns:D="DAV:"
          xmlns:Z="http://schemas.microsoft.com/rvp/">
               <D:response>
                       <D:href>
                               http://im.example.com/instmsg/aliases/stevem
                       </D:href>
                       <D:propstat>
                               <D:prop>
                                       <D:displayname>
                                               Steve Morgan
                                       </D:displayname>
                               </D:prop>
                               <D:status>HTTP/1.1 200 OK</D:status>
                       </D:propstat>
               </D:response>
          </D:multistatus>

       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

          <?xml version="1.0"?>
          <D:propupdate xmlns:D="DAV:"
          xmlns:Z="http://schemas.microsoft.com/rvp/">
               <D:set>
                       <D:prop>
                               <Z:state>
                                       <Z:leased-value>
                                               <Z:value>

       Osborne et al                                                       15

                                        RVP

                                                       <Z:online/>
                                               </Z:value>
                                               <Z:default-value> 
                                                       <Z:offline/>
                                               </Z:default-value> 
                                               <Z:timeout>3600</Z:timeout>
                                       </Z:leased-value> 
                               </Z:state>
                       </D:prop> 
               </D:set>
          </D:propertyupdate>

          >>Response:

          HTTP/1.1 207 Multi-Status
          RVP-Notifications-Version: 1.0 
          Content-Type: text/xml
          Content-Length: XXXX
           
          <?xml version="1.0"?> 
          <D:multistatus xmlns:D="DAV:" 
          xmlns:Z="http://schemas.microsoft.com/rvp/"> 
               <D:response>
                       <D:href>
                               http://im.example.com/instmsg/aliases/stevem 
                       </D:href>
                       <D:propstat> 
                               <D:prop> 
                                       <Z:state> 
                                               <Z:leased-value> 
                                                       <Z:value> 
                                                               <Z:online/> 
                                                       </Z:value> 
                                                       <Z:default-value>
                                                               <Z:offline/> 
                                                       </Z:default-value> 
                                                       <D:timeout> 
                                                               3600 
                                                       </D:timeout> 
                                               </Z:leased-value> 
                                               <Z:view-id>3577</Z:view-id> 
                                       </Z:state> 
                               </D:prop> 
                               <D:status>HTTP/1.1 200 OK</D:status> 
                       </D:propstat> 
               </D:response>
          </D:multistatus>

       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

          <?xml version="1.0"?>
          <D:notification xmlns:D="DAV:"
          xmlns:Z="http://schemas.microsoft.com/rvp/">
               <Z:message>
                       <Z:notification-from>
                               <Z:contact>
                                       <D:href>
                                       http://im.example.com/instms
          g/aliases/stevem
                                       </Z:href>
                                       <Z:description>
                                               Steve Morgan
                                       </Z:description>
                               </Z:contact>
                       </Z:notification-from>
                       <Z:notification-to>
                               <Z:contact>
                                       <D:href>
                                               http://im.acmewidgets.com/in
          stmsg/aliases/bruceb</D:href>
                                       <Z:description>
                                               bruce
                                       </Z:description>
                               </Z:contact> 
                       </Z:notification-to>
                       <Z:msgbody>
                               <Z:mime-data> 
                                       <![CDATA[MIME-Version: 1.0
                                       Content-Type: text/plain; 
                                       charset=UTF-8
                                       X-MMS-IM-Format: 
                                       FN=Microsoft%20Sans%20Serif; EF=;
                                       CO=0; CS=0; PF=22 
                                       Session-Id: {79FC61B5-1234-1234-
                                       8A10-941F33CA4C90} 

                                       Let’s have lunch 
                                       ]]>
                               </Z:mime-data> 
                       </Z:msgbody>
               </Z:message> 
          </Z:notification>

          >>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

          <?xml version="1.0"?>
          <Z:notification xmlns:D="DAV:"
          xmlns:Z="http://schemas.microsoft.com/rvp/">
               <Z:propnotification>
                       <Z:notification-from>
                               <Z:contact>
                                       <D:href>
                                            http://im.example.com/instmsg/a
          liases/stevem
                                       </D:href>
                                       <Z:description/>
                               </Z:contact>
                       </Z:notification-from>
                       <Z:notification-to>
                               <Z:contact>
                                       <D:href>
                                            http://im.acmewidgets.com/instm
          sg/aliases/bruceb
                                       </D:href>
                                       <Z:description/>
                               </Z:contact>
                       </Z:notification-to>
                       <D:propertyupdate>
                               <D:set>
                                       <D:prop> 
                                               <Z:state> 
                                                       <Z:online/> 
                                               </Z:state> 
                                       </D:prop> 
                               </D:set> 
                       </D:propertyupdate> 
               </Z:propnotification> 
          </Z:notification> 
         
       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: 
          <mEvent> 
               <eventType>DELIVER</eventType> 
               <eventTime>13:45 PST</eventTime> 
               <eventDate>03/24/98</eventDate> 
               <eventComment>Signed for by J Cohen</eventComment> 
          </mEvent> 
           
          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 
           
          <?xml version="1.0"?> 
          <Z:notification xmlns:D="DAV:" 
          xmlns:Z="http://schemas.microsoft.com/rvp/"> 
               <mEvent> 
                       <eventType>DELIVER</eventType> 
                       <eventTime>13:45 PST</eventTime> 
                       <eventDate>03/24/98</eventDate> 
                       <eventComment>Signed for by J Cohen</ eventComment> 
               </mEvent> 
          </Z:notification> 
           
          <Z:notification> 
               <manifest> 
                       <mTrackNo>12345</mTrackNo> 
                       <mShipper> 
                               <pName>CDNOW</pName> 
                               <pAddress> 
                                       100 any street, anytown, USA 
         
       Osborne et al                                                       22

                                        RVP                                  

                               <pAddress> 
                               <pPhone>111-555-1212</pPhone> 
                       </mShipper> 
                       <mDest> 
                       <pName>Josh Cohen</pName> 
                               <pAddress> 
                                       100 any other street, anyother town, 
                                  USA 
                               <pAddress> 
                               <pPhone>999-555-1212</pPhone> 
                       </mDest> 
                       <mEvent> 
                               <eventType>PICKUP</eventType> 
                               <eventTime>13:45 PST</eventTime> 
                               <eventDate>03/2 0/98</eventDate> 
                               <eventComment> 
                                       Picked up from CDNOW shipping room 
                               </eventComment> 
                       </mEvent> 
                       <mEvent> 
                               <eventType>HUB_TRANSITION</eventType> 
                               <eventTime>09:45 PST</eventTime> 
                               <eventDate>03/21/98</eventDate> 
                               <eventComment> 
                                       Dropped, smashed 
                               </eventComment> 
                       </mEvent> 
                       <mEvent> 
                               <eventType>DELIVER</eventType> 
                               <eventTime>13:45 PST</eventTime> 
                               <eventDate>03/24/98</eventDate> 
                               <eventComment> 
                                       Signed for by J Cohen 
                               </eventComment> 
                       </mEvent> 
               </manifest> 
          </Z:notification> 
           
          (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 <principal></principal> tag pair must contain one and only 
         
       Osborne et al                                                       24 

                                        RVP                                  

          one <rvp-principal> child, and one and only one <credentials> 
          child. 
           
          Name:        rvp-principal 
          Parent:      <principal> 
          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 <rvp-principal>.  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 <credentials/> element, either explicitly or 
          implicitly (as part of an <any/> 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 <credentials/> is null, the ACL 
          manipulation must be rejected with a “400  credentials not specified”.  
           
       5.7.2.1 credentials 
           
          Definition:  <!Element credentials (any | (ntlm?, digest?, 
                       assertion?, internal?))> 
          Parent:      <principal> 
          Purpose:     To uniquely identify the credentials a PRINCIPAL 
                       must present. 
          Values:      Any set of one or more valid credentials identifiers 
                       (currently  any combination of “<ntlm> <digest> 
                       <assertion> <internal>” or “<any>”) 
           
       5.7.2.2 ntlm 
           
          Definition:  <!Element ntlm EMPTY) 
          Parent:      <credentials> 
          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:  <!Element digest EMPTY)
          Parent:      <credentials> 
          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:  <!Element assertion EMPTY) 
          Parent:      <credentials> 
          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:  <!Element internal EMPTY) 
          Parent:      <credentials> 
          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:  <!Element any EMPTY) 
          Parent:      <credentials> 
          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 <credentials> 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 
           
          <?xml version="1.0"?> 
          <a:rvpacl xmlns:a="http://schemas.microsoft.com/rvp/acl/"> 
               <a:acl> 
                       <a:inheritance>none</a:inheritance> 
                       <a:ace> 
                               <a:principal> 
                                       <a:rvp-principal> 
                                          http://im.example.com/instmsg/ali
                                  ases/steveb/ 
                                       </a:rvp-principal> 
                                       <a:credentials> 
                                               <a:assertion/> 
                                               <a:digest/>
                                               <a:ntlm/> 
                                       </a:credentials> 
                               </a:principal> 
                               <a:grant/> 
                               <a:deny> 
                                       <a:send-to/> 
                                       <a:presence/> 
                               </a:deny> 
                       </a:ace> 
                       <a:ace> 
                               <a:principal> 
                                       <a:allprincipals/>
                                       <a:credentials> 
                                               <a:assertion/> 
                                               <a:digest/> 
                                               <a:ntlm/> 
                                       </a:credentials> 
                               </a:principal> 
                               <a:grant> 
                                       <a:list/> 
                                       <a:read/> 
                                       <a:send-to/> 
                                       <a:presence/> 
                               </a:grant> 
                               <a:deny/> 
                       </a:ace> 
                       <a:ace> 
                               <a:principal> 
                                       <a:rvp-principal> 
                                               http://im.acme.com/instmsg/a
                                       liases/bruceb 
                                       </a:rvp-principal> 
                                       <a:credentials> 
                                               <a:assertion/> 
                                       </a:credentials> 
         
       Osborne et al                                                       27 

                                        RVP                                  

                               </a:principal> 
                               <a:grant> 
                                       <a:list/>
                                       <a:read/> 
                                       <a:write/> 
                                       <a:send-to/> 
                                       <a:receive-from/> 
                                       <a:readacl/> 
                                       <a:writeacl/> 
                                       <a:presence/> 
                                       <a:subscriptions/> 
                                       <a:subscribe-others/> 
                               </a:grant> 
                               <a:deny/> 
                       </a:ace>
               </a:acl> 
          </a:rvpacl> 
           
       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:  <!Element state (leased-value, view-id?)>
          Parent:      DAV:<prop>
          Purpose:     To indicate the current state information for the
                       node.

       9.1.2 leased-value

          Definition:  <!Element leased-value (value, default-value,
                       timeout)>
          Parent:      <state>
          Purpose:     To indicate the current leased values status

       9.1.3 default-value

          Definition:  <!Element default-value ANY>
          Parent:      <leased-value>

       Osborne et al                                                       32

                                        RVP

          Purpose:     To indicate the current default status of the node
                       (currently one of “<online> <offline> <away> <busy>”
                       <back-soon> <on-phone> or <at-lunch>)

       9.1.4 value

          Definition:  <!Element value ANY>
          Parent:      <leased-value>
          Purpose:     To indicate the current status of the node
                       (currently one of “<online> <offline> <away> <busy>”
                       <back-soon> <on-phone> or <at-lunch>)

       9.1.5 online

          Definition:  <!Element online EMPTY>
          Parent:      <default-value> | <value>
          Purpose:     To indicate the online status

       9.1.6 offline

          Definition:  <!Element offline EMPTY>
          Parent:      <default-value> | <value>
          Purpose:     To indicate the offline status

       9.1.7 away

          Definition:  <!Element away EMPTY>
          Parent:      <default-value> | <value>
          Purpose:     To indicate the away status

       9.1.8 busy

          Definition:  <!Element busy EMPTY>
          Parent:      <default-value> | <value>
          Purpose:     To indicate the busy status

       9.1.9 back-soon

          Definition:  <!Element back-soon EMPTY>
          Parent:      <default-value> | <value>
          Purpose:     To indicate the back soon status

       9.1.10 on-phone

          Definition:  <!Element on-phone EMPTY>
          Parent:      <default-value> | <value>
          Purpose:     To indicate the on the phone status

       9.1.11 at-lunch

          Definition:  <!Element at-lunch EMPTY>
          Parent:      <default-value> | <value>
          Purpose:     To indicate the at lunch status


       Osborne et al                                                       33

                                        RVP

       9.1.12 view-id

          Definition:  <!Element view-id (#PCDATA)>
          Parent:      <state>
          Purpose:     A unique identifier for updates to a node

       9.1.13 principal

          Definition:  <!Element principal (rvp-principal)>
          Parent:      <subscription>
          Purpose:     Container for details about the PRINCIPAL

       9.1.14 rvp-principal

          Definition:  <!Element rvp-principal (#PCDATA)>
          Parent       <principal>
          Purpose:     To detail the logical URL for a PRINCIPAL

       9.1.15 email

          Definition:  <!Element email (#PCDATA)>
          Parent:      DAV:<prop>
          Purpose:     Contains details of the PRINCIPAL’s email address

       9.1.16 mobile-state

          Definition:  <!Element mobile-state (0 | 1)>
          Parent:      DAV:<prop>
          Purpose:     Determines if PRINCIPAL’s mobile is online

       9.1.17 mobile-description

          Definition:  <!Element mobile-description (#PCDATA)>
          Parent:      DAV:<prop>
          Purpose:     Description of PRINCIPAL’s mobile (e.g. Cell phone
                       number)

       9.1.18 notification

          Definition:  <!Element notification (message | propnotification)>
          Parent:      None
          Purpose:     To indicate an instant message, or update to
                       PRINCIPAL’s state has occurred

       9.1.19 propnotification

          Definition:  <!Element propnotification (notification-from,
                       notification-to, propertyupdate)>
          Parent:      <notification>
          Purpose:     To indicate a change in PRINCIPAL’s state

       9.1.20 message



       Osborne et al                                                       34

                                        RVP

          Definition:  <!Element message (notification-from, notification-
                       to*, msgbody)>
          Parent:      <notification>
          Purpose:     To indicate that a instant message has been sent, or
                       received

       9.1.21 notification-from

          Definition:  <!Element notification-from (contact)>
          Parent:      <propnotification> | <message>
          Purpose:     To indicate who the notification or message is from

       9.1.22 notification-to

          Definition:  <!Element notification-to (contact)>
          Parent:      <propnotification> | <message>
          Purpose:     To indication who the notification or message is
                       destined for

       9.1.23 msgbody

          Definition:  <!Element msgbody (mime-data)>
          Parent:      <message>
          Purpose:     Contains the MIME encoded message that needs to be
                       sent

       9.1.24 contact

          Definition:  <!Element contact (href, description) >
          Parent:      <notification-to> | <notification-from>
          Purpose:     To detail how to contact the PRINCIPAL

       9.1.25 description

          Definition:  <!Element description (#PCDATA)>
          Parent:      <contact>
          Purpose:     To describe the contact

       9.1.26 mime-data

          Definition:  <!Element mime-data (#CDATA)>
          Parent:      <msgbody>
          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:

          <![CDATA[
          MIME-Version: 1.0
          Content-Type: text/plain; charset=UTF-8
          X-MMS-IM-Format: FN=Microsoft%20Sans%20Serif; EF=; CO=0; CS=0;
          PF=22
          Session-Id: {79FC61B5-1234-1234-8A10-941F33CA4C90}

          Lets have lunch]]>

       10.2 Typing Message

          This is used to indicate that a PRINCIPAL is typing. In Microsoft
          Exchange 2000 these are sent every four seconds.

          <![CDATA[
          MIME-Version 1.0
          Content-Type: text/x-msmsscontrol
          TypingUser: bruceb@example.com
          Session-Id: {79FC6B5-1234-1234-8A0-941F33CA4C90}

          ]]>

       10.3 Application Invites

          This is used when a request to start an application occurs.

          <![CDATA[
          MIME-Version: 1.0
          Content-Type: text/x-msmsgsinvite;.charset=UTF-8
          Session-Id: {79FC61B5-1234-1234-8A10-941F33CA4C90}

          Application-Name: NetMeeting.3.01
          Application-GUID: {44BBA842-CC51-11CF-AAFA-00AA00B6015C}
          Invitation-Command: INVITE
          Invitation-Cookie: 3


          ]]>

          © 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 <draft-ietf-webdav-acl-00.txt>, November 1997 
           
          [RVP-CALSYN] M. Calsyn, L. Dusseault and G. Mohr, “A Presence 
          Notification Protocol”, INTERNET DRAFT <draft-calsyn-rvp-01.txt>, 
          September 1998 
           
          [IMPP-REQTS] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, 
          “Instant Messaging / Presence Protocol Requirements”, INTERNET 
          DRAFT <draft-ietf-impp-reqts-04.txt> 
           
          [GENA] J. Cohen, S. Aggarwal, and Y. Y. Goland, “General Event 
          Notification Architecture Base”, INTERNET DRAFT <draft-cohen-
          gena-p-base-01.txt>, 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