Re: [ogpx] WG Action: Virtual World Region Agent Protocol (vwrap)

Congratulations, everyone! :-)

\o/

Morgaine.

=============================================

On Tue, Sep 29, 2009 at 6:30 PM, IESG Secretary <iesg-secretary@ietf.org>wrote:

> 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@lindenlab.com)
>  Barry Leiba (barryleiba@computer.org)
>
> Applications Area Directors:
>  Lisa Dusseault (lisa.dusseault@gmail.com)
>  Alexey Melnikov (alexey.melnikov@isode.com)
>
> Applications Area Advisor:
>  Alexey Melnikov (alexey.melnikov@isode.com)
>
> Mailing Lists:
>  General Discussion: ogpx@ietf.org
>  To Subscribe: ogpx-request@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@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>