Re: [ogpx] Protocol for permitting policy decisions

[Vaughn Deluca <[e-mail]>]

I  agree with this conceptual split, yet i would like to stick to the more
precise terminology I outlined above.R1 and R2 are *by definition* in
different domains.
The case you mention in 1. is a  R1.1 -> R1.2 transfer.

In addition it can be argued that it should be left to the AD to decide how
far its wants to optimise.
As long as the protocol *allows* a region transfer via the AD rather than
requiring the direct R1->R2 connection everybody can be satisfied. Its left
up to the end users to pick an agent domain that fits their needs for
privacy.

-Vaughn


On Fri, Oct 16, 2009 at 8:35 AM, Morgaine <[e-mail]>wrote;wrote:

> 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 <[e-mail]> 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 <[e-mail]>*
>>
>> 10/15/2009 06:54 AM
>>   To
>> Vaughn Deluca <[e-mail]>
>>  cc
>> David W Levine/Watson/IBM@IBMUS, Infinity Linden <[e-mail]>om>,
>> Meadhbh Hamrick <[e-mail]>om>, "[e-mail]" <
>> [e-mail]>gt;, "[e-mail]" <[e-mail]>rg>, Magnus
>> Zeisig <[e-mail]>
>>  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 <[e-mail]>
>>
>>
>> _______________________________________________
>> ogpx mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>