[ogpx] OGPX WG draft charter, 2009-08-19 revision

[Joshua Bell <[e-mail]>]

Howdy, folks.

Please find attached the latest draft of the proposed OGPX working
group charter. It incorporates feedback from many list and
face-to-face meeting participants. I think it's much closer to a
document that reflects the group consensus. There are a few points, we
may want to comment on separately:

1. The Name. We're still using the name OGPX in this draft. There has
been much discussion about other names, but we're not at consensus
yet. When we have agreement on a new name, it's easy enough to do a
search and replace in the document before submitting it for
consideration.

2. The Mailing List. Since we're not at consensus on a name yet, I
recommend we continue to us the [e-mail] mailing list for the
time being. When we've selected a new name, and after a working group
is approved, we can request a mailing list with the same name as the
working group. Again, we can just simply do a search and replace after
we have consensus on the name.

3. Description of the Group's Work. The first two paragraphs in the
description outline the scope of the working group's efforts. The
intent is to briefly describe the group's work to people outside the
working group and to "draw a line in the sand" regarding the
group's focus (so we don't experience scope creep.) This revision
defines terms as they are introduced. It was thought that this
approach made for easier reading than having a separate glossary
section.

4. Previous Work. Several people have commented that the charter
should be explicit regarding what documents we think we're starting
from. There is a list of related internet drafts in this draft to meet
this requirement.

5. Selecting a Transport. We added verbiage supporting the idea that
OGP is transport agnostic, and that we should somewhere describe how
OGP uses it's transports and which features it needs. It also lists
HTTP(S) as the protocol of choice for OGP messages.

6. Objectives. There is a list of specific objectives, defined in
terms of the problem domain. This list is thought to be roughly
complete at the moment. The process of adding objectives or
refactoring them after working group formation is non-trivial, but not
impossible. But, we should have agreement that the objectives are an
honest assessment of what we think we need to be working on.

7. Milestone Dates. The dates listed below may be a touch optimistic.
They may need to be massaged before the charter is submitted to the
IESG.

Here is the draft charter...


Working Group Name:

 Open Grid Protocol (OGPX)

Chairs:

 TBD

Area and Area Directors:

 Applications Area

 Lisa Dusseault <[e-mail]>
 Alexey Melnikov <[e-mail]>

Responsible Area Director:

 TBD

Mailing List:

 [e-mail]
 http://www.ietf.org/mailman/listinfo/ogpx

Description of Working Group:

The working group will define the Open Grid Protocol (OGP) 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  the 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
the 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 the  virtual world is independent  of the client
applications that access it and may persist between user sessions.

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 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 the
   virtual world,

 * an  application-layer  protocol  for  moving  a  user's  avatar  between
   adjacent and remote locations in the 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.

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