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

[Morgaine <[e-mail]>]

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

> none of the implementers involved in developing the draft charter share
> your belief that *deployers MUST NOT use OGP* for interoperability between
> virtual worlds. rather, it would be a policy decision, and not a protocol
> decision.
>
>
Who wrote "*deployers MUST NOT use OGP"* which you then proceed to reject?
I did not, and straw men misrepresentations do not help in this discussion.

More importantly, you are avoiding the central point that *OGP cannot be
used* to provide interoperability between virtual worlds, because it does
not define this case.  It defines only how a separate region can be added to
a given virtual world, and not how two such worlds can interoperate.

The claim "*it would be a policy decision, and not a protocol decision*" is
false, because OGP does not provide for any alternative.


Morgaine.








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

> morgaine. i am not rejecting language that increases clarity, but
> language that enforces a false requirement. none of the implementers
> involved in developing the draft charter share your belief that
> deployers MUST NOT use OGP for interoperability between virtual
> worlds. rather, it would be a policy decision, and not a protocol
> decision.
>
>
> On Wed, Aug 19, 2009 at 7:14 PM, Morgaine<[e-mail]>
> wrote:
> > 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:
> >>
> >> 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
> >> >
> >> >
> >
> >
> > _______________________________________________
> > ogpx mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ogpx
> >
> >
>