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
+ ®-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
+ ®-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]