idnits 2.17.1
draft-wolf-vpp-00.txt:
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-19) 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 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 6 months
document validity.
** 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.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an Introduction section.
(A line matching the expected section header was found, but with an
unexpected indentation:
' 1 Introduction' )
** The document seems to lack a Security Considerations section.
(A line matching the expected section header was found, but with an
unexpected indentation:
' 8 Security Considerations' )
** 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 an Authors' Addresses Section.
** The abstract seems to contain references ([RVP], [ABNF], [RFC2048],
[RVPAddr], [Message-id], [SLP], [Microscape], [Bradner97], [DNSSRV], [-],
[CRLF], [URL], [MD5], [P3P]), which it shouldn't. Please replace those
with straight textual mentions of the documents in question.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 470: '... preted. They SHOULD be created glob...'
RFC 2119 keyword, line 488: '... REQUIRED set, which MUST be underst...'
RFC 2119 keyword, line 505: '...n. VPP instances SHOULD treat "unrelat...'
RFC 2119 keyword, line 511: '... MUST NOT use these values....'
RFC 2119 keyword, line 581: '...onse = vpp-responsetype ; OPTIONAL...'
(90 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHOULD not' in this paragraph:
The signature SHOULD be a short string. The signature is the
finger-print of the property. It SHOULD not be interpreted by the
receiver. The signature SHOULD change if the property data changes. An
ASCII representation of a 32 bit CRC or an [MD5] digest of the property
data is adequate for most applications.
-- 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)
-- Missing reference section? 'RVP' on line 1930 looks like a reference
-- Missing reference section? 'Bradner97' on line 1938 looks like a
reference
-- Missing reference section? 'ABNF' on line 1949 looks like a reference
-- Missing reference section? 'RVPAddr' on line 1934 looks like a reference
-- Missing reference section? 'P3P' on line 1968 looks like a reference
-- Missing reference section? 'Message-id' on line 1971 looks like a
reference
-- Missing reference section? 'URL' on line 1946 looks like a reference
-- Missing reference section? 'DNS SRV' on line 1952 looks like a reference
-- Missing reference section? 'SLP' on line 1955 looks like a reference
-- Missing reference section? 'CRLF' on line 1091 looks like a reference
-- Missing reference section? '-' on line 1220 looks like a reference
-- Missing reference section? 'MD5' on line 1965 looks like a reference
-- Missing reference section? 'RFC 2048' on line 1962 looks like a reference
-- Missing reference section? 'Microscape' on line 1958 looks like a
reference
Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 INTERNET-DRAFT K. H. Wolf
3 Expires: February 1, 1999 University of Ulm
5 VPP: Virtual Presence Protocol
6 draft-wolf-vpp-00.txt
8 Status of this Memo
10 This document is an Internet Draft. Internet Drafts are working
11 documents of the Internet Engineering Task Force (IETF), its areas,
12 and its working groups. Note that other groups may also distribute
13 working documents as Internet Drafts.
15 Internet Drafts are draft documents valid for a maximum of six months
16 and may be updated, replaced, or obsoleted by other documents at any
17 time. It is inappropriate to use Internet Drafts as reference
18 material or to cite them other than as "work in progress."
19 Distribution of this document is unlimited.
21 To view the entire list of current Internet Drafts, please check the
22 "1id-abstracts.txt" listing contained in the Internet Drafts Shadow
23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
25 ftp.isi.edu (US West Coast).
27 Abstract
29 The purpose of the Virtual Presence Protocol (VPP) protocol is to
30 enable the exchange of document based virtual presence information.
31 Virtual presence information is the foundation for virtual
32 neighborhood services which provide users with information about
33 virtual neighbors, i.e. other users who are close within the virtual
34 document space. VPP enables the creation of dynamic vicinities based
35 on hypertext references. It is not meant to replace or supersede
36 presence notification protocols, but it augments online presence with
37 location information. The protocol described in this document is
38 based on 2 years of experience with location based virtual presence
39 and presence notification.
41 The purpose of presence notification protocols such as the drafted
42 [RVP] is to tell whether another individual is online or arrives
43 online, etc. As opposed to such real online presence, the presence on
44 documents in the World Wide Web is a virtual one. The authors
45 recognize that VPP shares methods, mechanisms, and formats with HTTP,
46 and drafted presence notification protocols (e.g. RVP), however the
47 functionality is significantly different.
49 Structure of the Document
51 The document starts by introducing the need for a virtual
52 neighborhood service and definitions of terms used by the document.
53 It explains the purpose, components, and operation of the virtual
54 neighborhood service.
56 The second part introduces the protocol and defines protocol elements
57 at an abstract level. Data formats are then presented, followed by
58 details of how the protocol may be encapsulated within HTTP.
60 The third part of the document covers security considerations and a
61 best current practice section with traffic considerations, other
62 recommendations, and examples.
64 Table of Contents
66 1 Introduction ............................................ 4
67 1.1 Problem to be solved ................................... 4
68 1.2 Terminology ............................................ 4
69 1.3 Virtual Neighborhood Service ........................... 5
70 1.3.1 Purpose ............................................... 6
71 1.3.2 VPP Client and VPP Server ............................. 6
72 1.3.3 Typical Operation ..................................... 7
73 1.3.4 Link Graph ............................................ 8
74 1.4 Relation to other Protocols ............................ 8
75 2 Protocol Overview ....................................... 9
76 2.1 Purpose ................................................ 9
77 2.2 Protocol Neutral ....................................... 9
78 2.3 General Format ......................................... 9
79 2.4 Basic Definitions ...................................... 10
80 2.4.1 Distance Definition ................................... 11
81 2.5 Data Formats ........................................... 11
82 2.6 Access Control ......................................... 13
83 3 Naming and Addressing ................................... 13
84 3.1 Locations .............................................. 13
85 3.2 Users .................................................. 13
86 3.3 Finding VPP Servers .................................... 14
87 3.3.1 DNS SRV Records ....................................... 14
88 3.3.2 Service Location Protocol ............................. 15
89 3.3.3 Associated Server Lookup .............................. 15
90 3.3.3.1 Request .............................................. 15
91 3.3.3.2 Response ............................................. 16
92 4 Messages ................................................ 16
93 4.1 ENTER/LEAVE ............................................ 16
94 4.1.1 ENTER Request ......................................... 16
95 4.1.2 LEAVE Request ......................................... 17
96 4.1.3 ENTER/LEAVE Response .................................. 17
97 4.2 LINK/UNLINK ............................................ 18
98 4.2.1 Introduction to Linking ............................... 18
99 4.2.2 LINK Request .......................................... 18
100 4.2.3 UNLINK Request ........................................ 19
101 4.2.4 LINK/UNLINK Response .................................. 20
102 4.3 SUBSCRIBE/UNSUBSCRIBE .................................. 20
103 4.3.1 Introduction to Subscriptions ......................... 20
104 4.3.2 SUBSCRIBE Request ..................................... 21
105 4.3.3 UNSUBSCRIBE Request ................................... 22
106 4.3.4 SUBSCRIBE/UNSUBSCRIBE Response ........................ 23
107 4.4 NOTIFY ................................................. 23
108 4.4.1 Request ............................................... 23
109 4.4.2 Response .............................................. 24
110 4.5 GET .................................................... 24
111 4.5.1 Request ............................................... 24
112 4.5.2 Response .............................................. 24
113 5 Properties .............................................. 25
114 5.1 Location Subject ....................................... 25
115 5.1.1 Users Property ........................................ 25
116 5.1.2 Links Property ........................................ 25
117 5.1.3 Symbol Property ....................................... 26
118 5.1.4 Summary Property ...................................... 27
119 5.2 User Subject ........................................... 27
120 5.2.1 Locations Property .................................... 28
121 5.2.2 Neighbors Property .................................... 28
122 6 HTTP/1.1 Encapsulation .................................. 28
123 6.1 Encapsulation Properties ............................... 29
124 6.2 Encapsulation Rules .................................... 29
125 6.2.1 Basic Rules ........................................... 29
126 6.2.2 Request ............................................... 31
127 6.2.3 Response .............................................. 31
128 6.3 Forced LEAVE ........................................... 31
129 7 Traffic Considerations .................................. 32
130 7.1 Overview ............................................... 32
131 7.2 ENTER/LEAVE ............................................ 32
132 7.3 LINK/UNLINK ............................................ 33
133 7.4 SUBSCRIBE/UNSUBSCRIBE/NOTIFY ........................... 34
134 7.5 Service Lookup ......................................... 34
135 8 Security Considerations ................................. 34
136 8.1 User Privacy ........................................... 34
137 8.2 Access Control ......................................... 35
138 8.3 Security of Documents .................................. 36
139 9 Appendices .............................................. 36
140 9.1 Location Mapping ....................................... 36
141 9.1.1 Traditional File Based ............................... 36
142 9.1.2 Document Databases ................................... 37
143 9.1.3 Database Queries ..................................... 37
144 9.2 User Names ............................................. 38
145 9.2.1 HTTP URL .............................................. 38
146 9.2.2 Internet Domain Name or Address ....................... 38
147 9.3 HTTP Encapsulation Examples ............................ 38
148 9.3.1 Service Lookup ........................................ 39
149 9.3.2 Enter ................................................. 39
150 9.3.3 Leave ................................................. 39
151 9.3.4 Link .................................................. 39
152 9.3.5 Subscribe ............................................. 40
153 9.3.6 Notify ................................................ 40
154 10 References .............................................. 41
155 11 Acknowledgements ........................................ 42
156 12 Author's Address ........................................ 42
158 1 Introduction
160 1.1 Problem to be solved
162 The World Wide Web is increasingly regarded as a virtual space rather
163 than a linked collection of documents. People get the impression that
164 they enter Web sites, and Web pages; in many cases they notice the
165 past or present presence of others, though this notion is usually
166 indirectly conveyed through access counters, statistics, or the
167 effects of other peoples actions on interactive Web sites. The
168 awareness horizon is in most cases limited to a small set of
169 documents on a single Web site.
171 Reasons for these limitations are:
173 o The lack of information about documents presented to a user
174 at a certain time. Only the request for a document is
175 registered by most existing document servers, not the dura-
176 tion of the document's presentation.
178 o The lack of presence information exchange between Web
179 sites. Hence, virtual presence on documents can not span
180 hypertext references between documents on different sites.
182 The Virtual Presence Protocol offers a means to exchange information
183 about user-document relations. It is the foundation for a virtual
184 neighborhood service that provides users with information about vir-
185 tual neighbors, i.e. other users who are close to each other in terms
186 of the set of documents visited. The document based neighborhood may
187 span multiple Web sites.
189 1.2 Terminology
190 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
191 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"
192 and "OPTIONAL" are to be interpreted as described in RFC 2119
193 [Bradner97] and indicate requirement levels for compliant VPP imple-
194 mentations.
196 Syntax definitions are in [ABNF] or from [HTTP/1.1].
198 Location
199 A reference to a network accessible document. A "resource"
200 addressed by a URL.
201 Border Location
202 User are considered to be at a border location if the document they
203 are viewing contains a link to a document on a different document
204 server.
205 Border Link
206 A link between documents on different document servers.
207 Document Server
208 The software process which makes document resources accessible to
209 network protocols. HTTP and FTP servers are document servers. Vir-
210 tual Neighborhood Service. See next section.
211 VPP Server / Neighborhood Server
212 The software process which implements the VPP protocol and offers
213 the virtual neighborhood service.
214 VPP Client
215 The part of a software process which submits information about the
216 location of users.
217 User
218 Usually a single human. A user operates directly or indirectly a
219 VPP client. A software process can be registered with locations
220 like a human. In this case it is regarded as a user.
221 Neighbor
222 A user which is registered with locations within a defined proxim-
223 ity to locations of another user.
224 Neighborhood List
225 Set of neighbors (users) computed by the virtual neighborhood ser-
226 vice.
227 VPP Subject
228 The active instance of a VPP request. It is expected that a VPP
229 server maps VPP requests to methods of the request's subject. The
230 VPP subject is the equivalent to the resource of HTTP requests.
231 Property
232 A named attribute of a VPP subject.
233 Subscription
234 A subscription is a request that will result in multiple responses,
235 one for each change in the subscribed property.
237 1.3 Virtual Neighborhood Service
238 1.3.1 Purpose
240 The virtual neighborhood service (VNS) provides users with informa-
241 tion about virtual neighbors, i.e. other users who are close to each
242 other in terms of the documents they are presented with. The VNS is a
243 network of loosely coupled VPP servers. Users can be registered at
244 locations regardless of whether they are reading the document. This
245 enables temporarily extended presence on documents.
247 A user's virtual neighborhood is defined by the documents the user is
248 registered with, and the links of these documents to other documents.
249 Documents may be static or dynamically created. Links between docu-
250 ments may be physically encoded into the documents (e.g. hypertext
251 references in HTML documents), stored externally in a link database,
252 or statically or dynamically derived from other properties of docu-
253 ments, e.g. by content matching.
255 A VNS uses links between locations, and information about the loca-
256 tions of users to create dynamically changing sets of associated
257 users. The algorithm used to compute these sets depends on the imple-
258 mentation of the VNS. The sets of associated users (virtual neigh-
259 bors) are the main result of the operation of a neighborhood service.
260 They are created for every user and each set is finally presented to
261 the respective user.
263 The set of neighbors is a user property. VPP maintains locations and
264 their properties whereas presence notification services maintain
265 users and user properties. Hence the access to the set of neighbors
266 is not part of VPP. The results must be fed into a presence notifica-
267 tion service to be available to presence notification clients. This
268 transfer may be done by an HTTP server, an HTTP client, an RVP
269 server, an RVP client, by data sharing between VPP and RVP server or
270 another kind of software component. It will be described in a
271 separate document.
273 1.3.2 VPP Client and VPP Server
275 Information about the registration of users with locations is
276 exchanged between a VPP client and a VPP server. On the other hand
277 VPP servers exchange information about users and locations. The
278 information exchanged between servers is usually derived from the
279 information obtained by client-server interaction. Messages used by
280 server-server interaction can also be used to present users with the
281 results of the service. However retrieval (and visualization) of
282 results is intentionally not specified here.
284 A network of VPP clients and VPP servers may look like this:
286 Client --v--> Server <--v--> Server <--v-+
287 | |---- Client
288 v--> Server <--v-+
289 |
290 v: VPP data
292 VPP clients are typically integrated with HTTP clients or clients for
293 other protocols with similar functionality, i.e. the retrieval and
294 presentation of documents (document clients). But VPP clients can be
295 operated independently of document clients to enable virtual presence
296 independent of any document presentation.
298 VPP servers are typically, but not necessarily, co-located with docu-
299 ment servers, such as HTTP servers or FTP servers. But VPP servers
300 can be operated without associated document servers to create virtual
301 neighborhoods independent of real documents.
303 1.3.3 Typical Operation
305 This section describes the typical application of a neighborhood
306 server. Other applications are possible.
308 A neighborhood server usually accompanies one or more document
309 servers. It maintains a link graph, i.e. a graph of nodes and edges
310 which represent documents and links of one or more document servers.
312 The neighborhood server maps document locations of its associated
313 document servers to nodes of the link graph. Edges may be derived
314 from hypertext references. The links are weighted. A way to weight
315 links derived from hypertext references is to augment HTML-anchor
316 tags with weights. Edges can be bi-directional.
318 Document clients retrieve and display documents for a user. The asso-
319 ciated VPP client registers the user with the respective location at
320 the VPP server/neighborhood server. The same happens for other users.
322 If users are registered with border locations then the VPP server
323 subscribes for information on users registered with locations linked
324 to the border location. The subscription is directed to a peer VPP
325 server. In turn the other VPP server continuously submits the
326 requested information, i.e. sets of users at or near to the location
327 linked to the border location.
329 The neighborhood server computes a set of users in the vicinity con-
330 tinuously for each user. This can be done by iterated or recursive
331 graph traversal with weighted stop marks. The neighborhood server may
332 use implementation specific, site specific, or user specific parame-
333 ters to do so.
335 The set of neighbors is presented to the user by means of a separate
336 protocol. The neighborhood server may act like an presence notifica-
337 tion (RVP) server to make the set of neighbors available to sub-
338 scribers. It may also submit the data actively to the user's home RVP
339 server. The current implementation includes a presence notification
340 server (which supports the 'user' subject, see section "Properties"
341 below).
343 1.3.4 Link Graph
345 The link graph of the VNS is to be considered independent of the
346 document database of the document service and its associated link
347 database, if there is any. However it is expected that in many cases
348 the link graph of the VNS is derived from the document database.
350 Location identifiers used by the VNS are to be considered independent
351 of document locations used by the document service, e.g. URLs. But it
352 is expected that locations used by the VNS are derived from document
353 locations or document contents. The mapping between both types of
354 locations depends on the application and the implementation of the
355 VNS. See appendix "Location Mapping".
357 1.4 Relation to other Protocols
359 The Virtual Presence Protocol uses references of locations and users.
360 Locations are referenced by URIs or URLs. VPP does not depend on HTTP
361 URLs, hence it is designed to be independent of HTTP rather than an
362 extension of HTTP.
364 Users may be represented by RVP URLs mentioned in the Internet Draft
365 "Addressing and Location for RVP" [RVPAddr] or a similar scheme. In
366 this case identifications of users contained in results of VPP
367 servers can be used to start up and conduct communication between
368 users. But VPP does not restrict the identification of users to RVP
369 URLs. Users can also be represented by various other schemes, e.g.
370 abstract numbers, HTTP URLs, Internet Domain Names, or email
371 addresses (see below "Naming and Addressing").
373 Users and their properties are the subjects of presence notification
374 protocols, whereas locations and their properties are the main sub-
375 jects of the Virtual Presence Protocol. The major reason to create
376 VPP independent from presence notification protocols is the concep-
377 tual independence of both subjects and subject identifiers. However
378 the similarities to the RVP draft may lead to an integration of parts
379 of VPP into a presence notification protocol or into a general event
380 notification protcol.
382 VPP clients notify VPP servers of the beginning and of the end of the
383 presence on documents. It may also in the future notify of movement
384 within documents. This applies to HTML documents as well as to vir-
385 tual reality scenes, but the main focus is currently on the creation
386 of a virtual presence infrastructure based on locations of documents.
388 Multi-user virtual spaces (MUVS) focus on positioning and orientation
389 within 3 dimensional spaces, while VPP focuses on locations of docu-
390 ments and linking between documents. To our knowledge there is no
391 Internet Draft, RFC or other IETF document about a MUVS protocol, but
392 it may well be that a MUVS protocol can be extended to cover parts of
393 the VPP functionality.
395 2 Protocol Overview
397 2.1 Purpose
399 The Virtual Presence Protocol is used between client and server to
400 register and un-register users with locations, and between servers to
401 propagate the information about the registration of users with loca-
402 tions. It may also be used to create dynamic displays of the data
403 maintained by neighborhood servers.
405 2.2 Protocol Neutral
407 This document defines an abstract representation of VPP. A "native"
408 format, or an incorporation into another protocol will be described
409 in a separate document.
411 The encapsulation of VPP within HTTP is currently implemented within
412 our prototype as described in the section "HTTP/1.1 Encapsulation".
414 2.3 General Format
416 VPP is a request/response protocol. A client sends a request message
417 to the server and the server responds with a response message.
419 A request message consists of
420 o protocol-version,
421 o subject,
422 o property,
423 o method,
424 o attributes, and
425 o additional-data.
427 A response message consists of
428 o protocol-version
429 o response-code, and
430 o additional-data.
432 Additional-data is always accompanied by
433 o data-length (number of octets), and
434 o data-type.
436 The VPP version described here is 2.0.
438 Examples for properties of locations are (see section "Properties"):
439 o users
440 o links
441 o symbol
443 2.4 Basic Definitions
445 The meaning of response codes follows HTTP status codes as defined in
446 [HTTP/1.1]:
448 vpp-responsecode = Status-Code
450 Other response codes may be added in the future. The problem of
451 status code sharing with HTTP has to be solved (Note: RTSP uses
452 status codes starting at x50, [P3P] at x30. But there are some
453 numbers free. RVP competes here and who knows who else).
455 Timeout specifications can be given in absolute time or relative to
456 the time of the request (the reception of the request, if no time
457 value included in the request).
459 vpp-time = HTTP-date | delta-seconds
461 The service address of a VPP server is used by VPP service lookup
462 responses (see "Finding VPP Servers"). The URL scheme used depends on
463 the host protocol:
465 vpp-serviceurl = genericurl
467 Some VPP requests refer to previous requests. Tokens are used to
468 identify previous requests and to validate references to previous
469 requests. These tokens are stored, compared and returned uninter-
470 preted. They SHOULD be created globally unique in a way which pro-
471 tects them from being re-created by attackers ([Message-id] may be
472 used as a guideline to unique IDs). In many cases tokens are
473 optional. Missing tokens are mapped to empty tokens (e.g. an empty
474 character string):
476 vpp-reference = *(VCHAR)
478 Subscriptions to properties of VPP subjects result in notifications
479 being sent back on certain events:
481 vpp-event = UPDATED | DELETED
483 2.4.1 Distance Definition
485 Links between locations can be weighted. The definition of the weight
486 is supposed to allow for a broad range of applications. Hence we have
487 left the definition open (see vpp-app-distance below), but with a
488 REQUIRED set, which MUST be understood by VPP instances in the way
489 defined here. Large numbers indicate a large distance.
491 vpp-distance = vpp-basic-distance ; 0 & positive integer values
492 | vpp-float-distance ; float values
493 | vpp-symbolic-distance ; named weights
494 | vpp-app-distance ; application defined
496 vpp-basic-distance = 1*DIGIT
497 vpp-float-distance = 1*DIGIT "." 1*DIGIT ; no exp. part (yet)
498 vpp-symbolic-distance = "none"
499 | "near"
500 | "far"
501 | "unrelated"
502 vpp-app-distance = 1*VCHAR
504 The exact interpretation of symbolic-distance values depends on the
505 implementation. VPP instances SHOULD treat "unrelated" as if there
506 where no link, "far" like a large basic-distance, "near" like a
507 float-distance between "0" and "2.718" exluding "0", and "none" like
508 the basic-distance "0".
510 The values of the symbolic-distance are reserved. App-distance values
511 MUST NOT use these values.
513 If no distance is given, a default distance of "1" is assigned, if
514 not stated otherwise. The default value applies for app-distance
515 values not understood.
517 2.5 Data Formats
519 Many request messages do not carry additional data. The information
520 of these messages is contained in the fields described above ("Gen-
521 eral Format") except the data field.
523 Additional data is exchanged in XML format. XML is used in order to
524 provide flexibility and extensibility. The data type is "text/xml".
526 The format is:
527 xml-encoded-data =
528 ""
529 ""
530 tag-encoded-data
532 tag-encoded-data = tag-encoded-response-data
533 | tag-encoded-request-data
535 tag-encoded-response-data = service-response-data
536 | enter-response-data
537 | link-response-data
538 | subscribe-response-data
539 | notify-response-data
540 | get-response-data
542 tag-encoded-request-data = notify-request-data
544 For the encoding of tags used only by property data see the respec-
545 tive section chapter "Properties").
547 The message fields use the following XML tags. They will be defined
548 by proper XML Element Definitions. The namespace may be omitted from
549 this document if no collisions are to be expected, but it is included
550 here for completeness.
552 vpp-timeout-tag = "" vpp-time ""
553 vpp-delay-tag = "" vpp-time ""
554 vpp-distance-tag = "" vpp-distance ""
555 vpp-responsecode-tag = "" vpp-responsecode ""
556 vpp-responsemsg-tag = "" *CHAR ""
557 vpp-serviceurl-tag = "" vpp-serviceurl ""
558 vpp-servicever-tag = "" vpp-serviceversion ""
560 For backward compatibility additional-data can also be encoded in
561 CRLF separated lists of ASCII text. The data type is "text/plain".
562 The exact format will be given in the respective section.
564 plain-data = plain-response-data
565 | plain-request-data
567 plain-response-data = plain-service-response-data
568 | plain-enter-response-data
569 | plain-link-response-data
570 | plain-subscribe-response-data
571 | plain-notify-response-data
572 | plain-get-response-data
574 plain-request-data = plain-notify-request-data
576 The server chooses the data type. But the client may employ an
577 optional request attribute to force the server to return a specific
578 type.
580 Attribute:
581 response = vpp-responsetype ; OPTIONAL
583 vpp-responsetype = media-type ; [HTTP/1.1]
585 2.6 Access Control
587 VPP does not support access control yet. Generally it is expected
588 that the access control mechanism will be similar to access control
589 mechanisms of document servers. Access control will be supported as
590 soon as an authorization mechanism has been defined. For the time
591 being the access control mechanism of the host protocol can be used.
593 3 Naming and Addressing
595 3.1 Locations
597 VPP uses URLs to identify document locations as defined in RFC1738
598 [URL]. In the case where a fragment/anchor identifier is associated
599 with a URL (following a "#"), the identifier would be appended to the
600 URL and used as the location of the fragment.
602 The interpretation of the scheme, of the scheme specific part of the
603 URL, and of optional fragment/anchor identifiers depends on the
604 implementation of the neighborhood server.
606 vpp-locationname = url [ "#" fragment ]
608 3.2 Users
610 User names are strings of VCHAR (CHAR except CTL and SP). The naming
611 of users depends on the implementation of VPP clients. Implementors
612 of VPP clients should be aware that names of users or information
613 derived from these names will finally be presented to (human) users,
614 hence names should be meaningful in some way.
616 vpp-username = 1*(VCHAR)
618 We recommend the use of one of the following schemes:
620 HTTP or FTP URLs
621 if additional user detail can be expected at locations derived
622 from the respective URL, e.g. by appending well known file
623 names to a base URL (see appendix "User Names").
625 User identifications of presence notification protocols
626 such as RVP URLs, as described in [RVPAddr] (other example: ICQ
627 numbers).
629 Arbitrary names
630 if an out-of-band mechanism can be used to map arbitrary names
631 to meaningful information such as nicknames.
633 Internet domain name or Internet address
634 of the user's host, if it is safe to assume, that at any time
635 only one user operates a VPP client on the host. Implementors
636 should be aware that disclosing the network address of a user
637 may pose security problems.
639 The use of RFC 822 email addresses is discouraged although they are
640 unique and meaningful. The email address is regarded as user detail
641 which is only selectively disclosed under control of the user.
643 A VPP client implementation MUST NOT use a naming scheme which con-
644 flicts with the interpretation of names as described in appendix
645 "User Names".
647 It is expected that a dominant naming scheme for users will emerge in
648 the future. Hence we are not enforcing a specific scheme yet.
650 3.3 Finding VPP Servers
652 VPP clients which are integrated with document clients will need the
653 service address of the VPP server which is responsible for documents
654 fetched by the document client.
656 VPP servers will need the service address of the VPP server which is
657 responsible for documents linked to border locations.
659 In both cases the service address of the VPP server must be derived
660 from the document location (URL).
662 3.3.1 DNS SRV Records
664 RFC 2052 [DNS SRV] recommends use of DNS SRV records to discover the
665 responsible server for a service.
667 Given the domain name, which can be parsed from the URL, the client
668 prepends "vpp.tcp." to the domain name. Next the client queries the
669 DNS server for the SRV record for "vpp.tcp.cobrow.com". The mechanism
670 for adding "vpp.tcp" onto the original domain name is described in
671 detail in [DNS SRV]. The DNS server returns the IP address for the
672 associated server for "vpp.tcp.cobrow.com". The VPP data is sent to
673 this server.
675 3.3.2 Service Location Protocol
677 The Service Location Protocol version 2.0 [SLP] is under development
678 but may serve our needs in the future. An SLP URL for a VPP server
679 could look like:
681 service:vpp://cobrow.com
683 3.3.3 Associated Server Lookup
685 A lookup mechanism based on the document server is provided for a
686 transition phase until one or both methods described above are pro-
687 vided by the respective site. This method integrates easily with
688 existing document servers. It has been designed for simple installa-
689 tion when a neighborhood server is being added to a document server.
691 3.3.3.1 Request
693 The lookup URL (httpurl or ftpurl) is used to find the VPP server
694 responsible for the location (docurl). Lookup URLs follow the scheme
695 used in the respective document locations. Currently defined are
696 schemes for "http" and "ftp" URLs [URL]:
698 httplookup1 = "http://" hostport "/_service/vpp?op=service"
699 "&location=" docurl
700 httplookup2 = "http://" hostport hbasepath "_vpp"
701 ftplookup = "ftp://" hostport "/_service/vpp"
703 If the "/" character is used to designate a hierarchical structure
704 then hbasepath is the hpath excluding the last segment (hsegment).
705 This aids VPP installations on webhosting services.
707 From [URL]:
708 httpurl = "http://" hostport [ "/" hpath [ "?" search ]]
709 hpath = hsegment *[ "/" hsegment ]
710 hsegment = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
711 search = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
713 VPP clients and VPP servers SHOULD try httplookup1 first and re-try
714 with httplookup2, if the first lookup fails.
716 Example:
717 docurl: http://www.cobrow.com/pages/docs/help.html
718 httplookup1: http://www.cobrow.com/_service/vpp?op=service&
719 location=http://www.cobrow.com/pages/docs/help.html
720 httplookup2: http://www.cobrow.com/pages/docs/_vpp"
722 3.3.3.2 Response
724 The response data returns the result of the lookup. The result con-
725 sists of a response code, the service address of the VPP server, and
726 optional additional information. The data type is "text/xml".
728 Response format:
729 service-response-data = vpp-responsecode-tag
730 [ vpp-responsemsg-tag ]
731 [ vpp-serviceurl-tag ]
732 [ vpp-serviceversion-tag ]
734 Currently defined response codes (meaning as defined in [HTTP/1.1]):
735 vpp-responsecode = "200" | "404"
737 VPP version:
738 vpp-serviceversion = "1.0" | "2.0"
740 The "Content-type" HTTP header of responses to httplookup2 SHOULD be
741 ignored.
743 Example:
744 The _vpp resource for httplookup2 may be provided as a file:
745
746 2002.0
747 http://vpp.cobrow.com:4145/
749 4 Messages
751 4.1 ENTER/LEAVE
753 4.1.1 ENTER Request
755 A user is registered with a location. The effect of such a registra-
756 tion is that the user is present on the document, hence the method is
757 called ENTER.
759 Message fields:
760 subject = vpp-locationname ; REQUIRED
761 method = ENTER ; REQUIRED
762 Attributes:
763 user = vpp-username ; REQUIRED
764 reg-id = vpp-reference ; OPTIONAL (registration-ID)
765 timeout = vpp-time ; OPTIONAL
766 previous = vpp-locationname ; OPTIONAL
768 The location is the subject of the message. The user is specified as
769 an attribute. It is expected that the ENTER method of a location is
770 executed with a vpp-username as parameter to add a user to a node of
771 the link graph.
773 The registration can be limited to an absolute or relative time. The
774 server MAY change the time. The timeout value MUST be returned if it
775 is changed or if the request does not include a 'timeout' attribute.
776 This allows the server to limit the presence of users. Clients which
777 want to be registered longer MUST re-submit the request later.
779 Requests with the same user, location, and registration-ID supersede
780 previous registrations regardless of the timeout. Multiple registra-
781 tions with different registration-IDs are permitted. They do not
782 supersede each other.
784 The 'previous' attribute is informational. It may be used to indicate
785 which path has been used to enter the location.
787 4.1.2 LEAVE Request
789 The registration of a user with a location is deleted. The effect of
790 the request is that the user is no longer present on the document,
791 hence the method is called LEAVE.
793 Message fields:
794 subject = vpp-locationname ; REQUIRED
795 method = LEAVE ; REQUIRED
796 Attributes:
797 user = vpp-username ; REQUIRED
798 reg-id = vpp-reference ; OPTIONAL (registration-ID)
799 delay = vpp-time ; OPTIONAL
801 The effect of the request can be delayed until an absolute time is
802 reached or a relative time has passed. The server MAY change the
803 delay. In this case it MUST return the new value. This allows the VPP
804 client to send the LEAVE request when the document client changes the
805 document presented, although the request is executed a bit later ena-
806 beling a smoother display of the user's movement. A delay of a few
807 seconds is recommended. The delay may be implementation specific,
808 site specific, or user specific.
810 The LEAVE request deletes a registration only if subject, user, and
811 registration-ID match.
813 4.1.3 ENTER/LEAVE Response
815 The response data returns the response code and optional additional
816 information.
818 Message fields:
819 response-code = vpp-responsecode ; REQUIRED
820 additional-data = xml-encoded-data ; REQUIRED
822 The additional-data returns status information. The format for type
823 "text/xml" includes the vpp-responsecode:
825 enter-response-data = vpp-responsecode-tag
826 [ vpp-responsemsg-tag ]
827 [ vpp-timeout-tag ]
828 [ vpp-delay-tag ]
830 Currently defined response codes:
831 vpp-responsecode = "200" ; OK
832 | "400" ; Bad Request
833 | "404" ; Not Found
834 | "500" ; Internal Server Error
836 The response code in response to ENTER requests indicates the state
837 of the subject. "404" means that the location could not be found.
839 The server MUST accept any vpp-username.
841 Note: A combination of user and location which is inacceptable due to
842 access limitation will cause "401" (Unauthorized) as soon as an
843 authorization mechanism has been defined.
845 The response code "404" in response to LEAVE requests indicates the
846 combination of location, user, and registration-ID could not be
847 found.
849 The format for "text/plain" is:
850 plain-enter-response-data = vpp-time [CRLF]
852 4.2 LINK/UNLINK
854 4.2.1 Introduction to Linking
856 Most links between documents are only uni-directional. The virtual
857 neighborhood service facilitates bi-directional visibility. This is
858 usually easy to achieve for locations maintained by a single neigh-
859 borhood server. But bi-directional visibility over border links
860 requires communication between neighborhood servers. The VPP server
861 which maintains a border location notifies the VPP server of the
862 linked location.
864 4.2.2 LINK Request
865 Notification of a link from a border location to another location.
866 The effect of such a notification is that the notified server is able
867 to subscribe for information about users at or close to the border
868 location of the originating server.
870 Message fields:
871 subject = vpp-locationname ; REQUIRED (link destination)
872 method = LINK ; REQUIRED
873 Attributes:
874 location = vpp-locationname ; REQUIRED (link source)
875 link-id = vpp-reference ; OPTIONAL (link-ID)
876 timeout = vpp-time ; OPTIONAL
877 distance = vpp-distance ; OPTIONAL
879 The location of the receiving VPP server is the subject of the mes-
880 sage. The border location of the sender is specified as an attribute.
881 It is expected that the LINK method of a location is executed with a
882 vpp-locationname as parameter to add an edge to a node of the link
883 graph, (and the node) if it does not already exist.
885 The link can be limited to an absolute or relative time. The server
886 MAY change the time. The timeout value MUST be returned if it is
887 changed or if the request does not include a 'timeout' attribute.
889 Requests with identical subject, location and link-ID supersede pre-
890 vious LINK requests regardless of the timeout. Multiple links with
891 different link-IDs are permitted. They do not supersede each other.
893 4.2.3 UNLINK Request
895 The link from a border location to the location of the receiver is
896 deleted. The receiver SHOULD delete the link from its link graph.
898 Message fields:
899 subject = vpp-locationname ; REQUIRED (link destination)
900 method = UNLINK ; REQUIRED
901 Attributes:
902 location = vpp-locationname ; REQUIRED (link source)
903 link-id = vpp-reference ; OPTIONAL (link-ID)
904 delay = vpp-time ; OPTIONAL
906 The UNLINK request deletes a link only if subject, location, and
907 link-ID match, regardless of the 'distance' attribute of the related
908 LINK request.
910 The effect of the request can be delayed until an absolute time is
911 reached or a relative time has passed. The server MAY change the
912 delay. In this case it MUST return the new value.
914 4.2.4 LINK/UNLINK Response
916 The response data returns the response code and optional additional
917 information.
919 Message fields:
920 response-code = vpp-responsecode ; REQUIRED
921 additional-data = xml-encoded-data ; REQUIRED
923 The additional-data returns status information. The format for type
924 "text/xml" includes the vpp-responsecode:
926 link-response-data = vpp-responsecode-tag
927 [ vpp-responsemsg-tag ]
928 [ vpp-timeout-tag ]
929 [ vpp-delay-tag ]
931 The response code "404" in response to LINK requests indicates that
932 the subject of the message could not be found.
934 The response code "404" in response to UNLINK requests indicates that
935 the combination of subject, location, and link-ID could not be found.
937 The format for "text/plain" is:
938 plain-link-response-data = vpp-time [CRLF]
940 4.3 SUBSCRIBE/UNSUBSCRIBE
942 4.3.1 Introduction to Subscriptions
944 Subscriptions request notifications about the state of properties of
945 remote objects. A VPP instance uses subscriptions and in turn notifi-
946 cations to get information about the registration of users with loca-
947 tions maintained by remote VPP servers.
949 The need for such information arises when VPP Server 1 (figure below)
950 computes the set of neighbors of user U1. The border location Lb
951 links to location Lx maintained by another VPP server (Server 2).
952 Location La is virtually close to Lb, hence user U2 is in the vicin-
953 ity of U1.
955 The presence of U1 at Lb causes Server 1 to subscribe for the set of
956 users at or close to Lx. In turn notifications are being sent from
957 Server 2 to Server 1 when the set of users at or close to Lx changes.
958 This information is kept in the 'users' property of Lx.
960 The notification may also include users (U3) registered with Ly. The
961 range of locations included depends on the distance specified by the
962 subscription.
964 The subscriber MUST subscribe with the lowest distance possible. The
965 distance depends on the implementation, personal preferences of
966 users, site defaults, etc.
968 Example:
969 Be U1 registered with La but not with Lb, and be the virtual neigh-
970 borhood (distance) to be observed "2".
972 Server 1 subscribes for Lx.users with distance "0", because the
973 distance between Lx and La is "2", hence only users registered with
974 Lx are visible to U1. A notification returns U2.
976 If U1 moves to Lb, Server 1 subscribes again for Lx.users, but with
977 distance "1" to additionally cover users registered with locations
978 linked closely to Lx: here Ly. A notification returns U2 and U3.
980 VPP Server 1 || VPP Server 2
981 +----+ +----+ || +----+ +----+
982 | La | --1--> | Lb | --1---++-----> | Lx | --1--> | Ly |
983 | | | U1 | || | U2 | | U3 |
984 +----+ +----+ || +----+ +----+
986 U[1|2|3]: Users
987 L[a|b|x|y]: Locations
988 Numbers in links indicate the VPP distance
990 4.3.2 SUBSCRIBE Request
992 Subscribe for a property.
994 Message fields:
995 subject = vpp-locationname ; REQUIRED
996 property = vpp-property ; REQUIRED
997 method = SUBSCRIBE ; REQUIRED
998 Attributes:
999 sub-id = vpp-reference ; OPTIONAL (subscription-ID)
1000 reply-to = vpp-serviceurl ; REQUIRED
1001 timeout = vpp-time ; OPTIONAL
1002 delay = vpp-time ; OPTIONAL
1003 distance = vpp-distance ; OPTIONAL
1005 The subscription can be limited to an absolute or relative time. The
1006 server MAY change the time. The timeout value MUST be returned if it
1007 is changed or if the request does not include a 'timeout' attribute.
1009 The 'delay' attribute specifies the minimum delay between
1010 notifications.
1012 The distance indicates the range of locations to be included in
1013 notifications. Subscriptions with higher distance supersede subscrip-
1014 tions with lower distance if the subject, property, and
1015 subscription-ID match. The receiver may limit the distance. In this
1016 case it must return the new distance. The default distance for sub-
1017 scriptions is "0".
1019 Notifications are to be sent to the VPP server specified by the
1020 'reply-to' attribute.
1022 Multiple subscriptions for a property with different subscription-IDs
1023 are permitted.
1025 The receiver of a subscription request MUST send a notification of
1026 type 'UPDATED' if the content of the property changes. It MUST send a
1027 'DELETED' event if the property has been deleted.
1029 An immediate notification request with the current content of the
1030 property MUST be sent to the subscriber in response to a subscrip-
1031 tion, if the property is not empty. The response message to the sub-
1032 scription returns information about the subscription. It does not
1033 carry the content of the property.
1035 Note:
1036 No effort has been made to integrate the response to the subscription
1037 and the first notification into a single message. Reasons are:
1039 o It is expected that most subscriptions will result in multiple
1040 notifications. An initial notification of an empty property is
1041 not required.
1043 o Integration of the subscription response and of the first notif-
1044 ication into a single message does not reduce the amount of VPP
1045 protocol data transmitted. It also does not reduce overall net-
1046 work traffic if the same transport system connection is used.
1047 Using the same transport system connection means that the roles
1048 of client and server change.
1050 The receiver of a subscription request SHOULD preserve the informa-
1051 tion if the service is discontinued and resumed (e.g. between
1052 "runs").
1054 4.3.3 UNSUBSCRIBE Request
1056 Delete subscription for property.
1058 Message fields:
1059 subject = vpp-locationname ; REQUIRED
1060 property = vpp-property ; REQUIRED
1061 method = UNSUBSCRIBE ; REQUIRED
1062 Attributes:
1063 sub-id = vpp-reference ; OPTIONAL (subscription-ID)
1065 The UNSUBSCRIBE request deletes a subscription only if subject, pro-
1066 perty, and subscription-ID match.
1068 4.3.4 SUBSCRIBE/UNSUBSCRIBE Response
1070 The response data returns the response code and optional additional
1071 information.
1073 Message fields:
1074 response-code = vpp-responsecode ; REQUIRED
1075 additional-data = xml-encoded-data ; REQUIRED
1077 The format for "text/xml" is:
1078 subscribe-response-data = vpp-responsecode-tag
1079 [ vpp-responsemsg-tag ]
1080 [ vpp-timeout-tag ]
1081 [ vpp-distance-tag ]
1083 The response code "404" in response to SUBSCRIBE requests indicates
1084 that the subject or its property could not be found.
1086 The response code "404" in response to UNSUBSCRIBE requests indicates
1087 that the combination of subject, property, and subscription-ID could
1088 not be found.
1090 The format for "text/plain" is:
1091 plain-subscribe-response-data = vpp-time [CRLF]
1093 4.4 NOTIFY
1095 4.4.1 Request
1097 Notifications are repeatedly sent in response to subscriptions. They
1098 carry the information in the additional-data part.
1100 Message fields:
1101 subject = vpp-locationname ; REQUIRED
1102 property = vpp-property ; REQUIRED
1103 method = NOTIFY ; REQUIRED
1104 Attributes:
1105 sub-id = vpp-reference ; OPTIONAL (subscription-ID)
1106 event = vpp-event ; OPTIONAL (event type)
1107 additional-data = xml-encoded-data ; REQUIRED
1109 The notification is only accepted if subject, property, and
1110 subscription-ID match any of the subscriptions previously sent. Oth-
1111 erwise a "404" response code is returned.
1113 The event type is indicated by the 'event' attribute. The default
1114 event type is 'UPDATED'.
1116 The format of the additional-data depends on the property (see "Pro-
1117 perties"). The format for "text/xml" is:
1118 notify-request-data = property-data
1120 The format for "text/plain" is:
1121 plain-notify-request-data = plain-property-data ; see "Properties"
1123 4.4.2 Response
1125 Message fields:
1126 response-code = vpp-responsecode ; REQUIRED
1127 additional-data = xml-encoded-data ; REQUIRED
1129 The format of the additional-data of type "text/xml" is:
1130 notify-response-data = vpp-responsecode-tag
1131 [ vpp-responsemsg-tag ]
1133 The additional-data of type "text/plain" is empty.
1135 4.5 GET
1137 4.5.1 Request
1139 The GET method is used to retrieve the contents of a property.
1141 Message fields:
1142 subject = vpp-locationname ; REQUIRED
1143 property = vpp-property ; REQUIRED
1144 method = GET ; REQUIRED
1146 The response code "404" in response to GET requests indicates that
1147 the subject or its property could not be found.
1149 4.5.2 Response
1151 Message fields:
1152 response-code = vpp-responsecode ; REQUIRED
1153 additional-data = xml-encoded-data ; REQUIRED
1155 The format of the additional-data of type "text/xml" is:
1156 get-response-data = vpp-responsecode-tag
1157 [ vpp-responsemsg-tag ]
1158 property-data
1160 The additional-data of type "text/plain" is:
1161 plain-get-response-data = property-data
1163 5 Properties
1165 5.1 Location Subject
1167 Property data formats for the location's properties defined below:
1169 property-data = summary-property-data
1170 | users-property-data
1171 | links-property-data
1172 | symbol-property-data
1174 plain-property-data = plain-summary-property-data
1175 | plain-users-property-data
1176 | plain-links-property-data
1177 | plain-symbol-property-data
1179 5.1.1 Users Property
1181 The 'users' property contains a set of users which are within a cer-
1182 tain distance of the respective location. The 'users' property is
1183 REQUIRED.
1185 The format for "text/xml" is:
1186 users-property-data = *(vpp-neighbor-tag)
1188 vpp-neighbor-tag = ""
1189 "" vpp-username ""
1190 [ vpp-distance-tag ]
1191 ""
1193 The format for "text/plain" is:
1194 plain-users-property-data =
1195 *(vpp-username WSP vpp-distance CRLF)
1197 5.1.2 Links Property
1199 The 'links' property contains the edges of a node of the link graph
1200 used by the neighborhood server. Edges are described by destination
1201 (vpp-locationname), length (vpp-distance), and optional relative
1202 coordinates, which can be used to position nodes in graphical
1203 neighborhood displays. Support of the 'links' property is RECOM-
1204 MENDED.
1206 The format for "text/xml" is:
1207 links-property-data = *(vpp-link-tag)
1209 vpp-link-tag = ""
1210 "" vpp-locationname ""
1211 [ vpp-distance-tag ]
1212 [ "" vpp-coordinate ""
1213 "" vpp-coordinate ""
1214 "" vpp-coordinate "" ]
1215 [ "" [ vpp-href-tag ] "" ]
1216 ""
1218 vpp-href-tag =
1220 vpp-coordinate = [-] 1*DIGIT
1222 The vpp-href-tag contains the original HTML-tag. An empty vpp-href-
1223 tag indicates that the link exists only in the link graph of the VNS,
1224 but not in the original hypertext. This usually means that the link
1225 has been introduced artificially into the link graph of the VPP
1226 server to facilitate bidirectional visibility.
1228 Coordinate scaling has not been defined yet. But all coordinates of a
1229 VPP server MUST be based on the same scale.
1231 The format for "text/plain" is:
1232 plain-links-property-data =
1233 *( vpp-locationname WSP vpp-distance
1234 [ WSP vpp-coordinate vpp-coordinate vpp-coordinate ] CRLF )
1236 5.1.3 Symbol Property
1238 The 'symbol' property is used in text based and graphical displays to
1239 represent locations.
1241 symbol-property-data = [ vpp-title-tag ]
1242 [ vpp-icon-tag ]
1243 [ vpp-prototype-tag ]
1245 vpp-title-tag = "" *CHAR ""
1246 ; the title of the document represented by the location
1247 vpp-icon-tag = "" url ""
1248 ; a URL of a small graphical representation of the location
1249 vpp-prototype-tag = "" url ""
1250 ; a URL representing the class of URLs mapped to the location
1252 The format for "text/plain" is:
1253 plain-symbol-property-data = *CHAR CRLF httpurl
1255 5.1.4 Summary Property
1257 The 'summary' property provides a summary of the properties of the
1258 location and an indication of changes. Its purpose is to enable sub-
1259 scribers to reduce traffic and system load imposed by high volume
1260 notifications. Support of the 'summary' property is RECOMMENDED. The
1261 'summary' property SHOULD cover the properties, which may have large
1262 contents (e.g. 'users' and 'links'). It MAY cover other properties.
1264 The format for "text/xml" is:
1265 summary-property-data = [ vpp-userssummary-tag ]
1266 [ vpp-linkssummary-tag ]
1267 [ vpp-symbolsummary-tag ]
1269 vpp-userssummary-tag =
1270 ""
1271 vpp-count-tag ; indicating the number of users
1272 [ vpp-signature-tag ]
1273 ""
1275 vpp-linkssummary-tag =
1276 ""
1277 vpp-count-tag ; indicating the number of links
1278 [ vpp-signature-tag ]
1279 ""
1281 vpp-symbolsummary-tag =
1282 ""
1283 url [ vpp-signature-tag ]
1284 ""
1286 vpp-count-tag = "" 1*DIGIT ""
1287 vpp-signature-tag = "" 1*VCHAR ""
1289 The signature SHOULD be a short string. The signature is the finger-
1290 print of the property. It SHOULD not be interpreted by the receiver.
1291 The signature SHOULD change if the property data changes. An ASCII
1292 representation of a 32 bit CRC or an [MD5] digest of the property
1293 data is adequate for most applications.
1295 The format for "text/plain" is:
1296 plain-summary-property-data = 1*DIGIT ; the number of users
1298 5.2 User Subject
1299 VPP focuses on locations. Hence, the user subject and user properties
1300 are not included into the VPP specification. But VPP servers use and
1301 create properties of users internally. The most important user pro-
1302 perties are the set of locations at which a user is registered and
1303 the set of neighbors. They are the results of the VNS and they are
1304 fed into a presence notification service in order to be presented to
1305 users.
1307 We hope that it will not be necessary to add the 'user' subject to
1308 this specification. Progress in the definition of presence notifica-
1309 tion protocols will make this part of the current implementation
1310 obsolete.
1312 This section decribes the data maintained within a VPP server as if
1313 it where available directly from the VPP server so that implementors
1314 of presence notification service components know what can be expected
1315 from a virtual presence server.
1317 5.2.1 Locations Property
1319 The format for "text/xml" is:
1320 user-locations-property-data = *(vpp-presence-tag)
1322 vpp-presence-tag = ""
1323 "" vpp-locationname ""
1324 [ "" vpp-locationname "" ]
1325 [ vpp-strength-tag ]
1326 ""
1328 vpp-strength-tag = ""
1329 ( "1.0" | "0." 1*DIGIT )
1330 ""
1332 The default strength is "1.0".
1334 The format for "text/plain" is:
1335 plain-user-locations-property-data = *(vpp-locationname CRLF)
1337 5.2.2 Neighbors Property
1339 The format for "text/xml" is:
1340 user-neighbors-property-data = *(vpp-neighbor-tag)
1342 The format for "text/plain" is:
1343 plain-user-neighbors-property-data = *(vpp-username CRLF)
1345 6 HTTP/1.1 Encapsulation
1346 6.1 Encapsulation Properties
1348 HTTP has been chosen as host protocol for several reasons:
1350 o HTTP passes firewalls because HTTP firewall gates and HTTP prox-
1351 ies are very common.
1353 o HTTP requests can easily be generated by WWW clients and in turn
1354 response data is displayed by the client. This is important for
1355 the development phase.
1357 o VPP servers might be integrated with HTTP servers, hence use of
1358 the same protocol engine is advantageous.
1360 Most VPP requests use the HTTP/1.1 GET method. VPP request message
1361 data is encoded into the HTTP request line. Only VPP requests which
1362 carry additional data (NOTIFY) use the HTTP POST method. VPP
1363 responses carry VPP message data in the message body of HTTP
1364 responses.
1366 Type and size of VPP data uses HTTP header fields to be compatible
1367 with HTTP clients.
1369 There are other ways to embed VPP into HTTP/1.1, e.g.
1371 o use of the HTTP message body only, without parameter encoding
1372 into the request line or
1374 o extensive use of HTTP header fields.
1376 The encoding described here has been chosen for ease of debugging
1377 with HTTP clients.
1379 6.2 Encapsulation Rules
1381 6.2.1 Basic Rules
1383 The following fields are defined here because they might look dif-
1384 ferent when encapsulated into another protocol, especially if the
1385 host protocol is not ASCII based:
1387 vpph-method = "enter"
1388 | "leave"
1389 | "link"
1390 | "unlink"
1391 | "subscribe"
1392 | "unsubscribe"
1393 | "notify"
1394 | "get"
1395 | "service"
1396 | other-vpph-method
1398 vpph-subject = vpp-locationname
1399 | other-vpph-subject
1401 vpph-property = vpph-location-property
1402 | other-vpph-property
1404 vpph-location-property = "users"
1405 | "links"
1406 | "symbol"
1407 | "summary"
1408 | other-vpph-property
1410 vpph-attribute = "user"
1411 | "location"
1412 | "previous"
1413 | "reg-id"
1414 | "link-id"
1415 | "sub-id"
1416 | "timeout"
1417 | "delay"
1418 | "distance"
1419 | "reply-to"
1420 | other-vpph-attribute
1422 vpph-event = "updated"
1423 | "deleted"
1424 | other-vpph-event
1426 vpph-attribvalue = 1*CHAR
1428 vpph-data-type = media-type
1429 ; Internet Media Types registered with the
1430 ; Internet Assigned Number Authority (IANA) [RFC 2048].
1432 vpph-data-length = 1*DIGIT ; decimal number of octets
1434 other-vpph-method = token ; to be defined on demand
1435 other-vpph-subject = token
1436 other-vpph-property = token
1437 other-vpph-attribute = token
1438 other-vpph-event = token
1440 VPP additional-data uses the HTTP body part. VPP data-legth and VPP
1441 data-type MUST use the HTTP header fields "Content-length" and
1442 "Content-type".
1444 The HTTP version used is "HTTP/1.1"
1446 See appendix "HTTP Encapsulation Examples"
1448 6.2.2 Request
1450 VPP requests are embedded into HTTP requests by the following URL:
1452 http_URL = vpp-serviceurl "?" vpp-urlencoded
1454 vpp-urlencoded = [ "op=" vpph-method ]
1455 [ "&" "ver=" vpp-serviceversion ]
1456 [ "&" "subject=" vpph-subject ]
1457 [ "&" "property=" vpph-property ]
1458 [ *( "&" vpph-attribute "=" vpph-attribvalue) ]
1460 The query part (vpp-urlencoded) MUST be encoded according to chapter
1461 2.2. of [URL]. This means that unsafe characters MUST be replaced by
1462 their 2 digit hexcode preceeded by "%".
1464 Most VPP requests use the HTTP "GET" method. VPP requests which carry
1465 data in the HTTP body part use the "POST" method. The "op=" query
1466 parameter may be omitted for VPP GET requests.
1468 6.2.3 Response
1470 The VPP response code for additional-data of type "text/plain" MUST
1471 be encoded into the HTTP status code.
1473 The HTTP status code of VPP responses with additional-data of type
1474 "text/xml" MUST be "200".
1476 Responses, except responses to VPP GET requests, MUST be marked as
1477 not cachable. The following HTTP headers may be used:
1478 Cache-control: no-cache
1479 Expires: Thu, 01 Jan 1970 01:01:01 GMT
1481 6.3 Forced LEAVE
1483 On program failure or system failure VPP clients often do not send
1484 LEAVE requests. The user remains The registered with a location until
1485 the timeout of the ENTER request expires. VPP clients which expect
1486 such failures and want to improve the behaviour of the VNS in these
1487 cases MAY use an additional attribute, to force a LEAVE operation.
1489 Attribute:
1491 onclose = vpph-onclose-action ; OPTIONAL
1493 vpph-onclose-action = "leave" | "stay" ; "stay" is default
1494 other-vpph-attribute = "onclose"
1496 The "onclose=leave" attribute/value pair of an ENTER request makes
1497 the registration of a user dependent of the state of the TCP connec-
1498 tion which carries the ENTER request. If the TCP connection closes,
1499 then the server MUST generate a LEAVE request on behalf of the client
1500 for the combination of location, user, and registration-ID of the
1501 ENTER request.
1503 Multiple ENTER requests may be attached to the same TCP connection.
1505 VPP clients MUST NOT rely upon the 'onclose' attribute as a substi-
1506 tute for LEAVE requests.
1508 Client action:
1509 Add 'onclose' attribute with value "leave" to ENTER requests.
1511 Server action:
1512 Store parameters of the ENTER request, monitor the TCP connection,
1513 and generate a LEAVE request if the connection closes:
1515 subject = vpp-locationname ; from ENTER request
1516 method = LEAVE
1517 Attributes:
1518 user = vpp-username ; from ENTER request
1519 reg-id = vpp-reference ; from ENTER request
1520 delay = "0"
1522 7 Traffic Considerations
1524 7.1 Overview
1526 The VNS generates significant traffic. The number of VPP messages is
1527 in the order of HTTP requests, but with much lower volume. Traffic
1528 generated by careless implementations can be in the order of the
1529 number of available documents, but effort has been made to limit the
1530 volume to a small fraction of the HTTP traffic. Implementors must
1531 consider the recommendations below.
1533 In general, VPP traffic may use optimizations provided by the host
1534 protocol, i.e. multiple requests on a single transport system connec-
1535 tion and pipelining [HTTP/1.1].
1537 7.2 ENTER/LEAVE
1538 The authors recognize that the number of ENTER and LEAVE requests is
1539 in the order of Web pages visited. However, we suppose that the
1540 traffic generated by this part of VPP will be only a small fraction
1541 of the overall document related traffic:
1543 o Requests are of the size of HTTP requests or smaller. Responses
1544 do not carry significant content.
1546 o There are only 2 VPP requests compared to (often) multiple HTTP
1547 requests per document (see [Microscape]).
1549 o Web sites which do not offer neighborhood services get at most 2
1550 Associated Server Lookup requests. VPP clients must not send
1551 ENTER/LEAVE requests, if the VPP server lookup failed.
1553 o If VPP servers are integrated with document servers, then VPP
1554 traffic may use the same (persistent) transport system connec-
1555 tion.
1557 7.3 LINK/UNLINK
1559 The purpose of LINK requests is to prepare for subscriptions in the
1560 reverse direction. A LINK request should only be issued if a sub-
1561 scription for information about users on the border location is prac-
1562 tical, i.e. if there are users at or close to location linked to the
1563 border location.
1565 LINK requests generate only a small fraction of the ENTER/LEAVE
1566 traffic
1568 o Requests are usually only issued if users are registered with a
1569 border location or close to the border location.
1571 o LINK requests are rare. The actual number depends on the fre-
1572 quency of hyperlink changes. VPP servers should allow for LINK-
1573 timeout values in the order of days.
1575 o UNLINK requests are very rare. LINKs usually expire rather than
1576 being UNLINKed.
1578 o Implementations should limit border links to a reasonable
1579 number.
1581 o VNS on index sites (search engines, etc.) should select VPP-
1582 links as they are already selecting so-called "related-pages" by
1583 search terms. It is expected that this method reduces the number
1584 of border links, hence the number of LINK requests.
1586 7.4 SUBSCRIBE/UNSUBSCRIBE/NOTIFY
1588 Subscriptions are usually only issued in response to LINK requests,
1589 thus they generate a similar amount of traffic. Notifications depend
1590 on the number of visits (order of HTTP requests), but only if users
1591 ENTER/LEAVE border locations. Hence the traffic is usually smaller
1592 than the traffic of ENTER/LEAVE requests on border locations and
1593 smaller than the HTTP traffic of the border pages only, and much
1594 smaller than the overall HTTP traffic.
1596 o A subscription should only be sent, if the information is
1597 required, i.e. if users are at or close to the border location.
1599 o Notifications communicate information about many users on a
1600 group of locations. They should not be sent for any single
1601 change. Changes (ENTER/LEAVE requests) should be accumulated for
1602 a reasonable time (seconds).
1604 o Implementations should monitor the traffic and increase update
1605 intervals if the total traffic increases.
1607 o Notifications should only be sent in response to ENTER/LEAVE
1608 requests or other notifications.
1610 o Subscribers which suffer under high load imposed by large notif-
1611 ications should switch to the respective summary property and
1612 either use the summary provided, or watch the signatures and
1613 request property data on demand.
1615 7.5 Service Lookup
1617 VPP clients need the VPP service URL for each document visited by the
1618 document client. They should try to minimize the number of lookup
1619 requests:
1621 o Clients should keep a cache of VPP service URL lookups.
1623 o VPP clients should try to estimate the service URL for a given
1624 document URL based on previous lookups. This is similar to the
1625 scheme used by HTTP clients to estimate the HTTP authentication
1626 scheme and parameters based on similarities between URLs.
1628 We suppose that the number of service lookups is in the order of web
1629 site visits.
1631 8 Security Considerations
1633 8.1 User Privacy
1634 The VNS facilitates tracking of users. It goes beyond the information
1635 voluntarily provided by clients of presence notification protocols.
1636 VPP clients (not servers) are the source for virtual presence infor-
1637 mation. If they are integrated with HTTP clients then there should be
1638 a way to control (and disable) the operation. The recommended prac-
1639 tice is to explicitely notify the user at least once about the ser-
1640 vice and the privacy issues. The negotiation should be carried out
1641 automatically using [P3P] (data category "Navigation and Click-stream
1642 Data") once P3P is supported by document clients.
1644 User detail is not disclosed by the VNS. This is the task of a pres-
1645 ence notification service which maintains user detail (hopefully)
1646 under control of the user.
1648 Generally we regard the virtual space as being very similar to the
1649 real world where people are used to being seen by or being aware of
1650 others. The VNS re-creates this for the document space. But still the
1651 visibility can be swichted off as opposed to the real world.
1653 8.2 Access Control
1655 Some VPP requests use tokens to refer to previous requests (initial
1656 requests). Correct references are required to validate requests which
1657 refer to previous ones. The tokens should be created in a way which
1658 protects them from being re-created by attackers.
1660 Notfications are validated the same way. The subscription-ID serves
1661 as a ticket which allows the subscribed party to send notifications.
1663 The protection (encryption) of token transmission is currently left
1664 to the host protocol.
1666 Protection of initial requests (e.g. ENTER, LINK) is a critical
1667 issue. Access authorization will be used similar to HTTP or other
1668 document services. But many Web sites do not have access restrictions
1669 at all. VPP initial requests for unprotected locations are as open to
1670 anyone as is the read access (e.g. HTTP-GET) to unprotected docu-
1671 ments.
1673 Implementations should consider posing limitations on initial
1674 requests. This means that the VPP server must maintain a reasonable
1675 amount of state. It may:
1677 o limit the number of ENTER requests per user for a period of
1678 time,
1680 o limit the number of registrations per user,
1681 o limit the number of LINK requests per originating VPP instance.
1682 The originating VPP instance can be derived from the 'location'
1683 attribute of LINK requests,
1685 o limit the number of subscriptions per "reply-to" address,
1687 o monitor overall load to detect denial of service attacks. Denial
1688 of service attacks are usually more critical to VPP servers than
1689 they are to document servers, because attackers can pose a
1690 higher system load with less or equal amount of bandwidth used
1691 for the attack.
1693 8.3 Security of Documents
1695 Documents are represented by nodes of the link graph. The security of
1696 documents is generally not affected. There is no write access at all
1697 to documents. But the current specification allows for unlimited read
1698 access to parts of the information contained in documents, even if
1699 the documents are protected by the document server. Document based
1700 access limitations (e.g. HTTP authorization) will be preserved by VPP
1701 to solve these issues once a authorization scheme has been selected
1702 for VPP. For the time being:
1704 o anyone can retrieve the set of hypertext references of a docu-
1705 ment, if the VPP server supports the 'links' property,
1707 o anyone may be able to retrieve symbolic information of a docu-
1708 ment, e.g. the title or an icon, if the VPP server supports the
1709 'symbol' property,
1711 o anyone may get information about the existence of a document
1712 through VPP even if HTTP access to higher levels of the hierar-
1713 chy is restricted and thus the document is invisible through the
1714 document server.
1716 9 Appendices
1718 9.1 Location Mapping
1720 9.1.1 Traditional File Based
1722 Many Web sites are based on files in a hierarchical file system. URLs
1723 are mapped to file system access paths. In many cases a document can
1724 be referenced by multiple different URLs. Examples are "default
1725 files" of directories and heuristics of HTTP servers, e.g. appending
1726 ".html" to URIs. However, users expect to be virtually present on the
1727 same document even if it can be accessed by multiple URLs. We there-
1728 fore suggest to use the final file access path as node name in the
1729 neighborhood server's link graph.
1731 This means that the neighborhood server must be able to reproduce the
1732 mapping from relative URLs to file access paths by the HTTP server. A
1733 full or partial integration of the neighborhood server or its loca-
1734 tion mapping component into the respective document server software
1735 is advantageous.
1737 9.1.2 Document Databases
1739 A growing percentage of Web sites does not rely on static files, but
1740 on document databases. Documents are often dynamically compiled of
1741 multiple fragments (database records). Again, the neighborhood server
1742 must be able to reproduce the mapping of the document server. This
1743 means that it might be necessary to provide a location mapper CGI
1744 program in addition to the CGI program which creates the documents.
1746 The expectation of the user is the primary guideline for the mapping
1747 process. We can give only hints here:
1749 o if a document consists of a core fragment and framework (e.g. an
1750 online newspaper article), then the node name may be the iden-
1751 tification of the core fragment (the record number, query param-
1752 eters, etc).
1754 o if a single document can be presented in different variants,
1755 then we suggest mapping all variants to a single node name.
1757 o if a document consists of multiple fragments, but does not build
1758 around a single core element, then implementors might consider
1759 the following strategy: each fragment is represented by a node
1760 in the link graph. Users are registered with all nodes (loca-
1761 tions). The virtual distance between these nodes does not have
1762 to be "0". This applies also to "frame pages".
1764 9.1.3 Database Queries
1766 Database queries (e.g. search engines) often return documents which
1767 consist of a large number of fragments. Fragments can be mixed to
1768 form similar documents or totally different documents. Registration
1769 of users with a large number of locations (one for each fragment) is
1770 not feasible. A different approach must be taken.
1772 Search engines may create a link graph of search terms rather than a
1773 graph of documents. The pre-processing and association of terms
1774 required is already done by many search engines for other purposes.
1776 If documents are not compiled of multiple fragments but a database
1777 returns identical documents for different queries, then the node name
1778 may be derived from the query result, e.g. by using a CRC of arbi-
1779 trary length on the document contents.
1781 9.2 User Names
1783 User names contained in neighborhood lists are interpreted when they
1784 are displayed to users of the VNS. This section defines the interpre-
1785 tation for specific naming schemes.
1787 9.2.1 HTTP URL
1789 An HTTP URL is used as the base URL for additional user detail. The
1790 additional user detail SHOULD be available from URLs created by a
1791 concatenation of the base URL and some well known file names. If the
1792 last character is not a "/" character, then a "/" is automatically
1793 appended to the base URL (baseurl).
1795 user_detail_URL = baseurl filename
1797 File names and formats are not part of VPP. They are included here as
1798 an example. A detailed description of formats used by the current
1799 implementation will be provided in a separate document.
1801 The current implementation defines the following file names:
1802 "properties" - a CRLF separated list of name/value pairs, like:
1803 realname= Nick
1804 linkdist= 2
1805 visibility= on
1806 "icon.gif" - a GIF image. Its dimensions should be 32x32 pixel.
1807 "image.jpg" - a JPEG image of any size.
1809 9.2.2 Internet Domain Name or Address
1811 An HTTP URL (url) is created from an internet domain name or internet
1812 address (host):
1814 url = "http://" host "/"
1816 The URL is then used as described above.
1818 9.3 HTTP Encapsulation Examples
1820 XML namespace specifications, 'Content-length' and other HTTP headers
1821 have been omitted from most examples. Request URLs are not "%"
1822 encoded. A "|" denotes a message line. Lines are separated by CRLF. A
1823 "+" denotes a continued line.
1825 9.3.1 Service Lookup
1827 A user opens the URL http://www.cobrow.com/. The VPP client deter-
1828 mines the service URL of the associated VPP server.
1830 Request to www.cobrow.com at 80:
1831 | GET /_service/vpp?op=service
1832 + &location=http://www.cobrow.com/ HTTP/1.1
1833 |
1834 |
1836 Response:
1837 | HTTP/1.1 200 OK
1838 | Content-type: text/xml
1839 | Content-length: 153
1840 |
1841 |
1842 |
1843 | 200 2.0
1844 | http://www.cobrow.com:4145/vpp
1846 9.3.2 Enter
1848 Request to www.cobrow.com at 4145:
1849 | GET /vpp?ver=2.0&subject=http://www.cobrow.com/
1850 + &method=enter&user=rvp://rvp.widgets.com/bill
1851 + ®-id=some-secret-number-1231424255
1852 + &timeout=86400 HTTP/1.1
1853 |
1855 Response:
1856 | HTTP/1.1 200 OK
1857 | Content-type: text/xml
1858 |
1859 | 200 2.0
1860 | 300
1862 9.3.3 Leave
1864 Request to www.cobrow.com at 4145:
1865 | GET /vpp?ver=2.0&subject=http://www.cobrow.com/
1866 + &method=leave&user=rvp://rvp.widgets.com/bill
1867 + ®-id=some-secret-number-1231424255 HTTP/1.1
1868 |
1870 9.3.4 Link
1872 The VPP server of http://www.cobrow.com/ announces a link to
1873 http://www.netscape.com/. Assumed the VPP service URL of
1874 http://www.netscape.com/ is http://vpp.netscape.com:81/
1876 Request to vpp.netscape.com at 81:
1877 | GET /vpp?ver=2.0&subject=http://www.netscape.com/
1878 + &method=link&location=http://www.cobrow.com/
1879 + &link-id=some-secret-number-34564745
1880 + &timeout=200000 HTTP/1.1
1881 |
1883 Response:
1884 | HTTP/1.1 200 OK
1885 | Content-type: text/xml
1886 |
1887 | 200 2.0
1889 9.3.5 Subscribe
1891 Request to www.cobrow.com at 4145:
1892 | GET /vpp?ver=2.0&subject=http://www.cobrow.com/
1893 + &method=subscribe&property=users&distance=2
1894 + &sub-id=some-secret-number-32874387267
1895 + &reply-to=http://vpp.netscape.com:81/ HTTP/1.1
1896 |
1898 Response:
1899 | HTTP/1.1 200 OK
1900 | Content-type: text/xml
1901 |
1902 | 200 2.0
1903 | 06 Nov 1998 08:49:37 GMT
1904 | 1
1906 9.3.6 Notify
1908 A notification in response to the subscription from
1909 http://vpp.netscape.com:81/ and on the registration of
1910 rvp://rvp.widgets.com/bill with http://www.cobrow.com/.
1912 Request to vpp.netscape.com at 81:
1913 | POST /vpp?ver=2.0&subject=http://www.cobrow.com/
1914 + &method=notify&property=users&event=updated
1915 + &sub-id=some-secret-number-32874387267 HTTP/1.1
1916 | Content-type: text/xml
1917 |
1918 |
1919 | rvp://rvp.widgets.com/bill
1920 | 0
1921 |
1922 |
1923 | 134.60.77.255
1924 |
1926 Response omitted.
1928 10 References
1930 [RVP] M. Calsyn, L. Dusseault, G. Mohr, "RVP: A Presence Notification
1931 Protocol", draft-calsyn-rvp-01.txt, INTERNET-DRAFT, work in progress,
1932 expires: Sept 1998.
1934 [RVPAddr] L. Dusseault, G. Mohr, "Addressing and Location for RVP" ,
1935 draft-dusseault-rvp-addr-00.txt, INTERNET-DRAFT, work in progress,
1936 expires: Sept 1998
1938 [Bradner97] S. Bradner, "Key words for use in RFCs to indicate
1939 requirement levels," RFC 2119, Internet Engineering Task Force, Mar.
1940 1997.
1942 [HTTP/1.1] Fielding R., Gettys J., Mogul J., Frystyk H. and Berners-
1943 Lee T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January
1944 1997.
1946 [URL] Berners-Lee T., Masinter L., McCahill M., "Uniform Resource
1947 Locators (URL)", RFC 1738, Dec 1994.
1949 [ABNF] D. Crocker, Ed., P. Overell., "2234 Augmented BNF for Syntax
1950 Specifications: ABNF", RFC 2234, November 1997.
1952 [DNS SRV] Gulbrandsen A. and Vixie P., "A DNS RR for specifying the
1953 location of services (DNS SRV)", RFC 2052, October 1996.
1955 [SLP] E. Guttman, C. Perkins, S. Kaplan, "Service Location Protocol",
1956 RFC 2165, June 1997.
1958 [Microscape] H.F. Nielsen, Jim Gettys, A. Baird-Smith, E.
1959 Prud'hommeaux, H. Lie, "Network Performance Effects of HTTP/1.1, CSS1
1960 and PNG", ACM SIGCOMM 97.
1962 [RFC 2048] Postel, J., "Media Type Registration Procedure", RFC 2048,
1963 USC/ISI, November 1996.
1965 [MD5] R. Rivest. "RFC 1321 -- The MD5 Message-Digest Algorithm," MIT.
1966 April 1992.
1968 [P3P] M. Marchiori, D.Jaye, "Platform for Privacy Preferences (P3P)
1969 Syntax Specification", WD-P3P-syntax, W3C Working Draft.
1971 [Message-id] M. Curtin, J. Zawinski, "Recommendations for generating
1972 Message IDs", INTERNET DRAFT, work in progress, , July 1998
1975 11 Acknowledgements
1977 We used parts of the Internet Drafts draft-calsyn-rvp-01.txt and
1978 draft-dusseault-rvp-addr-00.txt by M. Calsyn, L. Dussault, and G.
1979 Mohr, and adapted them to our needs.
1981 Many people were or are involved in our work on virtual neighborhood
1982 services. They have implemented components, tested the system, shared
1983 ideas, and given valuable feedback.
1985 Alphabetically: Holger Boenisch (UUlm), Ehsan Chirazi (UBruxelles),
1986 Marcel Dasen (ETHZ), Heiner Erne (Hirschmann), Stefan Fiedler (UUlm),
1987 Konrad Froizheim (UUlm), Philipp Hiller, David Hutchinson (ULancas-
1988 ter), Michael Merz (TUT Systems), Stefan Schmidt (ULancaster), Andrew
1989 Scott (ULancaster), Michael Weber (UUlm).
1991 12 Author's Address
1993 Klaus H. Wolf
1994 Distributed Systems Dept.
1995 University of Ulm
1996 89069 Ulm
1997 Germany
1998 Phone: +49 (731) 502 4145
1999 EMail: wolf@informatik.uni-ulm.de
2001 Draft expires: February 1, 1999