IETF Logo Mail Archive

Re: [ogpx] Protocol for permitting policy decisions

David W Levine <dwl@us.ibm.com> Thu, 15 October 2009 16:59 UTC

Return-Path: <dwl@us.ibm.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 A433B28C112; Thu, 15 Oct 2009 09:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.298
X-Spam-Level:
X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 fMikcMutzKu4; Thu, 15 Oct 2009 09:59:06 -0700 (PDT)
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 7AABF3A69B2; Thu, 15 Oct 2009 09:59:06 -0700 (PDT)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9FGnOAK008146; Thu, 15 Oct 2009 12:49:24 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9FGx55x250930; Thu, 15 Oct 2009 12:59:05 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n9FGtbgP001745; Thu, 15 Oct 2009 12:55:38 -0400
Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n9FGtTbP001561; Thu, 15 Oct 2009 12:55:31 -0400
In-Reply-To: <20091015105430.GA26932@alinoe.com>
References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <OFE55CFEA3.6AD0DA74-ON85257646.006FC774-85257646.0070F176@us.ibm.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> <b8ef0a220910071407w14040de4ka198375a70896b@mail.gmail.com> <20091008114435.GA22204@alinoe.com> <OF17263597.F074C846-ON85257649.004AC591-85257649.004CA2BE@us.ibm.com> <9b8a8de40910121244l94e4f4ai4805692e224f70f@mail.gmail.com> <20091015105430.GA26932@alinoe.com>
To: Carlo Wood <carlo@alinoe.com>
MIME-Version: 1.0
X-KeepSent: 8ED24AAF:6A56D7D6-85257650:005CEDBD; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
Message-ID: <OF8ED24AAF.6A56D7D6-ON85257650.005CEDBD-85257650.005D4967@us.ibm.com>
From: David W Levine <dwl@us.ibm.com>
Date: Thu, 15 Oct 2009 12:58:55 -0400
X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/15/2009 12:58:57, Serialize complete at 10/15/2009 12:58:57
Content-Type: multipart/alternative; boundary="=_alternative 005D496585257650_="
Cc: Magnus Zeisig <magnus.zeisig@iis.se>, Infinity Linden <infinity@lindenlab.com>, "ogpx-bounces@ietf.org" <ogpx-bounces@ietf.org>, Meadhbh Hamrick <meadhbh.siobhan@gmail.com>, "ogpx@ietf.org" <ogpx@ietf.org>
Subject: Re: [ogpx] Protocol for permitting policy decisions
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, 15 Oct 2009 16:59:07 -0000

Region 1 (the source) holds the current state of the avatar. Running 
scripts in attachments, in particular. Without the source region 
participating, you end up having no way to
retrieve that state, nor a way to know when that region can stop 
simulating the avatar.  Now.. You could go R1->AD->R2 which would obviate 
the privacy concern, but you end up
with a pass through the "Not present in any region" state which might be 
disconcerting. (You also add at least one set of transactions to the 
dance, which, again isn't too bad) 
For edge crossings and TPs within a single "domain" that seems awfully 
expensive. 

- David
~ Zha




Carlo Wood <carlo@alinoe.com> 
10/15/2009 06:54 AM

To
Vaughn Deluca <vaughn.deluca@gmail.com>
cc
David W Levine/Watson/IBM@IBMUS, Infinity Linden <infinity@lindenlab.com>om>, 
Meadhbh Hamrick <meadhbh.siobhan@gmail.com>om>, "ogpx@ietf.org" 
<ogpx@ietf.org>rg>, "ogpx-bounces@ietf.org" <ogpx-bounces@ietf.org>rg>, Magnus 
Zeisig <magnus.zeisig@iis.se>
Subject
Re: [ogpx] Protocol for permitting policy decisions






On Mon, Oct 12, 2009 at 09:44:56PM +0200, Vaughn Deluca wrote:
> (8) AD1---(Rez avatar cap) ---> Derez avatar cap
> The stored Derez avatar cap is a URI pointing to the current region of 
the
> avatar, in this case RS1.1

Why is this step needed?

> (9) RS1.1---(POST)---> Rez avatar cap
> The Rez avatar cap is un URI pointing to the destination region of the 
avatar,
> in this case RS2.1

Why is RS1.1 involved in the TP to RS2.1?
This seems to mean that:
a) RS1.1 can stop a successful TP away from RS1.1 to RS2.1
b) RS1.1 learns about where an avatar TPs away to (privacy issue)

> (10) RS2.1---( Rez avatar result)---> RS1.1
> 
> (11) RS1.1---(Rez avatar result)---> AD1

Same thing; there is no need for RS1.1 to be 'in between' this, is there?

> (12) AD1---(Place avatar result, Rez avatar result)--->  viewer
> The viewer can now contact the region.

-- 
Carlo Wood <carlo@alinoe.com>

v2.8.7 | Report a Bug | By Email