WG Review: Virtual World Region Agent Protocol (vwrap)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A new IETF working group has been proposed in the Applications Area.  The
IESG has not made any determination as yet.  The following draft charter
was submitted, and is provided for informational purposes only.  Please
send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday,
September 22, 2009

Virtual World Region Agent Protocol (vwrap)
----------------------------------------------------------
Current Status: Proposed Working Group

Last Modified: 2009-09-03

Chairs:

TBD

Area and Area Directors:

Applications Area

Lisa Dusseault <lisa.dusseault@gmail.com>
Alexey Melnikov <alexey.melnikov@isode.com>

Responsible Area Director:

TBD

Mailing List:

ogpx@ietf.org
http://www.ietf.org/mailman/listinfo/ogpx

Description of Working Group:

The working group will define the Virtual World Region Agent Protocol
(VWRAP) for a collaborative 3-dimensional virtual environment. The
protocol permits users to interact as digital representations called
"avatars". An avatar exists in at most one location within a shared
virtual space. Conforming client applications use the protocol to
manipulate and move the user's avatar, create virtual objects,
interact with other users and their surroundings, consume and create
media and information from sources inside and outside their simulated
environment.

A virtual space can be partitioned into "regions" to facilitate the
computational and communication load balancing required to simulate
the virtual environment. A region provides the service environment in
which inhabitants and objects can interact. A region uniquely
represents a partition of the virtual space; they are not a mechanism
for load balancing by having multiple instances of the same space.
Different regions may be administered by different organizations. The
state of a virtual world is independent of the client applications
that access it and may persist between user sessions.

Within a VWRAP virtual environment, services may be deployed by
multiple organizations having varying policies and trust domains. The
VWRAP protocol will provide the mechanisms for these services to
interoperate, when permitted by policy. The working group may document
examples of policies applicable to a VWRAP environment.

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 region,

* an application-layer protocol for changing an avatar's position,
including moving between regions,

* format descriptions for objects and avatars, and

* an application-layer protocol for identifying entities, 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

The protocol should describe interaction semantics 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.

Goals and Milestones:


* February 2010 "Introduction and Goals" to the IESG as an
Informational RFC

* February 2010 "Abstract Type System for the Transmission of
Dynamic Structured Data" to the IESG as Proposed Standard

* June 2010 "Foundational Concepts and Transport Expectations" to
the IESG as Proposed Standard

* June 2010 "Client Application Launch Message" to the IESG as an
Informational RFC

* October 2010 "Trust Model and User Authentication" to the IESG as
Proposed Standard

* October 2010 "Voice and Text Communication Channel Establishment"
to the IESG as Proposed Standard

* February 2011 "Agent Presence Establishment" to the IESG as
Proposed Standard

* February 2011 "Region Description Format" to the IESG as Proposed
Standard

* June 2011 "Digital Asset Access" to the IESG as Proposed Standard

* June 2011 "Primitive Object Format" to the IESG as Proposed
Standard

* October 2011 "Avatar Format" to the IESG as Proposed Standard

* October 2011 "Entity Identifiers" to the IESG as Proposed Standard

* February 2012 "Time Sensitive Messages" to the IESG as Proposed
Standard
_______________________________________________

IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux