Re: [ogpx] Informal draft for discussion -- client side capabilitiesand setup flows

Infinity Linden <infinity@lindenlab.com> Thu, 25 June 2009 19:12 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 DDDE73A684D; Thu, 25 Jun 2009 12:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.403
X-Spam-Level:
X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6]
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 Ck9OGt+pAAZk; Thu, 25 Jun 2009 12:12:58 -0700 (PDT)
Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by core3.amsl.com (Postfix) with ESMTP id AFF883A6837; Thu, 25 Jun 2009 12:12:58 -0700 (PDT)
Received: by yxe1 with SMTP id 1so2719265yxe.29 for <multiple recipients>; Thu, 25 Jun 2009 12:12:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.46.10 with SMTP id t10mr3751633ant.116.1245956765375; Thu, 25 Jun 2009 12:06:05 -0700 (PDT)
In-Reply-To: <OF68EA1CF7.7097A5B8-ON852575DF.005D4F02-852575DF.005DFB80@us.ibm.com>
References: <4A3BE302.5070405@isode.com> <OF68EA1CF7.7097A5B8-ON852575DF.005D4F02-852575DF.005DFB80@us.ibm.com>
Date: Thu, 25 Jun 2009 12:06:05 -0700
Message-ID: <3a880e2c0906251206q219b2e8fx471b359cdeb35747@mail.gmail.com>
From: Infinity Linden <infinity@lindenlab.com>
To: David W Levine <dwl@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ogpx-bounces@ietf.org, ogpx@ietf.org
Subject: Re: [ogpx] Informal draft for discussion -- client side capabilitiesand setup flows
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: Thu, 25 Jun 2009 19:13:00 -0000

and some nits...

in requirements, item 2, were we going to add the use case of the
client application having a routable IP address and responding to HTTP
requests directly? i think we talked about it and we (Linden) figured
we would probably rarely see such a use case, but you (IBM) thought it
was likely enough to be supported. personally, i think it would be
okay if we identified it as an option (not a requirement) of the
client application and that client capabilities were simply formulated
as http(s): URIs, we could just not deploy it in our client ('cause it
DOES have security ramifications.)

the example ... hmm ... we've got to be able to come up with a better
example. one of the things i've been thinking about is how the
underlying OGP mechanisms may be used with HyperGrid and CableBeach.
maybe there's a use case here for when users direct their avatars to
move across HG grid boundaries? if i understand it correctly,
different HG grids may specify distinct agent domains and asset
servers. perhaps the use case of a client mediated grid transfer in HG
would bear fruit.

i think.. in general... the existing event queue defined in OGP:Base
is perfectly acceptable for a wide number of uses, and will be less of
a lightening rod for security screeds. but yeah... when you need a
client side cap, sending a message down an event queue just won't
work.

so... i guess i'm thinking... we should do a little more word defining
WHEN client side caps are appropriate and when an existing event queue
structure is acceptable.

and about the URI scheme... i thought we were going to call it eq://
and eqs://. and lets be more explicit:

EQ://client_id@host:port/path?query#fragment

or

EQS://client_id@host:port/path?query#fragment

and... the example at the end seems to imply that it's the agent host
that creates the capability. shouldn't the client be the one that
creates the path portion of the capability and passes it off to the
agent host?

On Wed, Jun 24, 2009 at 10:06 AM, David W Levine<dwl@us.ibm.com> wrote:
>
> This is an informal draft intended to drive some feedback and discussion.
> The content follows the discussion a week ago, in SL at the weekly
> AWGroupies meeting. Feedback is welcome, and encouraged, here, and at next
> week's AWGroupy meeting. For those who do not follow the weekly discussions,
> they are held in world, on Second Life Contact Zha Ewry (me) or
> Saijanai Kuhn in world for an invite. The AWGroupies meet Tuesday mornings
> at 9:30 AM Pacific time, in second life. For those who do not routinely use
> second life, a free account is available, details at the Linden Lab web
> site: http://secondlife.com/   I expect the next iteration of the document
> to be posted as an IETF input for discussion at IETF75 in Stockholm.
>
>
>
>
>
> - David Levine
> ~ Zha Ewry  (In Second Life)
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>