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