INTERNET-DRAFT K. H. Wolf Expires: February 1, 1999 University of Ulm VPP: Virtual Presence Protocol draft-wolf-vpp-00.txt Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." Distribution of this document is unlimited. To view the entire list of current Internet Drafts, please check the "1id-abstracts.txt" listing contained in the Internet Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract The purpose of the Virtual Presence Protocol (VPP) protocol is to enable the exchange of document based virtual presence information. Virtual presence information is the foundation for virtual neighborhood services which provide users with information about virtual neighbors, i.e. other users who are close within the virtual document space. VPP enables the creation of dynamic vicinities based on hypertext references. It is not meant to replace or supersede presence notification protocols, but it augments online presence with location information. The protocol described in this document is based on 2 years of experience with location based virtual presence and presence notification. The purpose of presence notification protocols such as the drafted [RVP] is to tell whether another individual is online or arrives online, etc. As opposed to such real online presence, the presence on documents in the World Wide Web is a virtual one. The authors recognize that VPP shares methods, mechanisms, and formats with HTTP, Wolf [Page 1] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 and drafted presence notification protocols (e.g. RVP), however the functionality is significantly different. Structure of the Document The document starts by introducing the need for a virtual neighborhood service and definitions of terms used by the document. It explains the purpose, components, and operation of the virtual neighborhood service. The second part introduces the protocol and defines protocol elements at an abstract level. Data formats are then presented, followed by details of how the protocol may be encapsulated within HTTP. The third part of the document covers security considerations and a best current practice section with traffic considerations, other recommendations, and examples. Table of Contents 1 Introduction ............................................ 4 1.1 Problem to be solved ................................... 4 1.2 Terminology ............................................ 4 1.3 Virtual Neighborhood Service ........................... 5 1.3.1 Purpose ............................................... 6 1.3.2 VPP Client and VPP Server ............................. 6 1.3.3 Typical Operation ..................................... 7 1.3.4 Link Graph ............................................ 8 1.4 Relation to other Protocols ............................ 8 2 Protocol Overview ....................................... 9 2.1 Purpose ................................................ 9 2.2 Protocol Neutral ....................................... 9 2.3 General Format ......................................... 9 2.4 Basic Definitions ...................................... 10 2.4.1 Distance Definition ................................... 11 2.5 Data Formats ........................................... 11 2.6 Access Control ......................................... 13 3 Naming and Addressing ................................... 13 3.1 Locations .............................................. 13 3.2 Users .................................................. 13 3.3 Finding VPP Servers .................................... 14 3.3.1 DNS SRV Records ....................................... 14 3.3.2 Service Location Protocol ............................. 15 3.3.3 Associated Server Lookup .............................. 15 3.3.3.1 Request .............................................. 15 3.3.3.2 Response ............................................. 16 4 Messages ................................................ 16 4.1 ENTER/LEAVE ............................................ 16 Wolf [Page 2] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 4.1.1 ENTER Request ......................................... 16 4.1.2 LEAVE Request ......................................... 17 4.1.3 ENTER/LEAVE Response .................................. 17 4.2 LINK/UNLINK ............................................ 18 4.2.1 Introduction to Linking ............................... 18 4.2.2 LINK Request .......................................... 18 4.2.3 UNLINK Request ........................................ 19 4.2.4 LINK/UNLINK Response .................................. 20 4.3 SUBSCRIBE/UNSUBSCRIBE .................................. 20 4.3.1 Introduction to Subscriptions ......................... 20 4.3.2 SUBSCRIBE Request ..................................... 21 4.3.3 UNSUBSCRIBE Request ................................... 22 4.3.4 SUBSCRIBE/UNSUBSCRIBE Response ........................ 23 4.4 NOTIFY ................................................. 23 4.4.1 Request ............................................... 23 4.4.2 Response .............................................. 24 4.5 GET .................................................... 24 4.5.1 Request ............................................... 24 4.5.2 Response .............................................. 24 5 Properties .............................................. 25 5.1 Location Subject ....................................... 25 5.1.1 Users Property ........................................ 25 5.1.2 Links Property ........................................ 25 5.1.3 Symbol Property ....................................... 26 5.1.4 Summary Property ...................................... 27 5.2 User Subject ........................................... 27 5.2.1 Locations Property .................................... 28 5.2.2 Neighbors Property .................................... 28 6 HTTP/1.1 Encapsulation .................................. 28 6.1 Encapsulation Properties ............................... 29 6.2 Encapsulation Rules .................................... 29 6.2.1 Basic Rules ........................................... 29 6.2.2 Request ............................................... 31 6.2.3 Response .............................................. 31 6.3 Forced LEAVE ........................................... 31 7 Traffic Considerations .................................. 32 7.1 Overview ............................................... 32 7.2 ENTER/LEAVE ............................................ 32 7.3 LINK/UNLINK ............................................ 33 7.4 SUBSCRIBE/UNSUBSCRIBE/NOTIFY ........................... 34 7.5 Service Lookup ......................................... 34 8 Security Considerations ................................. 34 8.1 User Privacy ........................................... 34 8.2 Access Control ......................................... 35 8.3 Security of Documents .................................. 36 9 Appendices .............................................. 36 9.1 Location Mapping ....................................... 36 9.1.1 Traditional File Based ............................... 36 Wolf [Page 3] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 9.1.2 Document Databases ................................... 37 9.1.3 Database Queries ..................................... 37 9.2 User Names ............................................. 38 9.2.1 HTTP URL .............................................. 38 9.2.2 Internet Domain Name or Address ....................... 38 9.3 HTTP Encapsulation Examples ............................ 38 9.3.1 Service Lookup ........................................ 39 9.3.2 Enter ................................................. 39 9.3.3 Leave ................................................. 39 9.3.4 Link .................................................. 39 9.3.5 Subscribe ............................................. 40 9.3.6 Notify ................................................ 40 10 References .............................................. 41 11 Acknowledgements ........................................ 42 12 Author's Address ........................................ 42 1 Introduction 1.1 Problem to be solved The World Wide Web is increasingly regarded as a virtual space rather than a linked collection of documents. People get the impression that they enter Web sites, and Web pages; in many cases they notice the past or present presence of others, though this notion is usually indirectly conveyed through access counters, statistics, or the effects of other peoples actions on interactive Web sites. The awareness horizon is in most cases limited to a small set of documents on a single Web site. Reasons for these limitations are: o The lack of information about documents presented to a user at a certain time. Only the request for a document is registered by most existing document servers, not the dura- tion of the document's presentation. o The lack of presence information exchange between Web sites. Hence, virtual presence on documents can not span hypertext references between documents on different sites. The Virtual Presence Protocol offers a means to exchange information about user-document relations. It is the foundation for a virtual neighborhood service that provides users with information about vir- tual neighbors, i.e. other users who are close to each other in terms of the set of documents visited. The document based neighborhood may span multiple Web sites. 1.2 Terminology Wolf [Page 4] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" are to be interpreted as described in RFC 2119 [Bradner97] and indicate requirement levels for compliant VPP imple- mentations. Syntax definitions are in [ABNF] or from [HTTP/1.1]. Location A reference to a network accessible document. A "resource" addressed by a URL. Border Location User are considered to be at a border location if the document they are viewing contains a link to a document on a different document server. Border Link A link between documents on different document servers. Document Server The software process which makes document resources accessible to network protocols. HTTP and FTP servers are document servers. Vir- tual Neighborhood Service. See next section. VPP Server / Neighborhood Server The software process which implements the VPP protocol and offers the virtual neighborhood service. VPP Client The part of a software process which submits information about the location of users. User Usually a single human. A user operates directly or indirectly a VPP client. A software process can be registered with locations like a human. In this case it is regarded as a user. Neighbor A user which is registered with locations within a defined proxim- ity to locations of another user. Neighborhood List Set of neighbors (users) computed by the virtual neighborhood ser- vice. VPP Subject The active instance of a VPP request. It is expected that a VPP server maps VPP requests to methods of the request's subject. The VPP subject is the equivalent to the resource of HTTP requests. Property A named attribute of a VPP subject. Subscription A subscription is a request that will result in multiple responses, one for each change in the subscribed property. 1.3 Virtual Neighborhood Service Wolf [Page 5] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 1.3.1 Purpose The virtual neighborhood service (VNS) provides users with informa- tion about virtual neighbors, i.e. other users who are close to each other in terms of the documents they are presented with. The VNS is a network of loosely coupled VPP servers. Users can be registered at locations regardless of whether they are reading the document. This enables temporarily extended presence on documents. A user's virtual neighborhood is defined by the documents the user is registered with, and the links of these documents to other documents. Documents may be static or dynamically created. Links between docu- ments may be physically encoded into the documents (e.g. hypertext references in HTML documents), stored externally in a link database, or statically or dynamically derived from other properties of docu- ments, e.g. by content matching. A VNS uses links between locations, and information about the loca- tions of users to create dynamically changing sets of associated users. The algorithm used to compute these sets depends on the imple- mentation of the VNS. The sets of associated users (virtual neigh- bors) are the main result of the operation of a neighborhood service. They are created for every user and each set is finally presented to the respective user. The set of neighbors is a user property. VPP maintains locations and their properties whereas presence notification services maintain users and user properties. Hence the access to the set of neighbors is not part of VPP. The results must be fed into a presence notifica- tion service to be available to presence notification clients. This transfer may be done by an HTTP server, an HTTP client, an RVP server, an RVP client, by data sharing between VPP and RVP server or another kind of software component. It will be described in a separate document. 1.3.2 VPP Client and VPP Server Information about the registration of users with locations is exchanged between a VPP client and a VPP server. On the other hand VPP servers exchange information about users and locations. The information exchanged between servers is usually derived from the information obtained by client-server interaction. Messages used by server-server interaction can also be used to present users with the results of the service. However retrieval (and visualization) of results is intentionally not specified here. A network of VPP clients and VPP servers may look like this: Wolf [Page 6] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 Client --v--> Server <--v--> Server <--v-+ | |---- Client v--> Server <--v-+ | v: VPP data VPP clients are typically integrated with HTTP clients or clients for other protocols with similar functionality, i.e. the retrieval and presentation of documents (document clients). But VPP clients can be operated independently of document clients to enable virtual presence independent of any document presentation. VPP servers are typically, but not necessarily, co-located with docu- ment servers, such as HTTP servers or FTP servers. But VPP servers can be operated without associated document servers to create virtual neighborhoods independent of real documents. 1.3.3 Typical Operation This section describes the typical application of a neighborhood server. Other applications are possible. A neighborhood server usually accompanies one or more document servers. It maintains a link graph, i.e. a graph of nodes and edges which represent documents and links of one or more document servers. The neighborhood server maps document locations of its associated document servers to nodes of the link graph. Edges may be derived from hypertext references. The links are weighted. A way to weight links derived from hypertext references is to augment HTML-anchor tags with weights. Edges can be bi-directional. Document clients retrieve and display documents for a user. The asso- ciated VPP client registers the user with the respective location at the VPP server/neighborhood server. The same happens for other users. If users are registered with border locations then the VPP server subscribes for information on users registered with locations linked to the border location. The subscription is directed to a peer VPP server. In turn the other VPP server continuously submits the requested information, i.e. sets of users at or near to the location linked to the border location. The neighborhood server computes a set of users in the vicinity con- tinuously for each user. This can be done by iterated or recursive graph traversal with weighted stop marks. The neighborhood server may use implementation specific, site specific, or user specific parame- ters to do so. Wolf [Page 7] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 The set of neighbors is presented to the user by means of a separate protocol. The neighborhood server may act like an presence notifica- tion (RVP) server to make the set of neighbors available to sub- scribers. It may also submit the data actively to the user's home RVP server. The current implementation includes a presence notification server (which supports the 'user' subject, see section "Properties" below). 1.3.4 Link Graph The link graph of the VNS is to be considered independent of the document database of the document service and its associated link database, if there is any. However it is expected that in many cases the link graph of the VNS is derived from the document database. Location identifiers used by the VNS are to be considered independent of document locations used by the document service, e.g. URLs. But it is expected that locations used by the VNS are derived from document locations or document contents. The mapping between both types of locations depends on the application and the implementation of the VNS. See appendix "Location Mapping". 1.4 Relation to other Protocols The Virtual Presence Protocol uses references of locations and users. Locations are referenced by URIs or URLs. VPP does not depend on HTTP URLs, hence it is designed to be independent of HTTP rather than an extension of HTTP. Users may be represented by RVP URLs mentioned in the Internet Draft "Addressing and Location for RVP" [RVPAddr] or a similar scheme. In this case identifications of users contained in results of VPP servers can be used to start up and conduct communication between users. But VPP does not restrict the identification of users to RVP URLs. Users can also be represented by various other schemes, e.g. abstract numbers, HTTP URLs, Internet Domain Names, or email addresses (see below "Naming and Addressing"). Users and their properties are the subjects of presence notification protocols, whereas locations and their properties are the main sub- jects of the Virtual Presence Protocol. The major reason to create VPP independent from presence notification protocols is the concep- tual independence of both subjects and subject identifiers. However the similarities to the RVP draft may lead to an integration of parts of VPP into a presence notification protocol or into a general event notification protcol. VPP clients notify VPP servers of the beginning and of the end of the Wolf [Page 8] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 presence on documents. It may also in the future notify of movement within documents. This applies to HTML documents as well as to vir- tual reality scenes, but the main focus is currently on the creation of a virtual presence infrastructure based on locations of documents. Multi-user virtual spaces (MUVS) focus on positioning and orientation within 3 dimensional spaces, while VPP focuses on locations of docu- ments and linking between documents. To our knowledge there is no Internet Draft, RFC or other IETF document about a MUVS protocol, but it may well be that a MUVS protocol can be extended to cover parts of the VPP functionality. 2 Protocol Overview 2.1 Purpose The Virtual Presence Protocol is used between client and server to register and un-register users with locations, and between servers to propagate the information about the registration of users with loca- tions. It may also be used to create dynamic displays of the data maintained by neighborhood servers. 2.2 Protocol Neutral This document defines an abstract representation of VPP. A "native" format, or an incorporation into another protocol will be described in a separate document. The encapsulation of VPP within HTTP is currently implemented within our prototype as described in the section "HTTP/1.1 Encapsulation". 2.3 General Format VPP is a request/response protocol. A client sends a request message to the server and the server responds with a response message. A request message consists of o protocol-version, o subject, o property, o method, o attributes, and o additional-data. A response message consists of o protocol-version o response-code, and o additional-data. Wolf [Page 9] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 Additional-data is always accompanied by o data-length (number of octets), and o data-type. The VPP version described here is 2.0. Examples for properties of locations are (see section "Properties"): o users o links o symbol 2.4 Basic Definitions The meaning of response codes follows HTTP status codes as defined in [HTTP/1.1]: vpp-responsecode = Status-Code Other response codes may be added in the future. The problem of status code sharing with HTTP has to be solved (Note: RTSP uses status codes starting at x50, [P3P] at x30. But there are some numbers free. RVP competes here and who knows who else). Timeout specifications can be given in absolute time or relative to the time of the request (the reception of the request, if no time value included in the request). vpp-time = HTTP-date | delta-seconds The service address of a VPP server is used by VPP service lookup responses (see "Finding VPP Servers"). The URL scheme used depends on the host protocol: vpp-serviceurl = genericurl Some VPP requests refer to previous requests. Tokens are used to identify previous requests and to validate references to previous requests. These tokens are stored, compared and returned uninter- preted. They SHOULD be created globally unique in a way which pro- tects them from being re-created by attackers ([Message-id] may be used as a guideline to unique IDs). In many cases tokens are optional. Missing tokens are mapped to empty tokens (e.g. an empty character string): vpp-reference = *(VCHAR) Subscriptions to properties of VPP subjects result in notifications being sent back on certain events: Wolf [Page 10] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 vpp-event = UPDATED | DELETED 2.4.1 Distance Definition Links between locations can be weighted. The definition of the weight is supposed to allow for a broad range of applications. Hence we have left the definition open (see vpp-app-distance below), but with a REQUIRED set, which MUST be understood by VPP instances in the way defined here. Large numbers indicate a large distance. vpp-distance = vpp-basic-distance ; 0 & positive integer values | vpp-float-distance ; float values | vpp-symbolic-distance ; named weights | vpp-app-distance ; application defined vpp-basic-distance = 1*DIGIT vpp-float-distance = 1*DIGIT "." 1*DIGIT ; no exp. part (yet) vpp-symbolic-distance = "none" | "near" | "far" | "unrelated" vpp-app-distance = 1*VCHAR The exact interpretation of symbolic-distance values depends on the implementation. VPP instances SHOULD treat "unrelated" as if there where no link, "far" like a large basic-distance, "near" like a float-distance between "0" and "2.718" exluding "0", and "none" like the basic-distance "0". The values of the symbolic-distance are reserved. App-distance values MUST NOT use these values. If no distance is given, a default distance of "1" is assigned, if not stated otherwise. The default value applies for app-distance values not understood. 2.5 Data Formats Many request messages do not carry additional data. The information of these messages is contained in the fields described above ("Gen- eral Format") except the data field. Additional data is exchanged in XML format. XML is used in order to provide flexibility and extensibility. The data type is "text/xml". The format is: xml-encoded-data = "" Wolf [Page 11] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 "" tag-encoded-data tag-encoded-data = tag-encoded-response-data | tag-encoded-request-data tag-encoded-response-data = service-response-data | enter-response-data | link-response-data | subscribe-response-data | notify-response-data | get-response-data tag-encoded-request-data = notify-request-data For the encoding of tags used only by property data see the respec- tive section chapter "Properties"). The message fields use the following XML tags. They will be defined by proper XML Element Definitions. The namespace may be omitted from this document if no collisions are to be expected, but it is included here for completeness. vpp-timeout-tag = "" vpp-time "" vpp-delay-tag = "" vpp-time "" vpp-distance-tag = "" vpp-distance "" vpp-responsecode-tag = "" vpp-responsecode "" vpp-responsemsg-tag = "" *CHAR "" vpp-serviceurl-tag = "" vpp-serviceurl "" vpp-servicever-tag = "" vpp-serviceversion "" For backward compatibility additional-data can also be encoded in CRLF separated lists of ASCII text. The data type is "text/plain". The exact format will be given in the respective section. plain-data = plain-response-data | plain-request-data plain-response-data = plain-service-response-data | plain-enter-response-data | plain-link-response-data | plain-subscribe-response-data | plain-notify-response-data | plain-get-response-data plain-request-data = plain-notify-request-data The server chooses the data type. But the client may employ an Wolf [Page 12] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 optional request attribute to force the server to return a specific type. Attribute: response = vpp-responsetype ; OPTIONAL vpp-responsetype = media-type ; [HTTP/1.1] 2.6 Access Control VPP does not support access control yet. Generally it is expected that the access control mechanism will be similar to access control mechanisms of document servers. Access control will be supported as soon as an authorization mechanism has been defined. For the time being the access control mechanism of the host protocol can be used. 3 Naming and Addressing 3.1 Locations VPP uses URLs to identify document locations as defined in RFC1738 [URL]. In the case where a fragment/anchor identifier is associated with a URL (following a "#"), the identifier would be appended to the URL and used as the location of the fragment. The interpretation of the scheme, of the scheme specific part of the URL, and of optional fragment/anchor identifiers depends on the implementation of the neighborhood server. vpp-locationname = url [ "#" fragment ] 3.2 Users User names are strings of VCHAR (CHAR except CTL and SP). The naming of users depends on the implementation of VPP clients. Implementors of VPP clients should be aware that names of users or information derived from these names will finally be presented to (human) users, hence names should be meaningful in some way. vpp-username = 1*(VCHAR) We recommend the use of one of the following schemes: HTTP or FTP URLs if additional user detail can be expected at locations derived from the respective URL, e.g. by appending well known file names to a base URL (see appendix "User Names"). Wolf [Page 13] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 User identifications of presence notification protocols such as RVP URLs, as described in [RVPAddr] (other example: ICQ numbers). Arbitrary names if an out-of-band mechanism can be used to map arbitrary names to meaningful information such as nicknames. Internet domain name or Internet address of the user's host, if it is safe to assume, that at any time only one user operates a VPP client on the host. Implementors should be aware that disclosing the network address of a user may pose security problems. The use of RFC 822 email addresses is discouraged although they are unique and meaningful. The email address is regarded as user detail which is only selectively disclosed under control of the user. A VPP client implementation MUST NOT use a naming scheme which con- flicts with the interpretation of names as described in appendix "User Names". It is expected that a dominant naming scheme for users will emerge in the future. Hence we are not enforcing a specific scheme yet. 3.3 Finding VPP Servers VPP clients which are integrated with document clients will need the service address of the VPP server which is responsible for documents fetched by the document client. VPP servers will need the service address of the VPP server which is responsible for documents linked to border locations. In both cases the service address of the VPP server must be derived from the document location (URL). 3.3.1 DNS SRV Records RFC 2052 [DNS SRV] recommends use of DNS SRV records to discover the responsible server for a service. Given the domain name, which can be parsed from the URL, the client prepends "vpp.tcp." to the domain name. Next the client queries the DNS server for the SRV record for "vpp.tcp.cobrow.com". The mechanism for adding "vpp.tcp" onto the original domain name is described in detail in [DNS SRV]. The DNS server returns the IP address for the associated server for "vpp.tcp.cobrow.com". The VPP data is sent to Wolf [Page 14] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 this server. 3.3.2 Service Location Protocol The Service Location Protocol version 2.0 [SLP] is under development but may serve our needs in the future. An SLP URL for a VPP server could look like: service:vpp://cobrow.com 3.3.3 Associated Server Lookup A lookup mechanism based on the document server is provided for a transition phase until one or both methods described above are pro- vided by the respective site. This method integrates easily with existing document servers. It has been designed for simple installa- tion when a neighborhood server is being added to a document server. 3.3.3.1 Request The lookup URL (httpurl or ftpurl) is used to find the VPP server responsible for the location (docurl). Lookup URLs follow the scheme used in the respective document locations. Currently defined are schemes for "http" and "ftp" URLs [URL]: httplookup1 = "http://" hostport "/_service/vpp?op=service" "&location=" docurl httplookup2 = "http://" hostport hbasepath "_vpp" ftplookup = "ftp://" hostport "/_service/vpp" If the "/" character is used to designate a hierarchical structure then hbasepath is the hpath excluding the last segment (hsegment). This aids VPP installations on webhosting services. From [URL]: httpurl = "http://" hostport [ "/" hpath [ "?" search ]] hpath = hsegment *[ "/" hsegment ] hsegment = *[ uchar | ";" | ":" | "@" | "&" | "=" ] search = *[ uchar | ";" | ":" | "@" | "&" | "=" ] VPP clients and VPP servers SHOULD try httplookup1 first and re-try with httplookup2, if the first lookup fails. Example: docurl: http://www.cobrow.com/pages/docs/help.html httplookup1: http://www.cobrow.com/_service/vpp?op=service& location=http://www.cobrow.com/pages/docs/help.html httplookup2: http://www.cobrow.com/pages/docs/_vpp" Wolf [Page 15] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 3.3.3.2 Response The response data returns the result of the lookup. The result con- sists of a response code, the service address of the VPP server, and optional additional information. The data type is "text/xml". Response format: service-response-data = vpp-responsecode-tag [ vpp-responsemsg-tag ] [ vpp-serviceurl-tag ] [ vpp-serviceversion-tag ] Currently defined response codes (meaning as defined in [HTTP/1.1]): vpp-responsecode = "200" | "404" VPP version: vpp-serviceversion = "1.0" | "2.0" The "Content-type" HTTP header of responses to httplookup2 SHOULD be ignored. Example: The _vpp resource for httplookup2 may be provided as a file: 2002.0 http://vpp.cobrow.com:4145/ 4 Messages 4.1 ENTER/LEAVE 4.1.1 ENTER Request A user is registered with a location. The effect of such a registra- tion is that the user is present on the document, hence the method is called ENTER. Message fields: subject = vpp-locationname ; REQUIRED method = ENTER ; REQUIRED Attributes: user = vpp-username ; REQUIRED reg-id = vpp-reference ; OPTIONAL (registration-ID) timeout = vpp-time ; OPTIONAL previous = vpp-locationname ; OPTIONAL The location is the subject of the message. The user is specified as an attribute. It is expected that the ENTER method of a location is Wolf [Page 16] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 executed with a vpp-username as parameter to add a user to a node of the link graph. The registration can be limited to an absolute or relative time. The server MAY change the time. The timeout value MUST be returned if it is changed or if the request does not include a 'timeout' attribute. This allows the server to limit the presence of users. Clients which want to be registered longer MUST re-submit the request later. Requests with the same user, location, and registration-ID supersede previous registrations regardless of the timeout. Multiple registra- tions with different registration-IDs are permitted. They do not supersede each other. The 'previous' attribute is informational. It may be used to indicate which path has been used to enter the location. 4.1.2 LEAVE Request The registration of a user with a location is deleted. The effect of the request is that the user is no longer present on the document, hence the method is called LEAVE. Message fields: subject = vpp-locationname ; REQUIRED method = LEAVE ; REQUIRED Attributes: user = vpp-username ; REQUIRED reg-id = vpp-reference ; OPTIONAL (registration-ID) delay = vpp-time ; OPTIONAL The effect of the request can be delayed until an absolute time is reached or a relative time has passed. The server MAY change the delay. In this case it MUST return the new value. This allows the VPP client to send the LEAVE request when the document client changes the document presented, although the request is executed a bit later ena- beling a smoother display of the user's movement. A delay of a few seconds is recommended. The delay may be implementation specific, site specific, or user specific. The LEAVE request deletes a registration only if subject, user, and registration-ID match. 4.1.3 ENTER/LEAVE Response The response data returns the response code and optional additional information. Wolf [Page 17] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 Message fields: response-code = vpp-responsecode ; REQUIRED additional-data = xml-encoded-data ; REQUIRED The additional-data returns status information. The format for type "text/xml" includes the vpp-responsecode: enter-response-data = vpp-responsecode-tag [ vpp-responsemsg-tag ] [ vpp-timeout-tag ] [ vpp-delay-tag ] Currently defined response codes: vpp-responsecode = "200" ; OK | "400" ; Bad Request | "404" ; Not Found | "500" ; Internal Server Error The response code in response to ENTER requests indicates the state of the subject. "404" means that the location could not be found. The server MUST accept any vpp-username. Note: A combination of user and location which is inacceptable due to access limitation will cause "401" (Unauthorized) as soon as an authorization mechanism has been defined. The response code "404" in response to LEAVE requests indicates the combination of location, user, and registration-ID could not be found. The format for "text/plain" is: plain-enter-response-data = vpp-time [CRLF] 4.2 LINK/UNLINK 4.2.1 Introduction to Linking Most links between documents are only uni-directional. The virtual neighborhood service facilitates bi-directional visibility. This is usually easy to achieve for locations maintained by a single neigh- borhood server. But bi-directional visibility over border links requires communication between neighborhood servers. The VPP server which maintains a border location notifies the VPP server of the linked location. 4.2.2 LINK Request Wolf [Page 18] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 Notification of a link from a border location to another location. The effect of such a notification is that the notified server is able to subscribe for information about users at or close to the border location of the originating server. Message fields: subject = vpp-locationname ; REQUIRED (link destination) method = LINK ; REQUIRED Attributes: location = vpp-locationname ; REQUIRED (link source) link-id = vpp-reference ; OPTIONAL (link-ID) timeout = vpp-time ; OPTIONAL distance = vpp-distance ; OPTIONAL The location of the receiving VPP server is the subject of the mes- sage. The border location of the sender is specified as an attribute. It is expected that the LINK method of a location is executed with a vpp-locationname as parameter to add an edge to a node of the link graph, (and the node) if it does not already exist. The link can be limited to an absolute or relative time. The server MAY change the time. The timeout value MUST be returned if it is changed or if the request does not include a 'timeout' attribute. Requests with identical subject, location and link-ID supersede pre- vious LINK requests regardless of the timeout. Multiple links with different link-IDs are permitted. They do not supersede each other. 4.2.3 UNLINK Request The link from a border location to the location of the receiver is deleted. The receiver SHOULD delete the link from its link graph. Message fields: subject = vpp-locationname ; REQUIRED (link destination) method = UNLINK ; REQUIRED Attributes: location = vpp-locationname ; REQUIRED (link source) link-id = vpp-reference ; OPTIONAL (link-ID) delay = vpp-time ; OPTIONAL The UNLINK request deletes a link only if subject, location, and link-ID match, regardless of the 'distance' attribute of the related LINK request. The effect of the request can be delayed until an absolute time is reached or a relative time has passed. The server MAY change the delay. In this case it MUST return the new value. Wolf [Page 19] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 4.2.4 LINK/UNLINK Response The response data returns the response code and optional additional information. Message fields: response-code = vpp-responsecode ; REQUIRED additional-data = xml-encoded-data ; REQUIRED The additional-data returns status information. The format for type "text/xml" includes the vpp-responsecode: link-response-data = vpp-responsecode-tag [ vpp-responsemsg-tag ] [ vpp-timeout-tag ] [ vpp-delay-tag ] The response code "404" in response to LINK requests indicates that the subject of the message could not be found. The response code "404" in response to UNLINK requests indicates that the combination of subject, location, and link-ID could not be found. The format for "text/plain" is: plain-link-response-data = vpp-time [CRLF] 4.3 SUBSCRIBE/UNSUBSCRIBE 4.3.1 Introduction to Subscriptions Subscriptions request notifications about the state of properties of remote objects. A VPP instance uses subscriptions and in turn notifi- cations to get information about the registration of users with loca- tions maintained by remote VPP servers. The need for such information arises when VPP Server 1 (figure below) computes the set of neighbors of user U1. The border location Lb links to location Lx maintained by another VPP server (Server 2). Location La is virtually close to Lb, hence user U2 is in the vicin- ity of U1. The presence of U1 at Lb causes Server 1 to subscribe for the set of users at or close to Lx. In turn notifications are being sent from Server 2 to Server 1 when the set of users at or close to Lx changes. This information is kept in the 'users' property of Lx. The notification may also include users (U3) registered with Ly. The range of locations included depends on the distance specified by the Wolf [Page 20] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 subscription. The subscriber MUST subscribe with the lowest distance possible. The distance depends on the implementation, personal preferences of users, site defaults, etc. Example: Be U1 registered with La but not with Lb, and be the virtual neigh- borhood (distance) to be observed "2". Server 1 subscribes for Lx.users with distance "0", because the distance between Lx and La is "2", hence only users registered with Lx are visible to U1. A notification returns U2. If U1 moves to Lb, Server 1 subscribes again for Lx.users, but with distance "1" to additionally cover users registered with locations linked closely to Lx: here Ly. A notification returns U2 and U3. VPP Server 1 || VPP Server 2 +----+ +----+ || +----+ +----+ | La | --1--> | Lb | --1---++-----> | Lx | --1--> | Ly | | | | U1 | || | U2 | | U3 | +----+ +----+ || +----+ +----+ U[1|2|3]: Users L[a|b|x|y]: Locations Numbers in links indicate the VPP distance 4.3.2 SUBSCRIBE Request Subscribe for a property. Message fields: subject = vpp-locationname ; REQUIRED property = vpp-property ; REQUIRED method = SUBSCRIBE ; REQUIRED Attributes: sub-id = vpp-reference ; OPTIONAL (subscription-ID) reply-to = vpp-serviceurl ; REQUIRED timeout = vpp-time ; OPTIONAL delay = vpp-time ; OPTIONAL distance = vpp-distance ; OPTIONAL The subscription can be limited to an absolute or relative time. The server MAY change the time. The timeout value MUST be returned if it is changed or if the request does not include a 'timeout' attribute. The 'delay' attribute specifies the minimum delay between Wolf [Page 21] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 notifications. The distance indicates the range of locations to be included in notifications. Subscriptions with higher distance supersede subscrip- tions with lower distance if the subject, property, and subscription-ID match. The receiver may limit the distance. In this case it must return the new distance. The default distance for sub- scriptions is "0". Notifications are to be sent to the VPP server specified by the 'reply-to' attribute. Multiple subscriptions for a property with different subscription-IDs are permitted. The receiver of a subscription request MUST send a notification of type 'UPDATED' if the content of the property changes. It MUST send a 'DELETED' event if the property has been deleted. An immediate notification request with the current content of the property MUST be sent to the subscriber in response to a subscrip- tion, if the property is not empty. The response message to the sub- scription returns information about the subscription. It does not carry the content of the property. Note: No effort has been made to integrate the response to the subscription and the first notification into a single message. Reasons are: o It is expected that most subscriptions will result in multiple notifications. An initial notification of an empty property is not required. o Integration of the subscription response and of the first notif- ication into a single message does not reduce the amount of VPP protocol data transmitted. It also does not reduce overall net- work traffic if the same transport system connection is used. Using the same transport system connection means that the roles of client and server change. The receiver of a subscription request SHOULD preserve the informa- tion if the service is discontinued and resumed (e.g. between "runs"). 4.3.3 UNSUBSCRIBE Request Delete subscription for property. Wolf [Page 22] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 Message fields: subject = vpp-locationname ; REQUIRED property = vpp-property ; REQUIRED method = UNSUBSCRIBE ; REQUIRED Attributes: sub-id = vpp-reference ; OPTIONAL (subscription-ID) The UNSUBSCRIBE request deletes a subscription only if subject, pro- perty, and subscription-ID match. 4.3.4 SUBSCRIBE/UNSUBSCRIBE Response The response data returns the response code and optional additional information. Message fields: response-code = vpp-responsecode ; REQUIRED additional-data = xml-encoded-data ; REQUIRED The format for "text/xml" is: subscribe-response-data = vpp-responsecode-tag [ vpp-responsemsg-tag ] [ vpp-timeout-tag ] [ vpp-distance-tag ] The response code "404" in response to SUBSCRIBE requests indicates that the subject or its property could not be found. The response code "404" in response to UNSUBSCRIBE requests indicates that the combination of subject, property, and subscription-ID could not be found. The format for "text/plain" is: plain-subscribe-response-data = vpp-time [CRLF] 4.4 NOTIFY 4.4.1 Request Notifications are repeatedly sent in response to subscriptions. They carry the information in the additional-data part. Message fields: subject = vpp-locationname ; REQUIRED property = vpp-property ; REQUIRED method = NOTIFY ; REQUIRED Attributes: sub-id = vpp-reference ; OPTIONAL (subscription-ID) Wolf [Page 23] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 event = vpp-event ; OPTIONAL (event type) additional-data = xml-encoded-data ; REQUIRED The notification is only accepted if subject, property, and subscription-ID match any of the subscriptions previously sent. Oth- erwise a "404" response code is returned. The event type is indicated by the 'event' attribute. The default event type is 'UPDATED'. The format of the additional-data depends on the property (see "Pro- perties"). The format for "text/xml" is: notify-request-data = property-data The format for "text/plain" is: plain-notify-request-data = plain-property-data ; see "Properties" 4.4.2 Response Message fields: response-code = vpp-responsecode ; REQUIRED additional-data = xml-encoded-data ; REQUIRED The format of the additional-data of type "text/xml" is: notify-response-data = vpp-responsecode-tag [ vpp-responsemsg-tag ] The additional-data of type "text/plain" is empty. 4.5 GET 4.5.1 Request The GET method is used to retrieve the contents of a property. Message fields: subject = vpp-locationname ; REQUIRED property = vpp-property ; REQUIRED method = GET ; REQUIRED The response code "404" in response to GET requests indicates that the subject or its property could not be found. 4.5.2 Response Message fields: response-code = vpp-responsecode ; REQUIRED additional-data = xml-encoded-data ; REQUIRED Wolf [Page 24] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 The format of the additional-data of type "text/xml" is: get-response-data = vpp-responsecode-tag [ vpp-responsemsg-tag ] property-data The additional-data of type "text/plain" is: plain-get-response-data = property-data 5 Properties 5.1 Location Subject Property data formats for the location's properties defined below: property-data = summary-property-data | users-property-data | links-property-data | symbol-property-data plain-property-data = plain-summary-property-data | plain-users-property-data | plain-links-property-data | plain-symbol-property-data 5.1.1 Users Property The 'users' property contains a set of users which are within a cer- tain distance of the respective location. The 'users' property is REQUIRED. The format for "text/xml" is: users-property-data = *(vpp-neighbor-tag) vpp-neighbor-tag = "" "" vpp-username "" [ vpp-distance-tag ] "" The format for "text/plain" is: plain-users-property-data = *(vpp-username WSP vpp-distance CRLF) 5.1.2 Links Property The 'links' property contains the edges of a node of the link graph used by the neighborhood server. Edges are described by destination (vpp-locationname), length (vpp-distance), and optional relative coordinates, which can be used to position nodes in graphical Wolf [Page 25] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 neighborhood displays. Support of the 'links' property is RECOM- MENDED. The format for "text/xml" is: links-property-data = *(vpp-link-tag) vpp-link-tag = "" "" vpp-locationname "" [ vpp-distance-tag ] [ "" vpp-coordinate "" "" vpp-coordinate "" "" vpp-coordinate "" ] [ "" [ vpp-href-tag ] "" ] "" vpp-href-tag = vpp-coordinate = [-] 1*DIGIT The vpp-href-tag contains the original HTML-tag. An empty vpp-href- tag indicates that the link exists only in the link graph of the VNS, but not in the original hypertext. This usually means that the link has been introduced artificially into the link graph of the VPP server to facilitate bidirectional visibility. Coordinate scaling has not been defined yet. But all coordinates of a VPP server MUST be based on the same scale. The format for "text/plain" is: plain-links-property-data = *( vpp-locationname WSP vpp-distance [ WSP vpp-coordinate vpp-coordinate vpp-coordinate ] CRLF ) 5.1.3 Symbol Property The 'symbol' property is used in text based and graphical displays to represent locations. symbol-property-data = [ vpp-title-tag ] [ vpp-icon-tag ] [ vpp-prototype-tag ] vpp-title-tag = "" *CHAR "" ; the title of the document represented by the location vpp-icon-tag = "" url "" ; a URL of a small graphical representation of the location vpp-prototype-tag = "" url "" ; a URL representing the class of URLs mapped to the location Wolf [Page 26] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 The format for "text/plain" is: plain-symbol-property-data = *CHAR CRLF httpurl 5.1.4 Summary Property The 'summary' property provides a summary of the properties of the location and an indication of changes. Its purpose is to enable sub- scribers to reduce traffic and system load imposed by high volume notifications. Support of the 'summary' property is RECOMMENDED. The 'summary' property SHOULD cover the properties, which may have large contents (e.g. 'users' and 'links'). It MAY cover other properties. The format for "text/xml" is: summary-property-data = [ vpp-userssummary-tag ] [ vpp-linkssummary-tag ] [ vpp-symbolsummary-tag ] vpp-userssummary-tag = "" vpp-count-tag ; indicating the number of users [ vpp-signature-tag ] "" vpp-linkssummary-tag = "" vpp-count-tag ; indicating the number of links [ vpp-signature-tag ] "" vpp-symbolsummary-tag = "" url [ vpp-signature-tag ] "" vpp-count-tag = "" 1*DIGIT "" vpp-signature-tag = "" 1*VCHAR "" 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 format for "text/plain" is: plain-summary-property-data = 1*DIGIT ; the number of users 5.2 User Subject Wolf [Page 27] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 VPP focuses on locations. Hence, the user subject and user properties are not included into the VPP specification. But VPP servers use and create properties of users internally. The most important user pro- perties are the set of locations at which a user is registered and the set of neighbors. They are the results of the VNS and they are fed into a presence notification service in order to be presented to users. We hope that it will not be necessary to add the 'user' subject to this specification. Progress in the definition of presence notifica- tion protocols will make this part of the current implementation obsolete. This section decribes the data maintained within a VPP server as if it where available directly from the VPP server so that implementors of presence notification service components know what can be expected from a virtual presence server. 5.2.1 Locations Property The format for "text/xml" is: user-locations-property-data = *(vpp-presence-tag) vpp-presence-tag = "" "" vpp-locationname "" [ "" vpp-locationname "" ] [ vpp-strength-tag ] "" vpp-strength-tag = "" ( "1.0" | "0." 1*DIGIT ) "" The default strength is "1.0". The format for "text/plain" is: plain-user-locations-property-data = *(vpp-locationname CRLF) 5.2.2 Neighbors Property The format for "text/xml" is: user-neighbors-property-data = *(vpp-neighbor-tag) The format for "text/plain" is: plain-user-neighbors-property-data = *(vpp-username CRLF) 6 HTTP/1.1 Encapsulation Wolf [Page 28] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 6.1 Encapsulation Properties HTTP has been chosen as host protocol for several reasons: o HTTP passes firewalls because HTTP firewall gates and HTTP prox- ies are very common. o HTTP requests can easily be generated by WWW clients and in turn response data is displayed by the client. This is important for the development phase. o VPP servers might be integrated with HTTP servers, hence use of the same protocol engine is advantageous. Most VPP requests use the HTTP/1.1 GET method. VPP request message data is encoded into the HTTP request line. Only VPP requests which carry additional data (NOTIFY) use the HTTP POST method. VPP responses carry VPP message data in the message body of HTTP responses. Type and size of VPP data uses HTTP header fields to be compatible with HTTP clients. There are other ways to embed VPP into HTTP/1.1, e.g. o use of the HTTP message body only, without parameter encoding into the request line or o extensive use of HTTP header fields. The encoding described here has been chosen for ease of debugging with HTTP clients. 6.2 Encapsulation Rules 6.2.1 Basic Rules The following fields are defined here because they might look dif- ferent when encapsulated into another protocol, especially if the host protocol is not ASCII based: vpph-method = "enter" | "leave" | "link" | "unlink" | "subscribe" | "unsubscribe" | "notify" Wolf [Page 29] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 | "get" | "service" | other-vpph-method vpph-subject = vpp-locationname | other-vpph-subject vpph-property = vpph-location-property | other-vpph-property vpph-location-property = "users" | "links" | "symbol" | "summary" | other-vpph-property vpph-attribute = "user" | "location" | "previous" | "reg-id" | "link-id" | "sub-id" | "timeout" | "delay" | "distance" | "reply-to" | other-vpph-attribute vpph-event = "updated" | "deleted" | other-vpph-event vpph-attribvalue = 1*CHAR vpph-data-type = media-type ; Internet Media Types registered with the ; Internet Assigned Number Authority (IANA) [RFC 2048]. vpph-data-length = 1*DIGIT ; decimal number of octets other-vpph-method = token ; to be defined on demand other-vpph-subject = token other-vpph-property = token other-vpph-attribute = token other-vpph-event = token VPP additional-data uses the HTTP body part. VPP data-legth and VPP data-type MUST use the HTTP header fields "Content-length" and Wolf [Page 30] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 "Content-type". The HTTP version used is "HTTP/1.1" See appendix "HTTP Encapsulation Examples" 6.2.2 Request VPP requests are embedded into HTTP requests by the following URL: http_URL = vpp-serviceurl "?" vpp-urlencoded vpp-urlencoded = [ "op=" vpph-method ] [ "&" "ver=" vpp-serviceversion ] [ "&" "subject=" vpph-subject ] [ "&" "property=" vpph-property ] [ *( "&" vpph-attribute "=" vpph-attribvalue) ] The query part (vpp-urlencoded) MUST be encoded according to chapter 2.2. of [URL]. This means that unsafe characters MUST be replaced by their 2 digit hexcode preceeded by "%". Most VPP requests use the HTTP "GET" method. VPP requests which carry data in the HTTP body part use the "POST" method. The "op=" query parameter may be omitted for VPP GET requests. 6.2.3 Response The VPP response code for additional-data of type "text/plain" MUST be encoded into the HTTP status code. The HTTP status code of VPP responses with additional-data of type "text/xml" MUST be "200". Responses, except responses to VPP GET requests, MUST be marked as not cachable. The following HTTP headers may be used: Cache-control: no-cache Expires: Thu, 01 Jan 1970 01:01:01 GMT 6.3 Forced LEAVE On program failure or system failure VPP clients often do not send LEAVE requests. The user remains The registered with a location until the timeout of the ENTER request expires. VPP clients which expect such failures and want to improve the behaviour of the VNS in these cases MAY use an additional attribute, to force a LEAVE operation. Attribute: Wolf [Page 31] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 onclose = vpph-onclose-action ; OPTIONAL vpph-onclose-action = "leave" | "stay" ; "stay" is default other-vpph-attribute = "onclose" The "onclose=leave" attribute/value pair of an ENTER request makes the registration of a user dependent of the state of the TCP connec- tion which carries the ENTER request. If the TCP connection closes, then the server MUST generate a LEAVE request on behalf of the client for the combination of location, user, and registration-ID of the ENTER request. Multiple ENTER requests may be attached to the same TCP connection. VPP clients MUST NOT rely upon the 'onclose' attribute as a substi- tute for LEAVE requests. Client action: Add 'onclose' attribute with value "leave" to ENTER requests. Server action: Store parameters of the ENTER request, monitor the TCP connection, and generate a LEAVE request if the connection closes: subject = vpp-locationname ; from ENTER request method = LEAVE Attributes: user = vpp-username ; from ENTER request reg-id = vpp-reference ; from ENTER request delay = "0" 7 Traffic Considerations 7.1 Overview The VNS generates significant traffic. The number of VPP messages is in the order of HTTP requests, but with much lower volume. Traffic generated by careless implementations can be in the order of the number of available documents, but effort has been made to limit the volume to a small fraction of the HTTP traffic. Implementors must consider the recommendations below. In general, VPP traffic may use optimizations provided by the host protocol, i.e. multiple requests on a single transport system connec- tion and pipelining [HTTP/1.1]. 7.2 ENTER/LEAVE Wolf [Page 32] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 The authors recognize that the number of ENTER and LEAVE requests is in the order of Web pages visited. However, we suppose that the traffic generated by this part of VPP will be only a small fraction of the overall document related traffic: o Requests are of the size of HTTP requests or smaller. Responses do not carry significant content. o There are only 2 VPP requests compared to (often) multiple HTTP requests per document (see [Microscape]). o Web sites which do not offer neighborhood services get at most 2 Associated Server Lookup requests. VPP clients must not send ENTER/LEAVE requests, if the VPP server lookup failed. o If VPP servers are integrated with document servers, then VPP traffic may use the same (persistent) transport system connec- tion. 7.3 LINK/UNLINK The purpose of LINK requests is to prepare for subscriptions in the reverse direction. A LINK request should only be issued if a sub- scription for information about users on the border location is prac- tical, i.e. if there are users at or close to location linked to the border location. LINK requests generate only a small fraction of the ENTER/LEAVE traffic o Requests are usually only issued if users are registered with a border location or close to the border location. o LINK requests are rare. The actual number depends on the fre- quency of hyperlink changes. VPP servers should allow for LINK- timeout values in the order of days. o UNLINK requests are very rare. LINKs usually expire rather than being UNLINKed. o Implementations should limit border links to a reasonable number. o VNS on index sites (search engines, etc.) should select VPP- links as they are already selecting so-called "related-pages" by search terms. It is expected that this method reduces the number of border links, hence the number of LINK requests. Wolf [Page 33] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 7.4 SUBSCRIBE/UNSUBSCRIBE/NOTIFY Subscriptions are usually only issued in response to LINK requests, thus they generate a similar amount of traffic. Notifications depend on the number of visits (order of HTTP requests), but only if users ENTER/LEAVE border locations. Hence the traffic is usually smaller than the traffic of ENTER/LEAVE requests on border locations and smaller than the HTTP traffic of the border pages only, and much smaller than the overall HTTP traffic. o A subscription should only be sent, if the information is required, i.e. if users are at or close to the border location. o Notifications communicate information about many users on a group of locations. They should not be sent for any single change. Changes (ENTER/LEAVE requests) should be accumulated for a reasonable time (seconds). o Implementations should monitor the traffic and increase update intervals if the total traffic increases. o Notifications should only be sent in response to ENTER/LEAVE requests or other notifications. o Subscribers which suffer under high load imposed by large notif- ications should switch to the respective summary property and either use the summary provided, or watch the signatures and request property data on demand. 7.5 Service Lookup VPP clients need the VPP service URL for each document visited by the document client. They should try to minimize the number of lookup requests: o Clients should keep a cache of VPP service URL lookups. o VPP clients should try to estimate the service URL for a given document URL based on previous lookups. This is similar to the scheme used by HTTP clients to estimate the HTTP authentication scheme and parameters based on similarities between URLs. We suppose that the number of service lookups is in the order of web site visits. 8 Security Considerations 8.1 User Privacy Wolf [Page 34] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 The VNS facilitates tracking of users. It goes beyond the information voluntarily provided by clients of presence notification protocols. VPP clients (not servers) are the source for virtual presence infor- mation. If they are integrated with HTTP clients then there should be a way to control (and disable) the operation. The recommended prac- tice is to explicitely notify the user at least once about the ser- vice and the privacy issues. The negotiation should be carried out automatically using [P3P] (data category "Navigation and Click-stream Data") once P3P is supported by document clients. User detail is not disclosed by the VNS. This is the task of a pres- ence notification service which maintains user detail (hopefully) under control of the user. Generally we regard the virtual space as being very similar to the real world where people are used to being seen by or being aware of others. The VNS re-creates this for the document space. But still the visibility can be swichted off as opposed to the real world. 8.2 Access Control Some VPP requests use tokens to refer to previous requests (initial requests). Correct references are required to validate requests which refer to previous ones. The tokens should be created in a way which protects them from being re-created by attackers. Notfications are validated the same way. The subscription-ID serves as a ticket which allows the subscribed party to send notifications. The protection (encryption) of token transmission is currently left to the host protocol. Protection of initial requests (e.g. ENTER, LINK) is a critical issue. Access authorization will be used similar to HTTP or other document services. But many Web sites do not have access restrictions at all. VPP initial requests for unprotected locations are as open to anyone as is the read access (e.g. HTTP-GET) to unprotected docu- ments. Implementations should consider posing limitations on initial requests. This means that the VPP server must maintain a reasonable amount of state. It may: o limit the number of ENTER requests per user for a period of time, o limit the number of registrations per user, Wolf [Page 35] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 o limit the number of LINK requests per originating VPP instance. The originating VPP instance can be derived from the 'location' attribute of LINK requests, o limit the number of subscriptions per "reply-to" address, o monitor overall load to detect denial of service attacks. Denial of service attacks are usually more critical to VPP servers than they are to document servers, because attackers can pose a higher system load with less or equal amount of bandwidth used for the attack. 8.3 Security of Documents Documents are represented by nodes of the link graph. The security of documents is generally not affected. There is no write access at all to documents. But the current specification allows for unlimited read access to parts of the information contained in documents, even if the documents are protected by the document server. Document based access limitations (e.g. HTTP authorization) will be preserved by VPP to solve these issues once a authorization scheme has been selected for VPP. For the time being: o anyone can retrieve the set of hypertext references of a docu- ment, if the VPP server supports the 'links' property, o anyone may be able to retrieve symbolic information of a docu- ment, e.g. the title or an icon, if the VPP server supports the 'symbol' property, o anyone may get information about the existence of a document through VPP even if HTTP access to higher levels of the hierar- chy is restricted and thus the document is invisible through the document server. 9 Appendices 9.1 Location Mapping 9.1.1 Traditional File Based Many Web sites are based on files in a hierarchical file system. URLs are mapped to file system access paths. In many cases a document can be referenced by multiple different URLs. Examples are "default files" of directories and heuristics of HTTP servers, e.g. appending ".html" to URIs. However, users expect to be virtually present on the same document even if it can be accessed by multiple URLs. We there- fore suggest to use the final file access path as node name in the Wolf [Page 36] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 neighborhood server's link graph. This means that the neighborhood server must be able to reproduce the mapping from relative URLs to file access paths by the HTTP server. A full or partial integration of the neighborhood server or its loca- tion mapping component into the respective document server software is advantageous. 9.1.2 Document Databases A growing percentage of Web sites does not rely on static files, but on document databases. Documents are often dynamically compiled of multiple fragments (database records). Again, the neighborhood server must be able to reproduce the mapping of the document server. This means that it might be necessary to provide a location mapper CGI program in addition to the CGI program which creates the documents. The expectation of the user is the primary guideline for the mapping process. We can give only hints here: o if a document consists of a core fragment and framework (e.g. an online newspaper article), then the node name may be the iden- tification of the core fragment (the record number, query param- eters, etc). o if a single document can be presented in different variants, then we suggest mapping all variants to a single node name. o if a document consists of multiple fragments, but does not build around a single core element, then implementors might consider the following strategy: each fragment is represented by a node in the link graph. Users are registered with all nodes (loca- tions). The virtual distance between these nodes does not have to be "0". This applies also to "frame pages". 9.1.3 Database Queries Database queries (e.g. search engines) often return documents which consist of a large number of fragments. Fragments can be mixed to form similar documents or totally different documents. Registration of users with a large number of locations (one for each fragment) is not feasible. A different approach must be taken. Search engines may create a link graph of search terms rather than a graph of documents. The pre-processing and association of terms required is already done by many search engines for other purposes. If documents are not compiled of multiple fragments but a database Wolf [Page 37] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 returns identical documents for different queries, then the node name may be derived from the query result, e.g. by using a CRC of arbi- trary length on the document contents. 9.2 User Names User names contained in neighborhood lists are interpreted when they are displayed to users of the VNS. This section defines the interpre- tation for specific naming schemes. 9.2.1 HTTP URL An HTTP URL is used as the base URL for additional user detail. The additional user detail SHOULD be available from URLs created by a concatenation of the base URL and some well known file names. If the last character is not a "/" character, then a "/" is automatically appended to the base URL (baseurl). user_detail_URL = baseurl filename File names and formats are not part of VPP. They are included here as an example. A detailed description of formats used by the current implementation will be provided in a separate document. The current implementation defines the following file names: "properties" - a CRLF separated list of name/value pairs, like: realname= Nick linkdist= 2 visibility= on "icon.gif" - a GIF image. Its dimensions should be 32x32 pixel. "image.jpg" - a JPEG image of any size. 9.2.2 Internet Domain Name or Address An HTTP URL (url) is created from an internet domain name or internet address (host): url = "http://" host "/" The URL is then used as described above. 9.3 HTTP Encapsulation Examples XML namespace specifications, 'Content-length' and other HTTP headers have been omitted from most examples. Request URLs are not "%" encoded. A "|" denotes a message line. Lines are separated by CRLF. A "+" denotes a continued line. Wolf [Page 38] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 9.3.1 Service Lookup A user opens the URL http://www.cobrow.com/. The VPP client deter- mines the service URL of the associated VPP server. Request to www.cobrow.com at 80: | GET /_service/vpp?op=service + &location=http://www.cobrow.com/ HTTP/1.1 | | Response: | HTTP/1.1 200 OK | Content-type: text/xml | Content-length: 153 | | | | 200 2.0 | http://www.cobrow.com:4145/vpp 9.3.2 Enter Request to www.cobrow.com at 4145: | GET /vpp?ver=2.0&subject=http://www.cobrow.com/ + &method=enter&user=rvp://rvp.widgets.com/bill + ®-id=some-secret-number-1231424255 + &timeout=86400 HTTP/1.1 | Response: | HTTP/1.1 200 OK | Content-type: text/xml | | 200 2.0 | 300 9.3.3 Leave Request to www.cobrow.com at 4145: | GET /vpp?ver=2.0&subject=http://www.cobrow.com/ + &method=leave&user=rvp://rvp.widgets.com/bill + ®-id=some-secret-number-1231424255 HTTP/1.1 | 9.3.4 Link The VPP server of http://www.cobrow.com/ announces a link to Wolf [Page 39] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 http://www.netscape.com/. Assumed the VPP service URL of http://www.netscape.com/ is http://vpp.netscape.com:81/ Request to vpp.netscape.com at 81: | GET /vpp?ver=2.0&subject=http://www.netscape.com/ + &method=link&location=http://www.cobrow.com/ + &link-id=some-secret-number-34564745 + &timeout=200000 HTTP/1.1 | Response: | HTTP/1.1 200 OK | Content-type: text/xml | | 200 2.0 9.3.5 Subscribe Request to www.cobrow.com at 4145: | GET /vpp?ver=2.0&subject=http://www.cobrow.com/ + &method=subscribe&property=users&distance=2 + &sub-id=some-secret-number-32874387267 + &reply-to=http://vpp.netscape.com:81/ HTTP/1.1 | Response: | HTTP/1.1 200 OK | Content-type: text/xml | | 200 2.0 | 06 Nov 1998 08:49:37 GMT | 1 9.3.6 Notify A notification in response to the subscription from http://vpp.netscape.com:81/ and on the registration of rvp://rvp.widgets.com/bill with http://www.cobrow.com/. Request to vpp.netscape.com at 81: | POST /vpp?ver=2.0&subject=http://www.cobrow.com/ + &method=notify&property=users&event=updated + &sub-id=some-secret-number-32874387267 HTTP/1.1 | Content-type: text/xml | | | rvp://rvp.widgets.com/bill | 0 Wolf [Page 40] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 | | | 134.60.77.255 | Response omitted. 10 References [RVP] M. Calsyn, L. Dusseault, G. Mohr, "RVP: A Presence Notification Protocol", draft-calsyn-rvp-01.txt, INTERNET-DRAFT, work in progress, expires: Sept 1998. [RVPAddr] L. Dusseault, G. Mohr, "Addressing and Location for RVP" , draft-dusseault-rvp-addr-00.txt, INTERNET-DRAFT, work in progress, expires: Sept 1998 [Bradner97] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. [HTTP/1.1] Fielding R., Gettys J., Mogul J., Frystyk H. and Berners- Lee T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [URL] Berners-Lee T., Masinter L., McCahill M., "Uniform Resource Locators (URL)", RFC 1738, Dec 1994. [ABNF] D. Crocker, Ed., P. Overell., "2234 Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [DNS SRV] Gulbrandsen A. and Vixie P., "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996. [SLP] E. Guttman, C. Perkins, S. Kaplan, "Service Location Protocol", RFC 2165, June 1997. [Microscape] H.F. Nielsen, Jim Gettys, A. Baird-Smith, E. Prud'hommeaux, H. Lie, "Network Performance Effects of HTTP/1.1, CSS1 and PNG", ACM SIGCOMM 97. [RFC 2048] Postel, J., "Media Type Registration Procedure", RFC 2048, USC/ISI, November 1996. [MD5] R. Rivest. "RFC 1321 -- The MD5 Message-Digest Algorithm," MIT. April 1992. [P3P] M. Marchiori, D.Jaye, "Platform for Privacy Preferences (P3P) Wolf [Page 41] INTERNET-DRAFT Virtual Presence Protocol August 1, 1998 Syntax Specification", WD-P3P-syntax, W3C Working Draft. [Message-id] M. Curtin, J. Zawinski, "Recommendations for generating Message IDs", INTERNET DRAFT, work in progress, , July 1998 11 Acknowledgements We used parts of the Internet Drafts draft-calsyn-rvp-01.txt and draft-dusseault-rvp-addr-00.txt by M. Calsyn, L. Dussault, and G. Mohr, and adapted them to our needs. Many people were or are involved in our work on virtual neighborhood services. They have implemented components, tested the system, shared ideas, and given valuable feedback. Alphabetically: Holger Boenisch (UUlm), Ehsan Chirazi (UBruxelles), Marcel Dasen (ETHZ), Heiner Erne (Hirschmann), Stefan Fiedler (UUlm), Konrad Froizheim (UUlm), Philipp Hiller, David Hutchinson (ULancas- ter), Michael Merz (TUT Systems), Stefan Schmidt (ULancaster), Andrew Scott (ULancaster), Michael Weber (UUlm). 12 Author's Address Klaus H. Wolf Distributed Systems Dept. University of Ulm 89069 Ulm Germany Phone: +49 (731) 502 4145 EMail: wolf@informatik.uni-ulm.de Draft expires: February 1, 1999 Wolf [Page 42]