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