[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]
Versions: 00 01 draft-ietf-vwrap-intro
Virtual World Region Agent M. Hamrick
Protocol
Internet-Draft D. Levine
Intended status: Informational IBM Thomas J. Watson Research
Expires: November 19, 2010 Center
May 18, 2010
VWRAP: Introduction and Goals
draft-hamrick-vwrap-intro-01
Abstract
The Virtual World Region Agent Protocol (VWRAP) defines interactions
between hosts collaborating to create an shared, internet scale
virtual world experience. This document introduces the protocol, the
objectives and requirements it imposes on hosts implementing the
protocol. To the extent it affects protocol interactions, this
document describes the model assumed by the protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 19, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Hamrick & Levine Expires November 19, 2010 [Page 1]
Internet-Draft VWRAP: Introduction and Goals May 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Introducing the Virtual World Region Agent Protocol . . . . . 3
2.1. A Brief Introduction to Virtual Worlds . . . . . . . . . . 3
2.2. Architectural Objectives . . . . . . . . . . . . . . . . . 5
2.3. Protocol Objectives . . . . . . . . . . . . . . . . . . . 8
3. Virtual World Region Agent Protocol Architecture . . . . . . . 10
3.1. Deployment Patterns . . . . . . . . . . . . . . . . . . . 10
3.2. Protocol Elements . . . . . . . . . . . . . . . . . . . . 11
3.2.1. Communicating Application State Using REST-Like
Resource Accesses . . . . . . . . . . . . . . . . . . 11
3.2.2. Bi-Directional Messaging with the VWRAP Event Queue . 13
3.2.3. Using Capabilities to Simplify Inter-Domain Access
Control . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4. Using LLSD to Avoid Version Skew . . . . . . . . . . . 14
4. Virtual World Region Agent Protocol Services . . . . . . . . . 15
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Text and Voice Chat . . . . . . . . . . . . . . . . . . . 18
4.3. Agent Presence . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1. Moving Presence . . . . . . . . . . . . . . . . . . . 20
4.4. Digital Asset Access . . . . . . . . . . . . . . . . . . . 21
4.4.1. Manipulating Digital Assets . . . . . . . . . . . . . 21
4.4.2. Establishing Presence for Digital Assets . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
5.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 24
5.2. User Authentication . . . . . . . . . . . . . . . . . . . 24
5.3. Service to Service Authentication . . . . . . . . . . . . 24
5.4. Access Control for Digital Assets . . . . . . . . . . . . 25
6. Accessibility Considerations . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Definitions of Important Terms . . . . . . . . . . . 26
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Hamrick & Levine Expires November 19, 2010 [Page 2]
Internet-Draft VWRAP: Introduction and Goals May 2010
1. Introduction and Motivation
Virtual Worlds are of increasing interest to the internet community.
Innumerable examples of virtual world implementations exist; most
using proprietary protocols. With roots in games and social
interaction, virtual worlds are now finding use in business,
education and information exchange. This document introduces the
Virtual World Region Agent Protocol (VWRAP) suite. This protocol
suite is intended to carry information about a virtual world: its
shape, its residents and objects existing within it. VWRAP's goal is
to define an extensible set of messages for carrying state and state
change information between hosts participating in the simulation of
the virtual world.
Virtual worlds differ in their capabilities and architectural
features. The VWRAP protocol suite is not appropriate for all
massively multi-participant experiences. This document provides an
introduction to virtual worlds and defines characteristics of virtual
worlds VWRAP explicitly supports. It also describes the specific
objectives of the protocol suite. An overview of the protocol is
included, including an architectural description and list of services
defined in a typical virtual world deployment.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introducing the Virtual World Region Agent Protocol
2.1. A Brief Introduction to Virtual Worlds
At its most basic level, the virtual world mirrors the reified world.
It is inhabited by people and contains objects. Objects and people
have a distinct place in the world and respond to external forces.
The social construction of the virtual world is also similar to the
reified world. People meet and interact with others to complete work
tasks or for simple enjoyment. People converse, share media, and
even sing to each other. A virtual world may allow commerce or
enable building of virtual assets. Nearly the complete range of
human interaction can be replicated in the virtual world. Properly
rendered, an experience in a virtual world can carry the same impact
as one in consensus reality.
To be relevant to the participant's experience, virtual worlds must
retain characteristics of the "real world." Objects in the virtual
Hamrick & Levine Expires November 19, 2010 [Page 3]
Internet-Draft VWRAP: Introduction and Goals May 2010
world are models of familiar shapes and textures, represented using a
common data format so they may be easily processed by the human
visual cortex. At the same time they must carry sufficient
information to be consumed by participants with visual impairments or
to be processed by automated systems. Though the virtual world's
state is maintained by abstract collections of data, it is rendered
as recognizable (though occasionally fantastical) physical objects.
But virtual worlds are not completly faithful mirrors of the world
our physical bodies inhabit. Virtual worlds are not limited by
distance. With appropriate network connectivity, users may interact
even if they are on opposite sides of the earth. Virtual worlds also
allow participants to "play" with physical constraints. They provide
the subjective experience of things not possible in consensus
reality: participants can fly, the effects of "death" are temporary,
users may call items into existence, examine the International Space
Station with friends, examine DNA codon by codon with co-workers, or
experience with a works of interactive art.
Virtual worlds inherit the intellectual property characteristics of
other digital media. Implementers wishing to replicate the economy
of scarcity present in the reified world must take special measures
to avoid or limit the ramifications of unauthorized content
duplication.
The VWRAP suite assumes network hosts, likely operated by distinct
organizations will collaborate to simulate the virtual world. It
also assumes that services originally defined for other environments
(like the world wide web) will enhance the experience of the virtual
world. The virtual world is expected to be simulated using software
from multiple sources; interoperability standards are essential for
delivering a robust services and compelling user experiences. VWRAP
provides these interoperability standaards. It may be used with
large arrays of hosts simulating a vast virtual world, or small
worlds operated for the benefit a few persons. It defines a trust
model so hosts from different organizations may limit access to
sensitive information.
VWRAP presupposes a virtual world with the following characteristics:
1. The virtual world exists independent of the participating
clients.
This is in contrast to systems that dynamically create virtual
environments for specific social or task-oriented simulation.
VWRAP assumes the state virtual world is "always on" and does not
require a specific protocol to establish new virtual worlds.
Hamrick & Levine Expires November 19, 2010 [Page 4]
Internet-Draft VWRAP: Introduction and Goals May 2010
2. Avatars have a single, unique presence in the virtual world.
Users are represented in the virtual world by a digital
representation called an avatar. A user's avatar has an
existence that mirrors the common physical world. Like people,
avatars exist in only one place at one time. Avatars have a
single identity that persists between user sessions. This
identity may be used to render user-specific avatar shape or as
the basis for access control.
3. The virtual world contains persistent objects.
Objects in the virtual world are governed by a "rational" life-
cycle. They are created, persist and are (optionally) destroyed.
Absent external forces, they tend to keep their current state.
2.2. Architectural Objectives
The overall objective of the VWRAP suite is to enable a stable,
extensible and secure virtual world. The protocols defined by this
working group do not mandate a specific system or network
architecture. However, previous implementations of large distributed
systems can yeild clues as to how VWRAP compliant systems will be
deployed. Documents produced by this working group reflect the
consensus view of best common practice for producing large-scale,
loosely-coupled distributed systems. VWRAP does not require a
specific architecture, but it's protocols are defined with a specific
series of architectural patterns in mind.
These architectural patterns have the following objectives in mind:
1. Systems implementing virtual world services should be
distributed.
Virtual worlds are inherently distributed systems. They are
collaborative tools intended to reduce the effect of distance on
meaningful social, educational and commercial interaction.
Typical virtual worlds are envisioned as drawing services from
network hosts operated by a wide array of organizational
entities. Virtual worlds may also be large enough that a single
system or cluster of systems is not capable of providing all
services to each client.
Experience with previous virtual world technologies suggests
systems implementing the virtual world assume services they
depend on are provided by distinct hosts in different
administrative domains. The virtual world, it's user base and
the constellation of virtual objects they use are simply too vast
Hamrick & Levine Expires November 19, 2010 [Page 5]
Internet-Draft VWRAP: Introduction and Goals May 2010
and varied to assume a single system or a single provider.
This does not mean, however, that virtual worlds simulated by the
VWRAP suite must exist on more than one system. Quite the
contrary, all VWRAP components (including the user agent) could
operate on a single system. But there is little reason to
believe the protocol used to exchange information between virtual
world services must differ between small and large systems.
Large virtual worlds with many users are certain to implement
virtual world services differently than small ones. But the
protocol used to to communicate between systems implementing the
virtual world can be the same. To be sure, optimizations may be
possible for smaller deployments. Implementers of these "small"
systems may find it useful to utilize standard, unoptimized
protocols to allow for the possibility of growth.
However large (or small) a virtual world deployment is, or how
many distinct organizations contribute to its operation, software
implementing virtual world services MUST assume resources
required to perform its function are distributed amongst multiple
hosts.
2. Services supporting collaboration are hosted on 'central'
systems.
The VWRAP suite assumes a collection of authoritative hosts for
critical data and services. This applies to digital assets, user
accounts, agent presence information and sources for virtual
world object updates. This is in contrast to 'peer to peer'
systems in which authoritative data may travel between hosts,
depending on which hosts are connected to the network at any
given moment. It also contrasts with 'client authoritative' or
'co-simulation' architectures in which physics simulation and
agent state change occurs on the client.
This does not imply there is a single collection of systems
holding authoritative data for the entire connected Internet.On
the contrary, it explicitly allows for the simultaneous existance
of multiple virtual worlds. It defines the mechanisms by which
systems cooperate to simulate a virtual world, but does not
specify a specific instance of those protocols as being any more
authoritative than any others.
This objective implies that for any given data item, be it a
avatar mesh, a region description or object description, there is
an authorative URL. Subject to security policy, the data may be
cached or transferred between domains, but authority over the
Hamrick & Levine Expires November 19, 2010 [Page 6]
Internet-Draft VWRAP: Introduction and Goals May 2010
data rests with administrative ownership of the host identified
by it's URL.
This decision was motivated by the realization that network load
in niave peer-to-peer implementations increases proportionally to
the factorial of the number of participants. "Client
Authoritative" solutions, where clients are first class
participants in physics simulation or object presence and
differences are explicitly resolved between clients, was thought
to introduce undesirable requirements for client connectivity and
client system performance.
This is not to say that either peer-to-peer or co-simulation are
incompatible with systems that might use VWRAP. But rather, it
was believed that their specification should be deferred to a
later time when solutions to perceived problems could be explored
more fully.
3. Hosts cooperating to simulate a virtual world should be composed
of loosely coupled systems.
This document uses the term "loosely coupled" to mean software
and systems implementing the virtual world should exhibit strong
separation of concerns and resiliance in the presence of version
skew. For the purposes of this document, "loosely coupled"
implies system developers should expect multiple revisions of
message formats to be encountered. Systems implementing these
protocols should make a best effort to interpret messages
received from remote hosts. Conversely, protocol developers and
system implementers should carefully craft new revisions of
messages to avoid confusion for systems expecting earlier message
formats.
The motivation for emphesizing this pattern stems from the
requirement that systems cooperating to simulate the virtual
world may be owned by distinct organizations.
4. A persistent, ubituitous identity may accompany requests between
hosts.
Many network services are provided anonymously; the nature of the
service does not require identity authentication prior to it's
use. But with the increasing deployment of customizable services
delivered on the internet, identity is increasingly important.
Even services that contain information that might not be
considered "sensitive" require a representation of digital
identity if for no other reason than to match service requests
with user preferences. For example, a web page presenting
Hamrick & Levine Expires November 19, 2010 [Page 7]
Internet-Draft VWRAP: Introduction and Goals May 2010
current weather information may be enhanced by remembering
locations of interest to each user. Recent work with "web mash
ups," where multiple personalized or sensitive resources are used
in concert with one another points to the utility of a
"universal" identity. The representation of this universal
identity enables independent services to cooperate to present the
facade of a unified application to the service consumer. This
allows service aggregators to more easily integrate "best of
breed" services into a consistent solution.
Universal identity is critical to the virtual world. To achieve
an internet scale virtual world, user services must be
distributed amongst multiple hosts. To achieve a compelling
experience, it must be easy for service providers to deliver
their services in the virtual world. To facilitate a compelling
social experience in the virtual world, all users must have the
ability evaluate identity information of other users. Domains
responsible for virtual world simulation MUST use a consistent
representation of identity across all their hosts; simulation
would otherwise be uncoordinated. Service providers who deliver
content into the virtual world MUST use a consistent
representation of identity to maintain the persistence of the
virtual manifestation of their service; virtual objects used in
conjunction with these services might otherwise appear to change
state without apparent cause. Users depend on the persistent,
universal identity of other users; if an avatar's identity
changed unexpectedly, the result would be a suboptimal virtual
world experience.
2.3. Protocol Objectives
The primary objective of the Virtual World Region Agent Protocol is
to provide a stable, extensible, secure system for virtual world
information interchange with the following characteristics:
1. Flexible presentation of protocol data
While the primary purpose of the virtual world is to simulate a
physical or social space, the tools used to access objects in the
virtual world may be varied. Using a "3d viewer" is the primary
mode of interaction with the virtual world, but other tools may
be better suited for some tasks. For instance, it may be easier
for a user to use a web browser to review avatar profile
information, or to change details of virtual objects. Further,
virtual world "mash ups" may prove to be important to some
communities. To support the web (where XML and JSON are the
lingua franca of information exchange) while also supporting
tools where binary encodings are more appropriate, VWRAP was
Hamrick & Levine Expires November 19, 2010 [Page 8]
Internet-Draft VWRAP: Introduction and Goals May 2010
designed to be "presentation neutral."
VWRAP protocol exchanges are described in terms of an abstract
type system using an interface description language.
Implementations may choose to instantiate actual protocol data
units using the most appropriate presentation format. Web-based
applications may choose to use JSON or XML. Server-to-server
interactions may use the VWRAP specific binary serialization
scheme if implementers and deployers view binary encoding to be
advantageous. The decision of which serialization scheme to use
is ultimately that of the system implementer. VWRAP has been
designed to provide this flexibility to system implementers and
those tasked with deploying VWRAP compatible systems.
2. Flexible decomposition of concerns and ease of extension
VWRAP has been daesigned to allow meaningful separation of
concerns. In other words, changes in one part of the protocol
should not appreciably affect other parts.
For example, the authentication portion of the protocol is
independent of the part of the protocol that deals with instant
messaging or instantiating objects in the virtual world. In
addition to defining messages for communicating application
state, the specification also defines pre- and post-conditions.
Should one particular authentication scheme be found to be
lacking, it can be modified or replaced without affecting other
systems.
This type of separation of concerns in the protocol specification
also makes it easy to deploy "related solutions." While VWRAP
was designed primarily to communicate the state of the virtual
world between servers and client applications, a number of
related applications also exist. E-Commerce web sites related to
the virtual world and mobile chat clients allowing instant
messaging between mobile networks and virtual world participants
are just two examples of such applications. Proper separation of
concerns allows new services to be specified and deployed without
the need to redefine existing protocol.
3. Resilience in the face of version skew
Core to the VWRAP protocol is the idea that different components
and services may be operated by different administrative
entities; identity management services might be operated one
business while simulation services are operated by another. In
environments where many different organizations participate,
version skew can be an important concern. VWRAP was designed to
Hamrick & Levine Expires November 19, 2010 [Page 9]
Internet-Draft VWRAP: Introduction and Goals May 2010
"degrade gracefully" when two systems running different versions
of the protocol attempt to communicate.
VWRAP uses the LLSD abstract type system and the LLIDL interface
description language to describe the structure and type semantics
of elements in messages sent between systems. Because LLSD makes
extensive use of variable width, clearly delineated data fields,
services which consume protocol messages may identify and extract
only those message elements they know how to handle. While this
is not a guarantee that message semantics may be preserved in all
version skew situations, it does eliminate one important cause of
interoperability failures.
3. Virtual World Region Agent Protocol Architecture
3.1. Deployment Patterns
The VWRAP suite assumes that the services that simulate the virtual
world will be hosted on multiple network hosts. Client applications
that render the virtual world for end users are assumed to be on
distinct hosts as well.
+---------------------+
| organization 1 |
| |
| +----------------+ | +-------------+
+------>| service host 1 |<------>] |
| | +----------------+ | | client |
| | | +-->| application |
+-------------+ | | | | | |
| |<----+ | +----------------+ | | +-------------+
| client |<----------->| service host 2 |<---+ ^
| application | | +----------------+ | |
| |<----+ +---------------------+ |
+-------------+ | |
| +---------------------+ |
| | organization 2 | |
| | | |
| | +----------------+ | |
+------>| service host 3 |<---------+
| +----------------+ |
+---------------------+
Figure 1: Protocol Flows in VWRAP
Hamrick & Levine Expires November 19, 2010 [Page 10]
Internet-Draft VWRAP: Introduction and Goals May 2010
Figure 1 above demonstrats a typical virtual world deployment. In it
we see multiple client applications connecting to several servers
operated by multiple organizations. Each "service host" in this
diagram exposes an interface to a collection of resources
representing the state of objects in the virtual world. It is
traditional to discuss related resources as exposing "an interface"
while related interfaces comprise "a service." Typical services are
listed in a section below.
There is no restriction on how services map to hosts. Deployments
where all resource interfaces are hosted on a single host is just as
valid as one where resources are spread between a wide array of
systems. Client applications should support both.Resource interfaces
are addressed using URLs. Clients should treat the URLs for
resources as opaque resource locations.
Clients use the "service establishment" process to retrieve URLs to
various resources.
3.2. Protocol Elements
VWRAP utilizes a number of "architectural motifs" or recurring design
patterns. Most notably they include:
o exposing application state via RESTful resources
o using URIs to represent the address of application resources
o using HTTP to "carry" message oriented protocol data
o defining application state transitions and accesses with an
interface description language
o using an abstract type system to define access semantics of fields
in protocol messages
o using multiple "serializations" of the abstract type system to
support different categories of consumers; defined serializations
include XML, JSON and Binary.
3.2.1. Communicating Application State Using REST-Like Resource
Accesses
Contrary to popular opinion, not ALL virtual world interactions must
be real-time exchanges. Many common activities like user
authentication and texture and object transfer do not require "real
time" semantics in the same way that applications like video-
conferencing and Voice Over IP (VOIP) do. While it is generally a
Hamrick & Levine Expires November 19, 2010 [Page 11]
Internet-Draft VWRAP: Introduction and Goals May 2010
better experience if textures download quickly, if they are delayed,
it does not have the same ramifications as if a voice packet in a
VOIP system were delayed. Additionally, some interactions with the
virtual world are strongly reminiscent of the request / response
semantics used by popular protocols (like HTTP, POP3, etc.)
Because many protocol exchanges in the virtual world may be
represented as non-real-time request / response interactions, VWRAP
"reuses" the messaging semantics of HTTP. The justification for this
is simple. Were VWRAP to not use HTTP, many of the features of HTTP
would need to be re-invented or at least re-specified. Features like
the use of mime types to identify payload structure; the use of
message headers to modify the request or response and the use of URIs
to address and identify resources. HTTP also has the benefit of
being well supported by tools vendors and well understood by
manufacturers of networking equipment.
Protocol exchanges in VWRAP that utilize request / response semantics
are described using the LLSD / LLIDL abstract type system
[I-D.hamrick-vwrap-type-system]. LLSD defines type semantics for
elements in a protocol data unit as well as rules for converting the
data into a serialized form suitable for transmission across the
network. VWRAP defines HTTP (and HTTPS) as the transports for
serialized messages.
Addressable protocol endpoints in VWRAP are represented as URIs
[RFC3986]. Protocol endpoints generally address RESTful resources.
The VWRAP protocol uses HTTP verbs to provide read and write access
to resources which represent the application state of the remote
peer.
To recap, the objective of VWRAP is to communicate application state
about the virtual world to all participants. VWRAP messages that
communicate request / response style messages flow between clients
and servers, using HTTP(S) as a message transport. Application
objects representing the application state expose a RESTful interface
and are addressed unambiguously using URIs. The VWRAP message
formats are described using LLIDL, the interface description language
defined as part of the LLSD abstract type system. LLIDL defines
RESTful resource accesses in terms of the LLSD abstract type system,
which may be serialized using one of three well defined serialization
mechanisms: XML, JSON and Binary. Protocol participants decide
before interacting which serialization mechanism is most appropriate
or use the content negotiation mechanisms defined in HTTP.
Hamrick & Levine Expires November 19, 2010 [Page 12]
Internet-Draft VWRAP: Introduction and Goals May 2010
3.2.2. Bi-Directional Messaging with the VWRAP Event Queue
Not all protocol interactions are easily represented by HTTP's
request / response semantics. When the server has a message for the
client, there is no widely deployed technique for the server to
initiate a HTTP request to the client. It is interesting to note
that this is the same problem developers of "rich web applications"
see when deploying their applications. Though VWRAP is not targeted
for implementation exclusively in web browsers, we can utilize some
of the techniques common in COMET applications.
Work is ongoing to define a general solution for "reverse HTTP," but
many of these solutions require the definition of new protocol and
deploying new code to web servers. The current best practice for
COMET-style interaction is the use of the "long poll."
To avoid "technology lock in," VWRAP defines an Event Queue
abstraction that represents the flow of messages from the server to
the client. The Event Queue is expected to be implemented using the
long poll technique. When additional options such as Reverse HTTP or
web sockets are specified and in general deployment, the Event Queue
may be re-implemented using these techniques. However, the interface
defined by the Event Queue in the VWRAP Foundation document
[I-D.lentczner-vwrap-foundation] should not change.
3.2.3. Using Capabilities to Simplify Inter-Domain Access Control
Simulated objects and services delivered by VWRAP compliant systems
will require some level of access control. Unfortunately,
distributed access control is a notoriously difficult problem. VWRAP
seeks to minimize the drawbacks of distributed access control by use
of capabilities. In this context, a capability is an opaque URL,
some portion of which contains a securely generated,
cryptographically unguessable sequence of digits. Capabilities are
used to define service endpoints and are intended to only be in the
possession of trusted parties.
For example, a system may export the capability:
http://www.example.org/s/B2A2A445-D234-463A-BE6D-6C54E5854FE4/
This URL defines the protocol endpoint used to communicate
application state changes (or query application state) for a specific
application object by a specific user (or delegate.)
Capabilities are required to be effectively unguessable as they
represent the right to perform a set of operations on a particular
resource. Additionally, they must be kept "secret." While the task
Hamrick & Levine Expires November 19, 2010 [Page 13]
Internet-Draft VWRAP: Introduction and Goals May 2010
of maintaining the confidentiality of a number of web resource
addresses may be a burden, it does have the advantage of simplifying
access delegation. If a subject wishes to delegate access to a third
party, they simply communicate the capability.
To reduce the likelihood of successful guessing attacks, inadvertent
disclosure of a capability and "time of check, time of use" attacks,
capabilities in VWRAP have a fixed lifetime, after which they expire.
Systems SHOULD pick capability lifetimes commensurate with their
security requirements and MUST NOT respond to protocol requests
directed at a capability's URL after it has expired. Additionally,
VWRAP capabilities may be "single use" or "one shot," meaning that
they may only be used once before expiring.
Because capabilities are randomly generated with a short lifetime,
VWRAP defines a mechanism for securely communicating capabilities and
re-requesting expired capabilities.
It is important to note that capabilities do not completely replace
traditional access control models. Systems may still use traditional
Subject-Permission-Object schemes to represent access control for
objects under their control. Capabilities provide a mechanism for
communicating access control decisions among loosely coupled trusted
systems.
3.2.4. Using LLSD to Avoid Version Skew
It is a common practice in large, complicated software systems to
divide the system into smaller, more manageable pieces. The precise
nature of this partitioning is beyond the scope of this protocol.
However, practical experience has demonstrated that services
distributed across multiple co-operating hosts MUST contend with the
issue of version skew. Simply stated, version skew is the condition
where multiple versions of a service are interoperating
simultaneously.
There are many reasons why version skew may be introduced. In VWRAP,
agent domain hosts and region domain hosts may be operated by
different organizations with different deployment schedules. Or
perhaps a domain operator is required to support an obsolete version
of a particular service endpoint for a small number of customers.
Whatever the cause of version skew, it has, in the past introduced
difficulties in deploying distributed services.
VWRAP does not seek to eliminate version skew, but it does attempt to
reduce it's impact. VWRAP services are defined in using the LLIDL
interface description language. LLIDL defines the type semantics of
fields inside a protocol message using the LLSD abstract type system.
Hamrick & Levine Expires November 19, 2010 [Page 14]
Internet-Draft VWRAP: Introduction and Goals May 2010
Each of the abstract types defined in LLSD has a default value, and
common conversions between conformable types are defined. LLSD
specifies three standard techniques for serializing a protocol
message prior to transmission across the network. Each of the three
serialization techniques renders protocol messages into a collection
of variable length fields. Protocol content is identified by JSON
syntax, binary tags or XML element semantics, not by it's position in
the message. LLIDL does not support the concept of a "required
field." If a field defined in a protocol interaction is not present
in the serialized message, it is semantically equivalent to the field
being present and containing the default value for the field's type.
Careful construction of service endpoints allows them to consume
messages described using LLIDL without fear that version skew induced
format differences may cause the semantics of the message to be
unclear. If a message arrives at a service endpoint with extra
fields (fields defined in a later revision of the protocol exchange),
the consumer can still extract those fields it understands. If a
message arrives lacking a field described in the protocol exchange,
the service endpoint SHOULD interpret it as if the field was present
and contained the default value for it's type. This implies the
message consumer cannot depend on the format of the message to
determine validity, but must examine the contents of the message,
converting missing fields to present fields with default values, and
then determine if sufficient information is present to imply
semantics about the protocol exchange.
This technique will not eliminate all ramifications of version skew,
but carefully constructed service descriptions should be able to
avoid the most common problems found when services interoperate with
minor revision differences. While the Virtual World Region Agent
Protocol itself does not mandate this style of message
interpretation, it does require that messages be constructed so that
service endpoints may do so.
4. Virtual World Region Agent Protocol Services
Simulation and persistence of virtual objects in VWRAP is managed on
"central" servers. Servers maintain interfaces to shared resources
which represent the state of the virtual world. Interfaces are
grouped by function into "services." Services are available to
support the access to and distribution of data representing multiple
facets of the virtual world. This section defines some services
defined by VWRAP.
Hamrick & Levine Expires November 19, 2010 [Page 15]
Internet-Draft VWRAP: Introduction and Goals May 2010
Avatar Presence
When a user authenticates themselves and wishes to interact with
the virtual world, the user's avatar presence must be
established. Simulating a user's avatar is a task shared by the
agent domain, the region domain and the client application. The
agent domain is responsible for establishing the user's presence
in the virtual world simulated by the region domain, and to
provide information about the avatar so it may be properly
rendered.
Object Presence
The state of objects in the virtual world (landscapes, avatars,
virtual "things") must be communicated to all participants. It
is the responsibility of the region domain to keep track of each
object's state. The landscape can change; clouds in the virtual
sky may move and change shape; virtual people may move around and
virtual "things" can undergo any number of state changes. The
region domain is responsible for receiving input from virtual
world inhabitants, evaluating how that input changes the state of
objects in the virtual world, and then communicating those state
changes to other observers.
Physics Simulation
Simulating the physical behavior of objects in the virtual world
is a core feature of any virtual world. Regions may choose
"earth like" conditions, or may modify gravity and atmospheric
settings to create the experience of being on a different planet.
Still other options include simulating quantum effects seen at
very small scales or the large scale relativistic effects seen on
galactic scales. Whatever the "physics" involved, it is the
individual hosts in the region domain tasked with the simulation.
Effects of Programmatic Changes
(aka "scripting.") Some virtual worlds allow users to modify the
state of objects using simple programming languages. The region
domain is generally responsible for managing and executing
scripts that modify the state of objects.
Region Specific Asset Storage
Though most "assets at rest" are associated with an avatar, it is
conceptually appropriate for some items to be associated with a
region; textures associated with landscapes, for instance. Or in
some situations, the operator of a region may wish to bind
Hamrick & Levine Expires November 19, 2010 [Page 16]
Internet-Draft VWRAP: Introduction and Goals May 2010
"sensitive" resources to the location to ensure they do not
follow region visitors to regions outside the originating
region's administrative authority.
4.1. Authentication
User Authentication in the Virtual World Region Agent Protocol is
intended to verify the user's authorization to control their avatar
in the virtual world and associated services. VWRAP currently
defines three methods for authenticating a user, as well as
recommendations for integrating some third party authentication
schemes. The inputs to authentication are an avatar or account
identifier and a related authentication token. Assuming the token is
successfully authenticated, the output of authentication is a seed
capability or "seed cap."
Like most VWRAP protocol exchanges, authentication protocol data is
represented as LLSD serialized data carried over a secure HTTPS
transport. The use of TLS with VWRAP authentication is recommended
for all deployers who do not employ some other network security
scheme (IPSec, link encryption, etc.) Implementers are advised that
in addition to user's password (or other credential,) the seed
capability returned after successful authentication is also
considered "sensitive" and should be protected with appropriate
network security measures.
The three authentication schemes defined in the VWRAP Trust Model and
User Authentication [I-D.hamrick-vwrap-authentication] specification
use a cryptographic hashes to demonstrate the user is in possession
of the shared secret associated with their account. Recommendations
also exist for using transport authentication mechanisms (such as TLS
client certificates) in place of shared secrets. Also, work is
currently underway to define protocol messages for use with Secure
Remote Password (SRP).
The authentication mechanisms described above are believed to be
sufficient at the time of this writing. It is an unfortunate truth,
however, that cryptographic primitives are occasionally shown to be
less secure than originally believed. For this reason, VWRAP
Authentication was designed to be extensible; allowing future users
to define new authentication schemes without invalidating other
authentication components. A further benefit of flexibility is the
ability to integrate other authentication schemes into an VWRAP
context. OpenID and SAML, for instance, are popular identity and
user authentication technologies that are defined outside the IETF.
VWRAP's flexible authentication system allows organizations
responsible for these standards to define their use with VWRAP
without having to change the text of the VWRAP Authentication
Hamrick & Levine Expires November 19, 2010 [Page 17]
Internet-Draft VWRAP: Introduction and Goals May 2010
standard.
A typical flow of events for user authentication follows. This is a
simplified version; readers with an interest in authentication are
referred to the VWRAP Trust Model and User Authentication
[I-D.hamrick-vwrap-authentication] specification.
1. The end user presents their account identifier (either avatar
name or account name) and an authenticator to the authentication
services of the agent domain. Endpoints for user authentication
protocol messages are typically well defined, public URLs.
2. The authentication service authenticates the authenticator. If
the credentials cannot be authenticated, an error condition is
returned.
3. The authentication service generates a seed capability and
returns it to the user.
4. The user queries the "seed cap," requesting capabilities for
other services the user is authorized to use.
It is important to note that in the last step listed above, the
client is free to request a subset of services offered by the agent
domain. This allows the same authentication service to be used by
restricted clients (for instance, a group-chat only client) as well
as traditional 3d viewers.
4.2. Text and Voice Chat
Virtual worlds are social spaces; efficent communication between
users is a critical component of the virtual world experience. VWRAP
virtual worlds support four types of text communication:
1. User to User Akin to traditional "instant message" systems, User-
to-User Text Chat includes two participants, the sender and the
receiver.
2. Group Group Text Chat is the process of delivering text messages
to members of a pre-defined group. Group Text Chat groups are
frequently defined by an external authority and have a well known
name, discoverable by a search function.
3. Ad Hoc Group Ad Hoc Group Text Chat involves delivering text
message to a group created in an ad-hoc fashion. Membership in
an Ad Hoc Text Chat group is defined by the message sender. The
group typically does not have an externally locatable name.
Hamrick & Levine Expires November 19, 2010 [Page 18]
Internet-Draft VWRAP: Introduction and Goals May 2010
4. Proximal Chat When a user "virtually" chats to an avatar near it
in the virtual world, it is making use of Proximal Chat. The
endpoint for Proximal Chat messages is a location in the virtual
world rather than a particular usre or group. Users whose
avatars are within the proximity of the chatting user's avatar
will receive text chat from that user.
Significant effort has been invested in developing protocols capable
of efficiently deliverign textual information between users and
groups. Protocols such as XMPP, SIMPLE and IRC may be used to carry
text chat messages while VWRAP defined messages are used to establish
and destroy text chat sessions.
Though the protocols used to implement voice communication in the
virtual world are no doubt different from those that carry text
messages, the scenarios for voice communication mirror those of for
text. Four types of voice chat exist: User-to-User, Group, Ad Hoc
Group and Proximal.
4.3. Agent Presence
Once authenticated, the client application has established "agent
presence." Once in possession of a valid seed capability, the client
application may request a set of capabilities representing services
offered by the agent domain: digital asset management, instant
message and voice chat support as well as placing the user's avatar
into the virtual world.
Placing an avatar in the virtual world begins with the client
exercising the "place my avatar in a region" capability. As part of
this transaction, the client provides the URI representing a region.
Upon receipt of this request, the agent domain determines the
validity of the URL provided, and if the URL resolves to a trusted
region domain begins the protocol between the agent domain and the
region domain to place the user's avatar in the region.
The precise exchange of messages between each party is beyond the
scope of this document, but is described in the VWRAP Teleport
specification But a few important points should be noted:
o The protocol endpoint used by the client application to place the
user's avatar in a region is managed by the agent presence service
and provided by the authentication service following successful
authentication. It is not a publicly defined, fixed URL.
o Regions in VWRAP are represented with a URL. After
authentication, the client uses this URL to tell the agent
presence service where to place the user's avatar.
Hamrick & Levine Expires November 19, 2010 [Page 19]
Internet-Draft VWRAP: Introduction and Goals May 2010
o The agent presence service MAY apply a local policy to the URI and
reject the request before attempting to connect with a region.
For instance, a "behind the firewall" agent presence service may
limit clients to regions known to be hosted by systems inside the
local intranet.
o The agent presence service MAY apply a local policy and reject the
request after it makes an initial communication request with the
remote region. (for example, if the region domain is operating
servers with expired TLS certificates, or if those certificates
are issued by a certifying authority the agent domain does not
trust, it may reject the request.)
o The process of placing the avatar in the region results in
capabilities from the region being communicated back to the agent
presence service and the client application. These capabilities
are used to by the client to control the user's avatar and to
access region-specific services.
o The process also results in the agent presence service issuing
capabilities to the region, allowing it limited access to
information about the avatar such as the avatar's shape and
appearance.
After an avatar is "placed" or "rezzed" in a region, the agent
presence service is responsible for maintaining it's presence in a
single location. That is to say, after the avatar has been
successfully been placed in a region, the agent presence service MUST
refuse to allow a second region to "take" the avatar's presence
without removing the avatar from its current region.
4.3.1. Moving Presence
When an avatar moves between regions, special care must be taken that
the agent presence service and both the source and destination
regions agree where avatar is located.
Moving between regions is typically initiated by the client. The
process is largely the same as the initial avatar placement, but with
the important added step of removing the avatar from it's source
location before rezzing it in it's destination. (In fact, the
initial placement of an avatar can be thought of as a transfer from
"nowhere.")
The process of moving between regions is described in the VWRAP
Teleport specification, thought implementers should keep the
following important considerations in mind:
Hamrick & Levine Expires November 19, 2010 [Page 20]
Internet-Draft VWRAP: Introduction and Goals May 2010
o The client signals to the agent presence service it's desire to
move from one region to another by accessing the same capability
as is used for initial placement of the avatar.
o The agent presence service must again check that local policy
allows movement to the new destination, and MUST receive a
capability for placing the client into the new region before it
removes the avatar from it's current location.
o The agent presence service MUST also remove the avatar from it's
current location before placing the avatar in the destination
location. Capabilities granted to the current region MUST be
revoked as part of this process.
o The location of the avatar MUST be unambiguous and the agent
presence service MUST NOT represent the avatars location as being
in two places at once. If required, for the short period between
removing the avatar from one region and placing it in another, the
avatar's location may be "in transit."
4.4. Digital Asset Access
The virtual world is filled with virtual objects: conference tables,
houses, airships, dragons, etc. These objects may or may not be
instantiated in the virtual world. Digital descriptions of objects
to be placed in the virtual world should be made available to clients
by way of the "Asset Access Protocol." Services that wish to display
or manipulate digital assets query servers using this protocol.
The asset access protocol defined in VWRAP differs significantly from
legacy protocols defined by previous virtual world systems. It has
been designed to more easily integrate existing collections of
digital assets using standard protocols such as HTTP. All assets
used by VWRAP, including avatar meshes, scene graphs and virtual
object descriptions are accessed using this protocol.
4.4.1. Manipulating Digital Assets
A number of useful manipulations of digital assets "at rest" are
defined by VWRAP. Where appropriate, asset metadata may be altered
by directly communicating with the network host with authority for
that asset. This host may be part of the user's agent domain, or in
the case of region-specific assets, it could be associated with a
region domain. It is important to note, however, that not all
metadata is modifiable by all users, even the asset's owner.
Specifically, the semantics of the creator metadata do not allow the
owner to change the creator's identity. Group membership may carry
some rights like the ability to manipulate the size, shape and
Hamrick & Levine Expires November 19, 2010 [Page 21]
Internet-Draft VWRAP: Introduction and Goals May 2010
texture of an asset, but not an asset's owner.
The ability to access or manipulate digital assets is based on the
accessor's identity. Accessing and manipulating digital assets is
performed via capabilities which expose the state of the asset to an
authorized client. This requires positive identification of the
accessor prior to access. In the case where an asset service is
owned by the same authority as the authentication service, this
access may be as simple as providing the proper capability after user
authentication. In cases where the asset service is owned by a
different authority, systems for deferred authentication may be
necessary. Work is currently underway to integrate OAuth and SAML
into VWRAP for this purpose.
At a gross level, the types of resources exposed by a digital asset
server would include:
o a resource for searching an agent's inventory
o a resource for iterating across an agent's inventory
o a resource for accessing or manipulating a digital asset's
metadata
o a resource for uploading new digital assets, or changes to an
existing asset.
o a resource for removing a digital asset from the authority of the
asset service
o a resource for transferring the asset or a copy of the asset to a
remote asset service
o a resource for instantiating (or "rezzing") an object "in world"
4.4.2. Establishing Presence for Digital Assets
Digital assets are intended to be used "in world," meaning there must
be a way for a user to direct a simulation host to take an asset from
an asset store and imbue it with presence in the virtual world. The
separation between agent based services and region based services is
fundamental to VWRAP and implies the authority for the system
maintaining the asset "at rest" may be distinct from that which
simulates the asset "in world." In practical terms, a region
simulator may need to communicate with an asset server owned by a
different person or company. In situations like this, trust is
paramount. Because an asset's metadata may limit the owner's right
to make copies of an asset, the agent domain MUST be able to trust
Hamrick & Levine Expires November 19, 2010 [Page 22]
Internet-Draft VWRAP: Introduction and Goals May 2010
the region domain will honor that metadata.
There are two levels of trust defined when working with digital
assets: host-based trust and user-based trust. The former represents
one system's expectation that the other will honor the metadata
regarding ownership, creatorship and rights and restrictions implied
by these concepts. Host based trust is carried by X.509 / PKIX
certificates and implies a managed PKI. User-based trust represents
the expectation the asset server will expose sensitive resources only
to users with the right to access such resources.
Provided trust is established between the asset server and a
simulation host, and the simulation host can demonstrate it is acting
on behalf of a user with rights to access a particular resource,
VWRAP defines a protocol for transferring a representation of the
digital asset for simulation. As part of this protocol, access to a
digital asset may be restricted while the object exists "in world."
This is the case for objects whose creators or owners specify that
only one copy of the asset may exist at a time.
5. Security Considerations
As mentioned previously, the concept of a persistent, ubiquitous
identity in the virtual world is core to the user experience.
Keeping agent based services distinct from region or object based
services has advantages for scalability and flexibility. However, it
does have ramifications for the security of the virtual world as a
whole.
Most notably, this structure puts the authentication service in the
role of a trust broker. As the authentication service must collect
capabilities for the benefit of the client, is trusted by both client
applications and peer services. A transitive trust relationship
exists between the peer services and end users by way of the
authentication service. The administrators of peer services trust
the authentication service to properly identify end users, and
potentially to ensure they are members of a particular class. The
end users trust the authentication service to properly identify peer
services and to limit the transfer of digital assets to only those
entities that explicitly agree to honor asset permissions meta-data.
VWRAP does not REQUIRE services to adhere to any preset policy,
however. It instead provides a mechanism for communicating identity
information so that such a policy MAY be enforced.
Hamrick & Levine Expires November 19, 2010 [Page 23]
Internet-Draft VWRAP: Introduction and Goals May 2010
5.1. Capabilities
VWRAP makes extensive use of RESTful resources accessed via HTTP.
Application state is communicated and changed by accessing web based
resources. One characteristic of such resources is they have a well
defined URL, many of which are formatted as URL-based capabilities.
[I-D.lentczner-vwrap-foundation] Capabilities have the characteristic
that possession of the URL implies the right to access the resource
it identifies. It is important that capability URLs are shared only
with trusted participants. The VWRAP Base document defines the
characteristics of URL-based capabilities, including the requirement
that they include an unpredictable random component in the URL.
Implementers need also ensure that these URLs are protected using
suitable mechanisms (such as TLS, IPSec or link encryption.)
5.2. User Authentication
Prior to granting an end user access to sensitive resources, the
client MUST be authenticated. The VWRAP Authentication specification
defines three techniques for using shared secrets to authenticate end
users. The agent_login resource used for end user authentication
provides an extensible mechanism, allowing the development and use of
additional authentication techniques (SRP, TLS Client Certificates,
SASL, etc.)
Again, it should be noted that VWRAP as currently defined does not
REQUIRE an authentication service to support a particular
authentication scheme (shared secret, public key, secure remote
password, etc.) But it does define the mechanism for three shared
secret options.
Once a user is successfully authenticated, their client application
is passed a seed capability (as described in the VWRAP Base
specification.) This seed capability is used by the client
application to request access to resources and services managed by
the agent domain (including services like "place my avatar in the
virtual world.")
5.3. Service to Service Authentication
Authenticating one service to another uses an X.509 PKI. Prior to
communicating, the originating service generates a key pair for each
host under their control and requests a certificate from each the
peer service with which they wish to interact. The peer service
returns a signed certificate the originating service uses in
subsequent communication with the region.
Hamrick & Levine Expires November 19, 2010 [Page 24]
Internet-Draft VWRAP: Introduction and Goals May 2010
5.4. Access Control for Digital Assets
In addition to security characteristics addressing traditional
network and user security issues, the raison d'etre of VWRAP is to
communicate state concerning items inhabiting a virtual world. Some
of these items may have access control restrictions within the scope
of the applications used to simulate and render the virtual world.
VWRAP defines an extensible permissions model which allows
permissions meta-data to be associated with virtual items.
6. Accessibility Considerations
This document makes extensive reference to the visual properties of
objects. It is important to note that semantic cues may be more
important to persons with visual deficits. The VWRAP suite includes
the ability to annotate objects with situaltional or semantic meta-
data to provide a meaningful experience to non-sighted users.
Implementers are are encouraged to consider that client applications
favored by non-blind users may query the state of the virtual world
differently; the VWRAP suite SHOULD be sufficently expressive to
support multiple modes of interaction with the virtual world.
Implementers are also encouraged to consider the wide range of human
capability and to design interaction experiences applicable to all.
7. IANA Considerations
This memo includes no request to IANA.
8. References
8.1. Normative References
[I-D.hamrick-vwrap-authentication]
Chu, T., Hamrick, M., and M. Lentczner, "VWRAP Trust Model
and User Authentication",
draft-hamrick-vwrap-authentication-00 (work in progress),
February 2010.
[I-D.hamrick-vwrap-type-system]
Brashears, A., Hamrick, M., and M. Lentczner, "VWRAP :
Abstract Type System for the Transmission of Dynamic
Structured Data", draft-hamrick-vwrap-type-system-00 (work
in progress), February 2010.
Hamrick & Levine Expires November 19, 2010 [Page 25]
Internet-Draft VWRAP: Introduction and Goals May 2010
[I-D.lentczner-vwrap-foundation]
Lentczner, M., "Virtual World Region Agent Protocol:
Foundation", draft-lentczner-vwrap-foundation-00 (work in
progress), February 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[RFC1822] Lowe, J., "A Grant of Rights to Use a Specific IBM patent
with Photuris", RFC 1822, August 1995.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
Appendix A. Definitions of Important Terms
agent domain
The agent domain is the administrative authority responsible for
managing services related to avatars and users. Identity
management, group membership, avatar appearance, profile
information, user authentication and group messaging are examples
of services and information maintained by the agent domain.
agent host
A network host maintained by the agent domain is called an "agent
host."
avatar
The avatar is the representation of a user in the virtual world.
The avatar's shape and appearance are used by other users to
render a graphical representation of the inhabited virtual world.
The user's view of the virtual world is rendered from the
perspective of their avatar.
Hamrick & Levine Expires November 19, 2010 [Page 26]
Internet-Draft VWRAP: Introduction and Goals May 2010
client application
A client application is any application that is operated for the
benefit of the user. Common client applications might include a
"viewer" that renders the virtual world on the user's workstation
or a web application used to manipulate the user's digital
assets. VWRAP does not provide a canonical list of client
application categories, but if an application is not a part of an
agent domain or a region domain and it is manipulating user data
or an avatar on behalf of a user, with the user's permission, it
is a client application.
region domain
The region domain is the administrative authority responsible for
managing services related to presence in the virtual world and
it's simulation. Typical services exposed by a region domain
would include physics simulation, avatar presence and virtual
object presence lifecycle management (i.e. - the creation,
manipulation and destruction of objects in the virtual world.)
region host
A network host maintained by the region domain is called a
"region host", though the historical term "simulator" is still
very common.
user
The entity controlling an avatar in world is the "user".
Appendix B. Acknowledgements
The author gratefully acknowledges the contributions of: Mark
Lentczner, David Levine, David Crocker, Larry Mastiner, Joshua Bell,
Barry Leiba, Kevin Flynn, Morgaine Dinova, Joe Hildebrand, Lora
Baines, Alan Bradley, Chris Newman, Katherine Mancuso and Jon
Peterson.
Hamrick & Levine Expires November 19, 2010 [Page 27]
Internet-Draft VWRAP: Introduction and Goals May 2010
Authors' Addresses
Meadhbh Siobhan Hamrick
P.O. Box 783
Boulder Creek, CA 95006
US
Phone: +1 650 283 0344
Email: OhMeadhbh@gmail.com
David W. Levine
IBM Thomas J. Watson Research Center
19 Skyline Drive
Hawthorn, NY 10532
US
Phone: +1 914 784 7427
Email: dwl@us.ibm.com
Hamrick & Levine Expires November 19, 2010 [Page 28]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/