INTERNET-DRAFT Martin Calsyn Expires: May 1998 Microsoft Corporation Rendezvous Protocol draft-calsyn-rvp-00.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 the Rendez-Vous Protocol (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 this draft 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 RVP discussion list (addresses at the end of this draft). Calsyn [Page 1] INTERNET-DRAFT Rendezvous Nov 21, 1997 3. Contents 1. Status of this Memo........................................1 2. Abstract...................................................1 3. Contents...................................................2 4. Introduction...............................................3 4.1. Problem to be solved..................................3 4.2. Overview of RVP Functionality.........................4 4.2.1. Namespace ........................................4 4.2.2. Client-Server Interactions .......................4 4.2.3. Server-Server Interactions .......................5 4.3. Solution Requirements.................................6 4.4. Terminology...........................................7 4.5. Definitions...........................................7 4.6. Protocol Properties...................................8 4.6.1. General format ...................................8 4.6.2. Minimal State ....................................8 4.6.3. Transport-Protocol Neutral .......................8 4.6.4. Text-based .......................................9 4.7. RVP Addressing........................................9 5. Locating an RVP Server.....................................9 5.1.1. Clients locating servers .........................9 5.1.2. Servers locating servers ........................10 5.1.3. Clients Locating Users ..........................10 6. RVP Transport.............................................10 7. RVP Uniform Resource Locators.............................11 8. Proxy and Referral Semantics..............................11 9. The Minimal Namespace Schema..............................12 9.1.1. All Nodes .......................................12 9.1.2. Root Node (rvp://hostname) ......................12 9.1.3. Users Node (rvp://hostname/Users) ...............13 9.1.4. User Node (rvp://hostname/Users/username) .......13 9.1.5. User Status Node (rvp://hostname/Users/username/Status) ..................13 9.1.6. Classes Node (rvp://hostname/Classes) ...........14 10. Security..................................................14 10.1. Authentication.......................................14 10.2. Content Protection...................................14 10.3. Server-to-Server Security............................14 10.4. Privacy Issues.......................................15 11. Protocol Details..........................................15 11.1. Requests.............................................16 11.1.1. Request-Line ....................................16 11.1.2. Methods .........................................16 11.1.2.1. GET ........................................16 11.1.2.2. PUT ........................................16 11.1.2.3. MKCOL ......................................17 11.1.2.4. RMCOL ......................................17 11.2. Headers..............................................17 11.2.1. Authorization ...................................18 11.2.2. Date ............................................18 11.2.3. Expires .........................................18 11.2.4. From ............................................18 Calsyn [Page 2] INTERNET-DRAFT Rendezvous Nov 21, 1997 11.2.5. PEP .............................................18 11.2.6. Refresh .........................................18 11.2.7. Request-ID ......................................18 11.3. Responses............................................19 12. Example Transactions......................................19 12.1. Protocol transcripts.................................19 12.2. Client-server interaction examples...................19 12.2.1. Request for another user or node on same server .19 12.3. Request for information or subscription to user on a different home server. In this case, server1 is proxying the request to server2. ........................................20 12.3.1. Identical subscriptions from two users on same server 20 12.3.2. Request involving proxy server ..................20 13. REFERENCES................................................21 14. Authors' Addresses........................................21 4. Introduction 4.1. Problem to be solved With the rise of real-time interaction systems, including text, audio and video over computer networks, along with the rise of numerous forms of real-time gaming systems, there is a need for a given user to be able to determine if his or her peers are online. Along with this need for this status information, there is a need to be able to exchange brief perishable (time-critical) messages. In addition to the one-to-one discovery and messaging, there is also a need to be able to discover the availability of and to message with one or more previously unknown users with common interests. For instance, a given user might want to send a message to all users currently logged in and interested in initiating a particular type of gaming session. In addition to the above interpersonal interactions, similar needs exist for the same reliable, secure interactions between automated processes and people for business and systems management purposes. Existing solutions to the user discovery problem (such as ILS) and to the messaging problem (e-mail) alone and in combination lack key features (scalability, data replication, integration). This has led to the rollout of many independent, centralized and monolithic, and incompatible vendor solutions. The popularity of these solutions nonetheless 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. Calsyn [Page 3] INTERNET-DRAFT Rendezvous Nov 21, 1997 4.2. Overview of RVP Functionality 4.2.1. Namespace A single RVP server hosts a hierarchy of named nodes. Each node can have properties, subscriptions and child nodes associated with it. A client or peer server can: . Get or set properties . Add or remove subscriptions . Create new child nodes . Put content to a node All of the above operations are gated by access control entries on each node. The access control lists are themselves properties of a node. `Putting' content to a node does not make any persistent change to the node, but does transmit the content to all clients (or peer servers) subscribed to that node. In order that servers may interact with each other and so that clients may interact with servers, a mandatory minimal schema is defined for the hierarchy of nodes. Individual implementations and even individual instances of servers can extend this schema, but must implement the minimal schema. NOTE: It may be desirable to define a meta-schema through which the minimal schema and any local extensions may be discovered on-the-fly. NOTE: The authors recognize that definition of the schema is perhaps best left to an entirely separate draft with this draft just addressing the wire protocol. This change will be considered for the next revision of the draft. The proposed minimal schema defines a space for nodes representing users and a space for nodes representing other notification/messaging classes. The distinction though is purely notational. The operational differences between user nodes and other nodes are purely driven by the access control entries on those nodes. The topmost node in any server's namespace is the name of that server. The RVP server on rvp.wingnuts.com might own the whole namespace for wingnuts.com or might partition that namespace among subordinate servers. The actual mechanisms of proxy and referral are described later in this document. Individual nodes in RVP namespace are identified by a Universal Resource Identifier syntax [RFC XXXX]. 4.2.2. Client-Server Interactions Calsyn [Page 4] INTERNET-DRAFT Rendezvous Nov 21, 1997 An RVP client is any endpoint process which participates in the RVP protocol on behalf of a user. A client can also act as a server by hosting rvp namespace. Clients which do not host namespace can converse with servers. Clients which do host namespace can converse with servers, but can also converse with other clients. This latter scenario represents a performance enhancement by facilitating peer-to-peer client interactions, but it also represents a slight reduction in security by directly exposing client addresses to other clients. In the remainder of this document, the term `client' refers to a process or portion of a process that does not host namespace. The term `server' is used to refer to a process or portion of a process that does host namespace. Nothing precludes a single process from acting as both client and server. A client may communicate with any convenient server. A client process discovers convenient servers by consulting DNS SRV records [RFC 2052], DHCP announcements, referral from another server, or per-user/per-machine local configuration information. A client may converse with a single server and send all requests to that server which in turn proxies the requests to other servers as appropriate, or a client may choose to open connections to multiple servers, including those which also host client functionality. Sending requests to a single local server allows the local server and a given remote server to `single- instance' responses to subscriptions, thus reducing network traffic. Opening multiple connections allows for the possibility of client peer-to-peer interactions reducing the potential for `choke points' at busy servers. A client process representing a user would, as part of its initialization, PUT properties to that user's node indicating that user's status and availability for various types of interactions. That same client process would update the status property as the user's status or preferences change. It should be noted that the user's node may not be local to the server to which the client process is currently attached. The proxy/referral mechanism takes care of getting the transactions to the correct server. The URI for that user's node determines which is the `correct' server. A client process representing an automated process would probably not announce it's presence in the above fashion, but might get and put properties, subscribe to content and properties, or put content to a node as part of it's operation. Examples include a fortune-cookie server, a system for announcing server status, or a stock transaction system. 4.2.3. Server-Server Interactions Calsyn [Page 5] INTERNET-DRAFT Rendezvous Nov 21, 1997 An RVP server is any process which hosts an RVP namespace. Servers interact with other servers using the same protocol as client-to-server interactions. Upon receiving a transaction, a server may respond by processing that transaction locally, updating its local persistent or dynamic data (including its property store and transient list of subscriptions) and by announcing the new data to any subscribed clients and peers. A given server can also respond by proxying the transaction to another server or by referring the requestor (client or peer server) to another server. When handling subscription requests, the requesting server passes on the request to the target server, but in issuing notifications against a subscription, the target server (the server now initiating the notification) should aggregate multiple notifications into a single response. So, subscription requests from a client always get registered verbatim at the target server so that the target server is aware of who is subscribing to its data. But, in issuing responses, the target server (now sourcing a notification) need only notify each unique server in its subscription list. This means that if server A has 100 users subscribing to a message class on server B, server B will be aware of all 100 subscriptions, but will return only one notification to server A. Server A must then `fan out' that notification to the 100 local users. 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. 4.3. Solution Requirements From the problems described above, here are the requirements: In the general case: 1. Scaleable to entire Internet, current and foreseeable future 2. Minimize network traffic: Message duplication is avoided where possible 3. Client IP addresses are known only to the local server Calsyn [Page 6] INTERNET-DRAFT Rendezvous Nov 21, 1997 4. Provide rich extensibility 5. Provide for delivery of complex content 6. Provide support for endpoint-to-endpoint security across untrusted links. 7. Provide a well-defined minimal namespace schema 8. Provide a well-defined mechanism for updating and querying properties. 9. Provide a well-defined mechanism for subscribing to and delivering notifications. 10. Firewall-friendly 11. Responsive For the user location and messaging sub-case: (all of which must be supported within the mechanisms of the general case) 12. There is a well-defined way to find the address of a user. 13. There is a well-defined way to see if a user is online 14. Users can control whether or not to publish their information and to whom 15. Users can audit who is tracking their status (in general, subscriptions may be listed) 16. Access control lists support `ask-first' semantics 17. Support person-to-person instant messaging 18. Support interest-classified messaging 19. Support media negotiation and session initiation 4.4. 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.5. 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 namespace of its own. This may also be referred to as a User Agent when it is a client which serves the needs of a human user. Client and server functionality may exist within a single process. Content: MIME-encapsulated data transmitted in the entity portion of an RVP transaction Calsyn [Page 7] INTERNET-DRAFT Rendezvous Nov 21, 1997 Node: A named vertex in an RVP tree Property: A named attribute of an RVP node 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 hosts RVP namespace and can accept connections from peer servers and optionally from RVP clients. Subscription: A subscription is a request that will result in multiple responses, one for each change in the subscribed property and/or one for each item of content `put' to the subscribed node. User: A single human (is that too restrictive?). We use the term `user' in the common fashion to refer to a person who might operate one or more instances of the client software. 4.6. Protocol Properties 4.6.1. General format The RVP protocol generally fits the HTTP [reference] model. Where we have used HTTP protocol elements, we will defer to the HTTP definition of those elements. 4.6.2. Minimal State 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 need not be persisted and may be dropped if the server goes `down'. Subscriptions for a given client may be discarded if the TCP connection to that client is broken (by either the client or the server), since clients are required to re-subscribe whenever reconnecting. 4.6.3. Transport-Protocol Neutral RVP is able to utilize both UDP and TCP as transport protocols. Servers MUST implement both UDP and TCP transport. Abbreviated headers are defined to facilitate UDP interactions between servers for cases where the transaction will fit wholly within the MTU. Transactions between servers which do not fit within the MTU are sent via TCP link. In general, clients will communicate with servers via TCP, but MAY optionally also support UDP interactions. Calsyn [Page 8] INTERNET-DRAFT Rendezvous Nov 21, 1997 4.6.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. 4.7. RVP Addressing The target of an RVP request is always a node in the RVP namespace. Nodes are identified by URI syntax. A long and short form is available. The long-form or fully-qualified URI follows the syntax set out in RFC XXXX: rvp://hostname/path The hostname component is used to resolve to the server or servers which own the namespace containing the target node. The particular server may be located via DNS SRV [RFC 2052] query (see: Locating RVP servers, below). The path identifies a particular node in that server's namespace. The short-form syntax is designed to map user identities to a well-known location in the minimal schema and is defined as follows: username@hostname And this translates directly into rvp://hostname/Users/username [NOTE: This may be an unnecessary construct. Can't the client do this translation internally and just deal with fully- qualified URI's?] 5. Locating an RVP Server 5.1.1. Clients locating servers Clients will locate a server topologically near them through one of the following mechanisms, listed in decreasing preference order: . Via a DHCP parameter specifying the preferred server . By resolving their local hostname and contacting the server associated with that domain in DNS SRV records [RFC 2052] . By resolving their local domain and contacting rvp.{domain} . By utilizing configuration data specific to the client process. While this is the least preferred mechanism, it may override the other mechanisms if present. Calsyn [Page 9] INTERNET-DRAFT Rendezvous Nov 21, 1997 In addition to the above methods, a client may also encounter a server by receiving a referral to that new server in response to a request. 5.1.2. Servers locating servers Servers locate other servers for proxying and referring records by the following mechanism. This mechanism presumes that the server has already rewritten the target URL via its proxy/referral rules and is now trying to resolve the target IP address: 1. If there is a SRV DNS resource record of type rvp.udp, contact the listed RVP servers in order of preference value using UDP as a transport protocol at the port number listed in the DNS resource record. This step may be omitted if the transaction exceeds the UDP MTU. 2. If there is a SRV DNS resource record of type rvp.tcp, contact the listed RVP servers in order of preference value using TCP as a transport protocol at the port number listed in the DNS resource record. 3. If there is a DNS MX record, contact the hosts listed in their order of preference at the default port number (TBD). For each host listed, first try to contact the server using UDP (if applicable), then TCP. 4. Finally, check if there is a DNS CNAME or A record for the given host and try to contact an RVP server at the one or more addresses listed, again trying first UDP, then TCP. 5.1.3. Clients Locating Users The RVP user-status reporting requires that the watcher be able to supply a canonical address for the watchee. Client programs which wish to help users determine these canonical addresses should include or cooperate with a directory browsing user agent _ an LDAP client for instance. The user can use that agent to find the desired user and enter their canonical address. The RVP system is not designed to supplant existing directory services. 6. RVP Transport Client-server RVP interactions MAY occur via TCP/IP or UDP. Any client which uses UDP to issue subscriptions MUST be able to accept TCP connections for delivery of content which exceeds the MTU. Servers MUST accept both TCP and UDP transactions though MAY choose to issue only TCP connections. Calsyn [Page 10] INTERNET-DRAFT Rendezvous Nov 21, 1997 7. RVP Uniform Resource Locators RVP URLs are used in RVP requests and request and response headers to indicate the originator and target of an RVP message, and to specify redirection addresses. RVP-URL = short-url | long-url short-url = name @ host | host "/" node-path long-url = "rvp://" [ "!" password] host [ ":" port ] "/" message-class [ "?" headers ] name = firstname "." lastname host = defined in RFC 1738 port = *digit node-path = node-name | node-name "/" node-path node-name = alphanumeric atom headers = "?" header [ ";" headers ] header = hname "=" hvalue Note that all URL reserved characters must be encoded. Examples of user URLs: juser@microsoft.com Joe.User@microsoft.com rvp://microsoft.com/users/juser rvp://microsoft.com/users/juser/status Examples of general-purpose node URLs: rvp://rvp.widgets.com/engineering/SDE rvp://rvp.widgets.com/engineering/SDE/announce rvp://rvp.widgets.com/engineering/SDE/discussion 8. Proxy and Referral Semantics Each RVP server MUST have a server-internal scheme for determining which requests can be satisfied locally and which must be proxied, referred or rejected. Calsyn [Page 11] INTERNET-DRAFT Rendezvous Nov 21, 1997 This can be as simple as rejecting any request that cannot be satisfied within the local namespace. It SHOULD at least allow for returning a proxy or referral response for non-local namespaces. For instance, a server might be configured to answer all queries to *widgets.com, but to proxy all other requests to the proper server. Likewise, a pair of servers might respond to [a- l]*@*widgets.com and [m-z]*@*.widgets.com respectively and refer queries to each other as appropriate. 9. The Minimal Namespace Schema All RVP servers MUST implement at least the following minimum schema within their namespace. NOTE: The authors are considering separating all schema issues into a separate draft document for the next revision. 9.1.1. All Nodes Properties: Requestors List of users requesting access via the ask- first access control element Subscribers List of users currently subscribed to this node ACL The access control list for this node. The ACL is broken into components which separately control access to the node (subscription, publication of content), and access to individual properties, including the acl itself. ACL components not specifically overridden are inherited from the parent node. Link An optional parameter which refers queries to another point in the namespace. The data is an URL representing the new location for this node. That new location may be on another server. All queries at or below this node will get referred to the same relative position in link-target namespace. 9.1.2. Root Node (rvp://hostname) Properties: none defined at this time Children: Users The user status and messaging hierarchy Classes The general-purpose messaging and notification hierarchy. This hierarchy contains nodes for one-to- many interactions (e.g., the community of all users Calsyn [Page 12] INTERNET-DRAFT Rendezvous Nov 21, 1997 looking for a gaming partner for a particular game for instance) or other applications of instant messaging and properties for user or automated interaction. Schema [NOTE: This is not currently defined, but is intended to be a place where client and server peers could retrieve schema information describing the data on this server. The schema would be formatted according to a fixed meta schema.] 9.1.3. Users Node (rvp://hostname/Users) Properties: none defined at this time Children: username One child node exists for each user address recognized by this local system. 9.1.4. User Node (rvp://hostname/Users/username) Properties: Alias A string representing the canonical local address for this user. This can be used to map Joe.User to juser. No child nodes are expected in the presence of an Alias property, and vice-versa _ they are mutually exclusive. Children: Status A node containing user status information. The default acl on this node allows only the user to write to it. The user may designate who may read from it and thus control who may view their status. Message The default acl for this node allows only the user `username' to subscribe. The user may designate others who may write content to this node. This node facilitates `instant messaging' with the user. 9.1.5. User Status Node (rvp://hostname/Users/username/Status) Properties: CurrentStatus The current status (online, offline, busy) of the named user. LastOn The last time this user reported their status as online. LastOff The last time this user reported any status other than online. Calsyn [Page 13] INTERNET-DRAFT Rendezvous Nov 21, 1997 Children: None defined 9.1.6. Classes Node (rvp://hostname/Classes) Properties: none defined at this time Children: site-defined The Classes node is a free-form portion of the namespace which individual servers and sites may define as they see fit. For instance, a site might choose to define Public and Private subtrees where the public hierarchy allows users to create their own nodes and the Private hierarchy is for the publication of site defined data (e.g, fortune cookies, weather forcasts, hosted discussions, etc.). 10. Security 10.1. Authentication Users do not `log in' to an RVP server. 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 requiring 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 are provided for indicating insufficient access rights. 10.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. This content signing/sealing is the mechanism for ensuring against message-stream modification, replay and/or repudiation. 10.3. Server-to-Server Security It is not anticipated that servers will authenticate to each other. Messages should be secured from endpoint to endpoint making further server-to-server security redundant. 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 Calsyn [Page 14] INTERNET-DRAFT Rendezvous Nov 21, 1997 authentication mechanism, but this is generally redundant and highly consumptive of CPU resources. In cases where a server must authenticate to another server for purposes of 10.4. Privacy Issues Each user node in an RVP server MUST support and honor ACLs placed on the Status and Message sub-trees in order to preserve the privacy of users. These ACLs MUST allow the user to, at a minimum, determine who may subscribe to, get properties from, put properties to, make/delete nodes within, and put content to nodes in their sub-tree. The ACLs MUST support access-granting and access-denying entries as described in [ref XML acl doc] and SHOULD also support the ask-first qualifier. Ask-first is essentially a deny access control entry which alerts the user to the access attemp 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. 11. Protocol Details Both request and Response messages use the generic message format of RFC 822 for transferring entities (the payload of the message). Both types of message consist of a start-line, one or more header fields (also known as `headers'), an empty line (i.e., a line with nothing preceding the carriage-return line- feed (CRLF)) indicating the end of the header fields, and an optional message-body. To avoid confusion with similar-named headers in HTTP, we refer to the header describing the message body as entity headers. These components are described in detail in the upcoming sections. generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line | Status-Line Request = Request-Line *( general-header | request-header | entity-header ) CRLF [ message-body ] Response = Status-Line *( general-header | response-header | entity-header ) Calsyn [Page 15] INTERNET-DRAFT Rendezvous Nov 21, 1997 CRLF [ message-body ] In the interest of robustness, any leading empty line(s) MUST be ignored. In other words, if the Request or Response message begins with a CRLF, the CRLF should be ignored. 11.1. Requests general-header = Request-ID | Date | Expires | From | Via entity-header = Content-Length | Content-Type request-header = Authorization | Organization | Proxy-Authorization | Refresh | Subject | To | User-Agent response-header = Location | Proxy-Authenticate | Server | Warning | WWW-Authenticate 11.1.1. Request-Line The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. SP characters separate the elements. No CR or LF is allowed except in the final CRLF sequence. Request-Line = Method SP Request-URI SP RVP-Version CRLF 11.1.2. Methods 11.1.2.1. GET Identical to the HTTP/1.1 syntax _ properties are queried via XML [ref] syntax. ACLs are named properties. Headers may be used to specify that this is a subscription to the named properties and/or to any content PUT to this node. The headers may also specify the minimum notification interval. A client may re-issue a GET with the same Call-ID and immediate- expiry Expires header to unsubscribe. 11.1.2.2. PUT Calsyn [Page 16] INTERNET-DRAFT Rendezvous Nov 21, 1997 Identical to the HTTP/1.1 syntax _ properties are set via XML syntax. ACLs are named properties. Entity data outside of XML property syntax is broadcast to all subscribers. Servers MAY choose to archive transactions, but beyond setting properties and archiving content, do not need to persist PUT data. Note that the extension to the Expires header below can cause some property changes to be rolled back or committed when a user session ends. This is to facilitate user status changes triggered by a (possibly unintentional) client disconnect. 11.1.2.3. MKCOL This method results in the creation of a new child node. 11.1.2.4. RMCOL This method results in the removal of a node and all nodes and properties within and below it. 11.2. Headers Header fields (general-header, request-header, response-header, and entity-header) follow the same generic header format as that given in Section 3.1 of RFC 822. 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. message-header = field-name ":" [ field-value ] CRLF field-name = token field-value = *( field-content | LWS ) field-content = < the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, tspecials, and quoted-string> 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 Calsyn [Page 17] INTERNET-DRAFT Rendezvous Nov 21, 1997 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. Headers listed in the syntax section, but not described below have their documented HTTP meanings. [NOTE: need to eliminate the above paragraph and list each header] 11.2.1. Authorization See [HTTP/1.1 14.8] 11.2.2. Date See [H14.19]. 11.2.3. Expires This gives the date/time when the GET subscription expires. It is also used to set an expiry for a PUT on a user status property. It is ignored for non-subscription GETs and all other PUTs and other methods. [NOTE: Need to specify the exact syntax for expiry time, `never' expires, and expires-on-disconnect. Also need to specify the exact behavior for the expiration of a PUT. That is, how does one determine what values to roll properties back to.] 11.2.4. From Requests MUST contain this header. Responses SHOULD contain this header. The From header contains the RVP URL for the identity which initiated the request. 11.2.5. PEP PEP headers may be used as documented in RFC XXXX to extend the base protocol. 11.2.6. Refresh Used in a GET, this changes the GET from a one-time retrieval of data into a continuing retrieval (subscription). There is an immediate 100-series response followed by subsequent 100-series responses each time the subscribed properties change and each time content is posted to the indicated node. 11.2.7. Request-ID Calsyn [Page 18] INTERNET-DRAFT Rendezvous Nov 21, 1997 The request-id uniquely identifies a request and may be used to refresh or cancel a standing GET (subscription) without having to re-issue the entire transaction. 11.3. Responses HTTP/1.1 responses are expanded to include these new codes or enhanced meaning: [TODO : to be included] 12. Example Transactions 12.1. Protocol transcripts [NOTE : TODO: include sample client-server and server-server session transcripts] 12.2. Client-server interaction examples 12.2.1. Request for another user or node on same server Note that this exchange happens whether user 2 (u2) is online or not. The home server for u2, which has u2's persistent data (perhaps phone number or email address) can answer requests for those persistent data or accept a subscription request (perhaps a request to be notified when u2 becomes online). Note also that there may be more than one reply if the request is a subscription. (1) GET -------------------> ___________ u1 <------------------- | | (2) >=1 Reply | Server | | | u2 |___________| Calsyn [Page 19] INTERNET-DRAFT Rendezvous Nov 21, 1997 12.3. Request for information or subscription to user on a different home server. In this case, server1 is proxying the request to server2. (1) GET u1 --------------------> ____________ <-------------------- | | (5) >=1 Reply | Server1 |--> (2) DNS Lookup |____________| | A (3) GET | | (4) >=1 Reply v | ____________ | | u2 | Server2 | |____________| The DNS Lookup step will be omitted from future diagrams. 12.3.1. Identical subscriptions from two users on same server Here both u2 and u1 are on the same server, making the same subscription to u3's home server. Server1 passes each subscription on to server2 so that server2 has a record of who is subscribing to its resources, but server2 only needs to send notifications once to Server1. (1) GET (subscription) ____________ u1 --------------------> | | <-------------------> | Server1 | (4,7) >=1 Reply | | | | (4) GET (subscription)| | u2 --------------------> | | <-------------------> |____________| (6,7) >=1 Reply | A | | (2,5) GET (subs)| | (3,6) Initial resp v | (7) >= 0 subsequent resps ____________ | | u3 | Server2 | |____________| 12.3.2. Request involving proxy server In this example, u2's domain has implemented a proxy server for its firewall. U1 is on the `inside' of the firewall. For outbound requests, the proxy server routes the request to the Calsyn [Page 20] INTERNET-DRAFT Rendezvous Nov 21, 1997 correct RVP server as determined via DNS. For inbound requests, the proxy server routes the request to the correct server on the inside of the firewall based on heuristics local to the proxy server. The "via" headers should show the proxy in the path of the request and reply. (1) Request u1 --------------------> ____________ <-------------------- | | (6) >=1 Reply | Server1 | |____________| | A (2) Request | | (5) >=1 Reply v | ____________ | | -------Firewall----------| Proxy |----------- |____________| | A (3) Request | | (4) >=1 Reply v | ____________ | | u2 | Server2 | |____________| A proxy server will not typically have local users, but nothing in this document prohibits that scenario. 13. REFERENCES [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 14. 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 Calsyn [Page 21] INTERNET-DRAFT Rendezvous Nov 21, 1997 Redmond, WA 98052 EMail: lisadu@microsoft.com Fax: (425) 936-7329 Calsyn [Page 22]