[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ogpx] Protocol for permitting policy decisions



There are two cases here:

  1. When the source R1 and destination R2 regions belong to the same administering authority, then it is a reasonable optimization for serialized agent data to be transferred directly from R1 to R2.
  2. In contrast, when they belong to different administrations then there is a privacy concern (as various people have mentioned), since it is no business of R1's to know that the agent is going to R2 nor any business of R2's to know that the agent came from R1.

As long as we consider the direct R1->R2 shortcut to be a local optimization, we're fine, since both privacy and efficiency can be satisfied in the distinct cases where each one is appropriate.  I think that this is a reasonable implementation note that we could add to the protocol specification.

What the teleport specification must not do however is to mandate a direct R1-R2 network connection, since that would deny case 2).


Morgaine.





=====================================

On Thu, Oct 15, 2009 at 5:58 PM, David W Levine <dwl at us.ibm.com> wrote:

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 at alinoe.com>

10/15/2009 06:54 AM

To
cc
David W Levine/Watson/IBM at IBMUS, Infinity Linden <infinity at lindenlab.com>, Meadhbh Hamrick <meadhbh.siobhan at gmail.com>, "ogpx at ietf.org" <ogpx at ietf.org>, "ogpx-bounces at ietf.org" <ogpx-bounces at ietf.org>, Magnus Zeisig <magnus.zeisig at 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 at alinoe.com>


_______________________________________________
ogpx mailing list
ogpx at ietf.org
https://www.ietf.org/mailman/listinfo/ogpx



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.