[scrm-wg] FW: [ogpx] WG Action: Virtual World Region Agent Protocol (vwrap)

[Romascanu, Dan (Dan)]

-----Original Message-----
From: ogpx-bounces at ietf.org [mailto:ogpx-bounces at ietf.org] On Behalf Of
IESG Secretary
Sent: Tuesday, September 29, 2009 7:30 PM
To: ietf-announce at ietf.org
Cc: barryleiba at computer.org; ogpx at ietf.org
Subject: [ogpx] WG Action: Virtual World Region Agent Protocol (vwrap)

A new IETF working group has been formed in the Applications Area.  For
additional information, please contact the Area Directors or the WG
Chairs.

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

Chairs:
  Joshua Bell (josh at lindenlab.com)
  Barry Leiba (barryleiba at computer.org)

Applications Area Directors:
  Lisa Dusseault (lisa.dusseault at gmail.com)
  Alexey Melnikov (alexey.melnikov at isode.com)

Applications Area Advisor:
  Alexey Melnikov (alexey.melnikov at isode.com)

Mailing Lists:
  General Discussion: ogpx at ietf.org
  To Subscribe: ogpx-request at ietf.org
  In Body: subscribe
  Archive:
http://www.ietf.org/mail-archive/web/ogpx/current/maillist.html


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:

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

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

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

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

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

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

Feb 2011  "Agent Presence Establishment" to the IESG as Proposed 
          Standard

Feb 2011  "Region Description Format" to the IESG as Proposed Standard

Jun 2011  "Digital Asset Access" to the IESG as Proposed Standard

Jun 2011  "Primitive Object Format" to the IESG as Proposed Standard

Oct 2011  "Avatar Format" to the IESG as Proposed Standard

Oct 2011  "Entity Identifiers" to the IESG as Proposed Standard

Feb 2012  "Time Sensitive Messages" to the IESG as Proposed Standard
_______________________________________________
ogpx mailing list
ogpx at ietf.org
https://www.ietf.org/mailman/listinfo/ogpx