INTERNET-DRAFT Martin Calsyn Expires: Sept 1998 Lisa Dusseault Microsoft Corporation Gordon Mohr Activerse RVP: A Presence Notification Protocol draft-calsyn-rvp-01.txt 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract A new kind of application is emerging on 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. This protocol for facilitating rendezvous between users, known herein as RVP, 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 authors recognize that there is significant overlap with between RVP and HTTP, though there are also significant differences. We expect RVP to evolve and either converge or diverge with HTTP and/or other existing protocols. The protocol described in this document represents a very viable starting point for a discussion of a standardized solution to the problem. Comments on this draft are solicited and should be sent to the authors or the RVP discussion list. To join the RVP discussion Calsyn, Dusseault & Mohr [Page 1] INTERNET-DRAFT RVP March 13, 1997 list, send email with the body "subscribe" to rvp- request@iastate.edu. 3. Contents 1. Status of this Memo.........................................1 2. Abstract....................................................1 3. Contents....................................................2 4. Introduction................................................4 4.1. Problem to be solved..................................4 4.2. Terminology...........................................4 4.3. Definitions...........................................4 4.4. Protocol Properties...................................5 4.4.1. General format....................................5 4.4.2. Minimal State.....................................5 4.4.3. Transport-Protocol Neutral........................6 4.4.4. Text-based........................................6 5. Overview of RVP Functionality...............................6 5.1.1. Naming and Location of RVP Objects................6 5.1.2. RVP Object Schemas................................7 5.1.3. RVP Clients.......................................7 5.1.4. Home Servers......................................8 5.1.5. Proxies...........................................8 5.1.6. Server-Server Interactions........................8 5.1.7. Subscriptions.....................................9 5.1.8. Multiple client issues...........................10 6. Security...................................................10 6.1. Authentication.......................................10 6.2. Content Protection...................................10 6.3. Server-to-Server Security............................11 6.4. Privacy Issues.......................................11 7. RVP Methods................................................11 7.1. GET method (from HTTP)...............................11 7.2. PUT method (from HTTP)...............................12 7.3. MKCOL (from DAV).....................................12 7.4. RMCOL (from DAV).....................................12 7.5. ACL (from DAV).......................................12 7.6. SUBSCRIBE (introduced here)..........................12 Reply-To header.........................................12 7.6.2. Notification-type header.........................12 7.6.3. Using XML to specify properties..................12 7.7. UNSUBSCRIBE..........................................13 7.8. NOTIFY...............................................13 8. Responses..................................................14 8.1. GET response.........................................14 8.2. SUBSCRIBE response...................................14 8.2.1. Privacy-level....................................14 8.3. Refer................................................15 9. Transport Considerations for Datagrams and Connections.....15 9.1. Choice of Transport..................................15 9.1.1. Matching Responses To Requests...................16 9.2. UDP Retry Policy.....................................16 9.3. Mixed-Transport Through Proxies......................17 10. Protocol Details..........................................17 10.1. Identity URLs, Location URLs, and default port.......17 Calsyn, Dusseault & Mohr [Page 2] INTERNET-DRAFT RVP March 13, 1997 10.2. Headers..............................................18 10.2.1.Accept-charset...................................18 10.2.2.Accept-encoding..................................18 10.2.3.Accept-Language..................................18 10.2.4.Allow............................................19 10.2.5.Authorization....................................19 10.2.6.Reply-To.........................................19 10.2.7.Content-Encoding.................................19 10.2.8.Content-Language.................................19 10.2.9.Content-Length...................................19 10.2.10.Content-Type....................................19 10.2.11.Date............................................19 10.2.12.From............................................19 10.2.13.Host............................................19 10.2.14.If-Modified-Since...............................20 10.2.15.If-Unmodified-Since.............................20 10.2.16.Last-Modified...................................20 10.2.17.Request-ID......................................20 10.2.18.Server..........................................20 10.2.19.Session-ID......................................20 10.2.20.Subscription-ID.................................20 10.2.21.Via.............................................20 10.2.22.XML-body........................................20 10.3. Responses............................................21 10.4. Proxying and Referral................................21 10.5. Peer to peer Messaging...............................22 10.5.1.Getting direct responses to requests.............23 10.5.2.Responding directly to notifications.............23 10.5.3.Receiving instant messages directly..............23 10.5.4.Receiving Requests Directly......................23 10.6. Proxy and Referral Conflicts.........................24 11. Examples..................................................24 11.1. Subscribing directly to status changes...............24 11.2. Subscribing through a proxy to a group:..............26 11.3. Setting ACLs on the status property..................27 11.4. Sending an instant message...........................27 11.5. Inviting a user to a session defined by SIP..........28 12. REFERENCES................................................28 13. Authors' Addresses........................................29 Calsyn, Dusseault & Mohr [Page 3] INTERNET-DRAFT RVP March 13, 1997 4. Introduction 4.1. Problem to be solved With the rise of real-time interaction systems, including text, audio and video over computer networks, there is a need for a user to be able to determine if his or her peers are online. Along with this need for status information, users wish to exchange brief, perishable, and perhaps time-critical messages. Users also want to exchange messages with groups of users with common interests. For instance, a given user might want to send a message to all users currently logged in who have indicated interest in a gaming session. Like individual users, the online status of a group can be published. A similar need exists for reliable, secure notifications and messages between people and automated processes, for business and systems management purposes. Existing protocols, such as SIP for session initiation, LDAP for user information and SMTP for messaging, overlap somewhat with the problem domain defined here. However, these protocols lack key features such as scalability, latency, data replication, and integration. This has led to many independent, centralized, monolithic and incompatible vendor solutions. The popularity of these non-interoperable solutions is an indication of the need to address the problem. This draft is an attempt to address the problem space in a generalized fashion that allows different server and client implementations to interact within a secure internet-wide infrastructure. The PIP Requirements draft [3] discusses in more detail the nature of this problem and requirements for solutions. 4.2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant RVP implementations. 4.3. Definitions This specification uses a number of terms to refer to the roles played by participants in RVP communications and the kinds of messages passed between them. Client: A software process or portion of a process which connects to RVP server(s) but hosts no RVP objects. Client and server functionality may exist within a single process. Calsyn, Dusseault & Mohr [Page 4] INTERNET-DRAFT RVP March 13, 1997 Content: MIME-encapsulated data transmitted in the body of an RVP transaction Node: A named vertex in an RVP tree, which can map to an object. Property: A named attribute of an RVP object. Request: A query for information initiated by a server or client and targeted at a server. Requests result in one or more responses. Response: The returned result of a request. A server may return one or more responses in answer to a request. Server: A software process which can host RVP objects and can accept connections from other entities sending messages to or requesting data from those objects. Alternatively, a pure proxy server does not host RVP objects but can still accept connections on behalf of another process which does host RVP objects. Subscription: A subscription is a request that will result in multiple responses, one for each change in the subscribed property or one for each message sent to the subscribed object. User: A single human; a person who might operate one or more instances of the client software; a human represented by a RVP ‘user’ object. 4.4. Protocol Properties RVP is designed to be a useful notification protocol for various purposes, but its primary purpose is notifying users of property changes on other user objects. This draft covers both generic notification mechanisms and specific people presence issues. Most of the generic notification mechanisms are discussed in this draft. Most of the specific people-presence issues are covered in the user and group schemas of the schema draft [2]. 4.4.1. General format The RVP protocol generally fits the HTTP [5] model. Where we have used HTTP protocol elements, we defer to the HTTP definition of those elements. RVP-specific information is general transferred in new commands 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 might allow a RVP server to coexist with an HTTP server. XML is used in order to provide flexibility and extensibility. Parsing of messages should follow HTTP recommendations. Port 80 may be used. 4.4.2. Minimal State Calsyn, Dusseault & Mohr [Page 5] INTERNET-DRAFT RVP March 13, 1997 An effort has been made to minimize the amount of state that a running server must maintain. A server is required to maintain a list of the subscriptions it currently holds while running. Subscriptions for a given client may be discarded if the connection to that client is broken, or if the publishing server receives a message that the subscriber is offline, but the publishing server should inform the subscriber that their subscription was dropped. For most objects, clients are required to re-subscribe whenever reconnecting. Issue: should subscriptions be dropped if the server goes down? 4.4.3. Transport-Protocol Neutral RVP is able to utilize both UDP and TCP as transport protocols. Servers MUST implement both UDP and TCP transport. Clients MUST support TCP and MAY support UDP interactions. Abbreviated headers should be defined to facilitate UDP interactions between servers for cases where the transaction will fit wholly within the MTU. Transactions between servers that do not fit within the MTU are sent via TCP link. 4.4.4. Text-based RVP is text-based. This allows easy implementation in languages such as Tcl and Perl, allows easy debugging, and most importantly, makes RVP flexible and extensible. 5. Overview of RVP Functionality 5.1.1. Naming and Location of RVP Objects Every RVP object has an authoritative address, which is a URL. This URL serves not only as a unique name, but also a pointer to the location where the object usually resides. For more information on RVP URLs and finding addresses and servers, see [4]. A single RVP server can host a hierarchy of nodes that correspond to objects. Each object must have certain properties, and each node may have child nodes. A client or peer server can attempt to: - Get or put properties on objects - Add or remove subscriptions on objects - Create new child nodes - Send notifications/messages to an object All of the above operations are gated by access control entries on each object. Calsyn, Dusseault & Mohr [Page 6] INTERNET-DRAFT RVP March 13, 1997 A node has a persistent location in this hierarchy, on this server, throughout its life. If a set of content moves away from a node and users should still be able to find that content, then the server should link, refer or proxy to the new node. 5.1.2. RVP Object Schemas In order that clients can query known properties of objects, a required minimal schema is defined for each object. Individual implementations and individual instances of servers can extend this schema, but must implement the minimal schema. The minimal schema, along with schemas for user and group objects, are defined separately in [2]. 5.1.3. RVP Clients An RVP client is any endpoint process that uses the RVP protocol on behalf of a user. A client can also act as its server by hosting rvp objects. Clients that do not host objects can only converse with servers. Clients that do host objects can converse with other clients as well as servers. Note that Client-to- client interaction may enhance performance, but it results in a reduction in security by directly exposing client IP addresses. In client-to-client interaction, both clients act as their own servers. In the remainder of this document, client requirements are for the process or portion of a process that interfaces with the user. Server requirements are for the process or portion of a process that hosts objects, subscribes directly to publishing servers, or otherwise needs to be contacted directly. Nothing precludes a single process from acting as both client and server. The referral and proxy mechanisms discussed later in this document allow users who have their content hosted on a server while offline to switch to hosting their own content while online. We require that a client be able to receive messages such as instant messages and notifications. This can be done in three ways: - The client maintains an open TCP connection to their proxy server. All queries, subscriptions and notifications from outside are sent to the proxy server, which sends messages to the client as appropriate. The user's canonical RVP address as listed for instant messages and the Reply-To address for subscriptions must be on their proxy server which is also their home server, OR the home server with the canonical address can refer to the proxy. The user's RVP address as listed for queries and subscriptions must be on their home server. - The client listens an open port, accepting connections ONLY from their home server. All queries, subscriptions and notifications from outside are sent to the server, and the server Calsyn, Dusseault & Mohr [Page 7] INTERNET-DRAFT RVP March 13, 1997 opens up a connection to the client and sends whichever messages are appropriate. RVP address restrictions are as above. - The client listens on an open port, accepting connections from any source. The client may now act as its own server. Messages that are sent to the home server may be redirected to the client. The user can then be addressed at either their home server or at their local client & server machine. Any client that does this must follow all RVP requirements for a server. A client process representing a user must, as part of its initialization, PUT values for properties to that user’s object (wherever it is hosted). These properties indicate the user’s status and availability for various types of interactions. The same client process must update the properties as they change. A client process representing an automated process could get and put properties, subscribe to content, or send content out as part of it’s operation. Examples include a fortune-cookie server, a system for announcing server status, or a stock transaction system. 5.1.4. Home Servers A user's home server is the server that most consistently hosts their data, particularly while the user is offline. This is also the server pointed to by the user's canonical RVP address. The home server may also act as a proxy. 5.1.5. Proxies Sending requests to a proxy can reduce network traffic. The proxy can maintain only one subscription for public data, which means that if many of that proxy's users subscribe to the same data, the number of messages is greatly reduced. For controlled data, the proxy must send one subscription request for every RVP object that wishes to subscribe, so that the publishing server may check ACLs. However, the number of messages is still low: the publishing server need only send one response to the proxy, which fans responses out to the individual subscribers. A proxy server may also be the home server for a user. If the proxy server is different from the home server, and the client does not accept incoming connections from any source, then the client must either maintain a connection to the proxy or listen on a port accepting messages from the proxy. 5.1.6. Server-Server Interactions An RVP server can be any process that hosts RVP objects, proxies RVP messages, or receives RVP messages directly from any sender. Calsyn, Dusseault & Mohr [Page 8] INTERNET-DRAFT RVP March 13, 1997 Servers interact with other servers using the same protocol as client-to-server interactions. Upon receiving a message, a server may respond by processing that message locally, updating its local persistent or dynamic data, proxying the message, or responding with an error. Because this represents a certain amount of dynamic state in the server, the client must refresh subscriptions whenever restoring a connection to a server and the server may throw away subscriptions when a client disconnects. Some connectionless interactions with servers need to be refreshed periodically. Client-server connections may be via UDP or TCP/IP and server- server connections may be via UDP or TCP. TCP and UDP interactions and client-server/server-server interactions are defined below in such a way to minimize dynamic server state while preserving network bandwidth and giving the clients a predictable level of reliability. 5.1.7. Subscriptions Subscriptions are usually registered ultimately at the server that publishes information. The exception is the case where a proxy that receives a new subscription request already has a subscription to that data AND the data is public. Since the proxy will already be getting notifications on that data, the proxy can fan out notifications to individual end-points. Since the first subscription always goes to the publishing server, and the response indicates whether the data is public or controlled, the proxy knows how to handle additional subscriptions. A subscription request always includes: - The source of the subscription (for access control) - The call-back address - Desired timeout value for subscription The response to a subscription always includes: - Whether the events being subscribed to are public or controlled - What the subscription-ID is (so it can be referred to if it needs to be cancelled) - What timeout was assigned to the subscription - Whether the subscription must be cancelled if the subscriber goes offline If a client subscribes to a proxy server which in turn subscribes to a publishing server, then the client's RVP address is listed as the source, but the proxy's address is listed as the call-back address. The subscription response (OK, failure) is proxied back to the originator. Calsyn, Dusseault & Mohr [Page 9] INTERNET-DRAFT RVP March 13, 1997 The subscription originator stores the timeout value (a date/time formatted with RFC 1123 as specified in schema draft), so that the originator can refresh the subscription before it times out. When the originator wishes to cancel the subscription, it can do so by specifying the subscription-ID. The same mechanism is used when the client goes offline, for any subscriptions listed as such. Issues: Can one person subscribe another person? How should we handle Reply-Tos that are different from the subscription requester? 5.1.8. Multiple client issues The issues for multiple clients connected at the same time haven't been worked out yet. Which ones should receive instant messages? If one client is "idle" and one client is "busy" what is the user marked as? Is there any way for another user to query the status of a particular client? E.g. to see if the desktop is idle while the laptop is active & vice-versa? Also, idea of addressing IM's to a particular online client? If multiple clients are connected, and the home server refers to one client, that client is primary. Other clients must send their status to the primary client. 6. Security 6.1. Authentication Users may log in to their home RVP server, but this is not required. Each request MAY contain user credentials, using HTTP syntax, in order to authenticate the user to the server which will actually process the request. Upon receiving a request for the return or 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. Return codes in HTTP style should be provided for indicating insufficient access rights. 6.2. Content Protection In addition to authentication contained in the headers and intended for server authorization, the content (contained in the entity) MAY be signed and or sealed according to prevailing MIME encoding, signing and encryption standards. Calsyn, Dusseault & Mohr [Page 10] INTERNET-DRAFT RVP March 13, 1997 This content signing/sealing is the mechanism for ensuring against message-stream modification, replay and/or repudiation. 6.3. Server-to-Server Security Servers may exchange server credentials along with user credentials. Servers which are acting on a request will use embedded credentials to authenticate and authorize the requesting user or process. Server implementations MAY choose to support SSL or other authentication mechanism, but this is generally redundant and highly consumptive of CPU resources. Private messages should be secured from endpoint to endpoint. 6.4. Privacy Issues Each RVP server MUST support and honor ACLs placed on objects and properties in order to preserve the privacy of users. These ACLs MUST allow the user to determine who may subscribe to, get properties from, put properties to, make/delete nodes within, and send messages to their user object and its child nodes. The ACLs MUST support access-granting and access-denying entries as described in [6] and SHOULD also support the ask-first qualifier. Ask-first is essentially a deny access control entry which alerts the user to the access attempt and allows the user to grant access to people who have been denied access by that entry. RVP servers MUST NOT reveal the network address of a connected user to any other server or client, except through a LINK property set by the user. 7. RVP Methods RVP messages use the generic message format of RFC822. Messages consist of a start-line, one or more header fields, an empty line (CRLF), and an optional message-body. The start-line contains the method name, a URL, and protocol version information. Generic message: [method] [URL] RVP/1.0 *message-header CRLF [message-body] 7.1. GET method (from HTTP) The GET method conforms to HTTP 1.1. Supported headers include request-ID, Date, Expires, From Via, content-length, content- type, authorization, organization, proxy-authorization, user- agent. Calsyn, Dusseault & Mohr [Page 11] INTERNET-DRAFT RVP March 13, 1997 In RVP, the GET method is used primarily to query properties such as the directory entry of a user object, or the number of members of a group object. The property itself is listed in the XML-body of the message. Where the property is unique to RVP, RVP is indicated as the namespace. Responses to the GET method are as defined by HTTP. 7.2. PUT method (from HTTP) The put method is used as in HTTP/1.1. It is used in RVP primarily to set property values that must be saved by the server. Once again, properties and values are identified via XML syntax. Responses to the PUT method are as defined by HTTP. 7.3. MKCOL (from DAV) This method results in the creation of a new child node. The method is defined in [7]. Responses to MKCOL as used in RVP should follow the DAV recommendations. 7.4. RMCOL (from DAV) This method results in the removal of a node and all nodes and properties within and below it. Also defined in [7]. Responses to RMCOL as used in RVP should follow the DAV recommendations. 7.5. ACL (from DAV) See DAV ACL draft [6] 7.6. SUBSCRIBE (introduced here) The Subscribe method is new and will be fully defined in this document. This is a new semantic method in the space of methods defined for HTTP and its derivatives. Care has been taken to make this method flexible enough to meet the needs of other applications, which may require subscription and notification methods. Responses to the SUBSCRIBE method are defined later in this document. 7.6.1. Reply-To header 7.6.2. Notification-type header The notification-type header is used to specify what the user wants to subscribe to. Events could include DEL, CREATE, MOVE, ANY, or could be defined in a very granular way with "XML". A value of "XML" in the notification-type header indicates that the notification-type is defined in the XML-body of the message. 7.6.3. Using XML to specify properties Calsyn, Dusseault & Mohr [Page 12] INTERNET-DRAFT RVP March 13, 1997 The body of the Subscribe message is text/XML, stating what properties the subscriber wishes to subscribe to. Using XML makes subscriptions very flexible: users can subscribe to a particular value of a property, or to a property being refreshed as well as changed. A subset of the full capabilities of XML will be used by RVP implementations designed to do presence information for people. This subset is not yet fully defined and the authors are aware that they need to work on it. XML uses namespaces to avoid confusion in property names. For RVP-specific properties, the namespace is 'rvp:'. Other possible namespaces could be `dav:' or `http://www.iana.org/vcard/' or a custom namespace like `http://host.org/namespaces/engineering'. In the XML-body of subscriptions, the RVP-specific field "event- type" is defined. The content of the event-type field could be any of the following examples: Value="offline" Value=[any value of any property] Query Subscribe Change Update Refresh ... The event-type is used along with the property field to indicate what kind of event the subscriber is interested in. For example, if the property is "status" and the event-type is "change", this is the way to monitor the online status of a user. The "value=..." is used when the subscriber wishes to be notified of a specific value of a property. A server implementation MUST support the "change" event-type. The properties that must be supported are defined in the RVP Schema specification [2]. There will be other event-types defined which the implementation MAY support. The examples below show the most common contents of an XML-body (i.e. for subscribing to a user's status) and should also provide an idea how new kinds of notifications could be defined. 7.7. UNSUBSCRIBE This new method is used to cancel a subscription before it times out. The Subscription-ID (provided by the publishing server) is used, along with the RVP address of the node being subscribed to, to specify uniquely which subscription should be cancelled. It is up to the server implementation to decide who can cancel subscriptions. 7.8. NOTIFY Calsyn, Dusseault & Mohr [Page 13] INTERNET-DRAFT RVP March 13, 1997 The NOTIFY method is introduced for two reasons: it is how subscriptions are responded to and how instant messages are sent. It has been suggested that a notification protocol use POST to send notifications and instant messages, because these types of messages fit into the initial definition of POST. However, others argue that overloading an existing method causes problems such as difficulties implementing firewall policies. The issue has not been closed yet. The NOTIFY method also requires a Reply-To header. It can use XML to specify what are recommended to be taken upon reception of the notification. 8. Responses 8.1. GET response 200 OK The GET response as used in RVP typically provides the value of the property that was queried. Format is like HTTP 1.1. The value of the property queried is included in the body of the response. The format of the property is indicated by MIME type in the content-type header. 8.2. SUBSCRIBE response Responses to SUBSCRIBE methods must include a response code (typically an error or OK/SUBSCRIBED). A successful response to a SUBSCRIBE method must include privacy- level and Subscription-ID headers. 8.2.1. Privacy-level The privacy-level of a subscription indicates whether this subscription may be shared. A privacy level of PUBLIC means that anybody can subscribe to the same data, and will receive the same responses. This can be used by proxies to reduce the amount of messages: if a proxy receives a second identical subscription to public data, the proxy need not subscribe a second time, but can simply forward the incoming data to all users subscribed to it. The proxy is responsible for maintaining a subscription list in this case. A privacy level of CONTROLLED means that access to this subscription is controlled, but all subscribers will receive the same information. A publishing server can use this to cut down on the number of notifications sent for the data. When a proxy Calsyn, Dusseault & Mohr [Page 14] INTERNET-DRAFT RVP March 13, 1997 receives two identical subscriptions, the proxy must forward both subscriptions so that the publishing server can return an error if either of those subscriptions is not allowed. The publishing server now maintains the full list of subscribers, even if some of those subscribers use the same proxy. When sending out notifications for that subscription, the publishing server can send only one notification to each unique Reply-To address. The XML body of the notification must include a fan-out list with the list of all subscribers known to the publishing server that had that Reply-To address. The proxy server need not maintain that same subscription list, but if it does it should reconcile the information with the received fan-out list. PRIVATE information is access-controlled and may not be identical for each subscriber, so no fan-out or single-instancing of subscriptions may be done. 8.3. Refer Could use HTTP response "302 Moved Temporarily" for refer 9. Transport Considerations for Datagrams and Connections RVP message transport differs from HTTP/1.1 in two prominent ways: - Like HTTP/1.1, TCP connections are assumed to be persistent, and multiple requests on such connections may be pipelined -- sent before responses to earlier requests have been received. However, RVP persistent TCP connections may carry requests and responses in either direction, and the responses may be delivered out-of-order relative to the requests that prompted them. - RVP offers the option of using connectionless, unreliable UDP as a transport. Except as otherwise noted, the policies and error-recovery behavior of RVP applications must comply with section 8 of the HTTP/1.1 specification. [5] 9.1. Choice of Transport An RVP client or server may choose to use either TCP or UDP when sending a request to a remote server. A likely basis for making the choice would be the size of the request (or expected response) and the maximal transmission unit (MTU) between source and destination: TCP's reliability becomes more useful with each multiple of the MTU required to send a message. Calsyn, Dusseault & Mohr [Page 15] INTERNET-DRAFT RVP March 13, 1997 Responses must use the same transport as the request which generated them. (Loosening this requirement deserves further investigation, as in the case where a small request, efficient to send over UDP, generates a large response, best sent by TCP. However, since this requires that the requestor accept inbound TCP, and additionally must be ready for a response to be the first message on an inbound connection, additional transport- negotiation constructs may be necessary to enable this scenario.) A mechanism (TBD) may be provided for a servers to specify that a particular resource is only available through one or the other transport. 9.1.1. Matching Responses To Requests RVP's UDP and persistent TCP pipelining allow the possibility that responses to outstanding requests will arrive out-of-order. Additionally, UDP responses are not associated with a request via a persistent connection, and if a request is retried while a response is in transit, a requestor may receive duplicate responses. Thus, requests MAY include a "Request-ID" header, which, if present, MUST be echoed in the response to a request. 9.2. UDP Retry Policy When using UDP transport, responses serve as the confirmation that the matching request was received. The lack of a timely response indicates either that the request should be resent or considered undeliverable, in accordance with the retry and timeout policies the requestor has adopted. RVP applications are free to choose their own policies for resending unacknowledged requests, within the following parameters: - A single request should be resent no more than 10 times. - A single request should be resent no more than once per second. - A single request should not be resent more than 90 seconds after the initial send. - If multiple retries fail to generate a received response within the desired amount of time, an application should wait at least 30 seconds before performing any operation which effectively restarts the retry-cycle on a similar transaction with the same remote host. Calsyn, Dusseault & Mohr [Page 16] INTERNET-DRAFT RVP March 13, 1997 For example, an acceptable retry policy within these parameters would be: resend a request every 3 seconds, up to 5 times, until a response is received; give up if no response is received within 30 seconds after the initial send, and refrain from sending a similar request to the same destination until 60 seconds after the initial send. Beyond these guidelines, applications are free to choose their own retry repetition, frequency, and timeout policies. By separate, explicit agreement (through mechanisms unspecified), communicating RVP programs may adopt retry policies outside these parameters. If responses are lost or delayed in transit, the responder may receive duplicates of an already-handled request. Subsequent requests from the same host and port, bearing the same "Request- ID", MUST be handled in a way that renders them idempotent (as defined in Section 9.1.2 of HTTP/1.1 [5]) within a reasonably long time window. (The above retry parameters suggest 3-5 minutes is a reasonably long window for recognizing duplicates.) (Open issue: Does DNS provide a better model for UDP retries?) 9.3. Mixed-Transport Through Proxies An RVP client may intially send a request via reliable TCP to its proxy, which may then use unreliable UDP to forward that request to its final destination. In all such cases, it is the responsibility of the RVP application which chose UDP transport to implement a retry and timeout policy. If a timely response is not received, the proxy machine must return a 504 ("Gateway Timeout") error-response to the request originator owed a reliable response. 10. Protocol Details 10.1. Identity URLs, Location URLs, and default port RVP identities and locations are both described as URL addresses, as specified in RFC1738. The scheme of a RVP URL is "rvp", and the syntax follows the "Common Internet Scheme Syntax" described in Section 3.1 of RFC1738. Further information about RVP URLs is available in [4]. It is always clear from context whether an RVP URL address is being used as an identity or a location. An identity URL may also Calsyn, Dusseault & Mohr [Page 17] INTERNET-DRAFT RVP March 13, 1997 be interpreted as the "canonical location" to interact with an object. For example, identity URLs are used in the "From" header, and as the principals in ACLs. Location URLs are used in the "Reply-To" header, and as the destination URLs of "LINK" properties (see section 9.X). Location URLs are not typically visible or useful for end-users. If not explicitly specified, the default port value in an RVP URL is XXXX. (TBD) 10.2. Headers Header fields follow the same generic header format as that given in Section 3.1 of RFC 822 [5]. Each header field consists of a name followed by a colon (":") and the field value. Field names are case insensitive. The field value may be preceded by any amount of leading white space (LWS), though a single space (SP) is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). Applications SHOULD follow HTTP "common form" when generating these constructs, since there might exist some implementations that fail to accept anything beyond the common forms. The order in which header fields are received is not significant if the header fields have different field names. Multiple header fields with the same field-name may be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (i.e., #(values)). It MUST be possible to combine the multiple header fields into one "field- name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded. Field names are not case sensitive, although their values may be. 10.2.1. Accept-charset As in HTTP/1.1, support for the ISO-8859-1 character set can be assumed. 10.2.2. Accept-encoding As in HTTP/1.1 10.2.3. Accept-Language Calsyn, Dusseault & Mohr [Page 18] INTERNET-DRAFT RVP March 13, 1997 As in HTTP/1.1 10.2.4. Allow As in http/1.1: used in 405 (Method Not Allowed) response to indicate which methods are allowed by a resource. In RVP, the resource will be either a RVP object or a property. 10.2.5. Authorization See section 14.8 of the HTTP/1.1 specification [5] 10.2.6. Reply-To Used with Subscribe, GET, notifications, etc. to specify where to send a response. 10.2.7. Content-Encoding See section 14.12 of the HTTP/1.1 specification [5]. 10.2.8. Content-Language See section 14.13 of the HTTP/1.1 specification [5]. 10.2.9. Content-Length See section 14.14 of the HTTP/1.1 specification [5]. 10.2.10. Content-Type See section 14.18 of the HTTP/1.1 specification [5]. 10.2.11. Date See section 14.19 of the HTTP/1.1 specification [5]. 10.2.12. From The RVP object that the message is from. Can be different from Reply-To. Requests MUST contain this header. Responses SHOULD contain this header. The 'From' header contains the RVP URL for the object that represents the user or process that initiated the request. See section 14.22 of the HTTP/1.1 specification [5]. 10.2.13. Host See section 14.23 of the HTTP/1.1 specification [5]: The Host request-header field specifies the Internet host and port number Calsyn, Dusseault & Mohr [Page 19] INTERNET-DRAFT RVP March 13, 1997 of the resource being requested, as obtained from the original URL given by the user or referring resource. 10.2.14. If-Modified-Since See section 14.24 of the HTTP/1.1 specification [5]. Used as a conditional in a GET request. 10.2.15. If-Unmodified-Since See section 14.28 of the HTTP/1.1 specification [5]. Used as a conditional in a GET request. 10.2.16. Last-Modified See section 14.29 of the HTTP/1.1 specification [5]. Used in a response to a GET request or the first response to a SUBSCRIBE. 10.2.17. Request-ID A token to uniquely identify a request to the requestor, opaque to the destination of a request. When generating a response to a request that has a "Request-ID" header, the "Request-ID" header must be including verbatim in the response 10.2.18. Server See section 14.39 of the HTTP/1.1 specification [5]. Optionally used to specify server software version. 10.2.19. Session-ID Sent with a NOTIFY message when there is no subscription-ID; used to maintain context in replies to that notification. 10.2.20. Subscription-ID Sent with a successful response to a subscription message. Used in future notifications which result from that subscription, or to cancel subscription. 10.2.21. Via As in HTTP/1.1, used when a message is proxied. 10.2.22. XML-body Used to specify ACL levels with the ACL method, and sometimes to specify notification-type. Not fully defined yet. In particular, the authors need to define what subset of all possible XML semantics must be supported by an implementation. Calsyn, Dusseault & Mohr [Page 20] INTERNET-DRAFT RVP March 13, 1997 It must be possible for a simple implementation to refuse complex XML bodies not defined as required in this draft. 10.3. Responses HTTP/1.1 responses are expanded to include these new codes or enhanced meaning: RVP/1.0 207 SUBSCRIBE RVP/1.0 ??? REFER (or we could use 302 "Moved Temporarily") Existing HTTP/1.1 responses used in RVP: HTTP/1.1 400 Bad Request (bad syntax) HTTP/1.1 401 Unauthorized (Need to get authenticated first) HTTP/1.1 402 Forbidden (ACLs forbid user to do that) HTTP/1.1 404 Not Found (object or property not found) HTTP/1.1 501 Not Implemented (method not understood by server) HTTP/1.1 503 Service Unavailable (i.e. too busy) 10.4. Proxying and Referral The default behavior for a RVP object on a server is for that server to respond to queries and subscriptions and receive instant messages for that object. However, there are exceptional circumstances. Both servers and clients can optionally support these features. Each RVP object may have a property named "LINK". The value of the LINK property is [link-method], [RVP-URL]. When the property is set using the PUT method, there may be a timeout property included with standard timeout syntax (never, date/time, logout). If the expiration is reached before the property value is refreshed, the server should reset the LINK property to NULL. The link-method can be PROXY, REFER, REFER-NOTIFICATIONS or LINK. The RVP-URL must be a full URL, including DNS address and path. Proxying a node means that rather than respond for the object, the server will forward requests to the address listed in the RVP-URL, and will also proxy replies. If the server is ever unable to proxy because the host has become unavailable, it should immediately timeout the LINK property and go back to handling queries itself. Proxies are intended to be used with firewalls: a RVP proxy can sit on a firewall and route messages. Referring an object means that the server will respond to any request, subscription or instant message with a referral to the address listed in the RVP-URL, requiring the originating client of the request, subscription or message to repeat it to the referred address. It may be desirable for the server to PING the referral address periodically to ensure that the referral is still valid: if the host is no longer available the value of LINK might go back to null. Calsyn, Dusseault & Mohr [Page 21] INTERNET-DRAFT RVP March 13, 1997 "REFER-NOTIFICATIONS" indicates that: - Unsolicited messages to the user should go to the referral address - Requests should continue to come to the object's home - Notifications in response to a subscription should continue to be sent to the Reply-To specified in the subscription. The Reply-To address should always be tried first. A LINK value of LINK typically indicates a link to the "real" home of the content requested: this allows content to be linked to from more than one node. One node is the real home for the object and all duplicate nodes link to the real home. When an entity decides to start hosting an object by setting the LINK field on that object's home node, it may wish to download all the object data including the subscription list from the server that was previously responsible for it. Ideally the GET command which asks for all the node’s data would be bundled with the PUT command which switches responsibility using the LINK property. If this is not possible, then the GET command should be done before the PUT LINK property command, because once the LINK property is in place the server will not respond directly to requests for that node and its contents are effectively hidden. The only request the server will respond directly to is a request to reset the LINK property. If the server does support the LINK property, then for any message to that server, the server must check each node and sub- node in the hierarchy starting from the root until it reaches the target node, checking each node for a LINK entry. If a LINK entry is encountered at any point, the server needs to follow the functionality defined by the link-method. If the server does not support the LINK property at all, it should respond to a PUT LINK command with an error that means "property not supported". If the server does not allow the sender to modify the LINK property, it should respond with an error that means "access denied". If the server supports the LINK property but not the PROXY functionality, then if it receives a command to set the link_method of the LINK property to PROXY, it should respond with an error that means "syntax not supported". Same thing if the REFER or LINK functionality is not supported. 10.5. Peer to peer Messaging Peer to peer communication can be desirable to lighten the load on servers. This can be done in several ways. Calsyn, Dusseault & Mohr [Page 22] INTERNET-DRAFT RVP March 13, 1997 10.5.1. Getting direct responses to requests When the client initiates communication by sending a message (a query, subscription or instant message), the client can send the message directly to the publishing server rather than to a proxy server. The sender header should include the full RVP Reply-To URL (e.g rvp://lisadu.host2.com/lisadu) as well as the full RVP identity of the user (e.g. rvp://rvp.host2.com/users/lisadu). When the response comes, it comes directly back to the client. In sending messages directly to the publishing server, the client reveals its DNS address and is therefore more open to attack, but the risk is limited by the fact that the IP address only goes to targets chosen by the user. If the initial message goes outside a firewall, that firewall must be able to pass incoming RVP messages (responses) to the RVP Reply-To URL. 10.5.2. Responding directly to notifications When the client receives a notification from a trusted source through the client's local proxy and wishes to continue the conversation, the client can choose to respond directly to that source rather than through the local proxy. Once again the Reply-To header points to the client machine and the From header points to the user's RVP object location. 10.5.3. Receiving instant messages directly If the client is willing to accept instant messages (unsolicited notifications) directly, it should set the LINK property for its RVP object on the server to REFER-NOTIFICATIONS plus its full client-side RVP URL. The timeout for this property should be set to a reasonable value in case the client goes offline unexpectedly. When the server receives unsolicited notifications (notifications which are not in response to a subscription) it can respond with a referral message including the REFER- NOTIFICATIONS and the client-side RVP URL. If the client is willing to accept unsolicited notifications and its server does not support the LINK property, then when the server proxies instant messages the client can respond with a success message and include the REFER-NOTIFICATIONS field, timeout, and URL itself. The proxy will forward this back to the original sender, who can now start using the client URL until the timeout listed. Queries and subscriptions should still be sent to the Reply-To address used in the original request message. 10.5.4. Receiving Requests Directly If a client wishes to handle queries and subscriptions to its user object data as well, it must ask the server to refer all messages, using the LINK property as outlined in the section on "Proxying, Referring and Linking nodes". Calsyn, Dusseault & Mohr [Page 23] INTERNET-DRAFT RVP March 13, 1997 10.6. Proxy and Referral Conflicts Note that the referral functionality allows clients to assume responsibility for their own user’s nodes, which means that the client becomes its own server. In the case where a user switches between clients (presumably on different hardware), this could lead to conflict. If client A sets the LINK property to proxy to A, then client B tries to sets the LINK property to proxy to B, what should happen? - If B does not have sufficient access, server responds with an error meaning "access denied". - Or, if the server does not allow a client to take over node which is already referred or proxied, the server can reply with an error meaning "locked" or something like that - Or, if the link_method of the LINK property is set to REFER, the server responds with a referral to client A. - Or, if the link_method of the LINK property is set to PROXY, the server proxies the PUT command to client A. When client A receives the PUT command for the LINK property, either through proxy or directly, it realizes that another client is trying to take control of the node. The options for client A are now: - Reply with an error "access denied" which is either proxied or sent directly to client B - Reply with a success message which is either proxied or sent directly to client B, after setting everything right on the server by refreshing all data on the node, including setting the LINK property to the new value given by client B. 11. Examples 11.1. Subscribing directly to status changes This example shows a client acting as its own server in subscribing directly to a user's RVP status. In this case the client MUST accept incoming connections because the publishing server needs to send notifications back to the client. Client to publishing server: SUBSCRIBE rvp://host.com/joeuser rvp/1.0 Notification-type: XML Reply-To: rvp://host2.com/lisadu From: rvp://host2.com/lisadu Content-type: text/XML Content-length: xyz Calsyn, Dusseault & Mohr [Page 24] INTERNET-DRAFT RVP March 13, 1997 [CRLF] change 06 Nov 1998 08:49:37 GMT rvp://host2.com/lisadu Publishing server to client (success): RVP/1.0 200 SUBSCRIBE Subscription-ID: 84 Content-type: text/xml From: rvp://host.com/joeuser [CRLF] online change 06 Nov 1998 08:49:37 GMT controlled Notice in this example that the publishing server set a lower timeout for the subscription than was requested by the subscriber. Notification sent as a result of this subscription: NOTIFY rvp://host.com/joeuser Subscription-ID: 84 Reply-To: rvp://host.com/joeuser From: rvp://host.com/joeuser Notification-type: XML Content-type: text/XML Content-length: xyz [CRLF] online change Refresh method for this subscription: Not yet defined. Unsubscribe method for this subscription: UNSUBSCRIBE rvp://host.com/joeuser rvp/1.0 Call-id: 84 11.2. Subscribing through a proxy to a group: Calsyn, Dusseault & Mohr [Page 25] INTERNET-DRAFT RVP March 13, 1997 Message from client to proxy: SUBSCRIBE rvp://host.com/groups/rvpdisc Notification-type: XML Reply-To: rvp://client.host2.com/lisadu From: rvp://rvp.host2.com/lisadu XML-body: message rvp://rvp.host2.com/lisadu Note that the Reply-To address is a URL to the user's client machine, whereas the subscriber-id is a pointer to a user's RVP object. Sometimes these are the same, but in this case the object is hosted on a RVP server, whereas the user receives messages at their client. Also note that no timeout is defined, because the user wants to use the max or default timeout for that subscription list. Message from proxy to publishing server: SUBSCRIBE rvp://host.com/groups/rvpdisc Notification-type: XML Reply-To: rvp://proxy.host2.com/lisadu From: rvp://rvp.host2.com/lisadu Via: RVP/1.0 rvp://proxy.host2.com/lisadu Content-type: text/XML Content-length: xyz [CRLF] message rvp://rvp.host2.com/lisadu Successful response from publishing server to proxy: RVP/1.0 200 SUBSCRIBE Subscription-ID: 1238 Content-type: text/xml Content-length: xyz From: rvp://host.com [CRLF] message 06 Nov 1998 08:49:37 GMT controlled Response forwarded from proxy to client: RVP/1.0 200 SUBSCRIBE Subscription-ID: 1238 Calsyn, Dusseault & Mohr [Page 26] INTERNET-DRAFT RVP March 13, 1997 Content-type: text/xml Body: [same body] Notification from publishing server (list server) to proxy: NOTIFY rvp://host.com/groups/rvpdisc RVP/1.0 Subscription-ID: 1238 Reply-To: rvp://fred.host3.com/fred From: rvp://host3.com/users/fred Notification-type: XML XML-body: Message high display rvp://rvp.host2.com/lisadu Content-type: text/plain [CRLF] Hey everybody, I've got something important to say. The same message is forwarded from the proxy to the subscriber, minus the fan-out list. The fan-out only shows one user, because only one user on this proxy is currently subscribed to the list. The original sender of the message is the user 'fred' on another system. His client machine address is listed as the Reply-To because responses to messages to this list are intended to go to the sender. (On other lists, the Reply-To might be the list itself, and the source would still be fred) 11.3. Setting ACLs on the status property Client to home server: ACL rvp://host.com/joeuser RVP/1.0 Content-type: text/XML [CRLF] grant subscribe rvp://host.com/lisadu deny subscribe rvp://host.com/baduser 11.4. Sending an instant message Client to target's home server: NOTIFY rvp://host.com/joeuser RVP/1.0 Reply-To: rvp://fred.host3.com/fred From: rvp://host3.com/users/fred Calsyn, Dusseault & Mohr [Page 27] INTERNET-DRAFT RVP March 13, 1997 Notification-type: XML Session-ID: 4321 XML-body: Message high display Content-type: text/plain Content-length: 7 [CRLF] Hi Joe. The action taken by the home server depends whether the home server refers instant messages or proxies them. If the home server proxies, it should send a notification to the client with the Reply-To replaced by its own RVP address. When it receives a success message, and forward the success message back to rvp://fred.host3.com/fred. If the home server refers instant messages to Joe's proxy or to Joe's machine, it replies back with a referral response: RVP/1.0 ??? REFER Session-ID: 4321 Referral-type: Notifications Referral-address: rvp://proxy.host.com/joeuser RVP/1.0 The referral-type header indicates which kinds of messages should go to the referred machine rather than to the home server. The only defined values so far are "notifications" and "all". In this case, requests (queries & subscriptions) for information should still go to the home server, but notifications (typically intended for the user's eyes) should go to the referred address IF THERE IS NO REPLY-TO SPECIFIED FOR THAT NOTIFICATION. The session-ID can also be used for future messages in the conversation between Joe and Fred, to provide context. 11.5. Inviting a user to a session defined by SIP Example is not done yet. It will be a NOTIFY message with a content-type of application/SIP and a body which is a SIP message. 12. REFERENCES [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [2] Dusseault L. and Bone J. "RVP Schemas", INTERNET-DRAFT , March 1998. Calsyn, Dusseault & Mohr [Page 28] INTERNET-DRAFT RVP March 13, 1997 [3] Dusseault L., "Presence Information Protocol Requirements", INTERNET-DRAFT , February 1998. [4] Dusseault L. and Mohr G. " Addressing and Location for RVP", INTERNET-DRAFT , March 1998. [5] Fielding R., Gettys J., Mogul J., Frystyk H. and Berners-Lee T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [6] Leach P. J. and Goland Y. Y., "WebDAV ACL Protocol", INTERNET-DRAFT , November 1997 [7] Goland Y. Y., Whitehead E. J., Faizi A., Carter S. R. and Jensen D., "Extensions for Distributed Authoring on the World Wide Web -- WEBDAV", INTERNET-DRAFT , January 1998. 13. Authors' Addresses Martin Calsyn Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: martinca@microsoft.com Fax: (425) 936-7329 Lisa Dusseault Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: lisadu@microsoft.com Fax: (425) 936-7329 Gordon Mohr Activerse, Inc. 1301 W. 25th St Suite 500 Austin, TX 78705 Email: gojomo@activerse.com Calsyn, Dusseault & Mohr [Page 29]