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

Carlo Wood <carlo@alinoe.com> Sat, 22 August 2009 02:12 UTC

Return-Path: <carlo@alinoe.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 717DD3A69F0 for <ogpx@core3.amsl.com>; Fri, 21 Aug 2009 19:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
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 hYRa2eYaykYJ for <ogpx@core3.amsl.com>; Fri, 21 Aug 2009 19:12:34 -0700 (PDT)
Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id 09F163A69BD for <ogpx@ietf.org>; Fri, 21 Aug 2009 19:12:33 -0700 (PDT)
Received: from edge05.upc.biz ([192.168.13.212]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090822021237.KFKR21098.viefep19-int.chello.at@edge05.upc.biz>; Sat, 22 Aug 2009 04:12:37 +0200
Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id XECa1c02X0FlQed05ECbUf; Sat, 22 Aug 2009 04:12:37 +0200
X-SourceIP: 77.250.43.12
Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from <carlo@alinoe.com>) id 1Meg6d-0000Gb-H2; Sat, 22 Aug 2009 04:13:23 +0200
Date: Sat, 22 Aug 2009 04:13:23 +0200
From: Carlo Wood <carlo@alinoe.com>
To: Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
Message-ID: <20090822021323.GC29557@alinoe.com>
References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <e0b04bba0908192003p34a367f2q4b99be3cf916cd72@mail.gmail.com> <20090820141835.GB28751@alinoe.com> <b8ef0a220908201101g3b448d8ck7b406fc481c56f8d@mail.gmail.com> <e0b04bba0908201342hd17ce91qac0136124cd3a444@mail.gmail.com> <f72742de0908201426m6b8feac9v57e9ef1cd73e5c06@mail.gmail.com> <f72742de0908201600y46311454la8db52c4be1b18dc@mail.gmail.com> <b8ef0a220908201609m1c77be2n3d499b7da20fec5a@mail.gmail.com> <20090820235051.GA21280@alinoe.com> <b8ef0a220908201716o67740c2emde12dbc29c73608c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b8ef0a220908201716o67740c2emde12dbc29c73608c@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
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: Sat, 22 Aug 2009 02:12:35 -0000

On Thu, Aug 20, 2009 at 05:16:09PM -0700, Meadhbh Siobhan wrote:
[deleted what I agree with, or just needs no comment]
> one of the objectives of the OGP protocol is to allow a virtual world
> to be constructed from regions, agent hosts and asset servers from
> different administrative domains. in order to do that, one of the

Okaaayy... now you're using "a virtual world" again for a collection
of regions run by *different* administrations, while I was proposing
to keep the fact that currently all different (Second Life like)
worlds are run by different administrations. But... I'm not in a hurry
to have the meaning of "world" clearly defined, the only thing
that is important for me is the intent of the people on this mailinglist
and those working for Linden Lab in particular ;)

> things we think we need to do is to have a scheme by which regions are
> unambiguously identified with a URL. we don't currently list
> "unambiguous landmarks" in the charter because we don't talk about
> landmarks at all in the charter. it's also unclear whether a landmark
> format will be defined as part of this effort.

Okay. Note that I only talked about landmarks as example with
as goal to get clarity between us, here and now; followed by
a search for correct wording of paragraphs. I never thought that
"landmark" had to be added to the charter in said paragraphs.

> so i guess what i'm saying is that if we listed "a format for
> unambiguous landmarks" in the charter, shouldn't we also list other
> Second-Life-like features like the C/M/T permissions system? the
> unambiguous URL representing a region is required for proper operation
> of teleport, which IS in scope, but the unambiguous landmark format is
> not required as landmarks are concepts more appropriately manipulated
> by client applications.

I don't think that even unambiguous URL needs to be mentioned.

> so, is it enough to add verbiage to the charter indicating that the
> protocol requires regions to be addressable by unambiguous URLs, but
> not explicitly constrain their use in the charter?

Again, it was just a down-to-earth example, not suitable for the
charter.

The problem that we're trying to tackle, that I was trying to tackle,
is this (going to formulate this VERY explicit, almost embarrashingly so ;).

There are people on this list that run (currently) small grids
with (obviously) opensim servers. They would very much like it
to be possible for people in SL to teleport directly to their
grid (and back), preferably (but not necessarily) while keeping
access to their inventory and keeping there appearance intact.
The reason they want that is simply: the more seamless that is
possible, the more people will come; and more people is Good(tm).

The likeliness that this is going to happen for them in the
future depends mainly on two things:

1) Will the protocol support it at all
2) Will Linden Lab grant those grids whatever access they need

Point 2 is policy, and has nothing to do with the efforts of
this group.

It is my understanding that Morgaine after reading the charter
lost all hope to achieve this goal of interoperability, and
concluded that with the given formulation (as proposed by you)
*apparently* Linden Lab wasn't interested the slightest to
have this kind of interoperability with any of the current
opensim pioneers; which led to some emotions and rather direct
attempt to let you "confess" that LL wasn't interested, and
when you said "that doesn't belong in the charter" that was
interpreted as "we have a hidden agenda".

At this point I believe that all of that has been a misunderstanding,
that is directly caused by the confusion that exists about what
"virtual world" means. Morgaine (and me) interpreted "world"
as "run by a different administration", while you seem use the
word for "all regions that one can teleport to". Obviously,
the latter says NOTHING about the intent of Linden Lab to
interoperate with any opensim grids :p, and I suppose you
don't have to tell us if they do. But it's good to know now
that the protocol will support this.

We're not there yet though:

The reason that two grids (or virtual worlds, or different
administrations) might decide not to allow teleporting is
probably for a large part going to be determined by (not) trusting.

Therefore, in order to achieve the goal of teleporting between
Second Life and the smaller opensim grids, we'd like a protocol
that demands as LITTLE trust as possible.

For example, if the protocol would define something like:
- in order to teleport, grid A logs into auth services of grid B
once and then has access the everything after that (including
allowing to teleport); then teleporting would be impossible unless
grid B would trust grid A completely.

Other shemes are thinkable that require less trust. One result
of a "hidden agenda" could be that the protocol would be designed
such that ANY operability would only be possible with FULL access
to everything, and therefore full trust, and therefore (in practise)
no interoperability at all (except between large companies with
lawyers and contracts-- not the little pioneers that run opensim
grids now).

-- 
Carlo Wood <carlo@alinoe.com>