Re: [ogpx] Tourist use case

"Infinity Linden (Meadhbh Hamrick)" <infinity@lindenlab.com> Fri, 16 October 2009 08:16 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 A36B13A6993 for <ogpx@core3.amsl.com>; Fri, 16 Oct 2009 01:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 d1u-T77Cz1ar for <ogpx@core3.amsl.com>; Fri, 16 Oct 2009 01:16:53 -0700 (PDT)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 868F03A698E for <ogpx@ietf.org>; Fri, 16 Oct 2009 01:16:53 -0700 (PDT)
Received: by fg-out-1718.google.com with SMTP id 22so142323fge.13 for <ogpx@ietf.org>; Fri, 16 Oct 2009 01:16:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.239.139.161 with SMTP id t33mr99398hbt.115.1255681014171; Fri, 16 Oct 2009 01:16:54 -0700 (PDT)
In-Reply-To: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com>
References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com>
From: "Infinity Linden (Meadhbh Hamrick)" <infinity@lindenlab.com>
Date: Fri, 16 Oct 2009 01:16:34 -0700
Message-ID: <3a880e2c0910160116g2f4f394ag763822dbd35c80e1@mail.gmail.com>
To: Vaughn Deluca <vaughn.deluca@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 08:16:54 -0000

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.

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.

maybe we could define the various models in terms of who trusts whom
and how service endpoint addresses are resolved?

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.

in the "tourist model" you would have no trust, and the client is
responsible for resolving the address of all 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.

-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
>
>