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

[Morgaine <[e-mail]>]

Infinity, Linden Lab's interoperation with OSgrid is a matter of company *
policy* which is not our business here.  We are involved only with defining
protocols, which are *mechanisms* that can be used to implement many
different policies.  You are suggesting that OGP provides no barrier to
interop apart from your own local policy, when this is clearly not true.

The OGP protocol is not being defined to permit any kind of interop between
virtual worlds *at all*.  As Joshua's latest charter describes clearly, it
is concerned only with the addition of single regions to a given virtual
world.  It does not address interop between two or more such virtual worlds
in any shape or form.

Your response therefore completely misses the point that OGP does not
provide any means for interop between worlds whatsoever, even when the world
operators desire it.  It is not a protocol for interoperation between
virtual worlds, even when these worlds are identical in architecture.  Being
clear is important in standards work.

Your last comment rejecting clarity in language escapes me at this time.

If OGPX does not intend to address interop between virtual worlds, that's a
conscious decision and is not something to hide.  A protocol that grows a
world by adding regions is still a useful protocol, despite providing no
interop between worlds.  Stating the goal clearly is to everyone's benefit.


Morgaine.








On Thu, Aug 20, 2009 at 1:38 AM, Infinity Linden <[e-mail]>wrote;wrote:

> hunh? if it makes sense for Linden to interoperate with OSGrid, and
> both parties want to do it, i think it will happen irrespective of the
> language in the charter. this work is not intended to be exclusively
> "the protocol that people use to communicate with Second Life." it is
> the protocol systems use to participate in a virtual world simulation.
> it makes no statement about which virtual world participating systems
> interact with.
>
> by their nature, open protocols do not limit participation to fixed
> systems. adding language to the charter that implies this is the case
> is inappropriate and inaccurate.
>
> On Wed, Aug 19, 2009 at 5:05 PM, Morgaine<[e-mail]>
> wrote:
> > 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
> >>
> >
> >
> > _______________________________________________
> > ogpx mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ogpx
> >
> >
>