okay... here's what i think we've all agreed to. i've taken the
liberty of using the VWRAP name since it seems to me we have consensus
around that name.
also note that i still have the ogpx at ietf.org email list in the
charter text, since we don't have the VWRAP mailing list up yet.
but the rest of it should be "correct" based on discussions. please
look it over and tell me if i've missed something.
-cheers
-meadhbh
Working Group Name:
Virtual Worlds Region Agent Protocol (VWRAP)
Chairs:
TBD
Area and Area Directors:
Applications Area
Lisa Dusseault <lisa.dusseault at gmail.com>
Alexey Melnikov <alexey.melnikov at isode.com>
Responsible Area Director:
TBD
Mailing List:
ogpx at ietf.org
http://www.ietf.org/mailman/listinfo/ogpx
Description of Working Group:
The working group will define the Virtual Worlds Region Agent Protocol
(VWRAP) for collaborative 3-dimensional virtual worlds. The protocol
permits users to interact with each other while represented as
"avatars," or digital representations of the user. Within a single
virtual world, avatars exist in at most one location in a shared
virtual space. Conforming client applications use the protocol to
manipulate and move the user's avatar, create objects in a virtual
world, interact with other users and their surroundings and consume
and create media and information from sources inside and outside their
virtual world.
Adjacent locations in virtual worlds accessible by this protocol may
be explicitly partitioned into "regions" to facilitate the
computational and communication load balancing required to simulate
the virtual environment. Such virtual worlds may consist of regions
administered by distinct organizations. Though these virtual worlds
may be partitioned, they remain "un-sharded;" all inhabitants and
objects in a particular location in a virtual world may initiate
interaction with all other inhabitants and objects in that location;
and, service endpoint addresses refer to at most one location. The
state of a virtual world is independent of the client applications
that access it and may persist between user sessions.
Regions and services implemented according to the specifications may
be deployed by separate organizations with varying policies and trust
domains. The OGPX protocols will provide the mechanisms for these
virtual world services to interoperate, when permitted by policy and
shared trust domains. To support the exegesis of the specifications,
the group may define a non-exhaustive set of non-normative policies
protocol participants may enforce.
The protocol should describe interaction semantics for these virtual
worlds, independent of transport, leveraging existing standards where
practical. It should define interoperability expectations for server
to server interactions as well as client-server interactions. Though
the protocol is independent of transport, early interoperability
trials used HTTP(S) for non-real-time messages. The working group will
define specific features that must be replicated in other transports
and will define the use of HTTP(S) as a transport of protocol
messages.
Foundational components of the protocol include the publication of:
* an abstract type system, suitable for describing the application
protocol in an implementation neutral manner,
* a security model describing trust relationships between
participating entities,
* guidelines for the use of existing authentication and
confidentiality mechanisms,
* an application-layer protocol for establishing the user's avatar
in a virtual world,
* an application-layer protocol for moving a user's avatar between
adjacent and remote locations in a virtual world,
* format descriptions for objects and avatars in a virtual world, and
* an application-layer protocol for identifying agents, and
requesting information about them.
The protocol defined by this group will carry information about the
virtual environment, its contents and its inhabitants. It is an
application layer protocol, independent of transport, based partially
on these previously published internet drafts:
* http://tools.ietf.org/html/draft-hamrick-ogp-intro
* http://tools.ietf.org/html/draft-hamrick-llsd
* http://tools.ietf.org/html/draft-hamrick-ogp-auth
* http://tools.ietf.org/html/draft-hamrick-ogp-launch
* http://tools.ietf.org/html/draft-lentczner-ogp-base
* http://tools.ietf.org/html/draft-levine-ogp-clientcap
* http://tools.ietf.org/html/draft-levine-ogp-layering
Goals and Milestones:
* October 2009 "Introduction and Goals" to the IESG as an
Informational RFC
* October 2009 "Abstract Type System for the Transmission of Dynamic
Structured Data" to the IESG as Proposed Standard
* October 2010 "Foundational Concepts and Transport Expectations" to
the IESG as Proposed Standard
* February 2010 "Guidelines for Host Authentication" to the IESG as
an Informational RFC
* February 2010 "Service Establishment" to the IESG as Proposed
Standard
* February 2010 "Client Application Launch Message" to the IESG as
an Informational RFC
* February 2010 "Simulation Presence Establishment" to the IESG as
Proposed Standard
* June 2010 "Primitive Object Format" to the IESG as Proposed
Standard
* June 2010 "Digital Asset Access" to the IESG as Proposed Standard
* June 2010 "Entity Identifiers" to the IESG as Proposed standard
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.