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

Infinity Linden <infinity@lindenlab.com> Thu, 20 August 2009 21:06 UTC

Return-Path: <infinity@lindenlab.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05BF13A6F48 for <ogpx@core3.amsl.com>; Thu, 20 Aug 2009 14:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.827
X-Spam-Level:
X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+q7WrSx2VCD for <ogpx@core3.amsl.com>; Thu, 20 Aug 2009 14:06:49 -0700 (PDT)
Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 0A6C53A6DCB for <ogpx@ietf.org>; Thu, 20 Aug 2009 14:06:49 -0700 (PDT)
Received: by pzk4 with SMTP id 4so17633pzk.29 for <ogpx@ietf.org>; Thu, 20 Aug 2009 14:06:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.61.33 with SMTP id j33mr42970wfa.236.1250802410627; Thu, 20 Aug 2009 14:06:50 -0700 (PDT)
In-Reply-To: <e0b04bba0908201342hd17ce91qac0136124cd3a444@mail.gmail.com>
References: <f72742de0908191206m2a5b3e2fm4efcf0eaf471a758@mail.gmail.com> <e0b04bba0908191914h4837045ct777d2c63a30ddaf0@mail.gmail.com> <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <e0b04bba0908192003p34a367f2q4b99be3cf916cd72@mail.gmail.com> <20090820141835.GB28751@alinoe.com> <b8ef0a220908201101g3b448d8ck7b406fc481c56f8d@mail.gmail.com> <e0b04bba0908201342hd17ce91qac0136124cd3a444@mail.gmail.com>
Date: Thu, 20 Aug 2009 14:06:50 -0700
Message-ID: <3a880e2c0908201406j5a2995ccjb0ec529c22540189@mail.gmail.com>
From: Infinity Linden <infinity@lindenlab.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ogpx@ietf.org
Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2009 21:06:50 -0000

morgaine. flip back up in the thread where we talk about teleport and
landmarks. it's the message that begins with "and to your point about
landmarks and teleport"

i think we've also very clearly responded to the question, "do you
support interaction between virtual worlds in addition to interactions
within a single virtual world?" the answer is yes, because the
protocol defines the mechanism for communicating between hosts, not
the policy of "you should only communicate between hosts supporting
the same virtual world."

we do not explicitly call it out as being supported for the same
reason we do not explicitly say "you can only have red avatars on the
'red avatars only grid.'" that is, this is a POLICY decision. the same
protocol can carry information about the "red avatars only grid" as
well as other virtual worlds.

i would argue that intentionally calling out detailed use cases in the
charter; use cases that do not violate the wording of the charter, may
imply that use cases that are not detailed in the charter are
explicitly out of scope. Further, if we started enumerating use cases
in the charter, some might feel it was appropriate to introduce
prohibitions against other use cases in the protocol itself.

the intent of this group is to work on a protocol that will enable
open virtual worlds. the primary focus is to define the interaction
between components in the same virtual world and between external data
sources and the virtual world, but it does not preclude work on
world-to-world interactions where group participants believe such use
cases are important and practical. we do not explicitly call out this
focus because it is one of policy; our job is to define the protocol
and processing expectations, not tell deployers what features their
virtual world should support or who should be allowed to participate.

-cheers
-meadhbh


On Thu, Aug 20, 2009 at 1:42 PM, Morgaine<morgaine.dinova@googlemail.com> wrote:
> On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
> wrote, in answer to Carlo Wood:
>
>> and to your point about landmarks and teleport.
>>
>> teleporting between points in the virtual world, even if the origin
>> and destination are managed by different administrative domains has
>> always been part of the protocol proposal. we're not taking that out.
>
>
> That was not Carlo's point.  Carlo asked about landmarks and teleports
> between  virtual worlds, so stating that you're not taking them out from
> within a single world is not answering his question.
>
> The question being asked is a very simple one.  I do not understand why a
> clear answer is not being given.
>
> This is a matter of huge importance to the large number of SL-compatible
> open grids that already exist, with more appearing regularly.  It needs to
> be clearly stated whether mechanisms for interop between SL-compatible
> worlds will be within the scope of the OGPX group, or not.
>
> Defining our scope is our primary task at this time.  This question cannot
> be dodged.
>
>
> Morgaine.
>
>
>
>
>
>
>
> On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
> wrote:
>>
>> and to your point about landmarks and teleport.
>>
>> teleporting between points in the virtual world, even if the origin
>> and destination are managed by different administrative domains has
>> always been part of the protocol proposal. we're not taking that out.
>>
>> sharable landmarks haven't been explicitly mentioned, but we do
>> require a way to uniquely address locations in a virtual world
>> (otherwise how do you represent where you're teleporting too?) there's
>> been a lot of discussion about using URLs to uniquely identify
>> regions. If you added an offset from the middle of the region to the
>> region's URL, that would be the beginning of a landmark.
>>
>> hmm... i don't think we've explicitly mentioned that regions have a
>> bounding surface and an origin, but lemme put that on the list of
>> things to add to the spec.
>>
>> -cheers
>> -meadhbh
>>
>> On Thu, Aug 20, 2009 at 7:18 AM, Carlo Wood<carlo@alinoe.com> wrote:
>> >
>> > I think that what Morgaine is trying to say is that
>> > if Linden Lab's official (or hidden) policy is to NOT
>> > interop with other virtual worlds, then they are not
>> > the right party to trust when it comes to defining
>> > a protocol that most, if not all, other parties DO
>> > want to support interop.
>> >
>> > Since it seems, at this point, that the policy of
>> > LL will prohibit interop in the future between
>> > SL and other grids, there is a lack of trust right now;
>> > and as a result of that lack of trust, a very clear
>> > statement about the intent of the OGPX (as opposed to LL)
>> > about interop MUST be part of this draft.
>> >
>> > Personally, I will reject any protocol that doesn't
>> > make it a priority to concentrate on interoperability
>> > (such as sharing LM's and teleporting). So, instead
>> > of adding a paragraph that clearly states that the
>> > objective of OGPX is to not support interop, I'd rather
>> > see a paragraph added that clearly states that it
>> > IS to support interop.
>> >
>> > The keyword here being "clearly". That is certainly
>> > not the case at the moment.
>> >
>> > --
>> > Carlo Wood <carlo@alinoe.com>
>> > _______________________________________________
>> > ogpx mailing list
>> > ogpx@ietf.org
>> > https://www.ietf.org/mailman/listinfo/ogpx
>> >
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>