[ogpx] where does VWRAP fit?

Kari Lippert <kari.lippert@gmail.com> Sun, 06 September 2009 16:04 UTC

Return-Path: <kari.lippert@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 2A11C3A68E6 for <ogpx@core3.amsl.com>; Sun, 6 Sep 2009 09:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.455
X-Spam-Level:
X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[AWL=-1.990, BAYES_20=-0.74, DC_GIF_UNO_LARGO=2.275]
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 3vEYBaRpX7Yk for <ogpx@core3.amsl.com>; Sun, 6 Sep 2009 09:04:36 -0700 (PDT)
Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 7C5423A68DA for <ogpx@ietf.org>; Sun, 6 Sep 2009 09:04:35 -0700 (PDT)
Received: by ewy3 with SMTP id 3so2083106ewy.42 for <ogpx@ietf.org>; Sun, 06 Sep 2009 09:04:57 -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=j3CHe5IvXIp0Gn6QDx2E1kKkPzPsJ2ZghqEE7Bdi10c=; b=BgBoNe0gdSmRhZG7Irsmp3McMSXiHQtJqrnn8BpMNyC3o63Ivj8OJJ+Hpb7ICH/ldJ Jg80lgnx2oD82qj+iWSfM6JY4kbgVoPsNUGdYdrxRNUQ7deL9tYUIsGHYcHx9IBvIyeF vXlKG5TNLH/qBBP5aBp0Q0gCWdwnAugpp6aN0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=tCJAe8ysa5CyP3Izogau1Nmw07sFbnFucbCKnwVURauhjeosBVfhXMD5stUTicnFex xUokGcDcWBYVeQkI8ZDe+5tYowe1rUqszKtpwXJwhcHFbXfYeyQT1sOjKjjGi/1D8/fq B2EgcGNzuLdICZWzjqwGe+kfsrnCnxTNHDs3I=
MIME-Version: 1.0
Received: by 10.216.87.9 with SMTP id x9mr1425404wee.0.1252253096045; Sun, 06 Sep 2009 09:04:56 -0700 (PDT)
Date: Sun, 06 Sep 2009 12:04:55 -0400
Message-ID: <382d73da0909060904h7b666bdqc40ce151ce0d241a@mail.gmail.com>
From: Kari Lippert <kari.lippert@gmail.com>
To: ogpx@ietf.org
Content-Type: multipart/mixed; boundary="0016e6db2996f56d4c0472eae4c7"
Subject: [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: Sun, 06 Sep 2009 16:04:37 -0000

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