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

Joshua Bell <josh@lindenlab.com> Fri, 21 August 2009 00:12 UTC

Return-Path: <josh@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 8B4D23A677E for <ogpx@core3.amsl.com>; Thu, 20 Aug 2009 17:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.846
X-Spam-Level:
X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 BF33UsbGCyVI for <ogpx@core3.amsl.com>; Thu, 20 Aug 2009 17:12:19 -0700 (PDT)
Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 736E93A6949 for <ogpx@ietf.org>; Thu, 20 Aug 2009 17:12:19 -0700 (PDT)
Received: by ywh26 with SMTP id 26so406029ywh.5 for <ogpx@ietf.org>; Thu, 20 Aug 2009 17:12:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.91.143.18 with SMTP id v18mr375626agn.71.1250813541008; Thu, 20 Aug 2009 17:12:21 -0700 (PDT)
In-Reply-To: <20090820235051.GA21280@alinoe.com>
References: <f72742de0908191206m2a5b3e2fm4efcf0eaf471a758@mail.gmail.com> <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>
Date: Thu, 20 Aug 2009 17:12:20 -0700
Message-ID: <f72742de0908201712u635fa6a6ne6b286bcbca03499@mail.gmail.com>
From: Joshua Bell <josh@lindenlab.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary=0016e643559acac43a04719bb8d9
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: Fri, 21 Aug 2009 00:12:20 -0000

>
> However, if we want to make these limitations vanish then they
> cannot be used to DEFINE what (separate) world mean... Hence,
> the term becomes undefined and unclear (in the future).
>

Agreed (with this and preceding points)


>
> But-- there are things that define the "worlds" that do NOT
> want to change:
>
> * The administration is entirely different:
>  - A TOS only applies to one world.
>  - An Abuse Report only has effect within one virtual world.
>  - A ban by such an administration only affects their own world.


Here I think you're projecting from the way things are now too directly. As
you mention later on...

how will that affect the ideal solution? Because to the user those
> worlds will suddenly appear to be a single world.
>

Agreed, and your examples are good ones:


> What if a griefer logins in with LL, teleports to opengrid X and
> halts a sim there by running 10,000 scripts in attachments.
>
> Whose TOS determines if that is allowed? I'd say opengrid X's tos.
> And if opengrid X's TOS does not allow halting a sim, then where does
> an Abuse Report go to? I'd say... still to opengrid X's administration.
> And when they decide to ban this person, will it be possible to
> ban that (LL) account from opengrid X?
>

I don't think we know the answers to those questions yet. We need actual
implementers to speak up and describe how they'd want their systems to work
(on their own and with partners) and it should be within the working group's
charter to ensure the protocols support those administrative needs and
scenarios.

As a result, an agent domain shouldn't care less where someone
> wants to go, because they are never responsible, and therefore
> it should NOT be a matter of policy where someone can or cannot
> teleport while keeping their inventory: it should simply be
> possible, because the address is given in the LandMark.
>

I disagree with that. As a corporation providing tools to my employees, I
may dictate policy about where my employees may go using those tools - e.g.
they may teleport to and bring inventory with corporate content to partner
company worlds where the companies have signed NDAs, to have meetings to
discuss shared interests. It is entirely a matter of policy. This is no
different than having corporate firewalls that block access to certain sites
or content.

That may not be the primary use case (again, see the Web) but we can't
discard it.

Joshua