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

[Morgaine <[e-mail]>]

Joshua,

This latest draft of the charter reads quite well, but it seems to be
missing an opening paragraph without which it is easy to misinterpret the
purpose of the workgroup and of the protocol.  That opening paragraph should
be something like this:

"This following work is aimed at defining a protocol for the integration of
individual regions into a single virtual world, and providing client
applications with access to these.  Interoperation between such a virtual
world and any other virtual world is outside of the scope of this protocol."


Without this introduction, it is easy to mistake OGPX for a VW interop
group.

After all, it follows nearly two years of discussions about interop between
worlds in the Architecture Working Group within Second Life, and it follows
6 months of work in the IETF MMOX group which was specifically targetting
interoperation between virtual worlds, and it follows a MMOX BoF in which
numerous participants (of which Lindens were only one) discussed interop
between worlds, and finally, it follows a decision to partition off a new
workgroup from MMOX so that its scope can be limited to interoperation
between SL-like worlds alone.

As it turns out, this new workgroup is not intending to address interop
between SL-like worlds at all, but only to integrate individual regions into
an existing world, which is extremely different.  As the new draft charter
describes well, OGPX is dedicated to growing walled gardens by addition of
new regions, and it is not concerned with interoperation between such walled
gardens.

That should be made immediately clear in the introduction --- it is I think
this group's main statement of scope, and I assume that our Area Directors
will encourage such clarity.  I recommend my opening paragraph above to
accomplish this.

On a more general note ...

In addition to making the above clear, what's going to be done about interop
between SL-like worlds?  There are already many SL-compatible Opensim-based
grids, and they currently believe that Linden Lab is defining OGP to
interoperate with them.  Clearly they are badly mistaken, but their need for
interop still remains.


Morgaine.





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

On Wed, Aug 19, 2009 at 8:06 PM, Joshua Bell<[e-mail]> wrote:
> 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
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>