[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
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 =
         "<?xml version=1.0 ?>"



Wolf                                                           [Page 11]


INTERNET-DRAFT         Virtual Presence Protocol          August 1, 1998


         "<?xml:namespace ns='vpp' prefix='v' ?>"
         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      = "<v:timeout>" vpp-time "</v:timeout>"
     vpp-delay-tag        = "<v:delay>" vpp-time "</v:delay>"
     vpp-distance-tag     = "<v:distance>" vpp-distance "</v:distance>"
     vpp-responsecode-tag = "<v:code>" vpp-responsecode "</v:code>"
     vpp-responsemsg-tag  = "<v:msg>" *CHAR "</v:msg>"
     vpp-serviceurl-tag   = "<v:svc>" vpp-serviceurl "</v:svc>"
     vpp-servicever-tag   = "<v:ver>" vpp-serviceversion "</v:ver>"

   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:
     <?xml version=1.0 ?><?xml:namespace ns='vpp' prefix='v' ?>
     <v:code>200</v:code><v:ver>2.0</v:ver>
     <v:svc>http://vpp.cobrow.com:4145/</v:svc>

 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 = "<v:neighbor>"
                          "<v:name>" vpp-username "</v:name>"
                          [ vpp-distance-tag ]
                        "</v:neighbor>"

   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 = "<v:link>"
                      "<v:name>" vpp-locationname "</v:name>"
                      [ vpp-distance-tag ]
                      [ "<v:dx>" vpp-coordinate "</v:dx>"
                        "<v:dy>" vpp-coordinate "</v:dy>"
                        "<v:dz>" vpp-coordinate "</v:dz>" ]
                      [ "<v:href>" [ vpp-href-tag ] "</v:href>" ]
                    "</v:link>"

     vpp-href-tag = <html anchor tag as defined in HTML 2.0 (RFC 1866)>

     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 = "<v:title>" *CHAR "</v:title>"
        ; the title of the document represented by the location
     vpp-icon-tag = "<v:icon>" url "</v:icon>"
        ; a URL of a small graphical representation of the location
     vpp-prototype-tag = "<v:proto>" url "</v:proto>"
        ; 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 =
         "<v:users>"
           vpp-count-tag      ; indicating the number of users
           [ vpp-signature-tag ]
         "</v:users>"

     vpp-linkssummary-tag =
         "<v:links>"
           vpp-count-tag      ; indicating the number of links
           [ vpp-signature-tag ]
         "</v:links>"

     vpp-symbolsummary-tag =
         "<v:symbol>"
           url [ vpp-signature-tag ]
         "</v:symbol>"

     vpp-count-tag     = "<v:cnt>" 1*DIGIT "</v:cnt>"
     vpp-signature-tag = "<v:sig>" 1*VCHAR "</v:sig>"

   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 = "<v:presence>"
                        "<v:name>" vpp-locationname "</v:name>"
                        [ "<v:prev>" vpp-locationname "</v:prev>" ]
                        [ vpp-strength-tag ]
                        "</v:presence>"

     vpp-strength-tag = "<v:strength>"
                        ( "1.0" | "0." 1*DIGIT )
                        "</v:strength>"

   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
   | <other HTTP headers>
   |

   Response:
   | HTTP/1.1 200 OK
   | Content-type: text/xml
   | Content-length: 153
   | <other HTTP headers>
   |
   | <?xml version=1.0 ?><?xml:namespace ns='vpp' prefix='v' ?>
   | <v:code> 200 </v:code><v:ver> 2.0 </v:ver>
   | <v:svc> http://www.cobrow.com:4145/vpp </v:svc>

   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
   +    &reg-id=some-secret-number-1231424255
   +    &timeout=86400 HTTP/1.1
   |

   Response:
   | HTTP/1.1 200 OK
   | Content-type: text/xml
   |
   | <v:code> 200 </v:code><v:ver> 2.0 </v:ver>
   | <v:timeout> 300 </v:timeout>

   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
   +    &reg-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
   |
   | <v:code> 200 </v:code><v:ver> 2.0 </v:ver>

   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
   |
   | <v:code> 200 </v:code><v:ver> 2.0 </v:ver>
   | <v:timeout> 06 Nov 1998 08:49:37 GMT </v:timeout>
   | <v:distance> 1 </v:distance>

   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
   |
   | <v:neighbor>
   |   <v:name> rvp://rvp.widgets.com/bill </v:name>
   |   <v:distance> 0 </v:distance>



Wolf                                                           [Page 40]


INTERNET-DRAFT         Virtual Presence Protocol          August 1, 1998


   | </v:neighbor>
   | <v:neighbor>
   |   <v:name> 134.60.77.255 </v:name>
   | </v:neighbor>

   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, <draft-ietf-usefor-
   message-id-01.txt>, 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]