Re: [ogpx] where does VWRAP fit?

Meadhbh Siobhan <meadhbh.siobhan@gmail.com> Fri, 11 September 2009 17:03 UTC

Return-Path: <meadhbh.siobhan@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 A00783A6895 for <ogpx@core3.amsl.com>; Fri, 11 Sep 2009 10:03:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level:
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599]
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 y53ybadPx4iS for <ogpx@core3.amsl.com>; Fri, 11 Sep 2009 10:03:19 -0700 (PDT)
Received: from mail-pz0-f190.google.com (mail-pz0-f190.google.com [209.85.222.190]) by core3.amsl.com (Postfix) with ESMTP id 2017E3A6892 for <ogpx@ietf.org>; Fri, 11 Sep 2009 10:03:19 -0700 (PDT)
Received: by pzk28 with SMTP id 28so1034308pzk.20 for <ogpx@ietf.org>; Fri, 11 Sep 2009 10:03:54 -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 :content-transfer-encoding; bh=D0q7V25QyGjqRBL1RTiJXdBqVHhv4AuIbrYXjYbXME0=; b=yForryr17iyIK0owXTT3WZHVJTeK34z5EI5QLdRIDNWrVJ0fxOvpYWRipCm0Ma/D8j 9oVCup9XPEXGfciRmDuyPeKMXQkd41rwwX0vsV7FWVVfwrwTS/1K96abTzy4/IGhNh+y AhWWku3JwlB4rq/LK7QWigmYlEQ4KXWajGh38=
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:content-transfer-encoding; b=KatXjzBmzsazUxm5uB6AwX/AuPYV7IIVI2I0fc7VjONTRagRtLpjY8h0UpWj8y8+Nj vmrvOB3QSwjFh+pvVZlK3krFlY0J0At3Ow6jJYe9IfjmMe+w/5YadD0CwTW4HJmpST/h PFQBK0shx/zAYB4SWXG4dncUK3UHkkOUHR36o=
MIME-Version: 1.0
Received: by 10.114.2.3 with SMTP id 3mr5819139wab.109.1252688633906; Fri, 11 Sep 2009 10:03:53 -0700 (PDT)
In-Reply-To: <303485.21843.qm@web82605.mail.mud.yahoo.com>
References: <382d73da0909060904h7b666bdqc40ce151ce0d241a@mail.gmail.com> <e0b04bba0909110036r3337f945tb93955fbac0c5798@mail.gmail.com> <303485.21843.qm@web82605.mail.mud.yahoo.com>
Date: Fri, 11 Sep 2009 10:03:53 -0700
Message-ID: <b8ef0a220909111003g434adb01t4d79ce16c678796c@mail.gmail.com>
From: Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
To: Charles Krinke <cfk@pacbell.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ogpx@ietf.org
Subject: Re: [ogpx] where does VWRAP fit?
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, 11 Sep 2009 17:03:20 -0000

good points, all.

i like to look at it as a trust issue.

if there are two "countries" that trust each other... like they've
signed agreements like "i promise not to rip off your users' content"
and "i promise not to grief your services" then you could create a
client application that knows how to work with both, and present a
pretty compelling experience. you could move from "country" to
"country" and still be able to chat with other people in the world,
and you should be able to carry your digital assets across country
borders and (subject to the permissions on the virtual land you're on)
rez objects. this is the use case i think we at linden are focused on.

but if i (as a user) have a trust relationship with two different
"countries," and they don't have a trust relationship between each
other... i can run a client that knows how to leverage these
relationships; it could be relatively seamless and could make it
appear as if entities from the two "countries" appear as the same
space. but because they are fundamentally different "countries" and
don't have agreements with each other about the use of services or the
protection of content, it might be hard to rez an object from one
country in another country's land. it _may_ still be possible if the
permissions were set right; you could download it from country A to
the client and then have the client upload it to country B, but that
won't work in all cases and assets will find it hard to interact with
other assets across country boundaries. this is a use case that works
well for adhocracy, and is the use case a number of peeps working on
hypergrid have expressed an interest in.

one of the motivations for the use of our terminology and desire to
separate policy from mechanism is to enable the first use case, but
not to deny the second.

just my $0.02.

-cheers
-meadhbh / infinity

On Fri, Sep 11, 2009 at 9:45 AM, Charles Krinke <cfk@pacbell.net> wrote:
> I think the country analogy is a good one. As I look at virtual worlds, I
> would perceive that SecondLife, OSGrid, ReactionGrid and ScienceSim are four
> seperate virtual worlds, and are analagous to countries.
>
> Each has their own set of central services including avatar authentication,
> assets, inventory, messaging, search within their grids and the like.
>
> Interop between these four worlds (or countries) will become similar to
> traversing a border crossing and customs between countries. In that mean
> that the user authentication, assets and inventory will most likely be tied
> back to the country of origin (the originating grid) and an avatar
> travelling from OSGrid to ReactionGrid or from ReactionGrid to SecondLife
> will have a certain set of privileges and responsibilites partly determined
> by the underlyiing protocols and partly determined by the policies of the
> respective grids.
>
> So, this seems to be headed in more or less the right direction. As long as
> we try to keep in mind that we have a set of peer to peer relationships to
> consider in order to allow interop between similar virtual worlds.
>
> Charles
>
> ________________________________
> From: Morgaine <morgaine.dinova@googlemail.com>
> To: ogpx@ietf.org
> Sent: Friday, September 11, 2009 12:36:59 AM
> Subject: Re: [ogpx] where does VWRAP fit?
>
> Kari's question is a good one, because it highlights the curious gulf that
> exists between the user's perspective of virtual worlds and the
> implementation perspective embodied in the OGP documents.  Much has been
> made of the alleged ambiguity and uncertainty about this term, but this is
> really not true at all.
>
> Users of virtual worlds know exactly what the term means, in the same way
> that they can distinguish one country from another when they go on holiday.
> People have been living with the concept of different places ever since they
> started travelling beyond their village boundary, and nowadays the
> popularity of tourism embodies that concept most vividly in the form of
> countries.  Different countries tend to look different and have different
> cultures and different rules (local policies).  This is entirely natural and
> instinctive to us.
>
> That concept doesn't disappear when "places" become digital.  Instead the
> concept blossoms, because without the constraints of the physical world,
> virtual places can be so dramatically different.  The huge diversity means
> that "virtual worlds" cannot be defined prescriptively, but there is no
> ambiguity at all about the separation and independence of virtual worlds as
> a concept.  That concept is hardwired within us from physical experience.
> As our imaginations are freed by the technology, the diversity and
> independence of virtual worlds can bloom while still enjoying a common
> protocol for communication.
>
> The only thing that has ever created any confusion about "virtual world" in
> the context of  OGPX is the invention of a completely new and totally
> unnecessary semantic for the phrase within the protocol documents, a
> semantic that bears no relation whatsoever to normal usage.  I'm glad that
> we managed to remove the source of the confusion from the charter, but now
> comes the larger task of removing it from the protocol documents as well.
>
> Having removed it, we can then address how VWRAP implements the
> user-oriented requirement of interop between multiple virtual worlds, since
> removing the "single VW" will allow us to refer to more than one VW.  We've
> already been told authoritatively that, as it stands, the protocol will only
> connect single regions or a region domain of regions to one single virtual
> world, and not interop with a whole other VW.  However, that goal has been
> extended recently in informal discussions, with a hint that more than one
> Agent Domain could be made to interact.  That would indeed be the start of
> interop between multiple VWs, as users know them.
>
> I look forward to that.
>
>
> Morgaine.
>
>
>
>
>
>
>
> =========================================
>
> On Sun, Sep 6, 2009 at 5:04 PM, Kari Lippert <kari.lippert@gmail.com> wrote:
>>
>> I present this perspective and ask this question to try to clarify
>> these concepts within my mind. All I ask is that you run with me on
>> this and think, not react. I am hopeful that this question and these
>> simple assumptions might inspire the great thinkers on this list to
>> forge ahead.
>>
>> As I understand it, a "virtual place" is somewhere my "virtual
>> representation" can go.  The "public" calls these the "virtual world"
>> and an "avatar" for convenience. What the "public" is not necessarily
>> aware of (nor do they want to be), is what goes on behind the curtain
>> so to speak. The "virtual place" doesn't exist anywhere, so you can't
>> actually have connectivity between two of them. You can, however, have
>> the illusion that two "virtual places" are connected. (Abandon here
>> all philosophical thoughts ye strain to have about this illusion or
>> the perception thereof - it matters not for the moment.) In the really
>> crude sketch that I've attached, this is represented by everything
>> above the red line.
>>
>> My view of what really does exist is a set of "services" that create
>> this "virtual place": a service that handles authentication and trust;
>> a service that provides logging; a service that provides world
>> construct management; a service that provides avatar management; a
>> service that provides visual representation; a service that provides
>> event management; a service that provides messaging; a service that
>> provides physical infrastructure; and so on. How a company uses this
>> set of "services" to create their "virtual world" may vary but it is
>> my guess that there is a lot of commonality. [As an aside, it is not
>> necessary that these "services" be implemented in any particular
>> fashion, such as SOA, so please don't get hung up on that detail.]  In
>> the sketch, this is shown as a set of colored boxes within a gray
>> shape. To me, the gray shape is an administrative domain (I
>> acknowledge that it might actually be only a part of a company even
>> thought the drawing does not show that. Stay with me here - don't get
>> lost down a rabbit hole!)
>>
>> The conceptual commonalities amongst these sets of "services" can be
>> represented generically. Representing these  commonalities
>> generically, IMHO, is important for the purpose of developing this
>> protocol. One can then use a set of generic representations to
>> describe a "collection of services that create the perception of a
>> virtual place" which is what those below the red line mean when they
>> speak of a "virtual world."
>>
>> My question is where VWRAP fits in this view. The "public" desire is
>> to have "interoperability between virtual worlds" so clearly to them
>> it is the double line between the two "virtual worlds." Behind the
>> curtain, what does that become? Does VWRAP interconnect these various
>> "services"? All of them one to another, or just some of them? Given
>> what I understand you wish this protocol to be, I believe VWRAP is
>> destined for existence at this "service" level - each of these
>> "services" becomes a VWRAP endpoint.
>>
>> Ultimately, given the various payloads envisioned for transport using
>> this protocol (as described generally in the proposed charter), I
>> believe VWRAP is actually a set of related "service" specific messages
>> that can be used to give the user a perception of connectivity.
>> "Services" will then be able to communicate freely without constraints
>> of "meat world" authority or responsibility.
>>
>> It doesn't make sense to me to relate what the protocol could be
>> applied to to what I understand as the notion of "region domain". The
>> last email interchange hinted at the issue with that. Each of these
>> "services" could be implemented by a different administrative
>> authority (the perfect world of the service oriented architecture)
>> thereby being shared across what I think you are calling "region
>> domains". I think a more flexible boundary distinction might be to
>> define a "trust region" - a set of these "services" that can be
>> accessed without a different authentication [note that I do not mean a
>> re-authentication to make sure it is still you but rather permission
>> to cross a trust boundary]. The trust boundaries can be related to one
>> "meat world" administrative authority or can span several depending on
>> the trust model they share.
>>
>> It is my hope that this crude sketch will support your understanding
>> of my perspective. While I recognize that this view might be a bit
>> strange (it did come from my mind after all), if it is wrong I would
>> appreciate your corrective comments, but let's not get hung up on
>> perfecting this sketch. It is only given to help you consider the
>> question I ask: Given this view of "services" that create the illusion
>> of a "virtual place," where (or how) does VWRAP fit? Is it, as I
>> believe it to be, between the orange "service" and the yellow
>> "service" so that they may understand and exchange with each other the
>> aspects of the illusion for which they are responsible?
>>
>> I hope this helps - I don't want to blow things up again but I do need
>> this clarity.
>>
>> Kari
>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>