idnits 2.17.1 draft-calsyn-rvp-01.txt: ** The Abstract section seems to be numbered -(34): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(366): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(367): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(373): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1080): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1167): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 29) being 65 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 411 instances of too long lines in the document, the longest one being 97 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 31 has weird spacing: '... A new kind ...' == Line 39 has weird spacing: '...esigned to en...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'URL' on line 547 -- Looks like a reference, but probably isn't: 'RVP-URL' on line 1038 -- Looks like a reference, but probably isn't: 'CRLF' on line 1388 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2068 (ref. '5') (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Martin Calsyn 2 Expires: Sept 1998 Lisa Dusseault 3 Microsoft Corporation 4 Gordon Mohr 5 Activerse 7 RVP: A Presence Notification Protocol 8 draft-calsyn-rvp-01.txt 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as "work 21 in progress." 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 27 Coast), or ftp.isi.edu (US West Coast). 29 2. Abstract 31 A new kind of application is emerging on the Internet, driven 32 by the desire of individuals to know instantly whether another 33 individual is online, to be notified when another individual 34 arrives online, and to send messages in �real time�. These are 35 all special cases of the more general problem of Internet-wide 36 notification. 38 This protocol for facilitating rendezvous between users, known 39 herein as RVP, is designed to enable such notifications and 40 messages across a loosely coupled (federated) constellation of 41 servers. RVP is designed to address the need for notification in 42 a secure, reliable and scaleable fashion. RVP encompasses the 43 client-server and server-server interactions. 45 The authors recognize that there is significant overlap with 46 between RVP and HTTP, though there are also significant 47 differences. We expect RVP to evolve and either converge or 48 diverge with HTTP and/or other existing protocols. The protocol 49 described in this document represents a very viable starting 50 point for a discussion of a standardized solution to the problem. 52 Comments on this draft are solicited and should be sent to the 53 authors or the RVP discussion list. To join the RVP discussion 54 list, send email with the body "subscribe" to rvp- 55 request@iastate.edu. 57 3. Contents 59 1. Status of this Memo.........................................1 60 2. Abstract....................................................1 61 3. Contents....................................................2 62 4. Introduction................................................4 63 4.1. Problem to be solved..................................4 64 4.2. Terminology...........................................4 65 4.3. Definitions...........................................4 66 4.4. Protocol Properties...................................5 67 4.4.1. General format....................................5 68 4.4.2. Minimal State.....................................5 69 4.4.3. Transport-Protocol Neutral........................6 70 4.4.4. Text-based........................................6 71 5. Overview of RVP Functionality...............................6 72 5.1.1. Naming and Location of RVP Objects................6 73 5.1.2. RVP Object Schemas................................7 74 5.1.3. RVP Clients.......................................7 75 5.1.4. Home Servers......................................8 76 5.1.5. Proxies...........................................8 77 5.1.6. Server-Server Interactions........................8 78 5.1.7. Subscriptions.....................................9 79 5.1.8. Multiple client issues...........................10 80 6. Security...................................................10 81 6.1. Authentication.......................................10 82 6.2. Content Protection...................................10 83 6.3. Server-to-Server Security............................11 84 6.4. Privacy Issues.......................................11 85 7. RVP Methods................................................11 86 7.1. GET method (from HTTP)...............................11 87 7.2. PUT method (from HTTP)...............................12 88 7.3. MKCOL (from DAV).....................................12 89 7.4. RMCOL (from DAV).....................................12 90 7.5. ACL (from DAV).......................................12 91 7.6. SUBSCRIBE (introduced here)..........................12 92 Reply-To header.........................................12 93 7.6.2. Notification-type header.........................12 94 7.6.3. Using XML to specify properties..................12 95 7.7. UNSUBSCRIBE..........................................13 96 7.8. NOTIFY...............................................13 97 8. Responses..................................................14 98 8.1. GET response.........................................14 99 8.2. SUBSCRIBE response...................................14 100 8.2.1. Privacy-level....................................14 101 8.3. Refer................................................15 102 9. Transport Considerations for Datagrams and Connections.....15 103 9.1. Choice of Transport..................................15 104 9.1.1. Matching Responses To Requests...................16 105 9.2. UDP Retry Policy.....................................16 106 9.3. Mixed-Transport Through Proxies......................17 107 10. Protocol Details..........................................17 108 10.1. Identity URLs, Location URLs, and default port.......17 109 10.2. Headers..............................................18 110 10.2.1.Accept-charset...................................18 111 10.2.2.Accept-encoding..................................18 112 10.2.3.Accept-Language..................................18 113 10.2.4.Allow............................................19 114 10.2.5.Authorization....................................19 115 10.2.6.Reply-To.........................................19 116 10.2.7.Content-Encoding.................................19 117 10.2.8.Content-Language.................................19 118 10.2.9.Content-Length...................................19 119 10.2.10.Content-Type....................................19 120 10.2.11.Date............................................19 121 10.2.12.From............................................19 122 10.2.13.Host............................................19 123 10.2.14.If-Modified-Since...............................20 124 10.2.15.If-Unmodified-Since.............................20 125 10.2.16.Last-Modified...................................20 126 10.2.17.Request-ID......................................20 127 10.2.18.Server..........................................20 128 10.2.19.Session-ID......................................20 129 10.2.20.Subscription-ID.................................20 130 10.2.21.Via.............................................20 131 10.2.22.XML-body........................................20 132 10.3. Responses............................................21 133 10.4. Proxying and Referral................................21 134 10.5. Peer to peer Messaging...............................22 135 10.5.1.Getting direct responses to requests.............23 136 10.5.2.Responding directly to notifications.............23 137 10.5.3.Receiving instant messages directly..............23 138 10.5.4.Receiving Requests Directly......................23 139 10.6. Proxy and Referral Conflicts.........................24 140 11. Examples..................................................24 141 11.1. Subscribing directly to status changes...............24 142 11.2. Subscribing through a proxy to a group:..............26 143 11.3. Setting ACLs on the status property..................27 144 11.4. Sending an instant message...........................27 145 11.5. Inviting a user to a session defined by SIP..........28 146 12. REFERENCES................................................28 147 13. Authors' Addresses........................................29 149 4. Introduction 151 4.1. Problem to be solved 153 With the rise of real-time interaction systems, including text, 154 audio and video over computer networks, there is a need for a 155 user to be able to determine if his or her peers are online. 156 Along with this need for status information, users wish to 157 exchange brief, perishable, and perhaps time-critical messages. 159 Users also want to exchange messages with groups of users with 160 common interests. For instance, a given user might want to send 161 a message to all users currently logged in who have indicated 162 interest in a gaming session. Like individual users, the online 163 status of a group can be published. 164 A similar need exists for reliable, secure notifications and 165 messages between people and automated processes, for business and 166 systems management purposes. 167 Existing protocols, such as SIP for session initiation, LDAP for 168 user information and SMTP for messaging, overlap somewhat with 169 the problem domain defined here. However, these protocols lack 170 key features such as scalability, latency, data replication, and 171 integration. This has led to many independent, centralized, 172 monolithic and incompatible vendor solutions. The popularity of 173 these non-interoperable solutions is an indication of the need to 174 address the problem. 176 This draft is an attempt to address the problem space in a 177 generalized fashion that allows different server and client 178 implementations to interact within a secure internet-wide 179 infrastructure. 181 The PIP Requirements draft [3] discusses in more detail the 182 nature of this problem and requirements for solutions. 183 4.2. Terminology 184 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 185 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 186 "MAY" and "OPTIONAL" are to be interpreted as described in RFC 187 2119 [1] and indicate requirement levels for compliant RVP 188 implementations. 190 4.3. Definitions 192 This specification uses a number of terms to refer to the roles 193 played by participants in RVP communications and the kinds of 194 messages passed between them. 196 Client: A software process or portion of a process which connects 197 to RVP server(s) but hosts no RVP objects. Client and server 198 functionality may exist within a single process. 200 Content: MIME-encapsulated data transmitted in the body of an RVP 201 transaction 202 Node: A named vertex in an RVP tree, which can map to an object. 204 Property: A named attribute of an RVP object. 206 Request: A query for information initiated by a server or client 207 and targeted at a server. Requests result in one or more 208 responses. 210 Response: The returned result of a request. A server may return 211 one or more responses in answer to a request. 213 Server: A software process which can host RVP objects and can 214 accept connections from other entities sending messages to or 215 requesting data from those objects. Alternatively, a pure proxy 216 server does not host RVP objects but can still accept connections 217 on behalf of another process which does host RVP objects. 219 Subscription: A subscription is a request that will result in 220 multiple responses, one for each change in the subscribed 221 property or one for each message sent to the subscribed object. 223 User: A single human; a person who might operate one or more 224 instances of the client software; a human represented by a RVP 225 �user� object. 227 4.4. Protocol Properties 229 RVP is designed to be a useful notification protocol for various 230 purposes, but its primary purpose is notifying users of property 231 changes on other user objects. This draft covers both generic 232 notification mechanisms and specific people presence issues. 233 Most of the generic notification mechanisms are discussed in this 234 draft. Most of the specific people-presence issues are covered 235 in the user and group schemas of the schema draft [2]. 237 4.4.1. General format 239 The RVP protocol generally fits the HTTP [5] model. Where we 240 have used HTTP protocol elements, we defer to the HTTP definition 241 of those elements. RVP-specific information is general 242 transferred in new commands or by specifying the RVP namespace in 243 XML-formatted data within the XML body of an HTTP protocol 244 element. Use of XML in this way might allow a RVP server to 245 coexist with an HTTP server. XML is used in order to provide 246 flexibility and extensibility. 248 Parsing of messages should follow HTTP recommendations. Port 80 249 may be used. 251 4.4.2. Minimal State 252 An effort has been made to minimize the amount of state that a 253 running server must maintain. A server is required to maintain a 254 list of the subscriptions it currently holds while running. 255 Subscriptions for a given client may be discarded if the 256 connection to that client is broken, or if the publishing server 257 receives a message that the subscriber is offline, but the 258 publishing server should inform the subscriber that their 259 subscription was dropped. For most objects, clients are required 260 to re-subscribe whenever reconnecting. 262 Issue: should subscriptions be dropped if the server goes down? 264 4.4.3. Transport-Protocol Neutral 266 RVP is able to utilize both UDP and TCP as transport protocols. 267 Servers MUST implement both UDP and TCP transport. Clients MUST 268 support TCP and MAY support UDP interactions. 270 Abbreviated headers should be defined to facilitate UDP 271 interactions between servers for cases where the transaction will 272 fit wholly within the MTU. Transactions between servers that do 273 not fit within the MTU are sent via TCP link. 275 4.4.4. Text-based 276 RVP is text-based. This allows easy implementation in languages 277 such as Tcl and Perl, allows easy debugging, and most 278 importantly, makes RVP flexible and extensible. 280 5. Overview of RVP Functionality 282 5.1.1. Naming and Location of RVP Objects 284 Every RVP object has an authoritative address, which is a URL. 285 This URL serves not only as a unique name, but also a pointer to 286 the location where the object usually resides. For more 287 information on RVP URLs and finding addresses and servers, see 288 [4]. 290 A single RVP server can host a hierarchy of nodes that correspond 291 to objects. Each object must have certain properties, and each 292 node may have child nodes. A client or peer server can attempt 293 to: 295 - Get or put properties on objects 296 - Add or remove subscriptions on objects 297 - Create new child nodes 298 - Send notifications/messages to an object 300 All of the above operations are gated by access control entries 301 on each object. 303 A node has a persistent location in this hierarchy, on this 304 server, throughout its life. If a set of content moves away from 305 a node and users should still be able to find that content, then 306 the server should link, refer or proxy to the new node. 308 5.1.2. RVP Object Schemas 310 In order that clients can query known properties of objects, a 311 required minimal schema is defined for each object. Individual 312 implementations and individual instances of servers can extend 313 this schema, but must implement the minimal schema. The minimal 314 schema, along with schemas for user and group objects, are 315 defined separately in [2]. 317 5.1.3. RVP Clients 319 An RVP client is any endpoint process that uses the RVP protocol 320 on behalf of a user. A client can also act as its server by 321 hosting rvp objects. Clients that do not host objects can only 322 converse with servers. Clients that do host objects can converse 323 with other clients as well as servers. Note that Client-to- 324 client interaction may enhance performance, but it results in a 325 reduction in security by directly exposing client IP addresses. 326 In client-to-client interaction, both clients act as their own 327 servers. 329 In the remainder of this document, client requirements are for 330 the process or portion of a process that interfaces with the 331 user. Server requirements are for the process or portion of a 332 process that hosts objects, subscribes directly to publishing 333 servers, or otherwise needs to be contacted directly. Nothing 334 precludes a single process from acting as both client and server. 335 The referral and proxy mechanisms discussed later in this 336 document allow users who have their content hosted on a server 337 while offline to switch to hosting their own content while 338 online. 340 We require that a client be able to receive messages such as 341 instant messages and notifications. This can be done in three 342 ways: 343 - The client maintains an open TCP connection to their proxy 344 server. All queries, subscriptions and notifications from outside 345 are sent to the proxy server, which sends messages to the client 346 as appropriate. The user's canonical RVP address as listed for 347 instant messages and the Reply-To address for subscriptions must 348 be on their proxy server which is also their home server, OR the 349 home server with the canonical address can refer to the proxy. 350 The user's RVP address as listed for queries and subscriptions 351 must be on their home server. 353 - The client listens an open port, accepting connections ONLY 354 from their home server. All queries, subscriptions and 355 notifications from outside are sent to the server, and the server 356 opens up a connection to the client and sends whichever messages 357 are appropriate. RVP address restrictions are as above. 358 - The client listens on an open port, accepting connections from 359 any source. The client may now act as its own server. Messages 360 that are sent to the home server may be redirected to the client. 361 The user can then be addressed at either their home server or at 362 their local client & server machine. Any client that does this 363 must follow all RVP requirements for a server. 365 A client process representing a user must, as part of its 366 initialization, PUT values for properties to that user�s object 367 (wherever it is hosted). These properties indicate the user�s 368 status and availability for various types of interactions. The 369 same client process must update the properties as they change. 371 A client process representing an automated process could get and 372 put properties, subscribe to content, or send content out as part 373 of it�s operation. Examples include a fortune-cookie server, a 374 system for announcing server status, or a stock transaction 375 system. 377 5.1.4. Home Servers 379 A user's home server is the server that most consistently hosts 380 their data, particularly while the user is offline. This is also 381 the server pointed to by the user's canonical RVP address. The 382 home server may also act as a proxy. 384 5.1.5. Proxies 386 Sending requests to a proxy can reduce network traffic. The 387 proxy can maintain only one subscription for public data, which 388 means that if many of that proxy's users subscribe to the same 389 data, the number of messages is greatly reduced. 391 For controlled data, the proxy must send one subscription request 392 for every RVP object that wishes to subscribe, so that the 393 publishing server may check ACLs. However, the number of 394 messages is still low: the publishing server need only send one 395 response to the proxy, which fans responses out to the individual 396 subscribers. 398 A proxy server may also be the home server for a user. If the 399 proxy server is different from the home server, and the client 400 does not accept incoming connections from any source, then the 401 client must either maintain a connection to the proxy or listen 402 on a port accepting messages from the proxy. 404 5.1.6. Server-Server Interactions 406 An RVP server can be any process that hosts RVP objects, proxies 407 RVP messages, or receives RVP messages directly from any sender. 409 Servers interact with other servers using the same protocol as 410 client-to-server interactions. 412 Upon receiving a message, a server may respond by processing that 413 message locally, updating its local persistent or dynamic data, 414 proxying the message, or responding with an error. 416 Because this represents a certain amount of dynamic state in the 417 server, the client must refresh subscriptions whenever restoring 418 a connection to a server and the server may throw away 419 subscriptions when a client disconnects. Some connectionless 420 interactions with servers need to be refreshed periodically. 422 Client-server connections may be via UDP or TCP/IP and server- 423 server connections may be via UDP or TCP. TCP and UDP 424 interactions and client-server/server-server interactions are 425 defined below in such a way to minimize dynamic server state 426 while preserving network bandwidth and giving the clients a 427 predictable level of reliability. 429 5.1.7. Subscriptions 431 Subscriptions are usually registered ultimately at the server 432 that publishes information. The exception is the case where a 433 proxy that receives a new subscription request already has a 434 subscription to that data AND the data is public. Since the 435 proxy will already be getting notifications on that data, the 436 proxy can fan out notifications to individual end-points. Since 437 the first subscription always goes to the publishing server, and 438 the response indicates whether the data is public or controlled, 439 the proxy knows how to handle additional subscriptions. 441 A subscription request always includes: 442 - The source of the subscription (for access control) 443 - The call-back address 444 - Desired timeout value for subscription 445 The response to a subscription always includes: 446 - Whether the events being subscribed to are public or 447 controlled 448 - What the subscription-ID is (so it can be referred to if it 449 needs to be cancelled) 450 - What timeout was assigned to the subscription 451 - Whether the subscription must be cancelled if the subscriber 452 goes offline 454 If a client subscribes to a proxy server which in turn subscribes 455 to a publishing server, then the client's RVP address is listed 456 as the source, but the proxy's address is listed as the call-back 457 address. The subscription response (OK, failure) is proxied back 458 to the originator. 460 The subscription originator stores the timeout value (a date/time formatted with RFC 1123 as specified in schema draft), so that 461 the originator can refresh the subscription before it times out. 462 When the originator wishes to cancel the subscription, it can do 463 so by specifying the subscription-ID. The same mechanism is used 464 when the client goes offline, for any subscriptions listed as 465 such. 466 Issues: Can one person subscribe another person? How should we 467 handle Reply-Tos that are different from the subscription 468 requester? 470 5.1.8. Multiple client issues 472 The issues for multiple clients connected at the same time 473 haven't been worked out yet. Which ones should receive instant 474 messages? If one client is "idle" and one client is "busy" what 475 is the user marked as? 477 Is there any way for another user to query the status of a 478 particular client? E.g. to see if the desktop is idle while the 479 laptop is active & vice-versa? Also, idea of addressing IM's to 480 a particular online client? 482 If multiple clients are connected, and the home server refers to 483 one client, that client is primary. Other clients must send 484 their status to the primary client. 486 6. Security 488 6.1. Authentication 490 Users may log in to their home RVP server, but this is not 491 required. Each request MAY contain user credentials, using HTTP 492 syntax, in order to authenticate the user to the server which 493 will actually process the request. 495 Upon receiving a request for the return or modification of 496 information, the server processing the request MUST validate the 497 authentication and honor any access control list entries which 498 might gate the completion of the request. 499 Return codes in HTTP style should be provided for indicating 500 insufficient access rights. 502 6.2. Content Protection 503 In addition to authentication contained in the headers and 504 intended for server authorization, the content (contained in the 505 entity) MAY be signed and or sealed according to prevailing MIME 506 encoding, signing and encryption standards. 508 This content signing/sealing is the mechanism for ensuring 509 against message-stream modification, replay and/or repudiation. 511 6.3. Server-to-Server Security 513 Servers may exchange server credentials along with user 514 credentials. Servers which are acting on a request will use 515 embedded credentials to authenticate and authorize the requesting 516 user or process. Server implementations MAY choose to support 517 SSL or other authentication mechanism, but this is generally 518 redundant and highly consumptive of CPU resources. 520 Private messages should be secured from endpoint to endpoint. 522 6.4. Privacy Issues 524 Each RVP server MUST support and honor ACLs placed on objects and 525 properties in order to preserve the privacy of users. These ACLs 526 MUST allow the user to determine who may subscribe to, get 527 properties from, put properties to, make/delete nodes within, and 528 send messages to their user object and its child nodes. The ACLs 529 MUST support access-granting and access-denying entries as 530 described in [6] and SHOULD also support the ask-first qualifier. 531 Ask-first is essentially a deny access control entry which alerts 532 the user to the access attempt and allows the user to grant 533 access to people who have been denied access by that entry. 535 RVP servers MUST NOT reveal the network address of a connected 536 user to any other server or client, except through a LINK 537 property set by the user. 539 7. RVP Methods 541 RVP messages use the generic message format of RFC822. Messages 542 consist of a start-line, one or more header fields, an empty line 543 (CRLF), and an optional message-body. The start-line contains the 544 method name, a URL, and protocol version information. 545 Generic message: 547 [method] [URL] RVP/1.0 548 *message-header 549 CRLF 550 [message-body] 552 7.1. GET method (from HTTP) 554 The GET method conforms to HTTP 1.1. Supported headers include 555 request-ID, Date, Expires, From Via, content-length, content- 556 type, authorization, organization, proxy-authorization, user- 557 agent. 559 In RVP, the GET method is used primarily to query properties such 560 as the directory entry of a user object, or the number of members 561 of a group object. The property itself is listed in the XML-body 562 of the message. Where the property is unique to RVP, RVP is 563 indicated as the namespace. 565 Responses to the GET method are as defined by HTTP. 567 7.2. PUT method (from HTTP) 569 The put method is used as in HTTP/1.1. It is used in RVP 570 primarily to set property values that must be saved by the 571 server. Once again, properties and values are identified via XML 572 syntax. Responses to the PUT method are as defined by HTTP. 574 7.3. MKCOL (from DAV) 576 This method results in the creation of a new child node. The 577 method is defined in [7]. Responses to MKCOL as used in RVP 578 should follow the DAV recommendations. 580 7.4. RMCOL (from DAV) 582 This method results in the removal of a node and all nodes and 583 properties within and below it. Also defined in [7]. Responses 584 to RMCOL as used in RVP should follow the DAV recommendations. 586 7.5. ACL (from DAV) 588 See DAV ACL draft [6] 590 7.6. SUBSCRIBE (introduced here) 592 The Subscribe method is new and will be fully defined in this 593 document. This is a new semantic method in the space of methods 594 defined for HTTP and its derivatives. Care has been taken to make 595 this method flexible enough to meet the needs of other applications, 596 which may require subscription and notification methods. 598 Responses to the SUBSCRIBE method are defined later in this 599 document. 601 7.6.1. Reply-To header 603 7.6.2. Notification-type header 605 The notification-type header is used to specify what the user 606 wants to subscribe to. Events could include DEL, CREATE, MOVE, 607 ANY, or could be defined in a very granular way with "XML". A 608 value of "XML" in the notification-type header indicates that the 609 notification-type is defined in the XML-body of the message. 610 7.6.3. Using XML to specify properties 611 The body of the Subscribe message is text/XML, stating what 612 properties the subscriber wishes to subscribe to. Using XML 613 makes subscriptions very flexible: users can subscribe to a 614 particular value of a property, or to a property being refreshed 615 as well as changed. A subset of the full capabilities of XML 616 will be used by RVP implementations designed to do presence 617 information for people. This subset is not yet fully defined and 618 the authors are aware that they need to work on it. 619 XML uses namespaces to avoid confusion in property names. For 620 RVP-specific properties, the namespace is 'rvp:'. Other possible 621 namespaces could be `dav:' or `http://www.iana.org/vcard/' or a 622 custom namespace like `http://host.org/namespaces/engineering'. 624 In the XML-body of subscriptions, the RVP-specific field "event- 625 type" is defined. The content of the event-type field could be 626 any of the following examples: 627 Value="offline" 628 Value=[any value of any property] 629 Query 630 Subscribe 631 Change 632 Update 633 Refresh 634 ... 636 The event-type is used along with the property field to indicate 637 what kind of event the subscriber is interested in. For example, 638 if the property is "status" and the event-type is "change", this 639 is the way to monitor the online status of a user. The 640 "value=..." is used when the subscriber wishes to be notified of 641 a specific value of a property. 643 A server implementation MUST support the "change" event-type. 644 The properties that must be supported are defined in the RVP 645 Schema specification [2]. There will be other event-types 646 defined which the implementation MAY support. 648 The examples below show the most common contents of an XML-body 649 (i.e. for subscribing to a user's status) and should also provide 650 an idea how new kinds of notifications could be defined. 652 7.7. UNSUBSCRIBE 654 This new method is used to cancel a subscription before it times 655 out. The Subscription-ID (provided by the publishing server) is 656 used, along with the RVP address of the node being subscribed to, 657 to specify uniquely which subscription should be cancelled. 659 It is up to the server implementation to decide who can cancel 660 subscriptions. 662 7.8. NOTIFY 663 The NOTIFY method is introduced for two reasons: it is how 664 subscriptions are responded to and how instant messages are sent. 666 It has been suggested that a notification protocol use POST to 667 send notifications and instant messages, because these types of 668 messages fit into the initial definition of POST. However, 669 others argue that overloading an existing method causes problems 670 such as difficulties implementing firewall policies. The issue 671 has not been closed yet. 672 The NOTIFY method also requires a Reply-To header. It can use 673 XML to specify what are recommended to be taken upon reception of 674 the notification. 676 8. Responses 678 8.1. GET response 680 200 OK 682 The GET response as used in RVP typically provides the value of 683 the property that was queried. Format is like HTTP 1.1. 685 The value of the property queried is included in the body of the 686 response. The format of the property is indicated by MIME type 687 in the content-type header. 689 8.2. SUBSCRIBE response 691 Responses to SUBSCRIBE methods must include a response code 692 (typically an error or OK/SUBSCRIBED). 694 A successful response to a SUBSCRIBE method must include privacy- 695 level and Subscription-ID headers. 697 8.2.1. Privacy-level 699 The privacy-level of a subscription indicates whether this 700 subscription may be shared. 702 A privacy level of PUBLIC means that anybody can subscribe to the 703 same data, and will receive the same responses. This can be used 704 by proxies to reduce the amount of messages: if a proxy receives 705 a second identical subscription to public data, the proxy need 706 not subscribe a second time, but can simply forward the incoming 707 data to all users subscribed to it. The proxy is responsible for 708 maintaining a subscription list in this case. 709 A privacy level of CONTROLLED means that access to this 710 subscription is controlled, but all subscribers will receive the 711 same information. A publishing server can use this to cut down 712 on the number of notifications sent for the data. When a proxy 713 receives two identical subscriptions, the proxy must forward both 714 subscriptions so that the publishing server can return an error 715 if either of those subscriptions is not allowed. The publishing 716 server now maintains the full list of subscribers, even if some 717 of those subscribers use the same proxy. When sending out 718 notifications for that subscription, the publishing server can 719 send only one notification to each unique Reply-To address. The 720 XML body of the notification must include a fan-out list with the 721 list of all subscribers known to the publishing server that had 722 that Reply-To address. The proxy server need not maintain that 723 same subscription list, but if it does it should reconcile the 724 information with the received fan-out list. 725 PRIVATE information is access-controlled and may not be identical 726 for each subscriber, so no fan-out or single-instancing of 727 subscriptions may be done. 729 8.3. Refer 731 Could use HTTP response "302 Moved Temporarily" for refer 733 9. Transport Considerations for Datagrams and Connections 735 RVP message transport differs from HTTP/1.1 in two prominent 736 ways: 738 - Like HTTP/1.1, TCP connections are assumed to be persistent, 739 and multiple requests on such connections may be pipelined -- 740 sent before responses to earlier requests have been received. 741 However, RVP persistent TCP connections may carry requests and 742 responses in either direction, and the responses may be delivered 743 out-of-order relative to the requests that prompted them. 745 - RVP offers the option of using connectionless, unreliable UDP 746 as a transport. 748 Except as otherwise noted, the policies and error-recovery 749 behavior of RVP applications must comply with section 8 of the 750 HTTP/1.1 specification. [5] 752 9.1. Choice of Transport 754 An RVP client or server may choose to use either TCP or UDP when 755 sending a request to a remote server. A likely basis for making 756 the choice would be the size of the request (or expected 757 response) and the maximal transmission unit (MTU) between source 758 and destination: TCP's reliability becomes more useful with each 759 multiple of the MTU required to send a message. 761 Responses must use the same transport as the request which 762 generated them. (Loosening this requirement deserves further 763 investigation, as in the case where a small request, efficient to 764 send over UDP, generates a large response, best sent by TCP. 765 However, since this requires that the requestor accept inbound 766 TCP, and additionally must be ready for a response to be the 767 first message on an inbound connection, additional transport- 768 negotiation constructs may be necessary to enable this scenario.) 770 A mechanism (TBD) may be provided for a servers to specify that a 771 particular resource is only available through one or the other 772 transport. 774 9.1.1. Matching Responses To Requests 776 RVP's UDP and persistent TCP pipelining allow the possibility 777 that responses to outstanding requests will arrive out-of-order. Additionally, UDP responses are not associated with a request via 778 a persistent connection, and if a request is retried while a 779 response is in transit, a requestor may receive duplicate 780 responses. 782 Thus, requests MAY include a "Request-ID" header, which, if 783 present, MUST be echoed in the response to a request. 785 9.2. UDP Retry Policy 787 When using UDP transport, responses serve as the confirmation 788 that the matching request was received. The lack of a timely 789 response indicates either that the request should be resent or 790 considered undeliverable, in accordance with the retry and 791 timeout policies the requestor has adopted. 793 RVP applications are free to choose their own policies for 794 resending unacknowledged requests, within the following 795 parameters: 797 - A single request should be resent no more than 10 times. 798 - A single request should be resent no more than once per 799 second. 800 - A single request should not be resent more than 90 seconds 801 after the initial send. 802 - If multiple retries fail to generate a received response 803 within the desired amount of time, an application should wait at 804 least 30 seconds before performing any operation which 805 effectively restarts the retry-cycle on a similar transaction 806 with the same remote host. 808 For example, an acceptable retry policy within these parameters 809 would be: resend a request every 3 seconds, up to 5 times, until 810 a response is received; give up if no response is received within 811 30 seconds after the initial send, and refrain from sending a 812 similar request to the same destination until 60 seconds after 813 the initial send. 815 Beyond these guidelines, applications are free to choose their 816 own retry repetition, frequency, and timeout policies. By 817 separate, explicit agreement (through mechanisms unspecified), 818 communicating RVP programs may adopt retry policies outside these 819 parameters. 821 If responses are lost or delayed in transit, the responder may 822 receive duplicates of an already-handled request. Subsequent 823 requests from the same host and port, bearing the same "Request- 824 ID", MUST be handled in a way that renders them idempotent (as 825 defined in Section 9.1.2 of HTTP/1.1 [5]) within a reasonably 826 long time window. (The above retry parameters suggest 3-5 minutes 827 is a reasonably long window for recognizing duplicates.) 829 (Open issue: Does DNS provide a better model for UDP retries?) 831 9.3. Mixed-Transport Through Proxies 833 An RVP client may intially send a request via reliable TCP to its 834 proxy, which may then use unreliable UDP to forward that request 835 to its final destination. In all such cases, it is the 836 responsibility of the RVP application which chose UDP transport 837 to implement a retry and timeout policy. If a timely response is 838 not received, the proxy machine must return a 504 ("Gateway 839 Timeout") error-response to the request originator owed a 840 reliable response. 842 10. Protocol Details 844 10.1. Identity URLs, Location URLs, and default port 846 RVP identities and locations are both described as URL addresses, 847 as specified in RFC1738. The scheme of a RVP URL is "rvp", and 848 the syntax follows the "Common Internet Scheme Syntax" described 849 in Section 3.1 of RFC1738. Further information about RVP URLs is 850 available in [4]. 852 It is always clear from context whether an RVP URL address is 853 being used as an identity or a location. An identity URL may also 854 be interpreted as the "canonical location" to interact with an 855 object. 857 For example, identity URLs are used in the "From" header, and as 858 the principals in ACLs. Location URLs are used in the "Reply-To" 859 header, and as the destination URLs of "LINK" properties (see 860 section 9.X). Location URLs are not typically visible or useful 861 for end-users. 863 If not explicitly specified, the default port value in an RVP URL 864 is XXXX. (TBD) 866 10.2. Headers 868 Header fields follow the same generic header format as that given 869 in Section 3.1 of RFC 822 [5]. Each header field consists of a 870 name followed by a colon (":") and the field value. Field names 871 are case insensitive. The field value may be preceded by any 872 amount of leading white space (LWS), though a single space (SP) 873 is preferred. Header fields can be extended over multiple lines 874 by preceding each extra line with at least one SP or horizontal 875 tab (HT). Applications SHOULD follow HTTP "common form" when 876 generating these constructs, since there might exist some 877 implementations that fail to accept anything beyond the common 878 forms. 880 The order in which header fields are received is not significant 881 if the header fields have different field names. Multiple header 882 fields with the same field-name may be present in a message if 883 and only if the entire field-value for that header field is 884 defined as a comma-separated list (i.e., #(values)). It MUST be 885 possible to combine the multiple header fields into one "field- 886 name: field-value" pair, without changing the semantics of the 887 message, by appending each subsequent field-value to the first, 888 each separated by a comma. The order in which header fields with 889 the same field-name are received is therefore significant to the 890 interpretation of the combined field value, and thus a proxy MUST 891 NOT change the order of these field values when a message is 892 forwarded. 894 Field names are not case sensitive, although their values may be. 896 10.2.1. Accept-charset 898 As in HTTP/1.1, support for the ISO-8859-1 character set can be 899 assumed. 901 10.2.2. Accept-encoding 903 As in HTTP/1.1 905 10.2.3. Accept-Language 906 As in HTTP/1.1 908 10.2.4. Allow 910 As in http/1.1: used in 405 (Method Not Allowed) response to 911 indicate which methods are allowed by a resource. In RVP, the 912 resource will be either a RVP object or a property. 914 10.2.5. Authorization 916 See section 14.8 of the HTTP/1.1 specification [5] 918 10.2.6. Reply-To 920 Used with Subscribe, GET, notifications, etc. to specify where to 921 send a response. 923 10.2.7. Content-Encoding 925 See section 14.12 of the HTTP/1.1 specification [5]. 927 10.2.8. Content-Language 929 See section 14.13 of the HTTP/1.1 specification [5]. 931 10.2.9. Content-Length 933 See section 14.14 of the HTTP/1.1 specification [5]. 935 10.2.10. Content-Type 937 See section 14.18 of the HTTP/1.1 specification [5]. 939 10.2.11. Date 941 See section 14.19 of the HTTP/1.1 specification [5]. 943 10.2.12. From 945 The RVP object that the message is from. Can be different from 946 Reply-To. 948 Requests MUST contain this header. Responses SHOULD contain this 949 header. The 'From' header contains the RVP URL for the object 950 that represents the user or process that initiated the request. 952 See section 14.22 of the HTTP/1.1 specification [5]. 954 10.2.13. Host 956 See section 14.23 of the HTTP/1.1 specification [5]: The Host 957 request-header field specifies the Internet host and port number 958 of the resource being requested, as obtained from the original 959 URL given by the user or referring resource. 961 10.2.14. If-Modified-Since 963 See section 14.24 of the HTTP/1.1 specification [5]. Used as a 964 conditional in a GET request. 966 10.2.15. If-Unmodified-Since 968 See section 14.28 of the HTTP/1.1 specification [5]. Used as a 969 conditional in a GET request. 971 10.2.16. Last-Modified 973 See section 14.29 of the HTTP/1.1 specification [5]. Used in a 974 response to a GET request or the first response to a SUBSCRIBE. 976 10.2.17. Request-ID 978 A token to uniquely identify a request to the requestor, opaque 979 to the destination of a request. When generating a response to a 980 request that has a "Request-ID" header, the "Request-ID" header 981 must be including verbatim in the response 983 10.2.18. Server 985 See section 14.39 of the HTTP/1.1 specification [5]. Optionally 986 used to specify server software version. 988 10.2.19. Session-ID 990 Sent with a NOTIFY message when there is no subscription-ID; used 991 to maintain context in replies to that notification. 993 10.2.20. Subscription-ID 995 Sent with a successful response to a subscription message. Used 996 in future notifications which result from that subscription, or 997 to cancel subscription. 999 10.2.21. Via 1001 As in HTTP/1.1, used when a message is proxied. 1003 10.2.22. XML-body 1005 Used to specify ACL levels with the ACL method, and sometimes to 1006 specify notification-type. Not fully defined yet. In 1007 particular, the authors need to define what subset of all 1008 possible XML semantics must be supported by an implementation. 1010 It must be possible for a simple implementation to refuse complex 1011 XML bodies not defined as required in this draft. 1013 10.3. Responses 1015 HTTP/1.1 responses are expanded to include these new codes or 1016 enhanced meaning: 1017 RVP/1.0 207 SUBSCRIBE 1018 RVP/1.0 ??? REFER (or we could use 302 "Moved Temporarily") 1020 Existing HTTP/1.1 responses used in RVP: 1022 HTTP/1.1 400 Bad Request (bad syntax) 1023 HTTP/1.1 401 Unauthorized (Need to get authenticated first) 1024 HTTP/1.1 402 Forbidden (ACLs forbid user to do that) 1025 HTTP/1.1 404 Not Found (object or property not found) 1026 HTTP/1.1 501 Not Implemented (method not understood by server) 1027 HTTP/1.1 503 Service Unavailable (i.e. too busy) 1029 10.4. Proxying and Referral 1031 The default behavior for a RVP object on a server is for that 1032 server to respond to queries and subscriptions and receive 1033 instant messages for that object. However, there are exceptional 1034 circumstances. Both servers and clients can optionally support 1035 these features. 1037 Each RVP object may have a property named "LINK". The value of 1038 the LINK property is [link-method], [RVP-URL]. When the property 1039 is set using the PUT method, there may be a timeout property 1040 included with standard timeout syntax (never, date/time, logout). 1041 If the expiration is reached before the property value is 1042 refreshed, the server should reset the LINK property to NULL. 1044 The link-method can be PROXY, REFER, REFER-NOTIFICATIONS or LINK. 1045 The RVP-URL must be a full URL, including DNS address and path. 1047 Proxying a node means that rather than respond for the object, 1048 the server will forward requests to the address listed in the 1049 RVP-URL, and will also proxy replies. If the server is ever 1050 unable to proxy because the host has become unavailable, it 1051 should immediately timeout the LINK property and go back to 1052 handling queries itself. Proxies are intended to be used with 1053 firewalls: a RVP proxy can sit on a firewall and route messages. 1055 Referring an object means that the server will respond to any 1056 request, subscription or instant message with a referral to the 1057 address listed in the RVP-URL, requiring the originating client 1058 of the request, subscription or message to repeat it to the 1059 referred address. It may be desirable for the server to PING the 1060 referral address periodically to ensure that the referral is 1061 still valid: if the host is no longer available the value of LINK 1062 might go back to null. 1064 "REFER-NOTIFICATIONS" indicates that: 1065 - Unsolicited messages to the user should go to the referral 1066 address 1067 - Requests should continue to come to the object's home 1068 - Notifications in response to a subscription should continue to 1069 be sent to the Reply-To specified in the subscription. The 1070 Reply-To address should always be tried first. 1072 A LINK value of LINK typically indicates a link to the "real" 1073 home of the content requested: this allows content to be linked 1074 to from more than one node. One node is the real home for the 1075 object and all duplicate nodes link to the real home. 1076 When an entity decides to start hosting an object by setting the 1077 LINK field on that object's home node, it may wish to download 1078 all the object data including the subscription list from the 1079 server that was previously responsible for it. Ideally the GET 1080 command which asks for all the node�s data would be bundled with 1081 the PUT command which switches responsibility using the LINK 1082 property. If this is not possible, then the GET command should 1083 be done before the PUT LINK property command, because once the 1084 LINK property is in place the server will not respond directly to 1085 requests for that node and its contents are effectively hidden. 1086 The only request the server will respond directly to is a request 1087 to reset the LINK property. 1089 If the server does support the LINK property, then for any 1090 message to that server, the server must check each node and sub- 1091 node in the hierarchy starting from the root until it reaches the 1092 target node, checking each node for a LINK entry. If a LINK 1093 entry is encountered at any point, the server needs to follow the 1094 functionality defined by the link-method. 1095 If the server does not support the LINK property at all, it 1096 should respond to a PUT LINK command with an error that means 1097 "property not supported". If the server does not allow the 1098 sender to modify the LINK property, it should respond with an 1099 error that means "access denied". If the server supports the 1100 LINK property but not the PROXY functionality, then if it 1101 receives a command to set the link_method of the LINK property to 1102 PROXY, it should respond with an error that means "syntax not 1103 supported". Same thing if the REFER or LINK functionality is not 1104 supported. 1106 10.5. Peer to peer Messaging 1108 Peer to peer communication can be desirable to lighten the load 1109 on servers. This can be done in several ways. 1111 10.5.1. Getting direct responses to requests 1113 When the client initiates communication by sending a message (a 1114 query, subscription or instant message), the client can send the 1115 message directly to the publishing server rather than to a proxy 1116 server. The sender header should include the full RVP Reply-To 1117 URL (e.g rvp://lisadu.host2.com/lisadu) as well as the full RVP 1118 identity of the user (e.g. rvp://rvp.host2.com/users/lisadu). 1119 When the response comes, it comes directly back to the client. In 1120 sending messages directly to the publishing server, the client 1121 reveals its DNS address and is therefore more open to attack, but 1122 the risk is limited by the fact that the IP address only goes to 1123 targets chosen by the user. If the initial message goes outside 1124 a firewall, that firewall must be able to pass incoming RVP 1125 messages (responses) to the RVP Reply-To URL. 1127 10.5.2. Responding directly to notifications 1129 When the client receives a notification from a trusted source 1130 through the client's local proxy and wishes to continue the 1131 conversation, the client can choose to respond directly to that 1132 source rather than through the local proxy. Once again the 1133 Reply-To header points to the client machine and the From header 1134 points to the user's RVP object location. 1136 10.5.3. Receiving instant messages directly 1138 If the client is willing to accept instant messages (unsolicited 1139 notifications) directly, it should set the LINK property for its 1140 RVP object on the server to REFER-NOTIFICATIONS plus its full 1141 client-side RVP URL. The timeout for this property should be set 1142 to a reasonable value in case the client goes offline 1143 unexpectedly. When the server receives unsolicited notifications 1144 (notifications which are not in response to a subscription) it 1145 can respond with a referral message including the REFER- 1146 NOTIFICATIONS and the client-side RVP URL. 1147 If the client is willing to accept unsolicited notifications and 1148 its server does not support the LINK property, then when the 1149 server proxies instant messages the client can respond with a 1150 success message and include the REFER-NOTIFICATIONS field, 1151 timeout, and URL itself. The proxy will forward this back to the 1152 original sender, who can now start using the client URL until the 1153 timeout listed. 1154 Queries and subscriptions should still be sent to the Reply-To 1155 address used in the original request message. 1157 10.5.4. Receiving Requests Directly 1159 If a client wishes to handle queries and subscriptions to its 1160 user object data as well, it must ask the server to refer all 1161 messages, using the LINK property as outlined in the section on 1162 "Proxying, Referring and Linking nodes". 1164 10.6. Proxy and Referral Conflicts 1166 Note that the referral functionality allows clients to assume 1167 responsibility for their own user�s nodes, which means that the 1168 client becomes its own server. In the case where a user switches 1169 between clients (presumably on different hardware), this could 1170 lead to conflict. If client A sets the LINK property to proxy to 1171 A, then client B tries to sets the LINK property to proxy to B, 1172 what should happen? 1174 - If B does not have sufficient access, server responds with an 1175 error meaning "access denied". 1177 - Or, if the server does not allow a client to take over node 1178 which is already referred or proxied, the server can reply with 1179 an error meaning "locked" or something like that 1181 - Or, if the link_method of the LINK property is set to REFER, 1182 the server responds with a referral to client A. 1184 - Or, if the link_method of the LINK property is set to PROXY, 1185 the server proxies the PUT command to client A. 1187 When client A receives the PUT command for the LINK property, 1188 either through proxy or directly, it realizes that another client 1189 is trying to take control of the node. The options for client A 1190 are now: 1192 - Reply with an error "access denied" which is either proxied or 1193 sent directly to client B 1195 - Reply with a success message which is either proxied or sent 1196 directly to client B, after setting everything right on the 1197 server by refreshing all data on the node, including setting the 1198 LINK property to the new value given by client B. 1200 11. Examples 1202 11.1. Subscribing directly to status changes 1204 This example shows a client acting as its own server in 1205 subscribing directly to a user's RVP status. In this case the 1206 client MUST accept incoming connections because the publishing 1207 server needs to send notifications back to the client. 1209 Client to publishing server: 1211 SUBSCRIBE rvp://host.com/joeuser rvp/1.0 1212 Notification-type: XML 1213 Reply-To: rvp://host2.com/lisadu 1214 From: rvp://host2.com/lisadu 1215 Content-type: text/XML 1216 Content-length: xyz 1218 [CRLF] 1219 1220 1221 1222 change 1223 06 Nov 1998 08:49:37 GMT 1224 rvp://host2.com/lisadu 1225 1227 Publishing server to client (success): 1229 RVP/1.0 200 SUBSCRIBE 1230 Subscription-ID: 84 1231 Content-type: text/xml 1232 From: rvp://host.com/joeuser 1233 [CRLF] 1234 1235 1236 online 1237 change 1238 06 Nov 1998 08:49:37 GMT 1239 controlled 1241 Notice in this example that the publishing server set a lower 1242 timeout for the subscription than was requested by the 1243 subscriber. 1245 Notification sent as a result of this subscription: 1247 NOTIFY rvp://host.com/joeuser 1248 Subscription-ID: 84 1249 Reply-To: rvp://host.com/joeuser 1250 From: rvp://host.com/joeuser 1251 Notification-type: XML 1252 Content-type: text/XML 1253 Content-length: xyz 1254 [CRLF] 1255 1256 1257 online 1258 change 1259 Refresh method for this subscription: 1261 Not yet defined. 1263 Unsubscribe method for this subscription: 1265 UNSUBSCRIBE rvp://host.com/joeuser rvp/1.0 1266 Call-id: 84 1268 11.2. Subscribing through a proxy to a group: 1270 Message from client to proxy: 1272 SUBSCRIBE rvp://host.com/groups/rvpdisc 1273 Notification-type: XML 1274 Reply-To: rvp://client.host2.com/lisadu 1275 From: rvp://rvp.host2.com/lisadu 1276 XML-body: 1277 1278 message 1279 rvp://rvp.host2.com/lisadu 1280 1282 Note that the Reply-To address is a URL to the user's client 1283 machine, whereas the subscriber-id is a pointer to a user's RVP 1284 object. Sometimes these are the same, but in this case the 1285 object is hosted on a RVP server, whereas the user receives 1286 messages at their client. Also note that no timeout is defined, 1287 because the user wants to use the max or default timeout for that 1288 subscription list. 1290 Message from proxy to publishing server: 1292 SUBSCRIBE rvp://host.com/groups/rvpdisc 1293 Notification-type: XML 1294 Reply-To: rvp://proxy.host2.com/lisadu 1295 From: rvp://rvp.host2.com/lisadu 1296 Via: RVP/1.0 rvp://proxy.host2.com/lisadu 1297 Content-type: text/XML 1298 Content-length: xyz 1299 [CRLF] 1300 1301 1302 message 1303 rvp://rvp.host2.com/lisadu 1304 1306 Successful response from publishing server to proxy: 1308 RVP/1.0 200 SUBSCRIBE 1309 Subscription-ID: 1238 1310 Content-type: text/xml 1311 Content-length: xyz 1312 From: rvp://host.com 1313 [CRLF] 1314 1315 1316 message 1317 06 Nov 1998 08:49:37 GMT 1318 controlled 1320 Response forwarded from proxy to client: 1322 RVP/1.0 200 SUBSCRIBE 1323 Subscription-ID: 1238 1324 Content-type: text/xml 1325 Body: 1326 [same body] 1328 Notification from publishing server (list server) to proxy: 1330 NOTIFY rvp://host.com/groups/rvpdisc RVP/1.0 1331 Subscription-ID: 1238 1332 Reply-To: rvp://fred.host3.com/fred 1333 From: rvp://host3.com/users/fred 1334 Notification-type: XML 1335 XML-body: 1336 1337 1338 Message 1339 high 1340 display 1341 rvp://rvp.host2.com/lisadu 1342 Content-type: text/plain 1343 [CRLF] 1344 Hey everybody, I've got something important to say. 1346 The same message is forwarded from the proxy to the subscriber, 1347 minus the fan-out list. The fan-out only shows one user, because 1348 only one user on this proxy is currently subscribed to the list. 1350 The original sender of the message is the user 'fred' on another 1351 system. His client machine address is listed as the Reply-To 1352 because responses to messages to this list are intended to go to 1353 the sender. (On other lists, the Reply-To might be the list 1354 itself, and the source would still be fred) 1356 11.3. Setting ACLs on the status property 1358 Client to home server: 1360 ACL rvp://host.com/joeuser RVP/1.0 1361 Content-type: text/XML 1362 [CRLF] 1363 1364 1365 1366 1367 grant subscribe rvp://host.com/lisadu 1368 deny subscribe rvp://host.com/baduser 1369 1371 11.4. Sending an instant message 1373 Client to target's home server: 1375 NOTIFY rvp://host.com/joeuser RVP/1.0 1376 Reply-To: rvp://fred.host3.com/fred 1377 From: rvp://host3.com/users/fred 1378 Notification-type: XML 1379 Session-ID: 4321 1380 XML-body: 1381 1382 1383 Message 1384 high 1385 display 1386 Content-type: text/plain 1387 Content-length: 7 1388 [CRLF] 1389 Hi Joe. 1391 The action taken by the home server depends whether the home 1392 server refers instant messages or proxies them. If the home 1393 server proxies, it should send a notification to the client with 1394 the Reply-To replaced by its own RVP address. When it receives a 1395 success message, and forward the success message back to 1396 rvp://fred.host3.com/fred. 1398 If the home server refers instant messages to Joe's proxy or to 1399 Joe's machine, it replies back with a referral response: 1401 RVP/1.0 ??? REFER 1402 Session-ID: 4321 1403 Referral-type: Notifications 1404 Referral-address: rvp://proxy.host.com/joeuser RVP/1.0 1406 The referral-type header indicates which kinds of messages should 1407 go to the referred machine rather than to the home server. The 1408 only defined values so far are "notifications" and "all". In this 1409 case, requests (queries & subscriptions) for information should 1410 still go to the home server, but notifications (typically 1411 intended for the user's eyes) should go to the referred address 1412 IF THERE IS NO REPLY-TO SPECIFIED FOR THAT NOTIFICATION. 1414 The session-ID can also be used for future messages in the 1415 conversation between Joe and Fred, to provide context. 1417 11.5. Inviting a user to a session defined by SIP 1419 Example is not done yet. It will be a NOTIFY message with a 1420 content-type of application/SIP and a body which is a SIP 1421 message. 1423 12. REFERENCES 1425 [1] S. Bradner, "Key words for use in RFCs to indicate 1426 requirement levels," RFC 2119, Internet Engineering Task Force, 1427 Mar. 1997. 1429 [2] Dusseault L. and Bone J. "RVP Schemas", INTERNET-DRAFT , March 1998. 1432 [3] Dusseault L., "Presence Information Protocol Requirements", 1433 INTERNET-DRAFT , February 1998. 1435 [4] Dusseault L. and Mohr G. " Addressing and Location for RVP", 1436 INTERNET-DRAFT , March 1998. 1438 [5] Fielding R., Gettys J., Mogul J., Frystyk H. and Berners-Lee 1439 T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1440 1997. 1442 [6] Leach P. J. and Goland Y. Y., "WebDAV ACL Protocol", 1444 [7] Goland Y. Y., Whitehead E. J., Faizi A., Carter S. R. and 1445 Jensen D., "Extensions for Distributed Authoring on the World 1446 Wide Web -- WEBDAV", INTERNET-DRAFT , January 1998. 1449 13. Authors' Addresses 1451 Martin Calsyn 1453 Microsoft Corporation 1454 One Microsoft Way 1455 Redmond, WA 98052 1457 EMail: martinca@microsoft.com 1458 Fax: (425) 936-7329 1460 Lisa Dusseault 1462 Microsoft Corporation 1463 One Microsoft Way 1464 Redmond, WA 98052 1466 EMail: lisadu@microsoft.com 1467 Fax: (425) 936-7329 1469 Gordon Mohr 1471 Activerse, Inc. 1472 1301 W. 25th St 1473 Suite 500 1474 Austin, TX 78705 1476 Email: gojomo@activerse.com