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

David W Levine <dwl@us.ibm.com> Fri, 21 August 2009 16:01 UTC

Return-Path: <dwl@us.ibm.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 778FE3A6D2A; Fri, 21 Aug 2009 09:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.645
X-Spam-Level:
X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 CCdD6wlI688r; Fri, 21 Aug 2009 09:01:15 -0700 (PDT)
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id D7B6B28C1F4; Fri, 21 Aug 2009 09:01:14 -0700 (PDT)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7LG5H3C020000; Fri, 21 Aug 2009 12:05:17 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7LG1CdU161314; Fri, 21 Aug 2009 12:01:12 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7LG1CSE024793; Fri, 21 Aug 2009 12:01:12 -0400
Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7LG18x0024395; Fri, 21 Aug 2009 12:01:09 -0400
In-Reply-To: <3a880e2c0908210733v5e2b53a0x889f0f564a573461@mail.gmail.com>
References: <e0b04bba0908191914h4837045ct777d2c63a30ddaf0@mail.gmail.com> <e0b04bba0908201342hd17ce91qac0136124cd3a444@mail.gmail.com> <f72742de0908201426m6b8feac9v57e9ef1cd73e5c06@mail.gmail.com> <f72742de0908201600y46311454la8db52c4be1b18dc@mail.gmail.com> <b8ef0a220908201609m1c77be2n3d499b7da20fec5a@mail.gmail.com> <20090820235051.GA21280@alinoe.com> <20090820235657.GB21280@alinoe.com> <f72742de0908201716i6f5adc29o18313a6e55318a7f@mail.gmail.com> <b8ef0a220908201725l5b9d20d6qcb2921d3547277db@mail.gmail.com> <OF048CEB61.3E58783F-ON85257619.004946AA-85257619.004C6C7B@us.ibm.com> <3a880e2c0908210733v5e2b53a0x889f0f564a573461@mail.gmail.com>
To: Infinity Linden <infinity@lindenlab.com>
MIME-Version: 1.0
X-KeepSent: BD0DCC89:9430E59E-85257619:0056B4DE; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
Message-ID: <OFBD0DCC89.9430E59E-ON85257619.0056B4DE-85257619.0057FD23@us.ibm.com>
From: David W Levine <dwl@us.ibm.com>
Date: Fri, 21 Aug 2009 12:01:05 -0400
X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 08/21/2009 12:01:08, Serialize complete at 08/21/2009 12:01:08
Content-Type: multipart/alternative; boundary="=_alternative 0057FD2285257619_="
Cc: Meadhbh Siobhan <meadhbh.siobhan@gmail.com>, ogpx@ietf.org, ogpx-bounces@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: Fri, 21 Aug 2009 16:01:16 -0000

Fair enough. So.. Let me try an even crisper wording. 

>>>
Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains. 

The OGPX protocols will provide the mechanisms for these services to 
interoperate,
when permitted by policy and shared trust domains. 
>>> 





Infinity Linden <infinity@lindenlab.com> 
08/21/2009 10:33 AM

To
David W Levine/Watson/IBM@IBMUS
cc
Meadhbh Siobhan <meadhbh.siobhan@gmail.com>om>, ogpx-bounces@ietf.org, 
ogpx@ietf.org
Subject
Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision






i would argue that we shouldn't be introducing a term into the charter
that we can't define. the term "virtual world" is more appropriate for
the MMOX effort. OGP has an intentionally loose definition of the term
"virtual world," and it means (roughly) "the set of places you can
teleport or walk to." this is NOT a feature that is defined by
protocol, but by trust.

there is absolutely nothing in the protocol that requires region
operator 'A' to trust region operator 'B' or agent domain operator
'C'. we do, however, define message formats and techniques to carry
artifacts of this trust. there is nothing in the PROTOCOL that defines
who trusts who.

this is EXACTLY the issue that torpedoed PEM and led to MOSS and later
S/MIME. the protocols MUST NOT define trust relationships for
operators. they MUST be deferred to deployers. because we cannot
define trust in the protocol, it is inappropriate to insert language
in the charter based on that assumption.

if you define the term "virtual world" as "the set of places you can
teleport to" then this term CAN'T have meaning because it depends on
local policy that is out of the control of the protocol specifiers.
this is why the term is not used. this is why we define the protocol
in terms of things we CAN make some assumptions about: the required
parties in a protocol transaction. in the case of teleport, this
includes the originating region, the target region and the agent
domain.

this is the moral equivalent to saying the following in the ssh
specification "every ssh server must define a user called 'root', and
that user must have full permissions over the server." as it happens,
a great number of ssh servers have a superuser named root, but some
don't. there's no reason to define it in the protocol because it's a
matter of local policy.

when we say "there are things called virtual worlds, and they're
defined as the set of all places you can teleport to," what does that
give us? from a protocol perspective, it gives us nothing, because we
will never user it.

as part of the introduction, we may want to say "this protocol can be
used to construct a set of connected regions that MAY be rendered by a
client application in a form that appears as a virtual world." but
this gets us what?

-cheers
-meadhbh

On Fri, Aug 21, 2009 at 6:54 AM, David W Levine<dwl@us.ibm.com> wrote:
>
> I am going to suggest inserting a very  concise paragraph after the 
second
> paragraph.
>
>>>> Insert
>
> Regions and Services implemented according to the specifications may be
> assembled into
> multiple virtual worlds. These worlds may embody multiple domains of 
trust.
> Deployed virtual
> worlds may support different policies of use. Constrained by these 
policies,
> the protocols will
> permit interoperation across OGPX  virtual worlds with compatible 
policies
> and trust models.
>
>>>> end insert
>
> I poersonally think this is implicit, but making it explicit doesn't 
hurt.
>
> I think this preserves the separation of concern we desire. Mechanisms 
are
> defined at the
> protocol level. Policy is defined separate from mechanism. It should be
> possible to deploy
> everything from highly constrained walled gardens to very open grids. 
The
> degree of
> avatar, agent, service and digital goods flow between specific virtual
> worlds will vary according
> to the policies, and trust boundaries established by deployers. Nothing 
in
> the specifications
> dictates specific policies
>
> This follows the existing  practices of the web and internet.The core
> protocols
> and formats of the internet permit interoperation, but deployers 
routinely
> constrain
> the accessibility and reach of services based on policy.
>
>
> - David W. Levine
> ~ Zha Ewry (ISL)
>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>