Difference between revisions of "VWRAP Charter"

From Second Life Wiki
Jump to navigation Jump to search
(Created page with 'Working Group Name:   Virtual Worlds Region Agent Protocol (VWRAP) Chairs:   TBD Area and Area Directors:   Applications Area   Lisa Dusseault <lisa.dusseault@gmail.com...')
 
(Cleaned up copy/pasted formatting a little.)
Line 1: Line 1:
Working Group Name:
'''Working Group Name:'''


  Virtual Worlds Region Agent Protocol (VWRAP)
  Virtual Worlds Region Agent Protocol (VWRAP)


Chairs:
'''Chairs:'''


  TBD
  TBD


Area and Area Directors:
'''Area and Area Directors:'''


  Applications Area
  ''Applications Area''\\
 
  Lisa Dusseault <lisa.dusseault@gmail.com>\\
  Lisa Dusseault <lisa.dusseault@gmail.com>
  Alexey Melnikov <alexey.melnikov@isode.com>
  Alexey Melnikov <alexey.melnikov@isode.com>


Responsible Area Director:
'''Responsible Area Director:'''


  TBD
  TBD


Mailing List:
'''Mailing List:'''


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


Description of Working Group:
'''Description of Working Group:'''


The working group will define the Virtual Worlds Region Agent Protocol
The working group will define the Virtual Worlds Region Agent Protocol (VWRAP) for collaborative 3-dimensional virtual  environment. The protocol permits users to interact as digital representations called "avatars". Avatars exist 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.
(VWRAP) for  collaborative 3-dimensional virtual  environment. The protocol permits users to interact as digital representations called "avatars". Avatars exist 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.


Adjacent points  in virtual spaces accessible by  this protocol may
Adjacent points  in virtual spaces 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  environments may consist  of regions administered  by distinct organizations. Regions provide the service endpoints for interacting with the inhabitants and objects they contain. Regions uniquely represent their partition of the virtual space (that is, they are not a "sharding" mechanism). The state of  a virtual  world is independent  of the  client applications that access it and may persist between user sessions.
be   explicitly   partitioned  into   "regions"   to  facilitate   the
computational  and communication load  balancing required  to simulate
the virtual  environment. Such virtual  environments may consist  of regions
administered  by distinct organizations. Regions provide the service endpoints for interacting with the inhabitants and objects they contain. Regions uniquely represent their partition of the virtual space (that is, they are not a "sharding" mechanism). The
state of  a virtual  world is independent  of the  client applications
that access it and may persist between user sessions.


Regions and  other services implemented according to  the specifications may
Regions and  other services implemented according to  the specifications may be deployed by separate  organizations with varying policies and trust domains.  The VWRAP  protocol 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.
be deployed by separate  organizations with varying policies and trust
domains.  The VWRAP  protocol 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.


Foundational components of the protocol include the publication of:
Foundational components of the protocol include the publication of:


  * an abstract  type system, suitable for  describing the application
* an abstract  type system, suitable for  describing the application    protocol in an implementation neutral manner,
    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,
  * a   security   model   describing  trust   relationships   between
* an application-layer  protocol for establishing  the user's avatar    in a region,
    participating entities,
* an application-layer  protocol for changing an avatar's position, including moving between regions, 
 
* format descriptions for objects and avatars, and
  * guidelines   for   the   use   of  existing   authentication   and
* an   application-layer  protocol   for  identifying   entities,  and    requesting information about them.
    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:
 
  * 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
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:
    an Informational RFC


  * February 2010  "Simulation Presence Establishment" to  the IESG as
* http://tools.ietf.org/html/draft-hamrick-ogp-intro
    Proposed Standard
* 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


  * June  2010  "Primitive Object  Format"  to  the  IESG as  Proposed
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
    Standard
and  will  define  the use  of  HTTP(S)  as  a transport  of  protocol messages.


  * June 2010 "Digital Asset Access" to the IESG as Proposed Standard
'''Goals and Milestones:'''


  * June 2010 "Entity Identifiers" to the IESG as Proposed standard
* 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

Revision as of 21:34, 1 October 2009

Working Group Name:

  Virtual Worlds Region Agent Protocol (VWRAP)

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 Worlds Region Agent Protocol (VWRAP) for collaborative 3-dimensional virtual  environment. The protocol permits users to interact as digital representations called "avatars". Avatars exist 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.

Adjacent points  in virtual spaces 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  environments may consist  of regions administered  by distinct organizations. Regions provide the service endpoints for interacting with the inhabitants and objects they contain. Regions uniquely represent their partition of the virtual space (that is, they are not a "sharding" mechanism). The state of  a virtual  world is independent  of the  client applications that access it and may persist between user sessions.

Regions and  other services implemented according to  the specifications may be deployed by separate  organizations with varying policies and trust domains.  The VWRAP  protocol 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.

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:

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:

  • 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