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

[Infinity Linden <[e-mail]>]

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
>
>