Re: [ogpx] Tourist use case
Vaughn Deluca <vaughn.deluca@gmail.com> Fri, 16 October 2009 10:16 UTC
Return-Path: <vaughn.deluca@gmail.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 363723A6859 for <ogpx@core3.amsl.com>;
Fri, 16 Oct 2009 03:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200,
BAYES_00=-2.599, 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 CboMuSK460zh for
<ogpx@core3.amsl.com>; Fri, 16 Oct 2009 03:16:51 -0700 (PDT)
Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com
[209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 2DF693A69CC for
<ogpx@ietf.org>; Fri, 16 Oct 2009 03:16:51 -0700 (PDT)
Received: by fxm18 with SMTP id 18so2209902fxm.37 for <ogpx@ietf.org>;
Fri, 16 Oct 2009 03:16:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type;
bh=9629xpNAoM52XRITkcHZ0ZrRTpcDsPcNWJ6J5J+/IxM=;
b=LnJ8CX/JkY6T+W1ln1JNghnJ0GJf24Q5hSR0VSYhh4gTaMJSEUdGCmBTAyd7JcUUOp
frmMkPuQpuToVwdXsnx6dQFOBOvGoxh52UZ04mjmeyHcjbvWj9rqqVgzQTjf/xejH27h
CR6aeqcopMiZm44SL3uqTXezSlgbxGSofeu/w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
b=B67YD5E2htLQSvMVBBAt92bNRhWlUiJg2NysCwXpLXAiR28+2hc6+dFVBvRdRb6NWh
IHW7yhidzFpXx8vsM9CsDoZo0F7klDl5ZOHOudL/RAyYZWQ75K577MEW/opE3tuTmcql
zGCygEyCeQGU4WwwXEW5AgQoPmnYRSqXjc0wQ=
MIME-Version: 1.0
Received: by 10.204.155.79 with SMTP id r15mr1115652bkw.142.1255688211645;
Fri, 16 Oct 2009 03:16:51 -0700 (PDT)
In-Reply-To: <3a880e2c0910160116g2f4f394ag763822dbd35c80e1@mail.gmail.com>
References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com>
<3a880e2c0910160116g2f4f394ag763822dbd35c80e1@mail.gmail.com>
Date: Fri, 16 Oct 2009 12:16:51 +0200
Message-ID: <9b8a8de40910160316w364a2695t8e8dd8992e0b524f@mail.gmail.com>
From: Vaughn Deluca <vaughn.deluca@gmail.com>
To: "Infinity Linden (Meadhbh Hamrick)" <infinity@lindenlab.com>
Content-Type: multipart/alternative; boundary=0015175d07d2cdc62404760ab1e7
Cc: ogpx@ietf.org
Subject: Re: [ogpx] Tourist use case
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, 16 Oct 2009 10:16:53 -0000
On Fri, Oct 16, 2009 at 10:16 AM, Infinity Linden (Meadhbh Hamrick) < infinity@lindenlab.com> wrote: > i had assumed that the "tourist model" also implied that the client > assumes no transitive trust on behalf of the agent domain, or includes > the agent domain as part of a client implementation. > Not in the most basic case, Morgaine indeed defined it that way, but i feel that that is a more complicated use case, and we would benefit from treating it separately from the more basic case. > also. we should tighten up the language. i would argue that from the > client's perspective, teleporting between Sim 1 and Sim 2 requires no > prior arrangement (for the client.) it does, however, require the > agent domain to trust both sims. > Yes, but note that the asset service will have its own policy in this model, so the needed reasons to distrust the destination region are limited. One obvious reason would be that promises were made to the user to protect the avatar from exposure to adult material. But if the user indicates is has no problem, i would think in the majority of cases the Agent service can trust the region. In the worst case the avatar would have to be ruthed because the avatar shape can not be exported. > maybe we could define the various models in terms of who trusts whom > and how service endpoint addresses are resolved? > Yes, i like that suggestion. > so the "second life" model [1] would essentially be that the client > and the agent domain trust each other, and the agent domain and all of > the region domains trust each other. service endpoints for agent > services are given to the client by the agent domain, while region > service are given to the client by the agent domain or the region > domain. > Yes, although you specify a bit more trust that is needed in my view because you do not allow assets services there own policy, distinct from the agent service policy, but if you want to make a blanket statement this is correct. > > in the "tourist model" you would have no trust, and the client is > responsible for resolving the address of all services. No, you loose me here. The client *does* trust the agent service, there is no difference here with the SL case. The client logs in to an AD, and by definition trusts that service. that AD has its own asset service, just like in the SL case, and the user can use those assets (as far as the Asset service allows the assets to go out to other domains). In addition to using its own asset services the Agent service can use other Asset services. > in the "cable beach" model, you have the same trust as the "second > life" model, but you bring the asset service into it's own domain > which is explicitly trusted by the agent domain, the region domains > and the client. asset service endpoints are resolved by the client. > I did not yet look in detail at cable beach, but I clearly should, since this sounds a lot like what i was thinking of. However, I do not think its needed to put the asset service in its own domain, because by definition a domain is under a different administration, and in many cases the asset service will be in some domain. So the critical point is that the asset service in some domain exposes an interface to the world so its assets *can* be used, if by anybody if policy allows it. -Vaughn > -cheers > -meadhbh > > -- > infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" > http://wiki.secondlife.com/wiki/User:Infinity_Linden > > > > On Fri, Oct 16, 2009 at 00:34, Vaughn Deluca <vaughn.deluca@gmail.com> > wrote: > > The "tourist use case" has been brought up several times, but the concept > is > > not always used in the same way, and needs to be more precisely defined. > > Morgaines original definition of the "Free Worlds Tourist use case" in > > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html > > mentions two characteristics: > > 1. Travel requires no prior arrangement. > > 2. Your avatar is defined by you, not by the target worlds, and it > appears > > in those worlds with no prior arrangement. > > Point 1 is only dependent the policies of the users AD as well as that of > > the destination region. It is not dependent on the protocol, so in > principle > > solved. > > The second point is actually extending the SL use case beyond what is in > my > > view needed for a basic tourist model (and that is why the post was in > the > > mmox list). In my view a basic tourist use case has two main > > characteristics: > > 1. Travel requires no prior arrangement. > > 2. Agent domains can use external asset services > > Point 2 requires that assets services expose an interface (in the current > > ogp description of the AD that is not the case). > > Note that this models does *not* assumes that all assets in a services > > should be useable by the agent in all domains, but only that an interface > is > > available so an asset service in one domain can be contacted by another > AD. > > I think exposing the asset service interface directly is essential for > > meaningful interop. I think it would benefit the discussion if some > > diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design > > and/or to the VWRAP wiki to document this possibility. > > -Vaughn > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > >
- [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Tourist use case Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Meadhbh Hamrick
- Re: [ogpx] Tourist use case Meadhbh Hamrick
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Sean Hennessee
- Re: [ogpx] Tourist use case Joshua Bell
- Re: [ogpx] Tourist use case Meadhbh Hamrick
- Re: [ogpx] Tourist use case Meadhbh Hamrick
- Re: [ogpx] Tourist use case Charles Krinke
- Re: [ogpx] Tourist use case Charles Krinke
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Tourist use case Lawson English
- Re: [ogpx] Tourist use case Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Tourist use case Vaughn Deluca
- [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Lawson English
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case David W Levine
- Re: [ogpx] Tourist use case Vaughn Deluca
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Lawson English
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Carlo Wood
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Joshua Bell
- Re: [ogpx] Tourist use case Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case dyerbrookme@juno.com
- Re: [ogpx] Tourist use case Carlo Wood
- Re: [ogpx] Tourist use case Morgaine
- Re: [ogpx] Tourist use case Han Sontse
- Re: [ogpx] Tourist use case Han Sontse
- Re: [ogpx] Tourist use case Carlo Wood
- Re: [ogpx] Tourist use case Morgaine