[ogpx] Tourist use case

Vaughn Deluca <vaughn.deluca@gmail.com> Fri, 16 October 2009 07:34 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 8DCB63A6989 for <ogpx@core3.amsl.com>; Fri, 16 Oct 2009 00:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.369
X-Spam-Level:
X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.229, 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 4CtZDCL6e9q2 for <ogpx@core3.amsl.com>; Fri, 16 Oct 2009 00:34:00 -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 1F5C13A67DA for <ogpx@ietf.org>; Fri, 16 Oct 2009 00:33:59 -0700 (PDT)
Received: by fxm18 with SMTP id 18so2063139fxm.37 for <ogpx@ietf.org>; Fri, 16 Oct 2009 00:34:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=F1fskYQANFMdDLocHZXT2BwDR7cY4lMP7YrAc/EkU4Q=; b=fviJPMSE4E/riA5KbfFnU3Eeig3ObuxndgLS+1vTrTXDB1Cwrz+czksNNI+SDHpaB0 m4JB+mklPqOhTX08usyAVMSui9tQPogYfP3Wtf7Tu3Z/RuG5OUiN1jPZ7UHPCH+7eJub lcqrDDXuLpzEflFfnN10YQ0RTd9w2WJ+nAwLI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=PHDDy7XIo3Xv10JLgXtyoWAG1MhL/WAK6aCnfqQuirXuJOXHDaQqrvrIphvdiFBQgn orq3/mf6vvzKyxbsXEO5Hj3L0HotBYGpG1ZEea5PZyGvD27ScjVWiaUYHSBmQFf/SZ/G 9lyTliel2ZjYZ8ONJK/msf2w7xAHWtVHuqkjk=
MIME-Version: 1.0
Received: by 10.204.16.88 with SMTP id n24mr976403bka.52.1255678442705; Fri, 16 Oct 2009 00:34:02 -0700 (PDT)
Date: Fri, 16 Oct 2009 09:34:02 +0200
Message-ID: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com>
From: Vaughn Deluca <vaughn.deluca@gmail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary=0003255597fe8793630476086b6b
Subject: [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 07:34:01 -0000

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_Designand/or to the VWRAP
wiki to document this possibility.

-Vaughn