From carlo@alinoe.com Thu Oct 1 03:53:12 2009 Return-Path: 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 4969E28B56A for ; Thu, 1 Oct 2009 03:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[AWL=-2.531, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, SARE_FWDLOOK=1.666] 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 1qfkgU1pjsos for ; Thu, 1 Oct 2009 03:53:08 -0700 (PDT) Received: from viefep12-int.chello.at (viefep12-int.chello.at [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id 8D3043A67AB for ; Thu, 1 Oct 2009 03:53:07 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep12-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091001105429.JLZM24520.viefep12-int.chello.at@edge03.upc.biz>; Thu, 1 Oct 2009 12:54:29 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upc.biz with edge id nNuT1c01R0FlQed03NuUMt; Thu, 01 Oct 2009 12:54:29 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MtJJn-0007y8-Q7; Thu, 01 Oct 2009 12:55:27 +0200 Date: Thu, 1 Oct 2009 12:55:27 +0200 From: Carlo Wood To: Joshua Bell Message-ID: <20091001105527.GA29450@alinoe.com> References: <20090902230338.GC6652@alinoe.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 10:53:12 -0000 On Wed, Sep 30, 2009 at 09:10:13AM -0700, Joshua Bell wrote: > Without diving in too deep, I believe this thread is putting up a two-level > false dichotomy - either the RD determines policy or the AD determines policy, > OR things aren't sensible w/o nil trust. If that's a mis-reading, my apologies. > > IMHO, it should be apparent that both AD (which is the agent/advocate for the > user) and RD (where the user wants to be) both need to make policy decisions. I'd formulate this as: It is the destination (the region (domain) that the user is in) that determines the ToS. This is something else than the RD making protocol-level policy decisions. The link between RD and ToS is in most cases not really a technical one (it will only require to use the current region to get relevant arguments for some messages). > A corporate AD may restrict where users may visit (e.g. agentd.corp.example.com > may say "no visiting party.example.com from work!") or an AD may restrict users > based on personal preferences (agentd.safesurf.example.com may say " > scam.example.com is on a shared blacklist of malicious sites, teleport > blocked"), legal or political requirements (agentd.kidfriendly.example.com may > say "you can't visit adultgrid.example.com"). Note that in all cases the AD is > enforcing policy as an agent of the user, just as a web browser on a local > network does today. Of course (excellent examples). The AD determines if you are allowed to teleport somewhere or not. Every example you give is about denying teleport: the user is not allowed to go the desired destination. However, if the user *is* allowed to go to the desired destination then depending on that destination restriction will still apply, and those restrictions will in most cases be a function of that destination. For example agentd.A.and.B.allowed.example.com will allow teleports to region.A.allowed.example.com and region.B.allowed.example.com, but once there, only A or B is allowed, for everyone in that region, independent of the agent domain. An agentd.A.and.B.are.evil.com would not allow their users to even go to those regions. > Presumably, there will exist many ADs that provide no > restrictions whatsoever, just as most Web browsers accessing the 'net via most > ISPs in most countries today don't restrict access to Web content via policy. > > On the flip side, the RD will also have policy. Corporate VWs may limit access > to employees. Adult-centric VWs may limit access to agents from ADs that verify > accounts with some well known service. Real-world-region-specific RDs may > require citizenship checks and deny access to citizens of some nation-states. These are again about access restrictions, which is not my concern. > And of course permissions would doubtless exist on a per-user basis as well as > per-AD. Again - no different than access permissions today on the Web, except > that instead of being a two-party user/service, it's three party user/AD/RD. > And one hopes that, like most of the Web, content is freely visitable by all. > > On the topic of nil-trust: again, I wholeheartedly support the stance that the > protocol should support nil trust operation. I hope that both the protocol and > operations of VWRAP-based worlds allow the bulk of VWRAP traffic to occur in a > nil trust environment, just like the Web does today. However, I *suspect* that, > in practical terms, the abilities we want to grant to regions by visiting them > - to display our avatars, to broadcast information about our agents, to give > and receive virtual goods - will require at least a modicum of trust for most > VW interaction, at least on the level of an SSL-style secured connection that > gives users a certificate to look at that provides some identity/trust > information about the service provider. > > I suspect I'm going to beat this drum a lot - "VWs are just like the Web, > except where they're different" :) > > On Tue, Sep 29, 2009 at 5:51 PM, Morgaine > wrote: > > Hi Vaughn! :-) > > Your description of our discussion is quite accurate.  However, it seems to > imply that I advocate in favour of the view that the AD must be the seat of > all policy for connected regions.  I do not.  I was merely explaining the > architecture of AD+RD pairing as it has been described to us repeatedly > throughout the two years of our OGP-related work in the LL+IBM sponsored > Architecture Working Group within Second Life. > > After the emails, Carlo and I examined this issue with higher discussion > bandwidth inside SL, and it turned out that we were describing two > different things:  I was explaining the AD+RD relationship in OGP, while > Carlo was describing RDs as they should be designed if an RD were an > autonomous unit with its own policies, effectively a small world.  If OGP > were designed differently and less restrictively to allow that, then there > would have been no discussion.  :-) > > Of course, OGP is not VWRAP, but only the seedcorn for VWRAP.  We can make > VWRAP as flexible as we like, and it's easy to see its potential > flexibility in David's deployments document.  Consequently, I have high > hopes that all parties will be happy with the eventual outcome. :-) > > You may have missed the primary reason why I do not advocate a design in > which an OGP-style AD is the seat of all power, possibly because the > discussion has been spread out across all of OGPX and MMOX.  It's easy to > summarize in one sentence though:  such a design cannot underpin an > Internet-wide metaverse of interoperating virtual worlds because it doesn't > respect the key meme of virtual and non-virtual tourism:  Destination > Determines Policy. > > This meme is so fundamental and crucial (and obvious) that OGP's support of > the exact opposite is terminally broken, as a basis for the hypothetical > metaverse.  Indeed, you yourself have referred to the problem in the funny > "war over purple". :-)  At best such a design can support only a random > scattering of VPN-like walled gardens, all isolated and incapable of > interoperating because they all claim the "one true policy".  We should not > go there. > > The most recent description of this problematic aspect of the OGP design > was posted by Magnus Zeisig in his excellent email at http://www.ietf.org/ > mail-archive/web/ogpx/current/msg00324.html , which I fully support.  Such > balkanization is not a desireable goal when designing a VW interop > protocol. > > So where are we now?  We're at the stage of examining David's VWRAP > deployment patterns to see how the protocol can support them.  And in that > examination, it is likely to become clear that the old OGP model of "AD > determines policy" is completely non-viable for interoperating between > VWRAP-compatible virtual worlds, except when that policy is "nil trust" as > a common denominator. > > Consequently, we will either decide to live with the original OGP split and > use "nil trust" as our basis for VW interop, or else we will redesign the > AD/RD relationship to place many more important policy decisions where they > really belong, at destination.  The latter seems the best choice to me, and > of course it would make Carlo happy, and it is also the model that every > single existing world already operates --- when in Rome, do as the Romans > do.  Only the old OGP AD/RD two-way split design is out of step.  Let's > hope that we can correct that in VWRAP. :-)) > > > Morgaine. > > > > > > > ==================================== > > > > On Tue, Sep 29, 2009 at 9:16 PM, Vaughn Deluca > wrote: > > Carlo and Morgaine have above been involved in a very interesting > discussion about the nature of the (or *a*) virtual world.  > > Painting their positions with  broad strokes, Morgaine stresses the > primary role of the AD as the seat of policy and trust, up to the point > where he denies the RD any role above that of a convenient extension of > the AD, i.e. the RD as "colony without a government". Carlo > passionately argues for the independent role of the RD in policy > issues. > > I feel that both positions are valid (to some degree), and both can be > covered by VWRAP. > > Calo makes absolutely clear that having all policy in the respective > ADs of the avatars leads to problems when several avatars meet in one > region domain, say RD1. Avatars will be busy killing each other over > the right to wear purple, and for the innocent bystanders caught in the > crossfire it will be fully unclear were to complain. Stepping in > Morgaines shoes, i think i would argue that what Carlo asks for can be > realised by applying the policy of a *particular* AD to RD1. The rules > to deal with color of clothes, could be formulated in AD1 associated > with RD1. In principle Carlo could run this domain himself, even > without a single avatar in it, and in this way get his "government" and > set any policy he wants. If two avatars from AD2 and AD3 visit RD1, The > policy in RD1 would be governed by what is specified by AD1. > > While this fully fits Morgaines view of "AD rules all", and also fits > Carlo call for autonomy of RD1, it feels decidedly like a kludge, and > in this particular case it seems much more straightforward to make RD1 > more autonomous. Yet, to keep everything within one framework, this > kludge seems to be the logical solution... I would like to hear what > others think about this. > > One other remark: the minimal example for  a "world"  -one AD and one > RD- would be more useful when extended with one asset service AS. > Explicit mentioning of the AS will make it much easier to discuss IP > issues.  > > Vaughn > > > > On Mon, Sep 14, 2009 at 10:44 AM, Carlo Wood wrote: > > On Mon, Sep 14, 2009 at 06:43:06AM +0100, Morgaine wrote: > > Carlo asked for detailed comments on the below, so here goes. :-) > > > > > > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood > wrote: > > > >     On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote: > >     > The problem you see is that a virtual world is much more > than just a > >     Region > >     > Domain.  It is a complete set of services of which the > Region Domain > >     service is > >     > just one.  Other typical services might be those of the > Agent Domain > >     (which > >     > provides identification and authorization services and > possibly others), > >     as > >     > well as asset and inventory services, IM and other > communication > >     services, and > >     > maybe several more. > > > >     Well... that is purely semantic. It is a way to define VW, > but not one that > >     I've been using :/ > > > > > > It's a rough top-level projection of the architectural model of > VWRAP, once the > > various services have been decoupled in the way that David Levine > often > > describes to us.  Nothing very contentious there, everyone likes > a > > services-oriented approach. :-) > > > > > > > >     For simplicity, assume that only two things are needed to > create a complete > >     virtual world, like SL or OG: A Region Domain (RD) and an > Agent Domain > >     (AD). > > > > > > I am happy to consider that simple scenario as representative. >  It is quite > > reasonable to equate AD with VW because the AD is the focus of > almost all the > > policy decisions of a VWRAP-based world.  When other decoupled > services are > > added to this picture, it doesn't change the fundamental > architecture of AD + > > RDs, only extends it by decoupling more than just the region > service.  So > > that's fine with me. > > I totally disagree that the AD is the representative...and why do > you say > that below a sentence of me where I say "A Region Domain (RD) and > an Agent Domain (AD)"? > > This is like I say "VW = AD + RD", and you go: "yes, VW = AD". We > can't > have a discussion like that Morgaine. > > >     Currently, without any interop, each administrative entity > (or trust > >     entity) > >     will need to provide both: an RD *and* an AD, otherwise they > don't have a > >     functional VW. > > > > > > Correct.  The AD is the seat of most (but not all) of the policy > decisions of a > > I even *stressed* the '*and*' here, and you do it again. > > > VW, so it's very central to the existence of a VW.  While it's > possible to > > imagine policy-free VWs that temporarily  take on the policy of > any other world > > they hook up with, this is clearly a subset situation.  All the > currently known > > SL-like virtual worlds are grids of the SL kind, with their own > individual > > policies which they are not going to change on interop. > > > > > > > >     Your conclusion is that a VW exist of both 1 RD and 1 AD. But > I ask you to > >     reconsider if that conclusion is correct, because it is based > on the > >     current > >     situation without any interop. Now "correct" might not be the > correct word > >     - heh. > >     Rather I should say: I ask you to reconsider if that > definition is very > >     useful. > > > >     Lets consider the following fictive case: > > > >     LL runs one RD and AD, called RD1 and AD1. > >     CB (Cable Beach) runs another RD and AD, called RD2 and AD2. > >     A user that authenticates with either AD1 or AD2 can travel > to RD1 AND RD2, > >     completely symmetrical, keeping their respective AD1- and > AD2- assets etc. > >     This is possible with the right policies, so for the sake of > looking at > >     the usefulness of the above definition of VW, assume this is > the case. > > > > > > That's not quite right because Cable Beach is not a world > provider like LL. > > Cable Beach is perhaps best described as a "login mediation" > mechanism or > > I might not understand what the real Cable Beach is or wants to be, > I was just > trying to give an example to work with. So, again: > > LL runs one RD and AD, called RD1 and AD1. > OG runs another RD and AD, called RD2 and AD2. > A user that authenticates with either AD1 or AD2 can travel to RD1 > AND RD2, > completely symmetrical, keeping their respective AD1- and AD2- > assets etc. > This is possible with the right policies, so for the sake of > looking at > the usefulness of the above definition of VW, assume this is the > case. > > > protocol, which provides a model for interaction between a "world > service" > > (effectively an AD), the user's client, and various decoupled > services such as > > simulation nodes (possibly an RD) and inventory/asset services. >  Let's assume > > therefore that your "CB" above means something different (another > world > > provider similar to LL), and then we can proceed with your > example case. > > Ok > > >     Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be > another VW? > >     Or do you think it would make most sense in THIS case to > speak of a single > >     VW? > > > > > > They're two worlds because you defined them as such, as each has > its own AD. > > :-)  But that aside, if they were set up separately then they > have two > > different sets of policies, two different sets of residents, two > different > > ToS's, possibly two different legal jurisdictions, two different > mechanisms for > > abuse control and conflict resolution, and so on and so forth. >  If they were > > created to be worlds that can stand alone but interoperate when > desired, then > > each of these is a diffferent world.  I don't see how that can be > disputed. > > As I stated in one of my first posts, it will (hopefully!!!) be > mainly the > the *RD* and NOT the AD that all of those things are a function of! > > You keep saying that it's mainly the AD that determines these > things, but > that would be confusing and very annoying. If two people meet in a > virtual > world, that is - if they are standing next to eachother in one > region and > using local chat - then they should fall under the same legal > jurisdiction > and the same ToS: it is the region that determines the rules, not > the AD > that they used to login with. > > As example, ToS1 says: it's ok to be naked; and ToS2 says: it's a > bannable > offence to be naked. Do you really think that it's even workable if > the > ToS to be applied is a function of the AD? Say you login using AD2, > so > ToS2 applies to you. You meet someone else that is naked. You know > that > you are not allowed to and you are offended. You create an abuse > report; > where does that report go to? To your AD administration? That makes > no > sense: that naked person is using a different AD. To his/her AD > administration > then? That makes also no sense since they allow it. > > Seriously, there is only one reasonable thing to do: the ToS that > applies > is a function of the Region Domain *only*, and if you write an > abuse report, > it should go to the administration of the region that you are in > and not > to your or the others AD administration. Same holds for the things > related > to legal jurisdiction and any other 'rules' that applies at any > given > moment (to users). The only thing that might be a function of the > AD are > technical policies that are automatically enforced by VWRAP. > > >     I think this is what Infinity means when she says that > "virtual world" > >     cannot > >     be defined, because what could be perceived as being a VW is > highly > >     dependend > >     on the exact situation (and policies) and in certain > configuration that are > >     not as clear as the current situation (no interop) or the > above example > >     (100% > >     interop). > > > > > > This is incorrect.  "Virtual world" is defined by each provider > of a virtual > > world and by nobody else, and each provider knows full well how > it is defined, > > what its boundaries are, and what makes it distinct.  Nobody else > can define > > what a virtual world is, and it's not our business to define it > either (nor to > > conjure up a fictitious definition). > > Sorry, but I think you should try harder to understand my point of > view first. > I didn't give the examples so you can ignore them. > > > We only need to define the protocol interactions at the endpoints > presented by > > those worlds, and not to define "virtual world" structurally nor > any other way. > >   Doing so is what has got us into this mess, by creating a > fictitious > > definition based on reachability and hence blocking any ability > to talk about > > actual virtual worlds.  Those worlds exist.  They won't go away. >  They want to > > interoperate, but they don't want to be told that they don't > exist. > > I was trying to make you understand WHY Infinitely tells you they > don't "exist", > if you understand her (and you don't, imho) then it will be easier > to solve this > miscommunication. > > > The contention that we don't know what "virtual world" means is > just plain > > bizarre. > > Only if you already have a definition of "virtual world" they way > you do. > > > I don't know of any VW operator who doesn't know what their world > is. > > That is the *current* situation... which is 100% simpler than what > we'll > have in the future. > > Compare with math... currently we only have Integers (Z). We're > about > to introduce division and by that we need to extend the definition > of > 'number' from Z to Q. Q aren't integers, even though currently > every > number is an integer doesn't mean you have to hold on tight the > "definition" > of "number" == integer. That definition will be broken and you will > have to redefine "number". > > >   Every single one of them could provide the necessary endpoints > for VWRAP > > within their world without any scratching of heads at the meaning > of "virtual > > world".  That repeated allegation has been a complete > misrepresentation.  It's > > just not true. > > You CANNOT define "virtual world" as "AD" (see above) nor as "AD + > RD" because > that is too simple and only holds in the current situation. You can > only, at most, > if you really want, say - well, lets define it as being some RD. > > > And possibly even worse is the excuse  that "virtual world" is > not being > > defined but is being used non-normatively, while in practice > using the phrase " > > the virtual world" to create a totally fictitious single virtual > world instead. > > I agree that as long as it isn't normatively defined, the term > shouldn't be > used in documents except in places where it can literally mean > anything without > that anyone will care (like in the protocol name). > > >   That phrase is unnecessary, it is misrepresentative of the > actual situation, > > it bypasses policy controls of one world by not mentioning its > AD, it prevents > > us from mentioning virtual worlds by blocking the normal meaning > of the term, > > and it provides nothing useful as a benefit in return.  Unless > total confusion > > is a benefit. ;-) > > Sorry, but that is like saying that defining the Rational Numbers > (Q) makes it > impossible to talk about 'numbers', because 3/7 isn't an integer. > What you have to do is let go of your current definition. > > >     In one of my first posts about this topic I stated that > "virtual world" > >     should > >     be considered to be the Region Domain (although I didn't use > that term at > >     the > >     moment) and be completely independent of the Agent Domain, > based on typical > >     cases of abuse and griefing etc: if anyone annoys some other > user, or > >     breaks > >     almost any ToS, it will be region based; which is why I've > always said that > >     any type of abuse can and should be handled at the sim > (single region) > >     level: > >     the estate owner and managers in SL, even, but that idea > definitely extends > >     to "world administrations": the people running the REGION > (domain) is the > >     one > >     that should decide what is the local ToS and deal with abuse > etc. That is > >     why I strongly argue to define "virtual world" as Region > Domain, and leave > >     the AD out of it. Nevertheless, now I have the term "Region > Domain" I don't > >     need "virtual world" anymore. > > > > > > But that's not how OGP is structured.  It's the AD that is the > focus of service > > policy choices in OGP, and it's the "world service" that is the > focus of > > service policy in Cable Beach.  The AD and the world service are > the source of > > capabilities that determine pretty much everything else, and the > region domain > > is very subsidiary to that. > > No, if the service prodiver of some AD disagrees with the (say) a > ToS that applies > when you go to some RD then they should disallow you go there; they > should not > allow you to go there and then demand that you follow their ToS, > that would not > be a practical solution that is workable. > > To use mathematics again, it's easy to make two ToS that have no > intersection: > Say, ToS1 says: you MUST wear purple clothes, and ToS2 says: you > MUST wear blue > clothes. Obviously those will apply to regions. > > So then we have: > > Provider1: RD1 --> TOS1 --> purple clothes > Provider2: RD2 --> TOS2 --> blue clothes > > *if* Provider 2 runs an AD (AD2) and they allow people logged in > with it > to go to region RD1 then the people there should wear purple > clothes: > TOS2 will not apply because of the AD you use. > > If it's against providers religious believe to support wearing > purple > clothes than they might disallow people to go to RD1, that is their > choice (policy). > > > Indeed, a region domain may have no policy of its > > own at all, but merely extend an existing virtual world by > accepting the > > policies of that world's AD.  That's the model in the original > OGP before it > > gained aspirations of becoming a cross-VW interop protocol. > > That makes no sense :/ > > There can be any number of people in a given RD, and each can in > principle > be using a different AD! PLEASE let the RD determine the rules they > have > to live by! Anyone else that disagrees with me about that?! > > > If RDs determined VW policy and generated seed capabilities for > everything and > > ADs were merely login services then your model would apply, and > RD could be > > considered "VW". > > Ah! At last.. > > > But that's not how it is currently structured --- RDs are > > If you are refering to OGP, then OGP should be changed. > > > merely the land + physical simulation components of worlds, and > in SL's case, > > also an elaborate system of proxies.  And that's why we need > multiple ADs to > > interact in VWRAP before we can consider that there is VW-VW > interop.  RDs > > don't handle it. > > What I seem to keep missing is the fact that VWRAP is already > completely > defined in those previous OGP documents and we're merely here to > rewrite > them in an IETF document of sorts. > > Yes we need multiple ADs to interact, and they will. > But yes, RD's will handle whatever they have to handle with VWRAP. > I never said that capabilities equal 'rules' (ToS and legal > jurisdiction > isn't something that should be enforced or controlled by the > protocol) by > the way. > > ... sorry my RSI forces me to stop typing here... shouldn't have > typed this much alrady anyway :( > > >     > In our new protocol, these services may either be > implemented internally > >     within > >     > a virtual world, or some might be implemented as external > services > >     offered by > >     > third parties, the choice being a policy and design > decision for each > >     world > >     > operator.  In all cases however, the virtual worlds are > defined by a set > >     of > >     > services, and not just by a Region Domain. > > > > > > Indeed.  But access to such decoupled services is provided by the > AD through > > the capabilities that it delivers to authorized parties, and > regions are just > > one such service.  You're giving RDs credit for something that > they don't do. > > :-)  Perhaps the VWRAP model should be redesigned along your > lines so that RDs > > become the VWs and are the generators of seed caps, and then ADs > become just a > > subservient policy-free login mechanism. :D > > > > > > > >     I'm afraid that is purely a matter of opinion. I agree that > it is likely > >     that a single 'administrative entity' that runs a RD will > also run an AD > >     and allow users authenticated with their AD visit their RD, > but it is no > >     more than *likely*. There will almost certainly be service > provides that > >     ONLY run an AD, and don't have a RD! And I can imagine that > there will > >     be some that only run a RD and do not care about running > their own AD. > > > > > > Oh sure, there will be all combinations of services, that is to > be expected. > > But it is the seat of policy that is the heart of each virtual > world, and > > currently the seat of policy lies in the AD.  A VW that doesn't > have an AD in > > the VWRAP model is just a colony without a government, ready to > be assimilated > > into a world that has an AD and that therefore sets policies, > instead of being > > a sovereign world that merely wants to interop with that other > world through > > VWRAP. > > > > > > > >     Therefore, "virtual world" cannot be synonym for "the set of > services > >     run by a single administrative entity" as you seem to argue, > and at > >     the SAME time be argued to include an RD *and* AD at all > times. > > > > > > I don't follow that.  Two worlds that can run independently > (that's very > > important) can certainly each be defined as a set of services > that includes the > > functions of an AD and an RD, and those worlds each continue to > include the > > functions of an AD and an RD even after they start interoperating > (assuming > > that VWRAP is extended to allow cross-VW interop).  No world is > going to give > > up part of its services portfolio on interop.  Interop is an > additional > > benefit, not a loss of capability. > > > > [It's worth noting that there may actually be a small loss of > capability > > occurring on interop in VWRAP, although it is rarely mentioned. >  You can be > > present in two worlds simultaneously with the same login > credentials > > pre-interop (a feature that we enjoy currently between SL and > OSgrid for > > example), but post-interop this may no longer be possible --- it > depends on the > > implementation.  No doubt we will visit this issue within VWRAP.] > > > > > > > >     > This is easy to see by looking at a couple of archetypal > examples in this > >     > space: > >     > > >     > > >     >     Is Second Life a virtual world?  Undoubtedly.  Is > Second Life just a > >     Region > >     >     Domain (assuming it were implemented using VWRAP)?  No, > of course > >     not, SL > >     >     includes all of the services mentioned above, and > others. > > > >     Of course, LL happens to run all services that are needed to > create one > >     virtual world; there are no third parties they can hire from > yet, so they > >     have to provide it all themselves. > > > >     But after SL implemented VWRAP they might decide to do away > from one of > >     their services and only keep their RD. Unlikely, but > possible. > > > > > > You're confusing RD functionality with AD functionality again > there.  The AD is > > the heart of a world because it defines its capabilities and > policies.  The RD > > is just a pile of region hosts that could easily be farmed out to > a third party > > to run without them determining policy, and indeed this is > already being done. > > While it is a very important pile of hosts which gives a world > its physical > > characterists, the RD is a subservient service to the AD in OGP, > just as the > > equivalent "simulation nodes" provide a subservient service to > the "world > > service" under Cable Beach.  The RD is well named --- it provides > region > > services only, not the package of internal + external services > that together > > create a virtual world. > > > > > > > >     >     Is OSgrid a virtual world?  Undoubtedly.  Is OSgrid > just a Region > >     Domain > >     >     (assuming it were implemented using VWRAP)?  No, of > course not, it > >     >     currently runs all the UGAIM services, which in a VWRAP > context would > >     >     become similar to those of Second Life. > > > >     Exact same argument. > > > > > > Exact same response because the same applies. :-)   What's more, > in OSgrid this > > is even easier to identify, because every person or company that > adds regions > > to OSgrid is subscribing to the notion that they are participants > in OSgrid --- > > OSgrid is their virtual world.  They are merely providing > additional land mass > > and simulation capacity. > > > > Also, in this example there is no need to hypothesize region > services being > > farmed out to third parties, as there already are hundreds to > thousands of > > independent third parties involved in supplying regions.  Those > regions and > > clusters of regions (equivalent to RDs) together combine to > create the virtual > > world of OSgrid.  There is a clear distinction between R/RDs here > and the VW > > itself, which also includes a variety of other services as > Charles has > > described several times.  The R/RDs are a very important part, > but functionally > > they are not the VW, nor are they the VW perceptually.  They are > places within > > the world, not the whole world. > > > > > > > >     > So you see, the idea that has been floated which claims > that "VW == RD" > >     is > >     > completely wrong, and misrepresents what constitutes a > "virtual world" > >     despite > >     > the very clear examples before us. > > > >     If you want to put it that way (including everything above > that you said) > >     then > >     I have to side with Infinity: you cannot define a virtual > world that way > >     and > >     use it for useful discussions regarding VWRAP. > > > > > > I think you may have misread that.  I did not define "VW == RD". >  That's the > > opposite of what I said, but I agree with you on the negative > conclusion.  If > > one defines "VW == RD" then it becomes impossible to have a > meaningful > > discussion about VWs in VWRAP.  It also becomes impossible to > have a meaningful > > discussion about VWs in VWRAP if one conjures up a fictitious > meaning of > > "virtual world" based on reachability.  And that's why we should > not define it > > in either of those two ways. > > > > The most useful and forward-looking way of defining virtual > worlds in VWRAP is > > as a collection of service endpoints, regardless of who operates > them.  All we > > should care about is the protocol between endpoints, and not > conjure up some > > non-existent single virtual world. > > > > > > > >     In the end, one virtual world as defined by "all services > together to make > >     things work" will be, or can be, a mix of many RD's and many > AD's with a > >     complex > >     web of trust/non-trust between them that makes the concept of > "virtual > >     world" > >     rather fuzzy at best. > > > > > > You're right but you're not being clear about what is fuzzy.  The > concept of " > > single virtual world" is not only fuzzy, it is totally > non-existent in practice > > (because there are many, not one) as well as impossible in theory >  because of > > balkanization through incompatible trust domains, as described so > magnificently > > by Magnus a week or two ago.  We should not go there. > > > > In contrast, the concept of multiple virtual worlds is crystal > clear.  Several > > people here in the group operate virtual worlds, but nobody would > suggest that > > they are unclear about what they operate.  We've been sold a > bridge on that > > "uncertainty".  Multiple virtual worlds presenting VWRAP > endpoints are the > > natural way of approaching interop between VWs, and you don't > have to define > > VWs structurally for that.  You only have to define the endpoints > that VWs need > > to present to the protocol, and avoid any notion of "single > virtual world". > > > > > > > >     [...] > >     > As we move into analysis of the problem space, these issues > will be > >     > disentangled and clarified and the protocols will be > defined and evolve, > >     but > >     > from the current OGP perspective there is no symmetrical > relationship > >     possible > >     > between VWs that could be described as "peering".  It is > the asymmetry of > >     the > >     > VW-RD relationship that has been the crux of the "no VW > interop" issue. > >     For > >     > symmetrical peering, the protocol would need to mention at > least two > >     > communicating VWs. > > > >     You can about peering with just two RD's and one AD, or one > RD and two > >     AD's. > > > > > > I think you're confusing RDs with VWs again --- RDs only provide > regions, > > nothing else.  For peering between two VWs, you would need > interaction between > > their two ADs because their ADs provide their policies.  If you > bypass a VW's > > AD then you bypass its policies, so you're not interoping with > that world.  And > > I don't think we're encouraging bypassing and hence subverting a > world's > > policies. > > > > > > > >     > Of course the situation could change as the protocol > evolves.  For > >     example, > >     > once or twice we have heard mention that multiple ADs could > be involved > >     in some > >     > way, and it seems certain that communication services from > multiple VWs > >     will be > >     > merged because residents demand this.  This would start to > take us into > >     VW-VW > >     > interop territory.  However, there is no such thing in > VWRAP currently, > >     and > >     > it's not in the list of deliverables to include it, and > therefore we > >     cannot say > >     > that VWRAP will provide VW-VW interop at all.  For now. ;-) > > > >     I can't comment on that cause I didn't see VWRAP yet, but > from the > >     charter and the comments on this list I'd think that full > support > >     for interop between any number of RD's and AD's is intended. > > > > > > Well you've put your finger on the problem here.  Everyone is > saying what they > > think is intended because the intention is not actually spelled > out in the > > documents.  Why cannot it be spelled out clearly that interop > between multiple > > ADs is intended?  If it were, this entire discussion could be > avoided because > > it's easy and reasonable to equate ADs with VWs in practice. > > > > Notice however that even if the protocol were modified to be able > to handle two > > ADs at a time, use of an unadorned "the virtual world" in the > documents would > > continue to raise the perennial question of "Which virtual world? > ".  After all, > > there would be two of them being discussed. > > > > It's this phraseology that stems from OGP's original goal of > adding single > > regions or RDs to an existing single virtual world (namely SL in > the prototype) > > that is creating such a problem.  That phraseology was > appropriate for that > > original goal.  It is not appropriate for the goal of > interoperating multiple > > virtual worlds --- it makes it impossible to even talk about the > goal sensibly, > > because "the virtual world" in the OGP sense has no plural. > > > > It's unfortunate, but this whole affair is just the product of > legacy wording > > from OGP.  That's never going to work in a multi-world setting > where we need to > > talk about the endpoints in different worlds. > > > > > > Morgaine. > > > > PS. If anyone else read this far other than Carlo, you have a lot > of stamina > > and dedication. ;-) > > > > > > > > > > > > > > > > ============================================== > > > > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood > wrote: > > > >     On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote: > >     > The problem you see is that a virtual world is much more > than just a > >     Region > >     > Domain.  It is a complete set of services of which the > Region Domain > >     service is > >     > just one.  Other typical services might be those of the > Agent Domain > >     (which > >     > provides identification and authorization services and > possibly others), > >     as > >     > well as asset and inventory services, IM and other > communication > >     services, and > >     > maybe several more. > > > >     Well... that is purely semantic. It is a way to define VW, > but not one that > >     I've been using :/ > > > >     For simplicity, assume that only two things are needed to > create a complete > >     virtual world, like SL or OG: A Region Domain (RD) and an > Agent Domain > >     (AD). > > > >     Currently, without any interop, each administrative entity > (or trust > >     entity) > >     will need to provide both: an RD *and* an AD, otherwise they > don't have a > >     functional VW. > > > >     Your conclusion is that a VW exist of both 1 RD and 1 AD. But > I ask you to > >     reconsider if that conclusion is correct, because it is based > on the > >     current > >     situation without any interop. Now "correct" might not be the > correct word > >     - heh. > >     Rather I should say: I ask you to reconsider if that > definition is very > >     useful. > > > >     Lets consider the following fictive case: > > > >     LL runs one RD and AD, called RD1 and AD1. > >     CB (Cable Beach) runs another RD and AD, called RD2 and AD2. > >     A user that authenticates with either AD1 or AD2 can travel > to RD1 AND RD2, > >     completely symmetrical, keeping their respective AD1- and > AD2- assets etc. > >     This is possible with the right policies, so for the sake of > looking at > >     the usefulness of the above definition of VW, assume this is > the case. > > > >     Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be > another VW? > >     Or do you think it would make most sense in THIS case to > speak of a single > >     VW? > > > >     I think this is what Infinity means when she says that > "virtual world" > >     cannot > >     be defined, because what could be perceived as being a VW is > highly > >     dependend > >     on the exact situation (and policies) and in certain > configuration that are > >     not as clear as the current situation (no interop) or the > above example > >     (100% > >     interop). > > > >     In one of my first posts about this topic I stated that > "virtual world" > >     should > >     be considered to be the Region Domain (although I didn't use > that term at > >     the > >     moment) and be completely independent of the Agent Domain, > based on typical > >     cases of abuse and griefing etc: if anyone annoys some other > user, or > >     breaks > >     almost any ToS, it will be region based; which is why I've > always said that > >     any type of abuse can and should be handled at the sim > (single region) > >     level: > >     the estate owner and managers in SL, even, but that idea > definitely extends > >     to "world administrations": the people running the REGION > (domain) is the > >     one > >     that should decide what is the local ToS and deal with abuse > etc. That is > >     why I strongly argue to define "virtual world" as Region > Domain, and leave > >     the AD out of it. Nevertheless, now I have the term "Region > Domain" I don't > >     need "virtual world" anymore. > > > >     > In our new protocol, these services may either be > implemented internally > >     within > >     > a virtual world, or some might be implemented as external > services > >     offered by > >     > third parties, the choice being a policy and design > decision for each > >     world > >     > operator.  In all cases however, the virtual worlds are > defined by a set > >     of > >     > services, and not just by a Region Domain. > > > >     I'm afraid that is purely a matter of opinion. I agree that > it is likely > >     that a single 'administrative entity' that runs a RD will > also run an AD > >     and allow users authenticated with their AD visit their RD, > but it is no > >     more than *likely*. There will almost certainly be service > provides that > >     ONLY run an AD, and don't have a RD! And I can imagine that > there will > >     be some that only run a RD and do not care about running > their own AD. > > > >     Therefore, "virtual world" cannot be synonym for "the set of > services > >     run by a single administrative entity" as you seem to argue, > and at > >     the SAME time be argued to include an RD *and* AD at all > times. > > > >     > This is easy to see by looking at a couple of archetypal > examples in this > >     > space: > >     > > >     > > >     >     Is Second Life a virtual world?  Undoubtedly.  Is > Second Life just a > >     Region > >     >     Domain (assuming it were implemented using VWRAP)?  No, > of course > >     not, SL > >     >     includes all of the services mentioned above, and > others. > > > >     Of course, LL happens to run all services that are needed to > create one > >     virtual world; there are no third parties they can hire from > yet, so they > >     have to provide it all themselves. > > > >     But after SL implemented VWRAP they might decide to do away > from one of > >     their services and only keep their RD. Unlikely, but > possible. > > > >     >     Is OSgrid a virtual world?  Undoubtedly.  Is OSgrid > just a Region > >     Domain > >     >     (assuming it were implemented using VWRAP)?  No, of > course not, it > >     >     currently runs all the UGAIM services, which in a VWRAP > context would > >     >     become similar to those of Second Life. > > > >     Exact same argument. > > > >     > So you see, the idea that has been floated which claims > that "VW == RD" > >     is > >     > completely wrong, and misrepresents what constitutes a > "virtual world" > >     despite > >     > the very clear examples before us. > > > >     If you want to put it that way (including everything above > that you said) > >     then > >     I have to side with Infinity: you cannot define a virtual > world that way > >     and > >     use it for useful discussions regarding VWRAP. > > > >     In the end, one virtual world as defined by "all services > together to make > >     things work" will be, or can be, a mix of many RD's and many > AD's with a > >     complex > >     web of trust/non-trust between them that makes the concept of > "virtual > >     world" > >     rather fuzzy at best. > > > >     [...] > >     > As we move into analysis of the problem space, these issues > will be > >     > disentangled and clarified and the protocols will be > defined and evolve, > >     but > >     > from the current OGP perspective there is no symmetrical > relationship > >     possible > >     > between VWs that could be described as "peering".  It is > the asymmetry of > >     the > >     > VW-RD relationship that has been the crux of the "no VW > interop" issue. > >     For > >     > symmetrical peering, the protocol would need to mention at > least two > >     > communicating VWs. > > > >     You can about peering with just two RD's and one AD, or one > RD and two > >     AD's. > > > >     > Of course the situation could change as the protocol > evolves.  For > >     example, > >     > once or twice we have heard mention that multiple ADs could > be involved > >     in some > >     > way, and it seems certain that communication services from > multiple VWs > >     will be > >     > merged because residents demand this.  This would start to > take us into > >     VW-VW > >     > interop territory.  However, there is no such thing in > VWRAP currently, > >     and > >     > it's not in the list of deliverables to include it, and > therefore we > >     cannot say > >     > that VWRAP will provide VW-VW interop at all.  For now. ;-) > > > >     I can't comment on that cause I didn't see VWRAP yet, but > from the > >     charter and the comments on this list I'd think that full > support > >     for interop between any number of RD's and AD's is intended. > > > >     -- > >     Carlo Wood > > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx -- Carlo Wood From vaughn.deluca@gmail.com Thu Oct 1 05:31:03 2009 Return-Path: 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 13BA23A6A5D for ; Thu, 1 Oct 2009 05:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.517 X-Spam-Level: X-Spam-Status: No, score=-1.517 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Rl8+69LklTAY for ; Thu, 1 Oct 2009 05:31:02 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 364883A6A45 for ; Thu, 1 Oct 2009 05:15:23 -0700 (PDT) Received: by bwz19 with SMTP id 19so82479bwz.11 for ; Thu, 01 Oct 2009 05:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=l0ahIYq/KdwjmPsS8ccwl6WSimqFqtWyVAW6457CoD8=; b=Becn2J7lhfWTqW3MMfzN6oUmMyotK+NNeAteIX4dS4sHzINz7QMqU8JnNs/PIZwTvI JCkZdSfBBpl2ej3a7RkF/wGaN7x8Q7LnF9i571vhW5e5COSVEhV/15ZANHxBlSqm+Fe2 pTvfu0bigccNcCpGPD6ZVPghUyl1FseDMp9nU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ImY8Pz5+nGvdOeAJFV7QfhO4V/uAqm00paeFS3FwQydtLadAFhVdC/hiNZzQdQdkiK wfzxEdV9Bovh/ZPRJ7BW74qtw0Wx0tFNxd8WmId+FG7u5Kdb4dfGO6dAIrPTyeCHKX0e qds1MnnVjWqMFnQXXRnYL1qI9SmM98fEF/Luc= MIME-Version: 1.0 Received: by 10.204.24.130 with SMTP id v2mr958422bkb.33.1254399402848; Thu, 01 Oct 2009 05:16:42 -0700 (PDT) In-Reply-To: <9b8a8de40910010456m68690c17u42c121e8b0cc64e3@mail.gmail.com> References: <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <20091001105527.GA29450@alinoe.com> <9b8a8de40910010456m68690c17u42c121e8b0cc64e3@mail.gmail.com> Date: Thu, 1 Oct 2009 14:16:42 +0200 Message-ID: <9b8a8de40910010516x12dcf7e3x659b38e7708030c9@mail.gmail.com> From: Vaughn Deluca To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00032555999ed032a70474de9e1b Subject: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 12:31:03 -0000 --00032555999ed032a70474de9e1b Content-Type: text/plain; charset=ISO-8859-1 Argg, again forgot the list... ---------- Forwarded message ---------- On Thu, Oct 1, 2009 at 12:55 PM, Carlo Wood wrote: > On Wed, Sep 30, 2009 at 09:10:13AM -0700, Joshua Bell wrote: > > Without diving in too deep, I believe this thread is putting up a > two-level > > false dichotomy - either the RD determines policy or the AD determines > policy, > > OR things aren't sensible w/o nil trust. If that's a mis-reading, my > apologies. > > > > IMHO, it should be apparent that both AD (which is the agent/advocate for > the > > user) and RD (where the user wants to be) both need to make policy > decisions. > > I'd formulate this as: It is the destination (the region (domain) that the > user > is in) that determines the ToS. This is something else than the RD making > protocol-level policy decisions. The link between RD and ToS is in most > cases > not really a technical one (it will only require to use the current region > to get relevant arguments for some messages). > > Its not clear to me what you mean Carlo. How does "the RD making protocol-level policy decisions" differ from "It is the destination (the region (domain) that the user is in) that determines the ToS." Asume the RD is mature, and therefore states in its terms of service that any agent present should be above 18. An agent domain without age verification will be happy to TP its agents to that RD The RD will want to inform the AD its not going to happen. In this example I fail to see the destinction you mention above. Vaughn --00032555999ed032a70474de9e1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Argg, again forgot the list...

----------= Forwarded message ----------

On Thu, Oct 1, 2009 at 12:55 PM, Carlo = Wood <carlo@alinoe.com> wrote:
On Wed, Sep 30, 2009 at 09:10:13AM -0700, Joshua Bell wrote:
> Without diving in too deep, I believe this thread is putting up a two-= level
> false dichotomy - either the RD determines policy or the AD determines= policy,
> OR things aren't sensible w/o nil trust. If that's a mis-readi= ng, my apologies.
>
> IMHO, it should be apparent that both AD (which is the agent/advocate = for the
> user) and RD (where the user wants to be) both need to make policy dec= isions.

I'd formulate this as: It is the destination (the region (domain)= that the user
is in) that determines the ToS. This is something else than the RD making protocol-level policy decisions. The link between RD and ToS is in most cas= es
not really a technical one (it will only require to use the current region<= br> to get relevant arguments for some messages).

Its not clear to me what you mean Ca= rlo. How does=A0
"the RD making protocol-level policy decisi= ons" differ from=A0
"It is the destin= ation (the region (domain) that the user is in) that determines the ToS.&qu= ot;

Asume the RD is mature, and therefore states in i= ts terms of service that any agent present should be above 18.
An= agent domain without age verification will be happy to TP its agents to th= at RD
The RD will want to inform the AD its not going to happen. =A0In this = example I fail to see the destinction you mention above.

Vaughn
=A0

--00032555999ed032a70474de9e1b-- From carlo@alinoe.com Thu Oct 1 09:04:37 2009 Return-Path: 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 6E9C028C166 for ; Thu, 1 Oct 2009 09:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 4o70FnWoHiry for ; Thu, 1 Oct 2009 09:04:36 -0700 (PDT) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id 145AA28C17D for ; Thu, 1 Oct 2009 09:04:05 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091001160529.KOXA19940.viefep19-int.chello.at@edge02.upc.biz>; Thu, 1 Oct 2009 18:05:29 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upc.biz with edge id nU5P1c0Bn0FlQed02U5QrA; Thu, 01 Oct 2009 18:05:29 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MtOAj-0003cC-3w; Thu, 01 Oct 2009 18:06:25 +0200 Date: Thu, 1 Oct 2009 18:06:25 +0200 From: Carlo Wood To: Vaughn Deluca Message-ID: <20091001160625.GA13702@alinoe.com> References: <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <20091001105527.GA29450@alinoe.com> <9b8a8de40910010456m68690c17u42c121e8b0cc64e3@mail.gmail.com> <9b8a8de40910010516x12dcf7e3x659b38e7708030c9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b8a8de40910010516x12dcf7e3x659b38e7708030c9@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:04:37 -0000 On Thu, Oct 01, 2009 at 02:16:42PM +0200, Vaughn Deluca wrote: > Its not clear to me what you mean Carlo. How does > "the RD making protocol-level policy decisions" differ from > "It is the destination (the region (domain) that the user is in) that > determines the ToS." > > Asume the RD is mature, and therefore states in its terms of service that any > agent present should be above 18. > An agent domain without age verification will be happy to TP its agents to that > RD > The RD will want to inform the AD its not going to happen. In this example I > fail to see the destinction you mention above. Access restriction again... Take for example: some region demands that everyone is an alien of some sorts. Nobody can be rejected based on the AD they use, and no AD will refuse to teleport to the region either. Once there, the users must use an alien avatar. If they do not, then they break a local (region) rule and the administration of the region will want to warn/ban them. This is nothing to do with AD's, nor can VWRAP detect and enforce what avie you use. -- Carlo Wood From josh@lindenlab.com Thu Oct 1 09:43:34 2009 Return-Path: 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 4D6073A69C4 for ; Thu, 1 Oct 2009 09:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 Z-dQJeqlvUdp for ; Thu, 1 Oct 2009 09:43:32 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 6770A3A6AA0 for ; Thu, 1 Oct 2009 09:43:26 -0700 (PDT) Received: by yxe30 with SMTP id 30so406667yxe.29 for ; Thu, 01 Oct 2009 09:44:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.109.11 with SMTP id l11mr1261512anm.145.1254415489195; Thu, 01 Oct 2009 09:44:49 -0700 (PDT) In-Reply-To: <20091001160625.GA13702@alinoe.com> References: <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <20091001105527.GA29450@alinoe.com> <9b8a8de40910010456m68690c17u42c121e8b0cc64e3@mail.gmail.com> <9b8a8de40910010516x12dcf7e3x659b38e7708030c9@mail.gmail.com> <20091001160625.GA13702@alinoe.com> Date: Thu, 1 Oct 2009 09:44:48 -0700 Message-ID: From: Joshua Bell To: Carlo Wood Content-Type: multipart/alternative; boundary=001636ed741ba25fe10474e25d4a Cc: ogpx@ietf.org Subject: Re: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:43:34 -0000 --001636ed741ba25fe10474e25d4a Content-Type: text/plain; charset=UTF-8 Ah, I believe your point is clear now - there are policies that can be enforced at a protocol level, and policies that cannot. Thanks for bringing that up; it will be important to note so we don't make blanket statements. I would point out that this occurs on both the agent side and region side, just like access control; your agent domain may have a policy which states "no kissing anyone with cooties"; the region domain you visit may allow such hi-jinks, but the user would be violating the agent domain's policy by doing so. This is also, presumably, unenforceable by protocol. (One could imagine an extensible mechanism for machine-readable policy that could be enforced by the domains, but us creative humans can always think of examples that can't be encoded.) On Thu, Oct 1, 2009 at 9:06 AM, Carlo Wood wrote: > On Thu, Oct 01, 2009 at 02:16:42PM +0200, Vaughn Deluca wrote: > > Its not clear to me what you mean Carlo. How does > > "the RD making protocol-level policy decisions" differ from > > "It is the destination (the region (domain) that the user is in) that > > determines the ToS." > > > > Asume the RD is mature, and therefore states in its terms of service that > any > > agent present should be above 18. > > An agent domain without age verification will be happy to TP its agents > to that > > RD > > The RD will want to inform the AD its not going to happen. In this > example I > > fail to see the destinction you mention above. > > Access restriction again... > > Take for example: some region demands that everyone is an alien of > some sorts. Nobody can be rejected based on the AD they use, and no > AD will refuse to teleport to the region either. > > Once there, the users must use an alien avatar. If they do not, > then they break a local (region) rule and the administration of > the region will want to warn/ban them. This is nothing to do > with AD's, nor can VWRAP detect and enforce what avie you use. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --001636ed741ba25fe10474e25d4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah, I believe your point is clear now - there are policies that can be enfo= rced at a protocol level, and policies that cannot. Thanks for bringing tha= t up; it will be important to note so we don't make blanket statements.=

I would point out that this occurs on both the agent side and region si= de, just like access control; your agent domain may have a policy which sta= tes "no kissing anyone with cooties"; the region domain you visit= may allow such hi-jinks, but the user would be violating the agent domain&= #39;s policy by doing so. This is also, presumably, unenforceable by protoc= ol.

(One could imagine an extensible mechanism for machine-readable policy = that could be enforced by the domains, but us creative humans can always th= ink of examples that can't be encoded.)

On Thu, Oct 1, 2009 at 9:06 AM, Carlo Wood <carlo@alinoe.com> wrote:
On Thu, Oct 01, 2009 at 02:16:42PM +0200, Vaughn Deluca w= rote:
> Its not clear to me what you mean Carlo. How does
> "the RD making protocol-level policy decisions" differ from<= br> > "It is the destination (the region (domain) that the user is in) = that
> determines the ToS."
>
> Asume the RD is mature, and therefore states in its terms of service t= hat any
> agent present should be above 18.
> An agent domain without age verification will be happy to TP its agent= s to that
> RD
> The RD will want to inform the AD its not going to happen. =C2=A0In th= is example I
> fail to see the destinction you mention above.

Access restriction again...

Take for example: some region demands that everyone is an alien of
some sorts. Nobody can be rejected based on the AD they use, and no
AD will refuse to teleport to the region either.

Once there, the users must use an alien avatar. If they do not,
then they break a local (region) rule and the administration of
the region will want to warn/ban them. This is nothing to do
with AD's, nor can VWRAP detect and enforce what avie you use.

--
Carlo Wood <carlo@alinoe.com>
___________________________________= ____________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--001636ed741ba25fe10474e25d4a-- From meadhbh.siobhan@gmail.com Thu Oct 1 09:45:23 2009 Return-Path: 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 B56603A67D3 for ; Thu, 1 Oct 2009 09:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] 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 7ss0bPa0gG5r for ; Thu, 1 Oct 2009 09:45:22 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id D4BAF3A6855 for ; Thu, 1 Oct 2009 09:45:22 -0700 (PDT) Received: by pxi6 with SMTP id 6so357837pxi.32 for ; Thu, 01 Oct 2009 09:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ixZ79/RSxwn+zvyL2YrWXcIpjLU38LnN6LdHUE0XtMI=; b=K1rG3AFJ1xvZONppnI88M+C9cw+9VV7CGtNF5gte9llGy8TWuSSsn7lBzPcsYhaJuG LVxnOWhm4CUBjB70Kdix5DmsgEiKIoqVtrRH7FZ9W/Y6pQOVMjMvS4bNnHfasYW/SzBM 4K4i8cPVSSZ8WzsnsSHXm13Kp/BiqPEXdivkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VisbakEEvCFsiyjIH1eGpGSvIBBHGa4CgoDqC4PSBBMHJuDLsP62yXkmEV0DxFHsVM FJBJyXQ+Q48Q1AKkzEuCVpGzhgUh5s2PcdYC9l5i977M6I1xN8V1q777gykPru9b2iHx 0qKeq/7aZlAwkwFfIuE2C7aUo/oqerojkh6TY= MIME-Version: 1.0 Received: by 10.114.2.19 with SMTP id 19mr2428408wab.26.1254415604857; Thu, 01 Oct 2009 09:46:44 -0700 (PDT) In-Reply-To: <20091001160625.GA13702@alinoe.com> References: <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <20091001105527.GA29450@alinoe.com> <9b8a8de40910010456m68690c17u42c121e8b0cc64e3@mail.gmail.com> <9b8a8de40910010516x12dcf7e3x659b38e7708030c9@mail.gmail.com> <20091001160625.GA13702@alinoe.com> Date: Thu, 1 Oct 2009 09:46:44 -0700 Message-ID: From: Meadhbh Siobhan To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Cc: ogpx@ietf.org Subject: Re: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 16:45:23 -0000 hmm.. carlo.. while the alien example you give does describe a "policy" that can be set by a RD, for the purpose of the protocol definition, that's drifting a bit far afield. when used in the same sentence as "protocol", i think it's common to mean only those things which the participant in the protocol can detect in a reasonably automated way, and are expressed in the protocol itself. though i suppose, if we really wanted to, we could create the "alien garment tag" that allows the producer of an attachment or clothing texture to declare assets as being suitably alien in appearance, then the RD could check that all assets and garmets on an incoming avatar bear this tag. but i'm not seriously recommending we do this; just trying to give an example of what i mean when i say "policy" in describing a protocol. we've already had the debate about the meaning of the term "virtual world," i would like to get consensus that when we say "policy" in terms of a protocol, we're using it in terms of what a protocol endpoint could reasonably be assumed to be able to intuit. -cheers -meadhbh / infinity From morgaine.dinova@googlemail.com Thu Oct 1 14:32:55 2009 Return-Path: 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 2C73A3A68B9 for ; Thu, 1 Oct 2009 14:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.059 X-Spam-Level: * X-Spam-Status: No, score=1.059 tagged_above=-999 required=5 tests=[AWL=-2.376, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, SARE_FWDLOOK=1.666, SARE_UNSUB18=0.131] 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 CG499EZkS2OA for ; Thu, 1 Oct 2009 14:32:48 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 9665D3A67B3 for ; Thu, 1 Oct 2009 14:32:47 -0700 (PDT) Received: by ewy28 with SMTP id 28so750486ewy.42 for ; Thu, 01 Oct 2009 14:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=DkHqubJiuNX47a/WuvHyWvipknbrfMD0F2kAwV3EiVY=; b=pOaa9E/9KPf0iYssZ/wBoJuhw+drCHd7qYyqTdoNtpoddsiJDRuvybSRvP0AfDTeRh 4UMOrgkxbbc4G+G5okAtM9Qi+N0C2P9YTTGGlU61kM5KKx/kC7an85Q3PK5+c2JvxzRD mZGDyCKcO7gQrKDMi+DDnFIduE29gMZVJjsiE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=udZCHuzNH+15uOR/ecibBJ+9CZUKnCuAthRlAjEfMAm29rppgpn1G0Q7JJ8uC/2rgf lPIqQw2J404ML0366nOZzC+TwL/3LJlS/+oZpzVDytzfE5HvAkff0pyUMQSg9L0Pslhq Xhd3Nv3GjIBt7gzXGGhioVVikPxh5gXShSPLo= MIME-Version: 1.0 Received: by 10.211.160.4 with SMTP id m4mr2047888ebo.24.1254432850216; Thu, 01 Oct 2009 14:34:10 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090902230338.GC6652@alinoe.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Thu, 1 Oct 2009 22:34:10 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00504502d38a6e91d40474e66857 Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 21:32:55 -0000 --00504502d38a6e91d40474e66857 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell wrote: > > IMHO, it should be apparent that both AD (which is the agent/advocate for > the user) and RD (where the user wants to be) both need to make policy > decisions. > > Excellent, Joshua! I think we're finally approaching the road towards *Destination Determines Policy* now, which is a prerequisite for real interop between virtual worlds. This was simply not possible with the old OGP thinking in which policy was given by a "trust domain" defined by a single AD alone. It's a two-part problem. Naturally your *source* world can impose restrictions on travel (a walled garden may disallow any foreign travel at all, for example), that's clear. What hasn't been clear until now is that the *destination* world will have conditions which are every bit as strong and important as the source world, and represented in the same way (eg. in their AD). Both sides must be allowed equivalent representation in the protocol. This is why the single-world terminology was such a barrier earlier. It completely prevented us from bringing the two worlds into the discussion simultaneously, which is necessarily when both source and destination are completely equivalent peer worlds. Your next step is to realize that, for two structurally identical worlds, if the seat of policy of one lies in its AD, then the seat of policy of the other also lies in its AD. Therefore your statement needs to be modified to the following: IMHO, it should be apparent that both the AD of the source world and the RD and AD of the destination world all need to make policy decisions. What's true for the source world is also true for the destination world, policy-wise. The destination world is not "inferior" in any way. It's a necessary peer in the protocol. You can't exclude it from the equation. Morgaine. ========================================= On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell wrote: > Without diving in too deep, I believe this thread is putting up a two-level > false dichotomy - either the RD determines policy or the AD determines > policy, OR things aren't sensible w/o nil trust. If that's a mis-reading, my > apologies. > > IMHO, it should be apparent that both AD (which is the agent/advocate for > the user) and RD (where the user wants to be) both need to make policy > decisions. > > A corporate AD may restrict where users may visit (e.g. > agentd.corp.example.com may say "no visiting party.example.com from > work!") or an AD may restrict users based on personal preferences ( > agentd.safesurf.example.com may say "scam.example.com is on a shared > blacklist of malicious sites, teleport blocked"), legal or political > requirements (agentd.kidfriendly.example.com may say "you can't visit > adultgrid.example.com"). Note that in all cases the AD is enforcing policy > as an agent of the user, just as a web browser on a local network does > today. Presumably, there will exist many ADs that provide no restrictions > whatsoever, just as most Web browsers accessing the 'net via most ISPs in > most countries today don't restrict access to Web content via policy. > > On the flip side, the RD will also have policy. Corporate VWs may limit > access to employees. Adult-centric VWs may limit access to agents from ADs > that verify accounts with some well known service. > Real-world-region-specific RDs may require citizenship checks and deny > access to citizens of some nation-states. And of course permissions would > doubtless exist on a per-user basis as well as per-AD. Again - no different > than access permissions today on the Web, except that instead of being a > two-party user/service, it's three party user/AD/RD. And one hopes that, > like most of the Web, content is freely visitable by all. > > On the topic of nil-trust: again, I wholeheartedly support the stance that > the protocol should support nil trust operation. I hope that both the > protocol and operations of VWRAP-based worlds allow the bulk of VWRAP > traffic to occur in a nil trust environment, just like the Web does today. > However, I *suspect* that, in practical terms, the abilities we want to > grant to regions by visiting them - to display our avatars, to broadcast > information about our agents, to give and receive virtual goods - will > require at least a modicum of trust for most VW interaction, at least on the > level of an SSL-style secured connection that gives users a certificate to > look at that provides some identity/trust information about the service > provider. > > I suspect I'm going to beat this drum a lot - "VWs are just like the Web, > except where they're different" :) > > > On Tue, Sep 29, 2009 at 5:51 PM, Morgaine wrote: > >> Hi Vaughn! :-) >> >> Your description of our discussion is quite accurate. However, it seems >> to imply that I advocate in favour of the view that the AD must be the seat >> of all policy for connected regions. I do not. I was merely explaining the >> architecture of AD+RD pairing as it has been described to us repeatedly >> throughout the two years of our OGP-related work in the LL+IBM sponsored >> Architecture Working Group within Second Life. >> >> After the emails, Carlo and I examined this issue with higher discussion >> bandwidth inside SL, and it turned out that we were describing two different >> things: I was explaining the AD+RD relationship in OGP, while Carlo was >> describing RDs *as they should be designed* if an RD were an autonomous >> unit with its own policies, effectively a small world. If OGP were designed >> differently and less restrictively to allow that, then there would have been >> no discussion. :-) >> >> Of course, OGP is not VWRAP, but only the seedcorn for VWRAP. We can make >> VWRAP as flexible as we like, and it's easy to see its potential flexibility >> in David's deployments document. Consequently, I have high hopes that all >> parties will be happy with the eventual outcome. :-) >> >> You may have missed the primary reason why I do not advocate a design in >> which an OGP-style AD is the seat of all power, possibly because the >> discussion has been spread out across all of OGPX and MMOX. It's easy to >> summarize in one sentence though: such a design cannot underpin an >> Internet-wide metaverse of interoperating virtual worlds because it doesn't >> respect the key meme of virtual and non-virtual tourism: *Destination >> Determines Policy*. >> >> This meme is so fundamental and crucial (and obvious) that OGP's support >> of the exact opposite is terminally broken, as a basis for the hypothetical >> metaverse. Indeed, you yourself have referred to the problem in the funny >> "war over purple". :-) At best such a design can support only a random >> scattering of VPN-like walled gardens, all isolated and *incapable of >> interoperating* because they all claim the "one true policy". We should >> not go there. >> >> The most recent description of this problematic aspect of the OGP design >> was posted by Magnus Zeisig in his excellent email at >> http://www.ietf.org/mail-archive/web/ogpx/current/msg00324.html , which I >> fully support. Such balkanization is not a desireable goal when designing a >> VW interop protocol. >> >> So where are we now? We're at the stage of examining David's VWRAP >> deployment patterns to see how the protocol can support them. And in that >> examination, it is likely to become clear that the old OGP model of "AD >> determines policy" is completely non-viable for interoperating between >> VWRAP-compatible virtual worlds, except when that policy is "nil trust" as a >> common denominator. >> >> Consequently, we will either decide to live with the original OGP split >> and use "nil trust" as our basis for VW interop, or else we will redesign >> the AD/RD relationship to place many more important policy decisions where >> they really belong, at destination. The latter seems the best choice to me, >> and of course it would make Carlo happy, and it is also the model that every >> single existing world already operates --- when in Rome, do as the Romans >> do. Only the old OGP AD/RD two-way split design is out of step. Let's hope >> that we can correct that in VWRAP. :-)) >> >> >> Morgaine. >> >> >> >> >> >> >> ==================================== >> >> >> >> On Tue, Sep 29, 2009 at 9:16 PM, Vaughn Deluca wrote: >> >>> Carlo and Morgaine have above been involved in a very interesting >>> discussion about the nature of the (or *a*) virtual world. >>> >>> Painting their positions with broad strokes, Morgaine stresses the >>> primary role of the AD as the seat of policy and trust, up to the point >>> where he denies the RD any role above that of a convenient extension of the >>> AD, i.e. the RD as "colony without a government". Carlo passionately argues >>> for the independent role of the RD in policy issues. >>> >>> I feel that both positions are valid (to some degree), and both can be >>> covered by VWRAP. >>> >>> Calo makes absolutely clear that having all policy in the respective ADs >>> of the avatars leads to problems when several avatars meet in one region >>> domain, say RD1. Avatars will be busy killing each other over the right to >>> wear purple, and for the innocent bystanders caught in the crossfire it will >>> be fully unclear were to complain. Stepping in Morgaines shoes, i think i >>> would argue that what Carlo asks for can be realised by applying the policy >>> of a *particular* AD to RD1. The rules to deal with color of clothes, could >>> be formulated in AD1 associated with RD1. In principle Carlo could run this >>> domain himself, even without a single avatar in it, and in this way get his >>> "government" and set any policy he wants. If two avatars from AD2 and AD3 >>> visit RD1, The policy in RD1 would be governed by what is specified by AD1. >>> >>> While this fully fits Morgaines view of "AD rules all", and also fits >>> Carlo call for autonomy of RD1, it feels decidedly like a kludge, and in >>> this particular case it seems much more straightforward to make RD1 more >>> autonomous. Yet, to keep everything within one framework, this kludge seems >>> to be the logical solution... I would like to hear what others think about >>> this. >>> >>> One other remark: the minimal example for a "world" -one AD and one RD- >>> would be more useful when extended with one asset service AS. Explicit >>> mentioning of the AS will make it much easier to discuss IP issues. >>> >>> Vaughn >>> >>> >>> >>> On Mon, Sep 14, 2009 at 10:44 AM, Carlo Wood wrote: >>> >>>> On Mon, Sep 14, 2009 at 06:43:06AM +0100, Morgaine wrote: >>>> > Carlo asked for detailed comments on the below, so here goes. :-) >>>> > >>>> > >>>> > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood wrote: >>>> > >>>> > On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote: >>>> > > The problem you see is that a virtual world is much more than >>>> just a >>>> > Region >>>> > > Domain. It is a complete set of services of which the Region >>>> Domain >>>> > service is >>>> > > just one. Other typical services might be those of the Agent >>>> Domain >>>> > (which >>>> > > provides identification and authorization services and possibly >>>> others), >>>> > as >>>> > > well as asset and inventory services, IM and other communication >>>> > services, and >>>> > > maybe several more. >>>> > >>>> > Well... that is purely semantic. It is a way to define VW, but not >>>> one that >>>> > I've been using :/ >>>> > >>>> > >>>> > It's a rough top-level projection of the architectural model of VWRAP, >>>> once the >>>> > various services have been decoupled in the way that David Levine >>>> often >>>> > describes to us. Nothing very contentious there, everyone likes a >>>> > services-oriented approach. :-) >>>> > >>>> > >>>> > >>>> > For simplicity, assume that only two things are needed to create a >>>> complete >>>> > virtual world, like SL or OG: A Region Domain (RD) and an Agent >>>> Domain >>>> > (AD). >>>> > >>>> > >>>> > I am happy to consider that simple scenario as representative. It is >>>> quite >>>> > reasonable to equate AD with VW because the AD is the focus of almost >>>> all the >>>> > policy decisions of a VWRAP-based world. When other decoupled >>>> services are >>>> > added to this picture, it doesn't change the fundamental architecture >>>> of AD + >>>> > RDs, only extends it by decoupling more than just the region service. >>>> So >>>> > that's fine with me. >>>> >>>> I totally disagree that the AD is the representative...and why do you >>>> say >>>> that below a sentence of me where I say "A Region Domain (RD) and an >>>> Agent Domain (AD)"? >>>> >>>> This is like I say "VW = AD + RD", and you go: "yes, VW = AD". We can't >>>> have a discussion like that Morgaine. >>>> >>>> > Currently, without any interop, each administrative entity (or >>>> trust >>>> > entity) >>>> > will need to provide both: an RD *and* an AD, otherwise they don't >>>> have a >>>> > functional VW. >>>> > >>>> > >>>> > Correct. The AD is the seat of most (but not all) of the policy >>>> decisions of a >>>> >>>> I even *stressed* the '*and*' here, and you do it again. >>>> >>>> > VW, so it's very central to the existence of a VW. While it's >>>> possible to >>>> > imagine policy-free VWs that temporarily take on the policy of any >>>> other world >>>> > they hook up with, this is clearly a subset situation. All the >>>> currently known >>>> > SL-like virtual worlds are grids of the SL kind, with their own >>>> individual >>>> > policies which they are not going to change on interop. >>>> > >>>> > >>>> > >>>> > Your conclusion is that a VW exist of both 1 RD and 1 AD. But I >>>> ask you to >>>> > reconsider if that conclusion is correct, because it is based on >>>> the >>>> > current >>>> > situation without any interop. Now "correct" might not be the >>>> correct word >>>> > - heh. >>>> > Rather I should say: I ask you to reconsider if that definition is >>>> very >>>> > useful. >>>> > >>>> > Lets consider the following fictive case: >>>> > >>>> > LL runs one RD and AD, called RD1 and AD1. >>>> > CB (Cable Beach) runs another RD and AD, called RD2 and AD2. >>>> > A user that authenticates with either AD1 or AD2 can travel to RD1 >>>> AND RD2, >>>> > completely symmetrical, keeping their respective AD1- and AD2- >>>> assets etc. >>>> > This is possible with the right policies, so for the sake of >>>> looking at >>>> > the usefulness of the above definition of VW, assume this is the >>>> case. >>>> > >>>> > >>>> > That's not quite right because Cable Beach is not a world provider >>>> like LL. >>>> > Cable Beach is perhaps best described as a "login mediation" mechanism >>>> or >>>> >>>> I might not understand what the real Cable Beach is or wants to be, I >>>> was just >>>> trying to give an example to work with. So, again: >>>> >>>> LL runs one RD and AD, called RD1 and AD1. >>>> OG runs another RD and AD, called RD2 and AD2. >>>> A user that authenticates with either AD1 or AD2 can travel to RD1 AND >>>> RD2, >>>> completely symmetrical, keeping their respective AD1- and AD2- assets >>>> etc. >>>> This is possible with the right policies, so for the sake of looking at >>>> the usefulness of the above definition of VW, assume this is the case. >>>> >>>> > protocol, which provides a model for interaction between a "world >>>> service" >>>> > (effectively an AD), the user's client, and various decoupled services >>>> such as >>>> > simulation nodes (possibly an RD) and inventory/asset services. Let's >>>> assume >>>> > therefore that your "CB" above means something different (another >>>> world >>>> > provider similar to LL), and then we can proceed with your example >>>> case. >>>> >>>> Ok >>>> >>>> > Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be >>>> another VW? >>>> > Or do you think it would make most sense in THIS case to speak of >>>> a single >>>> > VW? >>>> > >>>> > >>>> > They're two worlds because you defined them as such, as each has its >>>> own AD. >>>> > :-) But that aside, if they were set up separately then they have two >>>> > different sets of policies, two different sets of residents, two >>>> different >>>> > ToS's, possibly two different legal jurisdictions, two different >>>> mechanisms for >>>> > abuse control and conflict resolution, and so on and so forth. If >>>> they were >>>> > created to be worlds that can stand alone but interoperate when >>>> desired, then >>>> > each of these is a diffferent world. I don't see how that can be >>>> disputed. >>>> >>>> As I stated in one of my first posts, it will (hopefully!!!) be mainly >>>> the >>>> the *RD* and NOT the AD that all of those things are a function of! >>>> >>>> You keep saying that it's mainly the AD that determines these things, >>>> but >>>> that would be confusing and very annoying. If two people meet in a >>>> virtual >>>> world, that is - if they are standing next to eachother in one region >>>> and >>>> using local chat - then they should fall under the same legal >>>> jurisdiction >>>> and the same ToS: it is the region that determines the rules, not the AD >>>> that they used to login with. >>>> >>>> As example, ToS1 says: it's ok to be naked; and ToS2 says: it's a >>>> bannable >>>> offence to be naked. Do you really think that it's even workable if the >>>> ToS to be applied is a function of the AD? Say you login using AD2, so >>>> ToS2 applies to you. You meet someone else that is naked. You know that >>>> you are not allowed to and you are offended. You create an abuse report; >>>> where does that report go to? To your AD administration? That makes no >>>> sense: that naked person is using a different AD. To his/her AD >>>> administration >>>> then? That makes also no sense since they allow it. >>>> >>>> Seriously, there is only one reasonable thing to do: the ToS that >>>> applies >>>> is a function of the Region Domain *only*, and if you write an abuse >>>> report, >>>> it should go to the administration of the region that you are in and not >>>> to your or the others AD administration. Same holds for the things >>>> related >>>> to legal jurisdiction and any other 'rules' that applies at any given >>>> moment (to users). The only thing that might be a function of the AD are >>>> technical policies that are automatically enforced by VWRAP. >>>> >>>> > I think this is what Infinity means when she says that "virtual >>>> world" >>>> > cannot >>>> > be defined, because what could be perceived as being a VW is >>>> highly >>>> > dependend >>>> > on the exact situation (and policies) and in certain configuration >>>> that are >>>> > not as clear as the current situation (no interop) or the above >>>> example >>>> > (100% >>>> > interop). >>>> > >>>> > >>>> > This is incorrect. "Virtual world" is defined by each provider of a >>>> virtual >>>> > world and by nobody else, and each provider knows full well how it is >>>> defined, >>>> > what its boundaries are, and what makes it distinct. Nobody else can >>>> define >>>> > what a virtual world is, and it's not our business to define it either >>>> (nor to >>>> > conjure up a fictitious definition). >>>> >>>> Sorry, but I think you should try harder to understand my point of view >>>> first. >>>> I didn't give the examples so you can ignore them. >>>> >>>> > We only need to define the protocol interactions at the endpoints >>>> presented by >>>> > those worlds, and not to define "virtual world" structurally nor any >>>> other way. >>>> > Doing so is what has got us into this mess, by creating a fictitious >>>> > definition based on reachability and hence blocking any ability to >>>> talk about >>>> > actual virtual worlds. Those worlds exist. They won't go away. They >>>> want to >>>> > interoperate, but they don't want to be told that they don't exist. >>>> >>>> I was trying to make you understand WHY Infinitely tells you they don't >>>> "exist", >>>> if you understand her (and you don't, imho) then it will be easier to >>>> solve this >>>> miscommunication. >>>> >>>> > The contention that we don't know what "virtual world" means is just >>>> plain >>>> > bizarre. >>>> >>>> Only if you already have a definition of "virtual world" they way you >>>> do. >>>> >>>> > I don't know of any VW operator who doesn't know what their world is. >>>> >>>> That is the *current* situation... which is 100% simpler than what we'll >>>> have in the future. >>>> >>>> Compare with math... currently we only have Integers (Z). We're about >>>> to introduce division and by that we need to extend the definition of >>>> 'number' from Z to Q. Q aren't integers, even though currently every >>>> number is an integer doesn't mean you have to hold on tight the >>>> "definition" >>>> of "number" == integer. That definition will be broken and you will >>>> have to redefine "number". >>>> >>>> > Every single one of them could provide the necessary endpoints for >>>> VWRAP >>>> > within their world without any scratching of heads at the meaning of >>>> "virtual >>>> > world". That repeated allegation has been a complete >>>> misrepresentation. It's >>>> > just not true. >>>> >>>> You CANNOT define "virtual world" as "AD" (see above) nor as "AD + RD" >>>> because >>>> that is too simple and only holds in the current situation. You can >>>> only, at most, >>>> if you really want, say - well, lets define it as being some RD. >>>> >>>> > And possibly even worse is the excuse that "virtual world" is not >>>> being >>>> > defined but is being used non-normatively, while in practice using the >>>> phrase " >>>> > the virtual world" to create a totally fictitious single virtual world >>>> instead. >>>> >>>> I agree that as long as it isn't normatively defined, the term shouldn't >>>> be >>>> used in documents except in places where it can literally mean anything >>>> without >>>> that anyone will care (like in the protocol name). >>>> >>>> > That phrase is unnecessary, it is misrepresentative of the actual >>>> situation, >>>> > it bypasses policy controls of one world by not mentioning its AD, it >>>> prevents >>>> > us from mentioning virtual worlds by blocking the normal meaning of >>>> the term, >>>> > and it provides nothing useful as a benefit in return. Unless total >>>> confusion >>>> > is a benefit. ;-) >>>> >>>> Sorry, but that is like saying that defining the Rational Numbers (Q) >>>> makes it >>>> impossible to talk about 'numbers', because 3/7 isn't an integer. >>>> What you have to do is let go of your current definition. >>>> >>>> > In one of my first posts about this topic I stated that "virtual >>>> world" >>>> > should >>>> > be considered to be the Region Domain (although I didn't use that >>>> term at >>>> > the >>>> > moment) and be completely independent of the Agent Domain, based >>>> on typical >>>> > cases of abuse and griefing etc: if anyone annoys some other user, >>>> or >>>> > breaks >>>> > almost any ToS, it will be region based; which is why I've always >>>> said that >>>> > any type of abuse can and should be handled at the sim (single >>>> region) >>>> > level: >>>> > the estate owner and managers in SL, even, but that idea >>>> definitely extends >>>> > to "world administrations": the people running the REGION (domain) >>>> is the >>>> > one >>>> > that should decide what is the local ToS and deal with abuse etc. >>>> That is >>>> > why I strongly argue to define "virtual world" as Region Domain, >>>> and leave >>>> > the AD out of it. Nevertheless, now I have the term "Region >>>> Domain" I don't >>>> > need "virtual world" anymore. >>>> > >>>> > >>>> > But that's not how OGP is structured. It's the AD that is the focus >>>> of service >>>> > policy choices in OGP, and it's the "world service" that is the focus >>>> of >>>> > service policy in Cable Beach. The AD and the world service are the >>>> source of >>>> > capabilities that determine pretty much everything else, and the >>>> region domain >>>> > is very subsidiary to that. >>>> >>>> No, if the service prodiver of some AD disagrees with the (say) a ToS >>>> that applies >>>> when you go to some RD then they should disallow you go there; they >>>> should not >>>> allow you to go there and then demand that you follow their ToS, that >>>> would not >>>> be a practical solution that is workable. >>>> >>>> To use mathematics again, it's easy to make two ToS that have no >>>> intersection: >>>> Say, ToS1 says: you MUST wear purple clothes, and ToS2 says: you MUST >>>> wear blue >>>> clothes. Obviously those will apply to regions. >>>> >>>> So then we have: >>>> >>>> Provider1: RD1 --> TOS1 --> purple clothes >>>> Provider2: RD2 --> TOS2 --> blue clothes >>>> >>>> *if* Provider 2 runs an AD (AD2) and they allow people logged in with it >>>> to go to region RD1 then the people there should wear purple clothes: >>>> TOS2 will not apply because of the AD you use. >>>> >>>> If it's against providers religious believe to support wearing purple >>>> clothes than they might disallow people to go to RD1, that is their >>>> choice (policy). >>>> >>>> > Indeed, a region domain may have no policy of its >>>> > own at all, but merely extend an existing virtual world by accepting >>>> the >>>> > policies of that world's AD. That's the model in the original OGP >>>> before it >>>> > gained aspirations of becoming a cross-VW interop protocol. >>>> >>>> That makes no sense :/ >>>> >>>> There can be any number of people in a given RD, and each can in >>>> principle >>>> be using a different AD! PLEASE let the RD determine the rules they have >>>> to live by! Anyone else that disagrees with me about that?! >>>> >>>> > If RDs determined VW policy and generated seed capabilities for >>>> everything and >>>> > ADs were merely login services then your model would apply, and RD >>>> could be >>>> > considered "VW". >>>> >>>> Ah! At last.. >>>> >>>> > But that's not how it is currently structured --- RDs are >>>> >>>> If you are refering to OGP, then OGP should be changed. >>>> >>>> > merely the land + physical simulation components of worlds, and in >>>> SL's case, >>>> > also an elaborate system of proxies. And that's why we need multiple >>>> ADs to >>>> > interact in VWRAP before we can consider that there is VW-VW interop. >>>> RDs >>>> > don't handle it. >>>> >>>> What I seem to keep missing is the fact that VWRAP is already completely >>>> defined in those previous OGP documents and we're merely here to rewrite >>>> them in an IETF document of sorts. >>>> >>>> Yes we need multiple ADs to interact, and they will. >>>> But yes, RD's will handle whatever they have to handle with VWRAP. >>>> I never said that capabilities equal 'rules' (ToS and legal jurisdiction >>>> isn't something that should be enforced or controlled by the protocol) >>>> by >>>> the way. >>>> >>>> ... sorry my RSI forces me to stop typing here... shouldn't have >>>> typed this much alrady anyway :( >>>> >>>> > > In our new protocol, these services may either be implemented >>>> internally >>>> > within >>>> > > a virtual world, or some might be implemented as external >>>> services >>>> > offered by >>>> > > third parties, the choice being a policy and design decision for >>>> each >>>> > world >>>> > > operator. In all cases however, the virtual worlds are defined >>>> by a set >>>> > of >>>> > > services, and not just by a Region Domain. >>>> > >>>> > >>>> > Indeed. But access to such decoupled services is provided by the AD >>>> through >>>> > the capabilities that it delivers to authorized parties, and regions >>>> are just >>>> > one such service. You're giving RDs credit for something that they >>>> don't do. >>>> > :-) Perhaps the VWRAP model should be redesigned along your lines so >>>> that RDs >>>> > become the VWs and are the generators of seed caps, and then ADs >>>> become just a >>>> > subservient policy-free login mechanism. :D >>>> > >>>> > >>>> > >>>> > I'm afraid that is purely a matter of opinion. I agree that it is >>>> likely >>>> > that a single 'administrative entity' that runs a RD will also run >>>> an AD >>>> > and allow users authenticated with their AD visit their RD, but it >>>> is no >>>> > more than *likely*. There will almost certainly be service >>>> provides that >>>> > ONLY run an AD, and don't have a RD! And I can imagine that there >>>> will >>>> > be some that only run a RD and do not care about running their own >>>> AD. >>>> > >>>> > >>>> > Oh sure, there will be all combinations of services, that is to be >>>> expected. >>>> > But it is the seat of policy that is the heart of each virtual world, >>>> and >>>> > currently the seat of policy lies in the AD. A VW that doesn't have >>>> an AD in >>>> > the VWRAP model is just a colony without a government, ready to be >>>> assimilated >>>> > into a world that has an AD and that therefore sets policies, instead >>>> of being >>>> > a sovereign world that merely wants to interop with that other world >>>> through >>>> > VWRAP. >>>> > >>>> > >>>> > >>>> > Therefore, "virtual world" cannot be synonym for "the set of >>>> services >>>> > run by a single administrative entity" as you seem to argue, and >>>> at >>>> > the SAME time be argued to include an RD *and* AD at all times. >>>> > >>>> > >>>> > I don't follow that. Two worlds that can run independently (that's >>>> very >>>> > important) can certainly each be defined as a set of services that >>>> includes the >>>> > functions of an AD and an RD, and those worlds each continue to >>>> include the >>>> > functions of an AD and an RD even after they start interoperating >>>> (assuming >>>> > that VWRAP is extended to allow cross-VW interop). No world is going >>>> to give >>>> > up part of its services portfolio on interop. Interop is an >>>> additional >>>> > benefit, not a loss of capability. >>>> > >>>> > [It's worth noting that there may actually be a small loss of >>>> capability >>>> > occurring on interop in VWRAP, although it is rarely mentioned. You >>>> can be >>>> > present in two worlds simultaneously with the same login credentials >>>> > pre-interop (a feature that we enjoy currently between SL and OSgrid >>>> for >>>> > example), but post-interop this may no longer be possible --- it >>>> depends on the >>>> > implementation. No doubt we will visit this issue within VWRAP.] >>>> > >>>> > >>>> > >>>> > > This is easy to see by looking at a couple of archetypal >>>> examples in this >>>> > > space: >>>> > > >>>> > > >>>> > > Is Second Life a virtual world? Undoubtedly. Is Second >>>> Life just a >>>> > Region >>>> > > Domain (assuming it were implemented using VWRAP)? No, of >>>> course >>>> > not, SL >>>> > > includes all of the services mentioned above, and others. >>>> > >>>> > Of course, LL happens to run all services that are needed to >>>> create one >>>> > virtual world; there are no third parties they can hire from yet, >>>> so they >>>> > have to provide it all themselves. >>>> > >>>> > But after SL implemented VWRAP they might decide to do away from >>>> one of >>>> > their services and only keep their RD. Unlikely, but possible. >>>> > >>>> > >>>> > You're confusing RD functionality with AD functionality again there. >>>> The AD is >>>> > the heart of a world because it defines its capabilities and policies. >>>> The RD >>>> > is just a pile of region hosts that could easily be farmed out to a >>>> third party >>>> > to run without them determining policy, and indeed this is already >>>> being done. >>>> > While it is a very important pile of hosts which gives a world its >>>> physical >>>> > characterists, the RD is a subservient service to the AD in OGP, just >>>> as the >>>> > equivalent "simulation nodes" provide a subservient service to the >>>> "world >>>> > service" under Cable Beach. The RD is well named --- it provides >>>> region >>>> > services only, not the package of internal + external services that >>>> together >>>> > create a virtual world. >>>> > >>>> > >>>> > >>>> > > Is OSgrid a virtual world? Undoubtedly. Is OSgrid just a >>>> Region >>>> > Domain >>>> > > (assuming it were implemented using VWRAP)? No, of course >>>> not, it >>>> > > currently runs all the UGAIM services, which in a VWRAP >>>> context would >>>> > > become similar to those of Second Life. >>>> > >>>> > Exact same argument. >>>> > >>>> > >>>> > Exact same response because the same applies. :-) What's more, in >>>> OSgrid this >>>> > is even easier to identify, because every person or company that adds >>>> regions >>>> > to OSgrid is subscribing to the notion that they are participants in >>>> OSgrid --- >>>> > OSgrid is their virtual world. They are merely providing additional >>>> land mass >>>> > and simulation capacity. >>>> > >>>> > Also, in this example there is no need to hypothesize region services >>>> being >>>> > farmed out to third parties, as there already are hundreds to >>>> thousands of >>>> > independent third parties involved in supplying regions. Those >>>> regions and >>>> > clusters of regions (equivalent to RDs) together combine to create the >>>> virtual >>>> > world of OSgrid. There is a clear distinction between R/RDs here and >>>> the VW >>>> > itself, which also includes a variety of other services as Charles has >>>> > described several times. The R/RDs are a very important part, but >>>> functionally >>>> > they are not the VW, nor are they the VW perceptually. They are >>>> places within >>>> > the world, not the whole world. >>>> > >>>> > >>>> > >>>> > > So you see, the idea that has been floated which claims that "VW >>>> == RD" >>>> > is >>>> > > completely wrong, and misrepresents what constitutes a "virtual >>>> world" >>>> > despite >>>> > > the very clear examples before us. >>>> > >>>> > If you want to put it that way (including everything above that >>>> you said) >>>> > then >>>> > I have to side with Infinity: you cannot define a virtual world >>>> that way >>>> > and >>>> > use it for useful discussions regarding VWRAP. >>>> > >>>> > >>>> > I think you may have misread that. I did not define "VW == RD". >>>> That's the >>>> > opposite of what I said, but I agree with you on the negative >>>> conclusion. If >>>> > one defines "VW == RD" then it becomes impossible to have a meaningful >>>> > discussion about VWs in VWRAP. It also becomes impossible to have a >>>> meaningful >>>> > discussion about VWs in VWRAP if one conjures up a fictitious meaning >>>> of >>>> > "virtual world" based on reachability. And that's why we should not >>>> define it >>>> > in either of those two ways. >>>> > >>>> > The most useful and forward-looking way of defining virtual worlds in >>>> VWRAP is >>>> > as a collection of service endpoints, regardless of who operates them. >>>> All we >>>> > should care about is the protocol between endpoints, and not conjure >>>> up some >>>> > non-existent single virtual world. >>>> > >>>> > >>>> > >>>> > In the end, one virtual world as defined by "all services together >>>> to make >>>> > things work" will be, or can be, a mix of many RD's and many AD's >>>> with a >>>> > complex >>>> > web of trust/non-trust between them that makes the concept of >>>> "virtual >>>> > world" >>>> > rather fuzzy at best. >>>> > >>>> > >>>> > You're right but you're not being clear about what is fuzzy. The >>>> concept of " >>>> > single virtual world" is not only fuzzy, it is totally non-existent in >>>> practice >>>> > (because there are many, not one) as well as impossible in theory >>>> because of >>>> > balkanization through incompatible trust domains, as described so >>>> magnificently >>>> > by Magnus a week or two ago. We should not go there. >>>> > >>>> > In contrast, the concept of multiple virtual worlds is crystal clear. >>>> Several >>>> > people here in the group operate virtual worlds, but nobody would >>>> suggest that >>>> > they are unclear about what they operate. We've been sold a bridge on >>>> that >>>> > "uncertainty". Multiple virtual worlds presenting VWRAP endpoints are >>>> the >>>> > natural way of approaching interop between VWs, and you don't have to >>>> define >>>> > VWs structurally for that. You only have to define the endpoints that >>>> VWs need >>>> > to present to the protocol, and avoid any notion of "single virtual >>>> world". >>>> > >>>> > >>>> > >>>> > [...] >>>> > > As we move into analysis of the problem space, these issues will >>>> be >>>> > > disentangled and clarified and the protocols will be defined and >>>> evolve, >>>> > but >>>> > > from the current OGP perspective there is no symmetrical >>>> relationship >>>> > possible >>>> > > between VWs that could be described as "peering". It is the >>>> asymmetry of >>>> > the >>>> > > VW-RD relationship that has been the crux of the "no VW interop" >>>> issue. >>>> > For >>>> > > symmetrical peering, the protocol would need to mention at least >>>> two >>>> > > communicating VWs. >>>> > >>>> > You can about peering with just two RD's and one AD, or one RD and >>>> two >>>> > AD's. >>>> > >>>> > >>>> > I think you're confusing RDs with VWs again --- RDs only provide >>>> regions, >>>> > nothing else. For peering between two VWs, you would need interaction >>>> between >>>> > their two ADs because their ADs provide their policies. If you bypass >>>> a VW's >>>> > AD then you bypass its policies, so you're not interoping with that >>>> world. And >>>> > I don't think we're encouraging bypassing and hence subverting a >>>> world's >>>> > policies. >>>> > >>>> > >>>> > >>>> > > Of course the situation could change as the protocol evolves. >>>> For >>>> > example, >>>> > > once or twice we have heard mention that multiple ADs could be >>>> involved >>>> > in some >>>> > > way, and it seems certain that communication services from >>>> multiple VWs >>>> > will be >>>> > > merged because residents demand this. This would start to take >>>> us into >>>> > VW-VW >>>> > > interop territory. However, there is no such thing in VWRAP >>>> currently, >>>> > and >>>> > > it's not in the list of deliverables to include it, and >>>> therefore we >>>> > cannot say >>>> > > that VWRAP will provide VW-VW interop at all. For now. ;-) >>>> > >>>> > I can't comment on that cause I didn't see VWRAP yet, but from the >>>> > charter and the comments on this list I'd think that full support >>>> > for interop between any number of RD's and AD's is intended. >>>> > >>>> > >>>> > Well you've put your finger on the problem here. Everyone is saying >>>> what they >>>> > think is intended because the intention is not actually spelled out in >>>> the >>>> > documents. Why cannot it be spelled out clearly that interop between >>>> multiple >>>> > ADs is intended? If it were, this entire discussion could be avoided >>>> because >>>> > it's easy and reasonable to equate ADs with VWs in practice. >>>> > >>>> > Notice however that even if the protocol were modified to be able to >>>> handle two >>>> > ADs at a time, use of an unadorned "the virtual world" in the >>>> documents would >>>> > continue to raise the perennial question of "Which virtual world?". >>>> After all, >>>> > there would be two of them being discussed. >>>> > >>>> > It's this phraseology that stems from OGP's original goal of adding >>>> single >>>> > regions or RDs to an existing single virtual world (namely SL in the >>>> prototype) >>>> > that is creating such a problem. That phraseology was appropriate for >>>> that >>>> > original goal. It is not appropriate for the goal of interoperating >>>> multiple >>>> > virtual worlds --- it makes it impossible to even talk about the goal >>>> sensibly, >>>> > because "the virtual world" in the OGP sense has no plural. >>>> > >>>> > It's unfortunate, but this whole affair is just the product of legacy >>>> wording >>>> > from OGP. That's never going to work in a multi-world setting where >>>> we need to >>>> > talk about the endpoints in different worlds. >>>> > >>>> > >>>> > Morgaine. >>>> > >>>> > PS. If anyone else read this far other than Carlo, you have a lot of >>>> stamina >>>> > and dedication. ;-) >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > ============================================== >>>> > >>>> > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood wrote: >>>> > >>>> > On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote: >>>> > > The problem you see is that a virtual world is much more than >>>> just a >>>> > Region >>>> > > Domain. It is a complete set of services of which the Region >>>> Domain >>>> > service is >>>> > > just one. Other typical services might be those of the Agent >>>> Domain >>>> > (which >>>> > > provides identification and authorization services and possibly >>>> others), >>>> > as >>>> > > well as asset and inventory services, IM and other communication >>>> > services, and >>>> > > maybe several more. >>>> > >>>> > Well... that is purely semantic. It is a way to define VW, but not >>>> one that >>>> > I've been using :/ >>>> > >>>> > For simplicity, assume that only two things are needed to create a >>>> complete >>>> > virtual world, like SL or OG: A Region Domain (RD) and an Agent >>>> Domain >>>> > (AD). >>>> > >>>> > Currently, without any interop, each administrative entity (or >>>> trust >>>> > entity) >>>> > will need to provide both: an RD *and* an AD, otherwise they don't >>>> have a >>>> > functional VW. >>>> > >>>> > Your conclusion is that a VW exist of both 1 RD and 1 AD. But I >>>> ask you to >>>> > reconsider if that conclusion is correct, because it is based on >>>> the >>>> > current >>>> > situation without any interop. Now "correct" might not be the >>>> correct word >>>> > - heh. >>>> > Rather I should say: I ask you to reconsider if that definition is >>>> very >>>> > useful. >>>> > >>>> > Lets consider the following fictive case: >>>> > >>>> > LL runs one RD and AD, called RD1 and AD1. >>>> > CB (Cable Beach) runs another RD and AD, called RD2 and AD2. >>>> > A user that authenticates with either AD1 or AD2 can travel to RD1 >>>> AND RD2, >>>> > completely symmetrical, keeping their respective AD1- and AD2- >>>> assets etc. >>>> > This is possible with the right policies, so for the sake of >>>> looking at >>>> > the usefulness of the above definition of VW, assume this is the >>>> case. >>>> > >>>> > Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be >>>> another VW? >>>> > Or do you think it would make most sense in THIS case to speak of >>>> a single >>>> > VW? >>>> > >>>> > I think this is what Infinity means when she says that "virtual >>>> world" >>>> > cannot >>>> > be defined, because what could be perceived as being a VW is >>>> highly >>>> > dependend >>>> > on the exact situation (and policies) and in certain configuration >>>> that are >>>> > not as clear as the current situation (no interop) or the above >>>> example >>>> > (100% >>>> > interop). >>>> > >>>> > In one of my first posts about this topic I stated that "virtual >>>> world" >>>> > should >>>> > be considered to be the Region Domain (although I didn't use that >>>> term at >>>> > the >>>> > moment) and be completely independent of the Agent Domain, based >>>> on typical >>>> > cases of abuse and griefing etc: if anyone annoys some other user, >>>> or >>>> > breaks >>>> > almost any ToS, it will be region based; which is why I've always >>>> said that >>>> > any type of abuse can and should be handled at the sim (single >>>> region) >>>> > level: >>>> > the estate owner and managers in SL, even, but that idea >>>> definitely extends >>>> > to "world administrations": the people running the REGION (domain) >>>> is the >>>> > one >>>> > that should decide what is the local ToS and deal with abuse etc. >>>> That is >>>> > why I strongly argue to define "virtual world" as Region Domain, >>>> and leave >>>> > the AD out of it. Nevertheless, now I have the term "Region >>>> Domain" I don't >>>> > need "virtual world" anymore. >>>> > >>>> > > In our new protocol, these services may either be implemented >>>> internally >>>> > within >>>> > > a virtual world, or some might be implemented as external >>>> services >>>> > offered by >>>> > > third parties, the choice being a policy and design decision for >>>> each >>>> > world >>>> > > operator. In all cases however, the virtual worlds are defined >>>> by a set >>>> > of >>>> > > services, and not just by a Region Domain. >>>> > >>>> > I'm afraid that is purely a matter of opinion. I agree that it is >>>> likely >>>> > that a single 'administrative entity' that runs a RD will also run >>>> an AD >>>> > and allow users authenticated with their AD visit their RD, but it >>>> is no >>>> > more than *likely*. There will almost certainly be service >>>> provides that >>>> > ONLY run an AD, and don't have a RD! And I can imagine that there >>>> will >>>> > be some that only run a RD and do not care about running their own >>>> AD. >>>> > >>>> > Therefore, "virtual world" cannot be synonym for "the set of >>>> services >>>> > run by a single administrative entity" as you seem to argue, and >>>> at >>>> > the SAME time be argued to include an RD *and* AD at all times. >>>> > >>>> > > This is easy to see by looking at a couple of archetypal >>>> examples in this >>>> > > space: >>>> > > >>>> > > >>>> > > Is Second Life a virtual world? Undoubtedly. Is Second >>>> Life just a >>>> > Region >>>> > > Domain (assuming it were implemented using VWRAP)? No, of >>>> course >>>> > not, SL >>>> > > includes all of the services mentioned above, and others. >>>> > >>>> > Of course, LL happens to run all services that are needed to >>>> create one >>>> > virtual world; there are no third parties they can hire from yet, >>>> so they >>>> > have to provide it all themselves. >>>> > >>>> > But after SL implemented VWRAP they might decide to do away from >>>> one of >>>> > their services and only keep their RD. Unlikely, but possible. >>>> > >>>> > > Is OSgrid a virtual world? Undoubtedly. Is OSgrid just a >>>> Region >>>> > Domain >>>> > > (assuming it were implemented using VWRAP)? No, of course >>>> not, it >>>> > > currently runs all the UGAIM services, which in a VWRAP >>>> context would >>>> > > become similar to those of Second Life. >>>> > >>>> > Exact same argument. >>>> > >>>> > > So you see, the idea that has been floated which claims that "VW >>>> == RD" >>>> > is >>>> > > completely wrong, and misrepresents what constitutes a "virtual >>>> world" >>>> > despite >>>> > > the very clear examples before us. >>>> > >>>> > If you want to put it that way (including everything above that >>>> you said) >>>> > then >>>> > I have to side with Infinity: you cannot define a virtual world >>>> that way >>>> > and >>>> > use it for useful discussions regarding VWRAP. >>>> > >>>> > In the end, one virtual world as defined by "all services together >>>> to make >>>> > things work" will be, or can be, a mix of many RD's and many AD's >>>> with a >>>> > complex >>>> > web of trust/non-trust between them that makes the concept of >>>> "virtual >>>> > world" >>>> > rather fuzzy at best. >>>> > >>>> > [...] >>>> > > As we move into analysis of the problem space, these issues will >>>> be >>>> > > disentangled and clarified and the protocols will be defined and >>>> evolve, >>>> > but >>>> > > from the current OGP perspective there is no symmetrical >>>> relationship >>>> > possible >>>> > > between VWs that could be described as "peering". It is the >>>> asymmetry of >>>> > the >>>> > > VW-RD relationship that has been the crux of the "no VW interop" >>>> issue. >>>> > For >>>> > > symmetrical peering, the protocol would need to mention at least >>>> two >>>> > > communicating VWs. >>>> > >>>> > You can about peering with just two RD's and one AD, or one RD and >>>> two >>>> > AD's. >>>> > >>>> > > Of course the situation could change as the protocol evolves. >>>> For >>>> > example, >>>> > > once or twice we have heard mention that multiple ADs could be >>>> involved >>>> > in some >>>> > > way, and it seems certain that communication services from >>>> multiple VWs >>>> > will be >>>> > > merged because residents demand this. This would start to take >>>> us into >>>> > VW-VW >>>> > > interop territory. However, there is no such thing in VWRAP >>>> currently, >>>> > and >>>> > > it's not in the list of deliverables to include it, and >>>> therefore we >>>> > cannot say >>>> > > that VWRAP will provide VW-VW interop at all. For now. ;-) >>>> > >>>> > I can't comment on that cause I didn't see VWRAP yet, but from the >>>> > charter and the comments on this list I'd think that full support >>>> > for interop between any number of RD's and AD's is intended. >>>> > >>>> > -- >>>> > Carlo Wood >>>> > >>>> > >>>> >>>> > _______________________________________________ >>>> > ogpx mailing list >>>> > ogpx@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/ogpx >>>> >>>> >>>> -- >>>> Carlo Wood >>>> _______________________________________________ >>>> ogpx mailing list >>>> ogpx@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ogpx >>>> >>> >>> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00504502d38a6e91d40474e66857 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell <josh@lindenlab.com> wrote:
=

IMHO, it should be apparent that both AD (which is the agent/advocate for the user) and RD (where the user wants to be) both need to make policy decisions.


Excellent, Jos= hua!

I think we're finally approaching the road towards Desti= nation Determines Policy now, which is a prerequisite for real interop = between virtual worlds.=A0 This was simply not possible with the old OGP th= inking in which policy was given by a "trust domain" defined by a= single AD alone.

It's a two-part problem.=A0 Naturally your source world can = impose restrictions on travel (a walled garden may disallow any foreign tra= vel at all, for example), that's clear.=A0 What hasn't been clear u= ntil now is that the destination world will have conditions which ar= e every bit as strong and important as the source world, and represented in= the same way (eg. in their AD).=A0 Both sides must be allowed equivalent r= epresentation in the protocol.

This is why the single-world terminology was such a barrier earlier.=A0= It completely prevented us from bringing the two worlds into the discussio= n simultaneously, which is necessarily when both source and destination are= completely equivalent peer worlds.

Your next step is to realize that, for two structurally identical= worlds, if the seat of policy of one lies in its AD, then the seat of poli= cy of the other also lies in its AD.=A0 Therefore your statement needs to b= e modified to the following:

IMHO, it should be apparent that both= the AD of the source world and the RD and AD of the destination world all need to make policy decisions.


What's true for the sou= rce world is also true for the destination world, policy-wise.=A0 The desti= nation world is not "inferior" in any way.=A0 It's a necessar= y peer in the protocol.=A0 You can't exclude it from the equation.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

On Wed, Sep 30, 200= 9 at 5:10 PM, Joshua Bell <josh@lindenlab.com> wrote:
Without diving in= too deep, I believe this thread is putting up a two-level false dichotomy = - either the RD determines policy or the AD determines policy, OR things ar= en't sensible w/o nil trust. If that's a mis-reading, my apologies.=

IMHO, it should be apparent that both AD (which is the agent/advocate f= or the user) and RD (where the user wants to be) both need to make policy d= ecisions.

A corporate AD may restrict where users may visit (e.g. <= a href=3D"http://agentd.corp.example.com" target=3D"_blank">agentd.corp.exa= mple.com may say "no visiting party.example.com from work!") or an AD may res= trict users based on personal preferences (agentd.safesurf.example.com may say &q= uot;scam.example.com<= /a> is on a shared blacklist of malicious sites, teleport blocked"), l= egal or political requirements (agentd.kidfriendly.example.com may say "y= ou can't visit adultgrid.example.com"). Note that in all cases the AD is enfor= cing policy as an agent of the user, just as a web browser on a local netwo= rk does today. Presumably, there will exist many ADs that provide no restri= ctions whatsoever, just as most Web browsers accessing the 'net via mos= t ISPs in most countries today don't restrict access to Web content via= policy.

On the flip side, the RD will also have policy. Corporate VWs may limit= access to employees. Adult-centric VWs may limit access to agents from ADs= that verify accounts with some well known service. Real-world-region-speci= fic RDs may require citizenship checks and deny access to citizens of some = nation-states. And of course permissions would doubtless exist on a per-use= r basis as well as per-AD. Again - no different than access permissions tod= ay on the Web, except that instead of being a two-party user/service, it= 9;s three party user/AD/RD. And one hopes that, like most of the Web, conte= nt is freely visitable by all.

On the topic of nil-trust: again, I wholeheartedly support the stance t= hat the protocol should support nil trust operation. I hope that both the p= rotocol and operations of VWRAP-based worlds allow the bulk of VWRAP traffi= c to occur in a nil trust environment, just like the Web does today. Howeve= r, I *suspect* that, in practical terms, the abilities we want to grant to = regions by visiting them - to display our avatars, to broadcast information= about our agents, to give and receive virtual goods - will require at leas= t a modicum of trust for most VW interaction, at least on the level of an S= SL-style secured connection that gives users a certificate to look at that = provides some identity/trust information about the service provider.

I suspect I'm going to beat this drum a lot - "VWs are just li= ke the Web, except where they're different" :)


On Tue, Sep 29, 2009 at 5:= 51 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Hi Vaughn! :-)
Your description of our discussion is quite accurate.=A0 However, it s= eems to imply that I advocate in favour of the view that the AD must be the= seat of all policy for connected regions.=A0 I do not.=A0 I was merely exp= laining the architecture of AD+RD pairing as it has been described to us re= peatedly throughout the two years of our OGP-related work in the LL+IBM spo= nsored Architecture Working Group within Second Life.

After the emails, Carlo and I examined this issue with higher discussio= n bandwidth inside SL, and it turned out that we were describing two differ= ent things:=A0 I was explaining the AD+RD relationship in OGP, while Carlo = was describing RDs as they should be designed if an RD were an auton= omous unit with its own policies, effectively a small world.=A0 If OGP were= designed differently and less restrictively to allow that, then there woul= d have been no discussion.=A0 :-)

Of course, OGP is not VWRAP, but only the seedcorn for VWRAP.=A0 We can= make VWRAP as flexible as we like, and it's easy to see its potential = flexibility in David's deployments document.=A0 Consequently, I have hi= gh hopes that all parties will be happy with the eventual outcome. :-)

You may have missed the primary reason why I do not advocate a design i= n which an OGP-style AD is the seat of all power, possibly because the disc= ussion has been spread out across all of OGPX and MMOX.=A0 It's easy to= summarize in one sentence though:=A0 such a design cannot underpin an Inte= rnet-wide metaverse of interoperating virtual worlds because it doesn't= respect the key meme of virtual and non-virtual tourism:=A0 Destination= Determines Policy.

This meme is so fundamental and crucial (and obvious) that OGP's su= pport of the exact opposite is terminally broken, as a basis for the hypoth= etical metaverse.=A0 Indeed, you yourself have referred to the problem in t= he funny "war over purple". :-)=A0 At best such a design can supp= ort only a random scattering of VPN-like walled gardens, all isolated and <= i>incapable of interoperating because they all claim the "o= ne true policy".=A0 We should not go there.

The most recent description of this problematic aspect of the OGP desig= n was posted by Magnus Zeisig in his excellent email at = http://www.ietf.org/mail-archive/web/ogpx/current/msg00324.html , which= I fully support.=A0 Such balkanization is not a desireable goal when desig= ning a VW interop protocol.

So where are we now?=A0 We're at the stage of examining David's= VWRAP deployment patterns to see how the protocol can support them.=A0 And= in that examination, it is likely to become clear that the old OGP model o= f "AD determines policy" is completely non-viable for interoperat= ing between VWRAP-compatible virtual worlds, except when that policy is &qu= ot;nil trust" as a common denominator.

Consequently, we will either decide to live with the original OGP split= and use "nil trust" as our basis for VW interop, or else we will= redesign the AD/RD relationship to place many more important policy decisi= ons where they really belong, at destination.=A0 The latter seems the best = choice to me, and of course it would make Carlo happy, and it is also the m= odel that every single existing world already operates --- when in Rome, do= as the Romans do.=A0 Only the old OGP AD/RD two-way split design is out of= step.=A0 Let's hope that we can correct that in VWRAP. :-))


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D



On Tu= e, Sep 29, 2009 at 9:16 PM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
Carlo and Mo= rgaine have above been involved in a very interesting discussion about the = nature of the (or *a*) virtual world.=A0

Painting their positions with =A0broad strokes, Morgain= e stresses the primary role of the AD as the seat of policy and trust, up t= o the point where he denies the RD any role above that of a convenient exte= nsion of the AD, i.e. the RD as "colony without a government". Ca= rlo passionately argues for the independent role of the RD in policy issues= .

I feel that both positions are valid (to some degree), = and both can be covered by VWRAP.

Calo makes absol= utely clear that having all policy in the respective ADs of the avatars lea= ds to problems when several avatars meet in one region domain, say RD1. Ava= tars will be busy killing each other over the right to wear purple, and for= the innocent bystanders caught in the crossfire it will be fully unclear w= ere to complain. Stepping in Morgaines shoes, i think i would argue that wh= at Carlo asks for can be realised by applying the policy of a *particular* = AD to RD1. The rules to deal with color of clothes, could be formulated in = AD1 associated with RD1. In principle Carlo could run this domain himself, = even without a single avatar in it, and in this way get his "governmen= t" and set any policy he wants. If two avatars from AD2 and AD3 visit = RD1, The policy in RD1 would be governed by what is specified by AD1.

While this fully fits Morgaines view of "AD rules = all", and also fits Carlo call for autonomy of RD1, it feels decidedly= like a kludge, and in this particular case it seems much more straightforw= ard to make RD1 more autonomous. Yet, to keep everything within one framewo= rk, this kludge seems to be the logical solution... I would like to hear wh= at others think about this.

One other remark: the minimal example for =A0a "wo= rld" =A0-one AD and one RD- would be more useful when extended with on= e asset service AS. Explicit mentioning of the AS will make it much easier = to discuss IP issues.=A0

Vaughn



On Mo= n, Sep 14, 2009 at 10:44 AM, Carlo Wood <carlo@alinoe.com> wr= ote:
<= div>On Mon, Sep 14, 2009 at 06:43:06AM +0100, Morgaine wrote:
> Carlo asked for detailed comments on the below, so here goes. :-)
>
>
> On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood <carlo@alinoe.com> wrote:
>
> =A0 =A0 On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote:
> =A0 =A0 > The problem you see is that a virtual world is much more = than just a
> =A0 =A0 Region
> =A0 =A0 > Domain. =A0It is a complete set of services of which the = Region Domain
> =A0 =A0 service is
> =A0 =A0 > just one. =A0Other typical services might be those of the= Agent Domain
> =A0 =A0 (which
> =A0 =A0 > provides identification and authorization services and po= ssibly others),
> =A0 =A0 as
> =A0 =A0 > well as asset and inventory services, IM and other commun= ication
> =A0 =A0 services, and
> =A0 =A0 > maybe several more.
>
> =A0 =A0 Well... that is purely semantic. It is a way to define VW, but= not one that
> =A0 =A0 I've been using :/
>
>
> It's a rough top-level projection of the architectural model of VW= RAP, once the
> various services have been decoupled in the way that David Levine ofte= n
> describes to us. =A0Nothing very contentious there, everyone likes a > services-oriented approach. :-)
>
>
>
> =A0 =A0 For simplicity, assume that only two things are needed to crea= te a complete
> =A0 =A0 virtual world, like SL or OG: A Region Domain (RD) and an Agen= t Domain
> =A0 =A0 (AD).
>
>
> I am happy to consider that simple scenario as representative. =A0It i= s quite
> reasonable to equate AD with VW because the AD is the focus of almost = all the
> policy decisions of a VWRAP-based world. =A0When other decoupled servi= ces are
> added to this picture, it doesn't change the fundamental architect= ure of AD +
> RDs, only extends it by decoupling more than just the region service. = =A0So
> that's fine with me.

I totally disagree that the AD is the representative...and why = do you say
that below a sentence of me where I say "A Region Domain (RD) and an A= gent Domain (AD)"?

This is like I say "VW =3D AD + RD", and you go: "yes, VW = =3D AD". We can't
have a discussion like that Morgaine.

> =A0 =A0 Currently, without any interop, each administrative entity (or= trust
> =A0 =A0 entity)
> =A0 =A0 will need to provide both: an RD *and* an AD, otherwise they d= on't have a
> =A0 =A0 functional VW.
>
>
> Correct. =A0The AD is the seat of most (but not all) of the policy dec= isions of a

I even *stressed* the '*and*' here, and you do it again.

> VW, so it's very central to the existence of a VW. =A0While it'= ;s possible to
> imagine policy-free VWs that temporarily =A0take on the policy of any = other world
> they hook up with, this is clearly a subset situation. =A0All the curr= ently known
> SL-like virtual worlds are grids of the SL kind, with their own indivi= dual
> policies which they are not going to change on interop.
>
>
>
> =A0 =A0 Your conclusion is that a VW exist of both 1 RD and 1 AD. But = I ask you to
> =A0 =A0 reconsider if that conclusion is correct, because it is based = on the
> =A0 =A0 current
> =A0 =A0 situation without any interop. Now "correct" might n= ot be the correct word
> =A0 =A0 - heh.
> =A0 =A0 Rather I should say: I ask you to reconsider if that definitio= n is very
> =A0 =A0 useful.
>
> =A0 =A0 Lets consider the following fictive case:
>
> =A0 =A0 LL runs one RD and AD, called RD1 and AD1.
> =A0 =A0 CB (Cable Beach) runs another RD and AD, called RD2 and AD2. > =A0 =A0 A user that authenticates with either AD1 or AD2 can travel to= RD1 AND RD2,
> =A0 =A0 completely symmetrical, keeping their respective AD1- and AD2-= assets etc.
> =A0 =A0 This is possible with the right policies, so for the sake of l= ooking at
> =A0 =A0 the usefulness of the above definition of VW, assume this is t= he case.
>
>
> That's not quite right because Cable Beach is not a world provider= like LL.
> Cable Beach is perhaps best described as a "login mediation"= mechanism or

I might not understand what the real Cable Beach is or wants to be, I= was just
trying to give an example to work with. So, again:

LL runs one RD and AD, called RD1 and AD1.
OG runs another RD and AD, called RD2 and AD2.
A user that authenticates with either AD1 or AD2 can travel to RD1 AND= RD2,
completely symmetrical, keeping their respective AD1- and AD2- assets etc.<= br> This is possible with the right policies, so for the sake of looking at
the usefulness of the above definition of VW, assume this is the case.

> protocol, which provides a model for interaction between a = "world service"
> (effectively an AD), the user's client, and various decoupled serv= ices such as
> simulation nodes (possibly an RD) and inventory/asset services. =A0Let= 's assume
> therefore that your "CB" above means something different (an= other world
> provider similar to LL), and then we can proceed with your example cas= e.

Ok

> =A0 =A0 Would you consider "RD1 + AD1" one VW, and "RD2= + AD2" to be another VW?
> =A0 =A0 Or do you think it would make most sense in THIS case to speak= of a single
> =A0 =A0 VW?
>
>
> They're two worlds because you defined them as such, as each has i= ts own AD.
> :-) =A0But that aside, if they were set up separately then they have t= wo
> different sets of policies, two different sets of residents, two diffe= rent
> ToS's, possibly two different legal jurisdictions, two different m= echanisms for
> abuse control and conflict resolution, and so on and so forth. =A0If t= hey were
> created to be worlds that can stand alone but interoperate when desire= d, then
> each of these is a diffferent world. =A0I don't see how that can b= e disputed.

As I stated in one of my first posts, it will (hopefully!!!) be mainl= y the
the *RD* and NOT the AD that all of those things are a function of!

You keep saying that it's mainly the AD that determines these things, b= ut
that would be confusing and very annoying. If two people meet in a virtual<= br> world, that is - if they are standing next to eachother in one region and using local chat - then they should fall under the same legal jurisdiction<= br> and the same ToS: it is the region that determines the rules, not the AD that they used to login with.

As example, ToS1 says: it's ok to be naked; and ToS2 says: it's a b= annable
offence to be naked. Do you really think that it's even workable if the=
ToS to be applied is a function of the AD? Say you login using AD2, so
ToS2 applies to you. You meet someone else that is naked. You know that
you are not allowed to and you are offended. You create an abuse report; where does that report go to? To your AD administration? That makes no
sense: that naked person is using a different AD. To his/her AD administrat= ion
then? That makes also no sense since they allow it.

Seriously, there is only one reasonable thing to do: the ToS that applies is a function of the Region Domain *only*, and if you write an abuse report= ,
it should go to the administration of the region that you are in and not to your or the others AD administration. Same holds for the things related<= br> to legal jurisdiction and any other 'rules' that applies at any giv= en
moment (to users). The only thing that might be a function of the AD are technical policies that are automatically enforced by VWRAP.

> =A0 =A0 I think this is what Infinity means when she says that "v= irtual world"
> =A0 =A0 cannot
> =A0 =A0 be defined, because what could be perceived as being a VW is h= ighly
> =A0 =A0 dependend
> =A0 =A0 on the exact situation (and policies) and in certain configura= tion that are
> =A0 =A0 not as clear as the current situation (no interop) or the abov= e example
> =A0 =A0 (100%
> =A0 =A0 interop).
>
>
> This is incorrect. =A0"Virtual world" is defined by each pro= vider of a virtual
> world and by nobody else, and each provider knows full well how it is = defined,
> what its boundaries are, and what makes it distinct. =A0Nobody else ca= n define
> what a virtual world is, and it's not our business to define it ei= ther (nor to
> conjure up a fictitious definition).

Sorry, but I think you should try harder to understand my point of vi= ew first.
I didn't give the examples so you can ignore them.

> We only need to define the protocol interactions at the endpoints pres= ented by
> those worlds, and not to define "virtual world" structurally= nor any other way.
> =A0 Doing so is what has got us into this mess, by creating a fictitio= us
> definition based on reachability and hence blocking any ability to tal= k about
> actual virtual worlds. =A0Those worlds exist. =A0They won't go awa= y. =A0They want to
> interoperate, but they don't want to be told that they don't e= xist.

I was trying to make you understand WHY Infinitely tells you they don= 't "exist",
if you understand her (and you don't, imho) then it will be easier to s= olve this
miscommunication.

> The contention that we don't know what "virtual world" m= eans is just plain
> bizarre.

Only if you already have a definition of "virtual world" th= ey way you do.

> I don't know of any VW operator who doesn't know what their wo= rld is.

That is the *current* situation... which is 100% simpler than what we= 'll
have in the future.

Compare with math... currently we only have Integers (Z). We're about to introduce division and by that we need to extend the definition of
'number' from Z to Q. Q aren't integers, even though currently = every
number is an integer doesn't mean you have to hold on tight the "d= efinition"
of "number" =3D=3D integer. That definition will be broken and yo= u will
have to redefine "number".

> =A0 Every single one of them could provide the necessary endpoints for= VWRAP
> within their world without any scratching of heads at the meaning of &= quot;virtual
> world". =A0That repeated allegation has been a complete misrepres= entation. =A0It's
> just not true.

You CANNOT define "virtual world" as "AD" (see ab= ove) nor as "AD + RD" because
that is too simple and only holds in the current situation. You can only, a= t most,
if you really want, say - well, lets define it as being some RD.

> And possibly even worse is the excuse =A0that "virtual world"= ; is not being
> defined but is being used non-normatively, while in practice using the= phrase "
> the virtual world" to create a totally fictitious single virtual = world instead.

I agree that as long as it isn't normatively defined, the term sh= ouldn't be
used in documents except in places where it can literally mean anything wit= hout
that anyone will care (like in the protocol name).

> =A0 That phrase is unnecessary, it is misrepresentative of the actual = situation,
> it bypasses policy controls of one world by not mentioning its AD, it = prevents
> us from mentioning virtual worlds by blocking the normal meaning of th= e term,
> and it provides nothing useful as a benefit in return. =A0Unless total= confusion
> is a benefit. ;-)

Sorry, but that is like saying that defining the Rational Numbers (Q)= makes it
impossible to talk about 'numbers', because 3/7 isn't an intege= r.
What you have to do is let go of your current definition.

> =A0 =A0 In one of my first posts about this topic I stated that "= virtual world"
> =A0 =A0 should
> =A0 =A0 be considered to be the Region Domain (although I didn't u= se that term at
> =A0 =A0 the
> =A0 =A0 moment) and be completely independent of the Agent Domain, bas= ed on typical
> =A0 =A0 cases of abuse and griefing etc: if anyone annoys some other u= ser, or
> =A0 =A0 breaks
> =A0 =A0 almost any ToS, it will be region based; which is why I've= always said that
> =A0 =A0 any type of abuse can and should be handled at the sim (single= region)
> =A0 =A0 level:
> =A0 =A0 the estate owner and managers in SL, even, but that idea defin= itely extends
> =A0 =A0 to "world administrations": the people running the R= EGION (domain) is the
> =A0 =A0 one
> =A0 =A0 that should decide what is the local ToS and deal with abuse e= tc. That is
> =A0 =A0 why I strongly argue to define "virtual world" as Re= gion Domain, and leave
> =A0 =A0 the AD out of it. Nevertheless, now I have the term "Regi= on Domain" I don't
> =A0 =A0 need "virtual world" anymore.
>
>
> But that's not how OGP is structured. =A0It's the AD that is t= he focus of service
> policy choices in OGP, and it's the "world service" that= is the focus of
> service policy in Cable Beach. =A0The AD and the world service are the= source of
> capabilities that determine pretty much everything else, and the regio= n domain
> is very subsidiary to that.

No, if the service prodiver of some AD disagrees with the (say) a ToS= that applies
when you go to some RD then they should disallow you go there; they should = not
allow you to go there and then demand that you follow their ToS, that would= not
be a practical solution that is workable.

To use mathematics again, it's easy to make two ToS that have no inters= ection:
Say, ToS1 says: you MUST wear purple clothes, and ToS2 says: you MUST wear = blue
clothes. Obviously those will apply to regions.

So then we have:

Provider1: RD1 --> TOS1 --> purple clothes
Provider2: RD2 --> TOS2 --> blue clothes

*if* Provider 2 runs an AD (AD2) and they allow people logged in with it to go to region RD1 then the people there should wear purple clothes:
TOS2 will not apply because of the AD you use.

If it's against providers religious believe to support wearing purple clothes than they might disallow people to go to RD1, that is their
choice (policy).

> Indeed, a region domain may have no policy of its
> own at all, but merely extend an existing virtual world by accepting t= he
> policies of that world's AD. =A0That's the model in the origin= al OGP before it
> gained aspirations of becoming a cross-VW interop protocol.

That makes no sense :/

There can be any number of people in a given RD, and each can in principle<= br> be using a different AD! PLEASE let the RD determine the rules they have to live by! Anyone else that disagrees with me about that?!

> If RDs determined VW policy and generated seed capabilities for everyt= hing and
> ADs were merely login services then your model would apply, and RD cou= ld be
> considered "VW".

Ah! At last..

> But that's not how it is currently structured --- RDs are

If you are refering to OGP, then OGP should be changed.

> merely the land + physical simulation components of worlds, and in SL&= #39;s case,
> also an elaborate system of proxies. =A0And that's why we need mul= tiple ADs to
> interact in VWRAP before we can consider that there is VW-VW interop. = =A0RDs
> don't handle it.

What I seem to keep missing is the fact that VWRAP is already complet= ely
defined in those previous OGP documents and we're merely here to rewrit= e
them in an IETF document of sorts.

Yes we need multiple ADs to interact, and they will.
But yes, RD's will handle whatever they have to handle with VWRAP.
I never said that capabilities equal 'rules' (ToS and legal jurisdi= ction
isn't something that should be enforced or controlled by the protocol) = by
the way.

... sorry my RSI forces me to stop typing here... shouldn't have
typed this much alrady anyway :(

> =A0 =A0 > In our new protocol, these services may either be impleme= nted internally
> =A0 =A0 within
> =A0 =A0 > a virtual world, or some might be implemented as external= services
> =A0 =A0 offered by
> =A0 =A0 > third parties, the choice being a policy and design decis= ion for each
> =A0 =A0 world
> =A0 =A0 > operator. =A0In all cases however, the virtual worlds are= defined by a set
> =A0 =A0 of
> =A0 =A0 > services, and not just by a Region Domain.
>
>
> Indeed. =A0But access to such decoupled services is provided by the AD= through
> the capabilities that it delivers to authorized parties, and regions a= re just
> one such service. =A0You're giving RDs credit for something that t= hey don't do.
> :-) =A0Perhaps the VWRAP model should be redesigned along your lines s= o that RDs
> become the VWs and are the generators of seed caps, and then ADs becom= e just a
> subservient policy-free login mechanism. :D
>
>
>
> =A0 =A0 I'm afraid that is purely a matter of opinion. I agree tha= t it is likely
> =A0 =A0 that a single 'administrative entity' that runs a RD w= ill also run an AD
> =A0 =A0 and allow users authenticated with their AD visit their RD, bu= t it is no
> =A0 =A0 more than *likely*. There will almost certainly be service pro= vides that
> =A0 =A0 ONLY run an AD, and don't have a RD! And I can imagine tha= t there will
> =A0 =A0 be some that only run a RD and do not care about running their= own AD.
>
>
> Oh sure, there will be all combinations of services, that is to be exp= ected.
> But it is the seat of policy that is the heart of each virtual world, = and
> currently the seat of policy lies in the AD. =A0A VW that doesn't = have an AD in
> the VWRAP model is just a colony without a government, ready to be ass= imilated
> into a world that has an AD and that therefore sets policies, instead = of being
> a sovereign world that merely wants to interop with that other world t= hrough
> VWRAP.
>
>
>
> =A0 =A0 Therefore, "virtual world" cannot be synonym for &qu= ot;the set of services
> =A0 =A0 run by a single administrative entity" as you seem to arg= ue, and at
> =A0 =A0 the SAME time be argued to include an RD *and* AD at all times= .
>
>
> I don't follow that. =A0Two worlds that can run independently (tha= t's very
> important) can certainly each be defined as a set of services that inc= ludes the
> functions of an AD and an RD, and those worlds each continue to includ= e the
> functions of an AD and an RD even after they start interoperating (ass= uming
> that VWRAP is extended to allow cross-VW interop). =A0No world is goin= g to give
> up part of its services portfolio on interop. =A0Interop is an additio= nal
> benefit, not a loss of capability.
>
> [It's worth noting that there may actually be a small loss of capa= bility
> occurring on interop in VWRAP, although it is rarely mentioned. =A0You= can be
> present in two worlds simultaneously with the same login credentials > pre-interop (a feature that we enjoy currently between SL and OSgrid f= or
> example), but post-interop this may no longer be possible --- it depen= ds on the
> implementation. =A0No doubt we will visit this issue within VWRAP.] >
>
>
> =A0 =A0 > This is easy to see by looking at a couple of archetypal = examples in this
> =A0 =A0 > space:
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Is Second Life a virtual world? =A0Undoubtedly. = =A0Is Second Life just a
> =A0 =A0 Region
> =A0 =A0 > =A0 =A0 Domain (assuming it were implemented using VWRAP)= ? =A0No, of course
> =A0 =A0 not, SL
> =A0 =A0 > =A0 =A0 includes all of the services mentioned above, and= others.
>
> =A0 =A0 Of course, LL happens to run all services that are needed to c= reate one
> =A0 =A0 virtual world; there are no third parties they can hire from y= et, so they
> =A0 =A0 have to provide it all themselves.
>
> =A0 =A0 But after SL implemented VWRAP they might decide to do away fr= om one of
> =A0 =A0 their services and only keep their RD. Unlikely, but possible.=
>
>
> You're confusing RD functionality with AD functionality again ther= e. =A0The AD is
> the heart of a world because it defines its capabilities and policies.= =A0The RD
> is just a pile of region hosts that could easily be farmed out to a th= ird party
> to run without them determining policy, and indeed this is already bei= ng done.
> While it is a very important pile of hosts which gives a world its phy= sical
> characterists, the RD is a subservient service to the AD in OGP, just = as the
> equivalent "simulation nodes" provide a subservient service = to the "world
> service" under Cable Beach. =A0The RD is well named --- it provid= es region
> services only, not the package of internal + external services that to= gether
> create a virtual world.
>
>
>
> =A0 =A0 > =A0 =A0 Is OSgrid a virtual world? =A0Undoubtedly. =A0Is = OSgrid just a Region
> =A0 =A0 Domain
> =A0 =A0 > =A0 =A0 (assuming it were implemented using VWRAP)? =A0No= , of course not, it
> =A0 =A0 > =A0 =A0 currently runs all the UGAIM services, which in a= VWRAP context would
> =A0 =A0 > =A0 =A0 become similar to those of Second Life.
>
> =A0 =A0 Exact same argument.
>
>
> Exact same response because the same applies. :-) =A0 What's more,= in OSgrid this
> is even easier to identify, because every person or company that adds = regions
> to OSgrid is subscribing to the notion that they are participants in O= Sgrid ---
> OSgrid is their virtual world. =A0They are merely providing additional= land mass
> and simulation capacity.
>
> Also, in this example there is no need to hypothesize region services = being
> farmed out to third parties, as there already are hundreds to thousand= s of
> independent third parties involved in supplying regions. =A0Those regi= ons and
> clusters of regions (equivalent to RDs) together combine to create the= virtual
> world of OSgrid. =A0There is a clear distinction between R/RDs here an= d the VW
> itself, which also includes a variety of other services as Charles has=
> described several times. =A0The R/RDs are a very important part, but f= unctionally
> they are not the VW, nor are they the VW perceptually. =A0They are pla= ces within
> the world, not the whole world.
>
>
>
> =A0 =A0 > So you see, the idea that has been floated which claims t= hat "VW =3D=3D RD"
> =A0 =A0 is
> =A0 =A0 > completely wrong, and misrepresents what constitutes a &q= uot;virtual world"
> =A0 =A0 despite
> =A0 =A0 > the very clear examples before us.
>
> =A0 =A0 If you want to put it that way (including everything above tha= t you said)
> =A0 =A0 then
> =A0 =A0 I have to side with Infinity: you cannot define a virtual worl= d that way
> =A0 =A0 and
> =A0 =A0 use it for useful discussions regarding VWRAP.
>
>
> I think you may have misread that. =A0I did not define "VW =3D=3D= RD". =A0That's the
> opposite of what I said, but I agree with you on the negative conclusi= on. =A0If
> one defines "VW =3D=3D RD" then it becomes impossible to hav= e a meaningful
> discussion about VWs in VWRAP. =A0It also becomes impossible to have a= meaningful
> discussion about VWs in VWRAP if one conjures up a fictitious meaning = of
> "virtual world" based on reachability. =A0And that's why= we should not define it
> in either of those two ways.
>
> The most useful and forward-looking way of defining virtual worlds in = VWRAP is
> as a collection of service endpoints, regardless of who operates them.= =A0All we
> should care about is the protocol between endpoints, and not conjure u= p some
> non-existent single virtual world.
>
>
>
> =A0 =A0 In the end, one virtual world as defined by "all services= together to make
> =A0 =A0 things work" will be, or can be, a mix of many RD's a= nd many AD's with a
> =A0 =A0 complex
> =A0 =A0 web of trust/non-trust between them that makes the concept of = "virtual
> =A0 =A0 world"
> =A0 =A0 rather fuzzy at best.
>
>
> You're right but you're not being clear about what is fuzzy. = =A0The concept of "
> single virtual world" is not only fuzzy, it is totally non-existe= nt in practice
> (because there are many, not one) as well as impossible in theory =A0b= ecause of
> balkanization through incompatible trust domains, as described so magn= ificently
> by Magnus a week or two ago. =A0We should not go there.
>
> In contrast, the concept of multiple virtual worlds is crystal clear. = =A0Several
> people here in the group operate virtual worlds, but nobody would sugg= est that
> they are unclear about what they operate. =A0We've been sold a bri= dge on that
> "uncertainty". =A0Multiple virtual worlds presenting VWRAP e= ndpoints are the
> natural way of approaching interop between VWs, and you don't have= to define
> VWs structurally for that. =A0You only have to define the endpoints th= at VWs need
> to present to the protocol, and avoid any notion of "single virtu= al world".
>
>
>
> =A0 =A0 [...]
> =A0 =A0 > As we move into analysis of the problem space, these issu= es will be
> =A0 =A0 > disentangled and clarified and the protocols will be defi= ned and evolve,
> =A0 =A0 but
> =A0 =A0 > from the current OGP perspective there is no symmetrical = relationship
> =A0 =A0 possible
> =A0 =A0 > between VWs that could be described as "peering"= ;. =A0It is the asymmetry of
> =A0 =A0 the
> =A0 =A0 > VW-RD relationship that has been the crux of the "no= VW interop" issue.
> =A0 =A0 For
> =A0 =A0 > symmetrical peering, the protocol would need to mention a= t least two
> =A0 =A0 > communicating VWs.
>
> =A0 =A0 You can about peering with just two RD's and one AD, or on= e RD and two
> =A0 =A0 AD's.
>
>
> I think you're confusing RDs with VWs again --- RDs only provide r= egions,
> nothing else. =A0For peering between two VWs, you would need interacti= on between
> their two ADs because their ADs provide their policies. =A0If you bypa= ss a VW's
> AD then you bypass its policies, so you're not interoping with tha= t world. =A0And
> I don't think we're encouraging bypassing and hence subverting= a world's
> policies.
>
>
>
> =A0 =A0 > Of course the situation could change as the protocol evol= ves. =A0For
> =A0 =A0 example,
> =A0 =A0 > once or twice we have heard mention that multiple ADs cou= ld be involved
> =A0 =A0 in some
> =A0 =A0 > way, and it seems certain that communication services fro= m multiple VWs
> =A0 =A0 will be
> =A0 =A0 > merged because residents demand this. =A0This would start= to take us into
> =A0 =A0 VW-VW
> =A0 =A0 > interop territory. =A0However, there is no such thing in = VWRAP currently,
> =A0 =A0 and
> =A0 =A0 > it's not in the list of deliverables to include it, a= nd therefore we
> =A0 =A0 cannot say
> =A0 =A0 > that VWRAP will provide VW-VW interop at all. =A0For now.= ;-)
>
> =A0 =A0 I can't comment on that cause I didn't see VWRAP yet, = but from the
> =A0 =A0 charter and the comments on this list I'd think that full = support
> =A0 =A0 for interop between any number of RD's and AD's is int= ended.
>
>
> Well you've put your finger on the problem here. =A0Everyone is sa= ying what they
> think is intended because the intention is not actually spelled out in= the
> documents. =A0Why cannot it be spelled out clearly that interop betwee= n multiple
> ADs is intended? =A0If it were, this entire discussion could be avoide= d because
> it's easy and reasonable to equate ADs with VWs in practice.
>
> Notice however that even if the protocol were modified to be able to h= andle two
> ADs at a time, use of an unadorned "the virtual world" in th= e documents would
> continue to raise the perennial question of "Which virtual world?= ". =A0After all,
> there would be two of them being discussed.
>
> It's this phraseology that stems from OGP's original goal of a= dding single
> regions or RDs to an existing single virtual world (namely SL in the p= rototype)
> that is creating such a problem. =A0That phraseology was appropriate f= or that
> original goal. =A0It is not appropriate for the goal of interoperating= multiple
> virtual worlds --- it makes it impossible to even talk about the goal = sensibly,
> because "the virtual world" in the OGP sense has no plural.<= br> >
> It's unfortunate, but this whole affair is just the product of leg= acy wording
> from OGP. =A0That's never going to work in a multi-world setting w= here we need to
> talk about the endpoints in different worlds.
>
>
> Morgaine.
>
> PS. If anyone else read this far other than Carlo, you have a lot of s= tamina
> and dedication. ;-)
>
>
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood <carlo@alinoe.com> wrote:
>
> =A0 =A0 On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote:
> =A0 =A0 > The problem you see is that a virtual world is much more = than just a
> =A0 =A0 Region
> =A0 =A0 > Domain. =A0It is a complete set of services of which the = Region Domain
> =A0 =A0 service is
> =A0 =A0 > just one. =A0Other typical services might be those of the= Agent Domain
> =A0 =A0 (which
> =A0 =A0 > provides identification and authorization services and po= ssibly others),
> =A0 =A0 as
> =A0 =A0 > well as asset and inventory services, IM and other commun= ication
> =A0 =A0 services, and
> =A0 =A0 > maybe several more.
>
> =A0 =A0 Well... that is purely semantic. It is a way to define VW, but= not one that
> =A0 =A0 I've been using :/
>
> =A0 =A0 For simplicity, assume that only two things are needed to crea= te a complete
> =A0 =A0 virtual world, like SL or OG: A Region Domain (RD) and an Agen= t Domain
> =A0 =A0 (AD).
>
> =A0 =A0 Currently, without any interop, each administrative entity (or= trust
> =A0 =A0 entity)
> =A0 =A0 will need to provide both: an RD *and* an AD, otherwise they d= on't have a
> =A0 =A0 functional VW.
>
> =A0 =A0 Your conclusion is that a VW exist of both 1 RD and 1 AD. But = I ask you to
> =A0 =A0 reconsider if that conclusion is correct, because it is based = on the
> =A0 =A0 current
> =A0 =A0 situation without any interop. Now "correct" might n= ot be the correct word
> =A0 =A0 - heh.
> =A0 =A0 Rather I should say: I ask you to reconsider if that definitio= n is very
> =A0 =A0 useful.
>
> =A0 =A0 Lets consider the following fictive case:
>
> =A0 =A0 LL runs one RD and AD, called RD1 and AD1.
> =A0 =A0 CB (Cable Beach) runs another RD and AD, called RD2 and AD2. > =A0 =A0 A user that authenticates with either AD1 or AD2 can travel to= RD1 AND RD2,
> =A0 =A0 completely symmetrical, keeping their respective AD1- and AD2-= assets etc.
> =A0 =A0 This is possible with the right policies, so for the sake of l= ooking at
> =A0 =A0 the usefulness of the above definition of VW, assume this is t= he case.
>
> =A0 =A0 Would you consider "RD1 + AD1" one VW, and "RD2= + AD2" to be another VW?
> =A0 =A0 Or do you think it would make most sense in THIS case to speak= of a single
> =A0 =A0 VW?
>
> =A0 =A0 I think this is what Infinity means when she says that "v= irtual world"
> =A0 =A0 cannot
> =A0 =A0 be defined, because what could be perceived as being a VW is h= ighly
> =A0 =A0 dependend
> =A0 =A0 on the exact situation (and policies) and in certain configura= tion that are
> =A0 =A0 not as clear as the current situation (no interop) or the abov= e example
> =A0 =A0 (100%
> =A0 =A0 interop).
>
> =A0 =A0 In one of my first posts about this topic I stated that "= virtual world"
> =A0 =A0 should
> =A0 =A0 be considered to be the Region Domain (although I didn't u= se that term at
> =A0 =A0 the
> =A0 =A0 moment) and be completely independent of the Agent Domain, bas= ed on typical
> =A0 =A0 cases of abuse and griefing etc: if anyone annoys some other u= ser, or
> =A0 =A0 breaks
> =A0 =A0 almost any ToS, it will be region based; which is why I've= always said that
> =A0 =A0 any type of abuse can and should be handled at the sim (single= region)
> =A0 =A0 level:
> =A0 =A0 the estate owner and managers in SL, even, but that idea defin= itely extends
> =A0 =A0 to "world administrations": the people running the R= EGION (domain) is the
> =A0 =A0 one
> =A0 =A0 that should decide what is the local ToS and deal with abuse e= tc. That is
> =A0 =A0 why I strongly argue to define "virtual world" as Re= gion Domain, and leave
> =A0 =A0 the AD out of it. Nevertheless, now I have the term "Regi= on Domain" I don't
> =A0 =A0 need "virtual world" anymore.
>
> =A0 =A0 > In our new protocol, these services may either be impleme= nted internally
> =A0 =A0 within
> =A0 =A0 > a virtual world, or some might be implemented as external= services
> =A0 =A0 offered by
> =A0 =A0 > third parties, the choice being a policy and design decis= ion for each
> =A0 =A0 world
> =A0 =A0 > operator. =A0In all cases however, the virtual worlds are= defined by a set
> =A0 =A0 of
> =A0 =A0 > services, and not just by a Region Domain.
>
> =A0 =A0 I'm afraid that is purely a matter of opinion. I agree tha= t it is likely
> =A0 =A0 that a single 'administrative entity' that runs a RD w= ill also run an AD
> =A0 =A0 and allow users authenticated with their AD visit their RD, bu= t it is no
> =A0 =A0 more than *likely*. There will almost certainly be service pro= vides that
> =A0 =A0 ONLY run an AD, and don't have a RD! And I can imagine tha= t there will
> =A0 =A0 be some that only run a RD and do not care about running their= own AD.
>
> =A0 =A0 Therefore, "virtual world" cannot be synonym for &qu= ot;the set of services
> =A0 =A0 run by a single administrative entity" as you seem to arg= ue, and at
> =A0 =A0 the SAME time be argued to include an RD *and* AD at all times= .
>
> =A0 =A0 > This is easy to see by looking at a couple of archetypal = examples in this
> =A0 =A0 > space:
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Is Second Life a virtual world? =A0Undoubtedly. = =A0Is Second Life just a
> =A0 =A0 Region
> =A0 =A0 > =A0 =A0 Domain (assuming it were implemented using VWRAP)= ? =A0No, of course
> =A0 =A0 not, SL
> =A0 =A0 > =A0 =A0 includes all of the services mentioned above, and= others.
>
> =A0 =A0 Of course, LL happens to run all services that are needed to c= reate one
> =A0 =A0 virtual world; there are no third parties they can hire from y= et, so they
> =A0 =A0 have to provide it all themselves.
>
> =A0 =A0 But after SL implemented VWRAP they might decide to do away fr= om one of
> =A0 =A0 their services and only keep their RD. Unlikely, but possible.=
>
> =A0 =A0 > =A0 =A0 Is OSgrid a virtual world? =A0Undoubtedly. =A0Is = OSgrid just a Region
> =A0 =A0 Domain
> =A0 =A0 > =A0 =A0 (assuming it were implemented using VWRAP)? =A0No= , of course not, it
> =A0 =A0 > =A0 =A0 currently runs all the UGAIM services, which in a= VWRAP context would
> =A0 =A0 > =A0 =A0 become similar to those of Second Life.
>
> =A0 =A0 Exact same argument.
>
> =A0 =A0 > So you see, the idea that has been floated which claims t= hat "VW =3D=3D RD"
> =A0 =A0 is
> =A0 =A0 > completely wrong, and misrepresents what constitutes a &q= uot;virtual world"
> =A0 =A0 despite
> =A0 =A0 > the very clear examples before us.
>
> =A0 =A0 If you want to put it that way (including everything above tha= t you said)
> =A0 =A0 then
> =A0 =A0 I have to side with Infinity: you cannot define a virtual worl= d that way
> =A0 =A0 and
> =A0 =A0 use it for useful discussions regarding VWRAP.
>
> =A0 =A0 In the end, one virtual world as defined by "all services= together to make
> =A0 =A0 things work" will be, or can be, a mix of many RD's a= nd many AD's with a
> =A0 =A0 complex
> =A0 =A0 web of trust/non-trust between them that makes the concept of = "virtual
> =A0 =A0 world"
> =A0 =A0 rather fuzzy at best.
>
> =A0 =A0 [...]
> =A0 =A0 > As we move into analysis of the problem space, these issu= es will be
> =A0 =A0 > disentangled and clarified and the protocols will be defi= ned and evolve,
> =A0 =A0 but
> =A0 =A0 > from the current OGP perspective there is no symmetrical = relationship
> =A0 =A0 possible
> =A0 =A0 > between VWs that could be described as "peering"= ;. =A0It is the asymmetry of
> =A0 =A0 the
> =A0 =A0 > VW-RD relationship that has been the crux of the "no= VW interop" issue.
> =A0 =A0 For
> =A0 =A0 > symmetrical peering, the protocol would need to mention a= t least two
> =A0 =A0 > communicating VWs.
>
> =A0 =A0 You can about peering with just two RD's and one AD, or on= e RD and two
> =A0 =A0 AD's.
>
> =A0 =A0 > Of course the situation could change as the protocol evol= ves. =A0For
> =A0 =A0 example,
> =A0 =A0 > once or twice we have heard mention that multiple ADs cou= ld be involved
> =A0 =A0 in some
> =A0 =A0 > way, and it seems certain that communication services fro= m multiple VWs
> =A0 =A0 will be
> =A0 =A0 > merged because residents demand this. =A0This would start= to take us into
> =A0 =A0 VW-VW
> =A0 =A0 > interop territory. =A0However, there is no such thing in = VWRAP currently,
> =A0 =A0 and
> =A0 =A0 > it's not in the list of deliverables to include it, a= nd therefore we
> =A0 =A0 cannot say
> =A0 =A0 > that VWRAP will provide VW-VW interop at all. =A0For now.= ;-)
>
> =A0 =A0 I can't comment on that cause I didn't see VWRAP yet, = but from the
> =A0 =A0 charter and the comments on this list I'd think that full = support
> =A0 =A0 for interop between any number of RD's and AD's is int= ended.
>
> =A0 =A0 --
> =A0 =A0 Carlo Wood <carlo@alinoe.com>
>
>

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


--
Carlo Wood <c= arlo@alinoe.com>
_______________________________________________<= br> ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx



_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx



_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00504502d38a6e91d40474e66857-- From infinity@lindenlab.com Thu Oct 1 14:41:10 2009 Return-Path: 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 C561728C0F1 for ; Thu, 1 Oct 2009 14:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.754 X-Spam-Level: X-Spam-Status: No, score=0.754 tagged_above=-999 required=5 tests=[AWL=-2.549, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, SARE_FWDLOOK=1.666] 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 rtSYm3SHyzx3 for ; Thu, 1 Oct 2009 14:41:05 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 8D9313A6886 for ; Thu, 1 Oct 2009 14:41:05 -0700 (PDT) Received: by pzk35 with SMTP id 35so818769pzk.29 for ; Thu, 01 Oct 2009 14:42:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.4.20 with SMTP id g20mr709901rvi.121.1254433348324; Thu, 01 Oct 2009 14:42:28 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090902230338.GC6652@alinoe.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Thu, 1 Oct 2009 14:42:28 -0700 Message-ID: <3a880e2c0910011442q5b35bf8epfad7cea37eb5d5d1@mail.gmail.com> From: Infinity Linden To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 21:41:10 -0000 did we read the same response? i totally didn't get "destination determines policy" from josh's response. and what? a single AD defines the trust policy of the RDs it connects to? h= uh? i'm totally reading different documents than you are morgaine. On Thu, Oct 1, 2009 at 2:34 PM, Morgaine w= rote: > On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell wrote: >> >> IMHO, it should be apparent that both AD (which is the agent/advocate fo= r >> the user) and RD (where the user wants to be) both need to make policy >> decisions. >> > > Excellent, Joshua! > > I think we're finally approaching the road towards Destination Determines > Policy now, which is a prerequisite for real interop between virtual > worlds.=A0 This was simply not possible with the old OGP thinking in whic= h > policy was given by a "trust domain" defined by a single AD alone. > > It's a two-part problem.=A0 Naturally your source world can impose > restrictions on travel (a walled garden may disallow any foreign travel a= t > all, for example), that's clear.=A0 What hasn't been clear until now is t= hat > the destination world will have conditions which are every bit as strong = and > important as the source world, and represented in the same way (eg. in th= eir > AD).=A0 Both sides must be allowed equivalent representation in the proto= col. > > This is why the single-world terminology was such a barrier earlier.=A0 I= t > completely prevented us from bringing the two worlds into the discussion > simultaneously, which is necessarily when both source and destination are > completely equivalent peer worlds. > > Your next step is to realize that, for two structurally identical worlds,= if > the seat of policy of one lies in its AD, then the seat of policy of the > other also lies in its AD.=A0 Therefore your statement needs to be modifi= ed to > the following: > > IMHO, it should be apparent that both the AD of the source world and the = RD > and AD of the destination world all need to make policy decisions. > > > What's true for the source world is also true for the destination world, > policy-wise.=A0 The destination world is not "inferior" in any way.=A0 It= 's a > necessary peer in the protocol.=A0 You can't exclude it from the equation= . > > > Morgaine. > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell wrote: >> >> Without diving in too deep, I believe this thread is putting up a >> two-level false dichotomy - either the RD determines policy or the AD >> determines policy, OR things aren't sensible w/o nil trust. If that's a >> mis-reading, my apologies. >> >> IMHO, it should be apparent that both AD (which is the agent/advocate fo= r >> the user) and RD (where the user wants to be) both need to make policy >> decisions. >> >> A corporate AD may restrict where users may visit (e.g. >> agentd.corp.example.com may say "no visiting party.example.com from work= !") >> or an AD may restrict users based on personal preferences >> (agentd.safesurf.example.com may say "scam.example.com is on a shared >> blacklist of malicious sites, teleport blocked"), legal or political >> requirements (agentd.kidfriendly.example.com may say "you can't visit >> adultgrid.example.com"). Note that in all cases the AD is enforcing poli= cy >> as an agent of the user, just as a web browser on a local network does >> today. Presumably, there will exist many ADs that provide no restriction= s >> whatsoever, just as most Web browsers accessing the 'net via most ISPs i= n >> most countries today don't restrict access to Web content via policy. >> >> On the flip side, the RD will also have policy. Corporate VWs may limit >> access to employees. Adult-centric VWs may limit access to agents from A= Ds >> that verify accounts with some well known service. >> Real-world-region-specific RDs may require citizenship checks and deny >> access to citizens of some nation-states. And of course permissions woul= d >> doubtless exist on a per-user basis as well as per-AD. Again - no differ= ent >> than access permissions today on the Web, except that instead of being a >> two-party user/service, it's three party user/AD/RD. And one hopes that, >> like most of the Web, content is freely visitable by all. >> >> On the topic of nil-trust: again, I wholeheartedly support the stance th= at >> the protocol should support nil trust operation. I hope that both the >> protocol and operations of VWRAP-based worlds allow the bulk of VWRAP >> traffic to occur in a nil trust environment, just like the Web does toda= y. >> However, I *suspect* that, in practical terms, the abilities we want to >> grant to regions by visiting them - to display our avatars, to broadcast >> information about our agents, to give and receive virtual goods - will >> require at least a modicum of trust for most VW interaction, at least on= the >> level of an SSL-style secured connection that gives users a certificate = to >> look at that provides some identity/trust information about the service >> provider. >> >> I suspect I'm going to beat this drum a lot - "VWs are just like the Web= , >> except where they're different" :) >> >> On Tue, Sep 29, 2009 at 5:51 PM, Morgaine >> wrote: >>> >>> Hi Vaughn! :-) >>> >>> Your description of our discussion is quite accurate.=A0 However, it se= ems >>> to imply that I advocate in favour of the view that the AD must be the = seat >>> of all policy for connected regions.=A0 I do not.=A0 I was merely expla= ining the >>> architecture of AD+RD pairing as it has been described to us repeatedly >>> throughout the two years of our OGP-related work in the LL+IBM sponsore= d >>> Architecture Working Group within Second Life. >>> >>> After the emails, Carlo and I examined this issue with higher discussio= n >>> bandwidth inside SL, and it turned out that we were describing two diff= erent >>> things:=A0 I was explaining the AD+RD relationship in OGP, while Carlo = was >>> describing RDs as they should be designed if an RD were an autonomous u= nit >>> with its own policies, effectively a small world.=A0 If OGP were design= ed >>> differently and less restrictively to allow that, then there would have= been >>> no discussion.=A0 :-) >>> >>> Of course, OGP is not VWRAP, but only the seedcorn for VWRAP.=A0 We can >>> make VWRAP as flexible as we like, and it's easy to see its potential >>> flexibility in David's deployments document.=A0 Consequently, I have hi= gh >>> hopes that all parties will be happy with the eventual outcome. :-) >>> >>> You may have missed the primary reason why I do not advocate a design i= n >>> which an OGP-style AD is the seat of all power, possibly because the >>> discussion has been spread out across all of OGPX and MMOX.=A0 It's eas= y to >>> summarize in one sentence though:=A0 such a design cannot underpin an >>> Internet-wide metaverse of interoperating virtual worlds because it doe= sn't >>> respect the key meme of virtual and non-virtual tourism:=A0 Destination >>> Determines Policy. >>> >>> This meme is so fundamental and crucial (and obvious) that OGP's suppor= t >>> of the exact opposite is terminally broken, as a basis for the hypothet= ical >>> metaverse.=A0 Indeed, you yourself have referred to the problem in the = funny >>> "war over purple". :-)=A0 At best such a design can support only a rand= om >>> scattering of VPN-like walled gardens, all isolated and incapable of >>> interoperating because they all claim the "one true policy".=A0 We shou= ld not >>> go there. >>> >>> The most recent description of this problematic aspect of the OGP desig= n >>> was posted by Magnus Zeisig in his excellent email at >>> http://www.ietf.org/mail-archive/web/ogpx/current/msg00324.html , which= I >>> fully support.=A0 Such balkanization is not a desireable goal when desi= gning a >>> VW interop protocol. >>> >>> So where are we now?=A0 We're at the stage of examining David's VWRAP >>> deployment patterns to see how the protocol can support them.=A0 And in= that >>> examination, it is likely to become clear that the old OGP model of "AD >>> determines policy" is completely non-viable for interoperating between >>> VWRAP-compatible virtual worlds, except when that policy is "nil trust"= as a >>> common denominator. >>> >>> Consequently, we will either decide to live with the original OGP split >>> and use "nil trust" as our basis for VW interop, or else we will redesi= gn >>> the AD/RD relationship to place many more important policy decisions wh= ere >>> they really belong, at destination.=A0 The latter seems the best choice= to me, >>> and of course it would make Carlo happy, and it is also the model that = every >>> single existing world already operates --- when in Rome, do as the Roma= ns >>> do.=A0 Only the old OGP AD/RD two-way split design is out of step.=A0 L= et's hope >>> that we can correct that in VWRAP. :-)) >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> On Tue, Sep 29, 2009 at 9:16 PM, Vaughn Deluca >>> wrote: >>>> >>>> Carlo and Morgaine have above been involved in a very interesting >>>> discussion about the nature of the (or *a*) virtual world. >>>> Painting their positions with =A0broad strokes, Morgaine stresses the >>>> primary role of the AD as the seat of policy and trust, up to the poin= t >>>> where he denies the RD any role above that of a convenient extension o= f the >>>> AD, i.e. the RD as "colony without a government". Carlo passionately a= rgues >>>> for the independent role of the RD in policy issues. >>>> I feel that both positions are valid (to some degree), and both can be >>>> covered by VWRAP. >>>> Calo makes absolutely clear that having all policy in the respective A= Ds >>>> of the avatars leads to problems when several avatars meet in one regi= on >>>> domain, say RD1. Avatars will be busy killing each other over the righ= t to >>>> wear purple, and for the innocent bystanders caught in the crossfire i= t will >>>> be fully unclear were to complain. Stepping in Morgaines shoes, i thin= k i >>>> would argue that what Carlo asks for can be realised by applying the p= olicy >>>> of a *particular* AD to RD1. The rules to deal with color of clothes, = could >>>> be formulated in AD1 associated with RD1. In principle Carlo could run= this >>>> domain himself, even without a single avatar in it, and in this way ge= t his >>>> "government" and set any policy he wants. If two avatars from AD2 and = AD3 >>>> visit RD1, The policy in RD1 would be governed by what is specified by= AD1. >>>> While this fully fits Morgaines view of "AD rules all", and also fits >>>> Carlo call for autonomy of RD1, it feels decidedly like a kludge, and = in >>>> this particular case it seems much more straightforward to make RD1 mo= re >>>> autonomous. Yet, to keep everything within one framework, this kludge = seems >>>> to be the logical solution... I would like to hear what others think a= bout >>>> this. >>>> One other remark: the minimal example for =A0a "world" =A0-one AD and = one >>>> RD- would be more useful when extended with one asset service AS. Expl= icit >>>> mentioning of the AS will make it much easier to discuss IP issues. >>>> Vaughn >>>> >>>> >>>> On Mon, Sep 14, 2009 at 10:44 AM, Carlo Wood wrote: >>>>> >>>>> On Mon, Sep 14, 2009 at 06:43:06AM +0100, Morgaine wrote: >>>>> > Carlo asked for detailed comments on the below, so here goes. :-) >>>>> > >>>>> > >>>>> > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood wrote= : >>>>> > >>>>> > =A0 =A0 On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote: >>>>> > =A0 =A0 > The problem you see is that a virtual world is much more = than >>>>> > just a >>>>> > =A0 =A0 Region >>>>> > =A0 =A0 > Domain. =A0It is a complete set of services of which the = Region >>>>> > Domain >>>>> > =A0 =A0 service is >>>>> > =A0 =A0 > just one. =A0Other typical services might be those of the= Agent >>>>> > Domain >>>>> > =A0 =A0 (which >>>>> > =A0 =A0 > provides identification and authorization services and po= ssibly >>>>> > others), >>>>> > =A0 =A0 as >>>>> > =A0 =A0 > well as asset and inventory services, IM and other >>>>> > communication >>>>> > =A0 =A0 services, and >>>>> > =A0 =A0 > maybe several more. >>>>> > >>>>> > =A0 =A0 Well... that is purely semantic. It is a way to define VW, = but >>>>> > not one that >>>>> > =A0 =A0 I've been using :/ >>>>> > >>>>> > >>>>> > It's a rough top-level projection of the architectural model of >>>>> > VWRAP, once the >>>>> > various services have been decoupled in the way that David Levine >>>>> > often >>>>> > describes to us. =A0Nothing very contentious there, everyone likes = a >>>>> > services-oriented approach. :-) >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 For simplicity, assume that only two things are needed to c= reate >>>>> > a complete >>>>> > =A0 =A0 virtual world, like SL or OG: A Region Domain (RD) and an A= gent >>>>> > Domain >>>>> > =A0 =A0 (AD). >>>>> > >>>>> > >>>>> > I am happy to consider that simple scenario as representative. =A0I= t is >>>>> > quite >>>>> > reasonable to equate AD with VW because the AD is the focus of almo= st >>>>> > all the >>>>> > policy decisions of a VWRAP-based world. =A0When other decoupled >>>>> > services are >>>>> > added to this picture, it doesn't change the fundamental architectu= re >>>>> > of AD + >>>>> > RDs, only extends it by decoupling more than just the region servic= e. >>>>> > =A0So >>>>> > that's fine with me. >>>>> >>>>> I totally disagree that the AD is the representative...and why do you >>>>> say >>>>> that below a sentence of me where I say "A Region Domain (RD) and an >>>>> Agent Domain (AD)"? >>>>> >>>>> This is like I say "VW =3D AD + RD", and you go: "yes, VW =3D AD". We= can't >>>>> have a discussion like that Morgaine. >>>>> >>>>> > =A0 =A0 Currently, without any interop, each administrative entity = (or >>>>> > trust >>>>> > =A0 =A0 entity) >>>>> > =A0 =A0 will need to provide both: an RD *and* an AD, otherwise the= y >>>>> > don't have a >>>>> > =A0 =A0 functional VW. >>>>> > >>>>> > >>>>> > Correct. =A0The AD is the seat of most (but not all) of the policy >>>>> > decisions of a >>>>> >>>>> I even *stressed* the '*and*' here, and you do it again. >>>>> >>>>> > VW, so it's very central to the existence of a VW. =A0While it's >>>>> > possible to >>>>> > imagine policy-free VWs that temporarily =A0take on the policy of a= ny >>>>> > other world >>>>> > they hook up with, this is clearly a subset situation. =A0All the >>>>> > currently known >>>>> > SL-like virtual worlds are grids of the SL kind, with their own >>>>> > individual >>>>> > policies which they are not going to change on interop. >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 Your conclusion is that a VW exist of both 1 RD and 1 AD. B= ut I >>>>> > ask you to >>>>> > =A0 =A0 reconsider if that conclusion is correct, because it is bas= ed on >>>>> > the >>>>> > =A0 =A0 current >>>>> > =A0 =A0 situation without any interop. Now "correct" might not be t= he >>>>> > correct word >>>>> > =A0 =A0 - heh. >>>>> > =A0 =A0 Rather I should say: I ask you to reconsider if that defini= tion >>>>> > is very >>>>> > =A0 =A0 useful. >>>>> > >>>>> > =A0 =A0 Lets consider the following fictive case: >>>>> > >>>>> > =A0 =A0 LL runs one RD and AD, called RD1 and AD1. >>>>> > =A0 =A0 CB (Cable Beach) runs another RD and AD, called RD2 and AD2= . >>>>> > =A0 =A0 A user that authenticates with either AD1 or AD2 can travel= to >>>>> > RD1 AND RD2, >>>>> > =A0 =A0 completely symmetrical, keeping their respective AD1- and A= D2- >>>>> > assets etc. >>>>> > =A0 =A0 This is possible with the right policies, so for the sake o= f >>>>> > looking at >>>>> > =A0 =A0 the usefulness of the above definition of VW, assume this i= s the >>>>> > case. >>>>> > >>>>> > >>>>> > That's not quite right because Cable Beach is not a world provider >>>>> > like LL. >>>>> > Cable Beach is perhaps best described as a "login mediation" >>>>> > mechanism or >>>>> >>>>> I might not understand what the real Cable Beach is or wants to be, I >>>>> was just >>>>> trying to give an example to work with. So, again: >>>>> >>>>> LL runs one RD and AD, called RD1 and AD1. >>>>> OG runs another RD and AD, called RD2 and AD2. >>>>> A user that authenticates with either AD1 or AD2 can travel to RD1 AN= D >>>>> RD2, >>>>> completely symmetrical, keeping their respective AD1- and AD2- assets >>>>> etc. >>>>> This is possible with the right policies, so for the sake of looking = at >>>>> the usefulness of the above definition of VW, assume this is the case= . >>>>> >>>>> > protocol, which provides a model for interaction between a "world >>>>> > service" >>>>> > (effectively an AD), the user's client, and various decoupled >>>>> > services such as >>>>> > simulation nodes (possibly an RD) and inventory/asset services. >>>>> > =A0Let's assume >>>>> > therefore that your "CB" above means something different (another >>>>> > world >>>>> > provider similar to LL), and then we can proceed with your example >>>>> > case. >>>>> >>>>> Ok >>>>> >>>>> > =A0 =A0 Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to b= e >>>>> > another VW? >>>>> > =A0 =A0 Or do you think it would make most sense in THIS case to sp= eak of >>>>> > a single >>>>> > =A0 =A0 VW? >>>>> > >>>>> > >>>>> > They're two worlds because you defined them as such, as each has it= s >>>>> > own AD. >>>>> > :-) =A0But that aside, if they were set up separately then they hav= e >>>>> > two >>>>> > different sets of policies, two different sets of residents, two >>>>> > different >>>>> > ToS's, possibly two different legal jurisdictions, two different >>>>> > mechanisms for >>>>> > abuse control and conflict resolution, and so on and so forth. =A0I= f >>>>> > they were >>>>> > created to be worlds that can stand alone but interoperate when >>>>> > desired, then >>>>> > each of these is a diffferent world. =A0I don't see how that can be >>>>> > disputed. >>>>> >>>>> As I stated in one of my first posts, it will (hopefully!!!) be mainl= y >>>>> the >>>>> the *RD* and NOT the AD that all of those things are a function of! >>>>> >>>>> You keep saying that it's mainly the AD that determines these things, >>>>> but >>>>> that would be confusing and very annoying. If two people meet in a >>>>> virtual >>>>> world, that is - if they are standing next to eachother in one region >>>>> and >>>>> using local chat - then they should fall under the same legal >>>>> jurisdiction >>>>> and the same ToS: it is the region that determines the rules, not the >>>>> AD >>>>> that they used to login with. >>>>> >>>>> As example, ToS1 says: it's ok to be naked; and ToS2 says: it's a >>>>> bannable >>>>> offence to be naked. Do you really think that it's even workable if t= he >>>>> ToS to be applied is a function of the AD? Say you login using AD2, s= o >>>>> ToS2 applies to you. You meet someone else that is naked. You know th= at >>>>> you are not allowed to and you are offended. You create an abuse >>>>> report; >>>>> where does that report go to? To your AD administration? That makes n= o >>>>> sense: that naked person is using a different AD. To his/her AD >>>>> administration >>>>> then? That makes also no sense since they allow it. >>>>> >>>>> Seriously, there is only one reasonable thing to do: the ToS that >>>>> applies >>>>> is a function of the Region Domain *only*, and if you write an abuse >>>>> report, >>>>> it should go to the administration of the region that you are in and >>>>> not >>>>> to your or the others AD administration. Same holds for the things >>>>> related >>>>> to legal jurisdiction and any other 'rules' that applies at any given >>>>> moment (to users). The only thing that might be a function of the AD >>>>> are >>>>> technical policies that are automatically enforced by VWRAP. >>>>> >>>>> > =A0 =A0 I think this is what Infinity means when she says that "vir= tual >>>>> > world" >>>>> > =A0 =A0 cannot >>>>> > =A0 =A0 be defined, because what could be perceived as being a VW i= s >>>>> > highly >>>>> > =A0 =A0 dependend >>>>> > =A0 =A0 on the exact situation (and policies) and in certain >>>>> > configuration that are >>>>> > =A0 =A0 not as clear as the current situation (no interop) or the a= bove >>>>> > example >>>>> > =A0 =A0 (100% >>>>> > =A0 =A0 interop). >>>>> > >>>>> > >>>>> > This is incorrect. =A0"Virtual world" is defined by each provider o= f a >>>>> > virtual >>>>> > world and by nobody else, and each provider knows full well how it = is >>>>> > defined, >>>>> > what its boundaries are, and what makes it distinct. =A0Nobody else= can >>>>> > define >>>>> > what a virtual world is, and it's not our business to define it >>>>> > either (nor to >>>>> > conjure up a fictitious definition). >>>>> >>>>> Sorry, but I think you should try harder to understand my point of vi= ew >>>>> first. >>>>> I didn't give the examples so you can ignore them. >>>>> >>>>> > We only need to define the protocol interactions at the endpoints >>>>> > presented by >>>>> > those worlds, and not to define "virtual world" structurally nor an= y >>>>> > other way. >>>>> > =A0 Doing so is what has got us into this mess, by creating a >>>>> > fictitious >>>>> > definition based on reachability and hence blocking any ability to >>>>> > talk about >>>>> > actual virtual worlds. =A0Those worlds exist. =A0They won't go away= . >>>>> > =A0They want to >>>>> > interoperate, but they don't want to be told that they don't exist. >>>>> >>>>> I was trying to make you understand WHY Infinitely tells you they don= 't >>>>> "exist", >>>>> if you understand her (and you don't, imho) then it will be easier to >>>>> solve this >>>>> miscommunication. >>>>> >>>>> > The contention that we don't know what "virtual world" means is jus= t >>>>> > plain >>>>> > bizarre. >>>>> >>>>> Only if you already have a definition of "virtual world" they way you >>>>> do. >>>>> >>>>> > I don't know of any VW operator who doesn't know what their world i= s. >>>>> >>>>> That is the *current* situation... which is 100% simpler than what >>>>> we'll >>>>> have in the future. >>>>> >>>>> Compare with math... currently we only have Integers (Z). We're about >>>>> to introduce division and by that we need to extend the definition of >>>>> 'number' from Z to Q. Q aren't integers, even though currently every >>>>> number is an integer doesn't mean you have to hold on tight the >>>>> "definition" >>>>> of "number" =3D=3D integer. That definition will be broken and you wi= ll >>>>> have to redefine "number". >>>>> >>>>> > =A0 Every single one of them could provide the necessary endpoints = for >>>>> > VWRAP >>>>> > within their world without any scratching of heads at the meaning o= f >>>>> > "virtual >>>>> > world". =A0That repeated allegation has been a complete >>>>> > misrepresentation. =A0It's >>>>> > just not true. >>>>> >>>>> You CANNOT define "virtual world" as "AD" (see above) nor as "AD + RD= " >>>>> because >>>>> that is too simple and only holds in the current situation. You can >>>>> only, at most, >>>>> if you really want, say - well, lets define it as being some RD. >>>>> >>>>> > And possibly even worse is the excuse =A0that "virtual world" is no= t >>>>> > being >>>>> > defined but is being used non-normatively, while in practice using >>>>> > the phrase " >>>>> > the virtual world" to create a totally fictitious single virtual >>>>> > world instead. >>>>> >>>>> I agree that as long as it isn't normatively defined, the term >>>>> shouldn't be >>>>> used in documents except in places where it can literally mean anythi= ng >>>>> without >>>>> that anyone will care (like in the protocol name). >>>>> >>>>> > =A0 That phrase is unnecessary, it is misrepresentative of the actu= al >>>>> > situation, >>>>> > it bypasses policy controls of one world by not mentioning its AD, = it >>>>> > prevents >>>>> > us from mentioning virtual worlds by blocking the normal meaning of >>>>> > the term, >>>>> > and it provides nothing useful as a benefit in return. =A0Unless to= tal >>>>> > confusion >>>>> > is a benefit. ;-) >>>>> >>>>> Sorry, but that is like saying that defining the Rational Numbers (Q) >>>>> makes it >>>>> impossible to talk about 'numbers', because 3/7 isn't an integer. >>>>> What you have to do is let go of your current definition. >>>>> >>>>> > =A0 =A0 In one of my first posts about this topic I stated that "vi= rtual >>>>> > world" >>>>> > =A0 =A0 should >>>>> > =A0 =A0 be considered to be the Region Domain (although I didn't us= e that >>>>> > term at >>>>> > =A0 =A0 the >>>>> > =A0 =A0 moment) and be completely independent of the Agent Domain, = based >>>>> > on typical >>>>> > =A0 =A0 cases of abuse and griefing etc: if anyone annoys some othe= r >>>>> > user, or >>>>> > =A0 =A0 breaks >>>>> > =A0 =A0 almost any ToS, it will be region based; which is why I've = always >>>>> > said that >>>>> > =A0 =A0 any type of abuse can and should be handled at the sim (sin= gle >>>>> > region) >>>>> > =A0 =A0 level: >>>>> > =A0 =A0 the estate owner and managers in SL, even, but that idea >>>>> > definitely extends >>>>> > =A0 =A0 to "world administrations": the people running the REGION >>>>> > (domain) is the >>>>> > =A0 =A0 one >>>>> > =A0 =A0 that should decide what is the local ToS and deal with abus= e etc. >>>>> > That is >>>>> > =A0 =A0 why I strongly argue to define "virtual world" as Region Do= main, >>>>> > and leave >>>>> > =A0 =A0 the AD out of it. Nevertheless, now I have the term "Region >>>>> > Domain" I don't >>>>> > =A0 =A0 need "virtual world" anymore. >>>>> > >>>>> > >>>>> > But that's not how OGP is structured. =A0It's the AD that is the fo= cus >>>>> > of service >>>>> > policy choices in OGP, and it's the "world service" that is the foc= us >>>>> > of >>>>> > service policy in Cable Beach. =A0The AD and the world service are = the >>>>> > source of >>>>> > capabilities that determine pretty much everything else, and the >>>>> > region domain >>>>> > is very subsidiary to that. >>>>> >>>>> No, if the service prodiver of some AD disagrees with the (say) a ToS >>>>> that applies >>>>> when you go to some RD then they should disallow you go there; they >>>>> should not >>>>> allow you to go there and then demand that you follow their ToS, that >>>>> would not >>>>> be a practical solution that is workable. >>>>> >>>>> To use mathematics again, it's easy to make two ToS that have no >>>>> intersection: >>>>> Say, ToS1 says: you MUST wear purple clothes, and ToS2 says: you MUST >>>>> wear blue >>>>> clothes. Obviously those will apply to regions. >>>>> >>>>> So then we have: >>>>> >>>>> Provider1: RD1 --> TOS1 --> purple clothes >>>>> Provider2: RD2 --> TOS2 --> blue clothes >>>>> >>>>> *if* Provider 2 runs an AD (AD2) and they allow people logged in with >>>>> it >>>>> to go to region RD1 then the people there should wear purple clothes: >>>>> TOS2 will not apply because of the AD you use. >>>>> >>>>> If it's against providers religious believe to support wearing purple >>>>> clothes than they might disallow people to go to RD1, that is their >>>>> choice (policy). >>>>> >>>>> > Indeed, a region domain may have no policy of its >>>>> > own at all, but merely extend an existing virtual world by acceptin= g >>>>> > the >>>>> > policies of that world's AD. =A0That's the model in the original OG= P >>>>> > before it >>>>> > gained aspirations of becoming a cross-VW interop protocol. >>>>> >>>>> That makes no sense :/ >>>>> >>>>> There can be any number of people in a given RD, and each can in >>>>> principle >>>>> be using a different AD! PLEASE let the RD determine the rules they >>>>> have >>>>> to live by! Anyone else that disagrees with me about that?! >>>>> >>>>> > If RDs determined VW policy and generated seed capabilities for >>>>> > everything and >>>>> > ADs were merely login services then your model would apply, and RD >>>>> > could be >>>>> > considered "VW". >>>>> >>>>> Ah! At last.. >>>>> >>>>> > But that's not how it is currently structured --- RDs are >>>>> >>>>> If you are refering to OGP, then OGP should be changed. >>>>> >>>>> > merely the land + physical simulation components of worlds, and in >>>>> > SL's case, >>>>> > also an elaborate system of proxies. =A0And that's why we need mult= iple >>>>> > ADs to >>>>> > interact in VWRAP before we can consider that there is VW-VW intero= p. >>>>> > =A0RDs >>>>> > don't handle it. >>>>> >>>>> What I seem to keep missing is the fact that VWRAP is already >>>>> completely >>>>> defined in those previous OGP documents and we're merely here to >>>>> rewrite >>>>> them in an IETF document of sorts. >>>>> >>>>> Yes we need multiple ADs to interact, and they will. >>>>> But yes, RD's will handle whatever they have to handle with VWRAP. >>>>> I never said that capabilities equal 'rules' (ToS and legal >>>>> jurisdiction >>>>> isn't something that should be enforced or controlled by the protocol= ) >>>>> by >>>>> the way. >>>>> >>>>> ... sorry my RSI forces me to stop typing here... shouldn't have >>>>> typed this much alrady anyway :( >>>>> >>>>> > =A0 =A0 > In our new protocol, these services may either be impleme= nted >>>>> > internally >>>>> > =A0 =A0 within >>>>> > =A0 =A0 > a virtual world, or some might be implemented as external >>>>> > services >>>>> > =A0 =A0 offered by >>>>> > =A0 =A0 > third parties, the choice being a policy and design decis= ion >>>>> > for each >>>>> > =A0 =A0 world >>>>> > =A0 =A0 > operator. =A0In all cases however, the virtual worlds are= defined >>>>> > by a set >>>>> > =A0 =A0 of >>>>> > =A0 =A0 > services, and not just by a Region Domain. >>>>> > >>>>> > >>>>> > Indeed. =A0But access to such decoupled services is provided by the= AD >>>>> > through >>>>> > the capabilities that it delivers to authorized parties, and region= s >>>>> > are just >>>>> > one such service. =A0You're giving RDs credit for something that th= ey >>>>> > don't do. >>>>> > :-) =A0Perhaps the VWRAP model should be redesigned along your line= s so >>>>> > that RDs >>>>> > become the VWs and are the generators of seed caps, and then ADs >>>>> > become just a >>>>> > subservient policy-free login mechanism. :D >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 I'm afraid that is purely a matter of opinion. I agree that= it is >>>>> > likely >>>>> > =A0 =A0 that a single 'administrative entity' that runs a RD will a= lso >>>>> > run an AD >>>>> > =A0 =A0 and allow users authenticated with their AD visit their RD,= but >>>>> > it is no >>>>> > =A0 =A0 more than *likely*. There will almost certainly be service >>>>> > provides that >>>>> > =A0 =A0 ONLY run an AD, and don't have a RD! And I can imagine that= there >>>>> > will >>>>> > =A0 =A0 be some that only run a RD and do not care about running th= eir >>>>> > own AD. >>>>> > >>>>> > >>>>> > Oh sure, there will be all combinations of services, that is to be >>>>> > expected. >>>>> > But it is the seat of policy that is the heart of each virtual worl= d, >>>>> > and >>>>> > currently the seat of policy lies in the AD. =A0A VW that doesn't h= ave >>>>> > an AD in >>>>> > the VWRAP model is just a colony without a government, ready to be >>>>> > assimilated >>>>> > into a world that has an AD and that therefore sets policies, inste= ad >>>>> > of being >>>>> > a sovereign world that merely wants to interop with that other worl= d >>>>> > through >>>>> > VWRAP. >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 Therefore, "virtual world" cannot be synonym for "the set o= f >>>>> > services >>>>> > =A0 =A0 run by a single administrative entity" as you seem to argue= , and >>>>> > at >>>>> > =A0 =A0 the SAME time be argued to include an RD *and* AD at all ti= mes. >>>>> > >>>>> > >>>>> > I don't follow that. =A0Two worlds that can run independently (that= 's >>>>> > very >>>>> > important) can certainly each be defined as a set of services that >>>>> > includes the >>>>> > functions of an AD and an RD, and those worlds each continue to >>>>> > include the >>>>> > functions of an AD and an RD even after they start interoperating >>>>> > (assuming >>>>> > that VWRAP is extended to allow cross-VW interop). =A0No world is g= oing >>>>> > to give >>>>> > up part of its services portfolio on interop. =A0Interop is an >>>>> > additional >>>>> > benefit, not a loss of capability. >>>>> > >>>>> > [It's worth noting that there may actually be a small loss of >>>>> > capability >>>>> > occurring on interop in VWRAP, although it is rarely mentioned. =A0= You >>>>> > can be >>>>> > present in two worlds simultaneously with the same login credential= s >>>>> > pre-interop (a feature that we enjoy currently between SL and OSgri= d >>>>> > for >>>>> > example), but post-interop this may no longer be possible --- it >>>>> > depends on the >>>>> > implementation. =A0No doubt we will visit this issue within VWRAP.] >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 > This is easy to see by looking at a couple of archetypal >>>>> > examples in this >>>>> > =A0 =A0 > space: >>>>> > =A0 =A0 > >>>>> > =A0 =A0 > >>>>> > =A0 =A0 > =A0 =A0 Is Second Life a virtual world? =A0Undoubtedly. = =A0Is Second >>>>> > Life just a >>>>> > =A0 =A0 Region >>>>> > =A0 =A0 > =A0 =A0 Domain (assuming it were implemented using VWRAP)= ? =A0No, of >>>>> > course >>>>> > =A0 =A0 not, SL >>>>> > =A0 =A0 > =A0 =A0 includes all of the services mentioned above, and= others. >>>>> > >>>>> > =A0 =A0 Of course, LL happens to run all services that are needed t= o >>>>> > create one >>>>> > =A0 =A0 virtual world; there are no third parties they can hire fro= m yet, >>>>> > so they >>>>> > =A0 =A0 have to provide it all themselves. >>>>> > >>>>> > =A0 =A0 But after SL implemented VWRAP they might decide to do away= from >>>>> > one of >>>>> > =A0 =A0 their services and only keep their RD. Unlikely, but possib= le. >>>>> > >>>>> > >>>>> > You're confusing RD functionality with AD functionality again there= . >>>>> > =A0The AD is >>>>> > the heart of a world because it defines its capabilities and >>>>> > policies. =A0The RD >>>>> > is just a pile of region hosts that could easily be farmed out to a >>>>> > third party >>>>> > to run without them determining policy, and indeed this is already >>>>> > being done. >>>>> > While it is a very important pile of hosts which gives a world its >>>>> > physical >>>>> > characterists, the RD is a subservient service to the AD in OGP, ju= st >>>>> > as the >>>>> > equivalent "simulation nodes" provide a subservient service to the >>>>> > "world >>>>> > service" under Cable Beach. =A0The RD is well named --- it provides >>>>> > region >>>>> > services only, not the package of internal + external services that >>>>> > together >>>>> > create a virtual world. >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 > =A0 =A0 Is OSgrid a virtual world? =A0Undoubtedly. =A0Is = OSgrid just a >>>>> > Region >>>>> > =A0 =A0 Domain >>>>> > =A0 =A0 > =A0 =A0 (assuming it were implemented using VWRAP)? =A0No= , of course >>>>> > not, it >>>>> > =A0 =A0 > =A0 =A0 currently runs all the UGAIM services, which in a= VWRAP >>>>> > context would >>>>> > =A0 =A0 > =A0 =A0 become similar to those of Second Life. >>>>> > >>>>> > =A0 =A0 Exact same argument. >>>>> > >>>>> > >>>>> > Exact same response because the same applies. :-) =A0 What's more, = in >>>>> > OSgrid this >>>>> > is even easier to identify, because every person or company that ad= ds >>>>> > regions >>>>> > to OSgrid is subscribing to the notion that they are participants i= n >>>>> > OSgrid --- >>>>> > OSgrid is their virtual world. =A0They are merely providing additio= nal >>>>> > land mass >>>>> > and simulation capacity. >>>>> > >>>>> > Also, in this example there is no need to hypothesize region servic= es >>>>> > being >>>>> > farmed out to third parties, as there already are hundreds to >>>>> > thousands of >>>>> > independent third parties involved in supplying regions. =A0Those >>>>> > regions and >>>>> > clusters of regions (equivalent to RDs) together combine to create >>>>> > the virtual >>>>> > world of OSgrid. =A0There is a clear distinction between R/RDs here= and >>>>> > the VW >>>>> > itself, which also includes a variety of other services as Charles >>>>> > has >>>>> > described several times. =A0The R/RDs are a very important part, bu= t >>>>> > functionally >>>>> > they are not the VW, nor are they the VW perceptually. =A0They are >>>>> > places within >>>>> > the world, not the whole world. >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 > So you see, the idea that has been floated which claims t= hat >>>>> > "VW =3D=3D RD" >>>>> > =A0 =A0 is >>>>> > =A0 =A0 > completely wrong, and misrepresents what constitutes a "v= irtual >>>>> > world" >>>>> > =A0 =A0 despite >>>>> > =A0 =A0 > the very clear examples before us. >>>>> > >>>>> > =A0 =A0 If you want to put it that way (including everything above = that >>>>> > you said) >>>>> > =A0 =A0 then >>>>> > =A0 =A0 I have to side with Infinity: you cannot define a virtual w= orld >>>>> > that way >>>>> > =A0 =A0 and >>>>> > =A0 =A0 use it for useful discussions regarding VWRAP. >>>>> > >>>>> > >>>>> > I think you may have misread that. =A0I did not define "VW =3D=3D R= D". >>>>> > =A0That's the >>>>> > opposite of what I said, but I agree with you on the negative >>>>> > conclusion. =A0If >>>>> > one defines "VW =3D=3D RD" then it becomes impossible to have a >>>>> > meaningful >>>>> > discussion about VWs in VWRAP. =A0It also becomes impossible to hav= e a >>>>> > meaningful >>>>> > discussion about VWs in VWRAP if one conjures up a fictitious meani= ng >>>>> > of >>>>> > "virtual world" based on reachability. =A0And that's why we should = not >>>>> > define it >>>>> > in either of those two ways. >>>>> > >>>>> > The most useful and forward-looking way of defining virtual worlds = in >>>>> > VWRAP is >>>>> > as a collection of service endpoints, regardless of who operates >>>>> > them. =A0All we >>>>> > should care about is the protocol between endpoints, and not conjur= e >>>>> > up some >>>>> > non-existent single virtual world. >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 In the end, one virtual world as defined by "all services >>>>> > together to make >>>>> > =A0 =A0 things work" will be, or can be, a mix of many RD's and man= y AD's >>>>> > with a >>>>> > =A0 =A0 complex >>>>> > =A0 =A0 web of trust/non-trust between them that makes the concept = of >>>>> > "virtual >>>>> > =A0 =A0 world" >>>>> > =A0 =A0 rather fuzzy at best. >>>>> > >>>>> > >>>>> > You're right but you're not being clear about what is fuzzy. =A0The >>>>> > concept of " >>>>> > single virtual world" is not only fuzzy, it is totally non-existent >>>>> > in practice >>>>> > (because there are many, not one) as well as impossible in theory >>>>> > =A0because of >>>>> > balkanization through incompatible trust domains, as described so >>>>> > magnificently >>>>> > by Magnus a week or two ago. =A0We should not go there. >>>>> > >>>>> > In contrast, the concept of multiple virtual worlds is crystal clea= r. >>>>> > =A0Several >>>>> > people here in the group operate virtual worlds, but nobody would >>>>> > suggest that >>>>> > they are unclear about what they operate. =A0We've been sold a brid= ge >>>>> > on that >>>>> > "uncertainty". =A0Multiple virtual worlds presenting VWRAP endpoint= s >>>>> > are the >>>>> > natural way of approaching interop between VWs, and you don't have = to >>>>> > define >>>>> > VWs structurally for that. =A0You only have to define the endpoints >>>>> > that VWs need >>>>> > to present to the protocol, and avoid any notion of "single virtual >>>>> > world". >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 [...] >>>>> > =A0 =A0 > As we move into analysis of the problem space, these issu= es >>>>> > will be >>>>> > =A0 =A0 > disentangled and clarified and the protocols will be defi= ned >>>>> > and evolve, >>>>> > =A0 =A0 but >>>>> > =A0 =A0 > from the current OGP perspective there is no symmetrical >>>>> > relationship >>>>> > =A0 =A0 possible >>>>> > =A0 =A0 > between VWs that could be described as "peering". =A0It i= s the >>>>> > asymmetry of >>>>> > =A0 =A0 the >>>>> > =A0 =A0 > VW-RD relationship that has been the crux of the "no VW >>>>> > interop" issue. >>>>> > =A0 =A0 For >>>>> > =A0 =A0 > symmetrical peering, the protocol would need to mention a= t >>>>> > least two >>>>> > =A0 =A0 > communicating VWs. >>>>> > >>>>> > =A0 =A0 You can about peering with just two RD's and one AD, or one= RD >>>>> > and two >>>>> > =A0 =A0 AD's. >>>>> > >>>>> > >>>>> > I think you're confusing RDs with VWs again --- RDs only provide >>>>> > regions, >>>>> > nothing else. =A0For peering between two VWs, you would need >>>>> > interaction between >>>>> > their two ADs because their ADs provide their policies. =A0If you >>>>> > bypass a VW's >>>>> > AD then you bypass its policies, so you're not interoping with that >>>>> > world. =A0And >>>>> > I don't think we're encouraging bypassing and hence subverting a >>>>> > world's >>>>> > policies. >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 > Of course the situation could change as the protocol evol= ves. >>>>> > =A0For >>>>> > =A0 =A0 example, >>>>> > =A0 =A0 > once or twice we have heard mention that multiple ADs cou= ld be >>>>> > involved >>>>> > =A0 =A0 in some >>>>> > =A0 =A0 > way, and it seems certain that communication services fro= m >>>>> > multiple VWs >>>>> > =A0 =A0 will be >>>>> > =A0 =A0 > merged because residents demand this. =A0This would start= to take >>>>> > us into >>>>> > =A0 =A0 VW-VW >>>>> > =A0 =A0 > interop territory. =A0However, there is no such thing in = VWRAP >>>>> > currently, >>>>> > =A0 =A0 and >>>>> > =A0 =A0 > it's not in the list of deliverables to include it, and >>>>> > therefore we >>>>> > =A0 =A0 cannot say >>>>> > =A0 =A0 > that VWRAP will provide VW-VW interop at all. =A0For now.= ;-) >>>>> > >>>>> > =A0 =A0 I can't comment on that cause I didn't see VWRAP yet, but f= rom >>>>> > the >>>>> > =A0 =A0 charter and the comments on this list I'd think that full s= upport >>>>> > =A0 =A0 for interop between any number of RD's and AD's is intended= . >>>>> > >>>>> > >>>>> > Well you've put your finger on the problem here. =A0Everyone is say= ing >>>>> > what they >>>>> > think is intended because the intention is not actually spelled out >>>>> > in the >>>>> > documents. =A0Why cannot it be spelled out clearly that interop bet= ween >>>>> > multiple >>>>> > ADs is intended? =A0If it were, this entire discussion could be avo= ided >>>>> > because >>>>> > it's easy and reasonable to equate ADs with VWs in practice. >>>>> > >>>>> > Notice however that even if the protocol were modified to be able t= o >>>>> > handle two >>>>> > ADs at a time, use of an unadorned "the virtual world" in the >>>>> > documents would >>>>> > continue to raise the perennial question of "Which virtual world?". >>>>> > =A0After all, >>>>> > there would be two of them being discussed. >>>>> > >>>>> > It's this phraseology that stems from OGP's original goal of adding >>>>> > single >>>>> > regions or RDs to an existing single virtual world (namely SL in th= e >>>>> > prototype) >>>>> > that is creating such a problem. =A0That phraseology was appropriat= e >>>>> > for that >>>>> > original goal. =A0It is not appropriate for the goal of interoperat= ing >>>>> > multiple >>>>> > virtual worlds --- it makes it impossible to even talk about the go= al >>>>> > sensibly, >>>>> > because "the virtual world" in the OGP sense has no plural. >>>>> > >>>>> > It's unfortunate, but this whole affair is just the product of lega= cy >>>>> > wording >>>>> > from OGP. =A0That's never going to work in a multi-world setting wh= ere >>>>> > we need to >>>>> > talk about the endpoints in different worlds. >>>>> > >>>>> > >>>>> > Morgaine. >>>>> > >>>>> > PS. If anyone else read this far other than Carlo, you have a lot o= f >>>>> > stamina >>>>> > and dedication. ;-) >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> > >>>>> > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood wrote= : >>>>> > >>>>> > =A0 =A0 On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote: >>>>> > =A0 =A0 > The problem you see is that a virtual world is much more = than >>>>> > just a >>>>> > =A0 =A0 Region >>>>> > =A0 =A0 > Domain. =A0It is a complete set of services of which the = Region >>>>> > Domain >>>>> > =A0 =A0 service is >>>>> > =A0 =A0 > just one. =A0Other typical services might be those of the= Agent >>>>> > Domain >>>>> > =A0 =A0 (which >>>>> > =A0 =A0 > provides identification and authorization services and po= ssibly >>>>> > others), >>>>> > =A0 =A0 as >>>>> > =A0 =A0 > well as asset and inventory services, IM and other >>>>> > communication >>>>> > =A0 =A0 services, and >>>>> > =A0 =A0 > maybe several more. >>>>> > >>>>> > =A0 =A0 Well... that is purely semantic. It is a way to define VW, = but >>>>> > not one that >>>>> > =A0 =A0 I've been using :/ >>>>> > >>>>> > =A0 =A0 For simplicity, assume that only two things are needed to c= reate >>>>> > a complete >>>>> > =A0 =A0 virtual world, like SL or OG: A Region Domain (RD) and an A= gent >>>>> > Domain >>>>> > =A0 =A0 (AD). >>>>> > >>>>> > =A0 =A0 Currently, without any interop, each administrative entity = (or >>>>> > trust >>>>> > =A0 =A0 entity) >>>>> > =A0 =A0 will need to provide both: an RD *and* an AD, otherwise the= y >>>>> > don't have a >>>>> > =A0 =A0 functional VW. >>>>> > >>>>> > =A0 =A0 Your conclusion is that a VW exist of both 1 RD and 1 AD. B= ut I >>>>> > ask you to >>>>> > =A0 =A0 reconsider if that conclusion is correct, because it is bas= ed on >>>>> > the >>>>> > =A0 =A0 current >>>>> > =A0 =A0 situation without any interop. Now "correct" might not be t= he >>>>> > correct word >>>>> > =A0 =A0 - heh. >>>>> > =A0 =A0 Rather I should say: I ask you to reconsider if that defini= tion >>>>> > is very >>>>> > =A0 =A0 useful. >>>>> > >>>>> > =A0 =A0 Lets consider the following fictive case: >>>>> > >>>>> > =A0 =A0 LL runs one RD and AD, called RD1 and AD1. >>>>> > =A0 =A0 CB (Cable Beach) runs another RD and AD, called RD2 and AD2= . >>>>> > =A0 =A0 A user that authenticates with either AD1 or AD2 can travel= to >>>>> > RD1 AND RD2, >>>>> > =A0 =A0 completely symmetrical, keeping their respective AD1- and A= D2- >>>>> > assets etc. >>>>> > =A0 =A0 This is possible with the right policies, so for the sake o= f >>>>> > looking at >>>>> > =A0 =A0 the usefulness of the above definition of VW, assume this i= s the >>>>> > case. >>>>> > >>>>> > =A0 =A0 Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to b= e >>>>> > another VW? >>>>> > =A0 =A0 Or do you think it would make most sense in THIS case to sp= eak of >>>>> > a single >>>>> > =A0 =A0 VW? >>>>> > >>>>> > =A0 =A0 I think this is what Infinity means when she says that "vir= tual >>>>> > world" >>>>> > =A0 =A0 cannot >>>>> > =A0 =A0 be defined, because what could be perceived as being a VW i= s >>>>> > highly >>>>> > =A0 =A0 dependend >>>>> > =A0 =A0 on the exact situation (and policies) and in certain >>>>> > configuration that are >>>>> > =A0 =A0 not as clear as the current situation (no interop) or the a= bove >>>>> > example >>>>> > =A0 =A0 (100% >>>>> > =A0 =A0 interop). >>>>> > >>>>> > =A0 =A0 In one of my first posts about this topic I stated that "vi= rtual >>>>> > world" >>>>> > =A0 =A0 should >>>>> > =A0 =A0 be considered to be the Region Domain (although I didn't us= e that >>>>> > term at >>>>> > =A0 =A0 the >>>>> > =A0 =A0 moment) and be completely independent of the Agent Domain, = based >>>>> > on typical >>>>> > =A0 =A0 cases of abuse and griefing etc: if anyone annoys some othe= r >>>>> > user, or >>>>> > =A0 =A0 breaks >>>>> > =A0 =A0 almost any ToS, it will be region based; which is why I've = always >>>>> > said that >>>>> > =A0 =A0 any type of abuse can and should be handled at the sim (sin= gle >>>>> > region) >>>>> > =A0 =A0 level: >>>>> > =A0 =A0 the estate owner and managers in SL, even, but that idea >>>>> > definitely extends >>>>> > =A0 =A0 to "world administrations": the people running the REGION >>>>> > (domain) is the >>>>> > =A0 =A0 one >>>>> > =A0 =A0 that should decide what is the local ToS and deal with abus= e etc. >>>>> > That is >>>>> > =A0 =A0 why I strongly argue to define "virtual world" as Region Do= main, >>>>> > and leave >>>>> > =A0 =A0 the AD out of it. Nevertheless, now I have the term "Region >>>>> > Domain" I don't >>>>> > =A0 =A0 need "virtual world" anymore. >>>>> > >>>>> > =A0 =A0 > In our new protocol, these services may either be impleme= nted >>>>> > internally >>>>> > =A0 =A0 within >>>>> > =A0 =A0 > a virtual world, or some might be implemented as external >>>>> > services >>>>> > =A0 =A0 offered by >>>>> > =A0 =A0 > third parties, the choice being a policy and design decis= ion >>>>> > for each >>>>> > =A0 =A0 world >>>>> > =A0 =A0 > operator. =A0In all cases however, the virtual worlds are= defined >>>>> > by a set >>>>> > =A0 =A0 of >>>>> > =A0 =A0 > services, and not just by a Region Domain. >>>>> > >>>>> > =A0 =A0 I'm afraid that is purely a matter of opinion. I agree that= it is >>>>> > likely >>>>> > =A0 =A0 that a single 'administrative entity' that runs a RD will a= lso >>>>> > run an AD >>>>> > =A0 =A0 and allow users authenticated with their AD visit their RD,= but >>>>> > it is no >>>>> > =A0 =A0 more than *likely*. There will almost certainly be service >>>>> > provides that >>>>> > =A0 =A0 ONLY run an AD, and don't have a RD! And I can imagine that= there >>>>> > will >>>>> > =A0 =A0 be some that only run a RD and do not care about running th= eir >>>>> > own AD. >>>>> > >>>>> > =A0 =A0 Therefore, "virtual world" cannot be synonym for "the set o= f >>>>> > services >>>>> > =A0 =A0 run by a single administrative entity" as you seem to argue= , and >>>>> > at >>>>> > =A0 =A0 the SAME time be argued to include an RD *and* AD at all ti= mes. >>>>> > >>>>> > =A0 =A0 > This is easy to see by looking at a couple of archetypal >>>>> > examples in this >>>>> > =A0 =A0 > space: >>>>> > =A0 =A0 > >>>>> > =A0 =A0 > >>>>> > =A0 =A0 > =A0 =A0 Is Second Life a virtual world? =A0Undoubtedly. = =A0Is Second >>>>> > Life just a >>>>> > =A0 =A0 Region >>>>> > =A0 =A0 > =A0 =A0 Domain (assuming it were implemented using VWRAP)= ? =A0No, of >>>>> > course >>>>> > =A0 =A0 not, SL >>>>> > =A0 =A0 > =A0 =A0 includes all of the services mentioned above, and= others. >>>>> > >>>>> > =A0 =A0 Of course, LL happens to run all services that are needed t= o >>>>> > create one >>>>> > =A0 =A0 virtual world; there are no third parties they can hire fro= m yet, >>>>> > so they >>>>> > =A0 =A0 have to provide it all themselves. >>>>> > >>>>> > =A0 =A0 But after SL implemented VWRAP they might decide to do away= from >>>>> > one of >>>>> > =A0 =A0 their services and only keep their RD. Unlikely, but possib= le. >>>>> > >>>>> > =A0 =A0 > =A0 =A0 Is OSgrid a virtual world? =A0Undoubtedly. =A0Is = OSgrid just a >>>>> > Region >>>>> > =A0 =A0 Domain >>>>> > =A0 =A0 > =A0 =A0 (assuming it were implemented using VWRAP)? =A0No= , of course >>>>> > not, it >>>>> > =A0 =A0 > =A0 =A0 currently runs all the UGAIM services, which in a= VWRAP >>>>> > context would >>>>> > =A0 =A0 > =A0 =A0 become similar to those of Second Life. >>>>> > >>>>> > =A0 =A0 Exact same argument. >>>>> > >>>>> > =A0 =A0 > So you see, the idea that has been floated which claims t= hat >>>>> > "VW =3D=3D RD" >>>>> > =A0 =A0 is >>>>> > =A0 =A0 > completely wrong, and misrepresents what constitutes a "v= irtual >>>>> > world" >>>>> > =A0 =A0 despite >>>>> > =A0 =A0 > the very clear examples before us. >>>>> > >>>>> > =A0 =A0 If you want to put it that way (including everything above = that >>>>> > you said) >>>>> > =A0 =A0 then >>>>> > =A0 =A0 I have to side with Infinity: you cannot define a virtual w= orld >>>>> > that way >>>>> > =A0 =A0 and >>>>> > =A0 =A0 use it for useful discussions regarding VWRAP. >>>>> > >>>>> > =A0 =A0 In the end, one virtual world as defined by "all services >>>>> > together to make >>>>> > =A0 =A0 things work" will be, or can be, a mix of many RD's and man= y AD's >>>>> > with a >>>>> > =A0 =A0 complex >>>>> > =A0 =A0 web of trust/non-trust between them that makes the concept = of >>>>> > "virtual >>>>> > =A0 =A0 world" >>>>> > =A0 =A0 rather fuzzy at best. >>>>> > >>>>> > =A0 =A0 [...] >>>>> > =A0 =A0 > As we move into analysis of the problem space, these issu= es >>>>> > will be >>>>> > =A0 =A0 > disentangled and clarified and the protocols will be defi= ned >>>>> > and evolve, >>>>> > =A0 =A0 but >>>>> > =A0 =A0 > from the current OGP perspective there is no symmetrical >>>>> > relationship >>>>> > =A0 =A0 possible >>>>> > =A0 =A0 > between VWs that could be described as "peering". =A0It i= s the >>>>> > asymmetry of >>>>> > =A0 =A0 the >>>>> > =A0 =A0 > VW-RD relationship that has been the crux of the "no VW >>>>> > interop" issue. >>>>> > =A0 =A0 For >>>>> > =A0 =A0 > symmetrical peering, the protocol would need to mention a= t >>>>> > least two >>>>> > =A0 =A0 > communicating VWs. >>>>> > >>>>> > =A0 =A0 You can about peering with just two RD's and one AD, or one= RD >>>>> > and two >>>>> > =A0 =A0 AD's. >>>>> > >>>>> > =A0 =A0 > Of course the situation could change as the protocol evol= ves. >>>>> > =A0For >>>>> > =A0 =A0 example, >>>>> > =A0 =A0 > once or twice we have heard mention that multiple ADs cou= ld be >>>>> > involved >>>>> > =A0 =A0 in some >>>>> > =A0 =A0 > way, and it seems certain that communication services fro= m >>>>> > multiple VWs >>>>> > =A0 =A0 will be >>>>> > =A0 =A0 > merged because residents demand this. =A0This would start= to take >>>>> > us into >>>>> > =A0 =A0 VW-VW >>>>> > =A0 =A0 > interop territory. =A0However, there is no such thing in = VWRAP >>>>> > currently, >>>>> > =A0 =A0 and >>>>> > =A0 =A0 > it's not in the list of deliverables to include it, and >>>>> > therefore we >>>>> > =A0 =A0 cannot say >>>>> > =A0 =A0 > that VWRAP will provide VW-VW interop at all. =A0For now.= ;-) >>>>> > >>>>> > =A0 =A0 I can't comment on that cause I didn't see VWRAP yet, but f= rom >>>>> > the >>>>> > =A0 =A0 charter and the comments on this list I'd think that full s= upport >>>>> > =A0 =A0 for interop between any number of RD's and AD's is intended= . >>>>> > >>>>> > =A0 =A0 -- >>>>> > =A0 =A0 Carlo Wood >>>>> > >>>>> > >>>>> >>>>> > _______________________________________________ >>>>> > ogpx mailing list >>>>> > ogpx@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/ogpx >>>>> >>>>> >>>>> -- >>>>> Carlo Wood >>>>> _______________________________________________ >>>>> ogpx mailing list >>>>> ogpx@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ogpx >>>> >>> >>> >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >>> >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From cfk@pacbell.net Thu Oct 1 14:47:13 2009 Return-Path: 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 0FAC43A69DF for ; Thu, 1 Oct 2009 14:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.813 X-Spam-Level: ** X-Spam-Status: No, score=2.813 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, SARE_FWDLOOK=1.666, SARE_UNSUB18=0.131] 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 SFb5GW2hL8pZ for ; Thu, 1 Oct 2009 14:47:06 -0700 (PDT) Received: from web82607.mail.mud.yahoo.com (web82607.mail.mud.yahoo.com [68.142.201.124]) by core3.amsl.com (Postfix) with SMTP id 336633A69BA for ; Thu, 1 Oct 2009 14:47:05 -0700 (PDT) Received: (qmail 83581 invoked by uid 60001); 1 Oct 2009 21:48:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=O5HjjeIbE5wmvIAMcOAbfFekZqqWWyeToKX5039vB3V5Gbd7abEGfar+dPHLo4S2tCnNk5OwO1d18sSAQs8QEQK/18hxPxQRe4GtIH2U8V8oFZHY1jdUvCzSaZhpdwmk76QYgA9hvQbWJ19M1wUHLcRimsuaQnFvRMj/6Y8fV5I=; Message-ID: <472889.79438.qm@web82607.mail.mud.yahoo.com> X-YMail-OSG: lCHZpO8VM1lrOGy58ilI4.cIxVf2fVZSJu1BicFdgjps5NB3I0BG1dco Received: from [75.212.124.14] by web82607.mail.mud.yahoo.com via HTTP; Thu, 01 Oct 2009 14:48:28 PDT X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.3 References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090902230338.GC6652@alinoe.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Thu, 1 Oct 2009 14:48:28 -0700 (PDT) From: Charles Krinke To: Morgaine , ogpx@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2056852013-1254433708=:79438" Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 21:47:13 -0000 --0-2056852013-1254433708=:79438 Content-Type: text/plain; charset=us-ascii This seems like the right path to me, too. In thinking about this, lets consider saying that where two policies of two interoperable grids intersect is the interesting case. To take it back to SecondLife and say, an OpenSim grid, the first few things in an interop teleport are going to be avatarName and avatarAppearance. In thinking of how this may work, it would seem that we will probably end up with something like "FirstLast@SecondLife.com" when teleporting to, say OSGrid from Secondlife to OSGrid and perhaps "FirstLast@OSGrid.org" when teleporting from OSGrid to SecondLife. So, ... perhaps the policy may define the format of the name carried across in the teleport as it is reasonable to assume that an avatar in SecondLife does not have an account on OSGrid, and the converse is also true. Second, I suspect we need to define what happens when an avatar attempts a teleport with attachments (particularly scripted attachments). I rather suspect that neither grid will wish to allow teleporting with scripting attachments without a significant amount of negotiation between the two corporations. As far as inventory goes, I rather suspect we wish to either avoid moving inventory between grids, or, ... perhaps define a 'vanilla' subset such as those items marked with 'export from grid, full permissions' bits set. I am taking that from memory in thinking about the additional bitfield for object exports discussion on SecondLife a year or so ago. I am trying to think of the simplest cases that will have the minimum of cussin, discussin and debate to get our minds wrapped around how to move forward a bit. Certainly, I have my mind wrapped around Zha's statement a year or so ago that went (if I recall more or less correctly): "We will have interop when I can slay a monster on WoW, teleport to a club in SecondLife, mount the monsters head on the wall and buy everyone a drink". Charles ________________________________ From: Morgaine To: ogpx@ietf.org Sent: Thursday, October 1, 2009 2:34:10 PM Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell wrote: >IMHO, it should be apparent that both AD (which is the >agent/advocate for the user) and RD (where the user wants to be) both >need to make policy decisions. > > Excellent, Joshua! I think we're finally approaching the road towards Destination Determines Policy now, which is a prerequisite for real interop between virtual worlds. This was simply not possible with the old OGP thinking in which policy was given by a "trust domain" defined by a single AD alone. It's a two-part problem. Naturally your source world can impose restrictions on travel (a walled garden may disallow any foreign travel at all, for example), that's clear. What hasn't been clear until now is that the destination world will have conditions which are every bit as strong and important as the source world, and represented in the same way (eg. in their AD). Both sides must be allowed equivalent representation in the protocol. This is why the single-world terminology was such a barrier earlier. It completely prevented us from bringing the two worlds into the discussion simultaneously, which is necessarily when both source and destination are completely equivalent peer worlds. Your next step is to realize that, for two structurally identical worlds, if the seat of policy of one lies in its AD, then the seat of policy of the other also lies in its AD. Therefore your statement needs to be modified to the following: IMHO, it should be apparent that both the AD of the source world and the RD and AD of the destination world all need to make policy decisions. What's true for the source world is also true for the destination world, policy-wise. The destination world is not "inferior" in any way. It's a necessary peer in the protocol. You can't exclude it from the equation. Morgaine. ========================================= On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell wrote: Without diving in too deep, I believe this thread is putting up a two-level false dichotomy - either the RD determines policy or the AD determines policy, OR things aren't sensible w/o nil trust. If that's a mis-reading, my apologies. > >IMHO, it should be apparent that both AD (which is the agent/advocate for the user) and RD (where the user wants to be) both need to make policy decisions. > >A corporate AD may restrict where users may visit (e.g. agentd.corp.example.com may say "no visiting party.example.com from work!") or an AD may restrict users based on personal preferences (agentd.safesurf.example.com may say "scam.example.com is on a shared blacklist of malicious sites, teleport blocked"), legal or political requirements (agentd.kidfriendly.example.com may say "you can't visit adultgrid.example.com"). Note that in all cases the AD is enforcing policy as an agent of the user, just as a web browser on a local network does today. Presumably, there will exist many ADs that provide no restrictions whatsoever, just as most Web browsers accessing the 'net via most ISPs in most countries today don't restrict access to Web content via policy. > >On the flip side, the RD will also have policy. Corporate VWs may limit access to employees. Adult-centric VWs may limit access to agents from ADs that verify accounts with some well known service. Real-world-region-specific RDs may require citizenship checks and deny access to citizens of some nation-states. And of course permissions would doubtless exist on a per-user basis as well as per-AD. Again - no different than access permissions today on the Web, except that instead of being a two-party user/service, it's three party user/AD/RD. And one hopes that, like most of the Web, content is freely visitable by all. > >On the topic of nil-trust: again, I wholeheartedly support the stance that the protocol should support nil trust operation. I hope that both the protocol and operations of VWRAP-based worlds allow the bulk of VWRAP traffic to occur in a nil trust environment, just like the Web does today. However, I *suspect* that, in practical terms, the abilities we want to grant to regions by visiting them - to display our avatars, to broadcast information about our agents, to give and receive virtual goods - will require at least a modicum of trust for most VW interaction, at least on the level of an SSL-style secured connection that gives users a certificate to look at that provides some identity/trust information about the service provider. > >I suspect I'm going to beat this drum a lot - "VWs are just like the Web, except where they're different" :) > > > >On Tue, Sep 29, 2009 at 5:51 PM, Morgaine wrote: > >Hi Vaughn! :-) >> >>Your description of our discussion is quite accurate. However, it seems to imply that I advocate in favour of the view that the AD must be the seat of all policy for connected regions. I do not. I was merely explaining the architecture of AD+RD pairing as it has been described to us repeatedly throughout the two years of our OGP-related work in the LL+IBM sponsored Architecture Working Group within Second Life. >> >>After the emails, Carlo and I examined this issue with higher discussion bandwidth inside SL, and it turned out that we were describing two different things: I was explaining the AD+RD relationship in OGP, while Carlo was describing RDs as they should be designed if an RD were an autonomous unit with its own policies, effectively a small world. If OGP were designed differently and less restrictively to allow that, then there would have been no discussion. :-) >> >>Of course, OGP is not VWRAP, but only the seedcorn for VWRAP. We can make VWRAP as flexible as we like, and it's easy to see its potential flexibility in David's deployments document. Consequently, I have high hopes that all parties will be happy with the eventual outcome. :-) >> >>You may have missed the primary reason why I do not advocate a design in which an OGP-style AD is the seat of all power, possibly because the discussion has been spread out across all of OGPX and MMOX. It's easy to summarize in one sentence though: such a design cannot underpin an Internet-wide metaverse of interoperating virtual worlds because it doesn't respect the key meme of virtual and non-virtual tourism: Destination Determines Policy. >> >>This meme is so fundamental and crucial (and obvious) that OGP's support of the exact opposite is terminally broken, as a basis for the hypothetical metaverse. Indeed, you yourself have referred to the problem in the funny "war over purple". :-) At best such a design can support only a random scattering of VPN-like walled gardens, all isolated and incapable of interoperating because they all claim the "one true policy". We should not go there. >> >>The most recent description of this problematic aspect of the OGP design was posted by Magnus Zeisig in his excellent email at http://www.ietf.org/mail-archive/web/ogpx/current/msg00324.html , which I fully support. Such balkanization is not a desireable goal when designing a VW interop protocol. >> >>So where are we now? We're at the stage of examining David's VWRAP deployment patterns to see how the protocol can support them. And in that examination, it is likely to become clear that the old OGP model of "AD determines policy" is completely non-viable for interoperating between VWRAP-compatible virtual worlds, except when that policy is "nil trust" as a common denominator. >> >>Consequently, we will either decide to live with the original OGP split and use "nil trust" as our basis for VW interop, or else we will redesign the AD/RD relationship to place many more important policy decisions where they really belong, at destination. The latter seems the best choice to me, and of course it would make Carlo happy, and it is also the model that every single existing world already operates --- when in Rome, do as the Romans do. Only the old OGP AD/RD two-way split design is out of step. Let's hope that we can correct that in VWRAP. :-)) >> >> >>Morgaine. >> >> >> >> >> >> >>==================================== >> >> >> >> >>On Tue, Sep 29, 2009 at 9:16 PM, Vaughn Deluca wrote: >> >>Carlo and Morgaine have above been involved in a very interesting discussion about the nature of the (or *a*) virtual world. >>> >>> >>>Painting their positions with broad strokes, Morgaine stresses the primary role of the AD as the seat of policy and trust, up to the point where he denies the RD any role above that of a convenient extension of the AD, i.e. the RD as "colony without a government". Carlo passionately argues for the independent role of the RD in policy issues. >>> >>> >>>I feel that both positions are valid (to some degree), and both can be covered by VWRAP. >>> >>> >>>Calo makes absolutely clear that having all policy in the respective ADs of the avatars leads to problems when several avatars meet in one region domain, say RD1. Avatars will be busy killing each other over the right to wear purple, and for the innocent bystanders caught in the crossfire it will be fully unclear were to complain. Stepping in Morgaines shoes, i think i would argue that what Carlo asks for can be realised by applying the policy of a *particular* AD to RD1. The rules to deal with color of clothes, could be formulated in AD1 associated with RD1. In principle Carlo could run this domain himself, even without a single avatar in it, and in this way get his "government" and set any policy he wants. If two avatars from AD2 and AD3 visit RD1, The policy in RD1 would be governed by what is specified by AD1. >>> >>> >>>While this fully fits Morgaines view of "AD rules all", and also fits Carlo call for autonomy of RD1, it feels decidedly like a kludge, and in this particular case it seems much more straightforward to make RD1 more autonomous. Yet, to keep everything within one framework, this kludge seems to be the logical solution... I would like to hear what others think about this. >>> >>> >>>One other remark: the minimal example for a "world" -one AD and one RD- would be more useful when extended with one asset service AS. Explicit mentioning of the AS will make it much easier to discuss IP issues. >>> >>>Vaughn >>> >>> >>> >>> >>> >>>On Mon, Sep 14, 2009 at 10:44 AM, Carlo Wood wrote: >>> >>>On Mon, Sep 14, 2009 at 06:43:06AM +0100, Morgaine wrote: >>>>>>>>> Carlo asked for detailed comments on the below, so here goes. :-) >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood wrote: >>>>>>>>> >>>>>>>>> On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote: >>>>>>>>> > The problem you see is that a virtual world is much more than just a >>>>>>>>> Region >>>>>>>>> > Domain. It is a complete set of services of which the Region Domain >>>>>>>>> service is >>>>>>>>> > just one. Other typical services might be those of the Agent Domain >>>>>>>>> (which >>>>>>>>> > provides identification and authorization services and possibly others), >>>>>>>>> as >>>>>>>>> > well as asset and inventory services, IM and other communication >>>>>>>>> services, and >>>>>>>>> > maybe several more. >>>>>>>>> >>>>>>>>> Well... that is purely semantic. It is a way to define VW, but not one that >>>>>>>>> I've been using :/ >>>>>>>>> >>>>>>>>> >>>>>>>>> It's a rough top-level projection of the architectural model of VWRAP, once the >>>>>>>>> various services have been decoupled in the way that David Levine often >>>>>>>>> describes to us. Nothing very contentious there, everyone likes a >>>>>>>>> services-oriented approach. :-) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> For simplicity, assume that only two things are needed to create a complete >>>>>>>>> virtual world, like SL or OG: A Region Domain (RD) and an Agent Domain >>>>>>>>> (AD). >>>>>>>>> >>>>>>>>> >>>>>>>>> I am happy to consider that simple scenario as representative. It is quite >>>>>>>>> reasonable to equate AD with VW because the AD is the focus of almost all the >>>>>>>>> policy decisions of a VWRAP-based world. When other decoupled services are >>>>>>>>> added to this picture, it doesn't change the fundamental architecture of AD + >>>>>>>>> RDs, only extends it by decoupling more than just the region service. So >>>>>>>>> that's fine with me. >>>> >>>>I totally disagree that the AD is the representative...and why do you say >>>>>>>>that below a sentence of me where I say "A Region Domain (RD) and an Agent Domain (AD)"? >>>> >>>>>>>>This is like I say "VW = AD + RD", and you go: "yes, VW = AD". We can't >>>>>>>>have a discussion like that Morgaine. >>>> >>>> >>>>>>>>> Currently, without any interop, each administrative entity (or trust >>>>>>>>> entity) >>>>>>>>> will need to provide both: an RD *and* an AD, otherwise they don't have a >>>>>>>>> functional VW. >>>>>>>>> >>>>>>>>> >>>>>>>>> Correct. The AD is the seat of most (but not all) of the policy decisions of a >>>> >>>>I even *stressed* the '*and*' here, and you do it again. >>>> >>>> >>>>>>>>> VW, so it's very central to the existence of a VW. While it's possible to >>>>>>>>> imagine policy-free VWs that temporarily take on the policy of any other world >>>>>>>>> they hook up with, this is clearly a subset situation. All the currently known >>>>>>>>> SL-like virtual worlds are grids of the SL kind, with their own individual >>>>>>>>> policies which they are not going to change on interop. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Your conclusion is that a VW exist of both 1 RD and 1 AD. But I ask you to >>>>>>>>> reconsider if that conclusion is correct, because it is based on the >>>>>>>>> current >>>>>>>>> situation without any interop. Now "correct" might not be the correct word >>>>>>>>> - heh. >>>>>>>>> Rather I should say: I ask you to reconsider if that definition is very >>>>>>>>> useful. >>>>>>>>> >>>>>>>>> Lets consider the following fictive case: >>>>>>>>> >>>>>>>>> LL runs one RD and AD, called RD1 and AD1. >>>>>>>>> CB (Cable Beach) runs another RD and AD, called RD2 and AD2. >>>>>>>>> A user that authenticates with either AD1 or AD2 can travel to RD1 AND RD2, >>>>>>>>> completely symmetrical, keeping their respective AD1- and AD2- assets etc. >>>>>>>>> This is possible with the right policies, so for the sake of looking at >>>>>>>>> the usefulness of the above definition of VW, assume this is the case. >>>>>>>>> >>>>>>>>> >>>>>>>>> That's not quite right because Cable Beach is not a world provider like LL. >>>>>>>>> Cable Beach is perhaps best described as a "login mediation" mechanism or >>>> >>>>I might not understand what the real Cable Beach is or wants to be, I was just >>>>>>>>trying to give an example to work with. So, again: >>>> >>>> >>>>>>>>LL runs one RD and AD, called RD1 and AD1. >>>>OG runs another RD and AD, called RD2 and AD2. >>>> >>>>A user that authenticates with either AD1 or AD2 can travel to RD1 AND RD2, >>>>>>>>completely symmetrical, keeping their respective AD1- and AD2- assets etc. >>>>>>>>This is possible with the right policies, so for the sake of looking at >>>>>>>>the usefulness of the above definition of VW, assume this is the case. >>>> >>>> >>>>> protocol, which provides a model for interaction between a "world service" >>>>>>>>> (effectively an AD), the user's client, and various decoupled services such as >>>>>>>>> simulation nodes (possibly an RD) and inventory/asset services. Let's assume >>>>>>>>> therefore that your "CB" above means something different (another world >>>>>>>>> provider similar to LL), and then we can proceed with your example case. >>>> >>>>Ok >>>> >>>> >>>>>>>>> Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be another VW? >>>>>>>>> Or do you think it would make most sense in THIS case to speak of a single >>>>>>>>> VW? >>>>>>>>> >>>>>>>>> >>>>>>>>> They're two worlds because you defined them as such, as each has its own AD. >>>>>>>>> :-) But that aside, if they were set up separately then they have two >>>>>>>>> different sets of policies, two different sets of residents, two different >>>>>>>>> ToS's, possibly two different legal jurisdictions, two different mechanisms for >>>>>>>>> abuse control and conflict resolution, and so on and so forth. If they were >>>>>>>>> created to be worlds that can stand alone but interoperate when desired, then >>>>>>>>> each of these is a diffferent world. I don't see how that can be disputed. >>>> >>>>As I stated in one of my first posts, it will (hopefully!!!) be mainly the >>>>>>>>the *RD* and NOT the AD that all of those things are a function of! >>>> >>>>>>>>You keep saying that it's mainly the AD that determines these things, but >>>>>>>>that would be confusing and very annoying. If two people meet in a virtual >>>>>>>>world, that is - if they are standing next to eachother in one region and >>>>>>>>using local chat - then they should fall under the same legal jurisdiction >>>>>>>>and the same ToS: it is the region that determines the rules, not the AD >>>>>>>>that they used to login with. >>>> >>>>>>>>As example, ToS1 says: it's ok to be naked; and ToS2 says: it's a bannable >>>>>>>>offence to be naked. Do you really think that it's even workable if the >>>>>>>>ToS to be applied is a function of the AD? Say you login using AD2, so >>>>>>>>ToS2 applies to you. You meet someone else that is naked. You know that >>>>>>>>you are not allowed to and you are offended. You create an abuse report; >>>>>>>>where does that report go to? To your AD administration? That makes no >>>>>>>>sense: that naked person is using a different AD. To his/her AD administration >>>>>>>>then? That makes also no sense since they allow it. >>>> >>>>>>>>Seriously, there is only one reasonable thing to do: the ToS that applies >>>>>>>>is a function of the Region Domain *only*, and if you write an abuse report, >>>>>>>>it should go to the administration of the region that you are in and not >>>>>>>>to your or the others AD administration. Same holds for the things related >>>>>>>>to legal jurisdiction and any other 'rules' that applies at any given >>>>>>>>moment (to users). The only thing that might be a function of the AD are >>>>>>>>technical policies that are automatically enforced by VWRAP. >>>> >>>> >>>>>>>>> I think this is what Infinity means when she says that "virtual world" >>>>>>>>> cannot >>>>>>>>> be defined, because what could be perceived as being a VW is highly >>>>>>>>> dependend >>>>>>>>> on the exact situation (and policies) and in certain configuration that are >>>>>>>>> not as clear as the current situation (no interop) or the above example >>>>>>>>> (100% >>>>>>>>> interop). >>>>>>>>> >>>>>>>>> >>>>>>>>> This is incorrect. "Virtual world" is defined by each provider of a virtual >>>>>>>>> world and by nobody else, and each provider knows full well how it is defined, >>>>>>>>> what its boundaries are, and what makes it distinct. Nobody else can define >>>>>>>>> what a virtual world is, and it's not our business to define it either (nor to >>>>>>>>> conjure up a fictitious definition). >>>> >>>>Sorry, but I think you should try harder to understand my point of view first. >>>>>>>>I didn't give the examples so you can ignore them. >>>> >>>> >>>>>>>>> We only need to define the protocol interactions at the endpoints presented by >>>>>>>>> those worlds, and not to define "virtual world" structurally nor any other way. >>>>>>>>> Doing so is what has got us into this mess, by creating a fictitious >>>>>>>>> definition based on reachability and hence blocking any ability to talk about >>>>>>>>> actual virtual worlds. Those worlds exist. They won't go away. They want to >>>>>>>>> interoperate, but they don't want to be told that they don't exist. >>>> >>>>I was trying to make you understand WHY Infinitely tells you they don't "exist", >>>>>>>>if you understand her (and you don't, imho) then it will be easier to solve this >>>>>>>>miscommunication. >>>> >>>> >>>>>>>>> The contention that we don't know what "virtual world" means is just plain >>>>>>>>> bizarre. >>>> >>>>Only if you already have a definition of "virtual world" they way you do. >>>> >>>> >>>>>>>>> I don't know of any VW operator who doesn't know what their world is. >>>> >>>>That is the *current* situation... which is 100% simpler than what we'll >>>>>>>>have in the future. >>>> >>>>>>>>Compare with math... currently we only have Integers (Z). We're about >>>>>>>>to introduce division and by that we need to extend the definition of >>>>>>>>'number' from Z to Q. Q aren't integers, even though currently every >>>>>>>>number is an integer doesn't mean you have to hold on tight the "definition" >>>>>>>>of "number" == integer. That definition will be broken and you will >>>>>>>>have to redefine "number". >>>> >>>> >>>>>>>>> Every single one of them could provide the necessary endpoints for VWRAP >>>>>>>>> within their world without any scratching of heads at the meaning of "virtual >>>>>>>>> world". That repeated allegation has been a complete misrepresentation. It's >>>>>>>>> just not true. >>>> >>>>You CANNOT define "virtual world" as "AD" (see above) nor as "AD + RD" because >>>>>>>>that is too simple and only holds in the current situation. You can only, at most, >>>>>>>>if you really want, say - well, lets define it as being some RD. >>>> >>>> >>>>>>>>> And possibly even worse is the excuse that "virtual world" is not being >>>>>>>>> defined but is being used non-normatively, while in practice using the phrase " >>>>>>>>> the virtual world" to create a totally fictitious single virtual world instead. >>>> >>>>I agree that as long as it isn't normatively defined, the term shouldn't be >>>>>>>>used in documents except in places where it can literally mean anything without >>>>>>>>that anyone will care (like in the protocol name). >>>> >>>> >>>>>>>>> That phrase is unnecessary, it is misrepresentative of the actual situation, >>>>>>>>> it bypasses policy controls of one world by not mentioning its AD, it prevents >>>>>>>>> us from mentioning virtual worlds by blocking the normal meaning of the term, >>>>>>>>> and it provides nothing useful as a benefit in return. Unless total confusion >>>>>>>>> is a benefit. ;-) >>>> >>>>Sorry, but that is like saying that defining the Rational Numbers (Q) makes it >>>>>>>>impossible to talk about 'numbers', because 3/7 isn't an integer. >>>>>>>>What you have to do is let go of your current definition. >>>> >>>> >>>>>>>>> In one of my first posts about this topic I stated that "virtual world" >>>>>>>>> should >>>>>>>>> be considered to be the Region Domain (although I didn't use that term at >>>>>>>>> the >>>>>>>>> moment) and be completely independent of the Agent Domain, based on typical >>>>>>>>> cases of abuse and griefing etc: if anyone annoys some other user, or >>>>>>>>> breaks >>>>>>>>> almost any ToS, it will be region based; which is why I've always said that >>>>>>>>> any type of abuse can and should be handled at the sim (single region) >>>>>>>>> level: >>>>>>>>> the estate owner and managers in SL, even, but that idea definitely extends >>>>>>>>> to "world administrations": the people running the REGION (domain) is the >>>>>>>>> one >>>>>>>>> that should decide what is the local ToS and deal with abuse etc. That is >>>>>>>>> why I strongly argue to define "virtual world" as Region Domain, and leave >>>>>>>>> the AD out of it. Nevertheless, now I have the term "Region Domain" I don't >>>>>>>>> need "virtual world" anymore. >>>>>>>>> >>>>>>>>> >>>>>>>>> But that's not how OGP is structured. It's the AD that is the focus of service >>>>>>>>> policy choices in OGP, and it's the "world service" that is the focus of >>>>>>>>> service policy in Cable Beach. The AD and the world service are the source of >>>>>>>>> capabilities that determine pretty much everything else, and the region domain >>>>>>>>> is very subsidiary to that. >>>> >>>>No, if the service prodiver of some AD disagrees with the (say) a ToS that applies >>>>>>>>when you go to some RD then they should disallow you go there; they should not >>>>>>>>allow you to go there and then demand that you follow their ToS, that would not >>>>>>>>be a practical solution that is workable. >>>> >>>>>>>>To use mathematics again, it's easy to make two ToS that have no intersection: >>>>>>>>Say, ToS1 says: you MUST wear purple clothes, and ToS2 says: you MUST wear blue >>>>>>>>clothes. Obviously those will apply to regions. >>>> >>>>>>>>So then we have: >>>> >>>>>>>>Provider1: RD1 --> TOS1 --> purple clothes >>>>>>>>Provider2: RD2 --> TOS2 --> blue clothes >>>> >>>>>>>>*if* Provider 2 runs an AD (AD2) and they allow people logged in with it >>>>>>>>to go to region RD1 then the people there should wear purple clothes: >>>>>>>>TOS2 will not apply because of the AD you use. >>>> >>>>>>>>If it's against providers religious believe to support wearing purple >>>>>>>>clothes than they might disallow people to go to RD1, that is their >>>>>>>>choice (policy). >>>> >>>> >>>>>>>>> Indeed, a region domain may have no policy of its >>>>>>>>> own at all, but merely extend an existing virtual world by accepting the >>>>>>>>> policies of that world's AD. That's the model in the original OGP before it >>>>>>>>> gained aspirations of becoming a cross-VW interop protocol. >>>> >>>>That makes no sense :/ >>>> >>>>>>>>There can be any number of people in a given RD, and each can in principle >>>>>>>>be using a different AD! PLEASE let the RD determine the rules they have >>>>>>>>to live by! Anyone else that disagrees with me about that?! >>>> >>>> >>>>>>>>> If RDs determined VW policy and generated seed capabilities for everything and >>>>>>>>> ADs were merely login services then your model would apply, and RD could be >>>>>>>>> considered "VW". >>>> >>>>Ah! At last.. >>>> >>>> >>>>>>>>> But that's not how it is currently structured --- RDs are >>>> >>>>If you are refering to OGP, then OGP should be changed. >>>> >>>> >>>>>>>>> merely the land + physical simulation components of worlds, and in SL's case, >>>>>>>>> also an elaborate system of proxies. And that's why we need multiple ADs to >>>>>>>>> interact in VWRAP before we can consider that there is VW-VW interop. RDs >>>>>>>>> don't handle it. >>>> >>>>What I seem to keep missing is the fact that VWRAP is already completely >>>>>>>>defined in those previous OGP documents and we're merely here to rewrite >>>>>>>>them in an IETF document of sorts. >>>> >>>>>>>>Yes we need multiple ADs to interact, and they will. >>>>>>>>But yes, RD's will handle whatever they have to handle with VWRAP. >>>>>>>>I never said that capabilities equal 'rules' (ToS and legal jurisdiction >>>>>>>>isn't something that should be enforced or controlled by the protocol) by >>>>>>>>the way. >>>> >>>>>>>>... sorry my RSI forces me to stop typing here... shouldn't have >>>>>>>>typed this much alrady anyway :( >>>> >>>> >>>>>>>>> > In our new protocol, these services may either be implemented internally >>>>>>>>> within >>>>>>>>> > a virtual world, or some might be implemented as external services >>>>>>>>> offered by >>>>>>>>> > third parties, the choice being a policy and design decision for each >>>>>>>>> world >>>>>>>>> > operator. In all cases however, the virtual worlds are defined by a set >>>>>>>>> of >>>>>>>>> > services, and not just by a Region Domain. >>>>>>>>> >>>>>>>>> >>>>>>>>> Indeed. But access to such decoupled services is provided by the AD through >>>>>>>>> the capabilities that it delivers to authorized parties, and regions are just >>>>>>>>> one such service. You're giving RDs credit for something that they don't do. >>>>>>>>> :-) Perhaps the VWRAP model should be redesigned along your lines so that RDs >>>>>>>>> become the VWs and are the generators of seed caps, and then ADs become just a >>>>>>>>> subservient policy-free login mechanism. :D >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm afraid that is purely a matter of opinion. I agree that it is likely >>>>>>>>> that a single 'administrative entity' that runs a RD will also run an AD >>>>>>>>> and allow users authenticated with their AD visit their RD, but it is no >>>>>>>>> more than *likely*. There will almost certainly be service provides that >>>>>>>>> ONLY run an AD, and don't have a RD! And I can imagine that there will >>>>>>>>> be some that only run a RD and do not care about running their own AD. >>>>>>>>> >>>>>>>>> >>>>>>>>> Oh sure, there will be all combinations of services, that is to be expected. >>>>>>>>> But it is the seat of policy that is the heart of each virtual world, and >>>>>>>>> currently the seat of policy lies in the AD. A VW that doesn't have an AD in >>>>>>>>> the VWRAP model is just a colony without a government, ready to be assimilated >>>>>>>>> into a world that has an AD and that therefore sets policies, instead of being >>>>>>>>> a sovereign world that merely wants to interop with that other world through >>>>>>>>> VWRAP. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Therefore, "virtual world" cannot be synonym for "the set of services >>>>>>>>> run by a single administrative entity" as you seem to argue, and at >>>>>>>>> the SAME time be argued to include an RD *and* AD at all times. >>>>>>>>> >>>>>>>>> >>>>>>>>> I don't follow that. Two worlds that can run independently (that's very >>>>>>>>> important) can certainly each be defined as a set of services that includes the >>>>>>>>> functions of an AD and an RD, and those worlds each continue to include the >>>>>>>>> functions of an AD and an RD even after they start interoperating (assuming >>>>>>>>> that VWRAP is extended to allow cross-VW interop). No world is going to give >>>>>>>>> up part of its services portfolio on interop. Interop is an additional >>>>>>>>> benefit, not a loss of capability. >>>>>>>>> >>>>>>>>> [It's worth noting that there may actually be a small loss of capability >>>>>>>>> occurring on interop in VWRAP, although it is rarely mentioned. You can be >>>>>>>>> present in two worlds simultaneously with the same login credentials >>>>>>>>> pre-interop (a feature that we enjoy currently between SL and OSgrid for >>>>>>>>> example), but post-interop this may no longer be possible --- it depends on the >>>>>>>>> implementation. No doubt we will visit this issue within VWRAP.] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > This is easy to see by looking at a couple of archetypal examples in this >>>>>>>>> > space: >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Is Second Life a virtual world? Undoubtedly. Is Second Life just a >>>>>>>>> Region >>>>>>>>> > Domain (assuming it were implemented using VWRAP)? No, of course >>>>>>>>> not, SL >>>>>>>>> > includes all of the services mentioned above, and others. >>>>>>>>> >>>>>>>>> Of course, LL happens to run all services that are needed to create one >>>>>>>>> virtual world; there are no third parties they can hire from yet, so they >>>>>>>>> have to provide it all themselves. >>>>>>>>> >>>>>>>>> But after SL implemented VWRAP they might decide to do away from one of >>>>>>>>> their services and only keep their RD. Unlikely, but possible. >>>>>>>>> >>>>>>>>> >>>>>>>>> You're confusing RD functionality with AD functionality again there. The AD is >>>>>>>>> the heart of a world because it defines its capabilities and policies. The RD >>>>>>>>> is just a pile of region hosts that could easily be farmed out to a third party >>>>>>>>> to run without them determining policy, and indeed this is already being done. >>>>>>>>> While it is a very important pile of hosts which gives a world its physical >>>>>>>>> characterists, the RD is a subservient service to the AD in OGP, just as the >>>>>>>>> equivalent "simulation nodes" provide a subservient service to the "world >>>>>>>>> service" under Cable Beach. The RD is well named --- it provides region >>>>>>>>> services only, not the package of internal + external services that together >>>>>>>>> create a virtual world. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > Is OSgrid a virtual world? Undoubtedly. Is OSgrid just a Region >>>>>>>>> Domain >>>>>>>>> > (assuming it were implemented using VWRAP)? No, of course not, it >>>>>>>>> > currently runs all the UGAIM services, which in a VWRAP context would >>>>>>>>> > become similar to those of Second Life. >>>>>>>>> >>>>>>>>> Exact same argument. >>>>>>>>> >>>>>>>>> >>>>>>>>> Exact same response because the same applies. :-) What's more, in OSgrid this >>>>>>>>> is even easier to identify, because every person or company that adds regions >>>>>>>>> to OSgrid is subscribing to the notion that they are participants in OSgrid --- >>>>>>>>> OSgrid is their virtual world. They are merely providing additional land mass >>>>>>>>> and simulation capacity. >>>>>>>>> >>>>>>>>> Also, in this example there is no need to hypothesize region services being >>>>>>>>> farmed out to third parties, as there already are hundreds to thousands of >>>>>>>>> independent third parties involved in supplying regions. Those regions and >>>>>>>>> clusters of regions (equivalent to RDs) together combine to create the virtual >>>>>>>>> world of OSgrid. There is a clear distinction between R/RDs here and the VW >>>>>>>>> itself, which also includes a variety of other services as Charles has >>>>>>>>> described several times. The R/RDs are a very important part, but functionally >>>>>>>>> they are not the VW, nor are they the VW perceptually. They are places within >>>>>>>>> the world, not the whole world. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > So you see, the idea that has been floated which claims that "VW == RD" >>>>>>>>> is >>>>>>>>> > completely wrong, and misrepresents what constitutes a "virtual world" >>>>>>>>> despite >>>>>>>>> > the very clear examples before us. >>>>>>>>> >>>>>>>>> If you want to put it that way (including everything above that you said) >>>>>>>>> then >>>>>>>>> I have to side with Infinity: you cannot define a virtual world that way >>>>>>>>> and >>>>>>>>> use it for useful discussions regarding VWRAP. >>>>>>>>> >>>>>>>>> >>>>>>>>> I think you may have misread that. I did not define "VW == RD". That's the >>>>>>>>> opposite of what I said, but I agree with you on the negative conclusion. If >>>>>>>>> one defines "VW == RD" then it becomes impossible to have a meaningful >>>>>>>>> discussion about VWs in VWRAP. It also becomes impossible to have a meaningful >>>>>>>>> discussion about VWs in VWRAP if one conjures up a fictitious meaning of >>>>>>>>> "virtual world" based on reachability. And that's why we should not define it >>>>>>>>> in either of those two ways. >>>>>>>>> >>>>>>>>> The most useful and forward-looking way of defining virtual worlds in VWRAP is >>>>>>>>> as a collection of service endpoints, regardless of who operates them. All we >>>>>>>>> should care about is the protocol between endpoints, and not conjure up some >>>>>>>>> non-existent single virtual world. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> In the end, one virtual world as defined by "all services together to make >>>>>>>>> things work" will be, or can be, a mix of many RD's and many AD's with a >>>>>>>>> complex >>>>>>>>> web of trust/non-trust between them that makes the concept of "virtual >>>>>>>>> world" >>>>>>>>> rather fuzzy at best. >>>>>>>>> >>>>>>>>> >>>>>>>>> You're right but you're not being clear about what is fuzzy. The concept of " >>>>>>>>> single virtual world" is not only fuzzy, it is totally non-existent in practice >>>>>>>>> (because there are many, not one) as well as impossible in theory because of >>>>>>>>> balkanization through incompatible trust domains, as described so magnificently >>>>>>>>> by Magnus a week or two ago. We should not go there. >>>>>>>>> >>>>>>>>> In contrast, the concept of multiple virtual worlds is crystal clear. Several >>>>>>>>> people here in the group operate virtual worlds, but nobody would suggest that >>>>>>>>> they are unclear about what they operate. We've been sold a bridge on that >>>>>>>>> "uncertainty". Multiple virtual worlds presenting VWRAP endpoints are the >>>>>>>>> natural way of approaching interop between VWs, and you don't have to define >>>>>>>>> VWs structurally for that. You only have to define the endpoints that VWs need >>>>>>>>> to present to the protocol, and avoid any notion of "single virtual world". >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [...] >>>>>>>>> > As we move into analysis of the problem space, these issues will be >>>>>>>>> > disentangled and clarified and the protocols will be defined and evolve, >>>>>>>>> but >>>>>>>>> > from the current OGP perspective there is no symmetrical relationship >>>>>>>>> possible >>>>>>>>> > between VWs that could be described as "peering". It is the asymmetry of >>>>>>>>> the >>>>>>>>> > VW-RD relationship that has been the crux of the "no VW interop" issue. >>>>>>>>> For >>>>>>>>> > symmetrical peering, the protocol would need to mention at least two >>>>>>>>> > communicating VWs. >>>>>>>>> >>>>>>>>> You can about peering with just two RD's and one AD, or one RD and two >>>>>>>>> AD's. >>>>>>>>> >>>>>>>>> >>>>>>>>> I think you're confusing RDs with VWs again --- RDs only provide regions, >>>>>>>>> nothing else. For peering between two VWs, you would need interaction between >>>>>>>>> their two ADs because their ADs provide their policies. If you bypass a VW's >>>>>>>>> AD then you bypass its policies, so you're not interoping with that world. And >>>>>>>>> I don't think we're encouraging bypassing and hence subverting a world's >>>>>>>>> policies. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > Of course the situation could change as the protocol evolves. For >>>>>>>>> example, >>>>>>>>> > once or twice we have heard mention that multiple ADs could be involved >>>>>>>>> in some >>>>>>>>> > way, and it seems certain that communication services from multiple VWs >>>>>>>>> will be >>>>>>>>> > merged because residents demand this. This would start to take us into >>>>>>>>> VW-VW >>>>>>>>> > interop territory. However, there is no such thing in VWRAP currently, >>>>>>>>> and >>>>>>>>> > it's not in the list of deliverables to include it, and therefore we >>>>>>>>> cannot say >>>>>>>>> > that VWRAP will provide VW-VW interop at all. For now. ;-) >>>>>>>>> >>>>>>>>> I can't comment on that cause I didn't see VWRAP yet, but from the >>>>>>>>> charter and the comments on this list I'd think that full support >>>>>>>>> for interop between any number of RD's and AD's is intended. >>>>>>>>> >>>>>>>>> >>>>>>>>> Well you've put your finger on the problem here. Everyone is saying what they >>>>>>>>> think is intended because the intention is not actually spelled out in the >>>>>>>>> documents. Why cannot it be spelled out clearly that interop between multiple >>>>>>>>> ADs is intended? If it were, this entire discussion could be avoided because >>>>>>>>> it's easy and reasonable to equate ADs with VWs in practice. >>>>>>>>> >>>>>>>>> Notice however that even if the protocol were modified to be able to handle two >>>>>>>>> ADs at a time, use of an unadorned "the virtual world" in the documents would >>>>>>>>> continue to raise the perennial question of "Which virtual world?". After all, >>>>>>>>> there would be two of them being discussed. >>>>>>>>> >>>>>>>>> It's this phraseology that stems from OGP's original goal of adding single >>>>>>>>> regions or RDs to an existing single virtual world (namely SL in the prototype) >>>>>>>>> that is creating such a problem. That phraseology was appropriate for that >>>>>>>>> original goal. It is not appropriate for the goal of interoperating multiple >>>>>>>>> virtual worlds --- it makes it impossible to even talk about the goal sensibly, >>>>>>>>> because "the virtual world" in the OGP sense has no plural. >>>>>>>>> >>>>>>>>> It's unfortunate, but this whole affair is just the product of legacy wording >>>>>>>>> from OGP. That's never going to work in a multi-world setting where we need to >>>>>>>>> talk about the endpoints in different worlds. >>>>>>>>> >>>>>>>>> >>>>>>>>> Morgaine. >>>>>>>>> >>>>>>>>> PS. If anyone else read this far other than Carlo, you have a lot of stamina >>>>>>>>> and dedication. ;-) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ============================================== >>>>>>>>> >>>>>>>>> On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood wrote: >>>>>>>>> >>>>>>>>> On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote: >>>>>>>>> > The problem you see is that a virtual world is much more than just a >>>>>>>>> Region >>>>>>>>> > Domain. It is a complete set of services of which the Region Domain >>>>>>>>> service is >>>>>>>>> > just one. Other typical services might be those of the Agent Domain >>>>>>>>> (which >>>>>>>>> > provides identification and authorization services and possibly others), >>>>>>>>> as >>>>>>>>> > well as asset and inventory services, IM and other communication >>>>>>>>> services, and >>>>>>>>> > maybe several more. >>>>>>>>> >>>>>>>>> Well... that is purely semantic. It is a way to define VW, but not one that >>>>>>>>> I've been using :/ >>>>>>>>> >>>>>>>>> For simplicity, assume that only two things are needed to create a complete >>>>>>>>> virtual world, like SL or OG: A Region Domain (RD) and an Agent Domain >>>>>>>>> (AD). >>>>>>>>> >>>>>>>>> Currently, without any interop, each administrative entity (or trust >>>>>>>>> entity) >>>>>>>>> will need to provide both: an RD *and* an AD, otherwise they don't have a >>>>>>>>> functional VW. >>>>>>>>> >>>>>>>>> Your conclusion is that a VW exist of both 1 RD and 1 AD. But I ask you to >>>>>>>>> reconsider if that conclusion is correct, because it is based on the >>>>>>>>> current >>>>>>>>> situation without any interop. Now "correct" might not be the correct word >>>>>>>>> - heh. >>>>>>>>> Rather I should say: I ask you to reconsider if that definition is very >>>>>>>>> useful. >>>>>>>>> >>>>>>>>> Lets consider the following fictive case: >>>>>>>>> >>>>>>>>> LL runs one RD and AD, called RD1 and AD1. >>>>>>>>> CB (Cable Beach) runs another RD and AD, called RD2 and AD2. >>>>>>>>> A user that authenticates with either AD1 or AD2 can travel to RD1 AND RD2, >>>>>>>>> completely symmetrical, keeping their respective AD1- and AD2- assets etc. >>>>>>>>> This is possible with the right policies, so for the sake of looking at >>>>>>>>> the usefulness of the above definition of VW, assume this is the case. >>>>>>>>> >>>>>>>>> Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be another VW? >>>>>>>>> Or do you think it would make most sense in THIS case to speak of a single >>>>>>>>> VW? >>>>>>>>> >>>>>>>>> I think this is what Infinity means when she says that "virtual world" >>>>>>>>> cannot >>>>>>>>> be defined, because what could be perceived as being a VW is highly >>>>>>>>> dependend >>>>>>>>> on the exact situation (and policies) and in certain configuration that are >>>>>>>>> not as clear as the current situation (no interop) or the above example >>>>>>>>> (100% >>>>>>>>> interop). >>>>>>>>> >>>>>>>>> In one of my first posts about this topic I stated that "virtual world" >>>>>>>>> should >>>>>>>>> be considered to be the Region Domain (although I didn't use that term at >>>>>>>>> the >>>>>>>>> moment) and be completely independent of the Agent Domain, based on typical >>>>>>>>> cases of abuse and griefing etc: if anyone annoys some other user, or >>>>>>>>> breaks >>>>>>>>> almost any ToS, it will be region based; which is why I've always said that >>>>>>>>> any type of abuse can and should be handled at the sim (single region) >>>>>>>>> level: >>>>>>>>> the estate owner and managers in SL, even, but that idea definitely extends >>>>>>>>> to "world administrations": the people running the REGION (domain) is the >>>>>>>>> one >>>>>>>>> that should decide what is the local ToS and deal with abuse etc. That is >>>>>>>>> why I strongly argue to define "virtual world" as Region Domain, and leave >>>>>>>>> the AD out of it. Nevertheless, now I have the term "Region Domain" I don't >>>>>>>>> need "virtual world" anymore. >>>>>>>>> >>>>>>>>> > In our new protocol, these services may either be implemented internally >>>>>>>>> within >>>>>>>>> > a virtual world, or some might be implemented as external services >>>>>>>>> offered by >>>>>>>>> > third parties, the choice being a policy and design decision for each >>>>>>>>> world >>>>>>>>> > operator. In all cases however, the virtual worlds are defined by a set >>>>>>>>> of >>>>>>>>> > services, and not just by a Region Domain. >>>>>>>>> >>>>>>>>> I'm afraid that is purely a matter of opinion. I agree that it is likely >>>>>>>>> that a single 'administrative entity' that runs a RD will also run an AD >>>>>>>>> and allow users authenticated with their AD visit their RD, but it is no >>>>>>>>> more than *likely*. There will almost certainly be service provides that >>>>>>>>> ONLY run an AD, and don't have a RD! And I can imagine that there will >>>>>>>>> be some that only run a RD and do not care about running their own AD. >>>>>>>>> >>>>>>>>> Therefore, "virtual world" cannot be synonym for "the set of services >>>>>>>>> run by a single administrative entity" as you seem to argue, and at >>>>>>>>> the SAME time be argued to include an RD *and* AD at all times. >>>>>>>>> >>>>>>>>> > This is easy to see by looking at a couple of archetypal examples in this >>>>>>>>> > space: >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Is Second Life a virtual world? Undoubtedly. Is Second Life just a >>>>>>>>> Region >>>>>>>>> > Domain (assuming it were implemented using VWRAP)? No, of course >>>>>>>>> not, SL >>>>>>>>> > includes all of the services mentioned above, and others. >>>>>>>>> >>>>>>>>> Of course, LL happens to run all services that are needed to create one >>>>>>>>> virtual world; there are no third parties they can hire from yet, so they >>>>>>>>> have to provide it all themselves. >>>>>>>>> >>>>>>>>> But after SL implemented VWRAP they might decide to do away from one of >>>>>>>>> their services and only keep their RD. Unlikely, but possible. >>>>>>>>> >>>>>>>>> > Is OSgrid a virtual world? Undoubtedly. Is OSgrid just a Region >>>>>>>>> Domain >>>>>>>>> > (assuming it were implemented using VWRAP)? No, of course not, it >>>>>>>>> > currently runs all the UGAIM services, which in a VWRAP context would >>>>>>>>> > become similar to those of Second Life. >>>>>>>>> >>>>>>>>> Exact same argument. >>>>>>>>> >>>>>>>>> > So you see, the idea that has been floated which claims that "VW == RD" >>>>>>>>> is >>>>>>>>> > completely wrong, and misrepresents what constitutes a "virtual world" >>>>>>>>> despite >>>>>>>>> > the very clear examples before us. >>>>>>>>> >>>>>>>>> If you want to put it that way (including everything above that you said) >>>>>>>>> then >>>>>>>>> I have to side with Infinity: you cannot define a virtual world that way >>>>>>>>> and >>>>>>>>> use it for useful discussions regarding VWRAP. >>>>>>>>> >>>>>>>>> In the end, one virtual world as defined by "all services together to make >>>>>>>>> things work" will be, or can be, a mix of many RD's and many AD's with a >>>>>>>>> complex >>>>>>>>> web of trust/non-trust between them that makes the concept of "virtual >>>>>>>>> world" >>>>>>>>> rather fuzzy at best. >>>>>>>>> >>>>>>>>> [...] >>>>>>>>> > As we move into analysis of the problem space, these issues will be >>>>>>>>> > disentangled and clarified and the protocols will be defined and evolve, >>>>>>>>> but >>>>>>>>> > from the current OGP perspective there is no symmetrical relationship >>>>>>>>> possible >>>>>>>>> > between VWs that could be described as "peering". It is the asymmetry of >>>>>>>>> the >>>>>>>>> > VW-RD relationship that has been the crux of the "no VW interop" issue. >>>>>>>>> For >>>>>>>>> > symmetrical peering, the protocol would need to mention at least two >>>>>>>>> > communicating VWs. >>>>>>>>> >>>>>>>>> You can about peering with just two RD's and one AD, or one RD and two >>>>>>>>> AD's. >>>>>>>>> >>>>>>>>> > Of course the situation could change as the protocol evolves. For >>>>>>>>> example, >>>>>>>>> > once or twice we have heard mention that multiple ADs could be involved >>>>>>>>> in some >>>>>>>>> > way, and it seems certain that communication services from multiple VWs >>>>>>>>> will be >>>>>>>>> > merged because residents demand this. This would start to take us into >>>>>>>>> VW-VW >>>>>>>>> > interop territory. However, there is no such thing in VWRAP currently, >>>>>>>>> and >>>>>>>>> > it's not in the list of deliverables to include it, and therefore we >>>>>>>>> cannot say >>>>>>>>> > that VWRAP will provide VW-VW interop at all. For now. ;-) >>>>>>>>> >>>>>>>>> I can't comment on that cause I didn't see VWRAP yet, but from the >>>>>>>>> charter and the comments on this list I'd think that full support >>>>>>>>> for interop between any number of RD's and AD's is intended. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Carlo Wood >>>>>>>>> >>>>>>>>> >>>> >>>> >>>>> _______________________________________________ >>>>>>>>> ogpx mailing list >>>>>>>>> ogpx@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ogpx >>>> >>>> >>>>-- >>>> >>>>Carlo Wood >>>> >>>>_______________________________________________ >>>>>>>>ogpx mailing list >>>>ogpx@ietf.org >>>>https://www.ietf.org/mailman/listinfo/ogpx >>>> >>> >> >>_______________________________________________ >>>>ogpx mailing list >>ogpx@ietf.org >>https://www.ietf.org/mailman/listinfo/ogpx >> >> > >_______________________________________________ >>ogpx mailing list >ogpx@ietf.org >https://www.ietf.org/mailman/listinfo/ogpx > > --0-2056852013-1254433708=:79438 Content-Type: text/html; charset=us-ascii

This seems like the right path to me, too.

In thinking about this, lets consider saying that where two policies of two interoperable grids intersect is the interesting case.

To take it back to SecondLife and say, an OpenSim grid, the first few things in an interop teleport are going to be avatarName and avatarAppearance.

In thinking of how this may work, it would seem that we will probably end up with something like "FirstLast@SecondLife.com" when teleporting to, say OSGrid from Secondlife to OSGrid and perhaps "FirstLast@OSGrid.org" when teleporting from OSGrid to SecondLife. So, ... perhaps the policy may define the format of the name carried across in the teleport as it is reasonable to assume that an avatar in SecondLife does not have an account on OSGrid, and the converse is also true.

Second, I suspect we need to define what happens when an avatar attempts a teleport with attachments (particularly scripted attachments). I rather suspect that neither grid will wish to allow teleporting with scripting attachments without a significant amount of negotiation between the two corporations.

As far as inventory goes, I rather suspect we wish to either avoid moving inventory between grids, or, ... perhaps define a 'vanilla' subset such as those items marked with 'export from grid, full permissions' bits set. I am taking that from memory in thinking about the additional bitfield for object exports discussion on SecondLife a year or so ago.

I am trying to think of the simplest cases that will have the minimum of cussin, discussin and debate to get our minds wrapped around how to move forward a bit.

Certainly, I have my mind wrapped around Zha's statement a year or so ago that went (if I recall more or less correctly):

"We will have interop when I can slay a monster on WoW, teleport to a club in SecondLife, mount the monsters head on the wall and buy everyone a drink".

Charles
From: Morgaine <morgaine.dinova@googlemail.com>
To: ogpx@ietf.org
Sent: Thursday, October 1, 2009 2:34:10 PM
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell <josh@lindenlab.com> wrote:

IMHO, it should be apparent that both AD (which is the agent/advocate for the user) and RD (where the user wants to be) both need to make policy decisions.


Excellent, Joshua!

I think we're finally approaching the road towards Destination Determines Policy now, which is a prerequisite for real interop between virtual worlds.  This was simply not possible with the old OGP thinking in which policy was given by a "trust domain" defined by a single AD alone.

It's a two-part problem.  Naturally your source world can impose restrictions on travel (a walled garden may disallow any foreign travel at all, for example), that's clear.  What hasn't been clear until now is that the destination world will have conditions which are every bit as strong and important as the source world, and represented in the same way (eg. in their AD).  Both sides must be allowed equivalent representation in the protocol.

This is why the single-world terminology was such a barrier earlier.  It completely prevented us from bringing the two worlds into the discussion simultaneously, which is necessarily when both source and destination are completely equivalent peer worlds.

Your next step is to realize that, for two structurally identical worlds, if the seat of policy of one lies in its AD, then the seat of policy of the other also lies in its AD.  Therefore your statement needs to be modified to the following:

IMHO, it should be apparent that both the AD of the source world and the RD and AD of the destination world all need to make policy decisions.


What's true for the source world is also true for the destination world, policy-wise.  The destination world is not "inferior" in any way.  It's a necessary peer in the protocol.  You can't exclude it from the equation.


Morgaine.






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

On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell <josh@lindenlab.com> wrote:
Without diving in too deep, I believe this thread is putting up a two-level false dichotomy - either the RD determines policy or the AD determines policy, OR things aren't sensible w/o nil trust. If that's a mis-reading, my apologies.

IMHO, it should be apparent that both AD (which is the agent/advocate for the user) and RD (where the user wants to be) both need to make policy decisions.

A corporate AD may restrict where users may visit (e.g. agentd.corp.example.com may say "no visiting party.example.com from work!") or an AD may restrict users based on personal preferences (agentd.safesurf.example.com may say "scam.example.com is on a shared blacklist of malicious sites, teleport blocked"), legal or political requirements (agentd.kidfriendly.example.com may say "you can't visit adultgrid.example.com"). Note that in all cases the AD is enforcing policy as an agent of the user, just as a web browser on a local network does today. Presumably, there will exist many ADs that provide no restrictions whatsoever, just as most Web browsers accessing the 'net via most ISPs in most countries today don't restrict access to Web content via policy.

On the flip side, the RD will also have policy. Corporate VWs may limit access to employees. Adult-centric VWs may limit access to agents from ADs that verify accounts with some well known service. Real-world-region-specific RDs may require citizenship checks and deny access to citizens of some nation-states. And of course permissions would doubtless exist on a per-user basis as well as per-AD. Again - no different than access permissions today on the Web, except that instead of being a two-party user/service, it's three party user/AD/RD. And one hopes that, like most of the Web, content is freely visitable by all.

On the topic of nil-trust: again, I wholeheartedly support the stance that the protocol should support nil trust operation. I hope that both the protocol and operations of VWRAP-based worlds allow the bulk of VWRAP traffic to occur in a nil trust environment, just like the Web does today. However, I *suspect* that, in practical terms, the abilities we want to grant to regions by visiting them - to display our avatars, to broadcast information about our agents, to give and receive virtual goods - will require at least a modicum of trust for most VW interaction, at least on the level of an SSL-style secured connection that gives users a certificate to look at that provides some identity/trust information about the service provider.

I suspect I'm going to beat this drum a lot - "VWs are just like the Web, except where they're different" :)


On Tue, Sep 29, 2009 at 5:51 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Hi Vaughn! :-)

Your description of our discussion is quite accurate.  However, it seems to imply that I advocate in favour of the view that the AD must be the seat of all policy for connected regions.  I do not.  I was merely explaining the architecture of AD+RD pairing as it has been described to us repeatedly throughout the two years of our OGP-related work in the LL+IBM sponsored Architecture Working Group within Second Life.

After the emails, Carlo and I examined this issue with higher discussion bandwidth inside SL, and it turned out that we were describing two different things:  I was explaining the AD+RD relationship in OGP, while Carlo was describing RDs as they should be designed if an RD were an autonomous unit with its own policies, effectively a small world.  If OGP were designed differently and less restrictively to allow that, then there would have been no discussion.  :-)

Of course, OGP is not VWRAP, but only the seedcorn for VWRAP.  We can make VWRAP as flexible as we like, and it's easy to see its potential flexibility in David's deployments document.  Consequently, I have high hopes that all parties will be happy with the eventual outcome. :-)

You may have missed the primary reason why I do not advocate a design in which an OGP-style AD is the seat of all power, possibly because the discussion has been spread out across all of OGPX and MMOX.  It's easy to summarize in one sentence though:  such a design cannot underpin an Internet-wide metaverse of interoperating virtual worlds because it doesn't respect the key meme of virtual and non-virtual tourism:  Destination Determines Policy.

This meme is so fundamental and crucial (and obvious) that OGP's support of the exact opposite is terminally broken, as a basis for the hypothetical metaverse.  Indeed, you yourself have referred to the problem in the funny "war over purple". :-)  At best such a design can support only a random scattering of VPN-like walled gardens, all isolated and incapable of interoperating because they all claim the "one true policy".  We should not go there.

The most recent description of this problematic aspect of the OGP design was posted by Magnus Zeisig in his excellent email at http://www.ietf.org/mail-archive/web/ogpx/current/msg00324.html , which I fully support.  Such balkanization is not a desireable goal when designing a VW interop protocol.

So where are we now?  We're at the stage of examining David's VWRAP deployment patterns to see how the protocol can support them.  And in that examination, it is likely to become clear that the old OGP model of "AD determines policy" is completely non-viable for interoperating between VWRAP-compatible virtual worlds, except when that policy is "nil trust" as a common denominator.

Consequently, we will either decide to live with the original OGP split and use "nil trust" as our basis for VW interop, or else we will redesign the AD/RD relationship to place many more important policy decisions where they really belong, at destination.  The latter seems the best choice to me, and of course it would make Carlo happy, and it is also the model that every single existing world already operates --- when in Rome, do as the Romans do.  Only the old OGP AD/RD two-way split design is out of step.  Let's hope that we can correct that in VWRAP. :-))


Morgaine.






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



On Tue, Sep 29, 2009 at 9:16 PM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
Carlo and Morgaine have above been involved in a very interesting discussion about the nature of the (or *a*) virtual world. 

Painting their positions with  broad strokes, Morgaine stresses the primary role of the AD as the seat of policy and trust, up to the point where he denies the RD any role above that of a convenient extension of the AD, i.e. the RD as "colony without a government". Carlo passionately argues for the independent role of the RD in policy issues.

I feel that both positions are valid (to some degree), and both can be covered by VWRAP.

Calo makes absolutely clear that having all policy in the respective ADs of the avatars leads to problems when several avatars meet in one region domain, say RD1. Avatars will be busy killing each other over the right to wear purple, and for the innocent bystanders caught in the crossfire it will be fully unclear were to complain. Stepping in Morgaines shoes, i think i would argue that what Carlo asks for can be realised by applying the policy of a *particular* AD to RD1. The rules to deal with color of clothes, could be formulated in AD1 associated with RD1. In principle Carlo could run this domain himself, even without a single avatar in it, and in this way get his "government" and set any policy he wants. If two avatars from AD2 and AD3 visit RD1, The policy in RD1 would be governed by what is specified by AD1.

While this fully fits Morgaines view of "AD rules all", and also fits Carlo call for autonomy of RD1, it feels decidedly like a kludge, and in this particular case it seems much more straightforward to make RD1 more autonomous. Yet, to keep everything within one framework, this kludge seems to be the logical solution... I would like to hear what others think about this.

One other remark: the minimal example for  a "world"  -one AD and one RD- would be more useful when extended with one asset service AS. Explicit mentioning of the AS will make it much easier to discuss IP issues. 

Vaughn



On Mon, Sep 14, 2009 at 10:44 AM, Carlo Wood <carlo@alinoe.com> wrote:
On Mon, Sep 14, 2009 at 06:43:06AM +0100, Morgaine wrote:
> Carlo asked for detailed comments on the below, so here goes. :-)
>
>
> On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood <carlo@alinoe.com> wrote:
>
>     On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote:
>     > The problem you see is that a virtual world is much more than just a
>     Region
>     > Domain.  It is a complete set of services of which the Region Domain
>     service is
>     > just one.  Other typical services might be those of the Agent Domain
>     (which
>     > provides identification and authorization services and possibly others),
>     as
>     > well as asset and inventory services, IM and other communication
>     services, and
>     > maybe several more.
>
>     Well... that is purely semantic. It is a way to define VW, but not one that
>     I've been using :/
>
>
> It's a rough top-level projection of the architectural model of VWRAP, once the
> various services have been decoupled in the way that David Levine often
> describes to us.  Nothing very contentious there, everyone likes a
> services-oriented approach. :-)
>
>
>
>     For simplicity, assume that only two things are needed to create a complete
>     virtual world, like SL or OG: A Region Domain (RD) and an Agent Domain
>     (AD).
>
>
> I am happy to consider that simple scenario as representative.  It is quite
> reasonable to equate AD with VW because the AD is the focus of almost all the
> policy decisions of a VWRAP-based world.  When other decoupled services are
> added to this picture, it doesn't change the fundamental architecture of AD +
> RDs, only extends it by decoupling more than just the region service.  So
> that's fine with me.

I totally disagree that the AD is the representative...and why do you say
that below a sentence of me where I say "A Region Domain (RD) and an Agent Domain (AD)"?

This is like I say "VW = AD + RD", and you go: "yes, VW = AD". We can't
have a discussion like that Morgaine.

>     Currently, without any interop, each administrative entity (or trust
>     entity)
>     will need to provide both: an RD *and* an AD, otherwise they don't have a
>     functional VW.
>
>
> Correct.  The AD is the seat of most (but not all) of the policy decisions of a

I even *stressed* the '*and*' here, and you do it again.

> VW, so it's very central to the existence of a VW.  While it's possible to
> imagine policy-free VWs that temporarily  take on the policy of any other world
> they hook up with, this is clearly a subset situation.  All the currently known
> SL-like virtual worlds are grids of the SL kind, with their own individual
> policies which they are not going to change on interop.
>
>
>
>     Your conclusion is that a VW exist of both 1 RD and 1 AD. But I ask you to
>     reconsider if that conclusion is correct, because it is based on the
>     current
>     situation without any interop. Now "correct" might not be the correct word
>     - heh.
>     Rather I should say: I ask you to reconsider if that definition is very
>     useful.
>
>     Lets consider the following fictive case:
>
>     LL runs one RD and AD, called RD1 and AD1.
>     CB (Cable Beach) runs another RD and AD, called RD2 and AD2.
>     A user that authenticates with either AD1 or AD2 can travel to RD1 AND RD2,
>     completely symmetrical, keeping their respective AD1- and AD2- assets etc.
>     This is possible with the right policies, so for the sake of looking at
>     the usefulness of the above definition of VW, assume this is the case.
>
>
> That's not quite right because Cable Beach is not a world provider like LL.
> Cable Beach is perhaps best described as a "login mediation" mechanism or

I might not understand what the real Cable Beach is or wants to be, I was just
trying to give an example to work with. So, again:

LL runs one RD and AD, called RD1 and AD1.
OG runs another RD and AD, called RD2 and AD2.
A user that authenticates with either AD1 or AD2 can travel to RD1 AND RD2,
completely symmetrical, keeping their respective AD1- and AD2- assets etc.
This is possible with the right policies, so for the sake of looking at
the usefulness of the above definition of VW, assume this is the case.

> protocol, which provides a model for interaction between a "world service"
> (effectively an AD), the user's client, and various decoupled services such as
> simulation nodes (possibly an RD) and inventory/asset services.  Let's assume
> therefore that your "CB" above means something different (another world
> provider similar to LL), and then we can proceed with your example case.

Ok

>     Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be another VW?
>     Or do you think it would make most sense in THIS case to speak of a single
>     VW?
>
>
> They're two worlds because you defined them as such, as each has its own AD.
> :-)  But that aside, if they were set up separately then they have two
> different sets of policies, two different sets of residents, two different
> ToS's, possibly two different legal jurisdictions, two different mechanisms for
> abuse control and conflict resolution, and so on and so forth.  If they were
> created to be worlds that can stand alone but interoperate when desired, then
> each of these is a diffferent world.  I don't see how that can be disputed.

As I stated in one of my first posts, it will (hopefully!!!) be mainly the
the *RD* and NOT the AD that all of those things are a function of!

You keep saying that it's mainly the AD that determines these things, but
that would be confusing and very annoying. If two people meet in a virtual
world, that is - if they are standing next to eachother in one region and
using local chat - then they should fall under the same legal jurisdiction
and the same ToS: it is the region that determines the rules, not the AD
that they used to login with.

As example, ToS1 says: it's ok to be naked; and ToS2 says: it's a bannable
offence to be naked. Do you really think that it's even workable if the
ToS to be applied is a function of the AD? Say you login using AD2, so
ToS2 applies to you. You meet someone else that is naked. You know that
you are not allowed to and you are offended. You create an abuse report;
where does that report go to? To your AD administration? That makes no
sense: that naked person is using a different AD. To his/her AD administration
then? That makes also no sense since they allow it.

Seriously, there is only one reasonable thing to do: the ToS that applies
is a function of the Region Domain *only*, and if you write an abuse report,
it should go to the administration of the region that you are in and not
to your or the others AD administration. Same holds for the things related
to legal jurisdiction and any other 'rules' that applies at any given
moment (to users). The only thing that might be a function of the AD are
technical policies that are automatically enforced by VWRAP.

>     I think this is what Infinity means when she says that "virtual world"
>     cannot
>     be defined, because what could be perceived as being a VW is highly
>     dependend
>     on the exact situation (and policies) and in certain configuration that are
>     not as clear as the current situation (no interop) or the above example
>     (100%
>     interop).
>
>
> This is incorrect.  "Virtual world" is defined by each provider of a virtual
> world and by nobody else, and each provider knows full well how it is defined,
> what its boundaries are, and what makes it distinct.  Nobody else can define
> what a virtual world is, and it's not our business to define it either (nor to
> conjure up a fictitious definition).

Sorry, but I think you should try harder to understand my point of view first.
I didn't give the examples so you can ignore them.

> We only need to define the protocol interactions at the endpoints presented by
> those worlds, and not to define "virtual world" structurally nor any other way.
>   Doing so is what has got us into this mess, by creating a fictitious
> definition based on reachability and hence blocking any ability to talk about
> actual virtual worlds.  Those worlds exist.  They won't go away.  They want to
> interoperate, but they don't want to be told that they don't exist.

I was trying to make you understand WHY Infinitely tells you they don't "exist",
if you understand her (and you don't, imho) then it will be easier to solve this
miscommunication.

> The contention that we don't know what "virtual world" means is just plain
> bizarre.

Only if you already have a definition of "virtual world" they way you do.

> I don't know of any VW operator who doesn't know what their world is.

That is the *current* situation... which is 100% simpler than what we'll
have in the future.

Compare with math... currently we only have Integers (Z). We're about
to introduce division and by that we need to extend the definition of
'number' from Z to Q. Q aren't integers, even though currently every
number is an integer doesn't mean you have to hold on tight the "definition"
of "number" == integer. That definition will be broken and you will
have to redefine "number".

>   Every single one of them could provide the necessary endpoints for VWRAP
> within their world without any scratching of heads at the meaning of "virtual
> world".  That repeated allegation has been a complete misrepresentation.  It's
> just not true.

You CANNOT define "virtual world" as "AD" (see above) nor as "AD + RD" because
that is too simple and only holds in the current situation. You can only, at most,
if you really want, say - well, lets define it as being some RD.

> And possibly even worse is the excuse  that "virtual world" is not being
> defined but is being used non-normatively, while in practice using the phrase "
> the virtual world" to create a totally fictitious single virtual world instead.

I agree that as long as it isn't normatively defined, the term shouldn't be
used in documents except in places where it can literally mean anything without
that anyone will care (like in the protocol name).

>   That phrase is unnecessary, it is misrepresentative of the actual situation,
> it bypasses policy controls of one world by not mentioning its AD, it prevents
> us from mentioning virtual worlds by blocking the normal meaning of the term,
> and it provides nothing useful as a benefit in return.  Unless total confusion
> is a benefit. ;-)

Sorry, but that is like saying that defining the Rational Numbers (Q) makes it
impossible to talk about 'numbers', because 3/7 isn't an integer.
What you have to do is let go of your current definition.

>     In one of my first posts about this topic I stated that "virtual world"
>     should
>     be considered to be the Region Domain (although I didn't use that term at
>     the
>     moment) and be completely independent of the Agent Domain, based on typical
>     cases of abuse and griefing etc: if anyone annoys some other user, or
>     breaks
>     almost any ToS, it will be region based; which is why I've always said that
>     any type of abuse can and should be handled at the sim (single region)
>     level:
>     the estate owner and managers in SL, even, but that idea definitely extends
>     to "world administrations": the people running the REGION (domain) is the
>     one
>     that should decide what is the local ToS and deal with abuse etc. That is
>     why I strongly argue to define "virtual world" as Region Domain, and leave
>     the AD out of it. Nevertheless, now I have the term "Region Domain" I don't
>     need "virtual world" anymore.
>
>
> But that's not how OGP is structured.  It's the AD that is the focus of service
> policy choices in OGP, and it's the "world service" that is the focus of
> service policy in Cable Beach.  The AD and the world service are the source of
> capabilities that determine pretty much everything else, and the region domain
> is very subsidiary to that.

No, if the service prodiver of some AD disagrees with the (say) a ToS that applies
when you go to some RD then they should disallow you go there; they should not
allow you to go there and then demand that you follow their ToS, that would not
be a practical solution that is workable.

To use mathematics again, it's easy to make two ToS that have no intersection:
Say, ToS1 says: you MUST wear purple clothes, and ToS2 says: you MUST wear blue
clothes. Obviously those will apply to regions.

So then we have:

Provider1: RD1 --> TOS1 --> purple clothes
Provider2: RD2 --> TOS2 --> blue clothes

*if* Provider 2 runs an AD (AD2) and they allow people logged in with it
to go to region RD1 then the people there should wear purple clothes:
TOS2 will not apply because of the AD you use.

If it's against providers religious believe to support wearing purple
clothes than they might disallow people to go to RD1, that is their
choice (policy).

> Indeed, a region domain may have no policy of its
> own at all, but merely extend an existing virtual world by accepting the
> policies of that world's AD.  That's the model in the original OGP before it
> gained aspirations of becoming a cross-VW interop protocol.

That makes no sense :/

There can be any number of people in a given RD, and each can in principle
be using a different AD! PLEASE let the RD determine the rules they have
to live by! Anyone else that disagrees with me about that?!

> If RDs determined VW policy and generated seed capabilities for everything and
> ADs were merely login services then your model would apply, and RD could be
> considered "VW".

Ah! At last..

> But that's not how it is currently structured --- RDs are

If you are refering to OGP, then OGP should be changed.

> merely the land + physical simulation components of worlds, and in SL's case,
> also an elaborate system of proxies.  And that's why we need multiple ADs to
> interact in VWRAP before we can consider that there is VW-VW interop.  RDs
> don't handle it.

What I seem to keep missing is the fact that VWRAP is already completely
defined in those previous OGP documents and we're merely here to rewrite
them in an IETF document of sorts.

Yes we need multiple ADs to interact, and they will.
But yes, RD's will handle whatever they have to handle with VWRAP.
I never said that capabilities equal 'rules' (ToS and legal jurisdiction
isn't something that should be enforced or controlled by the protocol) by
the way.

... sorry my RSI forces me to stop typing here... shouldn't have
typed this much alrady anyway :(

>     > In our new protocol, these services may either be implemented internally
>     within
>     > a virtual world, or some might be implemented as external services
>     offered by
>     > third parties, the choice being a policy and design decision for each
>     world
>     > operator.  In all cases however, the virtual worlds are defined by a set
>     of
>     > services, and not just by a Region Domain.
>
>
> Indeed.  But access to such decoupled services is provided by the AD through
> the capabilities that it delivers to authorized parties, and regions are just
> one such service.  You're giving RDs credit for something that they don't do.
> :-)  Perhaps the VWRAP model should be redesigned along your lines so that RDs
> become the VWs and are the generators of seed caps, and then ADs become just a
> subservient policy-free login mechanism. :D
>
>
>
>     I'm afraid that is purely a matter of opinion. I agree that it is likely
>     that a single 'administrative entity' that runs a RD will also run an AD
>     and allow users authenticated with their AD visit their RD, but it is no
>     more than *likely*. There will almost certainly be service provides that
>     ONLY run an AD, and don't have a RD! And I can imagine that there will
>     be some that only run a RD and do not care about running their own AD.
>
>
> Oh sure, there will be all combinations of services, that is to be expected.
> But it is the seat of policy that is the heart of each virtual world, and
> currently the seat of policy lies in the AD.  A VW that doesn't have an AD in
> the VWRAP model is just a colony without a government, ready to be assimilated
> into a world that has an AD and that therefore sets policies, instead of being
> a sovereign world that merely wants to interop with that other world through
> VWRAP.
>
>
>
>     Therefore, "virtual world" cannot be synonym for "the set of services
>     run by a single administrative entity" as you seem to argue, and at
>     the SAME time be argued to include an RD *and* AD at all times.
>
>
> I don't follow that.  Two worlds that can run independently (that's very
> important) can certainly each be defined as a set of services that includes the
> functions of an AD and an RD, and those worlds each continue to include the
> functions of an AD and an RD even after they start interoperating (assuming
> that VWRAP is extended to allow cross-VW interop).  No world is going to give
> up part of its services portfolio on interop.  Interop is an additional
> benefit, not a loss of capability.
>
> [It's worth noting that there may actually be a small loss of capability
> occurring on interop in VWRAP, although it is rarely mentioned.  You can be
> present in two worlds simultaneously with the same login credentials
> pre-interop (a feature that we enjoy currently between SL and OSgrid for
> example), but post-interop this may no longer be possible --- it depends on the
> implementation.  No doubt we will visit this issue within VWRAP.]
>
>
>
>     > This is easy to see by looking at a couple of archetypal examples in this
>     > space:
>     >
>     >
>     >     Is Second Life a virtual world?  Undoubtedly.  Is Second Life just a
>     Region
>     >     Domain (assuming it were implemented using VWRAP)?  No, of course
>     not, SL
>     >     includes all of the services mentioned above, and others.
>
>     Of course, LL happens to run all services that are needed to create one
>     virtual world; there are no third parties they can hire from yet, so they
>     have to provide it all themselves.
>
>     But after SL implemented VWRAP they might decide to do away from one of
>     their services and only keep their RD. Unlikely, but possible.
>
>
> You're confusing RD functionality with AD functionality again there.  The AD is
> the heart of a world because it defines its capabilities and policies.  The RD
> is just a pile of region hosts that could easily be farmed out to a third party
> to run without them determining policy, and indeed this is already being done.
> While it is a very important pile of hosts which gives a world its physical
> characterists, the RD is a subservient service to the AD in OGP, just as the
> equivalent "simulation nodes" provide a subservient service to the "world
> service" under Cable Beach.  The RD is well named --- it provides region
> services only, not the package of internal + external services that together
> create a virtual world.
>
>
>
>     >     Is OSgrid a virtual world?  Undoubtedly.  Is OSgrid just a Region
>     Domain
>     >     (assuming it were implemented using VWRAP)?  No, of course not, it
>     >     currently runs all the UGAIM services, which in a VWRAP context would
>     >     become similar to those of Second Life.
>
>     Exact same argument.
>
>
> Exact same response because the same applies. :-)   What's more, in OSgrid this
> is even easier to identify, because every person or company that adds regions
> to OSgrid is subscribing to the notion that they are participants in OSgrid ---
> OSgrid is their virtual world.  They are merely providing additional land mass
> and simulation capacity.
>
> Also, in this example there is no need to hypothesize region services being
> farmed out to third parties, as there already are hundreds to thousands of
> independent third parties involved in supplying regions.  Those regions and
> clusters of regions (equivalent to RDs) together combine to create the virtual
> world of OSgrid.  There is a clear distinction between R/RDs here and the VW
> itself, which also includes a variety of other services as Charles has
> described several times.  The R/RDs are a very important part, but functionally
> they are not the VW, nor are they the VW perceptually.  They are places within
> the world, not the whole world.
>
>
>
>     > So you see, the idea that has been floated which claims that "VW == RD"
>     is
>     > completely wrong, and misrepresents what constitutes a "virtual world"
>     despite
>     > the very clear examples before us.
>
>     If you want to put it that way (including everything above that you said)
>     then
>     I have to side with Infinity: you cannot define a virtual world that way
>     and
>     use it for useful discussions regarding VWRAP.
>
>
> I think you may have misread that.  I did not define "VW == RD".  That's the
> opposite of what I said, but I agree with you on the negative conclusion.  If
> one defines "VW == RD" then it becomes impossible to have a meaningful
> discussion about VWs in VWRAP.  It also becomes impossible to have a meaningful
> discussion about VWs in VWRAP if one conjures up a fictitious meaning of
> "virtual world" based on reachability.  And that's why we should not define it
> in either of those two ways.
>
> The most useful and forward-looking way of defining virtual worlds in VWRAP is
> as a collection of service endpoints, regardless of who operates them.  All we
> should care about is the protocol between endpoints, and not conjure up some
> non-existent single virtual world.
>
>
>
>     In the end, one virtual world as defined by "all services together to make
>     things work" will be, or can be, a mix of many RD's and many AD's with a
>     complex
>     web of trust/non-trust between them that makes the concept of "virtual
>     world"
>     rather fuzzy at best.
>
>
> You're right but you're not being clear about what is fuzzy.  The concept of "
> single virtual world" is not only fuzzy, it is totally non-existent in practice
> (because there are many, not one) as well as impossible in theory  because of
> balkanization through incompatible trust domains, as described so magnificently
> by Magnus a week or two ago.  We should not go there.
>
> In contrast, the concept of multiple virtual worlds is crystal clear.  Several
> people here in the group operate virtual worlds, but nobody would suggest that
> they are unclear about what they operate.  We've been sold a bridge on that
> "uncertainty".  Multiple virtual worlds presenting VWRAP endpoints are the
> natural way of approaching interop between VWs, and you don't have to define
> VWs structurally for that.  You only have to define the endpoints that VWs need
> to present to the protocol, and avoid any notion of "single virtual world".
>
>
>
>     [...]
>     > As we move into analysis of the problem space, these issues will be
>     > disentangled and clarified and the protocols will be defined and evolve,
>     but
>     > from the current OGP perspective there is no symmetrical relationship
>     possible
>     > between VWs that could be described as "peering".  It is the asymmetry of
>     the
>     > VW-RD relationship that has been the crux of the "no VW interop" issue.
>     For
>     > symmetrical peering, the protocol would need to mention at least two
>     > communicating VWs.
>
>     You can about peering with just two RD's and one AD, or one RD and two
>     AD's.
>
>
> I think you're confusing RDs with VWs again --- RDs only provide regions,
> nothing else.  For peering between two VWs, you would need interaction between
> their two ADs because their ADs provide their policies.  If you bypass a VW's
> AD then you bypass its policies, so you're not interoping with that world.  And
> I don't think we're encouraging bypassing and hence subverting a world's
> policies.
>
>
>
>     > Of course the situation could change as the protocol evolves.  For
>     example,
>     > once or twice we have heard mention that multiple ADs could be involved
>     in some
>     > way, and it seems certain that communication services from multiple VWs
>     will be
>     > merged because residents demand this.  This would start to take us into
>     VW-VW
>     > interop territory.  However, there is no such thing in VWRAP currently,
>     and
>     > it's not in the list of deliverables to include it, and therefore we
>     cannot say
>     > that VWRAP will provide VW-VW interop at all.  For now. ;-)
>
>     I can't comment on that cause I didn't see VWRAP yet, but from the
>     charter and the comments on this list I'd think that full support
>     for interop between any number of RD's and AD's is intended.
>
>
> Well you've put your finger on the problem here.  Everyone is saying what they
> think is intended because the intention is not actually spelled out in the
> documents.  Why cannot it be spelled out clearly that interop between multiple
> ADs is intended?  If it were, this entire discussion could be avoided because
> it's easy and reasonable to equate ADs with VWs in practice.
>
> Notice however that even if the protocol were modified to be able to handle two
> ADs at a time, use of an unadorned "the virtual world" in the documents would
> continue to raise the perennial question of "Which virtual world?".  After all,
> there would be two of them being discussed.
>
> It's this phraseology that stems from OGP's original goal of adding single
> regions or RDs to an existing single virtual world (namely SL in the prototype)
> that is creating such a problem.  That phraseology was appropriate for that
> original goal.  It is not appropriate for the goal of interoperating multiple
> virtual worlds --- it makes it impossible to even talk about the goal sensibly,
> because "the virtual world" in the OGP sense has no plural.
>
> It's unfortunate, but this whole affair is just the product of legacy wording
> from OGP.  That's never going to work in a multi-world setting where we need to
> talk about the endpoints in different worlds.
>
>
> Morgaine.
>
> PS. If anyone else read this far other than Carlo, you have a lot of stamina
> and dedication. ;-)
>
>
>
>
>
>
>
> ==============================================
>
> On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood <carlo@alinoe.com> wrote:
>
>     On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote:
>     > The problem you see is that a virtual world is much more than just a
>     Region
>     > Domain.  It is a complete set of services of which the Region Domain
>     service is
>     > just one.  Other typical services might be those of the Agent Domain
>     (which
>     > provides identification and authorization services and possibly others),
>     as
>     > well as asset and inventory services, IM and other communication
>     services, and
>     > maybe several more.
>
>     Well... that is purely semantic. It is a way to define VW, but not one that
>     I've been using :/
>
>     For simplicity, assume that only two things are needed to create a complete
>     virtual world, like SL or OG: A Region Domain (RD) and an Agent Domain
>     (AD).
>
>     Currently, without any interop, each administrative entity (or trust
>     entity)
>     will need to provide both: an RD *and* an AD, otherwise they don't have a
>     functional VW.
>
>     Your conclusion is that a VW exist of both 1 RD and 1 AD. But I ask you to
>     reconsider if that conclusion is correct, because it is based on the
>     current
>     situation without any interop. Now "correct" might not be the correct word
>     - heh.
>     Rather I should say: I ask you to reconsider if that definition is very
>     useful.
>
>     Lets consider the following fictive case:
>
>     LL runs one RD and AD, called RD1 and AD1.
>     CB (Cable Beach) runs another RD and AD, called RD2 and AD2.
>     A user that authenticates with either AD1 or AD2 can travel to RD1 AND RD2,
>     completely symmetrical, keeping their respective AD1- and AD2- assets etc.
>     This is possible with the right policies, so for the sake of looking at
>     the usefulness of the above definition of VW, assume this is the case.
>
>     Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be another VW?
>     Or do you think it would make most sense in THIS case to speak of a single
>     VW?
>
>     I think this is what Infinity means when she says that "virtual world"
>     cannot
>     be defined, because what could be perceived as being a VW is highly
>     dependend
>     on the exact situation (and policies) and in certain configuration that are
>     not as clear as the current situation (no interop) or the above example
>     (100%
>     interop).
>
>     In one of my first posts about this topic I stated that "virtual world"
>     should
>     be considered to be the Region Domain (although I didn't use that term at
>     the
>     moment) and be completely independent of the Agent Domain, based on typical
>     cases of abuse and griefing etc: if anyone annoys some other user, or
>     breaks
>     almost any ToS, it will be region based; which is why I've always said that
>     any type of abuse can and should be handled at the sim (single region)
>     level:
>     the estate owner and managers in SL, even, but that idea definitely extends
>     to "world administrations": the people running the REGION (domain) is the
>     one
>     that should decide what is the local ToS and deal with abuse etc. That is
>     why I strongly argue to define "virtual world" as Region Domain, and leave
>     the AD out of it. Nevertheless, now I have the term "Region Domain" I don't
>     need "virtual world" anymore.
>
>     > In our new protocol, these services may either be implemented internally
>     within
>     > a virtual world, or some might be implemented as external services
>     offered by
>     > third parties, the choice being a policy and design decision for each
>     world
>     > operator.  In all cases however, the virtual worlds are defined by a set
>     of
>     > services, and not just by a Region Domain.
>
>     I'm afraid that is purely a matter of opinion. I agree that it is likely
>     that a single 'administrative entity' that runs a RD will also run an AD
>     and allow users authenticated with their AD visit their RD, but it is no
>     more than *likely*. There will almost certainly be service provides that
>     ONLY run an AD, and don't have a RD! And I can imagine that there will
>     be some that only run a RD and do not care about running their own AD.
>
>     Therefore, "virtual world" cannot be synonym for "the set of services
>     run by a single administrative entity" as you seem to argue, and at
>     the SAME time be argued to include an RD *and* AD at all times.
>
>     > This is easy to see by looking at a couple of archetypal examples in this
>     > space:
>     >
>     >
>     >     Is Second Life a virtual world?  Undoubtedly.  Is Second Life just a
>     Region
>     >     Domain (assuming it were implemented using VWRAP)?  No, of course
>     not, SL
>     >     includes all of the services mentioned above, and others.
>
>     Of course, LL happens to run all services that are needed to create one
>     virtual world; there are no third parties they can hire from yet, so they
>     have to provide it all themselves.
>
>     But after SL implemented VWRAP they might decide to do away from one of
>     their services and only keep their RD. Unlikely, but possible.
>
>     >     Is OSgrid a virtual world?  Undoubtedly.  Is OSgrid just a Region
>     Domain
>     >     (assuming it were implemented using VWRAP)?  No, of course not, it
>     >     currently runs all the UGAIM services, which in a VWRAP context would
>     >     become similar to those of Second Life.
>
>     Exact same argument.
>
>     > So you see, the idea that has been floated which claims that "VW == RD"
>     is
>     > completely wrong, and misrepresents what constitutes a "virtual world"
>     despite
>     > the very clear examples before us.
>
>     If you want to put it that way (including everything above that you said)
>     then
>     I have to side with Infinity: you cannot define a virtual world that way
>     and
>     use it for useful discussions regarding VWRAP.
>
>     In the end, one virtual world as defined by "all services together to make
>     things work" will be, or can be, a mix of many RD's and many AD's with a
>     complex
>     web of trust/non-trust between them that makes the concept of "virtual
>     world"
>     rather fuzzy at best.
>
>     [...]
>     > As we move into analysis of the problem space, these issues will be
>     > disentangled and clarified and the protocols will be defined and evolve,
>     but
>     > from the current OGP perspective there is no symmetrical relationship
>     possible
>     > between VWs that could be described as "peering".  It is the asymmetry of
>     the
>     > VW-RD relationship that has been the crux of the "no VW interop" issue.
>     For
>     > symmetrical peering, the protocol would need to mention at least two
>     > communicating VWs.
>
>     You can about peering with just two RD's and one AD, or one RD and two
>     AD's.
>
>     > Of course the situation could change as the protocol evolves.  For
>     example,
>     > once or twice we have heard mention that multiple ADs could be involved
>     in some
>     > way, and it seems certain that communication services from multiple VWs
>     will be
>     > merged because residents demand this.  This would start to take us into
>     VW-VW
>     > interop territory.  However, there is no such thing in VWRAP currently,
>     and
>     > it's not in the list of deliverables to include it, and therefore we
>     cannot say
>     > that VWRAP will provide VW-VW interop at all.  For now. ;-)
>
>     I can't comment on that cause I didn't see VWRAP yet, but from the
>     charter and the comments on this list I'd think that full support
>     for interop between any number of RD's and AD's is intended.
>
>     --
>     Carlo Wood <carlo@alinoe.com>
>
>

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


--
Carlo Wood <carlo@alinoe.com>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx



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



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


--0-2056852013-1254433708=:79438-- From josh@lindenlab.com Thu Oct 1 14:56:03 2009 Return-Path: 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 840DE3A6938 for ; Thu, 1 Oct 2009 14:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 nE2XQ6XMqXbX for ; Thu, 1 Oct 2009 14:56:02 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id AEC573A6840 for ; Thu, 1 Oct 2009 14:56:02 -0700 (PDT) Received: by pxi6 with SMTP id 6so672999pxi.32 for ; Thu, 01 Oct 2009 14:57:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.132.12 with SMTP id f12mr711483rvd.277.1254434243616; Thu, 01 Oct 2009 14:57:23 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090902230338.GC6652@alinoe.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Thu, 1 Oct 2009 14:57:23 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cd296467c22970474e6bb22 Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 21:56:03 -0000 --000e0cd296467c22970474e6bb22 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 1, 2009 at 2:34 PM, Morgaine wrote: > > Your next step is to realize that, for two structurally identical worlds, > if the seat of policy of one lies in its AD, then the seat of policy of the > other also lies in its AD. Therefore your statement needs to be modified to > the following: > > IMHO, it should be apparent that both the AD of the source world and the RD > and AD of the destination world all need to make policy decisions. > > I don't agree with this at all. A VW service provider could operate a region domain with no agent domain. I believe this is VERY LOOSELY equivalent to running an OpenSim instance in Grid mode today (but I can't state that definitively) the person running the sim is basically running just the region, and relying on someone else's agent domain (agent-centric services). Similarly, BigGiantCo could operate an agent domain for their employs (as a bolt-on to their enterprise LDAP server, say) with no region domain. A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to place the agent in a region. There aren't necessarily any other RDs or ADs involved at all. This is where protocol and policy come into play - the AD needs to communicate with and trust the RD and vice versa (even if that's nil-trust). --000e0cd296467c22970474e6bb22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgai= ne.dinova@googlemail.com> wrote:

Your next step is to realize that, for two structurally identical world= s, if the seat of policy of one lies in its AD, then the seat of policy of = the other also lies in its AD.=C2=A0 Therefore your statement needs to be m= odified to the following:

IMHO, it should be apparent that both= the AD of the source world and the RD and AD of the destination world all need to make policy decisions.

=C2=A0
I = don't agree with this at all.

A VW service provider could operat= e a region domain with no agent domain. I believe this is VERY LOOSELY equi= valent to running an OpenSim instance in Grid mode today (but I can't s= tate that definitively) the person running the sim is basically running jus= t the region, and relying on someone else's agent domain (agent-centric= services).

Similarly, BigGiantCo could operate an agent domain for their employs (= as a bolt-on to their enterprise LDAP server, say) with no region domain. <= br>
A BigGiantCo employee can visit the RD-only VW - the AD talks to the= RD to place the agent in a region. There aren't necessarily any other = RDs or ADs involved at all. This is where protocol and policy come into pla= y - the AD needs to communicate with and trust the RD and vice versa (even = if that's nil-trust).

--000e0cd296467c22970474e6bb22-- From cfk@pacbell.net Thu Oct 1 15:11:43 2009 Return-Path: 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 A0C8128C10C for ; Thu, 1 Oct 2009 15:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.852 X-Spam-Level: X-Spam-Status: No, score=0.852 tagged_above=-999 required=5 tests=[AWL=1.961, BAYES_05=-1.11, HTML_MESSAGE=0.001] 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 fSyWS7vFdt6x for ; Thu, 1 Oct 2009 15:11:42 -0700 (PDT) Received: from web82603.mail.mud.yahoo.com (web82603.mail.mud.yahoo.com [68.142.201.120]) by core3.amsl.com (Postfix) with SMTP id E2F823A679F for ; Thu, 1 Oct 2009 15:11:41 -0700 (PDT) Received: (qmail 48152 invoked by uid 60001); 1 Oct 2009 22:13:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WpzYBmQWJhfG6nsJ8c5Hy1NNMRZJPBvsOfst68qRuSFfm+YdPPugpWmxaniMqx5/3x8PXJBrpJnexDVjD0rNUJPb3076u5xZBbaNVqD6NyZQID1jedQSxo1RQ4cCC00soimnwFAz/zpUnRIdL4XG8xmkOaFxA+l5LErhHW+7jCQ=; Message-ID: <716017.47390.qm@web82603.mail.mud.yahoo.com> X-YMail-OSG: ZfRcQhAVM1n6YL45ygs2NnScjUAT7uWVp3eOZWIbnxfGNOOpN_7X32LefNuMX4MbytIRPNnTvk9aHTCsfE274wSrK710hj__P3cGv2t6WJYR221oC3y5HmVEdBd5P_poEwNnRutOBYSGpfRZK8qSw4UPsLG0VStKXqo0k0Pvww2hETIqiTfKmJj2DfOui2clpc5Ol918Z32FGUARZFVEq0_nwBp7oKheCSmKISqdQoAX.L40eRMsp.AGlqDDoLOv5.ydm7wkwhRtjJHYN2kxV0hHJ6FOR7goRAQkY0RLs_7WSk7k1QcVRJq3UIfbxqiwgRUyut0XHTVVc7fx3u78SDzzW2bv9uT5pk0BsnuKbkYmlSmKNSA2pG7XJ6W1auJrTxX20cGDGnu3JDRfp47q3yoyzbO_fWWrFeLg.MusRA-- Received: from [75.212.124.14] by web82603.mail.mud.yahoo.com via HTTP; Thu, 01 Oct 2009 15:13:05 PDT X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.3 References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090902230338.GC6652@alinoe.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Thu, 1 Oct 2009 15:13:05 -0700 (PDT) From: Charles Krinke To: Joshua Bell , ogpx@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-466661375-1254435185=:47390" Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 22:11:43 -0000 --0-466661375-1254435185=:47390 Content-Type: text/plain; charset=us-ascii Well, no, thats not quite how OpenSim works. A standalone OpenSim region with no grid services is probably loosely equivalent to no AD and I think that was the mode in which the tests were performed with the IBM OpenSim region and OGP a year or so ago. An OpenSim region running in grid mode is connected to a number of servers that connect the grid together. These are a UserServer, GridServer, Asset/InventoryServer and MessagingServer. So these are *more or less* equivalent to AD notions. Charles ________________________________ From: Joshua Bell To: ogpx@ietf.org Sent: Thursday, October 1, 2009 2:57:23 PM Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 On Thu, Oct 1, 2009 at 2:34 PM, Morgaine wrote: >Your next step is to realize that, for two structurally identical worlds, if the seat of policy of one lies in its AD, then the seat of policy of the other also lies in its AD. Therefore your statement needs to be modified to the following: > > >IMHO, it should be apparent that both the AD of the source world and the RD and AD of the destination world all >need to make policy decisions. > > I don't agree with this at all. A VW service provider could operate a region domain with no agent domain. I believe this is VERY LOOSELY equivalent to running an OpenSim instance in Grid mode today (but I can't state that definitively) the person running the sim is basically running just the region, and relying on someone else's agent domain (agent-centric services). Similarly, BigGiantCo could operate an agent domain for their employs (as a bolt-on to their enterprise LDAP server, say) with no region domain. A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to place the agent in a region. There aren't necessarily any other RDs or ADs involved at all. This is where protocol and policy come into play - the AD needs to communicate with and trust the RD and vice versa (even if that's nil-trust). --0-466661375-1254435185=:47390 Content-Type: text/html; charset=us-ascii
Well, no, thats not quite how OpenSim works.

A standalone OpenSim region with no grid services is probably loosely equivalent to no AD and I think that was the mode in which the tests were performed with the IBM OpenSim region and OGP a year or so ago.

An OpenSim region running in grid mode is connected to a number of servers that connect the grid together. These are a UserServer, GridServer, Asset/InventoryServer and MessagingServer. So these are *more or less* equivalent to AD notions.

Charles

From: Joshua Bell <josh@lindenlab.com>
To: ogpx@ietf.org
Sent: Thursday, October 1, 2009 2:57:23 PM
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01


On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:

Your next step is to realize that, for two structurally identical worlds, if the seat of policy of one lies in its AD, then the seat of policy of the other also lies in its AD.  Therefore your statement needs to be modified to the following:

IMHO, it should be apparent that both the AD of the source world and the RD and AD of the destination world all need to make policy decisions.

 
I don't agree with this at all.

A VW service provider could operate a region domain with no agent domain. I believe this is VERY LOOSELY equivalent to running an OpenSim instance in Grid mode today (but I can't state that definitively) the person running the sim is basically running just the region, and relying on someone else's agent domain (agent-centric services).

Similarly, BigGiantCo could operate an agent domain for their employs (as a bolt-on to their enterprise LDAP server, say) with no region domain.

A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to place the agent in a region. There aren't necessarily any other RDs or ADs involved at all. This is where protocol and policy come into play - the AD needs to communicate with and trust the RD and vice versa (even if that's nil-trust).

--0-466661375-1254435185=:47390-- From infinity@lindenlab.com Thu Oct 1 15:16:41 2009 Return-Path: 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 F36C13A6840 for ; Thu, 1 Oct 2009 15:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 h6TxYky5tXp5 for ; Thu, 1 Oct 2009 15:16:39 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 68FDA3A679F for ; Thu, 1 Oct 2009 15:16:39 -0700 (PDT) Received: by pzk35 with SMTP id 35so858195pzk.29 for ; Thu, 01 Oct 2009 15:18:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.173.16 with SMTP id v16mr636766rve.129.1254435483062; Thu, 01 Oct 2009 15:18:03 -0700 (PDT) In-Reply-To: <716017.47390.qm@web82603.mail.mud.yahoo.com> References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <716017.47390.qm@web82603.mail.mud.yahoo.com> Date: Thu, 1 Oct 2009 15:18:02 -0700 Message-ID: <3a880e2c0910011518i4e068b55scc0baf19997f8e6f@mail.gmail.com> From: Infinity Linden To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 22:16:41 -0000 isn't an OpenSim region running in standalone mode like having all the services locally. i mean... it's beginning to sound like a petty distinction, but in order to serve up information about the user or the region or assets in the region, you have to have SOMETHING that behaves like a user server or asset server. i always looked at it as being that all these "services" were local to the machine, not that they didn't really exist. On Thu, Oct 1, 2009 at 3:13 PM, Charles Krinke wrote: > Well, no, thats not quite how OpenSim works. > > A standalone OpenSim region with no grid services is probably loosely > equivalent to no AD and I think that was the mode in which the tests were > performed with the IBM OpenSim region and OGP a year or so ago. > > An OpenSim region running in grid mode is connected to a number of server= s > that connect the grid together. These are a UserServer, GridServer, > Asset/InventoryServer and MessagingServer. So these are *more or less* > equivalent to AD notions. > > Charles > > ________________________________ > From: Joshua Bell > To: ogpx@ietf.org > Sent: Thursday, October 1, 2009 2:57:23 PM > Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 > > > On Thu, Oct 1, 2009 at 2:34 PM, Morgaine > wrote: >> >> Your next step is to realize that, for two structurally identical worlds= , >> if the seat of policy of one lies in its AD, then the seat of policy of = the >> other also lies in its AD.=A0 Therefore your statement needs to be modif= ied to >> the following: >> >> IMHO, it should be apparent that both the AD of the source world and the >> RD and AD of the destination world all need to make policy decisions. >> > > I don't agree with this at all. > > A VW service provider could operate a region domain with no agent domain.= I > believe this is VERY LOOSELY equivalent to running an OpenSim instance in > Grid mode today (but I can't state that definitively) the person running = the > sim is basically running just the region, and relying on someone else's > agent domain (agent-centric services). > > Similarly, BigGiantCo could operate an agent domain for their employs (as= a > bolt-on to their enterprise LDAP server, say) with no region domain. > > A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD t= o > place the agent in a region. There aren't necessarily any other RDs or AD= s > involved at all. This is where protocol and policy come into play - the A= D > needs to communicate with and trust the RD and vice versa (even if that's > nil-trust). > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From dwl@us.ibm.com Thu Oct 1 15:25:41 2009 Return-Path: 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 C34843A67B3; Thu, 1 Oct 2009 15:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.746 X-Spam-Level: X-Spam-Status: No, score=-5.746 tagged_above=-999 required=5 tests=[AWL=0.852, BAYES_00=-2.599, 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 QeVizlc6agx6; Thu, 1 Oct 2009 15:25:40 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id BDA623A695A; Thu, 1 Oct 2009 15:24:11 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n91MI0qf021852; Thu, 1 Oct 2009 18:18:00 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n91MPTTa207076; Thu, 1 Oct 2009 18:25:31 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n91MPSQS010030; Thu, 1 Oct 2009 18:25:28 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n91MPSgl010027; Thu, 1 Oct 2009 18:25:28 -0400 In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090902230338.GC6652@alinoe.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> To: Joshua Bell MIME-Version: 1.0 X-KeepSent: BDE64925:B257B8B0-85257642:007957C9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Thu, 1 Oct 2009 18:25:22 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 10/01/2009 18:25:27, Serialize complete at 10/01/2009 18:25:27 Content-Type: multipart/alternative; boundary="=_alternative 007B2CA285257642_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 22:25:41 -0000 This is a multipart message in MIME format. --=_alternative 007B2CA285257642_= Content-Type: text/plain; charset="US-ASCII" One.. I think its very important to keep in mind that services are going to manage policy, not the domains they reside in. This is important, because it highlights the fact that what's going to happen when different people deploy this stuff in different deployments is going to vary. I think we need to be very careful to focus not on any one deployment pattern, but the broader set of possible deployment patterns we are attempting to enable. This goes hand in glove with Joshua's comments below. This leads to Two.. I *think* the correct model is "All the services involved may have policies they bring to the table." The set of actions which are possible between an arbitrary service inside of one deployment and an arbitrary service inside another is going to be dictated by the policies those two services follow. This is especially likely when looking at things like asset permissions. Consider the case of a region attempting to pass a prim to an asset store for storage. The Region may have policies about which asset stores it is willing to deliver assets to. The Asset store may have policies about which regions it is willing to accept assets from. If the user's agent domain holds his inventory (One, but not the only possible deployment pattern) it may have policies about the asset servers it interacts with. Its possible to imagine cases where the only role the ADs play in this policy decision is that they have authenticated the user, We need to be careful, when looking at this stuff to strike a balance between focusing on the current deployed clusterings, and turning everything into soup. That said, the actual deployed systems which implement these specifications are only going to be able to enforce policy at the interfaces we define, and these interfaces are on services, not domains. In fact, as I've argued several times, I think, in general, the notion of a domain emerges from the policies of the deployed services, not the other way around. Infinity's made a very nice case for describing the key distinctions as being "Agent domains include the auth service" and "Region Domains include the presence service" If we keep this in mind, I think it helps us move away from thinking purely in terms of the split that Linden Labs has focused on. To circle back to the question of soup, simply focusing on the services risks describing stuff that's falls into the HLA/DIS trap of having deployments which are each "conforming" but vary so much in assumption as to not actually interoperate. - David ~Zha Joshua Bell Sent by: ogpx-bounces@ietf.org 10/01/2009 05:57 PM To ogpx@ietf.org cc Subject Re: [ogpx] VWRAP Draft Charter - 2009 09 01 On Thu, Oct 1, 2009 at 2:34 PM, Morgaine wrote: Your next step is to realize that, for two structurally identical worlds, if the seat of policy of one lies in its AD, then the seat of policy of the other also lies in its AD. Therefore your statement needs to be modified to the following: IMHO, it should be apparent that both the AD of the source world and the RD and AD of the destination world all need to make policy decisions. I don't agree with this at all. A VW service provider could operate a region domain with no agent domain. I believe this is VERY LOOSELY equivalent to running an OpenSim instance in Grid mode today (but I can't state that definitively) the person running the sim is basically running just the region, and relying on someone else's agent domain (agent-centric services). Similarly, BigGiantCo could operate an agent domain for their employs (as a bolt-on to their enterprise LDAP server, say) with no region domain. A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to place the agent in a region. There aren't necessarily any other RDs or ADs involved at all. This is where protocol and policy come into play - the AD needs to communicate with and trust the RD and vice versa (even if that's nil-trust). _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 007B2CA285257642_= Content-Type: text/html; charset="US-ASCII"
One.. I think its very important to keep in mind that services are going to manage policy, not the domains they reside in. This is important, because it highlights the fact that what's going to happen when different people deploy this stuff in different deployments is going to vary.  I think we need to be very careful to focus not on any one deployment pattern, but the broader set of possible deployment patterns we are attempting to enable. This goes hand in glove with Joshua's comments below.

This leads to

Two.. I *think* the correct model is "All the services involved may have policies they bring to the table."  The set of actions which are possible between an arbitrary service inside of one deployment and an arbitrary service inside another is going to be
dictated by the policies those two services follow.  This is especially likely when looking at things like asset permissions.  Consider the case of a region attempting to pass a prim to an asset store for storage. The Region may have policies about which
asset stores it is willing to deliver assets to. The Asset store may have policies about which regions it is willing to accept assets from. If the user's agent domain holds his inventory (One, but not the only possible deployment pattern) it may have policies about
the asset servers it interacts with. Its possible to imagine cases where the only role the ADs play in this policy decision is that they have authenticated the user,

We need to be careful, when looking at this stuff to strike a balance between focusing on the current deployed clusterings, and turning everything into soup. That said, the actual deployed systems which implement these specifications are only going to be able
to enforce policy at the interfaces we define, and these interfaces are on services, not domains.  In fact, as I've argued several times, I think, in general, the notion of a domain emerges from the policies of the deployed services, not the other way around. Infinity's made a very nice case for describing the key distinctions as being "Agent domains include the auth service" and "Region Domains include the presence service"  If we keep this in mind, I think it helps us move away from thinking purely in terms of the split that Linden Labs has focused on. To circle back to the question of soup, simply focusing on the services risks describing stuff that's falls into the HLA/DIS trap of having deployments which are each "conforming" but vary so much in assumption as to not actually interoperate.

- David
~Zha





Joshua Bell <josh@lindenlab.com>
Sent by: ogpx-bounces@ietf.org

10/01/2009 05:57 PM

To
ogpx@ietf.org
cc
Subject
Re: [ogpx] VWRAP Draft Charter - 2009 09 01






On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:

Your next step is to realize that, for two structurally identical worlds, if the seat of policy of one lies in its AD, then the seat of policy of the other also lies in its AD.  Therefore your statement needs to be modified to the following:
IMHO, it should be apparent that both the AD of the source world and the RD and AD of the destination world all need to make policy decisions.

 
I don't agree with this at all.

A VW service provider could operate a region domain with no agent domain. I believe this is VERY LOOSELY equivalent to running an OpenSim instance in Grid mode today (but I can't state that definitively) the person running the sim is basically running just the region, and relying on someone else's agent domain (agent-centric services).

Similarly, BigGiantCo could operate an agent domain for their employs (as a bolt-on to their enterprise LDAP server, say) with no region domain.

A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to place the agent in a region. There aren't necessarily any other RDs or ADs involved at all. This is where protocol and policy come into play - the AD needs to communicate with and trust the RD and vice versa (even if that's nil-trust).
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 007B2CA285257642_=-- From josh@lindenlab.com Thu Oct 1 15:26:36 2009 Return-Path: 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 AAEFA3A67A4 for ; Thu, 1 Oct 2009 15:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 xz9bH0Dwx4mi for ; Thu, 1 Oct 2009 15:26:35 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id C10663A679F for ; Thu, 1 Oct 2009 15:26:35 -0700 (PDT) Received: by pzk35 with SMTP id 35so868432pzk.29 for ; Thu, 01 Oct 2009 15:27:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.142.11 with SMTP id p11mr715149rvd.7.1254436079457; Thu, 01 Oct 2009 15:27:59 -0700 (PDT) In-Reply-To: <716017.47390.qm@web82603.mail.mud.yahoo.com> References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <716017.47390.qm@web82603.mail.mud.yahoo.com> Date: Thu, 1 Oct 2009 15:27:59 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cd14836e8d7180474e7282d Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 22:26:36 -0000 --000e0cd14836e8d7180474e7282d Content-Type: text/plain; charset=UTF-8 Cool, thanks for the clarification. Yeah... I think if you take GridServer out of that mix you'd get something conceptually equivalent to the AD. On Thu, Oct 1, 2009 at 3:13 PM, Charles Krinke wrote: > Well, no, thats not quite how OpenSim works. > > A standalone OpenSim region with no grid services is probably loosely > equivalent to no AD and I think that was the mode in which the tests were > performed with the IBM OpenSim region and OGP a year or so ago. > > An OpenSim region running in grid mode is connected to a number of servers > that connect the grid together. These are a UserServer, GridServer, > Asset/InventoryServer and MessagingServer. So these are *more or less* > equivalent to AD notions. > > Charles > > ------------------------------ > *From:* Joshua Bell > *To:* ogpx@ietf.org > *Sent:* Thursday, October 1, 2009 2:57:23 PM > *Subject:* Re: [ogpx] VWRAP Draft Charter - 2009 09 01 > > > On Thu, Oct 1, 2009 at 2:34 PM, Morgaine wrote: > >> >> Your next step is to realize that, for two structurally identical worlds, >> if the seat of policy of one lies in its AD, then the seat of policy of the >> other also lies in its AD. Therefore your statement needs to be modified to >> the following: >> >> IMHO, it should be apparent that both the AD of the source world and the >> RD and AD of the destination world all need to make policy decisions. >> >> > I don't agree with this at all. > > A VW service provider could operate a region domain with no agent domain. I > believe this is VERY LOOSELY equivalent to running an OpenSim instance in > Grid mode today (but I can't state that definitively) the person running the > sim is basically running just the region, and relying on someone else's > agent domain (agent-centric services). > > Similarly, BigGiantCo could operate an agent domain for their employs (as a > bolt-on to their enterprise LDAP server, say) with no region domain. > > A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to > place the agent in a region. There aren't necessarily any other RDs or ADs > involved at all. This is where protocol and policy come into play - the AD > needs to communicate with and trust the RD and vice versa (even if that's > nil-trust). > > --000e0cd14836e8d7180474e7282d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cool, thanks for the clarification. Yeah... I think if you take GridServer = out of that mix you'd get something conceptually equivalent to the AD. =

On Thu, Oct 1, 2009 at 3:13 PM, Charles = Krinke <cfk@pacbell= .net> wrote:
Well, no, thats not quite how OpenSim works.

A standalone OpenS= im region with no grid services is probably loosely equivalent to no AD and= I think that was the mode in which the tests were performed with the IBM O= penSim region and OGP a year or so ago.

An OpenSim region running in grid mode is connected to a number of serv= ers that connect the grid together. These are a UserServer, GridServer, Ass= et/InventoryServer and MessagingServer. So these are *more or less* equival= ent to AD notions.

Charles

From: Joshua Bell <josh@lindenlab.com&= gt;
To: ogpx@ietf.org
Sent: Thursday, October 1,= 2009 2:57:23 PM

Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01
<= /font>

On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com> = wrote:

Your next step is to realize that, for two structurally identical world= s, if the seat of policy of one lies in its AD, then the seat of policy of = the other also lies in its AD.=C2=A0 Therefore your statement needs to be m= odified to the following:

IMHO, it should be apparent that both= the AD of the source world and the RD and AD of the destination world all need to make policy decisions.

=C2=A0
I = don't agree with this at all.

A VW service provider could operat= e a region domain with no agent domain. I believe this is VERY LOOSELY equi= valent to running an OpenSim instance in Grid mode today (but I can't s= tate that definitively) the person running the sim is basically running jus= t the region, and relying on someone else's agent domain (agent-centric= services).

Similarly, BigGiantCo could operate an agent domain for their employs (= as a bolt-on to their enterprise LDAP server, say) with no region domain. <= br>
A BigGiantCo employee can visit the RD-only VW - the AD talks to the= RD to place the agent in a region. There aren't necessarily any other = RDs or ADs involved at all. This is where protocol and policy come into pla= y - the AD needs to communicate with and trust the RD and vice versa (even = if that's nil-trust).


--000e0cd14836e8d7180474e7282d-- From morgaine.dinova@googlemail.com Thu Oct 1 15:29:23 2009 Return-Path: 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 C17603A6828 for ; Thu, 1 Oct 2009 15:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.12 X-Spam-Level: * X-Spam-Status: No, score=1.12 tagged_above=-999 required=5 tests=[AWL=-2.315, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, SARE_FWDLOOK=1.666, SARE_UNSUB18=0.131] 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 Vq3feeYy9O5O for ; Thu, 1 Oct 2009 15:29:15 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 755D73A67B3 for ; Thu, 1 Oct 2009 15:29:08 -0700 (PDT) Received: by ewy28 with SMTP id 28so796513ewy.42 for ; Thu, 01 Oct 2009 15:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8KIqaLcPxwQGpo2AJXBsPgwPKGiwbxLoJ5tDnillny0=; b=VKIWyzP0JjAFpg9DEwHK8/RNo3PZ6dJEZaL2q7pfIPK6qOGag3u1foJ6b5n3l+kI+V N7KaW2Xqavfb4aAF+4J3uELUlE7DOJucmi/YalRAG3rNSqRHxwmhBxYtaFeln2TF4g1e sg2PeMxITXcrcbid7HBIOiYPwhaiNLfFWJZC8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=x5Q5mjCc9QpJ0rHyfVa9JB8rHJb3J5bWP7tZ4BldBFlj/AOcjoRp3vM+e7bSqxk3N3 0cEPmotKjmGXPKDAmpGsUUl/+zIjirpnQWJZNhrb84CHJ+w4hWB48Tlkp0BXuD57ye+0 kPCKl+mfRuRl3XDeyUSD0jDym0PaBLgognlHk= MIME-Version: 1.0 Received: by 10.211.142.17 with SMTP id u17mr2132425ebn.0.1254436230626; Thu, 01 Oct 2009 15:30:30 -0700 (PDT) In-Reply-To: <3a880e2c0910011442q5b35bf8epfad7cea37eb5d5d1@mail.gmail.com> References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <3a880e2c0910011442q5b35bf8epfad7cea37eb5d5d1@mail.gmail.com> Date: Thu, 1 Oct 2009 23:30:30 +0100 Message-ID: From: Morgaine To: Infinity Linden Content-Type: multipart/alternative; boundary=00504502c78eeb7ed80474e731c8 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 22:29:23 -0000 --00504502c78eeb7ed80474e731c8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 1, 2009 at 10:42 PM, Infinity Linden wrote: did we read the same response? i totally didn't get "destination determines policy" from josh's response. You need to go further back to find the reference to *Destination Determines Policy*, which I wrote in my reply to Vaugh, here: http://www.ietf.org/mail-archive/web/ogpx/current/msg00417.html . Joshua then replied to that, and very clearly stated that the destination RD will also determine policy. Of course, the destination RD's policy may be given by its world's AD, so naturally that AD will have to be party to the protocol. SL provides a good example. Would you want an external grid to provide teleports into one of your regions, consulting only its own AD and not SL's AD? I think not. There's total symmetry between the worlds here. You need to stop thinking of one world as "special" and trying to grow it with regions, and start thinking of worlds as peers. Destination Determines Policy is the only approach that allows for tourism to one world simultaneously from multiple other worlds each having different policies, which is why it's so important. Under any other model, you either have no interop at all because the tourism is disallowed, or else you get the perpetual state of war that Vaughn nicely mocked as "war over purple". This is why I'm so pleased that the profile of the RD is being raised in respect of determining policy. It's a small step from there to realizing that Destination Determines Policy is where you're actually heading because it's needed for interop between worlds. Morgaine. ========================================== On Thu, Oct 1, 2009 at 10:42 PM, Infinity Linden wrote: > did we read the same response? i totally didn't get "destination > determines policy" from josh's response. > > and what? a single AD defines the trust policy of the RDs it connects to? > huh? > > i'm totally reading different documents than you are morgaine. > > On Thu, Oct 1, 2009 at 2:34 PM, Morgaine > wrote: > > On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell wrote: > >> > >> IMHO, it should be apparent that both AD (which is the agent/advocate > for > >> the user) and RD (where the user wants to be) both need to make policy > >> decisions. > >> > > > > Excellent, Joshua! > > > > I think we're finally approaching the road towards Destination Determines > > Policy now, which is a prerequisite for real interop between virtual > > worlds. This was simply not possible with the old OGP thinking in which > > policy was given by a "trust domain" defined by a single AD alone. > > > > It's a two-part problem. Naturally your source world can impose > > restrictions on travel (a walled garden may disallow any foreign travel > at > > all, for example), that's clear. What hasn't been clear until now is > that > > the destination world will have conditions which are every bit as strong > and > > important as the source world, and represented in the same way (eg. in > their > > AD). Both sides must be allowed equivalent representation in the > protocol. > > > > This is why the single-world terminology was such a barrier earlier. It > > completely prevented us from bringing the two worlds into the discussion > > simultaneously, which is necessarily when both source and destination are > > completely equivalent peer worlds. > > > > Your next step is to realize that, for two structurally identical worlds, > if > > the seat of policy of one lies in its AD, then the seat of policy of the > > other also lies in its AD. Therefore your statement needs to be modified > to > > the following: > > > > IMHO, it should be apparent that both the AD of the source world and the > RD > > and AD of the destination world all need to make policy decisions. > > > > > > What's true for the source world is also true for the destination world, > > policy-wise. The destination world is not "inferior" in any way. It's a > > necessary peer in the protocol. You can't exclude it from the equation. > > > > > > Morgaine. > > > > > > > > > > > > > > ========================================= > > > > On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell wrote: > >> > >> Without diving in too deep, I believe this thread is putting up a > >> two-level false dichotomy - either the RD determines policy or the AD > >> determines policy, OR things aren't sensible w/o nil trust. If that's a > >> mis-reading, my apologies. > >> > >> IMHO, it should be apparent that both AD (which is the agent/advocate > for > >> the user) and RD (where the user wants to be) both need to make policy > >> decisions. > >> > >> A corporate AD may restrict where users may visit (e.g. > >> agentd.corp.example.com may say "no visiting party.example.com from > work!") > >> or an AD may restrict users based on personal preferences > >> (agentd.safesurf.example.com may say "scam.example.com is on a shared > >> blacklist of malicious sites, teleport blocked"), legal or political > >> requirements (agentd.kidfriendly.example.com may say "you can't visit > >> adultgrid.example.com"). Note that in all cases the AD is enforcing > policy > >> as an agent of the user, just as a web browser on a local network does > >> today. Presumably, there will exist many ADs that provide no > restrictions > >> whatsoever, just as most Web browsers accessing the 'net via most ISPs > in > >> most countries today don't restrict access to Web content via policy. > >> > >> On the flip side, the RD will also have policy. Corporate VWs may limit > >> access to employees. Adult-centric VWs may limit access to agents from > ADs > >> that verify accounts with some well known service. > >> Real-world-region-specific RDs may require citizenship checks and deny > >> access to citizens of some nation-states. And of course permissions > would > >> doubtless exist on a per-user basis as well as per-AD. Again - no > different > >> than access permissions today on the Web, except that instead of being a > >> two-party user/service, it's three party user/AD/RD. And one hopes that, > >> like most of the Web, content is freely visitable by all. > >> > >> On the topic of nil-trust: again, I wholeheartedly support the stance > that > >> the protocol should support nil trust operation. I hope that both the > >> protocol and operations of VWRAP-based worlds allow the bulk of VWRAP > >> traffic to occur in a nil trust environment, just like the Web does > today. > >> However, I *suspect* that, in practical terms, the abilities we want to > >> grant to regions by visiting them - to display our avatars, to broadcast > >> information about our agents, to give and receive virtual goods - will > >> require at least a modicum of trust for most VW interaction, at least on > the > >> level of an SSL-style secured connection that gives users a certificate > to > >> look at that provides some identity/trust information about the service > >> provider. > >> > >> I suspect I'm going to beat this drum a lot - "VWs are just like the > Web, > >> except where they're different" :) > >> > >> On Tue, Sep 29, 2009 at 5:51 PM, Morgaine < > morgaine.dinova@googlemail.com> > >> wrote: > >>> > >>> Hi Vaughn! :-) > >>> > >>> Your description of our discussion is quite accurate. However, it > seems > >>> to imply that I advocate in favour of the view that the AD must be the > seat > >>> of all policy for connected regions. I do not. I was merely > explaining the > >>> architecture of AD+RD pairing as it has been described to us repeatedly > >>> throughout the two years of our OGP-related work in the LL+IBM > sponsored > >>> Architecture Working Group within Second Life. > >>> > >>> After the emails, Carlo and I examined this issue with higher > discussion > >>> bandwidth inside SL, and it turned out that we were describing two > different > >>> things: I was explaining the AD+RD relationship in OGP, while Carlo > was > >>> describing RDs as they should be designed if an RD were an autonomous > unit > >>> with its own policies, effectively a small world. If OGP were designed > >>> differently and less restrictively to allow that, then there would have > been > >>> no discussion. :-) > >>> > >>> Of course, OGP is not VWRAP, but only the seedcorn for VWRAP. We can > >>> make VWRAP as flexible as we like, and it's easy to see its potential > >>> flexibility in David's deployments document. Consequently, I have high > >>> hopes that all parties will be happy with the eventual outcome. :-) > >>> > >>> You may have missed the primary reason why I do not advocate a design > in > >>> which an OGP-style AD is the seat of all power, possibly because the > >>> discussion has been spread out across all of OGPX and MMOX. It's easy > to > >>> summarize in one sentence though: such a design cannot underpin an > >>> Internet-wide metaverse of interoperating virtual worlds because it > doesn't > >>> respect the key meme of virtual and non-virtual tourism: Destination > >>> Determines Policy. > >>> > >>> This meme is so fundamental and crucial (and obvious) that OGP's > support > >>> of the exact opposite is terminally broken, as a basis for the > hypothetical > >>> metaverse. Indeed, you yourself have referred to the problem in the > funny > >>> "war over purple". :-) At best such a design can support only a random > >>> scattering of VPN-like walled gardens, all isolated and incapable of > >>> interoperating because they all claim the "one true policy". We should > not > >>> go there. > >>> > >>> The most recent description of this problematic aspect of the OGP > design > >>> was posted by Magnus Zeisig in his excellent email at > >>> http://www.ietf.org/mail-archive/web/ogpx/current/msg00324.html , > which I > >>> fully support. Such balkanization is not a desireable goal when > designing a > >>> VW interop protocol. > >>> > >>> So where are we now? We're at the stage of examining David's VWRAP > >>> deployment patterns to see how the protocol can support them. And in > that > >>> examination, it is likely to become clear that the old OGP model of "AD > >>> determines policy" is completely non-viable for interoperating between > >>> VWRAP-compatible virtual worlds, except when that policy is "nil trust" > as a > >>> common denominator. > >>> > >>> Consequently, we will either decide to live with the original OGP split > >>> and use "nil trust" as our basis for VW interop, or else we will > redesign > >>> the AD/RD relationship to place many more important policy decisions > where > >>> they really belong, at destination. The latter seems the best choice > to me, > >>> and of course it would make Carlo happy, and it is also the model that > every > >>> single existing world already operates --- when in Rome, do as the > Romans > >>> do. Only the old OGP AD/RD two-way split design is out of step. Let's > hope > >>> that we can correct that in VWRAP. :-)) > >>> > >>> > >>> Morgaine. > >>> > >>> > >>> > >>> > >>> > >>> > >>> ==================================== > >>> > >>> > >>> On Tue, Sep 29, 2009 at 9:16 PM, Vaughn Deluca < > vaughn.deluca@gmail.com> > >>> wrote: > >>>> > >>>> Carlo and Morgaine have above been involved in a very interesting > >>>> discussion about the nature of the (or *a*) virtual world. > >>>> Painting their positions with broad strokes, Morgaine stresses the > >>>> primary role of the AD as the seat of policy and trust, up to the > point > >>>> where he denies the RD any role above that of a convenient extension > of the > >>>> AD, i.e. the RD as "colony without a government". Carlo passionately > argues > >>>> for the independent role of the RD in policy issues. > >>>> I feel that both positions are valid (to some degree), and both can be > >>>> covered by VWRAP. > >>>> Calo makes absolutely clear that having all policy in the respective > ADs > >>>> of the avatars leads to problems when several avatars meet in one > region > >>>> domain, say RD1. Avatars will be busy killing each other over the > right to > >>>> wear purple, and for the innocent bystanders caught in the crossfire > it will > >>>> be fully unclear were to complain. Stepping in Morgaines shoes, i > think i > >>>> would argue that what Carlo asks for can be realised by applying the > policy > >>>> of a *particular* AD to RD1. The rules to deal with color of clothes, > could > >>>> be formulated in AD1 associated with RD1. In principle Carlo could run > this > >>>> domain himself, even without a single avatar in it, and in this way > get his > >>>> "government" and set any policy he wants. If two avatars from AD2 and > AD3 > >>>> visit RD1, The policy in RD1 would be governed by what is specified by > AD1. > >>>> While this fully fits Morgaines view of "AD rules all", and also fits > >>>> Carlo call for autonomy of RD1, it feels decidedly like a kludge, and > in > >>>> this particular case it seems much more straightforward to make RD1 > more > >>>> autonomous. Yet, to keep everything within one framework, this kludge > seems > >>>> to be the logical solution... I would like to hear what others think > about > >>>> this. > >>>> One other remark: the minimal example for a "world" -one AD and one > >>>> RD- would be more useful when extended with one asset service AS. > Explicit > >>>> mentioning of the AS will make it much easier to discuss IP issues. > >>>> Vaughn > >>>> > >>>> > >>>> On Mon, Sep 14, 2009 at 10:44 AM, Carlo Wood > wrote: > >>>>> > >>>>> On Mon, Sep 14, 2009 at 06:43:06AM +0100, Morgaine wrote: > >>>>> > Carlo asked for detailed comments on the below, so here goes. :-) > >>>>> > > >>>>> > > >>>>> > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood > wrote: > >>>>> > > >>>>> > On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote: > >>>>> > > The problem you see is that a virtual world is much more than > >>>>> > just a > >>>>> > Region > >>>>> > > Domain. It is a complete set of services of which the Region > >>>>> > Domain > >>>>> > service is > >>>>> > > just one. Other typical services might be those of the Agent > >>>>> > Domain > >>>>> > (which > >>>>> > > provides identification and authorization services and > possibly > >>>>> > others), > >>>>> > as > >>>>> > > well as asset and inventory services, IM and other > >>>>> > communication > >>>>> > services, and > >>>>> > > maybe several more. > >>>>> > > >>>>> > Well... that is purely semantic. It is a way to define VW, but > >>>>> > not one that > >>>>> > I've been using :/ > >>>>> > > >>>>> > > >>>>> > It's a rough top-level projection of the architectural model of > >>>>> > VWRAP, once the > >>>>> > various services have been decoupled in the way that David Levine > >>>>> > often > >>>>> > describes to us. Nothing very contentious there, everyone likes a > >>>>> > services-oriented approach. :-) > >>>>> > > >>>>> > > >>>>> > > >>>>> > For simplicity, assume that only two things are needed to > create > >>>>> > a complete > >>>>> > virtual world, like SL or OG: A Region Domain (RD) and an Agent > >>>>> > Domain > >>>>> > (AD). > >>>>> > > >>>>> > > >>>>> > I am happy to consider that simple scenario as representative. It > is > >>>>> > quite > >>>>> > reasonable to equate AD with VW because the AD is the focus of > almost > >>>>> > all the > >>>>> > policy decisions of a VWRAP-based world. When other decoupled > >>>>> > services are > >>>>> > added to this picture, it doesn't change the fundamental > architecture > >>>>> > of AD + > >>>>> > RDs, only extends it by decoupling more than just the region > service. > >>>>> > So > >>>>> > that's fine with me. > >>>>> > >>>>> I totally disagree that the AD is the representative...and why do you > >>>>> say > >>>>> that below a sentence of me where I say "A Region Domain (RD) and an > >>>>> Agent Domain (AD)"? > >>>>> > >>>>> This is like I say "VW = AD + RD", and you go: "yes, VW = AD". We > can't > >>>>> have a discussion like that Morgaine. > >>>>> > >>>>> > Currently, without any interop, each administrative entity (or > >>>>> > trust > >>>>> > entity) > >>>>> > will need to provide both: an RD *and* an AD, otherwise they > >>>>> > don't have a > >>>>> > functional VW. > >>>>> > > >>>>> > > >>>>> > Correct. The AD is the seat of most (but not all) of the policy > >>>>> > decisions of a > >>>>> > >>>>> I even *stressed* the '*and*' here, and you do it again. > >>>>> > >>>>> > VW, so it's very central to the existence of a VW. While it's > >>>>> > possible to > >>>>> > imagine policy-free VWs that temporarily take on the policy of any > >>>>> > other world > >>>>> > they hook up with, this is clearly a subset situation. All the > >>>>> > currently known > >>>>> > SL-like virtual worlds are grids of the SL kind, with their own > >>>>> > individual > >>>>> > policies which they are not going to change on interop. > >>>>> > > >>>>> > > >>>>> > > >>>>> > Your conclusion is that a VW exist of both 1 RD and 1 AD. But I > >>>>> > ask you to > >>>>> > reconsider if that conclusion is correct, because it is based > on > >>>>> > the > >>>>> > current > >>>>> > situation without any interop. Now "correct" might not be the > >>>>> > correct word > >>>>> > - heh. > >>>>> > Rather I should say: I ask you to reconsider if that definition > >>>>> > is very > >>>>> > useful. > >>>>> > > >>>>> > Lets consider the following fictive case: > >>>>> > > >>>>> > LL runs one RD and AD, called RD1 and AD1. > >>>>> > CB (Cable Beach) runs another RD and AD, called RD2 and AD2. > >>>>> > A user that authenticates with either AD1 or AD2 can travel to > >>>>> > RD1 AND RD2, > >>>>> > completely symmetrical, keeping their respective AD1- and AD2- > >>>>> > assets etc. > >>>>> > This is possible with the right policies, so for the sake of > >>>>> > looking at > >>>>> > the usefulness of the above definition of VW, assume this is > the > >>>>> > case. > >>>>> > > >>>>> > > >>>>> > That's not quite right because Cable Beach is not a world provider > >>>>> > like LL. > >>>>> > Cable Beach is perhaps best described as a "login mediation" > >>>>> > mechanism or > >>>>> > >>>>> I might not understand what the real Cable Beach is or wants to be, I > >>>>> was just > >>>>> trying to give an example to work with. So, again: > >>>>> > >>>>> LL runs one RD and AD, called RD1 and AD1. > >>>>> OG runs another RD and AD, called RD2 and AD2. > >>>>> A user that authenticates with either AD1 or AD2 can travel to RD1 > AND > >>>>> RD2, > >>>>> completely symmetrical, keeping their respective AD1- and AD2- assets > >>>>> etc. > >>>>> This is possible with the right policies, so for the sake of looking > at > >>>>> the usefulness of the above definition of VW, assume this is the > case. > >>>>> > >>>>> > protocol, which provides a model for interaction between a "world > >>>>> > service" > >>>>> > (effectively an AD), the user's client, and various decoupled > >>>>> > services such as > >>>>> > simulation nodes (possibly an RD) and inventory/asset services. > >>>>> > Let's assume > >>>>> > therefore that your "CB" above means something different (another > >>>>> > world > >>>>> > provider similar to LL), and then we can proceed with your example > >>>>> > case. > >>>>> > >>>>> Ok > >>>>> > >>>>> > Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be > >>>>> > another VW? > >>>>> > Or do you think it would make most sense in THIS case to speak > of > >>>>> > a single > >>>>> > VW? > >>>>> > > >>>>> > > >>>>> > They're two worlds because you defined them as such, as each has > its > >>>>> > own AD. > >>>>> > :-) But that aside, if they were set up separately then they have > >>>>> > two > >>>>> > different sets of policies, two different sets of residents, two > >>>>> > different > >>>>> > ToS's, possibly two different legal jurisdictions, two different > >>>>> > mechanisms for > >>>>> > abuse control and conflict resolution, and so on and so forth. If > >>>>> > they were > >>>>> > created to be worlds that can stand alone but interoperate when > >>>>> > desired, then > >>>>> > each of these is a diffferent world. I don't see how that can be > >>>>> > disputed. > >>>>> > >>>>> As I stated in one of my first posts, it will (hopefully!!!) be > mainly > >>>>> the > >>>>> the *RD* and NOT the AD that all of those things are a function of! > >>>>> > >>>>> You keep saying that it's mainly the AD that determines these things, > >>>>> but > >>>>> that would be confusing and very annoying. If two people meet in a > >>>>> virtual > >>>>> world, that is - if they are standing next to eachother in one region > >>>>> and > >>>>> using local chat - then they should fall under the same legal > >>>>> jurisdiction > >>>>> and the same ToS: it is the region that determines the rules, not the > >>>>> AD > >>>>> that they used to login with. > >>>>> > >>>>> As example, ToS1 says: it's ok to be naked; and ToS2 says: it's a > >>>>> bannable > >>>>> offence to be naked. Do you really think that it's even workable if > the > >>>>> ToS to be applied is a function of the AD? Say you login using AD2, > so > >>>>> ToS2 applies to you. You meet someone else that is naked. You know > that > >>>>> you are not allowed to and you are offended. You create an abuse > >>>>> report; > >>>>> where does that report go to? To your AD administration? That makes > no > >>>>> sense: that naked person is using a different AD. To his/her AD > >>>>> administration > >>>>> then? That makes also no sense since they allow it. > >>>>> > >>>>> Seriously, there is only one reasonable thing to do: the ToS that > >>>>> applies > >>>>> is a function of the Region Domain *only*, and if you write an abuse > >>>>> report, > >>>>> it should go to the administration of the region that you are in and > >>>>> not > >>>>> to your or the others AD administration. Same holds for the things > >>>>> related > >>>>> to legal jurisdiction and any other 'rules' that applies at any given > >>>>> moment (to users). The only thing that might be a function of the AD > >>>>> are > >>>>> technical policies that are automatically enforced by VWRAP. > >>>>> > >>>>> > I think this is what Infinity means when she says that "virtual > >>>>> > world" > >>>>> > cannot > >>>>> > be defined, because what could be perceived as being a VW is > >>>>> > highly > >>>>> > dependend > >>>>> > on the exact situation (and policies) and in certain > >>>>> > configuration that are > >>>>> > not as clear as the current situation (no interop) or the above > >>>>> > example > >>>>> > (100% > >>>>> > interop). > >>>>> > > >>>>> > > >>>>> > This is incorrect. "Virtual world" is defined by each provider of > a > >>>>> > virtual > >>>>> > world and by nobody else, and each provider knows full well how it > is > >>>>> > defined, > >>>>> > what its boundaries are, and what makes it distinct. Nobody else > can > >>>>> > define > >>>>> > what a virtual world is, and it's not our business to define it > >>>>> > either (nor to > >>>>> > conjure up a fictitious definition). > >>>>> > >>>>> Sorry, but I think you should try harder to understand my point of > view > >>>>> first. > >>>>> I didn't give the examples so you can ignore them. > >>>>> > >>>>> > We only need to define the protocol interactions at the endpoints > >>>>> > presented by > >>>>> > those worlds, and not to define "virtual world" structurally nor > any > >>>>> > other way. > >>>>> > Doing so is what has got us into this mess, by creating a > >>>>> > fictitious > >>>>> > definition based on reachability and hence blocking any ability to > >>>>> > talk about > >>>>> > actual virtual worlds. Those worlds exist. They won't go away. > >>>>> > They want to > >>>>> > interoperate, but they don't want to be told that they don't exist. > >>>>> > >>>>> I was trying to make you understand WHY Infinitely tells you they > don't > >>>>> "exist", > >>>>> if you understand her (and you don't, imho) then it will be easier to > >>>>> solve this > >>>>> miscommunication. > >>>>> > >>>>> > The contention that we don't know what "virtual world" means is > just > >>>>> > plain > >>>>> > bizarre. > >>>>> > >>>>> Only if you already have a definition of "virtual world" they way you > >>>>> do. > >>>>> > >>>>> > I don't know of any VW operator who doesn't know what their world > is. > >>>>> > >>>>> That is the *current* situation... which is 100% simpler than what > >>>>> we'll > >>>>> have in the future. > >>>>> > >>>>> Compare with math... currently we only have Integers (Z). We're about > >>>>> to introduce division and by that we need to extend the definition of > >>>>> 'number' from Z to Q. Q aren't integers, even though currently every > >>>>> number is an integer doesn't mean you have to hold on tight the > >>>>> "definition" > >>>>> of "number" == integer. That definition will be broken and you will > >>>>> have to redefine "number". > >>>>> > >>>>> > Every single one of them could provide the necessary endpoints > for > >>>>> > VWRAP > >>>>> > within their world without any scratching of heads at the meaning > of > >>>>> > "virtual > >>>>> > world". That repeated allegation has been a complete > >>>>> > misrepresentation. It's > >>>>> > just not true. > >>>>> > >>>>> You CANNOT define "virtual world" as "AD" (see above) nor as "AD + > RD" > >>>>> because > >>>>> that is too simple and only holds in the current situation. You can > >>>>> only, at most, > >>>>> if you really want, say - well, lets define it as being some RD. > >>>>> > >>>>> > And possibly even worse is the excuse that "virtual world" is not > >>>>> > being > >>>>> > defined but is being used non-normatively, while in practice using > >>>>> > the phrase " > >>>>> > the virtual world" to create a totally fictitious single virtual > >>>>> > world instead. > >>>>> > >>>>> I agree that as long as it isn't normatively defined, the term > >>>>> shouldn't be > >>>>> used in documents except in places where it can literally mean > anything > >>>>> without > >>>>> that anyone will care (like in the protocol name). > >>>>> > >>>>> > That phrase is unnecessary, it is misrepresentative of the actual > >>>>> > situation, > >>>>> > it bypasses policy controls of one world by not mentioning its AD, > it > >>>>> > prevents > >>>>> > us from mentioning virtual worlds by blocking the normal meaning of > >>>>> > the term, > >>>>> > and it provides nothing useful as a benefit in return. Unless > total > >>>>> > confusion > >>>>> > is a benefit. ;-) > >>>>> > >>>>> Sorry, but that is like saying that defining the Rational Numbers (Q) > >>>>> makes it > >>>>> impossible to talk about 'numbers', because 3/7 isn't an integer. > >>>>> What you have to do is let go of your current definition. > >>>>> > >>>>> > In one of my first posts about this topic I stated that > "virtual > >>>>> > world" > >>>>> > should > >>>>> > be considered to be the Region Domain (although I didn't use > that > >>>>> > term at > >>>>> > the > >>>>> > moment) and be completely independent of the Agent Domain, > based > >>>>> > on typical > >>>>> > cases of abuse and griefing etc: if anyone annoys some other > >>>>> > user, or > >>>>> > breaks > >>>>> > almost any ToS, it will be region based; which is why I've > always > >>>>> > said that > >>>>> > any type of abuse can and should be handled at the sim (single > >>>>> > region) > >>>>> > level: > >>>>> > the estate owner and managers in SL, even, but that idea > >>>>> > definitely extends > >>>>> > to "world administrations": the people running the REGION > >>>>> > (domain) is the > >>>>> > one > >>>>> > that should decide what is the local ToS and deal with abuse > etc. > >>>>> > That is > >>>>> > why I strongly argue to define "virtual world" as Region > Domain, > >>>>> > and leave > >>>>> > the AD out of it. Nevertheless, now I have the term "Region > >>>>> > Domain" I don't > >>>>> > need "virtual world" anymore. > >>>>> > > >>>>> > > >>>>> > But that's not how OGP is structured. It's the AD that is the > focus > >>>>> > of service > >>>>> > policy choices in OGP, and it's the "world service" that is the > focus > >>>>> > of > >>>>> > service policy in Cable Beach. The AD and the world service are > the > >>>>> > source of > >>>>> > capabilities that determine pretty much everything else, and the > >>>>> > region domain > >>>>> > is very subsidiary to that. > >>>>> > >>>>> No, if the service prodiver of some AD disagrees with the (say) a ToS > >>>>> that applies > >>>>> when you go to some RD then they should disallow you go there; they > >>>>> should not > >>>>> allow you to go there and then demand that you follow their ToS, that > >>>>> would not > >>>>> be a practical solution that is workable. > >>>>> > >>>>> To use mathematics again, it's easy to make two ToS that have no > >>>>> intersection: > >>>>> Say, ToS1 says: you MUST wear purple clothes, and ToS2 says: you MUST > >>>>> wear blue > >>>>> clothes. Obviously those will apply to regions. > >>>>> > >>>>> So then we have: > >>>>> > >>>>> Provider1: RD1 --> TOS1 --> purple clothes > >>>>> Provider2: RD2 --> TOS2 --> blue clothes > >>>>> > >>>>> *if* Provider 2 runs an AD (AD2) and they allow people logged in with > >>>>> it > >>>>> to go to region RD1 then the people there should wear purple clothes: > >>>>> TOS2 will not apply because of the AD you use. > >>>>> > >>>>> If it's against providers religious believe to support wearing purple > >>>>> clothes than they might disallow people to go to RD1, that is their > >>>>> choice (policy). > >>>>> > >>>>> > Indeed, a region domain may have no policy of its > >>>>> > own at all, but merely extend an existing virtual world by > accepting > >>>>> > the > >>>>> > policies of that world's AD. That's the model in the original OGP > >>>>> > before it > >>>>> > gained aspirations of becoming a cross-VW interop protocol. > >>>>> > >>>>> That makes no sense :/ > >>>>> > >>>>> There can be any number of people in a given RD, and each can in > >>>>> principle > >>>>> be using a different AD! PLEASE let the RD determine the rules they > >>>>> have > >>>>> to live by! Anyone else that disagrees with me about that?! > >>>>> > >>>>> > If RDs determined VW policy and generated seed capabilities for > >>>>> > everything and > >>>>> > ADs were merely login services then your model would apply, and RD > >>>>> > could be > >>>>> > considered "VW". > >>>>> > >>>>> Ah! At last.. > >>>>> > >>>>> > But that's not how it is currently structured --- RDs are > >>>>> > >>>>> If you are refering to OGP, then OGP should be changed. > >>>>> > >>>>> > merely the land + physical simulation components of worlds, and in > >>>>> > SL's case, > >>>>> > also an elaborate system of proxies. And that's why we need > multiple > >>>>> > ADs to > >>>>> > interact in VWRAP before we can consider that there is VW-VW > interop. > >>>>> > RDs > >>>>> > don't handle it. > >>>>> > >>>>> What I seem to keep missing is the fact that VWRAP is already > >>>>> completely > >>>>> defined in those previous OGP documents and we're merely here to > >>>>> rewrite > >>>>> them in an IETF document of sorts. > >>>>> > >>>>> Yes we need multiple ADs to interact, and they will. > >>>>> But yes, RD's will handle whatever they have to handle with VWRAP. > >>>>> I never said that capabilities equal 'rules' (ToS and legal > >>>>> jurisdiction > >>>>> isn't something that should be enforced or controlled by the > protocol) > >>>>> by > >>>>> the way. > >>>>> > >>>>> ... sorry my RSI forces me to stop typing here... shouldn't have > >>>>> typed this much alrady anyway :( > >>>>> > >>>>> > > In our new protocol, these services may either be implemented > >>>>> > internally > >>>>> > within > >>>>> > > a virtual world, or some might be implemented as external > >>>>> > services > >>>>> > offered by > >>>>> > > third parties, the choice being a policy and design decision > >>>>> > for each > >>>>> > world > >>>>> > > operator. In all cases however, the virtual worlds are > defined > >>>>> > by a set > >>>>> > of > >>>>> > > services, and not just by a Region Domain. > >>>>> > > >>>>> > > >>>>> > Indeed. But access to such decoupled services is provided by the > AD > >>>>> > through > >>>>> > the capabilities that it delivers to authorized parties, and > regions > >>>>> > are just > >>>>> > one such service. You're giving RDs credit for something that they > >>>>> > don't do. > >>>>> > :-) Perhaps the VWRAP model should be redesigned along your lines > so > >>>>> > that RDs > >>>>> > become the VWs and are the generators of seed caps, and then ADs > >>>>> > become just a > >>>>> > subservient policy-free login mechanism. :D > >>>>> > > >>>>> > > >>>>> > > >>>>> > I'm afraid that is purely a matter of opinion. I agree that it > is > >>>>> > likely > >>>>> > that a single 'administrative entity' that runs a RD will also > >>>>> > run an AD > >>>>> > and allow users authenticated with their AD visit their RD, but > >>>>> > it is no > >>>>> > more than *likely*. There will almost certainly be service > >>>>> > provides that > >>>>> > ONLY run an AD, and don't have a RD! And I can imagine that > there > >>>>> > will > >>>>> > be some that only run a RD and do not care about running their > >>>>> > own AD. > >>>>> > > >>>>> > > >>>>> > Oh sure, there will be all combinations of services, that is to be > >>>>> > expected. > >>>>> > But it is the seat of policy that is the heart of each virtual > world, > >>>>> > and > >>>>> > currently the seat of policy lies in the AD. A VW that doesn't > have > >>>>> > an AD in > >>>>> > the VWRAP model is just a colony without a government, ready to be > >>>>> > assimilated > >>>>> > into a world that has an AD and that therefore sets policies, > instead > >>>>> > of being > >>>>> > a sovereign world that merely wants to interop with that other > world > >>>>> > through > >>>>> > VWRAP. > >>>>> > > >>>>> > > >>>>> > > >>>>> > Therefore, "virtual world" cannot be synonym for "the set of > >>>>> > services > >>>>> > run by a single administrative entity" as you seem to argue, > and > >>>>> > at > >>>>> > the SAME time be argued to include an RD *and* AD at all times. > >>>>> > > >>>>> > > >>>>> > I don't follow that. Two worlds that can run independently (that's > >>>>> > very > >>>>> > important) can certainly each be defined as a set of services that > >>>>> > includes the > >>>>> > functions of an AD and an RD, and those worlds each continue to > >>>>> > include the > >>>>> > functions of an AD and an RD even after they start interoperating > >>>>> > (assuming > >>>>> > that VWRAP is extended to allow cross-VW interop). No world is > going > >>>>> > to give > >>>>> > up part of its services portfolio on interop. Interop is an > >>>>> > additional > >>>>> > benefit, not a loss of capability. > >>>>> > > >>>>> > [It's worth noting that there may actually be a small loss of > >>>>> > capability > >>>>> > occurring on interop in VWRAP, although it is rarely mentioned. > You > >>>>> > can be > >>>>> > present in two worlds simultaneously with the same login > credentials > >>>>> > pre-interop (a feature that we enjoy currently between SL and > OSgrid > >>>>> > for > >>>>> > example), but post-interop this may no longer be possible --- it > >>>>> > depends on the > >>>>> > implementation. No doubt we will visit this issue within VWRAP.] > >>>>> > > >>>>> > > >>>>> > > >>>>> > > This is easy to see by looking at a couple of archetypal > >>>>> > examples in this > >>>>> > > space: > >>>>> > > > >>>>> > > > >>>>> > > Is Second Life a virtual world? Undoubtedly. Is Second > >>>>> > Life just a > >>>>> > Region > >>>>> > > Domain (assuming it were implemented using VWRAP)? No, > of > >>>>> > course > >>>>> > not, SL > >>>>> > > includes all of the services mentioned above, and others. > >>>>> > > >>>>> > Of course, LL happens to run all services that are needed to > >>>>> > create one > >>>>> > virtual world; there are no third parties they can hire from > yet, > >>>>> > so they > >>>>> > have to provide it all themselves. > >>>>> > > >>>>> > But after SL implemented VWRAP they might decide to do away > from > >>>>> > one of > >>>>> > their services and only keep their RD. Unlikely, but possible. > >>>>> > > >>>>> > > >>>>> > You're confusing RD functionality with AD functionality again > there. > >>>>> > The AD is > >>>>> > the heart of a world because it defines its capabilities and > >>>>> > policies. The RD > >>>>> > is just a pile of region hosts that could easily be farmed out to a > >>>>> > third party > >>>>> > to run without them determining policy, and indeed this is already > >>>>> > being done. > >>>>> > While it is a very important pile of hosts which gives a world its > >>>>> > physical > >>>>> > characterists, the RD is a subservient service to the AD in OGP, > just > >>>>> > as the > >>>>> > equivalent "simulation nodes" provide a subservient service to the > >>>>> > "world > >>>>> > service" under Cable Beach. The RD is well named --- it provides > >>>>> > region > >>>>> > services only, not the package of internal + external services that > >>>>> > together > >>>>> > create a virtual world. > >>>>> > > >>>>> > > >>>>> > > >>>>> > > Is OSgrid a virtual world? Undoubtedly. Is OSgrid just > a > >>>>> > Region > >>>>> > Domain > >>>>> > > (assuming it were implemented using VWRAP)? No, of > course > >>>>> > not, it > >>>>> > > currently runs all the UGAIM services, which in a VWRAP > >>>>> > context would > >>>>> > > become similar to those of Second Life. > >>>>> > > >>>>> > Exact same argument. > >>>>> > > >>>>> > > >>>>> > Exact same response because the same applies. :-) What's more, in > >>>>> > OSgrid this > >>>>> > is even easier to identify, because every person or company that > adds > >>>>> > regions > >>>>> > to OSgrid is subscribing to the notion that they are participants > in > >>>>> > OSgrid --- > >>>>> > OSgrid is their virtual world. They are merely providing > additional > >>>>> > land mass > >>>>> > and simulation capacity. > >>>>> > > >>>>> > Also, in this example there is no need to hypothesize region > services > >>>>> > being > >>>>> > farmed out to third parties, as there already are hundreds to > >>>>> > thousands of > >>>>> > independent third parties involved in supplying regions. Those > >>>>> > regions and > >>>>> > clusters of regions (equivalent to RDs) together combine to create > >>>>> > the virtual > >>>>> > world of OSgrid. There is a clear distinction between R/RDs here > and > >>>>> > the VW > >>>>> > itself, which also includes a variety of other services as Charles > >>>>> > has > >>>>> > described several times. The R/RDs are a very important part, but > >>>>> > functionally > >>>>> > they are not the VW, nor are they the VW perceptually. They are > >>>>> > places within > >>>>> > the world, not the whole world. > >>>>> > > >>>>> > > >>>>> > > >>>>> > > So you see, the idea that has been floated which claims that > >>>>> > "VW == RD" > >>>>> > is > >>>>> > > completely wrong, and misrepresents what constitutes a > "virtual > >>>>> > world" > >>>>> > despite > >>>>> > > the very clear examples before us. > >>>>> > > >>>>> > If you want to put it that way (including everything above that > >>>>> > you said) > >>>>> > then > >>>>> > I have to side with Infinity: you cannot define a virtual world > >>>>> > that way > >>>>> > and > >>>>> > use it for useful discussions regarding VWRAP. > >>>>> > > >>>>> > > >>>>> > I think you may have misread that. I did not define "VW == RD". > >>>>> > That's the > >>>>> > opposite of what I said, but I agree with you on the negative > >>>>> > conclusion. If > >>>>> > one defines "VW == RD" then it becomes impossible to have a > >>>>> > meaningful > >>>>> > discussion about VWs in VWRAP. It also becomes impossible to have > a > >>>>> > meaningful > >>>>> > discussion about VWs in VWRAP if one conjures up a fictitious > meaning > >>>>> > of > >>>>> > "virtual world" based on reachability. And that's why we should > not > >>>>> > define it > >>>>> > in either of those two ways. > >>>>> > > >>>>> > The most useful and forward-looking way of defining virtual worlds > in > >>>>> > VWRAP is > >>>>> > as a collection of service endpoints, regardless of who operates > >>>>> > them. All we > >>>>> > should care about is the protocol between endpoints, and not > conjure > >>>>> > up some > >>>>> > non-existent single virtual world. > >>>>> > > >>>>> > > >>>>> > > >>>>> > In the end, one virtual world as defined by "all services > >>>>> > together to make > >>>>> > things work" will be, or can be, a mix of many RD's and many > AD's > >>>>> > with a > >>>>> > complex > >>>>> > web of trust/non-trust between them that makes the concept of > >>>>> > "virtual > >>>>> > world" > >>>>> > rather fuzzy at best. > >>>>> > > >>>>> > > >>>>> > You're right but you're not being clear about what is fuzzy. The > >>>>> > concept of " > >>>>> > single virtual world" is not only fuzzy, it is totally non-existent > >>>>> > in practice > >>>>> > (because there are many, not one) as well as impossible in theory > >>>>> > because of > >>>>> > balkanization through incompatible trust domains, as described so > >>>>> > magnificently > >>>>> > by Magnus a week or two ago. We should not go there. > >>>>> > > >>>>> > In contrast, the concept of multiple virtual worlds is crystal > clear. > >>>>> > Several > >>>>> > people here in the group operate virtual worlds, but nobody would > >>>>> > suggest that > >>>>> > they are unclear about what they operate. We've been sold a bridge > >>>>> > on that > >>>>> > "uncertainty". Multiple virtual worlds presenting VWRAP endpoints > >>>>> > are the > >>>>> > natural way of approaching interop between VWs, and you don't have > to > >>>>> > define > >>>>> > VWs structurally for that. You only have to define the endpoints > >>>>> > that VWs need > >>>>> > to present to the protocol, and avoid any notion of "single virtual > >>>>> > world". > >>>>> > > >>>>> > > >>>>> > > >>>>> > [...] > >>>>> > > As we move into analysis of the problem space, these issues > >>>>> > will be > >>>>> > > disentangled and clarified and the protocols will be defined > >>>>> > and evolve, > >>>>> > but > >>>>> > > from the current OGP perspective there is no symmetrical > >>>>> > relationship > >>>>> > possible > >>>>> > > between VWs that could be described as "peering". It is the > >>>>> > asymmetry of > >>>>> > the > >>>>> > > VW-RD relationship that has been the crux of the "no VW > >>>>> > interop" issue. > >>>>> > For > >>>>> > > symmetrical peering, the protocol would need to mention at > >>>>> > least two > >>>>> > > communicating VWs. > >>>>> > > >>>>> > You can about peering with just two RD's and one AD, or one RD > >>>>> > and two > >>>>> > AD's. > >>>>> > > >>>>> > > >>>>> > I think you're confusing RDs with VWs again --- RDs only provide > >>>>> > regions, > >>>>> > nothing else. For peering between two VWs, you would need > >>>>> > interaction between > >>>>> > their two ADs because their ADs provide their policies. If you > >>>>> > bypass a VW's > >>>>> > AD then you bypass its policies, so you're not interoping with that > >>>>> > world. And > >>>>> > I don't think we're encouraging bypassing and hence subverting a > >>>>> > world's > >>>>> > policies. > >>>>> > > >>>>> > > >>>>> > > >>>>> > > Of course the situation could change as the protocol evolves. > >>>>> > For > >>>>> > example, > >>>>> > > once or twice we have heard mention that multiple ADs could > be > >>>>> > involved > >>>>> > in some > >>>>> > > way, and it seems certain that communication services from > >>>>> > multiple VWs > >>>>> > will be > >>>>> > > merged because residents demand this. This would start to > take > >>>>> > us into > >>>>> > VW-VW > >>>>> > > interop territory. However, there is no such thing in VWRAP > >>>>> > currently, > >>>>> > and > >>>>> > > it's not in the list of deliverables to include it, and > >>>>> > therefore we > >>>>> > cannot say > >>>>> > > that VWRAP will provide VW-VW interop at all. For now. ;-) > >>>>> > > >>>>> > I can't comment on that cause I didn't see VWRAP yet, but from > >>>>> > the > >>>>> > charter and the comments on this list I'd think that full > support > >>>>> > for interop between any number of RD's and AD's is intended. > >>>>> > > >>>>> > > >>>>> > Well you've put your finger on the problem here. Everyone is > saying > >>>>> > what they > >>>>> > think is intended because the intention is not actually spelled out > >>>>> > in the > >>>>> > documents. Why cannot it be spelled out clearly that interop > between > >>>>> > multiple > >>>>> > ADs is intended? If it were, this entire discussion could be > avoided > >>>>> > because > >>>>> > it's easy and reasonable to equate ADs with VWs in practice. > >>>>> > > >>>>> > Notice however that even if the protocol were modified to be able > to > >>>>> > handle two > >>>>> > ADs at a time, use of an unadorned "the virtual world" in the > >>>>> > documents would > >>>>> > continue to raise the perennial question of "Which virtual world?". > >>>>> > After all, > >>>>> > there would be two of them being discussed. > >>>>> > > >>>>> > It's this phraseology that stems from OGP's original goal of adding > >>>>> > single > >>>>> > regions or RDs to an existing single virtual world (namely SL in > the > >>>>> > prototype) > >>>>> > that is creating such a problem. That phraseology was appropriate > >>>>> > for that > >>>>> > original goal. It is not appropriate for the goal of > interoperating > >>>>> > multiple > >>>>> > virtual worlds --- it makes it impossible to even talk about the > goal > >>>>> > sensibly, > >>>>> > because "the virtual world" in the OGP sense has no plural. > >>>>> > > >>>>> > It's unfortunate, but this whole affair is just the product of > legacy > >>>>> > wording > >>>>> > from OGP. That's never going to work in a multi-world setting > where > >>>>> > we need to > >>>>> > talk about the endpoints in different worlds. > >>>>> > > >>>>> > > >>>>> > Morgaine. > >>>>> > > >>>>> > PS. If anyone else read this far other than Carlo, you have a lot > of > >>>>> > stamina > >>>>> > and dedication. ;-) > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > ============================================== > >>>>> > > >>>>> > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood > wrote: > >>>>> > > >>>>> > On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote: > >>>>> > > The problem you see is that a virtual world is much more than > >>>>> > just a > >>>>> > Region > >>>>> > > Domain. It is a complete set of services of which the Region > >>>>> > Domain > >>>>> > service is > >>>>> > > just one. Other typical services might be those of the Agent > >>>>> > Domain > >>>>> > (which > >>>>> > > provides identification and authorization services and > possibly > >>>>> > others), > >>>>> > as > >>>>> > > well as asset and inventory services, IM and other > >>>>> > communication > >>>>> > services, and > >>>>> > > maybe several more. > >>>>> > > >>>>> > Well... that is purely semantic. It is a way to define VW, but > >>>>> > not one that > >>>>> > I've been using :/ > >>>>> > > >>>>> > For simplicity, assume that only two things are needed to > create > >>>>> > a complete > >>>>> > virtual world, like SL or OG: A Region Domain (RD) and an Agent > >>>>> > Domain > >>>>> > (AD). > >>>>> > > >>>>> > Currently, without any interop, each administrative entity (or > >>>>> > trust > >>>>> > entity) > >>>>> > will need to provide both: an RD *and* an AD, otherwise they > >>>>> > don't have a > >>>>> > functional VW. > >>>>> > > >>>>> > Your conclusion is that a VW exist of both 1 RD and 1 AD. But I > >>>>> > ask you to > >>>>> > reconsider if that conclusion is correct, because it is based > on > >>>>> > the > >>>>> > current > >>>>> > situation without any interop. Now "correct" might not be the > >>>>> > correct word > >>>>> > - heh. > >>>>> > Rather I should say: I ask you to reconsider if that definition > >>>>> > is very > >>>>> > useful. > >>>>> > > >>>>> > Lets consider the following fictive case: > >>>>> > > >>>>> > LL runs one RD and AD, called RD1 and AD1. > >>>>> > CB (Cable Beach) runs another RD and AD, called RD2 and AD2. > >>>>> > A user that authenticates with either AD1 or AD2 can travel to > >>>>> > RD1 AND RD2, > >>>>> > completely symmetrical, keeping their respective AD1- and AD2- > >>>>> > assets etc. > >>>>> > This is possible with the right policies, so for the sake of > >>>>> > looking at > >>>>> > the usefulness of the above definition of VW, assume this is > the > >>>>> > case. > >>>>> > > >>>>> > Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to be > >>>>> > another VW? > >>>>> > Or do you think it would make most sense in THIS case to speak > of > >>>>> > a single > >>>>> > VW? > >>>>> > > >>>>> > I think this is what Infinity means when she says that "virtual > >>>>> > world" > >>>>> > cannot > >>>>> > be defined, because what could be perceived as being a VW is > >>>>> > highly > >>>>> > dependend > >>>>> > on the exact situation (and policies) and in certain > >>>>> > configuration that are > >>>>> > not as clear as the current situation (no interop) or the above > >>>>> > example > >>>>> > (100% > >>>>> > interop). > >>>>> > > >>>>> > In one of my first posts about this topic I stated that > "virtual > >>>>> > world" > >>>>> > should > >>>>> > be considered to be the Region Domain (although I didn't use > that > >>>>> > term at > >>>>> > the > >>>>> > moment) and be completely independent of the Agent Domain, > based > >>>>> > on typical > >>>>> > cases of abuse and griefing etc: if anyone annoys some other > >>>>> > user, or > >>>>> > breaks > >>>>> > almost any ToS, it will be region based; which is why I've > always > >>>>> > said that > >>>>> > any type of abuse can and should be handled at the sim (single > >>>>> > region) > >>>>> > level: > >>>>> > the estate owner and managers in SL, even, but that idea > >>>>> > definitely extends > >>>>> > to "world administrations": the people running the REGION > >>>>> > (domain) is the > >>>>> > one > >>>>> > that should decide what is the local ToS and deal with abuse > etc. > >>>>> > That is > >>>>> > why I strongly argue to define "virtual world" as Region > Domain, > >>>>> > and leave > >>>>> > the AD out of it. Nevertheless, now I have the term "Region > >>>>> > Domain" I don't > >>>>> > need "virtual world" anymore. > >>>>> > > >>>>> > > In our new protocol, these services may either be implemented > >>>>> > internally > >>>>> > within > >>>>> > > a virtual world, or some might be implemented as external > >>>>> > services > >>>>> > offered by > >>>>> > > third parties, the choice being a policy and design decision > >>>>> > for each > >>>>> > world > >>>>> > > operator. In all cases however, the virtual worlds are > defined > >>>>> > by a set > >>>>> > of > >>>>> > > services, and not just by a Region Domain. > >>>>> > > >>>>> > I'm afraid that is purely a matter of opinion. I agree that it > is > >>>>> > likely > >>>>> > that a single 'administrative entity' that runs a RD will also > >>>>> > run an AD > >>>>> > and allow users authenticated with their AD visit their RD, but > >>>>> > it is no > >>>>> > more than *likely*. There will almost certainly be service > >>>>> > provides that > >>>>> > ONLY run an AD, and don't have a RD! And I can imagine that > there > >>>>> > will > >>>>> > be some that only run a RD and do not care about running their > >>>>> > own AD. > >>>>> > > >>>>> > Therefore, "virtual world" cannot be synonym for "the set of > >>>>> > services > >>>>> > run by a single administrative entity" as you seem to argue, > and > >>>>> > at > >>>>> > the SAME time be argued to include an RD *and* AD at all times. > >>>>> > > >>>>> > > This is easy to see by looking at a couple of archetypal > >>>>> > examples in this > >>>>> > > space: > >>>>> > > > >>>>> > > > >>>>> > > Is Second Life a virtual world? Undoubtedly. Is Second > >>>>> > Life just a > >>>>> > Region > >>>>> > > Domain (assuming it were implemented using VWRAP)? No, > of > >>>>> > course > >>>>> > not, SL > >>>>> > > includes all of the services mentioned above, and others. > >>>>> > > >>>>> > Of course, LL happens to run all services that are needed to > >>>>> > create one > >>>>> > virtual world; there are no third parties they can hire from > yet, > >>>>> > so they > >>>>> > have to provide it all themselves. > >>>>> > > >>>>> > But after SL implemented VWRAP they might decide to do away > from > >>>>> > one of > >>>>> > their services and only keep their RD. Unlikely, but possible. > >>>>> > > >>>>> > > Is OSgrid a virtual world? Undoubtedly. Is OSgrid just > a > >>>>> > Region > >>>>> > Domain > >>>>> > > (assuming it were implemented using VWRAP)? No, of > course > >>>>> > not, it > >>>>> > > currently runs all the UGAIM services, which in a VWRAP > >>>>> > context would > >>>>> > > become similar to those of Second Life. > >>>>> > > >>>>> > Exact same argument. > >>>>> > > >>>>> > > So you see, the idea that has been floated which claims that > >>>>> > "VW == RD" > >>>>> > is > >>>>> > > completely wrong, and misrepresents what constitutes a > "virtual > >>>>> > world" > >>>>> > despite > >>>>> > > the very clear examples before us. > >>>>> > > >>>>> > If you want to put it that way (including everything above that > >>>>> > you said) > >>>>> > then > >>>>> > I have to side with Infinity: you cannot define a virtual world > >>>>> > that way > >>>>> > and > >>>>> > use it for useful discussions regarding VWRAP. > >>>>> > > >>>>> > In the end, one virtual world as defined by "all services > >>>>> > together to make > >>>>> > things work" will be, or can be, a mix of many RD's and many > AD's > >>>>> > with a > >>>>> > complex > >>>>> > web of trust/non-trust between them that makes the concept of > >>>>> > "virtual > >>>>> > world" > >>>>> > rather fuzzy at best. > >>>>> > > >>>>> > [...] > >>>>> > > As we move into analysis of the problem space, these issues > >>>>> > will be > >>>>> > > disentangled and clarified and the protocols will be defined > >>>>> > and evolve, > >>>>> > but > >>>>> > > from the current OGP perspective there is no symmetrical > >>>>> > relationship > >>>>> > possible > >>>>> > > between VWs that could be described as "peering". It is the > >>>>> > asymmetry of > >>>>> > the > >>>>> > > VW-RD relationship that has been the crux of the "no VW > >>>>> > interop" issue. > >>>>> > For > >>>>> > > symmetrical peering, the protocol would need to mention at > >>>>> > least two > >>>>> > > communicating VWs. > >>>>> > > >>>>> > You can about peering with just two RD's and one AD, or one RD > >>>>> > and two > >>>>> > AD's. > >>>>> > > >>>>> > > Of course the situation could change as the protocol evolves. > >>>>> > For > >>>>> > example, > >>>>> > > once or twice we have heard mention that multiple ADs could > be > >>>>> > involved > >>>>> > in some > >>>>> > > way, and it seems certain that communication services from > >>>>> > multiple VWs > >>>>> > will be > >>>>> > > merged because residents demand this. This would start to > take > >>>>> > us into > >>>>> > VW-VW > >>>>> > > interop territory. However, there is no such thing in VWRAP > >>>>> > currently, > >>>>> > and > >>>>> > > it's not in the list of deliverables to include it, and > >>>>> > therefore we > >>>>> > cannot say > >>>>> > > that VWRAP will provide VW-VW interop at all. For now. ;-) > >>>>> > > >>>>> > I can't comment on that cause I didn't see VWRAP yet, but from > >>>>> > the > >>>>> > charter and the comments on this list I'd think that full > support > >>>>> > for interop between any number of RD's and AD's is intended. > >>>>> > > >>>>> > -- > >>>>> > Carlo Wood > >>>>> > > >>>>> > > >>>>> > >>>>> > _______________________________________________ > >>>>> > ogpx mailing list > >>>>> > ogpx@ietf.org > >>>>> > https://www.ietf.org/mailman/listinfo/ogpx > >>>>> > >>>>> > >>>>> -- > >>>>> Carlo Wood > >>>>> _______________________________________________ > >>>>> ogpx mailing list > >>>>> ogpx@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ogpx > >>>> > >>> > >>> > >>> _______________________________________________ > >>> ogpx mailing list > >>> ogpx@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ogpx > >>> > >> > >> > >> _______________________________________________ > >> ogpx mailing list > >> ogpx@ietf.org > >> https://www.ietf.org/mailman/listinfo/ogpx > >> > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --00504502c78eeb7ed80474e731c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 1, 2009 at 10:42 PM, Infinity Linden <infinity@lindenlab.com>= wrote:
did we read the same response?= i totally didn't get "destination
determines policy" from josh's response.

=A0
You need to go further back to find the reference to Destination Det= ermines Policy, which I wrote in my reply to Vaugh, here:=A0 http://ww= w.ietf.org/mail-archive/web/ogpx/current/msg00417.html .

Joshua then replied to that, and very clearly stated that the destinati= on RD will also determine policy.=A0 Of course, the destination RD's po= licy may be given by its world's AD, so naturally that AD will have to = be party to the protocol.

SL provides a good example.=A0 Would you want an external grid to provi= de teleports into one of your regions, consulting only its own AD and not S= L's AD?=A0 I think not.

There's total symmetry between the w= orlds here.=A0 You need to stop thinking of one world as "special"= ; and trying to grow it with regions, and start thinking of worlds as peers= .

Destination Determines Policy is the only approach that allows for tour= ism to one world simultaneously from multiple other worlds each having diff= erent policies, which is why it's so important.

Under any other = model, you either have no interop at all because the tourism is disallowed,= or else you get the perpetual state of war that Vaughn nicely mocked as &q= uot;war over purple".

This is why I'm so pleased that the profile of the RD is being rais= ed in respect of determining policy.=A0 It's a small step from there to= realizing that Destination Determines Policy is where you're actually = heading because it's needed for interop between worlds.


Morgaine.







=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

On Thu, Oct 1= , 2009 at 10:42 PM, Infinity Linden <infinity@lindenlab.com> wrote:
did we read the s= ame response? i totally didn't get "destination
determines policy" from josh's response.

and what? a single AD defines the trust policy of the RDs it connects to? h= uh?

i'm totally reading different documents than you are morgaine.

On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:
> On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell <josh@lindenlab.com> wrote:
>>
>> IMHO, it should be apparent that both AD (which is the agent/advoc= ate for
>> the user) and RD (where the user wants to be) both need to make po= licy
>> decisions.
>>
>
> Excellent, Joshua!
>
> I think we're finally approaching the road towards Destination Det= ermines
> Policy now, which is a prerequisite for real interop between virtual > worlds.=A0 This was simply not possible with the old OGP thinking in w= hich
> policy was given by a "trust domain" defined by a single AD = alone.
>
> It's a two-part problem.=A0 Naturally your source world can impose=
> restrictions on travel (a walled garden may disallow any foreign trave= l at
> all, for example), that's clear.=A0 What hasn't been clear unt= il now is that
> the destination world will have conditions which are every bit as stro= ng and
> important as the source world, and represented in the same way (eg. in= their
> AD).=A0 Both sides must be allowed equivalent representation in the pr= otocol.
>
> This is why the single-world terminology was such a barrier earlier.= =A0 It
> completely prevented us from bringing the two worlds into the discussi= on
> simultaneously, which is necessarily when both source and destination = are
> completely equivalent peer worlds.
>
> Your next step is to realize that, for two structurally identical worl= ds, if
> the seat of policy of one lies in its AD, then the seat of policy of t= he
> other also lies in its AD.=A0 Therefore your statement needs to be mod= ified to
> the following:
>
> IMHO, it should be apparent that both the AD of the source world and t= he RD
> and AD of the destination world all need to make policy decisions.
>
>
> What's true for the source world is also true for the destination = world,
> policy-wise.=A0 The destination world is not "inferior" in a= ny way.=A0 It's a
> necessary peer in the protocol.=A0 You can't exclude it from the e= quation.
>
>
> Morgaine.
>
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell <josh@lindenlab.com> wrote:
>>
>> Without diving in too deep, I believe this thread is putting up a<= br> >> two-level false dichotomy - either the RD determines policy or the= AD
>> determines policy, OR things aren't sensible w/o nil trust. If= that's a
>> mis-reading, my apologies.
>>
>> IMHO, it should be apparent that both AD (which is the agent/advoc= ate for
>> the user) and RD (where the user wants to be) both need to make po= licy
>> decisions.
>>
>> A corporate AD may restrict where users may visit (e.g.
>> agent= d.corp.example.com may say "no visiting party.example.com from work!")
>> or an AD may restrict users based on personal preferences
>> (= agentd.safesurf.example.com may say "scam.example.com is on a shared
>> blacklist of malicious sites, teleport blocked"), legal or po= litical
>> requirements (agentd.kidfriendly.example.com may say "you can= 9;t visit
>> adultgr= id.example.com"). Note that in all cases the AD is enforcing polic= y
>> as an agent of the user, just as a web browser on a local network = does
>> today. Presumably, there will exist many ADs that provide no restr= ictions
>> whatsoever, just as most Web browsers accessing the 'net via m= ost ISPs in
>> most countries today don't restrict access to Web content via = policy.
>>
>> On the flip side, the RD will also have policy. Corporate VWs may = limit
>> access to employees. Adult-centric VWs may limit access to agents = from ADs
>> that verify accounts with some well known service.
>> Real-world-region-specific RDs may require citizenship checks and = deny
>> access to citizens of some nation-states. And of course permission= s would
>> doubtless exist on a per-user basis as well as per-AD. Again - no = different
>> than access permissions today on the Web, except that instead of b= eing a
>> two-party user/service, it's three party user/AD/RD. And one h= opes that,
>> like most of the Web, content is freely visitable by all.
>>
>> On the topic of nil-trust: again, I wholeheartedly support the sta= nce that
>> the protocol should support nil trust operation. I hope that both = the
>> protocol and operations of VWRAP-based worlds allow the bulk of VW= RAP
>> traffic to occur in a nil trust environment, just like the Web doe= s today.
>> However, I *suspect* that, in practical terms, the abilities we wa= nt to
>> grant to regions by visiting them - to display our avatars, to bro= adcast
>> information about our agents, to give and receive virtual goods - = will
>> require at least a modicum of trust for most VW interaction, at le= ast on the
>> level of an SSL-style secured connection that gives users a certif= icate to
>> look at that provides some identity/trust information about the se= rvice
>> provider.
>>
>> I suspect I'm going to beat this drum a lot - "VWs are ju= st like the Web,
>> except where they're different" :)
>>
>> On Tue, Sep 29, 2009 at 5:51 PM, Morgaine <morgaine.dinova@googlemail.com>
>> wrote:
>>>
>>> Hi Vaughn! :-)
>>>
>>> Your description of our discussion is quite accurate.=A0 Howev= er, it seems
>>> to imply that I advocate in favour of the view that the AD mus= t be the seat
>>> of all policy for connected regions.=A0 I do not.=A0 I was mer= ely explaining the
>>> architecture of AD+RD pairing as it has been described to us r= epeatedly
>>> throughout the two years of our OGP-related work in the LL+IBM= sponsored
>>> Architecture Working Group within Second Life.
>>>
>>> After the emails, Carlo and I examined this issue with higher = discussion
>>> bandwidth inside SL, and it turned out that we were describing= two different
>>> things:=A0 I was explaining the AD+RD relationship in OGP, whi= le Carlo was
>>> describing RDs as they should be designed if an RD were an aut= onomous unit
>>> with its own policies, effectively a small world.=A0 If OGP we= re designed
>>> differently and less restrictively to allow that, then there w= ould have been
>>> no discussion.=A0 :-)
>>>
>>> Of course, OGP is not VWRAP, but only the seedcorn for VWRAP.= =A0 We can
>>> make VWRAP as flexible as we like, and it's easy to see it= s potential
>>> flexibility in David's deployments document.=A0 Consequent= ly, I have high
>>> hopes that all parties will be happy with the eventual outcome= . :-)
>>>
>>> You may have missed the primary reason why I do not advocate a= design in
>>> which an OGP-style AD is the seat of all power, possibly becau= se the
>>> discussion has been spread out across all of OGPX and MMOX.=A0= It's easy to
>>> summarize in one sentence though:=A0 such a design cannot unde= rpin an
>>> Internet-wide metaverse of interoperating virtual worlds becau= se it doesn't
>>> respect the key meme of virtual and non-virtual tourism:=A0 De= stination
>>> Determines Policy.
>>>
>>> This meme is so fundamental and crucial (and obvious) that OGP= 's support
>>> of the exact opposite is terminally broken, as a basis for the= hypothetical
>>> metaverse.=A0 Indeed, you yourself have referred to the proble= m in the funny
>>> "war over purple". :-)=A0 At best such a design can = support only a random
>>> scattering of VPN-like walled gardens, all isolated and incapa= ble of
>>> interoperating because they all claim the "one true polic= y".=A0 We should not
>>> go there.
>>>
>>> The most recent description of this problematic aspect of the = OGP design
>>> was posted by Magnus Zeisig in his excellent email at
>>> http://www.ietf.org/mail-archive/web/ogpx/c= urrent/msg00324.html , which I
>>> fully support.=A0 Such balkanization is not a desireable goal = when designing a
>>> VW interop protocol.
>>>
>>> So where are we now?=A0 We're at the stage of examining Da= vid's VWRAP
>>> deployment patterns to see how the protocol can support them.= =A0 And in that
>>> examination, it is likely to become clear that the old OGP mod= el of "AD
>>> determines policy" is completely non-viable for interoper= ating between
>>> VWRAP-compatible virtual worlds, except when that policy is &q= uot;nil trust" as a
>>> common denominator.
>>>
>>> Consequently, we will either decide to live with the original = OGP split
>>> and use "nil trust" as our basis for VW interop, or = else we will redesign
>>> the AD/RD relationship to place many more important policy dec= isions where
>>> they really belong, at destination.=A0 The latter seems the be= st choice to me,
>>> and of course it would make Carlo happy, and it is also the mo= del that every
>>> single existing world already operates --- when in Rome, do as= the Romans
>>> do.=A0 Only the old OGP AD/RD two-way split design is out of s= tep.=A0 Let's hope
>>> that we can correct that in VWRAP. :-))
>>>
>>>
>>> Morgaine.
>>>
>>>
>>>
>>>
>>>
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>>
>>> On Tue, Sep 29, 2009 at 9:16 PM, Vaughn Deluca <vaughn.deluca@gmail.com>
>>> wrote:
>>>>
>>>> Carlo and Morgaine have above been involved in a very inte= resting
>>>> discussion about the nature of the (or *a*) virtual world.=
>>>> Painting their positions with =A0broad strokes, Morgaine s= tresses the
>>>> primary role of the AD as the seat of policy and trust, up= to the point
>>>> where he denies the RD any role above that of a convenient= extension of the
>>>> AD, i.e. the RD as "colony without a government"= . Carlo passionately argues
>>>> for the independent role of the RD in policy issues.
>>>> I feel that both positions are valid (to some degree), and= both can be
>>>> covered by VWRAP.
>>>> Calo makes absolutely clear that having all policy in the = respective ADs
>>>> of the avatars leads to problems when several avatars meet= in one region
>>>> domain, say RD1. Avatars will be busy killing each other o= ver the right to
>>>> wear purple, and for the innocent bystanders caught in the= crossfire it will
>>>> be fully unclear were to complain. Stepping in Morgaines s= hoes, i think i
>>>> would argue that what Carlo asks for can be realised by ap= plying the policy
>>>> of a *particular* AD to RD1. The rules to deal with color = of clothes, could
>>>> be formulated in AD1 associated with RD1. In principle Car= lo could run this
>>>> domain himself, even without a single avatar in it, and in= this way get his
>>>> "government" and set any policy he wants. If two= avatars from AD2 and AD3
>>>> visit RD1, The policy in RD1 would be governed by what is = specified by AD1.
>>>> While this fully fits Morgaines view of "AD rules all= ", and also fits
>>>> Carlo call for autonomy of RD1, it feels decidedly like a = kludge, and in
>>>> this particular case it seems much more straightforward to= make RD1 more
>>>> autonomous. Yet, to keep everything within one framework, = this kludge seems
>>>> to be the logical solution... I would like to hear what ot= hers think about
>>>> this.
>>>> One other remark: the minimal example for =A0a "world= " =A0-one AD and one
>>>> RD- would be more useful when extended with one asset serv= ice AS. Explicit
>>>> mentioning of the AS will make it much easier to discuss I= P issues.
>>>> Vaughn
>>>>
>>>>
>>>> On Mon, Sep 14, 2009 at 10:44 AM, Carlo Wood <carlo@alinoe.com> wrote:
>>>>>
>>>>> On Mon, Sep 14, 2009 at 06:43:06AM +0100, Morgaine wro= te:
>>>>> > Carlo asked for detailed comments on the below, s= o here goes. :-)
>>>>> >
>>>>> >
>>>>> > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood <carlo@alinoe.com> wrote:
>>>>> >
>>>>> > =A0 =A0 On Thu, Sep 03, 2009 at 04:28:03AM +0100,= Morgaine wrote:
>>>>> > =A0 =A0 > The problem you see is that a virtua= l world is much more than
>>>>> > just a
>>>>> > =A0 =A0 Region
>>>>> > =A0 =A0 > Domain. =A0It is a complete set of s= ervices of which the Region
>>>>> > Domain
>>>>> > =A0 =A0 service is
>>>>> > =A0 =A0 > just one. =A0Other typical services = might be those of the Agent
>>>>> > Domain
>>>>> > =A0 =A0 (which
>>>>> > =A0 =A0 > provides identification and authoriz= ation services and possibly
>>>>> > others),
>>>>> > =A0 =A0 as
>>>>> > =A0 =A0 > well as asset and inventory services= , IM and other
>>>>> > communication
>>>>> > =A0 =A0 services, and
>>>>> > =A0 =A0 > maybe several more.
>>>>> >
>>>>> > =A0 =A0 Well... that is purely semantic. It is a = way to define VW, but
>>>>> > not one that
>>>>> > =A0 =A0 I've been using :/
>>>>> >
>>>>> >
>>>>> > It's a rough top-level projection of the arch= itectural model of
>>>>> > VWRAP, once the
>>>>> > various services have been decoupled in the way t= hat David Levine
>>>>> > often
>>>>> > describes to us. =A0Nothing very contentious ther= e, everyone likes a
>>>>> > services-oriented approach. :-)
>>>>> >
>>>>> >
>>>>> >
>>>>> > =A0 =A0 For simplicity, assume that only two thin= gs are needed to create
>>>>> > a complete
>>>>> > =A0 =A0 virtual world, like SL or OG: A Region Do= main (RD) and an Agent
>>>>> > Domain
>>>>> > =A0 =A0 (AD).
>>>>> >
>>>>> >
>>>>> > I am happy to consider that simple scenario as re= presentative. =A0It is
>>>>> > quite
>>>>> > reasonable to equate AD with VW because the AD is= the focus of almost
>>>>> > all the
>>>>> > policy decisions of a VWRAP-based world. =A0When = other decoupled
>>>>> > services are
>>>>> > added to this picture, it doesn't change the = fundamental architecture
>>>>> > of AD +
>>>>> > RDs, only extends it by decoupling more than just= the region service.
>>>>> > =A0So
>>>>> > that's fine with me.
>>>>>
>>>>> I totally disagree that the AD is the representative..= .and why do you
>>>>> say
>>>>> that below a sentence of me where I say "A Region= Domain (RD) and an
>>>>> Agent Domain (AD)"?
>>>>>
>>>>> This is like I say "VW =3D AD + RD", and you= go: "yes, VW =3D AD". We can't
>>>>> have a discussion like that Morgaine.
>>>>>
>>>>> > =A0 =A0 Currently, without any interop, each admi= nistrative entity (or
>>>>> > trust
>>>>> > =A0 =A0 entity)
>>>>> > =A0 =A0 will need to provide both: an RD *and* an= AD, otherwise they
>>>>> > don't have a
>>>>> > =A0 =A0 functional VW.
>>>>> >
>>>>> >
>>>>> > Correct. =A0The AD is the seat of most (but not a= ll) of the policy
>>>>> > decisions of a
>>>>>
>>>>> I even *stressed* the '*and*' here, and you do= it again.
>>>>>
>>>>> > VW, so it's very central to the existence of = a VW. =A0While it's
>>>>> > possible to
>>>>> > imagine policy-free VWs that temporarily =A0take = on the policy of any
>>>>> > other world
>>>>> > they hook up with, this is clearly a subset situa= tion. =A0All the
>>>>> > currently known
>>>>> > SL-like virtual worlds are grids of the SL kind, = with their own
>>>>> > individual
>>>>> > policies which they are not going to change on in= terop.
>>>>> >
>>>>> >
>>>>> >
>>>>> > =A0 =A0 Your conclusion is that a VW exist of bot= h 1 RD and 1 AD. But I
>>>>> > ask you to
>>>>> > =A0 =A0 reconsider if that conclusion is correct,= because it is based on
>>>>> > the
>>>>> > =A0 =A0 current
>>>>> > =A0 =A0 situation without any interop. Now "= correct" might not be the
>>>>> > correct word
>>>>> > =A0 =A0 - heh.
>>>>> > =A0 =A0 Rather I should say: I ask you to reconsi= der if that definition
>>>>> > is very
>>>>> > =A0 =A0 useful.
>>>>> >
>>>>> > =A0 =A0 Lets consider the following fictive case:=
>>>>> >
>>>>> > =A0 =A0 LL runs one RD and AD, called RD1 and AD1= .
>>>>> > =A0 =A0 CB (Cable Beach) runs another RD and AD, = called RD2 and AD2.
>>>>> > =A0 =A0 A user that authenticates with either AD1= or AD2 can travel to
>>>>> > RD1 AND RD2,
>>>>> > =A0 =A0 completely symmetrical, keeping their res= pective AD1- and AD2-
>>>>> > assets etc.
>>>>> > =A0 =A0 This is possible with the right policies,= so for the sake of
>>>>> > looking at
>>>>> > =A0 =A0 the usefulness of the above definition of= VW, assume this is the
>>>>> > case.
>>>>> >
>>>>> >
>>>>> > That's not quite right because Cable Beach is= not a world provider
>>>>> > like LL.
>>>>> > Cable Beach is perhaps best described as a "= login mediation"
>>>>> > mechanism or
>>>>>
>>>>> I might not understand what the real Cable Beach is or= wants to be, I
>>>>> was just
>>>>> trying to give an example to work with. So, again:
>>>>>
>>>>> LL runs one RD and AD, called RD1 and AD1.
>>>>> OG runs another RD and AD, called RD2 and AD2.
>>>>> A user that authenticates with either AD1 or AD2 can t= ravel to RD1 AND
>>>>> RD2,
>>>>> completely symmetrical, keeping their respective AD1- = and AD2- assets
>>>>> etc.
>>>>> This is possible with the right policies, so for the s= ake of looking at
>>>>> the usefulness of the above definition of VW, assume t= his is the case.
>>>>>
>>>>> > protocol, which provides a model for interaction = between a "world
>>>>> > service"
>>>>> > (effectively an AD), the user's client, and v= arious decoupled
>>>>> > services such as
>>>>> > simulation nodes (possibly an RD) and inventory/a= sset services.
>>>>> > =A0Let's assume
>>>>> > therefore that your "CB" above means so= mething different (another
>>>>> > world
>>>>> > provider similar to LL), and then we can proceed = with your example
>>>>> > case.
>>>>>
>>>>> Ok
>>>>>
>>>>> > =A0 =A0 Would you consider "RD1 + AD1" = one VW, and "RD2 + AD2" to be
>>>>> > another VW?
>>>>> > =A0 =A0 Or do you think it would make most sense = in THIS case to speak of
>>>>> > a single
>>>>> > =A0 =A0 VW?
>>>>> >
>>>>> >
>>>>> > They're two worlds because you defined them a= s such, as each has its
>>>>> > own AD.
>>>>> > :-) =A0But that aside, if they were set up separa= tely then they have
>>>>> > two
>>>>> > different sets of policies, two different sets of= residents, two
>>>>> > different
>>>>> > ToS's, possibly two different legal jurisdict= ions, two different
>>>>> > mechanisms for
>>>>> > abuse control and conflict resolution, and so on = and so forth. =A0If
>>>>> > they were
>>>>> > created to be worlds that can stand alone but int= eroperate when
>>>>> > desired, then
>>>>> > each of these is a diffferent world. =A0I don'= ;t see how that can be
>>>>> > disputed.
>>>>>
>>>>> As I stated in one of my first posts, it will (hopeful= ly!!!) be mainly
>>>>> the
>>>>> the *RD* and NOT the AD that all of those things are a= function of!
>>>>>
>>>>> You keep saying that it's mainly the AD that deter= mines these things,
>>>>> but
>>>>> that would be confusing and very annoying. If two peop= le meet in a
>>>>> virtual
>>>>> world, that is - if they are standing next to eachothe= r in one region
>>>>> and
>>>>> using local chat - then they should fall under the sam= e legal
>>>>> jurisdiction
>>>>> and the same ToS: it is the region that determines the= rules, not the
>>>>> AD
>>>>> that they used to login with.
>>>>>
>>>>> As example, ToS1 says: it's ok to be naked; and To= S2 says: it's a
>>>>> bannable
>>>>> offence to be naked. Do you really think that it's= even workable if the
>>>>> ToS to be applied is a function of the AD? Say you log= in using AD2, so
>>>>> ToS2 applies to you. You meet someone else that is nak= ed. You know that
>>>>> you are not allowed to and you are offended. You creat= e an abuse
>>>>> report;
>>>>> where does that report go to? To your AD administratio= n? That makes no
>>>>> sense: that naked person is using a different AD. To h= is/her AD
>>>>> administration
>>>>> then? That makes also no sense since they allow it. >>>>>
>>>>> Seriously, there is only one reasonable thing to do: t= he ToS that
>>>>> applies
>>>>> is a function of the Region Domain *only*, and if you = write an abuse
>>>>> report,
>>>>> it should go to the administration of the region that = you are in and
>>>>> not
>>>>> to your or the others AD administration. Same holds fo= r the things
>>>>> related
>>>>> to legal jurisdiction and any other 'rules' th= at applies at any given
>>>>> moment (to users). The only thing that might be a func= tion of the AD
>>>>> are
>>>>> technical policies that are automatically enforced by = VWRAP.
>>>>>
>>>>> > =A0 =A0 I think this is what Infinity means when = she says that "virtual
>>>>> > world"
>>>>> > =A0 =A0 cannot
>>>>> > =A0 =A0 be defined, because what could be perceiv= ed as being a VW is
>>>>> > highly
>>>>> > =A0 =A0 dependend
>>>>> > =A0 =A0 on the exact situation (and policies) and= in certain
>>>>> > configuration that are
>>>>> > =A0 =A0 not as clear as the current situation (no= interop) or the above
>>>>> > example
>>>>> > =A0 =A0 (100%
>>>>> > =A0 =A0 interop).
>>>>> >
>>>>> >
>>>>> > This is incorrect. =A0"Virtual world" i= s defined by each provider of a
>>>>> > virtual
>>>>> > world and by nobody else, and each provider knows= full well how it is
>>>>> > defined,
>>>>> > what its boundaries are, and what makes it distin= ct. =A0Nobody else can
>>>>> > define
>>>>> > what a virtual world is, and it's not our bus= iness to define it
>>>>> > either (nor to
>>>>> > conjure up a fictitious definition).
>>>>>
>>>>> Sorry, but I think you should try harder to understand= my point of view
>>>>> first.
>>>>> I didn't give the examples so you can ignore them.=
>>>>>
>>>>> > We only need to define the protocol interactions = at the endpoints
>>>>> > presented by
>>>>> > those worlds, and not to define "virtual wor= ld" structurally nor any
>>>>> > other way.
>>>>> > =A0 Doing so is what has got us into this mess, b= y creating a
>>>>> > fictitious
>>>>> > definition based on reachability and hence blocki= ng any ability to
>>>>> > talk about
>>>>> > actual virtual worlds. =A0Those worlds exist. =A0= They won't go away.
>>>>> > =A0They want to
>>>>> > interoperate, but they don't want to be told = that they don't exist.
>>>>>
>>>>> I was trying to make you understand WHY Infinitely tel= ls you they don't
>>>>> "exist",
>>>>> if you understand her (and you don't, imho) then i= t will be easier to
>>>>> solve this
>>>>> miscommunication.
>>>>>
>>>>> > The contention that we don't know what "= virtual world" means is just
>>>>> > plain
>>>>> > bizarre.
>>>>>
>>>>> Only if you already have a definition of "virtual= world" they way you
>>>>> do.
>>>>>
>>>>> > I don't know of any VW operator who doesn'= ;t know what their world is.
>>>>>
>>>>> That is the *current* situation... which is 100% simpl= er than what
>>>>> we'll
>>>>> have in the future.
>>>>>
>>>>> Compare with math... currently we only have Integers (= Z). We're about
>>>>> to introduce division and by that we need to extend th= e definition of
>>>>> 'number' from Z to Q. Q aren't integers, e= ven though currently every
>>>>> number is an integer doesn't mean you have to hold= on tight the
>>>>> "definition"
>>>>> of "number" =3D=3D integer. That definition = will be broken and you will
>>>>> have to redefine "number".
>>>>>
>>>>> > =A0 Every single one of them could provide the ne= cessary endpoints for
>>>>> > VWRAP
>>>>> > within their world without any scratching of head= s at the meaning of
>>>>> > "virtual
>>>>> > world". =A0That repeated allegation has been= a complete
>>>>> > misrepresentation. =A0It's
>>>>> > just not true.
>>>>>
>>>>> You CANNOT define "virtual world" as "A= D" (see above) nor as "AD + RD"
>>>>> because
>>>>> that is too simple and only holds in the current situa= tion. You can
>>>>> only, at most,
>>>>> if you really want, say - well, lets define it as bein= g some RD.
>>>>>
>>>>> > And possibly even worse is the excuse =A0that &qu= ot;virtual world" is not
>>>>> > being
>>>>> > defined but is being used non-normatively, while = in practice using
>>>>> > the phrase "
>>>>> > the virtual world" to create a totally ficti= tious single virtual
>>>>> > world instead.
>>>>>
>>>>> I agree that as long as it isn't normatively defin= ed, the term
>>>>> shouldn't be
>>>>> used in documents except in places where it can litera= lly mean anything
>>>>> without
>>>>> that anyone will care (like in the protocol name).
>>>>>
>>>>> > =A0 That phrase is unnecessary, it is misrepresen= tative of the actual
>>>>> > situation,
>>>>> > it bypasses policy controls of one world by not m= entioning its AD, it
>>>>> > prevents
>>>>> > us from mentioning virtual worlds by blocking the= normal meaning of
>>>>> > the term,
>>>>> > and it provides nothing useful as a benefit in re= turn. =A0Unless total
>>>>> > confusion
>>>>> > is a benefit. ;-)
>>>>>
>>>>> Sorry, but that is like saying that defining the Ratio= nal Numbers (Q)
>>>>> makes it
>>>>> impossible to talk about 'numbers', because 3/= 7 isn't an integer.
>>>>> What you have to do is let go of your current definiti= on.
>>>>>
>>>>> > =A0 =A0 In one of my first posts about this topic= I stated that "virtual
>>>>> > world"
>>>>> > =A0 =A0 should
>>>>> > =A0 =A0 be considered to be the Region Domain (al= though I didn't use that
>>>>> > term at
>>>>> > =A0 =A0 the
>>>>> > =A0 =A0 moment) and be completely independent of = the Agent Domain, based
>>>>> > on typical
>>>>> > =A0 =A0 cases of abuse and griefing etc: if anyon= e annoys some other
>>>>> > user, or
>>>>> > =A0 =A0 breaks
>>>>> > =A0 =A0 almost any ToS, it will be region based; = which is why I've always
>>>>> > said that
>>>>> > =A0 =A0 any type of abuse can and should be handl= ed at the sim (single
>>>>> > region)
>>>>> > =A0 =A0 level:
>>>>> > =A0 =A0 the estate owner and managers in SL, even= , but that idea
>>>>> > definitely extends
>>>>> > =A0 =A0 to "world administrations": the= people running the REGION
>>>>> > (domain) is the
>>>>> > =A0 =A0 one
>>>>> > =A0 =A0 that should decide what is the local ToS = and deal with abuse etc.
>>>>> > That is
>>>>> > =A0 =A0 why I strongly argue to define "virt= ual world" as Region Domain,
>>>>> > and leave
>>>>> > =A0 =A0 the AD out of it. Nevertheless, now I hav= e the term "Region
>>>>> > Domain" I don't
>>>>> > =A0 =A0 need "virtual world" anymore. >>>>> >
>>>>> >
>>>>> > But that's not how OGP is structured. =A0It&#= 39;s the AD that is the focus
>>>>> > of service
>>>>> > policy choices in OGP, and it's the "wor= ld service" that is the focus
>>>>> > of
>>>>> > service policy in Cable Beach. =A0The AD and the = world service are the
>>>>> > source of
>>>>> > capabilities that determine pretty much everythin= g else, and the
>>>>> > region domain
>>>>> > is very subsidiary to that.
>>>>>
>>>>> No, if the service prodiver of some AD disagrees with = the (say) a ToS
>>>>> that applies
>>>>> when you go to some RD then they should disallow you g= o there; they
>>>>> should not
>>>>> allow you to go there and then demand that you follow = their ToS, that
>>>>> would not
>>>>> be a practical solution that is workable.
>>>>>
>>>>> To use mathematics again, it's easy to make two To= S that have no
>>>>> intersection:
>>>>> Say, ToS1 says: you MUST wear purple clothes, and ToS2= says: you MUST
>>>>> wear blue
>>>>> clothes. Obviously those will apply to regions.
>>>>>
>>>>> So then we have:
>>>>>
>>>>> Provider1: RD1 --> TOS1 --> purple clothes
>>>>> Provider2: RD2 --> TOS2 --> blue clothes
>>>>>
>>>>> *if* Provider 2 runs an AD (AD2) and they allow people= logged in with
>>>>> it
>>>>> to go to region RD1 then the people there should wear = purple clothes:
>>>>> TOS2 will not apply because of the AD you use.
>>>>>
>>>>> If it's against providers religious believe to sup= port wearing purple
>>>>> clothes than they might disallow people to go to RD1, = that is their
>>>>> choice (policy).
>>>>>
>>>>> > Indeed, a region domain may have no policy of its=
>>>>> > own at all, but merely extend an existing virtual= world by accepting
>>>>> > the
>>>>> > policies of that world's AD. =A0That's th= e model in the original OGP
>>>>> > before it
>>>>> > gained aspirations of becoming a cross-VW interop= protocol.
>>>>>
>>>>> That makes no sense :/
>>>>>
>>>>> There can be any number of people in a given RD, and e= ach can in
>>>>> principle
>>>>> be using a different AD! PLEASE let the RD determine t= he rules they
>>>>> have
>>>>> to live by! Anyone else that disagrees with me about t= hat?!
>>>>>
>>>>> > If RDs determined VW policy and generated seed ca= pabilities for
>>>>> > everything and
>>>>> > ADs were merely login services then your model wo= uld apply, and RD
>>>>> > could be
>>>>> > considered "VW".
>>>>>
>>>>> Ah! At last..
>>>>>
>>>>> > But that's not how it is currently structured= --- RDs are
>>>>>
>>>>> If you are refering to OGP, then OGP should be changed= .
>>>>>
>>>>> > merely the land + physical simulation components = of worlds, and in
>>>>> > SL's case,
>>>>> > also an elaborate system of proxies. =A0And that&= #39;s why we need multiple
>>>>> > ADs to
>>>>> > interact in VWRAP before we can consider that the= re is VW-VW interop.
>>>>> > =A0RDs
>>>>> > don't handle it.
>>>>>
>>>>> What I seem to keep missing is the fact that VWRAP is = already
>>>>> completely
>>>>> defined in those previous OGP documents and we're = merely here to
>>>>> rewrite
>>>>> them in an IETF document of sorts.
>>>>>
>>>>> Yes we need multiple ADs to interact, and they will. >>>>> But yes, RD's will handle whatever they have to ha= ndle with VWRAP.
>>>>> I never said that capabilities equal 'rules' (= ToS and legal
>>>>> jurisdiction
>>>>> isn't something that should be enforced or control= led by the protocol)
>>>>> by
>>>>> the way.
>>>>>
>>>>> ... sorry my RSI forces me to stop typing here... shou= ldn't have
>>>>> typed this much alrady anyway :(
>>>>>
>>>>> > =A0 =A0 > In our new protocol, these services = may either be implemented
>>>>> > internally
>>>>> > =A0 =A0 within
>>>>> > =A0 =A0 > a virtual world, or some might be im= plemented as external
>>>>> > services
>>>>> > =A0 =A0 offered by
>>>>> > =A0 =A0 > third parties, the choice being a po= licy and design decision
>>>>> > for each
>>>>> > =A0 =A0 world
>>>>> > =A0 =A0 > operator. =A0In all cases however, t= he virtual worlds are defined
>>>>> > by a set
>>>>> > =A0 =A0 of
>>>>> > =A0 =A0 > services, and not just by a Region D= omain.
>>>>> >
>>>>> >
>>>>> > Indeed. =A0But access to such decoupled services = is provided by the AD
>>>>> > through
>>>>> > the capabilities that it delivers to authorized p= arties, and regions
>>>>> > are just
>>>>> > one such service. =A0You're giving RDs credit= for something that they
>>>>> > don't do.
>>>>> > :-) =A0Perhaps the VWRAP model should be redesign= ed along your lines so
>>>>> > that RDs
>>>>> > become the VWs and are the generators of seed cap= s, and then ADs
>>>>> > become just a
>>>>> > subservient policy-free login mechanism. :D
>>>>> >
>>>>> >
>>>>> >
>>>>> > =A0 =A0 I'm afraid that is purely a matter of= opinion. I agree that it is
>>>>> > likely
>>>>> > =A0 =A0 that a single 'administrative entity&= #39; that runs a RD will also
>>>>> > run an AD
>>>>> > =A0 =A0 and allow users authenticated with their = AD visit their RD, but
>>>>> > it is no
>>>>> > =A0 =A0 more than *likely*. There will almost cer= tainly be service
>>>>> > provides that
>>>>> > =A0 =A0 ONLY run an AD, and don't have a RD! = And I can imagine that there
>>>>> > will
>>>>> > =A0 =A0 be some that only run a RD and do not car= e about running their
>>>>> > own AD.
>>>>> >
>>>>> >
>>>>> > Oh sure, there will be all combinations of servic= es, that is to be
>>>>> > expected.
>>>>> > But it is the seat of policy that is the heart of= each virtual world,
>>>>> > and
>>>>> > currently the seat of policy lies in the AD. =A0A= VW that doesn't have
>>>>> > an AD in
>>>>> > the VWRAP model is just a colony without a govern= ment, ready to be
>>>>> > assimilated
>>>>> > into a world that has an AD and that therefore se= ts policies, instead
>>>>> > of being
>>>>> > a sovereign world that merely wants to interop wi= th that other world
>>>>> > through
>>>>> > VWRAP.
>>>>> >
>>>>> >
>>>>> >
>>>>> > =A0 =A0 Therefore, "virtual world" cann= ot be synonym for "the set of
>>>>> > services
>>>>> > =A0 =A0 run by a single administrative entity&quo= t; as you seem to argue, and
>>>>> > at
>>>>> > =A0 =A0 the SAME time be argued to include an RD = *and* AD at all times.
>>>>> >
>>>>> >
>>>>> > I don't follow that. =A0Two worlds that can r= un independently (that's
>>>>> > very
>>>>> > important) can certainly each be defined as a set= of services that
>>>>> > includes the
>>>>> > functions of an AD and an RD, and those worlds ea= ch continue to
>>>>> > include the
>>>>> > functions of an AD and an RD even after they star= t interoperating
>>>>> > (assuming
>>>>> > that VWRAP is extended to allow cross-VW interop)= . =A0No world is going
>>>>> > to give
>>>>> > up part of its services portfolio on interop. =A0= Interop is an
>>>>> > additional
>>>>> > benefit, not a loss of capability.
>>>>> >
>>>>> > [It's worth noting that there may actually be= a small loss of
>>>>> > capability
>>>>> > occurring on interop in VWRAP, although it is rar= ely mentioned. =A0You
>>>>> > can be
>>>>> > present in two worlds simultaneously with the sam= e login credentials
>>>>> > pre-interop (a feature that we enjoy currently be= tween SL and OSgrid
>>>>> > for
>>>>> > example), but post-interop this may no longer be = possible --- it
>>>>> > depends on the
>>>>> > implementation. =A0No doubt we will visit this is= sue within VWRAP.]
>>>>> >
>>>>> >
>>>>> >
>>>>> > =A0 =A0 > This is easy to see by looking at a = couple of archetypal
>>>>> > examples in this
>>>>> > =A0 =A0 > space:
>>>>> > =A0 =A0 >
>>>>> > =A0 =A0 >
>>>>> > =A0 =A0 > =A0 =A0 Is Second Life a virtual wor= ld? =A0Undoubtedly. =A0Is Second
>>>>> > Life just a
>>>>> > =A0 =A0 Region
>>>>> > =A0 =A0 > =A0 =A0 Domain (assuming it were imp= lemented using VWRAP)? =A0No, of
>>>>> > course
>>>>> > =A0 =A0 not, SL
>>>>> > =A0 =A0 > =A0 =A0 includes all of the services= mentioned above, and others.
>>>>> >
>>>>> > =A0 =A0 Of course, LL happens to run all services= that are needed to
>>>>> > create one
>>>>> > =A0 =A0 virtual world; there are no third parties= they can hire from yet,
>>>>> > so they
>>>>> > =A0 =A0 have to provide it all themselves.
>>>>> >
>>>>> > =A0 =A0 But after SL implemented VWRAP they might= decide to do away from
>>>>> > one of
>>>>> > =A0 =A0 their services and only keep their RD. Un= likely, but possible.
>>>>> >
>>>>> >
>>>>> > You're confusing RD functionality with AD fun= ctionality again there.
>>>>> > =A0The AD is
>>>>> > the heart of a world because it defines its capab= ilities and
>>>>> > policies. =A0The RD
>>>>> > is just a pile of region hosts that could easily = be farmed out to a
>>>>> > third party
>>>>> > to run without them determining policy, and indee= d this is already
>>>>> > being done.
>>>>> > While it is a very important pile of hosts which = gives a world its
>>>>> > physical
>>>>> > characterists, the RD is a subservient service to= the AD in OGP, just
>>>>> > as the
>>>>> > equivalent "simulation nodes" provide a= subservient service to the
>>>>> > "world
>>>>> > service" under Cable Beach. =A0The RD is wel= l named --- it provides
>>>>> > region
>>>>> > services only, not the package of internal + exte= rnal services that
>>>>> > together
>>>>> > create a virtual world.
>>>>> >
>>>>> >
>>>>> >
>>>>> > =A0 =A0 > =A0 =A0 Is OSgrid a virtual world? = =A0Undoubtedly. =A0Is OSgrid just a
>>>>> > Region
>>>>> > =A0 =A0 Domain
>>>>> > =A0 =A0 > =A0 =A0 (assuming it were implemente= d using VWRAP)? =A0No, of course
>>>>> > not, it
>>>>> > =A0 =A0 > =A0 =A0 currently runs all the UGAIM= services, which in a VWRAP
>>>>> > context would
>>>>> > =A0 =A0 > =A0 =A0 become similar to those of S= econd Life.
>>>>> >
>>>>> > =A0 =A0 Exact same argument.
>>>>> >
>>>>> >
>>>>> > Exact same response because the same applies. :-)= =A0 What's more, in
>>>>> > OSgrid this
>>>>> > is even easier to identify, because every person = or company that adds
>>>>> > regions
>>>>> > to OSgrid is subscribing to the notion that they = are participants in
>>>>> > OSgrid ---
>>>>> > OSgrid is their virtual world. =A0They are merely= providing additional
>>>>> > land mass
>>>>> > and simulation capacity.
>>>>> >
>>>>> > Also, in this example there is no need to hypothe= size region services
>>>>> > being
>>>>> > farmed out to third parties, as there already are= hundreds to
>>>>> > thousands of
>>>>> > independent third parties involved in supplying r= egions. =A0Those
>>>>> > regions and
>>>>> > clusters of regions (equivalent to RDs) together = combine to create
>>>>> > the virtual
>>>>> > world of OSgrid. =A0There is a clear distinction = between R/RDs here and
>>>>> > the VW
>>>>> > itself, which also includes a variety of other se= rvices as Charles
>>>>> > has
>>>>> > described several times. =A0The R/RDs are a very = important part, but
>>>>> > functionally
>>>>> > they are not the VW, nor are they the VW perceptu= ally. =A0They are
>>>>> > places within
>>>>> > the world, not the whole world.
>>>>> >
>>>>> >
>>>>> >
>>>>> > =A0 =A0 > So you see, the idea that has been f= loated which claims that
>>>>> > "VW =3D=3D RD"
>>>>> > =A0 =A0 is
>>>>> > =A0 =A0 > completely wrong, and misrepresents = what constitutes a "virtual
>>>>> > world"
>>>>> > =A0 =A0 despite
>>>>> > =A0 =A0 > the very clear examples before us. >>>>> >
>>>>> > =A0 =A0 If you want to put it that way (including= everything above that
>>>>> > you said)
>>>>> > =A0 =A0 then
>>>>> > =A0 =A0 I have to side with Infinity: you cannot = define a virtual world
>>>>> > that way
>>>>> > =A0 =A0 and
>>>>> > =A0 =A0 use it for useful discussions regarding V= WRAP.
>>>>> >
>>>>> >
>>>>> > I think you may have misread that. =A0I did not d= efine "VW =3D=3D RD".
>>>>> > =A0That's the
>>>>> > opposite of what I said, but I agree with you on = the negative
>>>>> > conclusion. =A0If
>>>>> > one defines "VW =3D=3D RD" then it beco= mes impossible to have a
>>>>> > meaningful
>>>>> > discussion about VWs in VWRAP. =A0It also becomes= impossible to have a
>>>>> > meaningful
>>>>> > discussion about VWs in VWRAP if one conjures up = a fictitious meaning
>>>>> > of
>>>>> > "virtual world" based on reachability. = =A0And that's why we should not
>>>>> > define it
>>>>> > in either of those two ways.
>>>>> >
>>>>> > The most useful and forward-looking way of defini= ng virtual worlds in
>>>>> > VWRAP is
>>>>> > as a collection of service endpoints, regardless = of who operates
>>>>> > them. =A0All we
>>>>> > should care about is the protocol between endpoin= ts, and not conjure
>>>>> > up some
>>>>> > non-existent single virtual world.
>>>>> >
>>>>> >
>>>>> >
>>>>> > =A0 =A0 In the end, one virtual world as defined = by "all services
>>>>> > together to make
>>>>> > =A0 =A0 things work" will be, or can be, a m= ix of many RD's and many AD's
>>>>> > with a
>>>>> > =A0 =A0 complex
>>>>> > =A0 =A0 web of trust/non-trust between them that = makes the concept of
>>>>> > "virtual
>>>>> > =A0 =A0 world"
>>>>> > =A0 =A0 rather fuzzy at best.
>>>>> >
>>>>> >
>>>>> > You're right but you're not being clear a= bout what is fuzzy. =A0The
>>>>> > concept of "
>>>>> > single virtual world" is not only fuzzy, it = is totally non-existent
>>>>> > in practice
>>>>> > (because there are many, not one) as well as impo= ssible in theory
>>>>> > =A0because of
>>>>> > balkanization through incompatible trust domains,= as described so
>>>>> > magnificently
>>>>> > by Magnus a week or two ago. =A0We should not go = there.
>>>>> >
>>>>> > In contrast, the concept of multiple virtual worl= ds is crystal clear.
>>>>> > =A0Several
>>>>> > people here in the group operate virtual worlds, = but nobody would
>>>>> > suggest that
>>>>> > they are unclear about what they operate. =A0We&#= 39;ve been sold a bridge
>>>>> > on that
>>>>> > "uncertainty". =A0Multiple virtual worl= ds presenting VWRAP endpoints
>>>>> > are the
>>>>> > natural way of approaching interop between VWs, a= nd you don't have to
>>>>> > define
>>>>> > VWs structurally for that. =A0You only have to de= fine the endpoints
>>>>> > that VWs need
>>>>> > to present to the protocol, and avoid any notion = of "single virtual
>>>>> > world".
>>>>> >
>>>>> >
>>>>> >
>>>>> > =A0 =A0 [...]
>>>>> > =A0 =A0 > As we move into analysis of the prob= lem space, these issues
>>>>> > will be
>>>>> > =A0 =A0 > disentangled and clarified and the p= rotocols will be defined
>>>>> > and evolve,
>>>>> > =A0 =A0 but
>>>>> > =A0 =A0 > from the current OGP perspective the= re is no symmetrical
>>>>> > relationship
>>>>> > =A0 =A0 possible
>>>>> > =A0 =A0 > between VWs that could be described = as "peering". =A0It is the
>>>>> > asymmetry of
>>>>> > =A0 =A0 the
>>>>> > =A0 =A0 > VW-RD relationship that has been the= crux of the "no VW
>>>>> > interop" issue.
>>>>> > =A0 =A0 For
>>>>> > =A0 =A0 > symmetrical peering, the protocol wo= uld need to mention at
>>>>> > least two
>>>>> > =A0 =A0 > communicating VWs.
>>>>> >
>>>>> > =A0 =A0 You can about peering with just two RD= 9;s and one AD, or one RD
>>>>> > and two
>>>>> > =A0 =A0 AD's.
>>>>> >
>>>>> >
>>>>> > I think you're confusing RDs with VWs again -= -- RDs only provide
>>>>> > regions,
>>>>> > nothing else. =A0For peering between two VWs, you= would need
>>>>> > interaction between
>>>>> > their two ADs because their ADs provide their pol= icies. =A0If you
>>>>> > bypass a VW's
>>>>> > AD then you bypass its policies, so you're no= t interoping with that
>>>>> > world. =A0And
>>>>> > I don't think we're encouraging bypassing= and hence subverting a
>>>>> > world's
>>>>> > policies.
>>>>> >
>>>>> >
>>>>> >
>>>>> > =A0 =A0 > Of course the situation could change= as the protocol evolves.
>>>>> > =A0For
>>>>> > =A0 =A0 example,
>>>>> > =A0 =A0 > once or twice we have heard mention = that multiple ADs could be
>>>>> > involved
>>>>> > =A0 =A0 in some
>>>>> > =A0 =A0 > way, and it seems certain that commu= nication services from
>>>>> > multiple VWs
>>>>> > =A0 =A0 will be
>>>>> > =A0 =A0 > merged because residents demand this= . =A0This would start to take
>>>>> > us into
>>>>> > =A0 =A0 VW-VW
>>>>> > =A0 =A0 > interop territory. =A0However, there= is no such thing in VWRAP
>>>>> > currently,
>>>>> > =A0 =A0 and
>>>>> > =A0 =A0 > it's not in the list of delivera= bles to include it, and
>>>>> > therefore we
>>>>> > =A0 =A0 cannot say
>>>>> > =A0 =A0 > that VWRAP will provide VW-VW intero= p at all. =A0For now. ;-)
>>>>> >
>>>>> > =A0 =A0 I can't comment on that cause I didn&= #39;t see VWRAP yet, but from
>>>>> > the
>>>>> > =A0 =A0 charter and the comments on this list I&#= 39;d think that full support
>>>>> > =A0 =A0 for interop between any number of RD'= s and AD's is intended.
>>>>> >
>>>>> >
>>>>> > Well you've put your finger on the problem he= re. =A0Everyone is saying
>>>>> > what they
>>>>> > think is intended because the intention is not ac= tually spelled out
>>>>> > in the
>>>>> > documents. =A0Why cannot it be spelled out clearl= y that interop between
>>>>> > multiple
>>>>> > ADs is intended? =A0If it were, this entire discu= ssion could be avoided
>>>>> > because
>>>>> > it's easy and reasonable to equate ADs with V= Ws in practice.
>>>>> >
>>>>> > Notice however that even if the protocol were mod= ified to be able to
>>>>> > handle two
>>>>> > ADs at a time, use of an unadorned "the virt= ual world" in the
>>>>> > documents would
>>>>> > continue to raise the perennial question of "= ;Which virtual world?".
>>>>> > =A0After all,
>>>>> > there would be two of them being discussed.
>>>>> >
>>>>> > It's this phraseology that stems from OGP'= ;s original goal of adding
>>>>> > single
>>>>> > regions or RDs to an existing single virtual worl= d (namely SL in the
>>>>> > prototype)
>>>>> > that is creating such a problem. =A0That phraseol= ogy was appropriate
>>>>> > for that
>>>>> > original goal. =A0It is not appropriate for the g= oal of interoperating
>>>>> > multiple
>>>>> > virtual worlds --- it makes it impossible to even= talk about the goal
>>>>> > sensibly,
>>>>> > because "the virtual world" in the OGP = sense has no plural.
>>>>> >
>>>>> > It's unfortunate, but this whole affair is ju= st the product of legacy
>>>>> > wording
>>>>> > from OGP. =A0That's never going to work in a = multi-world setting where
>>>>> > we need to
>>>>> > talk about the endpoints in different worlds.
>>>>> >
>>>>> >
>>>>> > Morgaine.
>>>>> >
>>>>> > PS. If anyone else read this far other than Carlo= , you have a lot of
>>>>> > stamina
>>>>> > and dedication. ;-)
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
>>>>> >
>>>>> > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood <carlo@alinoe.com> wrote:
>>>>> >
>>>>> > =A0 =A0 On Thu, Sep 03, 2009 at 04:28:03AM +0100,= Morgaine wrote:
>>>>> > =A0 =A0 > The problem you see is that a virtua= l world is much more than
>>>>> > just a
>>>>> > =A0 =A0 Region
>>>>> > =A0 =A0 > Domain. =A0It is a complete set of s= ervices of which the Region
>>>>> > Domain
>>>>> > =A0 =A0 service is
>>>>> > =A0 =A0 > just one. =A0Other typical services = might be those of the Agent
>>>>> > Domain
>>>>> > =A0 =A0 (which
>>>>> > =A0 =A0 > provides identification and authoriz= ation services and possibly
>>>>> > others),
>>>>> > =A0 =A0 as
>>>>> > =A0 =A0 > well as asset and inventory services= , IM and other
>>>>> > communication
>>>>> > =A0 =A0 services, and
>>>>> > =A0 =A0 > maybe several more.
>>>>> >
>>>>> > =A0 =A0 Well... that is purely semantic. It is a = way to define VW, but
>>>>> > not one that
>>>>> > =A0 =A0 I've been using :/
>>>>> >
>>>>> > =A0 =A0 For simplicity, assume that only two thin= gs are needed to create
>>>>> > a complete
>>>>> > =A0 =A0 virtual world, like SL or OG: A Region Do= main (RD) and an Agent
>>>>> > Domain
>>>>> > =A0 =A0 (AD).
>>>>> >
>>>>> > =A0 =A0 Currently, without any interop, each admi= nistrative entity (or
>>>>> > trust
>>>>> > =A0 =A0 entity)
>>>>> > =A0 =A0 will need to provide both: an RD *and* an= AD, otherwise they
>>>>> > don't have a
>>>>> > =A0 =A0 functional VW.
>>>>> >
>>>>> > =A0 =A0 Your conclusion is that a VW exist of bot= h 1 RD and 1 AD. But I
>>>>> > ask you to
>>>>> > =A0 =A0 reconsider if that conclusion is correct,= because it is based on
>>>>> > the
>>>>> > =A0 =A0 current
>>>>> > =A0 =A0 situation without any interop. Now "= correct" might not be the
>>>>> > correct word
>>>>> > =A0 =A0 - heh.
>>>>> > =A0 =A0 Rather I should say: I ask you to reconsi= der if that definition
>>>>> > is very
>>>>> > =A0 =A0 useful.
>>>>> >
>>>>> > =A0 =A0 Lets consider the following fictive case:=
>>>>> >
>>>>> > =A0 =A0 LL runs one RD and AD, called RD1 and AD1= .
>>>>> > =A0 =A0 CB (Cable Beach) runs another RD and AD, = called RD2 and AD2.
>>>>> > =A0 =A0 A user that authenticates with either AD1= or AD2 can travel to
>>>>> > RD1 AND RD2,
>>>>> > =A0 =A0 completely symmetrical, keeping their res= pective AD1- and AD2-
>>>>> > assets etc.
>>>>> > =A0 =A0 This is possible with the right policies,= so for the sake of
>>>>> > looking at
>>>>> > =A0 =A0 the usefulness of the above definition of= VW, assume this is the
>>>>> > case.
>>>>> >
>>>>> > =A0 =A0 Would you consider "RD1 + AD1" = one VW, and "RD2 + AD2" to be
>>>>> > another VW?
>>>>> > =A0 =A0 Or do you think it would make most sense = in THIS case to speak of
>>>>> > a single
>>>>> > =A0 =A0 VW?
>>>>> >
>>>>> > =A0 =A0 I think this is what Infinity means when = she says that "virtual
>>>>> > world"
>>>>> > =A0 =A0 cannot
>>>>> > =A0 =A0 be defined, because what could be perceiv= ed as being a VW is
>>>>> > highly
>>>>> > =A0 =A0 dependend
>>>>> > =A0 =A0 on the exact situation (and policies) and= in certain
>>>>> > configuration that are
>>>>> > =A0 =A0 not as clear as the current situation (no= interop) or the above
>>>>> > example
>>>>> > =A0 =A0 (100%
>>>>> > =A0 =A0 interop).
>>>>> >
>>>>> > =A0 =A0 In one of my first posts about this topic= I stated that "virtual
>>>>> > world"
>>>>> > =A0 =A0 should
>>>>> > =A0 =A0 be considered to be the Region Domain (al= though I didn't use that
>>>>> > term at
>>>>> > =A0 =A0 the
>>>>> > =A0 =A0 moment) and be completely independent of = the Agent Domain, based
>>>>> > on typical
>>>>> > =A0 =A0 cases of abuse and griefing etc: if anyon= e annoys some other
>>>>> > user, or
>>>>> > =A0 =A0 breaks
>>>>> > =A0 =A0 almost any ToS, it will be region based; = which is why I've always
>>>>> > said that
>>>>> > =A0 =A0 any type of abuse can and should be handl= ed at the sim (single
>>>>> > region)
>>>>> > =A0 =A0 level:
>>>>> > =A0 =A0 the estate owner and managers in SL, even= , but that idea
>>>>> > definitely extends
>>>>> > =A0 =A0 to "world administrations": the= people running the REGION
>>>>> > (domain) is the
>>>>> > =A0 =A0 one
>>>>> > =A0 =A0 that should decide what is the local ToS = and deal with abuse etc.
>>>>> > That is
>>>>> > =A0 =A0 why I strongly argue to define "virt= ual world" as Region Domain,
>>>>> > and leave
>>>>> > =A0 =A0 the AD out of it. Nevertheless, now I hav= e the term "Region
>>>>> > Domain" I don't
>>>>> > =A0 =A0 need "virtual world" anymore. >>>>> >
>>>>> > =A0 =A0 > In our new protocol, these services = may either be implemented
>>>>> > internally
>>>>> > =A0 =A0 within
>>>>> > =A0 =A0 > a virtual world, or some might be im= plemented as external
>>>>> > services
>>>>> > =A0 =A0 offered by
>>>>> > =A0 =A0 > third parties, the choice being a po= licy and design decision
>>>>> > for each
>>>>> > =A0 =A0 world
>>>>> > =A0 =A0 > operator. =A0In all cases however, t= he virtual worlds are defined
>>>>> > by a set
>>>>> > =A0 =A0 of
>>>>> > =A0 =A0 > services, and not just by a Region D= omain.
>>>>> >
>>>>> > =A0 =A0 I'm afraid that is purely a matter of= opinion. I agree that it is
>>>>> > likely
>>>>> > =A0 =A0 that a single 'administrative entity&= #39; that runs a RD will also
>>>>> > run an AD
>>>>> > =A0 =A0 and allow users authenticated with their = AD visit their RD, but
>>>>> > it is no
>>>>> > =A0 =A0 more than *likely*. There will almost cer= tainly be service
>>>>> > provides that
>>>>> > =A0 =A0 ONLY run an AD, and don't have a RD! = And I can imagine that there
>>>>> > will
>>>>> > =A0 =A0 be some that only run a RD and do not car= e about running their
>>>>> > own AD.
>>>>> >
>>>>> > =A0 =A0 Therefore, "virtual world" cann= ot be synonym for "the set of
>>>>> > services
>>>>> > =A0 =A0 run by a single administrative entity&quo= t; as you seem to argue, and
>>>>> > at
>>>>> > =A0 =A0 the SAME time be argued to include an RD = *and* AD at all times.
>>>>> >
>>>>> > =A0 =A0 > This is easy to see by looking at a = couple of archetypal
>>>>> > examples in this
>>>>> > =A0 =A0 > space:
>>>>> > =A0 =A0 >
>>>>> > =A0 =A0 >
>>>>> > =A0 =A0 > =A0 =A0 Is Second Life a virtual wor= ld? =A0Undoubtedly. =A0Is Second
>>>>> > Life just a
>>>>> > =A0 =A0 Region
>>>>> > =A0 =A0 > =A0 =A0 Domain (assuming it were imp= lemented using VWRAP)? =A0No, of
>>>>> > course
>>>>> > =A0 =A0 not, SL
>>>>> > =A0 =A0 > =A0 =A0 includes all of the services= mentioned above, and others.
>>>>> >
>>>>> > =A0 =A0 Of course, LL happens to run all services= that are needed to
>>>>> > create one
>>>>> > =A0 =A0 virtual world; there are no third parties= they can hire from yet,
>>>>> > so they
>>>>> > =A0 =A0 have to provide it all themselves.
>>>>> >
>>>>> > =A0 =A0 But after SL implemented VWRAP they might= decide to do away from
>>>>> > one of
>>>>> > =A0 =A0 their services and only keep their RD. Un= likely, but possible.
>>>>> >
>>>>> > =A0 =A0 > =A0 =A0 Is OSgrid a virtual world? = =A0Undoubtedly. =A0Is OSgrid just a
>>>>> > Region
>>>>> > =A0 =A0 Domain
>>>>> > =A0 =A0 > =A0 =A0 (assuming it were implemente= d using VWRAP)? =A0No, of course
>>>>> > not, it
>>>>> > =A0 =A0 > =A0 =A0 currently runs all the UGAIM= services, which in a VWRAP
>>>>> > context would
>>>>> > =A0 =A0 > =A0 =A0 become similar to those of S= econd Life.
>>>>> >
>>>>> > =A0 =A0 Exact same argument.
>>>>> >
>>>>> > =A0 =A0 > So you see, the idea that has been f= loated which claims that
>>>>> > "VW =3D=3D RD"
>>>>> > =A0 =A0 is
>>>>> > =A0 =A0 > completely wrong, and misrepresents = what constitutes a "virtual
>>>>> > world"
>>>>> > =A0 =A0 despite
>>>>> > =A0 =A0 > the very clear examples before us. >>>>> >
>>>>> > =A0 =A0 If you want to put it that way (including= everything above that
>>>>> > you said)
>>>>> > =A0 =A0 then
>>>>> > =A0 =A0 I have to side with Infinity: you cannot = define a virtual world
>>>>> > that way
>>>>> > =A0 =A0 and
>>>>> > =A0 =A0 use it for useful discussions regarding V= WRAP.
>>>>> >
>>>>> > =A0 =A0 In the end, one virtual world as defined = by "all services
>>>>> > together to make
>>>>> > =A0 =A0 things work" will be, or can be, a m= ix of many RD's and many AD's
>>>>> > with a
>>>>> > =A0 =A0 complex
>>>>> > =A0 =A0 web of trust/non-trust between them that = makes the concept of
>>>>> > "virtual
>>>>> > =A0 =A0 world"
>>>>> > =A0 =A0 rather fuzzy at best.
>>>>> >
>>>>> > =A0 =A0 [...]
>>>>> > =A0 =A0 > As we move into analysis of the prob= lem space, these issues
>>>>> > will be
>>>>> > =A0 =A0 > disentangled and clarified and the p= rotocols will be defined
>>>>> > and evolve,
>>>>> > =A0 =A0 but
>>>>> > =A0 =A0 > from the current OGP perspective the= re is no symmetrical
>>>>> > relationship
>>>>> > =A0 =A0 possible
>>>>> > =A0 =A0 > between VWs that could be described = as "peering". =A0It is the
>>>>> > asymmetry of
>>>>> > =A0 =A0 the
>>>>> > =A0 =A0 > VW-RD relationship that has been the= crux of the "no VW
>>>>> > interop" issue.
>>>>> > =A0 =A0 For
>>>>> > =A0 =A0 > symmetrical peering, the protocol wo= uld need to mention at
>>>>> > least two
>>>>> > =A0 =A0 > communicating VWs.
>>>>> >
>>>>> > =A0 =A0 You can about peering with just two RD= 9;s and one AD, or one RD
>>>>> > and two
>>>>> > =A0 =A0 AD's.
>>>>> >
>>>>> > =A0 =A0 > Of course the situation could change= as the protocol evolves.
>>>>> > =A0For
>>>>> > =A0 =A0 example,
>>>>> > =A0 =A0 > once or twice we have heard mention = that multiple ADs could be
>>>>> > involved
>>>>> > =A0 =A0 in some
>>>>> > =A0 =A0 > way, and it seems certain that commu= nication services from
>>>>> > multiple VWs
>>>>> > =A0 =A0 will be
>>>>> > =A0 =A0 > merged because residents demand this= . =A0This would start to take
>>>>> > us into
>>>>> > =A0 =A0 VW-VW
>>>>> > =A0 =A0 > interop territory. =A0However, there= is no such thing in VWRAP
>>>>> > currently,
>>>>> > =A0 =A0 and
>>>>> > =A0 =A0 > it's not in the list of delivera= bles to include it, and
>>>>> > therefore we
>>>>> > =A0 =A0 cannot say
>>>>> > =A0 =A0 > that VWRAP will provide VW-VW intero= p at all. =A0For now. ;-)
>>>>> >
>>>>> > =A0 =A0 I can't comment on that cause I didn&= #39;t see VWRAP yet, but from
>>>>> > the
>>>>> > =A0 =A0 charter and the comments on this list I&#= 39;d think that full support
>>>>> > =A0 =A0 for interop between any number of RD'= s and AD's is intended.
>>>>> >
>>>>> > =A0 =A0 --
>>>>> > =A0 =A0 Carlo Wood <carlo@alinoe.com>
>>>>> >
>>>>> >
>>>>>
>>>>> > _______________________________________________ >>>>> > ogpx mailing list
>>>>> > ogpx@ietf.org
>>>>> > https://www.ietf.org/mailman/listinfo/ogpx
>>>>>
>>>>>
>>>>> --
>>>>> Carlo Wood <car= lo@alinoe.com>
>>>>> _______________________________________________
>>>>> ogpx mailing list
>>>>> ogpx@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>>
>>>
>>>
>>> _______________________________________________
>>> ogpx mailing list
>>> ogpx@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>
>>
>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

--00504502c78eeb7ed80474e731c8-- From dwl@us.ibm.com Thu Oct 1 15:29:38 2009 Return-Path: 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 E34C93A68CD; Thu, 1 Oct 2009 15:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.793 X-Spam-Level: X-Spam-Status: No, score=-5.793 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, 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 YUY56boYdC09; Thu, 1 Oct 2009 15:29:36 -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 D0F243A67B3; Thu, 1 Oct 2009 15:29:35 -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 n91MLiPO014328; Thu, 1 Oct 2009 18:21:44 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n91MV1tM246946; Thu, 1 Oct 2009 18:31:01 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n91MV1Ds014406; Thu, 1 Oct 2009 18:31:01 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n91MV1Cn014402; Thu, 1 Oct 2009 18:31:01 -0400 In-Reply-To: <3a880e2c0910011518i4e068b55scc0baf19997f8e6f@mail.gmail.com> References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <716017.47390.qm@web82603.mail.mud.yahoo.com> <3a880e2c0910011518i4e068b55scc0baf19997f8e6f@mail.gmail.com> To: Infinity Linden MIME-Version: 1.0 X-KeepSent: 39A45D78:3DB71AF9-85257642:007B39BF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Thu, 1 Oct 2009 18:30:55 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 10/01/2009 18:31:01, Serialize complete at 10/01/2009 18:31:01 Content-Type: multipart/alternative; boundary="=_alternative 007BAEA085257642_=" Cc: ogpx@ietf.org, ogpx-bounces@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 22:29:38 -0000 This is a multipart message in MIME format. --=_alternative 007BAEA085257642_= Content-Type: text/plain; charset="US-ASCII" A stand alone region in OpenSim effectively has all the services hosted locally. The services may have not external exposure (Tho, if you run a multi-region, standalone deployment that's a fuzzy statement) The Client does auth, fetches inventory and assets and gets region services from the single executable. The regions simply talk to all those services locally. As the ROBUST stuff rolls through OpenSim, I think the distinction is likely to become even muddier. - David ~ Zha Infinity Linden Sent by: ogpx-bounces@ietf.org 10/01/2009 06:18 PM To Charles Krinke cc ogpx@ietf.org Subject Re: [ogpx] VWRAP Draft Charter - 2009 09 01 isn't an OpenSim region running in standalone mode like having all the services locally. i mean... it's beginning to sound like a petty distinction, but in order to serve up information about the user or the region or assets in the region, you have to have SOMETHING that behaves like a user server or asset server. i always looked at it as being that all these "services" were local to the machine, not that they didn't really exist. On Thu, Oct 1, 2009 at 3:13 PM, Charles Krinke wrote: > Well, no, thats not quite how OpenSim works. > > A standalone OpenSim region with no grid services is probably loosely > equivalent to no AD and I think that was the mode in which the tests were > performed with the IBM OpenSim region and OGP a year or so ago. > > An OpenSim region running in grid mode is connected to a number of servers > that connect the grid together. These are a UserServer, GridServer, > Asset/InventoryServer and MessagingServer. So these are *more or less* > equivalent to AD notions. > > Charles > > ________________________________ > From: Joshua Bell > To: ogpx@ietf.org > Sent: Thursday, October 1, 2009 2:57:23 PM > Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 > > > On Thu, Oct 1, 2009 at 2:34 PM, Morgaine > wrote: >> >> Your next step is to realize that, for two structurally identical worlds, >> if the seat of policy of one lies in its AD, then the seat of policy of the >> other also lies in its AD. Therefore your statement needs to be modified to >> the following: >> >> IMHO, it should be apparent that both the AD of the source world and the >> RD and AD of the destination world all need to make policy decisions. >> > > I don't agree with this at all. > > A VW service provider could operate a region domain with no agent domain. I > believe this is VERY LOOSELY equivalent to running an OpenSim instance in > Grid mode today (but I can't state that definitively) the person running the > sim is basically running just the region, and relying on someone else's > agent domain (agent-centric services). > > Similarly, BigGiantCo could operate an agent domain for their employs (as a > bolt-on to their enterprise LDAP server, say) with no region domain. > > A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to > place the agent in a region. There aren't necessarily any other RDs or ADs > involved at all. This is where protocol and policy come into play - the AD > needs to communicate with and trust the RD and vice versa (even if that's > nil-trust). > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 007BAEA085257642_= Content-Type: text/html; charset="US-ASCII"
A stand alone region in OpenSim effectively has all the services hosted locally. The services may have not external exposure (Tho, if you run a multi-region, standalone deployment that's a fuzzy statement)  The Client does auth, fetches inventory and assets and gets region services from the single executable. The regions simply talk to all those services locally.  As the ROBUST stuff rolls through OpenSim, I think the distinction is likely to become even muddier.

- David
~ Zha



Infinity Linden <infinity@lindenlab.com>
Sent by: ogpx-bounces@ietf.org

10/01/2009 06:18 PM

To
Charles Krinke <cfk@pacbell.net>
cc
ogpx@ietf.org
Subject
Re: [ogpx] VWRAP Draft Charter - 2009 09 01





isn't an OpenSim region running in standalone mode like having all the
services locally. i mean... it's beginning to sound like a petty
distinction, but in order to serve up information about the user or
the region or assets in the region, you have to have SOMETHING that
behaves like a user server or asset server. i always looked at it as
being that all these "services" were local to the machine, not that
they didn't really exist.

On Thu, Oct 1, 2009 at 3:13 PM, Charles Krinke <cfk@pacbell.net> wrote:
> Well, no, thats not quite how OpenSim works.
>
> A standalone OpenSim region with no grid services is probably loosely
> equivalent to no AD and I think that was the mode in which the tests were
> performed with the IBM OpenSim region and OGP a year or so ago.
>
> An OpenSim region running in grid mode is connected to a number of servers
> that connect the grid together. These are a UserServer, GridServer,
> Asset/InventoryServer and MessagingServer. So these are *more or less*
> equivalent to AD notions.
>
> Charles
>
> ________________________________
> From: Joshua Bell <josh@lindenlab.com>
> To: ogpx@ietf.org
> Sent: Thursday, October 1, 2009 2:57:23 PM
> Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01
>
>
> On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com>
> wrote:
>>
>> Your next step is to realize that, for two structurally identical worlds,
>> if the seat of policy of one lies in its AD, then the seat of policy of the
>> other also lies in its AD.  Therefore your statement needs to be modified to
>> the following:
>>
>> IMHO, it should be apparent that both the AD of the source world and the
>> RD and AD of the destination world all need to make policy decisions.
>>
>
> I don't agree with this at all.
>
> A VW service provider could operate a region domain with no agent domain. I
> believe this is VERY LOOSELY equivalent to running an OpenSim instance in
> Grid mode today (but I can't state that definitively) the person running the
> sim is basically running just the region, and relying on someone else's
> agent domain (agent-centric services).
>
> Similarly, BigGiantCo could operate an agent domain for their employs (as a
> bolt-on to their enterprise LDAP server, say) with no region domain.
>
> A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to
> place the agent in a region. There aren't necessarily any other RDs or ADs
> involved at all. This is where protocol and policy come into play - the AD
> needs to communicate with and trust the RD and vice versa (even if that's
> nil-trust).
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 007BAEA085257642_=-- From cfk@pacbell.net Thu Oct 1 15:31:26 2009 Return-Path: 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 43F433A67EC for ; Thu, 1 Oct 2009 15:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=1.725, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Sb9+GnkV3Gqq for ; Thu, 1 Oct 2009 15:31:24 -0700 (PDT) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id 6FACD3A679F for ; Thu, 1 Oct 2009 15:31:24 -0700 (PDT) Received: (qmail 24386 invoked by uid 60001); 1 Oct 2009 22:32:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Hw+wGL3Vk7oOVtRFu5FW6Tl4jkqFtGWb/5hVwGZsxjdf01DpxgoDhaKn8U+Cd8e6fLvK3ZLgLYQMKzVRERpDC9shOnMTAUA+UtXMU2ZG4IYh7JQ0VJ5Sy8JrXjdU6FiWUSXKeXeejjCIpvtP6wBMKimk+Q7D0zoSmPB/512IS4Y=; Message-ID: <769711.21421.qm@web82605.mail.mud.yahoo.com> X-YMail-OSG: u.Cs52UVM1mHy5nXnk.AOS.drWsDDopDRmm4lSJNboHBBe5WqLd3Ku1tuaqcLE90u2M4ggHlb4lLtDDc2l_nCE.ztmRLjOM_KpUvrlBtysQyASANMDnJv6YBncNTarHg2Wby5cvIYB59Wa1EWWs1fWZhATx0UKVLMYjEjPQvHrJz.PzpM312CiX5GHbgwMz_V0c4E4Nlb2vS9Qa6ncUiG_V0w2tJ8mSBCCvWQY3Cx1OHODaRG9e2jn52DvU6G9RmSJNOH0RC8jw8j71hM9UMa7A1rsOUSnEQ9sok3xPpfFG3_gTThHwoOOVkPx3uHyhnb3QUu2sh_lij2rpRLgNY9D00iUi2itPXz4zWZM5DD8OPbIoYDvSUAzPQJl9IVGSeT.yu14ueqg1dsvh0qOlxDxoBpcQ6aNb9RpLfU822 Received: from [75.212.124.14] by web82605.mail.mud.yahoo.com via HTTP; Thu, 01 Oct 2009 15:32:50 PDT X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.3 References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <716017.47390.qm@web82603.mail.mud.yahoo.com> <3a880e2c0910011518i4e068b55scc0baf19997f8e6f@mail.gmail.com> Date: Thu, 1 Oct 2009 15:32:50 -0700 (PDT) From: Charles Krinke To: Infinity Linden In-Reply-To: <3a880e2c0910011518i4e068b55scc0baf19997f8e6f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-5158224-1254436370=:21421" Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 22:31:26 -0000 --0-5158224-1254436370=:21421 Content-Type: text/plain; charset=us-ascii Yes, certainly, Infinity. In standalone mode, those services to exist and are somewhat simplified, but indeed you are correct. And perhaps this discussion might be a bit premature in that OpenSim doesnt have anything named RD or AD, but we do have something *more or less* functionally equivalent. I think it is fair to say that as this group works through the details that there are those that will wish to 'harmonize' as much as practical modules in OpenSim to provide the services this group is working on. Or at the very least, to provide additional modules consistent with this group as the UGRM, Robust and other gridServer notions continue to evolve in their own directions. Charles ________________________________ From: Infinity Linden To: Charles Krinke Cc: Joshua Bell ; ogpx@ietf.org Sent: Thursday, October 1, 2009 3:18:02 PM Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 isn't an OpenSim region running in standalone mode like having all the services locally. i mean... it's beginning to sound like a petty distinction, but in order to serve up information about the user or the region or assets in the region, you have to have SOMETHING that behaves like a user server or asset server. i always looked at it as being that all these "services" were local to the machine, not that they didn't really exist. On Thu, Oct 1, 2009 at 3:13 PM, Charles Krinke wrote: > Well, no, thats not quite how OpenSim works. > > A standalone OpenSim region with no grid services is probably loosely > equivalent to no AD and I think that was the mode in which the tests were > performed with the IBM OpenSim region and OGP a year or so ago. > > An OpenSim region running in grid mode is connected to a number of servers > that connect the grid together. These are a UserServer, GridServer, > Asset/InventoryServer and MessagingServer. So these are *more or less* > equivalent to AD notions. > > Charles > > ________________________________ > From: Joshua Bell > To: ogpx@ietf.org > Sent: Thursday, October 1, 2009 2:57:23 PM > Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 > > > On Thu, Oct 1, 2009 at 2:34 PM, Morgaine > wrote: >> >> Your next step is to realize that, for two structurally identical worlds, >> if the seat of policy of one lies in its AD, then the seat of policy of the >> other also lies in its AD. Therefore your statement needs to be modified to >> the following: >> >> IMHO, it should be apparent that both the AD of the source world and the >> RD and AD of the destination world all need to make policy decisions. >> > > I don't agree with this at all. > > A VW service provider could operate a region domain with no agent domain. I > believe this is VERY LOOSELY equivalent to running an OpenSim instance in > Grid mode today (but I can't state that definitively) the person running the > sim is basically running just the region, and relying on someone else's > agent domain (agent-centric services). > > Similarly, BigGiantCo could operate an agent domain for their employs (as a > bolt-on to their enterprise LDAP server, say) with no region domain. > > A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to > place the agent in a region. There aren't necessarily any other RDs or ADs > involved at all. This is where protocol and policy come into play - the AD > needs to communicate with and trust the RD and vice versa (even if that's > nil-trust). > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0-5158224-1254436370=:21421 Content-Type: text/html; charset=us-ascii

Yes, certainly, Infinity.

In standalone mode, those services to exist and are somewhat simplified, but indeed you are correct.

And perhaps this discussion might be a bit premature in that OpenSim doesnt have anything named RD or AD, but we do have something *more or less* functionally equivalent.

I think it is fair to say that as this group works through the details that there are those that will wish to 'harmonize' as much as practical modules in OpenSim to provide the services this group is working on.

Or at the very least, to provide additional modules consistent with this group as the UGRM, Robust and other gridServer notions continue to evolve in their own directions.

Charles

From: Infinity Linden <infinity@lindenlab.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: Joshua Bell <josh@lindenlab.com>; ogpx@ietf.org
Sent: Thursday, October 1, 2009 3:18:02 PM
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

isn't an OpenSim region running in standalone mode like having all the
services locally. i mean... it's beginning to sound like a petty
distinction, but in order to serve up information about the user or
the region or assets in the region, you have to have SOMETHING that
behaves like a user server or asset server. i always looked at it as
being that all these "services" were local to the machine, not that
they didn't really exist.

On Thu, Oct 1, 2009 at 3:13 PM, Charles Krinke <cfk@pacbell.net> wrote:
> Well, no, thats not quite how OpenSim works.
>
> A standalone OpenSim region with no grid services is probably loosely
> equivalent to no AD and I think that was the mode in which the tests were
> performed with the IBM OpenSim region and OGP a year or so ago.
>
> An OpenSim region running in grid mode is connected to a number of servers
> that connect the grid together. These are a UserServer, GridServer,
> Asset/InventoryServer and MessagingServer. So these are *more or less*
> equivalent to AD notions.
>
> Charles
>
> ________________________________
> From: Joshua Bell <josh@lindenlab.com>
> To: ogpx@ietf.org
> Sent: Thursday, October 1, 2009 2:57:23 PM
> Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01
>
>
> On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com>
> wrote:
>>
>> Your next step is to realize that, for two structurally identical worlds,
>> if the seat of policy of one lies in its AD, then the seat of policy of the
>> other also lies in its AD.  Therefore your statement needs to be modified to
>> the following:
>>
>> IMHO, it should be apparent that both the AD of the source world and the
>> RD and AD of the destination world all need to make policy decisions.
>>
>
> I don't agree with this at all.
>
> A VW service provider could operate a region domain with no agent domain. I
> believe this is VERY LOOSELY equivalent to running an OpenSim instance in
> Grid mode today (but I can't state that definitively) the person running the
> sim is basically running just the region, and relying on someone else's
> agent domain (agent-centric services).
>
> Similarly, BigGiantCo could operate an agent domain for their employs (as a
> bolt-on to their enterprise LDAP server, say) with no region domain.
>
> A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to
> place the agent in a region. There aren't necessarily any other RDs or ADs
> involved at all. This is where protocol and policy come into play - the AD
> needs to communicate with and trust the RD and vice versa (even if that's
> nil-trust).
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
--0-5158224-1254436370=:21421-- From infinity@lindenlab.com Thu Oct 1 15:32:41 2009 Return-Path: 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 AFDA528C0FB for ; Thu, 1 Oct 2009 15:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.406 X-Spam-Level: X-Spam-Status: No, score=-0.406 tagged_above=-999 required=5 tests=[AWL=-1.295, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, SARE_FWDLOOK=1.666] 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 dh-aLjH5DxyC for ; Thu, 1 Oct 2009 15:32:36 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 5FB5A3A67EC for ; Thu, 1 Oct 2009 15:32:36 -0700 (PDT) Received: by pxi6 with SMTP id 6so701892pxi.32 for ; Thu, 01 Oct 2009 15:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.162.7 with SMTP id k7mr718359rve.192.1254436438649; Thu, 01 Oct 2009 15:33:58 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <3a880e2c0910011442q5b35bf8epfad7cea37eb5d5d1@mail.gmail.com> Date: Thu, 1 Oct 2009 15:33:58 -0700 Message-ID: <3a880e2c0910011533q38cbd3b2wadf1def2e3058be6@mail.gmail.com> From: Infinity Linden To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 22:32:41 -0000 "RD also determines policy" means that BOTH the RD and the AD determine policy. this is distinct from "destination RD determines policy." On Thu, Oct 1, 2009 at 3:30 PM, Morgaine w= rote: > On Thu, Oct 1, 2009 at 10:42 PM, Infinity Linden > wrote: > did we read the same response? i totally didn't get "destination > determines policy" from josh's response. > > > You need to go further back to find the reference to Destination Determin= es > Policy, which I wrote in my reply to Vaugh, here: > http://www.ietf.org/mail-archive/web/ogpx/current/msg00417.html . > > Joshua then replied to that, and very clearly stated that the destination= RD > will also determine policy.=A0 Of course, the destination RD's policy may= be > given by its world's AD, so naturally that AD will have to be party to th= e > protocol. > > SL provides a good example.=A0 Would you want an external grid to provide > teleports into one of your regions, consulting only its own AD and not SL= 's > AD?=A0 I think not. > > There's total symmetry between the worlds here.=A0 You need to stop think= ing > of one world as "special" and trying to grow it with regions, and start > thinking of worlds as peers. > > Destination Determines Policy is the only approach that allows for touris= m > to one world simultaneously from multiple other worlds each having differ= ent > policies, which is why it's so important. > > Under any other model, you either have no interop at all because the tour= ism > is disallowed, or else you get the perpetual state of war that Vaughn nic= ely > mocked as "war over purple". > > This is why I'm so pleased that the profile of the RD is being raised in > respect of determining policy.=A0 It's a small step from there to realizi= ng > that Destination Determines Policy is where you're actually heading becau= se > it's needed for interop between worlds. > > > Morgaine. > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Thu, Oct 1, 2009 at 10:42 PM, Infinity Linden > wrote: >> >> did we read the same response? i totally didn't get "destination >> determines policy" from josh's response. >> >> and what? a single AD defines the trust policy of the RDs it connects to= ? >> huh? >> >> i'm totally reading different documents than you are morgaine. >> >> On Thu, Oct 1, 2009 at 2:34 PM, Morgaine >> wrote: >> > On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell wrot= e: >> >> >> >> IMHO, it should be apparent that both AD (which is the agent/advocate >> >> for >> >> the user) and RD (where the user wants to be) both need to make polic= y >> >> decisions. >> >> >> > >> > Excellent, Joshua! >> > >> > I think we're finally approaching the road towards Destination >> > Determines >> > Policy now, which is a prerequisite for real interop between virtual >> > worlds.=A0 This was simply not possible with the old OGP thinking in w= hich >> > policy was given by a "trust domain" defined by a single AD alone. >> > >> > It's a two-part problem.=A0 Naturally your source world can impose >> > restrictions on travel (a walled garden may disallow any foreign trave= l >> > at >> > all, for example), that's clear.=A0 What hasn't been clear until now i= s >> > that >> > the destination world will have conditions which are every bit as stro= ng >> > and >> > important as the source world, and represented in the same way (eg. in >> > their >> > AD).=A0 Both sides must be allowed equivalent representation in the >> > protocol. >> > >> > This is why the single-world terminology was such a barrier earlier.= =A0 It >> > completely prevented us from bringing the two worlds into the discussi= on >> > simultaneously, which is necessarily when both source and destination >> > are >> > completely equivalent peer worlds. >> > >> > Your next step is to realize that, for two structurally identical >> > worlds, if >> > the seat of policy of one lies in its AD, then the seat of policy of t= he >> > other also lies in its AD.=A0 Therefore your statement needs to be >> > modified to >> > the following: >> > >> > IMHO, it should be apparent that both the AD of the source world and t= he >> > RD >> > and AD of the destination world all need to make policy decisions. >> > >> > >> > What's true for the source world is also true for the destination worl= d, >> > policy-wise.=A0 The destination world is not "inferior" in any way.=A0= It's >> > a >> > necessary peer in the protocol.=A0 You can't exclude it from the equat= ion. >> > >> > >> > Morgaine. >> > >> > >> > >> > >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell wrot= e: >> >> >> >> Without diving in too deep, I believe this thread is putting up a >> >> two-level false dichotomy - either the RD determines policy or the AD >> >> determines policy, OR things aren't sensible w/o nil trust. If that's= a >> >> mis-reading, my apologies. >> >> >> >> IMHO, it should be apparent that both AD (which is the agent/advocate >> >> for >> >> the user) and RD (where the user wants to be) both need to make polic= y >> >> decisions. >> >> >> >> A corporate AD may restrict where users may visit (e.g. >> >> agentd.corp.example.com may say "no visiting party.example.com from >> >> work!") >> >> or an AD may restrict users based on personal preferences >> >> (agentd.safesurf.example.com may say "scam.example.com is on a shared >> >> blacklist of malicious sites, teleport blocked"), legal or political >> >> requirements (agentd.kidfriendly.example.com may say "you can't visit >> >> adultgrid.example.com"). Note that in all cases the AD is enforcing >> >> policy >> >> as an agent of the user, just as a web browser on a local network doe= s >> >> today. Presumably, there will exist many ADs that provide no >> >> restrictions >> >> whatsoever, just as most Web browsers accessing the 'net via most ISP= s >> >> in >> >> most countries today don't restrict access to Web content via policy. >> >> >> >> On the flip side, the RD will also have policy. Corporate VWs may lim= it >> >> access to employees. Adult-centric VWs may limit access to agents fro= m >> >> ADs >> >> that verify accounts with some well known service. >> >> Real-world-region-specific RDs may require citizenship checks and den= y >> >> access to citizens of some nation-states. And of course permissions >> >> would >> >> doubtless exist on a per-user basis as well as per-AD. Again - no >> >> different >> >> than access permissions today on the Web, except that instead of bein= g >> >> a >> >> two-party user/service, it's three party user/AD/RD. And one hopes >> >> that, >> >> like most of the Web, content is freely visitable by all. >> >> >> >> On the topic of nil-trust: again, I wholeheartedly support the stance >> >> that >> >> the protocol should support nil trust operation. I hope that both the >> >> protocol and operations of VWRAP-based worlds allow the bulk of VWRAP >> >> traffic to occur in a nil trust environment, just like the Web does >> >> today. >> >> However, I *suspect* that, in practical terms, the abilities we want = to >> >> grant to regions by visiting them - to display our avatars, to >> >> broadcast >> >> information about our agents, to give and receive virtual goods - wil= l >> >> require at least a modicum of trust for most VW interaction, at least >> >> on the >> >> level of an SSL-style secured connection that gives users a certifica= te >> >> to >> >> look at that provides some identity/trust information about the servi= ce >> >> provider. >> >> >> >> I suspect I'm going to beat this drum a lot - "VWs are just like the >> >> Web, >> >> except where they're different" :) >> >> >> >> On Tue, Sep 29, 2009 at 5:51 PM, Morgaine >> >> >> >> wrote: >> >>> >> >>> Hi Vaughn! :-) >> >>> >> >>> Your description of our discussion is quite accurate.=A0 However, it >> >>> seems >> >>> to imply that I advocate in favour of the view that the AD must be t= he >> >>> seat >> >>> of all policy for connected regions.=A0 I do not.=A0 I was merely >> >>> explaining the >> >>> architecture of AD+RD pairing as it has been described to us >> >>> repeatedly >> >>> throughout the two years of our OGP-related work in the LL+IBM >> >>> sponsored >> >>> Architecture Working Group within Second Life. >> >>> >> >>> After the emails, Carlo and I examined this issue with higher >> >>> discussion >> >>> bandwidth inside SL, and it turned out that we were describing two >> >>> different >> >>> things:=A0 I was explaining the AD+RD relationship in OGP, while Car= lo >> >>> was >> >>> describing RDs as they should be designed if an RD were an autonomou= s >> >>> unit >> >>> with its own policies, effectively a small world.=A0 If OGP were >> >>> designed >> >>> differently and less restrictively to allow that, then there would >> >>> have been >> >>> no discussion.=A0 :-) >> >>> >> >>> Of course, OGP is not VWRAP, but only the seedcorn for VWRAP.=A0 We = can >> >>> make VWRAP as flexible as we like, and it's easy to see its potentia= l >> >>> flexibility in David's deployments document.=A0 Consequently, I have >> >>> high >> >>> hopes that all parties will be happy with the eventual outcome. :-) >> >>> >> >>> You may have missed the primary reason why I do not advocate a desig= n >> >>> in >> >>> which an OGP-style AD is the seat of all power, possibly because the >> >>> discussion has been spread out across all of OGPX and MMOX.=A0 It's = easy >> >>> to >> >>> summarize in one sentence though:=A0 such a design cannot underpin a= n >> >>> Internet-wide metaverse of interoperating virtual worlds because it >> >>> doesn't >> >>> respect the key meme of virtual and non-virtual tourism:=A0 Destinat= ion >> >>> Determines Policy. >> >>> >> >>> This meme is so fundamental and crucial (and obvious) that OGP's >> >>> support >> >>> of the exact opposite is terminally broken, as a basis for the >> >>> hypothetical >> >>> metaverse.=A0 Indeed, you yourself have referred to the problem in t= he >> >>> funny >> >>> "war over purple". :-)=A0 At best such a design can support only a >> >>> random >> >>> scattering of VPN-like walled gardens, all isolated and incapable of >> >>> interoperating because they all claim the "one true policy".=A0 We >> >>> should not >> >>> go there. >> >>> >> >>> The most recent description of this problematic aspect of the OGP >> >>> design >> >>> was posted by Magnus Zeisig in his excellent email at >> >>> http://www.ietf.org/mail-archive/web/ogpx/current/msg00324.html , >> >>> which I >> >>> fully support.=A0 Such balkanization is not a desireable goal when >> >>> designing a >> >>> VW interop protocol. >> >>> >> >>> So where are we now?=A0 We're at the stage of examining David's VWRA= P >> >>> deployment patterns to see how the protocol can support them.=A0 And= in >> >>> that >> >>> examination, it is likely to become clear that the old OGP model of >> >>> "AD >> >>> determines policy" is completely non-viable for interoperating betwe= en >> >>> VWRAP-compatible virtual worlds, except when that policy is "nil >> >>> trust" as a >> >>> common denominator. >> >>> >> >>> Consequently, we will either decide to live with the original OGP >> >>> split >> >>> and use "nil trust" as our basis for VW interop, or else we will >> >>> redesign >> >>> the AD/RD relationship to place many more important policy decisions >> >>> where >> >>> they really belong, at destination.=A0 The latter seems the best cho= ice >> >>> to me, >> >>> and of course it would make Carlo happy, and it is also the model th= at >> >>> every >> >>> single existing world already operates --- when in Rome, do as the >> >>> Romans >> >>> do.=A0 Only the old OGP AD/RD two-way split design is out of step. >> >>> Let's hope >> >>> that we can correct that in VWRAP. :-)) >> >>> >> >>> >> >>> Morgaine. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>> >> >>> >> >>> On Tue, Sep 29, 2009 at 9:16 PM, Vaughn Deluca >> >>> >> >>> wrote: >> >>>> >> >>>> Carlo and Morgaine have above been involved in a very interesting >> >>>> discussion about the nature of the (or *a*) virtual world. >> >>>> Painting their positions with =A0broad strokes, Morgaine stresses t= he >> >>>> primary role of the AD as the seat of policy and trust, up to the >> >>>> point >> >>>> where he denies the RD any role above that of a convenient extensio= n >> >>>> of the >> >>>> AD, i.e. the RD as "colony without a government". Carlo passionatel= y >> >>>> argues >> >>>> for the independent role of the RD in policy issues. >> >>>> I feel that both positions are valid (to some degree), and both can >> >>>> be >> >>>> covered by VWRAP. >> >>>> Calo makes absolutely clear that having all policy in the respectiv= e >> >>>> ADs >> >>>> of the avatars leads to problems when several avatars meet in one >> >>>> region >> >>>> domain, say RD1. Avatars will be busy killing each other over the >> >>>> right to >> >>>> wear purple, and for the innocent bystanders caught in the crossfir= e >> >>>> it will >> >>>> be fully unclear were to complain. Stepping in Morgaines shoes, i >> >>>> think i >> >>>> would argue that what Carlo asks for can be realised by applying th= e >> >>>> policy >> >>>> of a *particular* AD to RD1. The rules to deal with color of clothe= s, >> >>>> could >> >>>> be formulated in AD1 associated with RD1. In principle Carlo could >> >>>> run this >> >>>> domain himself, even without a single avatar in it, and in this way >> >>>> get his >> >>>> "government" and set any policy he wants. If two avatars from AD2 a= nd >> >>>> AD3 >> >>>> visit RD1, The policy in RD1 would be governed by what is specified >> >>>> by AD1. >> >>>> While this fully fits Morgaines view of "AD rules all", and also fi= ts >> >>>> Carlo call for autonomy of RD1, it feels decidedly like a kludge, a= nd >> >>>> in >> >>>> this particular case it seems much more straightforward to make RD1 >> >>>> more >> >>>> autonomous. Yet, to keep everything within one framework, this klud= ge >> >>>> seems >> >>>> to be the logical solution... I would like to hear what others thin= k >> >>>> about >> >>>> this. >> >>>> One other remark: the minimal example for =A0a "world" =A0-one AD a= nd one >> >>>> RD- would be more useful when extended with one asset service AS. >> >>>> Explicit >> >>>> mentioning of the AS will make it much easier to discuss IP issues. >> >>>> Vaughn >> >>>> >> >>>> >> >>>> On Mon, Sep 14, 2009 at 10:44 AM, Carlo Wood >> >>>> wrote: >> >>>>> >> >>>>> On Mon, Sep 14, 2009 at 06:43:06AM +0100, Morgaine wrote: >> >>>>> > Carlo asked for detailed comments on the below, so here goes. :-= ) >> >>>>> > >> >>>>> > >> >>>>> > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood >> >>>>> > wrote: >> >>>>> > >> >>>>> > =A0 =A0 On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote= : >> >>>>> > =A0 =A0 > The problem you see is that a virtual world is much mo= re >> >>>>> > than >> >>>>> > just a >> >>>>> > =A0 =A0 Region >> >>>>> > =A0 =A0 > Domain. =A0It is a complete set of services of which t= he >> >>>>> > Region >> >>>>> > Domain >> >>>>> > =A0 =A0 service is >> >>>>> > =A0 =A0 > just one. =A0Other typical services might be those of = the >> >>>>> > Agent >> >>>>> > Domain >> >>>>> > =A0 =A0 (which >> >>>>> > =A0 =A0 > provides identification and authorization services and >> >>>>> > possibly >> >>>>> > others), >> >>>>> > =A0 =A0 as >> >>>>> > =A0 =A0 > well as asset and inventory services, IM and other >> >>>>> > communication >> >>>>> > =A0 =A0 services, and >> >>>>> > =A0 =A0 > maybe several more. >> >>>>> > >> >>>>> > =A0 =A0 Well... that is purely semantic. It is a way to define V= W, but >> >>>>> > not one that >> >>>>> > =A0 =A0 I've been using :/ >> >>>>> > >> >>>>> > >> >>>>> > It's a rough top-level projection of the architectural model of >> >>>>> > VWRAP, once the >> >>>>> > various services have been decoupled in the way that David Levin= e >> >>>>> > often >> >>>>> > describes to us. =A0Nothing very contentious there, everyone lik= es a >> >>>>> > services-oriented approach. :-) >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > =A0 =A0 For simplicity, assume that only two things are needed t= o >> >>>>> > create >> >>>>> > a complete >> >>>>> > =A0 =A0 virtual world, like SL or OG: A Region Domain (RD) and a= n >> >>>>> > Agent >> >>>>> > Domain >> >>>>> > =A0 =A0 (AD). >> >>>>> > >> >>>>> > >> >>>>> > I am happy to consider that simple scenario as representative. = =A0It >> >>>>> > is >> >>>>> > quite >> >>>>> > reasonable to equate AD with VW because the AD is the focus of >> >>>>> > almost >> >>>>> > all the >> >>>>> > policy decisions of a VWRAP-based world. =A0When other decoupled >> >>>>> > services are >> >>>>> > added to this picture, it doesn't change the fundamental >> >>>>> > architecture >> >>>>> > of AD + >> >>>>> > RDs, only extends it by decoupling more than just the region >> >>>>> > service. >> >>>>> > =A0So >> >>>>> > that's fine with me. >> >>>>> >> >>>>> I totally disagree that the AD is the representative...and why do >> >>>>> you >> >>>>> say >> >>>>> that below a sentence of me where I say "A Region Domain (RD) and = an >> >>>>> Agent Domain (AD)"? >> >>>>> >> >>>>> This is like I say "VW =3D AD + RD", and you go: "yes, VW =3D AD".= We >> >>>>> can't >> >>>>> have a discussion like that Morgaine. >> >>>>> >> >>>>> > =A0 =A0 Currently, without any interop, each administrative enti= ty (or >> >>>>> > trust >> >>>>> > =A0 =A0 entity) >> >>>>> > =A0 =A0 will need to provide both: an RD *and* an AD, otherwise = they >> >>>>> > don't have a >> >>>>> > =A0 =A0 functional VW. >> >>>>> > >> >>>>> > >> >>>>> > Correct. =A0The AD is the seat of most (but not all) of the poli= cy >> >>>>> > decisions of a >> >>>>> >> >>>>> I even *stressed* the '*and*' here, and you do it again. >> >>>>> >> >>>>> > VW, so it's very central to the existence of a VW. =A0While it's >> >>>>> > possible to >> >>>>> > imagine policy-free VWs that temporarily =A0take on the policy o= f >> >>>>> > any >> >>>>> > other world >> >>>>> > they hook up with, this is clearly a subset situation. =A0All th= e >> >>>>> > currently known >> >>>>> > SL-like virtual worlds are grids of the SL kind, with their own >> >>>>> > individual >> >>>>> > policies which they are not going to change on interop. >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > =A0 =A0 Your conclusion is that a VW exist of both 1 RD and 1 AD= . But >> >>>>> > I >> >>>>> > ask you to >> >>>>> > =A0 =A0 reconsider if that conclusion is correct, because it is = based >> >>>>> > on >> >>>>> > the >> >>>>> > =A0 =A0 current >> >>>>> > =A0 =A0 situation without any interop. Now "correct" might not b= e the >> >>>>> > correct word >> >>>>> > =A0 =A0 - heh. >> >>>>> > =A0 =A0 Rather I should say: I ask you to reconsider if that >> >>>>> > definition >> >>>>> > is very >> >>>>> > =A0 =A0 useful. >> >>>>> > >> >>>>> > =A0 =A0 Lets consider the following fictive case: >> >>>>> > >> >>>>> > =A0 =A0 LL runs one RD and AD, called RD1 and AD1. >> >>>>> > =A0 =A0 CB (Cable Beach) runs another RD and AD, called RD2 and = AD2. >> >>>>> > =A0 =A0 A user that authenticates with either AD1 or AD2 can tra= vel to >> >>>>> > RD1 AND RD2, >> >>>>> > =A0 =A0 completely symmetrical, keeping their respective AD1- an= d AD2- >> >>>>> > assets etc. >> >>>>> > =A0 =A0 This is possible with the right policies, so for the sak= e of >> >>>>> > looking at >> >>>>> > =A0 =A0 the usefulness of the above definition of VW, assume thi= s is >> >>>>> > the >> >>>>> > case. >> >>>>> > >> >>>>> > >> >>>>> > That's not quite right because Cable Beach is not a world provid= er >> >>>>> > like LL. >> >>>>> > Cable Beach is perhaps best described as a "login mediation" >> >>>>> > mechanism or >> >>>>> >> >>>>> I might not understand what the real Cable Beach is or wants to be= , >> >>>>> I >> >>>>> was just >> >>>>> trying to give an example to work with. So, again: >> >>>>> >> >>>>> LL runs one RD and AD, called RD1 and AD1. >> >>>>> OG runs another RD and AD, called RD2 and AD2. >> >>>>> A user that authenticates with either AD1 or AD2 can travel to RD1 >> >>>>> AND >> >>>>> RD2, >> >>>>> completely symmetrical, keeping their respective AD1- and AD2- >> >>>>> assets >> >>>>> etc. >> >>>>> This is possible with the right policies, so for the sake of looki= ng >> >>>>> at >> >>>>> the usefulness of the above definition of VW, assume this is the >> >>>>> case. >> >>>>> >> >>>>> > protocol, which provides a model for interaction between a "worl= d >> >>>>> > service" >> >>>>> > (effectively an AD), the user's client, and various decoupled >> >>>>> > services such as >> >>>>> > simulation nodes (possibly an RD) and inventory/asset services. >> >>>>> > =A0Let's assume >> >>>>> > therefore that your "CB" above means something different (anothe= r >> >>>>> > world >> >>>>> > provider similar to LL), and then we can proceed with your examp= le >> >>>>> > case. >> >>>>> >> >>>>> Ok >> >>>>> >> >>>>> > =A0 =A0 Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" t= o be >> >>>>> > another VW? >> >>>>> > =A0 =A0 Or do you think it would make most sense in THIS case to= speak >> >>>>> > of >> >>>>> > a single >> >>>>> > =A0 =A0 VW? >> >>>>> > >> >>>>> > >> >>>>> > They're two worlds because you defined them as such, as each has >> >>>>> > its >> >>>>> > own AD. >> >>>>> > :-) =A0But that aside, if they were set up separately then they = have >> >>>>> > two >> >>>>> > different sets of policies, two different sets of residents, two >> >>>>> > different >> >>>>> > ToS's, possibly two different legal jurisdictions, two different >> >>>>> > mechanisms for >> >>>>> > abuse control and conflict resolution, and so on and so forth. = =A0If >> >>>>> > they were >> >>>>> > created to be worlds that can stand alone but interoperate when >> >>>>> > desired, then >> >>>>> > each of these is a diffferent world. =A0I don't see how that can= be >> >>>>> > disputed. >> >>>>> >> >>>>> As I stated in one of my first posts, it will (hopefully!!!) be >> >>>>> mainly >> >>>>> the >> >>>>> the *RD* and NOT the AD that all of those things are a function of= ! >> >>>>> >> >>>>> You keep saying that it's mainly the AD that determines these >> >>>>> things, >> >>>>> but >> >>>>> that would be confusing and very annoying. If two people meet in a >> >>>>> virtual >> >>>>> world, that is - if they are standing next to eachother in one >> >>>>> region >> >>>>> and >> >>>>> using local chat - then they should fall under the same legal >> >>>>> jurisdiction >> >>>>> and the same ToS: it is the region that determines the rules, not >> >>>>> the >> >>>>> AD >> >>>>> that they used to login with. >> >>>>> >> >>>>> As example, ToS1 says: it's ok to be naked; and ToS2 says: it's a >> >>>>> bannable >> >>>>> offence to be naked. Do you really think that it's even workable i= f >> >>>>> the >> >>>>> ToS to be applied is a function of the AD? Say you login using AD2= , >> >>>>> so >> >>>>> ToS2 applies to you. You meet someone else that is naked. You know >> >>>>> that >> >>>>> you are not allowed to and you are offended. You create an abuse >> >>>>> report; >> >>>>> where does that report go to? To your AD administration? That make= s >> >>>>> no >> >>>>> sense: that naked person is using a different AD. To his/her AD >> >>>>> administration >> >>>>> then? That makes also no sense since they allow it. >> >>>>> >> >>>>> Seriously, there is only one reasonable thing to do: the ToS that >> >>>>> applies >> >>>>> is a function of the Region Domain *only*, and if you write an abu= se >> >>>>> report, >> >>>>> it should go to the administration of the region that you are in a= nd >> >>>>> not >> >>>>> to your or the others AD administration. Same holds for the things >> >>>>> related >> >>>>> to legal jurisdiction and any other 'rules' that applies at any >> >>>>> given >> >>>>> moment (to users). The only thing that might be a function of the = AD >> >>>>> are >> >>>>> technical policies that are automatically enforced by VWRAP. >> >>>>> >> >>>>> > =A0 =A0 I think this is what Infinity means when she says that >> >>>>> > "virtual >> >>>>> > world" >> >>>>> > =A0 =A0 cannot >> >>>>> > =A0 =A0 be defined, because what could be perceived as being a V= W is >> >>>>> > highly >> >>>>> > =A0 =A0 dependend >> >>>>> > =A0 =A0 on the exact situation (and policies) and in certain >> >>>>> > configuration that are >> >>>>> > =A0 =A0 not as clear as the current situation (no interop) or th= e >> >>>>> > above >> >>>>> > example >> >>>>> > =A0 =A0 (100% >> >>>>> > =A0 =A0 interop). >> >>>>> > >> >>>>> > >> >>>>> > This is incorrect. =A0"Virtual world" is defined by each provide= r of >> >>>>> > a >> >>>>> > virtual >> >>>>> > world and by nobody else, and each provider knows full well how = it >> >>>>> > is >> >>>>> > defined, >> >>>>> > what its boundaries are, and what makes it distinct. =A0Nobody e= lse >> >>>>> > can >> >>>>> > define >> >>>>> > what a virtual world is, and it's not our business to define it >> >>>>> > either (nor to >> >>>>> > conjure up a fictitious definition). >> >>>>> >> >>>>> Sorry, but I think you should try harder to understand my point of >> >>>>> view >> >>>>> first. >> >>>>> I didn't give the examples so you can ignore them. >> >>>>> >> >>>>> > We only need to define the protocol interactions at the endpoint= s >> >>>>> > presented by >> >>>>> > those worlds, and not to define "virtual world" structurally nor >> >>>>> > any >> >>>>> > other way. >> >>>>> > =A0 Doing so is what has got us into this mess, by creating a >> >>>>> > fictitious >> >>>>> > definition based on reachability and hence blocking any ability = to >> >>>>> > talk about >> >>>>> > actual virtual worlds. =A0Those worlds exist. =A0They won't go a= way. >> >>>>> > =A0They want to >> >>>>> > interoperate, but they don't want to be told that they don't >> >>>>> > exist. >> >>>>> >> >>>>> I was trying to make you understand WHY Infinitely tells you they >> >>>>> don't >> >>>>> "exist", >> >>>>> if you understand her (and you don't, imho) then it will be easier >> >>>>> to >> >>>>> solve this >> >>>>> miscommunication. >> >>>>> >> >>>>> > The contention that we don't know what "virtual world" means is >> >>>>> > just >> >>>>> > plain >> >>>>> > bizarre. >> >>>>> >> >>>>> Only if you already have a definition of "virtual world" they way >> >>>>> you >> >>>>> do. >> >>>>> >> >>>>> > I don't know of any VW operator who doesn't know what their worl= d >> >>>>> > is. >> >>>>> >> >>>>> That is the *current* situation... which is 100% simpler than what >> >>>>> we'll >> >>>>> have in the future. >> >>>>> >> >>>>> Compare with math... currently we only have Integers (Z). We're >> >>>>> about >> >>>>> to introduce division and by that we need to extend the definition >> >>>>> of >> >>>>> 'number' from Z to Q. Q aren't integers, even though currently eve= ry >> >>>>> number is an integer doesn't mean you have to hold on tight the >> >>>>> "definition" >> >>>>> of "number" =3D=3D integer. That definition will be broken and you= will >> >>>>> have to redefine "number". >> >>>>> >> >>>>> > =A0 Every single one of them could provide the necessary endpoin= ts >> >>>>> > for >> >>>>> > VWRAP >> >>>>> > within their world without any scratching of heads at the meanin= g >> >>>>> > of >> >>>>> > "virtual >> >>>>> > world". =A0That repeated allegation has been a complete >> >>>>> > misrepresentation. =A0It's >> >>>>> > just not true. >> >>>>> >> >>>>> You CANNOT define "virtual world" as "AD" (see above) nor as "AD + >> >>>>> RD" >> >>>>> because >> >>>>> that is too simple and only holds in the current situation. You ca= n >> >>>>> only, at most, >> >>>>> if you really want, say - well, lets define it as being some RD. >> >>>>> >> >>>>> > And possibly even worse is the excuse =A0that "virtual world" is= not >> >>>>> > being >> >>>>> > defined but is being used non-normatively, while in practice usi= ng >> >>>>> > the phrase " >> >>>>> > the virtual world" to create a totally fictitious single virtual >> >>>>> > world instead. >> >>>>> >> >>>>> I agree that as long as it isn't normatively defined, the term >> >>>>> shouldn't be >> >>>>> used in documents except in places where it can literally mean >> >>>>> anything >> >>>>> without >> >>>>> that anyone will care (like in the protocol name). >> >>>>> >> >>>>> > =A0 That phrase is unnecessary, it is misrepresentative of the >> >>>>> > actual >> >>>>> > situation, >> >>>>> > it bypasses policy controls of one world by not mentioning its A= D, >> >>>>> > it >> >>>>> > prevents >> >>>>> > us from mentioning virtual worlds by blocking the normal meaning >> >>>>> > of >> >>>>> > the term, >> >>>>> > and it provides nothing useful as a benefit in return. =A0Unless >> >>>>> > total >> >>>>> > confusion >> >>>>> > is a benefit. ;-) >> >>>>> >> >>>>> Sorry, but that is like saying that defining the Rational Numbers >> >>>>> (Q) >> >>>>> makes it >> >>>>> impossible to talk about 'numbers', because 3/7 isn't an integer. >> >>>>> What you have to do is let go of your current definition. >> >>>>> >> >>>>> > =A0 =A0 In one of my first posts about this topic I stated that >> >>>>> > "virtual >> >>>>> > world" >> >>>>> > =A0 =A0 should >> >>>>> > =A0 =A0 be considered to be the Region Domain (although I didn't= use >> >>>>> > that >> >>>>> > term at >> >>>>> > =A0 =A0 the >> >>>>> > =A0 =A0 moment) and be completely independent of the Agent Domai= n, >> >>>>> > based >> >>>>> > on typical >> >>>>> > =A0 =A0 cases of abuse and griefing etc: if anyone annoys some o= ther >> >>>>> > user, or >> >>>>> > =A0 =A0 breaks >> >>>>> > =A0 =A0 almost any ToS, it will be region based; which is why I'= ve >> >>>>> > always >> >>>>> > said that >> >>>>> > =A0 =A0 any type of abuse can and should be handled at the sim (= single >> >>>>> > region) >> >>>>> > =A0 =A0 level: >> >>>>> > =A0 =A0 the estate owner and managers in SL, even, but that idea >> >>>>> > definitely extends >> >>>>> > =A0 =A0 to "world administrations": the people running the REGIO= N >> >>>>> > (domain) is the >> >>>>> > =A0 =A0 one >> >>>>> > =A0 =A0 that should decide what is the local ToS and deal with a= buse >> >>>>> > etc. >> >>>>> > That is >> >>>>> > =A0 =A0 why I strongly argue to define "virtual world" as Region >> >>>>> > Domain, >> >>>>> > and leave >> >>>>> > =A0 =A0 the AD out of it. Nevertheless, now I have the term "Reg= ion >> >>>>> > Domain" I don't >> >>>>> > =A0 =A0 need "virtual world" anymore. >> >>>>> > >> >>>>> > >> >>>>> > But that's not how OGP is structured. =A0It's the AD that is the >> >>>>> > focus >> >>>>> > of service >> >>>>> > policy choices in OGP, and it's the "world service" that is the >> >>>>> > focus >> >>>>> > of >> >>>>> > service policy in Cable Beach. =A0The AD and the world service a= re >> >>>>> > the >> >>>>> > source of >> >>>>> > capabilities that determine pretty much everything else, and the >> >>>>> > region domain >> >>>>> > is very subsidiary to that. >> >>>>> >> >>>>> No, if the service prodiver of some AD disagrees with the (say) a >> >>>>> ToS >> >>>>> that applies >> >>>>> when you go to some RD then they should disallow you go there; the= y >> >>>>> should not >> >>>>> allow you to go there and then demand that you follow their ToS, >> >>>>> that >> >>>>> would not >> >>>>> be a practical solution that is workable. >> >>>>> >> >>>>> To use mathematics again, it's easy to make two ToS that have no >> >>>>> intersection: >> >>>>> Say, ToS1 says: you MUST wear purple clothes, and ToS2 says: you >> >>>>> MUST >> >>>>> wear blue >> >>>>> clothes. Obviously those will apply to regions. >> >>>>> >> >>>>> So then we have: >> >>>>> >> >>>>> Provider1: RD1 --> TOS1 --> purple clothes >> >>>>> Provider2: RD2 --> TOS2 --> blue clothes >> >>>>> >> >>>>> *if* Provider 2 runs an AD (AD2) and they allow people logged in >> >>>>> with >> >>>>> it >> >>>>> to go to region RD1 then the people there should wear purple >> >>>>> clothes: >> >>>>> TOS2 will not apply because of the AD you use. >> >>>>> >> >>>>> If it's against providers religious believe to support wearing >> >>>>> purple >> >>>>> clothes than they might disallow people to go to RD1, that is thei= r >> >>>>> choice (policy). >> >>>>> >> >>>>> > Indeed, a region domain may have no policy of its >> >>>>> > own at all, but merely extend an existing virtual world by >> >>>>> > accepting >> >>>>> > the >> >>>>> > policies of that world's AD. =A0That's the model in the original= OGP >> >>>>> > before it >> >>>>> > gained aspirations of becoming a cross-VW interop protocol. >> >>>>> >> >>>>> That makes no sense :/ >> >>>>> >> >>>>> There can be any number of people in a given RD, and each can in >> >>>>> principle >> >>>>> be using a different AD! PLEASE let the RD determine the rules the= y >> >>>>> have >> >>>>> to live by! Anyone else that disagrees with me about that?! >> >>>>> >> >>>>> > If RDs determined VW policy and generated seed capabilities for >> >>>>> > everything and >> >>>>> > ADs were merely login services then your model would apply, and = RD >> >>>>> > could be >> >>>>> > considered "VW". >> >>>>> >> >>>>> Ah! At last.. >> >>>>> >> >>>>> > But that's not how it is currently structured --- RDs are >> >>>>> >> >>>>> If you are refering to OGP, then OGP should be changed. >> >>>>> >> >>>>> > merely the land + physical simulation components of worlds, and = in >> >>>>> > SL's case, >> >>>>> > also an elaborate system of proxies. =A0And that's why we need >> >>>>> > multiple >> >>>>> > ADs to >> >>>>> > interact in VWRAP before we can consider that there is VW-VW >> >>>>> > interop. >> >>>>> > =A0RDs >> >>>>> > don't handle it. >> >>>>> >> >>>>> What I seem to keep missing is the fact that VWRAP is already >> >>>>> completely >> >>>>> defined in those previous OGP documents and we're merely here to >> >>>>> rewrite >> >>>>> them in an IETF document of sorts. >> >>>>> >> >>>>> Yes we need multiple ADs to interact, and they will. >> >>>>> But yes, RD's will handle whatever they have to handle with VWRAP. >> >>>>> I never said that capabilities equal 'rules' (ToS and legal >> >>>>> jurisdiction >> >>>>> isn't something that should be enforced or controlled by the >> >>>>> protocol) >> >>>>> by >> >>>>> the way. >> >>>>> >> >>>>> ... sorry my RSI forces me to stop typing here... shouldn't have >> >>>>> typed this much alrady anyway :( >> >>>>> >> >>>>> > =A0 =A0 > In our new protocol, these services may either be >> >>>>> > implemented >> >>>>> > internally >> >>>>> > =A0 =A0 within >> >>>>> > =A0 =A0 > a virtual world, or some might be implemented as exter= nal >> >>>>> > services >> >>>>> > =A0 =A0 offered by >> >>>>> > =A0 =A0 > third parties, the choice being a policy and design de= cision >> >>>>> > for each >> >>>>> > =A0 =A0 world >> >>>>> > =A0 =A0 > operator. =A0In all cases however, the virtual worlds = are >> >>>>> > defined >> >>>>> > by a set >> >>>>> > =A0 =A0 of >> >>>>> > =A0 =A0 > services, and not just by a Region Domain. >> >>>>> > >> >>>>> > >> >>>>> > Indeed. =A0But access to such decoupled services is provided by = the >> >>>>> > AD >> >>>>> > through >> >>>>> > the capabilities that it delivers to authorized parties, and >> >>>>> > regions >> >>>>> > are just >> >>>>> > one such service. =A0You're giving RDs credit for something that >> >>>>> > they >> >>>>> > don't do. >> >>>>> > :-) =A0Perhaps the VWRAP model should be redesigned along your l= ines >> >>>>> > so >> >>>>> > that RDs >> >>>>> > become the VWs and are the generators of seed caps, and then ADs >> >>>>> > become just a >> >>>>> > subservient policy-free login mechanism. :D >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > =A0 =A0 I'm afraid that is purely a matter of opinion. I agree t= hat it >> >>>>> > is >> >>>>> > likely >> >>>>> > =A0 =A0 that a single 'administrative entity' that runs a RD wil= l also >> >>>>> > run an AD >> >>>>> > =A0 =A0 and allow users authenticated with their AD visit their = RD, >> >>>>> > but >> >>>>> > it is no >> >>>>> > =A0 =A0 more than *likely*. There will almost certainly be servi= ce >> >>>>> > provides that >> >>>>> > =A0 =A0 ONLY run an AD, and don't have a RD! And I can imagine t= hat >> >>>>> > there >> >>>>> > will >> >>>>> > =A0 =A0 be some that only run a RD and do not care about running= their >> >>>>> > own AD. >> >>>>> > >> >>>>> > >> >>>>> > Oh sure, there will be all combinations of services, that is to = be >> >>>>> > expected. >> >>>>> > But it is the seat of policy that is the heart of each virtual >> >>>>> > world, >> >>>>> > and >> >>>>> > currently the seat of policy lies in the AD. =A0A VW that doesn'= t >> >>>>> > have >> >>>>> > an AD in >> >>>>> > the VWRAP model is just a colony without a government, ready to = be >> >>>>> > assimilated >> >>>>> > into a world that has an AD and that therefore sets policies, >> >>>>> > instead >> >>>>> > of being >> >>>>> > a sovereign world that merely wants to interop with that other >> >>>>> > world >> >>>>> > through >> >>>>> > VWRAP. >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > =A0 =A0 Therefore, "virtual world" cannot be synonym for "the se= t of >> >>>>> > services >> >>>>> > =A0 =A0 run by a single administrative entity" as you seem to ar= gue, >> >>>>> > and >> >>>>> > at >> >>>>> > =A0 =A0 the SAME time be argued to include an RD *and* AD at all >> >>>>> > times. >> >>>>> > >> >>>>> > >> >>>>> > I don't follow that. =A0Two worlds that can run independently >> >>>>> > (that's >> >>>>> > very >> >>>>> > important) can certainly each be defined as a set of services th= at >> >>>>> > includes the >> >>>>> > functions of an AD and an RD, and those worlds each continue to >> >>>>> > include the >> >>>>> > functions of an AD and an RD even after they start interoperatin= g >> >>>>> > (assuming >> >>>>> > that VWRAP is extended to allow cross-VW interop). =A0No world i= s >> >>>>> > going >> >>>>> > to give >> >>>>> > up part of its services portfolio on interop. =A0Interop is an >> >>>>> > additional >> >>>>> > benefit, not a loss of capability. >> >>>>> > >> >>>>> > [It's worth noting that there may actually be a small loss of >> >>>>> > capability >> >>>>> > occurring on interop in VWRAP, although it is rarely mentioned. >> >>>>> > =A0You >> >>>>> > can be >> >>>>> > present in two worlds simultaneously with the same login >> >>>>> > credentials >> >>>>> > pre-interop (a feature that we enjoy currently between SL and >> >>>>> > OSgrid >> >>>>> > for >> >>>>> > example), but post-interop this may no longer be possible --- it >> >>>>> > depends on the >> >>>>> > implementation. =A0No doubt we will visit this issue within VWRA= P.] >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > =A0 =A0 > This is easy to see by looking at a couple of archetyp= al >> >>>>> > examples in this >> >>>>> > =A0 =A0 > space: >> >>>>> > =A0 =A0 > >> >>>>> > =A0 =A0 > >> >>>>> > =A0 =A0 > =A0 =A0 Is Second Life a virtual world? =A0Undoubtedly= . =A0Is Second >> >>>>> > Life just a >> >>>>> > =A0 =A0 Region >> >>>>> > =A0 =A0 > =A0 =A0 Domain (assuming it were implemented using VWR= AP)? =A0No, >> >>>>> > of >> >>>>> > course >> >>>>> > =A0 =A0 not, SL >> >>>>> > =A0 =A0 > =A0 =A0 includes all of the services mentioned above, = and >> >>>>> > others. >> >>>>> > >> >>>>> > =A0 =A0 Of course, LL happens to run all services that are neede= d to >> >>>>> > create one >> >>>>> > =A0 =A0 virtual world; there are no third parties they can hire = from >> >>>>> > yet, >> >>>>> > so they >> >>>>> > =A0 =A0 have to provide it all themselves. >> >>>>> > >> >>>>> > =A0 =A0 But after SL implemented VWRAP they might decide to do a= way >> >>>>> > from >> >>>>> > one of >> >>>>> > =A0 =A0 their services and only keep their RD. Unlikely, but pos= sible. >> >>>>> > >> >>>>> > >> >>>>> > You're confusing RD functionality with AD functionality again >> >>>>> > there. >> >>>>> > =A0The AD is >> >>>>> > the heart of a world because it defines its capabilities and >> >>>>> > policies. =A0The RD >> >>>>> > is just a pile of region hosts that could easily be farmed out t= o >> >>>>> > a >> >>>>> > third party >> >>>>> > to run without them determining policy, and indeed this is alrea= dy >> >>>>> > being done. >> >>>>> > While it is a very important pile of hosts which gives a world i= ts >> >>>>> > physical >> >>>>> > characterists, the RD is a subservient service to the AD in OGP, >> >>>>> > just >> >>>>> > as the >> >>>>> > equivalent "simulation nodes" provide a subservient service to t= he >> >>>>> > "world >> >>>>> > service" under Cable Beach. =A0The RD is well named --- it provi= des >> >>>>> > region >> >>>>> > services only, not the package of internal + external services >> >>>>> > that >> >>>>> > together >> >>>>> > create a virtual world. >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > =A0 =A0 > =A0 =A0 Is OSgrid a virtual world? =A0Undoubtedly. =A0= Is OSgrid just >> >>>>> > a >> >>>>> > Region >> >>>>> > =A0 =A0 Domain >> >>>>> > =A0 =A0 > =A0 =A0 (assuming it were implemented using VWRAP)? = =A0No, of >> >>>>> > course >> >>>>> > not, it >> >>>>> > =A0 =A0 > =A0 =A0 currently runs all the UGAIM services, which i= n a VWRAP >> >>>>> > context would >> >>>>> > =A0 =A0 > =A0 =A0 become similar to those of Second Life. >> >>>>> > >> >>>>> > =A0 =A0 Exact same argument. >> >>>>> > >> >>>>> > >> >>>>> > Exact same response because the same applies. :-) =A0 What's mor= e, >> >>>>> > in >> >>>>> > OSgrid this >> >>>>> > is even easier to identify, because every person or company that >> >>>>> > adds >> >>>>> > regions >> >>>>> > to OSgrid is subscribing to the notion that they are participant= s >> >>>>> > in >> >>>>> > OSgrid --- >> >>>>> > OSgrid is their virtual world. =A0They are merely providing >> >>>>> > additional >> >>>>> > land mass >> >>>>> > and simulation capacity. >> >>>>> > >> >>>>> > Also, in this example there is no need to hypothesize region >> >>>>> > services >> >>>>> > being >> >>>>> > farmed out to third parties, as there already are hundreds to >> >>>>> > thousands of >> >>>>> > independent third parties involved in supplying regions. =A0Thos= e >> >>>>> > regions and >> >>>>> > clusters of regions (equivalent to RDs) together combine to crea= te >> >>>>> > the virtual >> >>>>> > world of OSgrid. =A0There is a clear distinction between R/RDs h= ere >> >>>>> > and >> >>>>> > the VW >> >>>>> > itself, which also includes a variety of other services as Charl= es >> >>>>> > has >> >>>>> > described several times. =A0The R/RDs are a very important part,= but >> >>>>> > functionally >> >>>>> > they are not the VW, nor are they the VW perceptually. =A0They a= re >> >>>>> > places within >> >>>>> > the world, not the whole world. >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > =A0 =A0 > So you see, the idea that has been floated which claim= s that >> >>>>> > "VW =3D=3D RD" >> >>>>> > =A0 =A0 is >> >>>>> > =A0 =A0 > completely wrong, and misrepresents what constitutes a >> >>>>> > "virtual >> >>>>> > world" >> >>>>> > =A0 =A0 despite >> >>>>> > =A0 =A0 > the very clear examples before us. >> >>>>> > >> >>>>> > =A0 =A0 If you want to put it that way (including everything abo= ve >> >>>>> > that >> >>>>> > you said) >> >>>>> > =A0 =A0 then >> >>>>> > =A0 =A0 I have to side with Infinity: you cannot define a virtua= l >> >>>>> > world >> >>>>> > that way >> >>>>> > =A0 =A0 and >> >>>>> > =A0 =A0 use it for useful discussions regarding VWRAP. >> >>>>> > >> >>>>> > >> >>>>> > I think you may have misread that. =A0I did not define "VW =3D= =3D RD". >> >>>>> > =A0That's the >> >>>>> > opposite of what I said, but I agree with you on the negative >> >>>>> > conclusion. =A0If >> >>>>> > one defines "VW =3D=3D RD" then it becomes impossible to have a >> >>>>> > meaningful >> >>>>> > discussion about VWs in VWRAP. =A0It also becomes impossible to = have >> >>>>> > a >> >>>>> > meaningful >> >>>>> > discussion about VWs in VWRAP if one conjures up a fictitious >> >>>>> > meaning >> >>>>> > of >> >>>>> > "virtual world" based on reachability. =A0And that's why we shou= ld >> >>>>> > not >> >>>>> > define it >> >>>>> > in either of those two ways. >> >>>>> > >> >>>>> > The most useful and forward-looking way of defining virtual worl= ds >> >>>>> > in >> >>>>> > VWRAP is >> >>>>> > as a collection of service endpoints, regardless of who operates >> >>>>> > them. =A0All we >> >>>>> > should care about is the protocol between endpoints, and not >> >>>>> > conjure >> >>>>> > up some >> >>>>> > non-existent single virtual world. >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > =A0 =A0 In the end, one virtual world as defined by "all service= s >> >>>>> > together to make >> >>>>> > =A0 =A0 things work" will be, or can be, a mix of many RD's and = many >> >>>>> > AD's >> >>>>> > with a >> >>>>> > =A0 =A0 complex >> >>>>> > =A0 =A0 web of trust/non-trust between them that makes the conce= pt of >> >>>>> > "virtual >> >>>>> > =A0 =A0 world" >> >>>>> > =A0 =A0 rather fuzzy at best. >> >>>>> > >> >>>>> > >> >>>>> > You're right but you're not being clear about what is fuzzy. =A0= The >> >>>>> > concept of " >> >>>>> > single virtual world" is not only fuzzy, it is totally >> >>>>> > non-existent >> >>>>> > in practice >> >>>>> > (because there are many, not one) as well as impossible in theor= y >> >>>>> > =A0because of >> >>>>> > balkanization through incompatible trust domains, as described s= o >> >>>>> > magnificently >> >>>>> > by Magnus a week or two ago. =A0We should not go there. >> >>>>> > >> >>>>> > In contrast, the concept of multiple virtual worlds is crystal >> >>>>> > clear. >> >>>>> > =A0Several >> >>>>> > people here in the group operate virtual worlds, but nobody woul= d >> >>>>> > suggest that >> >>>>> > they are unclear about what they operate. =A0We've been sold a >> >>>>> > bridge >> >>>>> > on that >> >>>>> > "uncertainty". =A0Multiple virtual worlds presenting VWRAP endpo= ints >> >>>>> > are the >> >>>>> > natural way of approaching interop between VWs, and you don't ha= ve >> >>>>> > to >> >>>>> > define >> >>>>> > VWs structurally for that. =A0You only have to define the endpoi= nts >> >>>>> > that VWs need >> >>>>> > to present to the protocol, and avoid any notion of "single >> >>>>> > virtual >> >>>>> > world". >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > =A0 =A0 [...] >> >>>>> > =A0 =A0 > As we move into analysis of the problem space, these i= ssues >> >>>>> > will be >> >>>>> > =A0 =A0 > disentangled and clarified and the protocols will be d= efined >> >>>>> > and evolve, >> >>>>> > =A0 =A0 but >> >>>>> > =A0 =A0 > from the current OGP perspective there is no symmetric= al >> >>>>> > relationship >> >>>>> > =A0 =A0 possible >> >>>>> > =A0 =A0 > between VWs that could be described as "peering". =A0I= t is the >> >>>>> > asymmetry of >> >>>>> > =A0 =A0 the >> >>>>> > =A0 =A0 > VW-RD relationship that has been the crux of the "no V= W >> >>>>> > interop" issue. >> >>>>> > =A0 =A0 For >> >>>>> > =A0 =A0 > symmetrical peering, the protocol would need to mentio= n at >> >>>>> > least two >> >>>>> > =A0 =A0 > communicating VWs. >> >>>>> > >> >>>>> > =A0 =A0 You can about peering with just two RD's and one AD, or = one RD >> >>>>> > and two >> >>>>> > =A0 =A0 AD's. >> >>>>> > >> >>>>> > >> >>>>> > I think you're confusing RDs with VWs again --- RDs only provide >> >>>>> > regions, >> >>>>> > nothing else. =A0For peering between two VWs, you would need >> >>>>> > interaction between >> >>>>> > their two ADs because their ADs provide their policies. =A0If yo= u >> >>>>> > bypass a VW's >> >>>>> > AD then you bypass its policies, so you're not interoping with >> >>>>> > that >> >>>>> > world. =A0And >> >>>>> > I don't think we're encouraging bypassing and hence subverting a >> >>>>> > world's >> >>>>> > policies. >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > =A0 =A0 > Of course the situation could change as the protocol >> >>>>> > evolves. >> >>>>> > =A0For >> >>>>> > =A0 =A0 example, >> >>>>> > =A0 =A0 > once or twice we have heard mention that multiple ADs = could >> >>>>> > be >> >>>>> > involved >> >>>>> > =A0 =A0 in some >> >>>>> > =A0 =A0 > way, and it seems certain that communication services = from >> >>>>> > multiple VWs >> >>>>> > =A0 =A0 will be >> >>>>> > =A0 =A0 > merged because residents demand this. =A0This would st= art to >> >>>>> > take >> >>>>> > us into >> >>>>> > =A0 =A0 VW-VW >> >>>>> > =A0 =A0 > interop territory. =A0However, there is no such thing = in VWRAP >> >>>>> > currently, >> >>>>> > =A0 =A0 and >> >>>>> > =A0 =A0 > it's not in the list of deliverables to include it, an= d >> >>>>> > therefore we >> >>>>> > =A0 =A0 cannot say >> >>>>> > =A0 =A0 > that VWRAP will provide VW-VW interop at all. =A0For n= ow. ;-) >> >>>>> > >> >>>>> > =A0 =A0 I can't comment on that cause I didn't see VWRAP yet, bu= t from >> >>>>> > the >> >>>>> > =A0 =A0 charter and the comments on this list I'd think that ful= l >> >>>>> > support >> >>>>> > =A0 =A0 for interop between any number of RD's and AD's is inten= ded. >> >>>>> > >> >>>>> > >> >>>>> > Well you've put your finger on the problem here. =A0Everyone is >> >>>>> > saying >> >>>>> > what they >> >>>>> > think is intended because the intention is not actually spelled >> >>>>> > out >> >>>>> > in the >> >>>>> > documents. =A0Why cannot it be spelled out clearly that interop >> >>>>> > between >> >>>>> > multiple >> >>>>> > ADs is intended? =A0If it were, this entire discussion could be >> >>>>> > avoided >> >>>>> > because >> >>>>> > it's easy and reasonable to equate ADs with VWs in practice. >> >>>>> > >> >>>>> > Notice however that even if the protocol were modified to be abl= e >> >>>>> > to >> >>>>> > handle two >> >>>>> > ADs at a time, use of an unadorned "the virtual world" in the >> >>>>> > documents would >> >>>>> > continue to raise the perennial question of "Which virtual >> >>>>> > world?". >> >>>>> > =A0After all, >> >>>>> > there would be two of them being discussed. >> >>>>> > >> >>>>> > It's this phraseology that stems from OGP's original goal of >> >>>>> > adding >> >>>>> > single >> >>>>> > regions or RDs to an existing single virtual world (namely SL in >> >>>>> > the >> >>>>> > prototype) >> >>>>> > that is creating such a problem. =A0That phraseology was appropr= iate >> >>>>> > for that >> >>>>> > original goal. =A0It is not appropriate for the goal of >> >>>>> > interoperating >> >>>>> > multiple >> >>>>> > virtual worlds --- it makes it impossible to even talk about the >> >>>>> > goal >> >>>>> > sensibly, >> >>>>> > because "the virtual world" in the OGP sense has no plural. >> >>>>> > >> >>>>> > It's unfortunate, but this whole affair is just the product of >> >>>>> > legacy >> >>>>> > wording >> >>>>> > from OGP. =A0That's never going to work in a multi-world setting >> >>>>> > where >> >>>>> > we need to >> >>>>> > talk about the endpoints in different worlds. >> >>>>> > >> >>>>> > >> >>>>> > Morgaine. >> >>>>> > >> >>>>> > PS. If anyone else read this far other than Carlo, you have a lo= t >> >>>>> > of >> >>>>> > stamina >> >>>>> > and dedication. ;-) >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>>>> > >> >>>>> > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood >> >>>>> > wrote: >> >>>>> > >> >>>>> > =A0 =A0 On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote= : >> >>>>> > =A0 =A0 > The problem you see is that a virtual world is much mo= re >> >>>>> > than >> >>>>> > just a >> >>>>> > =A0 =A0 Region >> >>>>> > =A0 =A0 > Domain. =A0It is a complete set of services of which t= he >> >>>>> > Region >> >>>>> > Domain >> >>>>> > =A0 =A0 service is >> >>>>> > =A0 =A0 > just one. =A0Other typical services might be those of = the >> >>>>> > Agent >> >>>>> > Domain >> >>>>> > =A0 =A0 (which >> >>>>> > =A0 =A0 > provides identification and authorization services and >> >>>>> > possibly >> >>>>> > others), >> >>>>> > =A0 =A0 as >> >>>>> > =A0 =A0 > well as asset and inventory services, IM and other >> >>>>> > communication >> >>>>> > =A0 =A0 services, and >> >>>>> > =A0 =A0 > maybe several more. >> >>>>> > >> >>>>> > =A0 =A0 Well... that is purely semantic. It is a way to define V= W, but >> >>>>> > not one that >> >>>>> > =A0 =A0 I've been using :/ >> >>>>> > >> >>>>> > =A0 =A0 For simplicity, assume that only two things are needed t= o >> >>>>> > create >> >>>>> > a complete >> >>>>> > =A0 =A0 virtual world, like SL or OG: A Region Domain (RD) and a= n >> >>>>> > Agent >> >>>>> > Domain >> >>>>> > =A0 =A0 (AD). >> >>>>> > >> >>>>> > =A0 =A0 Currently, without any interop, each administrative enti= ty (or >> >>>>> > trust >> >>>>> > =A0 =A0 entity) >> >>>>> > =A0 =A0 will need to provide both: an RD *and* an AD, otherwise = they >> >>>>> > don't have a >> >>>>> > =A0 =A0 functional VW. >> >>>>> > >> >>>>> > =A0 =A0 Your conclusion is that a VW exist of both 1 RD and 1 AD= . But >> >>>>> > I >> >>>>> > ask you to >> >>>>> > =A0 =A0 reconsider if that conclusion is correct, because it is = based >> >>>>> > on >> >>>>> > the >> >>>>> > =A0 =A0 current >> >>>>> > =A0 =A0 situation without any interop. Now "correct" might not b= e the >> >>>>> > correct word >> >>>>> > =A0 =A0 - heh. >> >>>>> > =A0 =A0 Rather I should say: I ask you to reconsider if that >> >>>>> > definition >> >>>>> > is very >> >>>>> > =A0 =A0 useful. >> >>>>> > >> >>>>> > =A0 =A0 Lets consider the following fictive case: >> >>>>> > >> >>>>> > =A0 =A0 LL runs one RD and AD, called RD1 and AD1. >> >>>>> > =A0 =A0 CB (Cable Beach) runs another RD and AD, called RD2 and = AD2. >> >>>>> > =A0 =A0 A user that authenticates with either AD1 or AD2 can tra= vel to >> >>>>> > RD1 AND RD2, >> >>>>> > =A0 =A0 completely symmetrical, keeping their respective AD1- an= d AD2- >> >>>>> > assets etc. >> >>>>> > =A0 =A0 This is possible with the right policies, so for the sak= e of >> >>>>> > looking at >> >>>>> > =A0 =A0 the usefulness of the above definition of VW, assume thi= s is >> >>>>> > the >> >>>>> > case. >> >>>>> > >> >>>>> > =A0 =A0 Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" t= o be >> >>>>> > another VW? >> >>>>> > =A0 =A0 Or do you think it would make most sense in THIS case to= speak >> >>>>> > of >> >>>>> > a single >> >>>>> > =A0 =A0 VW? >> >>>>> > >> >>>>> > =A0 =A0 I think this is what Infinity means when she says that >> >>>>> > "virtual >> >>>>> > world" >> >>>>> > =A0 =A0 cannot >> >>>>> > =A0 =A0 be defined, because what could be perceived as being a V= W is >> >>>>> > highly >> >>>>> > =A0 =A0 dependend >> >>>>> > =A0 =A0 on the exact situation (and policies) and in certain >> >>>>> > configuration that are >> >>>>> > =A0 =A0 not as clear as the current situation (no interop) or th= e >> >>>>> > above >> >>>>> > example >> >>>>> > =A0 =A0 (100% >> >>>>> > =A0 =A0 interop). >> >>>>> > >> >>>>> > =A0 =A0 In one of my first posts about this topic I stated that >> >>>>> > "virtual >> >>>>> > world" >> >>>>> > =A0 =A0 should >> >>>>> > =A0 =A0 be considered to be the Region Domain (although I didn't= use >> >>>>> > that >> >>>>> > term at >> >>>>> > =A0 =A0 the >> >>>>> > =A0 =A0 moment) and be completely independent of the Agent Domai= n, >> >>>>> > based >> >>>>> > on typical >> >>>>> > =A0 =A0 cases of abuse and griefing etc: if anyone annoys some o= ther >> >>>>> > user, or >> >>>>> > =A0 =A0 breaks >> >>>>> > =A0 =A0 almost any ToS, it will be region based; which is why I'= ve >> >>>>> > always >> >>>>> > said that >> >>>>> > =A0 =A0 any type of abuse can and should be handled at the sim (= single >> >>>>> > region) >> >>>>> > =A0 =A0 level: >> >>>>> > =A0 =A0 the estate owner and managers in SL, even, but that idea >> >>>>> > definitely extends >> >>>>> > =A0 =A0 to "world administrations": the people running the REGIO= N >> >>>>> > (domain) is the >> >>>>> > =A0 =A0 one >> >>>>> > =A0 =A0 that should decide what is the local ToS and deal with a= buse >> >>>>> > etc. >> >>>>> > That is >> >>>>> > =A0 =A0 why I strongly argue to define "virtual world" as Region >> >>>>> > Domain, >> >>>>> > and leave >> >>>>> > =A0 =A0 the AD out of it. Nevertheless, now I have the term "Reg= ion >> >>>>> > Domain" I don't >> >>>>> > =A0 =A0 need "virtual world" anymore. >> >>>>> > >> >>>>> > =A0 =A0 > In our new protocol, these services may either be >> >>>>> > implemented >> >>>>> > internally >> >>>>> > =A0 =A0 within >> >>>>> > =A0 =A0 > a virtual world, or some might be implemented as exter= nal >> >>>>> > services >> >>>>> > =A0 =A0 offered by >> >>>>> > =A0 =A0 > third parties, the choice being a policy and design de= cision >> >>>>> > for each >> >>>>> > =A0 =A0 world >> >>>>> > =A0 =A0 > operator. =A0In all cases however, the virtual worlds = are >> >>>>> > defined >> >>>>> > by a set >> >>>>> > =A0 =A0 of >> >>>>> > =A0 =A0 > services, and not just by a Region Domain. >> >>>>> > >> >>>>> > =A0 =A0 I'm afraid that is purely a matter of opinion. I agree t= hat it >> >>>>> > is >> >>>>> > likely >> >>>>> > =A0 =A0 that a single 'administrative entity' that runs a RD wil= l also >> >>>>> > run an AD >> >>>>> > =A0 =A0 and allow users authenticated with their AD visit their = RD, >> >>>>> > but >> >>>>> > it is no >> >>>>> > =A0 =A0 more than *likely*. There will almost certainly be servi= ce >> >>>>> > provides that >> >>>>> > =A0 =A0 ONLY run an AD, and don't have a RD! And I can imagine t= hat >> >>>>> > there >> >>>>> > will >> >>>>> > =A0 =A0 be some that only run a RD and do not care about running= their >> >>>>> > own AD. >> >>>>> > >> >>>>> > =A0 =A0 Therefore, "virtual world" cannot be synonym for "the se= t of >> >>>>> > services >> >>>>> > =A0 =A0 run by a single administrative entity" as you seem to ar= gue, >> >>>>> > and >> >>>>> > at >> >>>>> > =A0 =A0 the SAME time be argued to include an RD *and* AD at all >> >>>>> > times. >> >>>>> > >> >>>>> > =A0 =A0 > This is easy to see by looking at a couple of archetyp= al >> >>>>> > examples in this >> >>>>> > =A0 =A0 > space: >> >>>>> > =A0 =A0 > >> >>>>> > =A0 =A0 > >> >>>>> > =A0 =A0 > =A0 =A0 Is Second Life a virtual world? =A0Undoubtedly= . =A0Is Second >> >>>>> > Life just a >> >>>>> > =A0 =A0 Region >> >>>>> > =A0 =A0 > =A0 =A0 Domain (assuming it were implemented using VWR= AP)? =A0No, >> >>>>> > of >> >>>>> > course >> >>>>> > =A0 =A0 not, SL >> >>>>> > =A0 =A0 > =A0 =A0 includes all of the services mentioned above, = and >> >>>>> > others. >> >>>>> > >> >>>>> > =A0 =A0 Of course, LL happens to run all services that are neede= d to >> >>>>> > create one >> >>>>> > =A0 =A0 virtual world; there are no third parties they can hire = from >> >>>>> > yet, >> >>>>> > so they >> >>>>> > =A0 =A0 have to provide it all themselves. >> >>>>> > >> >>>>> > =A0 =A0 But after SL implemented VWRAP they might decide to do a= way >> >>>>> > from >> >>>>> > one of >> >>>>> > =A0 =A0 their services and only keep their RD. Unlikely, but pos= sible. >> >>>>> > >> >>>>> > =A0 =A0 > =A0 =A0 Is OSgrid a virtual world? =A0Undoubtedly. =A0= Is OSgrid just >> >>>>> > a >> >>>>> > Region >> >>>>> > =A0 =A0 Domain >> >>>>> > =A0 =A0 > =A0 =A0 (assuming it were implemented using VWRAP)? = =A0No, of >> >>>>> > course >> >>>>> > not, it >> >>>>> > =A0 =A0 > =A0 =A0 currently runs all the UGAIM services, which i= n a VWRAP >> >>>>> > context would >> >>>>> > =A0 =A0 > =A0 =A0 become similar to those of Second Life. >> >>>>> > >> >>>>> > =A0 =A0 Exact same argument. >> >>>>> > >> >>>>> > =A0 =A0 > So you see, the idea that has been floated which claim= s that >> >>>>> > "VW =3D=3D RD" >> >>>>> > =A0 =A0 is >> >>>>> > =A0 =A0 > completely wrong, and misrepresents what constitutes a >> >>>>> > "virtual >> >>>>> > world" >> >>>>> > =A0 =A0 despite >> >>>>> > =A0 =A0 > the very clear examples before us. >> >>>>> > >> >>>>> > =A0 =A0 If you want to put it that way (including everything abo= ve >> >>>>> > that >> >>>>> > you said) >> >>>>> > =A0 =A0 then >> >>>>> > =A0 =A0 I have to side with Infinity: you cannot define a virtua= l >> >>>>> > world >> >>>>> > that way >> >>>>> > =A0 =A0 and >> >>>>> > =A0 =A0 use it for useful discussions regarding VWRAP. >> >>>>> > >> >>>>> > =A0 =A0 In the end, one virtual world as defined by "all service= s >> >>>>> > together to make >> >>>>> > =A0 =A0 things work" will be, or can be, a mix of many RD's and = many >> >>>>> > AD's >> >>>>> > with a >> >>>>> > =A0 =A0 complex >> >>>>> > =A0 =A0 web of trust/non-trust between them that makes the conce= pt of >> >>>>> > "virtual >> >>>>> > =A0 =A0 world" >> >>>>> > =A0 =A0 rather fuzzy at best. >> >>>>> > >> >>>>> > =A0 =A0 [...] >> >>>>> > =A0 =A0 > As we move into analysis of the problem space, these i= ssues >> >>>>> > will be >> >>>>> > =A0 =A0 > disentangled and clarified and the protocols will be d= efined >> >>>>> > and evolve, >> >>>>> > =A0 =A0 but >> >>>>> > =A0 =A0 > from the current OGP perspective there is no symmetric= al >> >>>>> > relationship >> >>>>> > =A0 =A0 possible >> >>>>> > =A0 =A0 > between VWs that could be described as "peering". =A0I= t is the >> >>>>> > asymmetry of >> >>>>> > =A0 =A0 the >> >>>>> > =A0 =A0 > VW-RD relationship that has been the crux of the "no V= W >> >>>>> > interop" issue. >> >>>>> > =A0 =A0 For >> >>>>> > =A0 =A0 > symmetrical peering, the protocol would need to mentio= n at >> >>>>> > least two >> >>>>> > =A0 =A0 > communicating VWs. >> >>>>> > >> >>>>> > =A0 =A0 You can about peering with just two RD's and one AD, or = one RD >> >>>>> > and two >> >>>>> > =A0 =A0 AD's. >> >>>>> > >> >>>>> > =A0 =A0 > Of course the situation could change as the protocol >> >>>>> > evolves. >> >>>>> > =A0For >> >>>>> > =A0 =A0 example, >> >>>>> > =A0 =A0 > once or twice we have heard mention that multiple ADs = could >> >>>>> > be >> >>>>> > involved >> >>>>> > =A0 =A0 in some >> >>>>> > =A0 =A0 > way, and it seems certain that communication services = from >> >>>>> > multiple VWs >> >>>>> > =A0 =A0 will be >> >>>>> > =A0 =A0 > merged because residents demand this. =A0This would st= art to >> >>>>> > take >> >>>>> > us into >> >>>>> > =A0 =A0 VW-VW >> >>>>> > =A0 =A0 > interop territory. =A0However, there is no such thing = in VWRAP >> >>>>> > currently, >> >>>>> > =A0 =A0 and >> >>>>> > =A0 =A0 > it's not in the list of deliverables to include it, an= d >> >>>>> > therefore we >> >>>>> > =A0 =A0 cannot say >> >>>>> > =A0 =A0 > that VWRAP will provide VW-VW interop at all. =A0For n= ow. ;-) >> >>>>> > >> >>>>> > =A0 =A0 I can't comment on that cause I didn't see VWRAP yet, bu= t from >> >>>>> > the >> >>>>> > =A0 =A0 charter and the comments on this list I'd think that ful= l >> >>>>> > support >> >>>>> > =A0 =A0 for interop between any number of RD's and AD's is inten= ded. >> >>>>> > >> >>>>> > =A0 =A0 -- >> >>>>> > =A0 =A0 Carlo Wood >> >>>>> > >> >>>>> > >> >>>>> >> >>>>> > _______________________________________________ >> >>>>> > ogpx mailing list >> >>>>> > ogpx@ietf.org >> >>>>> > https://www.ietf.org/mailman/listinfo/ogpx >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Carlo Wood >> >>>>> _______________________________________________ >> >>>>> ogpx mailing list >> >>>>> ogpx@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/ogpx >> >>>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> ogpx mailing list >> >>> ogpx@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/ogpx >> >>> >> >> >> >> >> >> _______________________________________________ >> >> ogpx mailing list >> >> ogpx@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ogpx >> >> >> > >> > >> > _______________________________________________ >> > ogpx mailing list >> > ogpx@ietf.org >> > https://www.ietf.org/mailman/listinfo/ogpx >> > >> > > > From infinity@lindenlab.com Thu Oct 1 15:32:53 2009 Return-Path: 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 010D13A679F for ; Thu, 1 Oct 2009 15:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=-1.271, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, SARE_FWDLOOK=1.666] 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 jF6S06oLKXWq for ; Thu, 1 Oct 2009 15:32:49 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 190CA28C19F for ; Thu, 1 Oct 2009 15:32:49 -0700 (PDT) Received: by pzk35 with SMTP id 35so874654pzk.29 for ; Thu, 01 Oct 2009 15:34:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.29.17 with SMTP id g17mr726208rvj.211.1254436453872; Thu, 01 Oct 2009 15:34:13 -0700 (PDT) In-Reply-To: <472889.79438.qm@web82607.mail.mud.yahoo.com> References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <472889.79438.qm@web82607.mail.mud.yahoo.com> Date: Thu, 1 Oct 2009 15:34:13 -0700 Message-ID: <3a880e2c0910011534r76d0edcbtf501f5e0aae86cfb@mail.gmail.com> From: Infinity Linden To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 22:32:53 -0000 right. VWRAP should be at least as functional as the old OGP stuff from summer 2008 (guess that's kind of a given.) i believe the decision process for what to work on back then was something = like: * you have to do auth before you can do anything else, so let's do auth * you have to do initial rez before you can do anything else in-world * and the way we've done initial rez in the past is as half of teleport, and that seemed to work, so let's to teleport sounds like you're adding: * it's nice to not look like ruth when you rez, so lets do appearance, a= nd * we really should know what name to put above your head, so let's discuss names. which are things i can get behind. i would add: * it's good to define trust so you know who you can give your assets ou= t to which will be necessary for the discussion on attachments. (frankly, i'm tired of showing up in vaak without my prim hair.) a proper discussion of trust will probably also include a discussion on deployment patterns, which zha has discussed many times in the past. i think the FirstLast@agent domain is a good hack for right now, and i'm thinking it _should_ be relatively easy to code. long term we may want to consider something more flexible, but right now, at this point, i'm happy to just move forward with Charles' name display proposal. what gets displayed above your avatar's head is really a matter for people writing clients, and i think they may want to have a "richer" experience in the future, but for the work at hand, of getting interop rolling again, it sounds like a good solution 'til we know that people want something different. -cheers -meadhbh On Thu, Oct 1, 2009 at 2:48 PM, Charles Krinke wrote: > > This seems like the right path to me, too. > > In thinking about this, lets consider saying that where two policies of t= wo > interoperable grids intersect is the interesting case. > > To take it back to SecondLife and say, an OpenSim grid, the first few thi= ngs > in an interop teleport are going to be avatarName and avatarAppearance. > > In thinking of how this may work, it would seem that we will probably end= up > with something like "FirstLast@SecondLife.com" when teleporting to, say > OSGrid from Secondlife to OSGrid and perhaps "FirstLast@OSGrid.org" when > teleporting from OSGrid to SecondLife. So, ... perhaps the policy may def= ine > the format of the name carried across in the teleport as it is reasonable= to > assume that an avatar in SecondLife does not have an account on OSGrid, a= nd > the converse is also true. > > Second, I suspect we need to define what happens when an avatar attempts = a > teleport with attachments (particularly scripted attachments). I rather > suspect that neither grid will wish to allow teleporting with scripting > attachments without a significant amount of negotiation between the two > corporations. > > As far as inventory goes, I rather suspect we wish to either avoid moving > inventory between grids, or, ... perhaps define a 'vanilla' subset such a= s > those items marked with 'export from grid, full permissions' bits set. I = am > taking that from memory in thinking about the additional bitfield for obj= ect > exports discussion on SecondLife a year or so ago. > > I am trying to think of the simplest cases that will have the minimum of > cussin, discussin and debate to get our minds wrapped around how to move > forward a bit. > > Certainly, I have my mind wrapped around Zha's statement a year or so ago > that went (if I recall more or less correctly): > > "We will have interop when I can slay a monster on WoW, teleport to a clu= b > in SecondLife, mount the monsters head on the wall and buy everyone a > drink". > > Charles > ________________________________ > From: Morgaine > To: ogpx@ietf.org > Sent: Thursday, October 1, 2009 2:34:10 PM > Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 > > On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell wrote: >> >> IMHO, it should be apparent that both AD (which is the agent/advocate fo= r >> the user) and RD (where the user wants to be) both need to make policy >> decisions. >> > > Excellent, Joshua! > > I think we're finally approaching the road towards Destination Determines > Policy now, which is a prerequisite for real interop between virtual > worlds.=A0 This was simply not possible with the old OGP thinking in whic= h > policy was given by a "trust domain" defined by a single AD alone. > > It's a two-part problem.=A0 Naturally your source world can impose > restrictions on travel (a walled garden may disallow any foreign travel a= t > all, for example), that's clear.=A0 What hasn't been clear until now is t= hat > the destination world will have conditions which are every bit as strong = and > important as the source world, and represented in the same way (eg. in th= eir > AD).=A0 Both sides must be allowed equivalent representation in the proto= col. > > This is why the single-world terminology was such a barrier earlier.=A0 I= t > completely prevented us from bringing the two worlds into the discussion > simultaneously, which is necessarily when both source and destination are > completely equivalent peer worlds. > > Your next step is to realize that, for two structurally identical worlds,= if > the seat of policy of one lies in its AD, then the seat of policy of the > other also lies in its AD.=A0 Therefore your statement needs to be modifi= ed to > the following: > > IMHO, it should be apparent that both the AD of the source world and the = RD > and AD of the destination world all need to make policy decisions. > > > What's true for the source world is also true for the destination world, > policy-wise.=A0 The destination world is not "inferior" in any way.=A0 It= 's a > necessary peer in the protocol.=A0 You can't exclude it from the equation= . > > > Morgaine. > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Wed, Sep 30, 2009 at 5:10 PM, Joshua Bell wrote: >> >> Without diving in too deep, I believe this thread is putting up a >> two-level false dichotomy - either the RD determines policy or the AD >> determines policy, OR things aren't sensible w/o nil trust. If that's a >> mis-reading, my apologies. >> >> IMHO, it should be apparent that both AD (which is the agent/advocate fo= r >> the user) and RD (where the user wants to be) both need to make policy >> decisions. >> >> A corporate AD may restrict where users may visit (e.g. >> agentd.corp.example.com may say "no visiting party.example.com from work= !") >> or an AD may restrict users based on personal preferences >> (agentd.safesurf.example.com may say "scam.example.com is on a shared >> blacklist of malicious sites, teleport blocked"), legal or political >> requirements (agentd.kidfriendly.example.com may say "you can't visit >> adultgrid.example.com"). Note that in all cases the AD is enforcing poli= cy >> as an agent of the user, just as a web browser on a local network does >> today. Presumably, there will exist many ADs that provide no restriction= s >> whatsoever, just as most Web browsers accessing the 'net via most ISPs i= n >> most countries today don't restrict access to Web content via policy. >> >> On the flip side, the RD will also have policy. Corporate VWs may limit >> access to employees. Adult-centric VWs may limit access to agents from A= Ds >> that verify accounts with some well known service. >> Real-world-region-specific RDs may require citizenship checks and deny >> access to citizens of some nation-states. And of course permissions woul= d >> doubtless exist on a per-user basis as well as per-AD. Again - no differ= ent >> than access permissions today on the Web, except that instead of being a >> two-party user/service, it's three party user/AD/RD. And one hopes that, >> like most of the Web, content is freely visitable by all. >> >> On the topic of nil-trust: again, I wholeheartedly support the stance th= at >> the protocol should support nil trust operation. I hope that both the >> protocol and operations of VWRAP-based worlds allow the bulk of VWRAP >> traffic to occur in a nil trust environment, just like the Web does toda= y. >> However, I *suspect* that, in practical terms, the abilities we want to >> grant to regions by visiting them - to display our avatars, to broadcast >> information about our agents, to give and receive virtual goods - will >> require at least a modicum of trust for most VW interaction, at least on= the >> level of an SSL-style secured connection that gives users a certificate = to >> look at that provides some identity/trust information about the service >> provider. >> >> I suspect I'm going to beat this drum a lot - "VWs are just like the Web= , >> except where they're different" :) >> >> On Tue, Sep 29, 2009 at 5:51 PM, Morgaine >> wrote: >>> >>> Hi Vaughn! :-) >>> >>> Your description of our discussion is quite accurate.=A0 However, it se= ems >>> to imply that I advocate in favour of the view that the AD must be the = seat >>> of all policy for connected regions.=A0 I do not.=A0 I was merely expla= ining the >>> architecture of AD+RD pairing as it has been described to us repeatedly >>> throughout the two years of our OGP-related work in the LL+IBM sponsore= d >>> Architecture Working Group within Second Life. >>> >>> After the emails, Carlo and I examined this issue with higher discussio= n >>> bandwidth inside SL, and it turned out that we were describing two diff= erent >>> things:=A0 I was explaining the AD+RD relationship in OGP, while Carlo = was >>> describing RDs as they should be designed if an RD were an autonomous u= nit >>> with its own policies, effectively a small world.=A0 If OGP were design= ed >>> differently and less restrictively to allow that, then there would have= been >>> no discussion.=A0 :-) >>> >>> Of course, OGP is not VWRAP, but only the seedcorn for VWRAP.=A0 We can >>> make VWRAP as flexible as we like, and it's easy to see its potential >>> flexibility in David's deployments document.=A0 Consequently, I have hi= gh >>> hopes that all parties will be happy with the eventual outcome. :-) >>> >>> You may have missed the primary reason why I do not advocate a design i= n >>> which an OGP-style AD is the seat of all power, possibly because the >>> discussion has been spread out across all of OGPX and MMOX.=A0 It's eas= y to >>> summarize in one sentence though:=A0 such a design cannot underpin an >>> Internet-wide metaverse of interoperating virtual worlds because it doe= sn't >>> respect the key meme of virtual and non-virtual tourism:=A0 Destination >>> Determines Policy. >>> >>> This meme is so fundamental and crucial (and obvious) that OGP's suppor= t >>> of the exact opposite is terminally broken, as a basis for the hypothet= ical >>> metaverse.=A0 Indeed, you yourself have referred to the problem in the = funny >>> "war over purple". :-)=A0 At best such a design can support only a rand= om >>> scattering of VPN-like walled gardens, all isolated and incapable of >>> interoperating because they all claim the "one true policy".=A0 We shou= ld not >>> go there. >>> >>> The most recent description of this problematic aspect of the OGP desig= n >>> was posted by Magnus Zeisig in his excellent email at >>> http://www.ietf.org/mail-archive/web/ogpx/current/msg00324.html , which= I >>> fully support.=A0 Such balkanization is not a desireable goal when desi= gning a >>> VW interop protocol. >>> >>> So where are we now?=A0 We're at the stage of examining David's VWRAP >>> deployment patterns to see how the protocol can support them.=A0 And in= that >>> examination, it is likely to become clear that the old OGP model of "AD >>> determines policy" is completely non-viable for interoperating between >>> VWRAP-compatible virtual worlds, except when that policy is "nil trust"= as a >>> common denominator. >>> >>> Consequently, we will either decide to live with the original OGP split >>> and use "nil trust" as our basis for VW interop, or else we will redesi= gn >>> the AD/RD relationship to place many more important policy decisions wh= ere >>> they really belong, at destination.=A0 The latter seems the best choice= to me, >>> and of course it would make Carlo happy, and it is also the model that = every >>> single existing world already operates --- when in Rome, do as the Roma= ns >>> do.=A0 Only the old OGP AD/RD two-way split design is out of step.=A0 L= et's hope >>> that we can correct that in VWRAP. :-)) >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> On Tue, Sep 29, 2009 at 9:16 PM, Vaughn Deluca >>> wrote: >>>> >>>> Carlo and Morgaine have above been involved in a very interesting >>>> discussion about the nature of the (or *a*) virtual world. >>>> Painting their positions with =A0broad strokes, Morgaine stresses the >>>> primary role of the AD as the seat of policy and trust, up to the poin= t >>>> where he denies the RD any role above that of a convenient extension o= f the >>>> AD, i.e. the RD as "colony without a government". Carlo passionately a= rgues >>>> for the independent role of the RD in policy issues. >>>> I feel that both positions are valid (to some degree), and both can be >>>> covered by VWRAP. >>>> Calo makes absolutely clear that having all policy in the respective A= Ds >>>> of the avatars leads to problems when several avatars meet in one regi= on >>>> domain, say RD1. Avatars will be busy killing each other over the righ= t to >>>> wear purple, and for the innocent bystanders caught in the crossfire i= t will >>>> be fully unclear were to complain. Stepping in Morgaines shoes, i thin= k i >>>> would argue that what Carlo asks for can be realised by applying the p= olicy >>>> of a *particular* AD to RD1. The rules to deal with color of clothes, = could >>>> be formulated in AD1 associated with RD1. In principle Carlo could run= this >>>> domain himself, even without a single avatar in it, and in this way ge= t his >>>> "government" and set any policy he wants. If two avatars from AD2 and = AD3 >>>> visit RD1, The policy in RD1 would be governed by what is specified by= AD1. >>>> While this fully fits Morgaines view of "AD rules all", and also fits >>>> Carlo call for autonomy of RD1, it feels decidedly like a kludge, and = in >>>> this particular case it seems much more straightforward to make RD1 mo= re >>>> autonomous. Yet, to keep everything within one framework, this kludge = seems >>>> to be the logical solution... I would like to hear what others think a= bout >>>> this. >>>> One other remark: the minimal example for =A0a "world" =A0-one AD and = one >>>> RD- would be more useful when extended with one asset service AS. Expl= icit >>>> mentioning of the AS will make it much easier to discuss IP issues. >>>> Vaughn >>>> >>>> >>>> On Mon, Sep 14, 2009 at 10:44 AM, Carlo Wood wrote: >>>>> >>>>> On Mon, Sep 14, 2009 at 06:43:06AM +0100, Morgaine wrote: >>>>> > Carlo asked for detailed comments on the below, so here goes. :-) >>>>> > >>>>> > >>>>> > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood wrote= : >>>>> > >>>>> > =A0 =A0 On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote: >>>>> > =A0 =A0 > The problem you see is that a virtual world is much more = than >>>>> > just a >>>>> > =A0 =A0 Region >>>>> > =A0 =A0 > Domain. =A0It is a complete set of services of which the = Region >>>>> > Domain >>>>> > =A0 =A0 service is >>>>> > =A0 =A0 > just one. =A0Other typical services might be those of the= Agent >>>>> > Domain >>>>> > =A0 =A0 (which >>>>> > =A0 =A0 > provides identification and authorization services and po= ssibly >>>>> > others), >>>>> > =A0 =A0 as >>>>> > =A0 =A0 > well as asset and inventory services, IM and other >>>>> > communication >>>>> > =A0 =A0 services, and >>>>> > =A0 =A0 > maybe several more. >>>>> > >>>>> > =A0 =A0 Well... that is purely semantic. It is a way to define VW, = but >>>>> > not one that >>>>> > =A0 =A0 I've been using :/ >>>>> > >>>>> > >>>>> > It's a rough top-level projection of the architectural model of >>>>> > VWRAP, once the >>>>> > various services have been decoupled in the way that David Levine >>>>> > often >>>>> > describes to us. =A0Nothing very contentious there, everyone likes = a >>>>> > services-oriented approach. :-) >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 For simplicity, assume that only two things are needed to c= reate >>>>> > a complete >>>>> > =A0 =A0 virtual world, like SL or OG: A Region Domain (RD) and an A= gent >>>>> > Domain >>>>> > =A0 =A0 (AD). >>>>> > >>>>> > >>>>> > I am happy to consider that simple scenario as representative. =A0I= t is >>>>> > quite >>>>> > reasonable to equate AD with VW because the AD is the focus of almo= st >>>>> > all the >>>>> > policy decisions of a VWRAP-based world. =A0When other decoupled >>>>> > services are >>>>> > added to this picture, it doesn't change the fundamental architectu= re >>>>> > of AD + >>>>> > RDs, only extends it by decoupling more than just the region servic= e. >>>>> > =A0So >>>>> > that's fine with me. >>>>> >>>>> I totally disagree that the AD is the representative...and why do you >>>>> say >>>>> that below a sentence of me where I say "A Region Domain (RD) and an >>>>> Agent Domain (AD)"? >>>>> >>>>> This is like I say "VW =3D AD + RD", and you go: "yes, VW =3D AD". We= can't >>>>> have a discussion like that Morgaine. >>>>> >>>>> > =A0 =A0 Currently, without any interop, each administrative entity = (or >>>>> > trust >>>>> > =A0 =A0 entity) >>>>> > =A0 =A0 will need to provide both: an RD *and* an AD, otherwise the= y >>>>> > don't have a >>>>> > =A0 =A0 functional VW. >>>>> > >>>>> > >>>>> > Correct. =A0The AD is the seat of most (but not all) of the policy >>>>> > decisions of a >>>>> >>>>> I even *stressed* the '*and*' here, and you do it again. >>>>> >>>>> > VW, so it's very central to the existence of a VW. =A0While it's >>>>> > possible to >>>>> > imagine policy-free VWs that temporarily =A0take on the policy of a= ny >>>>> > other world >>>>> > they hook up with, this is clearly a subset situation. =A0All the >>>>> > currently known >>>>> > SL-like virtual worlds are grids of the SL kind, with their own >>>>> > individual >>>>> > policies which they are not going to change on interop. >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 Your conclusion is that a VW exist of both 1 RD and 1 AD. B= ut I >>>>> > ask you to >>>>> > =A0 =A0 reconsider if that conclusion is correct, because it is bas= ed on >>>>> > the >>>>> > =A0 =A0 current >>>>> > =A0 =A0 situation without any interop. Now "correct" might not be t= he >>>>> > correct word >>>>> > =A0 =A0 - heh. >>>>> > =A0 =A0 Rather I should say: I ask you to reconsider if that defini= tion >>>>> > is very >>>>> > =A0 =A0 useful. >>>>> > >>>>> > =A0 =A0 Lets consider the following fictive case: >>>>> > >>>>> > =A0 =A0 LL runs one RD and AD, called RD1 and AD1. >>>>> > =A0 =A0 CB (Cable Beach) runs another RD and AD, called RD2 and AD2= . >>>>> > =A0 =A0 A user that authenticates with either AD1 or AD2 can travel= to >>>>> > RD1 AND RD2, >>>>> > =A0 =A0 completely symmetrical, keeping their respective AD1- and A= D2- >>>>> > assets etc. >>>>> > =A0 =A0 This is possible with the right policies, so for the sake o= f >>>>> > looking at >>>>> > =A0 =A0 the usefulness of the above definition of VW, assume this i= s the >>>>> > case. >>>>> > >>>>> > >>>>> > That's not quite right because Cable Beach is not a world provider >>>>> > like LL. >>>>> > Cable Beach is perhaps best described as a "login mediation" >>>>> > mechanism or >>>>> >>>>> I might not understand what the real Cable Beach is or wants to be, I >>>>> was just >>>>> trying to give an example to work with. So, again: >>>>> >>>>> LL runs one RD and AD, called RD1 and AD1. >>>>> OG runs another RD and AD, called RD2 and AD2. >>>>> A user that authenticates with either AD1 or AD2 can travel to RD1 AN= D >>>>> RD2, >>>>> completely symmetrical, keeping their respective AD1- and AD2- assets >>>>> etc. >>>>> This is possible with the right policies, so for the sake of looking = at >>>>> the usefulness of the above definition of VW, assume this is the case= . >>>>> >>>>> > protocol, which provides a model for interaction between a "world >>>>> > service" >>>>> > (effectively an AD), the user's client, and various decoupled >>>>> > services such as >>>>> > simulation nodes (possibly an RD) and inventory/asset services. >>>>> > =A0Let's assume >>>>> > therefore that your "CB" above means something different (another >>>>> > world >>>>> > provider similar to LL), and then we can proceed with your example >>>>> > case. >>>>> >>>>> Ok >>>>> >>>>> > =A0 =A0 Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to b= e >>>>> > another VW? >>>>> > =A0 =A0 Or do you think it would make most sense in THIS case to sp= eak of >>>>> > a single >>>>> > =A0 =A0 VW? >>>>> > >>>>> > >>>>> > They're two worlds because you defined them as such, as each has it= s >>>>> > own AD. >>>>> > :-) =A0But that aside, if they were set up separately then they hav= e >>>>> > two >>>>> > different sets of policies, two different sets of residents, two >>>>> > different >>>>> > ToS's, possibly two different legal jurisdictions, two different >>>>> > mechanisms for >>>>> > abuse control and conflict resolution, and so on and so forth. =A0I= f >>>>> > they were >>>>> > created to be worlds that can stand alone but interoperate when >>>>> > desired, then >>>>> > each of these is a diffferent world. =A0I don't see how that can be >>>>> > disputed. >>>>> >>>>> As I stated in one of my first posts, it will (hopefully!!!) be mainl= y >>>>> the >>>>> the *RD* and NOT the AD that all of those things are a function of! >>>>> >>>>> You keep saying that it's mainly the AD that determines these things, >>>>> but >>>>> that would be confusing and very annoying. If two people meet in a >>>>> virtual >>>>> world, that is - if they are standing next to eachother in one region >>>>> and >>>>> using local chat - then they should fall under the same legal >>>>> jurisdiction >>>>> and the same ToS: it is the region that determines the rules, not the >>>>> AD >>>>> that they used to login with. >>>>> >>>>> As example, ToS1 says: it's ok to be naked; and ToS2 says: it's a >>>>> bannable >>>>> offence to be naked. Do you really think that it's even workable if t= he >>>>> ToS to be applied is a function of the AD? Say you login using AD2, s= o >>>>> ToS2 applies to you. You meet someone else that is naked. You know th= at >>>>> you are not allowed to and you are offended. You create an abuse >>>>> report; >>>>> where does that report go to? To your AD administration? That makes n= o >>>>> sense: that naked person is using a different AD. To his/her AD >>>>> administration >>>>> then? That makes also no sense since they allow it. >>>>> >>>>> Seriously, there is only one reasonable thing to do: the ToS that >>>>> applies >>>>> is a function of the Region Domain *only*, and if you write an abuse >>>>> report, >>>>> it should go to the administration of the region that you are in and >>>>> not >>>>> to your or the others AD administration. Same holds for the things >>>>> related >>>>> to legal jurisdiction and any other 'rules' that applies at any given >>>>> moment (to users). The only thing that might be a function of the AD >>>>> are >>>>> technical policies that are automatically enforced by VWRAP. >>>>> >>>>> > =A0 =A0 I think this is what Infinity means when she says that "vir= tual >>>>> > world" >>>>> > =A0 =A0 cannot >>>>> > =A0 =A0 be defined, because what could be perceived as being a VW i= s >>>>> > highly >>>>> > =A0 =A0 dependend >>>>> > =A0 =A0 on the exact situation (and policies) and in certain >>>>> > configuration that are >>>>> > =A0 =A0 not as clear as the current situation (no interop) or the a= bove >>>>> > example >>>>> > =A0 =A0 (100% >>>>> > =A0 =A0 interop). >>>>> > >>>>> > >>>>> > This is incorrect. =A0"Virtual world" is defined by each provider o= f a >>>>> > virtual >>>>> > world and by nobody else, and each provider knows full well how it = is >>>>> > defined, >>>>> > what its boundaries are, and what makes it distinct. =A0Nobody else= can >>>>> > define >>>>> > what a virtual world is, and it's not our business to define it >>>>> > either (nor to >>>>> > conjure up a fictitious definition). >>>>> >>>>> Sorry, but I think you should try harder to understand my point of vi= ew >>>>> first. >>>>> I didn't give the examples so you can ignore them. >>>>> >>>>> > We only need to define the protocol interactions at the endpoints >>>>> > presented by >>>>> > those worlds, and not to define "virtual world" structurally nor an= y >>>>> > other way. >>>>> > =A0 Doing so is what has got us into this mess, by creating a >>>>> > fictitious >>>>> > definition based on reachability and hence blocking any ability to >>>>> > talk about >>>>> > actual virtual worlds. =A0Those worlds exist. =A0They won't go away= . >>>>> > =A0They want to >>>>> > interoperate, but they don't want to be told that they don't exist. >>>>> >>>>> I was trying to make you understand WHY Infinitely tells you they don= 't >>>>> "exist", >>>>> if you understand her (and you don't, imho) then it will be easier to >>>>> solve this >>>>> miscommunication. >>>>> >>>>> > The contention that we don't know what "virtual world" means is jus= t >>>>> > plain >>>>> > bizarre. >>>>> >>>>> Only if you already have a definition of "virtual world" they way you >>>>> do. >>>>> >>>>> > I don't know of any VW operator who doesn't know what their world i= s. >>>>> >>>>> That is the *current* situation... which is 100% simpler than what >>>>> we'll >>>>> have in the future. >>>>> >>>>> Compare with math... currently we only have Integers (Z). We're about >>>>> to introduce division and by that we need to extend the definition of >>>>> 'number' from Z to Q. Q aren't integers, even though currently every >>>>> number is an integer doesn't mean you have to hold on tight the >>>>> "definition" >>>>> of "number" =3D=3D integer. That definition will be broken and you wi= ll >>>>> have to redefine "number". >>>>> >>>>> > =A0 Every single one of them could provide the necessary endpoints = for >>>>> > VWRAP >>>>> > within their world without any scratching of heads at the meaning o= f >>>>> > "virtual >>>>> > world". =A0That repeated allegation has been a complete >>>>> > misrepresentation. =A0It's >>>>> > just not true. >>>>> >>>>> You CANNOT define "virtual world" as "AD" (see above) nor as "AD + RD= " >>>>> because >>>>> that is too simple and only holds in the current situation. You can >>>>> only, at most, >>>>> if you really want, say - well, lets define it as being some RD. >>>>> >>>>> > And possibly even worse is the excuse =A0that "virtual world" is no= t >>>>> > being >>>>> > defined but is being used non-normatively, while in practice using >>>>> > the phrase " >>>>> > the virtual world" to create a totally fictitious single virtual >>>>> > world instead. >>>>> >>>>> I agree that as long as it isn't normatively defined, the term >>>>> shouldn't be >>>>> used in documents except in places where it can literally mean anythi= ng >>>>> without >>>>> that anyone will care (like in the protocol name). >>>>> >>>>> > =A0 That phrase is unnecessary, it is misrepresentative of the actu= al >>>>> > situation, >>>>> > it bypasses policy controls of one world by not mentioning its AD, = it >>>>> > prevents >>>>> > us from mentioning virtual worlds by blocking the normal meaning of >>>>> > the term, >>>>> > and it provides nothing useful as a benefit in return. =A0Unless to= tal >>>>> > confusion >>>>> > is a benefit. ;-) >>>>> >>>>> Sorry, but that is like saying that defining the Rational Numbers (Q) >>>>> makes it >>>>> impossible to talk about 'numbers', because 3/7 isn't an integer. >>>>> What you have to do is let go of your current definition. >>>>> >>>>> > =A0 =A0 In one of my first posts about this topic I stated that "vi= rtual >>>>> > world" >>>>> > =A0 =A0 should >>>>> > =A0 =A0 be considered to be the Region Domain (although I didn't us= e that >>>>> > term at >>>>> > =A0 =A0 the >>>>> > =A0 =A0 moment) and be completely independent of the Agent Domain, = based >>>>> > on typical >>>>> > =A0 =A0 cases of abuse and griefing etc: if anyone annoys some othe= r >>>>> > user, or >>>>> > =A0 =A0 breaks >>>>> > =A0 =A0 almost any ToS, it will be region based; which is why I've = always >>>>> > said that >>>>> > =A0 =A0 any type of abuse can and should be handled at the sim (sin= gle >>>>> > region) >>>>> > =A0 =A0 level: >>>>> > =A0 =A0 the estate owner and managers in SL, even, but that idea >>>>> > definitely extends >>>>> > =A0 =A0 to "world administrations": the people running the REGION >>>>> > (domain) is the >>>>> > =A0 =A0 one >>>>> > =A0 =A0 that should decide what is the local ToS and deal with abus= e etc. >>>>> > That is >>>>> > =A0 =A0 why I strongly argue to define "virtual world" as Region Do= main, >>>>> > and leave >>>>> > =A0 =A0 the AD out of it. Nevertheless, now I have the term "Region >>>>> > Domain" I don't >>>>> > =A0 =A0 need "virtual world" anymore. >>>>> > >>>>> > >>>>> > But that's not how OGP is structured. =A0It's the AD that is the fo= cus >>>>> > of service >>>>> > policy choices in OGP, and it's the "world service" that is the foc= us >>>>> > of >>>>> > service policy in Cable Beach. =A0The AD and the world service are = the >>>>> > source of >>>>> > capabilities that determine pretty much everything else, and the >>>>> > region domain >>>>> > is very subsidiary to that. >>>>> >>>>> No, if the service prodiver of some AD disagrees with the (say) a ToS >>>>> that applies >>>>> when you go to some RD then they should disallow you go there; they >>>>> should not >>>>> allow you to go there and then demand that you follow their ToS, that >>>>> would not >>>>> be a practical solution that is workable. >>>>> >>>>> To use mathematics again, it's easy to make two ToS that have no >>>>> intersection: >>>>> Say, ToS1 says: you MUST wear purple clothes, and ToS2 says: you MUST >>>>> wear blue >>>>> clothes. Obviously those will apply to regions. >>>>> >>>>> So then we have: >>>>> >>>>> Provider1: RD1 --> TOS1 --> purple clothes >>>>> Provider2: RD2 --> TOS2 --> blue clothes >>>>> >>>>> *if* Provider 2 runs an AD (AD2) and they allow people logged in with >>>>> it >>>>> to go to region RD1 then the people there should wear purple clothes: >>>>> TOS2 will not apply because of the AD you use. >>>>> >>>>> If it's against providers religious believe to support wearing purple >>>>> clothes than they might disallow people to go to RD1, that is their >>>>> choice (policy). >>>>> >>>>> > Indeed, a region domain may have no policy of its >>>>> > own at all, but merely extend an existing virtual world by acceptin= g >>>>> > the >>>>> > policies of that world's AD. =A0That's the model in the original OG= P >>>>> > before it >>>>> > gained aspirations of becoming a cross-VW interop protocol. >>>>> >>>>> That makes no sense :/ >>>>> >>>>> There can be any number of people in a given RD, and each can in >>>>> principle >>>>> be using a different AD! PLEASE let the RD determine the rules they >>>>> have >>>>> to live by! Anyone else that disagrees with me about that?! >>>>> >>>>> > If RDs determined VW policy and generated seed capabilities for >>>>> > everything and >>>>> > ADs were merely login services then your model would apply, and RD >>>>> > could be >>>>> > considered "VW". >>>>> >>>>> Ah! At last.. >>>>> >>>>> > But that's not how it is currently structured --- RDs are >>>>> >>>>> If you are refering to OGP, then OGP should be changed. >>>>> >>>>> > merely the land + physical simulation components of worlds, and in >>>>> > SL's case, >>>>> > also an elaborate system of proxies. =A0And that's why we need mult= iple >>>>> > ADs to >>>>> > interact in VWRAP before we can consider that there is VW-VW intero= p. >>>>> > =A0RDs >>>>> > don't handle it. >>>>> >>>>> What I seem to keep missing is the fact that VWRAP is already >>>>> completely >>>>> defined in those previous OGP documents and we're merely here to >>>>> rewrite >>>>> them in an IETF document of sorts. >>>>> >>>>> Yes we need multiple ADs to interact, and they will. >>>>> But yes, RD's will handle whatever they have to handle with VWRAP. >>>>> I never said that capabilities equal 'rules' (ToS and legal >>>>> jurisdiction >>>>> isn't something that should be enforced or controlled by the protocol= ) >>>>> by >>>>> the way. >>>>> >>>>> ... sorry my RSI forces me to stop typing here... shouldn't have >>>>> typed this much alrady anyway :( >>>>> >>>>> > =A0 =A0 > In our new protocol, these services may either be impleme= nted >>>>> > internally >>>>> > =A0 =A0 within >>>>> > =A0 =A0 > a virtual world, or some might be implemented as external >>>>> > services >>>>> > =A0 =A0 offered by >>>>> > =A0 =A0 > third parties, the choice being a policy and design decis= ion >>>>> > for each >>>>> > =A0 =A0 world >>>>> > =A0 =A0 > operator. =A0In all cases however, the virtual worlds are= defined >>>>> > by a set >>>>> > =A0 =A0 of >>>>> > =A0 =A0 > services, and not just by a Region Domain. >>>>> > >>>>> > >>>>> > Indeed. =A0But access to such decoupled services is provided by the= AD >>>>> > through >>>>> > the capabilities that it delivers to authorized parties, and region= s >>>>> > are just >>>>> > one such service. =A0You're giving RDs credit for something that th= ey >>>>> > don't do. >>>>> > :-) =A0Perhaps the VWRAP model should be redesigned along your line= s so >>>>> > that RDs >>>>> > become the VWs and are the generators of seed caps, and then ADs >>>>> > become just a >>>>> > subservient policy-free login mechanism. :D >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 I'm afraid that is purely a matter of opinion. I agree that= it is >>>>> > likely >>>>> > =A0 =A0 that a single 'administrative entity' that runs a RD will a= lso >>>>> > run an AD >>>>> > =A0 =A0 and allow users authenticated with their AD visit their RD,= but >>>>> > it is no >>>>> > =A0 =A0 more than *likely*. There will almost certainly be service >>>>> > provides that >>>>> > =A0 =A0 ONLY run an AD, and don't have a RD! And I can imagine that= there >>>>> > will >>>>> > =A0 =A0 be some that only run a RD and do not care about running th= eir >>>>> > own AD. >>>>> > >>>>> > >>>>> > Oh sure, there will be all combinations of services, that is to be >>>>> > expected. >>>>> > But it is the seat of policy that is the heart of each virtual worl= d, >>>>> > and >>>>> > currently the seat of policy lies in the AD. =A0A VW that doesn't h= ave >>>>> > an AD in >>>>> > the VWRAP model is just a colony without a government, ready to be >>>>> > assimilated >>>>> > into a world that has an AD and that therefore sets policies, inste= ad >>>>> > of being >>>>> > a sovereign world that merely wants to interop with that other worl= d >>>>> > through >>>>> > VWRAP. >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 Therefore, "virtual world" cannot be synonym for "the set o= f >>>>> > services >>>>> > =A0 =A0 run by a single administrative entity" as you seem to argue= , and >>>>> > at >>>>> > =A0 =A0 the SAME time be argued to include an RD *and* AD at all ti= mes. >>>>> > >>>>> > >>>>> > I don't follow that. =A0Two worlds that can run independently (that= 's >>>>> > very >>>>> > important) can certainly each be defined as a set of services that >>>>> > includes the >>>>> > functions of an AD and an RD, and those worlds each continue to >>>>> > include the >>>>> > functions of an AD and an RD even after they start interoperating >>>>> > (assuming >>>>> > that VWRAP is extended to allow cross-VW interop). =A0No world is g= oing >>>>> > to give >>>>> > up part of its services portfolio on interop. =A0Interop is an >>>>> > additional >>>>> > benefit, not a loss of capability. >>>>> > >>>>> > [It's worth noting that there may actually be a small loss of >>>>> > capability >>>>> > occurring on interop in VWRAP, although it is rarely mentioned. =A0= You >>>>> > can be >>>>> > present in two worlds simultaneously with the same login credential= s >>>>> > pre-interop (a feature that we enjoy currently between SL and OSgri= d >>>>> > for >>>>> > example), but post-interop this may no longer be possible --- it >>>>> > depends on the >>>>> > implementation. =A0No doubt we will visit this issue within VWRAP.] >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 > This is easy to see by looking at a couple of archetypal >>>>> > examples in this >>>>> > =A0 =A0 > space: >>>>> > =A0 =A0 > >>>>> > =A0 =A0 > >>>>> > =A0 =A0 > =A0 =A0 Is Second Life a virtual world? =A0Undoubtedly. = =A0Is Second >>>>> > Life just a >>>>> > =A0 =A0 Region >>>>> > =A0 =A0 > =A0 =A0 Domain (assuming it were implemented using VWRAP)= ? =A0No, of >>>>> > course >>>>> > =A0 =A0 not, SL >>>>> > =A0 =A0 > =A0 =A0 includes all of the services mentioned above, and= others. >>>>> > >>>>> > =A0 =A0 Of course, LL happens to run all services that are needed t= o >>>>> > create one >>>>> > =A0 =A0 virtual world; there are no third parties they can hire fro= m yet, >>>>> > so they >>>>> > =A0 =A0 have to provide it all themselves. >>>>> > >>>>> > =A0 =A0 But after SL implemented VWRAP they might decide to do away= from >>>>> > one of >>>>> > =A0 =A0 their services and only keep their RD. Unlikely, but possib= le. >>>>> > >>>>> > >>>>> > You're confusing RD functionality with AD functionality again there= . >>>>> > =A0The AD is >>>>> > the heart of a world because it defines its capabilities and >>>>> > policies. =A0The RD >>>>> > is just a pile of region hosts that could easily be farmed out to a >>>>> > third party >>>>> > to run without them determining policy, and indeed this is already >>>>> > being done. >>>>> > While it is a very important pile of hosts which gives a world its >>>>> > physical >>>>> > characterists, the RD is a subservient service to the AD in OGP, ju= st >>>>> > as the >>>>> > equivalent "simulation nodes" provide a subservient service to the >>>>> > "world >>>>> > service" under Cable Beach. =A0The RD is well named --- it provides >>>>> > region >>>>> > services only, not the package of internal + external services that >>>>> > together >>>>> > create a virtual world. >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 > =A0 =A0 Is OSgrid a virtual world? =A0Undoubtedly. =A0Is = OSgrid just a >>>>> > Region >>>>> > =A0 =A0 Domain >>>>> > =A0 =A0 > =A0 =A0 (assuming it were implemented using VWRAP)? =A0No= , of course >>>>> > not, it >>>>> > =A0 =A0 > =A0 =A0 currently runs all the UGAIM services, which in a= VWRAP >>>>> > context would >>>>> > =A0 =A0 > =A0 =A0 become similar to those of Second Life. >>>>> > >>>>> > =A0 =A0 Exact same argument. >>>>> > >>>>> > >>>>> > Exact same response because the same applies. :-) =A0 What's more, = in >>>>> > OSgrid this >>>>> > is even easier to identify, because every person or company that ad= ds >>>>> > regions >>>>> > to OSgrid is subscribing to the notion that they are participants i= n >>>>> > OSgrid --- >>>>> > OSgrid is their virtual world. =A0They are merely providing additio= nal >>>>> > land mass >>>>> > and simulation capacity. >>>>> > >>>>> > Also, in this example there is no need to hypothesize region servic= es >>>>> > being >>>>> > farmed out to third parties, as there already are hundreds to >>>>> > thousands of >>>>> > independent third parties involved in supplying regions. =A0Those >>>>> > regions and >>>>> > clusters of regions (equivalent to RDs) together combine to create >>>>> > the virtual >>>>> > world of OSgrid. =A0There is a clear distinction between R/RDs here= and >>>>> > the VW >>>>> > itself, which also includes a variety of other services as Charles >>>>> > has >>>>> > described several times. =A0The R/RDs are a very important part, bu= t >>>>> > functionally >>>>> > they are not the VW, nor are they the VW perceptually. =A0They are >>>>> > places within >>>>> > the world, not the whole world. >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 > So you see, the idea that has been floated which claims t= hat >>>>> > "VW =3D=3D RD" >>>>> > =A0 =A0 is >>>>> > =A0 =A0 > completely wrong, and misrepresents what constitutes a "v= irtual >>>>> > world" >>>>> > =A0 =A0 despite >>>>> > =A0 =A0 > the very clear examples before us. >>>>> > >>>>> > =A0 =A0 If you want to put it that way (including everything above = that >>>>> > you said) >>>>> > =A0 =A0 then >>>>> > =A0 =A0 I have to side with Infinity: you cannot define a virtual w= orld >>>>> > that way >>>>> > =A0 =A0 and >>>>> > =A0 =A0 use it for useful discussions regarding VWRAP. >>>>> > >>>>> > >>>>> > I think you may have misread that. =A0I did not define "VW =3D=3D R= D". >>>>> > =A0That's the >>>>> > opposite of what I said, but I agree with you on the negative >>>>> > conclusion. =A0If >>>>> > one defines "VW =3D=3D RD" then it becomes impossible to have a >>>>> > meaningful >>>>> > discussion about VWs in VWRAP. =A0It also becomes impossible to hav= e a >>>>> > meaningful >>>>> > discussion about VWs in VWRAP if one conjures up a fictitious meani= ng >>>>> > of >>>>> > "virtual world" based on reachability. =A0And that's why we should = not >>>>> > define it >>>>> > in either of those two ways. >>>>> > >>>>> > The most useful and forward-looking way of defining virtual worlds = in >>>>> > VWRAP is >>>>> > as a collection of service endpoints, regardless of who operates >>>>> > them. =A0All we >>>>> > should care about is the protocol between endpoints, and not conjur= e >>>>> > up some >>>>> > non-existent single virtual world. >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 In the end, one virtual world as defined by "all services >>>>> > together to make >>>>> > =A0 =A0 things work" will be, or can be, a mix of many RD's and man= y AD's >>>>> > with a >>>>> > =A0 =A0 complex >>>>> > =A0 =A0 web of trust/non-trust between them that makes the concept = of >>>>> > "virtual >>>>> > =A0 =A0 world" >>>>> > =A0 =A0 rather fuzzy at best. >>>>> > >>>>> > >>>>> > You're right but you're not being clear about what is fuzzy. =A0The >>>>> > concept of " >>>>> > single virtual world" is not only fuzzy, it is totally non-existent >>>>> > in practice >>>>> > (because there are many, not one) as well as impossible in theory >>>>> > =A0because of >>>>> > balkanization through incompatible trust domains, as described so >>>>> > magnificently >>>>> > by Magnus a week or two ago. =A0We should not go there. >>>>> > >>>>> > In contrast, the concept of multiple virtual worlds is crystal clea= r. >>>>> > =A0Several >>>>> > people here in the group operate virtual worlds, but nobody would >>>>> > suggest that >>>>> > they are unclear about what they operate. =A0We've been sold a brid= ge >>>>> > on that >>>>> > "uncertainty". =A0Multiple virtual worlds presenting VWRAP endpoint= s >>>>> > are the >>>>> > natural way of approaching interop between VWs, and you don't have = to >>>>> > define >>>>> > VWs structurally for that. =A0You only have to define the endpoints >>>>> > that VWs need >>>>> > to present to the protocol, and avoid any notion of "single virtual >>>>> > world". >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 [...] >>>>> > =A0 =A0 > As we move into analysis of the problem space, these issu= es >>>>> > will be >>>>> > =A0 =A0 > disentangled and clarified and the protocols will be defi= ned >>>>> > and evolve, >>>>> > =A0 =A0 but >>>>> > =A0 =A0 > from the current OGP perspective there is no symmetrical >>>>> > relationship >>>>> > =A0 =A0 possible >>>>> > =A0 =A0 > between VWs that could be described as "peering". =A0It i= s the >>>>> > asymmetry of >>>>> > =A0 =A0 the >>>>> > =A0 =A0 > VW-RD relationship that has been the crux of the "no VW >>>>> > interop" issue. >>>>> > =A0 =A0 For >>>>> > =A0 =A0 > symmetrical peering, the protocol would need to mention a= t >>>>> > least two >>>>> > =A0 =A0 > communicating VWs. >>>>> > >>>>> > =A0 =A0 You can about peering with just two RD's and one AD, or one= RD >>>>> > and two >>>>> > =A0 =A0 AD's. >>>>> > >>>>> > >>>>> > I think you're confusing RDs with VWs again --- RDs only provide >>>>> > regions, >>>>> > nothing else. =A0For peering between two VWs, you would need >>>>> > interaction between >>>>> > their two ADs because their ADs provide their policies. =A0If you >>>>> > bypass a VW's >>>>> > AD then you bypass its policies, so you're not interoping with that >>>>> > world. =A0And >>>>> > I don't think we're encouraging bypassing and hence subverting a >>>>> > world's >>>>> > policies. >>>>> > >>>>> > >>>>> > >>>>> > =A0 =A0 > Of course the situation could change as the protocol evol= ves. >>>>> > =A0For >>>>> > =A0 =A0 example, >>>>> > =A0 =A0 > once or twice we have heard mention that multiple ADs cou= ld be >>>>> > involved >>>>> > =A0 =A0 in some >>>>> > =A0 =A0 > way, and it seems certain that communication services fro= m >>>>> > multiple VWs >>>>> > =A0 =A0 will be >>>>> > =A0 =A0 > merged because residents demand this. =A0This would start= to take >>>>> > us into >>>>> > =A0 =A0 VW-VW >>>>> > =A0 =A0 > interop territory. =A0However, there is no such thing in = VWRAP >>>>> > currently, >>>>> > =A0 =A0 and >>>>> > =A0 =A0 > it's not in the list of deliverables to include it, and >>>>> > therefore we >>>>> > =A0 =A0 cannot say >>>>> > =A0 =A0 > that VWRAP will provide VW-VW interop at all. =A0For now.= ;-) >>>>> > >>>>> > =A0 =A0 I can't comment on that cause I didn't see VWRAP yet, but f= rom >>>>> > the >>>>> > =A0 =A0 charter and the comments on this list I'd think that full s= upport >>>>> > =A0 =A0 for interop between any number of RD's and AD's is intended= . >>>>> > >>>>> > >>>>> > Well you've put your finger on the problem here. =A0Everyone is say= ing >>>>> > what they >>>>> > think is intended because the intention is not actually spelled out >>>>> > in the >>>>> > documents. =A0Why cannot it be spelled out clearly that interop bet= ween >>>>> > multiple >>>>> > ADs is intended? =A0If it were, this entire discussion could be avo= ided >>>>> > because >>>>> > it's easy and reasonable to equate ADs with VWs in practice. >>>>> > >>>>> > Notice however that even if the protocol were modified to be able t= o >>>>> > handle two >>>>> > ADs at a time, use of an unadorned "the virtual world" in the >>>>> > documents would >>>>> > continue to raise the perennial question of "Which virtual world?". >>>>> > =A0After all, >>>>> > there would be two of them being discussed. >>>>> > >>>>> > It's this phraseology that stems from OGP's original goal of adding >>>>> > single >>>>> > regions or RDs to an existing single virtual world (namely SL in th= e >>>>> > prototype) >>>>> > that is creating such a problem. =A0That phraseology was appropriat= e >>>>> > for that >>>>> > original goal. =A0It is not appropriate for the goal of interoperat= ing >>>>> > multiple >>>>> > virtual worlds --- it makes it impossible to even talk about the go= al >>>>> > sensibly, >>>>> > because "the virtual world" in the OGP sense has no plural. >>>>> > >>>>> > It's unfortunate, but this whole affair is just the product of lega= cy >>>>> > wording >>>>> > from OGP. =A0That's never going to work in a multi-world setting wh= ere >>>>> > we need to >>>>> > talk about the endpoints in different worlds. >>>>> > >>>>> > >>>>> > Morgaine. >>>>> > >>>>> > PS. If anyone else read this far other than Carlo, you have a lot o= f >>>>> > stamina >>>>> > and dedication. ;-) >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> > >>>>> > On Fri, Sep 4, 2009 at 8:58 PM, Carlo Wood wrote= : >>>>> > >>>>> > =A0 =A0 On Thu, Sep 03, 2009 at 04:28:03AM +0100, Morgaine wrote: >>>>> > =A0 =A0 > The problem you see is that a virtual world is much more = than >>>>> > just a >>>>> > =A0 =A0 Region >>>>> > =A0 =A0 > Domain. =A0It is a complete set of services of which the = Region >>>>> > Domain >>>>> > =A0 =A0 service is >>>>> > =A0 =A0 > just one. =A0Other typical services might be those of the= Agent >>>>> > Domain >>>>> > =A0 =A0 (which >>>>> > =A0 =A0 > provides identification and authorization services and po= ssibly >>>>> > others), >>>>> > =A0 =A0 as >>>>> > =A0 =A0 > well as asset and inventory services, IM and other >>>>> > communication >>>>> > =A0 =A0 services, and >>>>> > =A0 =A0 > maybe several more. >>>>> > >>>>> > =A0 =A0 Well... that is purely semantic. It is a way to define VW, = but >>>>> > not one that >>>>> > =A0 =A0 I've been using :/ >>>>> > >>>>> > =A0 =A0 For simplicity, assume that only two things are needed to c= reate >>>>> > a complete >>>>> > =A0 =A0 virtual world, like SL or OG: A Region Domain (RD) and an A= gent >>>>> > Domain >>>>> > =A0 =A0 (AD). >>>>> > >>>>> > =A0 =A0 Currently, without any interop, each administrative entity = (or >>>>> > trust >>>>> > =A0 =A0 entity) >>>>> > =A0 =A0 will need to provide both: an RD *and* an AD, otherwise the= y >>>>> > don't have a >>>>> > =A0 =A0 functional VW. >>>>> > >>>>> > =A0 =A0 Your conclusion is that a VW exist of both 1 RD and 1 AD. B= ut I >>>>> > ask you to >>>>> > =A0 =A0 reconsider if that conclusion is correct, because it is bas= ed on >>>>> > the >>>>> > =A0 =A0 current >>>>> > =A0 =A0 situation without any interop. Now "correct" might not be t= he >>>>> > correct word >>>>> > =A0 =A0 - heh. >>>>> > =A0 =A0 Rather I should say: I ask you to reconsider if that defini= tion >>>>> > is very >>>>> > =A0 =A0 useful. >>>>> > >>>>> > =A0 =A0 Lets consider the following fictive case: >>>>> > >>>>> > =A0 =A0 LL runs one RD and AD, called RD1 and AD1. >>>>> > =A0 =A0 CB (Cable Beach) runs another RD and AD, called RD2 and AD2= . >>>>> > =A0 =A0 A user that authenticates with either AD1 or AD2 can travel= to >>>>> > RD1 AND RD2, >>>>> > =A0 =A0 completely symmetrical, keeping their respective AD1- and A= D2- >>>>> > assets etc. >>>>> > =A0 =A0 This is possible with the right policies, so for the sake o= f >>>>> > looking at >>>>> > =A0 =A0 the usefulness of the above definition of VW, assume this i= s the >>>>> > case. >>>>> > >>>>> > =A0 =A0 Would you consider "RD1 + AD1" one VW, and "RD2 + AD2" to b= e >>>>> > another VW? >>>>> > =A0 =A0 Or do you think it would make most sense in THIS case to sp= eak of >>>>> > a single >>>>> > =A0 =A0 VW? >>>>> > >>>>> > =A0 =A0 I think this is what Infinity means when she says that "vir= tual >>>>> > world" >>>>> > =A0 =A0 cannot >>>>> > =A0 =A0 be defined, because what could be perceived as being a VW i= s >>>>> > highly >>>>> > =A0 =A0 dependend >>>>> > =A0 =A0 on the exact situation (and policies) and in certain >>>>> > configuration that are >>>>> > =A0 =A0 not as clear as the current situation (no interop) or the a= bove >>>>> > example >>>>> > =A0 =A0 (100% >>>>> > =A0 =A0 interop). >>>>> > >>>>> > =A0 =A0 In one of my first posts about this topic I stated that "vi= rtual >>>>> > world" >>>>> > =A0 =A0 should >>>>> > =A0 =A0 be considered to be the Region Domain (although I didn't us= e that >>>>> > term at >>>>> > =A0 =A0 the >>>>> > =A0 =A0 moment) and be completely independent of the Agent Domain, = based >>>>> > on typical >>>>> > =A0 =A0 cases of abuse and griefing etc: if anyone annoys some othe= r >>>>> > user, or >>>>> > =A0 =A0 breaks >>>>> > =A0 =A0 almost any ToS, it will be region based; which is why I've = always >>>>> > said that >>>>> > =A0 =A0 any type of abuse can and should be handled at the sim (sin= gle >>>>> > region) >>>>> > =A0 =A0 level: >>>>> > =A0 =A0 the estate owner and managers in SL, even, but that idea >>>>> > definitely extends >>>>> > =A0 =A0 to "world administrations": the people running the REGION >>>>> > (domain) is the >>>>> > =A0 =A0 one >>>>> > =A0 =A0 that should decide what is the local ToS and deal with abus= e etc. >>>>> > That is >>>>> > =A0 =A0 why I strongly argue to define "virtual world" as Region Do= main, >>>>> > and leave >>>>> > =A0 =A0 the AD out of it. Nevertheless, now I have the term "Region >>>>> > Domain" I don't >>>>> > =A0 =A0 need "virtual world" anymore. >>>>> > >>>>> > =A0 =A0 > In our new protocol, these services may either be impleme= nted >>>>> > internally >>>>> > =A0 =A0 within >>>>> > =A0 =A0 > a virtual world, or some might be implemented as external >>>>> > services >>>>> > =A0 =A0 offered by >>>>> > =A0 =A0 > third parties, the choice being a policy and design decis= ion >>>>> > for each >>>>> > =A0 =A0 world >>>>> > =A0 =A0 > operator. =A0In all cases however, the virtual worlds are= defined >>>>> > by a set >>>>> > =A0 =A0 of >>>>> > =A0 =A0 > services, and not just by a Region Domain. >>>>> > >>>>> > =A0 =A0 I'm afraid that is purely a matter of opinion. I agree that= it is >>>>> > likely >>>>> > =A0 =A0 that a single 'administrative entity' that runs a RD will a= lso >>>>> > run an AD >>>>> > =A0 =A0 and allow users authenticated with their AD visit their RD,= but >>>>> > it is no >>>>> > =A0 =A0 more than *likely*. There will almost certainly be service >>>>> > provides that >>>>> > =A0 =A0 ONLY run an AD, and don't have a RD! And I can imagine that= there >>>>> > will >>>>> > =A0 =A0 be some that only run a RD and do not care about running th= eir >>>>> > own AD. >>>>> > >>>>> > =A0 =A0 Therefore, "virtual world" cannot be synonym for "the set o= f >>>>> > services >>>>> > =A0 =A0 run by a single administrative entity" as you seem to argue= , and >>>>> > at >>>>> > =A0 =A0 the SAME time be argued to include an RD *and* AD at all ti= mes. >>>>> > >>>>> > =A0 =A0 > This is easy to see by looking at a couple of archetypal >>>>> > examples in this >>>>> > =A0 =A0 > space: >>>>> > =A0 =A0 > >>>>> > =A0 =A0 > >>>>> > =A0 =A0 > =A0 =A0 Is Second Life a virtual world? =A0Undoubtedly. = =A0Is Second >>>>> > Life just a >>>>> > =A0 =A0 Region >>>>> > =A0 =A0 > =A0 =A0 Domain (assuming it were implemented using VWRAP)= ? =A0No, of >>>>> > course >>>>> > =A0 =A0 not, SL >>>>> > =A0 =A0 > =A0 =A0 includes all of the services mentioned above, and= others. >>>>> > >>>>> > =A0 =A0 Of course, LL happens to run all services that are needed t= o >>>>> > create one >>>>> > =A0 =A0 virtual world; there are no third parties they can hire fro= m yet, >>>>> > so they >>>>> > =A0 =A0 have to provide it all themselves. >>>>> > >>>>> > =A0 =A0 But after SL implemented VWRAP they might decide to do away= from >>>>> > one of >>>>> > =A0 =A0 their services and only keep their RD. Unlikely, but possib= le. >>>>> > >>>>> > =A0 =A0 > =A0 =A0 Is OSgrid a virtual world? =A0Undoubtedly. =A0Is = OSgrid just a >>>>> > Region >>>>> > =A0 =A0 Domain >>>>> > =A0 =A0 > =A0 =A0 (assuming it were implemented using VWRAP)? =A0No= , of course >>>>> > not, it >>>>> > =A0 =A0 > =A0 =A0 currently runs all the UGAIM services, which in a= VWRAP >>>>> > context would >>>>> > =A0 =A0 > =A0 =A0 become similar to those of Second Life. >>>>> > >>>>> > =A0 =A0 Exact same argument. >>>>> > >>>>> > =A0 =A0 > So you see, the idea that has been floated which claims t= hat >>>>> > "VW =3D=3D RD" >>>>> > =A0 =A0 is >>>>> > =A0 =A0 > completely wrong, and misrepresents what constitutes a "v= irtual >>>>> > world" >>>>> > =A0 =A0 despite >>>>> > =A0 =A0 > the very clear examples before us. >>>>> > >>>>> > =A0 =A0 If you want to put it that way (including everything above = that >>>>> > you said) >>>>> > =A0 =A0 then >>>>> > =A0 =A0 I have to side with Infinity: you cannot define a virtual w= orld >>>>> > that way >>>>> > =A0 =A0 and >>>>> > =A0 =A0 use it for useful discussions regarding VWRAP. >>>>> > >>>>> > =A0 =A0 In the end, one virtual world as defined by "all services >>>>> > together to make >>>>> > =A0 =A0 things work" will be, or can be, a mix of many RD's and man= y AD's >>>>> > with a >>>>> > =A0 =A0 complex >>>>> > =A0 =A0 web of trust/non-trust between them that makes the concept = of >>>>> > "virtual >>>>> > =A0 =A0 world" >>>>> > =A0 =A0 rather fuzzy at best. >>>>> > >>>>> > =A0 =A0 [...] >>>>> > =A0 =A0 > As we move into analysis of the problem space, these issu= es >>>>> > will be >>>>> > =A0 =A0 > disentangled and clarified and the protocols will be defi= ned >>>>> > and evolve, >>>>> > =A0 =A0 but >>>>> > =A0 =A0 > from the current OGP perspective there is no symmetrical >>>>> > relationship >>>>> > =A0 =A0 possible >>>>> > =A0 =A0 > between VWs that could be described as "peering". =A0It i= s the >>>>> > asymmetry of >>>>> > =A0 =A0 the >>>>> > =A0 =A0 > VW-RD relationship that has been the crux of the "no VW >>>>> > interop" issue. >>>>> > =A0 =A0 For >>>>> > =A0 =A0 > symmetrical peering, the protocol would need to mention a= t >>>>> > least two >>>>> > =A0 =A0 > communicating VWs. >>>>> > >>>>> > =A0 =A0 You can about peering with just two RD's and one AD, or one= RD >>>>> > and two >>>>> > =A0 =A0 AD's. >>>>> > >>>>> > =A0 =A0 > Of course the situation could change as the protocol evol= ves. >>>>> > =A0For >>>>> > =A0 =A0 example, >>>>> > =A0 =A0 > once or twice we have heard mention that multiple ADs cou= ld be >>>>> > involved >>>>> > =A0 =A0 in some >>>>> > =A0 =A0 > way, and it seems certain that communication services fro= m >>>>> > multiple VWs >>>>> > =A0 =A0 will be >>>>> > =A0 =A0 > merged because residents demand this. =A0This would start= to take >>>>> > us into >>>>> > =A0 =A0 VW-VW >>>>> > =A0 =A0 > interop territory. =A0However, there is no such thing in = VWRAP >>>>> > currently, >>>>> > =A0 =A0 and >>>>> > =A0 =A0 > it's not in the list of deliverables to include it, and >>>>> > therefore we >>>>> > =A0 =A0 cannot say >>>>> > =A0 =A0 > that VWRAP will provide VW-VW interop at all. =A0For now.= ;-) >>>>> > >>>>> > =A0 =A0 I can't comment on that cause I didn't see VWRAP yet, but f= rom >>>>> > the >>>>> > =A0 =A0 charter and the comments on this list I'd think that full s= upport >>>>> > =A0 =A0 for interop between any number of RD's and AD's is intended= . >>>>> > >>>>> > =A0 =A0 -- >>>>> > =A0 =A0 Carlo Wood >>>>> > >>>>> > >>>>> >>>>> > _______________________________________________ >>>>> > ogpx mailing list >>>>> > ogpx@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/ogpx >>>>> >>>>> >>>>> -- >>>>> Carlo Wood >>>>> _______________________________________________ >>>>> ogpx mailing list >>>>> ogpx@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ogpx >>>> >>> >>> >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >>> >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From morgaine.dinova@googlemail.com Thu Oct 1 16:12:23 2009 Return-Path: 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 D67E23A67DD for ; Thu, 1 Oct 2009 16:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.527 X-Spam-Level: X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 8so4K4eW+D+f for ; Thu, 1 Oct 2009 16:12:21 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 75E273A6781 for ; Thu, 1 Oct 2009 16:12:20 -0700 (PDT) Received: by ewy28 with SMTP id 28so827034ewy.42 for ; Thu, 01 Oct 2009 16:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=H2zXHOHQm8w/neCBMgf4LraPIqHLkkdnVOAXmIaupJY=; b=Aw61CkRBBcWtusisy4XkDaFv3iCTdM/IDsPbUqys4vFBOwEM1Rpu2/tdud76HHpyi1 GXqoztVC40qe4moj1xmeB0hr6NLxc7bGgbDEx87KPa8yVnMGWfqLwyBS82F/M+q7luIa 1zfL1Fjcqt55kkcsPBhVTR/Bhfyy0dp7L2wKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=udommc4SWBysVJM70FhMXqHDd+NLo+eKDP5zKGux5uCOeVhpa5TjC0/OY3njKths8E 1smIo/z6H+4QIA+RE19BP3q+p4SwfQ/5wA+N3XbkosLJ2T7AHyAW0fISGbgY7247wElt 7b+fowWmVXh6Cw/krZOJsRHzL38UXcsZnk9xc= MIME-Version: 1.0 Received: by 10.210.7.21 with SMTP id 21mr2057447ebg.75.1254438822476; Thu, 01 Oct 2009 16:13:42 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Fri, 2 Oct 2009 00:13:42 +0100 Message-ID: From: Morgaine To: Joshua Bell Content-Type: multipart/alternative; boundary=000e0ce0445067fbda0474e7cc17 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 23:12:23 -0000 --000e0ce0445067fbda0474e7cc17 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 1, 2009 at 10:57 PM, Joshua Bell wrote: > > On Thu, Oct 1, 2009 at 2:34 PM, Morgaine wrote: > >> >> Your next step is to realize that, for two structurally identical worlds, >> if the seat of policy of one lies in its AD, then the seat of policy of the >> other also lies in its AD. Therefore your statement needs to be modified to >> the following: >> >> IMHO, it should be apparent that both the AD of the source world and the >> RD and AD of the destination world all need to make policy decisions. >> >> > I don't agree with this at all. > > A VW service provider could operate a region domain with no agent domain. I > believe this is VERY LOOSELY equivalent to running an OpenSim instance in > Grid mode today (but I can't state that definitively) the person running the > sim is basically running just the region, and relying on someone else's > agent domain (agent-centric services). > > Similarly, BigGiantCo could operate an agent domain for their employs (as a > bolt-on to their enterprise LDAP server, say) with no region domain. > > A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to > place the agent in a region. There aren't necessarily any other RDs or ADs > involved at all. This is where protocol and policy come into play - the AD > needs to communicate with and trust the RD and vice versa (even if that's > nil-trust). > Those are valid examples, but they're cherry picked to support your specific use case. Please examine the more general use case of two complete SL-like worlds using VWRAP, W1 and W2. They both have ADs and RDs, so let's label those with 1's and 2's accordingly. If both ADs and RDs determine policy together (as you stated), then you can't expect a resident of W1 to TP from RD1 to RD2 without AD2's policy coming into play, otherwise you would be subverting AD2's policy. There *IS* one way of allowing the above, and that is to require that ADs carry no region-related policies at all, so that consulting only the destination RD is sufficient. This would give us a perfect *Destination Determines Policy* (DDP) system. The W1 resident could then TP from RD1 to RD2 without consulting AD2 at all. If you wish to define ADs in this way then we are in perfect agreement, since DDP is essential for interop between worlds. I am hoping that this is what you had in mind for when we start discussing specific AD and RD policies. :-) Morgaine. ====================================== On Thu, Oct 1, 2009 at 10:57 PM, Joshua Bell wrote: > > On Thu, Oct 1, 2009 at 2:34 PM, Morgaine wrote: > >> >> Your next step is to realize that, for two structurally identical worlds, >> if the seat of policy of one lies in its AD, then the seat of policy of the >> other also lies in its AD. Therefore your statement needs to be modified to >> the following: >> >> IMHO, it should be apparent that both the AD of the source world and the >> RD and AD of the destination world all need to make policy decisions. >> >> > I don't agree with this at all. > > A VW service provider could operate a region domain with no agent domain. I > believe this is VERY LOOSELY equivalent to running an OpenSim instance in > Grid mode today (but I can't state that definitively) the person running the > sim is basically running just the region, and relying on someone else's > agent domain (agent-centric services). > > Similarly, BigGiantCo could operate an agent domain for their employs (as a > bolt-on to their enterprise LDAP server, say) with no region domain. > > A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to > place the agent in a region. There aren't necessarily any other RDs or ADs > involved at all. This is where protocol and policy come into play - the AD > needs to communicate with and trust the RD and vice versa (even if that's > nil-trust). > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --000e0ce0445067fbda0474e7cc17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 1, 2009 at 10:57 PM, Joshua Bell <josh@lindenlab.com> wrote:
=

On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgaine.dinov= a@googlemail.com> wrote:

Your next step is to realize that, for two structurally identical worlds, if the seat of policy of one lies in its AD, then the seat of policy of the other also lies in its AD.=A0 Therefore your statement needs to be modified to the following:

IMHO, it should be apparent that both= the AD of the source world and the RD and AD of the destination world all need to make policy decisions.

=A0
I don't agree with this at all.

A VW service provider could operate a region domain with no agent domain. I believe this is VERY LOOSELY equivalent to running an OpenSim instance in Grid mode today (but I can't state that definitively) the person running the sim is basically running just the region, and relying on someone else's agent domain (agent-centric services).
Similarly, BigGiantCo could operate an agent domain for their employs (as a bolt-on to their enterprise LDAP server, say) with no region domain.

A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to place the agent in a region. There aren't necessarily any other RDs or ADs involved at all. This is where protocol and policy come into play - the AD needs to communicate with and trust the RD and vice versa (even if that's nil-trust).



Those are valid examples, but they're cherry p= icked to support your specific use case.

Please examine the more gen= eral use case of two complete SL-like worlds using VWRAP, W1 and W2.=A0 The= y both have ADs and RDs, so let's label those with 1's and 2's = accordingly.

If both ADs and RDs determine policy together (as you stated), then you= can't expect a resident of W1 to TP from RD1 to RD2 without AD2's = policy coming into play, otherwise you would be subverting AD2's policy= .

There *IS* one way of allowing the above, and that is to require that A= Ds carry no region-related policies at all, so that consulting only the des= tination RD is sufficient.=A0 This would give us a perfect Destination D= etermines Policy (DDP) system.=A0 The W1 resident could then TP from RD= 1 to RD2 without consulting AD2 at all.

If you wish to define ADs in this way then we are in perfect agreement,= since DDP is essential for interop between worlds.=A0 I am hoping that thi= s is what you had in mind for when we start discussing specific AD and RD p= olicies. :-)


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

On Thu, Oct 1, 2009 at 10:57 PM= , Joshua Bell <j= osh@lindenlab.com> wrote:

On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:

Your next step is to realize that, for two structurally identical world= s, if the seat of policy of one lies in its AD, then the seat of policy of = the other also lies in its AD.=A0 Therefore your statement needs to be modi= fied to the following:

IMHO, it should be apparent that both= the AD of the source world and the RD and AD of the destination world all need to make policy decisions.

=A0
I don't agree with this at all.

A VW service provider could ope= rate a region domain with no agent domain. I believe this is VERY LOOSELY e= quivalent to running an OpenSim instance in Grid mode today (but I can'= t state that definitively) the person running the sim is basically running = just the region, and relying on someone else's agent domain (agent-cent= ric services).

Similarly, BigGiantCo could operate an agent domain for their employs (= as a bolt-on to their enterprise LDAP server, say) with no region domain. <= br>
A BigGiantCo employee can visit the RD-only VW - the AD talks to the= RD to place the agent in a region. There aren't necessarily any other = RDs or ADs involved at all. This is where protocol and policy come into pla= y - the AD needs to communicate with and trust the RD and vice versa (even = if that's nil-trust).


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--000e0ce0445067fbda0474e7cc17-- From josh@lindenlab.com Thu Oct 1 16:30:50 2009 Return-Path: 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 4B7403A68F9 for ; Thu, 1 Oct 2009 16:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 u+WFnHXdsRHA for ; Thu, 1 Oct 2009 16:30:48 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id AC9E03A6781 for ; Thu, 1 Oct 2009 16:30:48 -0700 (PDT) Received: by pzk35 with SMTP id 35so927977pzk.29 for ; Thu, 01 Oct 2009 16:32:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.192.18 with SMTP id p18mr722950rvf.168.1254439931826; Thu, 01 Oct 2009 16:32:11 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Thu, 1 Oct 2009 16:32:11 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cd153e68753ec0474e80e24 Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 23:30:50 -0000 --000e0cd153e68753ec0474e80e24 Content-Type: text/plain; charset=UTF-8 I think we're converging... On Thu, Oct 1, 2009 at 4:13 PM, Morgaine wrote: > > Those are valid examples, but they're cherry picked to support your > specific use case. > > Well, simplified examples. I don't believe more complicated examples actually add meaningfully at a protocol level, as will become clear... > Please examine the more general use case of two complete SL-like worlds > using VWRAP, W1 and W2. They both have ADs and RDs, so let's label those > with 1's and 2's accordingly. > At a protocol level, I don't think VWs exist. There are services, which we're clustering into AD and RD. Although we may later determine there are further subdivisions, that's our working model in the drafts. Further drafts are strongly encouraged! > If both ADs and RDs determine policy together (as you stated), then you > can't expect a resident of W1 to TP from RD1 to RD2 without AD2's policy > coming into play, otherwise you would be subverting AD2's policy. > Here's the crux of the issue: in our model, the provider of W2 is offering two sets of services, AD2 and RD2. There may be a policy covering W2 in general, which would affect the AD2 and RD2 services. However, if an agent "from" W1, meaning the agent services are provided by AD1, attempts to visit RD2, then AD2 does *not* come into play. The protocol describes the negotiation between the client, AD1 and RD2 *only*. (Again, this is insofar as the model in the current drafts are concerned. If we're missing something, please bring the conversation back to the drafts and point out issues and/or submit new work for discussion!) Let me restate: even if AD2 and RD2 are governed by the same policy - potentially even to the point of being implemented by the same monolithic piece of code! - AD2 is irrelevant *from a protocol perspective* in the attempt to place an agent from AD1 into AD2, since by definition the AD2 and RD2 services are disjoint. > There *IS* one way of allowing the above, and that is to require that ADs > carry no region-related policies at all, so that consulting only the > destination RD is sufficient. This would give us a perfect *Destination > Determines Policy* (DDP) system. The W1 resident could then TP from RD1 > to RD2 without consulting AD2 at all. > .... and so it looks like we're in agreement - if this wasn't clear, then we need to review the drafts (please, go for it!); it should be the case that ADs carry policies about region services... except, of course, that the AD may say "hey, you can't go to *that* RD...". I believe I may have misread some of your earlier posts as implying that the agent's AD was not allowed to have a say in policy decisions, only the destination RD. I have a clearer reading of your DDP statement, though, that of course it's the AD reasoning about the RD, and contrariwise the RD reasoning about the AD. If we call that "DDP" then we're copacetic. > If you wish to define ADs in this way then we are in perfect agreement, > since DDP is essential for interop between worlds. I am hoping that this is > what you had in mind for when we start discussing specific AD and RD > policies. :-) > --000e0cd153e68753ec0474e80e24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think we're converging...

On Thu, O= ct 1, 2009 at 4:13 PM, Morgaine <morgaine.dinova@googlemail.com> = wrote:
<= div class=3D"h5">
Those are valid examples, but they're = cherry picked to support your specific use case.


Well, simplified examples. I don't believe mo= re complicated examples actually add meaningfully at a protocol level, as w= ill become clear...
=C2=A0
Please examine the more general use case of two complete SL-like worlds usi= ng VWRAP, W1 and W2.=C2=A0 They both have ADs and RDs, so let's label t= hose with 1's and 2's accordingly.

At a pr= otocol level, I don't think VWs exist. There are services, which we'= ;re clustering into AD and RD. Although we may later determine there are fu= rther subdivisions, that's our working model in the drafts. Further dra= fts are strongly encouraged!
=C2=A0
If bo= th ADs and RDs determine policy together (as you stated), then you can'= t expect a resident of W1 to TP from RD1 to RD2 without AD2's policy co= ming into play, otherwise you would be subverting AD2's policy.

Here's the crux of the issue: in our model, the p= rovider of W2 is offering two sets of services, AD2 and RD2. There may be a= policy covering W2 in general, which would affect the AD2 and RD2 services= . However, if an agent "from" W1, meaning the agent services are = provided by AD1, attempts to visit RD2, then AD2 does *not* come into play.= The protocol describes the negotiation between the client, AD1 and RD2 *on= ly*.

(Again, this is insofar as the model in the current drafts are concerne= d. If we're missing something, please bring the conversation back to th= e drafts and point out issues and/or submit new work for discussion!)

Let me restate: even if AD2 and RD2 are governed by the same policy - p= otentially even to the point of being implemented by the same monolithic pi= ece of code! - AD2 is irrelevant *from a protocol perspective* in the attem= pt to place an agent from AD1 into AD2, since by definition the AD2 and RD2= services are disjoint.
=C2=A0
There *IS* one way of allowing the above, and that is to require that= ADs carry no region-related policies at all, so that consulting only the d= estination RD is sufficient.=C2=A0 This would give us a perfect Destinat= ion Determines Policy (DDP) system.=C2=A0 The W1 resident could then TP= from RD1 to RD2 without consulting AD2 at all.

.... and so it looks like we're in agreement - if= this wasn't clear, then we need to review the drafts (please, go for i= t!); it should be the case that ADs carry policies about region services...= except, of course, that the AD may say "hey, you can't go to *tha= t* RD...".

I believe I may have misread some of your earlier posts as implying tha= t the agent's AD was not allowed to have a say in policy decisions, onl= y the destination RD. I have a clearer reading of your DDP statement, thoug= h, that of course it's the AD reasoning about the RD, and contrariwise = the RD reasoning about the AD. If we call that "DDP" then we'= re copacetic.

=C2=A0
If you wish to define ADs in this way then we are in perfect agre= ement, since DDP is essential for interop between worlds.=C2=A0 I am hoping= that this is what you had in mind for when we start discussing specific AD= and RD policies. :-)

--000e0cd153e68753ec0474e80e24-- From carlo@alinoe.com Thu Oct 1 17:49:16 2009 Return-Path: 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 0BD553A695A for ; Thu, 1 Oct 2009 17:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 1Wx2sIRlmfE8 for ; Thu, 1 Oct 2009 17:49:15 -0700 (PDT) Received: from viefep13-int.chello.at (viefep13-int.chello.at [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id E2EF13A6922 for ; Thu, 1 Oct 2009 17:48:57 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep13-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091002005022.TKWN28202.viefep13-int.chello.at@edge04.upc.biz>; Fri, 2 Oct 2009 02:50:22 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id ncqL1c0680FlQed04cqMmH; Fri, 02 Oct 2009 02:50:22 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MtWMl-0001wd-9O; Fri, 02 Oct 2009 02:51:23 +0200 Date: Fri, 2 Oct 2009 02:51:23 +0200 From: Carlo Wood To: Joshua Bell Message-ID: <20091002005123.GA690@alinoe.com> References: <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 00:49:16 -0000 On Thu, Oct 01, 2009 at 04:32:11PM -0700, Joshua Bell wrote: > Here's the crux of the issue: in our model, the provider of W2 is offering two > sets of services, AD2 and RD2. There may be a policy covering W2 in general, > which would affect the AD2 and RD2 services. However, if an agent "from" W1, > meaning the agent services are provided by AD1, attempts to visit RD2, then AD2 > does *not* come into play. The protocol describes the negotiation between the > client, AD1 and RD2 *only*. Good :). Actually, I considered this to be trivial. -- Carlo Wood From carlo@alinoe.com Thu Oct 1 18:21:12 2009 Return-Path: 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 DE18C3A681E for ; Thu, 1 Oct 2009 18:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 NKjJHEo0LWxa for ; Thu, 1 Oct 2009 18:21:10 -0700 (PDT) Received: from viefep13-int.chello.at (viefep13-int.chello.at [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id 21BCA3A6837 for ; Thu, 1 Oct 2009 18:21:09 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep13-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091002012234.UAQB28202.viefep13-int.chello.at@edge03.upc.biz>; Fri, 2 Oct 2009 03:22:34 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upc.biz with edge id ndNY1c03b0FlQed03dNZoK; Fri, 02 Oct 2009 03:22:34 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MtWrv-0002NH-5X; Fri, 02 Oct 2009 03:23:35 +0200 Date: Fri, 2 Oct 2009 03:23:35 +0200 From: Carlo Wood To: David W Levine Message-ID: <20091002012335.GB690@alinoe.com> References: <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 01:21:13 -0000 On Thu, Oct 01, 2009 at 06:25:22PM -0400, David W Levine wrote: > We need to be careful, when looking at this stuff to strike a balance between > focusing on the current deployed clusterings, and turning everything into soup. > That said, the actual deployed systems which implement these specifications are > only going to be able > to enforce policy at the interfaces we define, and these interfaces are on > services, not domains. It is because we can't allow *every* possible deployment to be supported (soup) that I brought up my worries about which service should determine policy (ToS). It would be easy to choose a simplification (== not allow every possibility) that leaves out a deployment that is essential, imho. My proposal was this: The AD can only allow a user to connect to (teleport to) a region (domain) or not. If it allows a user to teleport there, then everything that that domain allows is allowed. I probably should have been more clear about this from the beginning: this (my concern) has everything to do with where Abuse Reports go to: Once a user is in a given region and breaks a policy (or not) and someone else wants to report this user, then the only authority that this report should go to is the administration of the region (personally, I even advocate the sim, but alas). If to whomever an 'abuse report' goes has nothing to do with VWRAP than we can skip this topic; but I think it might be relevant and it is certainly something we need to keep in mind while designing the protocol (to make sure that won't go wrong). Example: Region RD1 runs on servers in country X whose laws state that adult content may be accessed at the age of 16 or older. However, the administration of RD1 has it in their ToS that one has to be 18. They do not see a reason to ban people of age 16 or 17 however. Agentd AD2 is seated in another country where one has to be 21 before one is allowed to access adult content. AD2 does age verification. If a person of age 18 logs in with AD2 and tries to TP to RD1 then * AD2 may disallow that if they so choose. * If AD2 allows the TP, than the user is allowed to access adult content by the ToS of RD1 if their age is 18 or older. If the user lives in a country where 18 is old enough as well, than I don't think that it matters (legally) where the AD2 is seated: the administration of AD2 cannot be sued for allowing a person to teleport to RD1 (I hope :p). *************************************************************** * Hence, it is possible to apply the simplication: * *- AD policies ONLY come into play at the moment of teleport * * (allow or not). * *- Once arrived in a new region, the policies of the AD can * * be 'forgotten' and only the policies of the RD apply. * * If the AD doesn't want that, they shouldn't allow the TP. * *************************************************************** We shouldn't take this simplification (or deployment limitation) too lightly, but I think it is one that will work VERY well in practice and well worth it, as it's benefits will far outweight the disadvantages, imho. If anyone can think of a clear counter example where a TP should be allowed but still the AD ToS should determine what is allowed and what not, please let us know. A clear advantage of this simplification is that it makes it trivial where an Abuse Report would go to: namely the to the administration of the Region (domain). A clear disadvantage of NOT making this simplification is that it would be totally unclear where Abuse Reports have to go, and that lots of confusion will arise about who can do what and why they can and you not. -- Carlo Wood From vaughn.deluca@gmail.com Thu Oct 1 18:46:00 2009 Return-Path: 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 26F7B3A6819 for ; Thu, 1 Oct 2009 18:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 UKrHzJvq2w+z for ; Thu, 1 Oct 2009 18:45:57 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id 31BE23A680C for ; Thu, 1 Oct 2009 18:45:56 -0700 (PDT) Received: by fxm28 with SMTP id 28so623067fxm.42 for ; Thu, 01 Oct 2009 18:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TeeY1QCS7RWBGrv1Obk7VIsFQbS8stNWnQaS6pCox28=; b=O/xT3/q7B3hgDzoATUlYHqJVxAsldQCeRddE8WDEhdyqmLxsRotGLxi3jOuMJ7+RET POX5/ZOUg4Jf6mj5t/KPJFh8CM3P8ZJb9rq+SjENmAXRdPJh0A8Qm1irXI2VI3Lic7t8 KZaSe/ofaz56Emu24XDO7aiLvb/XBDDvrpLyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=F4YwghhrH74db7+KAmDd6CjhLiBedB9/G+gaX+RGYvFapOk4vNBfXRby+jHgXWzvLI 2GDa0bAR1FbLXjzHF+2mmffgJcNlhwij0/f+K/zxZ4bH6wleuFzvTBZiqKZzCqWwDKkW Abr/f/51fodzGqfB/OafOIU2mT6UOKWMMt76U= MIME-Version: 1.0 Received: by 10.204.48.203 with SMTP id s11mr606129bkf.133.1254448034883; Thu, 01 Oct 2009 18:47:14 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Fri, 2 Oct 2009 03:47:14 +0200 Message-ID: <9b8a8de40910011847n61be601ej6a4f10a64195ef0@mail.gmail.com> From: Vaughn Deluca To: Morgaine Content-Type: multipart/alternative; boundary=00032555877682296b0474e9f19b Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 01:46:00 -0000 --00032555877682296b0474e9f19b Content-Type: text/plain; charset=ISO-8859-1 @ Joshua & Carlo, You have beaten me to the punch, i write to slow... @ Morgaine, since its written i might as well post my response, it broadly agree's with what has been said already :) convergence indeed! [...] >If both ADs and RDs determine policy together (as you stated), then you can't expect a resident of W1 to TP from RD1 to RD2 without >AD2's policy coming into play, otherwise you would be subverting AD2's policy. No, it does not have to be that complicated, for the *teleport* (and ignoring assets for now) of an agent from AD1 (present in RD1) to RD2 the only interaction needed is between AD1 and RD2. So for sure AD1 caries RD related policy, but *only* in respect to allowing the TP to RD2. On the destinations world's end, AD2 has for this TP no role at all, AD1 does not need to talk to AD2, all policy can be in RD2. However, maybe its *technically* more convenient to derive all policy for RD2 from AD2, and make RD2 a straw man for AD2 as far as policy is concerned. As long as AD2 and RD2 fully trust each other it makes no difference, it would under full trust even be possible to cut RD2 completely out of the loop regarding policy aspects, and have AD1 and AD2 work out the intended TP to RD2. Its up to the owner of RD2 to decide if she wants to do it that way, and simply trust an external AD2, or be more careful and run her own AD2 allowing her to keep full control over who is going to be allowed into RD2. So yes, in this case destination largely determines policy, but not exclusively, AD1 has to agree to let the agent go. If destination policy is defined by RD2 alone, or by a combination AD2/RD2 or even by AD2 alone is not really important. I think that *protocol efficiency* should be used as guideline to determine that. In terms of freedom it does not matter, since its always possible to run your own AD services if you feel you can't trust somebody else his service. >There *IS* one way of allowing the above, and that is to require that ADs carry no region-related policies at all, so that consulting only the >destination RD is sufficient. This would give us a perfect Destination Determines Policy (DDP) system. The W1 resident could then TP >from RD1 to RD2 without consulting AD2 at all. I would view that example as a special case were AD1 has a full trust policy regarding were it allows its residents to travel to, in combination with a version of VWRAP were the trust issues for a RD are all handled by the RD itself, rather than delegating the trust issues to a trusted AD. >If you wish to define ADs in this way then we are in perfect agreement, since DDP is essential for interop between worlds. I am hoping that >this is what you had in mind for when we start discussing specific AD and RD policies. :-) I *think* Infinity had something like what i described above in mind, but she can speak for herself. Anyhow I have the feeling that there is a very high level of basic agreement in this group. But Zha's remark about the danger of creating a system were everybody complies, yet hardly any interop is possible is highly relevant. This "Balkanisation" has been mentioned before, but i do not see a principle way to prevent it. In the end it will be the trust networks that determine what happens in terms of interop, and users will probably vote with their feet. The next step are the assets services. That is slightly more tricky, but in principle not different from the TP case. Here AS1 has policies about letting stuff go, so clearly its *not* only "DDP" in this phase. Yet, RD2 (or its ruling AD2 if we prefer that format) does have a voice, and might not want to accept objects from an AS (or optionally its ruling AD/RD) if that service has griefer associations. -Vaughn On Fri, Oct 2, 2009 at 1:13 AM, Morgaine wrote: > On Thu, Oct 1, 2009 at 10:57 PM, Joshua Bell wrote: > >> >> On Thu, Oct 1, 2009 at 2:34 PM, Morgaine wrote: >> >>> >>> Your next step is to realize that, for two structurally identical worlds, >>> if the seat of policy of one lies in its AD, then the seat of policy of the >>> other also lies in its AD. Therefore your statement needs to be modified to >>> the following: >>> >>> IMHO, it should be apparent that both the AD of the source world and the >>> RD and AD of the destination world all need to make policy decisions. >>> >>> >> I don't agree with this at all. >> >> A VW service provider could operate a region domain with no agent domain. >> I believe this is VERY LOOSELY equivalent to running an OpenSim instance in >> Grid mode today (but I can't state that definitively) the person running the >> sim is basically running just the region, and relying on someone else's >> agent domain (agent-centric services). >> >> Similarly, BigGiantCo could operate an agent domain for their employs (as >> a bolt-on to their enterprise LDAP server, say) with no region domain. >> >> A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to >> place the agent in a region. There aren't necessarily any other RDs or ADs >> involved at all. This is where protocol and policy come into play - the AD >> needs to communicate with and trust the RD and vice versa (even if that's >> nil-trust). >> > > > > Those are valid examples, but they're cherry picked to support your > specific use case. > > Please examine the more general use case of two complete SL-like worlds > using VWRAP, W1 and W2. They both have ADs and RDs, so let's label those > with 1's and 2's accordingly. > > If both ADs and RDs determine policy together (as you stated), then you > can't expect a resident of W1 to TP from RD1 to RD2 without AD2's policy > coming into play, otherwise you would be subverting AD2's policy. > > There *IS* one way of allowing the above, and that is to require that ADs > carry no region-related policies at all, so that consulting only the > destination RD is sufficient. This would give us a perfect *Destination > Determines Policy* (DDP) system. The W1 resident could then TP from RD1 > to RD2 without consulting AD2 at all. > > If you wish to define ADs in this way then we are in perfect agreement, > since DDP is essential for interop between worlds. I am hoping that this is > what you had in mind for when we start discussing specific AD and RD > policies. :-) > > > Morgaine. > > > > > > > ====================================== > > On Thu, Oct 1, 2009 at 10:57 PM, Joshua Bell wrote: > >> >> On Thu, Oct 1, 2009 at 2:34 PM, Morgaine wrote: >> >>> >>> Your next step is to realize that, for two structurally identical worlds, >>> if the seat of policy of one lies in its AD, then the seat of policy of the >>> other also lies in its AD. Therefore your statement needs to be modified to >>> the following: >>> >>> IMHO, it should be apparent that both the AD of the source world and the >>> RD and AD of the destination world all need to make policy decisions. >>> >>> >> I don't agree with this at all. >> >> A VW service provider could operate a region domain with no agent domain. >> I believe this is VERY LOOSELY equivalent to running an OpenSim instance in >> Grid mode today (but I can't state that definitively) the person running the >> sim is basically running just the region, and relying on someone else's >> agent domain (agent-centric services). >> >> Similarly, BigGiantCo could operate an agent domain for their employs (as >> a bolt-on to their enterprise LDAP server, say) with no region domain. >> >> A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to >> place the agent in a region. There aren't necessarily any other RDs or ADs >> involved at all. This is where protocol and policy come into play - the AD >> needs to communicate with and trust the RD and vice versa (even if that's >> nil-trust). >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00032555877682296b0474e9f19b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
@ Joshua & Carlo, You have beaten me to the punch, i write to slow= ...
@ Morgaine, since its written =A0i might as well post my resp= onse, it broadly agree's with what has been said already :) convergence= indeed!


[...]
>If both ADs and RDs = determine policy together (as you stated), then you can't expect a resi= dent of W1 to TP from RD1 to RD2 without >AD2's policy coming into p= lay, otherwise you would be subverting AD2's policy.

No, it does not have to be that complicated, for the *t= eleport* (and ignoring assets for now) of an agent from AD1 (present in RD1= ) to RD2 the only interaction needed is between AD1 and RD2.
So for sure AD1 caries RD related policy, but *only* in respect to allowing= the TP =A0to RD2. =A0On the destinations world's end, AD2 has for this= TP no role at all, =A0AD1 does not need to talk to AD2, all policy can be = in RD2.

However, maybe its *technically* =A0more convenient to = derive all policy for RD2 from AD2, and make RD2 a straw man for AD2 as far= as policy is concerned. As long as AD2 and RD2 fully trust each other it m= akes no difference, it would under full trust even be possible to cut RD2 c= ompletely out of the loop regarding policy aspects, and have AD1 and AD2 wo= rk out the intended TP to RD2. =A0Its up to the owner of RD2 to decide if s= he wants to do it that way, and simply trust an external AD2, or be more ca= reful and run her own AD2 allowing her to keep full control over who is goi= ng to be allowed into RD2.

So yes, in this case destination largely determines pol= icy, but not exclusively, AD1 has to agree to let the agent go. If destinat= ion policy =A0is defined by RD2 alone, or by a combination AD2/RD2 or even = by AD2 alone is not really important.
I think that *protocol efficiency* should be used as =A0guideline to d= etermine that. In terms of freedom it does not matter, since its always pos= sible to run your own AD services if you feel you can't trust somebody = else his service.


>There *IS* one way of allowing the a= bove, and that is to require that ADs carry no region-related policies at a= ll, so that consulting only the >destination RD is sufficient. =A0This w= ould give us a perfect Destination Determines Policy (DDP) system. =A0The W= 1 resident could then TP >from RD1 to RD2 without consulting AD2 at all.=

I would view that example as a special case were AD1 ha= s a full trust policy regarding were it allows its residents to travel to, = in combination with a version of VWRAP were the trust issues for a RD are a= ll handled by the RD itself, rather than delegating the trust issues to a t= rusted AD.


>If you wish to define ADs in this wa= y then we are in perfect agreement, since DDP is essential for interop betw= een worlds. =A0I am hoping that >this is what you had in mind for when w= e start discussing specific AD and RD policies. :-)

I *think* Infinity had something like what i described = above in mind, but she can speak for herself.=A0

A= nyhow I have the feeling that there is a very high level of basic agreement= in this group. But Zha's remark about the danger of creating a system = were everybody complies, yet hardly any interop is possible is highly relev= ant. This "Balkanisation" has been mentioned before, but i do not= see a principle way to prevent it. In the end it will be the trust network= s that determine what happens in terms of interop, and users will probably = vote with their feet.=A0

The next step are the assets services. That is slightly= more tricky, but in principle not different from the TP case. Here AS1 has= policies about letting stuff go, so clearly its *not* only "DDP"= in this phase. Yet, RD2 (or its ruling AD2 if we prefer that format) does = have a voice, and might not want to accept objects from an AS (or optionall= y its ruling AD/RD) if that service has griefer associations.

-Vaughn

On Fri, Oct= 2, 2009 at 1:13 AM, Morgaine <morgaine.dinova@googlemail.com> wr= ote:
On Thu, O= ct 1, 2009 at 10:57 PM, Joshua Bell <josh@lindenlab.com> wr= ote:

On Thu, Oct = 1, 2009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com<= /a>> wrote:

Your next step is to realize that, for two structurally identical worlds, if the seat of policy of one lies in its AD, then the seat of policy of the other also lies in its AD.=A0 Therefore your statement needs to be modified to the following:

IMHO, it should be apparent that both t= he AD of the source world and the RD and AD of the destination world all need to make policy decisions.

=A0
I don't agree with this at all.

A VW service provider could operate a region domain with no agent domain. I believe this is VERY LOOSELY equivalent to running an OpenSim instance in Grid mode today (but I can't state that definitively) the person running the sim is basically running just the region, and relying on someone else's agent domain (agent-centric services).
Similarly, BigGiantCo could operate an agent domain for their employs (as a bolt-on to their enterprise LDAP server, say) with no region domain.

A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to place the agent in a region. There aren't necessarily any other RDs or ADs involved at all. This is where protocol and policy come into play - the AD needs to communicate with and trust the RD and vice versa (even if that's nil-trust).



Those are valid examples, but they'= ;re cherry picked to support your specific use case.

Please examine = the more general use case of two complete SL-like worlds using VWRAP, W1 an= d W2.=A0 They both have ADs and RDs, so let's label those with 1's = and 2's accordingly.

If both ADs and RDs determine policy together (as you stated), then you= can't expect a resident of W1 to TP from RD1 to RD2 without AD2's = policy coming into play, otherwise you would be subverting AD2's policy= .

There *IS* one way of allowing the above, and that is to require that A= Ds carry no region-related policies at all, so that consulting only the des= tination RD is sufficient.=A0 This would give us a perfect Destination D= etermines Policy (DDP) system.=A0 The W1 resident could then TP from RD= 1 to RD2 without consulting AD2 at all.

If you wish to define ADs in this way then we are in perfect agreement,= since DDP is essential for interop between worlds.=A0 I am hoping that thi= s is what you had in mind for when we start discussing specific AD and RD p= olicies. :-)


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

<= /div>

On Thu, Oct 1, 2= 009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com&= gt; wrote:

Your next step is to realize that, for two structurally identical world= s, if the seat of policy of one lies in its AD, then the seat of policy of = the other also lies in its AD.=A0 Therefore your statement needs to be modi= fied to the following:

IMHO, it should be apparent that both t= he AD of the source world and the RD and AD of the destination world all need to make policy decisions.

=A0
I don't agree with this at all.

A VW service provider could ope= rate a region domain with no agent domain. I believe this is VERY LOOSELY e= quivalent to running an OpenSim instance in Grid mode today (but I can'= t state that definitively) the person running the sim is basically running = just the region, and relying on someone else's agent domain (agent-cent= ric services).

Similarly, BigGiantCo could operate an agent domain for their employs (= as a bolt-on to their enterprise LDAP server, say) with no region domain. <= br>
A BigGiantCo employee can visit the RD-only VW - the AD talks to the= RD to place the agent in a region. There aren't necessarily any other = RDs or ADs involved at all. This is where protocol and policy come into pla= y - the AD needs to communicate with and trust the RD and vice versa (even = if that's nil-trust).


_________________________________________= ______
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx



_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00032555877682296b0474e9f19b-- From morgaine.dinova@googlemail.com Thu Oct 1 22:51:23 2009 Return-Path: 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 5D2533A6973 for ; Thu, 1 Oct 2009 22:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 L1wSCLAJ+B-A for ; Thu, 1 Oct 2009 22:51:21 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 817603A68C3 for ; Thu, 1 Oct 2009 22:51:20 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so190357eye.51 for ; Thu, 01 Oct 2009 22:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sL+zcq0P6XJIDcLwCFJCGLP/GoDWqXcq/ZrvLOhJmu4=; b=VFZjCaAswbiVqw8naEWqoQktq6MSmw6P2BxZ40HbNezCWpMuh6uOHvJsA5GADlJtlp M9xX3KEhCG+gaaDfUvkzhFl2sdp9t/hAWfogdZjKCYq/vsGmJgxCCmw63RMs0SAz4Wwb KB1OzPGFg7ekWWFBUo90oVvooNlWJKGrdjWEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N/Sa8WRvJhRt0HLZXjfNPsaeILQ8UeFxW++0YMU3tCKFtGko9T1l3mKmJYu7FB+p+p xRALMLq7hUtJtTsEr88a1PSGBTHIV/xJJhE4jEXniH26kOTF3JUuKBliBpoWyCRUbalt 39/KBJQSmPZ288O1gRwl6SbMq/6C3vOwN6usI= MIME-Version: 1.0 Received: by 10.211.156.13 with SMTP id i13mr2527039ebo.22.1254462762744; Thu, 01 Oct 2009 22:52:42 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Fri, 2 Oct 2009 06:52:42 +0100 Message-ID: From: Morgaine To: Joshua Bell Content-Type: multipart/alternative; boundary=00504502d2ed5b7c470474ed5f47 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 05:51:23 -0000 --00504502d2ed5b7c470474ed5f47 Content-Type: text/plain; charset=ISO-8859-1 I agree Joshua, I think we are converging. :-) On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell wrote: > > On Thu, Oct 1, 2009 at 4:13 PM, Morgaine wrote: > > >> There *IS* one way of allowing the above, and that is to require that ADs >> carry no region-related policies at all, so that consulting only the >> destination RD is sufficient. This would give us a perfect *Destination >> Determines Policy* (DDP) system. The W1 resident could then TP from RD1 >> to RD2 without consulting AD2 at all. >> > .... and so it looks like we're in agreement ... That's a very good start then. If ADs have no region-related policies, then AD2 clearly doesn't need to be consulted when RD2 is entered from RD1. Unfortunately, you then wrote: it should be the case that ADs carry policies about region services... Is there a typo in that? If it's free of typos and hence ADs carry policies about region services, then clearly AD2 *does* have to be consulted before you can TP from RD1 to RD2. (I assume it has a typo, and you actually meant to write "do *not* carry policies about region services", to make this line consistent with what you said above.) Leaving the above to be clarified, we seem to be arriving at a *Destination Determines Policy* (DDP) model which makes tourism possible, by giving RDs control over their region-related policies so that AD2 doesn't need to be consulted on entry to RD2. That's fine, but it's not yet clear how you're going to achieve this since you haven't narrowed the scope of the AD to exclude region services. One promising angle stems from this very interesting phrase of yours: ... by definition the AD2 and RD2 services are disjoint. > It's a bit ambiguous though: - If by this you mean that AD1 has no say over region services in RD2, then that's very cool! :-) (It's cool because it provides DDP and hence allows tourism.) - But instead you might mean the following: "*if RD2 uses some service of type X, say X2, then AD1 cannot provide an X service when in RD2"*. That would be extremely not cool, since this would totally block meaningful tourism. For example, RD2 could be using Asset Service AS2, as a result of which AD1 would not supply an asset service to its travelling agent A1, and hence A1 would never be able to appear in RD2 wearing any asset available in W1. Clearly this interpretation would mean no useful interop between W1 and W2 at all. I'm hoping this interpretation is wrong. I'd appreciate more info about the disjointness please, to clear up this ambiguity. > > > I believe I may have misread some of your earlier posts as implying that > the agent's AD was not allowed to have a say in policy decisions, only the > destination RD. I have a clearer reading of your DDP statement, though, that > of course it's the AD reasoning about the RD, and contrariwise the RD > reasoning about the AD. If we call that "DDP" then we're copacetic. > > Ah good, I think we're starting to talk the same language now. :-) AD1 has plenty to say in regards to a TP from RD1 to RD2, as long as it sticks to the affairs of its own world W1 and its own agent A1. What it cannot do is impose W1's region-related policies on W2's regions, otherwise we end up with Vaughn's "war on purple". ;-) In other words, once in RD2, DDP applies and AD1 has no say. The DDP principle is so obvious from our experience in RL that I didn't bother explaining its scope, but perhaps some basic scoping is needed to alleviate fears that the source AD has no say at all. The only thing that DDP requires is that the travelling agent *obey the law of the land* on arrival in W2, namely the region-related policies that hold in RD2, and not those that would hold in a W1 homeworld region like RD1. It's pretty simple, and non-optional if tourism between worlds is desired. "When in Rome, do as the Romans do" says it all. As you say, I believe we're converging. :-) Morgaine. ========================================= On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell wrote: > I think we're converging... > > On Thu, Oct 1, 2009 at 4:13 PM, Morgaine wrote: > >> >> Those are valid examples, but they're cherry picked to support your >> specific use case. >> >> > Well, simplified examples. I don't believe more complicated examples > actually add meaningfully at a protocol level, as will become clear... > > >> Please examine the more general use case of two complete SL-like worlds >> using VWRAP, W1 and W2. They both have ADs and RDs, so let's label those >> with 1's and 2's accordingly. >> > > At a protocol level, I don't think VWs exist. There are services, which > we're clustering into AD and RD. Although we may later determine there are > further subdivisions, that's our working model in the drafts. Further drafts > are strongly encouraged! > > >> If both ADs and RDs determine policy together (as you stated), then you >> can't expect a resident of W1 to TP from RD1 to RD2 without AD2's policy >> coming into play, otherwise you would be subverting AD2's policy. >> > > Here's the crux of the issue: in our model, the provider of W2 is offering > two sets of services, AD2 and RD2. There may be a policy covering W2 in > general, which would affect the AD2 and RD2 services. However, if an agent > "from" W1, meaning the agent services are provided by AD1, attempts to visit > RD2, then AD2 does *not* come into play. The protocol describes the > negotiation between the client, AD1 and RD2 *only*. > > (Again, this is insofar as the model in the current drafts are concerned. > If we're missing something, please bring the conversation back to the drafts > and point out issues and/or submit new work for discussion!) > > Let me restate: even if AD2 and RD2 are governed by the same policy - > potentially even to the point of being implemented by the same monolithic > piece of code! - AD2 is irrelevant *from a protocol perspective* in the > attempt to place an agent from AD1 into AD2, since by definition the AD2 and > RD2 services are disjoint. > > >> There *IS* one way of allowing the above, and that is to require that ADs >> carry no region-related policies at all, so that consulting only the >> destination RD is sufficient. This would give us a perfect *Destination >> Determines Policy* (DDP) system. The W1 resident could then TP from RD1 >> to RD2 without consulting AD2 at all. >> > > .... and so it looks like we're in agreement - if this wasn't clear, then > we need to review the drafts (please, go for it!); it should be the case > that ADs carry policies about region services... except, of course, that the > AD may say "hey, you can't go to *that* RD...". > > I believe I may have misread some of your earlier posts as implying that > the agent's AD was not allowed to have a say in policy decisions, only the > destination RD. I have a clearer reading of your DDP statement, though, that > of course it's the AD reasoning about the RD, and contrariwise the RD > reasoning about the AD. If we call that "DDP" then we're copacetic. > > > >> If you wish to define ADs in this way then we are in perfect agreement, >> since DDP is essential for interop between worlds. I am hoping that this is >> what you had in mind for when we start discussing specific AD and RD >> policies. :-) >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00504502d2ed5b7c470474ed5f47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree Joshua, I think we are converging. :-)

On Fri, Oct 2, 2009 a= t 12:32 AM, Joshua Bell <josh@lindenlab.com> wrote:

On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <morgaine.dinov= a@googlemail.com> wrote:
=A0
There *IS* one way of allowing the above, and that is to require that ADs carry no region-related policies at all, so that consulting only the destination RD is sufficient.=A0 This would give us a perfect Destinatio= n Determines Policy (DDP) system.=A0 The W1 resident could then TP from= RD1 to RD2 without consulting AD2 at all.
=A0
.... and so it looks like we're in agreement ...


That's a very good start then.=A0= If ADs have no region-related policies, then AD2 clearly doesn't need to be consulted when RD2 is ent= ered from RD1.

Unfortunately, you then wrote:
=A0
it should be th= e case that ADs carry policies about region services...


Is there a typo in that?=A0= If it's free of typos and hence ADs carry policies about region services, then clearly AD2 does have to be consulted be= fore you can TP from RD1 to RD2.=A0 (I assume it has a typo, and you actual= ly meant to write "do not carry policies about region services", to make this line consistent with what you sai= d above.)

Leaving the above to be clarified, we seem to be arriving at a = Destination Determines Policy (DDP) model which makes tourism possible,= by giving RDs control over their region-related policies so that AD2 doesn= 't need to be consulted on entry to RD2.=A0 That's fine, but it'= ;s not yet clear how you're going to achieve this since you haven't= narrowed the scope of the AD to exclude region services.

One promising angle stems from this very interesting phrase of yo= urs:

... b= y definition the AD2 and RD2 services are disjoint.

It's a bit ambiguous though:
  • If by thi= s you mean that AD1 has no say over region services in RD2, then that's= very cool! :-)=A0 (It's cool because it provides DDP and hence allows = tourism.)
  • But instead you might mean the following:=A0 "if RD2 uses = some service of type X, say X2, then AD1 cannot provide an X service when i= n RD2".=A0 That would be extremely not cool, since this would tota= lly block meaningful tourism.=A0 For example, RD2 could be using Asset Serv= ice AS2, as a result of which AD1 would not supply an asset service to its = travelling agent A1, and hence A1 would never be able to appear in RD2 wear= ing any asset available in W1.=A0 Clearly this interpretation would mean no= useful interop between W1 and W2 at all.=A0 I'm hoping this interpreta= tion is wrong.

I'd appreciate more info about the disjointness please, t= o clear up this ambiguity.


I believe I may have misread some of = your earlier posts as implying that the agent's AD was not allowed to have a say in policy decisions, only the destination RD. I have a clearer reading of your DDP statement, though, that of course it's the AD reasoning about the RD, and contrariwise the RD reasoning about the AD. If we call that "DDP&q= uot; then we're copacetic.

Ah good, I think we're starting to ta= lk the same language now. :-)=A0 AD1 has plenty to say in regards to a TP f= rom RD1 to RD2, as long as it sticks to the affairs of its own world W1 and= its own agent A1.=A0 What it cannot do is impose W1's region-related p= olicies on W2's regions, otherwise we end up with Vaughn's "wa= r on purple". ;-) =A0 In other words, once in RD2, DDP applies and AD1= has no say.

The DDP principle is so obvious from our experience in RL that I didn&#= 39;t bother explaining its scope, but perhaps some basic scoping is needed = to alleviate fears that the source AD has no say at all.=A0 The only thing = that DDP requires is that the travelling agent obey the law of the land on arrival in W2, namely the region-related policies that hold in RD2, and not those that would hold in a W1 homeworld region like RD= 1.=A0 It's pretty simple, and non-optional if tourism between worlds is= desired.=A0 "When in Rome, do as the Romans do" says it all.

As you say, I believe we're converging. :-)


Morgai= ne.







=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

On Fri, Oct 2, 2009 at 12:32 AM= , Joshua Bell <j= osh@lindenlab.com> wrote:
I think we're= converging...

On Thu, = Oct 1, 2009 at 4:13 PM, Morgaine <morgaine.dinova@googlemail.= com> wrote:
<= div>
Those are valid examples, but they're cherry picked= to support your specific use case.


Well, simplified examples. I don't beli= eve more complicated examples actually add meaningfully at a protocol level= , as will become clear...
=A0
Please examine the more general use case of two complete SL-like worlds usi= ng VWRAP, W1 and W2.=A0 They both have ADs and RDs, so let's label thos= e with 1's and 2's accordingly.

At a= protocol level, I don't think VWs exist. There are services, which we&= #39;re clustering into AD and RD. Although we may later determine there are= further subdivisions, that's our working model in the drafts. Further = drafts are strongly encouraged!
=A0
If both ADs and RDs determine policy together (as you stated), th= en you can't expect a resident of W1 to TP from RD1 to RD2 without AD2&= #39;s policy coming into play, otherwise you would be subverting AD2's = policy.

Here's the crux of the issue: in our model,= the provider of W2 is offering two sets of services, AD2 and RD2. There ma= y be a policy covering W2 in general, which would affect the AD2 and RD2 se= rvices. However, if an agent "from" W1, meaning the agent service= s are provided by AD1, attempts to visit RD2, then AD2 does *not* come into= play. The protocol describes the negotiation between the client, AD1 and R= D2 *only*.

(Again, this is insofar as the model in the current drafts are concerne= d. If we're missing something, please bring the conversation back to th= e drafts and point out issues and/or submit new work for discussion!)

Let me restate: even if AD2 and RD2 are governed by the same policy - p= otentially even to the point of being implemented by the same monolithic pi= ece of code! - AD2 is irrelevant *from a protocol perspective* in the attem= pt to place an agent from AD1 into AD2, since by definition the AD2 and RD2= services are disjoint.
=A0
There *IS* one way of allowing the above, and that is = to require that ADs carry no region-related policies at all, so that consul= ting only the destination RD is sufficient.=A0 This would give us a perfect= Destination Determines Policy (DDP) system.=A0 The W1 resident coul= d then TP from RD1 to RD2 without consulting AD2 at all.

.... and so it looks like we're in agreemen= t - if this wasn't clear, then we need to review the drafts (please, go= for it!); it should be the case that ADs carry policies about region servi= ces... except, of course, that the AD may say "hey, you can't go t= o *that* RD...".

I believe I may have misread some of your earlier posts as implying tha= t the agent's AD was not allowed to have a say in policy decisions, onl= y the destination RD. I have a clearer reading of your DDP statement, thoug= h, that of course it's the AD reasoning about the RD, and contrariwise = the RD reasoning about the AD. If we call that "DDP" then we'= re copacetic.

=A0
If you wish to define ADs in this way then we are = in perfect agreement, since DDP is essential for interop between worlds.=A0= I am hoping that this is what you had in mind for when we start discussing= specific AD and RD policies. :-)


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00504502d2ed5b7c470474ed5f47-- From vaughn.deluca@gmail.com Fri Oct 2 01:42:58 2009 Return-Path: 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 711023A6870 for ; Fri, 2 Oct 2009 01:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 TwLw4IXMHJ9h for ; Fri, 2 Oct 2009 01:42:55 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id E4FF73A6802 for ; Fri, 2 Oct 2009 01:42:54 -0700 (PDT) Received: by bwz6 with SMTP id 6so793768bwz.37 for ; Fri, 02 Oct 2009 01:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LG6FFOqX2zlAxnYPhlst5IniiC8LlZhb4FEI/9+yPM8=; b=b3TYnGoIa77it0X9+hqyP5H1ktC0sT3jBfhBHWbj3djH1uooYOpYajG6Z0uyQWnO29 vOWg1utcb3tNQm2yIPHM1BajcUK84BgP39fUEaKHDTsTEflw82+2g5Nh3Lu/mYgfZUK3 Qel7haL5O9FZ0IbufrxdMltuPr59BnlrwiwjI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y6dpOZAPNFBN6+QXwbt5oAO+igT5qniq6u66o/iBl+VFl30133m7DiyNubiNeOq1Y6 4FepJtNl005/TYTMohPmz2Mi+7rJK4L9xN3G4KkfpR0h2l662yw20V/qGBjPRC1tnlkK rHb6HZM4pk7RZTs2GhB4Blhwrgw1pcTcDZ8ps= MIME-Version: 1.0 Received: by 10.204.156.212 with SMTP id y20mr939826bkw.126.1254473057997; Fri, 02 Oct 2009 01:44:17 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Fri, 2 Oct 2009 10:44:17 +0200 Message-ID: <9b8a8de40910020144v36077295u314d34d579e21f26@mail.gmail.com> From: Vaughn Deluca To: Morgaine Content-Type: multipart/alternative; boundary=0015175ce1ec0092ca0474efc50d Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 08:42:58 -0000 --0015175ce1ec0092ca0474efc50d Content-Type: text/plain; charset=ISO-8859-1 Morgaine, I am equally worried about the problem you sketch in the paragraph below, however, i think you put the source of that problem in the wrong place. You argue that if only AD2 is cut out of the equation, all will be fine, and tourism will be possible. I wish it was true, but even when things are fully organised as you suggested its the *trust* relations that determine what will happen, let me explain: >[...] But instead you might mean the following: "if RD2 uses some service of type X, say X2, >then AD1 cannot provide an X service when in RD2". That would be extremely not cool, since >this would totally block meaningful tourism. I agree with this sad conclusion, i think the wording could be a lot sharper, i will come to that below, but loosely speaking you are right. Now you make the example more explicit: > For example, RD2 could be using Asset Service AS2, as a result > of which AD1 would not supply an asset service to its traveling > agent A1, and hence A1 would never be able to appear in RD2 wearing > any asset available in W1. Note that you now say "would not supply" not "cant not provide" as you did above. This distinction is important. I will follow the more explicit example, since that is how things are intended IMHO. Also you seem to suggest an all or nothing behaviour of the asset server that i feel is not needed, and probably not desirable. >Clearly this interpretation would mean no useful interop between >W1 and W2 at all. I'm hoping this interpretation is wrong. It would mean no meaningful interop between some of the involved services, and that as a result of *policy* decisions that can be in *each and every case* right there where they belong. As i will show below, you can not escape this situation by trying to deny AD2 any role in the process. The pain is elsewhere. Lets do this example a bit more careful: Our tourist is at home in W1. W1 is a container concept for a collection of services. The agent is in fact registered in AD1, it uses a big collection of (purple) clothes from AS1, and is presently located in RD1, trying to become a tourist and travel for the first time to RD2 (to show off its purple clothes). AD1 talks to RD2, trying to gain access rights. RD2 has some age restrictions, but AD1 manages to convince RD2 its agent is worthy of entry based on some shared trust of a third party identity provider. No role for AD2 as you stipulated (although RD2 might have passed responsibility for this part of the process to AD2, but for clarity lets assume that is not the case). Our tourist could now enter RD2 as Ruth. Next AD1 tries to organise the passage of the purple cloths. That transfer has two endpoints, the asset service AS1, and RD2. Again RD2 might have some policy what to allow in, and lets assume its cool with anything, purple or not. Infinity and Carlo looked at some alien boundary cases, but here we assume RD2 is happy with any tourism it can get, including all assets. AS1 on the other hand has obligations to a large group of purple cloths makers, and will only give out purple stuff to RD2 if RD2 satisfies some strong conditions. It has the protocol means to test those conditions, it *could* send the purple object, but does not *want to* based on policy, in particular obligations towards purple clothes makers and the lack of trust in the behaviour of RD2. AS1 will however probably send any non-purple clothes to RD2. Cursing under its breath our tourist might go there in blue, mentally making a note to find a different clothes shop next time its shopping time. I completely fail to see what you would like to put in the protocol, or leave out of it, to remedy this situation. The would-be tourist has only one option, and that is to find an asset server that is willing to give out at least the blue clothes to RD2. The restriction in this example is in AS1 not willing to serve the purple clothes, and AS1 is a service that the *tourist* has picked. If that turns out to be an unlucky choice and AS1 refuses to give *anything* out to RD2 as you implied in your original example, the tourist might opt to start using an additional AS, say AS2. If AD1 in turn refuses to use AS2 next to AS1, it might really be time to pack up and move world. Hence my remark (and that of several others) that in the end interop will be a question of trust, and users will vote with their feet. In fact its not even AS1 that is the root of the problem, its the buying decision of the avatar itself. It might be have been wiser to check more careful on the export conditions of the purple wonders. In summary, i see your problem, its big and bad, but i fail to see your solution. Could you go over this example and point out how things should be done to prevent the blocked transfer of purple clothes? I do not think that within the scope of the protocol there is a solution. Looking in even more detail at the example brings up deeper problems, like how the clothes maker is going to know in what AS the purple clothes will end up. But that is for later i think. Sorry for the long mail, i will tty to be more brief in the future Vaughn On Fri, Oct 2, 2009 at 7:52 AM, Morgaine wrote: > I agree Joshua, I think we are converging. :-) > > On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell wrote: > >> >> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine wrote: >> >> >>> There *IS* one way of allowing the above, and that is to require that ADs >>> carry no region-related policies at all, so that consulting only the >>> destination RD is sufficient. This would give us a perfect *Destination >>> Determines Policy* (DDP) system. The W1 resident could then TP from RD1 >>> to RD2 without consulting AD2 at all. >>> >> > .... and so it looks like we're in agreement ... > > > That's a very good start then. If ADs have no region-related policies, > then AD2 clearly doesn't need to be consulted when RD2 is entered from RD1. > > Unfortunately, you then wrote: > > it should be the case that ADs carry policies about region services... > > > Is there a typo in that? If it's free of typos and hence ADs carry > policies about region services, then clearly AD2 *does* have to be > consulted before you can TP from RD1 to RD2. (I assume it has a typo, and > you actually meant to write "do *not* carry policies about region > services", to make this line consistent with what you said above.) > > Leaving the above to be clarified, we seem to be arriving at a *Destination > Determines Policy* (DDP) model which makes tourism possible, by giving RDs > control over their region-related policies so that AD2 doesn't need to be > consulted on entry to RD2. That's fine, but it's not yet clear how you're > going to achieve this since you haven't narrowed the scope of the AD to > exclude region services. > > One promising angle stems from this very interesting phrase of yours: > > ... by definition the AD2 and RD2 services are disjoint. >> > > It's a bit ambiguous though: > > - If by this you mean that AD1 has no say over region services in RD2, > then that's very cool! :-) (It's cool because it provides DDP and hence > allows tourism.) > - But instead you might mean the following: "*if RD2 uses some service > of type X, say X2, then AD1 cannot provide an X service when in RD2"*. > That would be extremely not cool, since this would totally block meaningful > tourism. For example, RD2 could be using Asset Service AS2, as a result of > which AD1 would not supply an asset service to its travelling agent A1, and > hence A1 would never be able to appear in RD2 wearing any asset available in > W1. Clearly this interpretation would mean no useful interop between W1 and > W2 at all. I'm hoping this interpretation is wrong. > > > I'd appreciate more info about the disjointness please, to clear up this > ambiguity. > >> >> >> I believe I may have misread some of your earlier posts as implying that >> the agent's AD was not allowed to have a say in policy decisions, only the >> destination RD. I have a clearer reading of your DDP statement, though, that >> of course it's the AD reasoning about the RD, and contrariwise the RD >> reasoning about the AD. If we call that "DDP" then we're copacetic. >> >> Ah good, I think we're starting to talk the same language now. :-) AD1 > has plenty to say in regards to a TP from RD1 to RD2, as long as it sticks > to the affairs of its own world W1 and its own agent A1. What it cannot do > is impose W1's region-related policies on W2's regions, otherwise we end up > with Vaughn's "war on purple". ;-) In other words, once in RD2, DDP > applies and AD1 has no say. > > The DDP principle is so obvious from our experience in RL that I didn't > bother explaining its scope, but perhaps some basic scoping is needed to > alleviate fears that the source AD has no say at all. The only thing that > DDP requires is that the travelling agent *obey the law of the land* on > arrival in W2, namely the region-related policies that hold in RD2, and not > those that would hold in a W1 homeworld region like RD1. It's pretty > simple, and non-optional if tourism between worlds is desired. "When in > Rome, do as the Romans do" says it all. > > As you say, I believe we're converging. :-) > > > Morgaine. > > > > > > > > ========================================= > > On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell wrote: > >> I think we're converging... >> >> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine wrote: >> >>> >>> Those are valid examples, but they're cherry picked to support your >>> specific use case. >>> >>> >> Well, simplified examples. I don't believe more complicated examples >> actually add meaningfully at a protocol level, as will become clear... >> >> >>> Please examine the more general use case of two complete SL-like worlds >>> using VWRAP, W1 and W2. They both have ADs and RDs, so let's label those >>> with 1's and 2's accordingly. >>> >> >> At a protocol level, I don't think VWs exist. There are services, which >> we're clustering into AD and RD. Although we may later determine there are >> further subdivisions, that's our working model in the drafts. Further drafts >> are strongly encouraged! >> >> >>> If both ADs and RDs determine policy together (as you stated), then you >>> can't expect a resident of W1 to TP from RD1 to RD2 without AD2's policy >>> coming into play, otherwise you would be subverting AD2's policy. >>> >> >> Here's the crux of the issue: in our model, the provider of W2 is offering >> two sets of services, AD2 and RD2. There may be a policy covering W2 in >> general, which would affect the AD2 and RD2 services. However, if an agent >> "from" W1, meaning the agent services are provided by AD1, attempts to visit >> RD2, then AD2 does *not* come into play. The protocol describes the >> negotiation between the client, AD1 and RD2 *only*. >> >> (Again, this is insofar as the model in the current drafts are concerned. >> If we're missing something, please bring the conversation back to the drafts >> and point out issues and/or submit new work for discussion!) >> >> Let me restate: even if AD2 and RD2 are governed by the same policy - >> potentially even to the point of being implemented by the same monolithic >> piece of code! - AD2 is irrelevant *from a protocol perspective* in the >> attempt to place an agent from AD1 into AD2, since by definition the AD2 and >> RD2 services are disjoint. >> >> >>> There *IS* one way of allowing the above, and that is to require that ADs >>> carry no region-related policies at all, so that consulting only the >>> destination RD is sufficient. This would give us a perfect *Destination >>> Determines Policy* (DDP) system. The W1 resident could then TP from RD1 >>> to RD2 without consulting AD2 at all. >>> >> >> .... and so it looks like we're in agreement - if this wasn't clear, then >> we need to review the drafts (please, go for it!); it should be the case >> that ADs carry policies about region services... except, of course, that the >> AD may say "hey, you can't go to *that* RD...". >> >> I believe I may have misread some of your earlier posts as implying that >> the agent's AD was not allowed to have a say in policy decisions, only the >> destination RD. I have a clearer reading of your DDP statement, though, that >> of course it's the AD reasoning about the RD, and contrariwise the RD >> reasoning about the AD. If we call that "DDP" then we're copacetic. >> >> >> >>> If you wish to define ADs in this way then we are in perfect agreement, >>> since DDP is essential for interop between worlds. I am hoping that this is >>> what you had in mind for when we start discussing specific AD and RD >>> policies. :-) >>> >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0015175ce1ec0092ca0474efc50d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Morgaine,=A0

I am equally worried about the p= roblem you sketch in the paragraph below, however, i think you put the sour= ce of that problem in the wrong place.=A0You argue that if only AD2 is cut = out of the equation, all will be fine, and tourism will be possible. I wish= it was true, but even when things are fully organised as you suggested its= the *trust* relations that determine what will happen, let me explain:=A0<= /div>

>[...] But instead you might mean the following: =A0= "if RD2 uses some service of type X, say X2,=A0
>then AD1= cannot provide an X service when in RD2". =A0That would be extremely = not cool, since=A0
>this would totally block meaningful tourism.

<= div>I agree with this sad conclusion, i think the wording could be a lot sh= arper, i will come to that below, but loosely speaking you are right. Now y= ou make the example more explicit:

> For example, RD2 could be using Asset Service AS2,= as a result=A0
> of which AD1 would not supply an asset servi= ce to its traveling=A0
> agent A1, and hence A1 would never be= able to appear in RD2 wearing=A0
> any asset available in W1. =A0

Note that= you now say "would not supply" not "cant not provide" = as you did above. This distinction is important. I will follow the more exp= licit example, since that is how things are intended IMHO. Also you seem to= suggest an all or nothing behaviour of the asset server that i feel=A0is n= ot needed, and probably not desirable.

>Clearly this interpretation would mean no useful in= terop between=A0
>W1 and W2 at all. =A0I'm hoping this int= erpretation is wrong.

It would mean no meaningful = interop between some of the involved services, and that as a result of *pol= icy* decisions that can be in *each and every case* right there where they = belong. As i will show below, you can not escape this situation by trying t= o deny AD2 any role in the process. The pain is elsewhere. =A0Lets do this = example a bit more careful:

Our tourist is at home in W1. W1 is a container concept= for a collection of services. The agent is in fact registered in AD1, it u= ses a big collection of (purple) clothes from AS1, and is presently located= in RD1, trying to become a tourist and travel for the first time to RD2 (t= o show off its purple clothes).

AD1 talks to RD2, trying to gain access rights. RD2 has= some age restrictions, but AD1 manages to convince RD2 its agent is worthy= of entry based on some shared trust of a third party identity provider. No= role for AD2 =A0as you stipulated (although RD2 might have passed responsi= bility for this part of the process to AD2, but for clarity lets assume tha= t is not the case).

Our tourist could now enter RD2 as Ruth. Next AD1 tries= to organise the passage of the purple cloths. That transfer has two endpoi= nts, the asset service AS1, and RD2. Again RD2 might have some policy what = to allow in, and lets assume its cool with anything, purple or not. Infinit= y and Carlo looked at some alien boundary cases, but here we =A0assume RD2 = is happy with any tourism it can get, including all assets. AS1 on the othe= r hand has obligations to a large group of purple cloths makers, and will o= nly give out purple stuff to RD2 if RD2 =A0satisfies some strong conditions= . =A0It has the protocol means to test those conditions, it *could* =A0send= the purple object, but does not *want to* based on policy, in particular o= bligations towards purple clothes makers =A0and the lack of trust in the be= haviour of RD2. AS1 will however probably send any non-purple clothes to RD= 2. Cursing under its breath our tourist might go there in blue, mentally ma= king a note to find a different clothes shop next time its shopping time.

I completely fail to see what you would like to put in = the protocol, or leave out of it, to remedy this situation. =A0The would-be= tourist has only one option, and that is to find an asset server that is w= illing to give out at least the blue =A0clothes to RD2. =A0The restriction = in this example is in AS1 not willing to serve the purple clothes, and AS1 = is a service that the *tourist* has picked. If that turns out to be an unlu= cky choice and AS1 refuses to give *anything* out to RD2 as you implied in = your original example, the tourist might opt to start using an additional A= S, say AS2. If AD1 in turn =A0refuses to use AS2 next to AS1, it might real= ly be time to pack up and move world. Hence my remark (and that of several = others) that in the end interop will be a question of trust, and users will= vote with their feet.
In fact its not even AS1 that is the root of the problem, its the buyi= ng decision of the avatar itself. It might be have been wiser to check more= careful on the export conditions of the purple wonders.=A0

In summary, i see your problem, its big and bad, but i fail to s= ee your solution. Could you go over this example and point out how things s= hould be done to prevent the blocked transfer of purple clothes? I do not t= hink that within the scope of the protocol there is a solution.

Looking in even more detail at the example brings up de= eper problems, like how the clothes maker is going to =A0know in what AS th= e purple clothes will end up. But that is for later i think.

Sorry for the long mail, i will tty to be more brief in the futu= re
Vaughn

On Fri, Oct 2, 2009= at 7:52 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
I agree Joshua, I think we are converging. = :-)


On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell <= span dir=3D"ltr"><josh@lindenlab.com> wrote:

On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <morgaine.dino= va@googlemail.com> wrote:
=A0
There *IS* one way of allowing the above, and that is to require that ADs carry no region-related policies at all, so that consulting only the destination RD is sufficient.=A0 This would give us a perfect Destinatio= n Determines Policy (DDP) system.=A0 The W1 resident could then TP from= RD1 to RD2 without consulting AD2 at all.
=A0
.... and so it looks like we're in agreement ...


That's a very good start then.=A0= If ADs have no region-related policies, then AD2 clearly doesn't need to be consulted when RD2 is ent= ered from RD1.


Unfortunately, you then wrote:
=A0
it should be the = case that ADs carry policies about region services...


Is there a typo in th= at?=A0 If it's free of typos and hence ADs carry policies about region services, then clearly AD2 does have to be consulted be= fore you can TP from RD1 to RD2.=A0 (I assume it has a typo, and you actual= ly meant to write "do not carry policies about region services", to make this line consistent with what you sai= d above.)

Leaving the above to be clarified, we seem to be arriving at a = Destination Determines Policy (DDP) model which makes tourism possible,= by giving RDs control over their region-related policies so that AD2 doesn= 't need to be consulted on entry to RD2.=A0 That's fine, but it'= ;s not yet clear how you're going to achieve this since you haven't= narrowed the scope of the AD to exclude region services.

One promising angle stems from this very interesting phrase of yo= urs:

... by defi= nition the AD2 and RD2 services are disjoint.

It's a bit ambiguous though:
  • If by thi= s you mean that AD1 has no say over region services in RD2, then that's= very cool! :-)=A0 (It's cool because it provides DDP and hence allows = tourism.)
  • But instead you might mean the following:=A0 "if RD2 uses = some service of type X, say X2, then AD1 cannot provide an X service when i= n RD2".=A0 That would be extremely not cool, since this would tota= lly block meaningful tourism.=A0 For example, RD2 could be using Asset Serv= ice AS2, as a result of which AD1 would not supply an asset service to its = travelling agent A1, and hence A1 would never be able to appear in RD2 wear= ing any asset available in W1.=A0 Clearly this interpretation would mean no= useful interop between W1 and W2 at all.=A0 I'm hoping this interpreta= tion is wrong.

I'd appreciate more info about the disjointness please, t= o clear up this ambiguity.


I believe I may have misread some of yo= ur earlier posts as implying that the agent's AD was not allowed to have a say in policy decisions, only the destination RD. I have a clearer reading of your DDP statement, though, that of course it's the AD reasoning about the RD, and contrariwise the RD reasoning about the AD. If we call that "DDP&q= uot; then we're copacetic.

Ah good, I think we're starting= to talk the same language now. :-)=A0 AD1 has plenty to say in regards to = a TP from RD1 to RD2, as long as it sticks to the affairs of its own world = W1 and its own agent A1.=A0 What it cannot do is impose W1's region-rel= ated policies on W2's regions, otherwise we end up with Vaughn's &q= uot;war on purple". ;-) =A0 In other words, once in RD2, DDP applies a= nd AD1 has no say.

The DDP principle is so obvious from our experience in RL that I didn&#= 39;t bother explaining its scope, but perhaps some basic scoping is needed = to alleviate fears that the source AD has no say at all.=A0 The only thing = that DDP requires is that the travelling agent obey the law of the land on arrival in W2, namely the region-related policies that hold in RD2, and not those that would hold in a W1 homeworld region like RD= 1.=A0 It's pretty simple, and non-optional if tourism between worlds is= desired.=A0 "When in Rome, do as the Romans do" says it all.

As you say, I believe we're converging. :-)


Morgai= ne.







=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell <josh@lindenlab.com&g= t; wrote:
<= /div>
I think we're converging...

On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <morgaine.dinov= a@googlemail.com> wrote:
Those are valid examples, but they're cherry picked to su= pport your specific use case.


Well, simplified examples. I don't beli= eve more complicated examples actually add meaningfully at a protocol level= , as will become clear...
=A0
Please examine the more general use case of two complete SL-like worlds usi= ng VWRAP, W1 and W2.=A0 They both have ADs and RDs, so let's label thos= e with 1's and 2's accordingly.

At a= protocol level, I don't think VWs exist. There are services, which we&= #39;re clustering into AD and RD. Although we may later determine there are= further subdivisions, that's our working model in the drafts. Further = drafts are strongly encouraged!
=A0
If both A= Ds and RDs determine policy together (as you stated), then you can't ex= pect a resident of W1 to TP from RD1 to RD2 without AD2's policy coming= into play, otherwise you would be subverting AD2's policy.

Here's the crux of the issue: in our model,= the provider of W2 is offering two sets of services, AD2 and RD2. There ma= y be a policy covering W2 in general, which would affect the AD2 and RD2 se= rvices. However, if an agent "from" W1, meaning the agent service= s are provided by AD1, attempts to visit RD2, then AD2 does *not* come into= play. The protocol describes the negotiation between the client, AD1 and R= D2 *only*.

(Again, this is insofar as the model in the current drafts are concerne= d. If we're missing something, please bring the conversation back to th= e drafts and point out issues and/or submit new work for discussion!)

Let me restate: even if AD2 and RD2 are governed by the same policy - p= otentially even to the point of being implemented by the same monolithic pi= ece of code! - AD2 is irrelevant *from a protocol perspective* in the attem= pt to place an agent from AD1 into AD2, since by definition the AD2 and RD2= services are disjoint.
=A0
If you wish to define ADs in this way then we are in perfect agreemen= t, since DDP is essential for interop between worlds.=A0 I am hoping that t= his is what you had in mind for when we start discussing specific AD and RD= policies. :-)


_________________________________________= ______
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx



_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--0015175ce1ec0092ca0474efc50d-- From josh@lindenlab.com Fri Oct 2 08:54:15 2009 Return-Path: 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 6539E3A6846 for ; Fri, 2 Oct 2009 08:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 rBSboJHGf7ne for ; Fri, 2 Oct 2009 08:54:14 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 48E863A6963 for ; Fri, 2 Oct 2009 08:54:08 -0700 (PDT) Received: by pxi6 with SMTP id 6so1378191pxi.32 for ; Fri, 02 Oct 2009 08:55:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.141.21 with SMTP id o21mr266706rvd.295.1254498930714; Fri, 02 Oct 2009 08:55:30 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Fri, 2 Oct 2009 08:55:30 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cd16eb022e9560474f5cbdd Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 15:54:15 -0000 --000e0cd16eb022e9560474f5cbdd Content-Type: text/plain; charset=UTF-8 On Thu, Oct 1, 2009 at 10:52 PM, Morgaine wrote: > > Unfortunately, you then wrote: > > it should be the case that ADs carry policies about region services... > > Is there a typo in that? If it's free of typos and hence ADs carry > policies about region services, then clearly AD2 *does* have to be > consulted before you can TP from RD1 to RD2. (I assume it has a typo, and > you actually meant to write "do *not* carry policies about region > services", to make this line consistent with what you said above.) > > Ugh, yes, typo... I indeed meant to echo your statement: "ADs carry no region-related policies". Thanks for catching that. One promising angle stems from this very interesting phrase of yours: > > ... by definition the AD2 and RD2 services are disjoint. >> > > It's a bit ambiguous though: > > - If by this you mean that AD1 has no say over region services in RD2, > then that's very cool! :-) (It's cool because it provides DDP and hence > allows tourism.) > > Did you mean AD2 or AD1? I agree for AD2. For AD1, being nitpicky, here's a scenario that possibly contradicts that: if RD2 tries to give you inventory, AD1 may refuse it since it is the final arbiter of your agent (and hence your inventory). I'm not sure if that counts as "say over region services" or not. Based on previous conversation, I think we agree that in that scenario, AD1 is enforcing agent-related policy in the interaction with region services, not "having a say" over those region services. > > - > - But instead you might mean the following: "*if RD2 uses some service > of type X, say X2, then AD1 cannot provide an X service when in RD2"*. > That would be extremely not cool, since this would totally block meaningful > tourism. For example, RD2 could be using Asset Service AS2, as a result of > which AD1 would not supply an asset service to its travelling agent A1, and > hence A1 would never be able to appear in RD2 wearing any asset available in > W1. Clearly this interpretation would mean no useful interop between W1 and > W2 at all. I'm hoping this interpretation is wrong. > > This is an extremely good point. "Disjoint" was too strong a word. I don't think we've sorted out assets yet, but from early brainstorming, asset services could indeed be provided by both ADs and RDs. (And a VW provider might host just one asset service that its ADs and RDs both reference.) "Mostly disjoint" :) --000e0cd16eb022e9560474f5cbdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 1, 2009 at 10:52 PM, Morgaine <morga= ine.dinova@googlemail.com> wrote:

Unfortunately, you then wrote:
=C2=A0
it should be= the case that ADs carry policies about region services...

Is there a typo in that?= =C2=A0 If it's free of typos and hence ADs carry policies about region services, then clearly AD2 does have to be consulted be= fore you can TP from RD1 to RD2.=C2=A0 (I assume it has a typo, and you act= ually meant to write "do not carry policies about region services", to make this line consistent with what you sai= d above.)


Ugh, yes, typo... I indeed meant to ec= ho your statement: "ADs carry no region-related policies". Thanks= for catching that.


One promising angle stems from this very interesting phrase of yours:
... by definiti= on the AD2 and RD2 services are disjoint.

It's a bit ambiguous though:
  • If by thi= s you mean that AD1 has no say over region services in RD2, then that's= very cool! :-)=C2=A0 (It's cool because it provides DDP and hence allo= ws tourism.)

Did you mean AD2 or AD1? I agree for = AD2. For AD1, being nitpicky, here's a scenario that possibly contradic= ts that: if RD2 tries to give you inventory, AD1 may refuse it since it is = the final arbiter of your agent (and hence your inventory). I'm not sur= e if that counts as "say over region services" or not. Based on p= revious conversation, I think we agree that in that scenario, AD1 is enforc= ing agent-related policy in the interaction with region services, not "= ;having a say" over those region services.
=C2=A0
=
  • But instead you might mean the following:=C2=A0 "if RD2 us= es some service of type X, say X2, then AD1 cannot provide an X service whe= n in RD2".=C2=A0 That would be extremely not cool, since this woul= d totally block meaningful tourism.=C2=A0 For example, RD2 could be using A= sset Service AS2, as a result of which AD1 would not supply an asset servic= e to its travelling agent A1, and hence A1 would never be able to appear in= RD2 wearing any asset available in W1.=C2=A0 Clearly this interpretation w= ould mean no useful interop between W1 and W2 at all.=C2=A0 I'm hoping = this interpretation is wrong.
This is an extremely good point. "Di= sjoint" was too strong a word. I don't think we've sorted out = assets yet, but from early brainstorming, asset services could indeed be pr= ovided by both ADs and RDs. (And a VW provider might host just one asset se= rvice that its ADs and RDs both reference.) "Mostly disjoint" :)<= br>


--000e0cd16eb022e9560474f5cbdd-- From infinity@lindenlab.com Fri Oct 2 09:31:00 2009 Return-Path: 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 808F63A672F for ; Fri, 2 Oct 2009 09:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 F1Bpx6kXKAjy for ; Fri, 2 Oct 2009 09:30:59 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 519A73A6405 for ; Fri, 2 Oct 2009 09:30:59 -0700 (PDT) Received: by pzk35 with SMTP id 35so1786029pzk.29 for ; Fri, 02 Oct 2009 09:32:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.61.41 with SMTP id j41mr345919wfa.298.1254501142674; Fri, 02 Oct 2009 09:32:22 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Fri, 2 Oct 2009 09:32:22 -0700 Message-ID: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> From: Infinity Linden To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 16:31:00 -0000 i am vaguely confused by the path we're taking. a lot of what we're fretting over was discussed over the summer. i am also disappointed that morgaine believes that simply making a fiat statement like "we are arriving at DDP" makes it true. it is not true. BOTH the agent domain and the region domain MUST have an opportunity to express their policy. the problem outlined by carlo above is interesting, but tractable. the agent domain is the entity with a direct relationship with the user. we should not require the region domain to have information about the user (such as the user's age.) and here's why... in VWRAP, as discussed before, it is the agent domain that acts as a trust broker. the user trusts the agent domain and the agent domain trusts the provider of other services (such as the agent presence service running on a host in the region domain.) we do not require the user to have a direct relationship with the region domain. instead, we define trust transitively. if the agent domain must ensure that underage users do not visit regions with adult content, then they should disallow underage user's avatars from visiting those regions. if this is an organizational policy that must be adhered to, then the agent domain should have information to make that decision: the user's age and whether a specific region (or entire region domain) allows adult content. if the region domain operator believes that the agent domain operator may believe that an acceptable age to view adult content is lower than they are comfortable with, they should communicate this concern at the time that they are negotiating access. please note that in this scenario, the evaluation of organizational policies is something that is performed by humans, not automated systems. the policy enforcement tool the AD can use in this scenario is to decide to not place a user's avatar in a particular region. the information the AD uses to evaluate whether they want to allow or deny a teleport request is largely not a concern of the protocol. though.. if the decision depends on the state of a region in the region domain, then there has to be a way to communicate this information from the region domain to the agent domain. and that _is_ definitely a protocol concern. the situation with the region domain is largely similar. the tool the RD has to enforce policy in this scenario is to disallow an agent domain from placing an avatar in one of it's regions. but i really like this example, so i created a diagram from this example at https://wiki.secondlife.com/wiki/File:VWRAP_adult_content_evaluation_example.jpg . it shows two agent domains and two region domains. one of the agent domains and one of the region domains define adult content as being viewable by those 18 and older, the others think adult content is viewable by those 21 and older. each has two regions; one of which has adult content, the other does not. lets assume that the user is 19. when the agent domain attempts to place an avatar in each of the regions, you get 8 scenarios. A - no adult content in the region, AD allows transfer, RD allows transfer B - adult content, but both the AD and RD agree that if you're 19, you're okay to view adult content. AD allows transfer, RD allows transfer. C - no adult content in the region, AD allows transfer, RD allows transfer D - adult content, but AD2 believes the user isn't old enough. AD does not allow transfer. E - no adult content in the region, AD allows transfer, RD allows transfer F - no adult content in the region, AD allows transfer, RD allows transfer G - adult content. AD1 believes the user is old enough, begins transfer. RD believes the user is not old enough, disallows transfer. H - adult content, but both AD2 and RD2 believe the user is old enough. AD allows transfer, RD allows transfer. i think the most vexxing scenario is scenario G. it forces the RD to make a policy decision based on information about the user maintained by the agent domain. there are a couple of ways to handle this. 1. the agent domain and the region domain hash out an agreement beforehand where the region domain operator tells the agent domain operator the equivalent of... "whoa dude, you'll get me in trouble with the state if you let 19 year olds into my adults only sim, PLEASE block them from entering sims i mark as adult." this effectively turns scenario G into scenario D for the AD2 / RD2 pairing. 2. the agent domain offers information in the teleport request about the user's age to the RD, allowing the RD to disallow the transfer of agent presence into adult regions. 3. the agent domain offers an interface the RD that lets the RD query information about the user (including their age.) all of these have some drawbacks. my employer is probably most interested in solution 1. linden views the relationship of agent domain to region domain as a long-term trust relationship with a fair amount of effort involved in setting it up. still, there are people that want to have more of a tourist model where the user enters the URL of a region into the client app and off you go without a previously established agreements on policy enforcement. for the tourist model, you could do either 2 or 3. 2 has the advantage that the RD doesn't need to make a request back to the AD before deciding whether to complete the teleport. it has the disadvantage that it requires the AD to give information about the user's age to an RD who may or may not be trustworthy (cause... remember... we're talking about the tourist model here.) i think what i'm getting at here is that carlo's example is interesting, but it does yield to analysis. i think it also exposes the difference between linden's vision of their service and what morgaine (and presumably others) want people to build. but we can get one protocol that works for both models, we just have to be careful, and the end result will likely be more complicated than we would prefer. but. welcome to the world of standards. -cheers -meadhbh From morgaine.dinova@googlemail.com Fri Oct 2 22:13:52 2009 Return-Path: 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 4275F28C0CE for ; Fri, 2 Oct 2009 22:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 YQncwhNsc0vx for ; Fri, 2 Oct 2009 22:13:50 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 4BDB23A6839 for ; Fri, 2 Oct 2009 22:13:49 -0700 (PDT) Received: by ewy28 with SMTP id 28so2110525ewy.42 for ; Fri, 02 Oct 2009 22:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oC0YnoK2oWODsfkeTrLbXiEAfr0/uSyMDFQlNUSJqUE=; b=M9h3B31PTpQSZFqnH4mzob35gBed30ALdJRnGlLeAUUrz7Is1Xb+2908ZR3bzvkfzp TGbC1xXP6CbX9Y5I1DVWYWekHIkVaZWOulR5mCTFJTfaBnuep2kjS/xUN66NyHY5B6gH 9runX2SMksFxensQyTbZsyadGgVZjngmqs8Qw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YT3BuMF3FD3/CHTpi1cNMfK8d+H4wQeYvq5wuroA+8yVXjzumq+nuEHR6X4obeqFN8 ipYqNJpzGy8ZNXlLUYKh1UcyI/Gei8+VF4jJIRnNY6eZvwNKFxjSX6Jz1U9TtYECAOyB tcxvLgDwsB2pUkeoHCr5FcjtAHRNIIddrLzJY= MIME-Version: 1.0 Received: by 10.211.145.15 with SMTP id x15mr4299214ebn.6.1254546915804; Fri, 02 Oct 2009 22:15:15 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Sat, 3 Oct 2009 06:15:15 +0100 Message-ID: From: Morgaine To: David W Levine Content-Type: multipart/alternative; boundary=00504502c3ec45476a047500f7dd Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 05:13:52 -0000 --00504502c3ec45476a047500f7dd Content-Type: text/plain; charset=ISO-8859-1 IMO, this post of David's is one of the most important ones in the thread, in particular its opening paragraph: On Thu, Oct 1, 2009 at 11:25 PM, David W Levine wrote: > > One.. I think its very important to keep in mind that services are going to > manage policy, not the domains they reside in. This is important, because it > highlights the fact that what's going to happen when different people deploy > this stuff in different deployments is going to vary. I think we need to be > very careful to focus not on any one deployment pattern, but the broader set > of possible deployment patterns we are attempting to enable. > It's important firstly because it provides us with a clear path towards implementation, and it seeks to reduce the focus on "domains" that has caused so much trouble --- services are so much easier to understand and to implement and to discuss. And it's important secondly because it underlines the massive and overriding power of the Agent Domain, because an AD provides caps that give access to services, and therefore it has more power in dictating policy than any service to which it gives access. This places a mammoth constraint upon David's first statement that "services are going to manage policy", because there will be no access to those services *at all* unless an AD allows it. (It's also worth pointing out that the AD's power to provide caps is in direct conflict with the 2nd part of David's sentence (highlighted): "services are going to manage policy, *not the domains they reside in*". The AD clearly is managing policy, *in a major way*, by providing caps that allow access to services.) Fortunately, the way out of this dilemma has already been provided by Joshua, namely limiting the scope of the AD to agent-related services only, while RDs control region-related services thus allowing DDP, in much the way that Carlo desired many weeks ago. :-) If ADs are limited to agent-only services such as authentication, then there are no significant problems. For example, if ADs provides only authentication, then AD2 doesn't need to be consulted when agent A1 teleports from RD1 to RD2, since A1 is already authenticated with AD1 and additional authentication with AD2 is not required. However, if ADs also provide caps to region-related services such as Asset Services, then AD2 will need to be consulted when agent A1 teleports to RD2, otherwise A1 won't have access to the assets of W2 that happen to reside in RD2. The following paragraph is crucial and its impact needs to be understood. If ADs are allowed to provide caps to asset services *in any deployment pattern whatsoever*, then AD2 will *always* have to be consulted if it exists, *in all deployments*, because W1 does not know what kind of deployment pattern is used by W2. This affects our protocol very strongly --- looking for an AD2 and querying it if it exists will not be optional. Clearly we have some thinking to do about what is allowed in ADs if we wish to avoid this. Finally, I want to quote a sentence from David's 2nd paragraph, which I think is quite illuminating: > If we keep this in mind, I think it helps us move away from thinking purely > in terms of the split that Linden Labs has focused on. I agree entirely. The rather coarse AD/RD split worked OK in its original scope as an implementation mechanism for adding regions to an existing world, but it's not very helpful now that we have started examining what really needs to happen for interop in multi-world deployments. If we feel a need for additional domains, let's add them --- for example, a separate Storage Domain might be helpful to ensure that AD2 never need to be consulted (unfortunately Asset Domain provides a conflicting abbreviation). And if we feel the need to abandon the concept of domains entirely and just leave services, then let's do that too. After all, the domain model was meant to help, not hinder. Our work is concerned primarily with defining a protocol --- domains are optional! :-) Morgaine. ======================================= On Thu, Oct 1, 2009 at 11:25 PM, David W Levine wrote: > > One.. I think its very important to keep in mind that services are going to > manage policy, not the domains they reside in. This is important, because it > highlights the fact that what's going to happen when different people deploy > this stuff in different deployments is going to vary. I think we need to be > very careful to focus not on any one deployment pattern, but the broader set > of possible deployment patterns we are attempting to enable. This goes hand > in glove with Joshua's comments below. > > This leads to > > Two.. I *think* the correct model is "All the services involved may have > policies they bring to the table." The set of actions which are possible > between an arbitrary service inside of one deployment and an arbitrary > service inside another is going to be > dictated by the policies those two services follow. This is especially > likely when looking at things like asset permissions. Consider the case of > a region attempting to pass a prim to an asset store for storage. The Region > may have policies about which > asset stores it is willing to deliver assets to. The Asset store may have > policies about which regions it is willing to accept assets from. If the > user's agent domain holds his inventory (One, but not the only possible > deployment pattern) it may have policies about > the asset servers it interacts with. Its possible to imagine cases where > the only role the ADs play in this policy decision is that they have > authenticated the user, > > We need to be careful, when looking at this stuff to strike a balance > between focusing on the current deployed clusterings, and turning everything > into soup. That said, the actual deployed systems which implement these > specifications are only going to be able > to enforce policy at the interfaces we define, and these interfaces are on > services, not domains. In fact, as I've argued several times, I think, in > general, the notion of a domain emerges from the policies of the deployed > services, not the other way around. Infinity's made a very nice case for > describing the key distinctions as being "Agent domains include the auth > service" and "Region Domains include the presence service" If we keep this > in mind, I think it helps us move away from thinking purely in terms of the > split that Linden Labs has focused on. To circle back to the question of > soup, simply focusing on the services risks describing stuff that's falls > into the HLA/DIS trap of having deployments which are each "conforming" but > vary so much in assumption as to not actually interoperate. > > - David > ~Zha > > > > > > *Joshua Bell * > Sent by: ogpx-bounces@ietf.org > > 10/01/2009 05:57 PM > To > ogpx@ietf.org cc > Subject > Re: [ogpx] VWRAP Draft Charter - 2009 09 01 > > > > > > On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <*morgaine.dinova@googlemail.com*> > wrote: > > Your next step is to realize that, for two structurally identical worlds, > if the seat of policy of one lies in its AD, then the seat of policy of the > other also lies in its AD. Therefore your statement needs to be modified to > the following: > > IMHO, it should be apparent that both the AD of the source world and the RD > and AD of the destination world all need to make policy decisions. > > > I don't agree with this at all. > > A VW service provider could operate a region domain with no agent domain. I > believe this is VERY LOOSELY equivalent to running an OpenSim instance in > Grid mode today (but I can't state that definitively) the person running the > sim is basically running just the region, and relying on someone else's > agent domain (agent-centric services). > > Similarly, BigGiantCo could operate an agent domain for their employs (as a > bolt-on to their enterprise LDAP server, say) with no region domain. > > A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to > place the agent in a region. There aren't necessarily any other RDs or ADs > involved at all. This is where protocol and policy come into play - the AD > needs to communicate with and trust the RD and vice versa (even if that's > nil-trust). > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00504502c3ec45476a047500f7dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable IMO, this post of David's is one of the most important ones in the thre= ad, in particular its opening paragraph:

On Thu, Oct 1, 2009 at 11:2= 5 PM, David W Levine <dwl@us.ibm.com> wrote:

= One.. I think its very important to keep in mind that services are going to manage policy, not the domains they reside in. This is important, because it highlights the fact that what's going to happen when different people deploy this stuff in diffe= rent deployments is going to vary. =A0I think we need to be very careful to focus not on any one deployment pattern, but the broader set of possible deployment patterns we are attempting to enable.
<= div>

It's important firstly because it provides us with a clear = path towards implementation, and it seeks to reduce the focus on "doma= ins" that has caused so much trouble --- services are so much easier t= o understand and to implement and to discuss.

And it's important secondly because it underlines the massive and o= verriding power of the Agent Domain, because an AD provides caps that give = access to services, and therefore it has more power in dictating policy tha= n any service to which it gives access.=A0 This places a mammoth constraint= upon David's first statement that "services are going to manage policy", because there will= be no access to those services at all unless an AD allows it.

(It's also worth pointing out that the AD's power to provide ca= ps is in direct conflict with the 2nd part of David's sentence (highlig= hted):=A0 "services are going to = manage policy, not the do= mains they reside in".=A0 The AD clearly is managing policy, = in a major way, by providing caps that allow access to services.)
Fortunately, the way out of this dilemma has already been provided by = Joshua, namely limiting the scope of the AD to agent-related services only,= while RDs control region-related services thus allowing DDP, in much the w= ay that Carlo desired many weeks ago. :-)

If ADs are limited to agent-only services such as authentication, then = there are no significant problems.=A0 For example, if ADs provides only aut= hentication, then AD2 doesn't need to be consulted when agent A1 telepo= rts from RD1 to RD2, since A1 is already authenticated with AD1 and additio= nal authentication with AD2 is not required.

However, if ADs also provide caps to region-related services such as As= set Services, then AD2 will need to be consulted when agent A1 teleports to= RD2, otherwise A1 won't have access to the assets of W2 that happen to= reside in RD2.

The following paragraph is crucial and its impact needs to be understoo= d.

If ADs are allowed to provide caps to asset services in any de= ployment pattern whatsoever, then AD2 will always have to be con= sulted if it exists, in all deployments, because W1 does not know wh= at kind of deployment pattern is used by W2.=A0 This affects our protocol v= ery strongly --- looking for an AD2 and querying it if it exists will not b= e optional.

Clearly we have some thinking to do about what is allowed in ADs if we = wish to avoid this.

Finally, I want to quote a sentence f= rom David's 2nd paragraph, which I think is quite illuminating:

=A0
If we keep this in mind, I think it helps us move away from thinking purely in terms of the split that Linden Labs has focused on.


I agree entirel= y.=A0 The rather coarse AD/RD split worked OK in its original scope as an i= mplementation mechanism for adding regions to an existing world, but it'= ;s not very helpful now that we have started examining what really needs to= happen for interop in multi-world deployments.

If we feel a need for additional domains, let's add them --- for ex= ample, a separate Storage Domain might be helpful to ensure that AD2 never = need to be consulted (unfortunately Asset Domain provides a conflicting abb= reviation).=A0 And if we feel the need to abandon the concept of domains en= tirely and just leave services, then let's do that too.=A0 After all, t= he domain model was meant to help, not hinder.=A0 Our work is concerned pri= marily with defining a protocol --- domains are optional!=A0 :-)


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

On Thu, Oct 1, 2009 at 11:25 PM= , David W Levine <dw= l@us.ibm.com> wrote:

One.. I think its very important t= o keep in mind that services are going to manage policy, not the domains they reside in. This is important, because it highlights the fact that what's going to happen when different people deploy this stuff in diffe= rent deployments is going to vary. =A0I think we need to be very careful to focus not on any one deployment pattern, but the broader set of possible deployment patterns we are attempting to enable. This goes hand in glove with Joshua's comments below.

This leads to

Two.. I *think* the correct model = is "All the services involved may have policies they bring to the table.&= quot; =A0The set of actions which are possible between an arbitrary service inside of one deployment and an arbitrary service inside another is going to be
dictated by the policies those two= services follow. =A0This is especially likely when looking at things like asset permissions. =A0Consider the case of a region attempting to pass a prim to an asset store for storage. The Region may have policies about which
asset stores it is willing to deli= ver assets to. The Asset store may have policies about which regions it is willing to accept assets from. If the user's agent domain holds his inv= entory (One, but not the only possible deployment pattern) it may have policies about
the asset servers it interacts wit= h. Its possible to imagine cases where the only role the ADs play in this policy decision is that they have authenticated the user,

We need to be careful, when lookin= g at this stuff to strike a balance between focusing on the current deployed clusterings, and turning everything into soup. That said, the actual deploy= ed systems which implement these specifications are only going to be able
to enforce policy at the interface= s we define, and these interfaces are on services, not domains. =A0In fact, as I've argued several times, I think, in general, the notion of a domain emerges from the policies of the deployed services, not the other way around. Infinity's made a very nice case for describing the key dis= tinctions as being "Agent domains include the auth service" and "Regio= n Domains include the presence service" =A0If we keep this in mind, I think it helps us move away from thinking purely in terms of the split that Linden Labs has focused on. To circle back to the question of soup, simply focusing on the services risks describing stuff that's falls int= o the HLA/DIS trap of having deployments which are each "conforming"= ; but vary so much in assumption as to not actually interoperate.

- David
~Zha





Joshua Bell <jo= sh@lindenlab.com>
Sent by: ogpx-bounces@ietf.org

10/01/2009 05:57 PM

To
ogpx@ietf.org
cc
Subject
Re: [ogpx] VWRAP Draft Charte= r - 2009 09 01






On Thu, Oct 1, 2009 at 2:34 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:

Your next step is to realize that, for two structurally identical worlds, if the seat of policy of one lies in its AD, then the seat of policy of the other also lies in its AD.=A0 Therefore your statement needs to be modified to the following:
IMHO, it should be apparent that both the AD of the so= urce world and the RD and AD of the destination world all need to make policy decisions.

=A0
I don't agree with this at all.

A VW service provider could operate a region domain with no agent domain. I believe this is VERY LOOSELY equivalent to running an OpenSim instance in Grid mode today (but I can't state that definitively) the person run= ning the sim is basically running just the region, and relying on someone else&#= 39;s agent domain (agent-centric services).

Similarly, BigGiantCo could operate an agent domain for their employs (as a bolt-on to their enterprise LDAP server, say) with no region domain.

A BigGiantCo employee can visit the RD-only VW - the AD talks to the RD to place the agent in a region. There aren't necessarily any other RDs or ADs involved at all. This is where protocol and policy come into play - the AD needs to communicate with and trust the RD and vice versa (even if that's nil-trust).
_= ______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx=


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00504502c3ec45476a047500f7dd-- From morgaine.dinova@googlemail.com Sat Oct 3 01:54:51 2009 Return-Path: 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 DEC0F3A685B for ; Sat, 3 Oct 2009 01:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 8GzwAQYUXOTN for ; Sat, 3 Oct 2009 01:54:50 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 584063A67F2 for ; Sat, 3 Oct 2009 01:54:48 -0700 (PDT) Received: by ewy28 with SMTP id 28so2238822ewy.42 for ; Sat, 03 Oct 2009 01:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jkHoMWwLr48u/j8ok7hVbMkWdvd/1yWx+mhMjMbb2Ik=; b=ioTYiEfF7PDNG5HAzXfQipQRYPkdZf9kaGuw54X44sp//F+IyslP+KgmSojLD0R91B nuG9PUtRnnO/ITpvwXNziZKky7YBAqpChjCjs8j+m2S73CdB0V4wuChatujZhE1OShsx i7Va95zJGeuguqIJV1oMXBdyiTwBB7AoCM0Ds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rJkAdyxydNL3NLRr7BOSNxcP4DFaVlCKrsfvXlGp0sfw8vdgNoex1Kiix1ncZ53zU8 ocQaEs2H8eWe7O5oeThRYMmqulwP1TExFotKYDk7ZQznRqhDsBwAEuPMIcDDCxdIiHKX A4/sfhtvKvR2Mn1ylJuhFlPVXPTRMKv6Y6v+Q= MIME-Version: 1.0 Received: by 10.211.146.2 with SMTP id y2mr749377ebn.21.1254560174511; Sat, 03 Oct 2009 01:56:14 -0700 (PDT) In-Reply-To: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> Date: Sat, 3 Oct 2009 09:56:14 +0100 Message-ID: From: Morgaine To: Infinity Linden Content-Type: multipart/alternative; boundary=001636c5a2828d16ea0475040d84 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 08:54:52 -0000 --001636c5a2828d16ea0475040d84 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 2, 2009 at 5:32 PM, Infinity Linden wrote: > > i am also disappointed that morgaine believes that simply making a > fiat statement like "we are arriving at DDP" makes it true. it is not > true. BOTH the agent domain and the region domain MUST have an > opportunity to express their policy. > Of course they must have that opportunity, and nobody said they mustn't. :-) You may have misinterpreted the scope of the DDP principle slightly, that's all. I explained its narrow scope at the end of this response to Joshua -- http://www.ietf.org/mail-archive/web/ogpx/current/msg00445.html . It applies only at the destination, so perhaps we should give it yet another 'D' and turn it into *Destination Determines Destination Policy*, although really it's implicit that it only applies in the destination region. Think of it just like in the physical world. If "When in Rome, do as the Romans do" isn't sufficient, then consider what happens when you travel from USA to France. When in France, French laws apply --- no US law has jurisdiction in France. Yet, despite French law being the only valid one during your stay, this doesn't mean that the US had no say in your exit from the US and your boarding of a plane. Nor does it mean that France has the power to override US laws while you are inside her borders, not does it mean that something you buy legally in France can necessarily be admitted into the US when you return. Despite DDP (or DDDP) in France, US law most certainly continues to apply in its own jurisdiction. However, US law does not apply on French soil when you travel there. Hopefully this squashes the worry that DDP means that AD1's agent-related policies have no opportunity to be expressed --- they can be expressed wherever agent-related policies are relevant to its agent A1. It is only the *region-related* policies of W2 that are determined by RD2 when A1 is in RD2. RD2 has no power beyond that. Morgaine. =================================== On Fri, Oct 2, 2009 at 5:32 PM, Infinity Linden wrote: > i am vaguely confused by the path we're taking. a lot of what we're > fretting over was discussed over the summer. > > i am also disappointed that morgaine believes that simply making a > fiat statement like "we are arriving at DDP" makes it true. it is not > true. BOTH the agent domain and the region domain MUST have an > opportunity to express their policy. > > the problem outlined by carlo above is interesting, but tractable. > > the agent domain is the entity with a direct relationship with the > user. we should not require the region domain to have information > about the user (such as the user's age.) and here's why... > > in VWRAP, as discussed before, it is the agent domain that acts as a > trust broker. the user trusts the agent domain and the agent domain > trusts the provider of other services (such as the agent presence > service running on a host in the region domain.) we do not require the > user to have a direct relationship with the region domain. instead, we > define trust transitively. > > if the agent domain must ensure that underage users do not visit > regions with adult content, then they should disallow underage user's > avatars from visiting those regions. if this is an organizational > policy that must be adhered to, then the agent domain should have > information to make that decision: the user's age and whether a > specific region (or entire region domain) allows adult content. > > if the region domain operator believes that the agent domain operator > may believe that an acceptable age to view adult content is lower than > they are comfortable with, they should communicate this concern at the > time that they are negotiating access. please note that in this > scenario, the evaluation of organizational policies is something that > is performed by humans, not automated systems. > > the policy enforcement tool the AD can use in this scenario is to > decide to not place a user's avatar in a particular region. the > information the AD uses to evaluate whether they want to allow or deny > a teleport request is largely not a concern of the protocol. though.. > if the decision depends on the state of a region in the region domain, > then there has to be a way to communicate this information from the > region domain to the agent domain. and that _is_ definitely a protocol > concern. > > the situation with the region domain is largely similar. the tool the > RD has to enforce policy in this scenario is to disallow an agent > domain from placing an avatar in one of it's regions. > > but i really like this example, so i created a diagram from this > example at > https://wiki.secondlife.com/wiki/File:VWRAP_adult_content_evaluation_example.jpg > . > > it shows two agent domains and two region domains. one of the agent > domains and one of the region domains define adult content as being > viewable by those 18 and older, the others think adult content is > viewable by those 21 and older. each has two regions; one of which has > adult content, the other does not. lets assume that the user is 19. > when the agent domain attempts to place an avatar in each of the > regions, you get 8 scenarios. > > A - no adult content in the region, AD allows transfer, RD allows transfer > B - adult content, but both the AD and RD agree that if you're 19, > you're okay to view adult content. AD allows transfer, RD allows > transfer. > C - no adult content in the region, AD allows transfer, RD allows transfer > D - adult content, but AD2 believes the user isn't old enough. AD does > not allow transfer. > E - no adult content in the region, AD allows transfer, RD allows transfer > F - no adult content in the region, AD allows transfer, RD allows transfer > G - adult content. AD1 believes the user is old enough, begins > transfer. RD believes the user is not old enough, disallows transfer. > H - adult content, but both AD2 and RD2 believe the user is old > enough. AD allows transfer, RD allows transfer. > > i think the most vexxing scenario is scenario G. it forces the RD to > make a policy decision based on information about the user maintained > by the agent domain. there are a couple of ways to handle this. > > 1. the agent domain and the region domain hash out an agreement > beforehand where the region domain operator tells the agent domain > operator the equivalent of... "whoa dude, you'll get me in trouble > with the state if you let 19 year olds into my adults only sim, PLEASE > block them from entering sims i mark as adult." this effectively turns > scenario G into scenario D for the AD2 / RD2 pairing. > > 2. the agent domain offers information in the teleport request about > the user's age to the RD, allowing the RD to disallow the transfer of > agent presence into adult regions. > > 3. the agent domain offers an interface the RD that lets the RD query > information about the user (including their age.) > > all of these have some drawbacks. my employer is probably most > interested in solution 1. linden views the relationship of agent > domain to region domain as a long-term trust relationship with a fair > amount of effort involved in setting it up. still, there are people > that want to have more of a tourist model where the user enters the > URL of a region into the client app and off you go without a > previously established agreements on policy enforcement. > > for the tourist model, you could do either 2 or 3. 2 has the advantage > that the RD doesn't need to make a request back to the AD before > deciding whether to complete the teleport. it has the disadvantage > that it requires the AD to give information about the user's age to an > RD who may or may not be trustworthy (cause... remember... we're > talking about the tourist model here.) > > i think what i'm getting at here is that carlo's example is > interesting, but it does yield to analysis. i think it also exposes > the difference between linden's vision of their service and what > morgaine (and presumably others) want people to build. but we can get > one protocol that works for both models, we just have to be careful, > and the end result will likely be more complicated than we would > prefer. but. welcome to the world of standards. > > -cheers > -meadhbh > --001636c5a2828d16ea0475040d84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 2, 2009 at 5:32 PM, Infinity Linden <infinity@lindenlab.com> = wrote:

i am also disappointed that morgaine believes that simply making a
fiat statement like "we are arriving at DDP" makes it true. it is= not
true. BOTH the agent domain and the region domain MUST have an
opportunity to express their policy.


Of course they must have that opportunity, and nobody = said they mustn't. :-)=A0 You may have misinterpreted the scope of the = DDP principle slightly, that's all.=A0 I explained its narrow scope at = the end of this response to Joshua -- http://www.ietf.org/mail-archive/web= /ogpx/current/msg00445.html .=A0 It applies only at the destination, so= perhaps we should give it yet another 'D' and turn it into Dest= ination Determines Destination Policy, although really it's implici= t that it only applies in the destination region.

Think of it just like in the physical world.=A0 If "When in Rome, = do as the Romans do" isn't sufficient, then consider what happens = when you travel from USA to France.=A0 When in France, French laws apply --= - no US law has jurisdiction in France.

Yet, despite French law being the only valid one during your stay, this= doesn't mean that the US had no say in your exit from the US and your = boarding of a plane.=A0 Nor does it mean that France has the power to overr= ide US laws while you are inside her borders, not does it mean that somethi= ng you buy legally in France can necessarily be admitted into the US when y= ou return.=A0 Despite DDP (or DDDP) in France, US law most certainly contin= ues to apply in its own jurisdiction.=A0 However, US law does not apply on = French soil when you travel there.

Hopefully this squashes the worry that DDP means that AD1's agent-r= elated policies have no opportunity to be expressed --- they can be express= ed wherever agent-related policies are relevant to its agent A1.=A0 It is o= nly the region-related policies of W2 that are determined by RD2 whe= n A1 is in RD2.=A0 RD2 has no power beyond that.


Morgaine.







=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

On Fri, Oct 2, 2009 at 5:32 PM, In= finity Linden <infinity@lindenlab.com> wrote:
i am vaguely conf= used by the path we're taking. a lot of what we're
fretting over was discussed over the summer.

i am also disappointed that morgaine believes that simply making a
fiat statement like "we are arriving at DDP" makes it true. it is= not
true. BOTH the agent domain and the region domain MUST have an
opportunity to express their policy.

the problem outlined by carlo above is interesting, but tractable.

the agent domain is the entity with a direct relationship with the
user. we should not require the region domain to have information
about the user (such as the user's age.) and here's why...

in VWRAP, as discussed before, it is the agent domain that acts as a
trust broker. the user trusts the agent domain and the agent domain
trusts the provider of other services (such as the agent presence
service running on a host in the region domain.) we do not require the
user to have a direct relationship with the region domain. instead, we
define trust transitively.

if the agent domain must ensure that underage users do not visit
regions with adult content, then they should disallow underage user's avatars from visiting those regions. if this is an organizational
policy that must be adhered to, then the agent domain should have
information to make that decision: the user's age and whether a
specific region (or entire region domain) allows adult content.

if the region domain operator believes that the agent domain operator
may believe that an acceptable age to view adult content is lower than
they are comfortable with, they should communicate this concern at the
time that they are negotiating access. please note that in this
scenario, the evaluation of organizational policies is something that
is performed by humans, not automated systems.

the policy enforcement tool the AD can use in this scenario is to
decide to not place a user's avatar in a particular region. the
information the AD uses to evaluate whether they want to allow or deny
a teleport request is largely not a concern of the protocol. though..
if the decision depends on the state of a region in the region domain,
then there has to be a way to communicate this information from the
region domain to the agent domain. and that _is_ definitely a protocol
concern.

the situation with the region domain is largely similar. the tool the
RD has to enforce policy in this scenario is to disallow an agent
domain from placing an avatar in one of it's regions.

but i really like this example, so i created a diagram from this
example at https://wiki.secondlife.com/= wiki/File:VWRAP_adult_content_evaluation_example.jpg
.

it shows two agent domains and two region domains. one of the agent
domains and one of the region domains define adult content as being
viewable by those 18 and older, the others think adult content is
viewable by those 21 and older. each has two regions; one of which has
adult content, the other does not. lets assume that the user is 19.
when the agent domain attempts to place an avatar in each of the
regions, you get 8 scenarios.

A - no adult content in the region, AD allows transfer, RD allows transfer<= br> B - adult content, but both the AD and RD agree that if you're 19,
you're okay to view adult content. AD allows transfer, RD allows
transfer.
C - no adult content in the region, AD allows transfer, RD allows transfer<= br> D - adult content, but AD2 believes the user isn't old enough. AD does<= br> not allow transfer.
E - no adult content in the region, AD allows transfer, RD allows transfer<= br> F - no adult content in the region, AD allows transfer, RD allows transfer<= br> G - adult content. AD1 believes the user is old enough, begins
transfer. RD believes the user is not old enough, disallows transfer.
H - adult content, but both AD2 and RD2 believe the user is old
enough. AD allows transfer, RD allows transfer.

i think the most vexxing scenario is scenario G. it forces the RD to
make a policy decision based on information about the user maintained
by the agent domain. there are a couple of ways to handle this.

1. the agent domain and the region domain hash out an agreement
beforehand where the region domain operator tells the agent domain
operator the equivalent of... "whoa dude, you'll get me in trouble=
with the state if you let 19 year olds into my adults only sim, PLEASE
block them from entering sims i mark as adult." this effectively turns=
scenario G into scenario D for the AD2 / RD2 pairing.

2. the agent domain offers information in the teleport request about
the user's age to the RD, allowing the RD to disallow the transfer of agent presence into adult regions.

3. the agent domain offers an interface the RD that lets the RD query
information about the user (including their age.)

all of these have some drawbacks. my employer is probably most
interested in solution 1. linden views the relationship of agent
domain to region domain as a long-term trust relationship with a fair
amount of effort involved in setting it up. still, there are people
that want to have more of a tourist model where the user enters the
URL of a region into the client app and off you go without a
previously established agreements on policy enforcement.

for the tourist model, you could do either 2 or 3. 2 has the advantage
that the RD doesn't need to make a request back to the AD before
deciding whether to complete the teleport. it has the disadvantage
that it requires the AD to give information about the user's age to an<= br> RD who may or may not be trustworthy (cause... remember... we're
talking about the tourist model here.)

i think what i'm getting at here is that carlo's example is
interesting, but it does yield to analysis. i think it also exposes
the difference between linden's vision of their service and what
morgaine (and presumably others) want people to build. but we can get
one protocol that works for both models, we just have to be careful,
and the end result will likely be more complicated than we would
prefer. but. welcome to the world of standards.

-cheers
-meadhbh

--001636c5a2828d16ea0475040d84-- From morgaine.dinova@googlemail.com Sat Oct 3 02:00:50 2009 Return-Path: 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 9B0043A6830 for ; Sat, 3 Oct 2009 02:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 AM0l7neqKqCE for ; Sat, 3 Oct 2009 02:00:48 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 0CA813A6802 for ; Sat, 3 Oct 2009 02:00:47 -0700 (PDT) Received: by ewy28 with SMTP id 28so2242737ewy.42 for ; Sat, 03 Oct 2009 02:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yKX35nQYh+oluD+wX/Sl2sR2PHQbL1SPwpW4+gTLiVk=; b=e/t/haNDImOpVVINLirM08scFjjiV5G+spQEOo9+ZMJPpCdWM2frZQA/WCvuGohLGY i+MEhWUcA1HTK+xfiHohwi94H4tZgcSg9aWw/puMlQ58NWBxkMPUy5MYFILOtOMXmfXI b4PUwBMm0qobVu0wRDRw2DmcPuohmbnxdU9zA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Clso/GoPlvaN0LDId2EVnJJwxAqIMCl9lJCr9QrycHyw4PZjCMKyLavP/27BLbLbRr NmI3BjZi9HBQd780eHa7Rq1D7PnhkwGdzUqMaPV0aHbNsDL5uT0sTsXaxy86g6QvHhCg MIg43TyM7a5cPnf3lJ2gNHOupyN5OdUJCYQVs= MIME-Version: 1.0 Received: by 10.211.156.13 with SMTP id i13mr4447788ebo.22.1254560534306; Sat, 03 Oct 2009 02:02:14 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> Date: Sat, 3 Oct 2009 10:02:14 +0100 Message-ID: From: Morgaine To: Joshua Bell Content-Type: multipart/alternative; boundary=00504502d2edff273b047504224a Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 09:00:50 -0000 --00504502d2edff273b047504224a Content-Type: text/plain; charset=ISO-8859-1 I'm totally in accord with you on all points here, Joshua. You raised a question about what I meant in one particular section, and the answer to that is *initially* that "it's fine under your preferred interpretation". However, further down I then show that we're forced to merge the two interpretations for symmetry or "bad things happen", so it turns out not to be an either/or answer. This was your query: On Fri, Oct 2, 2009 at 4:55 PM, Joshua Bell wrote: > > On Thu, Oct 1, 2009 at 10:52 PM, Morgaine wrote: > >> >> One promising angle stems from this very interesting phrase of yours: >> >> ... by definition the AD2 and RD2 services are disjoint. >>> >> >> It's a bit ambiguous though: >> >> - If by this you mean that AD1 has no say over region services in RD2, >> then that's very cool! :-) (It's cool because it provides DDP and hence >> allows tourism.) >> >> > Did you mean AD2 or AD1? I agree for AD2. For AD1, being nitpicky, here's a > scenario that possibly contradicts that: if RD2 tries to give you inventory, > AD1 may refuse it since it is the final arbiter of your agent (and hence > your inventory). I'm not sure if that counts as "say over region services" > or not. Based on previous conversation, I think we agree that in that > scenario, AD1 is enforcing agent-related policy in the interaction with > region services, not "having a say" over those region services. > That you agree for AD2 is crucial, so let's accept that, and let's leave AD1 contributing to A1's asset service policy when in RD2 (as well as in charge of asset service policy in RD1 for consistency) for now as you suggest. (This is going to change slightly when we look at its ramifications in a few paragraphs.) > - But instead you might mean the following: "*if RD2 uses some service > of type X, say X2, then AD1 cannot provide an X service when in RD2"*. > That would be extremely not cool, since this would totally block meaningful > tourism. For example, RD2 could be using Asset Service AS2, as a result of > which AD1 would not supply an asset service to its travelling agent A1, and > hence A1 would never be able to appear in RD2 wearing any asset available in > W1. Clearly this interpretation would mean no useful interop between W1 and > W2 at all. I'm hoping this interpretation is wrong. > > This is an extremely good point. "Disjoint" was too strong a word. I don't > think we've sorted out assets yet, but from early brainstorming, asset > services could indeed be provided by both ADs and RDs. (And a VW provider > might host just one asset service that its ADs and RDs both reference.) > "Mostly disjoint" :) > Excellent. :-) It's great that this point is taken and we understand that asset service cannot come *only* from the destination RD, nor from W1 alone. Unfortunately, this means that now the key paragraph I wrote in answer to David in post http://www.ietf.org/mail-archive/web/ogpx/current/msg00449.html comes into play, which I'll rewrite here for easy reading and with more explanation added: If ADs are allowed to provide caps to asset services *in any deployment pattern whatsoever*, then AD2 will *always* have to be consulted if it exists, *in all deployments*, because nobody knows what kind of deployment pattern is used in W2, so AD2 might be providing asset services as well as RD2. This affects our protocol very strongly --- looking for an AD2 and querying it if it exists will not be optional. By noting that we require Asset Services contributions from both W1 and W2, then if the W1 contribution is made to come from AD1, we have lumbered ourselves with the need to consult AD2 because of symmetry (if AD1 can provide asset services then so can AD2, so it must be consulted). This is not what we wanted. I can see two ways out of this dilemma: 1. Let the W1 asset service contribution come *not from AD1* but from * RD1*. This not only avoids the need to consult ADs on asset services, but it is also nicely symmetrical for both source and destination, and it also respects the maxim "ADs do not provide region-related services" and hence allows DDP. This is the clear winner on all counts. 2. Alternatively, define another domain to carry asset services, such as a Storage Domain, so that ADs do not need to provide region-related services. I don't see any real benefit in this, given that option 1 seems so good. It's just substituting an SD2 lookup in place of the unwanted AD2 lookup. That's close to being a mere word change so I don't find any real merit in it. Option 2 is so bad (I think) that really I'm only proposing option 1. Option 1 makes the VWRAP model in respect of asset services very simple and symmetric, as well as consistent with our common view in the last pair of emails: - ADs do not provide any asset services at all. - RDs are the sole providers of asset services. These asset services are provided to all three categories of agent: (i) homeworld residents in a home RD, (ii) homeworld residents touring in other worlds, and (iii) foreign tourists arriving in the home RD from other worlds. Such a scheme avoids needing to consult RD2, while still providing A1 with W1 assets to carry into RD2 for full interop alongside W2's assets provided by RD2. And of course it's a DDP scheme since RD2 has full control over its own policies, so this allows full tourism. How does this sound? Morgaine. ======================================== On Fri, Oct 2, 2009 at 4:55 PM, Joshua Bell wrote: > > On Thu, Oct 1, 2009 at 10:52 PM, Morgaine wrote: > >> >> Unfortunately, you then wrote: >> >> it should be the case that ADs carry policies about region services... >> >> Is there a typo in that? If it's free of typos and hence ADs carry >> policies about region services, then clearly AD2 *does* have to be >> consulted before you can TP from RD1 to RD2. (I assume it has a typo, and >> you actually meant to write "do *not* carry policies about region >> services", to make this line consistent with what you said above.) >> >> > Ugh, yes, typo... I indeed meant to echo your statement: "ADs carry no > region-related policies". Thanks for catching that. > > > One promising angle stems from this very interesting phrase of yours: >> >> ... by definition the AD2 and RD2 services are disjoint. >>> >> >> It's a bit ambiguous though: >> >> - If by this you mean that AD1 has no say over region services in RD2, >> then that's very cool! :-) (It's cool because it provides DDP and hence >> allows tourism.) >> >> > Did you mean AD2 or AD1? I agree for AD2. For AD1, being nitpicky, here's a > scenario that possibly contradicts that: if RD2 tries to give you inventory, > AD1 may refuse it since it is the final arbiter of your agent (and hence > your inventory). I'm not sure if that counts as "say over region services" > or not. Based on previous conversation, I think we agree that in that > scenario, AD1 is enforcing agent-related policy in the interaction with > region services, not "having a say" over those region services. > > >> >> - >> - But instead you might mean the following: "*if RD2 uses some >> service of type X, say X2, then AD1 cannot provide an X service when in RD2" >> *. That would be extremely not cool, since this would totally block >> meaningful tourism. For example, RD2 could be using Asset Service AS2, as a >> result of which AD1 would not supply an asset service to its travelling >> agent A1, and hence A1 would never be able to appear in RD2 wearing any >> asset available in W1. Clearly this interpretation would mean no useful >> interop between W1 and W2 at all. I'm hoping this interpretation is wrong. >> >> This is an extremely good point. "Disjoint" was too strong a word. I don't > think we've sorted out assets yet, but from early brainstorming, asset > services could indeed be provided by both ADs and RDs. (And a VW provider > might host just one asset service that its ADs and RDs both reference.) > "Mostly disjoint" :) > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00504502d2edff273b047504224a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm totally in accord with you on all points here, Joshua.

You r= aised a question about what I meant in one particular section, and the answ= er to that is initially=A0 that "it's fine under your prefe= rred interpretation".=A0 However, further down I then show that we'= ;re forced to merge the two interpretations for symmetry or "bad thing= s happen", so it turns out not to be an either/or answer.=A0 This was = your query:

On Fri, Oct 2, 2009 at 4:55 PM, Joshua Bell <josh@lindenlab.com&g= t; wrote:

On Thu, Oct 1, 2009 at 10:52 PM, Morgai= ne <morgaine.dinova@googlemail.com> wrote:

One promising angle stems from this very interesting phrase of yours:
... by definiti= on the AD2 and RD2 services are disjoint.

It's a bit ambiguous though:
  • If by this you mean that AD1 has no say over region services in RD2, then that's very cool! :-)=A0 (It's cool because it provides DDP and hen= ce allows tourism.)

Did you mean AD2 or AD1? I agree for AD2. For AD1, being nitpicky, here's a scenario that possibly contradicts that: if RD2 tries to give you inventory, AD1 may refuse it since it is the final arbiter of your agent (and hence your inventory). I'm not sure if that counts as "say over region services" or = not. Based on previous conversation, I think we agree that in that scenario, AD1 is enforcing agent-related policy in the interaction with region services, not "having a say" over those region services.=A0


That you agree for AD2 is crucial= , so let's accept that, and let's leave AD1 contributing to A1'= s asset service policy when in RD2 (as well as in charge of asset service p= olicy in RD1 for consistency) for now as you suggest.=A0 (This is going to = change slightly when we look at its ramifications in a few paragraphs.)


  • But instead you might mean the followi= ng:=A0 "if RD2 uses some service of type X, say X2, then AD1 cannot= provide an X service when in RD2".=A0 That would be extremely not cool, since this would totally block meaningful tourism.=A0 For example, RD2 could be using Asset Service AS2, as a result of which AD1 would not supply an asset service to its travelling agent A1, and hence A1 would never be able to appear in RD2 wearing any asset available in W1.=A0 Clearly this interpretation would mean no useful interop between W1 and W2 at all.=A0 I'm hoping this interpretation is wrong.
This is an extremely good point. "Disjoint" was too strong a word. I don't think we'= ;ve sorted out assets yet, but from early brainstorming, asset services could indeed be provided by both ADs and RDs. (And a VW provider might host just one asset service that its ADs and RDs both reference.) "Mostly disjoint&q= uot; :)
=A0

Excellent. :-)=A0 It'= s great that this point is taken and we understand that asset service canno= t come only from the destination RD, nor from W1 alone.=A0 Unfortuna= tely, this means that now the key paragraph I wrote in answer to David in p= ost http://www.ietf.org/mail-archive/web/ogpx/current/ms= g00449.html comes into play, which I'll rewrite here for easy readi= ng and with more explanation added:

If ADs are allowed to provide caps to= asset services in any deployment pattern whatsoever, then AD2 will = always have to be consulted if it exists, in all deploy= ments, because nobody knows what kind of deployment pattern is used in W2, so AD2 might be providing asset services as well as RD2.=A0 This affect= s our protocol very strongly --- looking for an AD2 and querying it if it exists will not be optional.


By noting t= hat we require Asset Services contributions from both W1 and W2, then if th= e W1 contribution is made to come from AD1, we have lumbered ourselves with= the need to consult AD2 because of symmetry (if AD1 can provide asset serv= ices then so can AD2, so it must be consulted).=A0 This is not what we want= ed.

I can see two ways out of this dilemma:
  1. Let the W1 asset ser= vice contribution come not from AD1 but from RD1.=A0 This not= only avoids the need to consult ADs on asset services, but it is also nice= ly symmetrical for both source and destination, and it also respects the ma= xim "ADs do not provide region-related services" and hence allows= DDP.=A0 This is the clear winner on all counts.
  2. Alternatively, define another domain to carry asset services, such= as a Storage Domain, so that ADs do not need to provide region-related ser= vices.=A0 I don't see any real benefit in this, given that option 1 see= ms so good.=A0 It's just substituting an SD2 lookup in place of the unw= anted AD2 lookup.=A0 That's close to being a mere word change so I don&= #39;t find any real merit in it.

Option 2 is so bad (I think) that really I'm only proposing op= tion 1.=A0 Option 1 makes the VWRAP model in respect of asset services very= simple and symmetric, as well as consistent with our common view in the la= st pair of emails:

  • ADs do not provide any asset services at all.
  • RDs are t= he sole providers of asset services.=A0 These asset services are provided t= o all three categories of agent: (i) homeworld residents in a home RD, (ii)= homeworld residents touring in other worlds, and (iii) foreign tourists ar= riving in the home RD from other worlds.

Such a scheme avoids needing to consult RD2, while still prov= iding A1 with W1 assets to carry into RD2 for full interop alongside W2'= ;s assets provided by RD2.=A0 And of course it's a DDP scheme since RD2= has full control over its own policies, so this allows full tourism.


How does this sound?


Morgaine.







=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Fri, Oct 2, 2009 at 4:55 PM, Joshua Bell <josh@linden= lab.com> wrote:

On Thu, Oct 1, 2009 at 10:52 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:

Unfortunately, you then wrote:
=A0
it should be th= e case that ADs carry policies about region services...

Is there a typo in that?= =A0 If it's free of typos and hence ADs carry policies about region services, then clearly AD2 does have to be consulted be= fore you can TP from RD1 to RD2.=A0 (I assume it has a typo, and you actual= ly meant to write "do not carry policies about region services", to make this line consistent with what you sai= d above.)


Ugh, yes, typo... I indeed meant= to echo your statement: "ADs carry no region-related policies". = Thanks for catching that.


One promising angle stems from this very interesting phrase of yours:
... by definiti= on the AD2 and RD2 services are disjoint.

It's a bit ambiguous though:
  • If by thi= s you mean that AD1 has no say over region services in RD2, then that's= very cool! :-)=A0 (It's cool because it provides DDP and hence allows = tourism.)

Did you mean AD2 or AD1? I agre= e for AD2. For AD1, being nitpicky, here's a scenario that possibly con= tradicts that: if RD2 tries to give you inventory, AD1 may refuse it since = it is the final arbiter of your agent (and hence your inventory). I'm n= ot sure if that counts as "say over region services" or not. Base= d on previous conversation, I think we agree that in that scenario, AD1 is = enforcing agent-related policy in the interaction with region services, not= "having a say" over those region services.
=A0
  • But instead you might mean the following:=A0 "if RD2 uses = some service of type X, say X2, then AD1 cannot provide an X service when i= n RD2".=A0 That would be extremely not cool, since this would tota= lly block meaningful tourism.=A0 For example, RD2 could be using Asset Serv= ice AS2, as a result of which AD1 would not supply an asset service to its = travelling agent A1, and hence A1 would never be able to appear in RD2 wear= ing any asset available in W1.=A0 Clearly this interpretation would mean no= useful interop between W1 and W2 at all.=A0 I'm hoping this interpreta= tion is wrong.
This is an extremely good point. &q= uot;Disjoint" was too strong a word. I don't think we've sorte= d out assets yet, but from early brainstorming, asset services could indeed= be provided by both ADs and RDs. (And a VW provider might host just one as= set service that its ADs and RDs both reference.) "Mostly disjoint&quo= t; :)




_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00504502d2edff273b047504224a-- From vaughn.deluca@gmail.com Sat Oct 3 04:53:49 2009 Return-Path: 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 EDF143A6825 for ; Sat, 3 Oct 2009 04:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 bG1zDQtAwWBK for ; Sat, 3 Oct 2009 04:53:48 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 0451F3A6886 for ; Sat, 3 Oct 2009 04:53:47 -0700 (PDT) Received: by bwz6 with SMTP id 6so1586501bwz.37 for ; Sat, 03 Oct 2009 04:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=i9AGLoQHjgdIOaUZDZJYrtrAGcv9rGZKZfuk9XF218I=; b=SfPz2kpvlWwzTEfyW047Iejex2JlZmv6EkPv/Y6m6piiYXO1boW412+Os4VOcvzAJe fFUi20SbqMdcinORg9svQj91HjvR8xm8qV3opj++DAYR+0ZD/pKfbesH/kGj8R+LqEM4 XHbfsNvGrgrJ5EeqZEgH6+9aNCNCW1busmREA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hO1Ea+X9B3lJ035BGqx/TxkPbFzrHLN7V5wZTqzNn6YyDiLb0wEP4anySXCa6GWgs7 BT+Ilijv1wmuq/WsUYQR92B1vxg5+urQ+Rknl6mQhu3nCDAhjGm8BBTdBTyUZIFdNCyG GASGhNF14vXfDckaa4jZeYJNBoVicETs51+DY= MIME-Version: 1.0 Received: by 10.204.34.65 with SMTP id k1mr2113042bkd.111.1254570911576; Sat, 03 Oct 2009 04:55:11 -0700 (PDT) In-Reply-To: References: <3a880e2c0909031149kda16e64neb4184ca70f59745@mail.gmail.com> <9b8a8de40909270716s25dc3a13v1a11917c3d37ce3a@mail.gmail.com> <3a880e2c0909270811s7abc399crcad8c0eed3027a1@mail.gmail.com> Date: Sat, 3 Oct 2009 13:55:11 +0200 Message-ID: <9b8a8de40910030455p47875547jdd63d85f7e12fc09@mail.gmail.com> From: Vaughn Deluca To: Meadhbh Siobhan Content-Type: multipart/alternative; boundary=00032555753287b5eb0475068ddb Cc: ogpx@ietf.org Subject: Re: [ogpx] refined idea for documents.. X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 11:53:50 -0000 --00032555753287b5eb0475068ddb Content-Type: text/plain; charset=ISO-8859-1 In an attempt to add more details in the deployment patterns I started to do some homework. I found this: http://wiki.secondlife.com/wiki/OGP_Teleport_Draft_3 Is there a newer version of this document? Is it more or less safe to use this as an starting point of my thinking about OGP/VWRAP? -Vaughn On Mon, Sep 28, 2009 at 3:33 PM, Meadhbh Siobhan wrote: > okay. discuss away! > > On Mon, Sep 28, 2009 at 12:26 AM, Morgaine > wrote: > > A good way of proceeding would be to discuss David's deployment patterns > > first, before cranking out a new intro document. After all, there is a > lot > > of good material there, hinting at many useful use cases. Then any new > > document would have a chance of reflecting the viewpoints of the group so > > far, and building on the consensus. > > > > Ref: http://tools.ietf.org/html/draft-levine-ogp-layering-00 > > > > > > Morgaine. > > > > > > > > > > > > > > ====================================== > > > > On Sun, Sep 27, 2009 at 4:11 PM, Infinity Linden > > > wrote: > >> > >> yup. we're actually in the process of adding the deployment pattern > >> stuff to the intro doc. great minds think alike! > >> > >> On Sun, Sep 27, 2009 at 7:16 AM, Vaughn Deluca > > >> wrote: > >> > On Thu, Sep 3, 2009 at 8:49 PM, Infinity > >> > Linden wrote: > >> >> > >> >> hey peeps... > >> >> > >> >> i was thinking about it, and came up with a slightly different list > of > >> >> documents: > >> >> > >> >> * intro and goals (used to be called intro and requirements) > >> >> * abstract type system (used to be called LLSD) > >> >> * foundations > >> >> * the VWRAP trust/security model > >> >> * virtual world description format > >> >> * client application launch message > >> >> * agent presence establishment > >> >> * avatar format > >> >> * asset format and access > >> >> * chat/voice establishment > >> >> * user profile access > >> >> * time sensitive messages > >> >> > >> >> [snip] > >> >> > >> >> * intro and goals ( based on > >> >> http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 ) > >> >> * social context of virtual worlds - why they're interesting > >> >> * very high level description of virtual world characteristics - not > >> >> what a virtual world "is" as much as features of a virtual world you > >> >> may not have thought about. > >> >> * how VWRAP virtual worlds differ from other virtual worlds - how > >> >> OpenSim and SecondLife differ on a technology level from WoW > >> >> * protocol objectives and goals - specific features of the protocol > >> >> > >> >> * this doc is it's own document because we think there's a need for > >> >> a lot of background, and it's mostly non-technical. > >> > > >> > [snip ] > >> > I would suggest to add some stuff > >> > from http://tools.ietf.org/html/draft-levine-ogp-layering > >> > The use cases given there would come a long way to clarify the current > >> > confusion over what we can call a virtual world and what the main seat > >> > of > >> > policy is in these cases. > >> > Vaughn > >> _______________________________________________ > >> ogpx mailing list > >> ogpx@ietf.org > >> https://www.ietf.org/mailman/listinfo/ogpx > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --00032555753287b5eb0475068ddb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In an attempt to add more details in the deployment patterns I started= to do some homework. I found this:=A0

Is there a newer version of this document? Is it more o= r less safe to use this as an starting point of my thinking about OGP/VWRAP= ?

-Vaughn

On M= on, Sep 28, 2009 at 3:33 PM, Meadhbh Siobhan <meadhbh.siobhan@gmail.com> wrote:
okay. discuss away!

On Mon, Sep 28, 2009 at 12:26 AM, Morgaine
<morgaine.dinova@googl= email.com> wrote:
> A good way of proceeding would be to discuss David's deployment pa= tterns
> first, before cranking out a new intro document.=A0 After all, there i= s a lot
> of good material there, hinting at many useful use cases.=A0 Then any = new
> document would have a chance of reflecting the viewpoints of the group= so
> far, and building on the consensus.
>
> Ref:=A0 http://tools.ietf.org/html/draft-levine-ogp-layerin= g-00
>
>
> Morgaine.
>
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On Sun, Sep 27, 2009 at 4:11 PM, Infinity Linden <infinity@lindenlab.com>
> wrote:
>>
>> yup. we're actually in the process of adding the deployment pa= ttern
>> stuff to the intro doc. great minds think alike!
>>
>> On Sun, Sep 27, 2009 at 7:16 AM, Vaughn Deluca <vaughn.deluca@gmail.com>
>> wrote:
>> > On Thu, Sep 3, 2009 at 8:49 PM, Infinity
>> > Linden=A0<infini= ty@lindenlab.com>=A0wrote:
>> >>
>> >> hey peeps...
>> >>
>> >> i was thinking about it, and came up with a slightly diff= erent list of
>> >> documents:
>> >>
>> >> * intro and goals (used to be called intro and requiremen= ts)
>> >> * abstract type system (used to be called LLSD)
>> >> * foundations
>> >> * the VWRAP trust/security model
>> >> * virtual world description format
>> >> * client application launch message
>> >> * agent presence establishment
>> >> * avatar format
>> >> * asset format and access
>> >> * chat/voice establishment
>> >> * user profile access
>> >> * time sensitive messages
>> >>
>> >> [snip]
>> >>
>> >> * intro and goals ( based on
>> >> http://tools.ietf.org/html/draft-hamrick-ogp-int= ro-00=A0)
>> >> =A0* social context of virtual worlds - why they're i= nteresting
>> >> =A0* very high level description of virtual world charact= eristics - not
>> >> what a virtual world "is" as much as features o= f a virtual world you
>> >> may not have thought about.
>> >> =A0* how VWRAP virtual worlds differ from other virtual w= orlds - how
>> >> OpenSim and SecondLife differ on a technology level from = WoW
>> >> =A0* protocol objectives and goals - specific features of= the protocol
>> >>
>> >> =A0* this doc is it's own document because we think t= here's a need for
>> >> a lot of background, and it's mostly non-technical. >> >
>> > [snip ]
>> > I would suggest to add some stuff
>> > from=A0http://tools.ietf.org/html/draft-levine-ogp-la= yering
>> > The use cases given there would come a long way to clarify th= e current
>> > confusion over what we can call a virtual world and what the = main seat
>> > of
>> > policy is in these cases.
>> > Vaughn
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

--00032555753287b5eb0475068ddb-- From infinity@lindenlab.com Sat Oct 3 09:26:28 2009 Return-Path: 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 B4B893A69EF for ; Sat, 3 Oct 2009 09:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 5sgW6AYY4zVP for ; Sat, 3 Oct 2009 09:26:27 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id A90B33A697C for ; Sat, 3 Oct 2009 09:26:27 -0700 (PDT) Received: by pxi6 with SMTP id 6so2192965pxi.32 for ; Sat, 03 Oct 2009 09:27:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.118.3 with SMTP id q3mr423262wfc.9.1254587273775; Sat, 03 Oct 2009 09:27:53 -0700 (PDT) In-Reply-To: <9b8a8de40910030455p47875547jdd63d85f7e12fc09@mail.gmail.com> References: <3a880e2c0909031149kda16e64neb4184ca70f59745@mail.gmail.com> <9b8a8de40909270716s25dc3a13v1a11917c3d37ce3a@mail.gmail.com> <3a880e2c0909270811s7abc399crcad8c0eed3027a1@mail.gmail.com> <9b8a8de40910030455p47875547jdd63d85f7e12fc09@mail.gmail.com> Date: Sat, 3 Oct 2009 09:27:53 -0700 Message-ID: <3a880e2c0910030927yec33851n9bf213f47e1a8300@mail.gmail.com> From: Infinity Linden To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Meadhbh Siobhan , ogpx@ietf.org Subject: Re: [ogpx] refined idea for documents.. X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 16:26:28 -0000 yup vaughn. that's the teleport draft we made after the 2008 interop tests. if i remember correctly, we didn't modify the code on vaak to follow this draft. and... we found a few things we wanted to change from this draft over the last year. but i think that about 99% of what's in the text on the wiki is going to show up in the teleport internet draft. stuff we've said we want to add includes discussion on policy and where policy enforcement points might be, as well as being slightly more clear where region caps for teleport come from and the relationship between teleport caps (that are given to agent domains the region trusts) and long lived information URLs (that may or may not be capabilities) with public information about the region. -cheers -meadhbh On Sat, Oct 3, 2009 at 4:55 AM, Vaughn Deluca wro= te: > In an attempt to add more details in the deployment patterns I started to= do > some homework. I found this: > http://wiki.secondlife.com/wiki/OGP_Teleport_Draft_3 > Is there a newer version of this document? Is it more or less safe to use > this as an starting point of my thinking about OGP/VWRAP? > -Vaughn > On Mon, Sep 28, 2009 at 3:33 PM, Meadhbh Siobhan > wrote: >> >> okay. discuss away! >> >> On Mon, Sep 28, 2009 at 12:26 AM, Morgaine >> wrote: >> > A good way of proceeding would be to discuss David's deployment patter= ns >> > first, before cranking out a new intro document.=A0 After all, there i= s a >> > lot >> > of good material there, hinting at many useful use cases.=A0 Then any = new >> > document would have a chance of reflecting the viewpoints of the group >> > so >> > far, and building on the consensus. >> > >> > Ref:=A0 http://tools.ietf.org/html/draft-levine-ogp-layering-00 >> > >> > >> > Morgaine. >> > >> > >> > >> > >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > On Sun, Sep 27, 2009 at 4:11 PM, Infinity Linden >> > >> > wrote: >> >> >> >> yup. we're actually in the process of adding the deployment pattern >> >> stuff to the intro doc. great minds think alike! >> >> >> >> On Sun, Sep 27, 2009 at 7:16 AM, Vaughn Deluca >> >> >> >> wrote: >> >> > On Thu, Sep 3, 2009 at 8:49 PM, Infinity >> >> > Linden=A0=A0wrote: >> >> >> >> >> >> hey peeps... >> >> >> >> >> >> i was thinking about it, and came up with a slightly different lis= t >> >> >> of >> >> >> documents: >> >> >> >> >> >> * intro and goals (used to be called intro and requirements) >> >> >> * abstract type system (used to be called LLSD) >> >> >> * foundations >> >> >> * the VWRAP trust/security model >> >> >> * virtual world description format >> >> >> * client application launch message >> >> >> * agent presence establishment >> >> >> * avatar format >> >> >> * asset format and access >> >> >> * chat/voice establishment >> >> >> * user profile access >> >> >> * time sensitive messages >> >> >> >> >> >> [snip] >> >> >> >> >> >> * intro and goals ( based on >> >> >> http://tools.ietf.org/html/draft-hamrick-ogp-intro-00=A0) >> >> >> =A0* social context of virtual worlds - why they're interesting >> >> >> =A0* very high level description of virtual world characteristics = - >> >> >> not >> >> >> what a virtual world "is" as much as features of a virtual world y= ou >> >> >> may not have thought about. >> >> >> =A0* how VWRAP virtual worlds differ from other virtual worlds - h= ow >> >> >> OpenSim and SecondLife differ on a technology level from WoW >> >> >> =A0* protocol objectives and goals - specific features of the prot= ocol >> >> >> >> >> >> =A0* this doc is it's own document because we think there's a need= for >> >> >> a lot of background, and it's mostly non-technical. >> >> > >> >> > [snip ] >> >> > I would suggest to add some stuff >> >> > from=A0http://tools.ietf.org/html/draft-levine-ogp-layering >> >> > The use cases given there would come a long way to clarify the >> >> > current >> >> > confusion over what we can call a virtual world and what the main >> >> > seat >> >> > of >> >> > policy is in these cases. >> >> > Vaughn >> >> _______________________________________________ >> >> ogpx mailing list >> >> ogpx@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ogpx >> > >> > >> > _______________________________________________ >> > ogpx mailing list >> > ogpx@ietf.org >> > https://www.ietf.org/mailman/listinfo/ogpx >> > >> > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From dwl@us.ibm.com Sat Oct 3 09:31:02 2009 Return-Path: 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 D18B83A690D; Sat, 3 Oct 2009 09:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.836 X-Spam-Level: X-Spam-Status: No, score=-5.836 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, 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 qBKLDAhxbVat; Sat, 3 Oct 2009 09:31:01 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id A13A93A67FB; Sat, 3 Oct 2009 09:31:00 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n93GP1IG006645; Sat, 3 Oct 2009 12:25:01 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n93GWMxp252184; Sat, 3 Oct 2009 12:32:22 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n93GWLqA002150; Sat, 3 Oct 2009 12:32:22 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n93GWLcq002147; Sat, 3 Oct 2009 12:32:21 -0400 In-Reply-To: <3a880e2c0910030927yec33851n9bf213f47e1a8300@mail.gmail.com> References: <3a880e2c0909031149kda16e64neb4184ca70f59745@mail.gmail.com> <9b8a8de40909270716s25dc3a13v1a11917c3d37ce3a@mail.gmail.com> <3a880e2c0909270811s7abc399crcad8c0eed3027a1@mail.gmail.com> <9b8a8de40910030455p47875547jdd63d85f7e12fc09@mail.gmail.com> <3a880e2c0910030927yec33851n9bf213f47e1a8300@mail.gmail.com> To: Infinity Linden MIME-Version: 1.0 X-KeepSent: E82085C7:4E50DA11-85257644:005AC654; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Sat, 3 Oct 2009 12:32:21 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/03/2009 12:32:21, Serialize complete at 10/03/2009 12:32:21 Content-Type: multipart/alternative; boundary="=_alternative 005ADA3A85257644_=" Cc: Meadhbh Siobhan , ogpx@ietf.org, ogpx-bounces@ietf.org Subject: Re: [ogpx] refined idea for documents.. X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 16:31:02 -0000 This is a multipart message in MIME format. --=_alternative 005ADA3A85257644_= Content-Type: text/plain; charset="US-ASCII" I think you can also expect some updates to that draft based on my group's experience with implmenting an Agent Domain this past year. In particular, some feedback on extension patterns. - David Infinity Linden Sent by: ogpx-bounces@ietf.org 10/03/2009 12:27 PM To Vaughn Deluca cc Meadhbh Siobhan , ogpx@ietf.org Subject Re: [ogpx] refined idea for documents.. yup vaughn. that's the teleport draft we made after the 2008 interop tests. if i remember correctly, we didn't modify the code on vaak to follow this draft. and... we found a few things we wanted to change from this draft over the last year. but i think that about 99% of what's in the text on the wiki is going to show up in the teleport internet draft. stuff we've said we want to add includes discussion on policy and where policy enforcement points might be, as well as being slightly more clear where region caps for teleport come from and the relationship between teleport caps (that are given to agent domains the region trusts) and long lived information URLs (that may or may not be capabilities) with public information about the region. -cheers -meadhbh On Sat, Oct 3, 2009 at 4:55 AM, Vaughn Deluca wrote: > In an attempt to add more details in the deployment patterns I started to do > some homework. I found this: > http://wiki.secondlife.com/wiki/OGP_Teleport_Draft_3 > Is there a newer version of this document? Is it more or less safe to use > this as an starting point of my thinking about OGP/VWRAP? > -Vaughn > On Mon, Sep 28, 2009 at 3:33 PM, Meadhbh Siobhan > wrote: >> >> okay. discuss away! >> >> On Mon, Sep 28, 2009 at 12:26 AM, Morgaine >> wrote: >> > A good way of proceeding would be to discuss David's deployment patterns >> > first, before cranking out a new intro document. After all, there is a >> > lot >> > of good material there, hinting at many useful use cases. Then any new >> > document would have a chance of reflecting the viewpoints of the group >> > so >> > far, and building on the consensus. >> > >> > Ref: http://tools.ietf.org/html/draft-levine-ogp-layering-00 >> > >> > >> > Morgaine. >> > >> > >> > >> > >> > >> > >> > ====================================== >> > >> > On Sun, Sep 27, 2009 at 4:11 PM, Infinity Linden >> > >> > wrote: >> >> >> >> yup. we're actually in the process of adding the deployment pattern >> >> stuff to the intro doc. great minds think alike! >> >> >> >> On Sun, Sep 27, 2009 at 7:16 AM, Vaughn Deluca >> >> >> >> wrote: >> >> > On Thu, Sep 3, 2009 at 8:49 PM, Infinity >> >> > Linden wrote: >> >> >> >> >> >> hey peeps... >> >> >> >> >> >> i was thinking about it, and came up with a slightly different list >> >> >> of >> >> >> documents: >> >> >> >> >> >> * intro and goals (used to be called intro and requirements) >> >> >> * abstract type system (used to be called LLSD) >> >> >> * foundations >> >> >> * the VWRAP trust/security model >> >> >> * virtual world description format >> >> >> * client application launch message >> >> >> * agent presence establishment >> >> >> * avatar format >> >> >> * asset format and access >> >> >> * chat/voice establishment >> >> >> * user profile access >> >> >> * time sensitive messages >> >> >> >> >> >> [snip] >> >> >> >> >> >> * intro and goals ( based on >> >> >> http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 ) >> >> >> * social context of virtual worlds - why they're interesting >> >> >> * very high level description of virtual world characteristics - >> >> >> not >> >> >> what a virtual world "is" as much as features of a virtual world you >> >> >> may not have thought about. >> >> >> * how VWRAP virtual worlds differ from other virtual worlds - how >> >> >> OpenSim and SecondLife differ on a technology level from WoW >> >> >> * protocol objectives and goals - specific features of the protocol >> >> >> >> >> >> * this doc is it's own document because we think there's a need for >> >> >> a lot of background, and it's mostly non-technical. >> >> > >> >> > [snip ] >> >> > I would suggest to add some stuff >> >> > from http://tools.ietf.org/html/draft-levine-ogp-layering >> >> > The use cases given there would come a long way to clarify the >> >> > current >> >> > confusion over what we can call a virtual world and what the main >> >> > seat >> >> > of >> >> > policy is in these cases. >> >> > Vaughn >> >> _______________________________________________ >> >> ogpx mailing list >> >> ogpx@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ogpx >> > >> > >> > _______________________________________________ >> > ogpx mailing list >> > ogpx@ietf.org >> > https://www.ietf.org/mailman/listinfo/ogpx >> > >> > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 005ADA3A85257644_= Content-Type: text/html; charset="US-ASCII"
I think you can also expect some updates to that draft based on my group's experience with implmenting  an Agent Domain this past year. In particular, some feedback on extension patterns.

- David



Infinity Linden <infinity@lindenlab.com>
Sent by: ogpx-bounces@ietf.org

10/03/2009 12:27 PM

To
Vaughn Deluca <vaughn.deluca@gmail.com>
cc
Meadhbh Siobhan <meadhbh.siobhan@gmail.com>, ogpx@ietf.org
Subject
Re: [ogpx] refined idea for documents..





yup vaughn. that's the teleport draft we made after the 2008 interop
tests. if i remember correctly, we didn't modify the code on vaak to
follow this draft. and... we found a few things we wanted to change
from this draft over the last year.

but i think that about 99% of what's in the text on the wiki is going
to show up in the teleport internet draft. stuff we've said we want to
add includes discussion on policy and where policy enforcement points
might be, as well as being slightly more clear where region caps for
teleport come from and the relationship between teleport caps (that
are given to agent domains the region trusts) and long lived
information URLs (that may or may not be capabilities) with public
information about the region.

-cheers
-meadhbh


On Sat, Oct 3, 2009 at 4:55 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
> In an attempt to add more details in the deployment patterns I started to do
> some homework. I found this:
> http://wiki.secondlife.com/wiki/OGP_Teleport_Draft_3
> Is there a newer version of this document? Is it more or less safe to use
> this as an starting point of my thinking about OGP/VWRAP?
> -Vaughn
> On Mon, Sep 28, 2009 at 3:33 PM, Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
> wrote:
>>
>> okay. discuss away!
>>
>> On Mon, Sep 28, 2009 at 12:26 AM, Morgaine
>> <morgaine.dinova@googlemail.com> wrote:
>> > A good way of proceeding would be to discuss David's deployment patterns
>> > first, before cranking out a new intro document.  After all, there is a
>> > lot
>> > of good material there, hinting at many useful use cases.  Then any new
>> > document would have a chance of reflecting the viewpoints of the group
>> > so
>> > far, and building on the consensus.
>> >
>> > Ref:  http://tools.ietf.org/html/draft-levine-ogp-layering-00
>> >
>> >
>> > Morgaine.
>> >
>> >
>> >
>> >
>> >
>> >
>> > ======================================
>> >
>> > On Sun, Sep 27, 2009 at 4:11 PM, Infinity Linden
>> > <infinity@lindenlab.com>
>> > wrote:
>> >>
>> >> yup. we're actually in the process of adding the deployment pattern
>> >> stuff to the intro doc. great minds think alike!
>> >>
>> >> On Sun, Sep 27, 2009 at 7:16 AM, Vaughn Deluca
>> >> <vaughn.deluca@gmail.com>
>> >> wrote:
>> >> > On Thu, Sep 3, 2009 at 8:49 PM, Infinity
>> >> > Linden <infinity@lindenlab.com> wrote:
>> >> >>
>> >> >> hey peeps...
>> >> >>
>> >> >> i was thinking about it, and came up with a slightly different list
>> >> >> of
>> >> >> documents:
>> >> >>
>> >> >> * intro and goals (used to be called intro and requirements)
>> >> >> * abstract type system (used to be called LLSD)
>> >> >> * foundations
>> >> >> * the VWRAP trust/security model
>> >> >> * virtual world description format
>> >> >> * client application launch message
>> >> >> * agent presence establishment
>> >> >> * avatar format
>> >> >> * asset format and access
>> >> >> * chat/voice establishment
>> >> >> * user profile access
>> >> >> * time sensitive messages
>> >> >>
>> >> >> [snip]
>> >> >>
>> >> >> * intro and goals ( based on
>> >> >> http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 )
>> >> >>  * social context of virtual worlds - why they're interesting
>> >> >>  * very high level description of virtual world characteristics -
>> >> >> not
>> >> >> what a virtual world "is" as much as features of a virtual world you
>> >> >> may not have thought about.
>> >> >>  * how VWRAP virtual worlds differ from other virtual worlds - how
>> >> >> OpenSim and SecondLife differ on a technology level from WoW
>> >> >>  * protocol objectives and goals - specific features of the protocol
>> >> >>
>> >> >>  * this doc is it's own document because we think there's a need for
>> >> >> a lot of background, and it's mostly non-technical.
>> >> >
>> >> > [snip ]
>> >> > I would suggest to add some stuff
>> >> > from http://tools.ietf.org/html/draft-levine-ogp-layering
>> >> > The use cases given there would come a long way to clarify the
>> >> > current
>> >> > confusion over what we can call a virtual world and what the main
>> >> > seat
>> >> > of
>> >> > policy is in these cases.
>> >> > Vaughn
>> >> _______________________________________________
>> >> ogpx mailing list
>> >> ogpx@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/ogpx
>> >
>> >
>> > _______________________________________________
>> > ogpx mailing list
>> > ogpx@ietf.org
>> > https://www.ietf.org/mailman/listinfo/ogpx
>> >
>> >
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 005ADA3A85257644_=-- From infinity@lindenlab.com Sat Oct 3 09:33:02 2009 Return-Path: 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 65F493A690D for ; Sat, 3 Oct 2009 09:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SPOOF_NET2COM=1.586] 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 O5uTwjVo9z6E for ; Sat, 3 Oct 2009 09:33:00 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id C1BC73A67FB for ; Sat, 3 Oct 2009 09:33:00 -0700 (PDT) Received: by pxi6 with SMTP id 6so2195988pxi.32 for ; Sat, 03 Oct 2009 09:34:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.209.20 with SMTP id h20mr457536wfg.36.1254587668836; Sat, 03 Oct 2009 09:34:28 -0700 (PDT) In-Reply-To: <3a880e2c0910030927yec33851n9bf213f47e1a8300@mail.gmail.com> References: <3a880e2c0909031149kda16e64neb4184ca70f59745@mail.gmail.com> <9b8a8de40909270716s25dc3a13v1a11917c3d37ce3a@mail.gmail.com> <3a880e2c0909270811s7abc399crcad8c0eed3027a1@mail.gmail.com> <9b8a8de40910030455p47875547jdd63d85f7e12fc09@mail.gmail.com> <3a880e2c0910030927yec33851n9bf213f47e1a8300@mail.gmail.com> Date: Sat, 3 Oct 2009 09:34:28 -0700 Message-ID: <3a880e2c0910030934m4b1893b0r4174fec852150254@mail.gmail.com> From: Infinity Linden To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Meadhbh Siobhan , ogpx@ietf.org Subject: Re: [ogpx] refined idea for documents.. X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 16:33:02 -0000 ack. totally forgot. some of the refinements i was talking about above, made it into this draft: http://secondlifegrid.net.s3.amazonaws.com/docs/specs/OGP-Teleport_Draft_5.= html which also reminds me, i think the following page has references to the most up to date pre-IETF drafts: http://wiki.secondlife.com/wiki/Open_Grid_Protocol and we have some diagrams on this page: http://wiki.secondlife.com/wiki/OGP_Explained not all of the diagrams are up to date (especially authentication, which has changed A LOT) but it should give you some ideas about the flows. -cheers -meadhbh / infinity On Sat, Oct 3, 2009 at 9:27 AM, Infinity Linden wr= ote: > yup vaughn. that's the teleport draft we made after the 2008 interop > tests. if i remember correctly, we didn't modify the code on vaak to > follow this draft. and... we found a few things we wanted to change > from this draft over the last year. > > but i think that about 99% of what's in the text on the wiki is going > to show up in the teleport internet draft. stuff we've said we want to > add includes discussion on policy and where policy enforcement points > might be, as well as being slightly more clear where region caps for > teleport come from and the relationship between teleport caps (that > are given to agent domains the region trusts) and long lived > information URLs (that may or may not be capabilities) with public > information about the region. > > -cheers > -meadhbh > > > On Sat, Oct 3, 2009 at 4:55 AM, Vaughn Deluca w= rote: >> In an attempt to add more details in the deployment patterns I started t= o do >> some homework. I found this: >> http://wiki.secondlife.com/wiki/OGP_Teleport_Draft_3 >> Is there a newer version of this document? Is it more or less safe to us= e >> this as an starting point of my thinking about OGP/VWRAP? >> -Vaughn >> On Mon, Sep 28, 2009 at 3:33 PM, Meadhbh Siobhan >> wrote: >>> >>> okay. discuss away! >>> >>> On Mon, Sep 28, 2009 at 12:26 AM, Morgaine >>> wrote: >>> > A good way of proceeding would be to discuss David's deployment patte= rns >>> > first, before cranking out a new intro document.=A0 After all, there = is a >>> > lot >>> > of good material there, hinting at many useful use cases.=A0 Then any= new >>> > document would have a chance of reflecting the viewpoints of the grou= p >>> > so >>> > far, and building on the consensus. >>> > >>> > Ref:=A0 http://tools.ietf.org/html/draft-levine-ogp-layering-00 >>> > >>> > >>> > Morgaine. >>> > >>> > >>> > >>> > >>> > >>> > >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> > >>> > On Sun, Sep 27, 2009 at 4:11 PM, Infinity Linden >>> > >>> > wrote: >>> >> >>> >> yup. we're actually in the process of adding the deployment pattern >>> >> stuff to the intro doc. great minds think alike! >>> >> >>> >> On Sun, Sep 27, 2009 at 7:16 AM, Vaughn Deluca >>> >> >>> >> wrote: >>> >> > On Thu, Sep 3, 2009 at 8:49 PM, Infinity >>> >> > Linden=A0=A0wrote: >>> >> >> >>> >> >> hey peeps... >>> >> >> >>> >> >> i was thinking about it, and came up with a slightly different li= st >>> >> >> of >>> >> >> documents: >>> >> >> >>> >> >> * intro and goals (used to be called intro and requirements) >>> >> >> * abstract type system (used to be called LLSD) >>> >> >> * foundations >>> >> >> * the VWRAP trust/security model >>> >> >> * virtual world description format >>> >> >> * client application launch message >>> >> >> * agent presence establishment >>> >> >> * avatar format >>> >> >> * asset format and access >>> >> >> * chat/voice establishment >>> >> >> * user profile access >>> >> >> * time sensitive messages >>> >> >> >>> >> >> [snip] >>> >> >> >>> >> >> * intro and goals ( based on >>> >> >> http://tools.ietf.org/html/draft-hamrick-ogp-intro-00=A0) >>> >> >> =A0* social context of virtual worlds - why they're interesting >>> >> >> =A0* very high level description of virtual world characteristics= - >>> >> >> not >>> >> >> what a virtual world "is" as much as features of a virtual world = you >>> >> >> may not have thought about. >>> >> >> =A0* how VWRAP virtual worlds differ from other virtual worlds - = how >>> >> >> OpenSim and SecondLife differ on a technology level from WoW >>> >> >> =A0* protocol objectives and goals - specific features of the pro= tocol >>> >> >> >>> >> >> =A0* this doc is it's own document because we think there's a nee= d for >>> >> >> a lot of background, and it's mostly non-technical. >>> >> > >>> >> > [snip ] >>> >> > I would suggest to add some stuff >>> >> > from=A0http://tools.ietf.org/html/draft-levine-ogp-layering >>> >> > The use cases given there would come a long way to clarify the >>> >> > current >>> >> > confusion over what we can call a virtual world and what the main >>> >> > seat >>> >> > of >>> >> > policy is in these cases. >>> >> > Vaughn >>> >> _______________________________________________ >>> >> ogpx mailing list >>> >> ogpx@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/ogpx >>> > >>> > >>> > _______________________________________________ >>> > ogpx mailing list >>> > ogpx@ietf.org >>> > https://www.ietf.org/mailman/listinfo/ogpx >>> > >>> > >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > From vaughn.deluca@gmail.com Sat Oct 3 10:49:43 2009 Return-Path: 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 E8F633A687C for ; Sat, 3 Oct 2009 10:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPOOF_NET2COM=1.586] 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 bVe0qbz58O8K for ; Sat, 3 Oct 2009 10:49:42 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id E9BA93A683C for ; Sat, 3 Oct 2009 10:49:41 -0700 (PDT) Received: by fxm28 with SMTP id 28so1821037fxm.42 for ; Sat, 03 Oct 2009 10:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=63MHp7x734BSnWv4tAtMn1HVMHGfx91wn32A1iT1JEs=; b=KqGqjEGfzpfueGNErnqEg7iq8rdC+FJYTYxrQt2R+LSa7fltHss7oYGpQzT4pHAEUz LL38nbm+IL6eakDhl5czbOioxAH5u5D9Kz9LzV4to5aemOk903q5zZnZ1rIiGB72DrSu hOfK7xSNDJVsKKBP1GeYyE19OvGevhlOBljog= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xcMSQiJ49REag25VvP/iTx/6tlrXHCUfp0b0keOprRMj9U7mcWDKDtUC8yUDP52GPf ZK3fJLeMbqY2kXIJtQAt6PGW4MB18K+dFfbiba6qA4+Nv6p3skONtZLFJM6dTSFqKmvC lIv49fQrGY4GQll5Ibo6GcLZMRvXit/Gjfcd4= MIME-Version: 1.0 Received: by 10.204.25.19 with SMTP id x19mr2319040bkb.189.1254592268558; Sat, 03 Oct 2009 10:51:08 -0700 (PDT) In-Reply-To: <3a880e2c0910030934m4b1893b0r4174fec852150254@mail.gmail.com> References: <3a880e2c0909031149kda16e64neb4184ca70f59745@mail.gmail.com> <9b8a8de40909270716s25dc3a13v1a11917c3d37ce3a@mail.gmail.com> <3a880e2c0909270811s7abc399crcad8c0eed3027a1@mail.gmail.com> <9b8a8de40910030455p47875547jdd63d85f7e12fc09@mail.gmail.com> <3a880e2c0910030927yec33851n9bf213f47e1a8300@mail.gmail.com> <3a880e2c0910030934m4b1893b0r4174fec852150254@mail.gmail.com> Date: Sat, 3 Oct 2009 19:51:08 +0200 Message-ID: <9b8a8de40910031051j53dd2107qa032821bf55c1cdb@mail.gmail.com> From: Vaughn Deluca To: Infinity Linden Content-Type: multipart/alternative; boundary=000325559fce81637704750b86b6 Cc: Meadhbh Siobhan , ogpx@ietf.org Subject: Re: [ogpx] refined idea for documents.. X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 17:49:44 -0000 --000325559fce81637704750b86b6 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the pointers!*starts studying* On Sat, Oct 3, 2009 at 6:34 PM, Infinity Linden wrote: > ack. totally forgot. some of the refinements i was talking about > above, made it into this draft: > > > http://secondlifegrid.net.s3.amazonaws.com/docs/specs/OGP-Teleport_Draft_5.html > > which also reminds me, i think the following page has references to > the most up to date pre-IETF drafts: > > http://wiki.secondlife.com/wiki/Open_Grid_Protocol > > and we have some diagrams on this page: > > http://wiki.secondlife.com/wiki/OGP_Explained > > not all of the diagrams are up to date (especially authentication, > which has changed A LOT) but it should give you some ideas about the > flows. > > -cheers > -meadhbh / infinity > > > On Sat, Oct 3, 2009 at 9:27 AM, Infinity Linden > wrote: > > yup vaughn. that's the teleport draft we made after the 2008 interop > > tests. if i remember correctly, we didn't modify the code on vaak to > > follow this draft. and... we found a few things we wanted to change > > from this draft over the last year. > > > > but i think that about 99% of what's in the text on the wiki is going > > to show up in the teleport internet draft. stuff we've said we want to > > add includes discussion on policy and where policy enforcement points > > might be, as well as being slightly more clear where region caps for > > teleport come from and the relationship between teleport caps (that > > are given to agent domains the region trusts) and long lived > > information URLs (that may or may not be capabilities) with public > > information about the region. > > > > -cheers > > -meadhbh > > > > > > On Sat, Oct 3, 2009 at 4:55 AM, Vaughn Deluca > wrote: > >> In an attempt to add more details in the deployment patterns I started > to do > >> some homework. I found this: > >> http://wiki.secondlife.com/wiki/OGP_Teleport_Draft_3 > >> Is there a newer version of this document? Is it more or less safe to > use > >> this as an starting point of my thinking about OGP/VWRAP? > >> -Vaughn > >> On Mon, Sep 28, 2009 at 3:33 PM, Meadhbh Siobhan < > meadhbh.siobhan@gmail.com> > >> wrote: > >>> > >>> okay. discuss away! > >>> > >>> On Mon, Sep 28, 2009 at 12:26 AM, Morgaine > >>> wrote: > >>> > A good way of proceeding would be to discuss David's deployment > patterns > >>> > first, before cranking out a new intro document. After all, there is > a > >>> > lot > >>> > of good material there, hinting at many useful use cases. Then any > new > >>> > document would have a chance of reflecting the viewpoints of the > group > >>> > so > >>> > far, and building on the consensus. > >>> > > >>> > Ref: http://tools.ietf.org/html/draft-levine-ogp-layering-00 > >>> > > >>> > > >>> > Morgaine. > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > ====================================== > >>> > > >>> > On Sun, Sep 27, 2009 at 4:11 PM, Infinity Linden > >>> > > >>> > wrote: > >>> >> > >>> >> yup. we're actually in the process of adding the deployment pattern > >>> >> stuff to the intro doc. great minds think alike! > >>> >> > >>> >> On Sun, Sep 27, 2009 at 7:16 AM, Vaughn Deluca > >>> >> > >>> >> wrote: > >>> >> > On Thu, Sep 3, 2009 at 8:49 PM, Infinity > >>> >> > Linden wrote: > >>> >> >> > >>> >> >> hey peeps... > >>> >> >> > >>> >> >> i was thinking about it, and came up with a slightly different > list > >>> >> >> of > >>> >> >> documents: > >>> >> >> > >>> >> >> * intro and goals (used to be called intro and requirements) > >>> >> >> * abstract type system (used to be called LLSD) > >>> >> >> * foundations > >>> >> >> * the VWRAP trust/security model > >>> >> >> * virtual world description format > >>> >> >> * client application launch message > >>> >> >> * agent presence establishment > >>> >> >> * avatar format > >>> >> >> * asset format and access > >>> >> >> * chat/voice establishment > >>> >> >> * user profile access > >>> >> >> * time sensitive messages > >>> >> >> > >>> >> >> [snip] > >>> >> >> > >>> >> >> * intro and goals ( based on > >>> >> >> http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 ) > >>> >> >> * social context of virtual worlds - why they're interesting > >>> >> >> * very high level description of virtual world characteristics - > >>> >> >> not > >>> >> >> what a virtual world "is" as much as features of a virtual world > you > >>> >> >> may not have thought about. > >>> >> >> * how VWRAP virtual worlds differ from other virtual worlds - > how > >>> >> >> OpenSim and SecondLife differ on a technology level from WoW > >>> >> >> * protocol objectives and goals - specific features of the > protocol > >>> >> >> > >>> >> >> * this doc is it's own document because we think there's a need > for > >>> >> >> a lot of background, and it's mostly non-technical. > >>> >> > > >>> >> > [snip ] > >>> >> > I would suggest to add some stuff > >>> >> > from http://tools.ietf.org/html/draft-levine-ogp-layering > >>> >> > The use cases given there would come a long way to clarify the > >>> >> > current > >>> >> > confusion over what we can call a virtual world and what the main > >>> >> > seat > >>> >> > of > >>> >> > policy is in these cases. > >>> >> > Vaughn > >>> >> _______________________________________________ > >>> >> ogpx mailing list > >>> >> ogpx@ietf.org > >>> >> https://www.ietf.org/mailman/listinfo/ogpx > >>> > > >>> > > >>> > _______________________________________________ > >>> > ogpx mailing list > >>> > ogpx@ietf.org > >>> > https://www.ietf.org/mailman/listinfo/ogpx > >>> > > >>> > > >> > >> > >> _______________________________________________ > >> ogpx mailing list > >> ogpx@ietf.org > >> https://www.ietf.org/mailman/listinfo/ogpx > >> > >> > > > --000325559fce81637704750b86b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the pointers!
*starts studying*

On Sat, Oct 3, 2009 at 6:34 PM, Infinity Linden <= ;infinity@lindenlab.com> wrote:
ack. totally forgot. some of the refinement= s i was talking about
above, made it into this draft:

http://secondlifegrid.net.s3.amazonaws.c= om/docs/specs/OGP-Teleport_Draft_5.html

which also reminds me, i think the following page has references to
the most up to date pre-IETF drafts:

http://wiki.secondlife.com/wiki/Open_Grid_Protocol

and we have some diagrams on this page:

http://wiki.secondlife.com/wiki/OGP_Explained

not all of the diagrams are up to date (especially authentication,
which has changed A LOT) but it should give you some ideas about the
flows.

-cheers
-meadhbh / infinity


On Sat, Oct 3, 2009 at 9:27 AM, Infinity Linden <infinity@lindenlab.com> wrote:
> yup vaughn. that's the teleport draft we made after the 2008 inter= op
> tests. if i remember correctly, we didn't modify the code on vaak = to
> follow this draft. and... we found a few things we wanted to change > from this draft over the last year.
>
> but i think that about 99% of what's in the text on the wiki is go= ing
> to show up in the teleport internet draft. stuff we've said we wan= t to
> add includes discussion on policy and where policy enforcement points<= br> > might be, as well as being slightly more clear where region caps for > teleport come from and the relationship between teleport caps (that > are given to agent domains the region trusts) and long lived
> information URLs (that may or may not be capabilities) with public
> information about the region.
>
> -cheers
> -meadhbh
>
>
> On Sat, Oct 3, 2009 at 4:55 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
>> In an attempt to add more details in the deployment patterns I sta= rted to do
>> some homework. I found this:
>> http://wiki.secondlife.com/wiki/OGP_Teleport_Draft_3 >> Is there a newer version of this document? Is it more or less safe= to use
>> this as an starting point of my thinking about OGP/VWRAP?
>> -Vaughn
>> On Mon, Sep 28, 2009 at 3:33 PM, Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
>> wrote:
>>>
>>> okay. discuss away!
>>>
>>> On Mon, Sep 28, 2009 at 12:26 AM, Morgaine
>>> <morgaine= .dinova@googlemail.com> wrote:
>>> > A good way of proceeding would be to discuss David's = deployment patterns
>>> > first, before cranking out a new intro document.=A0 After= all, there is a
>>> > lot
>>> > of good material there, hinting at many useful use cases.= =A0 Then any new
>>> > document would have a chance of reflecting the viewpoints= of the group
>>> > so
>>> > far, and building on the consensus.
>>> >
>>> > Ref:=A0 http://tools.ietf.org/html/draft-levin= e-ogp-layering-00
>>> >
>>> >
>>> > Morgaine.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> >
>>> > On Sun, Sep 27, 2009 at 4:11 PM, Infinity Linden
>>> > <infinity@li= ndenlab.com>
>>> > wrote:
>>> >>
>>> >> yup. we're actually in the process of adding the = deployment pattern
>>> >> stuff to the intro doc. great minds think alike!
>>> >>
>>> >> On Sun, Sep 27, 2009 at 7:16 AM, Vaughn Deluca
>>> >> <vaughn= .deluca@gmail.com>
>>> >> wrote:
>>> >> > On Thu, Sep 3, 2009 at 8:49 PM, Infinity
>>> >> > Linden=A0<infinity@lindenlab.com>=A0wrote:
>>> >> >>
>>> >> >> hey peeps...
>>> >> >>
>>> >> >> i was thinking about it, and came up with a = slightly different list
>>> >> >> of
>>> >> >> documents:
>>> >> >>
>>> >> >> * intro and goals (used to be called intro a= nd requirements)
>>> >> >> * abstract type system (used to be called LL= SD)
>>> >> >> * foundations
>>> >> >> * the VWRAP trust/security model
>>> >> >> * virtual world description format
>>> >> >> * client application launch message
>>> >> >> * agent presence establishment
>>> >> >> * avatar format
>>> >> >> * asset format and access
>>> >> >> * chat/voice establishment
>>> >> >> * user profile access
>>> >> >> * time sensitive messages
>>> >> >>
>>> >> >> [snip]
>>> >> >>
>>> >> >> * intro and goals ( based on
>>> >> >> http://tools.ietf.org/html/draft-ha= mrick-ogp-intro-00=A0)
>>> >> >> =A0* social context of virtual worlds - why = they're interesting
>>> >> >> =A0* very high level description of virtual = world characteristics -
>>> >> >> not
>>> >> >> what a virtual world "is" as much = as features of a virtual world you
>>> >> >> may not have thought about.
>>> >> >> =A0* how VWRAP virtual worlds differ from ot= her virtual worlds - how
>>> >> >> OpenSim and SecondLife differ on a technolog= y level from WoW
>>> >> >> =A0* protocol objectives and goals - specifi= c features of the protocol
>>> >> >>
>>> >> >> =A0* this doc is it's own document becau= se we think there's a need for
>>> >> >> a lot of background, and it's mostly non= -technical.
>>> >> >
>>> >> > [snip ]
>>> >> > I would suggest to add some stuff
>>> >> > from=A0http://tools.ietf.org/html/draft-= levine-ogp-layering
>>> >> > The use cases given there would come a long way = to clarify the
>>> >> > current
>>> >> > confusion over what we can call a virtual world = and what the main
>>> >> > seat
>>> >> > of
>>> >> > policy is in these cases.
>>> >> > Vaughn
>>> >> _______________________________________________
>>> >> ogpx mailing list
>>> >> ogpx@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/ogpx
>>> >
>>> >
>>> > _______________________________________________
>>> > ogpx mailing list
>>> > ogpx@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/ogpx
>>> >
>>> >
>>
>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>>
>

--000325559fce81637704750b86b6-- From carlo@alinoe.com Sat Oct 3 12:19:27 2009 Return-Path: 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 D84223A67A8 for ; Sat, 3 Oct 2009 12:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 nZGtnenp+LiV for ; Sat, 3 Oct 2009 12:19:26 -0700 (PDT) Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id 423B73A67E4 for ; Sat, 3 Oct 2009 12:19:25 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091003192053.NVJF422.viefep16-int.chello.at@edge04.upc.biz>; Sat, 3 Oct 2009 21:20:53 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id oKLr1c02L0FlQed04KLsmz; Sat, 03 Oct 2009 21:20:53 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MuAB5-0002HT-G7; Sat, 03 Oct 2009 21:21:59 +0200 Date: Sat, 3 Oct 2009 21:21:59 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20091003192159.GA7474@alinoe.com> References: <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 19:19:28 -0000 Can't type much with my RSI, but I'd like to add that instead I'd prefer this for D, (not G): 1. the agent domain and the region domain hash out an agreement beforehand where the region domain operator tells the agent domain operator the equivalent of... "whoa dude, you won't get me in trouble with the state if you let 19 year olds into my adults only sim, PLEASE DON'T block them from entering sims i mark as adult." this effectively turns scenario D into scenario B for the AD2 / RD1 pairing. Reason, it's the region (destination) that really determines the law. And as extension to this, it should be the region that determines all rules that a visiting user must follow (independent of AD they use). On Fri, Oct 02, 2009 at 09:32:22AM -0700, Infinity Linden wrote: > i am vaguely confused by the path we're taking. a lot of what we're > fretting over was discussed over the summer. > > i am also disappointed that morgaine believes that simply making a > fiat statement like "we are arriving at DDP" makes it true. it is not > true. BOTH the agent domain and the region domain MUST have an > opportunity to express their policy. > > the problem outlined by carlo above is interesting, but tractable. > > the agent domain is the entity with a direct relationship with the > user. we should not require the region domain to have information > about the user (such as the user's age.) and here's why... > > in VWRAP, as discussed before, it is the agent domain that acts as a > trust broker. the user trusts the agent domain and the agent domain > trusts the provider of other services (such as the agent presence > service running on a host in the region domain.) we do not require the > user to have a direct relationship with the region domain. instead, we > define trust transitively. > > if the agent domain must ensure that underage users do not visit > regions with adult content, then they should disallow underage user's > avatars from visiting those regions. if this is an organizational > policy that must be adhered to, then the agent domain should have > information to make that decision: the user's age and whether a > specific region (or entire region domain) allows adult content. > > if the region domain operator believes that the agent domain operator > may believe that an acceptable age to view adult content is lower than > they are comfortable with, they should communicate this concern at the > time that they are negotiating access. please note that in this > scenario, the evaluation of organizational policies is something that > is performed by humans, not automated systems. > > the policy enforcement tool the AD can use in this scenario is to > decide to not place a user's avatar in a particular region. the > information the AD uses to evaluate whether they want to allow or deny > a teleport request is largely not a concern of the protocol. though.. > if the decision depends on the state of a region in the region domain, > then there has to be a way to communicate this information from the > region domain to the agent domain. and that _is_ definitely a protocol > concern. > > the situation with the region domain is largely similar. the tool the > RD has to enforce policy in this scenario is to disallow an agent > domain from placing an avatar in one of it's regions. > > but i really like this example, so i created a diagram from this > example at https://wiki.secondlife.com/wiki/File:VWRAP_adult_content_evaluation_example.jpg > . > > it shows two agent domains and two region domains. one of the agent > domains and one of the region domains define adult content as being > viewable by those 18 and older, the others think adult content is > viewable by those 21 and older. each has two regions; one of which has > adult content, the other does not. lets assume that the user is 19. > when the agent domain attempts to place an avatar in each of the > regions, you get 8 scenarios. > > A - no adult content in the region, AD allows transfer, RD allows transfer > B - adult content, but both the AD and RD agree that if you're 19, > you're okay to view adult content. AD allows transfer, RD allows > transfer. > C - no adult content in the region, AD allows transfer, RD allows transfer > D - adult content, but AD2 believes the user isn't old enough. AD does > not allow transfer. > E - no adult content in the region, AD allows transfer, RD allows transfer > F - no adult content in the region, AD allows transfer, RD allows transfer > G - adult content. AD1 believes the user is old enough, begins > transfer. RD believes the user is not old enough, disallows transfer. > H - adult content, but both AD2 and RD2 believe the user is old > enough. AD allows transfer, RD allows transfer. > > i think the most vexxing scenario is scenario G. it forces the RD to > make a policy decision based on information about the user maintained > by the agent domain. there are a couple of ways to handle this. > > 1. the agent domain and the region domain hash out an agreement > beforehand where the region domain operator tells the agent domain > operator the equivalent of... "whoa dude, you'll get me in trouble > with the state if you let 19 year olds into my adults only sim, PLEASE > block them from entering sims i mark as adult." this effectively turns > scenario G into scenario D for the AD2 / RD2 pairing. > > 2. the agent domain offers information in the teleport request about > the user's age to the RD, allowing the RD to disallow the transfer of > agent presence into adult regions. > > 3. the agent domain offers an interface the RD that lets the RD query > information about the user (including their age.) > > all of these have some drawbacks. my employer is probably most > interested in solution 1. linden views the relationship of agent > domain to region domain as a long-term trust relationship with a fair > amount of effort involved in setting it up. still, there are people > that want to have more of a tourist model where the user enters the > URL of a region into the client app and off you go without a > previously established agreements on policy enforcement. > > for the tourist model, you could do either 2 or 3. 2 has the advantage > that the RD doesn't need to make a request back to the AD before > deciding whether to complete the teleport. it has the disadvantage > that it requires the AD to give information about the user's age to an > RD who may or may not be trustworthy (cause... remember... we're > talking about the tourist model here.) > > i think what i'm getting at here is that carlo's example is > interesting, but it does yield to analysis. i think it also exposes > the difference between linden's vision of their service and what > morgaine (and presumably others) want people to build. but we can get > one protocol that works for both models, we just have to be careful, > and the end result will likely be more complicated than we would > prefer. but. welcome to the world of standards. > > -cheers > -meadhbh > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx -- Carlo Wood From morgaine.dinova@googlemail.com Sat Oct 3 14:50:54 2009 Return-Path: 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 379A93A63EB for ; Sat, 3 Oct 2009 14:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 n1DtaSlL0pzH for ; Sat, 3 Oct 2009 14:50:52 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 6B1AC3A6359 for ; Sat, 3 Oct 2009 14:50:51 -0700 (PDT) Received: by ewy28 with SMTP id 28so2783501ewy.42 for ; Sat, 03 Oct 2009 14:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=IUHS5wXfpHl5DI/pjR1O5saMKryY1qGhA8FlV/6glbQ=; b=fTE/Ubrk1MUWwr0BFj0Aa9CPcuOfZSOcveQPcZ/cWXeSq7KgoZ/bLaopr7JHl2UO4h qb1CdEAdtXMXmoSIRQ6moiiU9sJCVg7UBvgOXdj5QQFx5prpPuWzcSIqwq3YnNmAWE5X 8xTY5coYErhD89P+2OQNBAQ4KNpvCeIkv54T0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PSisLnBZUum7aTCPYXmg3sdsc+R4GTjofLeg0PGO8x1K9iugni/qdZ05N+0rflS0YG 5flS+mU5+xL2IlDRr4M9ETLi5xGnmPOIbplnCEqY70POkI+vg3UO4yEs9TqHgrK3QrwZ TdaJ8C+NcgRS0GqZi4FB9qktF4j8rvNBTnBUM= MIME-Version: 1.0 Received: by 10.210.7.17 with SMTP id 17mr1423112ebg.17.1254606738926; Sat, 03 Oct 2009 14:52:18 -0700 (PDT) In-Reply-To: <20091003192159.GA7474@alinoe.com> References: <20090914084420.GA25580@alinoe.com> <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> Date: Sat, 3 Oct 2009 22:52:18 +0100 Message-ID: From: Morgaine To: Carlo Wood Content-Type: multipart/alternative; boundary=000e0ce0450a01aeb404750ee555 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 21:50:54 -0000 --000e0ce0450a01aeb404750ee555 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 3, 2009 at 8:21 PM, Carlo Wood wrote: > > 1. the agent domain and the region domain hash out an agreement > beforehand where the region domain operator tells the agent domain > operator the equivalent of... "whoa dude, you won't get me in trouble > with the state if you let 19 year olds into my adults only sim, PLEASE > DON'T block them from entering sims i mark as adult." this effectively > turns > scenario D into scenario B for the AD2 / RD1 pairing. > > *Reason, it's the region (destination) that really determines the law.* > And as extension to this, it should be the region that determines all > rules that a visiting user must follow (independent of AD they use). > > Yes indeed. And that's pure *DDP*. W2's regions or RDs may be run by a provider located in a different country to W1's regions, so no way can W1 determine policy in RD2. W1's policies can at most dictate whether A1 is allowed to TP to a W2 region or RD, and which items can be brought back to W1. That's all. It's important to highlight (as you did) that issues such as age verification have no place in a worldwide IETF protocol standard, so while you provide a good example of policy variations among worlds, any such agreements are outside of the context of our protocol. Morgaine. ======================================= On Sat, Oct 3, 2009 at 8:21 PM, Carlo Wood wrote: > Can't type much with my RSI, but I'd like to add that instead > I'd prefer this for D, (not G): > > 1. the agent domain and the region domain hash out an agreement > beforehand where the region domain operator tells the agent domain > operator the equivalent of... "whoa dude, you won't get me in trouble > with the state if you let 19 year olds into my adults only sim, PLEASE > DON'T block them from entering sims i mark as adult." this effectively > turns > scenario D into scenario B for the AD2 / RD1 pairing. > > Reason, it's the region (destination) that really determines the law. > And as extension to this, it should be the region that determines all > rules that a visiting user must follow (independent of AD they use). > > On Fri, Oct 02, 2009 at 09:32:22AM -0700, Infinity Linden wrote: > > i am vaguely confused by the path we're taking. a lot of what we're > > fretting over was discussed over the summer. > > > > i am also disappointed that morgaine believes that simply making a > > fiat statement like "we are arriving at DDP" makes it true. it is not > > true. BOTH the agent domain and the region domain MUST have an > > opportunity to express their policy. > > > > the problem outlined by carlo above is interesting, but tractable. > > > > the agent domain is the entity with a direct relationship with the > > user. we should not require the region domain to have information > > about the user (such as the user's age.) and here's why... > > > > in VWRAP, as discussed before, it is the agent domain that acts as a > > trust broker. the user trusts the agent domain and the agent domain > > trusts the provider of other services (such as the agent presence > > service running on a host in the region domain.) we do not require the > > user to have a direct relationship with the region domain. instead, we > > define trust transitively. > > > > if the agent domain must ensure that underage users do not visit > > regions with adult content, then they should disallow underage user's > > avatars from visiting those regions. if this is an organizational > > policy that must be adhered to, then the agent domain should have > > information to make that decision: the user's age and whether a > > specific region (or entire region domain) allows adult content. > > > > if the region domain operator believes that the agent domain operator > > may believe that an acceptable age to view adult content is lower than > > they are comfortable with, they should communicate this concern at the > > time that they are negotiating access. please note that in this > > scenario, the evaluation of organizational policies is something that > > is performed by humans, not automated systems. > > > > the policy enforcement tool the AD can use in this scenario is to > > decide to not place a user's avatar in a particular region. the > > information the AD uses to evaluate whether they want to allow or deny > > a teleport request is largely not a concern of the protocol. though.. > > if the decision depends on the state of a region in the region domain, > > then there has to be a way to communicate this information from the > > region domain to the agent domain. and that _is_ definitely a protocol > > concern. > > > > the situation with the region domain is largely similar. the tool the > > RD has to enforce policy in this scenario is to disallow an agent > > domain from placing an avatar in one of it's regions. > > > > but i really like this example, so i created a diagram from this > > example at > https://wiki.secondlife.com/wiki/File:VWRAP_adult_content_evaluation_example.jpg > > . > > > > it shows two agent domains and two region domains. one of the agent > > domains and one of the region domains define adult content as being > > viewable by those 18 and older, the others think adult content is > > viewable by those 21 and older. each has two regions; one of which has > > adult content, the other does not. lets assume that the user is 19. > > when the agent domain attempts to place an avatar in each of the > > regions, you get 8 scenarios. > > > > A - no adult content in the region, AD allows transfer, RD allows > transfer > > B - adult content, but both the AD and RD agree that if you're 19, > > you're okay to view adult content. AD allows transfer, RD allows > > transfer. > > C - no adult content in the region, AD allows transfer, RD allows > transfer > > D - adult content, but AD2 believes the user isn't old enough. AD does > > not allow transfer. > > E - no adult content in the region, AD allows transfer, RD allows > transfer > > F - no adult content in the region, AD allows transfer, RD allows > transfer > > G - adult content. AD1 believes the user is old enough, begins > > transfer. RD believes the user is not old enough, disallows transfer. > > H - adult content, but both AD2 and RD2 believe the user is old > > enough. AD allows transfer, RD allows transfer. > > > > i think the most vexxing scenario is scenario G. it forces the RD to > > make a policy decision based on information about the user maintained > > by the agent domain. there are a couple of ways to handle this. > > > > 1. the agent domain and the region domain hash out an agreement > > beforehand where the region domain operator tells the agent domain > > operator the equivalent of... "whoa dude, you'll get me in trouble > > with the state if you let 19 year olds into my adults only sim, PLEASE > > block them from entering sims i mark as adult." this effectively turns > > scenario G into scenario D for the AD2 / RD2 pairing. > > > > 2. the agent domain offers information in the teleport request about > > the user's age to the RD, allowing the RD to disallow the transfer of > > agent presence into adult regions. > > > > 3. the agent domain offers an interface the RD that lets the RD query > > information about the user (including their age.) > > > > all of these have some drawbacks. my employer is probably most > > interested in solution 1. linden views the relationship of agent > > domain to region domain as a long-term trust relationship with a fair > > amount of effort involved in setting it up. still, there are people > > that want to have more of a tourist model where the user enters the > > URL of a region into the client app and off you go without a > > previously established agreements on policy enforcement. > > > > for the tourist model, you could do either 2 or 3. 2 has the advantage > > that the RD doesn't need to make a request back to the AD before > > deciding whether to complete the teleport. it has the disadvantage > > that it requires the AD to give information about the user's age to an > > RD who may or may not be trustworthy (cause... remember... we're > > talking about the tourist model here.) > > > > i think what i'm getting at here is that carlo's example is > > interesting, but it does yield to analysis. i think it also exposes > > the difference between linden's vision of their service and what > > morgaine (and presumably others) want people to build. but we can get > > one protocol that works for both models, we just have to be careful, > > and the end result will likely be more complicated than we would > > prefer. but. welcome to the world of standards. > > > > -cheers > > -meadhbh > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > -- > Carlo Wood > --000e0ce0450a01aeb404750ee555 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 3, 2009 at 8:21 PM, Carlo Wood <carlo@alinoe.com> wrote:

1. the agent domain and the region domain hash out an agreement
beforehand where the region domain operator tells the agent domain
operator the equivalent of... "whoa dude, you won't get me i= n trouble
with the state if you let 19 year olds into my adults onl= y sim, PLEASE
DON'T block them from entering sims i mark as adult." this e= ffectively turns
scenario D into scenario B for the AD2 / RD1 pairing.

Reason, it's the region (destination) that really determines the law= .
And as extension to this, it should be the region that determines all
rules that a visiting user must follow (independent of AD they use).


Yes indeed.=A0 And = that's pure DDP.=A0 W2's regions or RDs may be run by a prov= ider located in a different country to W1's regions, so no way can W1 d= etermine policy in RD2.

W1's policies can at most dictate whether A1 is allowed to TP to a = W2 region or RD, and which items can be brought back to W1.=A0 That's a= ll.

It's important to highlight (as you did) that issues such as= age verification have no place in a worldwide IETF protocol standard, so w= hile you provide a good example of policy variations among worlds, any such= agreements are outside of the context of our protocol.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

On Sat, Oct 3, 2009 at 8:21 = PM, Carlo Wood <ca= rlo@alinoe.com> wrote:
Can't type mu= ch with my RSI, but I'd like to add that instead
I'd prefer this for D, (not G):

1. the agent domain and the region domain hash out an agreement
beforehand where the region domain operator tells the agent domain
operator the equivalent of... "whoa dude, you won't get me i= n trouble
with the state if you let 19 year olds into my adults onl= y sim, PLEASE
DON'T block them from entering sims i mark as adult." this e= ffectively turns
scenario D into scenario B for the AD2 / RD1 pairing.

Reason, it's the region (destination) that really determines the law. And as extension to this, it should be the region that determines all
rules that a visiting user must follow (independent of AD they use).

On Fri, Oct 02, 2009 at 09:32:22AM -0700, Infinity Linden wrote:
> i am vaguely confused by the path we're taking. a lot of what we&#= 39;re
> fretting over was discussed over the summer.
>
> i am also disappointed that morgaine believes that simply making a
> fiat statement like "we are arriving at DDP" makes it true. = it is not
> true. BOTH the agent domain and the region domain MUST have an
> opportunity to express their policy.
>
> the problem outlined by carlo above is interesting, but tractable.
>
> the agent domain is the entity with a direct relationship with the
> user. we should not require the region domain to have information
> about the user (such as the user's age.) and here's why...
>
> in VWRAP, as discussed before, it is the agent domain that acts as a > trust broker. the user trusts the agent domain and the agent domain > trusts the provider of other services (such as the agent presence
> service running on a host in the region domain.) we do not require the=
> user to have a direct relationship with the region domain. instead, we=
> define trust transitively.
>
> if the agent domain must ensure that underage users do not visit
> regions with adult content, then they should disallow underage user= 9;s
> avatars from visiting those regions. if this is an organizational
> policy that must be adhered to, then the agent domain should have
> information to make that decision: the user's age and whether a > specific region (or entire region domain) allows adult content.
>
> if the region domain operator believes that the agent domain operator<= br> > may believe that an acceptable age to view adult content is lower than=
> they are comfortable with, they should communicate this concern at the=
> time that they are negotiating access. please note that in this
> scenario, the evaluation of organizational policies is something that<= br> > is performed by humans, not automated systems.
>
> the policy enforcement tool the AD can use in this scenario is to
> decide to not place a user's avatar in a particular region. the > information the AD uses to evaluate whether they want to allow or deny=
> a teleport request is largely not a concern of the protocol. though..<= br> > if the decision depends on the state of a region in the region domain,=
> then there has to be a way to communicate this information from the > region domain to the agent domain. and that _is_ definitely a protocol=
> concern.
>
> the situation with the region domain is largely similar. the tool the<= br> > RD has to enforce policy in this scenario is to disallow an agent
> domain from placing an avatar in one of it's regions.
>
> but i really like this example, so i created a diagram from this
> example at https://wiki.secondlife= .com/wiki/File:VWRAP_adult_content_evaluation_example.jpg
> .
>
> it shows two agent domains and two region domains. one of the agent > domains and one of the region domains define adult content as being > viewable by those 18 and older, the others think adult content is
> viewable by those 21 and older. each has two regions; one of which has=
> adult content, the other does not. lets assume that the user is 19. > when the agent domain attempts to place an avatar in each of the
> regions, you get 8 scenarios.
>
> A - no adult content in the region, AD allows transfer, RD allows tran= sfer
> B - adult content, but both the AD and RD agree that if you're 19,=
> you're okay to view adult content. AD allows transfer, RD allows > transfer.
> C - no adult content in the region, AD allows transfer, RD allows tran= sfer
> D - adult content, but AD2 believes the user isn't old enough. AD = does
> not allow transfer.
> E - no adult content in the region, AD allows transfer, RD allows tran= sfer
> F - no adult content in the region, AD allows transfer, RD allows tran= sfer
> G - adult content. AD1 believes the user is old enough, begins
> transfer. RD believes the user is not old enough, disallows transfer.<= br> > H - adult content, but both AD2 and RD2 believe the user is old
> enough. AD allows transfer, RD allows transfer.
>
> i think the most vexxing scenario is scenario G. it forces the RD to > make a policy decision based on information about the user maintained<= br> > by the agent domain. there are a couple of ways to handle this.
>
> 1. the agent domain and the region domain hash out an agreement
> beforehand where the region domain operator tells the agent domain
> operator the equivalent of... "whoa dude, you'll get me in tr= ouble
> with the state if you let 19 year olds into my adults only sim, PLEASE=
> block them from entering sims i mark as adult." this effectively = turns
> scenario G into scenario D for the AD2 / RD2 pairing.
>
> 2. the agent domain offers information in the teleport request about > the user's age to the RD, allowing the RD to disallow the transfer= of
> agent presence into adult regions.
>
> 3. the agent domain offers an interface the RD that lets the RD query<= br> > information about the user (including their age.)
>
> all of these have some drawbacks. my employer is probably most
> interested in solution 1. linden views the relationship of agent
> domain to region domain as a long-term trust relationship with a fair<= br> > amount of effort involved in setting it up. still, there are people > that want to have more of a tourist model where the user enters the > URL of a region into the client app and off you go without a
> previously established agreements on policy enforcement.
>
> for the tourist model, you could do either 2 or 3. 2 has the advantage=
> that the RD doesn't need to make a request back to the AD before > deciding whether to complete the teleport. it has the disadvantage
> that it requires the AD to give information about the user's age t= o an
> RD who may or may not be trustworthy (cause... remember... we're > talking about the tourist model here.)
>
> i think what i'm getting at here is that carlo's example is > interesting, but it does yield to analysis. i think it also exposes > the difference between linden's vision of their service and what > morgaine (and presumably others) want people to build. but we can get<= br> > one protocol that works for both models, we just have to be careful, > and the end result will likely be more complicated than we would
> prefer. but. welcome to the world of standards.
>
> -cheers
> -meadhbh
> ________________________________________= _______
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx

--
Carlo Wood <carlo@alinoe.com>

--000e0ce0450a01aeb404750ee555-- From carlo@alinoe.com Sat Oct 3 15:18:45 2009 Return-Path: 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 CDBA13A695C for ; Sat, 3 Oct 2009 15:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 1+1e1Ml8Ib0a for ; Sat, 3 Oct 2009 15:18:44 -0700 (PDT) Received: from viefep14-int.chello.at (viefep14-int.chello.at [62.179.121.34]) by core3.amsl.com (Postfix) with ESMTP id 15AF03A63EB for ; Sat, 3 Oct 2009 15:18:43 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep14-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091003222011.LFHU20477.viefep14-int.chello.at@edge01.upc.biz>; Sun, 4 Oct 2009 00:20:11 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id oNL91c0590FlQed01NLAd3; Sun, 04 Oct 2009 00:20:11 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MuCyc-0004cd-EH; Sun, 04 Oct 2009 00:21:18 +0200 Date: Sun, 4 Oct 2009 00:21:18 +0200 From: Carlo Wood To: Morgaine Message-ID: <20091003222118.GA16290@alinoe.com> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 22:18:45 -0000 On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote: > It's important to highlight (as you did) that issues such as age verification > have no place in a worldwide IETF protocol standard, so while you provide a > good example of policy variations among worlds, any such agreements are outside > of the context of our protocol. Not entirely... age verification is necessary in many countries with what's going on in an SL-like world. A RD cannot do the age-verification; that is a job for an AD. However, I think it's the RD that needs to make the decision whether or not a user is allowed in (based on its age), which in turn means that the AD has to tell the RD if it knows the age, and if so, what it is; hence, it should be part of the protocol. -- Carlo Wood From morgaine.dinova@googlemail.com Sat Oct 3 16:32:14 2009 Return-Path: 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 192E83A689F for ; Sat, 3 Oct 2009 16:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.795 X-Spam-Level: X-Spam-Status: No, score=-0.795 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 gewcgqPln6qF for ; Sat, 3 Oct 2009 16:32:13 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 949E63A6359 for ; Sat, 3 Oct 2009 16:32:12 -0700 (PDT) Received: by ewy28 with SMTP id 28so2841833ewy.42 for ; Sat, 03 Oct 2009 16:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hEXGEdX9Dpo1szXyoCGpqcqsTa+yc4DOtS3UwBtE3qQ=; b=xnnlZ+O8DXpp1t89pCAxTCef7190aEBYuITyapFrQlpxofa539/SgaU2sMbc0VWC2k qIebyhWUi5eqgvVEjmVNx/tKrf2fYTwMHOGDH8oE+UHsNrP0Qx6RjExoZ1BXKsI0pKw+ QWCInF9mGiof4iRDMofGI8CBeFhqq47O1Oy1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HMSt7iMv5CpnEMPTq+a31bfV7WbIQVoRsKtWhEwvOvRwj7+nhR/G1adOn3fjQ2GPQO Ak0ZKXrPHMelB0XssuXeE+1/yBA2Oewqq/AOedGm702sdMBv7JPlPmZblvMGQBiQLreD 1QICEq7a9bkDLKCJXXBAS5M16QG19uKKmwJu0= MIME-Version: 1.0 Received: by 10.211.147.26 with SMTP id z26mr1460004ebn.73.1254612820720; Sat, 03 Oct 2009 16:33:40 -0700 (PDT) In-Reply-To: <20091003222118.GA16290@alinoe.com> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> Date: Sun, 4 Oct 2009 00:33:40 +0100 Message-ID: From: Morgaine To: Carlo Wood Content-Type: multipart/alternative; boundary=001636c5bd9d827ca90475104f09 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2009 23:32:14 -0000 --001636c5bd9d827ca90475104f09 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood wrote: > On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote: > > It's important to highlight (as you did) that issues such as age > verification > > have no place in a worldwide IETF protocol standard, so while you provide > a > > good example of policy variations among worlds, any such agreements are > outside > > of the context of our protocol. > > Not entirely... age verification is necessary in many countries with > what's going on in an SL-like world. > > A RD cannot do the age-verification; that is a job for an AD. > > However, I think it's the RD that needs to make the decision whether > or not a user is allowed in (based on its age), which in turn means > that the AD has to tell the RD if it knows the age, and if so, what > it is; hence, it should be part of the protocol. > > It's no business of an IETF protocol to deal with the age of participants. That's like SMTP rejecting connections or mail delivery based on the ages of the MTA operator and owner of the mail client. The whole idea is completely ludicrous, not to mention unimplementable. Please let's try not to engage in what Schneier calls "security theater", a politically correct feelgood factor that actually achieves nothing while adding layers of red tape and complexity. Morgaine. ============================== On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood wrote: > On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote: > > It's important to highlight (as you did) that issues such as age > verification > > have no place in a worldwide IETF protocol standard, so while you provide > a > > good example of policy variations among worlds, any such agreements are > outside > > of the context of our protocol. > > Not entirely... age verification is necessary in many countries with > what's going on in an SL-like world. > > A RD cannot do the age-verification; that is a job for an AD. > > However, I think it's the RD that needs to make the decision whether > or not a user is allowed in (based on its age), which in turn means > that the AD has to tell the RD if it knows the age, and if so, what > it is; hence, it should be part of the protocol. > > -- > Carlo Wood > --001636c5bd9d827ca90475104f09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood <carlo@alinoe.com> wrote:
On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote:=
> It's important to highlight (as you did) that issues such as age v= erification
> have no place in a worldwide IETF protocol standard, so while you prov= ide a
> good example of policy variations among worlds, any such agreements ar= e outside
> of the context of our protocol.

Not entirely... age verification is necessary in many countries with<= br> what's going on in an SL-like world.

A RD cannot do the age-verification; that is a job for an AD.

However, I think it's the RD that needs to make the decision whether or not a user is allowed in (based on its age), which in turn means
that the AD has to tell the RD if it knows the age, and if so, what
it is; hence, it should be part of the protocol.


It's no business of= an IETF protocol to deal with the age of participants.=A0 That's like = SMTP rejecting connections or mail delivery based on the ages of the MTA op= erator and owner of the mail client.=A0 The whole idea is completely ludicr= ous, not to mention unimplementable.

Please let's try not to engage in what Schneier calls "securit= y theater", a politically correct feelgood factor that actually achiev= es nothing while adding layers of red tape and complexity.


Morga= ine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

O= n Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood <carlo@alinoe.com> wrote:
On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote:
> It's important to highlight (as you did) that issues such as age v= erification
> have no place in a worldwide IETF protocol standard, so while you prov= ide a
> good example of policy variations among worlds, any such agreements ar= e outside
> of the context of our protocol.

Not entirely... age verification is necessary in many countries with<= br> what's going on in an SL-like world.

A RD cannot do the age-verification; that is a job for an AD.

However, I think it's the RD that needs to make the decision whether or not a user is allowed in (based on its age), which in turn means
that the AD has to tell the RD if it knows the age, and if so, what
it is; hence, it should be part of the protocol.

--
Carlo Wood <carlo@alinoe.com>

--001636c5bd9d827ca90475104f09-- From mike.dickson@hp.com Sat Oct 3 17:37:14 2009 Return-Path: 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 1CC2E3A6824 for ; Sat, 3 Oct 2009 17:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.854 X-Spam-Level: X-Spam-Status: No, score=-105.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 KieIlfjU5SqC for ; Sat, 3 Oct 2009 17:37:13 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id CD4ED3A688C for ; Sat, 3 Oct 2009 17:37:12 -0700 (PDT) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 7BACE380BC; Sun, 4 Oct 2009 00:38:43 +0000 (UTC) Received: from G3W0629.americas.hpqcorp.net (16.233.58.78) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 4 Oct 2009 00:36:18 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G3W0629.americas.hpqcorp.net ([16.233.58.78]) with mapi; Sun, 4 Oct 2009 00:36:18 +0000 From: "Dickson, Mike (ISS Software)" To: Morgaine , Carlo Wood Date: Sun, 4 Oct 2009 00:36:06 +0000 Thread-Topic: [ogpx] VWRAP Draft Charter - 2009 09 01 Thread-Index: AcpEgfUKSipR7gbPRaSov+QPwjAMtAACF0Mw Message-ID: <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD771A0D8236GVW0433EXBame_" MIME-Version: 1.0 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 00:37:14 -0000 --_000_4646639E08F58B42836FAC24C94624DD771A0D8236GVW0433EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The algorithm or mechanism to enforce an age related connection policy is o= utside the scope of the protocol, yes. But its not at all inconceivable t= hat the protocol could carry age information as an attribute that an AD/RD = pair could use to make a decision as to whether a connection is to be allow= ed. Mike From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of Mor= gaine Sent: Saturday, October 03, 2009 6:34 PM To: Carlo Wood Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood > wrote: On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote: > It's important to highlight (as you did) that issues such as age verifica= tion > have no place in a worldwide IETF protocol standard, so while you provide= a > good example of policy variations among worlds, any such agreements are o= utside > of the context of our protocol. Not entirely... age verification is necessary in many countries with what's going on in an SL-like world. A RD cannot do the age-verification; that is a job for an AD. However, I think it's the RD that needs to make the decision whether or not a user is allowed in (based on its age), which in turn means that the AD has to tell the RD if it knows the age, and if so, what it is; hence, it should be part of the protocol. It's no business of an IETF protocol to deal with the age of participants. = That's like SMTP rejecting connections or mail delivery based on the ages = of the MTA operator and owner of the mail client. The whole idea is comple= tely ludicrous, not to mention unimplementable. Please let's try not to engage in what Schneier calls "security theater", a= politically correct feelgood factor that actually achieves nothing while a= dding layers of red tape and complexity. Morgaine. --_000_4646639E08F58B42836FAC24C94624DD771A0D8236GVW0433EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The algorithm or mechanism to enforce an age related connect= ion policy is outside the scope of the protocol, yes.  But its not at all&= nbsp; inconceivable that the protocol could carry age information as an attribute that an AD/RD pair could use to make a decision as to whether a connection is to be allow= ed.

 

Mike

 

From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of Mo= rgaine
Sent: Saturday, October 03, 2009 6:34 PM
To: Carlo Wood
Cc: ogpx@ietf.org
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

 

On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood <carlo@alinoe.com> wrote:=

On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote:
> It's important to highlight (as you did) that issues such as age verification
> have no place in a worldwide IETF protocol standard, so while you prov= ide a
> good example of policy variations among worlds, any such agreements ar= e outside
> of the context of our protocol.

Not entirely... age verification is necessary in many countries with
what's going on in an SL-like world.

A RD cannot do the age-verification; that is a job for an AD.

However, I think it's the RD that needs to make the decision whether
or not a user is allowed in (based on its age), which in turn means
that the AD has to tell the RD if it knows the age, and if so, what
it is; hence, it should be part of the protocol.


It's no business of an IETF protocol to deal with the age of participants.  That's like SMTP rejecting connections or mail delivery based on the ages of the MTA operator and owner of the mail client.  T= he whole idea is completely ludicrous, not to mention unimplementable.

Please let's try not to engage in what Schneier calls "security theater", a politically correct feelgood factor that actually achieves nothing while adding layers of red tape and complexity.

Morgaine.

 

--_000_4646639E08F58B42836FAC24C94624DD771A0D8236GVW0433EXBame_-- From morgaine.dinova@googlemail.com Sat Oct 3 19:13:27 2009 Return-Path: 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 3D4153A685C for ; Sat, 3 Oct 2009 19:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.533 X-Spam-Level: X-Spam-Status: No, score=-1.533 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 lmx4p+GNgzso for ; Sat, 3 Oct 2009 19:13:26 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 935373A67E7 for ; Sat, 3 Oct 2009 19:13:25 -0700 (PDT) Received: by ewy28 with SMTP id 28so2926001ewy.42 for ; Sat, 03 Oct 2009 19:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=4VhxSz6858iCQLQ1zGB2b4GwAs60Wr+ohm1Q9+7bJyM=; b=uCxrefgluR3RGOr8KfMPMz1Vq+5RiutKJSHeyi5PCX48gY8D5/7uj3rdjSASmMBJCG rUjtqbp7t6iXr6To+zgfvT4apdwh6dshOdFyp6rerPTzkRULMgJDcnfpuHtl/emq/QaN cCB3gvIy+ohy9mHbv6QlRD9cHr/mVda78wBrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Mbv3g9on5qnB+qovIj3BQOFFFoUfFyKzZQXgWKXn4QLO87nN9hVtIGN4HRkrKIIC+w /SJoRlgR3jzDN/2NzIihKTNYhPnLzxz6gio/Llhy2BcZyHXAst0d/mZeeKsvy1tqvgVG CbNwP+Sj/hXYt/bIjUAUKtqZJlVjP9aCCKxPY= MIME-Version: 1.0 Received: by 10.211.156.13 with SMTP id i13mr5303302ebo.22.1254622492822; Sat, 03 Oct 2009 19:14:52 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> Date: Sun, 4 Oct 2009 03:14:52 +0100 Message-ID: From: Morgaine To: "Dickson, Mike (ISS Software)" Content-Type: multipart/alternative; boundary=00504502d2ed030b6c04751290f4 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 02:13:27 -0000 --00504502d2ed030b6c04751290f4 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) < mike.dickson@hp.com> wrote: > The algorithm or mechanism to enforce an age related connection policy is > outside the scope of the protocol, yes. But its not at all inconceivable > that the protocol could carry age information as an attribute that an AD/RD > pair could use to make a decision as to whether a connection is to be > allowed. > As carried payload, sure. Just like an SMTP message could carry a message body or even a Subject line about the age of a mail user or about the ages of the MTA sysadmins. But that's not at the level of protocol at all. If the SMTP protocol dealt with the ages of the users of its endpoint applications as a machine-processable semantic, we would be entering an age of total madness and police states. Admittedly, there are totally mad people and police-state advocates around, but hopefully we are not among them. Particularly when it's purely *security theater* and doesn't actually achieve anything. Morgaine. ======================================= On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) < mike.dickson@hp.com> wrote: > The algorithm or mechanism to enforce an age related connection policy is > outside the scope of the protocol, yes. But its not at all inconceivable > that the protocol could carry age information as an attribute that an AD/RD > pair could use to make a decision as to whether a connection is to be > allowed. > > > > Mike > > > > *From:* ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] *On Behalf Of > *Morgaine > *Sent:* Saturday, October 03, 2009 6:34 PM > *To:* Carlo Wood > *Cc:* ogpx@ietf.org > *Subject:* Re: [ogpx] VWRAP Draft Charter - 2009 09 01 > > > > On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood wrote: > > On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote: > > It's important to highlight (as you did) that issues such as age > verification > > have no place in a worldwide IETF protocol standard, so while you provide > a > > good example of policy variations among worlds, any such agreements are > outside > > of the context of our protocol. > > Not entirely... age verification is necessary in many countries with > what's going on in an SL-like world. > > A RD cannot do the age-verification; that is a job for an AD. > > However, I think it's the RD that needs to make the decision whether > or not a user is allowed in (based on its age), which in turn means > that the AD has to tell the RD if it knows the age, and if so, what > it is; hence, it should be part of the protocol. > > > It's no business of an IETF protocol to deal with the age of participants. > That's like SMTP rejecting connections or mail delivery based on the ages of > the MTA operator and owner of the mail client. The whole idea is completely > ludicrous, not to mention unimplementable. > > Please let's try not to engage in what Schneier calls "security theater", a > politically correct feelgood factor that actually achieves nothing while > adding layers of red tape and complexity. > > Morgaine. > > > --00504502d2ed030b6c04751290f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) <mike.dickson@hp.com><= /span> wrote:

The algorithm = or mechanism to enforce an age related connection policy is outside the scope of the protocol, yes.=A0 But its not at all=A0 = inconceivable that the protocol could carry age information as an attribute that an AD/RD pair could use to make a decision as to whether a connection is to be allow= ed.


As carried payload, sure.= =A0 Just like an SMTP message could carry a message body or even a Subject = line about the age of a mail user or about the ages of the MTA sysadmins.= =A0 But that's not at the level of protocol at all.=A0 If the SMTP prot= ocol dealt with the ages of the users of its endpoint applications as a mac= hine-processable semantic, we would be entering an age of total madness and= police states.

Admittedly, there are totally mad people and police-state advocates aro= und, but hopefully we are not among them.=A0 Particularly when it's pur= ely security theater and doesn't actually achieve anything.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
=A0
On Sun, Oct 4, 2009 at= 1:36 AM, Dickson, Mike (ISS Software) <mike.dickson@hp.com> wrote:

The algorithm = or mechanism to enforce an age related connection policy is outside the scope of the protocol, yes.=A0 But its not at all=A0 = inconceivable that the protocol could carry age information as an attribute that an AD/RD pair could use to make a decision as to whether a connection is to be allow= ed.

=A0

Mike

=A0

From: ogpx-bounces@iet= f.org [mailto:ogpx-bounces@ietf.org] On Behalf Of Morgaine
Sent: Saturday, October 03, 2009 6:34 PM
To: Carlo Wood
Cc: ogpx@ietf.org=


Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

=A0

On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood <carlo@alinoe.com> wrote:

On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote:
> It's important to highlight (as you did) that issues such as age verification
> have no place in a worldwide IETF protocol standard, so while you prov= ide a
> good example of policy variations among worlds, any such agreements ar= e outside
> of the context of our protocol.

Not entirely... age verification is necessary in many countries with
what's going on in an SL-like world.

A RD cannot do the age-verification; that is a job for an AD.

However, I think it's the RD that needs to make the decision whether or not a user is allowed in (based on its age), which in turn means
that the AD has to tell the RD if it knows the age, and if so, what
it is; hence, it should be part of the protocol.


It's no business of an IETF protocol to deal with the age of participants.=A0 That's like SMTP rejecting connections or mail deliver= y based on the ages of the MTA operator and owner of the mail client.=A0 The = whole idea is completely ludicrous, not to mention unimplementable.

Please let's try not to engage in what Schneier calls "security theater", a politically correct feelgood factor that actually achieves nothing while adding layers of red tape and complexity.

Morgaine.

=A0


--00504502d2ed030b6c04751290f4-- From mike.dickson@hp.com Sat Oct 3 20:27:58 2009 Return-Path: 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 A97D03A67E7 for ; Sat, 3 Oct 2009 20:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 NOJEgt9b2yh4 for ; Sat, 3 Oct 2009 20:27:51 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by core3.amsl.com (Postfix) with ESMTP id 7F60E3A67A7 for ; Sat, 3 Oct 2009 20:27:51 -0700 (PDT) Received: from G6W0640.americas.hpqcorp.net (g6w0640.atlanta.hp.com [16.230.34.76]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0006.atlanta.hp.com (Postfix) with ESMTPS id 6F929C044; Sun, 4 Oct 2009 03:29:22 +0000 (UTC) Received: from G4W1853.americas.hpqcorp.net (16.234.97.231) by G6W0640.americas.hpqcorp.net (16.230.34.76) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 4 Oct 2009 03:28:47 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G4W1853.americas.hpqcorp.net ([16.234.97.231]) with mapi; Sun, 4 Oct 2009 03:28:48 +0000 From: "Dickson, Mike (ISS Software)" To: Morgaine Date: Sun, 4 Oct 2009 03:25:13 +0000 Thread-Topic: [ogpx] VWRAP Draft Charter - 2009 09 01 Thread-Index: AcpEmHZ6S34UY5gXTVClbcbyNRKe4QACDrLw Message-ID: <4646639E08F58B42836FAC24C94624DD771A0D824C@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD771A0D824CGVW0433EXBame_" MIME-Version: 1.0 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 03:27:58 -0000 --_000_4646639E08F58B42836FAC24C94624DD771A0D824CGVW0433EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) > wrote: The algorithm or mechanism to enforce an age related connection policy is o= utside the scope of the protocol, yes. But its not at all inconceivable t= hat the protocol could carry age information as an attribute that an AD/RD = pair could use to make a decision as to whether a connection is to be allow= ed. As carried payload, sure. Just like an SMTP message could carry a message = body or even a Subject line about the age of a mail user or about the ages = of the MTA sysadmins. But that's not at the level of protocol at all. If = the SMTP protocol dealt with the ages of the users of its endpoint applicat= ions as a machine-processable semantic, we would be entering an age of tota= l madness and police states. Except that in the case of virtual worlds there already is a practice aroun= d defining regions in terms of age specific characteristics. Are you sayin= g you don't like the practice so you don't want it in the protocol? Or are= you really saying it's not necessary and if so how do you propose someone = providing a region to a VW environment who wishes to restrict it to "Adult"= content where age matters. And I don't understand your assertion that its= not at the "protocol" level... In an SMTP exchange when I connect and sen= d the HELO I generally need to identify myself. The from address is an att= ribute in the same way that age information could be carried in the protoco= l (in SMTP more analogous to the additional message headers like mailer, et= c). Admittedly, there are totally mad people and police-state advocates around,= but hopefully we are not among them. Particularly when it's purely securi= ty theater and doesn't actually achieve anything. Again, I don't understand this assertion given this is an already existing = practice. Mike =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) > wrote: The algorithm or mechanism to enforce an age related connection policy is o= utside the scope of the protocol, yes. But its not at all inconceivable t= hat the protocol could carry age information as an attribute that an AD/RD = pair could use to make a decision as to whether a connection is to be allow= ed. Mike From: ogpx-bounces@ietf.org [mailto:ogpx-boun= ces@ietf.org] On Behalf Of Morgaine Sent: Saturday, October 03, 2009 6:34 PM To: Carlo Wood Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood > wrote: On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote: > It's important to highlight (as you did) that issues such as age verifica= tion > have no place in a worldwide IETF protocol standard, so while you provide= a > good example of policy variations among worlds, any such agreements are o= utside > of the context of our protocol. Not entirely... age verification is necessary in many countries with what's going on in an SL-like world. A RD cannot do the age-verification; that is a job for an AD. However, I think it's the RD that needs to make the decision whether or not a user is allowed in (based on its age), which in turn means that the AD has to tell the RD if it knows the age, and if so, what it is; hence, it should be part of the protocol. It's no business of an IETF protocol to deal with the age of participants. = That's like SMTP rejecting connections or mail delivery based on the ages = of the MTA operator and owner of the mail client. The whole idea is comple= tely ludicrous, not to mention unimplementable. Please let's try not to engage in what Schneier calls "security theater", a= politically correct feelgood factor that actually achieves nothing while a= dding layers of red tape and complexity. Morgaine. --_000_4646639E08F58B42836FAC24C94624DD771A0D824CGVW0433EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On Sun, Oct 4, 2009 at 1:36= AM, Dickson, Mike (ISS Software) <mik= e.dickson@hp.com> wrote:

The algorithm or mechanism to enforce an age related connection policy is outsi= de the scope of the protocol, yes.  But its not at all  inconceivabl= e that the protocol could carry age information as an attribute that an AD/RD pair could use to make a decision as to whether a connection is to be allow= ed.

As carried payload, sure.  Just like an = SMTP message could carry a message body or even a Subject line about the age of = a mail user or about the ages of the MTA sysadmins.  But that's not at t= he level of protocol at all.  If the SMTP protocol dealt with the ages of= the users of its endpoint applications as a machine-processable semantic, we wo= uld be entering an age of total madness and police states.

Except that in the case of virtual worlds there already is a practice around defin= ing regions in terms of age specific characteristics.  Are you saying you don̵= 7;t like the practice so you don’t want it in the protocol?  Or are = you really saying it’s not necessary and if so how do you propose someone providing a region to a VW environment who wishes to restrict it to “= Adult” content where age matters.  And I don’t understand your assertio= n that its not at the “protocol” level…  In an SMTP ex= change when I connect and send the HELO I generally need to identify myself. = The from address is an attribute in the same way that age information could be carried in the protocol (in SMTP more analogous to the additional message headers like mailer, etc).         =     

Admittedly, there are totally mad people and police-state advocates around, but hopefully we are not among them.  Particularly when it's purely security theater and doesn't actually achieve anything.

Again, I don’t understand this assertion given this is an already existing practice.

Mike





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 

On Sun, Oct 4, 2009 at 1:36= AM, Dickson, Mike (ISS Software) <mik= e.dickson@hp.com> wrote:

The algorithm or mechanism to enforce an age related connection policy is outsi= de the scope of the protocol, yes.  But its not at all  inconceivabl= e that the protocol could carry age information as an attribute that an AD/RD pair could use to make a decision as to whether a connection is to be allow= ed.

 

Mike

 

From: ogpx-bounces@ietf.org [mailto:ogpx-bou= nces@ietf.org] On Behalf Of Morgaine
Sent: Saturday, October 03, 2009 6:34 PM
To: Carlo Wood
Cc: ogpx@ietf.org=


Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

 

On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood &= lt;carlo@alinoe.com>= wrote:

On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote:=
> It's important to highlight (as you did) that issues such as age verification
> have no place in a worldwide IETF protocol standard, so while you prov= ide a
> good example of policy variations among worlds, any such agreements ar= e outside
> of the context of our protocol.

Not entirely... age verification is necessary in many countries with
what's going on in an SL-like world.

A RD cannot do the age-verification; that is a job for an AD.

However, I think it's the RD that needs to make the decision whether
or not a user is allowed in (based on its age), which in turn means
that the AD has to tell the RD if it knows the age, and if so, what
it is; hence, it should be part of the protocol.


It's no business of an IETF protocol to deal with the age of participants.  That's like SMTP rejecting connections or mail delivery based on the ages of the MTA operator and owner of the mail client.  T= he whole idea is completely ludicrous, not to mention unimplementable.

Please let's try not to engage in what Schneier calls "security theater", a politically correct feelgood factor that actually achieves nothing while adding layers of red tape and complexity.

Morgaine.

 

 

--_000_4646639E08F58B42836FAC24C94624DD771A0D824CGVW0433EXBame_-- From morgaine.dinova@googlemail.com Sun Oct 4 00:43:37 2009 Return-Path: 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 B16523A690E for ; Sun, 4 Oct 2009 00:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 3Dl1NbSlFbVu for ; Sun, 4 Oct 2009 00:43:36 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 2962E3A68F1 for ; Sun, 4 Oct 2009 00:43:32 -0700 (PDT) Received: by ewy28 with SMTP id 28so3054163ewy.42 for ; Sun, 04 Oct 2009 00:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bf6Aycy2NG6SXgtvdpw9Pp9G+gxe1MMib+Bx3X5S0nQ=; b=oGtCNT+PyaP8+5Qh0DfpGAcds6/Q35SwbZnC5Y9OAYFIL9Whg0OuHWFdgnWCw+sIdC 4VMXoUtF+IYm5HDvPs4NCtPDzlQT8TIBiz1c5WvOfIF5d1P9x7W8+vc6YAqiYwcFIUkL 1FRgCB8PcsLQLpMFnzTDrRxe1q+RY8IBDUTmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LozGvgPaZHlP/RiHCM2Np81nxJjlYF85SzbInz3/H8aW9mLdobhpORj9zBlGsavGzE XJdJe7N7I8gnOEMguWLKRY5Q/hXhaTusdxu11ZCNOQBJ4/brMGTNw/qxJBkPtyj2KYty ZExwpc47GnVKHOo+M0NFX6sNVaB4fx7sXmIuw= MIME-Version: 1.0 Received: by 10.211.145.12 with SMTP id x12mr5469672ebn.44.1254642300934; Sun, 04 Oct 2009 00:45:00 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A0D824C@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> <4646639E08F58B42836FAC24C94624DD771A0D824C@GVW0433EXB.americas.hpqcorp.net> Date: Sun, 4 Oct 2009 08:45:00 +0100 Message-ID: From: Morgaine To: "Dickson, Mike (ISS Software)" Content-Type: multipart/alternative; boundary=00504502c7e1aadc480475172cb0 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 07:43:37 -0000 --00504502c7e1aadc480475172cb0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Oct 4, 2009 at 4:25 AM, Dickson, Mike (ISS Software) < mike.dickson@hp.com> wrote: > > > Again, I don=92t understand this assertion given this is an already exist= ing > practice. > It is "existing practice" in one single proprietary virtual world (Second Life), and nowhere else. In particular, it is not existing practice in the many open virtual worlds that use the Opensim framework. And further on the proprietary example, SL added it only very recently, and that despite mass objections from a good 90% of its resident population who were completely ignored and overridden in the alleged "consultation". So your attempt at making this sound normal and desired merely reflects you= r minority bias and lack of concern for balkanizing the metaverse even furthe= r than the "trust agreements" are going to do already. No thanks. Age restrictions have no place in an IETF interop protocol. As payload, of course everything will be carried, but we don't need to add = a totally ridiculous piece of security theater to the protocol just to carry such data. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sun, Oct 4, 2009 at 4:25 AM, Dickson, Mike (ISS Software) < mike.dickson@hp.com> wrote: > On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) < > mike.dickson@hp.com> wrote: > > The algorithm or mechanism to enforce an age related connection policy is > outside the scope of the protocol, yes. But its not at all inconceivabl= e > that the protocol could carry age information as an attribute that an AD/= RD > pair could use to make a decision as to whether a connection is to be > allowed. > > As carried payload, sure. Just like an SMTP message could carry a messag= e > body or even a Subject line about the age of a mail user or about the age= s > of the MTA sysadmins. But that's not at the level of protocol at all. I= f > the SMTP protocol dealt with the ages of the users of its endpoint > applications as a machine-processable semantic, we would be entering an a= ge > of total madness and police states. > > Except that in the case of virtual worlds there already is a practice > around defining regions in terms of age specific characteristics. Are yo= u > saying you don=92t like the practice so you don=92t want it in the protoc= ol? Or > are you really saying it=92s not necessary and if so how do you propose > someone providing a region to a VW environment who wishes to restrict it = to > =93Adult=94 content where age matters. And I don=92t understand your ass= ertion > that its not at the =93protocol=94 level=85 In an SMTP exchange when I c= onnect > and send the HELO I generally need to identify myself. The from address = is > an attribute in the same way that age information could be carried in the > protocol (in SMTP more analogous to the additional message headers like > mailer, etc). > > Admittedly, there are totally mad people and police-state advocates aroun= d, > but hopefully we are not among them. Particularly when it's purely *secu= rity > theater* and doesn't actually achieve anything. > > Again, I don=92t understand this assertion given this is an already exist= ing > practice. > > Mike > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) < > mike.dickson@hp.com> wrote: > > The algorithm or mechanism to enforce an age related connection policy is > outside the scope of the protocol, yes. But its not at all inconceivabl= e > that the protocol could carry age information as an attribute that an AD/= RD > pair could use to make a decision as to whether a connection is to be > allowed. > > > > Mike > > > > *From:* ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] *On Behalf O= f > *Morgaine > *Sent:* Saturday, October 03, 2009 6:34 PM > *To:* Carlo Wood > *Cc:* ogpx@ietf.org > > > *Subject:* Re: [ogpx] VWRAP Draft Charter - 2009 09 01 > > > > On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood wrote: > > On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote: > > It's important to highlight (as you did) that issues such as age > verification > > have no place in a worldwide IETF protocol standard, so while you provi= de > a > > good example of policy variations among worlds, any such agreements are > outside > > of the context of our protocol. > > Not entirely... age verification is necessary in many countries with > what's going on in an SL-like world. > > A RD cannot do the age-verification; that is a job for an AD. > > However, I think it's the RD that needs to make the decision whether > or not a user is allowed in (based on its age), which in turn means > that the AD has to tell the RD if it knows the age, and if so, what > it is; hence, it should be part of the protocol. > > > It's no business of an IETF protocol to deal with the age of participants= . > That's like SMTP rejecting connections or mail delivery based on the ages= of > the MTA operator and owner of the mail client. The whole idea is complet= ely > ludicrous, not to mention unimplementable. > > Please let's try not to engage in what Schneier calls "security theater",= a > politically correct feelgood factor that actually achieves nothing while > adding layers of red tape and complexity. > > Morgaine. > > > > > --00504502c7e1aadc480475172cb0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Oct 4, 2009 at 4:25 AM, Dickson, Mike (ISS Software) <mike.dickson@hp.com><= /span> wrote:
=A0

Again, I don=92t understand this assertion given this is an already existing practice.


It is &q= uot;existing practice" in one single proprietary virtual world (Second= Life), and nowhere else.=A0 In particular, it is not existing practice in = the many open virtual worlds that use the Opensim framework.

And further on the proprietary example, SL added it only very recently,= and that despite mass objections from a good 90% of its resident populatio= n who were completely ignored and overridden in the alleged "consultat= ion".
=A0
So your attempt at making this sound normal and desired merely ref= lects your minority bias and lack of concern for balkanizing the metaverse = even further than the "trust agreements" are going to do already.=

No thanks.=A0 Age restrictions have no place in an IETF interop protoco= l.

As payload, of course everything will be carried, but we don'= t need to add a totally ridiculous piece of security theater to the protoco= l just to carry such data.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

On Sun, Oct 4, 2009= at 4:25 AM, Dickson, Mike (ISS Software) <mike.dickson@hp.com> wrote:

On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) <mike.dickson@hp.com> wrote:

The algorithm or mechanism to enforce an age related connection policy is outsi= de the scope of the protocol, yes.=A0 But its not at all=A0 inconceivable that the protocol could carry age information as an attribute that an AD/RD pair could use to make a decision as to whether a connection is to be allow= ed.=

As carried payload, sure.=A0 Just like an = SMTP message could carry a message body or even a Subject line about the age of = a mail user or about the ages of the MTA sysadmins.=A0 But that's not at = the level of protocol at all.=A0 If the SMTP protocol dealt with the ages of th= e users of its endpoint applications as a machine-processable semantic, we wo= uld be entering an age of total madness and police states.

Except that in the case of virtual worlds there already is a practice around defin= ing regions in terms of age specific characteristics.=A0 Are you saying you don=92t like the practice so you don=92t want it in the protocol?=A0 Or are you really saying it=92s not necessary and if so how do you propose someone providing a region to a VW environment who wishes to restrict it to =93Adul= t=94 content where age matters.=A0 And I don=92t understand your assertion that its not at the =93protocol=94 level=85=A0 In an SMTP exchange when I connect and send the HELO I generally need to identify myself.=A0 Th= e from address is an attribute in the same way that age information could be carried in the protocol (in SMTP more analogous to the additional message headers like mailer, etc). =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=

Admittedly, there are totally mad people a= nd police-state advocates around, but hopefully we are not among them.=A0 Particularly when it's purely security theater and doesn't a= ctually achieve anything.

Again, I don=92t understand this assertion given this is an already existing practice.

Mike




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=A0

On Sun, Oct 4, 2009 at 1:36 AM, Dickson, Mike (ISS Software) <mike.dickson@hp.com> wrote:

The algorithm or mechanism to enforce an age related connection policy is outsi= de the scope of the protocol, yes.=A0 But its not at all=A0 inconceivable that the protocol could carry age information as an attribute that an AD/RD pair could use to make a decision as to whether a connection is to be allow= ed.

=A0

Mike

=A0

From:<= /span> ogpx-bounces@ietf.org [mailto:ogpx-bou= nces@ietf.org] On Behalf Of Morgaine
Sent: Saturday, October 03, 2009 6:34 PM
To: Carlo Wood
Cc: ogpx@ietf.org=


Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

=A0

On Sat, Oct 3, 2009 at 11:21 PM, Carlo Woo= d <carlo@alinoe.co= m> wrote:

On= Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote:
> It's important to highlight (as you did) that issues such as age verification
> have no place in a worldwide IETF protocol standard, so while you prov= ide a
> good example of policy variations among worlds, any such agreements ar= e outside
> of the context of our protocol.

No= t entirely... age verification is necessary in many countries with
what's going on in an SL-like world.

A RD cannot do the age-verification; that is a job for an AD.

However, I think it's the RD that needs to make the decision whether or not a user is allowed in (based on its age), which in turn means
that the AD has to tell the RD if it knows the age, and if so, what
it is; hence, it should be part of the protocol.

It's no business of an IETF protocol to deal with the age of participants.=A0 That's like SMTP rejecting connections or mail deliver= y based on the ages of the MTA operator and owner of the mail client.=A0 The whole idea is completely ludicrous, not to mention unimplementable.

Please let's try not to engage in what Schneier calls "security theater", a politically correct feelgood factor that actually achieves nothing while adding layers of red tape and complexity.

Morgaine.

=A0

=A0


--00504502c7e1aadc480475172cb0-- From morgaine.dinova@googlemail.com Sun Oct 4 00:49:18 2009 Return-Path: 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 70EB03A6912 for ; Sun, 4 Oct 2009 00:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 vvU9Rc+J-+Mt for ; Sun, 4 Oct 2009 00:49:15 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 9043D3A68F1 for ; Sun, 4 Oct 2009 00:49:14 -0700 (PDT) Received: by ewy28 with SMTP id 28so3057174ewy.42 for ; Sun, 04 Oct 2009 00:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LJPEQNNihvJYEywya1peMFJnolZSnYDnFO5kDGTWAk8=; b=kfzIqXPQh5k1e89YPFPUwWcLRCEXk+DevmLfM9a0yAY6Tyvlg7x9RbXyCm+qe9Fptl zWyJ7FlCabgkujLQqY8eZ0b5SWMXHmCoiEiNBZGneR5sXko6f451hHsxQ6QfLN5oJhGw qxG/r/1K4QtUWrfKufD1qkef2G/rrNlxcP19I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W5tukHT7OQ4x6mpy7jEtlkYGpYwVxXDWIaKHD7ONNwY0eCnNpphSf/j72LcdvIIDSO 0gJ7QNc6K0qFRW4JO+GTfXa3uNAUejAToLYaB92TyzoPht5wO3Ed0QudWsqCO6YsXR+W zLamqlhHVjzIGYOFZNFHF8BxM9KPQjfg6ehok= MIME-Version: 1.0 Received: by 10.211.159.11 with SMTP id l11mr5285264ebo.78.1254642643244; Sun, 04 Oct 2009 00:50:43 -0700 (PDT) In-Reply-To: <9b8a8de40910020144v36077295u314d34d579e21f26@mail.gmail.com> References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <9b8a8de40910020144v36077295u314d34d579e21f26@mail.gmail.com> Date: Sun, 4 Oct 2009 08:50:43 +0100 Message-ID: From: Morgaine To: Vaughn Deluca Content-Type: multipart/alternative; boundary=001636d3464012195604751741fd Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 07:49:18 -0000 --001636d3464012195604751741fd Content-Type: text/plain; charset=ISO-8859-1 Vaughn, I think I'm with you on the problems you've highlighted, although perhaps I'd better tick the paragraphs to be sure: On Fri, Oct 2, 2009 at 9:44 AM, Vaughn Deluca wrote: > Morgaine, > > I am equally worried about the problem you sketch in the paragraph below, > however, i think you put the source of that problem in the wrong place. You > argue that if only AD2 is cut out of the equation, all will be fine, and > tourism will be possible. I wish it was true, but even when things are fully > organised as you suggested its the *trust* relations that determine what > will happen, let me explain: > It should be noted that I'm trying to cut AD2 out of the equation mainly because this is one of Joshua's requirements stemming from the original OGP scheme. If our various goals can be achieved without needing to involve AD2 then all the better, since reduction of complexity is always a good thing, so I support Joshua in that. As it happens, it is possible to achieve DDP using Joshua's scheme by limiting ADs to agent policies and RDs to region policies, and therefore I'm happy with this approach. However, I am fully aware that this doesn't always make tourism possible, since it still requires the cooperation of both worlds. A prison world will not let its inmates escape, and a closed society will not allow foreign visitors to enter, so just because DDP makes tourism *possible* doesn't mean that individual world policies will always allow it. > > >[...] But instead you might mean the following: "if RD2 uses some service > of type X, say X2, > >then AD1 cannot provide an X service when in RD2". That would be > extremely not cool, since > >this would totally block meaningful tourism. > > I agree with this sad conclusion, i think the wording could be a lot > sharper, i will come to that below, but loosely speaking you are right. Now > you make the example more explicit: > > > For example, RD2 could be using Asset Service AS2, as a result > > of which AD1 would not supply an asset service to its traveling > > agent A1, and hence A1 would never be able to appear in RD2 wearing > > any asset available in W1. > While this is catastrophic for interop in multi-world deployments, note that Joshua has already accepted this and recognized that asset service contributions are required from both W1 and W2. Although we are still working out the details, the point is already somewhat moot because the severity of the problem has been accepted. Note that I offered one solution to this problem at the end of this post -- http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html . It's really simple, and boils down to asset services being provided entirely by the RDs. RD1 provides access to the asset service AS1 (typically proxy access --- after all, SL's regions already work as proxies to an asset service, so it's no big leap), while RD2 provides access to the asset service AS2. No AD can ever provide an asset service, and therefore AD2 does not need to be consulted on TP. > > Note that you now say "would not supply" not "cant not provide" as you did > above. This distinction is important. I will follow the more explicit > example, since that is how things are intended IMHO. Also you seem to > suggest an all or nothing behaviour of the asset server that i feel is not > needed, and probably not desirable. > > I meant *cannot provide*, very specifically. The reason is that my analysis stemmed from Joshua's statement about *disjointness* of AS and RD services. The "cannot" is a mathematical "cannot", in the sense that if the AD and RD service sets are *disjoint* then the same services cannot appear in both. Joshua accepted the problem and softened his phrase to the funny "mostly disjoint". :D Note that my proposal resolved this quite simply by requiring asset services to be provided only by RDs. This gives us the DDP necessary for tourism (or *potential* tourism, I should say), plus it allows assets from W1 and W2 to appear in RD2, and it does not require AD2 to be consulted. That seems quite a nice package deal. > >Clearly this interpretation would mean no useful interop between > >W1 and W2 at all. I'm hoping this interpretation is wrong. > > It would mean no meaningful interop between some of the involved services, > and that as a result of *policy* decisions that can be in *each and every > case* right there where they belong. As i will show below, you can not > escape this situation by trying to deny AD2 any role in the process. The > pain is elsewhere. Lets do this example a bit more careful: > > Our tourist is at home in W1. W1 is a container concept for a collection of > services. The agent is in fact registered in AD1, it uses a big collection > of (purple) clothes from AS1, and is presently located in RD1, trying to > become a tourist and travel for the first time to RD2 (to show off its > purple clothes). > > AD1 talks to RD2, trying to gain access rights. RD2 has some age > restrictions, but AD1 manages to convince RD2 its agent is worthy of entry > based on some shared trust of a third party identity provider. No role for > AD2 as you stipulated (although RD2 might have passed responsibility for > this part of the process to AD2, but for clarity lets assume that is not the > case). > > Our tourist could now enter RD2 as Ruth. Next AD1 tries to organise the > passage of the purple cloths. That transfer has two endpoints, the asset > service AS1, and RD2. Again RD2 might have some policy what to allow in, and > lets assume its cool with anything, purple or not. Infinity and Carlo looked > at some alien boundary cases, but here we assume RD2 is happy with any > tourism it can get, including all assets. AS1 on the other hand has > obligations to a large group of purple cloths makers, and will only give out > purple stuff to RD2 if RD2 satisfies some strong conditions. It has the > protocol means to test those conditions, it *could* send the purple object, > but does not *want to* based on policy, in particular obligations towards > purple clothes makers and the lack of trust in the behaviour of RD2. AS1 > will however probably send any non-purple clothes to RD2. Cursing under its > breath our tourist might go there in blue, mentally making a note to find a > different clothes shop next time its shopping time. > I believe that I understand your point. You are describing the situation that arises when W1 policy overrides the user-chosen policy that the user encodes in her assets in AS1. I agree that this is an issue. I pointed it out here http://www.ietf.org/mail-archive/web/ogpx/current/msg00433.html in answer to David's statement that "services are going to manage policy, not the domains they reside in", Clearly David's statement doesn't quite reflect where we are at the moment with the protocol, in which domains are totally crushing the policies of services, although of course it is still early days. :-) > I completely fail to see what you would like to put in the protocol, or > leave out of it, to remedy this situation. The would-be tourist has only > one option, and that is to find an asset server that is willing to give out > at least the blue clothes to RD2. The restriction in this example is in > AS1 not willing to serve the purple clothes, and AS1 is a service that the > *tourist* has picked. If that turns out to be an unlucky choice and AS1 > refuses to give *anything* out to RD2 as you implied in your original > example, the tourist might opt to start using an additional AS, say AS2. If > AD1 in turn refuses to use AS2 next to AS1, it might really be time to pack > up and move world. Hence my remark (and that of several others) that in the > end interop will be a question of trust, and users will vote with their > feet. > In fact its not even AS1 that is the root of the problem, its the buying > decision of the avatar itself. It might be have been wiser to check more > careful on the export conditions of the purple wonders. > I think that my view on this is more in tune with David. We have made a rod for our own backs by defining domains as enforcers of policy, instead of leaving policy to the services. If we had left policy to the services then a user would be able to configure her asset service AS1 to allow purple clothing to enter RD2, despite the cartel operating in W1 seeking to restrict any travel while wearing purple clothing. > In summary, i see your problem, its big and bad, but i fail to see your > solution. Could you go over this example and point out how things should be > done to prevent the blocked transfer of purple clothes? I do not think that > within the scope of the protocol there is a solution. > > You may be right to be worried. The protocol as it stands denies any possibility of such user freedom. Perhaps domains should be removed from the model altogether, leaving just services. An interesting post, Vaughn, thanks. :-) Morgaine. ================================= > Looking in even more detail at the example brings up deeper problems, like > how the clothes maker is going to know in what AS the purple clothes will > end up. But that is for later i think. > > Sorry for the long mail, i will tty to be more brief in the future > Vaughn > > On Fri, Oct 2, 2009 at 7:52 AM, Morgaine wrote: > >> I agree Joshua, I think we are converging. :-) >> >> On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell wrote: >> >>> >>> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine >> > wrote: >>> >>> >>>> There *IS* one way of allowing the above, and that is to require that >>>> ADs carry no region-related policies at all, so that consulting only the >>>> destination RD is sufficient. This would give us a perfect *Destination >>>> Determines Policy* (DDP) system. The W1 resident could then TP from >>>> RD1 to RD2 without consulting AD2 at all. >>>> >>> >> .... and so it looks like we're in agreement ... >> >> >> That's a very good start then. If ADs have no region-related policies, >> then AD2 clearly doesn't need to be consulted when RD2 is entered from RD1. >> >> Unfortunately, you then wrote: >> >> it should be the case that ADs carry policies about region services... >> >> >> Is there a typo in that? If it's free of typos and hence ADs carry >> policies about region services, then clearly AD2 *does* have to be >> consulted before you can TP from RD1 to RD2. (I assume it has a typo, and >> you actually meant to write "do *not* carry policies about region >> services", to make this line consistent with what you said above.) >> >> Leaving the above to be clarified, we seem to be arriving at a *Destination >> Determines Policy* (DDP) model which makes tourism possible, by giving >> RDs control over their region-related policies so that AD2 doesn't need to >> be consulted on entry to RD2. That's fine, but it's not yet clear how >> you're going to achieve this since you haven't narrowed the scope of the AD >> to exclude region services. >> >> One promising angle stems from this very interesting phrase of yours: >> >> ... by definition the AD2 and RD2 services are disjoint. >>> >> >> It's a bit ambiguous though: >> >> - If by this you mean that AD1 has no say over region services in RD2, >> then that's very cool! :-) (It's cool because it provides DDP and hence >> allows tourism.) >> - But instead you might mean the following: "*if RD2 uses some >> service of type X, say X2, then AD1 cannot provide an X service when in RD2" >> *. That would be extremely not cool, since this would totally block >> meaningful tourism. For example, RD2 could be using Asset Service AS2, as a >> result of which AD1 would not supply an asset service to its travelling >> agent A1, and hence A1 would never be able to appear in RD2 wearing any >> asset available in W1. Clearly this interpretation would mean no useful >> interop between W1 and W2 at all. I'm hoping this interpretation is wrong. >> >> >> I'd appreciate more info about the disjointness please, to clear up this >> ambiguity. >> >>> >>> >>> I believe I may have misread some of your earlier posts as implying that >>> the agent's AD was not allowed to have a say in policy decisions, only the >>> destination RD. I have a clearer reading of your DDP statement, though, that >>> of course it's the AD reasoning about the RD, and contrariwise the RD >>> reasoning about the AD. If we call that "DDP" then we're copacetic. >>> >>> Ah good, I think we're starting to talk the same language now. :-) AD1 >> has plenty to say in regards to a TP from RD1 to RD2, as long as it sticks >> to the affairs of its own world W1 and its own agent A1. What it cannot do >> is impose W1's region-related policies on W2's regions, otherwise we end up >> with Vaughn's "war on purple". ;-) In other words, once in RD2, DDP >> applies and AD1 has no say. >> >> The DDP principle is so obvious from our experience in RL that I didn't >> bother explaining its scope, but perhaps some basic scoping is needed to >> alleviate fears that the source AD has no say at all. The only thing that >> DDP requires is that the travelling agent *obey the law of the land* on >> arrival in W2, namely the region-related policies that hold in RD2, and not >> those that would hold in a W1 homeworld region like RD1. It's pretty >> simple, and non-optional if tourism between worlds is desired. "When in >> Rome, do as the Romans do" says it all. >> >> As you say, I believe we're converging. :-) >> >> >> Morgaine. >> >> >> >> >> >> >> >> ========================================= >> >> On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell wrote: >> >>> I think we're converging... >>> >>> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine >> > wrote: >>> >>>> >>>> Those are valid examples, but they're cherry picked to support your >>>> specific use case. >>>> >>>> >>> Well, simplified examples. I don't believe more complicated examples >>> actually add meaningfully at a protocol level, as will become clear... >>> >>> >>>> Please examine the more general use case of two complete SL-like worlds >>>> using VWRAP, W1 and W2. They both have ADs and RDs, so let's label those >>>> with 1's and 2's accordingly. >>>> >>> >>> At a protocol level, I don't think VWs exist. There are services, which >>> we're clustering into AD and RD. Although we may later determine there are >>> further subdivisions, that's our working model in the drafts. Further drafts >>> are strongly encouraged! >>> >>> >>>> If both ADs and RDs determine policy together (as you stated), then you >>>> can't expect a resident of W1 to TP from RD1 to RD2 without AD2's policy >>>> coming into play, otherwise you would be subverting AD2's policy. >>>> >>> >>> Here's the crux of the issue: in our model, the provider of W2 is >>> offering two sets of services, AD2 and RD2. There may be a policy covering >>> W2 in general, which would affect the AD2 and RD2 services. However, if an >>> agent "from" W1, meaning the agent services are provided by AD1, attempts to >>> visit RD2, then AD2 does *not* come into play. The protocol describes the >>> negotiation between the client, AD1 and RD2 *only*. >>> >>> (Again, this is insofar as the model in the current drafts are concerned. >>> If we're missing something, please bring the conversation back to the drafts >>> and point out issues and/or submit new work for discussion!) >>> >>> Let me restate: even if AD2 and RD2 are governed by the same policy - >>> potentially even to the point of being implemented by the same monolithic >>> piece of code! - AD2 is irrelevant *from a protocol perspective* in the >>> attempt to place an agent from AD1 into AD2, since by definition the AD2 and >>> RD2 services are disjoint. >>> >>> >>>> There *IS* one way of allowing the above, and that is to require that >>>> ADs carry no region-related policies at all, so that consulting only the >>>> destination RD is sufficient. This would give us a perfect *Destination >>>> Determines Policy* (DDP) system. The W1 resident could then TP from >>>> RD1 to RD2 without consulting AD2 at all. >>>> >>> >>> .... and so it looks like we're in agreement - if this wasn't clear, then >>> we need to review the drafts (please, go for it!); it should be the case >>> that ADs carry policies about region services... except, of course, that the >>> AD may say "hey, you can't go to *that* RD...". >>> >>> I believe I may have misread some of your earlier posts as implying that >>> the agent's AD was not allowed to have a say in policy decisions, only the >>> destination RD. I have a clearer reading of your DDP statement, though, that >>> of course it's the AD reasoning about the RD, and contrariwise the RD >>> reasoning about the AD. If we call that "DDP" then we're copacetic. >>> >>> >>> >>>> If you wish to define ADs in this way then we are in perfect agreement, >>>> since DDP is essential for interop between worlds. I am hoping that this is >>>> what you had in mind for when we start discussing specific AD and RD >>>> policies. :-) >>>> >>> >>> >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >>> >>> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > --001636d3464012195604751741fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vaughn, I think I'm with you on the problems you've highlighted, al= though perhaps I'd better tick the paragraphs to be sure:

On Fri, Oct 2, 2009 at 9:44 AM, Vaughn Deluca <vaughn.deluca@gmai= l.com> wrote:
Morgaine,=A0=

I am equally worried about the problem you sketch= in the paragraph below, however, i think you put the source of that proble= m in the wrong place.=A0You argue that if only AD2 is cut out of the equati= on, all will be fine, and tourism will be possible. I wish it was true, but= even when things are fully organised as you suggested its the *trust* rela= tions that determine what will happen, let me explain:


It should be noted that I'm trying to cut AD2= out of the equation mainly because this is one of Joshua's requirement= s stemming from the original OGP scheme.=A0 If our various goals can be ach= ieved without needing to involve AD2 then all the better, since reduction o= f complexity is always a good thing, so I support Joshua in that.

As it happens, it is possible to achieve DDP using Joshua's scheme = by limiting ADs to agent policies and RDs to region policies, and therefore= I'm happy with this approach.=A0 However, I am fully aware that this d= oesn't always make tourism possible, since it still requires the cooper= ation of both worlds.=A0 A prison world will not let its inmates escape, an= d a closed society will not allow foreign visitors to enter, so just becaus= e DDP makes tourism possible=A0 doesn't mean that individual wor= ld policies will always allow it.
=A0

>[...] But instead you might mean the following: =A0= "if RD2 uses some service of type X, say X2,=A0
>then AD1 cannot provide an X service when in RD2". =A0That w= ould be extremely not cool, since=A0
>this would totally block meaningful tourism.
=A0
I = agree with this sad conclusion, i think the wording could be a lot sharper,= i will come to that below, but loosely speaking you are right. Now you mak= e the example more explicit:

> For example, RD2 could be using Asset Service AS2,= as a result=A0
> of which AD1 would not supply an asset= service to its traveling=A0
> agent A1, and= hence A1 would never be able to appear in RD2 wearing=A0
> any asset available in W1.

<= br>While this is catastrophic for interop in multi-world deployments, note = that Joshua has already accepted this and recognized that asset service con= tributions are required from both W1 and W2.=A0 Although we are still worki= ng out the details, the point is already somewhat moot because the severity= of the problem has been accepted.

Note that I offered one solution to this problem at the end of this pos= t -- http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html .= =A0 It's really simple, and boils down to asset services being provided= entirely by the RDs.=A0 RD1 provides access to the asset service AS1 (typi= cally proxy access --- after all, SL's regions already work as proxies = to an asset service, so it's no big leap), while RD2 provides access to= the asset service AS2.=A0 No AD can ever provide an asset service, and the= refore AD2 does not need to be consulted on TP.
=A0

Note that you now say "= would not supply" not "cant not provide" as you did above. T= his distinction is important. I will follow the more explicit example, sinc= e that is how things are intended IMHO. Also you seem to suggest an all or = nothing behaviour of the asset server that i feel=A0is not needed, and prob= ably not desirable.

=A0
I meant cannot p= rovide, very specifically.=A0 The reason is that my analysis stemme= d from Joshua's statement about disjointness of AS and RD servic= es.=A0 The "cannot" is a mathematical "cannot", in the = sense that if the AD and RD service sets are disjoint=A0 then the sa= me services cannot appear in both.=A0 Joshua accepted the problem and softe= ned his phrase to the funny "mostly disjoint". :D

Note that my proposal resolved this quite simply by requiring asset ser= vices to be provided only by RDs.=A0 This gives us the DDP necessary for to= urism (or potential=A0 tourism, I should say), plus it allows assets= from W1 and W2 to appear in RD2, and it does not require AD2 to be consult= ed.=A0 That seems quite a nice package deal.

=A0
>Clearly this interpretation would mean no= useful interop between=A0
>W1 and W2 at all. =A0I'm hoping this interpretation is wrong.<= /div>

It would mean no meaningful interop between = some of the involved services, and that as a result of *policy* decisions t= hat can be in *each and every case* right there where they belong. As i wil= l show below, you can not escape this situation by trying to deny AD2 any r= ole in the process. The pain is elsewhere. =A0Lets do this example a bit mo= re careful:

Our tourist is at home in W1. W1 is a container concept= for a collection of services. The agent is in fact registered in AD1, it u= ses a big collection of (purple) clothes from AS1, and is presently located= in RD1, trying to become a tourist and travel for the first time to RD2 (t= o show off its purple clothes).

AD1 talks to RD2, trying to gain access rights. RD2 has= some age restrictions, but AD1 manages to convince RD2 its agent is worthy= of entry based on some shared trust of a third party identity provider. No= role for AD2 =A0as you stipulated (although RD2 might have passed responsi= bility for this part of the process to AD2, but for clarity lets assume tha= t is not the case).

Our tourist could now enter RD2 as Ruth. Next AD1 tries= to organise the passage of the purple cloths. That transfer has two endpoi= nts, the asset service AS1, and RD2. Again RD2 might have some policy what = to allow in, and lets assume its cool with anything, purple or not. Infinit= y and Carlo looked at some alien boundary cases, but here we =A0assume RD2 = is happy with any tourism it can get, including all assets. AS1 on the othe= r hand has obligations to a large group of purple cloths makers, and will o= nly give out purple stuff to RD2 if RD2 =A0satisfies some strong conditions= . =A0It has the protocol means to test those conditions, it *could* =A0send= the purple object, but does not *want to* based on policy, in particular o= bligations towards purple clothes makers =A0and the lack of trust in the be= haviour of RD2. AS1 will however probably send any non-purple clothes to RD= 2. Cursing under its breath our tourist might go there in blue, mentally ma= king a note to find a different clothes shop next time its shopping time.


I believe that I understand your point.=A0 You ar= e describing the situation that arises when W1 policy overrides the user-ch= osen policy that the user encodes in her assets in AS1.

I agree that= this is an issue.=A0 I pointed it out here http://www.ietf.org/mail-archi= ve/web/ogpx/current/msg00433.html in answer to David's statement th= at "services are going to manage = policy, not the domains they reside in",=A0 Clearly David's statement doesn't q= uite reflect where we are at the moment with the protocol, in which domains= are totally crushing the policies of services, although of course it is st= ill early days. :-)

=A0
I completely fail to see what you would like to put in the prot= ocol, or leave out of it, to remedy this situation. =A0The would-be tourist= has only one option, and that is to find an asset server that is willing t= o give out at least the blue =A0clothes to RD2. =A0The restriction in this = example is in AS1 not willing to serve the purple clothes, and AS1 is a ser= vice that the *tourist* has picked. If that turns out to be an unlucky choi= ce and AS1 refuses to give *anything* out to RD2 as you implied in your ori= ginal example, the tourist might opt to start using an additional AS, say A= S2. If AD1 in turn =A0refuses to use AS2 next to AS1, it might really be ti= me to pack up and move world. Hence my remark (and that of several others) = that in the end interop will be a question of trust, and users will vote wi= th their feet.
In fact its not even AS1 that is the root of the problem, its the buyi= ng decision of the avatar itself. It might be have been wiser to check more= careful on the export conditions of the purple wonders.


I think that my view on this is more in tune with David.=A0 We= have made a rod for our own backs by defining domains as enforcers of poli= cy, instead of leaving policy to the services.=A0 If we had left policy to = the services then a user would be able to configure her asset service AS1 t= o allow purple clothing to enter RD2, despite the cartel operating in W1 se= eking to restrict any travel while wearing purple clothing.

In summary, i see your problem, its big and bad, but i fail to s= ee your solution. Could you go over this example and point out how things s= hould be done to prevent the blocked transfer of purple clothes? I do not t= hink that within the scope of the protocol there is a solution.

=A0
You may be right to be worri= ed.=A0 The protocol as it stands denies any possibility of such user freedo= m.=A0 Perhaps domains should be removed from the model altogether, leaving = just services.


An interesting post, Vaughn, thanks. :-)


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=A0
Looking in even more detail at the example brings up deeper= problems, like how the clothes maker is going to =A0know in what AS the pu= rple clothes will end up. But that is for later i think.

Sorry for the long mail, i will tty to be more brief in the futu= re
Vaughn

On Fri, Oct 2, 2009 at 7:52 AM, Morgaine <mo= rgaine.dinova@googlemail.com> wrote:
I agree Joshua, I= think we are converging. :-)


On Fri, Oct 2, 2009 at 12:32 AM, = Joshua Bell <josh@lindenlab.com> wrote:

On Th= u, Oct 1, 2009 at 4:13 PM, Morgaine <morgaine.dinova@googlema= il.com> wrote:
=A0
There *IS* one way of allowing the above, and that is to require that ADs carry no region-related policies at all, so that consulting only the destination RD is sufficient.=A0 This would give us a perfect Destinatio= n Determines Policy (DDP) system.=A0 The W1 resident could then TP from= RD1 to RD2 without consulting AD2 at all.
=A0
.... and so it looks like we're in agreement ...


That's a very good start then.=A0= If ADs have no region-related policies, then AD2 clearly doesn't need to be consulted when RD2 is ent= ered from RD1.


Unfortunately, you then wrote:
=A0
it should be th= e case that ADs carry policies about region services...


Is there a typo in th= at?=A0 If it's free of typos and hence ADs carry policies about region services, then clearly AD2 does have to be consulted be= fore you can TP from RD1 to RD2.=A0 (I assume it has a typo, and you actual= ly meant to write "do not carry policies about region services", to make this line consistent with what you sai= d above.)

Leaving the above to be clarified, we seem to be arriving at a = Destination Determines Policy (DDP) model which makes tourism possible,= by giving RDs control over their region-related policies so that AD2 doesn= 't need to be consulted on entry to RD2.=A0 That's fine, but it'= ;s not yet clear how you're going to achieve this since you haven't= narrowed the scope of the AD to exclude region services.

One promising angle stems from this very interesting phrase of yo= urs:

... b= y definition the AD2 and RD2 services are disjoint.

It's a bit ambiguous though:
  • If by thi= s you mean that AD1 has no say over region services in RD2, then that's= very cool! :-)=A0 (It's cool because it provides DDP and hence allows = tourism.)
  • But instead you might mean the following:=A0 "if RD2 uses = some service of type X, say X2, then AD1 cannot provide an X service when i= n RD2".=A0 That would be extremely not cool, since this would tota= lly block meaningful tourism.=A0 For example, RD2 could be using Asset Serv= ice AS2, as a result of which AD1 would not supply an asset service to its = travelling agent A1, and hence A1 would never be able to appear in RD2 wear= ing any asset available in W1.=A0 Clearly this interpretation would mean no= useful interop between W1 and W2 at all.=A0 I'm hoping this interpreta= tion is wrong.

I'd appreciate more info about the disjointness please, t= o clear up this ambiguity.


I believe I may have misread some of = your earlier posts as implying that the agent's AD was not allowed to have a say in policy decisions, only the destination RD. I have a clearer reading of your DDP statement, though, that of course it's the AD reasoning about the RD, and contrariwise the RD reasoning about the AD. If we call that "DDP&q= uot; then we're copacetic.

Ah good, I think we're starting= to talk the same language now. :-)=A0 AD1 has plenty to say in regards to = a TP from RD1 to RD2, as long as it sticks to the affairs of its own world = W1 and its own agent A1.=A0 What it cannot do is impose W1's region-rel= ated policies on W2's regions, otherwise we end up with Vaughn's &q= uot;war on purple". ;-) =A0 In other words, once in RD2, DDP applies a= nd AD1 has no say.

The DDP principle is so obvious from our experience in RL that I didn&#= 39;t bother explaining its scope, but perhaps some basic scoping is needed = to alleviate fears that the source AD has no say at all.=A0 The only thing = that DDP requires is that the travelling agent obey the law of the land on arrival in W2, namely the region-related policies that hold in RD2, and not those that would hold in a W1 homeworld region like RD= 1.=A0 It's pretty simple, and non-optional if tourism between worlds is= desired.=A0 "When in Rome, do as the Romans do" says it all.

As you say, I believe we're converging. :-)


Morgai= ne.







=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

On Fri, Oc= t 2, 2009 at 12:32 AM, Joshua Bell <josh@lindenlab.com> wro= te:
=
I think we're converging...

On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <morgaine.dinov= a@googlemail.com> wrote:
<= div>
Those are valid examples, but they're cherry picked= to support your specific use case.


Well, simplified examples. I don't beli= eve more complicated examples actually add meaningfully at a protocol level= , as will become clear...
=A0
Please examine the more general use case of two complete SL-like worlds usi= ng VWRAP, W1 and W2.=A0 They both have ADs and RDs, so let's label thos= e with 1's and 2's accordingly.

At a= protocol level, I don't think VWs exist. There are services, which we&= #39;re clustering into AD and RD. Although we may later determine there are= further subdivisions, that's our working model in the drafts. Further = drafts are strongly encouraged!
=A0
If = both ADs and RDs determine policy together (as you stated), then you can= 9;t expect a resident of W1 to TP from RD1 to RD2 without AD2's policy = coming into play, otherwise you would be subverting AD2's policy.

Here's the crux of the issue: in our model,= the provider of W2 is offering two sets of services, AD2 and RD2. There ma= y be a policy covering W2 in general, which would affect the AD2 and RD2 se= rvices. However, if an agent "from" W1, meaning the agent service= s are provided by AD1, attempts to visit RD2, then AD2 does *not* come into= play. The protocol describes the negotiation between the client, AD1 and R= D2 *only*.

(Again, this is insofar as the model in the current drafts are concerne= d. If we're missing something, please bring the conversation back to th= e drafts and point out issues and/or submit new work for discussion!)

Let me restate: even if AD2 and RD2 are governed by the same policy - p= otentially even to the point of being implemented by the same monolithic pi= ece of code! - AD2 is irrelevant *from a protocol perspective* in the attem= pt to place an agent from AD1 into AD2, since by definition the AD2 and RD2= services are disjoint.
=A0
There *IS* one way of allowing the above, and that is to require th= at ADs carry no region-related policies at all, so that consulting only the= destination RD is sufficient.=A0 This would give us a perfect Destinati= on Determines Policy (DDP) system.=A0 The W1 resident could then TP fro= m RD1 to RD2 without consulting AD2 at all.

.... and so it looks like we're in agreemen= t - if this wasn't clear, then we need to review the drafts (please, go= for it!); it should be the case that ADs carry policies about region servi= ces... except, of course, that the AD may say "hey, you can't go t= o *that* RD...".

I believe I may have misread some of your earlier posts as implying tha= t the agent's AD was not allowed to have a say in policy decisions, onl= y the destination RD. I have a clearer reading of your DDP statement, thoug= h, that of course it's the AD reasoning about the RD, and contrariwise = the RD reasoning about the AD. If we call that "DDP" then we'= re copacetic.

=A0
If you wish to define ADs in this way then we are in perfect ag= reement, since DDP is essential for interop between worlds.=A0 I am hoping = that this is what you had in mind for when we start discussing specific AD = and RD policies. :-)


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx



_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx



--001636d3464012195604751741fd-- From vaughn.deluca@gmail.com Sun Oct 4 04:20:19 2009 Return-Path: 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 4D6023A672E for ; Sun, 4 Oct 2009 04:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 hIOmjZf20v1B for ; Sun, 4 Oct 2009 04:20:18 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 8087B3A6358 for ; Sun, 4 Oct 2009 04:20:17 -0700 (PDT) Received: by bwz6 with SMTP id 6so1920881bwz.37 for ; Sun, 04 Oct 2009 04:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZFJ1TeNy5PRviQ8Z8VhnyvVX9b//qcghD1aX1WX8J1w=; b=hyI1HyRkXAWVnrJTQpTJNx3NOXGkxgpH3VBld6oPhmlM88/dl3GfKs9YVpmtYPoDNs JcAC4HJVhiYBWdTmXyJnI+XzjwYZ4zWvyWVZndsGKQz5YvVkj19qdkMoWzrpXCXF7xKq IvIQNUc1KHGNWypV1Aumrs7siWz8yrl9cPpls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X1mNe+Z1oyClaxngswy0yLXQmmhTh01VJLArweB6jFSKyeFnu4uOZhctXIn5vMCIZt JyaIFBIJ8DbfrZ2c+lQNZgQUWcog2LdSXMNFI2aJzgBdoFXWLivXTISomOWTU3P0z8zW Kzd9YmF6wzOS8m1c4HyLoAr9261OjwbSPIgug= MIME-Version: 1.0 Received: by 10.204.25.19 with SMTP id x19mr2908778bkb.189.1254655306581; Sun, 04 Oct 2009 04:21:46 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> Date: Sun, 4 Oct 2009 13:21:46 +0200 Message-ID: <9b8a8de40910040421y41314922o4c5242c77941af4c@mail.gmail.com> From: Vaughn Deluca To: "Dickson, Mike (ISS Software)" Content-Type: multipart/alternative; boundary=000325559fcedd56d704751a3318 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 11:20:19 -0000 --000325559fcedd56d704751a3318 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 4, 2009 at 2:36 AM, Dickson, Mike (ISS Software) < mike.dickson@hp.com> wrote: > The algorithm or mechanism to enforce an age related connection policy is > outside the scope of the protocol, yes. But its not at all inconceivable > that the protocol could carry age information as an attribute that an AD/RD > pair could use to make a decision as to whether a connection is to be > allowed. > > > > Mike > > I think SMTP is a very good example. An SMTP server will reject mail from untrusted sources; if I try to use the SMTP server in Domain X while logged in at domain Y it normally fails, because the SMTP server does not trust anybody but those it has information on (that might include age, real world address etc.), i.e. users from X. The age restriction is not carried explicitly in the protocol, but is coded in the source of the message. Its actually the trust relation between the SMTP server and that domain were the user is logged in that determines the SMTP protocol response. In my view this is fully analogous to the way VWRAP should deal with age restrictions or whatever other constrain. -Vaughn > > > *From:* ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] *On Behalf Of > *Morgaine > *Sent:* Saturday, October 03, 2009 6:34 PM > *To:* Carlo Wood > *Cc:* ogpx@ietf.org > *Subject:* Re: [ogpx] VWRAP Draft Charter - 2009 09 01 > > > > On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood wrote: > > On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote: > > It's important to highlight (as you did) that issues such as age > verification > > have no place in a worldwide IETF protocol standard, so while you provide > a > > good example of policy variations among worlds, any such agreements are > outside > > of the context of our protocol. > > Not entirely... age verification is necessary in many countries with > what's going on in an SL-like world. > > A RD cannot do the age-verification; that is a job for an AD. > > However, I think it's the RD that needs to make the decision whether > or not a user is allowed in (based on its age), which in turn means > that the AD has to tell the RD if it knows the age, and if so, what > it is; hence, it should be part of the protocol. > > > It's no business of an IETF protocol to deal with the age of participants. > That's like SMTP rejecting connections or mail delivery based on the ages of > the MTA operator and owner of the mail client. The whole idea is completely > ludicrous, not to mention unimplementable. > > Please let's try not to engage in what Schneier calls "security theater", a > politically correct feelgood factor that actually achieves nothing while > adding layers of red tape and complexity. > > Morgaine. > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --000325559fcedd56d704751a3318 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Oct 4, 2009 at 2:36 AM, Dickson,= Mike (ISS Software) <mike.dickson@hp.com> wrote:

The algorithm or mechanis= m to enforce an age related connection policy is outside the scope of the protocol, yes.=A0 But its not at all=A0 = inconceivable that the protocol could carry age information as an attribute that an AD/RD pair could use to make a decision as to whether a connection is to be allow= ed.

=A0

Mike

I think SMTP is a very good example. An SMTP server =A0will rej= ect mail from untrusted sources; if I try to use the SMTP server in Domain = X while logged in at domain Y it normally fails, because the SMTP server do= es not trust anybody but those it has information on (that might include ag= e, real world address etc.), i.e. users =A0from X.

The age restriction is not carried explicitly in the pr= otocol, but is coded in the source of the message. Its actually the trust r= elation between the SMTP server and that domain were the user is logged in = that determines the SMTP protocol response.

In my view this is fully analogous to the way VWRAP sho= uld deal with age restrictions or whatever other constrain.

<= /div>
-Vaughn

=A0

From: ogpx-bounces@iet= f.org [mailto:ogpx-bounces@ietf.org] On Behalf Of Morgaine
Sent: Saturday, October 03, 2009 6:34 PM
To: Carlo Wood
Cc: ogpx@ietf.org=


Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01

=A0

On Sat, Oct 3, 2009 at 11:21 PM, Carlo Wood <carlo@alinoe.com> wrote:

On Sat, Oct 03, 2009 at 10:52:18PM +0100, Morgaine wrote:
> It's important to highlight (as you did) that issues such as age verification
> have no place in a worldwide IETF protocol standard, so while you prov= ide a
> good example of policy variations among worlds, any such agreements ar= e outside
> of the context of our protocol.

Not entirely... age verification is necessary in many countries with
what's going on in an SL-like world.

A RD cannot do the age-verification; that is a job for an AD.

However, I think it's the RD that needs to make the decision whether or not a user is allowed in (based on its age), which in turn means
that the AD has to tell the RD if it knows the age, and if so, what
it is; hence, it should be part of the protocol.


It's no business of an IETF protocol to deal with the age of participants.=A0 That's like SMTP rejecting connections or mail deliver= y based on the ages of the MTA operator and owner of the mail client.=A0 The = whole idea is completely ludicrous, not to mention unimplementable.

Please let's try not to engage in what Schneier calls "security theater", a politically correct feelgood factor that actually achieves nothing while adding layers of red tape and complexity.

Morgaine.

=A0


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--000325559fcedd56d704751a3318-- From carlo@alinoe.com Sun Oct 4 06:09:14 2009 Return-Path: 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 9AAE23A68B4 for ; Sun, 4 Oct 2009 06:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 iaVTMGTjLO0t for ; Sun, 4 Oct 2009 06:09:14 -0700 (PDT) Received: from viefep12-int.chello.at (viefep12-int.chello.at [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id 5F3B83A66B4 for ; Sun, 4 Oct 2009 06:09:13 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep12-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091004131044.HHBS4394.viefep12-int.chello.at@edge05.upc.biz>; Sun, 4 Oct 2009 15:10:44 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id odAi1c03U0FlQed05dAjPB; Sun, 04 Oct 2009 15:10:44 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MuQsT-0007zJ-0e; Sun, 04 Oct 2009 15:11:53 +0200 Date: Sun, 4 Oct 2009 15:11:53 +0200 From: Carlo Wood To: Morgaine Message-ID: <20091004131153.GA29765@alinoe.com> References: <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <9b8a8de40910020144v36077295u314d34d579e21f26@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 13:09:14 -0000 On Sun, Oct 04, 2009 at 08:50:43AM +0100, Morgaine wrote: > Note that I offered one solution to this problem at the end of this post -- > http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html . It's really > simple, and boils down to asset services being provided entirely by the RDs. > RD1 provides access to the asset service AS1 (typically proxy access --- after > all, SL's regions already work as proxies to an asset service, so it's no big > leap), while RD2 provides access to the asset service AS2. No AD can ever > provide an asset service, and therefore AD2 does not need to be consulted on > TP. Your phrase "RD1 provides access to the asset service AS1" is slightly misleading... It should read: "RD1 provides (proxy) access to all asset services involved". For example, three users visit RD1, they respectively use AS1, AS2 and AS3. Then in order to see what they wear (or rezzed) all three asset servers need to be accessed. -- Carlo Wood From vaughn.deluca@gmail.com Sun Oct 4 06:57:49 2009 Return-Path: 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 47BDE3A695D for ; Sun, 4 Oct 2009 06:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 xbihzMKTYq1j for ; Sun, 4 Oct 2009 06:57:45 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id C28A63A6965 for ; Sun, 4 Oct 2009 06:57:44 -0700 (PDT) Received: by fxm28 with SMTP id 28so2131049fxm.42 for ; Sun, 04 Oct 2009 06:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ejypWUBNum5sCQH7O4YMy6MuMpSTMOSh18lx029mRP0=; b=Z+FYQ5/cYvXjzamVuYs+OGpnnhP57B29xMhbU7VozEfkuc70GMA347MH8OLVtuvH5N 8MK0Qe+4IZ6tOXx3ALXKAjxr2BSov9PP3yHNuZg7AtLiI+yx2RpO0jHfKhHBu8UV6qTE o+tjZsryg6oqt2jRNoM+FRpUG/XYbfr7usIPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZlXqRISI7GovO3KXd9Zh+16SragjI3mLiiYypi9JtUl/z1jBI+sRS5ImCea27xhi5H 68A7xlq6eAv5gXEkXKUIjcMt2PhSdXcWzMuLkOwg60mao9vQEXcPJdTL10qS7jAWRjBO oybdET6nmWXOZtiwC1s3FIfZlzG4ON190c/mU= MIME-Version: 1.0 Received: by 10.204.33.7 with SMTP id f7mr2994497bkd.123.1254664752661; Sun, 04 Oct 2009 06:59:12 -0700 (PDT) In-Reply-To: References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <9b8a8de40910020144v36077295u314d34d579e21f26@mail.gmail.com> Date: Sun, 4 Oct 2009 15:59:12 +0200 Message-ID: <9b8a8de40910040659r54d26527wd641b6a175a68d0c@mail.gmail.com> From: Vaughn Deluca To: Morgaine Content-Type: multipart/alternative; boundary=00032555a282e5060b04751c6694 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 13:57:49 -0000 --00032555a282e5060b04751c6694 Content-Type: text/plain; charset=ISO-8859-1 Morgaine, >We have made a rod for our own backs by defining domains as enforcers of policy, instead of leaving > policy to the services. I see domains merely as a convenience making it easier to organise things. Indeed as David says, the service will ultimately enforce the policy, yet if a service is deployed within the domain you might as well say the domain enforces the policy by *picking* this particular service. Its just wordplay. > If we had left policy to the services then a user would be able to configure her >asset service AS1 to allow purple clothing to enter RD2, despite the cartel operating in W1 seeking to >restrict any travel while wearing purple clothing. I do not like the way you frame the situation here. I am interested in my own freedom to experience a unified virtual world, irrespective of the underlaying ownership of services. I have no objection against people running their own worlds in the way they like. The word "cartel" implies that i have no other options, and are forced to use something i don't like. The protocol should give me the freedom to do things the way i do like. Yet, I can *not* demand control over resources i do not own. If i take residence in W1 (better: if i subscribe to AD1) that does not give me any right to configure asset services used by AD1. I might expect however that AS1 will give me back anything i trusted it with. But if i put object in AS1 that carry export restrictions, i know AS1 will under certain conditions refuse to send that object outside its jurisdiction. Nothing wrong with that. Its *my* choice to put the object in AS1. I do expect however that AS1 will allow me to take to RD2 anything that carries *no* restrictions. If AS1 is not flexible enough to determine what it can give out to RD2 and what not, and therefore refuses to give out anything to RD2, i would be disappointed, and feel compelled to store all my stuff in AS2, that acts more intelligent (Alas, I will not be able to put my purple clothes in AS2, because the maker does not want to sell to me if i don't put them in AS1 first and AS1 does not want to give them out to AS2). I would certainly expect that when I am in AD1/RD1 I can get access to AS2 were i have a lot of other stuff, and in this way prevent the need to copy or move everything from AS2 to AS1 before i try to use it in RD1. My conclusion is the protocol should allow me to contact *any* AS i choose. But it is up to RD1 to decide if it wants to accept stuff from my chosen AS (that's your DDP). If RD1 has a policy that prevent me from rezzing anything but objects from AS1, and AS1 insists on giving objects only to RD1, well thats fine, but i am not going to live in such a world. It might mean though i have to stop wearing the nice purple clothes only sold in RD1, (or more precise, only sold if placed in AS1). But regarding the protocol, the important question is if it allows me access to AS2 when in AD1. As soon as that is the case, i have my freedom. > > In summary, i see your problem, its big and bad, but i fail to see your > solution. Could you go over this example and point out how things should be > done to prevent the blocked transfer of purple clothes? I do not think that > within the scope of the protocol there is a solution. > > >You may be right to be worried. The protocol as it stands denies any possibility of such user freedom. >Perhaps domains should be removed from the model altogether, leaving just services. I should have been more clear, i meant to say that i don't see how *any* protocol change can solve this problem since we are actually discussing trust and rights issues. Doing away with domains will not help. So probably its wrong to call it a "problem" in the sense that it needs solving before we can proceed. That is not the case. We should focus on the *possibility* to use external services when in a particular domain, and i feel confident there are very workable solutions for that, that will make all parties happy. -Vaughn On Sun, Oct 4, 2009 at 9:50 AM, Morgaine wrote: > Vaughn, I think I'm with you on the problems you've highlighted, although > perhaps I'd better tick the paragraphs to be sure: > > On Fri, Oct 2, 2009 at 9:44 AM, Vaughn Deluca wrote: > >> Morgaine, >> >> I am equally worried about the problem you sketch in the paragraph below, >> however, i think you put the source of that problem in the wrong place. You >> argue that if only AD2 is cut out of the equation, all will be fine, and >> tourism will be possible. I wish it was true, but even when things are fully >> organised as you suggested its the *trust* relations that determine what >> will happen, let me explain: >> > > > It should be noted that I'm trying to cut AD2 out of the equation mainly > because this is one of Joshua's requirements stemming from the original OGP > scheme. If our various goals can be achieved without needing to involve AD2 > then all the better, since reduction of complexity is always a good thing, > so I support Joshua in that. > > As it happens, it is possible to achieve DDP using Joshua's scheme by > limiting ADs to agent policies and RDs to region policies, and therefore I'm > happy with this approach. However, I am fully aware that this doesn't > always make tourism possible, since it still requires the cooperation of > both worlds. A prison world will not let its inmates escape, and a closed > society will not allow foreign visitors to enter, so just because DDP makes > tourism *possible* doesn't mean that individual world policies will > always allow it. > > >> >> >[...] But instead you might mean the following: "if RD2 uses some >> service of type X, say X2, >> >then AD1 cannot provide an X service when in RD2". That would be >> extremely not cool, since >> >this would totally block meaningful tourism. >> >> > I agree with this sad conclusion, i think the wording could be a lot >> sharper, i will come to that below, but loosely speaking you are right. Now >> you make the example more explicit: >> >> > For example, RD2 could be using Asset Service AS2, as a result >> > of which AD1 would not supply an asset service to its traveling >> > agent A1, and hence A1 would never be able to appear in RD2 wearing >> > any asset available in W1. >> > > > While this is catastrophic for interop in multi-world deployments, note > that Joshua has already accepted this and recognized that asset service > contributions are required from both W1 and W2. Although we are still > working out the details, the point is already somewhat moot because the > severity of the problem has been accepted. > > Note that I offered one solution to this problem at the end of this post -- > http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html . It's > really simple, and boils down to asset services being provided entirely by > the RDs. RD1 provides access to the asset service AS1 (typically proxy > access --- after all, SL's regions already work as proxies to an asset > service, so it's no big leap), while RD2 provides access to the asset > service AS2. No AD can ever provide an asset service, and therefore AD2 > does not need to be consulted on TP. > > >> >> Note that you now say "would not supply" not "cant not provide" as you did >> above. This distinction is important. I will follow the more explicit >> example, since that is how things are intended IMHO. Also you seem to >> suggest an all or nothing behaviour of the asset server that i feel is not >> needed, and probably not desirable. >> >> > I meant *cannot provide*, very specifically. The reason is that my > analysis stemmed from Joshua's statement about *disjointness* of AS and RD > services. The "cannot" is a mathematical "cannot", in the sense that if the > AD and RD service sets are *disjoint* then the same services cannot > appear in both. Joshua accepted the problem and softened his phrase to the > funny "mostly disjoint". :D > > Note that my proposal resolved this quite simply by requiring asset > services to be provided only by RDs. This gives us the DDP necessary for > tourism (or *potential* tourism, I should say), plus it allows assets > from W1 and W2 to appear in RD2, and it does not require AD2 to be > consulted. That seems quite a nice package deal. > > > >> >Clearly this interpretation would mean no useful interop between >> >W1 and W2 at all. I'm hoping this interpretation is wrong. >> >> It would mean no meaningful interop between some of the involved services, >> and that as a result of *policy* decisions that can be in *each and every >> case* right there where they belong. As i will show below, you can not >> escape this situation by trying to deny AD2 any role in the process. The >> pain is elsewhere. Lets do this example a bit more careful: >> >> Our tourist is at home in W1. W1 is a container concept for a collection >> of services. The agent is in fact registered in AD1, it uses a big >> collection of (purple) clothes from AS1, and is presently located in RD1, >> trying to become a tourist and travel for the first time to RD2 (to show off >> its purple clothes). >> >> AD1 talks to RD2, trying to gain access rights. RD2 has some age >> restrictions, but AD1 manages to convince RD2 its agent is worthy of entry >> based on some shared trust of a third party identity provider. No role for >> AD2 as you stipulated (although RD2 might have passed responsibility for >> this part of the process to AD2, but for clarity lets assume that is not the >> case). >> >> Our tourist could now enter RD2 as Ruth. Next AD1 tries to organise the >> passage of the purple cloths. That transfer has two endpoints, the asset >> service AS1, and RD2. Again RD2 might have some policy what to allow in, and >> lets assume its cool with anything, purple or not. Infinity and Carlo looked >> at some alien boundary cases, but here we assume RD2 is happy with any >> tourism it can get, including all assets. AS1 on the other hand has >> obligations to a large group of purple cloths makers, and will only give out >> purple stuff to RD2 if RD2 satisfies some strong conditions. It has the >> protocol means to test those conditions, it *could* send the purple object, >> but does not *want to* based on policy, in particular obligations towards >> purple clothes makers and the lack of trust in the behaviour of RD2. AS1 >> will however probably send any non-purple clothes to RD2. Cursing under its >> breath our tourist might go there in blue, mentally making a note to find a >> different clothes shop next time its shopping time. >> > > > I believe that I understand your point. You are describing the situation > that arises when W1 policy overrides the user-chosen policy that the user > encodes in her assets in AS1. > > I agree that this is an issue. I pointed it out here > http://www.ietf.org/mail-archive/web/ogpx/current/msg00433.html in answer > to David's statement that "services are going to manage policy, not the > domains they reside in", Clearly David's statement doesn't quite reflect > where we are at the moment with the protocol, in which domains are totally > crushing the policies of services, although of course it is still early > days. :-) > > > >> I completely fail to see what you would like to put in the protocol, or >> leave out of it, to remedy this situation. The would-be tourist has only >> one option, and that is to find an asset server that is willing to give out >> at least the blue clothes to RD2. The restriction in this example is in >> AS1 not willing to serve the purple clothes, and AS1 is a service that the >> *tourist* has picked. If that turns out to be an unlucky choice and AS1 >> refuses to give *anything* out to RD2 as you implied in your original >> example, the tourist might opt to start using an additional AS, say AS2. If >> AD1 in turn refuses to use AS2 next to AS1, it might really be time to pack >> up and move world. Hence my remark (and that of several others) that in the >> end interop will be a question of trust, and users will vote with their >> feet. >> In fact its not even AS1 that is the root of the problem, its the buying >> decision of the avatar itself. It might be have been wiser to check more >> careful on the export conditions of the purple wonders. >> > > > I think that my view on this is more in tune with David. We have made a > rod for our own backs by defining domains as enforcers of policy, instead of > leaving policy to the services. If we had left policy to the services then > a user would be able to configure her asset service AS1 to allow purple > clothing to enter RD2, despite the cartel operating in W1 seeking to > restrict any travel while wearing purple clothing. > > >> In summary, i see your problem, its big and bad, but i fail to see your >> solution. Could you go over this example and point out how things should be >> done to prevent the blocked transfer of purple clothes? I do not think that >> within the scope of the protocol there is a solution. >> >> > You may be right to be worried. The protocol as it stands denies any > possibility of such user freedom. Perhaps domains should be removed from > the model altogether, leaving just services. > > > An interesting post, Vaughn, thanks. :-) > > > Morgaine. > > > > > ================================= > > > >> Looking in even more detail at the example brings up deeper problems, like >> how the clothes maker is going to know in what AS the purple clothes will >> end up. But that is for later i think. >> >> Sorry for the long mail, i will tty to be more brief in the future >> Vaughn >> >> On Fri, Oct 2, 2009 at 7:52 AM, Morgaine wrote: >> >>> I agree Joshua, I think we are converging. :-) >>> >>> On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell wrote: >>> >>>> >>>> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine < >>>> morgaine.dinova@googlemail.com> wrote: >>>> >>>> >>>>> There *IS* one way of allowing the above, and that is to require that >>>>> ADs carry no region-related policies at all, so that consulting only the >>>>> destination RD is sufficient. This would give us a perfect *Destination >>>>> Determines Policy* (DDP) system. The W1 resident could then TP from >>>>> RD1 to RD2 without consulting AD2 at all. >>>>> >>>> >>> .... and so it looks like we're in agreement ... >>> >>> >>> That's a very good start then. If ADs have no region-related policies, >>> then AD2 clearly doesn't need to be consulted when RD2 is entered from RD1. >>> >>> Unfortunately, you then wrote: >>> >>> it should be the case that ADs carry policies about region services... >>> >>> >>> Is there a typo in that? If it's free of typos and hence ADs carry >>> policies about region services, then clearly AD2 *does* have to be >>> consulted before you can TP from RD1 to RD2. (I assume it has a typo, and >>> you actually meant to write "do *not* carry policies about region >>> services", to make this line consistent with what you said above.) >>> >>> Leaving the above to be clarified, we seem to be arriving at a *Destination >>> Determines Policy* (DDP) model which makes tourism possible, by giving >>> RDs control over their region-related policies so that AD2 doesn't need to >>> be consulted on entry to RD2. That's fine, but it's not yet clear how >>> you're going to achieve this since you haven't narrowed the scope of the AD >>> to exclude region services. >>> >>> One promising angle stems from this very interesting phrase of yours: >>> >>> ... by definition the AD2 and RD2 services are disjoint. >>>> >>> >>> It's a bit ambiguous though: >>> >>> - If by this you mean that AD1 has no say over region services in >>> RD2, then that's very cool! :-) (It's cool because it provides DDP and >>> hence allows tourism.) >>> - But instead you might mean the following: "*if RD2 uses some >>> service of type X, say X2, then AD1 cannot provide an X service when in RD2" >>> *. That would be extremely not cool, since this would totally block >>> meaningful tourism. For example, RD2 could be using Asset Service AS2, as a >>> result of which AD1 would not supply an asset service to its travelling >>> agent A1, and hence A1 would never be able to appear in RD2 wearing any >>> asset available in W1. Clearly this interpretation would mean no useful >>> interop between W1 and W2 at all. I'm hoping this interpretation is wrong. >>> >>> >>> I'd appreciate more info about the disjointness please, to clear up this >>> ambiguity. >>> >>>> >>>> >>>> I believe I may have misread some of your earlier posts as implying that >>>> the agent's AD was not allowed to have a say in policy decisions, only the >>>> destination RD. I have a clearer reading of your DDP statement, though, that >>>> of course it's the AD reasoning about the RD, and contrariwise the RD >>>> reasoning about the AD. If we call that "DDP" then we're copacetic. >>>> >>>> Ah good, I think we're starting to talk the same language now. :-) AD1 >>> has plenty to say in regards to a TP from RD1 to RD2, as long as it sticks >>> to the affairs of its own world W1 and its own agent A1. What it cannot do >>> is impose W1's region-related policies on W2's regions, otherwise we end up >>> with Vaughn's "war on purple". ;-) In other words, once in RD2, DDP >>> applies and AD1 has no say. >>> >>> The DDP principle is so obvious from our experience in RL that I didn't >>> bother explaining its scope, but perhaps some basic scoping is needed to >>> alleviate fears that the source AD has no say at all. The only thing that >>> DDP requires is that the travelling agent *obey the law of the land* on >>> arrival in W2, namely the region-related policies that hold in RD2, and not >>> those that would hold in a W1 homeworld region like RD1. It's pretty >>> simple, and non-optional if tourism between worlds is desired. "When in >>> Rome, do as the Romans do" says it all. >>> >>> As you say, I believe we're converging. :-) >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> >>> >>> ========================================= >>> >>> On Fri, Oct 2, 2009 at 12:32 AM, Joshua Bell wrote: >>> >>>> I think we're converging... >>>> >>>> On Thu, Oct 1, 2009 at 4:13 PM, Morgaine < >>>> morgaine.dinova@googlemail.com> wrote: >>>> >>>>> >>>>> Those are valid examples, but they're cherry picked to support your >>>>> specific use case. >>>>> >>>>> >>>> Well, simplified examples. I don't believe more complicated examples >>>> actually add meaningfully at a protocol level, as will become clear... >>>> >>>> >>>>> Please examine the more general use case of two complete SL-like worlds >>>>> using VWRAP, W1 and W2. They both have ADs and RDs, so let's label those >>>>> with 1's and 2's accordingly. >>>>> >>>> >>>> At a protocol level, I don't think VWs exist. There are services, which >>>> we're clustering into AD and RD. Although we may later determine there are >>>> further subdivisions, that's our working model in the drafts. Further drafts >>>> are strongly encouraged! >>>> >>>> >>>>> If both ADs and RDs determine policy together (as you stated), then you >>>>> can't expect a resident of W1 to TP from RD1 to RD2 without AD2's policy >>>>> coming into play, otherwise you would be subverting AD2's policy. >>>>> >>>> >>>> Here's the crux of the issue: in our model, the provider of W2 is >>>> offering two sets of services, AD2 and RD2. There may be a policy covering >>>> W2 in general, which would affect the AD2 and RD2 services. However, if an >>>> agent "from" W1, meaning the agent services are provided by AD1, attempts to >>>> visit RD2, then AD2 does *not* come into play. The protocol describes the >>>> negotiation between the client, AD1 and RD2 *only*. >>>> >>>> (Again, this is insofar as the model in the current drafts are >>>> concerned. If we're missing something, please bring the conversation back to >>>> the drafts and point out issues and/or submit new work for discussion!) >>>> >>>> Let me restate: even if AD2 and RD2 are governed by the same policy - >>>> potentially even to the point of being implemented by the same monolithic >>>> piece of code! - AD2 is irrelevant *from a protocol perspective* in the >>>> attempt to place an agent from AD1 into AD2, since by definition the AD2 and >>>> RD2 services are disjoint. >>>> >>>> >>>>> There *IS* one way of allowing the above, and that is to require that >>>>> ADs carry no region-related policies at all, so that consulting only the >>>>> destination RD is sufficient. This would give us a perfect *Destination >>>>> Determines Policy* (DDP) system. The W1 resident could then TP from >>>>> RD1 to RD2 without consulting AD2 at all. >>>>> >>>> >>>> .... and so it looks like we're in agreement - if this wasn't clear, >>>> then we need to review the drafts (please, go for it!); it should be the >>>> case that ADs carry policies about region services... except, of course, >>>> that the AD may say "hey, you can't go to *that* RD...". >>>> >>>> I believe I may have misread some of your earlier posts as implying that >>>> the agent's AD was not allowed to have a say in policy decisions, only the >>>> destination RD. I have a clearer reading of your DDP statement, though, that >>>> of course it's the AD reasoning about the RD, and contrariwise the RD >>>> reasoning about the AD. If we call that "DDP" then we're copacetic. >>>> >>>> >>>> >>>>> If you wish to define ADs in this way then we are in perfect agreement, >>>>> since DDP is essential for interop between worlds. I am hoping that this is >>>>> what you had in mind for when we start discussing specific AD and RD >>>>> policies. :-) >>>>> >>>> >>>> >>>> _______________________________________________ >>>> ogpx mailing list >>>> ogpx@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ogpx >>>> >>>> >>> >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >>> >>> >> > --00032555a282e5060b04751c6694 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Morgaine,

>We have made a rod for our own back= s by defining domains as enforcers of policy, instead of leaving
= > policy to the services.=A0

I see domains merely as a convenience making it easier = to organise things. Indeed as David says, the service will ultimately enfor= ce the policy, yet if a service is deployed within the domain you might as = well say the domain enforces the policy by *picking* this particular servic= e. Its just wordplay.

>=A0If we had left policy to the services then a use= r would be able to configure her=A0
>asset service AS1 to allo= w purple clothing to enter RD2, despite the cartel operating in W1 seeking = to=A0
>restrict any travel while wearing purple clothing.

I do not like the way you frame the situation here. I am in= terested in my own freedom to experience a unified virtual world, irrespect= ive of the underlaying ownership of services. I have no objection against p= eople running their own worlds in the way they like. The word "cartel&= quot; implies that =A0i have no other options, and =A0are forced to use som= ething i don't like. The protocol should give me the freedom to do thin= gs the way i do like. Yet, I can *not* demand control over resources i do n= ot own. If i take residence in W1=A0(better: if i subscribe to AD1) that do= es not give me any right to configure asset services used by AD1.=A0

I might expect however that AS1 will give me back anyth= ing i trusted it with. But if i put object in AS1 that carry export restric= tions, i know AS1 will under certain conditions refuse to send that object = outside its jurisdiction. Nothing wrong with that. Its *my* choice to put t= he object in AS1.

I do expect however that AS1 will allow me to take to R= D2 anything that carries *no* restrictions. If AS1 is not flexible enough t= o determine what it can give out to RD2 and what not, and therefore refuses= to give out anything to RD2, i would be disappointed, and feel compelled t= o store all my stuff in AS2, that acts more intelligent (Alas, I will not b= e able to put my purple clothes in AS2, because the maker does not want to = sell to me if i don't put them in AS1 first and AS1 does not want to gi= ve them out to AS2). =A0I would certainly expect that when I am in AD1/RD1 = I can get access to AS2 were i have a lot of other =A0stuff, and in this wa= y prevent the need to copy or move everything from AS2 to AS1 before i try = to use it in RD1.

My conclusion is the protocol should allow me to contac= t =A0*any* AS i choose. But it is up to RD1 to decide if it wants to accept= stuff from my chosen AS (that's your DDP). If RD1 has a policy that pr= event me from rezzing anything =A0but objects from AS1, and AS1 insists on = giving objects only to RD1, well thats fine, but i am not going to live in = such a world. It might mean though i have to stop wearing the nice purple c= lothes only sold in RD1, =A0(or more precise, only sold if placed in AS1). = But regarding the protocol, the important question is if it allows me acces= s to AS2 when in AD1. As soon as that is the case, i have my freedom.

In summary, i see your problem, its big and bad, but i = fail to see your solution. Could you go over this example and point out how= things should be done to prevent the blocked transfer of purple clothes? I= do not think that within the scope of the protocol there is a solution.

=A0
>You may be right t= o be worried.=A0 The protocol as it stands denies any possibility of such u= ser freedom.=A0=A0
>Perhaps domains should be removed from the= model altogether, leaving just services.

I should have been more clear, i meant to say tha= t i don't see how *any* protocol =A0change can solve this problem since= we are actually discussing trust and rights issues. Doing away with domain= s will not help. So probably its wrong to call it a "problem" in = the sense that it needs solving before we can proceed. That is not the case= . We should focus on the *possibility* to use external services when in a p= articular domain, and i feel confident there are very workable solutions fo= r that, that will make all parties happy.

-Vaughn

On S= un, Oct 4, 2009 at 9:50 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Vaughn, I think I'm with you on the pro= blems you've highlighted, although perhaps I'd better tick the para= graphs to be sure:

On Fri, Oct 2, 2009 at 9:4= 4 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
Morgaine,=A0
=

I am equally worried about the problem you sketch in th= e paragraph below, however, i think you put the source of that problem in t= he wrong place.=A0You argue that if only AD2 is cut out of the equation, al= l will be fine, and tourism will be possible. I wish it was true, but even = when things are fully organised as you suggested its the *trust* relations = that determine what will happen, let me explain:


It should be noted that I'm trying to c= ut AD2 out of the equation mainly because this is one of Joshua's requi= rements stemming from the original OGP scheme.=A0 If our various goals can = be achieved without needing to involve AD2 then all the better, since reduc= tion of complexity is always a good thing, so I support Joshua in that.

As it happens, it is possible to achieve DDP using Joshua's scheme = by limiting ADs to agent policies and RDs to region policies, and therefore= I'm happy with this approach.=A0 However, I am fully aware that this d= oesn't always make tourism possible, since it still requires the cooper= ation of both worlds.=A0 A prison world will not let its inmates escape, an= d a closed society will not allow foreign visitors to enter, so just becaus= e DDP makes tourism possible=A0 doesn't mean that individual wor= ld policies will always allow it.
=A0

>[...] But instead you might mean the following: =A0= "if RD2 uses some service of type X, say X2,=A0
>the= n AD1 cannot provide an X service when in RD2". =A0That would be extre= mely not cool, since=A0
>this would totally block meaningful tourism.
=A0
I agree = with this sad conclusion, i think the wording could be a lot sharper, i wil= l come to that below, but loosely speaking you are right. Now you make the = example more explicit:

> For example, RD2 could be using Asset Service AS2,= as a result=A0
> of which AD1 would not supply an asset= service to its traveling=A0
> agent A1, and hence A1 wou= ld never be able to appear in RD2 wearing=A0
> any asset available in W1.


While this is catastrophic for interop in multi-world deployments,= note that Joshua has already accepted this and recognized that asset servi= ce contributions are required from both W1 and W2.=A0 Although we are still= working out the details, the point is already somewhat moot because the se= verity of the problem has been accepted.

Note that I offered one solution to this problem at the end of this pos= t -- http://www.ietf.org/mail-archive/web/ogpx/current/m= sg00451.html .=A0 It's really simple, and boils down to asset servi= ces being provided entirely by the RDs.=A0 RD1 provides access to the asset= service AS1 (typically proxy access --- after all, SL's regions alread= y work as proxies to an asset service, so it's no big leap), while RD2 = provides access to the asset service AS2.=A0 No AD can ever provide an asse= t service, and therefore AD2 does not need to be consulted on TP.
=A0

Note that you now say "w= ould not supply" not "cant not provide" as you did above. Th= is distinction is important. I will follow the more explicit example, since= that is how things are intended IMHO. Also you seem to suggest an all or n= othing behaviour of the asset server that i feel=A0is not needed, and proba= bly not desirable.

=A0
I meant ca= nnot provide, very specifically.=A0 The reason is that my analysis = stemmed from Joshua's statement about disjointness of AS and RD = services.=A0 The "cannot" is a mathematical "cannot", i= n the sense that if the AD and RD service sets are disjoint=A0 then = the same services cannot appear in both.=A0 Joshua accepted the problem and= softened his phrase to the funny "mostly disjoint". :D

Note that my proposal resolved this quite simply by requiring asset ser= vices to be provided only by RDs.=A0 This gives us the DDP necessary for to= urism (or potential=A0 tourism, I should say), plus it allows assets= from W1 and W2 to appear in RD2, and it does not require AD2 to be consult= ed.=A0 That seems quite a nice package deal.

=A0
>Clearly this interpretation would mean no = useful interop between=A0
>W1 and W2 at all. =A0I'm hoping this interpretation is wrong.<= /div>

It would mean no meaningful interop between = some of the involved services, and that as a result of *policy* decisions t= hat can be in *each and every case* right there where they belong. As i wil= l show below, you can not escape this situation by trying to deny AD2 any r= ole in the process. The pain is elsewhere. =A0Lets do this example a bit mo= re careful:

Our tourist is at home in W1. W1 is a container concept= for a collection of services. The agent is in fact registered in AD1, it u= ses a big collection of (purple) clothes from AS1, and is presently located= in RD1, trying to become a tourist and travel for the first time to RD2 (t= o show off its purple clothes).

AD1 talks to RD2, trying to gain access rights. RD2 has= some age restrictions, but AD1 manages to convince RD2 its agent is worthy= of entry based on some shared trust of a third party identity provider. No= role for AD2 =A0as you stipulated (although RD2 might have passed responsi= bility for this part of the process to AD2, but for clarity lets assume tha= t is not the case).

Our tourist could now enter RD2 as Ruth. Next AD1 tries= to organise the passage of the purple cloths. That transfer has two endpoi= nts, the asset service AS1, and RD2. Again RD2 might have some policy what = to allow in, and lets assume its cool with anything, purple or not. Infinit= y and Carlo looked at some alien boundary cases, but here we =A0assume RD2 = is happy with any tourism it can get, including all assets. AS1 on the othe= r hand has obligations to a large group of purple cloths makers, and will o= nly give out purple stuff to RD2 if RD2 =A0satisfies some strong conditions= . =A0It has the protocol means to test those conditions, it *could* =A0send= the purple object, but does not *want to* based on policy, in particular o= bligations towards purple clothes makers =A0and the lack of trust in the be= haviour of RD2. AS1 will however probably send any non-purple clothes to RD= 2. Cursing under its breath our tourist might go there in blue, mentally ma= king a note to find a different clothes shop next time its shopping time.


I believe that I understand your point.=A0 = You are describing the situation that arises when W1 policy overrides the u= ser-chosen policy that the user encodes in her assets in AS1.

I agre= e that this is an issue.=A0 I pointed it out here http:/= /www.ietf.org/mail-archive/web/ogpx/current/msg00433.html in answer to = David's statement that "servi= ces are going to manage policy, not the domains they reside in",=A0 Clearly David's statement doesn't q= uite reflect where we are at the moment with the protocol, in which domains= are totally crushing the policies of services, although of course it is st= ill early days. :-)

=A0
I completely fail to see what you would like to put= in the protocol, or leave out of it, to remedy this situation. =A0The woul= d-be tourist has only one option, and that is to find an asset server that = is willing to give out at least the blue =A0clothes to RD2. =A0The restrict= ion in this example is in AS1 not willing to serve the purple clothes, and = AS1 is a service that the *tourist* has picked. If that turns out to be an = unlucky choice and AS1 refuses to give *anything* out to RD2 as you implied= in your original example, the tourist might opt to start using an addition= al AS, say AS2. If AD1 in turn =A0refuses to use AS2 next to AS1, it might = really be time to pack up and move world. Hence my remark (and that of seve= ral others) that in the end interop will be a question of trust, and users = will vote with their feet.
In fact its not even AS1 that is the root of the problem, its the buyi= ng decision of the avatar itself. It might be have been wiser to check more= careful on the export conditions of the purple wonders.


I think that my view on this is more in tune with David.= =A0 We have made a rod for our own backs by defining domains as enforcers o= f policy, instead of leaving policy to the services.=A0 If we had left poli= cy to the services then a user would be able to configure her asset service= AS1 to allow purple clothing to enter RD2, despite the cartel operating in= W1 seeking to restrict any travel while wearing purple clothing.


In summary, i see your problem, its big and bad, but i fail to s= ee your solution. Could you go over this example and point out how things s= hould be done to prevent the blocked transfer of purple clothes? I do not t= hink that within the scope of the protocol there is a solution.

=A0
You may be right to be= worried.=A0 The protocol as it stands denies any possibility of such user = freedom.=A0 Perhaps domains should be removed from the model altogether, le= aving just services.


An interesting post, Vaughn, thanks. :-)


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=A0<= /font>
Looking in even more detail at the example brings up deeper= problems, like how the clothes maker is going to =A0know in what AS the pu= rple clothes will end up. But that is for later i think.

Sorry for the long mail, i will tty to be more brief in the futu= re
Vaughn

On Fri, Oct 2, 2009 at 7:52 AM, Morgaine <morgaine.dinova@g= ooglemail.com> wrote:
I agree Joshua, I think= we are converging. :-)


On Fri, Oct 2, 2009 at 12:32 AM, Joshua= Bell <josh@lindenlab.com> wrote:

On Thu,= Oct 1, 2009 at 4:13 PM, Morgaine <morgaine.dinova@googlemail= .com> wrote:
=A0
There *IS* one way of allowing the above, and that is to require that ADs carry no region-related policies at all, so that consulting only the destination RD is sufficient.=A0 This would give us a perfect Destinatio= n Determines Policy (DDP) system.=A0 The W1 resident could then TP from= RD1 to RD2 without consulting AD2 at all.
=A0
.... and so it looks like we're in agreement ...


That's a very good start then.=A0= If ADs have no region-related policies, then AD2 clearly doesn't need to be consulted when RD2 is ent= ered from RD1.


Unfortunately, you then wrote:
=A0
it should be the = case that ADs carry policies about region services...


Is there a typo in th= at?=A0 If it's free of typos and hence ADs carry policies about region services, then clearly AD2 does have to be consulted be= fore you can TP from RD1 to RD2.=A0 (I assume it has a typo, and you actual= ly meant to write "do not carry policies about region services", to make this line consistent with what you sai= d above.)

Leaving the above to be clarified, we seem to be arriving at a = Destination Determines Policy (DDP) model which makes tourism possible,= by giving RDs control over their region-related policies so that AD2 doesn= 't need to be consulted on entry to RD2.=A0 That's fine, but it'= ;s not yet clear how you're going to achieve this since you haven't= narrowed the scope of the AD to exclude region services.

One promising angle stems from this very interesting phrase of yo= urs:

... by defi= nition the AD2 and RD2 services are disjoint.

It's a bit ambiguous though:
  • If by thi= s you mean that AD1 has no say over region services in RD2, then that's= very cool! :-)=A0 (It's cool because it provides DDP and hence allows = tourism.)
  • But instead you might mean the following:=A0 "if RD2 uses = some service of type X, say X2, then AD1 cannot provide an X service when i= n RD2".=A0 That would be extremely not cool, since this would tota= lly block meaningful tourism.=A0 For example, RD2 could be using Asset Serv= ice AS2, as a result of which AD1 would not supply an asset service to its = travelling agent A1, and hence A1 would never be able to appear in RD2 wear= ing any asset available in W1.=A0 Clearly this interpretation would mean no= useful interop between W1 and W2 at all.=A0 I'm hoping this interpreta= tion is wrong.

I'd appreciate more info about the disjointness please, t= o clear up this ambiguity.


I believe I may have misread some of yo= ur earlier posts as implying that the agent's AD was not allowed to have a say in policy decisions, only the destination RD. I have a clearer reading of your DDP statement, though, that of course it's the AD reasoning about the RD, and contrariwise the RD reasoning about the AD. If we call that "DDP&q= uot; then we're copacetic.

Ah good, I think we're starting= to talk the same language now. :-)=A0 AD1 has plenty to say in regards to = a TP from RD1 to RD2, as long as it sticks to the affairs of its own world = W1 and its own agent A1.=A0 What it cannot do is impose W1's region-rel= ated policies on W2's regions, otherwise we end up with Vaughn's &q= uot;war on purple". ;-) =A0 In other words, once in RD2, DDP applies a= nd AD1 has no say.

The DDP principle is so obvious from our experience in RL that I didn&#= 39;t bother explaining its scope, but perhaps some basic scoping is needed = to alleviate fears that the source AD has no say at all.=A0 The only thing = that DDP requires is that the travelling agent obey the law of the land on arrival in W2, namely the region-related policies that hold in RD2, and not those that would hold in a W1 homeworld region like RD= 1.=A0 It's pretty simple, and non-optional if tourism between worlds is= desired.=A0 "When in Rome, do as the Romans do" says it all.

As you say, I believe we're converging. :-)


Morgai= ne.







=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

On Fri, Oc= t 2, 2009 at 12:32 AM, Joshua Bell <josh@lindenlab.com> wro= te:
<= /div>
I think we're converging...

On Thu, Oct 1, 2009 at 4:13 PM, Morgaine <morgaine.dinov= a@googlemail.com> wrote:
Those are valid examples, but they're cherry picked to su= pport your specific use case.


Well, simplified examples. I don't beli= eve more complicated examples actually add meaningfully at a protocol level= , as will become clear...
=A0
Please examine the more general use case of two complete SL-like worlds usi= ng VWRAP, W1 and W2.=A0 They both have ADs and RDs, so let's label thos= e with 1's and 2's accordingly.

At a= protocol level, I don't think VWs exist. There are services, which we&= #39;re clustering into AD and RD. Although we may later determine there are= further subdivisions, that's our working model in the drafts. Further = drafts are strongly encouraged!
=A0
If both A= Ds and RDs determine policy together (as you stated), then you can't ex= pect a resident of W1 to TP from RD1 to RD2 without AD2's policy coming= into play, otherwise you would be subverting AD2's policy.

Here's the crux of the issue: in our model,= the provider of W2 is offering two sets of services, AD2 and RD2. There ma= y be a policy covering W2 in general, which would affect the AD2 and RD2 se= rvices. However, if an agent "from" W1, meaning the agent service= s are provided by AD1, attempts to visit RD2, then AD2 does *not* come into= play. The protocol describes the negotiation between the client, AD1 and R= D2 *only*.

(Again, this is insofar as the model in the current drafts are concerne= d. If we're missing something, please bring the conversation back to th= e drafts and point out issues and/or submit new work for discussion!)

Let me restate: even if AD2 and RD2 are governed by the same policy - p= otentially even to the point of being implemented by the same monolithic pi= ece of code! - AD2 is irrelevant *from a protocol perspective* in the attem= pt to place an agent from AD1 into AD2, since by definition the AD2 and RD2= services are disjoint.
=A0
If you wish to define ADs in this way then we are in perfect agreemen= t, since DDP is essential for interop between worlds.=A0 I am hoping that t= his is what you had in mind for when we start discussing specific AD and RD= policies. :-)


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx



_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx




--00032555a282e5060b04751c6694-- From sm@resistor.net Sun Oct 4 07:56:49 2009 Return-Path: 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 CC47E3A6960 for ; Sun, 4 Oct 2009 07:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] 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 2QdrCiwLvZTZ for ; Sun, 4 Oct 2009 07:56:49 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id F19EA3A65A6 for ; Sun, 4 Oct 2009 07:56:48 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n94EvrgG021212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Oct 2009 07:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1254668286; x=1254754686; bh=N4NStUfmjn50lKg5ZNkS3DmBH0+31UCLjlMaHnCKOiM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=gHGymsr5N0ypXvKT6YCfNOJmvnE8IWnsMjX+9X13j9t7jFmMJn/tjZ7qFG8Oua4iz OEf/7lpWQJElUsMt7O6UGqnTgwK58vQpJkyULRbLp0quB0DND5Jy6zEZNhwJMjh1Tw dohplzg+bfQic4MyWeucBWJcS9XkhfEESISmViwU= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=CBaNVbSz+S+JvMWWyKdcrjFbdwlu7Oxut5niQZYO7t5tiCynYBmF/THRU6sXmIq/E Ujwv7YTx2Ev1fZPAcmSwRfJ5QeopMq5+ZemI0WjPc/M2bmGhAiXJzhDIgzzh9foSPEf WfdepIJSKQfRXrKkD1JNRTlBvv1fW1JAdJLByOU= Message-Id: <6.2.5.6.2.20091004072856.031ac940@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 04 Oct 2009 07:56:46 -0700 To: Vaughn Deluca From: SM In-Reply-To: <9b8a8de40910040421y41314922o4c5242c77941af4c@mail.gmail.co m> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910040421y41314922o4c5242c77941af4c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 14:56:49 -0000 At 04:21 04-10-2009, Vaughn Deluca wrote: >I think SMTP is a very good example. An SMTP server will reject >mail from untrusted sources; if I try to use the SMTP server in >Domain X while logged in at domain Y it normally fails, because the >SMTP server does not trust anybody but those it has information on >(that might include age, real world address etc.), i.e. users from X. SMTP is not based on a concept of "trust domains". If a SMTP server were to reject mail from untrusted sources, this email would not reach your mailbox. You are using a gmail.com email address. Does your email provider have your real name, your real world address and did it validate your age? Regards, -sm From mike.dickson@hp.com Sun Oct 4 09:07:37 2009 Return-Path: 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 7EBE13A6407 for ; Sun, 4 Oct 2009 09:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 zYvcmjjyB0TO for ; Sun, 4 Oct 2009 09:07:33 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by core3.amsl.com (Postfix) with ESMTP id C29393A687B for ; Sun, 4 Oct 2009 09:07:33 -0700 (PDT) Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0006.atlanta.hp.com (Postfix) with ESMTPS id 103F2C0D4; Sun, 4 Oct 2009 16:09:05 +0000 (UTC) Received: from G3W0058.americas.hpqcorp.net (16.232.1.3) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 4 Oct 2009 16:08:09 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G3W0058.americas.hpqcorp.net ([16.232.1.3]) with mapi; Sun, 4 Oct 2009 16:08:09 +0000 From: "Dickson, Mike (ISS Software)" To: Vaughn Deluca Date: Sun, 4 Oct 2009 16:07:29 +0000 Thread-Topic: [ogpx] VWRAP Draft Charter - 2009 09 01 Thread-Index: AcpE5Nypx3BAH61hQEKWjVt6gLf6SQAJ51AQ Message-ID: <4646639E08F58B42836FAC24C94624DD771A0D8277@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910040421y41314922o4c5242c77941af4c@mail.gmail.com> In-Reply-To: <9b8a8de40910040421y41314922o4c5242c77941af4c@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD771A0D8277GVW0433EXBame_" MIME-Version: 1.0 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 16:07:37 -0000 --_000_4646639E08F58B42836FAC24C94624DD771A0D8277GVW0433EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think SMTP is a very good example. An SMTP server will reject mail from = untrusted sources; if I try to use the SMTP server in Domain X while logged= in at domain Y it normally fails, because the SMTP server does not trust a= nybody but those it has information on (that might include age, real world = address etc.), i.e. users from X. The age restriction is not carried explicitly in the protocol, but is coded= in the source of the message. Its actually the trust relation between the = SMTP server and that domain were the user is logged in that determines the = SMTP protocol response. In my view this is fully analogous to the way VWRAP should deal with age re= strictions or whatever other constrain. -Vaughn You've expressed this more concisely than me. Yes, I completely agree and t= hat was the point I was making. Not to code the policy in the exchange but= to allow the exchange of information such that a policy decision can be ma= de. Mike --_000_4646639E08F58B42836FAC24C94624DD771A0D8277GVW0433EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think SMTP is a very good example. An SMTP server  will reject mail from untrusted sources; if I= try to use the SMTP server in Domain X while logged in at domain Y it normally fails, because the SMTP server does not trust anybody but those it has info= rmation on (that might include age, real world address etc.), i.e. users  from= X.

 

The age restriction is not = carried explicitly in the protocol, but is coded in the source of the message. Its actually the trust relation between the SMTP server and that domain were th= e user is logged in that determines the SMTP protocol response.

 

In my view this is fully an= alogous to the way VWRAP should deal with age restrictions or whatever other constr= ain.

 

-Vaughn

 

You’ve expressed this more concisely than me. Yes, I c= ompletely agree and that was the point I was making.  Not to code the policy in = the exchange but to allow the exchange of information such that a policy decisi= on can be made.

 

Mike

 

--_000_4646639E08F58B42836FAC24C94624DD771A0D8277GVW0433EXBame_-- From mike.dickson@hp.com Sun Oct 4 09:18:21 2009 Return-Path: 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 8E4503A676A for ; Sun, 4 Oct 2009 09:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 rEGps2myrG7h for ; Sun, 4 Oct 2009 09:18:18 -0700 (PDT) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by core3.amsl.com (Postfix) with ESMTP id 1BEBF3A6903 for ; Sun, 4 Oct 2009 09:18:17 -0700 (PDT) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id 3982F1401D; Sun, 4 Oct 2009 16:19:50 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 4 Oct 2009 16:19:08 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Sun, 4 Oct 2009 16:19:08 +0000 From: "Dickson, Mike (ISS Software)" To: SM , Vaughn Deluca Date: Sun, 4 Oct 2009 16:18:44 +0000 Thread-Topic: [ogpx] VWRAP Draft Charter - 2009 09 01 Thread-Index: AcpFAx/Z3AqGUb+8SxyfXx+Pt2+00QACpHRQ Message-ID: <4646639E08F58B42836FAC24C94624DD771A0D827E@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910040421y41314922o4c5242c77941af4c@mail.gmail.com> <6.2.5.6.2.20091004072856.031ac940@resistor.net> In-Reply-To: <6.2.5.6.2.20091004072856.031ac940@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD771A0D827EGVW0433EXBame_" MIME-Version: 1.0 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 16:18:21 -0000 --_000_4646639E08F58B42836FAC24C94624DD771A0D827EGVW0433EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SMTP is not based on a concept of "trust domains". If a SMTP server were to reject mail from untrusted sources, this email would not reach your mailbox. You are using a gmail.com email address. Does your email provider have your real name, your real world address and did it validate your age? Regards, -sm Sure it does if I'm required to authenticate to use it. That is, if I'm se= nding using my gmail.com address and I'm required to authenticate to use it= then yes, its very possible to make the association. True, I may be able = to find an SMTP server that will accept my mail anonymously. In that sense= the protocols are different (though even then an SMTP gateway can refuse t= o accept or forward from a server that accepts such anonymous connections). Mike _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --_000_4646639E08F58B42836FAC24C94624DD771A0D827EGVW0433EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

SMTP is not based on a c= oncept of "trust domains".  If a SMTP server

were to reject mail from untrusted sources, this email would not

reach your mailbox.=

 

You are using a gmail.co= m email address.  Does your email provider

have your real name, you= r real world address and did it validate your age?

 

Regards,

-sm

 

Sure it does if I'm req= uired to authenticate to use it.  That is, if I’m sending using my gmail.= com address and I’m required to authenticate to use it then yes, its very possible to make the association.  True, I may be able to find an SMTP server that will accept my mail anonymously.  In that sense the protoc= ols are different (though even then an SMTP gateway can refuse to accept or for= ward from a server that accepts such anonymous connections).

 

Mike<= /p>

_______________________________________________

ogpx mailing list

ogpx@ietf.org

https://www.ietf.org/mailman/listinfo/ogpx

--_000_4646639E08F58B42836FAC24C94624DD771A0D827EGVW0433EXBame_-- From vaughn.deluca@gmail.com Sun Oct 4 11:45:09 2009 Return-Path: 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 8A3EC28C0EF for ; Sun, 4 Oct 2009 11:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 ckmHCH+q73Bn for ; Sun, 4 Oct 2009 11:45:08 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id 2E25E28C0DC for ; Sun, 4 Oct 2009 11:45:07 -0700 (PDT) Received: by fxm28 with SMTP id 28so2227273fxm.42 for ; Sun, 04 Oct 2009 11:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=f33iT4/BB1Za+8eBCPH5nGg4l+pMoPeQ04TSCao41mI=; b=cYthJUpVjoe6aqASZDAe6eKBOode6RLY0Visv0fT5/QAzJg7t8Mc+yGhLTIiJzreg/ SgF5mPJRbPEkh1dFyqiJueHz7iHZw8ndQjPdD2+JnnWdKszq/u2PI1lbSptD9gLXpQ7D +rAlaCn/lI9NKwTEWEuqMUuTon+jgLQlexY+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U+X7MZdB25mZpGtT/FH4JU+DwpXKpBXYmA1GD23k5qONivoChGIeANRWwvwAgZ0jgm vwReeUoMPsh8MzOoo6p8qVcm5wzhtYKzU0lGSoFD3wMUBkJeGd/sm+V2GjI9HenPlf/W OxLyqlmSspI5AzDBhqaosC/5H1Ap4j6pITUl4= MIME-Version: 1.0 Received: by 10.204.34.5 with SMTP id j5mr3308012bkd.5.1254681995872; Sun, 04 Oct 2009 11:46:35 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20091004072856.031ac940@resistor.net> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910040421y41314922o4c5242c77941af4c@mail.gmail.com> <6.2.5.6.2.20091004072856.031ac940@resistor.net> Date: Sun, 4 Oct 2009 20:46:35 +0200 Message-ID: <9b8a8de40910041146h4c8e8bbdt2176ee143ec6656b@mail.gmail.com> From: Vaughn Deluca To: SM Content-Type: multipart/alternative; boundary=00032555af76ab8be60475206a48 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 18:45:09 -0000 --00032555af76ab8be60475206a48 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 4, 2009 at 4:56 PM, SM wrote: > At 04:21 04-10-2009, Vaughn Deluca wrote: > >> I think SMTP is a very good example. An SMTP server will reject mail from >> untrusted sources; if I try to use the SMTP server in Domain X while logged >> in at domain Y it normally fails, because the SMTP server does not trust >> anybody but those it has information on (that might include age, real world >> address etc.), i.e. users from X. >> > > SMTP is not based on a concept of "trust domains". If a SMTP server were > to reject mail from untrusted sources, this email would not reach your > mailbox. > > You are using a gmail.com email address. Does your email provider have > your real name, your real world address and did it validate your age? > No, but that is besides the point, they *could* have done so, in fact they implicitly did, since they made me accept their TOS including this: 2.3 You may not use the Services and may not accept the Terms if (a) you are not of legal age to form a binding contract with Google, and this: 5.1 In order to access certain Services, you may be required to provide information about yourself (such as identification or contact details) as part of the registration process for the Service, or as part of your continued use of the Services. You agree that any registration information you give to Google will always be accurate, correct and up to date. I read that as: a) I have to be 18 or older b) I am obliged to prove my true age if asked for. But the discussion is drifting, were talking about the way that for instance an age limit might be passed in the protocol. Carlo said that info was needed, Morgaine set it has no place in the protocol, using SMTP as an example, Mike stated that it is very well possible to transfer the age information without putting it explicitly in the protocol, and indeed Morgaine's example of SMTP is a perfect model to demonstrate how that could work. There are still complications, but if feel this is a good basis to work from. --Vaughn > > Regards, > -sm > --00032555af76ab8be60475206a48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Oct 4, 2009 at 4:56 PM, SM <sm@re= sistor.net> wrote:
At 04:21 04-10-2009, Vaughn Deluca wrote:
I think SMTP is a very good example. An SMTP server =A0will reject mail fro= m untrusted sources; if I try to use the SMTP server in Domain X while logg= ed in at domain Y it normally fails, because the SMTP server does not trust= anybody but those it has information on (that might include age, real worl= d address etc.), i.e. users =A0from X.

SMTP is not based on a concept of "trust domains". =A0If a SMTP s= erver were to reject mail from untrusted sources, this email would not reac= h your mailbox.

You are using a gmail.com email address. =A0Does your email provider have your real name, your real= world address and did it validate your age?
=
No, but that is besides the point, they *could* have done so, in fact = they implicitly did, since they made me accept their TOS including this:

2.3 You may not use the Services and may not ac= cept the Terms if (a) you are not of legal age to form a binding contract w= ith Google,
=A0=A0=A0
and this:
=A0
=A0=A05.1 In ord= er to access certain Services, you may be required to provide information a= bout yourself (such as identification or contact details) =A0 as part of th= e registration process for the Service, or as part of your continued use of= the Services. You agree that any registration information you give to Goog= le will always be accurate, correct and up to date.

I read that as:
a) I have to be 18 or o= lder
b) I am obliged to prove my true age if asked for.

But the discussion is drifting, =A0were talking about the w= ay that for instance an age limit might be passed in the protocol. =A0Carlo= said that info was needed, Morgaine set it has no place in the protocol, u= sing SMTP as an example, Mike stated that it is very well possible to trans= fer the age information without putting it explicitly in the protocol, and = indeed Morgaine's example of SMTP is a perfect model to demonstrate how= that could work.
There are still complications, but if feel this is a good basis to wor= k from.
--Vaughn

=A0

Regards,
-sm

--00032555af76ab8be60475206a48-- From morgaine.dinova@googlemail.com Sun Oct 4 12:32:46 2009 Return-Path: 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 764BF3A6916 for ; Sun, 4 Oct 2009 12:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.541 X-Spam-Level: X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 rkQcUDwvW3pm for ; Sun, 4 Oct 2009 12:32:45 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 9C7323A684E for ; Sun, 4 Oct 2009 12:32:44 -0700 (PDT) Received: by ewy28 with SMTP id 28so3508687ewy.42 for ; Sun, 04 Oct 2009 12:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MoZOKAm2OC1K46oVxuumh8e2Kqrb2YgSJbw2L//0XLw=; b=MaoRXkAyYINcHTTBFp9FIutF2gA08SkwrzIoJUC7EmHaPooRwf10U/E5nWosvxCUIu lEkaNqnlXP/8ceSEFkgUVOFLz8St7LgBGiwYirQVtCaPkl6nlnH09HEL+5hBdQxeasRT 3CZb9VYIcYizqxft79dRGsRac7BzKJCYzwvKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=USz1Z82A0ONzbH+6OVvusww3sFNKRaEmtJ7LB1Foiei5i6J7Q3sB/CUgJQKvuT9sNG obHfZH/yKL3p2+416UxKjCcvTJ/biCSQl9k+mIM+pyK+aqqJwydOjsJS7EvAl45dJzrh 3cXkJ+g4A0foRfJZ9UhPvd8+A2uW3moTVTCdY= MIME-Version: 1.0 Received: by 10.211.160.4 with SMTP id m4mr6035723ebo.24.1254684854797; Sun, 04 Oct 2009 12:34:14 -0700 (PDT) In-Reply-To: <9b8a8de40910041146h4c8e8bbdt2176ee143ec6656b@mail.gmail.com> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910040421y41314922o4c5242c77941af4c@mail.gmail.com> <6.2.5.6.2.20091004072856.031ac940@resistor.net> <9b8a8de40910041146h4c8e8bbdt2176ee143ec6656b@mail.gmail.com> Date: Sun, 4 Oct 2009 20:34:14 +0100 Message-ID: From: Morgaine To: Vaughn Deluca Content-Type: multipart/alternative; boundary=00504502d38a1347f504752115bd Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 19:32:46 -0000 --00504502d38a1347f504752115bd Content-Type: text/plain; charset=ISO-8859-1 Google have not modified SMTP to carry SMTP-readable metadata about the age of participants, so the whole example of Google is inaccurate and moot. Carrying data as payload is a different matter entirely to using it in the protocol. There is nothing to stop arbitrary payloads being sent between world to implement random policies which, indirectly, could deny connections or deny object transfer, but this is outside the scope of the protocol. It **HAS** to be outside of the scope of the protocol, because there exist an infinite number of possible attributes on the basis of which a world could implement an exclusion policy, and we're not here to ennumerate such attributes nor to support one particular type of attribute over another. Morgaine. ========================================== On Sun, Oct 4, 2009 at 7:46 PM, Vaughn Deluca wrote: > > > On Sun, Oct 4, 2009 at 4:56 PM, SM wrote: > >> At 04:21 04-10-2009, Vaughn Deluca wrote: >> >>> I think SMTP is a very good example. An SMTP server will reject mail >>> from untrusted sources; if I try to use the SMTP server in Domain X while >>> logged in at domain Y it normally fails, because the SMTP server does not >>> trust anybody but those it has information on (that might include age, real >>> world address etc.), i.e. users from X. >>> >> >> SMTP is not based on a concept of "trust domains". If a SMTP server were >> to reject mail from untrusted sources, this email would not reach your >> mailbox. >> >> You are using a gmail.com email address. Does your email provider have >> your real name, your real world address and did it validate your age? >> > > No, but that is besides the point, they *could* have done so, in fact they > implicitly did, since they made me accept their TOS including this: > > 2.3 You may not use the Services and may not accept the Terms if (a) you > are not of legal age to form a binding contract with Google, > > and this: > > 5.1 In order to access certain Services, you may be required to provide > information about yourself (such as identification or contact details) as > part of the registration process for the Service, or as part of your > continued use of the Services. You agree that any registration information > you give to Google will always be accurate, correct and up to date. > > I read that as: > a) I have to be 18 or older > b) I am obliged to prove my true age if asked for. > > But the discussion is drifting, were talking about the way that for > instance an age limit might be passed in the protocol. Carlo said that info > was needed, Morgaine set it has no place in the protocol, using SMTP as an > example, Mike stated that it is very well possible to transfer the age > information without putting it explicitly in the protocol, and indeed > Morgaine's example of SMTP is a perfect model to demonstrate how that could > work. > There are still complications, but if feel this is a good basis to work > from. > --Vaughn > > > >> >> Regards, >> -sm >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00504502d38a1347f504752115bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Google have not modified SMTP to carry SMTP-readable metadata about the age= of participants, so the whole example of Google is inaccurate and moot.
Carrying data as payload is a different matter entirely to using it in= the protocol.

There is nothing to stop arbitrary payloads being sent between world to= implement random policies which, indirectly, could deny connections or den= y object transfer, but this is outside the scope of the protocol.

It *HAS* to be outside of the scope of the protocol, because there e= xist an infinite number of possible attributes on the basis of which a worl= d could implement an exclusion policy, and we're not here to ennumerate= such attributes nor to support one particular type of attribute over anoth= er.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

On Sun, Oct 4, 2009= at 7:46 PM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:


On Sun, Oct 4, 2009 at 4:56 PM, SM <sm@r= esistor.net> wrote:
At 04:21 04-10-2009, Vaughn Deluca wrote:
I think SMTP is a very good example. An SMTP server =A0will reject mail fro= m untrusted sources; if I try to use the SMTP server in Domain X while logg= ed in at domain Y it normally fails, because the SMTP server does not trust= anybody but those it has information on (that might include age, real worl= d address etc.), i.e. users =A0from X.

SMTP is not based on a concept of "trust domains". =A0If a SMTP s= erver were to reject mail from untrusted sources, this email would not reac= h your mailbox.

You are using a gmail.com email address. =A0Does your email provider have your real name, your real= world address and did it validate your age?
=
No, but that is besides the point, they *could* have done so, in fact = they implicitly did, since they made me accept their TOS including this:

2.3 You may not use the Services and may not ac= cept the Terms if (a) you are not of legal age to form a binding contract w= ith Google,
=A0=A0=A0
and this:
=A0
=A0=A05.1 In ord= er to access certain Services, you may be required to provide information a= bout yourself (such as identification or contact details) =A0 as part of th= e registration process for the Service, or as part of your continued use of= the Services. You agree that any registration information you give to Goog= le will always be accurate, correct and up to date.

I read that as:
a) I have to be 18 or o= lder
b) I am obliged to prove my true age if asked for.

But the discussion is drifting, =A0were talking about the w= ay that for instance an age limit might be passed in the protocol. =A0Carlo= said that info was needed, Morgaine set it has no place in the protocol, u= sing SMTP as an example, Mike stated that it is very well possible to trans= fer the age information without putting it explicitly in the protocol, and = indeed Morgaine's example of SMTP is a perfect model to demonstrate how= that could work.
There are still complications, but if feel this is a good basis to wor= k from.
--Vaughn

=A0

Regards,
-sm


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00504502d38a1347f504752115bd-- From dwl@us.ibm.com Sun Oct 4 14:25:33 2009 Return-Path: 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 03E3F3A67A3; Sun, 4 Oct 2009 14:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.667 X-Spam-Level: X-Spam-Status: No, score=-2.667 tagged_above=-999 required=5 tests=[AWL=-2.483, BAYES_40=-0.185, HTML_MESSAGE=0.001] 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 eZEQ6cmzTspY; Sun, 4 Oct 2009 14:25:32 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id B8CF93A677E; Sun, 4 Oct 2009 14:25:31 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n94LOM9F018407; Sun, 4 Oct 2009 17:24:22 -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 n94LQvKu245900; Sun, 4 Oct 2009 17:26:57 -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 n94LNatN025914; Sun, 4 Oct 2009 17:23:36 -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 n94LNafj025911; Sun, 4 Oct 2009 17:23:36 -0400 In-Reply-To: References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910040421y41314922o4c5242c77941af4c@mail.gmail.com> <6.2.5.6.2.20091004072856.031ac940@resistor.net> <9b8a8de40910041146h4c8e8bbdt2176ee143ec6656b@mail.gmail.com> To: Morgaine MIME-Version: 1.0 X-KeepSent: 4CD5B4C5:5E22B3C8-85257645:006F25DB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Sun, 4 Oct 2009 17:26:57 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/04/2009 17:26:57, Serialize complete at 10/04/2009 17:26:57 Content-Type: multipart/alternative; boundary="=_alternative 0075D2EA85257645_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: [ogpx] Policy between services X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2009 21:25:33 -0000 This is a multipart message in MIME format. --=_alternative 0075D2EA85257645_= Content-Type: text/plain; charset="US-ASCII" I've changed the subject, because the thread drift has become brutal I want to make a couple of points, one of, something akin to etiquette. Lets start there. I don't think it advances our technical agenda when we start dragging in philosophical, political and cultural issues around some of the use cases people are advancing. One persons abhorred policy is another's legally required to stay in business use case. We also need to be careful to separate the use cases, such as "I don't want people who haven't passed some form of age verification accessing some virtual spaces" from possible mechanisms for achieving those use cases. It is also worth keeping in mind the limitations of what we can express in a protocol and what mechanisms we have for allowing services to express and manage policy. At the end of the day the policy enforcement points are primarily when either: 1) first contact is made with a cluster of services, where meta-data is included in the request, and based on this, and policy, caps are granted (or not) and meta-data is associated with those caps. This is one of the nice bits of a cap grant, it permits a policy decision to be made once, and encapsulated in the cap(s) granted. 2) at invocation of a cap, mediated by meta-data associated with the request. This is notably more expensive, as it requires the check to be made in all cases, but it provides a finer grained policy enforcement scheme. Also note protocol is unlikely to directly encode complex, "semantic" concepts such as "age-verified." They are far more likely to permit set of deploys to define mechanisms for making (and possibly in some cases verifying) properties of the users they represent This is rather like the point made by several people, a distinction between having the spots to carry the information, and mandating the contents of those slots. The nice thing about LLSD protocol elements is that they are easily extensible. if we say "Here is where a set of properties that the authenticating service vouches for about the user go" we can stop there, and allow the community to define the properties they care about. We also need to recognize the limits of any specification. We describe mechanisms to enable interoperability. We cannot mandate how people extend those mechanisms nor deployment choices they make, nor policy choices they make which are beyond those defined in the specifications. Lastly, for better or worse, some of the use cases involved in policy effectively are about linking a real world legal contract with the use of services. We're not going to flow protocol elements which are legal contracts, but.. we may well end up using things like PKI to prove the a given end user or service is in procession of a proof token for having signed a specific legal document . In this case, less a matter of defining the mechanisms as much as leveraging existing ones. - David Levine ~ Zha Ewry --=_alternative 0075D2EA85257645_= Content-Type: text/html; charset="US-ASCII"
I've changed the subject, because the thread drift has become brutal

I want to make a couple of points, one of, something akin to etiquette. Lets start there.

I don't think it advances our technical agenda when we start dragging in philosophical,
political and cultural issues around some of the use cases people are advancing.
One persons abhorred policy is another's legally required to stay in business use case.

We also need to be careful to separate the use cases, such as "I don't want people
who haven't passed some form of age verification accessing some virtual spaces"
from possible mechanisms for achieving those use cases.

It is also worth keeping in mind the limitations of  what we can express in a protocol
and what  mechanisms we have for allowing services to express and manage policy.

At the end of the day the policy enforcement points are primarily when either:

        1) first contact is made with a cluster of services, where meta-data is
            included in the request, and based on this, and policy, caps are
                    granted (or not) and meta-data is associated with those caps. This
            is one of the nice bits of a cap grant, it permits a policy decision to
                    be made once, and encapsulated in the cap(s) granted.

        2) at invocation of a cap, mediated by meta-data associated with
                    the request. This is notably more expensive, as it requires the check
                   to be made in all cases, but it provides a finer grained policy enforcement
                   scheme.

 
Also note protocol is unlikely to directly encode complex, "semantic" concepts such as
"age-verified." They are far more likely to permit set of deploys to define mechanisms
for making (and possibly in some cases verifying)  properties of the users they represent  

This is rather like the point made by several people, a distinction between having the
spots to carry the information, and mandating the contents of those slots. The nice
thing about LLSD protocol elements  is that they are easily extensible. if we say "Here is where
a set of properties that the authenticating service vouches for about the user go"
we can stop there, and allow the community to define the properties they care about.

We also need to recognize the limits of any specification. We describe mechanisms
to enable interoperability. We cannot mandate how people extend those mechanisms
nor deployment choices they make, nor policy choices they make which are beyond those
defined in the specifications.

Lastly, for better or worse, some of the use cases involved in policy effectively are
about linking a real world legal contract with the use of services. We're not going to
flow protocol elements which are legal contracts, but.. we may well end up using
things like PKI to prove the a given end user or service is in procession of a proof
token for having signed a specific legal document . In this case, less a matter
of defining the mechanisms as much as leveraging existing ones.

- David Levine
~ Zha Ewry


--=_alternative 0075D2EA85257645_=-- From magnus.zeisig@iis.se Mon Oct 5 01:53:51 2009 Return-Path: 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 BC6343A6774 for ; Mon, 5 Oct 2009 01:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.905 X-Spam-Level: X-Spam-Status: No, score=-4.905 tagged_above=-999 required=5 tests=[AWL=-1.257, BAYES_50=0.001, HELO_EQ_SE=0.35, 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 O+iWoN1havs9 for ; Mon, 5 Oct 2009 01:53:50 -0700 (PDT) Received: from cleaner.prod.iis.se (cleaner.prod.iis.se [212.247.7.212]) by core3.amsl.com (Postfix) with ESMTP id 01AE83A6892 for ; Mon, 5 Oct 2009 01:53:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cleaner.prod.iis.se (Postfix) with ESMTP id 4B930A801D; Mon, 5 Oct 2009 08:55:20 +0000 (UTC) Received: from cleaner.prod.iis.se ([127.0.0.1]) by localhost (cleaner.prod.iis.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03939-01; Mon, 5 Oct 2009 08:55:14 +0000 (UTC) Received: from pgpkeys.office.nic.se (pgpkeys.office.nic.se [212.247.204.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cleaner.prod.iis.se (Postfix) with ESMTP id 8EB22A8017 for ; Mon, 5 Oct 2009 08:55:14 +0000 (UTC) Received: from EXCH2K7HUB-BRG.office.nic.se ([212.247.3.5]) by pgpkeys.office.nic.se (PGP Universal service); Mon, 05 Oct 2009 10:55:14 +0200 X-PGP-Universal: processed; by pgpkeys.office.nic.se on Mon, 05 Oct 2009 10:55:14 +0200 Received: from Exchange2k7.office.nic.se ([169.254.1.222]) by EXCH2K7HUB-BRG.office.nic.se ([212.247.3.5]) with mapi; Mon, 5 Oct 2009 10:55:13 +0200 From: Magnus Zeisig To: "ogpx@ietf.org" Date: Mon, 5 Oct 2009 10:55:12 +0200 Thread-Topic: Protocol for permitting policy decisions Thread-Index: AcpFmYY7rtB6bOoDTWi+fAneeDEo7Q== Message-ID: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> Accept-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-pgp-encoding-version: 2.0.2 x-pgp-mapi-encoding-version: 2.5.0 x-pgp-encoding-format: Partitioned x-pgp-universal-saved-content-codepage: utf-8 acceptlanguage: sv-SE MIME-Version: 1.0 Content-Language: sv-SE Content-Type: multipart/alternative; boundary="_000_983F17705339E24699AA251B458249B50CC48CAEBFEXCHANGE2K7of_" X-Virus-Scanned: Debian amavisd-new at cleaner.prod.iis.se Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 08:53:51 -0000 --_000_983F17705339E24699AA251B458249B50CC48CAEBFEXCHANGE2K7of_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCklmIEkg cmVnaXN0ZXIgd2l0aCBhbiBhZ2VudCBkb21haW4sIG9yIGF1dGhlbnRpY2F0aW9uIHNlcnZpY2Us IHdoaWNoZXZlciBzaG91bGQgYmUgdGhlIHByb3BlciBuYW1lIGZvciBpdCwgSSB3aWxsIG1vc3Qg cHJvYmFibHkgaGFuZCB0aGVtIHNvbWUgcGllY2VzIG9mIGluZm9ybWF0aW9uIGFib3V0IG15c2Vs ZiB0aGF0IEkgZG9uJ3Qgd2FudCBkaXNzZW1pbmF0ZWQgdG8gYW55b25lLiBUaGVyZWZvcmUsIEkg dGhpbmsgdGhlIHByb3RvY29sIGZvciBncmFudGluZyBhY2Nlc3MgdG8gcmVnaW9ucyBhbmQgb3Ro ZXIgc2VydmljZXMgc2hvdWxkIG5vdCBpbmNsdWRlIHN1Y2ggaW5mb3JtYXRpb24gZXhwbGljaXRs eSwgYnV0IHJhdGhlciBsZXQgdGhlIGFnZW50IGRvbWFpbi9hdXRoZW50aWNhdGlvbiBzZXJ2aWNl IGp1c3QgYW5zd2VyIHF1ZXN0aW9ucyBmcm9tIHRoZSBvdGhlciBkb21haW4vc2VydmljZSBpZiB0 aGUgcGFyYW1ldGVycyBhcmUgd2l0aGluIGFjY2VwdGFibGUgcmFuZ2UuDQoNCkluc3RlYWQgb2Yg dGhlIHJldmVhbGluZyAobWV0YS1oYW5kc2hha2UpOg0KDQpBZ2VudCBkb21haW46DQpyZXF1ZXN0 IGFjY2VzcyBmb3INCnVzZXI6IFRpdGxlLkZpcnN0TmFtZS5Jbml0aWFscy5MYXN0TmFtZS5FeHRy YVNvbWV0aGluZ0BhZ2VudGRvbWFpbi5vcmcNCmFnZTogMTgNCmdlbmRlcjogbWFsZQ0Kc2V4dWFs aXR5OiBiaQ0KY291bnRyeTogcHQNCmxhbmd1YWdlczogcHQsIGVzLCBlbiwgZGUNCmxlbmd0aDog MS44Mg0Kd2VpZ2h0OiAxMjINCmNvbG9yIG9mIHNvY2tzOiBibHVlDQoNClJlZ2lvbiBkb21haW46 DQphY2Nlc3MgZ3JhbnRlZCBmb3INCnVzZXI6IFRpdGxlLkZpcnN0TmFtZS5Jbml0aWFscy5MYXN0 TmFtZS5FeHRyYVNvbWV0aGluZ0BhZ2VudGRvbWFpbi5vcmcNCg0KVGhlIGhhbmRzaGFrZSBzaG91 bGQgaW5zdGVhZCBiZToNCg0KQWdlbnQgZG9tYWluOg0KcmVxdWVzdCBhY2Nlc3MgZm9yDQp1c2Vy OiBUaXRsZS5GaXJzdE5hbWUuSW5pdGlhbHMuTGFzdE5hbWUuRXh0cmFTb21ldGhpbmdAYWdlbnRk b21haW4ub3JnDQoNClJlZ2lvbiBkb21haW46DQpyZXF1aXJlIHBhcmFtZXRlciB2YWx1ZXMNCmxh bmd1YWdlczogZXMgQU5EIChkZSBPUiBoYiBPUiBydSkNCmxlbmd0aDogWzEuMjEtMi40Ml0NCmNv bG9yIG9mIHNvY2tzOiBwaW5rIE9SIGJsdWUgT1IgYmxhY2sNCmhhaXJkbzogc2hhdmVkIE9SIHBv bnl0YWlsDQoNCkFnZW50IGRvbWFpbjoNCnJlcXVpcmVkIHBhcmFtZXRlciB2YWx1ZXMNCmxhbmd1 YWdlczogeWVzDQpsZW5ndGg6IHllcw0KY29sb3Igb2Ygc29ja3M6IHllcw0KaGFpcmRvOiBuL2EN Cg0KQWZ0ZXIgd2hpY2ggdGhlIHJlZ2lvbiBkb21haW4gbWlnaHQgZGVjaWRlIHRoYXQgdGhlIG1p c3NpbmcgaGFpcmRvIHBhcmFtZXRlciBpcyBub3QgY3J1Y2lhbCBhbmQgZ3JhbnQgYWNjZXNzLCBv ciByZWZ1c2UgYWNjZXNzIGJlY2F1c2Ugb2YgaXQ6DQoNClJlZ2lvbiBkb21haW46DQphY2Nlc3Mg ZGVuaWVkIGZvcg0KdXNlcjogVGl0bGUuRmlyc3ROYW1lLkluaXRpYWxzLkxhc3ROYW1lLkV4dHJh U29tZXRoaW5nQGFnZW50ZG9tYWluLm9yZw0KDQpUaGlzIGhhcyB0aGUgYmVuZWZpdCBvZiBwZXJt aXR0aW5nIHNlcnZpY2UgcHJvdmlkZXJzIHRvIHJlcXVpcmUgd2hhdCB1c2VyIHBhcmFtZXRlcnMg dGhleSB0aGluayBhcmUgaW1wb3J0YW50LCBiZSBpdCBhZ2Ugb3IgY29sb3Igb2Ygc29ja3MsIGJ1 dCB0aGUgZGlzYWR2YW50YWdlIG9mIHNvbWUgZXh0cmEgb3ZlcmhlYWQgYW5kIHRoZSByaXNrIG9m IGJhbGthbml6YXRpb24gYmVjYXVzZSBvZiByZXF1aXJlbWVudHMgb2YgIm9kZCIgcGFyYW1ldGVy cyBvbmx5IHN1cHBvcnRlZCBieSBmZXcgc2VydmljZXMuIFRoZSBsYXR0ZXIsIGhvd2V2ZXIsIEkg YmVsaWV2ZSB3aWxsIGJlY29tZSBzZWxmLWVsaW1pbmF0aW5nLCBiZWNhdXNlIHN1Y2ggc2Vydmlj ZXMgd2lsbCBwcm9iYWJseSBub3QgZmluZCBtYW55IHVzZXJzLiBFaXRoZXIgd2F5LCBJIGRvbid0 IHRoaW5rIHRoZSBwcm90b2NvbCBpbiBpdHNlbGYgc2hvdWxkIHJlcXVpcmUgYW55IHBhcnRpY3Vs YXIgcGFyYW1ldGVycywgbGlrZSBhZ2Ugb3IgY29sb3Igb2Ygc29ja3MsIGp1c3QgcHJvdmlkZSB0 aGUgbWVhbnMgdG8gY29tbXVuaWNhdGUgYW55IHBhcmFtZXRlcnMsIGFuZCBwZXJoYXBzIHN1Z2dl c3QgYSBsaXN0IG9mIHBvc3NpYmxlLCBidXQgbm90IHJlcXVpcmVkLCBwYXJhbWV0ZXJzIGFuZCBm b3JtYXRzIGZvciB2YWx1ZXMsIGxpa2Ugb3B0aW9ucywgcmFuZ2VzIGFuZCBlbnVtZXJhdGlvbnMu IFRoZSBzYW1lIGtpbmQgb2YgaGFuZHNoYWtlIGNvdWxkIGFsc28gYmUgdXNlZCB3aGVuIHJlcXVl c3RpbmcgYWNjZXNzIHRvIGFzc2V0IHNlcnZpY2VzIGFuZCB0aGUgbGlrZSwgZXZlbiBpZiBwYXJh bWV0ZXJzIGxpa2UgIm9iamVjdCB0eXBlcyIgYW5kICJpcCBhZ3JlZW1lbnRzIiBtYXkgYmUgbW9y ZSBpbXBvcnRhbnQgdGhhbiAiY29sb3Igb2Ygc29ja3MiIHRoZXJlLg0KDQpCZXN0IHJlZ2FyZHMs DQoNCk1hZ251cw0KDQoNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiA5 LjguMyAoQnVpbGQgNDAyOCkNCkNoYXJzZXQ6IHV0Zi04DQoNCndzQlZBd1VCU3NtMGNPNU1sVTlY eWFpU0FRZ0VnQWdBaU5pem5aYTRmSk4raUltNEx1bDRpVXBQTnl0ZXhuOWcNCnJKV0xaNG9ldmV3 bmd2U0NPd2hzbHNlWEtOK09UQ1VwU1BxMHZHeFJJbDU4bit1OVA1NnEwWDRwWUJaNXdzcWMNCllB UGRkNnpHdFFwUisyMVhROG9XTTk0OExFZEd4YmE4bU5PMWdEeWdxdEl5eDBzdUJZa3ZZVVd5WWl0 d2xEcHUNCm9mdkRldytKVDE0MEFwbVgvZDFkVHlnbHh5WXY2cW5EZjhpRHNIc05pV1lJMUltQjVh L2h2UEswVGtDVkZ2enINCnZMWGZMNUJmQ1hLMEkzdEpiTHB2L09vVUZFbjUvZW16ZWh1M3VhdnVR ZlFxUU0wdUJwdzhXVlNRR1hxWnppS2INCjZpOFlwRHZCcklrTkw0c3lHaG1BczdaTFVxcFpFZm9X cTJMYkdhc3FoVk1tRENCa2FrclBwZz09DQo9SDJGag0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0t LS0tDQoNCg0K --_000_983F17705339E24699AA251B458249B50CC48CAEBFEXCHANGE2K7of_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+DQo8ZGl2Pi0tLS0t QkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS08L2Rpdj4NCjxkaXY+SGFzaDogU0hBMjU2PC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JZiBJIHJlZ2lzdGVyIHdpdGggYW4gYWdlbnQg ZG9tYWluLCBvciBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlLCB3aGljaGV2ZXIgc2hvdWxkIGJlIHRo ZSBwcm9wZXIgbmFtZSBmb3IgaXQsIEkgd2lsbCBtb3N0IHByb2JhYmx5IGhhbmQgdGhlbSBzb21l IHBpZWNlcyBvZiBpbmZvcm1hdGlvbiBhYm91dCBteXNlbGYgdGhhdCBJIGRvbid0IHdhbnQgZGlz c2VtaW5hdGVkIHRvIGFueW9uZS4gVGhlcmVmb3JlLCBJIHRoaW5rIHRoZSBwcm90b2NvbA0KZm9y IGdyYW50aW5nIGFjY2VzcyB0byByZWdpb25zIGFuZCBvdGhlciBzZXJ2aWNlcyBzaG91bGQgbm90 IGluY2x1ZGUgc3VjaCBpbmZvcm1hdGlvbiBleHBsaWNpdGx5LCBidXQgcmF0aGVyIGxldCB0aGUg YWdlbnQgZG9tYWluL2F1dGhlbnRpY2F0aW9uIHNlcnZpY2UganVzdCBhbnN3ZXIgcXVlc3Rpb25z IGZyb20gdGhlIG90aGVyIGRvbWFpbi9zZXJ2aWNlIGlmIHRoZSBwYXJhbWV0ZXJzIGFyZSB3aXRo aW4gYWNjZXB0YWJsZSByYW5nZS48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pkluc3Rl YWQgb2YgdGhlIHJldmVhbGluZyAobWV0YS1oYW5kc2hha2UpOjwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXY+QWdlbnQgZG9tYWluOjwvZGl2Pg0KPGRpdj5yZXF1ZXN0IGFjY2VzcyBmb3I8 L2Rpdj4NCjxkaXY+dXNlcjogVGl0bGUuRmlyc3ROYW1lLkluaXRpYWxzLkxhc3ROYW1lLkV4dHJh U29tZXRoaW5nQGFnZW50ZG9tYWluLm9yZzwvZGl2Pg0KPGRpdj5hZ2U6IDE4PC9kaXY+DQo8ZGl2 PmdlbmRlcjogbWFsZTwvZGl2Pg0KPGRpdj5zZXh1YWxpdHk6IGJpPC9kaXY+DQo8ZGl2PmNvdW50 cnk6IHB0PC9kaXY+DQo8ZGl2Pmxhbmd1YWdlczogcHQsIGVzLCBlbiwgZGU8L2Rpdj4NCjxkaXY+ bGVuZ3RoOiAxLjgyPC9kaXY+DQo8ZGl2PndlaWdodDogMTIyPC9kaXY+DQo8ZGl2PmNvbG9yIG9m IHNvY2tzOiBibHVlPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5SZWdpb24gZG9tYWlu OjwvZGl2Pg0KPGRpdj5hY2Nlc3MgZ3JhbnRlZCBmb3I8L2Rpdj4NCjxkaXY+dXNlcjogVGl0bGUu Rmlyc3ROYW1lLkluaXRpYWxzLkxhc3ROYW1lLkV4dHJhU29tZXRoaW5nQGFnZW50ZG9tYWluLm9y ZzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+VGhlIGhhbmRzaGFrZSBzaG91bGQgaW5z dGVhZCBiZTo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkFnZW50IGRvbWFpbjo8L2Rp dj4NCjxkaXY+cmVxdWVzdCBhY2Nlc3MgZm9yPC9kaXY+DQo8ZGl2PnVzZXI6IFRpdGxlLkZpcnN0 TmFtZS5Jbml0aWFscy5MYXN0TmFtZS5FeHRyYVNvbWV0aGluZ0BhZ2VudGRvbWFpbi5vcmc8L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlJlZ2lvbiBkb21haW46PC9kaXY+DQo8ZGl2PnJl cXVpcmUgcGFyYW1ldGVyIHZhbHVlczwvZGl2Pg0KPGRpdj5sYW5ndWFnZXM6IGVzIEFORCAoZGUg T1IgaGIgT1IgcnUpPC9kaXY+DQo8ZGl2Pmxlbmd0aDogWzEuMjEtMi40Ml08L2Rpdj4NCjxkaXY+ Y29sb3Igb2Ygc29ja3M6IHBpbmsgT1IgYmx1ZSBPUiBibGFjazwvZGl2Pg0KPGRpdj5oYWlyZG86 IHNoYXZlZCBPUiBwb255dGFpbDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QWdlbnQg ZG9tYWluOjwvZGl2Pg0KPGRpdj5yZXF1aXJlZCBwYXJhbWV0ZXIgdmFsdWVzPC9kaXY+DQo8ZGl2 Pmxhbmd1YWdlczogeWVzPC9kaXY+DQo8ZGl2Pmxlbmd0aDogeWVzPC9kaXY+DQo8ZGl2PmNvbG9y IG9mIHNvY2tzOiB5ZXM8L2Rpdj4NCjxkaXY+aGFpcmRvOiBuL2E8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2PkFmdGVyIHdoaWNoIHRoZSByZWdpb24gZG9tYWluIG1pZ2h0IGRlY2lkZSB0 aGF0IHRoZSBtaXNzaW5nIGhhaXJkbyBwYXJhbWV0ZXIgaXMgbm90IGNydWNpYWwgYW5kIGdyYW50 IGFjY2Vzcywgb3IgcmVmdXNlIGFjY2VzcyBiZWNhdXNlIG9mIGl0OjwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+UmVnaW9uIGRvbWFpbjo8L2Rpdj4NCjxkaXY+YWNjZXNzIGRlbmllZCBm b3I8L2Rpdj4NCjxkaXY+dXNlcjogVGl0bGUuRmlyc3ROYW1lLkluaXRpYWxzLkxhc3ROYW1lLkV4 dHJhU29tZXRoaW5nQGFnZW50ZG9tYWluLm9yZzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+VGhpcyBoYXMgdGhlIGJlbmVmaXQgb2YgcGVybWl0dGluZyBzZXJ2aWNlIHByb3ZpZGVycyB0 byByZXF1aXJlIHdoYXQgdXNlciBwYXJhbWV0ZXJzIHRoZXkgdGhpbmsgYXJlIGltcG9ydGFudCwg YmUgaXQgYWdlIG9yIGNvbG9yIG9mIHNvY2tzLCBidXQgdGhlIGRpc2FkdmFudGFnZSBvZiBzb21l IGV4dHJhIG92ZXJoZWFkIGFuZCB0aGUgcmlzayBvZiBiYWxrYW5pemF0aW9uIGJlY2F1c2Ugb2Yg cmVxdWlyZW1lbnRzIG9mICZxdW90O29kZCZxdW90OyBwYXJhbWV0ZXJzDQpvbmx5IHN1cHBvcnRl ZCBieSBmZXcgc2VydmljZXMuIFRoZSBsYXR0ZXIsIGhvd2V2ZXIsIEkgYmVsaWV2ZSB3aWxsIGJl Y29tZSBzZWxmLWVsaW1pbmF0aW5nLCBiZWNhdXNlIHN1Y2ggc2VydmljZXMgd2lsbCBwcm9iYWJs eSBub3QgZmluZCBtYW55IHVzZXJzLiBFaXRoZXIgd2F5LCBJIGRvbid0IHRoaW5rIHRoZSBwcm90 b2NvbCBpbiBpdHNlbGYgc2hvdWxkIHJlcXVpcmUgYW55IHBhcnRpY3VsYXIgcGFyYW1ldGVycywg bGlrZSBhZ2Ugb3IgY29sb3INCm9mIHNvY2tzLCBqdXN0IHByb3ZpZGUgdGhlIG1lYW5zIHRvIGNv bW11bmljYXRlIGFueSBwYXJhbWV0ZXJzLCBhbmQgcGVyaGFwcyBzdWdnZXN0IGEgbGlzdCBvZiBw b3NzaWJsZSwgYnV0IG5vdCByZXF1aXJlZCwgcGFyYW1ldGVycyBhbmQgZm9ybWF0cyBmb3IgdmFs dWVzLCBsaWtlIG9wdGlvbnMsIHJhbmdlcyBhbmQgZW51bWVyYXRpb25zLiBUaGUgc2FtZSBraW5k IG9mIGhhbmRzaGFrZSBjb3VsZCBhbHNvIGJlIHVzZWQgd2hlbiByZXF1ZXN0aW5nDQphY2Nlc3Mg dG8gYXNzZXQgc2VydmljZXMgYW5kIHRoZSBsaWtlLCBldmVuIGlmIHBhcmFtZXRlcnMgbGlrZSAm cXVvdDtvYmplY3QgdHlwZXMmcXVvdDsgYW5kICZxdW90O2lwIGFncmVlbWVudHMmcXVvdDsgbWF5 IGJlIG1vcmUgaW1wb3J0YW50IHRoYW4gJnF1b3Q7Y29sb3Igb2Ygc29ja3MmcXVvdDsgdGhlcmUu PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5CZXN0IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj5NYWdudXM8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj4tLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLTwvZGl2Pg0K PGRpdj5WZXJzaW9uOiA5LjguMyAoQnVpbGQgNDAyOCk8L2Rpdj4NCjxkaXY+Q2hhcnNldDogdXRm LTg8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PndzQlZBd1VCU3NtMGNPNU1sVTlYeWFp U0FRZ0VnQWdBaU5pem5aYTRmSk4mIzQzO2lJbTRMdWw0aVVwUE55dGV4bjlnPC9kaXY+DQo8ZGl2 PnJKV0xaNG9ldmV3bmd2U0NPd2hzbHNlWEtOJiM0MztPVENVcFNQcTB2R3hSSWw1OG4mIzQzO3U5 UDU2cTBYNHBZQlo1d3NxYzwvZGl2Pg0KPGRpdj5ZQVBkZDZ6R3RRcFImIzQzOzIxWFE4b1dNOTQ4 TEVkR3hiYThtTk8xZ0R5Z3F0SXl4MHN1QllrdllVV3lZaXR3bERwdTwvZGl2Pg0KPGRpdj5vZnZE ZXcmIzQzO0pUMTQwQXBtWC9kMWRUeWdseHlZdjZxbkRmOGlEc0hzTmlXWUkxSW1CNWEvaHZQSzBU a0NWRnZ6cjwvZGl2Pg0KPGRpdj52TFhmTDVCZkNYSzBJM3RKYkxwdi9Pb1VGRW41L2VtemVodTN1 YXZ1UWZRcVFNMHVCcHc4V1ZTUUdYcVp6aUtiPC9kaXY+DQo8ZGl2PjZpOFlwRHZCcklrTkw0c3lH aG1BczdaTFVxcFpFZm9XcTJMYkdhc3FoVk1tRENCa2FrclBwZz09PC9kaXY+DQo8ZGl2Pj1IMkZq PC9kaXY+DQo8ZGl2Pi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLTwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_983F17705339E24699AA251B458249B50CC48CAEBFEXCHANGE2K7of_-- From sm@resistor.net Mon Oct 5 02:20:37 2009 Return-Path: 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 873C428C142 for ; Mon, 5 Oct 2009 02:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] 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 3e1dlWcBdbkQ for ; Mon, 5 Oct 2009 02:20:36 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id C933F3A6918 for ; Mon, 5 Oct 2009 02:20:36 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n959M0ed022695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Oct 2009 02:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1254734528; x=1254820928; bh=q06S8dorD3g5wJLJwipbe/WbiLcBNSXziDslgo+Ri38=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=h1ESgAUB4hCMKc6tfEkEVKBEzCXCwmpIBdxcA7KTMIe8IIgKZt2lKhiUGozgb0xYU Sn/hbcxf08LnGUrSxPDKGIBVfw1l7ojJeJu7sdm7P4pQWH79fExtrnWxnTVFXst7t9 9B7MhIStAFp3aoPcTqUWkSyb0vKH8NRLKTGMxDt0= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=1y+52EV8Qvn1g35EqwhGnhr9M97UVBFzJVa7zre3iBRjW/Votc0IxHJzUiuxHApJz YqK2v1GNPNJ4/1UfBUzidOQ5vfgfJa0ECyPFDzR1oj6iDO7wEJskmFZq2hNafn3rREN cBj/OoA2p0RJE6dbFXmwJ67k0yq6nWpbNctssWk= Message-Id: <6.2.5.6.2.20091005015852.03101298@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 05 Oct 2009 02:21:41 -0700 To: ogpx@ietf.org From: SM In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A0D827E@GVW0433EXB.amer icas.hpqcorp.net> References: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com> <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910040421y41314922o4c5242c77941af4c@mail.gmail.com> <6.2.5.6.2.20091004072856.031ac940@resistor.net> <4646639E08F58B42836FAC24C94624DD771A0D827E@GVW0433EXB.americas.hpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 09:20:37 -0000 At 09:18 04-10-2009, Dickson, Mike (ISS Software) wrote: >Sure it does if I'm required to authenticate to use it. That is, if >I'm sending using my gmail.com address and I'm required to >authenticate to use it then yes, its very possible >to make the association. True, I may be able to find an SMTP server >that will accept my That's mail submission. I'll skip the discussion about the analogy. At 11:46 04-10-2009, Vaughn Deluca wrote: >But the discussion is drifting, were talking about the way that for >instance an age limit might be passed in the protocol. Carlo said >that info was needed, Morgaine set it > has no place in the protocol, using SMTP as an example, Mike > stated that it is very well The discussion seems to be about acquiring policy information to authorize access to a resource and whether that should be part of the protocol. It could be age, location or other non-technical information. Regards, -sm From morgaine.dinova@googlemail.com Mon Oct 5 03:19:11 2009 Return-Path: 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 BF7303A6892 for ; Mon, 5 Oct 2009 03:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 dVJ8nmi1mRDN for ; Mon, 5 Oct 2009 03:19:10 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 7437A3A659A for ; Mon, 5 Oct 2009 03:19:10 -0700 (PDT) Received: by ewy28 with SMTP id 28so4074489ewy.42 for ; Mon, 05 Oct 2009 03:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bEdTFiyoubnS+/Zo8Ai5bcwHBW9yYjl1YSvjt6OQpXI=; b=mRA38js5+E9nJpBrmDtVppe9PiPGWp7bkv0epeCUT/emtEW9zKT6fRbqurfUG6tZLb nHOHN/r6NMrLsKrPr9fEVEeTEX5K69PeKLzK1L4EwusekGK3VXbGDiahIdYTwUYHCEoS ld/Qs0MobVzqAQltWuwC48oBoKVLKgRw0h0cs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=u9KSqg9MYep1+4Ru4ODcXBTE6ZXoF74RdheHQzDzP6RglVFTONQ2cX1yN/vZ40QmFH ZHjH3JZujjDBkDj0SaY7g0OniqcML4IVILrP5HUq+EV+2JQk9lXtC9g0PFJKcp25adhf 6IrH/z3xLdH2qzDZGwU8lu/jQ7HQ+AlA2umRQ= MIME-Version: 1.0 Received: by 10.210.6.8 with SMTP id 8mr4902781ebf.80.1254738042303; Mon, 05 Oct 2009 03:20:42 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20091005015852.03101298@resistor.net> References: <20091003192159.GA7474@alinoe.com> <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910040421y41314922o4c5242c77941af4c@mail.gmail.com> <6.2.5.6.2.20091004072856.031ac940@resistor.net> <4646639E08F58B42836FAC24C94624DD771A0D827E@GVW0433EXB.americas.hpqcorp.net> <6.2.5.6.2.20091005015852.03101298@resistor.net> Date: Mon, 5 Oct 2009 11:20:42 +0100 Message-ID: From: Morgaine To: SM Content-Type: multipart/alternative; boundary=000e0ce0d6404c342204752d77f9 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 10:19:11 -0000 --000e0ce0d6404c342204752d77f9 Content-Type: text/plain; charset=ISO-8859-1 Judging by personal mails received on this topic, I sense that sanity is prevailing, and that there is no desire nor intention to make trigger concepts such as age, sex, race, religion, creed, DNA genome or any other sensitive and/or personal information part of the protocol. It would be the thin end of the wedge, and I'm hoping that people are clever enough not to go there. Services are authenticated. Let that be enough. Morgaine. =================================== On Mon, Oct 5, 2009 at 10:21 AM, SM wrote: > At 09:18 04-10-2009, Dickson, Mike (ISS Software) wrote: > >> Sure it does if I'm required to authenticate to use it. That is, if I'm >> sending using my gmail.com address and I'm required to authenticate to >> use it then yes, its very possible >> to make the association. True, I may be able to find an SMTP server that >> will accept my >> > > That's mail submission. I'll skip the discussion about the analogy. > > At 11:46 04-10-2009, Vaughn Deluca wrote: > >> But the discussion is drifting, were talking about the way that for >> instance an age limit might be passed in the protocol. Carlo said that info >> was needed, Morgaine set it >> has no place in the protocol, using SMTP as an example, Mike stated that >> it is very well >> > > The discussion seems to be about acquiring policy information to authorize > access to a resource and whether that should be part of the protocol. It > could be age, location or other non-technical information. > > Regards, > -sm > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --000e0ce0d6404c342204752d77f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Judging by personal mails received on this topic, I sense that sanity is pr= evailing, and that there is no desire nor intention to make trigger concept= s such as age, sex, race, religion, creed, DNA genome or any other sensitiv= e and/or personal information part of the protocol.

It would be the thin end of the wedge, and I'm hoping that people a= re clever enough not to go there.

Services are authenticated.=A0 Let= that be enough.

Morgaine.





=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

On Mon, Oct 5, 2009 at 10:21 AM, SM <sm@resistor.net> wrote:
At 09:18 04-10-2009, Dickson, Mike (ISS Software) wrote:<= br>
Sure it does if I'm required to authenticate to use it. =A0That is, if = I'm sending using my gma= il.com address and I'm required to authenticate to use it then yes,= its very possible
to make the association. =A0True, I may be able to find an SMTP server that= will accept my

That's mail submission. =A0I'll skip the discussion about the analo= gy.


At 11:46 04-10-2009, Vaughn Deluca wrote:
But the discussion is drifting, =A0were talking about the way that for inst= ance an age limit might be passed in the protocol. =A0Carlo said that info = was needed, Morgaine set it
=A0has no place in the protocol, using SMTP as an example, Mike stated that= it is very well

The discussion seems to be about acquiring policy information to authorize = access to a resource and whether that should be part of the protocol. =A0It= could be age, location or other non-technical information.

Regards,
-sm
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--000e0ce0d6404c342204752d77f9-- From morgaine.dinova@googlemail.com Mon Oct 5 05:28:48 2009 Return-Path: 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 60E6428C12F for ; Mon, 5 Oct 2009 05:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.258 X-Spam-Level: X-Spam-Status: No, score=-0.258 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 PyWqUVXSF1p7 for ; Mon, 5 Oct 2009 05:28:47 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id F02BC28C186 for ; Mon, 5 Oct 2009 05:28:46 -0700 (PDT) Received: by ewy28 with SMTP id 28so4187569ewy.42 for ; Mon, 05 Oct 2009 05:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=39fPTu5elSMZQ4B/aRQRbcZI1if2zRCZXathxsN3xs8=; b=BWDIZE74tNCOZbE8DlMIxW/umWKYa9pK558Mxk43ER2KWdyDvVesdwQZzq2BIWc+T7 bJ7hh6ySyiM5ko9cVAFFGp5E+Xemz8vmWJadTxjs+jgPNkHEEHG5X2qJA3rp3nsTFVbm rc2oFz0NsJk8/WyVwNckuWGQdpTSOM8mXtvtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=GczjztMw1c/gtMAO5jp0a+m9kccAH2jzmN0ESXQXYGptBUAqyotARuNqxaNPy+eSGO ZinvrnQMsyXBhvSk0DvBw9K65EHAccVEodvmUaTomaejfw3zK46hCmveqeMxdoy2PWW2 DM+5k5NgxS7kdnBebEh4YRFd5f4v8NTgW0Q/o= MIME-Version: 1.0 Received: by 10.211.160.4 with SMTP id m4mr6932007ebo.24.1254745818410; Mon, 05 Oct 2009 05:30:18 -0700 (PDT) Date: Mon, 5 Oct 2009 13:30:18 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00504502d38aca31f104752f469c Subject: [ogpx] Virtual worlds versus the real world X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 12:28:48 -0000 --00504502d38aca31f104752f469c Content-Type: text/plain; charset=ISO-8859-1 Given the recent rash of preoccupation with real-world attributes, I think it needs stating that virtual worlds are immensely broader in scope than a mere pixellated 3D re-enactment of the real world with all its historical baggage and petty cultural issues. Our interest is in enabling interop between worlds using our particular protocol, not in prescribing the nature of worlds nor in proscribing others. For those who have not before seen the topic addressed, I suggest you read Henrik Bennetsen's useful summary at http://slcreativity.org/wiki/index.php?title=Augmentation_vs_Immersion . The topic of *augmentism* versus *immersionism* has been discussed in immense detail over many years, and if a single article can be said to capture the essence, Henrik's comes close. If after reading this you are still in denial about the separation of worlds, this positions you as an augmentist, which is a highly coercive worldview. Immersionists affirm that all worlds are possible and separate and non-interfering, so their worldview is inherently inclusive. Supporting virtual worlds in all their diversity and generality requires a broader approach than does a mere re-enactment of the physical world. More specifically, it requires an understanding that only a small subset of virtual worlds reflect the real world, and that trying to force them all to do so is out of place. Morgaine. --00504502d38aca31f104752f469c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Given the recent rash of preoccupation with real-world attributes, I think = it needs stating that virtual worlds are immensely broader in scope than a = mere pixellated 3D re-enactment of the real world with all its historical b= aggage and petty cultural issues.

Our interest is in enabling interop between worlds using our particular= protocol, not in prescribing the nature of worlds nor in proscribing other= s.

For those who have not before seen the topic addressed, I suggest= you read Henrik Bennetsen's useful summary at http://slcreat= ivity.org/wiki/index.php?title=3DAugmentation_vs_Immersion .=A0 The top= ic of augmentism versus immersionism has been d= iscussed in immense detail over many years, and if a single article can be = said to capture the essence, Henrik's comes close. =A0 If after reading= this you are still in denial about the separation of worlds, this position= s you as an augmentist, which is a highly coercive worldview.=A0 Immersioni= sts affirm that all worlds are possible and separate and non-interfering, s= o their worldview is inherently inclusive.

Supporting virtual worlds in all their diversity and generality require= s a broader approach than does a mere re-enactment of the physical world.= =A0 More specifically, it requires an understanding that only a small subse= t of virtual worlds reflect the real world, and that trying to force them a= ll to do so is out of place.


Morgaine.


--00504502d38aca31f104752f469c-- From mike.dickson@hp.com Mon Oct 5 07:47:23 2009 Return-Path: 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 3BCFB3A695F for ; Mon, 5 Oct 2009 07:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 nWAxjYu0i0CK for ; Mon, 5 Oct 2009 07:47:22 -0700 (PDT) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by core3.amsl.com (Postfix) with ESMTP id C35E63A67A1 for ; Mon, 5 Oct 2009 07:47:21 -0700 (PDT) Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 68B1138196; Mon, 5 Oct 2009 14:48:56 +0000 (UTC) Received: from G4W1852.americas.hpqcorp.net (16.234.97.230) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 5 Oct 2009 14:48:52 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G4W1852.americas.hpqcorp.net ([16.234.97.230]) with mapi; Mon, 5 Oct 2009 14:48:52 +0000 From: "Dickson, Mike (ISS Software)" To: Magnus Zeisig , "ogpx@ietf.org" Date: Mon, 5 Oct 2009 14:48:47 +0000 Thread-Topic: Protocol for permitting policy decisions Thread-Index: AcpFmYY7rtB6bOoDTWi+fAneeDEo7QAMJZtg Message-ID: <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> In-Reply-To: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD771A0D8521GVW0433EXBame_" MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 14:47:23 -0000 --_000_4646639E08F58B42836FAC24C94624DD771A0D8521GVW0433EXBame_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBNYWdudXPigJkgbWVzc2FnZSBpcyBhIGdvb2Qgc3lub3BzaXMgb2YgdGhlIHJlcXVp cmVtZW50cywgSU1PLiAgSSBzZWUgYSBuZWVkIHRvIG5lZ290aWF0ZSAqYm90aCogY2FwYWJpbGl0 aWVzIGFuZCBjb25zdHJhaW50cyBpbiB0aGUgcHJvdG9jb2wgd2hlcmUgYm90aCBzaG91bGQgYmUg aWRlYWxseSBhdHRyaWJ1dGVzIGluIGFuIGV4dGVuc2libGUgbGlzdCAodGhhdCBpcyB0aGUgbGlz dCBpc27igJl0IGhhcmQgY29kZWQgaW4gdGhlIHByb3RvY29sIGRlZmluaXRpb24pLiAgU28sIElN TywgYXV0aGVudGljYXRpb24gaXNu4oCZdCBlbm91Z2guICBCZXlvbmQgYXV0aGVudGljYXRpbmcg dGhlcmXigJlzIGFuIGV4Y2hhbmdlIGFyb3VuZCBjYXBzIGFuZCBjb25zdHJhaW50cyB0aGF0IG5l ZWRzIHRvIHRha2UgcGxhY2UuICBJ4oCZZCB1c2UgdGhhdCBtZWNoYW5pc20gdG8gaGFuZGxlIOKA nEFkdWx0IG9ubHnigJ0gcmVnaW9ucywgbWVtYmVyc2hpcCBpbiBhIGdyb3VwIHdoZXJlIHRoZSBn cm91cCBpcyBkZWZpbmVkIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBwcm90b2NvbCwgZXRjLg0K DQpNaWtlDQoNCkZyb206IG9ncHgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9ncHgtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hZ251cyBaZWlzaWcNClNlbnQ6IE1vbmRheSwgT2N0 b2JlciAwNSwgMjAwOSAzOjU1IEFNDQpUbzogb2dweEBpZXRmLm9yZw0KU3ViamVjdDogW29ncHhd IFByb3RvY29sIGZvciBwZXJtaXR0aW5nIHBvbGljeSBkZWNpc2lvbnMNCg0KLS0tLS1CRUdJTiBQ R1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCklmIEkgcmVnaXN0ZXIgd2l0 aCBhbiBhZ2VudCBkb21haW4sIG9yIGF1dGhlbnRpY2F0aW9uIHNlcnZpY2UsIHdoaWNoZXZlciBz aG91bGQgYmUgdGhlIHByb3BlciBuYW1lIGZvciBpdCwgSSB3aWxsIG1vc3QgcHJvYmFibHkgaGFu ZCB0aGVtIHNvbWUgcGllY2VzIG9mIGluZm9ybWF0aW9uIGFib3V0IG15c2VsZiB0aGF0IEkgZG9u J3Qgd2FudCBkaXNzZW1pbmF0ZWQgdG8gYW55b25lLiBUaGVyZWZvcmUsIEkgdGhpbmsgdGhlIHBy b3RvY29sIGZvciBncmFudGluZyBhY2Nlc3MgdG8gcmVnaW9ucyBhbmQgb3RoZXIgc2VydmljZXMg c2hvdWxkIG5vdCBpbmNsdWRlIHN1Y2ggaW5mb3JtYXRpb24gZXhwbGljaXRseSwgYnV0IHJhdGhl ciBsZXQgdGhlIGFnZW50IGRvbWFpbi9hdXRoZW50aWNhdGlvbiBzZXJ2aWNlIGp1c3QgYW5zd2Vy IHF1ZXN0aW9ucyBmcm9tIHRoZSBvdGhlciBkb21haW4vc2VydmljZSBpZiB0aGUgcGFyYW1ldGVy cyBhcmUgd2l0aGluIGFjY2VwdGFibGUgcmFuZ2UuDQoNCkluc3RlYWQgb2YgdGhlIHJldmVhbGlu ZyAobWV0YS1oYW5kc2hha2UpOg0KDQpBZ2VudCBkb21haW46DQpyZXF1ZXN0IGFjY2VzcyBmb3IN CnVzZXI6IFRpdGxlLkZpcnN0TmFtZS5Jbml0aWFscy5MYXN0TmFtZS5FeHRyYVNvbWV0aGluZ0Bh Z2VudGRvbWFpbi5vcmcNCmFnZTogMTgNCmdlbmRlcjogbWFsZQ0Kc2V4dWFsaXR5OiBiaQ0KY291 bnRyeTogcHQNCmxhbmd1YWdlczogcHQsIGVzLCBlbiwgZGUNCmxlbmd0aDogMS44Mg0Kd2VpZ2h0 OiAxMjINCmNvbG9yIG9mIHNvY2tzOiBibHVlDQoNClJlZ2lvbiBkb21haW46DQphY2Nlc3MgZ3Jh bnRlZCBmb3INCnVzZXI6IFRpdGxlLkZpcnN0TmFtZS5Jbml0aWFscy5MYXN0TmFtZS5FeHRyYVNv bWV0aGluZ0BhZ2VudGRvbWFpbi5vcmcNCg0KVGhlIGhhbmRzaGFrZSBzaG91bGQgaW5zdGVhZCBi ZToNCg0KQWdlbnQgZG9tYWluOg0KcmVxdWVzdCBhY2Nlc3MgZm9yDQp1c2VyOiBUaXRsZS5GaXJz dE5hbWUuSW5pdGlhbHMuTGFzdE5hbWUuRXh0cmFTb21ldGhpbmdAYWdlbnRkb21haW4ub3JnDQoN ClJlZ2lvbiBkb21haW46DQpyZXF1aXJlIHBhcmFtZXRlciB2YWx1ZXMNCmxhbmd1YWdlczogZXMg QU5EIChkZSBPUiBoYiBPUiBydSkNCmxlbmd0aDogWzEuMjEtMi40Ml0NCmNvbG9yIG9mIHNvY2tz OiBwaW5rIE9SIGJsdWUgT1IgYmxhY2sNCmhhaXJkbzogc2hhdmVkIE9SIHBvbnl0YWlsDQoNCkFn ZW50IGRvbWFpbjoNCnJlcXVpcmVkIHBhcmFtZXRlciB2YWx1ZXMNCmxhbmd1YWdlczogeWVzDQps ZW5ndGg6IHllcw0KY29sb3Igb2Ygc29ja3M6IHllcw0KaGFpcmRvOiBuL2ENCg0KQWZ0ZXIgd2hp Y2ggdGhlIHJlZ2lvbiBkb21haW4gbWlnaHQgZGVjaWRlIHRoYXQgdGhlIG1pc3NpbmcgaGFpcmRv IHBhcmFtZXRlciBpcyBub3QgY3J1Y2lhbCBhbmQgZ3JhbnQgYWNjZXNzLCBvciByZWZ1c2UgYWNj ZXNzIGJlY2F1c2Ugb2YgaXQ6DQoNClJlZ2lvbiBkb21haW46DQphY2Nlc3MgZGVuaWVkIGZvcg0K dXNlcjogVGl0bGUuRmlyc3ROYW1lLkluaXRpYWxzLkxhc3ROYW1lLkV4dHJhU29tZXRoaW5nQGFn ZW50ZG9tYWluLm9yZw0KDQpUaGlzIGhhcyB0aGUgYmVuZWZpdCBvZiBwZXJtaXR0aW5nIHNlcnZp Y2UgcHJvdmlkZXJzIHRvIHJlcXVpcmUgd2hhdCB1c2VyIHBhcmFtZXRlcnMgdGhleSB0aGluayBh cmUgaW1wb3J0YW50LCBiZSBpdCBhZ2Ugb3IgY29sb3Igb2Ygc29ja3MsIGJ1dCB0aGUgZGlzYWR2 YW50YWdlIG9mIHNvbWUgZXh0cmEgb3ZlcmhlYWQgYW5kIHRoZSByaXNrIG9mIGJhbGthbml6YXRp b24gYmVjYXVzZSBvZiByZXF1aXJlbWVudHMgb2YgIm9kZCIgcGFyYW1ldGVycyBvbmx5IHN1cHBv cnRlZCBieSBmZXcgc2VydmljZXMuIFRoZSBsYXR0ZXIsIGhvd2V2ZXIsIEkgYmVsaWV2ZSB3aWxs IGJlY29tZSBzZWxmLWVsaW1pbmF0aW5nLCBiZWNhdXNlIHN1Y2ggc2VydmljZXMgd2lsbCBwcm9i YWJseSBub3QgZmluZCBtYW55IHVzZXJzLiBFaXRoZXIgd2F5LCBJIGRvbid0IHRoaW5rIHRoZSBw cm90b2NvbCBpbiBpdHNlbGYgc2hvdWxkIHJlcXVpcmUgYW55IHBhcnRpY3VsYXIgcGFyYW1ldGVy cywgbGlrZSBhZ2Ugb3IgY29sb3Igb2Ygc29ja3MsIGp1c3QgcHJvdmlkZSB0aGUgbWVhbnMgdG8g Y29tbXVuaWNhdGUgYW55IHBhcmFtZXRlcnMsIGFuZCBwZXJoYXBzIHN1Z2dlc3QgYSBsaXN0IG9m IHBvc3NpYmxlLCBidXQgbm90IHJlcXVpcmVkLCBwYXJhbWV0ZXJzIGFuZCBmb3JtYXRzIGZvciB2 YWx1ZXMsIGxpa2Ugb3B0aW9ucywgcmFuZ2VzIGFuZCBlbnVtZXJhdGlvbnMuIFRoZSBzYW1lIGtp bmQgb2YgaGFuZHNoYWtlIGNvdWxkIGFsc28gYmUgdXNlZCB3aGVuIHJlcXVlc3RpbmcgYWNjZXNz IHRvIGFzc2V0IHNlcnZpY2VzIGFuZCB0aGUgbGlrZSwgZXZlbiBpZiBwYXJhbWV0ZXJzIGxpa2Ug Im9iamVjdCB0eXBlcyIgYW5kICJpcCBhZ3JlZW1lbnRzIiBtYXkgYmUgbW9yZSBpbXBvcnRhbnQg dGhhbiAiY29sb3Igb2Ygc29ja3MiIHRoZXJlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCk1hZ251cw0K DQoNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiA5LjguMyAoQnVpbGQg NDAyOCkNCkNoYXJzZXQ6IHV0Zi04DQoNCndzQlZBd1VCU3NtMGNPNU1sVTlYeWFpU0FRZ0VnQWdB aU5pem5aYTRmSk4raUltNEx1bDRpVXBQTnl0ZXhuOWcNCnJKV0xaNG9ldmV3bmd2U0NPd2hzbHNl WEtOK09UQ1VwU1BxMHZHeFJJbDU4bit1OVA1NnEwWDRwWUJaNXdzcWMNCllBUGRkNnpHdFFwUisy MVhROG9XTTk0OExFZEd4YmE4bU5PMWdEeWdxdEl5eDBzdUJZa3ZZVVd5WWl0d2xEcHUNCm9mdkRl dytKVDE0MEFwbVgvZDFkVHlnbHh5WXY2cW5EZjhpRHNIc05pV1lJMUltQjVhL2h2UEswVGtDVkZ2 enINCnZMWGZMNUJmQ1hLMEkzdEpiTHB2L09vVUZFbjUvZW16ZWh1M3VhdnVRZlFxUU0wdUJwdzhX VlNRR1hxWnppS2INCjZpOFlwRHZCcklrTkw0c3lHaG1BczdaTFVxcFpFZm9XcTJMYkdhc3FoVk1t RENCa2FrclBwZz09DQo9SDJGag0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQoNCg0K --_000_4646639E08F58B42836FAC24C94624DD771A0D8521GVW0433EXBame_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuZW1haWxxdW90ZSwgbGkuZW1h aWxxdW90ZSwgZGl2LmVtYWlscXVvdGUNCgl7bXNvLXN0eWxlLW5hbWU6ZW1haWxxdW90ZTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjEuMHB0Ow0KCWJvcmRlcjpub25lOw0KCXBh ZGRpbmc6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LlNlY3Rpb24xDQoJe3Bh Z2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQog PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxp bms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+SSB0aGluayBNYWdudXPigJkgbWVz c2FnZSBpcyBhIGdvb2Qgc3lub3BzaXMgb2YgdGhlIHJlcXVpcmVtZW50cywNCklNTy7CoCBJIHNl ZSBhIG5lZWQgdG8gbmVnb3RpYXRlICo8Yj5ib3RoPC9iPiogY2FwYWJpbGl0aWVzIGFuZCBjb25z dHJhaW50cyBpbg0KdGhlIHByb3RvY29sIHdoZXJlIGJvdGggc2hvdWxkIGJlIGlkZWFsbHkgYXR0 cmlidXRlcyBpbiBhbiBleHRlbnNpYmxlIGxpc3QNCih0aGF0IGlzIHRoZSBsaXN0IGlzbuKAmXQg aGFyZCBjb2RlZCBpbiB0aGUgcHJvdG9jb2wgZGVmaW5pdGlvbikuwqAgU28sIElNTywNCmF1dGhl bnRpY2F0aW9uIGlzbuKAmXQgZW5vdWdoLsKgIEJleW9uZCBhdXRoZW50aWNhdGluZyB0aGVyZeKA mXMgYW4gZXhjaGFuZ2UgYXJvdW5kIGNhcHMNCmFuZCBjb25zdHJhaW50cyB0aGF0IG5lZWRzIHRv IHRha2UgcGxhY2UuwqAgSeKAmWQgdXNlIHRoYXQgbWVjaGFuaXNtIHRvIGhhbmRsZSDigJxBZHVs dA0Kb25seeKAnSByZWdpb25zLCBtZW1iZXJzaGlwIGluIGEgZ3JvdXAgd2hlcmUgdGhlIGdyb3Vw IGlzIGRlZmluZWQgb3V0c2lkZSB0aGUNCnNjb3BlIG9mIHRoZSBwcm90b2NvbCwgZXRjLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KY29sb3I6IzFGNDk3RCc+TWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gb2dweC1ib3VuY2VzQGlldGYub3JnDQpbbWFpbHRv Om9ncHgtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5NYWdudXMgWmVpc2ln PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAwNSwgMjAwOSAzOjU1IEFNPGJyPg0K PGI+VG86PC9iPiBvZ3B4QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtvZ3B4XSBQcm90 b2NvbCBmb3IgcGVybWl0dGluZyBwb2xpY3kgZGVjaXNpb25zPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6LjVpbic+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+LS0tLS1CRUdJTiBQR1Ag U0lHTkVEIE1FU1NBR0UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxk aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+SGFzaDogU0hBMjU2PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPklmIEkgcmVnaXN0 ZXIgd2l0aCBhbiBhZ2VudCBkb21haW4sIG9yDQphdXRoZW50aWNhdGlvbiBzZXJ2aWNlLCB3aGlj aGV2ZXIgc2hvdWxkIGJlIHRoZSBwcm9wZXIgbmFtZSBmb3IgaXQsIEkgd2lsbCBtb3N0DQpwcm9i YWJseSBoYW5kIHRoZW0gc29tZSBwaWVjZXMgb2YgaW5mb3JtYXRpb24gYWJvdXQgbXlzZWxmIHRo YXQgSSBkb24ndCB3YW50DQpkaXNzZW1pbmF0ZWQgdG8gYW55b25lLiBUaGVyZWZvcmUsIEkgdGhp bmsgdGhlIHByb3RvY29sIGZvciBncmFudGluZyBhY2Nlc3MgdG8NCnJlZ2lvbnMgYW5kIG90aGVy IHNlcnZpY2VzIHNob3VsZCBub3QgaW5jbHVkZSBzdWNoIGluZm9ybWF0aW9uIGV4cGxpY2l0bHks IGJ1dA0KcmF0aGVyIGxldCB0aGUgYWdlbnQgZG9tYWluL2F1dGhlbnRpY2F0aW9uIHNlcnZpY2Ug anVzdCBhbnN3ZXIgcXVlc3Rpb25zIGZyb20NCnRoZSBvdGhlciBkb21haW4vc2VydmljZSBpZiB0 aGUgcGFyYW1ldGVycyBhcmUgd2l0aGluIGFjY2VwdGFibGUgcmFuZ2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0 Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPkluc3RlYWQgb2YgdGhlIHJldmVhbGluZyAobWV0YS1oYW5kc2hha2Up OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5BZ2VudCBkb21haW46PG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5yZXF1ZXN0IGFjY2VzcyBmb3I8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPnVzZXI6DQpUaXRsZS5GaXJzdE5hbWUuSW5p dGlhbHMuTGFzdE5hbWUuRXh0cmFTb21ldGhpbmdAYWdlbnRkb21haW4ub3JnPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5hZ2U6IDE4PG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz5nZW5kZXI6IG1hbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0 Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPnNleHVhbGl0eTogYmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41 aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiInPmNvdW50cnk6IHB0PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz5sYW5ndWFnZXM6IHB0LCBlcywgZW4sIGRlPG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz5sZW5ndGg6IDEuODI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41 aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiInPndlaWdodDogMTIyPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz5jb2xvciBvZiBzb2NrczogYmx1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVp bic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz5SZWdpb24gZG9tYWluOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ YWNjZXNzIGdyYW50ZWQgZm9yPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Jz51c2VyOg0KVGl0bGUuRmlyc3ROYW1lLkluaXRpYWxzLkxhc3ROYW1lLkV4dHJhU29tZXRoaW5n QGFnZW50ZG9tYWluLm9yZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5UaGUgaGFuZHNo YWtlIHNob3VsZCBpbnN0ZWFkIGJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5BZ2Vu dCBkb21haW46PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5yZXF1ZXN0 IGFjY2VzcyBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPnVzZXI6 DQpUaXRsZS5GaXJzdE5hbWUuSW5pdGlhbHMuTGFzdE5hbWUuRXh0cmFTb21ldGhpbmdAYWdlbnRk b21haW4ub3JnPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlJlZ2lvbiBkb21haW46PG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5yZXF1aXJlIHBhcmFtZXRlciB2 YWx1ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmxhbmd1YWdlczog ZXMgQU5EIChkZSBPUiBoYiBPUiBydSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0K DQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiInPmxlbmd0aDogWzEuMjEtMi40Ml08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPmNvbG9yIG9mIHNvY2tzOiBwaW5rIE9SIGJsdWUgT1IgYmxhY2s8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmhhaXJkbzogc2hhdmVkIE9SIHBvbnl0YWls PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkFnZW50IGRvbWFpbjo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPnJlcXVpcmVkIHBhcmFtZXRlciB2YWx1ZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPmxhbmd1YWdlczogeWVzPG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsN CmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5sZW5ndGg6IHllczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Y29sb3Igb2Ygc29ja3M6IHllczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+aGFpcmRvOiBuL2E8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+QWZ0ZXIgd2hpY2ggdGhlIHJlZ2lvbiBkb21haW4gbWlnaHQgZGVj aWRlDQp0aGF0IHRoZSBtaXNzaW5nIGhhaXJkbyBwYXJhbWV0ZXIgaXMgbm90IGNydWNpYWwgYW5k IGdyYW50IGFjY2Vzcywgb3IgcmVmdXNlDQphY2Nlc3MgYmVjYXVzZSBvZiBpdDo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+UmVnaW9uIGRvbWFpbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1s ZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiInPmFjY2VzcyBkZW5pZWQgZm9yPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t bGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz51c2VyOg0KVGl0bGUuRmlyc3ROYW1lLkluaXRpYWxzLkxhc3RO YW1lLkV4dHJhU29tZXRoaW5nQGFnZW50ZG9tYWluLm9yZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxl ZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiJz5UaGlzIGhhcyB0aGUgYmVuZWZpdCBvZiBwZXJtaXR0aW5nIHNlcnZpY2UNCnByb3Zp ZGVycyB0byByZXF1aXJlIHdoYXQgdXNlciBwYXJhbWV0ZXJzIHRoZXkgdGhpbmsgYXJlIGltcG9y dGFudCwgYmUgaXQgYWdlDQpvciBjb2xvciBvZiBzb2NrcywgYnV0IHRoZSBkaXNhZHZhbnRhZ2Ug b2Ygc29tZSBleHRyYSBvdmVyaGVhZCBhbmQgdGhlIHJpc2sgb2YNCmJhbGthbml6YXRpb24gYmVj YXVzZSBvZiByZXF1aXJlbWVudHMgb2YgJnF1b3Q7b2RkJnF1b3Q7IHBhcmFtZXRlcnMgb25seQ0K c3VwcG9ydGVkIGJ5IGZldyBzZXJ2aWNlcy4gVGhlIGxhdHRlciwgaG93ZXZlciwgSSBiZWxpZXZl IHdpbGwgYmVjb21lDQpzZWxmLWVsaW1pbmF0aW5nLCBiZWNhdXNlIHN1Y2ggc2VydmljZXMgd2ls bCBwcm9iYWJseSBub3QgZmluZCBtYW55IHVzZXJzLg0KRWl0aGVyIHdheSwgSSBkb24ndCB0aGlu ayB0aGUgcHJvdG9jb2wgaW4gaXRzZWxmIHNob3VsZCByZXF1aXJlIGFueSBwYXJ0aWN1bGFyDQpw YXJhbWV0ZXJzLCBsaWtlIGFnZSBvciBjb2xvciBvZiBzb2NrcywganVzdCBwcm92aWRlIHRoZSBt ZWFucyB0byBjb21tdW5pY2F0ZQ0KYW55IHBhcmFtZXRlcnMsIGFuZCBwZXJoYXBzIHN1Z2dlc3Qg YSBsaXN0IG9mIHBvc3NpYmxlLCBidXQgbm90IHJlcXVpcmVkLA0KcGFyYW1ldGVycyBhbmQgZm9y bWF0cyBmb3IgdmFsdWVzLCBsaWtlIG9wdGlvbnMsIHJhbmdlcyBhbmQgZW51bWVyYXRpb25zLiBU aGUNCnNhbWUga2luZCBvZiBoYW5kc2hha2UgY291bGQgYWxzbyBiZSB1c2VkIHdoZW4gcmVxdWVz dGluZyBhY2Nlc3MgdG8gYXNzZXQNCnNlcnZpY2VzIGFuZCB0aGUgbGlrZSwgZXZlbiBpZiBwYXJh bWV0ZXJzIGxpa2UgJnF1b3Q7b2JqZWN0IHR5cGVzJnF1b3Q7IGFuZA0KJnF1b3Q7aXAgYWdyZWVt ZW50cyZxdW90OyBtYXkgYmUgbW9yZSBpbXBvcnRhbnQgdGhhbiAmcXVvdDtjb2xvciBvZiBzb2Nr cyZxdW90Ow0KdGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkJlc3QgcmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+TWFnbnVzPG86cD48L286cD48L3NwYW4+ PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tbGVmdDouNWluJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41 aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxk aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Iic+LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0 Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPlZlcnNpb246IDkuOC4zIChCdWlsZCA0MDI4KTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Q2hhcnNldDogdXRmLTg8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+d3NCVkF3VUJTc20wY081TWxVOVh5YWlTQVFnRWdBZ0FpTml6blphNGZK TitpSW00THVsNGlVcFBOeXRleG45ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIic+ckpXTFo0b2V2ZXduZ3ZTQ093aHNsc2VYS04rT1RDVXBTUHEwdkd4UklsNThuK3U5UDU2 cTBYNHBZQlo1d3NxYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+WUFQ ZGQ2ekd0UXBSKzIxWFE4b1dNOTQ4TEVkR3hiYThtTk8xZ0R5Z3F0SXl4MHN1QllrdllVV3lZaXR3 bERwdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+b2Z2RGV3K0pUMTQw QXBtWC9kMWRUeWdseHlZdjZxbkRmOGlEc0hzTmlXWUkxSW1CNWEvaHZQSzBUa0NWRnZ6cjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+dkxYZkw1QmZDWEswSTN0SmJMcHYv T29VRkVuNS9lbXplaHUzdWF2dVFmUXFRTTB1QnB3OFdWU1FHWHFaemlLYjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Nmk4WXBEdkJySWtOTDRzeUdobUFzN1pMVXFwWkVm b1dxMkxiR2FzcWhWTW1EQ0JrYWtyUHBnPT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPj1IMkZqPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVmdDouNWluJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4t LS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvYm9k eT4NCg0KPC9odG1sPg0K --_000_4646639E08F58B42836FAC24C94624DD771A0D8521GVW0433EXBame_-- From mike.dickson@hp.com Mon Oct 5 07:57:43 2009 Return-Path: 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 130683A69F9 for ; Mon, 5 Oct 2009 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.515 X-Spam-Level: X-Spam-Status: No, score=-106.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 D+BxWjpvTwQ6 for ; Mon, 5 Oct 2009 07:57:38 -0700 (PDT) Received: from g5t0008.atlanta.hp.com (g5t0008.atlanta.hp.com [15.192.0.45]) by core3.amsl.com (Postfix) with ESMTP id 6A2543A699C for ; Mon, 5 Oct 2009 07:57:38 -0700 (PDT) Received: from G6W0640.americas.hpqcorp.net (g6w0640.atlanta.hp.com [16.230.34.76]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0008.atlanta.hp.com (Postfix) with ESMTPS id 2A7A3241D5; Mon, 5 Oct 2009 14:59:13 +0000 (UTC) Received: from G3W0055.americas.hpqcorp.net (16.232.1.152) by G6W0640.americas.hpqcorp.net (16.230.34.76) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 5 Oct 2009 14:59:06 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G3W0055.americas.hpqcorp.net ([16.232.1.152]) with mapi; Mon, 5 Oct 2009 14:59:02 +0000 From: "Dickson, Mike (ISS Software)" To: Morgaine , "ogpx@ietf.org" Date: Mon, 5 Oct 2009 14:59:00 +0000 Thread-Topic: [ogpx] Virtual worlds versus the real world Thread-Index: AcpFt540ugPfaPZgTICesfA75PKqtQAE8b7Q Message-ID: <4646639E08F58B42836FAC24C94624DD771A0D8549@GVW0433EXB.americas.hpqcorp.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD771A0D8549GVW0433EXBame_" MIME-Version: 1.0 Subject: Re: [ogpx] Virtual worlds versus the real world X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 14:57:43 -0000 --_000_4646639E08F58B42836FAC24C94624DD771A0D8549GVW0433EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of Mor= gaine Sent: Monday, October 05, 2009 7:30 AM To: ogpx@ietf.org Subject: [ogpx] Virtual worlds versus the real world [snip] For those who have not before seen the topic addressed, I suggest you read = Henrik Bennetsen's useful summary at http://slcreativity.org/wiki/index.php= ?title=3DAugmentation_vs_Immersion . The topic of augmentism versus immers= ionism has been discussed in immense detail over many years, and if a singl= e article can be said to capture the essence, Henrik's comes close. If af= ter reading this you are still in denial about the separation of worlds, th= is positions you as an augmentist, which is a highly coercive worldview. I= mmersionists affirm that all worlds are possible and separate and non-inter= fering, so their worldview is inherently inclusive. Henrik's summary is indeed well written and a good synopsis. I guess I fee= l like given the wide range of possible use cases for virtual worlds both m= odels are "correct". So nothing in the protocol should preclude either ap= proach but IMO conversely the distinction is almost unimportant at the prot= ocol level. As long as there's a mechanism for the AD/RD to negotiate with= the client the caps/constraints in play and a way to represent and visuali= ze the in world content the VW content developer (which may be its users) s= hould be free to evolve as appropriate for that VW context. Mike --_000_4646639E08F58B42836FAC24C94624DD771A0D8549GVW0433EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of Morgaine
Sent: Monday, October 05, 2009 7:30 AM
To: ogpx@ietf.org
Subject: [ogpx] Virtual worlds versus the real world

 

[snip]


For those who have not before seen the topic addressed, I suggest you read Henrik Bennetsen's useful summary at http://slcreativity.org/wiki/index.php?title=3DAugmentation_vs_Immer= sion .  The topic of augmentism versus immersionism= has been discussed in immense detail over many years, and if a single artic= le can be said to capture the essence, Henrik's comes close.   If after reading this you are still in denial about the separation of worlds, this positions you as an augmentist, which is a highly coercive worldview. = Immersionists affirm that all worlds are possible and separate and non-interfering, so th= eir worldview is inherently inclusive.=

Henrik’s summary is indeed well written and a good synopsis.  I guess I feel like given the wide range of possible use ca= ses for virtual worlds both models are “correct”.   So nothing in the protocol should preclude either approach but IMO conversely = the distinction is almost unimportant at the protocol level.  As long as t= here’s a mechanism for the AD/RD to negotiate with the client the caps/constraints= in play and a way to represent and visualize the in world content the VW conte= nt developer (which may be its users) should be free to evolve as appropriate = for that VW context.

 

Mike

 

--_000_4646639E08F58B42836FAC24C94624DD771A0D8549GVW0433EXBame_-- From meadhbh.siobhan@gmail.com Mon Oct 5 09:31:04 2009 Return-Path: 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 2561D28C20F for ; Mon, 5 Oct 2009 09:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] 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 9BKGvFYW-nxR for ; Mon, 5 Oct 2009 09:31:03 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 5329328C22F for ; Mon, 5 Oct 2009 09:31:02 -0700 (PDT) Received: by pzk4 with SMTP id 4so3060460pzk.32 for ; Mon, 05 Oct 2009 09:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3yiraq0iWXWtsIF6dmd6DjWgGc8mjW8R3Q24lmu3rUI=; b=WRoZ2x9gJmEZLFH1ak8vfZ3W+val5NZy6YVCqjawFUxuoTLEmTvYEcYXwyVwqHioqM kRAqbBAUenlGD83VBgFMkNSAvC21ZMSXtS7XRWHIrugQmIX6oel2yD5As8yLXtUzhkjU W1v/pbN9n1xohSsW5QW1+NmLQAOpdWtdFGxJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SS8PL0LNv6Yqy4p7KtSfNql0VKm7s5Vef6fS6PHPwHoXraqgf+TsLURXkbTTxvYC7h /jdR2tGCH2GS8nieQi6GZ/8Bimxhy4qDSCa6t0C4205UFXQD5X23H832Ectqe9HA4Udf A6BUp0QKXlA5Jb8QwUeqwHFOH06wYDQJbi2Ss= MIME-Version: 1.0 Received: by 10.114.86.2 with SMTP id j2mr319153wab.159.1254760354910; Mon, 05 Oct 2009 09:32:34 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> Date: Mon, 5 Oct 2009 09:32:34 -0700 Message-ID: From: Meadhbh Siobhan To: "Dickson, Mike (ISS Software)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 16:31:04 -0000 again, this is a matter of policy, not a matter of protocol. let me give you a counter example. some trusted organization, maybe the new zealand sea scouts, decides it wants a virtual social space to teach seamanship, knot tying and whatever else scouts are taught these days. the sea scouts organization is not really known for it's ability to maintain a reasonably large networking and system infrastructure, so instead of building the service themselves, they outsource. at this point, there are a couple of options open to them. they can give their entire user database to a third party and hope for the best. or they can give portions of their user database (name, email address, adult / minor boolean.) or they could put a VWRAP authentication service that they maintain in front of their user database. each are valid options. one would hope that in the first two options, they worked out with the third party some pretty hard-core data retention and privacy policies. so what if they did the third option? what would the protocol have to do? the sea scout's agent domain would only allow agents to enter a private virtual world. the sea scouts would negotiate with their region domain provider to ensure that adult content was not allowed in the regions accessible by the sea scout agent domain. moreover, the region domain provider could ensure that ONLY agents with accounts from the sea scouts would get access to the sea scouts virtual spaces. so the answer to the question of "what does the protocol have to do?" is that it only has to convey information about the identity of the agent domain to the region provider. it also has to have a mechanism for the agent domain to identify the region. but the protocol itself does not impose restrictions as to the identity of either party. that is a policy issue. in other words, if you don't want to use an agent domain / region domain pair that provides information about you to a trusted third party, don't give that information the the agent domain in the first place. or double check that the agent domain's privacy policy requires third parties to which it reveals information to treat that information with due care. that being said, some people's paranoia level is higher than others, so maybe we could have multiple techniques defined for sharing sensitive information, none of which are mandatory. -cheers -meadhbh On Mon, Oct 5, 2009 at 7:48 AM, Dickson, Mike (ISS Software) wrote: > I think Magnus=92 message is a good synopsis of the requirements, IMO.=A0= I see > a need to negotiate *both* capabilities and constraints in the protocol > where both should be ideally attributes in an extensible list (that is th= e > list isn=92t hard coded in the protocol definition).=A0 So, IMO, authenti= cation > isn=92t enough.=A0 Beyond authenticating there=92s an exchange around cap= s and > constraints that needs to take place.=A0 I=92d use that mechanism to hand= le > =93Adult only=94 regions, membership in a group where the group is define= d > outside the scope of the protocol, etc. > > > > Mike > > > > From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of > Magnus Zeisig > Sent: Monday, October 05, 2009 3:55 AM > To: ogpx@ietf.org > Subject: [ogpx] Protocol for permitting policy decisions > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > If I register with an agent domain, or authentication service, whichever > should be the proper name for it, I will most probably hand them some pie= ces > of information about myself that I don't want disseminated to anyone. > Therefore, I think the protocol for granting access to regions and other > services should not include such information explicitly, but rather let t= he > agent domain/authentication service just answer questions from the other > domain/service if the parameters are within acceptable range. > > > > Instead of the revealing (meta-handshake): > > > > Agent domain: > > request access for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > age: 18 > > gender: male > > sexuality: bi > > country: pt > > languages: pt, es, en, de > > length: 1.82 > > weight: 122 > > color of socks: blue > > > > Region domain: > > access granted for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > The handshake should instead be: > > > > Agent domain: > > request access for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > Region domain: > > require parameter values > > languages: es AND (de OR hb OR ru) > > length: [1.21-2.42] > > color of socks: pink OR blue OR black > > hairdo: shaved OR ponytail > > > > Agent domain: > > required parameter values > > languages: yes > > length: yes > > color of socks: yes > > hairdo: n/a > > > > After which the region domain might decide that the missing hairdo parame= ter > is not crucial and grant access, or refuse access because of it: > > > > Region domain: > > access denied for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > This has the benefit of permitting service providers to require what user > parameters they think are important, be it age or color of socks, but the > disadvantage of some extra overhead and the risk of balkanization because= of > requirements of "odd" parameters only supported by few services. The latt= er, > however, I believe will become self-eliminating, because such services wi= ll > probably not find many users. Either way, I don't think the protocol in > itself should require any particular parameters, like age or color of soc= ks, > just provide the means to communicate any parameters, and perhaps suggest= a > list of possible, but not required, parameters and formats for values, li= ke > options, ranges and enumerations. The same kind of handshake could also b= e > used when requesting access to asset services and the like, even if > parameters like "object types" and "ip agreements" may be more important > than "color of socks" there. > > > > Best regards, > > > > Magnus > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: 9.8.3 (Build 4028) > > Charset: utf-8 > > > > wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g > > rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc > > YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu > > ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr > > vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb > > 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg=3D=3D > > =3DH2Fj > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From mike.dickson@hp.com Mon Oct 5 10:11:21 2009 Return-Path: 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 4B47328C208 for ; Mon, 5 Oct 2009 10:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 hxxf11xg-RGy for ; Mon, 5 Oct 2009 10:11:18 -0700 (PDT) Received: from g5t0009.atlanta.hp.com (g5t0009.atlanta.hp.com [15.192.0.46]) by core3.amsl.com (Postfix) with ESMTP id 5F0CD3A6990 for ; Mon, 5 Oct 2009 10:11:18 -0700 (PDT) Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0009.atlanta.hp.com (Postfix) with ESMTPS id ED74B301A5; Mon, 5 Oct 2009 17:12:52 +0000 (UTC) Received: from G4W1852.americas.hpqcorp.net (16.234.97.230) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 5 Oct 2009 17:12:08 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G4W1852.americas.hpqcorp.net ([16.234.97.230]) with mapi; Mon, 5 Oct 2009 17:12:08 +0000 From: "Dickson, Mike (ISS Software)" To: Meadhbh Siobhan Date: Mon, 5 Oct 2009 17:12:03 +0000 Thread-Topic: [ogpx] Protocol for permitting policy decisions Thread-Index: AcpF2XH5dI2WnjnFRNmfn/a1KztSLAABCkIA Message-ID: <4646639E08F58B42836FAC24C94624DD771A156244@GVW0433EXB.americas.hpqcorp.net> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 17:11:21 -0000 I think I buy it in the case you put forward. That is if you simplify the = problem so that AD itself specifies the constraint (the AD in your example = only carries accounts from the sea scouts). But what if I'm running multip= le regions with different policies all served by a single AD? Are you sugge= sting that each region needs to handle the policy for its own? Picking on what is probably a corner case but one that's been raised... If= I'm running multiple regions, some of which are "Adult" and some are not, = does treating constraints as outside the protocol require each RD to do the= age verification (I could make a case the answer is yes since "Adultness" = might differ depending on who/where I am). And if so how do they do that w= ithout getting "sensitive information" that is probably best owned by the A= D. Is it reasonable perhaps for a RD to delegate that to the AD and provid= e a mechanism to negotiate the details on connect so I can centralize such = decisions in a single place? Mike -----Original Message----- From: Meadhbh Siobhan [mailto:meadhbh.siobhan@gmail.com]=20 Sent: Monday, October 05, 2009 11:33 AM To: Dickson, Mike (ISS Software) Cc: Magnus Zeisig; ogpx@ietf.org Subject: Re: [ogpx] Protocol for permitting policy decisions again, this is a matter of policy, not a matter of protocol. let me give you a counter example. some trusted organization, maybe the new zealand sea scouts, decides it wants a virtual social space to teach seamanship, knot tying and whatever else scouts are taught these days. the sea scouts organization is not really known for it's ability to maintain a reasonably large networking and system infrastructure, so instead of building the service themselves, they outsource. at this point, there are a couple of options open to them. they can give their entire user database to a third party and hope for the best. or they can give portions of their user database (name, email address, adult / minor boolean.) or they could put a VWRAP authentication service that they maintain in front of their user database. each are valid options. one would hope that in the first two options, they worked out with the third party some pretty hard-core data retention and privacy policies. so what if they did the third option? what would the protocol have to do? the sea scout's agent domain would only allow agents to enter a private virtual world. the sea scouts would negotiate with their region domain provider to ensure that adult content was not allowed in the regions accessible by the sea scout agent domain. moreover, the region domain provider could ensure that ONLY agents with accounts from the sea scouts would get access to the sea scouts virtual spaces. so the answer to the question of "what does the protocol have to do?" is that it only has to convey information about the identity of the agent domain to the region provider. it also has to have a mechanism for the agent domain to identify the region. but the protocol itself does not impose restrictions as to the identity of either party. that is a policy issue. in other words, if you don't want to use an agent domain / region domain pair that provides information about you to a trusted third party, don't give that information the the agent domain in the first place. or double check that the agent domain's privacy policy requires third parties to which it reveals information to treat that information with due care. that being said, some people's paranoia level is higher than others, so maybe we could have multiple techniques defined for sharing sensitive information, none of which are mandatory. -cheers -meadhbh On Mon, Oct 5, 2009 at 7:48 AM, Dickson, Mike (ISS Software) wrote: > I think Magnus' message is a good synopsis of the requirements, IMO.=A0 I= see > a need to negotiate *both* capabilities and constraints in the protocol > where both should be ideally attributes in an extensible list (that is th= e > list isn't hard coded in the protocol definition).=A0 So, IMO, authentica= tion > isn't enough.=A0 Beyond authenticating there's an exchange around caps an= d > constraints that needs to take place.=A0 I'd use that mechanism to handle > "Adult only" regions, membership in a group where the group is defined > outside the scope of the protocol, etc. > > > > Mike > > > > From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of > Magnus Zeisig > Sent: Monday, October 05, 2009 3:55 AM > To: ogpx@ietf.org > Subject: [ogpx] Protocol for permitting policy decisions > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > If I register with an agent domain, or authentication service, whichever > should be the proper name for it, I will most probably hand them some pie= ces > of information about myself that I don't want disseminated to anyone. > Therefore, I think the protocol for granting access to regions and other > services should not include such information explicitly, but rather let t= he > agent domain/authentication service just answer questions from the other > domain/service if the parameters are within acceptable range. > > > > Instead of the revealing (meta-handshake): > > > > Agent domain: > > request access for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > age: 18 > > gender: male > > sexuality: bi > > country: pt > > languages: pt, es, en, de > > length: 1.82 > > weight: 122 > > color of socks: blue > > > > Region domain: > > access granted for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > The handshake should instead be: > > > > Agent domain: > > request access for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > Region domain: > > require parameter values > > languages: es AND (de OR hb OR ru) > > length: [1.21-2.42] > > color of socks: pink OR blue OR black > > hairdo: shaved OR ponytail > > > > Agent domain: > > required parameter values > > languages: yes > > length: yes > > color of socks: yes > > hairdo: n/a > > > > After which the region domain might decide that the missing hairdo parame= ter > is not crucial and grant access, or refuse access because of it: > > > > Region domain: > > access denied for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > This has the benefit of permitting service providers to require what user > parameters they think are important, be it age or color of socks, but the > disadvantage of some extra overhead and the risk of balkanization because= of > requirements of "odd" parameters only supported by few services. The latt= er, > however, I believe will become self-eliminating, because such services wi= ll > probably not find many users. Either way, I don't think the protocol in > itself should require any particular parameters, like age or color of soc= ks, > just provide the means to communicate any parameters, and perhaps suggest= a > list of possible, but not required, parameters and formats for values, li= ke > options, ranges and enumerations. The same kind of handshake could also b= e > used when requesting access to asset services and the like, even if > parameters like "object types" and "ip agreements" may be more important > than "color of socks" there. > > > > Best regards, > > > > Magnus > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: 9.8.3 (Build 4028) > > Charset: utf-8 > > > > wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g > > rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc > > YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu > > ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr > > vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb > > 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg=3D=3D > > =3DH2Fj > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From morgaine.dinova@googlemail.com Mon Oct 5 10:52:50 2009 Return-Path: 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 7BE613A6947 for ; Mon, 5 Oct 2009 10:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.541 X-Spam-Level: X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 UaqN7t6+mms8 for ; Mon, 5 Oct 2009 10:52:48 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 78F6628C1CD for ; Mon, 5 Oct 2009 10:52:47 -0700 (PDT) Received: by ewy10 with SMTP id 10so3307501ewy.9 for ; Mon, 05 Oct 2009 10:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vmvXUWGLV6Fau9PoX0iG3dWO0sQZGWQhnV0++YCNedo=; b=BZu6ik5H2WlV4YjKuP8QI7+rXp6DyrRVS5PiKk8LO8s5MIkQrSIwXMKUA6u1U5oQ9j VuDcXU4NX7A2SWzdtc/njs/Yoql7WARKhiCuX7zkuyESYhPppbqxMYuOMkAeWeEvJuR5 U8MvYZKMcSraO3z7+5+/O6F+sHssTIKZc3bJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MHGqXejFMT2Cl2/x0LyZ2lSbtcEpTrXcz6LXxTphGJrTEblQ7WJsHkg0oefO//wN5Z hBjXHH/gDxNoS7U66ePy1P1dEuoDBVspUQzZzuKp+rznCK+bS+CzANtAC0lWi3xwPTuT Dm1fn1boZWCfjRbIhXK1QspQ0QcqK1Nzq6fbc= MIME-Version: 1.0 Received: by 10.210.7.23 with SMTP id 23mr355777ebg.27.1254765258617; Mon, 05 Oct 2009 10:54:18 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> Date: Mon, 5 Oct 2009 18:54:18 +0100 Message-ID: From: Morgaine To: "Dickson, Mike (ISS Software)" Content-Type: multipart/alternative; boundary=000e0cdfd7e68433c9047533cd6c Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 17:52:50 -0000 --000e0cdfd7e68433c9047533cd6c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You're opening up a can of worms of biblical proportions here, Mike. What in hell's teeth is an "Adult only region"? Who gets to define it? Under what rules? In what legal jurisdiction? And those are just the simplest questions, pertaining to worlds that are merely reflections of the physical world. What about virtual worlds that intentionally maintain separation from RL, bearing in mind the recent augmentism versus immersionism thread? Each immersionist's world is separate from all others= , and your value judgements from elsewhere are not importable to those worlds. What about fantasy worlds? Is a naked orc "Adult content"? How d= o you judge "Adult only" in a virtual world set in our distant future? How d= o you judge "Adult only" in a virtual world of aliens? What about in a virtual world of classic art recreations in all their naked and educational glory? And there are probably another 500 questions like this one. It's not just a can of worms. It's totally unworkable, nothing more than theater, and verging on farce or comedy. I bet that some readers here who are not exposed to recent events in Second Life may be wondering why this topic has even appeared in these discussions. One particular world provider has implemented a ratings system within its own walled garden, and this has been confused with the requirements of interop outside of a walled garden. Such ratings systems may be workable within a single managed domain in which the provider has total control over region spaces and asset services and can sanction individuals who break the rules, but it does not extrapolate to multiple worlds with separate Terms and Conditions, different jurisdictions, or varying cultures, even when they're all mirrors of the physical world. Even less can it work or apply in the general case of immersionist virtual worlds. This is extremely poorly considered, on numerous fronts. Authentication is more than enough for coarsely segregating highly restricted enclaves from the general mass of virtual worlds. Going beyond that is simply unworkable across multiple separate virtual virtual worlds, when you look at the implications. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D On Mon, Oct 5, 2009 at 3:48 PM, Dickson, Mike (ISS Software) < mike.dickson@hp.com> wrote: > I think Magnus=92 message is a good synopsis of the requirements, IMO. = I > see a need to negotiate **both** capabilities and constraints in the > protocol where both should be ideally attributes in an extensible list (t= hat > is the list isn=92t hard coded in the protocol definition). So, IMO, > authentication isn=92t enough. Beyond authenticating there=92s an exchan= ge > around caps and constraints that needs to take place. I=92d use that > mechanism to handle =93Adult only=94 regions, membership in a group where= the > group is defined outside the scope of the protocol, etc. > > > > Mike > > > > *From:* ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] *On Behalf O= f > *Magnus Zeisig > *Sent:* Monday, October 05, 2009 3:55 AM > *To:* ogpx@ietf.org > *Subject:* [ogpx] Protocol for permitting policy decisions > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > If I register with an agent domain, or authentication service, whichever > should be the proper name for it, I will most probably hand them some pie= ces > of information about myself that I don't want disseminated to anyone. > Therefore, I think the protocol for granting access to regions and other > services should not include such information explicitly, but rather let t= he > agent domain/authentication service just answer questions from the other > domain/service if the parameters are within acceptable range. > > > > Instead of the revealing (meta-handshake): > > > > Agent domain: > > request access for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > age: 18 > > gender: male > > sexuality: bi > > country: pt > > languages: pt, es, en, de > > length: 1.82 > > weight: 122 > > color of socks: blue > > > > Region domain: > > access granted for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > The handshake should instead be: > > > > Agent domain: > > request access for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > Region domain: > > require parameter values > > languages: es AND (de OR hb OR ru) > > length: [1.21-2.42] > > color of socks: pink OR blue OR black > > hairdo: shaved OR ponytail > > > > Agent domain: > > required parameter values > > languages: yes > > length: yes > > color of socks: yes > > hairdo: n/a > > > > After which the region domain might decide that the missing hairdo > parameter is not crucial and grant access, or refuse access because of it= : > > > > Region domain: > > access denied for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > This has the benefit of permitting service providers to require what user > parameters they think are important, be it age or color of socks, but the > disadvantage of some extra overhead and the risk of balkanization because= of > requirements of "odd" parameters only supported by few services. The latt= er, > however, I believe will become self-eliminating, because such services wi= ll > probably not find many users. Either way, I don't think the protocol in > itself should require any particular parameters, like age or color of soc= ks, > just provide the means to communicate any parameters, and perhaps suggest= a > list of possible, but not required, parameters and formats for values, li= ke > options, ranges and enumerations. The same kind of handshake could also b= e > used when requesting access to asset services and the like, even if > parameters like "object types" and "ip agreements" may be more important > than "color of socks" there. > > > > Best regards, > > > > Magnus > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: 9.8.3 (Build 4028) > > Charset: utf-8 > > > > wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g > > rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc > > YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu > > ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr > > vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb > > 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg=3D=3D > > =3DH2Fj > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --000e0cdfd7e68433c9047533cd6c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable You're opening up a can of worms of biblical proportions here, Mike.
What in hell's teeth is an "Adult only region"?=A0 Who g= ets to define it?=A0 Under what rules?=A0 In what legal jurisdiction?=A0 An= d those are just the simplest questions, pertaining to worlds that are mere= ly reflections of the physical world.=A0 What about virtual worlds that int= entionally maintain separation from RL, bearing in mind the recent augmenti= sm versus immersionism thread?=A0 Each immersionist's world is separate= from all others, and your value judgements from elsewhere are not importab= le to those worlds.=A0 What about fantasy worlds?=A0 Is a naked orc "A= dult content"?=A0 How do you judge "Adult only" in a virtual= world set in our distant future?=A0 How do you judge "Adult only"= ; in a virtual world of aliens?=A0 What about in a virtual world of classic= art recreations in all their naked and educational glory?=A0 And there are= probably another 500 questions like this one.

It's not just a can of worms.=A0 It's totally unworkable, nothi= ng more than theater, and verging on farce or comedy.=A0 I bet that some re= aders here who are not exposed to recent events in Second Life may be wonde= ring why this topic has even appeared in these discussions.

One particular world provider has implemented a ratings system within i= ts own walled garden, and this has been confused with the requirements of i= nterop outside of a walled garden.=A0 Such ratings systems may be workable = within a single managed domain in which the provider has total control over= region spaces and asset services and can sanction individuals who break th= e rules, but it does not extrapolate to multiple worlds with separate Terms= and Conditions, different jurisdictions, or varying cultures, even when th= ey're all mirrors of the physical world.=A0 Even less can it work or ap= ply in the general case of immersionist virtual worlds.

This is extremely poorly considered, on numerous fronts.

Authent= ication is more than enough for coarsely segregating highly restricted encl= aves from the general mass of virtual worlds.=A0 Going beyond that is simpl= y unworkable across multiple separate virtual virtual worlds, when you look= at the implications.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Mon, Oct 5, 2009 at 3:48 PM, Dickson, Mike = (ISS Software) <mike.dickson@hp.com> wrote:

I think Magnus= =92 message is a good synopsis of the requirements, IMO.=A0 I see a need to negotiate *both* capabilities and constraint= s in the protocol where both should be ideally attributes in an extensible list (that is the list isn=92t hard coded in the protocol definition).=A0 So, IM= O, authentication isn=92t enough.=A0 Beyond authenticating there=92s an exchan= ge around caps and constraints that needs to take place.=A0 I=92d use that mechanism to ha= ndle =93Adult only=94 regions, membership in a group where the group is defined outside t= he scope of the protocol, etc.

=A0

Mike

=A0

From:<= /span> ogpx-bounces@ietf.org [mailto:ogpx-bou= nces@ietf.org] On Behalf Of Magnus Zeisig
Sent: Monday, October 05, 2009 3:55 AM
To: ogpx@ietf.org=
Subject: [ogpx] Protocol for permitting policy decisions

=A0

-----BEGI= N PGP SIGNED MESSAGE-----

Hash: SHA= 256

=A0

If I regi= ster with an agent domain, or authentication service, whichever should be the proper name for it, I will = most probably hand them some pieces of information about myself that I don't= want disseminated to anyone. Therefore, I think the protocol for granting access= to regions and other services should not include such information explicitly, = but rather let the agent domain/authentication service just answer questions fr= om the other domain/service if the parameters are within acceptable range.

=A0

Instead o= f the revealing (meta-handshake):

=A0

Agent dom= ain:

request a= ccess for

age: 18

gender: m= ale

sexuality= : bi

country: = pt

languages= : pt, es, en, de

length: 1= .82

weight: 1= 22

color of = socks: blue

=A0

Region do= main:

access gr= anted for

=A0

The hands= hake should instead be:

=A0

Agent dom= ain:

request a= ccess for

=A0

Region do= main:

require p= arameter values

languages= : es AND (de OR hb OR ru)

length: [= 1.21-2.42]

color of = socks: pink OR blue OR black

hairdo: s= haved OR ponytail

=A0

Agent dom= ain:

required = parameter values

languages= : yes

length: y= es

color of = socks: yes

hairdo: n= /a

=A0

After whi= ch the region domain might decide that the missing hairdo parameter is not crucial and grant access, or refus= e access because of it:

=A0

Region do= main:

access de= nied for

=A0

This has = the benefit of permitting service providers to require what user parameters they think are important, be it a= ge or color of socks, but the disadvantage of some extra overhead and the risk= of balkanization because of requirements of "odd" parameters only supported by few services. The latter, however, I believe will become self-eliminating, because such services will probably not find many users. Either way, I don't think the protocol in itself should require any par= ticular parameters, like age or color of socks, just provide the means to communica= te any parameters, and perhaps suggest a list of possible, but not required, parameters and formats for values, like options, ranges and enumerations. T= he same kind of handshake could also be used when requesting access to asset services and the like, even if parameters like "object types" and "ip agreements" may be more important than "color of socks&q= uot; there.

=A0

Best rega= rds,

=A0

Magnus

=A0

=A0

-----BEGI= N PGP SIGNATURE-----

Version: = 9.8.3 (Build 4028)

Charset: = utf-8

=A0

wsBVAwUBS= sm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g

rJWLZ4oev= ewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc

YAPdd6zGt= QpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu

ofvDew+JT= 140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr

vLXfL5BfC= XK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb

6i8YpDvBr= IkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg=3D=3D

=3DH2Fj

-----END = PGP SIGNATURE-----

=A0

=A0


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--000e0cdfd7e68433c9047533cd6c-- From morgaine.dinova@googlemail.com Mon Oct 5 11:05:06 2009 Return-Path: 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 C11893A67FB for ; Mon, 5 Oct 2009 11:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 2CFr5KGPPqlg for ; Mon, 5 Oct 2009 11:05:05 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 4410628C0D9 for ; Mon, 5 Oct 2009 11:05:03 -0700 (PDT) Received: by ewy10 with SMTP id 10so3320376ewy.9 for ; Mon, 05 Oct 2009 11:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=iPf7+3+jwQA1Kv8Z6Dirluh18y9p7dxQB+tz4z7yM/k=; b=F6omNEEm8LkchBtY6QHVCEmDfLEMBNyPtnNBLlvhVS81I9tmcEyDAlNnF6S4y/mBpx LqGDNFKCPN5hWqwX0S22N+XcgXzmLVl18sw1qRPQCgbMuyoTaBOO4FWbDqxOo9pP71nH I5tWVx8kcHgs5Kx22g9lpf6qDPPmFdo9lgaW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZfnN4cBjDFfw+YeObOekO5tiYl8n3GcuQKzNQtlfyuVItLFEwTx3jPBG5/C4BloMhi kkV3lSNuRBWw1e3dzSizmKCtkA26xF1/tay9vjumCL2cG03ELUAaahoCagECKu3+h1fp hRBIZQhc25XnjQBuYnHw6kiTInez9JGrtuqVk= MIME-Version: 1.0 Received: by 10.211.158.11 with SMTP id k11mr343949ebo.63.1254765996862; Mon, 05 Oct 2009 11:06:36 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A156244@GVW0433EXB.americas.hpqcorp.net> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> <4646639E08F58B42836FAC24C94624DD771A156244@GVW0433EXB.americas.hpqcorp.net> Date: Mon, 5 Oct 2009 19:06:36 +0100 Message-ID: From: Morgaine To: "Dickson, Mike (ISS Software)" Content-Type: multipart/alternative; boundary=00504502d51484eff8047533f922 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 18:05:06 -0000 --00504502d51484eff8047533f922 Content-Type: text/plain; charset=ISO-8859-1 That's an issue specific to the particular policies of Second Life, and like all matters of policy, it doesn't involve us here. In fact, that's exactly what Meadhbh wrote in the email to which you responded, and her words are spot on. Morgaine. ======================================= On Mon, Oct 5, 2009 at 6:12 PM, Dickson, Mike (ISS Software) < mike.dickson@hp.com> wrote: > I think I buy it in the case you put forward. That is if you simplify the > problem so that AD itself specifies the constraint (the AD in your example > only carries accounts from the sea scouts). But what if I'm running > multiple regions with different policies all served by a single AD? Are you > suggesting that each region needs to handle the policy for its own? > > Picking on what is probably a corner case but one that's been raised... If > I'm running multiple regions, some of which are "Adult" and some are not, > does treating constraints as outside the protocol require each RD to do the > age verification (I could make a case the answer is yes since "Adultness" > might differ depending on who/where I am). And if so how do they do that > without getting "sensitive information" that is probably best owned by the > AD. Is it reasonable perhaps for a RD to delegate that to the AD and > provide a mechanism to negotiate the details on connect so I can centralize > such decisions in a single place? > > Mike > > -----Original Message----- > From: Meadhbh Siobhan [mailto:meadhbh.siobhan@gmail.com] > Sent: Monday, October 05, 2009 11:33 AM > To: Dickson, Mike (ISS Software) > Cc: Magnus Zeisig; ogpx@ietf.org > Subject: Re: [ogpx] Protocol for permitting policy decisions > > again, this is a matter of policy, not a matter of protocol. > > let me give you a counter example. some trusted organization, maybe > the new zealand sea scouts, decides it wants a virtual social space to > teach seamanship, knot tying and whatever else scouts are taught these > days. > > the sea scouts organization is not really known for it's ability to > maintain a reasonably large networking and system infrastructure, so > instead of building the service themselves, they outsource. > > at this point, there are a couple of options open to them. they can > give their entire user database to a third party and hope for the > best. or they can give portions of their user database (name, email > address, adult / minor boolean.) or they could put a VWRAP > authentication service that they maintain in front of their user > database. each are valid options. > > one would hope that in the first two options, they worked out with the > third party some pretty hard-core data retention and privacy policies. > > so what if they did the third option? what would the protocol have to > do? the sea scout's agent domain would only allow agents to enter a > private virtual world. the sea scouts would negotiate with their > region domain provider to ensure that adult content was not allowed in > the regions accessible by the sea scout agent domain. moreover, the > region domain provider could ensure that ONLY agents with accounts > from the sea scouts would get access to the sea scouts virtual spaces. > > so the answer to the question of "what does the protocol have to do?" > is that it only has to convey information about the identity of the > agent domain to the region provider. it also has to have a mechanism > for the agent domain to identify the region. > > but the protocol itself does not impose restrictions as to the > identity of either party. that is a policy issue. > > in other words, if you don't want to use an agent domain / region > domain pair that provides information about you to a trusted third > party, don't give that information the the agent domain in the first > place. or double check that the agent domain's privacy policy requires > third parties to which it reveals information to treat that > information with due care. > > that being said, some people's paranoia level is higher than others, > so maybe we could have multiple techniques defined for sharing > sensitive information, none of which are mandatory. > > -cheers > -meadhbh > > On Mon, Oct 5, 2009 at 7:48 AM, Dickson, Mike (ISS Software) > wrote: > > I think Magnus' message is a good synopsis of the requirements, IMO. I > see > > a need to negotiate *both* capabilities and constraints in the protocol > > where both should be ideally attributes in an extensible list (that is > the > > list isn't hard coded in the protocol definition). So, IMO, > authentication > > isn't enough. Beyond authenticating there's an exchange around caps and > > constraints that needs to take place. I'd use that mechanism to handle > > "Adult only" regions, membership in a group where the group is defined > > outside the scope of the protocol, etc. > > > > > > > > Mike > > > > > > > > From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of > > Magnus Zeisig > > Sent: Monday, October 05, 2009 3:55 AM > > To: ogpx@ietf.org > > Subject: [ogpx] Protocol for permitting policy decisions > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA256 > > > > > > > > If I register with an agent domain, or authentication service, whichever > > should be the proper name for it, I will most probably hand them some > pieces > > of information about myself that I don't want disseminated to anyone. > > Therefore, I think the protocol for granting access to regions and other > > services should not include such information explicitly, but rather let > the > > agent domain/authentication service just answer questions from the other > > domain/service if the parameters are within acceptable range. > > > > > > > > Instead of the revealing (meta-handshake): > > > > > > > > Agent domain: > > > > request access for > > > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > age: 18 > > > > gender: male > > > > sexuality: bi > > > > country: pt > > > > languages: pt, es, en, de > > > > length: 1.82 > > > > weight: 122 > > > > color of socks: blue > > > > > > > > Region domain: > > > > access granted for > > > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > > > > > The handshake should instead be: > > > > > > > > Agent domain: > > > > request access for > > > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > > > > > Region domain: > > > > require parameter values > > > > languages: es AND (de OR hb OR ru) > > > > length: [1.21-2.42] > > > > color of socks: pink OR blue OR black > > > > hairdo: shaved OR ponytail > > > > > > > > Agent domain: > > > > required parameter values > > > > languages: yes > > > > length: yes > > > > color of socks: yes > > > > hairdo: n/a > > > > > > > > After which the region domain might decide that the missing hairdo > parameter > > is not crucial and grant access, or refuse access because of it: > > > > > > > > Region domain: > > > > access denied for > > > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > > > > > This has the benefit of permitting service providers to require what user > > parameters they think are important, be it age or color of socks, but the > > disadvantage of some extra overhead and the risk of balkanization because > of > > requirements of "odd" parameters only supported by few services. The > latter, > > however, I believe will become self-eliminating, because such services > will > > probably not find many users. Either way, I don't think the protocol in > > itself should require any particular parameters, like age or color of > socks, > > just provide the means to communicate any parameters, and perhaps suggest > a > > list of possible, but not required, parameters and formats for values, > like > > options, ranges and enumerations. The same kind of handshake could also > be > > used when requesting access to asset services and the like, even if > > parameters like "object types" and "ip agreements" may be more important > > than "color of socks" there. > > > > > > > > Best regards, > > > > > > > > Magnus > > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > > Version: 9.8.3 (Build 4028) > > > > Charset: utf-8 > > > > > > > > wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g > > > > rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc > > > > YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu > > > > ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr > > > > vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb > > > > 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg== > > > > =H2Fj > > > > -----END PGP SIGNATURE----- > > > > > > > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --00504502d51484eff8047533f922 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's an issue specific to the particular policies of Second Life, and= like all matters of policy, it doesn't involve us here.

In fact= , that's exactly what Meadhbh wrote in the email to which you responded= , and her words are spot on.

Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Mon, Oct 5, 2009 at 6:12 PM, Dickson, Mi= ke (ISS Software) <mike.dickson@hp.com> wrote:
I think I buy it = in the case you put forward. =A0That is if you simplify the problem so that= AD itself specifies the constraint (the AD in your example only carries ac= counts from the sea scouts). =A0But what if I'm running multiple region= s with different policies all served by a single AD? Are you suggesting tha= t each region needs to handle the policy for its own?

Picking on what is probably a corner case but one that's been raised...= =A0If I'm running multiple regions, some of which are "Adult"= ; and some are not, does treating constraints as outside the protocol requi= re each RD to do the age verification (I could make a case the answer is ye= s since "Adultness" might differ depending on who/where I am). = =A0And if so how do they do that without getting "sensitive informatio= n" that is probably best owned by the AD. =A0Is it reasonable perhaps = for a RD to delegate that to the AD and provide a mechanism to negotiate th= e details on connect so I can centralize such decisions in a single place?<= br>
Mike

-----Original Message-----
From: Meadhbh Siobhan [mailto:= meadhbh.siobhan@gmail.com]
Sent: Monday, October 05, 2009 11:33 AM
To: Dickson, Mike (ISS Software)
Cc: Magnus Zeisig; ogpx@ietf.org
Subject: Re: [ogpx] Protocol for permitting policy decisions

again, this is a matter of policy, not a matter of protocol.

let me give you a counter example. some trusted organization, maybe
the new zealand sea scouts, decides it wants a virtual social space to
teach seamanship, knot tying and whatever else scouts are taught these
days.

the sea scouts organization is not really known for it's ability to
maintain a reasonably large networking and system infrastructure, so
instead of building the service themselves, they outsource.

at this point, there are a couple of options open to them. they can
give their entire user database to a third party and hope for the
best. or they can give portions of their user database (name, email
address, adult / minor boolean.) or they could put a VWRAP
authentication service that they maintain in front of their user
database. each are valid options.

one would hope that in the first two options, they worked out with the
third party some pretty hard-core data retention and privacy policies.

so what if they did the third option? what would the protocol have to
do? the sea scout's agent domain would only allow agents to enter a
private virtual world. the sea scouts would negotiate with their
region domain provider to ensure that adult content was not allowed in
the regions accessible by the sea scout agent domain. moreover, the
region domain provider could ensure that ONLY agents with accounts
from the sea scouts would get access to the sea scouts virtual spaces.

so the answer to the question of "what does the protocol have to do?&q= uot;
is that it only has to convey information about the identity of the
agent domain to the region provider. it also has to have a mechanism
for the agent domain to identify the region.

but the protocol itself does not impose restrictions as to the
identity of either party. that is a policy issue.

in other words, if you don't want to use an agent domain =A0/ region domain pair that provides information about you to a trusted third
party, don't give that information the the agent domain in the first place. or double check that the agent domain's privacy policy requires<= br> third parties to which it reveals information to =A0treat that
information with due care.

that being said, some people's paranoia level is higher than others, so maybe we could have multiple techniques defined for sharing
sensitive information, none of which are mandatory.

-cheers
-meadhbh

On Mon, Oct 5, 2009 at 7:48 AM, Dickson, Mike (ISS Software)
<mike.dickson@hp.com> wrot= e:
> I think Magnus' message is a good synopsis of the requirements, IM= O.=A0 I see
> a need to negotiate *both* capabilities and constraints in the protoco= l
> where both should be ideally attributes in an extensible list (that is= the
> list isn't hard coded in the protocol definition).=A0 So, IMO, aut= hentication
> isn't enough.=A0 Beyond authenticating there's an exchange aro= und caps and
> constraints that needs to take place.=A0 I'd use that mechanism to= handle
> "Adult only" regions, membership in a group where the group = is defined
> outside the scope of the protocol, etc.
>
>
>
> Mike
>
>
>
> From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of
> Magnus Zeisig
> Sent: Monday, October 05, 2009 3:55 AM
> To: ogpx@ietf.org
> Subject: [ogpx] Protocol for permitting policy decisions
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Hash: SHA256
>
>
>
> If I register with an agent domain, or authentication service, whichev= er
> should be the proper name for it, I will most probably hand them some = pieces
> of information about myself that I don't want disseminated to anyo= ne.
> Therefore, I think the protocol for granting access to regions and oth= er
> services should not include such information explicitly, but rather le= t the
> agent domain/authentication service just answer questions from the oth= er
> domain/service if the parameters are within acceptable range.
>
>
>
> Instead of the revealing (meta-handshake):
>
>
>
> Agent domain:
>
> request access for
>
> user: Title.FirstName.Initials.LastName.ExtraSomething@agentd= omain.org
>
> age: 18
>
> gender: male
>
> sexuality: bi
>
> country: pt
>
> languages: pt, es, en, de
>
> length: 1.82
>
> weight: 122
>
> color of socks: blue
>
>
>
> Region domain:
>
> access granted for
>
> user: Title.FirstName.Initials.LastName.ExtraSomething@agentd= omain.org
>
>
>
> The handshake should instead be:
>
>
>
> Agent domain:
>
> request access for
>
> user: Title.FirstName.Initials.LastName.ExtraSomething@agentd= omain.org
>
>
>
> Region domain:
>
> require parameter values
>
> languages: es AND (de OR hb OR ru)
>
> length: [1.21-2.42]
>
> color of socks: pink OR blue OR black
>
> hairdo: shaved OR ponytail
>
>
>
> Agent domain:
>
> required parameter values
>
> languages: yes
>
> length: yes
>
> color of socks: yes
>
> hairdo: n/a
>
>
>
> After which the region domain might decide that the missing hairdo par= ameter
> is not crucial and grant access, or refuse access because of it:
>
>
>
> Region domain:
>
> access denied for
>
> user: Title.FirstName.Initials.LastName.ExtraSomething@agentd= omain.org
>
>
>
> This has the benefit of permitting service providers to require what u= ser
> parameters they think are important, be it age or color of socks, but = the
> disadvantage of some extra overhead and the risk of balkanization beca= use of
> requirements of "odd" parameters only supported by few servi= ces. The latter,
> however, I believe will become self-eliminating, because such services= will
> probably not find many users. Either way, I don't think the protoc= ol in
> itself should require any particular parameters, like age or color of = socks,
> just provide the means to communicate any parameters, and perhaps sugg= est a
> list of possible, but not required, parameters and formats for values,= like
> options, ranges and enumerations. The same kind of handshake could als= o be
> used when requesting access to asset services and the like, even if > parameters like "object types" and "ip agreements"= may be more important
> than "color of socks" there.
>
>
>
> Best regards,
>
>
>
> Magnus
>
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> Version: 9.8.3 (Build 4028)
>
> Charset: utf-8
>
>
>
> wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g
>
> rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc
>
> YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu
>
> ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr
>
> vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb
>
> 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg=3D=3D
>
> =3DH2Fj
>
> -----END PGP SIGNATURE-----
>
>
>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--00504502d51484eff8047533f922-- From mike.dickson@hp.com Mon Oct 5 11:07:01 2009 Return-Path: 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 0152428C0E0 for ; Mon, 5 Oct 2009 11:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Udz1mSKC1kov for ; Mon, 5 Oct 2009 11:06:50 -0700 (PDT) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by core3.amsl.com (Postfix) with ESMTP id 5701E3A67FB for ; Mon, 5 Oct 2009 11:06:50 -0700 (PDT) Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 691A0819D; Mon, 5 Oct 2009 18:08:23 +0000 (UTC) Received: from G4W0659.americas.hpqcorp.net (16.234.40.187) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 5 Oct 2009 18:07:47 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G4W0659.americas.hpqcorp.net ([16.234.40.187]) with mapi; Mon, 5 Oct 2009 18:07:47 +0000 From: "Dickson, Mike (ISS Software)" To: Morgaine Date: Mon, 5 Oct 2009 18:07:40 +0000 Thread-Topic: [ogpx] Protocol for permitting policy decisions Thread-Index: AcpF5NzpLzZyGpArTaSGNCk6pDOFdQAAJi4w Message-ID: <4646639E08F58B42836FAC24C94624DD771A1562F4@GVW0433EXB.americas.hpqcorp.net> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD771A1562F4GVW0433EXBame_" MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 18:07:01 -0000 --_000_4646639E08F58B42836FAC24C94624DD771A1562F4GVW0433EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm going to drop this since I'm a poor choice to defend the case. In prin= ciple I agree with Morgaine and the LL folks don't seem to see a need for t= his sort of handshake. I do personally see cases where the AD and RD may w= ant to share attribute information on a connect but it could be done out of= band and so isn't really required to make the VWRAP bits work. And in ans= wer to the question Morgaine raised... i.e. who gets define what adult onl= y is, it's the region IMO hence the reason (if I understood) Meadbah argue= d it's a matter of policy and not protocol. Apologies if I tested anyone's patience. I'm still working through these c= ases in my own head. Mike From: Morgaine [mailto:morgaine.dinova@googlemail.com] Sent: Monday, October 05, 2009 12:54 PM To: Dickson, Mike (ISS Software) Cc: ogpx@ietf.org Subject: Re: [ogpx] Protocol for permitting policy decisions You're opening up a can of worms of biblical proportions here, Mike. What in hell's teeth is an "Adult only region"? Who gets to define it? Un= der what rules? In what legal jurisdiction? And those are just the simple= st questions, pertaining to worlds that are merely reflections of the physi= cal world. What about virtual worlds that intentionally maintain separatio= n from RL, bearing in mind the recent augmentism versus immersionism thread= ? Each immersionist's world is separate from all others, and your value ju= dgements from elsewhere are not importable to those worlds. What about fan= tasy worlds? Is a naked orc "Adult content"? How do you judge "Adult only= " in a virtual world set in our distant future? How do you judge "Adult on= ly" in a virtual world of aliens? What about in a virtual world of classic= art recreations in all their naked and educational glory? And there are p= robably another 500 questions like this one. It's not just a can of worms. It's totally unworkable, nothing more than t= heater, and verging on farce or comedy. I bet that some readers here who a= re not exposed to recent events in Second Life may be wondering why this to= pic has even appeared in these discussions. One particular world provider has implemented a ratings system within its o= wn walled garden, and this has been confused with the requirements of inter= op outside of a walled garden. Such ratings systems may be workable within= a single managed domain in which the provider has total control over regio= n spaces and asset services and can sanction individuals who break the rule= s, but it does not extrapolate to multiple worlds with separate Terms and C= onditions, different jurisdictions, or varying cultures, even when they're = all mirrors of the physical world. Even less can it work or apply in the g= eneral case of immersionist virtual worlds. This is extremely poorly considered, on numerous fronts. Authentication is more than enough for coarsely segregating highly restrict= ed enclaves from the general mass of virtual worlds. Going beyond that is = simply unworkable across multiple separate virtual virtual worlds, when you= look at the implications. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D On Mon, Oct 5, 2009 at 3:48 PM, Dickson, Mike (ISS Software) > wrote: I think Magnus' message is a good synopsis of the requirements, IMO. I see= a need to negotiate *both* capabilities and constraints in the protocol wh= ere both should be ideally attributes in an extensible list (that is the li= st isn't hard coded in the protocol definition). So, IMO, authentication i= sn't enough. Beyond authenticating there's an exchange around caps and con= straints that needs to take place. I'd use that mechanism to handle "Adult= only" regions, membership in a group where the group is defined outside th= e scope of the protocol, etc. Mike From: ogpx-bounces@ietf.org [mailto:ogpx-boun= ces@ietf.org] On Behalf Of Magnus Zeisig Sent: Monday, October 05, 2009 3:55 AM To: ogpx@ietf.org Subject: [ogpx] Protocol for permitting policy decisions -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 If I register with an agent domain, or authentication service, whichever sh= ould be the proper name for it, I will most probably hand them some pieces = of information about myself that I don't want disseminated to anyone. There= fore, I think the protocol for granting access to regions and other service= s should not include such information explicitly, but rather let the agent = domain/authentication service just answer questions from the other domain/s= ervice if the parameters are within acceptable range. Instead of the revealing (meta-handshake): Agent domain: request access for user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org age: 18 gender: male sexuality: bi country: pt languages: pt, es, en, de length: 1.82 weight: 122 color of socks: blue Region domain: access granted for user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org The handshake should instead be: Agent domain: request access for user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org Region domain: require parameter values languages: es AND (de OR hb OR ru) length: [1.21-2.42] color of socks: pink OR blue OR black hairdo: shaved OR ponytail Agent domain: required parameter values languages: yes length: yes color of socks: yes hairdo: n/a After which the region domain might decide that the missing hairdo paramete= r is not crucial and grant access, or refuse access because of it: Region domain: access denied for user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org This has the benefit of permitting service providers to require what user p= arameters they think are important, be it age or color of socks, but the di= sadvantage of some extra overhead and the risk of balkanization because of = requirements of "odd" parameters only supported by few services. The latter= , however, I believe will become self-eliminating, because such services wi= ll probably not find many users. Either way, I don't think the protocol in = itself should require any particular parameters, like age or color of socks= , just provide the means to communicate any parameters, and perhaps suggest= a list of possible, but not required, parameters and formats for values, l= ike options, ranges and enumerations. The same kind of handshake could also= be used when requesting access to asset services and the like, even if par= ameters like "object types" and "ip agreements" may be more important than = "color of socks" there. Best regards, Magnus -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg=3D=3D =3DH2Fj -----END PGP SIGNATURE----- _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --_000_4646639E08F58B42836FAC24C94624DD771A1562F4GVW0433EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m going to drop this since I’m a poor choice t= o defend the case.  In principle I agree with Morgaine and the LL folks = don’t seem to see a need for this sort of handshake.  I do personally see ca= ses where the AD and RD may want to share attribute information on a connect bu= t it could be done out of band and so isn’t really required to make the VW= RAP bits work.  And in answer to the question Morgaine raised… i.e. =  who gets define what adult only is, it’s the region IMO hence the reason = (if I understood)  Meadbah argued it’s a matter of policy and not protocol.

 

Apologies if I tested anyone’s patience.  I’= ;m still working through these cases in my own head.

 

Mike

 

From: Morgaine [mailto:morgaine.dinova@google= mail.com]
Sent: Monday, October 05, 2009 12:54 PM
To: Dickson, Mike (ISS Software)
Cc: ogpx@ietf.org
Subject: Re: [ogpx] Protocol for permitting policy decisions

 

You're opening up a can of worms of biblical proportions here, Mike.

What in hell's teeth is an "Adult only region"?  Who gets to define it?  Under what rules?  In what legal jurisdiction?  = And those are just the simplest questions, pertaining to worlds that are merely reflections of the physical world.  What about virtual worlds that intentionally maintain separation from RL, bearing in mind the recent augmentism versus immersionism thread?  Each immersionist's world is separate from all others, and your value judgements from elsewhere are not importable to those worlds.  What about fantasy worlds?  Is a nak= ed orc "Adult content"?  How do you judge "Adult only"= ; in a virtual world set in our distant future?  How do you judge "Adu= lt only" in a virtual world of aliens?  What about in a virtual worl= d of classic art recreations in all their naked and educational glory?  And there are probably another 500 questions like this one.

It's not just a can of worms.  It's totally unworkable, nothing more t= han theater, and verging on farce or comedy.  I bet that some readers here= who are not exposed to recent events in Second Life may be wondering why this t= opic has even appeared in these discussions.

One particular world provider has implemented a ratings system within its o= wn walled garden, and this has been confused with the requirements of interop outside of a walled garden.  Such ratings systems may be workable with= in a single managed domain in which the provider has total control over region spaces and asset services and can sanction individuals who break the rules,= but it does not extrapolate to multiple worlds with separate Terms and Conditio= ns, different jurisdictions, or varying cultures, even when they're all mirrors= of the physical world.  Even less can it work or apply in the general cas= e of immersionist virtual worlds.

This is extremely poorly considered, on numerous fronts.

Authentication is more than enough for coarsely segregating highly restrict= ed enclaves from the general mass of virtual worlds.  Going beyond that i= s simply unworkable across multiple separate virtual virtual worlds, when you look at the implications.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Oct 5, 2009 at 3:48= PM, Dickson, Mike (ISS Software) <mik= e.dickson@hp.com> wrote:

I think Magnus’ message is a good synopsis of the requirements, IMO.&nb= sp; I see a need to negotiate *both* capabilities and constraints in the protocol where both should be ideally attributes in an extensible list (tha= t is the list isn’t hard coded in the protocol definition).  So, IMO, authentication isn’t enough.  Beyond authenticating there’= s an exchange around caps and constraints that needs to take place.  I̵= 7;d use that mechanism to handle “Adult only” regions, membership i= n a group where the group is defined outside the scope of the protocol, etc.

 

Mike

 

From: ogpx-bounces@ietf.org [mailto:ogpx-bou= nces@ietf.org] On Behalf Of Magnus Zeisig
Sent: Monday, October 05, 2009 3:55 AM
To: ogpx@ietf.org=
Subject: [ogpx] Protocol for permitting policy decisions=

 

-----BEGIN = PGP SIGNED MESSAGE-----

Hash: SHA25= 6

 

If I regist= er with an agent domain, or authentication service, whichever should be the proper = name for it, I will most probably hand them some pieces of information about mys= elf that I don't want disseminated to anyone. Therefore, I think the protocol f= or granting access to regions and other services should not include such information explicitly, but rather let the agent domain/authentication serv= ice just answer questions from the other domain/service if the parameters are within acceptable range.

 

Instead of = the revealing (meta-handshake):

 

Agent domai= n:

request acc= ess for

age: 18

gender: mal= e

sexuality: = bi

country: pt=

languages: = pt, es, en, de

length: 1.8= 2

weight: 122=

color of so= cks: blue

 

Region doma= in:

access gran= ted for

 

The handsha= ke should instead be:

 

Agent domai= n:

request acc= ess for

 

Region doma= in:

require par= ameter values

languages: = es AND (de OR hb OR ru)

length: [1.= 21-2.42]

color of so= cks: pink OR blue OR black

hairdo: sha= ved OR ponytail

 

Agent domai= n:

required pa= rameter values

languages: = yes

length: yes=

color of so= cks: yes

hairdo: n/a=

 

After which= the region domain might decide that the missing hairdo parameter is not crucial= and grant access, or refuse access because of it:

 

Region doma= in:

access deni= ed for

 

This has th= e benefit of permitting service providers to require what user parameters the= y think are important, be it age or color of socks, but the disadvantage of s= ome extra overhead and the risk of balkanization because of requirements of "odd" parameters only supported by few services. The latter, howe= ver, I believe will become self-eliminating, because such services will probably= not find many users. Either way, I don't think the protocol in itself should require any particular parameters, like age or color of socks, just provide= the means to communicate any parameters, and perhaps suggest a list of possible= , but not required, parameters and formats for values, like options, ranges a= nd enumerations. The same kind of handshake could also be used when requesting access to asset services and the like, even if parameters like "object types" and "ip agreements" may be more important than "color of socks" there.

 

Best regard= s,

 

Magnus

 

 

-----BEGIN = PGP SIGNATURE-----

Version: 9.= 8.3 (Build 4028)

Charset: ut= f-8

 

wsBVAwUBSsm= 0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g

rJWLZ4oevew= ngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc

YAPdd6zGtQp= R+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu

ofvDew+JT14= 0ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr

vLXfL5BfCXK= 0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb

6i8YpDvBrIk= NL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg=3D=3D

=3DH2Fj

-----END PG= P SIGNATURE-----

 

 


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

 

--_000_4646639E08F58B42836FAC24C94624DD771A1562F4GVW0433EXBame_-- From carlo@alinoe.com Mon Oct 5 11:22:18 2009 Return-Path: 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 E155B28C20B for ; Mon, 5 Oct 2009 11:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 DFS-g6xGfZDR for ; Mon, 5 Oct 2009 11:22:18 -0700 (PDT) Received: from viefep20-int.chello.at (viefep20-int.chello.at [62.179.121.40]) by core3.amsl.com (Postfix) with ESMTP id 7680A3A6941 for ; Mon, 5 Oct 2009 11:22:17 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep20-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091005182351.KTPY10558.viefep20-int.chello.at@edge05.upc.biz>; Mon, 5 Oct 2009 20:23:51 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id p6Pq1c04t0FlQed056PryW; Mon, 05 Oct 2009 20:23:51 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MusF7-0005P4-4D; Mon, 05 Oct 2009 20:25:05 +0200 Date: Mon, 5 Oct 2009 20:25:05 +0200 From: Carlo Wood To: David W Levine Message-ID: <20091005182505.GA20468@alinoe.com> References: <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <20091002012335.GB690@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091002012335.GB690@alinoe.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 18:22:19 -0000 Nobody reacted to this post of me so far, does that mean everyone agrees? On Fri, Oct 02, 2009 at 03:23:35AM +0200, Carlo Wood wrote: > On Thu, Oct 01, 2009 at 06:25:22PM -0400, David W Levine wrote: > > We need to be careful, when looking at this stuff to strike a balance between > > focusing on the current deployed clusterings, and turning everything into soup. > > That said, the actual deployed systems which implement these specifications are > > only going to be able > > to enforce policy at the interfaces we define, and these interfaces are on > > services, not domains. > > It is because we can't allow *every* possible deployment to be supported (soup) > that I brought up my worries about which service should determine policy (ToS). > > It would be easy to choose a simplification (== not allow every possibility) > that leaves out a deployment that is essential, imho. > > My proposal was this: > > The AD can only allow a user to connect to (teleport to) a region (domain) > or not. If it allows a user to teleport there, then everything that that > domain allows is allowed. > > I probably should have been more clear about this from the beginning: > this (my concern) has everything to do with where Abuse Reports go to: > Once a user is in a given region and breaks a policy (or not) and someone > else wants to report this user, then the only authority that this report > should go to is the administration of the region (personally, I even > advocate the sim, but alas). > > If to whomever an 'abuse report' goes has nothing to do with VWRAP > than we can skip this topic; but I think it might be relevant and it > is certainly something we need to keep in mind while designing the > protocol (to make sure that won't go wrong). > > Example: > > Region RD1 runs on servers in country X whose laws state that adult > content may be accessed at the age of 16 or older. However, the > administration of RD1 has it in their ToS that one has to be 18. > They do not see a reason to ban people of age 16 or 17 however. > > Agentd AD2 is seated in another country where one has to be 21 before > one is allowed to access adult content. AD2 does age verification. > > If a person of age 18 logs in with AD2 and tries to TP to RD1 then > * AD2 may disallow that if they so choose. > * If AD2 allows the TP, than the user is allowed to access adult > content by the ToS of RD1 if their age is 18 or older. > > If the user lives in a country where 18 is old enough as well, > than I don't think that it matters (legally) where the AD2 is > seated: the administration of AD2 cannot be sued for allowing > a person to teleport to RD1 (I hope :p). > > *************************************************************** > * Hence, it is possible to apply the simplication: * > *- AD policies ONLY come into play at the moment of teleport * > * (allow or not). * > *- Once arrived in a new region, the policies of the AD can * > * be 'forgotten' and only the policies of the RD apply. * > * If the AD doesn't want that, they shouldn't allow the TP. * > *************************************************************** > > We shouldn't take this simplification (or deployment limitation) too > lightly, but I think it is one that will work VERY well in practice > and well worth it, as it's benefits will far outweight the disadvantages, > imho. > > If anyone can think of a clear counter example where a TP should > be allowed but still the AD ToS should determine what is allowed > and what not, please let us know. > > A clear advantage of this simplification is that it makes > it trivial where an Abuse Report would go to: namely the to the > administration of the Region (domain). > > A clear disadvantage of NOT making this simplification is that > it would be totally unclear where Abuse Reports have to go, and > that lots of confusion will arise about who can do what and why > they can and you not. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx -- Carlo Wood From infinity@lindenlab.com Mon Oct 5 11:30:21 2009 Return-Path: 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 603A73A687C for ; Mon, 5 Oct 2009 11:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 gzumhiuXWAU3 for ; Mon, 5 Oct 2009 11:30:20 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 156333A685B for ; Mon, 5 Oct 2009 11:30:20 -0700 (PDT) Received: by pzk35 with SMTP id 35so1328629pzk.29 for ; Mon, 05 Oct 2009 11:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.3.12 with SMTP id 12mr24795wfc.331.1254767512613; Mon, 05 Oct 2009 11:31:52 -0700 (PDT) In-Reply-To: <20091005182505.GA20468@alinoe.com> References: <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <20091002012335.GB690@alinoe.com> <20091005182505.GA20468@alinoe.com> Date: Mon, 5 Oct 2009 11:31:52 -0700 Message-ID: <3a880e2c0910051131k2d81531au275782c6cb3c3655@mail.gmail.com> From: Infinity Linden To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 18:30:21 -0000 silence does not mean agreement. On Mon, Oct 5, 2009 at 11:25 AM, Carlo Wood wrote: > Nobody reacted to this post of me so far, > does that mean everyone agrees? > > On Fri, Oct 02, 2009 at 03:23:35AM +0200, Carlo Wood wrote: >> On Thu, Oct 01, 2009 at 06:25:22PM -0400, David W Levine wrote: >> > We need to be careful, when looking at this stuff to strike a balance = between >> > focusing on the current deployed clusterings, and turning everything i= nto soup. >> > That said, the actual deployed systems which implement these specifica= tions are >> > only going to be able >> > to enforce policy at the interfaces we define, and these interfaces ar= e on >> > services, not domains. >> >> It is because we can't allow *every* possible deployment to be supported= (soup) >> that I brought up my worries about which service should determine policy= (ToS). >> >> It would be easy to choose a simplification (=3D=3D not allow every poss= ibility) >> that leaves out a deployment that is essential, imho. >> >> My proposal was this: >> >> The AD can only allow a user to connect to (teleport to) a region (domai= n) >> or not. If it allows a user to teleport there, then everything that that >> domain allows is allowed. >> >> I probably should have been more clear about this from the beginning: >> this (my concern) has everything to do with where Abuse Reports go to: >> Once a user is in a given region and breaks a policy (or not) and someon= e >> else wants to report this user, then the only authority that this report >> should go to is the administration of the region (personally, I even >> advocate the sim, but alas). >> >> If to whomever an 'abuse report' goes has nothing to do with VWRAP >> than we can skip this topic; but I think it might be relevant and it >> is certainly something we need to keep in mind while designing the >> protocol (to make sure that won't go wrong). >> >> Example: >> >> Region RD1 runs on servers in country X whose laws state that adult >> content may be accessed at the age of 16 or older. However, the >> administration of RD1 has it in their ToS that one has to be 18. >> They do not see a reason to ban people of age 16 or 17 however. >> >> Agentd AD2 is seated in another country where one has to be 21 before >> one is allowed to access adult content. =A0AD2 does age verification. >> >> If a person of age 18 logs in with AD2 and tries to TP to RD1 then >> * AD2 may disallow that if they so choose. >> * If AD2 allows the TP, than the user is allowed to access adult >> =A0 content by the ToS of RD1 if their age is 18 or older. >> >> If the user lives in a country where 18 is old enough as well, >> than I don't think that it matters (legally) where the AD2 is >> seated: the administration of AD2 cannot be sued for allowing >> a person to teleport to RD1 (I hope :p). >> >> *************************************************************** >> * Hence, it is possible to apply the simplication: =A0 =A0 =A0 =A0 =A0 = =A0* >> *- AD policies ONLY come into play at the moment of teleport =A0* >> * =A0(allow or not). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* >> *- Once arrived in a new region, the policies of the AD can =A0 * >> * =A0be 'forgotten' and only the policies of the RD apply. =A0 =A0 =A0* >> * =A0If the AD doesn't want that, they shouldn't allow the TP. =A0* >> *************************************************************** >> >> We shouldn't take this simplification (or deployment limitation) too >> lightly, but I think it is one that will work VERY well in practice >> and well worth it, as it's benefits will far outweight the disadvantages= , >> imho. >> >> If anyone can think of a clear counter example where a TP should >> be allowed but still the AD ToS should determine what is allowed >> and what not, please let us know. >> >> A clear advantage of this simplification is that it makes >> it trivial where an Abuse Report would go to: namely the to the >> administration of the Region (domain). >> >> A clear disadvantage of NOT making this simplification is that >> it would be totally unclear where Abuse Reports have to go, and >> that lots of confusion will arise about who can do what and why >> they can and you not. >> >> -- >> Carlo Wood >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From infinity@lindenlab.com Mon Oct 5 11:40:04 2009 Return-Path: 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 693E43A6A16 for ; Mon, 5 Oct 2009 11:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 O0rRZ7j8Y9w8 for ; Mon, 5 Oct 2009 11:40:03 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 348663A68D6 for ; Mon, 5 Oct 2009 11:40:03 -0700 (PDT) Received: by pxi6 with SMTP id 6so3743932pxi.32 for ; Mon, 05 Oct 2009 11:41:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.196.7 with SMTP id t7mr30529wff.90.1254768094192; Mon, 05 Oct 2009 11:41:34 -0700 (PDT) In-Reply-To: References: <20091003222118.GA16290@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A0D8236@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910040421y41314922o4c5242c77941af4c@mail.gmail.com> <6.2.5.6.2.20091004072856.031ac940@resistor.net> <4646639E08F58B42836FAC24C94624DD771A0D827E@GVW0433EXB.americas.hpqcorp.net> <6.2.5.6.2.20091005015852.03101298@resistor.net> Date: Mon, 5 Oct 2009 11:41:34 -0700 Message-ID: <3a880e2c0910051141u3824b27fs80d6a0388356c36f@mail.gmail.com> From: Infinity Linden To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 18:40:04 -0000 i agree that identifying information should not be included in the protocol, but for use cases where such information is required for proper operation (i.e. - the adult verification example) we should not eliminate it as a possibility. i would recommend making it not be a required part of the protocol, but identify where in the protocol flows such information SHOULD be included if that option is to be used by collaborating AD's and RD's. one of the reasons LLSD was designed was for situations like this; it is quite possible for agent domains that do not want to reveal sensitive information (like the account holders age or whether they are considered an "adult" for the purposes of accessing adult content) then they do not have to include those bits of information in the protocol flow. these agent domains may find, howerver, that some region operators will refuse to allow them to place avatars in their regions. this is a POLICY issue that should be left entirely up to the AD and RD. morgaine, if the {agent|region} domain code you write wants to connect potentially underage account holders with adult content, that's entirely your call. however, there are a number of us here who operate in an environment in which these concerns are very real. also. i'm sure the people who have been sending email to you on this topic are perfectly capable of participating in the conversation here. -cheers -meadhbh On Mon, Oct 5, 2009 at 3:20 AM, Morgaine w= rote: > Judging by personal mails received on this topic, I sense that sanity is > prevailing, and that there is no desire nor intention to make trigger > concepts such as age, sex, race, religion, creed, DNA genome or any other > sensitive and/or personal information part of the protocol. > > It would be the thin end of the wedge, and I'm hoping that people are cle= ver > enough not to go there. > > Services are authenticated.=A0 Let that be enough. > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Mon, Oct 5, 2009 at 10:21 AM, SM wrote: >> >> At 09:18 04-10-2009, Dickson, Mike (ISS Software) wrote: >>> >>> Sure it does if I'm required to authenticate to use it. =A0That is, if = I'm >>> sending using my gmail.com address and I'm required to authenticate to = use >>> it then yes, its very possible >>> to make the association. =A0True, I may be able to find an SMTP server = that >>> will accept my >> >> That's mail submission. =A0I'll skip the discussion about the analogy. >> >> At 11:46 04-10-2009, Vaughn Deluca wrote: >>> >>> But the discussion is drifting, =A0were talking about the way that for >>> instance an age limit might be passed in the protocol. =A0Carlo said th= at info >>> was needed, Morgaine set it >>> =A0has no place in the protocol, using SMTP as an example, Mike stated = that >>> it is very well >> >> The discussion seems to be about acquiring policy information to authori= ze >> access to a resource and whether that should be part of the protocol. = =A0It >> could be age, location or other non-technical information. >> >> Regards, >> -sm >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From morgaine.dinova@googlemail.com Mon Oct 5 11:51:59 2009 Return-Path: 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 3212C3A6833 for ; Mon, 5 Oct 2009 11:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 3XlywEjOWJ7t for ; Mon, 5 Oct 2009 11:51:55 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 32F533A6863 for ; Mon, 5 Oct 2009 11:51:55 -0700 (PDT) Received: by ewy10 with SMTP id 10so3370668ewy.9 for ; Mon, 05 Oct 2009 11:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KXoKeyDuldWM52gbWhMB5VW9uKs7s+bbYxb5UAc42JI=; b=VrpdIrtCmcuyiHuymUdUgwNseH4Rr5ykOhnXIUpi3tZ6Mmd1egb7gn1EYXI6ptcGoc n4A9xKxyrvM8GKNcLk7dtVtUkABghiLQqCXEf5JFQPRgvMzJ5dHbTHQPUDwjx79uMZb9 yeUWK3PViLu/me0UK1z+kv7dhoRT6gs8cgyCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CTJpPWVhegJG0bntThSRP+3uXEKU6w+2LrdQw/snsXycwrIal93qILAusQkYWZnA3O Jix+1RN6kYI7A8kvolLPFPQDClOt670fdsIafxRWxuzJPjZLrRk019hqh+ga10MRKFFh p1RxoGGvTu1yXXWr1a4iUOb/Yv0CHyUwJV+70= MIME-Version: 1.0 Received: by 10.210.7.23 with SMTP id 23mr422947ebg.27.1254768808524; Mon, 05 Oct 2009 11:53:28 -0700 (PDT) In-Reply-To: <20091005182505.GA20468@alinoe.com> References: <20090904195822.GA15341@alinoe.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <20091002012335.GB690@alinoe.com> <20091005182505.GA20468@alinoe.com> Date: Mon, 5 Oct 2009 19:53:28 +0100 Message-ID: From: Morgaine To: Carlo Wood Content-Type: multipart/alternative; boundary=000e0cdfd7e61b7a98047534a1b5 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 18:51:59 -0000 --000e0cdfd7e61b7a98047534a1b5 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 5, 2009 at 7:25 PM, Carlo Wood wrote: > Nobody reacted to this post of me so far, does that mean everyone agrees? I agreed with your approach Carlo when I found total accord with Joshua here -- http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html . As you have probably noticed, we've been moving gradually towards your general position on RD-controlled region policy just by analysing deployment requirements. My post didn't make an arbitrary proposal that the AD's policy be limited to allowing the TP. Instead it reasoned out that this was the only known approach that provides DDP to allow tourism and at the same time allows us to omit querying AD2 on TP from RD1. This approach sounds fine to me Carlo, and it's quite simple, symmetrical and elegant. What's more, I can't think of any alternative, if we're constrained to not querying AD2. :-) Morgaine. =============================== On Mon, Oct 5, 2009 at 7:25 PM, Carlo Wood wrote: > Nobody reacted to this post of me so far, > does that mean everyone agrees? > > On Fri, Oct 02, 2009 at 03:23:35AM +0200, Carlo Wood wrote: > > On Thu, Oct 01, 2009 at 06:25:22PM -0400, David W Levine wrote: > > > We need to be careful, when looking at this stuff to strike a balance > between > > > focusing on the current deployed clusterings, and turning everything > into soup. > > > That said, the actual deployed systems which implement these > specifications are > > > only going to be able > > > to enforce policy at the interfaces we define, and these interfaces are > on > > > services, not domains. > > > > It is because we can't allow *every* possible deployment to be supported > (soup) > > that I brought up my worries about which service should determine policy > (ToS). > > > > It would be easy to choose a simplification (== not allow every > possibility) > > that leaves out a deployment that is essential, imho. > > > > My proposal was this: > > > > The AD can only allow a user to connect to (teleport to) a region > (domain) > > or not. If it allows a user to teleport there, then everything that that > > domain allows is allowed. > > > > I probably should have been more clear about this from the beginning: > > this (my concern) has everything to do with where Abuse Reports go to: > > Once a user is in a given region and breaks a policy (or not) and someone > > else wants to report this user, then the only authority that this report > > should go to is the administration of the region (personally, I even > > advocate the sim, but alas). > > > > If to whomever an 'abuse report' goes has nothing to do with VWRAP > > than we can skip this topic; but I think it might be relevant and it > > is certainly something we need to keep in mind while designing the > > protocol (to make sure that won't go wrong). > > > > Example: > > > > Region RD1 runs on servers in country X whose laws state that adult > > content may be accessed at the age of 16 or older. However, the > > administration of RD1 has it in their ToS that one has to be 18. > > They do not see a reason to ban people of age 16 or 17 however. > > > > Agentd AD2 is seated in another country where one has to be 21 before > > one is allowed to access adult content. AD2 does age verification. > > > > If a person of age 18 logs in with AD2 and tries to TP to RD1 then > > * AD2 may disallow that if they so choose. > > * If AD2 allows the TP, than the user is allowed to access adult > > content by the ToS of RD1 if their age is 18 or older. > > > > If the user lives in a country where 18 is old enough as well, > > than I don't think that it matters (legally) where the AD2 is > > seated: the administration of AD2 cannot be sued for allowing > > a person to teleport to RD1 (I hope :p). > > > > *************************************************************** > > * Hence, it is possible to apply the simplication: * > > *- AD policies ONLY come into play at the moment of teleport * > > * (allow or not). * > > *- Once arrived in a new region, the policies of the AD can * > > * be 'forgotten' and only the policies of the RD apply. * > > * If the AD doesn't want that, they shouldn't allow the TP. * > > *************************************************************** > > > > We shouldn't take this simplification (or deployment limitation) too > > lightly, but I think it is one that will work VERY well in practice > > and well worth it, as it's benefits will far outweight the disadvantages, > > imho. > > > > If anyone can think of a clear counter example where a TP should > > be allowed but still the AD ToS should determine what is allowed > > and what not, please let us know. > > > > A clear advantage of this simplification is that it makes > > it trivial where an Abuse Report would go to: namely the to the > > administration of the Region (domain). > > > > A clear disadvantage of NOT making this simplification is that > > it would be totally unclear where Abuse Reports have to go, and > > that lots of confusion will arise about who can do what and why > > they can and you not. > > > > -- > > Carlo Wood > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --000e0cdfd7e61b7a98047534a1b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 5, 2009 at 7:25 PM, Carlo Wood <carlo@alinoe.com> wrote:
Nobody reacted to this post of me so far, does that mean everyone agrees?

I agreed with your approach Carlo when I found total acc= ord with Joshua here -- http://www.ietf.org/mail-archive/web/ogpx/current/= msg00451.html .=A0 As you have probably noticed, we've been moving = gradually towards your general position on RD-controlled region policy just= by analysing deployment requirements.

My post didn't make an arbitrary proposal that the AD's policy = be limited to allowing the TP.=A0 Instead it reasoned out that this was the= only known approach that provides DDP to allow tourism and at the same tim= e allows us to omit querying AD2 on TP from RD1.

This approach sounds fine to me Carlo, and it's quite simple, symme= trical and elegant.=A0 What's more, I can't think of any alternativ= e, if we're constrained to not querying AD2. :-)


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On M= on, Oct 5, 2009 at 7:25 PM, Carlo Wood <carlo@alinoe.com> wrote:
Nobody reacted to this post of me so far,
does that mean everyone agrees?

On Fri, Oct 02, 2009 at 03:23:35AM +0200, Carlo Wood wrote:
> On Thu, Oct 01, 2009 at 06:25:22PM -0400, David W Levine wrote:
> > We need to be careful, when looking at this stuff to strike a bal= ance between
> > focusing on the current deployed clusterings, and turning everyth= ing into soup.
> > That said, the actual deployed systems which implement these spec= ifications are
> > only going to be able
> > to enforce policy at the interfaces we define, and these interfac= es are on
> > services, not domains.
>
> It is because we can't allow *every* possible deployment to be sup= ported (soup)
> that I brought up my worries about which service should determine poli= cy (ToS).
>
> It would be easy to choose a simplification (=3D=3D not allow every po= ssibility)
> that leaves out a deployment that is essential, imho.
>
> My proposal was this:
>
> The AD can only allow a user to connect to (teleport to) a region (dom= ain)
> or not. If it allows a user to teleport there, then everything that th= at
> domain allows is allowed.
>
> I probably should have been more clear about this from the beginning:<= br> > this (my concern) has everything to do with where Abuse Reports go to:=
> Once a user is in a given region and breaks a policy (or not) and some= one
> else wants to report this user, then the only authority that this repo= rt
> should go to is the administration of the region (personally, I even > advocate the sim, but alas).
>
> If to whomever an 'abuse report' goes has nothing to do with V= WRAP
> than we can skip this topic; but I think it might be relevant and it > is certainly something we need to keep in mind while designing the
> protocol (to make sure that won't go wrong).
>
> Example:
>
> Region RD1 runs on servers in country X whose laws state that adult > content may be accessed at the age of 16 or older. However, the
> administration of RD1 has it in their ToS that one has to be 18.
> They do not see a reason to ban people of age 16 or 17 however.
>
> Agentd AD2 is seated in another country where one has to be 21 before<= br> > one is allowed to access adult content. =A0AD2 does age verification.<= br> >
> If a person of age 18 logs in with AD2 and tries to TP to RD1 then
> * AD2 may disallow that if they so choose.
> * If AD2 allows the TP, than the user is allowed to access adult
> =A0 content by the ToS of RD1 if their age is 18 or older.
>
> If the user lives in a country where 18 is old enough as well,
> than I don't think that it matters (legally) where the AD2 is
> seated: the administration of AD2 cannot be sued for allowing
> a person to teleport to RD1 (I hope :p).
>
> ***************************************************************
> * Hence, it is possible to apply the simplication: =A0 =A0 =A0 =A0 =A0= =A0*
> *- AD policies ONLY come into play at the moment of teleport =A0*
> * =A0(allow or not). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*
> *- Once arrived in a new region, the policies of the AD can =A0 *
> * =A0be 'forgotten' and only the policies of the RD apply. =A0= =A0 =A0*
> * =A0If the AD doesn't want that, they shouldn't allow the TP.= =A0*
> ***************************************************************
>
> We shouldn't take this simplification (or deployment limitation) t= oo
> lightly, but I think it is one that will work VERY well in practice > and well worth it, as it's benefits will far outweight the disadva= ntages,
> imho.
>
> If anyone can think of a clear counter example where a TP should
> be allowed but still the AD ToS should determine what is allowed
> and what not, please let us know.
>
> A clear advantage of this simplification is that it makes
> it trivial where an Abuse Report would go to: namely the to the
> administration of the Region (domain).
>
> A clear disadvantage of NOT making this simplification is that
> it would be totally unclear where Abuse Reports have to go, and
> that lots of confusion will arise about who can do what and why
> they can and you not.
>
> --
> Carlo Wood <carlo@alinoe.com>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx

--
Carlo Wood <carlo@alinoe.com>=
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--000e0cdfd7e61b7a98047534a1b5-- From infinity@lindenlab.com Mon Oct 5 11:57:48 2009 Return-Path: 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 A037728C0F1 for ; Mon, 5 Oct 2009 11:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 vnD7VAZ4CiKL for ; Mon, 5 Oct 2009 11:57:47 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 1EF7D3A6A30 for ; Mon, 5 Oct 2009 11:57:47 -0700 (PDT) Received: by pxi6 with SMTP id 6so3758875pxi.32 for ; Mon, 05 Oct 2009 11:59:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.66.15 with SMTP id o15mr31337wfa.145.1254769159990; Mon, 05 Oct 2009 11:59:19 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> Date: Mon, 5 Oct 2009 11:59:19 -0700 Message-ID: <3a880e2c0910051159o77ca380qc5e9534e01f444b1@mail.gmail.com> From: Infinity Linden To: Morgaine Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 18:57:48 -0000 On Mon, Oct 5, 2009 at 10:54 AM, Morgaine wrote: > You're opening up a can of worms of biblical proportions here, Mike. > > What in hell's teeth is an "Adult only region"? an adult only region is a region which contains content that may be considered adult in nature. but again, this is a matter of policy, not a matter of protocol. the protocol should be able to carry tags protocol consumers can use to identify regions as having an "adult nature." > Who gets to define it? probably a lawyer familiar with the case history of accessing adult content on the internet. but again, this is a matter of policy, not a matter of protocol. the protocol should be able to carry tags protocol consumers can use to identify regions as having an "adult nature." > Under what rules? probably under rules radically similar to the ones currently used to define operator's policies. VWRAP is a protocol, not a product. the creation of a new protocol to carry information about virtual places does not change international legal frameworks. but again, this is a matter of policy, not a matter of protocol. the protocol should be able to carry tags protocol consumers can use to identify regions as having an "adult nature." > In what legal jurisdiction? probably under jurisdictions radically similar to the ones currently used to define operator's policies. but again, this is a matter of policy, not a matter of protocol. the protocol should be able to carry tags protocol consumers can use to identify regions as having an "adult nature." > And those are just the > simplest questions, pertaining to worlds that are merely reflections of t= he > physical world.=A0 What about virtual worlds that intentionally maintain > separation from RL, bearing in mind the recent augmentism versus > immersionism thread? in many jurisdictions, the intent of the service operator is not material to cases related to the distribution of adult content. but again, this is a matter of policy, not a matter of protocol. the protocol should be able to carry tags protocol consumers can use to identify regions as having an "adult nature." > Each immersionist's world is separate from all others, > and your value judgements from elsewhere are not importable to those > worlds.=A0 What about fantasy worlds? in many jurisdictions, the intent of the service operator is not material to cases related to the distribution of adult content. but again, this is a matter of policy, not a matter of protocol. the protocol should be able to carry tags protocol consumers can use to identify regions as having an "adult nature." > Is a naked orc "Adult content"? ugh. unfortunately, we won't know that until someone raises a legal challenge which is either successfully defended against or successfully prosecuted. some jurisdictions may simply restrict access to content they do not like. but again, this is a matter of policy, not a matter of protocol. the protocol should be able to carry tags protocol consumers can use to identify regions as having an "adult nature." > How do you judge "Adult only" in a virtual world set in our distant futur= e? you don't. because we're talking about a protocol that can be used in the near future. the distant future can take care of itself. but again, this is a matter of policy, not a matter of protocol. the protocol should be able to carry tags protocol consumers can use to identify regions as having an "adult nature." > How do you judge "Adult only" in a virtual world of aliens? ugh. unfortunately, we won't know that until someone raises a legal challenge which is either successfully defended against or successfully prosecuted. some jurisdictions may simply restrict access to content they do not like. but again, this is a matter of policy, not a matter of protocol. the protocol should be able to carry tags protocol consumers can use to identify regions as having an "adult nature." >What about in a virtual world of classic art recreations in all their nak= ed and educational > glory? ugh. unfortunately, we won't know that until someone raises a legal challenge which is either successfully defended against or successfully prosecuted. some jurisdictions may simply restrict access to content they do not like. but again, this is a matter of policy, not a matter of protocol. the protocol should be able to carry tags protocol consumers can use to identify regions as having an "adult nature." > And there are probably another 500 questions like this one. it's okay. bits are cheap. > It's not just a can of worms.=A0 It's totally unworkable, nothing more th= an > theater, and verging on farce or comedy.=A0 I bet that some readers here = who > are not exposed to recent events in Second Life may be wondering why this > topic has even appeared in these discussions. the fact of the matter is that laws and regulations covering access of "adult" material is a patchwork and is frequently difficult to navigate. saying "it's difficult" and ignoring it (like you recommended we do with security in the MMOX discussions) is not an option. there are many people who want to use this protocol that want a tool to help limit their exposure to legal liability. > One particular world provider has implemented a ratings system within its > own walled garden, and this has been confused with the requirements of > interop outside of a walled garden.=A0 Such ratings systems may be workab= le > within a single managed domain in which the provider has total control ov= er > region spaces and asset services and can sanction individuals who break t= he > rules, but it does not extrapolate to multiple worlds with separate Terms > and Conditions, different jurisdictions, or varying cultures, even when > they're all mirrors of the physical world.=A0 Even less can it work or ap= ply > in the general case of immersionist virtual worlds. very well then. how do you recommend virtual world operators shield themselves from legal liability? > > This is extremely poorly considered, on numerous fronts. > > Authentication is more than enough for coarsely segregating highly > restricted enclaves from the general mass of virtual worlds.=A0 Going bey= ond > that is simply unworkable across multiple separate virtual virtual worlds= , > when you look at the implications. > > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Mon, Oct 5, 2009 at 3:48 PM, Dickson, Mike (ISS Software) > wrote: >> >> I think Magnus=92 message is a good synopsis of the requirements, IMO.= =A0 I >> see a need to negotiate *both* capabilities and constraints in the proto= col >> where both should be ideally attributes in an extensible list (that is t= he >> list isn=92t hard coded in the protocol definition).=A0 So, IMO, authent= ication >> isn=92t enough.=A0 Beyond authenticating there=92s an exchange around ca= ps and >> constraints that needs to take place.=A0 I=92d use that mechanism to han= dle >> =93Adult only=94 regions, membership in a group where the group is defin= ed >> outside the scope of the protocol, etc. >> >> >> >> Mike >> >> >> >> From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of >> Magnus Zeisig >> Sent: Monday, October 05, 2009 3:55 AM >> To: ogpx@ietf.org >> Subject: [ogpx] Protocol for permitting policy decisions >> >> >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA256 >> >> >> >> If I register with an agent domain, or authentication service, whichever >> should be the proper name for it, I will most probably hand them some pi= eces >> of information about myself that I don't want disseminated to anyone. >> Therefore, I think the protocol for granting access to regions and other >> services should not include such information explicitly, but rather let = the >> agent domain/authentication service just answer questions from the other >> domain/service if the parameters are within acceptable range. >> >> >> >> Instead of the revealing (meta-handshake): >> >> >> >> Agent domain: >> >> request access for >> >> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org >> >> age: 18 >> >> gender: male >> >> sexuality: bi >> >> country: pt >> >> languages: pt, es, en, de >> >> length: 1.82 >> >> weight: 122 >> >> color of socks: blue >> >> >> >> Region domain: >> >> access granted for >> >> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org >> >> >> >> The handshake should instead be: >> >> >> >> Agent domain: >> >> request access for >> >> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org >> >> >> >> Region domain: >> >> require parameter values >> >> languages: es AND (de OR hb OR ru) >> >> length: [1.21-2.42] >> >> color of socks: pink OR blue OR black >> >> hairdo: shaved OR ponytail >> >> >> >> Agent domain: >> >> required parameter values >> >> languages: yes >> >> length: yes >> >> color of socks: yes >> >> hairdo: n/a >> >> >> >> After which the region domain might decide that the missing hairdo >> parameter is not crucial and grant access, or refuse access because of i= t: >> >> >> >> Region domain: >> >> access denied for >> >> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org >> >> >> >> This has the benefit of permitting service providers to require what use= r >> parameters they think are important, be it age or color of socks, but th= e >> disadvantage of some extra overhead and the risk of balkanization becaus= e of >> requirements of "odd" parameters only supported by few services. The lat= ter, >> however, I believe will become self-eliminating, because such services w= ill >> probably not find many users. Either way, I don't think the protocol in >> itself should require any particular parameters, like age or color of so= cks, >> just provide the means to communicate any parameters, and perhaps sugges= t a >> list of possible, but not required, parameters and formats for values, l= ike >> options, ranges and enumerations. The same kind of handshake could also = be >> used when requesting access to asset services and the like, even if >> parameters like "object types" and "ip agreements" may be more important >> than "color of socks" there. >> >> >> >> Best regards, >> >> >> >> Magnus >> >> >> >> >> >> -----BEGIN PGP SIGNATURE----- >> >> Version: 9.8.3 (Build 4028) >> >> Charset: utf-8 >> >> >> >> wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g >> >> rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc >> >> YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu >> >> ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr >> >> vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb >> >> 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg=3D=3D >> >> =3DH2Fj >> >> -----END PGP SIGNATURE----- >> >> >> >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From infinity@lindenlab.com Mon Oct 5 12:18:10 2009 Return-Path: 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 5DD4C28C0F4 for ; Mon, 5 Oct 2009 12:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 1drb-SGvlZ0g for ; Mon, 5 Oct 2009 12:18:09 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 1281A28C0F2 for ; Mon, 5 Oct 2009 12:18:09 -0700 (PDT) Received: by pzk35 with SMTP id 35so1370545pzk.29 for ; Mon, 05 Oct 2009 12:19:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.5.35 with SMTP id 35mr31001wfe.69.1254770380323; Mon, 05 Oct 2009 12:19:40 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A1562F4@GVW0433EXB.americas.hpqcorp.net> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> <4646639E08F58B42836FAC24C94624DD771A1562F4@GVW0433EXB.americas.hpqcorp.net> Date: Mon, 5 Oct 2009 12:19:40 -0700 Message-ID: <3a880e2c0910051219k659d3425re177a4ebb9604162@mail.gmail.com> From: Infinity Linden To: "Dickson, Mike (ISS Software)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 19:18:10 -0000 mike, don't let morgaine shout you down. i'm interested in having a serious conversation about the subject. a number of us will need to develop a "regime" regions may use to flag the presence of adult content. and the protocol flows should be able to carry this (and related) information so either the AD or the RD can make whatever policy decisions they think they need to make. that being said... morgaine's comments do show the difficulty (or even impossibility) of trying to create an internet-wide standard for adult content. but, if we don't add this to the standard, i think a lot of people will be implementing their own, incompatible standard. (i mean a standard for carrying meta data about the content of a region.) second life currently has three levels of maturity (four if you count the teen grid.) i cannot imagine we would ditch that for the privilege of using a new standard. i would simply recommend that when we get around to defining the information about a region communicated to an agent domain, we include the provision for the communication of meta-data about the region and leave it at that. we could then leave it as a matter of policy for agent domains and region domains to define the semantics of values defined for a "maturity" key. keep in mind that this protocol is intended to be flexible. we don't have to define the meaning of region labels in the protocol. in fact, we don't have to define the "maturity" key at all. all we have to do is say "this is where you put the meta-data." if we wanted, we _could_ list a maturity key in the region descriptor. if we don't do it here, it's not the end of the world. people will define their own schemes. (for instance, i can't imagine second life would be deployed without such a feature.) or, we could create one and just tell people who don't care about enforcing these rules to simply ignore them. at the end of the day, you can't detect "adult content" in an automated fashion, so the "adult content" tag is purely discretionary. the protocol will not break if you fail to honor the maturity tag. i suspect that if we defined a maturity scheme as part of the protocol, it would wind up being something like HTTP authentication. a system that is widely used, but due to it's weaknesses is frequently augmented by other tools (like TLS) or completely replaced (like logging in via a form, then having the server set an access token cookie.) but just because HTTP auth has it's problems, doesn't mean they removed headers from HTTP messages. -cheers -meadhbh On Mon, Oct 5, 2009 at 11:07 AM, Dickson, Mike (ISS Software) wrote: > I=92m going to drop this since I=92m a poor choice to defend the case. = =A0In > principle I agree with Morgaine and the LL folks don=92t seem to see a ne= ed > for this sort of handshake.=A0 I do personally see cases where the AD and= RD > may want to share attribute information on a connect but it could be done > out of band and so isn=92t really required to make the VWRAP bits work.= =A0 And > in answer to the question Morgaine raised=85 i.e. =A0who gets define what= adult > only is, it=92s the region IMO hence the reason (if I understood) =A0Mead= bah > argued it=92s a matter of policy and not protocol. > > > > Apologies if I tested anyone=92s patience.=A0 I=92m still working through= these > cases in my own head. > > > > Mike > > > > From: Morgaine [mailto:morgaine.dinova@googlemail.com] > Sent: Monday, October 05, 2009 12:54 PM > > To: Dickson, Mike (ISS Software) > Cc: ogpx@ietf.org > Subject: Re: [ogpx] Protocol for permitting policy decisions > > > > You're opening up a can of worms of biblical proportions here, Mike. > > What in hell's teeth is an "Adult only region"?=A0 Who gets to define it? > Under what rules?=A0 In what legal jurisdiction?=A0 And those are just th= e > simplest questions, pertaining to worlds that are merely reflections of t= he > physical world.=A0 What about virtual worlds that intentionally maintain > separation from RL, bearing in mind the recent augmentism versus > immersionism thread?=A0 Each immersionist's world is separate from all ot= hers, > and your value judgements from elsewhere are not importable to those > worlds.=A0 What about fantasy worlds?=A0 Is a naked orc "Adult content"?= =A0 How do > you judge "Adult only" in a virtual world set in our distant future?=A0 H= ow do > you judge "Adult only" in a virtual world of aliens?=A0 What about in a > virtual world of classic art recreations in all their naked and education= al > glory?=A0 And there are probably another 500 questions like this one. > > It's not just a can of worms.=A0 It's totally unworkable, nothing more th= an > theater, and verging on farce or comedy.=A0 I bet that some readers here = who > are not exposed to recent events in Second Life may be wondering why this > topic has even appeared in these discussions. > > One particular world provider has implemented a ratings system within its > own walled garden, and this has been confused with the requirements of > interop outside of a walled garden.=A0 Such ratings systems may be workab= le > within a single managed domain in which the provider has total control ov= er > region spaces and asset services and can sanction individuals who break t= he > rules, but it does not extrapolate to multiple worlds with separate Terms > and Conditions, different jurisdictions, or varying cultures, even when > they're all mirrors of the physical world.=A0 Even less can it work or ap= ply > in the general case of immersionist virtual worlds. > > This is extremely poorly considered, on numerous fronts. > > Authentication is more than enough for coarsely segregating highly > restricted enclaves from the general mass of virtual worlds.=A0 Going bey= ond > that is simply unworkable across multiple separate virtual virtual worlds= , > when you look at the implications. > > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Mon, Oct 5, 2009 at 3:48 PM, Dickson, Mike (ISS Software) > wrote: > > I think Magnus=92 message is a good synopsis of the requirements, IMO.=A0= I see > a need to negotiate *both* capabilities and constraints in the protocol > where both should be ideally attributes in an extensible list (that is th= e > list isn=92t hard coded in the protocol definition).=A0 So, IMO, authenti= cation > isn=92t enough.=A0 Beyond authenticating there=92s an exchange around cap= s and > constraints that needs to take place.=A0 I=92d use that mechanism to hand= le > =93Adult only=94 regions, membership in a group where the group is define= d > outside the scope of the protocol, etc. > > > > Mike > > > > From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of > Magnus Zeisig > Sent: Monday, October 05, 2009 3:55 AM > To: ogpx@ietf.org > Subject: [ogpx] Protocol for permitting policy decisions > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > If I register with an agent domain, or authentication service, whichever > should be the proper name for it, I will most probably hand them some pie= ces > of information about myself that I don't want disseminated to anyone. > Therefore, I think the protocol for granting access to regions and other > services should not include such information explicitly, but rather let t= he > agent domain/authentication service just answer questions from the other > domain/service if the parameters are within acceptable range. > > > > Instead of the revealing (meta-handshake): > > > > Agent domain: > > request access for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > age: 18 > > gender: male > > sexuality: bi > > country: pt > > languages: pt, es, en, de > > length: 1.82 > > weight: 122 > > color of socks: blue > > > > Region domain: > > access granted for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > The handshake should instead be: > > > > Agent domain: > > request access for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > Region domain: > > require parameter values > > languages: es AND (de OR hb OR ru) > > length: [1.21-2.42] > > color of socks: pink OR blue OR black > > hairdo: shaved OR ponytail > > > > Agent domain: > > required parameter values > > languages: yes > > length: yes > > color of socks: yes > > hairdo: n/a > > > > After which the region domain might decide that the missing hairdo parame= ter > is not crucial and grant access, or refuse access because of it: > > > > Region domain: > > access denied for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > This has the benefit of permitting service providers to require what user > parameters they think are important, be it age or color of socks, but the > disadvantage of some extra overhead and the risk of balkanization because= of > requirements of "odd" parameters only supported by few services. The latt= er, > however, I believe will become self-eliminating, because such services wi= ll > probably not find many users. Either way, I don't think the protocol in > itself should require any particular parameters, like age or color of soc= ks, > just provide the means to communicate any parameters, and perhaps suggest= a > list of possible, but not required, parameters and formats for values, li= ke > options, ranges and enumerations. The same kind of handshake could also b= e > used when requesting access to asset services and the like, even if > parameters like "object types" and "ip agreements" may be more important > than "color of socks" there. > > > > Best regards, > > > > Magnus > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: 9.8.3 (Build 4028) > > Charset: utf-8 > > > > wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g > > rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc > > YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu > > ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr > > vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb > > 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg=3D=3D > > =3DH2Fj > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From infinity@lindenlab.com Mon Oct 5 12:38:00 2009 Return-Path: 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 965F828C225 for ; Mon, 5 Oct 2009 12:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 0ycXuSAPQIrC for ; Mon, 5 Oct 2009 12:37:59 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 7ECC43A686B for ; Mon, 5 Oct 2009 12:37:59 -0700 (PDT) Received: by pzk35 with SMTP id 35so1387887pzk.29 for ; Mon, 05 Oct 2009 12:39:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.250.6 with SMTP id x6mr30370wfh.292.1254771572578; Mon, 05 Oct 2009 12:39:32 -0700 (PDT) In-Reply-To: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> Date: Mon, 5 Oct 2009 12:39:32 -0700 Message-ID: <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> From: Infinity Linden To: Magnus Zeisig Content-Type: text/plain; charset=ISO-8859-1 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 19:38:00 -0000 right. this is similar to what i was talking about in one of the previously mentioned options. i mentioned that the region might need to call back into the agent domain to get more information about a particular agent. to me it looks like you're suggesting a two-message handshake instead of the region turning around and querying the agent domain. lemme draw some diagrams: "name" and "age" are bits of data that, like you might expect, are an account identifier and the account holder's age. "rez cap" is the capability used to establish the agent's presence in that region. "age > X? cap" is a capability granted to the agent domain that's supposed to be used by the agent domain only if the agent domain agrees that the account holder is older than X. option 1: information push AD ------------ ( name, age ) ---------> RD AD <------------- (rez cap) ------------ RD option 2: RD queries the AD AD --------------- (name) -------------> RD AD <----- (is name older than X?) ------ RD AD -------------- (yes/no) ------------> RD AD <------------ (rez cap) ------------- RD option 3: multi-message handshake AD --------------- (name) -------------> RD AD <-------- (X, age > X? cap) --------- RD AD ------------------------------------> RD (age > X? cap) AD <------------ (rez cap) ------------- RD option 3 here is my attempt to model what magnus is talking about, but with a RESTful capability system. -cheers -meadhbh On Mon, Oct 5, 2009 at 1:55 AM, Magnus Zeisig wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > If I register with an agent domain, or authentication service, whichever > should be the proper name for it, I will most probably hand them some pieces > of information about myself that I don't want disseminated to anyone. > Therefore, I think the protocol for granting access to regions and other > services should not include such information explicitly, but rather let the > agent domain/authentication service just answer questions from the other > domain/service if the parameters are within acceptable range. > > Instead of the revealing (meta-handshake): > > Agent domain: > request access for > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > age: 18 > gender: male > sexuality: bi > country: pt > languages: pt, es, en, de > length: 1.82 > weight: 122 > color of socks: blue > > Region domain: > access granted for > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > The handshake should instead be: > > Agent domain: > request access for > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > Region domain: > require parameter values > languages: es AND (de OR hb OR ru) > length: [1.21-2.42] > color of socks: pink OR blue OR black > hairdo: shaved OR ponytail > > Agent domain: > required parameter values > languages: yes > length: yes > color of socks: yes > hairdo: n/a > > After which the region domain might decide that the missing hairdo parameter > is not crucial and grant access, or refuse access because of it: > > Region domain: > access denied for > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > This has the benefit of permitting service providers to require what user > parameters they think are important, be it age or color of socks, but the > disadvantage of some extra overhead and the risk of balkanization because of > requirements of "odd" parameters only supported by few services. The latter, > however, I believe will become self-eliminating, because such services will > probably not find many users. Either way, I don't think the protocol in > itself should require any particular parameters, like age or color of socks, > just provide the means to communicate any parameters, and perhaps suggest a > list of possible, but not required, parameters and formats for values, like > options, ranges and enumerations. The same kind of handshake could also be > used when requesting access to asset services and the like, even if > parameters like "object types" and "ip agreements" may be more important > than "color of socks" there. > > Best regards, > > Magnus > > > -----BEGIN PGP SIGNATURE----- > Version: 9.8.3 (Build 4028) > Charset: utf-8 > > wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g > rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc > YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu > ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr > vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb > 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg== > =H2Fj > -----END PGP SIGNATURE----- > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From dwl@us.ibm.com Mon Oct 5 13:19:08 2009 Return-Path: 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 DA66228C2A1; Mon, 5 Oct 2009 13:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.756 X-Spam-Level: X-Spam-Status: No, score=-5.756 tagged_above=-999 required=5 tests=[AWL=0.842, BAYES_00=-2.599, 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 uO-3fayPaISy; Mon, 5 Oct 2009 13:19: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 7F4BF3A6975; Mon, 5 Oct 2009 13:19: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 n95KBBCF023338; Mon, 5 Oct 2009 16:11:11 -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 n95KKZWa254638; Mon, 5 Oct 2009 16:20:35 -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 n95KHDdm023783; Mon, 5 Oct 2009 16:17:13 -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 n95KHDto023758; Mon, 5 Oct 2009 16:17:13 -0400 In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A156244@GVW0433EXB.americas.hpqcorp.net> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> <4646639E08F58B42836FAC24C94624DD771A156244@GVW0433EXB.americas.hpqcorp.net> To: "Dickson, Mike (ISS Software)" MIME-Version: 1.0 X-KeepSent: 714157A7:67B36655-85257646:005F0B45; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Mon, 5 Oct 2009 16:20:28 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/05/2009 16:20:33, Serialize complete at 10/05/2009 16:20:33 Content-Type: multipart/alternative; boundary="=_alternative 006FBCCE85257646_=" Cc: Meadhbh Siobhan , "ogpx@ietf.org" , ogpx-bounces@ietf.org, Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 20:19:09 -0000 This is a multipart message in MIME format. --=_alternative 006FBCCE85257646_= Content-Type: text/plain; charset="US-ASCII" So.. to sound like a broken record The policy decisions end up being applied to services. To an extent, this sort of implies that the enforcement point *has* to be the service, not the "domain" but.. one important point right behind this. There is nothing which prevents a region from letting a front end service handle access to it. In particular, one very sane model for handling the cap grant to a large cluster of regions is to deploy that on a front end box, which handles all of that separate from the region process, and hands out caps to the actual region. - David "Dickson, Mike (ISS Software)" Sent by: ogpx-bounces@ietf.org 10/05/2009 01:12 PM To Meadhbh Siobhan cc "ogpx@ietf.org" , Magnus Zeisig Subject Re: [ogpx] Protocol for permitting policy decisions I think I buy it in the case you put forward. That is if you simplify the problem so that AD itself specifies the constraint (the AD in your example only carries accounts from the sea scouts). But what if I'm running multiple regions with different policies all served by a single AD? Are you suggesting that each region needs to handle the policy for its own? Picking on what is probably a corner case but one that's been raised... If I'm running multiple regions, some of which are "Adult" and some are not, does treating constraints as outside the protocol require each RD to do the age verification (I could make a case the answer is yes since "Adultness" might differ depending on who/where I am). And if so how do they do that without getting "sensitive information" that is probably best owned by the AD. Is it reasonable perhaps for a RD to delegate that to the AD and provide a mechanism to negotiate the details on connect so I can centralize such decisions in a single place? Mike -----Original Message----- From: Meadhbh Siobhan [mailto:meadhbh.siobhan@gmail.com] Sent: Monday, October 05, 2009 11:33 AM To: Dickson, Mike (ISS Software) Cc: Magnus Zeisig; ogpx@ietf.org Subject: Re: [ogpx] Protocol for permitting policy decisions again, this is a matter of policy, not a matter of protocol. let me give you a counter example. some trusted organization, maybe the new zealand sea scouts, decides it wants a virtual social space to teach seamanship, knot tying and whatever else scouts are taught these days. the sea scouts organization is not really known for it's ability to maintain a reasonably large networking and system infrastructure, so instead of building the service themselves, they outsource. at this point, there are a couple of options open to them. they can give their entire user database to a third party and hope for the best. or they can give portions of their user database (name, email address, adult / minor boolean.) or they could put a VWRAP authentication service that they maintain in front of their user database. each are valid options. one would hope that in the first two options, they worked out with the third party some pretty hard-core data retention and privacy policies. so what if they did the third option? what would the protocol have to do? the sea scout's agent domain would only allow agents to enter a private virtual world. the sea scouts would negotiate with their region domain provider to ensure that adult content was not allowed in the regions accessible by the sea scout agent domain. moreover, the region domain provider could ensure that ONLY agents with accounts from the sea scouts would get access to the sea scouts virtual spaces. so the answer to the question of "what does the protocol have to do?" is that it only has to convey information about the identity of the agent domain to the region provider. it also has to have a mechanism for the agent domain to identify the region. but the protocol itself does not impose restrictions as to the identity of either party. that is a policy issue. in other words, if you don't want to use an agent domain / region domain pair that provides information about you to a trusted third party, don't give that information the the agent domain in the first place. or double check that the agent domain's privacy policy requires third parties to which it reveals information to treat that information with due care. that being said, some people's paranoia level is higher than others, so maybe we could have multiple techniques defined for sharing sensitive information, none of which are mandatory. -cheers -meadhbh On Mon, Oct 5, 2009 at 7:48 AM, Dickson, Mike (ISS Software) wrote: > I think Magnus' message is a good synopsis of the requirements, IMO. I see > a need to negotiate *both* capabilities and constraints in the protocol > where both should be ideally attributes in an extensible list (that is the > list isn't hard coded in the protocol definition). So, IMO, authentication > isn't enough. Beyond authenticating there's an exchange around caps and > constraints that needs to take place. I'd use that mechanism to handle > "Adult only" regions, membership in a group where the group is defined > outside the scope of the protocol, etc. > > > > Mike > > > > From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of > Magnus Zeisig > Sent: Monday, October 05, 2009 3:55 AM > To: ogpx@ietf.org > Subject: [ogpx] Protocol for permitting policy decisions > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > If I register with an agent domain, or authentication service, whichever > should be the proper name for it, I will most probably hand them some pieces > of information about myself that I don't want disseminated to anyone. > Therefore, I think the protocol for granting access to regions and other > services should not include such information explicitly, but rather let the > agent domain/authentication service just answer questions from the other > domain/service if the parameters are within acceptable range. > > > > Instead of the revealing (meta-handshake): > > > > Agent domain: > > request access for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > age: 18 > > gender: male > > sexuality: bi > > country: pt > > languages: pt, es, en, de > > length: 1.82 > > weight: 122 > > color of socks: blue > > > > Region domain: > > access granted for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > The handshake should instead be: > > > > Agent domain: > > request access for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > Region domain: > > require parameter values > > languages: es AND (de OR hb OR ru) > > length: [1.21-2.42] > > color of socks: pink OR blue OR black > > hairdo: shaved OR ponytail > > > > Agent domain: > > required parameter values > > languages: yes > > length: yes > > color of socks: yes > > hairdo: n/a > > > > After which the region domain might decide that the missing hairdo parameter > is not crucial and grant access, or refuse access because of it: > > > > Region domain: > > access denied for > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > This has the benefit of permitting service providers to require what user > parameters they think are important, be it age or color of socks, but the > disadvantage of some extra overhead and the risk of balkanization because of > requirements of "odd" parameters only supported by few services. The latter, > however, I believe will become self-eliminating, because such services will > probably not find many users. Either way, I don't think the protocol in > itself should require any particular parameters, like age or color of socks, > just provide the means to communicate any parameters, and perhaps suggest a > list of possible, but not required, parameters and formats for values, like > options, ranges and enumerations. The same kind of handshake could also be > used when requesting access to asset services and the like, even if > parameters like "object types" and "ip agreements" may be more important > than "color of socks" there. > > > > Best regards, > > > > Magnus > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: 9.8.3 (Build 4028) > > Charset: utf-8 > > > > wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g > > rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc > > YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu > > ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr > > vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb > > 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg== > > =H2Fj > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 006FBCCE85257646_= Content-Type: text/html; charset="US-ASCII"
So.. to sound like a broken record The policy decisions end up being applied to services. To an extent, this sort of implies that the enforcement point *has* to be the service, not the "domain" but.. one important point right behind this.
There is nothing which prevents a region from letting a front end service handle access to it. In particular, one very sane model for handling the cap grant to a large cluster of regions is to deploy that on a front end box, which handles
all of that separate from the region process, and hands out caps to the actual region.

- David



"Dickson, Mike (ISS Software)" <mike.dickson@hp.com>
Sent by: ogpx-bounces@ietf.org

10/05/2009 01:12 PM

To
Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
cc
"ogpx@ietf.org" <ogpx@ietf.org>, Magnus Zeisig <magnus.zeisig@iis.se>
Subject
Re: [ogpx] Protocol for permitting policy decisions





I think I buy it in the case you put forward.  That is if you simplify the problem so that AD itself specifies the constraint (the AD in your example only carries accounts from the sea scouts).  But what if I'm running multiple regions with different policies all served by a single AD? Are you suggesting that each region needs to handle the policy for its own?

Picking on what is probably a corner case but one that's been raised...  If I'm running multiple regions, some of which are "Adult" and some are not, does treating constraints as outside the protocol require each RD to do the age verification (I could make a case the answer is yes since "Adultness" might differ depending on who/where I am).  And if so how do they do that without getting "sensitive information" that is probably best owned by the AD.  Is it reasonable perhaps for a RD to delegate that to the AD and provide a mechanism to negotiate the details on connect so I can centralize such decisions in a single place?

Mike

-----Original Message-----
From: Meadhbh Siobhan [mailto:meadhbh.siobhan@gmail.com]
Sent: Monday, October 05, 2009 11:33 AM
To: Dickson, Mike (ISS Software)
Cc: Magnus Zeisig; ogpx@ietf.org
Subject: Re: [ogpx] Protocol for permitting policy decisions

again, this is a matter of policy, not a matter of protocol.

let me give you a counter example. some trusted organization, maybe
the new zealand sea scouts, decides it wants a virtual social space to
teach seamanship, knot tying and whatever else scouts are taught these
days.

the sea scouts organization is not really known for it's ability to
maintain a reasonably large networking and system infrastructure, so
instead of building the service themselves, they outsource.

at this point, there are a couple of options open to them. they can
give their entire user database to a third party and hope for the
best. or they can give portions of their user database (name, email
address, adult / minor boolean.) or they could put a VWRAP
authentication service that they maintain in front of their user
database. each are valid options.

one would hope that in the first two options, they worked out with the
third party some pretty hard-core data retention and privacy policies.

so what if they did the third option? what would the protocol have to
do? the sea scout's agent domain would only allow agents to enter a
private virtual world. the sea scouts would negotiate with their
region domain provider to ensure that adult content was not allowed in
the regions accessible by the sea scout agent domain. moreover, the
region domain provider could ensure that ONLY agents with accounts
from the sea scouts would get access to the sea scouts virtual spaces.

so the answer to the question of "what does the protocol have to do?"
is that it only has to convey information about the identity of the
agent domain to the region provider. it also has to have a mechanism
for the agent domain to identify the region.

but the protocol itself does not impose restrictions as to the
identity of either party. that is a policy issue.

in other words, if you don't want to use an agent domain  / region
domain pair that provides information about you to a trusted third
party, don't give that information the the agent domain in the first
place. or double check that the agent domain's privacy policy requires
third parties to which it reveals information to  treat that
information with due care.

that being said, some people's paranoia level is higher than others,
so maybe we could have multiple techniques defined for sharing
sensitive information, none of which are mandatory.

-cheers
-meadhbh

On Mon, Oct 5, 2009 at 7:48 AM, Dickson, Mike (ISS Software)
<mike.dickson@hp.com> wrote:
> I think Magnus' message is a good synopsis of the requirements, IMO.  I see
> a need to negotiate *both* capabilities and constraints in the protocol
> where both should be ideally attributes in an extensible list (that is the
> list isn't hard coded in the protocol definition).  So, IMO, authentication
> isn't enough.  Beyond authenticating there's an exchange around caps and
> constraints that needs to take place.  I'd use that mechanism to handle
> "Adult only" regions, membership in a group where the group is defined
> outside the scope of the protocol, etc.
>
>
>
> Mike
>
>
>
> From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of
> Magnus Zeisig
> Sent: Monday, October 05, 2009 3:55 AM
> To: ogpx@ietf.org
> Subject: [ogpx] Protocol for permitting policy decisions
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Hash: SHA256
>
>
>
> If I register with an agent domain, or authentication service, whichever
> should be the proper name for it, I will most probably hand them some pieces
> of information about myself that I don't want disseminated to anyone.
> Therefore, I think the protocol for granting access to regions and other
> services should not include such information explicitly, but rather let the
> agent domain/authentication service just answer questions from the other
> domain/service if the parameters are within acceptable range.
>
>
>
> Instead of the revealing (meta-handshake):
>
>
>
> Agent domain:
>
> request access for
>
> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org
>
> age: 18
>
> gender: male
>
> sexuality: bi
>
> country: pt
>
> languages: pt, es, en, de
>
> length: 1.82
>
> weight: 122
>
> color of socks: blue
>
>
>
> Region domain:
>
> access granted for
>
> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org
>
>
>
> The handshake should instead be:
>
>
>
> Agent domain:
>
> request access for
>
> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org
>
>
>
> Region domain:
>
> require parameter values
>
> languages: es AND (de OR hb OR ru)
>
> length: [1.21-2.42]
>
> color of socks: pink OR blue OR black
>
> hairdo: shaved OR ponytail
>
>
>
> Agent domain:
>
> required parameter values
>
> languages: yes
>
> length: yes
>
> color of socks: yes
>
> hairdo: n/a
>
>
>
> After which the region domain might decide that the missing hairdo parameter
> is not crucial and grant access, or refuse access because of it:
>
>
>
> Region domain:
>
> access denied for
>
> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org
>
>
>
> This has the benefit of permitting service providers to require what user
> parameters they think are important, be it age or color of socks, but the
> disadvantage of some extra overhead and the risk of balkanization because of
> requirements of "odd" parameters only supported by few services. The latter,
> however, I believe will become self-eliminating, because such services will
> probably not find many users. Either way, I don't think the protocol in
> itself should require any particular parameters, like age or color of socks,
> just provide the means to communicate any parameters, and perhaps suggest a
> list of possible, but not required, parameters and formats for values, like
> options, ranges and enumerations. The same kind of handshake could also be
> used when requesting access to asset services and the like, even if
> parameters like "object types" and "ip agreements" may be more important
> than "color of socks" there.
>
>
>
> Best regards,
>
>
>
> Magnus
>
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> Version: 9.8.3 (Build 4028)
>
> Charset: utf-8
>
>
>
> wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g
>
> rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc
>
> YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu
>
> ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr
>
> vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb
>
> 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg==
>
> =H2Fj
>
> -----END PGP SIGNATURE-----
>
>
>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 006FBCCE85257646_=-- From dwl@us.ibm.com Mon Oct 5 13:32:07 2009 Return-Path: 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 17C763A6A36; Mon, 5 Oct 2009 13:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.794 X-Spam-Level: X-Spam-Status: No, score=-5.794 tagged_above=-999 required=5 tests=[AWL=0.804, BAYES_00=-2.599, 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 FcgsygYiAIqk; Mon, 5 Oct 2009 13:32:05 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 3C67B3A6A34; Mon, 5 Oct 2009 13:32:05 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n95KQGlV013891; Mon, 5 Oct 2009 16:26:16 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n95KXe5h189980; Mon, 5 Oct 2009 16:33:40 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n95KXdsn013036; Mon, 5 Oct 2009 16:33:39 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n95KXdco013027; Mon, 5 Oct 2009 16:33:39 -0400 In-Reply-To: <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> To: Infinity Linden MIME-Version: 1.0 X-KeepSent: E55CFEA3:6AD0DA74-85257646:006FC774; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Mon, 5 Oct 2009 16:33:38 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/05/2009 16:33:39, Serialize complete at 10/05/2009 16:33:39 Content-Type: multipart/alternative; boundary="=_alternative 0070F17685257646_=" Cc: ogpx-bounces@ietf.org, "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 20:32:07 -0000 This is a multipart message in MIME format. --=_alternative 0070F17685257646_= Content-Type: text/plain; charset="US-ASCII" I want to point out an important related concept for much of this discussion. If one's goal is to *know* that someone actually is following a policy one has, especially a policy with real world implications, the process has to ground out in provable statements. In fact, for cases where the policy covers legal liabilities, it has to ground out in legally meaningful stuff. I studied distributed systems, not law, so don't take any of this as a legal pronouncement, but.. If I'm going to trust a third party Agent Domain to tell me something that has legal consequences, I'm probably going to want that statement tied down with a digital signature or similar proof, that links to a real world document. So.. My personal suspicion is that what we'll see comes much closer to this: "In order to have rights beyond "guest" on this region, you, or your agent domain, on your behalf, needs to have signed the TOS document. I will demand a digitally signed proof of this, as metadata when you request acess to my region." - David ~ Zha Infinity Linden Sent by: ogpx-bounces@ietf.org 10/05/2009 03:39 PM To Magnus Zeisig cc "ogpx@ietf.org" Subject Re: [ogpx] Protocol for permitting policy decisions right. this is similar to what i was talking about in one of the previously mentioned options. i mentioned that the region might need to call back into the agent domain to get more information about a particular agent. to me it looks like you're suggesting a two-message handshake instead of the region turning around and querying the agent domain. lemme draw some diagrams: "name" and "age" are bits of data that, like you might expect, are an account identifier and the account holder's age. "rez cap" is the capability used to establish the agent's presence in that region. "age > X? cap" is a capability granted to the agent domain that's supposed to be used by the agent domain only if the agent domain agrees that the account holder is older than X. option 1: information push AD ------------ ( name, age ) ---------> RD AD <------------- (rez cap) ------------ RD option 2: RD queries the AD AD --------------- (name) -------------> RD AD <----- (is name older than X?) ------ RD AD -------------- (yes/no) ------------> RD AD <------------ (rez cap) ------------- RD option 3: multi-message handshake AD --------------- (name) -------------> RD AD <-------- (X, age > X? cap) --------- RD AD ------------------------------------> RD (age > X? cap) AD <------------ (rez cap) ------------- RD option 3 here is my attempt to model what magnus is talking about, but with a RESTful capability system. -cheers -meadhbh On Mon, Oct 5, 2009 at 1:55 AM, Magnus Zeisig wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > If I register with an agent domain, or authentication service, whichever > should be the proper name for it, I will most probably hand them some pieces > of information about myself that I don't want disseminated to anyone. > Therefore, I think the protocol for granting access to regions and other > services should not include such information explicitly, but rather let the > agent domain/authentication service just answer questions from the other > domain/service if the parameters are within acceptable range. > > Instead of the revealing (meta-handshake): > > Agent domain: > request access for > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > age: 18 > gender: male > sexuality: bi > country: pt > languages: pt, es, en, de > length: 1.82 > weight: 122 > color of socks: blue > > Region domain: > access granted for > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > The handshake should instead be: > > Agent domain: > request access for > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > Region domain: > require parameter values > languages: es AND (de OR hb OR ru) > length: [1.21-2.42] > color of socks: pink OR blue OR black > hairdo: shaved OR ponytail > > Agent domain: > required parameter values > languages: yes > length: yes > color of socks: yes > hairdo: n/a > > After which the region domain might decide that the missing hairdo parameter > is not crucial and grant access, or refuse access because of it: > > Region domain: > access denied for > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > This has the benefit of permitting service providers to require what user > parameters they think are important, be it age or color of socks, but the > disadvantage of some extra overhead and the risk of balkanization because of > requirements of "odd" parameters only supported by few services. The latter, > however, I believe will become self-eliminating, because such services will > probably not find many users. Either way, I don't think the protocol in > itself should require any particular parameters, like age or color of socks, > just provide the means to communicate any parameters, and perhaps suggest a > list of possible, but not required, parameters and formats for values, like > options, ranges and enumerations. The same kind of handshake could also be > used when requesting access to asset services and the like, even if > parameters like "object types" and "ip agreements" may be more important > than "color of socks" there. > > Best regards, > > Magnus > > > -----BEGIN PGP SIGNATURE----- > Version: 9.8.3 (Build 4028) > Charset: utf-8 > > wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g > rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc > YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu > ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr > vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb > 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg== > =H2Fj > -----END PGP SIGNATURE----- > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 0070F17685257646_= Content-Type: text/html; charset="US-ASCII"
I want to point out an important related concept for much of this discussion.

If one's goal is to *know* that someone actually is following a policy one has, especially a policy with real world implications, the process has to ground out in provable statements.
In fact, for cases where the policy covers legal liabilities, it has to ground out in legally meaningful stuff. I studied distributed systems, not law, so don't take any of this as a legal pronouncement,
but.. If I'm going to trust a third party Agent Domain to tell me something that has legal consequences, I'm probably going to want that statement tied down with a digital signature or similar
proof, that links to a real world document.

So.. My personal suspicion is that what we'll see comes much closer to this:

"In order to have rights beyond "guest" on this region, you, or your agent domain, on your behalf, needs to have signed the TOS document. I will demand a digitally signed proof of this, as metadata when you
request acess to my region."

- David
~ Zha





Infinity Linden <infinity@lindenlab.com>
Sent by: ogpx-bounces@ietf.org

10/05/2009 03:39 PM

To
Magnus Zeisig <magnus.zeisig@iis.se>
cc
"ogpx@ietf.org" <ogpx@ietf.org>
Subject
Re: [ogpx] Protocol for permitting policy decisions





right. this is similar to what i was talking about in one of the
previously mentioned options. i mentioned that the region might need
to call back into the agent domain to get more information about a
particular agent. to me it looks like you're suggesting a two-message
handshake instead of the region turning around and querying the agent
domain.

lemme draw some diagrams:

"name" and "age" are bits of data that, like you might expect, are an
account identifier and the account holder's age. "rez cap" is the
capability used to establish the agent's presence in that region. "age
> X? cap" is a capability granted to the agent domain that's supposed
to be used by the agent domain only if the agent domain agrees that
the account holder is older than X.

option 1: information push

AD ------------ ( name, age ) ---------> RD
AD <------------- (rez cap) ------------ RD

option 2: RD queries the AD

AD --------------- (name) -------------> RD
AD <----- (is name older than X?) ------ RD
AD -------------- (yes/no) ------------> RD
AD <------------ (rez cap) ------------- RD

option 3: multi-message handshake

AD --------------- (name) -------------> RD
AD <-------- (X, age > X? cap) --------- RD

AD ------------------------------------> RD (age > X? cap)
AD <------------ (rez cap) ------------- RD


option 3 here is my attempt to model what magnus is talking about, but
with a RESTful capability system.

-cheers
-meadhbh

On Mon, Oct 5, 2009 at 1:55 AM, Magnus Zeisig <magnus.zeisig@iis.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> If I register with an agent domain, or authentication service, whichever
> should be the proper name for it, I will most probably hand them some pieces
> of information about myself that I don't want disseminated to anyone.
> Therefore, I think the protocol for granting access to regions and other
> services should not include such information explicitly, but rather let the
> agent domain/authentication service just answer questions from the other
> domain/service if the parameters are within acceptable range.
>
> Instead of the revealing (meta-handshake):
>
> Agent domain:
> request access for
> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org
> age: 18
> gender: male
> sexuality: bi
> country: pt
> languages: pt, es, en, de
> length: 1.82
> weight: 122
> color of socks: blue
>
> Region domain:
> access granted for
> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org
>
> The handshake should instead be:
>
> Agent domain:
> request access for
> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org
>
> Region domain:
> require parameter values
> languages: es AND (de OR hb OR ru)
> length: [1.21-2.42]
> color of socks: pink OR blue OR black
> hairdo: shaved OR ponytail
>
> Agent domain:
> required parameter values
> languages: yes
> length: yes
> color of socks: yes
> hairdo: n/a
>
> After which the region domain might decide that the missing hairdo parameter
> is not crucial and grant access, or refuse access because of it:
>
> Region domain:
> access denied for
> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org
>
> This has the benefit of permitting service providers to require what user
> parameters they think are important, be it age or color of socks, but the
> disadvantage of some extra overhead and the risk of balkanization because of
> requirements of "odd" parameters only supported by few services. The latter,
> however, I believe will become self-eliminating, because such services will
> probably not find many users. Either way, I don't think the protocol in
> itself should require any particular parameters, like age or color of socks,
> just provide the means to communicate any parameters, and perhaps suggest a
> list of possible, but not required, parameters and formats for values, like
> options, ranges and enumerations. The same kind of handshake could also be
> used when requesting access to asset services and the like, even if
> parameters like "object types" and "ip agreements" may be more important
> than "color of socks" there.
>
> Best regards,
>
> Magnus
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: 9.8.3 (Build 4028)
> Charset: utf-8
>
> wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g
> rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc
> YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu
> ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr
> vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb
> 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg==
> =H2Fj
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 0070F17685257646_=-- From carlo@alinoe.com Mon Oct 5 15:29:57 2009 Return-Path: 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 C54CF28C24C for ; Mon, 5 Oct 2009 15:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 mokiedV4nzsC for ; Mon, 5 Oct 2009 15:29:57 -0700 (PDT) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id 8D2413A686E for ; Mon, 5 Oct 2009 15:29:56 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep15-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091005223130.XXHB17988.viefep15-int.chello.at@edge02.upc.biz>; Tue, 6 Oct 2009 00:31:30 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upc.biz with edge id pAXS1c06p0FlQed02AXTMl; Tue, 06 Oct 2009 00:31:30 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Muw6k-0000AS-3S; Tue, 06 Oct 2009 00:32:42 +0200 Date: Tue, 6 Oct 2009 00:32:42 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20091005223242.GA32650@alinoe.com> References: <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <20091002012335.GB690@alinoe.com> <20091005182505.GA20468@alinoe.com> <3a880e2c0910051131k2d81531au275782c6cb3c3655@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3a880e2c0910051131k2d81531au275782c6cb3c3655@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 22:29:57 -0000 *************************************************************** * Hence, it is possible to apply the simplication:            * *- AD policies ONLY come into play at the moment of teleport  * *  (allow or not).                                            * *- Once arrived in a new region, the policies of the AD can   * *  be 'forgotten' and only the policies of the RD apply.      * *  If the AD doesn't want that, they shouldn't allow the TP.  * *************************************************************** The rationale behind this is that this is the only reasonable way to achieve that for any two people in a given region, the same rules apply. Hopefully we can reach consensus on that it would be unworkable if one person is allowed to X, while the person next to him/her is not, where X being anything and everything. Example, one person is allowed to use avatar Foo without clothes, then everyone in the region should be allowed to use avatar Foo without clothes (not taking into account local rules set by sim owner or parcel owner). Since two different people can be using two different AD's, no AD can force a limitation upon a user (beyond what the region already demands) because another AD might not enforce that leading to different rules for different people in the same region. It's really quite logical, almost trivial, but seeing previous confusion about things on this list it would be nice to see people agree. Thanks! -- Carlo Wood From infinity@lindenlab.com Mon Oct 5 15:59:30 2009 Return-Path: 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 ED1E03A683D for ; Mon, 5 Oct 2009 15:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 kJVGXC9kfU9E for ; Mon, 5 Oct 2009 15:59:30 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 3A85A3A679C for ; Mon, 5 Oct 2009 15:59:30 -0700 (PDT) Received: by pzk35 with SMTP id 35so1540486pzk.29 for ; Mon, 05 Oct 2009 16:01:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.5.35 with SMTP id 35mr47871wfe.69.1254783663707; Mon, 05 Oct 2009 16:01:03 -0700 (PDT) In-Reply-To: <20091005223242.GA32650@alinoe.com> References: <20090914084420.GA25580@alinoe.com> <20091002012335.GB690@alinoe.com> <20091005182505.GA20468@alinoe.com> <3a880e2c0910051131k2d81531au275782c6cb3c3655@mail.gmail.com> <20091005223242.GA32650@alinoe.com> Date: Mon, 5 Oct 2009 16:01:03 -0700 Message-ID: <3a880e2c0910051601q7761b380w5985442899ec45aa@mail.gmail.com> From: Infinity Linden To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 22:59:31 -0000 we will not be able to reach consensus with a protocol that supports "destination determines policy" exclusively. if we want to add that as an option, i'm down with that, but i cannot imagine my employer signing onto a proposal that would disallow the agent domain from enforcing it's policies as well as the region domain's policies. but the great thing about policies is they're outside of the protocol definition. so... i'm hip to adding the "tourist model" as a supported use case if this will allow us to get on with more important matters. i would suggest we not add the "allowed to wear clothes" bits to the protocol, but leave this as a POLICY for the deployers. personally, i have NO PROBLEM with an agent domain and a region domain making asymmetric agreements. that is, if region domain X wants to make policy A with agent domain Y, but wants to make a different policy (call it policy B) with agent domain Z, well good on 'em. i guess i'm too much of libertarian at heart to have a protocol demand that each participant or pair of participants use exactly the same protocol. -cheers -meadhbh On Mon, Oct 5, 2009 at 3:32 PM, Carlo Wood wrote: > *************************************************************** > * Hence, it is possible to apply the simplication: =A0 =A0 =A0 =A0 =A0 = =A0* > *- AD policies ONLY come into play at the moment of teleport =A0* > * =A0(allow or not). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* > *- Once arrived in a new region, the policies of the AD can =A0 * > * =A0be 'forgotten' and only the policies of the RD apply. =A0 =A0 =A0* > * =A0If the AD doesn't want that, they shouldn't allow the TP. =A0* > *************************************************************** > > The rationale behind this is that this is the only reasonable > way to achieve that for any two people in a given region, the > same rules apply. > > Hopefully we can reach consensus on that it would be unworkable > if one person is allowed to X, while the person next to him/her > is not, where X being anything and everything. > > Example, one person is allowed to use avatar Foo without clothes, > then everyone in the region should be allowed to use avatar Foo > without clothes (not taking into account local rules set by > sim owner or parcel owner). > > Since two different people can be using two different AD's, > no AD can force a limitation upon a user (beyond what the > region already demands) because another AD might not enforce > that leading to different rules for different people in the > same region. > > It's really quite logical, almost trivial, but seeing previous > confusion about things on this list it would be nice to see > people agree. Thanks! > > -- > Carlo Wood > From infinity@lindenlab.com Mon Oct 5 16:02:09 2009 Return-Path: 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 3206428C1BE for ; Mon, 5 Oct 2009 16:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 oTqqc474Upaj for ; Mon, 5 Oct 2009 16:02:08 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 2E0A128C1B1 for ; Mon, 5 Oct 2009 16:02:08 -0700 (PDT) Received: by pzk35 with SMTP id 35so1542221pzk.29 for ; Mon, 05 Oct 2009 16:03:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.247.23 with SMTP id u23mr47236wfh.240.1254783821656; Mon, 05 Oct 2009 16:03:41 -0700 (PDT) In-Reply-To: <3a880e2c0910051601q7761b380w5985442899ec45aa@mail.gmail.com> References: <20090914084420.GA25580@alinoe.com> <20091002012335.GB690@alinoe.com> <20091005182505.GA20468@alinoe.com> <3a880e2c0910051131k2d81531au275782c6cb3c3655@mail.gmail.com> <20091005223242.GA32650@alinoe.com> <3a880e2c0910051601q7761b380w5985442899ec45aa@mail.gmail.com> Date: Mon, 5 Oct 2009 16:03:41 -0700 Message-ID: <3a880e2c0910051603j4e6dc8c3p542a1fe8cf4483ae@mail.gmail.com> From: Infinity Linden To: Carlo Wood , ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 23:02:09 -0000 ack. and when i say "i guess i'm too much of libertarian at heart to have a protocol demand that each participant or pair of participants use exactly the same PROTOCOL," i obviously mean "i guess i'm too much of libertarian at heart to have a protocol demand that each participant or pair of participants use exactly the same POLICY." On Mon, Oct 5, 2009 at 4:01 PM, Infinity Linden wr= ote: > we will not be able to reach consensus with a protocol that supports > "destination determines policy" exclusively. > > if we want to add that as an option, i'm down with that, but i cannot > imagine my employer signing onto a proposal that would disallow the > agent domain from enforcing it's policies as well as the region > domain's policies. > > but the great thing about policies is they're outside of the protocol > definition. so... i'm hip to adding the "tourist model" as a supported > use case if this will allow us to get on with more important matters. > > i would suggest we not add the "allowed to wear clothes" bits to the > protocol, but leave this as a POLICY for the deployers. personally, i > have NO PROBLEM with an agent domain and a region domain making > asymmetric agreements. that is, if region domain X wants to make > policy A with agent domain Y, but wants to make a different policy > (call it policy B) with agent domain Z, well good on 'em. i guess i'm > too much of libertarian at heart to have a protocol demand that each > participant or pair of participants use exactly the same protocol. > > -cheers > -meadhbh > > On Mon, Oct 5, 2009 at 3:32 PM, Carlo Wood wrote: >> *************************************************************** >> * Hence, it is possible to apply the simplication: =A0 =A0 =A0 =A0 =A0 = =A0* >> *- AD policies ONLY come into play at the moment of teleport =A0* >> * =A0(allow or not). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* >> *- Once arrived in a new region, the policies of the AD can =A0 * >> * =A0be 'forgotten' and only the policies of the RD apply. =A0 =A0 =A0* >> * =A0If the AD doesn't want that, they shouldn't allow the TP. =A0* >> *************************************************************** >> >> The rationale behind this is that this is the only reasonable >> way to achieve that for any two people in a given region, the >> same rules apply. >> >> Hopefully we can reach consensus on that it would be unworkable >> if one person is allowed to X, while the person next to him/her >> is not, where X being anything and everything. >> >> Example, one person is allowed to use avatar Foo without clothes, >> then everyone in the region should be allowed to use avatar Foo >> without clothes (not taking into account local rules set by >> sim owner or parcel owner). >> >> Since two different people can be using two different AD's, >> no AD can force a limitation upon a user (beyond what the >> region already demands) because another AD might not enforce >> that leading to different rules for different people in the >> same region. >> >> It's really quite logical, almost trivial, but seeing previous >> confusion about things on this list it would be nice to see >> people agree. Thanks! >> >> -- >> Carlo Wood >> > From morgaine.dinova@googlemail.com Mon Oct 5 16:26:07 2009 Return-Path: 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 71C813A6882 for ; Mon, 5 Oct 2009 16:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.548 X-Spam-Level: X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 Z7LX-aOjQ0UJ for ; Mon, 5 Oct 2009 16:26:06 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id C2D123A67B3 for ; Mon, 5 Oct 2009 16:26:05 -0700 (PDT) Received: by ewy10 with SMTP id 10so3621816ewy.9 for ; Mon, 05 Oct 2009 16:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=FnJuzEYZJMG24sy5fDSZX9cpspeCbAv5UUiZ/IZ2POE=; b=hwN3KzOC9XZDaoDQWIl/mmza+0JSwMhl7rDt9rGQPMpNkzOUg2wnIZFWi7CUMr0ziG H0CbOQS8V08xn68ouNKpIE9TQykKjXNzFoonU7J1cqXi/vAiYKK+v1rroE5F6b3tdGqN 5F4VBCJmfL6ucOHVcNhUjPQ35VmeO9r6GDJ/U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=RRhdcgXOIf4v9RnDVpF1ENPZZeLRsnpy3Js6gT9JmCNoRh8TU1nIROSIIJoO70ovVc dGrO+pEbVxaOpsrHXNC0uGYCmu8On6kthy2DXU4XVUO5dX/e0HlMCWdJxMwuCHmTKyNz Pn0OUPoqp0QgoHwAMRDcVHWWFNEJM1mvI5jMU= MIME-Version: 1.0 Received: by 10.211.155.11 with SMTP id h11mr3994847ebo.40.1254785258962; Mon, 05 Oct 2009 16:27:38 -0700 (PDT) In-Reply-To: <3a880e2c0910051601q7761b380w5985442899ec45aa@mail.gmail.com> References: <20090914084420.GA25580@alinoe.com> <20091002012335.GB690@alinoe.com> <20091005182505.GA20468@alinoe.com> <3a880e2c0910051131k2d81531au275782c6cb3c3655@mail.gmail.com> <20091005223242.GA32650@alinoe.com> <3a880e2c0910051601q7761b380w5985442899ec45aa@mail.gmail.com> Date: Tue, 6 Oct 2009 00:27:38 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00504502ca5aa13efd0475387571 Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 23:26:07 -0000 --00504502ca5aa13efd0475387571 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 6, 2009 at 12:01 AM, Infinity Linden wrote: we will not be able to reach consensus with a protocol that supports > "destination determines policy" exclusively. That has already been addressed in numerous places. DDP does not imply that *only* "destination determines policy" exclusively in the way you suggest at all. You may have missed this post the first time around, but it was written specifically to help you understand DDP --- http://www.ietf.org/mail-archive/web/ogpx/current/msg00450.html . You may also wish to examine Joshua's post here --- http://www.ietf.org/mail-archive/web/ogpx/current/msg00447.html , in which we were discussing the implications of tourism enabled by DDP on the services provided by ADs and RDs. Good progress was made by understanding this basic principle for tourists interacting in a non-local RD. Morgaine. =================================== On Tue, Oct 6, 2009 at 12:01 AM, Infinity Linden wrote: > we will not be able to reach consensus with a protocol that supports > "destination determines policy" exclusively. > > if we want to add that as an option, i'm down with that, but i cannot > imagine my employer signing onto a proposal that would disallow the > agent domain from enforcing it's policies as well as the region > domain's policies. > > but the great thing about policies is they're outside of the protocol > definition. so... i'm hip to adding the "tourist model" as a supported > use case if this will allow us to get on with more important matters. > > i would suggest we not add the "allowed to wear clothes" bits to the > protocol, but leave this as a POLICY for the deployers. personally, i > have NO PROBLEM with an agent domain and a region domain making > asymmetric agreements. that is, if region domain X wants to make > policy A with agent domain Y, but wants to make a different policy > (call it policy B) with agent domain Z, well good on 'em. i guess i'm > too much of libertarian at heart to have a protocol demand that each > participant or pair of participants use exactly the same protocol. > > -cheers > -meadhbh > > On Mon, Oct 5, 2009 at 3:32 PM, Carlo Wood wrote: > > *************************************************************** > > * Hence, it is possible to apply the simplication: * > > *- AD policies ONLY come into play at the moment of teleport * > > * (allow or not). * > > *- Once arrived in a new region, the policies of the AD can * > > * be 'forgotten' and only the policies of the RD apply. * > > * If the AD doesn't want that, they shouldn't allow the TP. * > > *************************************************************** > > > > The rationale behind this is that this is the only reasonable > > way to achieve that for any two people in a given region, the > > same rules apply. > > > > Hopefully we can reach consensus on that it would be unworkable > > if one person is allowed to X, while the person next to him/her > > is not, where X being anything and everything. > > > > Example, one person is allowed to use avatar Foo without clothes, > > then everyone in the region should be allowed to use avatar Foo > > without clothes (not taking into account local rules set by > > sim owner or parcel owner). > > > > Since two different people can be using two different AD's, > > no AD can force a limitation upon a user (beyond what the > > region already demands) because another AD might not enforce > > that leading to different rules for different people in the > > same region. > > > > It's really quite logical, almost trivial, but seeing previous > > confusion about things on this list it would be nice to see > > people agree. Thanks! > > > > -- > > Carlo Wood > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --00504502ca5aa13efd0475387571 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 6, 2009 at 12:01 AM, Infinity Linden <infinity@lindenlab.com>= wrote:

we will not be able to reach consensus with a protocol that supports "= destination determines policy" exclusively.

That has a= lready been addressed in numerous places.=A0 DDP does not imply that onl= y "destination determines policy" exclusively in the way you = suggest at all.

You may have missed this post the first time around, but it was written= specifically to help you understand DDP ---=A0 http://www.ietf.org/mail-a= rchive/web/ogpx/current/msg00450.html=A0 .

You may also wish to examine Joshua's post here ---=A0 http://www.= ietf.org/mail-archive/web/ogpx/current/msg00447.html=A0 , in which we w= ere discussing the implications of tourism enabled by DDP on the services p= rovided by ADs and RDs.=A0 Good progress was made by understanding this bas= ic principle for tourists interacting in a non-local RD.


Morgaine.







=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

On Tue, Oct 6, 2009 at 12:01 AM, I= nfinity Linden <infinity@lindenlab.com> wrote:
we will not be ab= le to reach consensus with a protocol that supports
"destination determines policy" exclusively.

if we want to add that as an option, i'm down with that, but i cannot imagine my employer signing onto a proposal that would disallow the
agent domain from enforcing it's policies as well as the region
domain's policies.

but the great thing about policies is they're outside of the protocol definition. so... i'm hip to adding the "tourist model" as a = supported
use case if this will allow us to get on with more important matters.

i would suggest we not add the "allowed to wear clothes" bits to = the
protocol, but leave this as a POLICY for the deployers. personally, i
have NO PROBLEM with an agent domain and a region domain making
asymmetric agreements. that is, if region domain X wants to make
policy A with agent domain Y, but wants to make a different policy
(call it policy B) with agent domain Z, well good on 'em. i guess i'= ;m
too much of libertarian at heart to have a protocol demand that each
participant or pair of participants use exactly the same protocol.

-cheers
-meadhbh

On Mon, Oct 5, 2009 at 3:32 PM, Carlo Wood <carlo@alinoe.com> wrote:
> ***************************************************************
> * Hence, it is possible to apply the simplication: =A0 =A0 =A0 =A0 =A0= =A0*
> *- AD policies ONLY come into play at the moment of teleport =A0*
> * =A0(allow or not). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*
> *- Once arrived in a new region, the policies of the AD can =A0 *
> * =A0be 'forgotten' and only the policies of the RD apply. =A0= =A0 =A0*
> * =A0If the AD doesn't want that, they shouldn't allow the TP.= =A0*
> ***************************************************************
>
> The rationale behind this is that this is the only reasonable
> way to achieve that for any two people in a given region, the
> same rules apply.
>
> Hopefully we can reach consensus on that it would be unworkable
> if one person is allowed to X, while the person next to him/her
> is not, where X being anything and everything.
>
> Example, one person is allowed to use avatar Foo without clothes,
> then everyone in the region should be allowed to use avatar Foo
> without clothes (not taking into account local rules set by
> sim owner or parcel owner).
>
> Since two different people can be using two different AD's,
> no AD can force a limitation upon a user (beyond what the
> region already demands) because another AD might not enforce
> that leading to different rules for different people in the
> same region.
>
> It's really quite logical, almost trivial, but seeing previous
> confusion about things on this list it would be nice to see
> people agree. Thanks!
>
> --
> Carlo Wood <carlo@alinoe.com>
>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--00504502ca5aa13efd0475387571-- From infinity@lindenlab.com Mon Oct 5 16:34:02 2009 Return-Path: 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 E60753A67D3; Mon, 5 Oct 2009 16:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 1As0EQujaCE6; Mon, 5 Oct 2009 16:34:00 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 87C253A67B4; Mon, 5 Oct 2009 16:34:00 -0700 (PDT) Received: by pzk35 with SMTP id 35so1564549pzk.29 for ; Mon, 05 Oct 2009 16:35:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.9.32 with SMTP id 32mr49446wfi.112.1254785736679; Mon, 05 Oct 2009 16:35:36 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> <4646639E08F58B42836FAC24C94624DD771A156244@GVW0433EXB.americas.hpqcorp.net> Date: Mon, 5 Oct 2009 16:35:36 -0700 Message-ID: <3a880e2c0910051635g10ee6bbcvdd74a050cced9583@mail.gmail.com> From: Infinity Linden To: David W Levine Content-Type: multipart/alternative; boundary=00504502b8551aa16204753892d1 Cc: Meadhbh Siobhan , "ogpx@ietf.org" , ogpx-bounces@ietf.org, Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 23:34:03 -0000 --00504502b8551aa16204753892d1 Content-Type: text/plain; charset=ISO-8859-1 yes. we can have per-service policies. that's no big deal. but the software implementing the service doesn't define policy, the people operating the service do. the people (i.e. - the authority) is represented in the specification as the "domain." so when we say "the domain sets policy" we mean that when we have a bunch of machines, all of which are potentially running different services, we mean that the owner of the machine running the service sets the policy, not the developer(s) of the software or the developer(s) of the protocol. that policy may be to defer policy setting to a subordinate authority. for example... on the second life grid, linden is likely to adopt a policy that regions are squares 256m on a side, and that certain regions may only be entered by administrators. on regions open to the general public, we may (and do) subdivide land into parcels and allow our residents to limit who is allowed to enter their parcels. (so... on mainland regions, we devolve authority for setting the policy of who enters each region to the region owners.) we also have a policy that even though you're not allowed to enter a parcel, you can generally see what's in it. a different developer may choose a different set of policies. that is, they may decide not to subdivide regions into parcels, and may refuse to give non-authorized clients information about items in virtual areas they don't have access to. another example might be a "private label agent domain." this would be an operator or authority (or domain) that sets policies like... "we do not support MD5 hash for password verification." but their business might be to operate an agent domain on behalf of other organizations. one of these clients may decide they have a policy that says "we will only authenticate requests from IP addresses we believe are in a given locality." so in this case, the private label agent domain operator devolves policy setting for geo-location based authentication, but retains the right to refuse to use the older MD5 based password authentication." so... throughout the documentation... we use the term "domain" to mean "a collection of systems and networks over which control is exercised." the "authority" is the entity (individual or group) that exercises the control. the manifestation of the authority's control is (among other things) the ability to set "policy." authority may be "devolved" to "subordinate authorities." superior authority may decide which policy clauses to devolve and which to retain. specific service interfaces deployed by a domain may implement different policies. ultimately it should not be the work of this group to determine policies for domains, or even to provide an exhaustive list of policies. specific clauses in a policy most likely arise from a specific implementation of the protocol. it should not be the work of this group to bless any one implementation and it's determination of how to represent policy. (i have personally said many times that the effort of this group should not be to bless Second Life(tm)'s legacy protocol and it's related policies. but this does not mean that we should bless OpenSimulator.) can we agree to this wording? can we move on? On Mon, Oct 5, 2009 at 1:20 PM, David W Levine wrote: > > So.. to sound like a broken record The policy decisions end up being > applied to services. To an extent, this sort of implies that the enforcement > point *has* to be the service, not the "domain" but.. one important point > right behind this. > There is nothing which prevents a region from letting a front end service > handle access to it. In particular, one very sane model for handling the cap > grant to a large cluster of regions is to deploy that on a front end box, > which handles > all of that separate from the region process, and hands out caps to the > actual region. > > - David > > > > *"Dickson, Mike (ISS Software)" * > Sent by: ogpx-bounces@ietf.org > > 10/05/2009 01:12 PM > To > Meadhbh Siobhan cc > "ogpx@ietf.org" , Magnus Zeisig > Subject > Re: [ogpx] Protocol for permitting policy decisions > > > > > I think I buy it in the case you put forward. That is if you simplify the > problem so that AD itself specifies the constraint (the AD in your example > only carries accounts from the sea scouts). But what if I'm running > multiple regions with different policies all served by a single AD? Are you > suggesting that each region needs to handle the policy for its own? > > Picking on what is probably a corner case but one that's been raised... If > I'm running multiple regions, some of which are "Adult" and some are not, > does treating constraints as outside the protocol require each RD to do the > age verification (I could make a case the answer is yes since "Adultness" > might differ depending on who/where I am). And if so how do they do that > without getting "sensitive information" that is probably best owned by the > AD. Is it reasonable perhaps for a RD to delegate that to the AD and > provide a mechanism to negotiate the details on connect so I can centralize > such decisions in a single place? > > Mike > > -----Original Message----- > From: Meadhbh Siobhan [mailto:meadhbh.siobhan@gmail.com] > > Sent: Monday, October 05, 2009 11:33 AM > To: Dickson, Mike (ISS Software) > Cc: Magnus Zeisig; ogpx@ietf.org > Subject: Re: [ogpx] Protocol for permitting policy decisions > > again, this is a matter of policy, not a matter of protocol. > > let me give you a counter example. some trusted organization, maybe > the new zealand sea scouts, decides it wants a virtual social space to > teach seamanship, knot tying and whatever else scouts are taught these > days. > > the sea scouts organization is not really known for it's ability to > maintain a reasonably large networking and system infrastructure, so > instead of building the service themselves, they outsource. > > at this point, there are a couple of options open to them. they can > give their entire user database to a third party and hope for the > best. or they can give portions of their user database (name, email > address, adult / minor boolean.) or they could put a VWRAP > authentication service that they maintain in front of their user > database. each are valid options. > > one would hope that in the first two options, they worked out with the > third party some pretty hard-core data retention and privacy policies. > > so what if they did the third option? what would the protocol have to > do? the sea scout's agent domain would only allow agents to enter a > private virtual world. the sea scouts would negotiate with their > region domain provider to ensure that adult content was not allowed in > the regions accessible by the sea scout agent domain. moreover, the > region domain provider could ensure that ONLY agents with accounts > from the sea scouts would get access to the sea scouts virtual spaces. > > so the answer to the question of "what does the protocol have to do?" > is that it only has to convey information about the identity of the > agent domain to the region provider. it also has to have a mechanism > for the agent domain to identify the region. > > but the protocol itself does not impose restrictions as to the > identity of either party. that is a policy issue. > > in other words, if you don't want to use an agent domain / region > domain pair that provides information about you to a trusted third > party, don't give that information the the agent domain in the first > place. or double check that the agent domain's privacy policy requires > third parties to which it reveals information to treat that > information with due care. > > that being said, some people's paranoia level is higher than others, > so maybe we could have multiple techniques defined for sharing > sensitive information, none of which are mandatory. > > -cheers > -meadhbh > > On Mon, Oct 5, 2009 at 7:48 AM, Dickson, Mike (ISS Software) > wrote: > > I think Magnus' message is a good synopsis of the requirements, IMO. I > see > > a need to negotiate *both* capabilities and constraints in the protocol > > where both should be ideally attributes in an extensible list (that is > the > > list isn't hard coded in the protocol definition). So, IMO, > authentication > > isn't enough. Beyond authenticating there's an exchange around caps and > > constraints that needs to take place. I'd use that mechanism to handle > > "Adult only" regions, membership in a group where the group is defined > > outside the scope of the protocol, etc. > > > > > > > > Mike > > > > > > > > From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] > On Behalf Of > > Magnus Zeisig > > Sent: Monday, October 05, 2009 3:55 AM > > To: ogpx@ietf.org > > Subject: [ogpx] Protocol for permitting policy decisions > > > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA256 > > > > > > > > If I register with an agent domain, or authentication service, whichever > > should be the proper name for it, I will most probably hand them some > pieces > > of information about myself that I don't want disseminated to anyone. > > Therefore, I think the protocol for granting access to regions and other > > services should not include such information explicitly, but rather let > the > > agent domain/authentication service just answer questions from the other > > domain/service if the parameters are within acceptable range. > > > > > > > > Instead of the revealing (meta-handshake): > > > > > > > > Agent domain: > > > > request access for > > > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > age: 18 > > > > gender: male > > > > sexuality: bi > > > > country: pt > > > > languages: pt, es, en, de > > > > length: 1.82 > > > > weight: 122 > > > > color of socks: blue > > > > > > > > Region domain: > > > > access granted for > > > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > > > > > The handshake should instead be: > > > > > > > > Agent domain: > > > > request access for > > > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > > > > > Region domain: > > > > require parameter values > > > > languages: es AND (de OR hb OR ru) > > > > length: [1.21-2.42] > > > > color of socks: pink OR blue OR black > > > > hairdo: shaved OR ponytail > > > > > > > > Agent domain: > > > > required parameter values > > > > languages: yes > > > > length: yes > > > > color of socks: yes > > > > hairdo: n/a > > > > > > > > After which the region domain might decide that the missing hairdo > parameter > > is not crucial and grant access, or refuse access because of it: > > > > > > > > Region domain: > > > > access denied for > > > > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > > > > > > > This has the benefit of permitting service providers to require what user > > parameters they think are important, be it age or color of socks, but the > > disadvantage of some extra overhead and the risk of balkanization because > of > > requirements of "odd" parameters only supported by few services. The > latter, > > however, I believe will become self-eliminating, because such services > will > > probably not find many users. Either way, I don't think the protocol in > > itself should require any particular parameters, like age or color of > socks, > > just provide the means to communicate any parameters, and perhaps suggest > a > > list of possible, but not required, parameters and formats for values, > like > > options, ranges and enumerations. The same kind of handshake could also > be > > used when requesting access to asset services and the like, even if > > parameters like "object types" and "ip agreements" may be more important > > than "color of socks" there. > > > > > > > > Best regards, > > > > > > > > Magnus > > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > > Version: 9.8.3 (Build 4028) > > > > Charset: utf-8 > > > > > > > > wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g > > > > rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc > > > > YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu > > > > ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr > > > > vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb > > > > 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg== > > > > =H2Fj > > > > -----END PGP SIGNATURE----- > > > > > > > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00504502b8551aa16204753892d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yes. we can have per-service policies. that's no big deal. but the soft= ware implementing the service doesn't define policy, the people operati= ng the service do. the people (i.e. - the authority) is represented in the = specification as the "domain." so when we say "the domain se= ts policy" we mean that when we have a bunch of machines, all of which= are potentially running different services, we mean that the owner of the = machine running the service sets the policy, not the developer(s) of the so= ftware or the developer(s) of the protocol. that policy may be to defer pol= icy setting to a subordinate authority.

for example... on the second life grid, linden is likely to = adopt a policy that regions are squares 256m on a side, and that certain re= gions may only be entered by administrators. on regions open to the general= public, we may (and do) subdivide land into parcels and allow our resident= s to limit who is allowed to enter their parcels. (so... on mainland region= s, we devolve authority for setting the policy of who enters each region to= the region owners.) we also have a policy that even though you're not = allowed to enter a parcel, you can generally see what's in it.

a different developer may choose a different set of pol= icies. that is, they may decide not to subdivide regions into parcels, and = may refuse to give non-authorized clients information about items in virtua= l areas they don't have access to.

another example might be a "private label agent do= main." this would be an operator or authority (or domain) that sets po= licies like... "we do not support MD5 hash for password verification.&= quot; but their business might be to operate an agent domain on behalf of o= ther organizations. one of these clients may decide they have a policy that= says "we will only authenticate requests from IP addresses we believe= are in a given locality." so in this case, the private label agent do= main operator devolves policy setting for geo-location based authentication= , but retains the right to refuse to use the older MD5 based password authe= ntication."

so... throughout the documentation... we use the term &= quot;domain" to mean "a=A0collection of systems and netw= orks over which control is exercised." the "authority" is th= e entity (individual or group) that exercises the control. the manifestatio= n of the authority's control is (among other things) the ability to set= "policy." authority may be "devolved" to "subordi= nate authorities." superior authority may decide which policy clauses = to devolve and which to retain. specific service interfaces deployed by a d= omain may implement different policies.

ultimately it should not be the= work of this group to determine policies for domains, or even to provide a= n exhaustive list of policies. specific clauses in a policy most likely ari= se from a specific implementation of the protocol. it should not be the wor= k of this group to bless any one implementation and it's determination = of how to represent policy. (i have personally said many times that the eff= ort of this group should not be to bless Second Life(tm)'s legacy proto= col and it's related policies. but this does not mean that we should bl= ess OpenSimulator.)

can we agree to this wording? c= an we move on?


On Mon, Oct 5, 2009 at 1:20 PM, David W L= evine <dwl@us.ibm.co= m> wrote:

So.. to sound like a broken record= The policy decisions end up being applied to services. To an extent, this sort of implies that the enforcement point *has* to be the service, not the "domain" but.. one important point right behind this.
There is nothing which prevents a = region from letting a front end service handle access to it. In particular, one very sane model for handling the cap grant to a large cluster of regions is to deploy that on a front end box, which handles
all of that separate from the regi= on process, and hands out caps to the actual region.

- David



"Dickson, Mike (ISS Software)" <mike.dickson@hp.com>
Sent by: ogpx-bounces@ietf.org

10/05/2009 01:12 PM

To
Meadhbh Siobhan <meadhbh.siobhan@gma= il.com>
cc
"ogpx@ietf.org" <ogpx@ietf.org>, Magnus Zeisig <magnus.zeisig@iis.se>
Subject
Re: [ogpx] Protocol for permi= tting policy decisions





I think I buy it in the case you put forward. =A0T= hat is if you simplify the problem so that AD itself specifies the constraint (the AD in your example only carries accounts from the sea scouts). =A0But what if I'm running multiple regions with different policies all served by a single AD? Are you suggesting that each region needs to handle the policy for its own?

Picking on what is probably a corner case but one that's been raised... =A0If I'm running multiple regions, some of which are "Adult" and some are not, does treating constraints as outside the protocol require each RD to do the age verification (I could make a case the answer is yes since "Adultness" might differ depending on who/where I am). =A0And if so how do they do that without getting "sensitive informatio= n" that is probably best owned by the AD. =A0Is it reasonable perhaps for a RD to delegate that to the AD and provide a mechanism to negotiate the details on connect so I can centralize such decisions in a single place?
Mike

-----Original Message-----
From: Meadhbh Siobhan [mailto:meadhbh.siobhan@gmail.co= m]
Sent: Monday, October 05, 2009 11:33 AM
To: Dickson, Mike (ISS Software)
Cc: Magnus Zeisig; ogpx@= ietf.org
Subject: Re: [ogpx] Protocol for permitting policy decisions

again, this is a matter of policy, not a matter of protocol.

let me give you a counter example. some trusted organization, maybe
the new zealand sea scouts, decides it wants a virtual social space to
teach seamanship, knot tying and whatever else scouts are taught these
days.

the sea scouts organization is not really known for it's ability to
maintain a reasonably large networking and system infrastructure, so
instead of building the service themselves, they outsource.

at this point, there are a couple of options open to them. they can
give their entire user database to a third party and hope for the
best. or they can give portions of their user database (name, email
address, adult / minor boolean.) or they could put a VWRAP
authentication service that they maintain in front of their user
database. each are valid options.

one would hope that in the first two options, they worked out with the
third party some pretty hard-core data retention and privacy policies.

so what if they did the third option? what would the protocol have to
do? the sea scout's agent domain would only allow agents to enter a
private virtual world. the sea scouts would negotiate with their
region domain provider to ensure that adult content was not allowed in
the regions accessible by the sea scout agent domain. moreover, the
region domain provider could ensure that ONLY agents with accounts
from the sea scouts would get access to the sea scouts virtual spaces.

so the answer to the question of "what does the protocol have to do?&q= uot;
is that it only has to convey information about the identity of the
agent domain to the region provider. it also has to have a mechanism
for the agent domain to identify the region.

but the protocol itself does not impose restrictions as to the
identity of either party. that is a policy issue.

in other words, if you don't want to use an agent domain =A0/ region domain pair that provides information about you to a trusted third
party, don't give that information the the agent domain in the first place. or double check that the agent domain's privacy policy requires<= br> third parties to which it reveals information to =A0treat that
information with due care.

that being said, some people's paranoia level is higher than others, so maybe we could have multiple techniques defined for sharing
sensitive information, none of which are mandatory.

-cheers
-meadhbh

On Mon, Oct 5, 2009 at 7:48 AM, Dickson, Mike (ISS Software)
<mike.dickson@h= p.com> wrote:
> I think Magnus' message is a good synopsis of the requirements, IM= O.=A0 I see
> a need to negotiate *both* capabilities and constraints in the protoco= l
> where both should be ideally attributes in an extensible list (that is the
> list isn't hard coded in the protocol definition).=A0 So, IMO, authentication
> isn't enough.=A0 Beyond authenticating there's an exchange aro= und caps and
> constraints that needs to take place.=A0 I'd use that mechanism to handle
> "Adult only" regions, membership in a group where the group is defined
> outside the scope of the protocol, etc.
>
>
>
> Mike
>
>
>
> From: ogpx-= bounces@ietf.org [mailto:ogpx-bounces@ietf.org<= /tt>] On Behalf Of
> Magnus Zeisig
> Sent: Monday, October 05, 2009 3:55 AM
> To: ogpx@ietf.org
> Subject: [ogpx] Protocol for permitting policy decisions
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Hash: SHA256
>
>
>
> If I register with an agent domain, or authentication service, whichev= er
> should be the proper name for it, I will most probably hand them some pieces
> of information about myself that I don't want disseminated to anyo= ne.
> Therefore, I think the protocol for granting access to regions and other
> services should not include such information explicitly, but rather let the
> agent domain/authentication service just answer questions from the other
> domain/service if the parameters are within acceptable range.
>
>
>
> Instead of the revealing (meta-handshake):
>
>
>
> Agent domain:
>
> request access for
>
> user: Title.FirstName.Initials.LastName.Ext= raSomething@agentdomain.org
>
> age: 18
>
> gender: male
>
> sexuality: bi
>
> country: pt
>
> languages: pt, es, en, de
>
> length: 1.82
>
> weight: 122
>
> color of socks: blue
>
>
>
> Region domain:
>
> access granted for
>
> user: Title.FirstName.Initials.LastName.Ext= raSomething@agentdomain.org
>
>
>
> The handshake should instead be:
>
>
>
> Agent domain:
>
> request access for
>
> user: Title.FirstName.Initials.LastName.Ext= raSomething@agentdomain.org
>
>
>
> Region domain:
>
> require parameter values
>
> languages: es AND (de OR hb OR ru)
>
> length: [1.21-2.42]
>
> color of socks: pink OR blue OR black
>
> hairdo: shaved OR ponytail
>
>
>
> Agent domain:
>
> required parameter values
>
> languages: yes
>
> length: yes
>
> color of socks: yes
>
> hairdo: n/a
>
>
>
> After which the region domain might decide that the missing hairdo parameter
> is not crucial and grant access, or refuse access because of it:
>
>
>
> Region domain:
>
> access denied for
>
> user: Title.FirstName.Initials.LastName.Ext= raSomething@agentdomain.org
>
>
>
> This has the benefit of permitting service providers to require what user
> parameters they think are important, be it age or color of socks, but the
> disadvantage of some extra overhead and the risk of balkanization because of
> requirements of "odd" parameters only supported by few servi= ces. The latter,
> however, I believe will become self-eliminating, because such services will
> probably not find many users. Either way, I don't think the protoc= ol in
> itself should require any particular parameters, like age or color of socks,
> just provide the means to communicate any parameters, and perhaps suggest a
> list of possible, but not required, parameters and formats for values, like
> options, ranges and enumerations. The same kind of handshake could also be
> used when requesting access to asset services and the like, even if > parameters like "object types" and "ip agreements" may be more important
> than "color of socks" there.
>
>
>
> Best regards,
>
>
>
> Magnus
>
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> Version: 9.8.3 (Build 4028)
>
> Charset: utf-8
>
>
>
> wsBVAwUBSsm0cO5MlU9XyaiSAQgEgAgAiNiznZa4fJN+iIm4Lul4iUpPNytexn9g
>
> rJWLZ4oevewngvSCOwhslseXKN+OTCUpSPq0vGxRIl58n+u9P56q0X4pYBZ5wsqc
>
> YAPdd6zGtQpR+21XQ8oWM948LEdGxba8mNO1gDygqtIyx0suBYkvYUWyYitwlDpu
>
> ofvDew+JT140ApmX/d1dTyglxyYv6qnDf8iDsHsNiWYI1ImB5a/hvPK0TkCVFvzr
>
> vLXfL5BfCXK0I3tJbLpv/OoUFEn5/emzehu3uavuQfQqQM0uBpw8WVSQGXqZziKb
>
> 6i8YpDvBrIkNL4syGhmAs7ZLUqpZEfoWq2LbGasqhVMmDCBkakrPpg=3D=3D
>
> =3DH2Fj
>
> -----END PGP SIGNATURE-----
>
>
>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/o= gpx
>
>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx=


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00504502b8551aa16204753892d1-- From infinity@lindenlab.com Mon Oct 5 16:37:11 2009 Return-Path: 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 7BF093A68E2; Mon, 5 Oct 2009 16:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.065 X-Spam-Level: X-Spam-Status: No, score=-1.065 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 Zj6m9RrjakjD; Mon, 5 Oct 2009 16:37:10 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 542633A68CE; Mon, 5 Oct 2009 16:37:10 -0700 (PDT) Received: by pzk35 with SMTP id 35so1566600pzk.29 for ; Mon, 05 Oct 2009 16:38:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.248.42 with SMTP id v42mr46716wfh.187.1254785923089; Mon, 05 Oct 2009 16:38:43 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> Date: Mon, 5 Oct 2009 16:38:43 -0700 Message-ID: <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> From: Infinity Linden To: David W Levine Content-Type: multipart/alternative; boundary=00504502caf83707f50475389d85 Cc: ogpx-bounces@ietf.org, "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 23:37:11 -0000 --00504502caf83707f50475389d85 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 5, 2009 at 1:33 PM, David W Levine wrote: > > "In order to have rights beyond "guest" on this region, you, or your agent > domain, on your behalf, needs to have signed the TOS document. I will demand > a digitally signed proof of this, as metadata when you > request acess to my region." > > - David > ~ Zha > > i think i grok what you're trying to say here, but i would also add... "a given agent domain MAY choose to deny you ANY service (including anonymous or guest access) if you don't provide some form of authenticator and assert that you have read and understand the domains terms of use." -cheers -meadhbh --00504502caf83707f50475389d85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 5, 2009 at 1:33 PM, David W Levine <dwl@us.ibm.com> wrote:

"In order to have rights beyo= nd "guest" on this region, you, or your agent domain, on your behalf= , needs to have signed the TOS document. I will demand a digitally signed proof of this, as metadata when you
request acess to my region."<= /font>

- David
~ Zha


i think i grok what you're trying = to say here, but i would also add... "a given agent domain MAY choose = to deny you ANY service (including anonymous or guest access) if you don= 9;t provide some form of authenticator and assert that you have read and un= derstand the domains terms of use."

-cheers
-meadhbh

--00504502caf83707f50475389d85-- From barryleiba.mailing.lists@gmail.com Mon Oct 5 16:38:32 2009 Return-Path: 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 55BAF3A68D0 for ; Mon, 5 Oct 2009 16:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] 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 SpKxeNJW-4eP for ; Mon, 5 Oct 2009 16:38:31 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 2A5B33A68CE for ; Mon, 5 Oct 2009 16:38:31 -0700 (PDT) Received: by yxe30 with SMTP id 30so5566277yxe.29 for ; Mon, 05 Oct 2009 16:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=oZHatSBXO8Q6DzHvy0L6eus8O/g6RIHWKVfwuUt9Wpk=; b=suOUUSXUrp6p3aEYWv8jko4ig5lEiAsKowucIm/1P/pwIHv3cCaScVjS35cSuxVUij WN+voyUhu4YZERI6zG3o3PIFcCmuzMd/Kd3FJ0NUA2CiHuAsWucbYR550KaWEBGkwblt aifuk8NggDwI2jPds1EEMHT2reVWb0acZQ0bU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=biouFqo5Fl3dLp13LI5tywgR+Lhg0XsV2o0Nhi/vTYW7HZ1L3540sZ854OCZvQXl1u 7Vz/ccfVY1jim09mbD3vA99X6GQQ3Og8uwbow4EZbXcEup6RfvNwW/6+xwQH1yrmBkCZ wcIr6jj89/oh3MdxK7iJm5LnxMMnpCXXZ4vo0= MIME-Version: 1.0 Received: by 10.150.183.11 with SMTP id g11mr1108173ybf.50.1254786006561; Mon, 05 Oct 2009 16:40:06 -0700 (PDT) Date: Mon, 5 Oct 2009 19:40:06 -0400 Message-ID: <6c9fcc2a0910051640k48499f0bs4b3bd5d1de88f3ae@mail.gmail.com> From: Barry Leiba To: ogpx Content-Type: text/plain; charset=ISO-8859-1 Subject: [ogpx] An administrative note about mailing-list participation X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 23:38:32 -0000 First, let me say that this isn't written to anyone in particular, nor with respect to any discussion thread in particular, nor in response to any existing problem. The working group chairs (Barry Leiba and Joshua Bell) and the Area Director (Alexey Melnikov) simply think that it's a good idea to make this all clear. Most of what I say here will be obvious, but there are some IETF-process-related points. There have always been participants in the IETF who choose not to be identified by traditional "full names", preferring to use nicknames, initials, or even email address alone. The IETF has welcomed such participants, and continues to do so. Yet, the VWRAP working group presents a situation unique in the IETF's experience with respect to the culture of pseudonyms and other alternative names used by its participants in other venues. Anyone who participates in any IETF discussions, including here on the mailing list, agrees, by that participation, to the "Note Well" terms [ http://www.ietf.org/about/note-well.html ]. That means, in part, that they're responsible for disclosing intellectual property rights (IPR) of which they're aware. Please be sure you understand that point, and see the relevant RFCs (the "Note Well" notice has pointers). Clearly, if you have IPR to disclose there's going to have to be some real-world identification involved, which will include the real identity of the owner of the IPR. Anyone who is a document author or editor must be contactable. We normally ask for name, affiliation, address, phone number, and email address for that, but not all of it is always provided, and we can work around some of that. The bottom line here is that what the authors provide must be given in good faith, and anyone reading the documents must be able to contact the authors. For other participants, identification doesn't matter, apart from your agreement to abide by the Note Well terms. As I said above, this has always been the case, even without virtual worlds. We ENCOURAGE everyone to use full, real-world names and, when reasonable, to disclose affiliations. What we REQUIRE is that participants either use a single, consistent identity or make it clear what set of identities they're using. If Joe Slobotnik, Shaquila Yazenzatta, and the Lone Haranguer all post to the mailing list, there should never be any question of whether or not they represent the same human participant. Misrepresentation along these lines might be cause for administrative action. It will also help if participants are familiar with the IETF Working Group Guidelines and Procedures (BCP 25), RFC 2418. The best introduction to the IETF, for those of you who are new, is Paul Hoffman's excellent document "The Tao of IETF": http://www.ietf.org/tao.html . Questions about the IETF or its process are welcome, either on the list or in private email. If you ask on the list, please use a new subject to create a new thread, so your question doesn't get lost in the middle of some other discussion. Finally, note that you can contact the chairs and the Area Directors for any working group through the tools aliases WGNAME-chairs and WGNAME-ads. For this working group, those addresses are and . Barry (and Joshua), VWRAP working group chair(s) From infinity@lindenlab.com Mon Oct 5 22:16:08 2009 Return-Path: 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 B349928C2C5 for ; Mon, 5 Oct 2009 22:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 mFP5nvp-SfM2 for ; Mon, 5 Oct 2009 22:16:07 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 8B63C3A6A8A for ; Mon, 5 Oct 2009 22:16:07 -0700 (PDT) Received: by pxi6 with SMTP id 6so4193759pxi.32 for ; Mon, 05 Oct 2009 22:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.247.23 with SMTP id u23mr73969wfh.240.1254806260234; Mon, 05 Oct 2009 22:17:40 -0700 (PDT) In-Reply-To: References: From: "Infinity Linden (Meadhbh Hamrick)" Date: Mon, 5 Oct 2009 22:17:20 -0700 Message-ID: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Virtual worlds versus the real world X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 05:16:08 -0000 this is definitely cool stuff, but fwiw, i disagree that the purpose of this working group is to work on interop between virtual worlds. MMOX is the place for those discussions. -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden On Mon, Oct 5, 2009 at 05:30, Morgaine wro= te: > Given the recent rash of preoccupation with real-world attributes, I thin= k > it needs stating that virtual worlds are immensely broader in scope than = a > mere pixellated 3D re-enactment of the real world with all its historical > baggage and petty cultural issues. > > Our interest is in enabling interop between worlds using our particular > protocol, not in prescribing the nature of worlds nor in proscribing othe= rs. > > For those who have not before seen the topic addressed, I suggest you rea= d > Henrik Bennetsen's useful summary at > http://slcreativity.org/wiki/index.php?title=3DAugmentation_vs_Immersion = . > The topic of augmentism versus immersionism has been discussed in immense > detail over many years, and if a single article can be said to capture th= e > essence, Henrik's comes close. =A0 If after reading this you are still in > denial about the separation of worlds, this positions you as an augmentis= t, > which is a highly coercive worldview.=A0 Immersionists affirm that all wo= rlds > are possible and separate and non-interfering, so their worldview is > inherently inclusive. > > Supporting virtual worlds in all their diversity and generality requires = a > broader approach than does a mere re-enactment of the physical world.=A0 = More > specifically, it requires an understanding that only a small subset of > virtual worlds reflect the real world, and that trying to force them all = to > do so is out of place. > > > Morgaine. > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From magnus.zeisig@iis.se Tue Oct 6 03:00:50 2009 Return-Path: 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 7B89628C309 for ; Tue, 6 Oct 2009 03:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.961 X-Spam-Level: X-Spam-Status: No, score=-4.961 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003] 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 v0a97u0JjfkK for ; Tue, 6 Oct 2009 03:00:49 -0700 (PDT) Received: from cleaner.prod.iis.se (cleaner.prod.iis.se [212.247.7.212]) by core3.amsl.com (Postfix) with ESMTP id 7F55628C30C for ; Tue, 6 Oct 2009 03:00:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cleaner.prod.iis.se (Postfix) with ESMTP id 2AD10A802A; Tue, 6 Oct 2009 10:02:25 +0000 (UTC) Received: from cleaner.prod.iis.se ([127.0.0.1]) by localhost (cleaner.prod.iis.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14325-07; Tue, 6 Oct 2009 10:02:11 +0000 (UTC) Received: from pgpkeys.office.nic.se (pgpkeys.office.nic.se [212.247.204.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cleaner.prod.iis.se (Postfix) with ESMTP id E55DCA8017; Tue, 6 Oct 2009 10:02:11 +0000 (UTC) Received: from EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) by pgpkeys.office.nic.se (PGP Universal service); Tue, 06 Oct 2009 12:02:11 +0200 X-PGP-Universal: processed; by pgpkeys.office.nic.se on Tue, 06 Oct 2009 12:02:11 +0200 Received: from Exchange2k7.office.nic.se ([169.254.1.222]) by EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) with mapi; Tue, 6 Oct 2009 12:02:10 +0200 From: Magnus Zeisig To: Infinity Linden , David W Levine Date: Tue, 6 Oct 2009 12:02:09 +0200 Thread-Topic: [ogpx] Protocol for permitting policy decisions Thread-Index: AcpGFQ29+H0N0AJpQxiuUJKbc7ZePgAVSOAQ Message-ID: <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> In-Reply-To: <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> Accept-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-pgp-encoding-version: 2.0.2 x-pgp-mapi-encoding-version: 2.5.0 x-pgp-encoding-format: Partitioned x-pgp-universal-saved-content-codepage: utf-8 acceptlanguage: sv-SE MIME-Version: 1.0 Content-Language: sv-SE Content-Type: multipart/alternative; boundary="_000_983F17705339E24699AA251B458249B50CC48CB1CBEXCHANGE2K7of_" X-Virus-Scanned: Debian amavisd-new at cleaner.prod.iis.se Cc: "ogpx-bounces@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 10:00:50 -0000 --_000_983F17705339E24699AA251B458249B50CC48CB1CBEXCHANGE2K7of_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkkgdHJ5 IHRvIGZvbGxvdyB0aGUgcGhpbG9zb3BoaWNhbCBkaXNjdXNzaW9ucyBvbiB0aGlzIGxpc3QsIGJ1 dCBJIG11c3QgYWRtaXQgSSdtIHByb2JhYmx5IGEgdG9vIG11Y2ggZG93biB0byBlYXJ0aCB0ZWNo IGd1eSB0byBmdWxseSBhcHByZWNpYXRlIHRoZW0uIFRoZXJlZm9yZSwgaXQncyBwb3NzaWJsZSBJ IG1pc3Mgc29tZSBvZiB0aGUgZmluZSBudWFuY2VzIG9yIHByb2JsZW1zIGluIHRoZW0uIE15IGJh c2ljIGludGVyZXN0IGlzIHRyeWluZyB0byB0cmFuc2xhdGUgdGhlIHByb2JsZW1zIEkgc2VlIGlu dG8gKG1ldGEpcHJvdG9jb2wuIEV4YWN0IG5vbWVuY2xhdHVyZSBhbmQgc3ludGF4LCBlLmcuICJk b21haW4iIG9yICJzZXJ2aWNlIiwgImFjY2VzcyIgb3IgImNhcHMiLCBJIHByZWZlciBsZWF2aW5n IHRvIHRob3NlIGJldHRlciBjYWxsZWQgdG8gZGVmaW5lIGl0LiBJIGhvcGUgdGhpcyBkb2Vzbid0 IGNhdXNlIHRvbyBtdWNoIGNvbmZ1c2lvbi4NCg0KTXkgYmFzaWMgc3VnZ2VzdGlvbiBvZiBhIGhh bmRzaGFrZSBwcm90b2NvbCBwZXJtaXR0aW5nIHBvbGljeSBkZWNpc2lvbnMgKGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vZ3B4L2N1cnJlbnQvbXNnMDA0NzUuaHRtbCkgY291 bGQgKHN0cmljdGx5IHRlY2huaWNhbGx5KSBoYW5kbGUgdGhlIGRlYmF0ZWQgaXNzdWVzIG9mIGF1 dGhlbnRpY2F0aW9uLCAiYWR1bHQgY29udGVudCIgYW5kIFRPU2VzOg0KDQpBZ2VudCBkb21haW46 DQpyZXF1ZXN0IGFjY2VzcyBmb3INCnVzZXI6IFRpdGxlLkZpcnN0TmFtZS5Jbml0aWFscy5MYXN0 TmFtZS5FeHRyYVNvbWV0aGluZ0BhZ2VudGRvbWFpbi5vcmcNCg0KUmVnaW9uIGRvbWFpbjoNCnJl cXVpcmUgcGFyYW1ldGVyIHZhbHVlcyBmb3INCnVzZXI6IFRpdGxlLkZpcnN0TmFtZS5Jbml0aWFs cy5MYXN0TmFtZS5FeHRyYVNvbWV0aGluZ0BhZ2VudGRvbWFpbi5vcmcNCmF1dGhlbnRpY2F0aW9u OiBQQVNTUE9SVCBPUiBVU1NTTiBPUiBFVUlEIE9SIEpQVkVSDQphY2NlcHQgYWR1bHQgY29udGVu dDogWUVTDQphY2NlcHQgbnVkaXR5OiBZRVMNCmFjY2VwdCBzZXh1YWwgYWN0czogWUVTDQphY2Nl cHQgcHJvZmFuZSBsYW5ndWFnZTogWUVTDQp0ZXJtcyBvZiBzZXJ2aWNlOiAoKEZSTEFXSU5GTzIw MDY6MTI4IEFORCBFVUxBV0lQMjAwODoyKSBPUiBVU0xBV1RFTEVDT00yMDA1OjEpIEFORCAoVldU T1MxLjIgT1IgTVZUT1MyLjMgT1IgTVlUT1MxLjApDQp1c2VyIHNpZ25hdHVyZTogVE9LRU4NCg0K QWdlbnQgZG9tYWluOg0KcmVxdWlyZWQgcGFyYW1ldGVyIHZhbHVlcyBmb3INCnVzZXI6IFRpdGxl LkZpcnN0TmFtZS5Jbml0aWFscy5MYXN0TmFtZS5FeHRyYVNvbWV0aGluZ0BhZ2VudGRvbWFpbi5v cmcNCmF1dGhlbnRpY2F0aW9uOiB5ZXMNCmFjY2VwdCBhZHVsdCBjb250ZW50OiB5ZXMNCmFjY2Vw dCBudWRpdHk6IHllcw0KYWNjZXB0IHNleHVhbCBhY3RzOiB5ZXMNCmFjY2VwdCBwcm9mYW5lIGxh bmd1YWdlOiBubw0KdGVybXMgb2Ygc2VydmljZTogeWVzDQp1c2VyIHNpZ25hdHVyZTogMjM4MTU4 LTIzNTYyNTctMjM4NjU4LTIzNTk2DQoNClJlZ2lvbiBkb21haW46DQphY2Nlc3MgZGVuaWVkIGZv cg0KdXNlcjogVGl0bGUuRmlyc3ROYW1lLkluaXRpYWxzLkxhc3ROYW1lLkV4dHJhU29tZXRoaW5n QGFnZW50ZG9tYWluLm9yZw0KKG91dHNpZGUgcHJvdG9jb2w6IHNpbmNlIG5vdCBhY2NlcHRpbmcg cHJvZmFuZSBsYW5ndWFnZSkNCg0KVXNpbmcgdGhpcyBtZXRob2QsIG9uZSBjb3VsZCBkZWNpZGUg dG8gbGV0IHRoZSBhZ2VudCBkb21haW4gbWFuYWdlIHRoZSBhY2NlcHRhbmNlIG9mICJhZHVsdCBj b250ZW50IiBlbnRpcmVseSwgYnkgdGhlIHJlZ2lvbiBkb21haW4gbm90IGFza2luZyBmb3IgYWdl IGJ1dCBsZXQgdGhlIGFnZW50IGRvbWFpbiBhdXRvbWF0aWNhbGx5IHNldCBhY2NlcHQgZm9yIGUu Zy4gImFkdWx0IGNvbnRlbnQiLCAibnVkaXR5IiwgInNleHVhbCBhY3RzIiBhbmQgInByb2ZhbmUg bGFuZ3VhZ2UiIHRvIE5PIGZvciB0aG9zZSB1bmRlcmFnZSBhbmQgYXMgb3B0aW9ucyBZRVMvTk8g Zm9yIHRob3NlIG9mIGFnZS4gT25lIGNvdWxkIGFsc28gZWl0aGVyIGFzayBmb3IgYWNjZXB0YW5j ZSBvZiAiYWR1bHQgY29udGVudCIgaW4gZ2VuZXJhbCBvciBmb3IgbW9yZSBzcGVjaWZpYyBwYXJh bWV0ZXJzIG9mdGVuIGFzc29jaWF0ZWQgd2l0aCAiYWR1bHQgY29udGVudCIsIGdpdmluZyBncmVh dCBmbGV4aWJpbGl0eSBpbiBwb2xpY3kgbWFraW5nLiBCdXQgb25jZSBhZ2FpbiwgdGhhdCBpcyBw b2xpY3kgb3V0c2lkZSBwcm90b2NvbCBsZXZlbC4NCg0KQmVzdCByZWdhcmRzLA0KDQpNYWdudXMN Cg0KLSAtLS0tLVVyc3BydW5nbGlndCBtZWRkZWxhbmRlLS0tLS0NCkZyw6VuOiBJbmZpbml0eSBM aW5kZW4gW21haWx0bzppbmZpbml0eUBsaW5kZW5sYWIuY29tXQ0KU2tpY2thdDogZGVuIDYgb2t0 b2JlciAyMDA5IDAxOjM5DQpUaWxsOiBEYXZpZCBXIExldmluZQ0KS29waWE6IE1hZ251cyBaZWlz aWc7IG9ncHhAaWV0Zi5vcmc7IG9ncHgtYm91bmNlc0BpZXRmLm9yZw0Kw4RtbmU6IFJlOiBbb2dw eF0gUHJvdG9jb2wgZm9yIHBlcm1pdHRpbmcgcG9saWN5IGRlY2lzaW9ucw0KDQpPbiBNb24sIE9j dCA1LCAyMDA5IGF0IDE6MzMgUE0sIERhdmlkIFcgTGV2aW5lIDxkd2xAdXMuaWJtLmNvbT4gd3Jv dGU6DQoNCg0KDQogICAgICAgICJJbiBvcmRlciB0byBoYXZlIHJpZ2h0cyBiZXlvbmQgImd1ZXN0 IiBvbiB0aGlzIHJlZ2lvbiwgeW91LCBvciB5b3VyIGFnZW50IGRvbWFpbiwgb24geW91ciBiZWhh bGYsIG5lZWRzIHRvIGhhdmUgc2lnbmVkIHRoZSBUT1MgZG9jdW1lbnQuIEkgd2lsbCBkZW1hbmQg YSBkaWdpdGFsbHkgc2lnbmVkIHByb29mIG9mIHRoaXMsIGFzIG1ldGFkYXRhIHdoZW4geW91DQog ICAgICAgIHJlcXVlc3QgYWNlc3MgdG8gbXkgcmVnaW9uLiINCg0KICAgICAgICAtIERhdmlkDQog ICAgICAgIH4gWmhhDQoNCg0KDQoNCmkgdGhpbmsgaSBncm9rIHdoYXQgeW91J3JlIHRyeWluZyB0 byBzYXkgaGVyZSwgYnV0IGkgd291bGQgYWxzbyBhZGQuLi4gImEgZ2l2ZW4gYWdlbnQgZG9tYWlu IE1BWSBjaG9vc2UgdG8gZGVueSB5b3UgQU5ZIHNlcnZpY2UgKGluY2x1ZGluZyBhbm9ueW1vdXMg b3IgZ3Vlc3QgYWNjZXNzKSBpZiB5b3UgZG9uJ3QgcHJvdmlkZSBzb21lIGZvcm0gb2YgYXV0aGVu dGljYXRvciBhbmQgYXNzZXJ0IHRoYXQgeW91IGhhdmUgcmVhZCBhbmQgdW5kZXJzdGFuZCB0aGUg ZG9tYWlucyB0ZXJtcyBvZiB1c2UuIg0KDQotIC1jaGVlcnMNCi0gLW1lYWRoYmgNCg0KDQotLS0t LUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KVmVyc2lvbjogOS44LjMgKEJ1aWxkIDQwMjgpDQpD aGFyc2V0OiB1dGYtOA0KDQp3c0JWQXdVQlNzc1ZvZTVNbFU5WHlhaVNBUWpnc3dnQXB5c2VtdERF OG5wS2hUU0NVR0hNeEZuR3hzZFV2SmZzDQovNHo2SXJpYmQ3dzJsbUQyMGN4OHhVQjEvb2pWNUFC RUVBckNSZEptV2JmNWFHSEJlRjhucnY4Y3hsRk94V1lCDQozN2NabUVZN3pBd2JZNlhOR0IwTklw RzJyblpXU1c5c0dKVU93VnM0bFcvREpLY0RtdXFneXd0d3RsNTcwNXU4DQpXM0c4eTA2STRzZWsv b3VrZ0djenFCQklHMlpueTFxZ2JQL2ZyMkFzZXdySFhZZllsTU4ySG5tenhRUjYwdnJ5DQp3SnVW K2dCZThSVkMvcHBISCtjYXJPTE1UbXdaUDhqYkduQ3kzK3dVd0k1SDgrUWJVdXB0ZFlObko4Rncw Ri91DQp5QzJJZXNLZXJNbUlsRjBaMlE5M0d5ekdvMDJtbjRkdmlMSU5ZWjBNOWtOWVhoRWUzT2t5 cFE9PQ0KPVMwTEMNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQoNCg== --_000_983F17705339E24699AA251B458249B50CC48CB1CBEXCHANGE2K7of_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+DQo8ZGl2Pi0tLS0t QkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS08L2Rpdj4NCjxkaXY+SGFzaDogU0hBMjU2PC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JIHRyeSB0byBmb2xsb3cgdGhlIHBoaWxvc29w aGljYWwgZGlzY3Vzc2lvbnMgb24gdGhpcyBsaXN0LCBidXQgSSBtdXN0IGFkbWl0IEknbSBwcm9i YWJseSBhIHRvbyBtdWNoIGRvd24gdG8gZWFydGggdGVjaCBndXkgdG8gZnVsbHkgYXBwcmVjaWF0 ZSB0aGVtLiBUaGVyZWZvcmUsIGl0J3MgcG9zc2libGUgSSBtaXNzIHNvbWUgb2YgdGhlIGZpbmUg bnVhbmNlcyBvciBwcm9ibGVtcyBpbiB0aGVtLiBNeSBiYXNpYyBpbnRlcmVzdCBpcyB0cnlpbmcN CnRvIHRyYW5zbGF0ZSB0aGUgcHJvYmxlbXMgSSBzZWUgaW50byAobWV0YSlwcm90b2NvbC4gRXhh Y3Qgbm9tZW5jbGF0dXJlIGFuZCBzeW50YXgsIGUuZy4gJnF1b3Q7ZG9tYWluJnF1b3Q7IG9yICZx dW90O3NlcnZpY2UmcXVvdDssICZxdW90O2FjY2VzcyZxdW90OyBvciAmcXVvdDtjYXBzJnF1b3Q7 LCBJIHByZWZlciBsZWF2aW5nIHRvIHRob3NlIGJldHRlciBjYWxsZWQgdG8gZGVmaW5lIGl0LiBJ IGhvcGUgdGhpcyBkb2Vzbid0IGNhdXNlIHRvbyBtdWNoIGNvbmZ1c2lvbi48L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2Pk15IGJhc2ljIHN1Z2dlc3Rpb24gb2YgYSBoYW5kc2hha2UgcHJv dG9jb2wgcGVybWl0dGluZyBwb2xpY3kgZGVjaXNpb25zICg8YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2dweC9jdXJyZW50L21zZzAwNDc1Lmh0bWwiPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vZ3B4L2N1cnJlbnQvbXNnMDA0NzUuaHRt bDwvYT4pIGNvdWxkIChzdHJpY3RseSB0ZWNobmljYWxseSkgaGFuZGxlDQp0aGUgZGViYXRlZCBp c3N1ZXMgb2YgYXV0aGVudGljYXRpb24sICZxdW90O2FkdWx0IGNvbnRlbnQmcXVvdDsgYW5kIFRP U2VzOjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QWdlbnQgZG9tYWluOjwvZGl2Pg0K PGRpdj5yZXF1ZXN0IGFjY2VzcyBmb3I8L2Rpdj4NCjxkaXY+dXNlcjogVGl0bGUuRmlyc3ROYW1l LkluaXRpYWxzLkxhc3ROYW1lLkV4dHJhU29tZXRoaW5nQGFnZW50ZG9tYWluLm9yZzwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+UmVnaW9uIGRvbWFpbjo8L2Rpdj4NCjxkaXY+cmVxdWly ZSBwYXJhbWV0ZXIgdmFsdWVzIGZvcjwvZGl2Pg0KPGRpdj51c2VyOiBUaXRsZS5GaXJzdE5hbWUu SW5pdGlhbHMuTGFzdE5hbWUuRXh0cmFTb21ldGhpbmdAYWdlbnRkb21haW4ub3JnPC9kaXY+DQo8 ZGl2PmF1dGhlbnRpY2F0aW9uOiBQQVNTUE9SVCBPUiBVU1NTTiBPUiBFVUlEIE9SIEpQVkVSPC9k aXY+DQo8ZGl2PmFjY2VwdCBhZHVsdCBjb250ZW50OiBZRVM8L2Rpdj4NCjxkaXY+YWNjZXB0IG51 ZGl0eTogWUVTPC9kaXY+DQo8ZGl2PmFjY2VwdCBzZXh1YWwgYWN0czogWUVTPC9kaXY+DQo8ZGl2 PmFjY2VwdCBwcm9mYW5lIGxhbmd1YWdlOiBZRVM8L2Rpdj4NCjxkaXY+dGVybXMgb2Ygc2Vydmlj ZTogKChGUkxBV0lORk8yMDA2OjEyOCBBTkQgRVVMQVdJUDIwMDg6MikgT1IgVVNMQVdURUxFQ09N MjAwNToxKSBBTkQgKFZXVE9TMS4yIE9SIE1WVE9TMi4zIE9SIE1ZVE9TMS4wKTwvZGl2Pg0KPGRp dj51c2VyIHNpZ25hdHVyZTogVE9LRU48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkFn ZW50IGRvbWFpbjo8L2Rpdj4NCjxkaXY+cmVxdWlyZWQgcGFyYW1ldGVyIHZhbHVlcyBmb3I8L2Rp dj4NCjxkaXY+dXNlcjogVGl0bGUuRmlyc3ROYW1lLkluaXRpYWxzLkxhc3ROYW1lLkV4dHJhU29t ZXRoaW5nQGFnZW50ZG9tYWluLm9yZzwvZGl2Pg0KPGRpdj5hdXRoZW50aWNhdGlvbjogeWVzPC9k aXY+DQo8ZGl2PmFjY2VwdCBhZHVsdCBjb250ZW50OiB5ZXM8L2Rpdj4NCjxkaXY+YWNjZXB0IG51 ZGl0eTogeWVzPC9kaXY+DQo8ZGl2PmFjY2VwdCBzZXh1YWwgYWN0czogeWVzPC9kaXY+DQo8ZGl2 PmFjY2VwdCBwcm9mYW5lIGxhbmd1YWdlOiBubzwvZGl2Pg0KPGRpdj50ZXJtcyBvZiBzZXJ2aWNl OiB5ZXM8L2Rpdj4NCjxkaXY+dXNlciBzaWduYXR1cmU6IDIzODE1OC0yMzU2MjU3LTIzODY1OC0y MzU5NjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+UmVnaW9uIGRvbWFpbjo8L2Rpdj4N CjxkaXY+YWNjZXNzIGRlbmllZCBmb3I8L2Rpdj4NCjxkaXY+dXNlcjogVGl0bGUuRmlyc3ROYW1l LkluaXRpYWxzLkxhc3ROYW1lLkV4dHJhU29tZXRoaW5nQGFnZW50ZG9tYWluLm9yZzwvZGl2Pg0K PGRpdj4ob3V0c2lkZSBwcm90b2NvbDogc2luY2Ugbm90IGFjY2VwdGluZyBwcm9mYW5lIGxhbmd1 YWdlKTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+VXNpbmcgdGhpcyBtZXRob2QsIG9u ZSBjb3VsZCBkZWNpZGUgdG8gbGV0IHRoZSBhZ2VudCBkb21haW4gbWFuYWdlIHRoZSBhY2NlcHRh bmNlIG9mICZxdW90O2FkdWx0IGNvbnRlbnQmcXVvdDsgZW50aXJlbHksIGJ5IHRoZSByZWdpb24g ZG9tYWluIG5vdCBhc2tpbmcgZm9yIGFnZSBidXQgbGV0IHRoZSBhZ2VudCBkb21haW4gYXV0b21h dGljYWxseSBzZXQgYWNjZXB0IGZvciBlLmcuICZxdW90O2FkdWx0IGNvbnRlbnQmcXVvdDssICZx dW90O251ZGl0eSZxdW90OywgJnF1b3Q7c2V4dWFsIGFjdHMmcXVvdDsgYW5kDQomcXVvdDtwcm9m YW5lIGxhbmd1YWdlJnF1b3Q7IHRvIE5PIGZvciB0aG9zZSB1bmRlcmFnZSBhbmQgYXMgb3B0aW9u cyBZRVMvTk8gZm9yIHRob3NlIG9mIGFnZS4gT25lIGNvdWxkIGFsc28gZWl0aGVyIGFzayBmb3Ig YWNjZXB0YW5jZSBvZiAmcXVvdDthZHVsdCBjb250ZW50JnF1b3Q7IGluIGdlbmVyYWwgb3IgZm9y IG1vcmUgc3BlY2lmaWMgcGFyYW1ldGVycyBvZnRlbiBhc3NvY2lhdGVkIHdpdGggJnF1b3Q7YWR1 bHQgY29udGVudCZxdW90OywgZ2l2aW5nIGdyZWF0IGZsZXhpYmlsaXR5IGluIHBvbGljeQ0KbWFr aW5nLiBCdXQgb25jZSBhZ2FpbiwgdGhhdCBpcyBwb2xpY3kgb3V0c2lkZSBwcm90b2NvbCBsZXZl bC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkJlc3QgcmVnYXJkcyw8L2Rpdj4NCjxk aXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1hZ251czwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+LSAtLS0tLVVyc3BydW5nbGlndCBtZWRkZWxhbmRlLS0tLS08L2Rpdj4NCjxkaXY+RnLDpW46 IEluZmluaXR5IExpbmRlbiBbPGEgaHJlZj0ibWFpbHRvOmluZmluaXR5QGxpbmRlbmxhYi5jb20i Pm1haWx0bzppbmZpbml0eUBsaW5kZW5sYWIuY29tPC9hPl0gPC9kaXY+DQo8ZGl2PlNraWNrYXQ6 IGRlbiA2IG9rdG9iZXIgMjAwOSAwMTozOTwvZGl2Pg0KPGRpdj5UaWxsOiBEYXZpZCBXIExldmlu ZTwvZGl2Pg0KPGRpdj5Lb3BpYTogTWFnbnVzIFplaXNpZzsgb2dweEBpZXRmLm9yZzsgb2dweC1i b3VuY2VzQGlldGYub3JnPC9kaXY+DQo8ZGl2PsOEbW5lOiBSZTogW29ncHhdIFByb3RvY29sIGZv ciBwZXJtaXR0aW5nIHBvbGljeSBkZWNpc2lvbnM8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2Pk9uIE1vbiwgT2N0IDUsIDIwMDkgYXQgMTozMyBQTSwgRGF2aWQgVyBMZXZpbmUgJmx0O2R3 bEB1cy5pYm0uY29tJmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0luIG9yZGVyIHRvIGhhdmUgcmlnaHRzIGJleW9u ZCAmcXVvdDtndWVzdCZxdW90OyBvbiB0aGlzIHJlZ2lvbiwgeW91LCBvciB5b3VyIGFnZW50IGRv bWFpbiwgb24geW91ciBiZWhhbGYsIG5lZWRzIHRvIGhhdmUgc2lnbmVkIHRoZSBUT1MgZG9jdW1l bnQuIEkgd2lsbCBkZW1hbmQgYSBkaWdpdGFsbHkgc2lnbmVkIHByb29mIG9mIHRoaXMsIGFzIG1l dGFkYXRhIHdoZW4geW91IDwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgcmVxdWVzdCBhY2VzcyB0byBteSByZWdpb24uJnF1b3Q7IDwvZGl2Pg0K PGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9kaXY+DQo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIERhdmlkIDwv ZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfiBa aGEgPC9kaXY+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PmkgdGhp bmsgaSBncm9rIHdoYXQgeW91J3JlIHRyeWluZyB0byBzYXkgaGVyZSwgYnV0IGkgd291bGQgYWxz byBhZGQuLi4gJnF1b3Q7YSBnaXZlbiBhZ2VudCBkb21haW4gTUFZIGNob29zZSB0byBkZW55IHlv dSBBTlkgc2VydmljZSAoaW5jbHVkaW5nIGFub255bW91cyBvciBndWVzdCBhY2Nlc3MpIGlmIHlv dSBkb24ndCBwcm92aWRlIHNvbWUgZm9ybSBvZiBhdXRoZW50aWNhdG9yIGFuZCBhc3NlcnQgdGhh dCB5b3UgaGF2ZSByZWFkIGFuZCB1bmRlcnN0YW5kDQp0aGUgZG9tYWlucyB0ZXJtcyBvZiB1c2Uu JnF1b3Q7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4tIC1jaGVlcnM8L2Rpdj4NCjxk aXY+LSAtbWVhZGhiaDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2Pi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tPC9kaXY+DQo8ZGl2PlZlcnNpb246 IDkuOC4zIChCdWlsZCA0MDI4KTwvZGl2Pg0KPGRpdj5DaGFyc2V0OiB1dGYtODwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+d3NCVkF3VUJTc3NWb2U1TWxVOVh5YWlTQVFqZ3N3Z0FweXNl bXRERThucEtoVFNDVUdITXhGbkd4c2RVdkpmczwvZGl2Pg0KPGRpdj4vNHo2SXJpYmQ3dzJsbUQy MGN4OHhVQjEvb2pWNUFCRUVBckNSZEptV2JmNWFHSEJlRjhucnY4Y3hsRk94V1lCPC9kaXY+DQo8 ZGl2PjM3Y1ptRVk3ekF3Ylk2WE5HQjBOSXBHMnJuWldTVzlzR0pVT3dWczRsVy9ESktjRG11cWd5 d3R3dGw1NzA1dTg8L2Rpdj4NCjxkaXY+VzNHOHkwNkk0c2VrL291a2dHY3pxQkJJRzJabnkxcWdi UC9mcjJBc2V3ckhYWWZZbE1OMkhubXp4UVI2MHZyeTwvZGl2Pg0KPGRpdj53SnVWJiM0MztnQmU4 UlZDL3BwSEgmIzQzO2Nhck9MTVRtd1pQOGpiR25DeTMmIzQzO3dVd0k1SDgmIzQzO1FiVXVwdGRZ Tm5KOEZ3MEYvdTwvZGl2Pg0KPGRpdj55QzJJZXNLZXJNbUlsRjBaMlE5M0d5ekdvMDJtbjRkdmlM SU5ZWjBNOWtOWVhoRWUzT2t5cFE9PTwvZGl2Pg0KPGRpdj49UzBMQzwvZGl2Pg0KPGRpdj4tLS0t LUVORCBQR1AgU0lHTkFUVVJFLS0tLS08L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_983F17705339E24699AA251B458249B50CC48CB1CBEXCHANGE2K7of_-- From carlo@alinoe.com Tue Oct 6 04:16:30 2009 Return-Path: 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 C6E123A6ABE for ; Tue, 6 Oct 2009 04:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 i6MN+m6SVSea for ; Tue, 6 Oct 2009 04:16:30 -0700 (PDT) Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id 8F64B3A6ABC for ; Tue, 6 Oct 2009 04:16:29 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091006111804.WHAE422.viefep16-int.chello.at@edge01.upc.biz>; Tue, 6 Oct 2009 13:18:04 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id pPJ21c05T0FlQed01PJ3lo; Tue, 06 Oct 2009 13:18:04 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mv84d-0001nI-H4; Tue, 06 Oct 2009 13:19:19 +0200 Date: Tue, 6 Oct 2009 13:19:19 +0200 From: Carlo Wood To: Meadhbh Siobhan Message-ID: <20091006111919.GB32650@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 11:16:30 -0000 On Mon, Oct 05, 2009 at 09:32:34AM -0700, Meadhbh Siobhan wrote: > again, this is a matter of policy, not a matter of protocol. > > let me give you a counter example. [...snip...] > so the answer to the question of "what does the protocol have to do?" > is that it only has to convey information about the identity of the > agent domain to the region provider. it also has to have a mechanism > for the agent domain to identify the region. > > but the protocol itself does not impose restrictions as to the > identity of either party. that is a policy issue. Correct me if I'm wrong, but you are saying that every AD needs to add a configuration for each region that is serves to know what to do when a given user wants to TP to that region? And the protocol does not provide a way for the RD to change that configuration. That sounds like a can of worms in terms of administration horrors. It's not flexible at all, it would make it very labour intensive to add a new AD to some RD, or for an RD to switch to a different AD. 'Trust' wouldn't be enough anymore. Imho, we MUST PUT THE MEANS OF (RE)CONFIGURATION OF REGION DOMAIN POLICIES IN THE HANDS OF THE REGION DOMAIN! Let them change it daily, and immediately, if they wish. -- Carlo Wood From carlo@alinoe.com Tue Oct 6 04:32:59 2009 Return-Path: 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 1BAC028C17C; Tue, 6 Oct 2009 04:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 F4c0FtAUEi0P; Tue, 6 Oct 2009 04:32:58 -0700 (PDT) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id AA86728C158; Tue, 6 Oct 2009 04:32:57 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091006113432.UPZG24260.viefep11-int.chello.at@edge05.upc.biz>; Tue, 6 Oct 2009 13:34:32 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id pPaW1c06g0FlQed05PaXWb; Tue, 06 Oct 2009 13:34:32 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mv8KZ-0001y0-M0; Tue, 06 Oct 2009 13:35:47 +0200 Date: Tue, 6 Oct 2009 13:35:47 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20091006113547.GC32650@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <4646639E08F58B42836FAC24C94624DD771A0D8521@GVW0433EXB.americas.hpqcorp.net> <4646639E08F58B42836FAC24C94624DD771A156244@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0910051635g10ee6bbcvdd74a050cced9583@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a880e2c0910051635g10ee6bbcvdd74a050cced9583@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Meadhbh Siobhan , "ogpx@ietf.org" , ogpx-bounces@ietf.org, Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 11:32:59 -0000 On Mon, Oct 05, 2009 at 04:35:36PM -0700, Infinity Linden wrote: > so... throughout the documentation... we use the term "domain" to mean "a > collection of systems and networks over which control is exercised." the > "authority" is the entity (individual or group) that exercises the control. the > manifestation of the authority's control is (among other things) the ability to > set "policy." authority may be "devolved" to "subordinate authorities." > superior authority may decide which policy clauses to devolve and which to > retain. specific service interfaces deployed by a domain may implement > different policies. > > ultimately it should not be the work of this group to determine policies for > domains, or even to provide an exhaustive list of policies. specific clauses in > a policy most likely arise from a specific implementation of the protocol. it > should not be the work of this group to bless any one implementation and it's > determination of how to represent policy. (i have personally said many times > that the effort of this group should not be to bless Second Life(tm)'s legacy > protocol and it's related policies. but this does not mean that we should bless > OpenSimulator.) This makes sense. > can we agree to this wording? yes > can we move on? no, still need answers to other questions :p -- Carlo Wood From carlo@alinoe.com Tue Oct 6 04:37:07 2009 Return-Path: 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 DA97E28C18A for ; Tue, 6 Oct 2009 04:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 0E6tixrRhlW7 for ; Tue, 6 Oct 2009 04:37:07 -0700 (PDT) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id AF27A28C171 for ; Tue, 6 Oct 2009 04:37:06 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep15-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091006113839.WTOB17988.viefep15-int.chello.at@edge02.upc.biz>; Tue, 6 Oct 2009 13:38:39 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upc.biz with edge id pPed1c03e0FlQed02Pee5R; Tue, 06 Oct 2009 13:38:39 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mv8OY-000242-G7; Tue, 06 Oct 2009 13:39:54 +0200 Date: Tue, 6 Oct 2009 13:39:54 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20091006113954.GD32650@alinoe.com> References: <20091002012335.GB690@alinoe.com> <20091005182505.GA20468@alinoe.com> <3a880e2c0910051131k2d81531au275782c6cb3c3655@mail.gmail.com> <20091005223242.GA32650@alinoe.com> <3a880e2c0910051601q7761b380w5985442899ec45aa@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a880e2c0910051601q7761b380w5985442899ec45aa@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 11:37:08 -0000 On Mon, Oct 05, 2009 at 04:01:03PM -0700, Infinity Linden wrote: > protocol, but leave this as a POLICY for the deployers. personally, i > have NO PROBLEM with an agent domain and a region domain making > asymmetric agreements. that is, if region domain X wants to make > policy A with agent domain Y, but wants to make a different policy > (call it policy B) with agent domain Z, well good on 'em. i guess i'm > too much of libertarian at heart to have a protocol demand that each > participant or pair of participants use exactly the same protocol. and that isn't a problem, as long as the AD policy is ONLY used to decide if a user is let in or not. -- Carlo Wood From dwl@us.ibm.com Tue Oct 6 06:47:47 2009 Return-Path: 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 B21403A69BC; Tue, 6 Oct 2009 06:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.829 X-Spam-Level: X-Spam-Status: No, score=-5.829 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_00=-2.599, 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 OLkcY0LzMoPu; Tue, 6 Oct 2009 06:47:43 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id 97BCC3A693F; Tue, 6 Oct 2009 06:47:43 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e8.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n96Dkisu000562; Tue, 6 Oct 2009 09:46:44 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n96DnKAu243690; Tue, 6 Oct 2009 09:49:20 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n96DnKuu028450; Tue, 6 Oct 2009 09:49:20 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n96DnK4P028444; Tue, 6 Oct 2009 09:49:20 -0400 In-Reply-To: <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> To: Infinity Linden MIME-Version: 1.0 X-KeepSent: 846C2637:4E109B09-85257647:004B1EFF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Tue, 6 Oct 2009 09:49:19 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/06/2009 09:49:19, Serialize complete at 10/06/2009 09:49:19 Content-Type: multipart/alternative; boundary="=_alternative 004BED8485257647_=" Cc: ogpx-bounces@ietf.org, "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 13:47:47 -0000 This is a multipart message in MIME format. --=_alternative 004BED8485257647_= Content-Type: text/plain; charset="US-ASCII" Well, I'd again (like the sadly broken record I'm becoming on this topic) say its a service or set of services which denies the access, but quite. A deployer is free to apply any policy they chose to a service request. If they only want people who have visited Candy Mountain, Surrendered a Kidney, and can prove it in the form of the ability to respond to provide a special token from the magical unicorn powered talisman they get from the Leoplueridon to access a given service, so be it. The protocol need merely allow them to insert: unicorn_talisman_token shun the unbeliever in an expected spot, and they can reject people who can't provide the correct response. - David ~ Zha Infinity Linden 10/05/2009 07:38 PM To David W Levine/Watson/IBM@IBMUS cc Magnus Zeisig , "ogpx@ietf.org" , ogpx-bounces@ietf.org Subject Re: [ogpx] Protocol for permitting policy decisions On Mon, Oct 5, 2009 at 1:33 PM, David W Levine wrote: "In order to have rights beyond "guest" on this region, you, or your agent domain, on your behalf, needs to have signed the TOS document. I will demand a digitally signed proof of this, as metadata when you request acess to my region." - David ~ Zha i think i grok what you're trying to say here, but i would also add... "a given agent domain MAY choose to deny you ANY service (including anonymous or guest access) if you don't provide some form of authenticator and assert that you have read and understand the domains terms of use." -cheers -meadhbh --=_alternative 004BED8485257647_= Content-Type: text/html; charset="US-ASCII"
Well, I'd again (like the sadly broken record I'm becoming on this topic) say its a service or set of services which denies the access, but quite. A deployer is free to apply any policy they chose to a service request. If they only want people who have visited Candy Mountain, Surrendered a Kidney, and can prove it in the form of the ability to respond to provide a special token from the magical unicorn powered talisman they get from the Leoplueridon to access a given service, so be it. The protocol need merely allow them to insert:
<map>
<key>unicorn_talisman_token</key>
<string>shun the unbeliever</string>
</map>

in an expected spot, and they can reject people who can't provide the correct response.

- David
~ Zha





Infinity Linden <infinity@lindenlab.com>

10/05/2009 07:38 PM

To
David W Levine/Watson/IBM@IBMUS
cc
Magnus Zeisig <magnus.zeisig@iis.se>, "ogpx@ietf.org" <ogpx@ietf.org>, ogpx-bounces@ietf.org
Subject
Re: [ogpx] Protocol for permitting policy decisions





On Mon, Oct 5, 2009 at 1:33 PM, David W Levine <dwl@us.ibm.com> wrote:

"In order to have rights beyond "guest" on this region, you, or your agent domain, on your behalf, needs to have signed the TOS document. I will demand a digitally signed proof of this, as metadata when you
request acess to my region."

- David
~ Zha


i think i grok what you're trying to say here, but i would also add... "a given agent domain MAY choose to deny you ANY service (including anonymous or guest access) if you don't provide some form of authenticator and assert that you have read and understand the domains terms of use."

-cheers
-meadhbh

--=_alternative 004BED8485257647_=-- From morgaine.dinova@googlemail.com Tue Oct 6 09:27:56 2009 Return-Path: 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 4FA093A6847 for ; Tue, 6 Oct 2009 09:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 j7Nt8zOkCaHS for ; Tue, 6 Oct 2009 09:27:54 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 3AAFF3A6821 for ; Tue, 6 Oct 2009 09:27:54 -0700 (PDT) Received: by ewy10 with SMTP id 10so4376370ewy.9 for ; Tue, 06 Oct 2009 09:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=4aZ/czBCNYmvKFV3jpS6aOWTG81QYGhYePMHH+OdxUw=; b=XOw2f9KBiXNsHns4d5yrWuiDa68dbrqsw08eTd/j12vTeQC3G2YLnXVa+fMBPmWQVR T55QYsRIstVA5doyOYix3UYJlfDu4wIe+YbBZTF7fMArWFLuz0r00a5pxWkgRB7wkpHF hDNo6Thhewfqw3hBShl3a5wcaEWapKZcnYhg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=P5XjIz54uUGoO75hJtv4zBjlvjluC8RBtB3VmKXWOvwPZeHFPBOZDJP1qIudCwp7tC HfTy611yxeuGGv0Ua4JNWbg9pf1lFGQ6U0GnZHOrxU4aR4jSu0BV6NYPNVxfc1DLC4OD 9rimRfln0+L7puMFMBh52Em15tRv8pgB3C2e8= MIME-Version: 1.0 Received: by 10.211.160.4 with SMTP id m4mr1890850ebo.24.1254846566972; Tue, 06 Oct 2009 09:29:26 -0700 (PDT) In-Reply-To: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> Date: Tue, 6 Oct 2009 17:29:26 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00504502d38adf3f38047546bb13 Subject: Re: [ogpx] Virtual worlds versus the real world X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 16:27:56 -0000 --00504502d38adf3f38047546bb13 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 6, 2009 at 6:17 AM, Infinity Linden (Meadhbh Hamrick) < infinity@lindenlab.com> wrote: this is definitely cool stuff, but fwiw, i disagree that the purpos of this > working group is to work on interop between virtual worlds. > We've just spent a week discussing multi-world deployments of VWRAP, consisting of two virtual worlds W1 and W2 containing AD1/AD2, RD1/RD2, and an agent A1 that travels between worlds, and we achieved more progress on this deployment pattern last week than in the preceding 2 years of AWG. Joshua has given us some excellent insights into the requirements of that deployment pattern, culminating in wholesale agreement here -- http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html . Consequently, we most certainly *are* working on interop between virtual worlds, VWRAP-compatible ones naturally. This has been decided and agreed by the group repeatedly over the last several months, because it is a deployment pattern that interests almost everybody in the group. You many wish to consult Joshua on this. > MMOX is the place for those discussions. MMOX is the place for discussions about worlds that cannot or do not wish to interoperate via VWRAP. We do not prescribe the kinds of worlds that can use VWRAP, nor proscribe which worlds cannot. If two worlds implement VWRAP-compatible endpoints to VWRAP services, then they fall under the banner of VWRAP. It's not our business to forbid them. (It's worth noting that this applies similarly to every other IETF protocol.) While it is common to use the shortcut "SL-like" to describe the worlds that are relevant to us here, VWRAP also applies very strongly to Opensim-based virtual worlds as well of course. Yet, Opensim-based virtual worlds can communicate through MXP and various other interop technologies that are not VWRAP, and those styles of interop would not concern us here but be a subject for MMOX. This highlights vividly that the nature of the worlds that communicate is not our concern. Only their interoperation using VWRAP is relevant to this workgroup. Morgaine. =================================== On Tue, Oct 6, 2009 at 6:17 AM, Infinity Linden (Meadhbh Hamrick) < infinity@lindenlab.com> wrote: > this is definitely cool stuff, but fwiw, i disagree that the purpose > of this working group is to work on interop between virtual worlds. > MMOX is the place for those discussions. > > -- > infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" > http://wiki.secondlife.com/wiki/User:Infinity_Linden > > > > On Mon, Oct 5, 2009 at 05:30, Morgaine > wrote: > > Given the recent rash of preoccupation with real-world attributes, I > think > > it needs stating that virtual worlds are immensely broader in scope than > a > > mere pixellated 3D re-enactment of the real world with all its historical > > baggage and petty cultural issues. > > > > Our interest is in enabling interop between worlds using our particular > > protocol, not in prescribing the nature of worlds nor in proscribing > others. > > > > For those who have not before seen the topic addressed, I suggest you > read > > Henrik Bennetsen's useful summary at > > http://slcreativity.org/wiki/index.php?title=Augmentation_vs_Immersion . > > The topic of augmentism versus immersionism has been discussed in immense > > detail over many years, and if a single article can be said to capture > the > > essence, Henrik's comes close. If after reading this you are still in > > denial about the separation of worlds, this positions you as an > augmentist, > > which is a highly coercive worldview. Immersionists affirm that all > worlds > > are possible and separate and non-interfering, so their worldview is > > inherently inclusive. > > > > Supporting virtual worlds in all their diversity and generality requires > a > > broader approach than does a mere re-enactment of the physical world. > More > > specifically, it requires an understanding that only a small subset of > > virtual worlds reflect the real world, and that trying to force them all > to > > do so is out of place. > > > > > > Morgaine. > > > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --00504502d38adf3f38047546bb13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Oct 6, 2009 at 6:17 AM, Infinity Linden (Meadhbh Hamrick) <infinity@lindenlab.c= om> wrote:

this is definitely cool stuff, but fwiw, i disagree that the purpos of this= working group is to work on interop between virtual worlds.


We've just spent a week discussing multi-world deploymen= ts of VWRAP, consisting of two virtual worlds W1 and W2 containing AD1/AD2,= RD1/RD2, and an agent A1 that travels between worlds, and we achieved more= progress on this deployment pattern last week than in the preceding 2 year= s of AWG.=A0 Joshua has given us some excellent insights into the requireme= nts of that deployment pattern, culminating in wholesale agreement here -- = http://www.ietf.org/mail-archive/web/ogpx/current/msg00451.html .

Consequently, we most certainly are working on interop between v= irtual worlds, VWRAP-compatible ones naturally.=A0 This has been decided an= d agreed by the group repeatedly over the last several months, because it i= s a deployment pattern that interests almost everybody in the group.=A0 You= many wish to consult Joshua on this.

=A0
MMOX is the place for those discussions.


MMOX is t= he place for discussions about worlds that cannot or do not wish to interop= erate via VWRAP.=A0 We do not prescribe the kinds of worlds that can use VW= RAP, nor proscribe which worlds cannot.=A0 If two worlds implement VWRAP-co= mpatible endpoints to VWRAP services, then they fall under the banner of VW= RAP.=A0 It's not our business to forbid them.

(It's worth noting that this applies similarly to every other IETF = protocol.)

While it is common to use the shortcut "SL-like"= ; to describe the worlds that are relevant to us here, VWRAP also applies v= ery strongly to Opensim-based virtual worlds as well of course.=A0 Yet, Ope= nsim-based virtual worlds can communicate through MXP and various other int= erop technologies that are not VWRAP, and those styles of interop would not= concern us here but be a subject for MMOX.

This highlights vividly that the nature of the worlds that communicate = is not our concern.=A0 Only their interoperation using VWRAP=A0 is relevant= to this workgroup.

Morgaine.





=A0
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

On Tue, Oct 6, 2009 at 6:17 AM, Infinity Lin= den (Meadhbh Hamrick) <infinity@lindenlab.com> wrote:
this is definitely cool stuff, but fwiw, i disagree that the purpose
of this working group is to work on interop between virtual worlds.
MMOX is the place for those discussions.

--
=A0 infinity linden (aka meadhbh hamrick) =A0* =A0it's pronounced &quo= t;maeve"
=A0 =A0 =A0 =A0 http://wiki.secondlife.com/wiki/User:Infinity_Lind= en



On Mon, Oct 5, 2009 at 05:30, Morgaine <morgaine.dinova@googlemail.com> wrote:
> Given the recent rash of preoccupation with real-world attributes, I t= hink
> it needs stating that virtual worlds are immensely broader in scope th= an a
> mere pixellated 3D re-enactment of the real world with all its histori= cal
> baggage and petty cultural issues.
>
> Our interest is in enabling interop between worlds using our particula= r
> protocol, not in prescribing the nature of worlds nor in proscribing o= thers.
>
> For those who have not before seen the topic addressed, I suggest you = read
> Henrik Bennetsen's useful summary at
> http://slcreativity.org/wiki/index.php?tit= le=3DAugmentation_vs_Immersion .
> The topic of augmentism versus immersionism has been discussed in imme= nse
> detail over many years, and if a single article can be said to capture= the
> essence, Henrik's comes close. =A0 If after reading this you are s= till in
> denial about the separation of worlds, this positions you as an augmen= tist,
> which is a highly coercive worldview.=A0 Immersionists affirm that all= worlds
> are possible and separate and non-interfering, so their worldview is > inherently inclusive.
>
> Supporting virtual worlds in all their diversity and generality requir= es a
> broader approach than does a mere re-enactment of the physical world.= =A0 More
> specifically, it requires an understanding that only a small subset of=
> virtual worlds reflect the real world, and that trying to force them a= ll to
> do so is out of place.
>
>
> Morgaine.
>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

--00504502d38adf3f38047546bb13-- From josh@lindenlab.com Tue Oct 6 10:30:39 2009 Return-Path: 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 65D253A6783 for ; Tue, 6 Oct 2009 10:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 1pde6Y1DCyzo for ; Tue, 6 Oct 2009 10:30:34 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 2F7E33A6821 for ; Tue, 6 Oct 2009 10:30:34 -0700 (PDT) Received: by pzk35 with SMTP id 35so2425434pzk.29 for ; Tue, 06 Oct 2009 10:32:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.36.13 with SMTP id o13mr273738rvj.188.1254850329258; Tue, 06 Oct 2009 10:32:09 -0700 (PDT) In-Reply-To: References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> Date: Tue, 6 Oct 2009 10:32:09 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cd22caa1f2b7f0475479c96 Subject: Re: [ogpx] Virtual worlds versus the real world X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 17:30:39 -0000 --000e0cd22caa1f2b7f0475479c96 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 6, 2009 at 9:29 AM, Morgaine wrote: > On Tue, Oct 6, 2009 at 6:17 AM, Infinity Linden (Meadhbh Hamrick) < > infinity@lindenlab.com> wrote: > > this is definitely cool stuff, but fwiw, i disagree that the purpos of this >> working group is to work on interop between virtual worlds. >> > (snip) > Consequently, we most certainly *are* working on interop between virtual > worlds, VWRAP-compatible ones naturally. > FWIW, I read Meadhbh's comment as "...between different VW technologies/types (as defined by protocol implementation)", so I don't see a disagreement between these statements. The distinction is between (1) attempting to define broad interop between all possible VWs (so I can TP from SL to Webkins and visit my son's creature) , and (2) defining basic operation of Agent/Region-style VWs with a protocol that therefore enables interop between conforming implementations. Anyone want to take on the task of collecting all of the definitions of "virtual world" that have been floated about, as an informational draft? --000e0cd22caa1f2b7f0475479c96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 6, 2009 at 9:29 AM, Morgaine <morgaine.d= inova@googlemail.com> wrote:
On Tue, Oct 6, 2009 at 6:17 AM, Infinity Linden (Meadhbh Hamrick) <in= finity@lindenlab.com> wrote:

this is definitely cool stuff, but fwiw, i disagree that the purpos of this= working group is to work on interop between virtual worlds.
=C2=A0
(snip)


Consequently, we most certainly are working on interop betw= een virtual worlds, VWRAP-compatible ones naturally.=C2=A0

FWIW, I read Meadhbh's comment as "...between differe= nt VW technologies/types (as defined by protocol implementation)", so = I don't see a disagreement between these statements.

The distinction is between (1) attempting to define broad interop betwe= en all possible VWs (so I can TP from SL to Webkins and visit my son's = creature) , and (2) defining basic operation of Agent/Region-style VWs with= a protocol that therefore enables interop between conforming implementatio= ns.

Anyone want to take on the task of collecting all of the definitions of= "virtual world" that have been floated about, as an informationa= l draft?
--000e0cd22caa1f2b7f0475479c96-- From mike.dickson@hp.com Tue Oct 6 10:39:43 2009 Return-Path: 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 77F953A6783 for ; Tue, 6 Oct 2009 10:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 u3AspkOa6gDf for ; Tue, 6 Oct 2009 10:39:42 -0700 (PDT) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by core3.amsl.com (Postfix) with ESMTP id 8A3413A69DC for ; Tue, 6 Oct 2009 10:39:42 -0700 (PDT) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 0AE2F81D2; Tue, 6 Oct 2009 17:41:19 +0000 (UTC) Received: from G4W1853.americas.hpqcorp.net (16.234.97.231) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 6 Oct 2009 17:40:10 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G4W1853.americas.hpqcorp.net ([16.234.97.231]) with mapi; Tue, 6 Oct 2009 17:40:10 +0000 From: "Dickson, Mike (ISS Software)" To: Joshua Bell , "ogpx@ietf.org" Date: Tue, 6 Oct 2009 17:39:53 +0000 Thread-Topic: Reference material Thread-Index: AcpGqvVVfz3fPRw2SY63Q6XAmNpEWgAAK7Zw Message-ID: <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD771A156C3EGVW0433EXBame_" MIME-Version: 1.0 Subject: [ogpx] Reference material X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 17:39:43 -0000 --_000_4646639E08F58B42836FAC24C94624DD771A156C3EGVW0433EXBame_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogb2dweC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2dweC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSm9zaHVhIEJlbGwNClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDYsIDIw MDkgMTI6MzIgUE0NClRvOiBvZ3B4QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW29ncHhdIFZpcnR1 YWwgd29ybGRzIHZlcnN1cyB0aGUgcmVhbCB3b3JsZA0KDQpBbnlvbmUgd2FudCB0byB0YWtlIG9u IHRoZSB0YXNrIG9mIGNvbGxlY3RpbmcgYWxsIG9mIHRoZSBkZWZpbml0aW9ucyBvZiAidmlydHVh bCB3b3JsZCIgdGhhdCBoYXZlIGJlZW4gZmxvYXRlZCBhYm91dCwgYXMgYW4NCmluZm9ybWF0aW9u YWwgZHJhZnQ/DQoNClJlbGF0ZWQsIGlzIHRoZXJlIGEgcG9pbnRlciB0byB0aGUgb3RoZXIgaW5m b3JtYXRpb25hbCBkb2N1bWVudHMgdGhhdCBhcmUgcmVsZXZhbnQgdG8gVldSQVAgKGxpa2UgdGhl IE9HUCBzdHVmZiBmb3IgaW5zdGFuY2UpPyAgVGhlcmXigJlzIG5vdGhpbmcgb24gdGhlIFZXUkFQ IHBhZ2Ugb3Igd2lraSBvbiB0aGUgSUVURiBzaXRlLiAgSXTigJlzIGNsZWFyIEkgY291bGQgZG8g d2l0aCBzb21lIGJhY2tncm91bmQgcmVhZGluZyBvbiB3aGF04oCZcyBjb21lIGJlZm9yZS4gIEkg c2VlIHJlZmVyZW5jZXMgdG8gaXQgaW4gb3RoZXIgcG9zdHMuDQoNCk1pa2UNCg== --_000_4646639E08F58B42836FAC24C94624DD771A156C3EGVW0433EXBame_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQg NCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlv bjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9 RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0K PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1sZWZ0Oi41aW4nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBv Z3B4LWJvdW5jZXNAaWV0Zi5vcmcNClttYWlsdG86b2dweC1ib3VuY2VzQGlldGYub3JnXSA8Yj5P biBCZWhhbGYgT2YgPC9iPkpvc2h1YSBCZWxsPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE9j dG9iZXIgMDYsIDIwMDkgMTI6MzIgUE08YnI+DQo8Yj5Ubzo8L2I+IG9ncHhAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtvZ3B4XSBWaXJ0dWFsIHdvcmxkcyB2ZXJzdXMgdGhlIHJl YWwgd29ybGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J3RleHQtaW5kZW50Oi41aW4nPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0ndGV4dC1pbmRlbnQ6LjVpbic+QW55b25lIHdhbnQgdG8gdGFrZSBvbiB0aGUgdGFzayBvZg0K Y29sbGVjdGluZyBhbGwgb2YgdGhlIGRlZmluaXRpb25zIG9mICZxdW90O3ZpcnR1YWwgd29ybGQm cXVvdDsgdGhhdCBoYXZlIGJlZW4NCmZsb2F0ZWQgYWJvdXQsIGFzIGFuIDxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0ndGV4dC1pbmRlbnQ6LjVpbic+aW5mb3JtYXRpb25hbCBkcmFmdD88bzpwPjwvbzpw PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzFGNDk3RCc+UmVsYXRlZCwgaXMgdGhlcmUgYSBwb2ludGVyIHRvIHRoZSBvdGhlciBp bmZvcm1hdGlvbmFsIGRvY3VtZW50cw0KdGhhdCBhcmUgcmVsZXZhbnQgdG8gVldSQVAgKGxpa2Ug dGhlIE9HUCBzdHVmZiBmb3IgaW5zdGFuY2UpP8KgIFRoZXJl4oCZcyBub3RoaW5nDQpvbiB0aGUg VldSQVAgcGFnZSBvciB3aWtpIG9uIHRoZSBJRVRGIHNpdGUuwqAgSXTigJlzIGNsZWFyIEkgY291 bGQgZG8gd2l0aCBzb21lDQpiYWNrZ3JvdW5kIHJlYWRpbmcgb24gd2hhdOKAmXMgY29tZSBiZWZv cmUuwqAgSSBzZWUgcmVmZXJlbmNlcyB0byBpdCBpbiBvdGhlciBwb3N0cy4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6IzFGNDk3RCc+TWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+ DQoNCjwvYm9keT4NCg0KPC9odG1sPg0K --_000_4646639E08F58B42836FAC24C94624DD771A156C3EGVW0433EXBame_-- From infinity@lindenlab.com Tue Oct 6 11:43:17 2009 Return-Path: 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 3169C3A684B for ; Tue, 6 Oct 2009 11:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ZsopegqUdyTX for ; Tue, 6 Oct 2009 11:43:16 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id CBF7D3A683B for ; Tue, 6 Oct 2009 11:43:13 -0700 (PDT) Received: by pzk35 with SMTP id 35so2490200pzk.29 for ; Tue, 06 Oct 2009 11:44:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.3.12 with SMTP id 12mr137336wfc.331.1254854688149; Tue, 06 Oct 2009 11:44:48 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> From: "Infinity Linden (Meadhbh Hamrick)" Date: Tue, 6 Oct 2009 11:44:28 -0700 Message-ID: <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> To: "Dickson, Mike (ISS Software)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "ogpx@ietf.org" Subject: Re: [ogpx] Reference material X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 18:43:17 -0000 the intro doc is a good place to start. http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 i've got a LOT of feedback that still needs to be incorporated into a new rev though. were you looking at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ ? i know josh said that he's in the process of putting some content up there. -cheers -meadhbh -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden On Tue, Oct 6, 2009 at 10:39, Dickson, Mike (ISS Software) wrote: > From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of > Joshua Bell > Sent: Tuesday, October 06, 2009 12:32 PM > To: ogpx@ietf.org > Subject: Re: [ogpx] Virtual worlds versus the real world > > > > Anyone want to take on the task of collecting all of the definitions of > "virtual world" that have been floated about, as an > > informational draft? > > > > Related, is there a pointer to the other informational documents that are > relevant to VWRAP (like the OGP stuff for instance)?=A0 There=92s nothing= on the > VWRAP page or wiki on the IETF site.=A0 It=92s clear I could do with some > background reading on what=92s come before.=A0 I see references to it in = other > posts. > > > > Mike > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From mike.dickson@hp.com Tue Oct 6 11:56:24 2009 Return-Path: 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 9644E28C0FF for ; Tue, 6 Oct 2009 11:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 OE3ci4aqkTvC for ; Tue, 6 Oct 2009 11:56:23 -0700 (PDT) Received: from g5t0009.atlanta.hp.com (g5t0009.atlanta.hp.com [15.192.0.46]) by core3.amsl.com (Postfix) with ESMTP id B214728C0CF for ; Tue, 6 Oct 2009 11:56:23 -0700 (PDT) Received: from G3W0630.americas.hpqcorp.net (g3w0630.americas.hpqcorp.net [16.233.58.74]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0009.atlanta.hp.com (Postfix) with ESMTPS id EF2EC3022D; Tue, 6 Oct 2009 18:58:00 +0000 (UTC) Received: from G4W1853.americas.hpqcorp.net (16.234.97.231) by G3W0630.americas.hpqcorp.net (16.233.58.74) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 6 Oct 2009 18:57:54 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G4W1853.americas.hpqcorp.net ([16.234.97.231]) with mapi; Tue, 6 Oct 2009 18:57:53 +0000 From: "Dickson, Mike (ISS Software)" To: "Infinity Linden (Meadhbh Hamrick)" Date: Tue, 6 Oct 2009 18:57:05 +0000 Thread-Topic: [ogpx] Reference material Thread-Index: AcpGtRU8Kwaoina0RzWoleWBWGxhxgAAWk9A Message-ID: <4646639E08F58B42836FAC24C94624DD771A156D0E@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> In-Reply-To: <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD771A156D0EGVW0433EXBame_" MIME-Version: 1.0 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] Reference material X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 18:56:24 -0000 --_000_4646639E08F58B42836FAC24C94624DD771A156D0EGVW0433EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable were you looking at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ ? i know josh said that he's in the process of putting some content up there. -cheers -meadhbh -- Yep. I did find the charter just now as well so it should be easier for ot= hers to find these references. I don't recall seeing it before but I'm sur= e I just missed it. Now for some reading.... Mike --_000_4646639E08F58B42836FAC24C94624DD771A156D0EGVW0433EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

were you looking at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ ? i

know josh said that he's= in the process of putting some content up

there.

 

-cheers

-meadhbh

--

 

Yep.  I did find the charter just now as well = so it should be easier for others to find these references.  I don't recall = seeing it before but I'm sure I just missed it.    Now for some readin= g....

 

Mike

 

 

--_000_4646639E08F58B42836FAC24C94624DD771A156D0EGVW0433EXBame_-- From morgaine.dinova@googlemail.com Tue Oct 6 12:00:25 2009 Return-Path: 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 D4A8D28C0D9 for ; Tue, 6 Oct 2009 12:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 J-MFE4Y3a615 for ; Tue, 6 Oct 2009 12:00:24 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id A17F828C366 for ; Tue, 6 Oct 2009 12:00:13 -0700 (PDT) Received: by ewy10 with SMTP id 10so4541101ewy.9 for ; Tue, 06 Oct 2009 12:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hrhquNG2NTmu1uLA3Snodwqf9smEi3b48wYVQwTkPD8=; b=vpiXV8MhdyYONBRjsTwctRtIl3oy3arQQEXO3137KCsX5IP6yw+aoMlplVI3DPCI3m rwghGBFCFrZrxBPPaQi8qzEMn3erkjKP0DyH6yNyTwEHrRP6NptlQA3KFGXeRclDWmlO SzMaInqgOadatsBwiWpVoEx5URWjm/huST4x0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lTwumXQdQVwd9robf3eOox3FCflm1zKYRP/47luYrgDWTHJa7Zqh6uaHC1CEJyAbYp qgl1V1sMauDsHRGTDKCElCRwLL0NvtwnMoBIvtq61BQ611piL8hlqhVsiOH4v8u0NUlY oF4a/IfQcicIqaHWPRpmqqupeCa1gmsLOWgyE= MIME-Version: 1.0 Received: by 10.210.6.21 with SMTP id 21mr5269949ebf.58.1254855708119; Tue, 06 Oct 2009 12:01:48 -0700 (PDT) In-Reply-To: References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> Date: Tue, 6 Oct 2009 20:01:48 +0100 Message-ID: From: Morgaine To: Joshua Bell Content-Type: multipart/alternative; boundary=000e0cdf7632ba152b047548dc45 Cc: ogpx@ietf.org Subject: Re: [ogpx] Virtual worlds versus the real world X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 19:00:25 -0000 --000e0cdf7632ba152b047548dc45 Content-Type: text/plain; charset=ISO-8859-1 Bringing up non-VWRAP virtual worlds here only to reject them is just a straw man that is occasionally trotted out for no reason that I can identity, and it derails discussions. Nobody in this group discusses any virtual worlds except those which are compatible with the VWRAP model and VWRAP service endpoints, except possibly a newcomer who might need to be brought up to speed. In that case then of course we help them out. At other times it amounts to a tactic for dismissing an argument, and I'm going to make sure that I draw attention to it if it seems to be done on purpose. Morgaine, ========================================= On Tue, Oct 6, 2009 at 6:32 PM, Joshua Bell wrote: > On Tue, Oct 6, 2009 at 9:29 AM, Morgaine wrote: > >> On Tue, Oct 6, 2009 at 6:17 AM, Infinity Linden (Meadhbh Hamrick) < >> infinity@lindenlab.com> wrote: >> >> this is definitely cool stuff, but fwiw, i disagree that the purpos of >>> this working group is to work on interop between virtual worlds. >>> >> > (snip) > > >> Consequently, we most certainly *are* working on interop between virtual >> worlds, VWRAP-compatible ones naturally. >> > > FWIW, I read Meadhbh's comment as "...between different VW > technologies/types (as defined by protocol implementation)", so I don't see > a disagreement between these statements. > > The distinction is between (1) attempting to define broad interop between > all possible VWs (so I can TP from SL to Webkins and visit my son's > creature) , and (2) defining basic operation of Agent/Region-style VWs with > a protocol that therefore enables interop between conforming > implementations. > > Anyone want to take on the task of collecting all of the definitions of > "virtual world" that have been floated about, as an informational draft? > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --000e0cdf7632ba152b047548dc45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bringing up non-VWRAP virtual worlds here only to reject them is just a str= aw man that is occasionally trotted out for no reason that I can identity, = and it derails discussions.

Nobody in this group discusses any virtu= al worlds except those which are compatible with the VWRAP model and VWRAP = service endpoints, except possibly a newcomer who might need to be brought = up to speed.=A0 In that case then of course we help them out.

At other times it amounts to a tactic for dismissing an argument, and I= 'm going to make sure that I draw attention to it if it seems to be don= e on purpose.

=A0
Morgaine,



=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

On Tue, Oct 6, 2009 at 6:32 PM, Joshua Bell = <josh@lindenlab.= com> wrote:
On Tue, Oct 6, 2009 at 9:29 AM= , Morgaine <morgaine.dinova@googlemail.com> wro= te:
On Tue, Oct 6, 2009 at 6:17 AM, Infinity Linden (Meadhbh Hamrick) <in= finity@lindenlab.com> wrote:

this is definitely cool stuff, but fwiw, i disagree that the purpos of this= working group is to work on interop between virtual worlds.
=A0
(snip)


Consequently, we most certainly are working on interop betw= een virtual worlds, VWRAP-compatible ones naturally.=A0
=

FWIW, I read Meadhbh's comment as "...between diff= erent VW technologies/types (as defined by protocol implementation)", = so I don't see a disagreement between these statements.

The distinction is between (1) attempting to define broad interop betwe= en all possible VWs (so I can TP from SL to Webkins and visit my son's = creature) , and (2) defining basic operation of Agent/Region-style VWs with= a protocol that therefore enables interop between conforming implementatio= ns.

Anyone want to take on the task of collecting all of the definitions of= "virtual world" that have been floated about, as an informationa= l draft?

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--000e0cdf7632ba152b047548dc45-- From vaughn.deluca@gmail.com Tue Oct 6 13:04:15 2009 Return-Path: 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 8A3133A6907 for ; Tue, 6 Oct 2009 13:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 gU5J-3yWK0Tv for ; Tue, 6 Oct 2009 13:04:14 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id D9A6F3A69FA for ; Tue, 6 Oct 2009 13:04:10 -0700 (PDT) Received: by fxm28 with SMTP id 28so3794261fxm.42 for ; Tue, 06 Oct 2009 13:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=+Ex2KUbzPrr9H3VRDliJLJ8koPNvyvzcpD7AKBLy8JE=; b=nnBkHztoJeLcOZ+FUpo1U7wlu7/Q7SmZqtFadGJxorq/6cUrxfzohBdaDKyLvgqmPx h2zukTko50k41V90Fk2HVdyWj0v7Ar0C4QJyeNfG72qi0MiMX1iQ0oqWUeWkRMHaVaSp w0L+Gz3OdY/gUEUOHMmtrW8yhB2mzKGtGQXT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=wvos9fSFiJTZYfG0xBuRONHByYsqnkmVjt1o++mQs6kR9YE5l1ARtfoRxjA0f7o6d5 xoi5iWyVWOYZTbf4b2/SnsFDpOs6GQImi/KfXPqmEMVlm4wgBh780U8HRvOffAFaQ+XM nljemCHT6beAX7NHtAn0t6B0PFGR/v4L9Vbeo= MIME-Version: 1.0 Received: by 10.204.175.80 with SMTP id w16mr5233884bkz.207.1254859544353; Tue, 06 Oct 2009 13:05:44 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> Date: Tue, 6 Oct 2009 22:05:44 +0200 Message-ID: <9b8a8de40910061305w56dc2b01qab60b7b7aaffa337@mail.gmail.com> From: Vaughn Deluca To: "ogpx@ietf.org" Content-Type: multipart/alternative; boundary=00032555b93a6260f0047549c1e0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 20:04:15 -0000 --00032555b93a6260f0047549c1e0 Content-Type: text/plain; charset=ISO-8859-1 Maybe this will help also: Anything we have said so far on policy in this discussion relates to protocol *options* someone *might* use. None of this will be REQUIRED. The protocol will function without using any of it. So really, as far as i can see we *can* move on. --Vaughn --00032555b93a6260f0047549c1e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0Maybe this will help also: Anything we have said so far on policy in thi= s discussion relates to protocol *options* =A0someone *might* use. None of = this will be REQUIRED. The protocol will function without using any of it. = =A0So really, as far as i can see we *can* move on.

--Vaughn

--00032555b93a6260f0047549c1e0-- From josh@lindenlab.com Tue Oct 6 13:04:53 2009 Return-Path: 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 2EB473A6960 for ; Tue, 6 Oct 2009 13:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.681 X-Spam-Level: X-Spam-Status: No, score=-1.681 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 PhPB2QWaOn-4 for ; Tue, 6 Oct 2009 13:04:52 -0700 (PDT) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 626B33A68FF for ; Tue, 6 Oct 2009 13:04:52 -0700 (PDT) Received: by pzk35 with SMTP id 35so2544383pzk.29 for ; Tue, 06 Oct 2009 13:06:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.36.13 with SMTP id o13mr299596rvj.188.1254859587686; Tue, 06 Oct 2009 13:06:27 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A156D0E@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156D0E@GVW0433EXB.americas.hpqcorp.net> Date: Tue, 6 Oct 2009 13:06:27 -0700 Message-ID: From: Joshua Bell To: "ogpx@ietf.org" Content-Type: multipart/alternative; boundary=000e0cd22caaf793a8047549c358 Subject: Re: [ogpx] Reference material X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 20:04:53 -0000 --000e0cd22caaf793a8047549c358 Content-Type: text/plain; charset=UTF-8 I made the trac/wiki updates in response to Mike's inquiry; your searching skills are not at fault! Suggestions for other updates to the wiki are welcome. I cribbed the top content to include from some other WGs. On Tue, Oct 6, 2009 at 11:57 AM, Dickson, Mike (ISS Software) < mike.dickson@hp.com> wrote: > were you looking at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ ? i > > know josh said that he's in the process of putting some content up > > there. > > > > -cheers > > -meadhbh > > -- > > > > Yep. I did find the charter just now as well so it should be easier for > others to find these references. I don't recall seeing it before but I'm > sure I just missed it. Now for some reading.... > > > > Mike > > > > > --000e0cd22caaf793a8047549c358 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I made the trac/wiki updates in response to Mike's inquiry; your search= ing skills are not at fault!

Suggestions for other updates to the wi= ki are welcome. I cribbed the top content to include from some other WGs.
On Tue, Oct 6, 2009 at 11:57 AM, Dickson, Mi= ke (ISS Software) <mike.dickson@hp.com> wrote:

were you looking at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ ? i

know josh said that he's in the process of putting some content up

there.

=C2=A0

-cheers

-meadhbh

--

=C2=A0

Yep.=C2=A0 I did find the charter just now as well so it should be easier for others to find these references.=C2=A0 I don't rec= all seeing it before but I'm sure I just missed it.=C2=A0=C2=A0=C2=A0 Now for some re= ading....

=C2=A0

Mike

=C2=A0

=C2=A0


--000e0cd22caaf793a8047549c358-- From dwl@us.ibm.com Tue Oct 6 14:43:41 2009 Return-Path: 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 D5E993A6A10; Tue, 6 Oct 2009 14:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.98 X-Spam-Level: X-Spam-Status: No, score=-4.98 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, 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 6t3rFagqgrZD; Tue, 6 Oct 2009 14:43:40 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id C41EA3A69BD; Tue, 6 Oct 2009 14:43:39 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n96Lc8gK025580; Tue, 6 Oct 2009 17:38:08 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n96LjAMj242794; Tue, 6 Oct 2009 17:45:10 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n96LjAJd015764; Tue, 6 Oct 2009 17:45:10 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n96LjAIB015753; Tue, 6 Oct 2009 17:45:10 -0400 In-Reply-To: References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156D0E@GVW0433EXB.americas.hpqcorp.net> To: Joshua Bell MIME-Version: 1.0 X-KeepSent: C69C61CF:F2BCE649-85257647:00774F20; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Tue, 6 Oct 2009 17:45:09 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/06/2009 17:45:09, Serialize complete at 10/06/2009 17:45:09 Content-Type: multipart/alternative; boundary="=_alternative 00777DDC85257647_=" Cc: ogpx-bounces@ietf.org, "ogpx@ietf.org" Subject: [ogpx] (no subject) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 21:43:42 -0000 This is a multipart message in MIME format. --=_alternative 00777DDC85257647_= Content-Type: text/plain; charset="US-ASCII" >From this mornings AWGroupies discussion, I want to try and pin down some terminology: I've been saying "Policy happens at services." I think I need to make this more precise, so: The current model grounds out in Web Services and streams of "events" (Notionally delivered in UDP or over an event queue in the current discussions) So.. From the bottom up: Web Services End point (URI + the LLIDL (encoded on LLSD, Binary, or JSON) which defines a web service capability A set of "events" which are notionally short, asynchronous and delivered quickly.. (How much, content flows in this form is at yet unclear) Web service endpoints cluster into set of services, which describe the bulk of the functionality in the specifications. (Loosely, this tends to be the Authentication Services, Region Service, Inventory services, Asset Services and IM services) There is nothing in this model which dictates how to implement or deploy these services behind the defined interfaces Laid over this lose description we have had the notion of "domains" in particular, the Agent and Region domains. The current (somewhat backlevel) intro document says: The Open Grid Protocol assumes a division between systems offering user / avatar oriented services and systems offering virtual world simulation services. OGP was designed to support the case where the administrative authority for agent services is distinct from the authority providing simulation and object persistence services. The administrative authority of the former group is termed the "agent domain" while the latter is termed the "region domain." The protocol allows the agent domain and region domain to be distinct; in other words, a user's identity may be managed by one person or organization while the virtual world they inhabit may be simulated by hosts owned by a completely different organization. Over the past few weeks, there has been a lot of discussion about the possible deployment patterns people will support, and the last definition of the split I have seen on the lists seems to be that if it holds the Authentication and Agent ID services its an agent domain, and if it holds the Virtual Presence services its a region domain. This seems quite reasonable. There is also the notion, that domains represent administrative spans of control, and that services within a domain share policy. At the same time.. actual policy is mediated by service end points. This is to say the moment we can actually apply policy is when a remote service requests a capability, or invokes a capability or (possibly) delivers an event or message to us on an asynchronous connection. I see two or possibly three bits of confusion here. I'm going to start with the basic one, which has come up over the past week. People keep saying "Region Domain Decides" or "Agent Domain Decides" or "The service consults the Agent Domain" I think this muddies stuff because it promotes the domain to an active element, when the real behavior is "A service endpoint is called, possibly with some special tokens, possibly, with a negotiation ensuing and the service endpoint acts according to its policy." Now, the service endpoint may well reside inside an administrative domain, and may have its policy dictated by its deployer. But without an active element, I don't think the domain "participates" The second thing which concerns me is that we're sort of conflating two useful ideas here. One, the split between authenticator and holders of agents, and virtual spaces, and the other, a pattern of common use in deploying services. I think this becomes increasingly strained, as you look at regions interacting with multiple services, and with services which fall outside of the agent/region split, and yet belong to one or more administrative domains. So.. I am not suggesting we throw away these concepts, I am suggesting that we look carefully at how we are tossing the word around, whether we are overloading it, and whether we could better serve our developing a shared understanding by being more rigorous, and more careful about how we attack some of these concepts - David Levine ~ Zha Ewry --=_alternative 00777DDC85257647_= Content-Type: text/html; charset="US-ASCII"
From this mornings AWGroupies discussion, I want to try and pin down
some terminology:

I've been saying "Policy happens at services." I think I need to make
this more precise, so:

The current model grounds out in Web Services and streams of "events"
(Notionally delivered in UDP or over an event queue in the current
discussions) So.. From the bottom up:

Web Services End point (URI + the LLIDL (encoded on LLSD, Binary, or
JSON) which defines a web service capability A set of "events" which
are notionally short, asynchronous and delivered quickly.. (How much,
content flows in this form is at yet unclear)

Web service endpoints cluster into set of services, which describe the
bulk of the functionality in the specifications. (Loosely, this tends
to be the Authentication Services, Region Service, Inventory services,
Asset Services and IM services) There is nothing in this model which
dictates how to implement or deploy these services behind the defined
interfaces

Laid over this lose description we have had the notion of "domains" in
particular, the Agent and Region domains. The current (somewhat
backlevel) intro document says:

   The Open Grid Protocol assumes a division between systems offering
   user / avatar oriented services and systems offering virtual world
   simulation services.  OGP was designed to support the case where the
   administrative authority for agent services is distinct from the
   authority providing simulation and object persistence services.  The
   administrative authority of the former group is termed the "agent
   domain" while the latter is termed the "region domain."  The protocol
   allows the agent domain and region domain to be distinct; in other
   words, a user's identity may be managed by one person or organization
   while the virtual world they inhabit may be simulated by hosts owned
   by a completely different organization.

Over the past few weeks, there has been a lot of discussion about the
possible deployment patterns people will support, and the last
definition of the split I have seen on the lists seems to be

that if it holds the Authentication and Agent ID services its an agent
domain, and if it holds the Virtual Presence services its a region
domain. This seems quite reasonable.

There is also the notion, that domains represent administrative
spans of control, and that services within a domain share policy.

At the same time.. actual policy is mediated by service end
points. This is to say the moment we can actually apply policy is
when a remote service requests a capability, or invokes a capability
or (possibly) delivers an event or message to us on an asynchronous
connection.

I see two or possibly three bits of confusion here. I'm going to start
with the basic one, which has come up over the past week.

People keep saying "Region Domain Decides" or "Agent Domain Decides"
or "The service consults the Agent Domain" I think this muddies stuff
because it promotes the domain to an active element, when the real
behavior is "A service endpoint is called, possibly with some special tokens,
possibly, with a negotiation ensuing and the service endpoint acts
according to its policy."

Now, the service endpoint may well reside inside an administrative
domain, and may have its policy dictated by its deployer. But without
an active element, I don't think the domain "participates"

The second thing which concerns me is that we're sort of conflating
two useful ideas here. One, the split between authenticator and
holders of agents, and virtual spaces, and the other, a pattern of
common use in deploying services. I think this becomes increasingly
strained, as you look at regions interacting with multiple services,
and with services which fall outside of the agent/region split, and
yet belong to one or more administrative domains.

So.. I am not suggesting we throw away these concepts, I am suggesting
that we look carefully at how we are tossing the word around, whether
we are overloading it, and whether we could better serve our
developing a shared understanding by being more rigorous, and more
careful about how we attack some of these concepts

- David Levine
~ Zha Ewry
--=_alternative 00777DDC85257647_=-- From morgaine.dinova@googlemail.com Wed Oct 7 02:05:27 2009 Return-Path: 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 7C9C728C100 for ; Wed, 7 Oct 2009 02:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 HfqFcJDFfOLM for ; Wed, 7 Oct 2009 02:05:25 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 30BDB28C0F9 for ; Wed, 7 Oct 2009 02:05:25 -0700 (PDT) Received: by ewy10 with SMTP id 10so5122892ewy.9 for ; Wed, 07 Oct 2009 02:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=G9NaF797NtomVejmiqmQiocxXdYEDJuy6pOxmLishRg=; b=gy8ai016H6/C1PTnFNP66gO0+JMXgJwzUsqpEL5PGrL+8iVxWrg0QMq9E/HDuaWanW tXgerSI/m4bo7VaVH/eM/nazSggSsfGvwEJkVgYl7OiTFDs0V8XHVdcwwnoNTXZSxrhX mIQywvvXbH3SqjIrEILBoUobhuf/ouWcOott8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=q1MHsPBrncHOC81h0zL4khFoS2IPlOi3bkJNn7eperquMwVmf+nsRORsLJP9h2FuZv P0khPX0GTINIFpx/K5ljIZCTl0B3Zj6DqhHTYI2krS/7Lqm8WZL6dLCu1G4zj9oFDbKx fOeOpIHfUq9vdne4wkevHGBR1qvZJQ/mGgb9k= MIME-Version: 1.0 Received: by 10.211.158.11 with SMTP id k11mr2831017ebo.63.1254906420234; Wed, 07 Oct 2009 02:07:00 -0700 (PDT) In-Reply-To: <6c9fcc2a0910051640k48499f0bs4b3bd5d1de88f3ae@mail.gmail.com> References: <6c9fcc2a0910051640k48499f0bs4b3bd5d1de88f3ae@mail.gmail.com> Date: Wed, 7 Oct 2009 10:07:00 +0100 Message-ID: From: Morgaine To: barryleiba@computer.org Content-Type: multipart/alternative; boundary=00504502d514678b4e047554abdc Cc: ogpx Subject: Re: [ogpx] An administrative note about mailing-list participation X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 09:05:27 -0000 --00504502d514678b4e047554abdc Content-Type: text/plain; charset=ISO-8859-1 Hi Barry! :-) Thanks for a very comprehensive summary of the rules, and a reminder in case we forgot them from earlier. :-) I was particularly interested in the reference to pseudonyms, as this affects many of us here, including myself. With regards to "Note Well" and the Tao and numerous other IETF documents about procedure and IPR and best current practices (not forgetting the Mission Statement), I assembled a shortlist of the most applicable introductory IETF documents I could find during the runup to the MMOX BoF, and much of this material still applies to OGPX / VWRAP. While only a personal selection, it's here in case anyone new to our group wants a fast track to relevant documents, within the MMOX links page at https://wiki.secondlife.com/wiki/MMOX#IETF_Information . This is supplemental to our official IETF wiki page at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ , although the latter will hopefully grow to include additional material. (MMOX itself may still bloom as well, as VWRAP has a much narrower scope. Both Opensim and realXtend have interop features that are not inherited from OGP and which are being developed further as we speak, and Croquet and DarkStar/Wonderland are frequently discussed in our in-world SL interop group, so who knows what the future might hold.) Back on your subject of pseudonyms which was strongly relevant to participants such as myself, I wish to take this opportunity to declare that I know and acknowledge and comply fully with the "Note Well" and Tao and Mission Statement as well as everything else that you have mentioned. I regard the undersigned as my professional working name for everything related to virtual worlds, and it is the only name which I have used or will use in this workgroup, so no ambiguity can occur. Having had this name registered and highly active and contactable in Second Life since August of 2004 also reinforces this. Finally, I take particular note of and embrace your sentence about providing information in good faith, which I consider part of being a professional. While at this time I do not have any desire to write an IETF draft as I trust that existing authors will incorporate our requested modifications in new versions when there is rough consensus for change, in principle this could happen one day, and then we'll have to see how, or if, your contact requirements can be satisfied. It was very interesting to hear you explain that we are to some extent breaking new IETF ground in this area. :-) With regards to IPR, the situation is extremely simple for me since I do not own any IPR and hence have none to declare. Also, I am not party to any company's IPR either, having worked freelance for the better part of two decades and had no exposure to any relevant encumbered technologies. This probably is as clean an IPR slate as one can have on this front. Being strongly pro-Free/Open Source Software, I would of course want it no other way. If you have any further suggestions for those of us wishing to work pseudonymously but very professionally in this way towards IETF goals, I would be delighted to hear them. :-) Best regards, Morgaine Dinova. =========================================== On Tue, Oct 6, 2009 at 12:40 AM, Barry Leiba < barryleiba.mailing.lists@gmail.com> wrote: > First, let me say that this isn't written to anyone in particular, nor > with respect to any discussion thread in particular, nor in response > to any existing problem. The working group chairs (Barry Leiba and > Joshua Bell) and the Area Director (Alexey Melnikov) simply think that > it's a good idea to make this all clear. Most of what I say here will > be obvious, but there are some IETF-process-related points. > > There have always been participants in the IETF who choose not to be > identified by traditional "full names", preferring to use nicknames, > initials, or even email address alone. The IETF has welcomed such > participants, and continues to do so. Yet, the VWRAP working group > presents a situation unique in the IETF's experience with respect to > the culture of pseudonyms and other alternative names used by its > participants in other venues. > > Anyone who participates in any IETF discussions, including here on the > mailing list, agrees, by that participation, to the "Note Well" terms > [ http://www.ietf.org/about/note-well.html ]. That means, in part, > that they're responsible for disclosing intellectual property rights > (IPR) of which they're aware. Please be sure you understand that > point, and see the relevant RFCs (the "Note Well" notice has > pointers). Clearly, if you have IPR to disclose there's going to have > to be some real-world identification involved, which will include the > real identity of the owner of the IPR. > > Anyone who is a document author or editor must be contactable. We > normally ask for name, affiliation, address, phone number, and email > address for that, but not all of it is always provided, and we can > work around some of that. The bottom line here is that what the > authors provide must be given in good faith, and anyone reading the > documents must be able to contact the authors. > > For other participants, identification doesn't matter, apart from your > agreement to abide by the Note Well terms. As I said above, this has > always been the case, even without virtual worlds. We ENCOURAGE > everyone to use full, real-world names and, when reasonable, to > disclose affiliations. What we REQUIRE is that participants either > use a single, consistent identity or make it clear what set of > identities they're using. If Joe Slobotnik, Shaquila Yazenzatta, and > the Lone Haranguer all post to the mailing list, there should never be > any question of whether or not they represent the same human > participant. Misrepresentation along these lines might be cause for > administrative action. > > It will also help if participants are familiar with the IETF Working > Group Guidelines and Procedures (BCP 25), RFC 2418. The best > introduction to the IETF, for those of you who are new, is Paul > Hoffman's excellent document "The Tao of IETF": > http://www.ietf.org/tao.html . Questions about the IETF or its > process are welcome, either on the list or in private email. If you > ask on the list, please use a new subject to create a new thread, so > your question doesn't get lost in the middle of some other discussion. > > Finally, note that you can contact the chairs and the Area Directors > for any working group through the tools aliases WGNAME-chairs and > WGNAME-ads. For this working group, those addresses are > and . > > Barry (and Joshua), VWRAP working group chair(s) > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --00504502d514678b4e047554abdc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Barry! :-)

Thanks for a very comprehensive summary of the rules, = and a reminder in case we forgot them from earlier. :-)=A0 I was particular= ly interested in the reference to pseudonyms, as this affects many of us he= re, including myself.

With regards to "Note Well" and the Tao and numerous other IE= TF documents about procedure and IPR and best current practices (not forget= ting the Mission Statement), I assembled a shortlist of the most applicable= introductory IETF documents I could find during the runup to the MMOX BoF,= and much of this material still applies to OGPX / VWRAP.=A0 While only a p= ersonal selection, it's here in case anyone new to our group wants a fa= st track to relevant documents, within the MMOX links page at htt= ps://wiki.secondlife.com/wiki/MMOX#IETF_Information .=A0 This is supple= mental to our official IETF wiki page at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/= , although the latter will hopefully grow to include additional material.<= br>
(MMOX itself may still bloom as well, as VWRAP has a much narrower scop= e.=A0 Both Opensim and realXtend have interop features that are not inherit= ed from OGP and which are being developed further as we speak, and Croquet = and DarkStar/Wonderland are frequently discussed in our in-world SL interop= group, so who knows what the future might hold.)

Back on your subject of pseudonyms which was strongly relevant to parti= cipants such as myself, I wish to take this opportunity to declare that I k= now and acknowledge and comply fully with the "Note Well" and Tao= and Mission Statement as well as everything else that you have mentioned.= =A0 I regard the undersigned as my professional working name for everything= related to virtual worlds, and it is the only name which I have used or wi= ll use in this workgroup, so no ambiguity can occur.=A0 Having had this nam= e registered and highly active and contactable in Second Life since August = of 2004 also reinforces this. =A0 Finally, I take particular note of and em= brace your sentence about providing information in good faith, which I consider part of being a professional.

While at this time I do not have any desire to write a= n IETF draft as I trust that existing authors will incorporate our requeste= d modifications in new versions when there is rough consensus for change, i= n principle this could happen one day, and then we'll have to see how, = or if, your contact requirements can be satisfied.=A0 It was very interesti= ng to hear you explain that we are to some extent breaking new IETF ground = in this area. :-)

With regards to IPR, the situation is extremely simple for me since I d= o not own any IPR and hence have none to declare.=A0 Also, I am not party t= o any company's IPR either, having worked freelance for the better part= of two decades and had no exposure to any relevant encumbered technologies= .=A0 This probably is as clean an IPR slate as one can have on this front.= =A0 Being strongly pro-Free/Open Source Software, I would of course want it= no other way.

If you have any further suggestions for those of us wishing to work pse= udonymously but very professionally in this way towards IETF goals, I would= be delighted to hear them. :-)

Best regards,


Morgaine Di= nova.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Tue, Oct 6, 2009 at 12:40 AM, Barry Leiba <barryleiba.mailing.lists@gmail.com> wrote:
First, let me say= that this isn't written to anyone in particular, nor
with respect to any discussion thread in particular, nor in response
to any existing problem. =A0The working group chairs (Barry Leiba and
Joshua Bell) and the Area Director (Alexey Melnikov) simply think that
it's a good idea to make this all clear. =A0Most of what I say here wil= l
be obvious, but there are some IETF-process-related points.

There have always been participants in the IETF who choose not to be
identified by traditional "full names", preferring to use nicknam= es,
initials, or even email address alone. =A0The IETF has welcomed such
participants, and continues to do so. =A0Yet, the VWRAP working group
presents a situation unique in the IETF's experience with respect to the culture of pseudonyms and other alternative names used by its
participants in other venues.

Anyone who participates in any IETF discussions, including here on the
mailing list, agrees, by that participation, to the "Note Well" t= erms
[ ht= tp://www.ietf.org/about/note-well.html ]. =A0That means, in part,
that they're responsible for disclosing intellectual property rights (IPR) of which they're aware. =A0Please be sure you understand that
point, and see the relevant RFCs (the "Note Well" notice has
pointers). =A0Clearly, if you have IPR to disclose there's going to hav= e
to be some real-world identification involved, which will include the
real identity of the owner of the IPR.

Anyone who is a document author or editor must be contactable. =A0We
normally ask for name, affiliation, address, phone number, and email
address for that, but not all of it is always provided, and we can
work around some of that. =A0The bottom line here is that what the
authors provide must be given in good faith, and anyone reading the
documents must be able to contact the authors.

For other participants, identification doesn't matter, apart from your<= br> agreement to abide by the Note Well terms. =A0As I said above, this has
always been the case, even without virtual worlds. =A0We ENCOURAGE
everyone to use full, real-world names and, when reasonable, to
disclose affiliations. =A0What we REQUIRE is that participants either
use a single, consistent identity or make it clear what set of
identities they're using. =A0If Joe Slobotnik, Shaquila Yazenzatta, and=
the Lone Haranguer all post to the mailing list, there should never be
any question of whether or not they represent the same human
participant. =A0Misrepresentation along these lines might be cause for
administrative action.

It will also help if participants are familiar with the IETF Working
Group Guidelines and Procedures (BCP 25), RFC 2418. =A0The best
introduction to the IETF, for those of you who are new, is Paul
Hoffman's excellent document "The Tao of IETF":
http://www.ietf.= org/tao.html . =A0Questions about the IETF or its
process are welcome, either on the list or in private email. =A0If you
ask on the list, please use a new subject to create a new thread, so
your question doesn't get lost in the middle of some other discussion.<= br>
Finally, note that you can contact the chairs and the Area Directors
for any working group through the tools aliases WGNAME-chairs and
WGNAME-ads. =A0For this working group, those addresses are
<vwrap-= chairs@tools.ietf.org> and <vwrap-ads@tools.ietf.org>.

Barry (and Joshua), VWRAP working group chair(s)
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--00504502d514678b4e047554abdc-- From carlo@alinoe.com Wed Oct 7 02:21:58 2009 Return-Path: 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 5EC5128C130 for ; Wed, 7 Oct 2009 02:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.281 X-Spam-Level: X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_20=-0.74, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 egV2JoSSLy7o for ; Wed, 7 Oct 2009 02:21:57 -0700 (PDT) Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id 2B57028C0EE for ; Wed, 7 Oct 2009 02:21:56 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091007092334.SSHX422.viefep16-int.chello.at@edge05.upc.biz>; Wed, 7 Oct 2009 11:23:34 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id plPY1c08m0FlQed05lPZf7; Wed, 07 Oct 2009 11:23:34 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MvSlQ-0002Dv-P7; Wed, 07 Oct 2009 11:24:52 +0200 Date: Wed, 7 Oct 2009 11:24:52 +0200 From: Carlo Wood To: Vaughn Deluca Message-ID: <20091007092452.GA8261@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <9b8a8de40910061305w56dc2b01qab60b7b7aaffa337@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b8a8de40910061305w56dc2b01qab60b7b7aaffa337@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 09:21:58 -0000 It still matters whether or not it's possible to query the AD about things the RD might want to deny someone access over or not (IP, email address, age). If that is not possible, than in PRACTISE I forsee that there will be much less cooperation, and thus interop, between AD's and RD's of different administrations. For example, in order to be able to ban people by email address, each RD might choose to run their own AD and not accept third party AD's. Sending an email, requesting a ban by email address, won't work, of cours :/ Too slow, no response... certainly not if the RD is small and considered insignificant and the AD has a monopoly and serves large grids. Therefore I think the protocol must support real-time a few important datas about users, so that the RD can make a decision, quickly and without human intervention from the AD. On Tue, Oct 06, 2009 at 10:05:44PM +0200, Vaughn Deluca wrote: > Maybe this will help also: Anything we have said so far on policy in this > discussion relates to protocol *options* someone *might* use. None of this > will be REQUIRED. The protocol will function without using any of it. So > really, as far as i can see we *can* move on. > > --Vaughn > -- Carlo Wood From vaughn.deluca@gmail.com Wed Oct 7 11:10:49 2009 Return-Path: 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 CDFB13A684F for ; Wed, 7 Oct 2009 11:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_40=-0.185, HTML_MESSAGE=0.001] 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 hH6pqpF-Anxb for ; Wed, 7 Oct 2009 11:10:48 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id 71E7D3A685D for ; Wed, 7 Oct 2009 11:10:45 -0700 (PDT) Received: by fxm28 with SMTP id 28so4610310fxm.42 for ; Wed, 07 Oct 2009 11:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Yu62BEH++IU0J6T/3P3t1HpSo/wxUyzcM45pGK+nvz8=; b=M6HzG0No1TXFh80ZOFaiaFjjYJPVvMzjIQjzmt4yjZNr6NRiWnwLCh+uka0WnKAiUu uanLZWQgnyfLM9uaXi7YSfJqsxXpALUu88oPClZG9SIGCdiNdsI04wKbyurXnYD1P3vv Ljz/FjR4dFodKaUImX6wMtirhw7J13Dxx2Too= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=n2q/BD+xSLaPotgCfgvEAKAAMVmW/DfNxLN6EpjqoUb7qPHvFff4KEFskulosTOc0M +6G441Ebe6vRViAHQxUnEUPPQe7kfjxSghNOboi2GjXzdoPkr0l6L0vSnrIZtb9vRBKr r8szoYwWTgCEFmGPwvdfURqg+ePbfhP3RRZWw= MIME-Version: 1.0 Received: by 10.204.15.24 with SMTP id i24mr189129bka.2.1254939140360; Wed, 07 Oct 2009 11:12:20 -0700 (PDT) In-Reply-To: <9b8a8de40910061305w56dc2b01qab60b7b7aaffa337@mail.gmail.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <9b8a8de40910061305w56dc2b01qab60b7b7aaffa337@mail.gmail.com> Date: Wed, 7 Oct 2009 20:12:19 +0200 Message-ID: <9b8a8de40910071112j600dea3fge21a35ffc0341e52@mail.gmail.com> From: Vaughn Deluca To: "ogpx@ietf.org" Content-Type: multipart/alternative; boundary=00032555af0ead086504755c494d 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 18:10:49 -0000 --00032555af0ead086504755c494d Content-Type: text/plain; charset=ISO-8859-1 Although I actually think enough has been said on policy, I want to expand my last message a bit to make it even more clear how i view this problem. In wrote: "Anything we have said so far on policy in this discussion relates to protocol *options* someone *might* use. None of this will be REQUIRED. The protocol will function without using any of it. So really, as far as i can see we *can* move on." Here is a longer version of the same message: We are talking policy, and by definition, everybody is free to ignore policy, and live with the consequences. If I run a some services in a RD, its my choice what policy i set to determine what is allowed in there. Yet, a visiting agent is under *its* ADs policy if I like that or not. Its the agents choice to be in that AD. If the policy of that AD is allowing, or even encouraging, the use of deadly weapons, while I like my regions to be free of violence. I can ignore the policy of the agents AD. I am free to do so, and apply a policy of "ban on the first sight of a gun", after all I run this service. Ignoring the policy of the AD may carry the consequence of spoiling my relations with that AD, since they strongly belief in the freedom to carry weapons, and this may prompt them to prevent any TP to my RD. Yet that is about all thats in the power of the AD, unless it has some legal hooks in my service via a real world contract with me. A more realistic example could be that it is the policy of the AD --or rather some associated asset service *winks to Zha* -- to only let go of purple clothes under strict conditions. I have struck a deal with that service, promising to follow the rules for purple cloths. Its my choice to live by that promise, or -at my peril- ignore it. So to answer one of Carlo's older questions, yes, from the perspective of the region service, the Asset service policy *can* be forgotten and ignored, but most likely I will prefer not to do so, or I would not have made the deal in the first place. While all this is very interesting, its *outside* of the scope of the protocol. Policy can be ignored, or followed, and its up to those setting the policies to enforce them, by whatever means they have at their disposal, but it has nothing to do with the protocol as such. Infinity is eager to move on, and I fully agree with her. I suddenly realised that the source of much of our problems might be that few people have made it clear that *whatever* method we pick to carry policy related information, the use of that information will *always* be optional, and never REQUIRED by protocol. I do not think there is a single person on the list that will disagree with this, and the chances of getting anything else than this past the IETF are in my view remote. [I am new to protocol discussions, but there surly must be precedents for this? We can't possibly be the first group to hit this obstacle?]. We can spend a very long time talking about the way to code the policy related information, and how explicit it is allowed to be; If it should be only payload, or actual part of the control flow; If it may contain actual values, or better only ranges. All of that is however somewhat moot as soon as it is realised that its *optional* to provide and/or use this info. There is not much chance we will gain full or even rough consensus on what is appropriate to put in the meta-information, because it depends fully on deeply personal value systems. One persons nightmare of a totalitarian state is the next persons hope to be free from adult material or unrestrained violence. The crux is that we realise that the use of anything that will be in the protocol relating to policy is optional. If I don't like that info to be there, I don't supply it, and ignore it if I find it. Nothing will break in protocol terms. We could (and probably should) have some discussion how far we want to go in facilitating certain use-cases by defining explicit fields to make interop easy. Not many will defend a pre-defined field for real-life skin color to allow other services more easy discrimination. But *even* if we had the (in my eyes) bad taste to define such a field or tag to aid some (in my eyes) unacceptable use-case, we are certainly NOT going to REQUIORE its use in the protocol, nor saying it MAY NOT be carried ever, since however wrong we think such a tag might be, it is a matter of policy, and as such outside the scope of the protocol. If we decided in this group that such a tag should be forbidden, and MUST NOT be carried we open the gates for demands that other tags must also be forbidden. And conversely, if we REQUIRE the use of such a tag, we can not prevent others in this discussion to REQUIRE other tags. And everything will end in tears. I think most (no, *all*) of what i just said has been mentioned before on the list in one form or another, and i really do not think there is much more to add that is pertinent to the protocol. I hold some (strong) convictions how meta information should be carried, in particular relating to privacy issues, but non of that is crucial, given that i am never forced to give this information, nor prevented from using it if somebody is sending it. That said, if I as a user don't like the choices made by some service, i SHOULD be able to pick another with in my view better options, or even run one myself. So lets move on, and make that possible! -Vaughn --00032555af0ead086504755c494d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Although I actually think enough has been said on policy, =A0I want to= expand my last message a bit to make it even more clear how i view this pr= oblem.

In wrote:
=A0"Anything we ha= ve said so far on policy in this discussion relates to protocol *options* = =A0someone *might* use. None of this will be REQUIRED. The protocol will fu= nction without using any of it. =A0So really, as far as i can see we *can* = move on."

Here is a longer version of the same message:=A0
<= div>
We are talking policy, and by definition, everybody is f= ree to ignore policy, and live with the consequences. =A0If I run a some se= rvices in a RD, its my choice what =A0policy i set to determine what is all= owed in there. Yet, a visiting agent is under *its* =A0ADs policy if I like= that or not. Its the agents choice to be in that AD.=A0

If the policy of that AD is allowing, or even encouragi= ng, the use of deadly weapons, =A0while I like my regions to be free of vio= lence. I can ignore the policy of the agents AD. I am free to do so, and ap= ply a policy of "ban on the first sight of a gun", after all I ru= n this service. Ignoring the policy of the AD may carry the consequence of = spoiling my relations with that AD, since they strongly belief in the freed= om to carry weapons, and this may prompt them to prevent any TP to my RD. Y= et that is about all thats in the power of the AD, unless it has some legal= hooks in my service via a real world contract with me.=A0

A more realistic example could be that it is the policy= of the AD --or rather =A0some associated asset service *winks to Zha* -- t= o only let go of purple clothes under strict conditions. I have struck a de= al with that service, promising to follow the rules for purple cloths. Its = my choice to live by that promise, or -at my peril- ignore it. So to answer= one of Carlo's older questions, yes, from the perspective of the regio= n service, the Asset service policy *can* be forgotten and ignored, =A0but = most likely I will prefer not to do so, or I would not have made the deal i= n the first place.

While all this is very interesting, its =A0*outside* of= the scope of the protocol.
Policy can be ignored, or followed, a= nd its up to those setting the policies to enforce them, by whatever means = they have at their disposal, but it has nothing to do with the protocol as = such.

Infinity is eager to move on, and I fully agree with he= r. I suddenly realised that the source of much of our problems might be tha= t few people have made it clear that *whatever* method =A0we pick to carry = =A0policy related information, the use of that information =A0will *always*= be optional, and never REQUIRED by protocol.

I do not think there is a single person on the list tha= t will disagree with this, and the chances of getting anything else than th= is past the IETF are in my view remote. [I am new to protocol discussions, = but there surly must be precedents for this? We can't possibly be the f= irst group to hit this obstacle?].=A0

We can spend a very long time talking about the way to = code the policy related information, and how explicit it is allowed to be; = If it should be only payload, or actual part of the control flow; If it may= contain actual values, or better only ranges. All of that is however somew= hat moot as soon as it is realised that its *optional* to provide and/or us= e this info.=A0

There is not much chance we will gain full or even roug= h consensus on what is appropriate to put in the meta-information, because = it depends fully on deeply personal value systems. One persons nightmare of= a totalitarian state is the next persons hope to be free from adult materi= al or unrestrained violence.

The crux is that we realise that the use of anything th= at will be in the protocol relating to policy is optional. If I don't l= ike that info to be there, I don't supply it, and ignore it if I find i= t. Nothing will break in protocol terms.

We could (and probably should) have some discussion how= far we want to go in facilitating certain use-cases by defining explicit f= ields to make interop easy. Not many will defend a pre-defined field for re= al-life skin color to allow other services more easy discrimination. But *e= ven* if we had the (in my eyes) bad taste to define such a field or tag to = aid some (in my eyes) unacceptable use-case, we are certainly NOT going to = REQUIORE its use in the protocol, nor saying it MAY NOT be carried ever, si= nce however wrong we think such a tag might be, it is a matter of policy, a= nd as such outside the scope of the protocol. If we decided in this group t= hat such a tag should be forbidden, and MUST NOT be carried we open the gat= es for demands that other tags must also be forbidden. And conversely, if w= e REQUIRE the use of such a tag, we can not prevent others in this discussi= on to REQUIRE other tags. And everything will end in tears.

I think most (no, *all*) of what i just said =A0has bee= n mentioned before on the list in one form or another, and i really do not = think there is much more to add that is pertinent to the protocol. I hold = =A0some (strong) convictions how meta information should be carried, in par= ticular relating to privacy issues, but non of that is crucial, given that = i am never forced to give this information, nor prevented from using it if = somebody is sending it.=A0
That said, if I as a user don't like the choices made by some serv= ice, i SHOULD be able to pick another with in my view better options, or ev= en run one myself. So lets move on, and make that possible!

-Vaughn



<= br>


--00032555af0ead086504755c494d-- From carlo@alinoe.com Wed Oct 7 13:32:40 2009 Return-Path: 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 D59F73A69A5 for ; Wed, 7 Oct 2009 13:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 fkg8MdblPZ-G for ; Wed, 7 Oct 2009 13:32:40 -0700 (PDT) Received: from viefep12-int.chello.at (viefep12-int.chello.at [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id 9878B3A67FB for ; Wed, 7 Oct 2009 13:32:39 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep12-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091007203416.BVDO4394.viefep12-int.chello.at@edge02.upc.biz>; Wed, 7 Oct 2009 22:34:16 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upc.biz with edge id pwaD1c06u0FlQed02waEnq; Wed, 07 Oct 2009 22:34:16 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MvdEV-0002GJ-8Q; Wed, 07 Oct 2009 22:35:35 +0200 Date: Wed, 7 Oct 2009 22:35:35 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20091007203535.GA13882@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 20:32:40 -0000 On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden wrote: > option 3: multi-message handshake > > AD --------------- (name) -------------> RD > AD <-------- (X, age > X? cap) --------- RD > > AD ------------------------------------> RD (age > X? cap) > AD <------------ (rez cap) ------------- RD Note, again, the need for a flexible protocol negotiation: we can't know, already, what all will be needed. Nevertheless, the more flexibility the better imho. I'd prefer to see this: AD ------(name, ) -----------> RD AD <-----(name, ) --- RD AD ------(name, yes/no)--------------------------> RD AD <-----(rez cap) ------------------------------- RD Where VWRAP will not define what keywords are possible. However, implementers might, for example, choose to use 'AGE' as keyword with an integer range, leading to a msg exchange like AD ------(name, (AGE)) -----------> RD AD <-----(name, (AGE, 21)) -------- RD AD ------(name, yes)--------------> RD AD <-----(rez cap) ---------------- RD or some might implement AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD AD <-----(name, (AGE, 13), YES) ------------------ RD AD ------(name, yes, yes)------------------------> RD AD <-----(rez cap) ------------------------------- RD For privacy reasons, I think it would suffice to just send the AND of all 'yes's, thus: AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD AD <-----(name, (AGE, 13), YES) ------------------ RD AD ------(name, yes)-----------------------------> RD AD <-----(rez cap) ------------------------------- RD or, AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD AD <-----(name, (AGE, 13), DONTCARE) ------------- RD AD ------(name, yes)-----------------------------> RD AD <-----(rez cap) ------------------------------- RD Again, neither 'AGE' nor 'LIKES_BUNNIES', would be defined by us, but we would define how to handle integer ranges, booleans, don't cares, string literals, and perhaps regular expressions. -- Carlo Wood From carlo@alinoe.com Wed Oct 7 13:46:20 2009 Return-Path: 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 3A0C13A6991; Wed, 7 Oct 2009 13:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 b-ob+5wRL3bm; Wed, 7 Oct 2009 13:46:19 -0700 (PDT) Received: from viefep14-int.chello.at (viefep14-int.chello.at [62.179.121.34]) by core3.amsl.com (Postfix) with ESMTP id 9C5CC3A67F3; Wed, 7 Oct 2009 13:46:18 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep14-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091007204758.YFPB20477.viefep14-int.chello.at@edge01.upc.biz>; Wed, 7 Oct 2009 22:47:58 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id pwnv1c06b0FlQed01wnxgX; Wed, 07 Oct 2009 22:47:58 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MvdRl-0002S7-Gm; Wed, 07 Oct 2009 22:49:17 +0200 Date: Wed, 7 Oct 2009 22:49:17 +0200 From: Carlo Wood To: Magnus Zeisig Message-ID: <20091007204917.GB13882@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Infinity Linden , "ogpx-bounces@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 20:46:20 -0000 I think this would require too much detail of 'filtering' parameters to go into the actual protocol. On Tue, Oct 06, 2009 at 12:02:09PM +0200, Magnus Zeisig wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I try to follow the philosophical discussions on this list, but I must admit > I'm probably a too much down to earth tech guy to fully appreciate them. > Therefore, it's possible I miss some of the fine nuances or problems in them. > My basic interest is trying to translate the problems I see into (meta) > protocol. Exact nomenclature and syntax, e.g. "domain" or "service", "access" > or "caps", I prefer leaving to those better called to define it. I hope this > doesn't cause too much confusion. > > My basic suggestion of a handshake protocol permitting policy decisions (http:/ > /www.ietf.org/mail-archive/web/ogpx/current/msg00475.html) could (strictly > technically) handle the debated issues of authentication, "adult content" and > TOSes: > > Agent domain: > request access for > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > > Region domain: > require parameter values for > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > authentication: PASSPORT OR USSSN OR EUID OR JPVER > accept adult content: YES > accept nudity: YES > accept sexual acts: YES > accept profane language: YES > terms of service: ((FRLAWINFO2006:128 AND EULAWIP2008:2) OR USLAWTELECOM2005:1) > AND (VWTOS1.2 OR MVTOS2.3 OR MYTOS1.0) > user signature: TOKEN > > Agent domain: > required parameter values for > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > authentication: yes > accept adult content: yes > accept nudity: yes > accept sexual acts: yes > accept profane language: no > terms of service: yes > user signature: 238158-2356257-238658-23596 > > Region domain: > access denied for > user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org > (outside protocol: since not accepting profane language) > > Using this method, one could decide to let the agent domain manage the > acceptance of "adult content" entirely, by the region domain not asking for age > but let the agent domain automatically set accept for e.g. "adult content", > "nudity", "sexual acts" and "profane language" to NO for those underage and as > options YES/NO for those of age. One could also either ask for acceptance of > "adult content" in general or for more specific parameters often associated > with "adult content", giving great flexibility in policy making. But once > again, that is policy outside protocol level. but what is the mature age is a function of country, and thus region, not agent domain. Adding to the protocol the notion of 'adult', so that the RD can ask the AD 'is this person an adult?' won't work for that reason. Better to ask the AD, 'does the age of the person fall in this range?', and even better to not define 'age' in the protocol, but just describe how the RD can ask for 'does X falls into this range', where the AD first tells the RD that it supports X (see my previous post). > > Best regards, > > Magnus > > - -----Ursprungligt meddelande----- > Från: Infinity Linden [mailto:infinity@lindenlab.com] > Skickat: den 6 oktober 2009 01:39 > Till: David W Levine > Kopia: Magnus Zeisig; ogpx@ietf.org; ogpx-bounces@ietf.org > Ämne: Re: [ogpx] Protocol for permitting policy decisions > > On Mon, Oct 5, 2009 at 1:33 PM, David W Levine wrote: > > > > "In order to have rights beyond "guest" on this region, you, or your > agent domain, on your behalf, needs to have signed the TOS document. I will > demand a digitally signed proof of this, as metadata when you > request acess to my region." > > - David > ~ Zha > > > > > i think i grok what you're trying to say here, but i would also add... "a given > agent domain MAY choose to deny you ANY service (including anonymous or guest > access) if you don't provide some form of authenticator and assert that you > have read and understand the domains terms of use." > > - -cheers > - -meadhbh > > > -----BEGIN PGP SIGNATURE----- > Version: 9.8.3 (Build 4028) > Charset: utf-8 > > wsBVAwUBSssVoe5MlU9XyaiSAQjgswgApysemtDE8npKhTSCUGHMxFnGxsdUvJfs > /4z6Iribd7w2lmD20cx8xUB1/ojV5ABEEArCRdJmWbf5aGHBeF8nrv8cxlFOxWYB > 37cZmEY7zAwbY6XNGB0NIpG2rnZWSW9sGJUOwVs4lW/DJKcDmuqgywtwtl5705u8 > W3G8y06I4sek/oukgGczqBBIG2Zny1qgbP/fr2AsewrHXYfYlMN2HnmzxQR60vry > wJuV+gBe8RVC/ppHH+carOLMTmwZP8jbGnCy3+wUwI5H8+QbUuptdYNnJ8Fw0F/u > yC2IesKerMmIlF0Z2Q93GyzGo02mn4dviLINYZ0M9kNYXhEe3OkypQ== > =S0LC > -----END PGP SIGNATURE----- > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx -- Carlo Wood From meadhbh.siobhan@gmail.com Wed Oct 7 13:56:36 2009 Return-Path: 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 547AF28C0D9 for ; Wed, 7 Oct 2009 13:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599] 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 zMMjGt8ULtza for ; Wed, 7 Oct 2009 13:56:35 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 5AF8428C0F0 for ; Wed, 7 Oct 2009 13:56:35 -0700 (PDT) Received: by pzk4 with SMTP id 4so1662861pzk.32 for ; Wed, 07 Oct 2009 13:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=mflA4enIJ4gPQ3TyFNvDseF5eNKMpsnLLfUc62jGAnk=; b=RxirIBI2oHQVzTA6RolLQCD0JNhnQTQKj3nNu0zoPSpYLslgcyXf6HcTfgVfm8uF/s COo/+jFpquUwmirETSSPbB5OO2+XIwM0pW1lv/1Nc97g0cPsO1m7rDp00xD3KerfRx4v rgiJHxiY3Y6G0T3npOXTR6gDuDbrUw0jbtZKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AT2L7Qam5EO23NGnSUcgfbER5dJay4+0vhtXR2kAr1omjLtgz2Jiu2jlN+gC4fe0vJ BvOJEJRDJb7AA7zgH6yhk7T+P4JTjlTrqTvP6jcuYxgw9tCbmRLwtmdZE2s16p7ZfPsS 3BJSYxNJaGkg4EqayCwrqReskCBKx2yjjqyNA= MIME-Version: 1.0 Received: by 10.115.117.13 with SMTP id u13mr601290wam.150.1254949093452; Wed, 07 Oct 2009 13:58:13 -0700 (PDT) In-Reply-To: <20091007203535.GA13882@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> Date: Wed, 7 Oct 2009 13:58:13 -0700 Message-ID: From: Meadhbh Hamrick To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Cc: Infinity Linden , "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 20:56:36 -0000 hmm.. okay. i like where we're headed here. carlo, what you're recommending is similar enough to the use of a seed capability we could almost call it the same design pattern. i like the idea of the AD tell the RD something like, "hey... here's a list of keywords describing concepts i'm concerned about." then having the RD respond, "oh! you're concerned about , well lemme tell you about ." and then having the AD decide whether or not the RD's values for FOO violate it's policy. however. i'm not entirely certain we (linden) would use it all the time, and here's why. the model we've been proposing is that AD's would negotiate deals with RD providers and specify requirements and policies in excruciating detail in legal documents. we would then use the name (domain name or subject name from the client cert) to lookup what we think the policy would be, and then act on it. but... i still like this scheme because a) it's really similar to the way seed caps work, b) it adds flexibility to our system(s), and c) it does what i was hoping... gives the AD the ability to make policy decisions (like am i going to let this 15 year old user access material that may land me in hot water with the local authorities.) so... what we could do is make the request optional, but the response manditory. this would mean we could still use the deployment model listed above, but the "tourist" model can use the request. (i'm using the term "tourist model" to mean where someone's AD attempts to place an avatar in a region the AD does not have a previous trust relationship with.) On Wed, Oct 7, 2009 at 1:35 PM, Carlo Wood wrote: > On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden wrote: >> option 3: multi-message handshake >> >> AD --------------- (name) -------------> RD >> AD <-------- (X, age > X? cap) --------- RD >> >> AD ------------------------------------> RD (age > X? cap) >> AD <------------ (rez cap) ------------- RD > > Note, again, the need for a flexible protocol negotiation: > we can't know, already, what all will be needed. > > Nevertheless, the more flexibility the better imho. > I'd prefer to see this: > > AD ------(name, ) -----------> RD > AD <-----(name, ) --- RD > AD ------(name, yes/no)--------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > Where VWRAP will not define what keywords are possible. > > However, implementers might, for example, choose to use 'AGE' as keyword > with an integer range, leading to a msg exchange like > > AD ------(name, (AGE)) -----------> RD > AD <-----(name, (AGE, 21)) -------- RD > AD ------(name, yes)--------------> RD > AD <-----(rez cap) ---------------- RD > > or some might implement > > AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD > AD <-----(name, (AGE, 13), YES) ------------------ RD > AD ------(name, yes, yes)------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > For privacy reasons, I think it would suffice to > just send the AND of all 'yes's, thus: > > AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD > AD <-----(name, (AGE, 13), YES) ------------------ RD > AD ------(name, yes)-----------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > or, > > AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD > AD <-----(name, (AGE, 13), DONTCARE) ------------- RD > AD ------(name, yes)-----------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > Again, neither 'AGE' nor 'LIKES_BUNNIES', would be defined by us, > but we would define how to handle integer ranges, booleans, > don't cares, string literals, and perhaps regular expressions. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From meadhbh.siobhan@gmail.com Wed Oct 7 14:06:22 2009 Return-Path: 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 1446228C0F0; Wed, 7 Oct 2009 14:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] 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 vRfENtlTImIi; Wed, 7 Oct 2009 14:06:20 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id BBE763A68D5; Wed, 7 Oct 2009 14:06:20 -0700 (PDT) Received: by pzk4 with SMTP id 4so1670885pzk.32 for ; Wed, 07 Oct 2009 14:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dXzntlwskI4soU8KnGMGzE06kYqfer3YIAGIdbWy0WA=; b=SMHUY5jev4IGxC8gll8iqP98ZpsMRwIyHctPvoLEW5LjCcmabKaWUMGyIZC7vm55gP 1x49T6v6KE3KsG3TjyTekmnR1auObbCGrZbGYY/zeD1q6XHga2yT8UUg87MmFkHXufs2 o/3t7tHcElcVgNdNcsTmwozyoVMMaL/qWryiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SLf3mqUv/ssDlIdyZOndyfm+j8c0Z1IiSkrlmOeIbhmbFRi3cTgq76ZiX7uQm4yyOT 53StmL/y4rCcSAsUsuUFRWJIl2MCuY9iM4+Kp8Bl6+CT6d/YwuXW5bUJQgMNAXUpuh8t RRo9i/ljktSCGjxYk9kAc/Vz+TvoaJVKg+VBk= MIME-Version: 1.0 Received: by 10.115.134.40 with SMTP id l40mr669295wan.41.1254949678624; Wed, 07 Oct 2009 14:07:58 -0700 (PDT) In-Reply-To: <20091007204917.GB13882@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> Date: Wed, 7 Oct 2009 14:07:58 -0700 Message-ID: From: Meadhbh Hamrick To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Infinity Linden , "ogpx-bounces@ietf.org" , "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 21:06:22 -0000 oh. hey. so i was just thinking about the "should we define global keys for region meta-data?" question. i think if we were to move forward with the AD telling the RD what it's concerned about plan, we _should_ have global identifiers. i just think that if everyone had different identifiers for the same concept, you would get protocol interop, but you would still have systems that don't know what each other are talking about. but i totally get the idea implementing age restriction to mature regions would be made difficult by the jurisdiction question. but then i was thinking. what if we defined policies with well known URIs? that way we (linden) could define names for policies like "http://lindenlab.com/vwrap/policy/age" while someone else could create a policy like "http://example.com/p/anglican". anyway. just a though. i'm going to spend a little time trying to understand a couple different country's regulations for online access to adult materials by minors, just to get a sense for where the differences would lie. -cheers -meadhbh On Wed, Oct 7, 2009 at 1:49 PM, Carlo Wood wrote: > I think this would require too much detail of 'filtering' parameters > to go into the actual protocol. > > On Tue, Oct 06, 2009 at 12:02:09PM +0200, Magnus Zeisig wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> I try to follow the philosophical discussions on this list, but I must a= dmit >> I'm probably a too much down to earth tech guy to fully appreciate them. >> Therefore, it's possible I miss some of the fine nuances or problems in = them. >> My basic interest is trying to translate the problems I see into (meta) >> protocol. Exact nomenclature and syntax, e.g. "domain" or "service", "ac= cess" >> or "caps", I prefer leaving to those better called to define it. I hope = this >> doesn't cause too much confusion. >> >> My basic suggestion of a handshake protocol permitting policy decisions = (http:/ >> /www.ietf.org/mail-archive/web/ogpx/current/msg00475.html) could (strict= ly >> technically) handle the debated issues of authentication, "adult content= " and >> TOSes: >> >> Agent domain: >> request access for >> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org >> >> Region domain: >> require parameter values for >> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org >> authentication: PASSPORT OR USSSN OR EUID OR JPVER >> accept adult content: YES >> accept nudity: YES >> accept sexual acts: YES >> accept profane language: YES >> terms of service: ((FRLAWINFO2006:128 AND EULAWIP2008:2) OR USLAWTELECOM= 2005:1) >> AND (VWTOS1.2 OR MVTOS2.3 OR MYTOS1.0) >> user signature: TOKEN >> >> Agent domain: >> required parameter values for >> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org >> authentication: yes >> accept adult content: yes >> accept nudity: yes >> accept sexual acts: yes >> accept profane language: no >> terms of service: yes >> user signature: 238158-2356257-238658-23596 >> >> Region domain: >> access denied for >> user: Title.FirstName.Initials.LastName.ExtraSomething@agentdomain.org >> (outside protocol: since not accepting profane language) >> >> Using this method, one could decide to let the agent domain manage the >> acceptance of "adult content" entirely, by the region domain not asking = for age >> but let the agent domain automatically set accept for e.g. "adult conten= t", >> "nudity", "sexual acts" and "profane language" to NO for those underage = and as >> options YES/NO for those of age. One could also either ask for acceptanc= e of >> "adult content" in general or for more specific parameters often associa= ted >> with "adult content", giving great flexibility in policy making. But onc= e >> again, that is policy outside protocol level. > > but what is the mature age is a function of country, and thus region, > not agent domain. Adding to the protocol the notion of 'adult', so that > the RD can ask the AD 'is this person an adult?' won't work for that > reason. > > Better to ask the AD, 'does the age of the person fall in this range?', > and even better to not define 'age' in the protocol, but just describe > how the RD can ask for 'does X falls into this range', where the AD > first tells the RD that it supports X (see my previous post). > >> >> Best regards, >> >> Magnus >> >> - -----Ursprungligt meddelande----- >> Fr=E5n: Infinity Linden [mailto:infinity@lindenlab.com] >> Skickat: den 6 oktober 2009 01:39 >> Till: David W Levine >> Kopia: Magnus Zeisig; ogpx@ietf.org; ogpx-bounces@ietf.org >> =C4mne: Re: [ogpx] Protocol for permitting policy decisions >> >> On Mon, Oct 5, 2009 at 1:33 PM, David W Levine wrote: >> >> >> >> =A0 =A0 =A0 =A0 "In order to have rights beyond "guest" on this region, = you, or your >> agent domain, on your behalf, needs to have signed the TOS document. I w= ill >> demand a digitally signed proof of this, as metadata when you >> =A0 =A0 =A0 =A0 request acess to my region." >> >> =A0 =A0 =A0 =A0 - David >> =A0 =A0 =A0 =A0 ~ Zha >> >> >> >> >> i think i grok what you're trying to say here, but i would also add... "= a given >> agent domain MAY choose to deny you ANY service (including anonymous or = guest >> access) if you don't provide some form of authenticator and assert that = you >> have read and understand the domains terms of use." >> >> - -cheers >> - -meadhbh >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: 9.8.3 (Build 4028) >> Charset: utf-8 >> >> wsBVAwUBSssVoe5MlU9XyaiSAQjgswgApysemtDE8npKhTSCUGHMxFnGxsdUvJfs >> /4z6Iribd7w2lmD20cx8xUB1/ojV5ABEEArCRdJmWbf5aGHBeF8nrv8cxlFOxWYB >> 37cZmEY7zAwbY6XNGB0NIpG2rnZWSW9sGJUOwVs4lW/DJKcDmuqgywtwtl5705u8 >> W3G8y06I4sek/oukgGczqBBIG2Zny1qgbP/fr2AsewrHXYfYlMN2HnmzxQR60vry >> wJuV+gBe8RVC/ppHH+carOLMTmwZP8jbGnCy3+wUwI5H8+QbUuptdYNnJ8Fw0F/u >> yC2IesKerMmIlF0Z2Q93GyzGo02mn4dviLINYZ0M9kNYXhEe3OkypQ=3D=3D >> =3DS0LC >> -----END PGP SIGNATURE----- >> >> > >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From morgaine.dinova@googlemail.com Wed Oct 7 14:49:45 2009 Return-Path: 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 750C528C190 for ; Wed, 7 Oct 2009 14:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 N2WYr3l7eMF3 for ; Wed, 7 Oct 2009 14:49:43 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 5369228C102 for ; Wed, 7 Oct 2009 14:49:43 -0700 (PDT) Received: by ewy4 with SMTP id 4so2332982ewy.37 for ; Wed, 07 Oct 2009 14:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tpXWr++Id/o6xn06INWv8+dm5MFCyPMHsLMIJI4ZryQ=; b=EJtlMdMBc4FlM/4FOyiCFCTGWIE9AXHeuEXWRYcp/6jRHomtePYYldDMbGGcHWck10 qJ/ObmwXTh0E7KhJUHhd1cNvoBOugfXM3/tGRpGfr80Pl+y7GD+LPuyAIpEFYc6F1VGk I+Cax/bx9xVmsCtz40JvTAHCRrHkCKWKjYLFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NOFPsQ2+33Hlj62kQFxtRa198tbq+7RhRpQ7C3Y8F1Ho7/t7w0d/j6JHQRNllZj7yl QxXQaRZV53resRxeiZrO0MEO4gM7y7JI0Ku3XNguOXpw3RVKnofE/rgknvnEIc66Y7lE Rjcv/ROIH+03qkBFMRnqtA5sVmqfToMYpnr9Y= MIME-Version: 1.0 Received: by 10.210.6.21 with SMTP id 21mr7069924ebf.58.1254952280627; Wed, 07 Oct 2009 14:51:20 -0700 (PDT) In-Reply-To: <9b8a8de40910071112j600dea3fge21a35ffc0341e52@mail.gmail.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <9b8a8de40910061305w56dc2b01qab60b7b7aaffa337@mail.gmail.com> <9b8a8de40910071112j600dea3fge21a35ffc0341e52@mail.gmail.com> Date: Wed, 7 Oct 2009 22:51:20 +0100 Message-ID: From: Morgaine To: Vaughn Deluca Content-Type: multipart/alternative; boundary=000e0cdf7632e59b7004755f583c Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 21:49:45 -0000 --000e0cdf7632e59b7004755f583c Content-Type: text/plain; charset=ISO-8859-1 Vaughn, I like your analysis here. If rough consensus can be achieved around your point as a design decision, I think it would remove a large hurdle to progress in regards to filtering and prohibition semantics. It would also reduce our workload immensely. I don't think that I can improve on your analysis, but I can shorten your wording: *Policies are only advisary, and not enforced by the protocol. Failure to comply with a policy is therefore addressed out of band by non-protocol means.* Given this design decision, we would no longer have to worry about semantic filters and policy blocks which are virtually impossible to get right, and which would require us to create and manage a *security framework* -- a major difficulty and source of problems. Also, this ties in perfectly with what many people have said about "trust agreements" --- that in the end they come down to courts, lawyers and contracts, none of which are entities in an IETF protocol which at best provides authenticated endpoints. If no such consensus can be found, then I see years of semantic battles ahead, and in particular a war between those who envisage creating protocol-enforced prison planets versus those who envisage a metaverse that by and large operates through emergent behaviour and dynamic consensus, in the manner of the Internet. Morgaine. ====================================== On Wed, Oct 7, 2009 at 7:12 PM, Vaughn Deluca wrote: > Although I actually think enough has been said on policy, I want to expand > my last message a bit to make it even more clear how i view this problem. > > In wrote: > "Anything we have said so far on policy in this discussion relates to > protocol *options* someone *might* use. None of this will be REQUIRED. The > protocol will function without using any of it. So really, as far as i can > see we *can* move on." > > Here is a longer version of the same message: > > We are talking policy, and by definition, everybody is free to ignore > policy, and live with the consequences. If I run a some services in a RD, > its my choice what policy i set to determine what is allowed in there. Yet, > a visiting agent is under *its* ADs policy if I like that or not. Its the > agents choice to be in that AD. > > If the policy of that AD is allowing, or even encouraging, the use of > deadly weapons, while I like my regions to be free of violence. I can > ignore the policy of the agents AD. I am free to do so, and apply a policy > of "ban on the first sight of a gun", after all I run this service. Ignoring > the policy of the AD may carry the consequence of spoiling my relations with > that AD, since they strongly belief in the freedom to carry weapons, and > this may prompt them to prevent any TP to my RD. Yet that is about all thats > in the power of the AD, unless it has some legal hooks in my service via a > real world contract with me. > > A more realistic example could be that it is the policy of the AD --or > rather some associated asset service *winks to Zha* -- to only let go of > purple clothes under strict conditions. I have struck a deal with that > service, promising to follow the rules for purple cloths. Its my choice to > live by that promise, or -at my peril- ignore it. So to answer one of > Carlo's older questions, yes, from the perspective of the region service, > the Asset service policy *can* be forgotten and ignored, but most likely I > will prefer not to do so, or I would not have made the deal in the first > place. > > While all this is very interesting, its *outside* of the scope of the > protocol. > Policy can be ignored, or followed, and its up to those setting the > policies to enforce them, by whatever means they have at their disposal, but > it has nothing to do with the protocol as such. > > Infinity is eager to move on, and I fully agree with her. I suddenly > realised that the source of much of our problems might be that few people > have made it clear that *whatever* method we pick to carry policy related > information, the use of that information will *always* be optional, and > never REQUIRED by protocol. > > I do not think there is a single person on the list that will disagree with > this, and the chances of getting anything else than this past the IETF are > in my view remote. [I am new to protocol discussions, but there surly must > be precedents for this? We can't possibly be the first group to hit this > obstacle?]. > > We can spend a very long time talking about the way to code the policy > related information, and how explicit it is allowed to be; If it should be > only payload, or actual part of the control flow; If it may contain actual > values, or better only ranges. All of that is however somewhat moot as soon > as it is realised that its *optional* to provide and/or use this info. > > There is not much chance we will gain full or even rough consensus on what > is appropriate to put in the meta-information, because it depends fully on > deeply personal value systems. One persons nightmare of a totalitarian state > is the next persons hope to be free from adult material or unrestrained > violence. > > The crux is that we realise that the use of anything that will be in the > protocol relating to policy is optional. If I don't like that info to be > there, I don't supply it, and ignore it if I find it. Nothing will break in > protocol terms. > > We could (and probably should) have some discussion how far we want to go > in facilitating certain use-cases by defining explicit fields to make > interop easy. Not many will defend a pre-defined field for real-life skin > color to allow other services more easy discrimination. But *even* if we had > the (in my eyes) bad taste to define such a field or tag to aid some (in my > eyes) unacceptable use-case, we are certainly NOT going to REQUIORE its use > in the protocol, nor saying it MAY NOT be carried ever, since however wrong > we think such a tag might be, it is a matter of policy, and as such outside > the scope of the protocol. If we decided in this group that such a tag > should be forbidden, and MUST NOT be carried we open the gates for demands > that other tags must also be forbidden. And conversely, if we REQUIRE the > use of such a tag, we can not prevent others in this discussion to REQUIRE > other tags. And everything will end in tears. > > I think most (no, *all*) of what i just said has been mentioned before on > the list in one form or another, and i really do not think there is much > more to add that is pertinent to the protocol. I hold some (strong) > convictions how meta information should be carried, in particular relating > to privacy issues, but non of that is crucial, given that i am never forced > to give this information, nor prevented from using it if somebody is sending > it. > That said, if I as a user don't like the choices made by some service, i > SHOULD be able to pick another with in my view better options, or even run > one myself. So lets move on, and make that possible! > > -Vaughn > > > > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --000e0cdf7632e59b7004755f583c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vaughn, I like your analysis here.

If rough consensus can be achieved around your point as a design decision, I think it would remove a large hurdle to progress in regards to filtering and prohibition semantics.=A0 It would als= o reduce our workload immensely.

I don't think that I can improve on your analysis, but I can shorten yo= ur wording:

Policies are only advisary, and not enforced by the protocol.=A0 Failure to comply with a policy is therefore a= ddressed out of band by non-protocol means.

Given this design decision, we would no longer have to worry about semantic= filters and policy blocks which are virtually impossible to get right, and= which would require us to create and manage a security framework --= a major difficulty and source of problems.

Also, this ties in perfectly with what many people have said about &quo= t;trust agreements" --- that in the end they come down to courts, lawy= ers and contracts, none of which are entities in an IETF protocol which at = best provides authenticated endpoints.

If no such consensus can be found, then I see years of semantic battles= ahead, and in particular a war between those who envisage creating protoco= l-enforced prison planets versus those who envisage a metaverse that by and= large operates through emergent behaviour and dynamic consensus, in the ma= nner of the Internet.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

On Wed, Oct 7, 2009 at 7:12 PM, Va= ughn Deluca <vaughn.deluca@gmail.com> wrote:
Although I a= ctually think enough has been said on policy, =A0I want to expand my last m= essage a bit to make it even more clear how i view this problem.

In wrote:
=A0"Anything= we have said so far on policy in this discussion relates to protocol *opti= ons* =A0someone *might* use. None of this will be REQUIRED. The protocol wi= ll function without using any of it. =A0So really, as far as i can see we *= can* move on."

Here is a longer version of the same message:=A0<= /div>

We are talking policy, and by definition, everybod= y is free to ignore policy, and live with the consequences. =A0If I run a s= ome services in a RD, its my choice what =A0policy i set to determine what = is allowed in there. Yet, a visiting agent is under *its* =A0ADs policy if = I like that or not. Its the agents choice to be in that AD.=A0

If the policy of that AD is allowing, or even encouragi= ng, the use of deadly weapons, =A0while I like my regions to be free of vio= lence. I can ignore the policy of the agents AD. I am free to do so, and ap= ply a policy of "ban on the first sight of a gun", after all I ru= n this service. Ignoring the policy of the AD may carry the consequence of = spoiling my relations with that AD, since they strongly belief in the freed= om to carry weapons, and this may prompt them to prevent any TP to my RD. Y= et that is about all thats in the power of the AD, unless it has some legal= hooks in my service via a real world contract with me.=A0

A more realistic example could be that it is the policy= of the AD --or rather =A0some associated asset service *winks to Zha* -- t= o only let go of purple clothes under strict conditions. I have struck a de= al with that service, promising to follow the rules for purple cloths. Its = my choice to live by that promise, or -at my peril- ignore it. So to answer= one of Carlo's older questions, yes, from the perspective of the regio= n service, the Asset service policy *can* be forgotten and ignored, =A0but = most likely I will prefer not to do so, or I would not have made the deal i= n the first place.

While all this is very interesting, its =A0*outside* of= the scope of the protocol.
Policy can be ignored, or followed, a= nd its up to those setting the policies to enforce them, by whatever means = they have at their disposal, but it has nothing to do with the protocol as = such.

Infinity is eager to move on, and I fully agree with he= r. I suddenly realised that the source of much of our problems might be tha= t few people have made it clear that *whatever* method =A0we pick to carry = =A0policy related information, the use of that information =A0will *always*= be optional, and never REQUIRED by protocol.

I do not think there is a single person on the list tha= t will disagree with this, and the chances of getting anything else than th= is past the IETF are in my view remote. [I am new to protocol discussions, = but there surly must be precedents for this? We can't possibly be the f= irst group to hit this obstacle?].=A0

We can spend a very long time talking about the way to = code the policy related information, and how explicit it is allowed to be; = If it should be only payload, or actual part of the control flow; If it may= contain actual values, or better only ranges. All of that is however somew= hat moot as soon as it is realised that its *optional* to provide and/or us= e this info.=A0

There is not much chance we will gain full or even roug= h consensus on what is appropriate to put in the meta-information, because = it depends fully on deeply personal value systems. One persons nightmare of= a totalitarian state is the next persons hope to be free from adult materi= al or unrestrained violence.

The crux is that we realise that the use of anything th= at will be in the protocol relating to policy is optional. If I don't l= ike that info to be there, I don't supply it, and ignore it if I find i= t. Nothing will break in protocol terms.

We could (and probably should) have some discussion how= far we want to go in facilitating certain use-cases by defining explicit f= ields to make interop easy. Not many will defend a pre-defined field for re= al-life skin color to allow other services more easy discrimination. But *e= ven* if we had the (in my eyes) bad taste to define such a field or tag to = aid some (in my eyes) unacceptable use-case, we are certainly NOT going to = REQUIORE its use in the protocol, nor saying it MAY NOT be carried ever, si= nce however wrong we think such a tag might be, it is a matter of policy, a= nd as such outside the scope of the protocol. If we decided in this group t= hat such a tag should be forbidden, and MUST NOT be carried we open the gat= es for demands that other tags must also be forbidden. And conversely, if w= e REQUIRE the use of such a tag, we can not prevent others in this discussi= on to REQUIRE other tags. And everything will end in tears.

I think most (no, *all*) of what i just said =A0has bee= n mentioned before on the list in one form or another, and i really do not = think there is much more to add that is pertinent to the protocol. I hold = =A0some (strong) convictions how meta information should be carried, in par= ticular relating to privacy issues, but non of that is crucial, given that = i am never forced to give this information, nor prevented from using it if = somebody is sending it.=A0
That said, if I as a user don't like the choices made by some serv= ice, i SHOULD be able to pick another with in my view better options, or ev= en run one myself. So lets move on, and make that possible!

-Vaughn



<= br>



_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--000e0cdf7632e59b7004755f583c-- From josh@lindenlab.com Wed Oct 7 15:12:04 2009 Return-Path: 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 2B46F3A6A12 for ; Wed, 7 Oct 2009 15:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.761 X-Spam-Level: X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 wSW4rsdp8X4x for ; Wed, 7 Oct 2009 15:12:03 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 00F203A69B4 for ; Wed, 7 Oct 2009 15:12:02 -0700 (PDT) Received: by pzk6 with SMTP id 6so38299pzk.29 for ; Wed, 07 Oct 2009 15:13:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.35.12 with SMTP id n12mr60813rvj.237.1254953620944; Wed, 07 Oct 2009 15:13:40 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> Date: Wed, 7 Oct 2009 15:13:40 -0700 Message-ID: From: Joshua Bell To: ogpx Content-Type: multipart/alternative; boundary=000e0cd1530ac9392804755fa854 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 22:12:04 -0000 --000e0cd1530ac9392804755fa854 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 7, 2009 at 2:07 PM, Meadhbh Hamrick wrote: > oh. hey. so i was just thinking about the "should we define global > keys for region meta-data?" question. > > i think if we were to move forward with the AD telling the RD what > it's concerned about plan, we _should_ have global identifiers. i just > think that if everyone had different identifiers for the same concept, > you would get protocol interop, but you would still have systems that > don't know what each other are talking about. > Thinking while I type here - these aren't finished thoughts, just some brainstorms: So fundamental to this, we're talking about one system making policy decisions based on data from another system that's in a different trust domain (e.g. separate organizations). That implies to me that they must have done an out-of-band trust negotiation, otherwise they have no reason to, er, trust the data, so the policy decision is advisory at best. And at that point, wouldn't we assume they're attempting to actively enable system interop and would therefore also have that opportunity to agree on a concept/identifier set? IMHO, that wouldn't live in the protocol itself, but perhaps a standard set of interchange profiles... Sample scenario (using the VW1=AD1+RD1, VW2=AD2+RD2 rough terminology we've been batting about): VW1 and VW2 want to enable inter-VW tourism (i.e. AD1 agents can visit RD2). VW2 has a policy that they only allow in users of a certain quality (e.g. "speaks Latin"). Only a subset of AD1 agents have that quality. Therefore, RD2 would only accept teleports of AD1 agents that have that quality (based on the sort of handshake discussed earlier in this thread). However, RD2 needs some trust relationship with AD1, otherwise malicious AD3 can come along which claims all of its users speak Latin and its users slip in. So VW1 and VW2 trade keys and sign some paperwork, and at that point (while the lawyers are busy) they could handshake on sharing "agent linguistic information profile v2.3" data. On the other hand, there might be more hard-core requirements (age, security clearance, etc) that would use different profiles. Hopefully there's also the nil-trust case where this information might be shared on a purely informational basis - e.g. even ADx asserts some quality about an agent to RDy, ADx feels comfortable broadcasting that information (since it can't trust that RDy will keep it confidential) and RDy feels comfortable using that information even without trusting it (since it has no reason to believe ADx is telling the truth). Now... this all doesn't sound like it should new. I'm vaguely reminded of W3C's PICS (which died quietly after negligible adoption), but there weren't two active (and potentially liable...) entities involved in that, just the single provider and user. Surely there are other examples? --000e0cd1530ac9392804755fa854 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 7, 2009 at 2:07 PM, Meadhbh Hamrick = <meadhbh.= siobhan@gmail.com> wrote:
oh. hey. so i was just thinking about the "should we define global
keys for region meta-data?" question.

i think if we were to move forward with the AD telling the RD what
it's concerned about plan, we _should_ have global identifiers. i just<= br> think that if everyone had different identifiers for the same concept,
you would get protocol interop, but you would still have systems that
don't know what each other are talking about.
Thinking while I type here - these aren't finished thoughts, just some= brainstorms:

So fundamental to this, we're talking about one sy= stem making policy decisions based on data from another system that's i= n a different trust domain (e.g. separate organizations). That implies to m= e that they must have done an out-of-band trust negotiation, otherwise they= have no reason to, er, trust the data, so the policy decision is advisory = at best. And at that point, wouldn't we assume they're attempting t= o actively enable system interop and would therefore also have that opportu= nity to agree on a concept/identifier set? IMHO, that wouldn't live in = the protocol itself, but perhaps a standard set of interchange profiles...<= br>
Sample scenario (using the VW1=3DAD1+RD1, VW2=3DAD2+RD2 rough terminolo= gy we've been batting about):

VW1 and VW2 want to enable inter-V= W tourism (i.e. AD1 agents can visit RD2). VW2 has a policy that they only = allow in users of a certain quality (e.g. "speaks Latin"). Only a= subset of AD1 agents have that quality. Therefore, RD2 would only accept t= eleports of AD1 agents that have that quality (based on the sort of handsha= ke discussed earlier in this thread). However, RD2 needs some trust relatio= nship with AD1, otherwise malicious AD3 can come along which claims all of = its users speak Latin and its users slip in. So VW1 and VW2 trade keys and = sign some paperwork, and at that point (while the lawyers are busy) they co= uld handshake on sharing "agent linguistic information profile v2.3&qu= ot; data.

On the other hand, there might be more hard-core requirements (age, sec= urity clearance, etc) that would use different profiles.

Hopefully = there's also the nil-trust case where this information might be shared = on a purely informational basis - e.g. even ADx asserts some quality about = an agent to RDy, ADx feels comfortable broadcasting that information (since= it can't trust that RDy will keep it confidential) and RDy feels comfo= rtable using that information even without trusting it (since it has no rea= son to believe ADx is telling the truth).

Now... this all doesn't sound like it should new. I'm vaguely r= eminded of W3C's PICS (which died quietly after negligible adoption), b= ut there weren't two active (and potentially liable...) entities involv= ed in that, just the single provider and user. Surely there are other examp= les?

--000e0cd1530ac9392804755fa854-- From meadhbh.siobhan@gmail.com Wed Oct 7 15:29:15 2009 Return-Path: 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 731E73A6801 for ; Wed, 7 Oct 2009 15:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] 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 R1wWfFYVtYoM for ; Wed, 7 Oct 2009 15:29:14 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id BB9D03A693D for ; Wed, 7 Oct 2009 15:28:48 -0700 (PDT) Received: by pzk6 with SMTP id 6so51802pzk.29 for ; Wed, 07 Oct 2009 15:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=p03M3JAl3JxMLGvc/VilGBvjQonHNpf/BsezXFnl6UA=; b=W+WV2PavINknlsFi0hS+6IbKCfqnAR1Ee+8fmVwnq6lbDpfC1GXEiBVgdSt8ADBViE 2WFF+iNmbSsDI2eLsvLsLliKIsWl86Vm3MpFjKU4lkJ5Fyt9Wt2HhTx1TV5phUsYUDjb 63Bbze3lfIzc7iq5hmIrmfGSmfHT8VwwcA9Pc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qJijLazBBURANOhqDkTCBYexExlE3uYKyXUoyHLMxIxpM3j9rU+LyzS8MxlE2aZTib pld0BQMF5fr/7g25c+1mD/U9sft2Ro5PSIoq7LnlZxu9f6AkZt9510JLw1vNG3tuz4QN J+i6X2JX3MBkFRpwZ+OEGR0TKfDrzY4KHi6Fs= MIME-Version: 1.0 Received: by 10.115.132.12 with SMTP id j12mr779633wan.121.1254954626957; Wed, 07 Oct 2009 15:30:26 -0700 (PDT) In-Reply-To: <9b8a8de40910071112j600dea3fge21a35ffc0341e52@mail.gmail.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <9b8a8de40910061305w56dc2b01qab60b7b7aaffa337@mail.gmail.com> <9b8a8de40910071112j600dea3fge21a35ffc0341e52@mail.gmail.com> Date: Wed, 7 Oct 2009 15:30:26 -0700 Message-ID: From: Meadhbh Hamrick To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 22:29:15 -0000 i think there might be some confusion on what we're using the term "policy" to mean. when i use the term with respect to VWRAP, i do not mean a type of policy like "please, no guns." i mean a policy such as "i (as a region domain) will only place avatars from this list of agent domains," or "i will not respond to LLSD messages encoded using the binary serialization." so in this sense, policy is not something imposed on you by a third party, but a collection of decisions you (as a service operator) make about how your service will behave. this is why i say things like "domain sets policy," because in many cases, the domain's authority may make a decision (like "i'm not going to accept MD5 hashed passwords" or "i won't accept connections from non-authenticated third parties" that will be global decisions. that being said, you could have these policies dictated to you by a third party, perhaps because they're paying you money or offering you a service. but other than to acknowledge that it might happen, i don't think it's in our best interest to define a protocol for transporting policy descriptions between domains. what policies are possible will differ between implementations, and the purpose of defining them as part of the policy domain is to explicitly remove them from negotiation during protocol exchanges. -cheers -meadhbh On Wed, Oct 7, 2009 at 11:12 AM, Vaughn Deluca wr= ote: > Although I actually think enough has been said on policy, =A0I want to ex= pand > my last message a bit to make it even more clear how i view this problem. > In wrote: > =A0"Anything we have said so far on policy in this discussion relates to > protocol *options* =A0someone *might* use. None of this will be REQUIRED.= The > protocol will function without using any of it. =A0So really, as far as i= can > see we *can* move on." > Here is a longer version of the same message: > We are talking policy, and by definition, everybody is free to ignore > policy, and live with the consequences. =A0If I run a some services in a = RD, > its my choice what =A0policy i set to determine what is allowed in there.= Yet, > a visiting agent is under *its* =A0ADs policy if I like that or not. Its = the > agents choice to be in that AD. > If the policy of that AD is allowing, or even encouraging, the use of dea= dly > weapons, =A0while I like my regions to be free of violence. I can ignore = the > policy of the agents AD. I am free to do so, and apply a policy of "ban o= n > the first sight of a gun", after all I run this service. Ignoring the pol= icy > of the AD may carry the consequence of spoiling my relations with that AD= , > since they strongly belief in the freedom to carry weapons, and this may > prompt them to prevent any TP to my RD. Yet that is about all thats in th= e > power of the AD, unless it has some legal hooks in my service via a real > world contract with me. > A more realistic example could be that it is the policy of the AD --or > rather =A0some associated asset service *winks to Zha* -- to only let go = of > purple clothes under strict conditions. I have struck a deal with that > service, promising to follow the rules for purple cloths. Its my choice t= o > live by that promise, or -at my peril- ignore it. So to answer one of > Carlo's older questions, yes, from the perspective of the region service, > the Asset service policy *can* be forgotten and ignored, =A0but most like= ly I > will prefer not to do so, or I would not have made the deal in the first > place. > While all this is very interesting, its =A0*outside* of the scope of the > protocol. > Policy can be ignored, or followed, and its up to those setting the polic= ies > to enforce them, by whatever means they have at their disposal, but it ha= s > nothing to do with the protocol as such. > Infinity is eager to move on, and I fully agree with her. I suddenly > realised that the source of much of our problems might be that few people > have made it clear that *whatever* method =A0we pick to carry =A0policy r= elated > information, the use of that information =A0will *always* be optional, an= d > never REQUIRED by protocol. > I do not think there is a single person on the list that will disagree wi= th > this, and the chances of getting anything else than this past the IETF ar= e > in my view remote. [I am new to protocol discussions, but there surly mus= t > be precedents for this? We can't possibly be the first group to hit this > obstacle?]. > We can spend a very long time talking about the way to code the policy > related information, and how explicit it is allowed to be; If it should b= e > only payload, or actual part of the control flow; If it may contain actua= l > values, or better only ranges. All of that is however somewhat moot as so= on > as it is realised that its *optional* to provide and/or use this info. > There is not much chance we will gain full or even rough consensus on wha= t > is appropriate to put in the meta-information, because it depends fully o= n > deeply personal value systems. One persons nightmare of a totalitarian st= ate > is the next persons hope to be free from adult material or unrestrained > violence. > The crux is that we realise that the use of anything that will be in the > protocol relating to policy is optional. If I don't like that info to be > there, I don't supply it, and ignore it if I find it. Nothing will break = in > protocol terms. > We could (and probably should) have some discussion how far we want to go= in > facilitating certain use-cases by defining explicit fields to make intero= p > easy. Not many will defend a pre-defined field for real-life skin color t= o > allow other services more easy discrimination. But *even* if we had the (= in > my eyes) bad taste to define such a field or tag to aid some (in my eyes) > unacceptable use-case, we are certainly NOT going to REQUIORE its use in = the > protocol, nor saying it MAY NOT be carried ever, since however wrong we > think such a tag might be, it is a matter of policy, and as such outside = the > scope of the protocol. If we decided in this group that such a tag should= be > forbidden, and MUST NOT be carried we open the gates for demands that oth= er > tags must also be forbidden. And conversely, if we REQUIRE the use of suc= h a > tag, we can not prevent others in this discussion to REQUIRE other tags. = And > everything will end in tears. > I think most (no, *all*) of what i just said =A0has been mentioned before= on > the list in one form or another, and i really do not think there is much > more to add that is pertinent to the protocol. I hold =A0some (strong) > convictions how meta information should be carried, in particular relatin= g > to privacy issues, but non of that is crucial, given that i am never forc= ed > to give this information, nor prevented from using it if somebody is send= ing > it. > That said, if I as a user don't like the choices made by some service, i > SHOULD be able to pick another with in my view better options, or even ru= n > one myself. So lets move on, and make that possible! > -Vaughn > > > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From mike.dickson@hp.com Wed Oct 7 18:16:52 2009 Return-Path: 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 54DB43A68D4 for ; Wed, 7 Oct 2009 18:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 EOmil8LvHxRt for ; Wed, 7 Oct 2009 18:16:48 -0700 (PDT) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id BB3723A68A7 for ; Wed, 7 Oct 2009 18:16:48 -0700 (PDT) Received: from G3W0630.americas.hpqcorp.net (g3w0630.americas.hpqcorp.net [16.233.58.74]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id C7F172436A; Thu, 8 Oct 2009 01:18:28 +0000 (UTC) Received: from G3W0055.americas.hpqcorp.net (16.232.1.152) by G3W0630.americas.hpqcorp.net (16.233.58.74) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 8 Oct 2009 01:17:37 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G3W0055.americas.hpqcorp.net ([16.232.1.152]) with mapi; Thu, 8 Oct 2009 01:17:37 +0000 From: "Dickson, Mike (ISS Software)" To: Meadhbh Hamrick , Carlo Wood Date: Thu, 8 Oct 2009 01:17:01 +0000 Thread-Topic: [ogpx] Protocol for permitting policy decisions Thread-Index: AcpHkOvk1RE6BS1RRfOYCMyTl300bQAI25kg Message-ID: <4646639E08F58B42836FAC24C94624DD771A1BA1FA@GVW0433EXB.americas.hpqcorp.net> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD771A1BA1FAGVW0433EXBame_" MIME-Version: 1.0 Cc: Infinity Linden , "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 01:16:52 -0000 --_000_4646639E08F58B42836FAC24C94624DD771A1BA1FAGVW0433EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Meadbah wrote: i still like this scheme because a) it's really similar to the way seed caps work, b) it adds flexibility to our system(s), and c) it does what i was hoping... gives the AD the ability to make policy decisions (like am i going to let this 15 year old user access material that may land me in hot water with the local authorities.) I may be mis-understanding all this since I'm still trying to come up to sp= eed but isn't it the region that's making the policy decision here to allow= /disallow a connect given what AD is representing about the user? And yes,= I agree that for this to work there must be trust established between the = services involved. I'm just confused by the above statement since it impli= es the AD is making a policy decision while it's really the RD that has the= content (and hence the possible issue). And the RD and AD may be run by t= wo different entities.... Mike --_000_4646639E08F58B42836FAC24C94624DD771A1BA1FAGVW0433EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Meadbah wrote:

 

i still like this scheme= because a) it's really similar to the way

seed caps work, b) it ad= ds flexibility to our system(s), and c) it

does what i was hoping..= . gives the AD the ability to make policy

decisions (like am i goi= ng to let this 15 year old user access

material that may land m= e in hot water with the local authorities.)

 

I may be mis-understand= ing all this since I’m still trying to come up to speed but isn’t it th= e region that’s making the policy decision here to allow/disallow a con= nect given what AD is representing about the user?  And yes, I agree that f= or this to work there must be trust established between the services involved.=   I’m just confused by the above statement since it implies the AD is making a policy decision while it’s really the RD that has the conten= t (and hence the possible issue).  And the RD and AD may be run by two different entities….

 

Mike<= /p>

 

--_000_4646639E08F58B42836FAC24C94624DD771A1BA1FAGVW0433EXBame_-- From morgaine.dinova@googlemail.com Wed Oct 7 20:32:26 2009 Return-Path: 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 1D6F028C0E1 for ; Wed, 7 Oct 2009 20:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 NTCv87RMizrp for ; Wed, 7 Oct 2009 20:32:24 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id E406C3A67C2 for ; Wed, 7 Oct 2009 20:32:23 -0700 (PDT) Received: by ewy4 with SMTP id 4so2527061ewy.37 for ; Wed, 07 Oct 2009 20:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ELxe0nINNqbCPZHi+FS+wCgVLYglQY6vATvcAJCCYEM=; b=tqzW+9bb8Dln3aCGVXcXuWmKIzBJZyl1S2O976SSf+CfhKLPiLBE9YjCygzygmJJcW hGj5F09getmQTGCN1Y9YshvC0TAx/yEr5ZJ7tlV38RieXHxa1ElmM3PBWslDSAvnoC2A FuerOmgKVBNxXhgpLrdNESnF9S1b072S5ePgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MD5aqN48vG/J4NejRrhFo9BqJ/askHkTs2JHD5t7AL25i2kKIIhEfGEZ9MaO9OgI9M /drb4oV7YLU0TAPM7RwYV0//ybsoL+smtsrOw/CoH5DIc3mEa0B8Pu3m9rXbwdWAXrWm QDHCi2LPW6jE74K7Eua0EmJmLEU1kah6yzx54= MIME-Version: 1.0 Received: by 10.210.9.5 with SMTP id 5mr7596465ebi.78.1254972841788; Wed, 07 Oct 2009 20:34:01 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> Date: Thu, 8 Oct 2009 04:34:01 +0100 Message-ID: From: Morgaine To: Joshua Bell Content-Type: multipart/alternative; boundary=0015173fe5b07004a904756422d5 Cc: ogpx 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 03:32:26 -0000 --0015173fe5b07004a904756422d5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 7, 2009 at 11:13 PM, Joshua Bell wrote: > > VW1 and VW2 want to enable inter-VW tourism (i.e. AD1 agents can visit > RD2). VW2 has a policy that they only allow in users of a certain quality > (e.g. "speaks Latin"). Only a subset of AD1 agents have that quality. > Therefore, RD2 would only accept teleports of AD1 agents that have that > quality (based on the sort of handshake discussed earlier in this thread). > However, RD2 needs some trust relationship with AD1, otherwise malicious AD3 > can come along which claims all of its users speak Latin and its users slip > in. So VW1 and VW2 trade keys and sign some paperwork, and at that point > (while the lawyers are busy) they could handshake on sharing "agent > linguistic information profile v2.3" data. > That's a great description of the ultimate interop dystopia in which, through definition of arbitrary set membership criteria by an arbitrary number of policy makers, the result of transitive policy transference and policy intersection is that the set of visitable worlds is the empty set. Are we trying to create an interop protocol here, or a protocol for preventing interop? I'm leaning ever more strongly towards David's position that only services should carry expressions of policy, not domains, because in the direction in which this discussion is heading there will be no widespread interop at all. Imagine if SMTP had been specified to manage a set of content-defining keywords and to block anything unacceptable to an MTA's "policy" based on such tagged content. And then (this is the killer), imagine if *sources of email had to adhere to such tag policies transitively*. There would either be no email except from closed groups, or the whole tagging thing would be such a farce that it would be ignored. For now, I'm affirming even more strongly Vaughn's principle of *advisary policy only* --- http://www.ietf.org/mail-archive/web/ogpx/current/msg00524.html . Anything else is a recipe for building walled gardens and widespread denial of interop through contagion. Morgaine. ========================================== On Wed, Oct 7, 2009 at 11:13 PM, Joshua Bell wrote: > On Wed, Oct 7, 2009 at 2:07 PM, Meadhbh Hamrick > wrote: > >> oh. hey. so i was just thinking about the "should we define global >> keys for region meta-data?" question. >> >> i think if we were to move forward with the AD telling the RD what >> it's concerned about plan, we _should_ have global identifiers. i just >> think that if everyone had different identifiers for the same concept, >> you would get protocol interop, but you would still have systems that >> don't know what each other are talking about. >> > > Thinking while I type here - these aren't finished thoughts, just some > brainstorms: > > So fundamental to this, we're talking about one system making policy > decisions based on data from another system that's in a different trust > domain (e.g. separate organizations). That implies to me that they must have > done an out-of-band trust negotiation, otherwise they have no reason to, er, > trust the data, so the policy decision is advisory at best. And at that > point, wouldn't we assume they're attempting to actively enable system > interop and would therefore also have that opportunity to agree on a > concept/identifier set? IMHO, that wouldn't live in the protocol itself, but > perhaps a standard set of interchange profiles... > > Sample scenario (using the VW1=AD1+RD1, VW2=AD2+RD2 rough terminology we've > been batting about): > > VW1 and VW2 want to enable inter-VW tourism (i.e. AD1 agents can visit > RD2). VW2 has a policy that they only allow in users of a certain quality > (e.g. "speaks Latin"). Only a subset of AD1 agents have that quality. > Therefore, RD2 would only accept teleports of AD1 agents that have that > quality (based on the sort of handshake discussed earlier in this thread). > However, RD2 needs some trust relationship with AD1, otherwise malicious AD3 > can come along which claims all of its users speak Latin and its users slip > in. So VW1 and VW2 trade keys and sign some paperwork, and at that point > (while the lawyers are busy) they could handshake on sharing "agent > linguistic information profile v2.3" data. > > On the other hand, there might be more hard-core requirements (age, > security clearance, etc) that would use different profiles. > > Hopefully there's also the nil-trust case where this information might be > shared on a purely informational basis - e.g. even ADx asserts some quality > about an agent to RDy, ADx feels comfortable broadcasting that information > (since it can't trust that RDy will keep it confidential) and RDy feels > comfortable using that information even without trusting it (since it has no > reason to believe ADx is telling the truth). > > Now... this all doesn't sound like it should new. I'm vaguely reminded of > W3C's PICS (which died quietly after negligible adoption), but there weren't > two active (and potentially liable...) entities involved in that, just the > single provider and user. Surely there are other examples? > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0015173fe5b07004a904756422d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Oct 7, 2009 at 11:13 PM, Joshua Bell <josh@lindenlab.com> wrote:
=

VW1 and VW2 want to enable inter-VW tourism (i.e. AD1 agents can visit RD2). VW2 has a policy that they only allow in users of a certain quality (e.g. "speaks Latin"). Only a subset of AD1 agents have t= hat quality. Therefore, RD2 would only accept teleports of AD1 agents that have that quality (based on the sort of handshake discussed earlier in this thread). However, RD2 needs some trust relationship with AD1, otherwise malicious AD3 can come along which claims all of its users speak Latin and its users slip in. So VW1 and VW2 trade keys and sign some paperwork, and at that point (while the lawyers are busy) they could handshake on sharing "agent linguistic information profile v2.3&= quot; data.


That's a great description of the ultimate interop= dystopia in which, through definition of arbitrary set membership criteria= by an arbitrary number of policy makers, the result of transitive policy t= ransference and policy intersection is that the set of visitable worlds is = the empty set.

Are we trying to create an interop protocol here, or a protocol for pre= venting interop?

I'm leaning ever more strongly towards David= 9;s position that only services should carry expressions of policy, not dom= ains, because in the direction in which this discussion is heading there wi= ll be no widespread interop at all.

Imagine if SMTP had been specified to manage a set of content-defining = keywords and to block anything unacceptable to an MTA's "policy&qu= ot; based on such tagged content.=A0 And then (this is the killer), imagine= if sources of email had to adhere to such tag policies transitively= .=A0 There would either be no email except from closed groups, or the whole= tagging thing would be such a farce that it would be ignored.

For now, I'm affirming even more strongly Vaughn's principle of= advisary policy only=A0 ---=A0 http://www.ietf.org/mail-archive/we= b/ogpx/current/msg00524.html .=A0 Anything else is a recipe for buildin= g walled gardens and widespread denial of interop through contagion.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

On Wed, Oct 7, 2009= at 11:13 PM, Joshua Bell <josh@lindenlab.com> wrote:
On Wed, Oct 7, 2009 at 2:07 PM, Meadhbh Hamrick= <meadhbh.siobhan@gmail.com> wrote:
oh. hey. so i was just thinking about the "should we define global
keys for region meta-data?" question.

i think if we were to move forward with the AD telling the RD what
it's concerned about plan, we _should_ have global identifiers. i just<= br> think that if everyone had different identifiers for the same concept,
you would get protocol interop, but you would still have systems that
don't know what each other are talking about.
Thinking while I type here - these aren't finished thoughts, jus= t some brainstorms:

So fundamental to this, we're talking about = one system making policy decisions based on data from another system that&#= 39;s in a different trust domain (e.g. separate organizations). That implie= s to me that they must have done an out-of-band trust negotiation, otherwis= e they have no reason to, er, trust the data, so the policy decision is adv= isory at best. And at that point, wouldn't we assume they're attemp= ting to actively enable system interop and would therefore also have that o= pportunity to agree on a concept/identifier set? IMHO, that wouldn't li= ve in the protocol itself, but perhaps a standard set of interchange profil= es...

Sample scenario (using the VW1=3DAD1+RD1, VW2=3DAD2+RD2 rough terminolo= gy we've been batting about):

VW1 and VW2 want to enable inter-V= W tourism (i.e. AD1 agents can visit RD2). VW2 has a policy that they only = allow in users of a certain quality (e.g. "speaks Latin"). Only a= subset of AD1 agents have that quality. Therefore, RD2 would only accept t= eleports of AD1 agents that have that quality (based on the sort of handsha= ke discussed earlier in this thread). However, RD2 needs some trust relatio= nship with AD1, otherwise malicious AD3 can come along which claims all of = its users speak Latin and its users slip in. So VW1 and VW2 trade keys and = sign some paperwork, and at that point (while the lawyers are busy) they co= uld handshake on sharing "agent linguistic information profile v2.3&qu= ot; data.

On the other hand, there might be more hard-core requirements (age, sec= urity clearance, etc) that would use different profiles.

Hopefully = there's also the nil-trust case where this information might be shared = on a purely informational basis - e.g. even ADx asserts some quality about = an agent to RDy, ADx feels comfortable broadcasting that information (since= it can't trust that RDy will keep it confidential) and RDy feels comfo= rtable using that information even without trusting it (since it has no rea= son to believe ADx is telling the truth).

Now... this all doesn't sound like it should new. I'm vaguely r= eminded of W3C's PICS (which died quietly after negligible adoption), b= ut there weren't two active (and potentially liable...) entities involv= ed in that, just the single provider and user. Surely there are other examp= les?


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--0015173fe5b07004a904756422d5-- From meadhbh.siobhan@gmail.com Wed Oct 7 22:35:09 2009 Return-Path: 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 26E8628C1F3 for ; Wed, 7 Oct 2009 22:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 0QYFqjMMRXTN for ; Wed, 7 Oct 2009 22:35:08 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 41F9128C1F1 for ; Wed, 7 Oct 2009 22:35:08 -0700 (PDT) Received: by pxi6 with SMTP id 6so6417247pxi.32 for ; Wed, 07 Oct 2009 22:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pY8+xhUiM/0iM+GAXt3BALVA1R30iSLYicMx67F3a54=; b=L9SpY5CB8ysU2kBBzcJOV5i3BJR3FoG7qfJJymKgrraB3jPQscYKT9t39sd7VaHOnY gHvLY0j+H/OGGzCUVVJocn3eCJQ/4hgvIyJfUYLfW10HSdZsR8fv34avNw67E9K4cKBu IhFC7ZholLOzhiEMivslpvabtTgxK0Ow+BSR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LKtNma46IOeEXVyNrffy8vfV0cj4fTX+X2bU8Dia1P/GQFWEudO/foEjrDRVVLA58L CtX9PBuq7Yr9QeBKtzVmZXFjd4UuBs0ctK7RHGbRszESmJ+kfCO8Zh7c9CWrrL0l4o0G fgQ4Kxr6pIxi0HJTu+0YsB1gJ+3myfKV2lMxg= MIME-Version: 1.0 Received: by 10.114.44.14 with SMTP id r14mr1504940war.196.1254980206863; Wed, 07 Oct 2009 22:36:46 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A1BA1FA@GVW0433EXB.americas.hpqcorp.net> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A1BA1FA@GVW0433EXB.americas.hpqcorp.net> Date: Wed, 7 Oct 2009 22:36:46 -0700 Message-ID: From: Meadhbh Hamrick To: "Dickson, Mike (ISS Software)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Infinity Linden , "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 05:35:09 -0000 the way that my employer plans to deploy AD's and RD's is that the AD will be the entity that has a relationship with the user. _it_ is responsible for ensuring that the little ones don't run afoul of the local obscenity regulations, because _it_ is the one that provides access to the regions. we _could_ say that it's the region's responsibility to know the agent domain's policy, and that the region needs to block access to the user when the agent domain tells it that the user in question is underage, but that's the scenario we were trying to avoid: leaking information about the user to the region domain. also, i think under current US law, this might change the relationship between the RD and the AD with respect to the nature of agency between the two. but, IANAL, so i'm not an expert on that topic. but at the end of the day, if i'm an agent domain, and i have a user whom i know is 15 and a US resident, i would really like to make the decision myself about whether i even want to start rezzing the user's avatar in a region. and to make that decision, i will want to know what the region's maturity level is set to. -cheers -meadhbh / infinity On Wed, Oct 7, 2009 at 6:17 PM, Dickson, Mike (ISS Software) wrote: > Meadbah wrote: > > > > i still like this scheme because a) it's really similar to the way > > seed caps work, b) it adds flexibility to our system(s), and c) it > > does what i was hoping... gives the AD the ability to make policy > > decisions (like am i going to let this 15 year old user access > > material that may land me in hot water with the local authorities.) > > > > I may be mis-understanding all this since I=92m still trying to come up t= o > speed but isn=92t it the region that=92s making the policy decision here = to > allow/disallow a connect given what AD is representing about the user?=A0= And > yes, I agree that for this to work there must be trust established betwee= n > the services involved.=A0 I=92m just confused by the above statement sinc= e it > implies the AD is making a policy decision while it=92s really the RD tha= t has > the content (and hence the possible issue).=A0 And the RD and AD may be r= un by > two different entities=85. > > > > Mike > > From magnus.zeisig@iis.se Thu Oct 8 01:47:06 2009 Return-Path: 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 B0FDC3A69A1 for ; Thu, 8 Oct 2009 01:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.842 X-Spam-Level: X-Spam-Status: No, score=-4.842 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003] 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 3rglcOIEDvld for ; Thu, 8 Oct 2009 01:47:05 -0700 (PDT) Received: from cleaner.prod.iis.se (cleaner.prod.iis.se [212.247.7.212]) by core3.amsl.com (Postfix) with ESMTP id 5D17A3A6885 for ; Thu, 8 Oct 2009 01:47:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cleaner.prod.iis.se (Postfix) with ESMTP id AF050A802F; Thu, 8 Oct 2009 08:48:43 +0000 (UTC) Received: from cleaner.prod.iis.se ([127.0.0.1]) by localhost (cleaner.prod.iis.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04886-04; Thu, 8 Oct 2009 08:48:35 +0000 (UTC) Received: from pgpkeys.office.nic.se (pgpkeys.office.nic.se [212.247.204.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cleaner.prod.iis.se (Postfix) with ESMTP id 7BCDFA8003; Thu, 8 Oct 2009 08:48:35 +0000 (UTC) Received: from EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) by pgpkeys.office.nic.se (PGP Universal service); Thu, 08 Oct 2009 10:48:35 +0200 X-PGP-Universal: processed; by pgpkeys.office.nic.se on Thu, 08 Oct 2009 10:48:35 +0200 Received: from Exchange2k7.office.nic.se ([169.254.1.222]) by EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) with mapi; Thu, 8 Oct 2009 10:48:34 +0200 From: Magnus Zeisig To: Carlo Wood , Infinity Linden Date: Thu, 8 Oct 2009 10:48:33 +0200 Thread-Topic: [ogpx] Protocol for permitting policy decisions Thread-Index: AcpHjZ/dn/0M4yr0TcCYhjtDQY9t6gAZSWyg Message-ID: <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> In-Reply-To: <20091007203535.GA13882@alinoe.com> Accept-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-pgp-encoding-version: 2.0.2 x-pgp-mapi-encoding-version: 2.5.0 x-pgp-encoding-format: Partitioned x-pgp-universal-saved-content-codepage: utf-8 acceptlanguage: sv-SE MIME-Version: 1.0 Content-Language: sv-SE Content-Type: multipart/alternative; boundary="_000_983F17705339E24699AA251B458249B50CC48CB683EXCHANGE2K7of_" X-Virus-Scanned: Debian amavisd-new at cleaner.prod.iis.se Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 08:47:06 -0000 --_000_983F17705339E24699AA251B458249B50CC48CB683EXCHANGE2K7of_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkkgYW0g c3Ryb25nbHkgaW4gZmF2b3VyIG9mIGxlYXZpbmcgcG9saWN5IGRlc2Npc2lvbnMgdG8gdGhlIFJE LCBidXQgc2luY2UgdGhlcmUgc2VlbXMgdG8gYmUgYSBuZWVkIGZvciBhdCBsZWFzdCBzb21lIEFE IG1hbmFnZXJzIHRvIGJlIGFibGUgdG8gbWFrZSBwb2xpY3kgZGVjaXNpb25zIGFzIHdlbGwsIEkg Z3Vlc3MgdGhlIHByb3RvY29sIGhhbmRzaGFrZSBuZWVkIGV2ZW4gbW9yZSBmbGV4aWJpbGl0eSB0 aGFuIHRoZSB2ZXJzaW9ucyBzY2V0Y2hlZCBvbiBieSBNZWFkaGJoLCBDYXJsbyBhbmQgbWUgc28g ZmFyLiBJIHdpbGwgYWRhcHQgdGhlIGRpYWdyYW0gc3R5bGUgb2YgTWVhZGhiaCBhbmQgQ2FybG8g KGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vZ3B4L2N1cnJlbnQvbXNnMDA1 MjAuaHRtbCksIHNpbmNlIGl0J3MgbW9yZSByZWFkYWJsZSB0aGFuIG15IHRleHQtZmxvdyB2YXJp YW50LiBBbHNvLCBJIHdpbGwgbGVhdmUgb3V0IHBhcmFtZXRlciBleGFtcGxlcyBzaW5jZSB0aGVy ZSBzZWVtIHRvIGJlIGEgcmlzayBwZW9wbGUgZ2V0IGhvb2tlZCBvbiBpZiBhIGNlcnRhaW4gcGFy YW1ldGVyIHNob3VsZCBiZSBpbmNsdWRlZCBvciBub3QsIHJhdGhlciB0aGFuIHRoZSBwb3NzaWJp bGl0eSBvZiBoYW5kbGluZyBhbnkgcGFyYW1ldGVyLg0KDQpJIG1heSBiZSBwYXJhbm9pZCwgYnV0 IEkgc3RpbGwgcHJlZmVyIGFnZW50IGRvbWFpbnMgdG8gYmUgYWxsb3dlZCwgYnV0IG5vdCBmb3Jj ZWQgYnkgcHJvdG9jb2wsIHRvIHJlZHVjZSB0aGUgZGlzc2VtaW5hdGlvbiBvZiBpbmZvcm1hdGlv biBhYm91dCB0aGVpciBjbGllbnRzIGFzIGZhciBhcyBwb3NzaWJsZSwgYW5kIHRoZXJlIENhcmxv J3MgQU5EIHZlcnNpb24gaW4gdGhlIHJlc3BvbnNlIGlzIGEgZ29vZCBzdGVwIGZvcndhcmQgKGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vZ3B4L2N1cnJlbnQvbXNnMDA1MjAu aHRtbCkuIFdlIG1pZ2h0IGV2ZW4gd2luZCB1cCB3aXRoIG5lZ290aWF0aW9ucyB3aGVyZSBvbmUg ZG9tYWluIHJlcXVlc3RzIHRoZSBhY3R1YWwgdmFsdWVzIHdoaWxlIHRoZSBvdGhlciBkb21haW4g b25seSB3YW50cyB0byBkaXNzZW1pbmF0ZSBhIHJlcGx5IHRvIGlmIGl0IGZpdHMgYSByYW5nZSBm b3Igb25lIG9yIG1vcmUgb2YgdGhlIHJlcXVlc3RlZCBwYXJhbWV0ZXJzLg0KDQpBRCAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKG5hbWUsIDxSRGtleTE/LCBSRGtleTI/PiktLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0+IFJEDQpBRCA8LS0obmFtZSwgPFJEdmFsdWUxLCBSRHZhbHVlMiwgQURrZXkx PywgQURrZXkyPywgYWdlbnRrZXkxPywgYWdlbnRrZXkyPz4pLS0tIFJEDQpBRCAtLShuYW1lLCA8 UkR2YWx1ZXMgT0ssIEFEdmFsdWUxLCBBRHZhbHVlMiwgYWdlbnR2YWx1ZTEsIGFnZW50a2V5MiBy YW5nZT8+KS0+IFJEDQpBRCA8LS0tLS0tLS0tLShuYW1lLCA8QUR2YWx1ZXMgT0ssIGFnZW50dmFs dWUxIE9LLCBhZ2VudGtleTIgcmFuZ2U+KS0tLS0tLS0tLS0tIFJEDQpBRCAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKG5hbWUsIGFnZW50a2V5MiBPSyktLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0+IFJEDQpBRCA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0obmFtZSwgcmV6IGNh cCktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFJEDQoNCkluIHRoaXMgZXhhbXBsZSwg UkQgbWlnaHQgaGF2ZSByZWZ1c2VkIGdpdmluZyB0aGUgcmVxdWlyZWQgcmFuZ2UgZm9yIGFnZW50 dmFsdWUyLCBlaXRoZXIgYmVjYXVzZSBpdCB0ZWNobmljYWxseSBkb2Vzbid0IHN1cHBvcnQgdGhh dCBraW5kIG9mIG5lZ290aWF0aW9uIG9yIGJlY2F1c2Ugb2YgcG9saWN5LCBpbiBlaXRoZXIgY2Fz ZSBvZiB3aGljaCB0aGUgcmV6IGNhcCB3b3VsZCBoYXZlIGZhaWxlZC4gSXQgbWlnaHQgb24gdGhl IG90aGVyIGhhbmQgaW5zdGVhZCBhbHJlYWR5IGZyb20gdGhlIGJlZ2lubmluZyBoYXZlIHN1cHBs aWVkIHRoZSByZXF1aXJlZCByYW5nZXMgaW5zdGVhZCBvZiBhc2tpbmcgZm9yIHRoZSBhY3R1YWwg dmFsdWUuIEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCBpZiB0aGUgcHJvdG9jb2wgd291bGQgZW5h YmxlIGVpdGhlciBvZiB0aGVzZSBjYXNlcyBmb3IgbWF4aW11bSBmbGV4aWJpbGl0eS4NCg0KSXQg bWF5IGFsc28gYmUgYW4gaWRlYSB0byBwZXJtaXQgY2FjaGluZyBvZiBhdCBsZWFzdCBBRC0gYW5k IFJELXBhcmFtZXRlcnMgb3IgZXZhbHVhdGlvbnMgb2YgdGhlbSwgZXNwZWNpYWxseSBpZiB3ZSdy ZSB0YWxraW5nIGV4dGVuc2l2ZSBzZXRzIHdpdGggcGVyaGFwcyBodW5kcmVkcyBvZiBwYXJhbWV0 ZXJzLiBTaW5jZSB0aGUgQURzIGFuZCBSRHMgc2hvdWxkIGJlIGZyZWUgdG8gdXBkYXRlIHRoZWly IG93biBwYXJhbWV0ZXJzIGF0IGFueSB0aW1lLCB0aGUgaGFuZHNoYWtlIGluIHRoYXQgY2FzZSBt dXN0IG9mIGNvdXJzZSBjb250YWluIGEgY2hlY2sgaWYgY2FjaGVkIHBhcmFtZXRlcnMgaGF2ZSBi ZWVuIHVwZGF0ZWQuIEFsc28sIGlmIGFuIEFEIG9yIFJEIHN1cHBvcnRzIHNldmVyYWwgc2V0cyBv ZiBwYXJhbWV0ZXJzIGRlcGVuZGluZyBvbiB3aGljaCBkb21haW4gb3Igc2VydmljZSBpdCBkZWFs cyB3aXRoLCBtZWFucyB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoZW0gYXJlIHJlcXVpcmVkLCBw ZXJoYXBzIHVzaW5nIHBvbGljeSBVUkkncyB0aGUgd2F5IE1lYWRoYmggc3VnZ2VzdGVkIChodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2dweC9jdXJyZW50L21zZzAwNTIzLmh0 bWwpLiBBIHBvbGljeSBjb3VsZCB0aGVuIGJhc2ljYWxseSBiZSBicm9rZW4gZG93biBpbnRvIGEg c2V0IG9mIG93biBwYXJhbWV0ZXIgdmFsdWVzIGFuZCByZXF1aXJlZCBwYXJhbWV0ZXIgcmFuZ2Vz IGZvciB0aGUgZG9tYWluIG9yIHNlcnZpY2UgY29ubmVjdGluZy4NCg0KSSBhbHNvIHRoaW5rLCBs aWtlIE1lYWRoYmggKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vZ3B4L2N1 cnJlbnQvbXNnMDA1MjMuaHRtbCksIHRoYXQgd2Ugd2lsbCBuZWVkIHRvIHN1Z2dlc3QsIGJ1dCBu b3QgcmVxdWlyZSwgYSBudW1iZXIgb2YgcGFyYW1ldGVyIG5hbWUgYW5kIGZvcm1hdHMgdG8gZmFj aWxpdGF0ZSBjb21tdW5pY2F0aW9uLCBzbyB0aGF0IG5vdCBlLmcuIFVTIGFuZCBVSyBkb21haW5z IGNhbid0IGNvbm5lY3QsIGJlY2F1c2Ugb25lIGFza3MgYWJvdXQgImNvbG9yIiBhbmQgdGhlIG90 aGVyIG9uZSBvbmx5IGNhbiByZXNwb25kIGFib3V0ICJjb2xvdXIiLg0KDQpCZXN0IHJlZ2FyZHMs DQoNCk1hZ251cw0KDQoNCi0gLS0tLS1VcnNwcnVuZ2xpZ3QgbWVkZGVsYW5kZS0tLS0tDQpGcsOl bjogQ2FybG8gV29vZCBbbWFpbHRvOmNhcmxvQGFsaW5vZS5jb21dDQpTa2lja2F0OiBkZW4gNyBv a3RvYmVyIDIwMDkgMjI6MzYNClRpbGw6IEluZmluaXR5IExpbmRlbg0KS29waWE6IE1hZ251cyBa ZWlzaWc7IG9ncHhAaWV0Zi5vcmcNCsOEbW5lOiBSZTogW29ncHhdIFByb3RvY29sIGZvciBwZXJt aXR0aW5nIHBvbGljeSBkZWNpc2lvbnMNCg0KT24gTW9uLCBPY3QgMDUsIDIwMDkgYXQgMTI6Mzk6 MzJQTSAtMDcwMCwgSW5maW5pdHkgTGluZGVuIHdyb3RlOg0KPiBvcHRpb24gMzogbXVsdGktbWVz c2FnZSBoYW5kc2hha2UNCj4NCj4gQUQgLS0tLS0tLS0tLS0tLS0tIChuYW1lKSAtLS0tLS0tLS0t LS0tPiBSRA0KPiBBRCA8LS0tLS0tLS0gKFgsIGFnZSA+IFg/IGNhcCkgLS0tLS0tLS0tIFJEDQo+ DQo+IEFEIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4gUkQgKGFnZSA+IFg/ IGNhcCkNCj4gQUQgPC0tLS0tLS0tLS0tLSAocmV6IGNhcCkgLS0tLS0tLS0tLS0tLSBSRA0KDQpO b3RlLCBhZ2FpbiwgdGhlIG5lZWQgZm9yIGEgZmxleGlibGUgcHJvdG9jb2wgbmVnb3RpYXRpb246 DQp3ZSBjYW4ndCBrbm93LCBhbHJlYWR5LCB3aGF0IGFsbCB3aWxsIGJlIG5lZWRlZC4NCg0KTmV2 ZXJ0aGVsZXNzLCB0aGUgbW9yZSBmbGV4aWJpbGl0eSB0aGUgYmV0dGVyIGltaG8uDQpJJ2QgcHJl ZmVyIHRvIHNlZSB0aGlzOg0KDQpBRCAtLS0tLS0obmFtZSwgPGxpc3Qgd2l0aCBrZXl3b3Jkcz4p IC0tLS0tLS0tLS0tPiBSRA0KQUQgPC0tLS0tKG5hbWUsIDxsaXN0IHdpdGgga2V5d29yZHMgKyBy YW5nZXM+KSAtLS0gUkQNCkFEIC0tLS0tLShuYW1lLCB5ZXMvbm8pLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0+IFJEDQpBRCA8LS0tLS0ocmV6IGNhcCkgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSBSRA0KDQpXaGVyZSBWV1JBUCB3aWxsIG5vdCBkZWZpbmUgd2hhdCBrZXl3b3JkcyBh cmUgcG9zc2libGUuDQoNCkhvd2V2ZXIsIGltcGxlbWVudGVycyBtaWdodCwgZm9yIGV4YW1wbGUs IGNob29zZSB0byB1c2UgJ0FHRScgYXMga2V5d29yZA0Kd2l0aCBhbiBpbnRlZ2VyIHJhbmdlLCBs ZWFkaW5nIHRvIGEgbXNnIGV4Y2hhbmdlIGxpa2UNCg0KQUQgLS0tLS0tKG5hbWUsIChBR0UpKSAt LS0tLS0tLS0tLT4gUkQNCkFEIDwtLS0tLShuYW1lLCAoQUdFLCAyMSkpIC0tLS0tLS0tIFJEDQpB RCAtLS0tLS0obmFtZSwgeWVzKS0tLS0tLS0tLS0tLS0tPiBSRA0KQUQgPC0tLS0tKHJleiBjYXAp IC0tLS0tLS0tLS0tLS0tLS0gUkQNCg0Kb3Igc29tZSBtaWdodCBpbXBsZW1lbnQNCg0KQUQgLS0t LS0tKG5hbWUsIChBR0UsIExJS0VTX0JVTk5JRVMpKSAtLS0tLS0tLS0tLT4gUkQNCkFEIDwtLS0t LShuYW1lLCAoQUdFLCAxMyksIFlFUykgLS0tLS0tLS0tLS0tLS0tLS0tIFJEDQpBRCAtLS0tLS0o bmFtZSwgeWVzLCB5ZXMpLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPiBSRA0KQUQgPC0tLS0tKHJl eiBjYXApIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gUkQNCg0KRm9yIHByaXZhY3kg cmVhc29ucywgSSB0aGluayBpdCB3b3VsZCBzdWZmaWNlIHRvDQpqdXN0IHNlbmQgdGhlIEFORCBv ZiBhbGwgJ3llcydzLCB0aHVzOg0KDQpBRCAtLS0tLS0obmFtZSwgKEFHRSwgTElLRVNfQlVOTklF UykpIC0tLS0tLS0tLS0tPiBSRA0KQUQgPC0tLS0tKG5hbWUsIChBR0UsIDEzKSwgWUVTKSAtLS0t LS0tLS0tLS0tLS0tLS0gUkQNCkFEIC0tLS0tLShuYW1lLCB5ZXMpLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0+IFJEDQpBRCA8LS0tLS0ocmV6IGNhcCkgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSBSRA0KDQpvciwNCg0KQUQgLS0tLS0tKG5hbWUsIChBR0UsIExJS0VTX0JVTk5J RVMpKSAtLS0tLS0tLS0tLT4gUkQNCkFEIDwtLS0tLShuYW1lLCAoQUdFLCAxMyksIERPTlRDQVJF KSAtLS0tLS0tLS0tLS0tIFJEDQpBRCAtLS0tLS0obmFtZSwgeWVzKS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPiBSRA0KQUQgPC0tLS0tKHJleiBjYXApIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gUkQNCg0KQWdhaW4sIG5laXRoZXIgJ0FHRScgbm9yICdMSUtFU19CVU5OSUVT Jywgd291bGQgYmUgZGVmaW5lZCBieSB1cywNCmJ1dCB3ZSB3b3VsZCBkZWZpbmUgaG93IHRvIGhh bmRsZSBpbnRlZ2VyIHJhbmdlcywgYm9vbGVhbnMsDQpkb24ndCBjYXJlcywgc3RyaW5nIGxpdGVy YWxzLCBhbmQgcGVyaGFwcyByZWd1bGFyIGV4cHJlc3Npb25zLg0KDQotIC0tDQpDYXJsbyBXb29k IDxjYXJsb0BhbGlub2UuY29tPg0KDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KVmVy c2lvbjogOS44LjMgKEJ1aWxkIDQwMjgpDQpDaGFyc2V0OiB1dGYtOA0KDQp3c0JWQXdVQlNzMm5Z ZTVNbFU5WHlhaVNBUWlKTEFmL2Z5ZTdIWDB2cDJKa1pGL3d1KzdGU1Z6WjJhbDNuS2NMDQpKaUIr WjFteFAzSUNpR1pydmRJb2pTQ0hMNStUOGsyM2NqOVE5Z2d6N3lRdjEyRWhSeW5xNHJtbFNmZ3M3 VGEvDQpjS3JLaDd2dlFIc1pzbnNhaUhhdzI5REEzMHJlalNKV2Fia1o1YzI5elVkMThsbDg2RVpy MHFJcVA5QnlJYk1KDQpScnBwR045OElhWWQzck9jbHpLMC9lM0xkUktBZ0xoZzFHb3R1ZFBLSjR2 VTdxSTNYVjZzS3d1YVVPeld6c1dtDQp0RHBjSHhjQ0hoRjlPNHVEc3RHRkF4YlBWdlpObnJtelFY UnpsUTZwYWptcHpUMGlVMjVrNzhZN2JsZHEvQm5kDQo2MElqOUdjb2ZvY2t2QnVXVlVpSURac3hx Wkc5ODJqbkRHejNEUUVvcmczOFh0QWJLaWVOOHc9PQ0KPTJOU3UNCi0tLS0tRU5EIFBHUCBTSUdO QVRVUkUtLS0tLQ0KDQoNCg== --_000_983F17705339E24699AA251B458249B50CC48CB683EXCHANGE2K7of_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+DQo8ZGl2Pi0tLS0t QkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS08L2Rpdj4NCjxkaXY+SGFzaDogU0hBMjU2PC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JIGFtIHN0cm9uZ2x5IGluIGZhdm91ciBvZiBs ZWF2aW5nIHBvbGljeSBkZXNjaXNpb25zIHRvIHRoZSBSRCwgYnV0IHNpbmNlIHRoZXJlIHNlZW1z IHRvIGJlIGEgbmVlZCBmb3IgYXQgbGVhc3Qgc29tZSBBRCBtYW5hZ2VycyB0byBiZSBhYmxlIHRv IG1ha2UgcG9saWN5IGRlY2lzaW9ucyBhcyB3ZWxsLCBJIGd1ZXNzIHRoZSBwcm90b2NvbCBoYW5k c2hha2UgbmVlZCBldmVuIG1vcmUgZmxleGliaWxpdHkgdGhhbiB0aGUgdmVyc2lvbnMgc2NldGNo ZWQNCm9uIGJ5IE1lYWRoYmgsIENhcmxvIGFuZCBtZSBzbyBmYXIuIEkgd2lsbCBhZGFwdCB0aGUg ZGlhZ3JhbSBzdHlsZSBvZiBNZWFkaGJoIGFuZCBDYXJsbyAoPGEgaHJlZj0iaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29ncHgvY3VycmVudC9tc2cwMDUyMC5odG1sIj5odHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2dweC9jdXJyZW50L21zZzAwNTIwLmh0 bWw8L2E+KSwgc2luY2UgaXQncyBtb3JlIHJlYWRhYmxlDQp0aGFuIG15IHRleHQtZmxvdyB2YXJp YW50LiBBbHNvLCBJIHdpbGwgbGVhdmUgb3V0IHBhcmFtZXRlciBleGFtcGxlcyBzaW5jZSB0aGVy ZSBzZWVtIHRvIGJlIGEgcmlzayBwZW9wbGUgZ2V0IGhvb2tlZCBvbiBpZiBhIGNlcnRhaW4gcGFy YW1ldGVyIHNob3VsZCBiZSBpbmNsdWRlZCBvciBub3QsIHJhdGhlciB0aGFuIHRoZSBwb3NzaWJp bGl0eSBvZiBoYW5kbGluZyBhbnkgcGFyYW1ldGVyLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+SSBtYXkgYmUgcGFyYW5vaWQsIGJ1dCBJIHN0aWxsIHByZWZlciBhZ2VudCBkb21haW5z IHRvIGJlIGFsbG93ZWQsIGJ1dCBub3QgZm9yY2VkIGJ5IHByb3RvY29sLCB0byByZWR1Y2UgdGhl IGRpc3NlbWluYXRpb24gb2YgaW5mb3JtYXRpb24gYWJvdXQgdGhlaXIgY2xpZW50cyBhcyBmYXIg YXMgcG9zc2libGUsIGFuZCB0aGVyZSBDYXJsbydzIEFORCB2ZXJzaW9uIGluIHRoZSByZXNwb25z ZSBpcyBhIGdvb2Qgc3RlcCBmb3J3YXJkICg8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvb2dweC9jdXJyZW50L21zZzAwNTIwLmh0bWwiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vZ3B4L2N1cnJlbnQvbXNnMDA1MjAuaHRtbDwvYT4pLg0K V2UgbWlnaHQgZXZlbiB3aW5kIHVwIHdpdGggbmVnb3RpYXRpb25zIHdoZXJlIG9uZSBkb21haW4g cmVxdWVzdHMgdGhlIGFjdHVhbCB2YWx1ZXMgd2hpbGUgdGhlIG90aGVyIGRvbWFpbiBvbmx5IHdh bnRzIHRvIGRpc3NlbWluYXRlIGEgcmVwbHkgdG8gaWYgaXQgZml0cyBhIHJhbmdlIGZvciBvbmUg b3IgbW9yZSBvZiB0aGUgcmVxdWVzdGVkIHBhcmFtZXRlcnMuPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5BRCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKG5hbWUsICZsdDtSRGtleTE/ LCBSRGtleTI/Jmd0OyktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7IFJEPC9kaXY+DQo8ZGl2 PkFEICZsdDstLShuYW1lLCAmbHQ7UkR2YWx1ZTEsIFJEdmFsdWUyLCBBRGtleTE/LCBBRGtleTI/ LCBhZ2VudGtleTE/LCBhZ2VudGtleTI/Jmd0OyktLS0gUkQ8L2Rpdj4NCjxkaXY+QUQgLS0obmFt ZSwgJmx0O1JEdmFsdWVzIE9LLCBBRHZhbHVlMSwgQUR2YWx1ZTIsIGFnZW50dmFsdWUxLCBhZ2Vu dGtleTIgcmFuZ2U/Jmd0OyktJmd0OyBSRDwvZGl2Pg0KPGRpdj5BRCAmbHQ7LS0tLS0tLS0tLShu YW1lLCAmbHQ7QUR2YWx1ZXMgT0ssIGFnZW50dmFsdWUxIE9LLCBhZ2VudGtleTIgcmFuZ2UmZ3Q7 KS0tLS0tLS0tLS0tIFJEPC9kaXY+DQo8ZGl2PkFEIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0obmFtZSwgYWdlbnRrZXkyIE9LKS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDsgUkQ8 L2Rpdj4NCjxkaXY+QUQgJmx0Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKG5hbWUsIHJl eiBjYXApLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSRDwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+SW4gdGhpcyBleGFtcGxlLCBSRCBtaWdodCBoYXZlIHJlZnVzZWQgZ2l2 aW5nIHRoZSByZXF1aXJlZCByYW5nZSBmb3IgYWdlbnR2YWx1ZTIsIGVpdGhlciBiZWNhdXNlIGl0 IHRlY2huaWNhbGx5IGRvZXNuJ3Qgc3VwcG9ydCB0aGF0IGtpbmQgb2YgbmVnb3RpYXRpb24gb3Ig YmVjYXVzZSBvZiBwb2xpY3ksIGluIGVpdGhlciBjYXNlIG9mIHdoaWNoIHRoZSByZXogY2FwIHdv dWxkIGhhdmUgZmFpbGVkLiBJdCBtaWdodCBvbiB0aGUgb3RoZXINCmhhbmQgaW5zdGVhZCBhbHJl YWR5IGZyb20gdGhlIGJlZ2lubmluZyBoYXZlIHN1cHBsaWVkIHRoZSByZXF1aXJlZCByYW5nZXMg aW5zdGVhZCBvZiBhc2tpbmcgZm9yIHRoZSBhY3R1YWwgdmFsdWUuIEkgdGhpbmsgaXQgd291bGQg YmUgZ29vZCBpZiB0aGUgcHJvdG9jb2wgd291bGQgZW5hYmxlIGVpdGhlciBvZiB0aGVzZSBjYXNl cyBmb3IgbWF4aW11bSBmbGV4aWJpbGl0eS48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2 Pkl0IG1heSBhbHNvIGJlIGFuIGlkZWEgdG8gcGVybWl0IGNhY2hpbmcgb2YgYXQgbGVhc3QgQUQt IGFuZCBSRC1wYXJhbWV0ZXJzIG9yIGV2YWx1YXRpb25zIG9mIHRoZW0sIGVzcGVjaWFsbHkgaWYg d2UncmUgdGFsa2luZyBleHRlbnNpdmUgc2V0cyB3aXRoIHBlcmhhcHMgaHVuZHJlZHMgb2YgcGFy YW1ldGVycy4gU2luY2UgdGhlIEFEcyBhbmQgUkRzIHNob3VsZCBiZSBmcmVlIHRvIHVwZGF0ZSB0 aGVpciBvd24gcGFyYW1ldGVycyBhdCBhbnkNCnRpbWUsIHRoZSBoYW5kc2hha2UgaW4gdGhhdCBj YXNlIG11c3Qgb2YgY291cnNlIGNvbnRhaW4gYSBjaGVjayBpZiBjYWNoZWQgcGFyYW1ldGVycyBo YXZlIGJlZW4gdXBkYXRlZC4gQWxzbywgaWYgYW4gQUQgb3IgUkQgc3VwcG9ydHMgc2V2ZXJhbCBz ZXRzIG9mIHBhcmFtZXRlcnMgZGVwZW5kaW5nIG9uIHdoaWNoIGRvbWFpbiBvciBzZXJ2aWNlIGl0 IGRlYWxzIHdpdGgsIG1lYW5zIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlbSBhcmUgcmVxdWly ZWQsDQpwZXJoYXBzIHVzaW5nIHBvbGljeSBVUkkncyB0aGUgd2F5IE1lYWRoYmggc3VnZ2VzdGVk ICg8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2dweC9jdXJy ZW50L21zZzAwNTIzLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9v Z3B4L2N1cnJlbnQvbXNnMDA1MjMuaHRtbDwvYT4pLiBBIHBvbGljeSBjb3VsZCB0aGVuIGJhc2lj YWxseSBiZSBicm9rZW4gZG93biBpbnRvIGEgc2V0IG9mDQpvd24gcGFyYW1ldGVyIHZhbHVlcyBh bmQgcmVxdWlyZWQgcGFyYW1ldGVyIHJhbmdlcyBmb3IgdGhlIGRvbWFpbiBvciBzZXJ2aWNlIGNv bm5lY3RpbmcuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JIGFsc28gdGhpbmssIGxp a2UgTWVhZGhiaCAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L29ncHgvY3VycmVudC9tc2cwMDUyMy5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvb2dweC9jdXJyZW50L21zZzAwNTIzLmh0bWw8L2E+KSwgdGhhdCB3ZSB3aWxsIG5l ZWQgdG8gc3VnZ2VzdCwgYnV0IG5vdCByZXF1aXJlLCBhIG51bWJlciBvZiBwYXJhbWV0ZXIgbmFt ZSBhbmQgZm9ybWF0cw0KdG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uLCBzbyB0aGF0IG5vdCBl LmcuIFVTIGFuZCBVSyBkb21haW5zIGNhbid0IGNvbm5lY3QsIGJlY2F1c2Ugb25lIGFza3MgYWJv dXQgJnF1b3Q7Y29sb3ImcXVvdDsgYW5kIHRoZSBvdGhlciBvbmUgb25seSBjYW4gcmVzcG9uZCBh Ym91dCAmcXVvdDtjb2xvdXImcXVvdDsuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5C ZXN0IHJlZ2FyZHMsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5NYWdudXM8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4tIC0tLS0tVXJzcHJ1 bmdsaWd0IG1lZGRlbGFuZGUtLS0tLTwvZGl2Pg0KPGRpdj5GcsOlbjogQ2FybG8gV29vZCBbPGEg aHJlZj0ibWFpbHRvOmNhcmxvQGFsaW5vZS5jb20iPm1haWx0bzpjYXJsb0BhbGlub2UuY29tPC9h Pl0gPC9kaXY+DQo8ZGl2PlNraWNrYXQ6IGRlbiA3IG9rdG9iZXIgMjAwOSAyMjozNjwvZGl2Pg0K PGRpdj5UaWxsOiBJbmZpbml0eSBMaW5kZW48L2Rpdj4NCjxkaXY+S29waWE6IE1hZ251cyBaZWlz aWc7IG9ncHhAaWV0Zi5vcmc8L2Rpdj4NCjxkaXY+w4RtbmU6IFJlOiBbb2dweF0gUHJvdG9jb2wg Zm9yIHBlcm1pdHRpbmcgcG9saWN5IGRlY2lzaW9uczwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+T24gTW9uLCBPY3QgMDUsIDIwMDkgYXQgMTI6Mzk6MzJQTSAtMDcwMCwgSW5maW5pdHkg TGluZGVuIHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7IG9wdGlvbiAzOiBtdWx0aS1tZXNzYWdlIGhh bmRzaGFrZTwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IEFEIC0tLS0tLS0tLS0t LS0tLSAobmFtZSkgLS0tLS0tLS0tLS0tLSZndDsgUkQ8L2Rpdj4NCjxkaXY+Jmd0OyBBRCAmbHQ7 LS0tLS0tLS0gKFgsIGFnZSAmZ3Q7IFg/IGNhcCkgLS0tLS0tLS0tIFJEPC9kaXY+DQo8ZGl2PiZn dDsgPC9kaXY+DQo8ZGl2PiZndDsgQUQgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tJmd0OyBSRCAoYWdlICZndDsgWD8gY2FwKTwvZGl2Pg0KPGRpdj4mZ3Q7IEFEICZsdDstLS0t LS0tLS0tLS0gKHJleiBjYXApIC0tLS0tLS0tLS0tLS0gUkQ8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k aXY+DQo8ZGl2Pk5vdGUsIGFnYWluLCB0aGUgbmVlZCBmb3IgYSBmbGV4aWJsZSBwcm90b2NvbCBu ZWdvdGlhdGlvbjo8L2Rpdj4NCjxkaXY+d2UgY2FuJ3Qga25vdywgYWxyZWFkeSwgd2hhdCBhbGwg d2lsbCBiZSBuZWVkZWQuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5OZXZlcnRoZWxl c3MsIHRoZSBtb3JlIGZsZXhpYmlsaXR5IHRoZSBiZXR0ZXIgaW1oby48L2Rpdj4NCjxkaXY+SSdk IHByZWZlciB0byBzZWUgdGhpczo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkFEIC0t LS0tLShuYW1lLCAmbHQ7bGlzdCB3aXRoIGtleXdvcmRzJmd0OykgLS0tLS0tLS0tLS0mZ3Q7IFJE PC9kaXY+DQo8ZGl2PkFEICZsdDstLS0tLShuYW1lLCAmbHQ7bGlzdCB3aXRoIGtleXdvcmRzICYj NDM7IHJhbmdlcyZndDspIC0tLSBSRDwvZGl2Pg0KPGRpdj5BRCAtLS0tLS0obmFtZSwgeWVzL25v KS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0OyBSRDwvZGl2Pg0KPGRpdj5BRCAmbHQ7LS0t LS0ocmV6IGNhcCkgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSRDwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+V2hlcmUgVldSQVAgd2lsbCBub3QgZGVmaW5lIHdoYXQga2V5 d29yZHMgYXJlIHBvc3NpYmxlLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SG93ZXZl ciwgaW1wbGVtZW50ZXJzIG1pZ2h0LCBmb3IgZXhhbXBsZSwgY2hvb3NlIHRvIHVzZSAnQUdFJyBh cyBrZXl3b3JkPC9kaXY+DQo8ZGl2PndpdGggYW4gaW50ZWdlciByYW5nZSwgbGVhZGluZyB0byBh IG1zZyBleGNoYW5nZSBsaWtlPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5BRCAtLS0t LS0obmFtZSwgKEFHRSkpIC0tLS0tLS0tLS0tJmd0OyBSRDwvZGl2Pg0KPGRpdj5BRCAmbHQ7LS0t LS0obmFtZSwgKEFHRSwgMjEpKSAtLS0tLS0tLSBSRDwvZGl2Pg0KPGRpdj5BRCAtLS0tLS0obmFt ZSwgeWVzKS0tLS0tLS0tLS0tLS0tJmd0OyBSRDwvZGl2Pg0KPGRpdj5BRCAmbHQ7LS0tLS0ocmV6 IGNhcCkgLS0tLS0tLS0tLS0tLS0tLSBSRDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+ b3Igc29tZSBtaWdodCBpbXBsZW1lbnQ8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkFE IC0tLS0tLShuYW1lLCAoQUdFLCBMSUtFU19CVU5OSUVTKSkgLS0tLS0tLS0tLS0mZ3Q7IFJEPC9k aXY+DQo8ZGl2PkFEICZsdDstLS0tLShuYW1lLCAoQUdFLCAxMyksIFlFUykgLS0tLS0tLS0tLS0t LS0tLS0tIFJEPC9kaXY+DQo8ZGl2PkFEIC0tLS0tLShuYW1lLCB5ZXMsIHllcyktLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0mZ3Q7IFJEPC9kaXY+DQo8ZGl2PkFEICZsdDstLS0tLShyZXogY2FwKSAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFJEPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj5Gb3IgcHJpdmFjeSByZWFzb25zLCBJIHRoaW5rIGl0IHdvdWxkIHN1ZmZpY2UgdG88 L2Rpdj4NCjxkaXY+anVzdCBzZW5kIHRoZSBBTkQgb2YgYWxsICd5ZXMncywgdGh1czo8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkFEIC0tLS0tLShuYW1lLCAoQUdFLCBMSUtFU19CVU5O SUVTKSkgLS0tLS0tLS0tLS0mZ3Q7IFJEPC9kaXY+DQo8ZGl2PkFEICZsdDstLS0tLShuYW1lLCAo QUdFLCAxMyksIFlFUykgLS0tLS0tLS0tLS0tLS0tLS0tIFJEPC9kaXY+DQo8ZGl2PkFEIC0tLS0t LShuYW1lLCB5ZXMpLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7IFJEPC9kaXY+DQo8 ZGl2PkFEICZsdDstLS0tLShyZXogY2FwKSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t IFJEPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5vciw8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2PkFEIC0tLS0tLShuYW1lLCAoQUdFLCBMSUtFU19CVU5OSUVTKSkgLS0tLS0t LS0tLS0mZ3Q7IFJEPC9kaXY+DQo8ZGl2PkFEICZsdDstLS0tLShuYW1lLCAoQUdFLCAxMyksIERP TlRDQVJFKSAtLS0tLS0tLS0tLS0tIFJEPC9kaXY+DQo8ZGl2PkFEIC0tLS0tLShuYW1lLCB5ZXMp LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7IFJEPC9kaXY+DQo8ZGl2PkFEICZsdDst LS0tLShyZXogY2FwKSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFJEPC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5BZ2FpbiwgbmVpdGhlciAnQUdFJyBub3IgJ0xJS0VTX0JV Tk5JRVMnLCB3b3VsZCBiZSBkZWZpbmVkIGJ5IHVzLDwvZGl2Pg0KPGRpdj5idXQgd2Ugd291bGQg ZGVmaW5lIGhvdyB0byBoYW5kbGUgaW50ZWdlciByYW5nZXMsIGJvb2xlYW5zLDwvZGl2Pg0KPGRp dj5kb24ndCBjYXJlcywgc3RyaW5nIGxpdGVyYWxzLCBhbmQgcGVyaGFwcyByZWd1bGFyIGV4cHJl c3Npb25zLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+LSAtLSA8L2Rpdj4NCjxkaXY+ Q2FybG8gV29vZCAmbHQ7Y2FybG9AYWxpbm9lLmNvbSZndDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k aXY+DQo8ZGl2Pi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tPC9kaXY+DQo8ZGl2PlZlcnNp b246IDkuOC4zIChCdWlsZCA0MDI4KTwvZGl2Pg0KPGRpdj5DaGFyc2V0OiB1dGYtODwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+d3NCVkF3VUJTczJuWWU1TWxVOVh5YWlTQVFpSkxBZi9m eWU3SFgwdnAySmtaRi93dSYjNDM7N0ZTVnpaMmFsM25LY0w8L2Rpdj4NCjxkaXY+SmlCJiM0Mzta MW14UDNJQ2lHWnJ2ZElvalNDSEw1JiM0MztUOGsyM2NqOVE5Z2d6N3lRdjEyRWhSeW5xNHJtbFNm Z3M3VGEvPC9kaXY+DQo8ZGl2PmNLcktoN3Z2UUhzWnNuc2FpSGF3MjlEQTMwcmVqU0pXYWJrWjVj Mjl6VWQxOGxsODZFWnIwcUlxUDlCeUliTUo8L2Rpdj4NCjxkaXY+UnJwcEdOOThJYVlkM3JPY2x6 SzAvZTNMZFJLQWdMaGcxR290dWRQS0o0dlU3cUkzWFY2c0t3dWFVT3pXenNXbTwvZGl2Pg0KPGRp dj50RHBjSHhjQ0hoRjlPNHVEc3RHRkF4YlBWdlpObnJtelFYUnpsUTZwYWptcHpUMGlVMjVrNzhZ N2JsZHEvQm5kPC9kaXY+DQo8ZGl2PjYwSWo5R2NvZm9ja3ZCdVdWVWlJRFpzeHFaRzk4MmpuREd6 M0RRRW9yZzM4WHRBYktpZU44dz09PC9kaXY+DQo8ZGl2Pj0yTlN1PC9kaXY+DQo8ZGl2Pi0tLS0t RU5EIFBHUCBTSUdOQVRVUkUtLS0tLTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_983F17705339E24699AA251B458249B50CC48CB683EXCHANGE2K7of_-- From morgaine.dinova@googlemail.com Thu Oct 8 02:40:19 2009 Return-Path: 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 54E633A6910 for ; Thu, 8 Oct 2009 02:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.745 X-Spam-Level: X-Spam-Status: No, score=-0.745 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, TRACKER_ID=2.003] 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 gR0wWad2FK2q for ; Thu, 8 Oct 2009 02:40:17 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 176FD28C120 for ; Thu, 8 Oct 2009 02:40:16 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so1381658eye.51 for ; Thu, 08 Oct 2009 02:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=wgBpJdTHRlO96fhr1UIcWIrfFTuhqJzX5p3CDdIRkIc=; b=CQWkM7pn1w+iRT7jByacw0lfJ4nV/XSU9NCyO0m91TMnttB5RyT+iOs6GeRAue1a2h qRrbo17GM223/LqVPuA3YtusY749sgP4Z/s5D7ekuIZE4Wc7YFMMutWFLRbJrjfyIQsu WEZRr4jpR5Lt0t5KhM7HDCa8jvowyXw2XrfZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xf/wzsBO+PZy52iqrEMkPNkRQnURo8ms0KPP+PE0wzv17Lm2p12n0xUKRRHQQnrQrF fAKT/uNHlwsMhmaKc4Lgr8l/bGSAY8emsZ1G5RlU4pqRftNy6w+ERE3vdoyaLvb3gd4p e4BF8r+4zwlx/c6w9Uq6XcB/Ho0LKnqqpi6FI= MIME-Version: 1.0 Received: by 10.211.144.9 with SMTP id w9mr7906955ebn.45.1254994914542; Thu, 08 Oct 2009 02:41:54 -0700 (PDT) In-Reply-To: <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> Date: Thu, 8 Oct 2009 10:41:54 +0100 Message-ID: From: Morgaine To: Magnus Zeisig Content-Type: multipart/alternative; boundary=00504502cfb51387ef04756946f2 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 09:40:19 -0000 --00504502cfb51387ef04756946f2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Magnus, If ADs are involved in region policy, then in the multi-world deployment pattern, AD2 will have to be consulted when agent A1 teleports from RD1 to RD2, because AD2 will be involved in region policy too. It's symmetric wit= h AD1. This is what Joshua wanted to avoid, and it can only be avoided by not giving ADs policy control over regions, otherwise symmetry requires that AD= 2 be consulted as well. It's this kind of problem that reinforces what David's been saying about th= e right mess we currently have when talking about domains determining policy. The AD/RD split was reasonably adequate when OGP was only extending a singl= e world with policy-free regions, but it is insufficient to do a good job onc= e we get into multi-world deployments with more complex service and policy patterns which require much more flexibility. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I am strongly in favour of leaving policy descisions to the RD, but since > there seems to be a need for at least some AD managers to be able to make > policy decisions as well, I guess the protocol handshake need even more > flexibility than the versions scetched on by Meadhbh, Carlo and me so far= . I > will adapt the diagram style of Meadhbh and Carlo ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html), since > it's more readable than my text-flow variant. Also, I will leave out > parameter examples since there seem to be a risk people get hooked on if = a > certain parameter should be included or not, rather than the possibility = of > handling any parameter. > > I may be paranoid, but I still prefer agent domains to be allowed, but no= t > forced by protocol, to reduce the dissemination of information about thei= r > clients as far as possible, and there Carlo's AND version in the response= is > a good step forward ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html). We migh= t > even wind up with negotiations where one domain requests the actual value= s > while the other domain only wants to disseminate a reply to if it fits a > range for one or more of the requested parameters. > > AD -------------------------(name, RDkey2?>)------------------------> RD > AD <--(name, agentkey2?>)--- RD > AD --(name, range?>)-> RD > AD <----------(name, range>)----------- RD > AD ----------------------------(name, agentkey2 > OK)---------------------------> RD > AD <-----------------------------(name, rez > cap)------------------------------- RD > > In this example, RD might have refused giving the required range for > agentvalue2, either because it technically doesn't support that kind of > negotiation or because of policy, in either case of which the rez cap wou= ld > have failed. It might on the other hand instead already from the beginnin= g > have supplied the required ranges instead of asking for the actual value.= I > think it would be good if the protocol would enable either of these cases > for maximum flexibility. > > It may also be an idea to permit caching of at least AD- and RD-parameter= s > or evaluations of them, especially if we're talking extensive sets with > perhaps hundreds of parameters. Since the ADs and RDs should be free to > update their own parameters at any time, the handshake in that case must = of > course contain a check if cached parameters have been updated. Also, if a= n > AD or RD supports several sets of parameters depending on which domain or > service it deals with, means to distinguish between them are required, > perhaps using policy URI's the way Meadhbh suggested ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html). A polic= y > could then basically be broken down into a set of own parameter values an= d > required parameter ranges for the domain or service connecting. > > I also think, like Meadhbh ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html), that we > will need to suggest, but not require, a number of parameter name and > formats to facilitate communication, so that not e.g. US and UK domains > can't connect, because one asks about "color" and the other one only can > respond about "colour". > > Best regards, > > Magnus > > > - -----Ursprungligt meddelande----- > Fr=E5n: Carlo Wood [mailto:carlo@alinoe.com ] > Skickat: den 7 oktober 2009 22:36 > Till: Infinity Linden > Kopia: Magnus Zeisig; ogpx@ietf.org > =C4mne: Re: [ogpx] Protocol for permitting policy decisions > > On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden wrote: > > option 3: multi-message handshake > > > > AD --------------- (name) -------------> RD > > AD <-------- (X, age > X? cap) --------- RD > > > > AD ------------------------------------> RD (age > X? cap) > > AD <------------ (rez cap) ------------- RD > > Note, again, the need for a flexible protocol negotiation: > we can't know, already, what all will be needed. > > Nevertheless, the more flexibility the better imho. > I'd prefer to see this: > > AD ------(name, ) -----------> RD > AD <-----(name, ) --- RD > AD ------(name, yes/no)--------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > Where VWRAP will not define what keywords are possible. > > However, implementers might, for example, choose to use 'AGE' as keyword > with an integer range, leading to a msg exchange like > > AD ------(name, (AGE)) -----------> RD > AD <-----(name, (AGE, 21)) -------- RD > AD ------(name, yes)--------------> RD > AD <-----(rez cap) ---------------- RD > > or some might implement > > AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD > AD <-----(name, (AGE, 13), YES) ------------------ RD > AD ------(name, yes, yes)------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > For privacy reasons, I think it would suffice to > just send the AND of all 'yes's, thus: > > AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD > AD <-----(name, (AGE, 13), YES) ------------------ RD > AD ------(name, yes)-----------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > or, > > AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD > AD <-----(name, (AGE, 13), DONTCARE) ------------- RD > AD ------(name, yes)-----------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > Again, neither 'AGE' nor 'LIKES_BUNNIES', would be defined by us, > but we would define how to handle integer ranges, booleans, > don't cares, string literals, and perhaps regular expressions. > > - -- > Carlo Wood > > -----BEGIN PGP SIGNATURE----- > Version: 9.8.3 (Build 4028) > Charset: utf-8 > > wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al3nKcL > JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfgs7Ta/ > cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9ByIbMJ > RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOzWzsWm > tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bldq/Bnd > 60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w=3D=3D > =3D2NSu > -----END PGP SIGNATURE----- > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00504502cfb51387ef04756946f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Magnus,

If ADs are involved in region policy, then in the multi-worl= d deployment pattern, AD2 will have to be consulted when agent A1 teleports= from RD1 to RD2, because AD2 will be involved in region policy too.=A0 It&= #39;s symmetric with AD1.

This is what Joshua wanted to avoid, and it can only be avoided by not = giving ADs policy control over regions, otherwise symmetry requires that AD= 2 be consulted as well.

It's this kind of problem that reinforce= s what David's been saying about the right mess we currently have when = talking about domains determining policy.=A0 The AD/RD split was reasonably= adequate when OGP was only extending a single world with policy-free regio= ns, but it is insufficient to do a good job once we get into multi-world de= ployments with more complex service and policy patterns which require much = more flexibility.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= div class=3D"gmail_quote">On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig <magnus.zeisig@ii= s.se> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
=A0
I am strongly in favour of leaving policy descisions to the RD, = but since there seems to be a need for at least some AD managers to be able= to make policy decisions as well, I guess the protocol handshake need even= more flexibility than the versions scetched on by Meadhbh, Carlo and me so far. I will adapt the diagram style of Meadh= bh and Carlo (http://www.ietf.org/mail-archive/web/ogpx/= current/msg00520.html), since it's more readable than my text-flow variant. Also, I will leave out parameter examples since = there seem to be a risk people get hooked on if a certain parameter should = be included or not, rather than the possibility of handling any parameter.<= /div>
=A0
I may be paranoid, but I still prefer agent domains to be allowed, but= not forced by protocol, to reduce the dissemination of information about t= heir clients as far as possible, and there Carlo's AND version in the r= esponse is a good step forward (http://www.ietf.org/mail= -archive/web/ogpx/current/msg00520.html). We might even wind up with negotiations where one domain requests the actua= l values while the other domain only wants to disseminate a reply to if it = fits a range for one or more of the requested parameters.
=A0
AD -------------------------(name, <RDkey1?, RDkey2?>)----------= --------------> RD
AD <--(name, <RDvalue1, RDvalue2, ADkey1?, ADkey2?, agentkey1?, = agentkey2?>)--- RD
AD --(name, <RDvalues OK, ADvalue1, ADvalue2, agentvalue1, agentkey= 2 range?>)-> RD
AD <----------(name, <ADvalues OK, agentvalue1 OK, agentkey2 ran= ge>)----------- RD
AD ----------------------------(name, agentkey2 OK)-------------------= --------> RD
AD <-----------------------------(name, rez cap)-------------------= ------------ RD
=A0
In this example, RD might have refused giving the required range for a= gentvalue2, either because it technically doesn't support that kind of = negotiation or because of policy, in either case of which the rez cap would= have failed. It might on the other hand instead already from the beginning have supplied the required ranges i= nstead of asking for the actual value. I think it would be good if the prot= ocol would enable either of these cases for maximum flexibility.
=A0
It may also be an idea to permit caching of at least AD- and RD-parame= ters or evaluations of them, especially if we're talking extensive sets= with perhaps hundreds of parameters. Since the ADs and RDs should be free = to update their own parameters at any time, the handshake in that case must of course contain a check if cached p= arameters have been updated. Also, if an AD or RD supports several sets of = parameters depending on which domain or service it deals with, means to dis= tinguish between them are required, perhaps using policy URI's the way Meadhbh suggested (http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html). A p= olicy could then basically be broken down into a set of own parameter values and required parameter ranges for the domain or servic= e connecting.
=A0
I also think, like Meadhbh (http://www.ietf.org/mai= l-archive/web/ogpx/current/msg00523.html), that we will need to suggest= , but not require, a number of parameter name and formats to facilitate communication, so that not e.g. US and UK domains can't c= onnect, because one asks about "color" and the other one only can= respond about "colour".
=A0
Best regards,
=A0
Magnus
=A0
=A0
- -----Ursprungligt meddelande-----
Fr=E5n: Carlo Wood [mailto:carlo@alinoe.com]
Skickat: den 7 oktober 2009 22:36
Till: Infinity Linden
Kopia: Magnus Zeisig; ogpx@ietf.org
=C4mne: Re: [ogpx] Protocol for permitting pol= icy decisions
=A0
On Mon, Oct 05, 2009 at 12:39:= 32PM -0700, Infinity Linden wrote:
> option 3: multi-message handshake
>
> AD --------------- (name) -------------> RD
> AD <-------- (X, age > X? cap) --------- RD
>
> AD ------------------------------------> RD (age > X? cap)<= /div>
> AD <------------ (rez cap) ------------- RD
=A0
Note, again, the need for a flexible protocol negotiation:
we can't know, already, what all will be needed.
=A0
Nevertheless, the more flexibility the better imho.
I'd prefer to see this:
=A0
AD ------(name, <list with keywords>) -----------> RD
AD <-----(name, <list with keywords + ranges>) --- RD
AD ------(name, yes/no)--------------------------> RD
AD <-----(rez cap) ------------------------------- RD
=A0
Where VWRAP will not define what keywords are possible.
=A0
However, implementers might, for example, choose to use 'AGE' = as keyword
with an integer range, leading to a msg exchange like
=A0
AD ------(name, (AGE)) -----------> RD
AD <-----(name, (AGE, 21)) -------- RD
AD ------(name, yes)--------------> RD
AD <-----(rez cap) ---------------- RD
=A0
or some might implement
=A0
AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD
AD <-----(name, (AGE, 13), YES) ------------------ RD
AD ------(name, yes, yes)------------------------> RD
AD <-----(rez cap) ------------------------------- RD
=A0
For privacy reasons, I think it would suffice to
just send the AND of all 'yes's, thus:
=A0
AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD
AD <-----(name, (AGE, 13), YES) ------------------ RD
AD ------(name, yes)-----------------------------> RD
AD <-----(rez cap) ------------------------------- RD
=A0
or,
=A0
AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD
AD <-----(name, (AGE, 13), DONTCARE) ------------- RD
AD ------(name, yes)-----------------------------> RD
AD <-----(rez cap) ------------------------------- RD
=A0
Again, neither 'AGE' nor 'LIKES_BUNNIES', would be def= ined by us,
but we would define how to handle integer ranges, booleans,
don't cares, string literals, and perhaps regular expressions.
=A0
- --
Carlo Wood <c= arlo@alinoe.com>
=A0
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8
=A0
wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al3nKcL=
JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfgs7Ta/
cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9ByIbMJ
RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOzWzsWm
tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bldq/Bnd
60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w=3D=3D
=3D2NSu
-----END PGP SIGNATURE-----
=A0
=A0

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00504502cfb51387ef04756946f2-- From magnus.zeisig@iis.se Thu Oct 8 03:29:16 2009 Return-Path: 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 85B2928C24E for ; Thu, 8 Oct 2009 03:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 59+pwi8WKcTh for ; Thu, 8 Oct 2009 03:29:15 -0700 (PDT) Received: from cleaner.prod.iis.se (cleaner.prod.iis.se [212.247.7.212]) by core3.amsl.com (Postfix) with ESMTP id 1E28528C24A for ; Thu, 8 Oct 2009 03:28:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cleaner.prod.iis.se (Postfix) with ESMTP id 8242EA8003; Thu, 8 Oct 2009 10:30:34 +0000 (UTC) Received: from cleaner.prod.iis.se ([127.0.0.1]) by localhost (cleaner.prod.iis.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07826-08; Thu, 8 Oct 2009 10:30:21 +0000 (UTC) Received: from pgpkeys.office.nic.se (pgpkeys.office.nic.se [212.247.204.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cleaner.prod.iis.se (Postfix) with ESMTP id 872A2A8008; Thu, 8 Oct 2009 10:30:21 +0000 (UTC) Received: from EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) by pgpkeys.office.nic.se (PGP Universal service); Thu, 08 Oct 2009 12:30:21 +0200 X-PGP-Universal: processed; by pgpkeys.office.nic.se on Thu, 08 Oct 2009 12:30:21 +0200 Received: from Exchange2k7.office.nic.se ([169.254.1.222]) by EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) with mapi; Thu, 8 Oct 2009 12:30:20 +0200 From: Magnus Zeisig To: Morgaine Date: Thu, 8 Oct 2009 12:30:20 +0200 Thread-Topic: [ogpx] Protocol for permitting policy decisions Thread-Index: AcpH+6vkIYVAUpUcSYmJ02uoCpu88QABotWQ Message-ID: <983F17705339E24699AA251B458249B50CC48CB6E2@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> In-Reply-To: Accept-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE MIME-Version: 1.0 Content-Language: sv-SE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Debian amavisd-new at cleaner.prod.iis.se Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 10:29:16 -0000 Morgaine, No, you are still stuck in the concept of one virtual world equals one AD p= lus one RD, even if you say you recognize a future more complex service pat= tern. VW=3DAD+RD does not have to be the case with VWRAP. If it _happens_ t= o be the case and the entity controlling AD2 and RD2 wants to enforce AD2 p= olicy for those visiting RD2, then they can move, duplicate or mirror the e= nforcement of that policy from AD2 to RD2, which they can do without proble= ms as long as they control both. If they don't control both, then it's enti= rely up to the entity controlling RD2 if they for some reason want to enfor= ce the policy of the entity controlling AD2. So I see no reason whatsoever = why symmetry is required. Policy is not decided and enforced by the AD, the RD or any service connect= ed with them, it is decided and enforced by the entities behind them. If th= e same entity controls an AD and a RD, then it's meaningless to try to divi= de up that entity's policy into AD policy and RD policy, because it can enf= orce that policy at any level, type of domain or connected service it contr= ols. But, like you, I am totally in favor of letting the entity controlling the = destination RD decide policy once the agent is there. However, if the agent= 's own AD for some reason wants to stop the agent from going there, then I = think it should have the possibility to do so. In all honesty, I don't thin= k an AD imposing undue restrictions on where people are allowed to go or wh= at they are allowed to do there will survive for long though, once competit= ion is in place. You may have to start out fresh, with a new AD, without th= e assets and inventory connected to the old AD, but I think most people are= willing to take that step if they feel their freedom is too limited. Best regards, Magnus -----Ursprungligt meddelande----- Fr=E5n: Morgaine [mailto:morgaine.dinova@googlemail.com]=20 Skickat: den 8 oktober 2009 11:42 Till: Magnus Zeisig Kopia: ogpx@ietf.org =C4mne: Re: [ogpx] Protocol for permitting policy decisions Magnus, If ADs are involved in region policy, then in the multi-world deployment pa= ttern, AD2 will have to be consulted when agent A1 teleports from RD1 to RD= 2, because AD2 will be involved in region policy too. It's symmetric with = AD1. This is what Joshua wanted to avoid, and it can only be avoided by not givi= ng ADs policy control over regions, otherwise symmetry requires that AD2 be= consulted as well. It's this kind of problem that reinforces what David's been saying about th= e right mess we currently have when talking about domains determining polic= y. The AD/RD split was reasonably adequate when OGP was only extending a s= ingle world with policy-free regions, but it is insufficient to do a good j= ob once we get into multi-world deployments with more complex service and p= olicy patterns which require much more flexibility. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig wrote: =09 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 =20 I am strongly in favour of leaving policy descisions to the RD, but since = there seems to be a need for at least some AD managers to be able to make p= olicy decisions as well, I guess the protocol handshake need even more flex= ibility than the versions scetched on by Meadhbh, Carlo and me so far. I wi= ll adapt the diagram style of Meadhbh and Carlo (http://www.ietf.org/mail-a= rchive/web/ogpx/current/msg00520.html), since it's more readable than my te= xt-flow variant. Also, I will leave out parameter examples since there seem= to be a risk people get hooked on if a certain parameter should be include= d or not, rather than the possibility of handling any parameter. =20 I may be paranoid, but I still prefer agent domains to be allowed, but not= forced by protocol, to reduce the dissemination of information about their= clients as far as possible, and there Carlo's AND version in the response = is a good step forward (http://www.ietf.org/mail-archive/web/ogpx/current/m= sg00520.html). We might even wind up with negotiations where one domain req= uests the actual values while the other domain only wants to disseminate a = reply to if it fits a range for one or more of the requested parameters. =20 AD -------------------------(name, )--------------------= ----> RD AD <--(name, )--- RD AD --(name, )-> RD AD <----------(name, )------= ----- RD AD ----------------------------(name, agentkey2 OK)-----------------------= ----> RD AD <-----------------------------(name, rez cap)--------------------------= ----- RD =20 In this example, RD might have refused giving the required range for agent= value2, either because it technically doesn't support that kind of negotiat= ion or because of policy, in either case of which the rez cap would have fa= iled. It might on the other hand instead already from the beginning have su= pplied the required ranges instead of asking for the actual value. I think = it would be good if the protocol would enable either of these cases for max= imum flexibility. =20 It may also be an idea to permit caching of at least AD- and RD-parameters= or evaluations of them, especially if we're talking extensive sets with pe= rhaps hundreds of parameters. Since the ADs and RDs should be free to updat= e their own parameters at any time, the handshake in that case must of cour= se contain a check if cached parameters have been updated. Also, if an AD o= r RD supports several sets of parameters depending on which domain or servi= ce it deals with, means to distinguish between them are required, perhaps u= sing policy URI's the way Meadhbh suggested (http://www.ietf.org/mail-archi= ve/web/ogpx/current/msg00523.html). A policy could then basically be broken= down into a set of own parameter values and required parameter ranges for = the domain or service connecting. =20 I also think, like Meadhbh (http://www.ietf.org/mail-archive/web/ogpx/curr= ent/msg00523.html), that we will need to suggest, but not require, a number= of parameter name and formats to facilitate communication, so that not e.g= . US and UK domains can't connect, because one asks about "color" and the o= ther one only can respond about "colour". =20 Best regards, =20 Magnus =20 =20 - -----Ursprungligt meddelande----- Fr=E5n: Carlo Wood [mailto:carlo@alinoe.com]=20 Skickat: den 7 oktober 2009 22:36 Till: Infinity Linden Kopia: Magnus Zeisig; ogpx@ietf.org =C4mne: Re: [ogpx] Protocol for permitting policy decisions =20 On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden wrote: > option 3: multi-message handshake >=20 > AD --------------- (name) -------------> RD > AD <-------- (X, age > X? cap) --------- RD >=20 > AD ------------------------------------> RD (age > X? cap) > AD <------------ (rez cap) ------------- RD =20 Note, again, the need for a flexible protocol negotiation: we can't know, already, what all will be needed. =20 Nevertheless, the more flexibility the better imho. I'd prefer to see this: =20 AD ------(name, ) -----------> RD AD <-----(name, ) --- RD AD ------(name, yes/no)--------------------------> RD AD <-----(rez cap) ------------------------------- RD =20 Where VWRAP will not define what keywords are possible. =20 However, implementers might, for example, choose to use 'AGE' as keyword with an integer range, leading to a msg exchange like =20 AD ------(name, (AGE)) -----------> RD AD <-----(name, (AGE, 21)) -------- RD AD ------(name, yes)--------------> RD AD <-----(rez cap) ---------------- RD =20 or some might implement =20 AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD AD <-----(name, (AGE, 13), YES) ------------------ RD AD ------(name, yes, yes)------------------------> RD AD <-----(rez cap) ------------------------------- RD =20 For privacy reasons, I think it would suffice to just send the AND of all 'yes's, thus: =20 AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD AD <-----(name, (AGE, 13), YES) ------------------ RD AD ------(name, yes)-----------------------------> RD AD <-----(rez cap) ------------------------------- RD =20 or, =20 AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD AD <-----(name, (AGE, 13), DONTCARE) ------------- RD AD ------(name, yes)-----------------------------> RD AD <-----(rez cap) ------------------------------- RD =20 Again, neither 'AGE' nor 'LIKES_BUNNIES', would be defined by us, but we would define how to handle integer ranges, booleans, don't cares, string literals, and perhaps regular expressions. =20 - --=20 Carlo Wood =20 -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 =20 wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al3nKcL JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfgs7Ta/ cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9ByIbMJ RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOzWzsWm tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bldq/Bnd 60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w=3D=3D =3D2NSu -----END PGP SIGNATURE----- =20 =20 _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx =09 =09 From magnus.zeisig@iis.se Thu Oct 8 03:37:23 2009 Return-Path: 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 5DBC23A6A68 for ; Thu, 8 Oct 2009 03:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 a0w0m9z+sxJ3 for ; Thu, 8 Oct 2009 03:37:22 -0700 (PDT) Received: from cleaner.prod.iis.se (cleaner.prod.iis.se [212.247.7.212]) by core3.amsl.com (Postfix) with ESMTP id 1F96F3A6A6B for ; Thu, 8 Oct 2009 03:37:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cleaner.prod.iis.se (Postfix) with ESMTP id 44F93A8010; Thu, 8 Oct 2009 10:39:01 +0000 (UTC) Received: from cleaner.prod.iis.se ([127.0.0.1]) by localhost (cleaner.prod.iis.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08143-08; Thu, 8 Oct 2009 10:38:50 +0000 (UTC) Received: from pgpkeys.office.nic.se (pgpkeys.office.nic.se [212.247.204.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cleaner.prod.iis.se (Postfix) with ESMTP id 553EEA8008; Thu, 8 Oct 2009 10:38:50 +0000 (UTC) Received: from EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) by pgpkeys.office.nic.se (PGP Universal service); Thu, 08 Oct 2009 12:38:50 +0200 X-PGP-Universal: processed; by pgpkeys.office.nic.se on Thu, 08 Oct 2009 12:38:50 +0200 Received: from Exchange2k7.office.nic.se ([169.254.1.222]) by EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) with mapi; Thu, 8 Oct 2009 12:38:50 +0200 From: Magnus Zeisig To: Morgaine Date: Thu, 8 Oct 2009 12:38:48 +0200 Thread-Topic: VWRAP future (mostly out of protocol ramblings) Thread-Index: AcpH+6vkIYVAUpUcSYmJ02uoCpu88QABtb4Q Message-ID: <983F17705339E24699AA251B458249B50CC48CB6E4@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> In-Reply-To: Accept-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-pgp-encoding-version: 2.0.2 x-pgp-mapi-encoding-version: 2.5.0 x-pgp-encoding-format: Partitioned x-pgp-universal-saved-content-codepage: utf-8 acceptlanguage: sv-SE MIME-Version: 1.0 Content-Language: sv-SE Content-Type: multipart/alternative; boundary="_000_983F17705339E24699AA251B458249B50CC48CB6E4EXCHANGE2K7of_" X-Virus-Scanned: Debian amavisd-new at cleaner.prod.iis.se Cc: "ogpx@ietf.org" Subject: [ogpx] VWRAP future (mostly out of protocol ramblings) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 10:37:23 -0000 --_000_983F17705339E24699AA251B458249B50CC48CB6E4EXCHANGE2K7of_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkluIHRo ZSBmdXR1cmUgSSB0aGluayB3ZSB3aWxsIGhhdmUgYSBWV1JBUCBtZXRhdmVyc2Ugc2ltaWxhciB0 byBob3cgdGhlIHdlYiB3b3JrcyB0b2RheS4gVGhlIFZXUkFQIHByb3RvY29sIHdpbGwgZW5hYmxl IGJvdGggcHJpdmF0ZSBwZXJzb25zIGFuZCBtYWpvciBvcmdhbml6YXRpb25zIHRvIHNldCB1cCBh bmQgaW50ZXJvcCwgdG8gdGhlIGRlZ3JlZSBlYWNoIGVudGl0eSB3YW50cywgdGhlaXIgb3duIGNv cm5lciBvZiB0aGUgdmlydHVhbCB3b3JsZCB3aXRoIHRoZSByZXN0IG9mIHRoYXQgd29ybGQuIEp1 c3QgbGlrZSBvbiB0aGUgd2ViLCB3ZSB3aWxsIHNlZSBlbnRpdGllcyBydW5uaW5nICJpbnRyYS1t ZXRhdmVyc2VzIiwgdG90YWxseSBzaHV0IG9mZiBvciBvbmx5IHRvIGEgbGltaXRlZCBkZWdyZWUg b3BlbiB0byB0aGUgcHVibGljLiBXZSB3aWxsIHByb2JhYmx5IGFsc28gc2VlIGF0dGVtcHRzIGJ5 IHNvbWUgbWFqb3IgZW50aXRpZXMsIGp1c3QgbGlrZSBlLmcuIE1pY3Jvc29mdCBOZXR3b3JrLCB0 byBzZXQgdGhlaXIgb3duIHN0YW5kYXJkcyBhbmQgYmVsaWV2ZSB0aGV5IGFyZSBiaWcgZW5vdWdo IHRvIGZvcmNlIG90aGVycyB0byBhZGFwdCB0byB0aG9zZSBzdGFuZGFyZHMsIGFuZCB3ZSB3aWxs IHByb2JhYmx5LCBqdXN0IGFzIHdhcyB0aGUgY2FzZSB3aXRoIE1pY3Jvc29mdCBOZXR3b3JrLCBz ZWUgdGhvc2UgYXR0ZW1wdHMgZmFpbC4NCg0KSW4gdGhlIGJlZ2lubmluZywgdGhlcmUgd2lsbCBw cm9iYWJseSBiZSBhIGZldyBtYWpvciBwbGF5ZXJzIHdpdGggYSBoZWFkIHN0YXJ0cyBhbmQgc2Vy dmVyIHBhcmtzLCBhbmQgYSBtdWx0aXR1ZGUgb2Ygc21hbGwgcGxheWVycywgcnVubmluZyB0aGVp ciBwaWVjZXMgb2YgdGhlIHZpcnR1YWwgd29ybGQgdXNpbmcgZS5nLiBPcGVuU2ltdWxhdG9yLCBv biB0aGVpciBkZXNrdG9wIG9yIGxhcHRvcCBjb21wdXRlcnMuIE1hbnkgb2YgdGhlIHNtYWxsIHBs YXllcnMgd2lsbCBwcm9iYWJseSBoYXZlIHRoZSB2ZXJ5IHNpbXBsZSBwb2xpY3kgb2YgIklmIHlv dSB3YW50IHRvIGNvbm5lY3QsIHdlbGNvbWUsIHJlZ2FyZGxlc3Mgb2YgeW91ciBjcmVkZW50aWFs cywgYnV0IGlmIHlvdSBtaXNiZWhhdmUgSSB3aWxsIGtpY2sgeW91IG91dC4iIEluIHRpbWUsIHNv bWUgb2YgdGhvc2Ugc21hbGwgcGxheWVycyB3aWxsIGdyb3cgYmVjYXVzZSB0aGV5IHNlcnZlIGlu dGVyZXN0aW5nIGNvbnRlbnQgb3IgY3JlYXRlIHNvY2lhbCBuZXR3b3JrcyB3aXRoIG1hbnkgdXNl cnMvdmlzaXRvcnMuIE1vc3Qgb2YgdGhlbSB3aWxsIHByb2JhYmx5IHNlZSBhIG5lZWQgdG8gZGV2 ZWxvcCBtb3JlIHN0cmljdCBwb2xpY2llcyB0byBlbmFibGUgYWRtaW5pc3RyYXRpb24gb2YgdGhl aXIgc2VydmljZXMgYXQgYWxsLCBzbyB0aGV5IGRvbid0IGhhdmUgdG8gc3BlbmQgYWxsIGRheSBr aWNraW5nIGFidXNlcnMgcmV0dXJuaW5nIHRpbWUgYWZ0ZXIgdGltZSB3aXRoIG5ldyBpZGVudGl0 aWVzLCBkaXNydXB0aW5nIHRoZSBleHBlcmllbmNlIGZvciBvdGhlciB1c2Vycy4NCg0KVGhvc2Ug c2VydmljZSBhbmQgZG9tYWluIG1hbmFnZXJzIHJlcXVlc3Rpbmcgc29tZSBraW5kIG9mIHRydXN0 IGRvbWFpbiB0byBhbGxvdyBvdGhlcnMgdXNpbmcgb3IgY29ubmVjdGluZyB0byB0aGVpciBzZXJ2 aWNlcyBhbmQgZG9tYWlucyB3aWxsIGVpdGhlciBjdXQgdGhlbXNlbHZlcyBvZmYgZnJvbSBhbGwg dGhvc2Ugc21hbGwgcGxheWVycyBydW5uaW5nIHRoZWlyIGRvbWFpbnMgb3Igc2VydmljZXMgaG9t ZSBpbiB0aGVpciBraXRjaGVuIG9yIGN1cGJvYXJkLCBlYXNlIHVwIG9uIHRoZWlyIGRlbWFuZHMg Zm9yIGRvbWFpbnMgb2YgdHJ1c3QsIG9yIHNpbXBsaWZ5IHRoZSBwcm9jZWR1cmUgc28gdGhhdCB0 aGUgbmVjZXNzYXJ5IGRvbWFpbiBvZiB0cnVzdCBjYW4gYmUgZXN0YWJsaXNoZWQgdmlhIGVsZWN0 cm9uaWMgc2lnbmF0dXJlcyBvbiB0aGUgZmlyc3QgY29ubmVjdGlvbi4gSWYgdGhleSBjaG9vc2Ug dG8gcmVtYWluIGN1dCBvZmYgZnJvbSB0aGUgcmVzdCBvZiB0aGUgbWV0YXZlcnNlLCB0aGV5IHdp bGwgcHJvYmFibHkgc29vbiBiZSBmb3Jnb3R0ZW4gaXNsYW5kcyBpbiB0aGUgc2VhIG9mIHRlbnMg b3IgaHVuZHJlZHMgb2YgdGhvdXNhbmRzIG1pbm9yIGRvbWFpbnMgYW5kIHNlcnZpY2VzIGludGVy b3BpbmcgbW9yZSBmcmVlbHkuDQoNClRoZSBwb2ludCBpcyB0aGF0IHRoZSBWV1JBUCBwcm90b2Nv bCB3aWxsIG5vdCBwcm9zY3JpYmUgaG93IHlvdSBzaG91bGQgcnVuIHlvdXIgc2VydmljZSwgb3Bl biBvciBhcyBhIHdhbGxlZCBnYXJkZW4sIHNtYWxsIG9yIGJpZy4gSXQgd2lsbCBwZXJtaXQgeW91 IHRvIGludGVyb3AgdG8gdGhlIGRlZ3JlZSB5b3UgY2hvc2UgeW91cnNlbGYsIG5vdCBmb3JjaW5n IHlvdSB0byBpbnRlcm9wIGFueSBtb3JlIG9yIGxlc3MgdGhhbiB0aGF0LiBPdGhlciBmYWN0b3Jz LCBsaWtlIGludGVybmF0aW9uYWwgbGF3LCBuYXRpb25hbCBsZWdpc2xhdGlvbiwgSVNQIFRPUywg b3JnYW5pemF0aW9uIHBvbGljaWVzIGFuZCBzdWNoLCBtYXkgZm9yY2UgeW91IHRvIHNldCBsaW1p dGF0aW9ucyBvciByYWlzZSByZXF1aXJlbWVudHMgb24gd2l0aCB3aG8gYW5kIGhvdyB5b3UgaW50 ZXJvcCwgYnV0IFZXUkFQIHNob3VsZCBvZmZlciB5b3UgdGhlIHRvb2wgdG8gZG8gc28sIHJlZ2Fy ZGxlc3Mgb2YgaWYgeW91IHdhbnQsIG9yIGFyZSBmb3JjZWQsIHRvIHJ1biBhIHN0cmljdGx5IHJl Z3VsYXRlZCB3YWxsZWQgZ2FyZGVuIGFsb25lIG9yIGluY2x1ZGluZyBhIGZldyB0cnVzdGVkIHBl ZXJzLCBieSBzdXBwb3J0aW5nIHRoZSBjb21tdW5pY2F0aW9uIG5lZWRlZCBmb3IgcG9saWN5LWVu Zm9yY2VtZW50LCBvciBydW4gYSBuby1ob2xkcy1iYXJyZWQgZnJlZS1mb3ItZXZlcnlvbmUgb3Bl cmF0aW9uLCBieSBub3QgcmVxdWlyaW5nIHRoZSB1c2Ugb2YgYW55IHBvbGljeS1zdXBwb3J0IHdo YXRzb2V2ZXIuDQoNCkJlc3QgcmVnYXJkcywNCg0KTWFnbnVzDQoNCg0KLSAtLS0tLVVyc3BydW5n bGlndCBtZWRkZWxhbmRlLS0tLS0NCkZyw6VuOiBNb3JnYWluZSBbbWFpbHRvOm1vcmdhaW5lLmRp bm92YUBnb29nbGVtYWlsLmNvbV0NClNraWNrYXQ6IGRlbiA4IG9rdG9iZXIgMjAwOSAxMTo0Mg0K VGlsbDogTWFnbnVzIFplaXNpZw0KS29waWE6IG9ncHhAaWV0Zi5vcmcNCsOEbW5lOiBSZTogW29n cHhdIFByb3RvY29sIGZvciBwZXJtaXR0aW5nIHBvbGljeSBkZWNpc2lvbnMNCg0KTWFnbnVzLA0K DQpJZiBBRHMgYXJlIGludm9sdmVkIGluIHJlZ2lvbiBwb2xpY3ksIHRoZW4gaW4gdGhlIG11bHRp LXdvcmxkIGRlcGxveW1lbnQgcGF0dGVybiwgQUQyIHdpbGwgaGF2ZSB0byBiZSBjb25zdWx0ZWQg d2hlbiBhZ2VudCBBMSB0ZWxlcG9ydHMgZnJvbSBSRDEgdG8gUkQyLCBiZWNhdXNlIEFEMiB3aWxs IGJlIGludm9sdmVkIGluIHJlZ2lvbiBwb2xpY3kgdG9vLiAgSXQncyBzeW1tZXRyaWMgd2l0aCBB RDEuDQoNClRoaXMgaXMgd2hhdCBKb3NodWEgd2FudGVkIHRvIGF2b2lkLCBhbmQgaXQgY2FuIG9u bHkgYmUgYXZvaWRlZCBieSBub3QgZ2l2aW5nIEFEcyBwb2xpY3kgY29udHJvbCBvdmVyIHJlZ2lv bnMsIG90aGVyd2lzZSBzeW1tZXRyeSByZXF1aXJlcyB0aGF0IEFEMiBiZSBjb25zdWx0ZWQgYXMg d2VsbC4NCg0KSXQncyB0aGlzIGtpbmQgb2YgcHJvYmxlbSB0aGF0IHJlaW5mb3JjZXMgd2hhdCBE YXZpZCdzIGJlZW4gc2F5aW5nIGFib3V0IHRoZSByaWdodCBtZXNzIHdlIGN1cnJlbnRseSBoYXZl IHdoZW4gdGFsa2luZyBhYm91dCBkb21haW5zIGRldGVybWluaW5nIHBvbGljeS4gIFRoZSBBRC9S RCBzcGxpdCB3YXMgcmVhc29uYWJseSBhZGVxdWF0ZSB3aGVuIE9HUCB3YXMgb25seSBleHRlbmRp bmcgYSBzaW5nbGUgd29ybGQgd2l0aCBwb2xpY3ktZnJlZSByZWdpb25zLCBidXQgaXQgaXMgaW5z dWZmaWNpZW50IHRvIGRvIGEgZ29vZCBqb2Igb25jZSB3ZSBnZXQgaW50byBtdWx0aS13b3JsZCBk ZXBsb3ltZW50cyB3aXRoIG1vcmUgY29tcGxleCBzZXJ2aWNlIGFuZCBwb2xpY3kgcGF0dGVybnMg d2hpY2ggcmVxdWlyZSBtdWNoIG1vcmUgZmxleGliaWxpdHkuDQoNCg0KTW9yZ2FpbmUuDQoNCg0K LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IDkuOC4zIChCdWlsZCA0MDI4 KQ0KQ2hhcnNldDogdXRmLTgNCg0Kd3NCVkF3VUJTczNCT081TWxVOVh5YWlTQVFqMnlRZ0FqcndL cC9ZaFNlK284a2xzUGcvTFYrRzZYUzFMYUJoOQ0KMmtFYzMxbGlxdnR0dk9IWW9SZGhyQ01UMllo NUYwUEtqYi9kYURxSy8zZHVUZ1RiejI3N3NaUytQNXhuZnp4cg0KZ3NKTjRZLy9rdUtjZG1jM3JR VGFZYWZvOWF6bDRKc2xQS05pUTJsU1RjS0R3QUExam41aGFtQnVpUDFUZHhRRA0KMUdRSDR6aE9Q dkVrZlBKS0NXNHlHSmR5cDMwZFlkWUZ2NkthL1JsNXZBZXNQWFN0bXBvQlE2eDlmeHRTcHZWVA0K VlY2WU1KeUVVWUNuVSsxdm9HTy9yQ0p0MUFLTkpDT1VuQ1h4ME4rYTVYcml4MG9XN2F6eDN4dzZH Ni9SQ3VWdg0KR1krbHdlaUUvYnFmVGI0UXI4L2VkVjRGZmV5MmZvMjFwbEtBQlE1d29ycEdLTDkv a2ZnMml3PT0NCj0xWUJFDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0NCg0KDQo= --_000_983F17705339E24699AA251B458249B50CC48CB6E4EXCHANGE2K7of_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+DQo8ZGl2Pi0tLS0t QkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS08L2Rpdj4NCjxkaXY+SGFzaDogU0hBMjU2PC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JbiB0aGUgZnV0dXJlIEkgdGhpbmsgd2Ugd2ls bCBoYXZlIGEgVldSQVAgbWV0YXZlcnNlIHNpbWlsYXIgdG8gaG93IHRoZSB3ZWIgd29ya3MgdG9k YXkuIFRoZSBWV1JBUCBwcm90b2NvbCB3aWxsIGVuYWJsZSBib3RoIHByaXZhdGUgcGVyc29ucyBh bmQgbWFqb3Igb3JnYW5pemF0aW9ucyB0byBzZXQgdXAgYW5kIGludGVyb3AsIHRvIHRoZSBkZWdy ZWUgZWFjaCBlbnRpdHkgd2FudHMsIHRoZWlyIG93biBjb3JuZXIgb2YgdGhlIHZpcnR1YWwNCndv cmxkIHdpdGggdGhlIHJlc3Qgb2YgdGhhdCB3b3JsZC4gSnVzdCBsaWtlIG9uIHRoZSB3ZWIsIHdl IHdpbGwgc2VlIGVudGl0aWVzIHJ1bm5pbmcgJnF1b3Q7aW50cmEtbWV0YXZlcnNlcyZxdW90Oywg dG90YWxseSBzaHV0IG9mZiBvciBvbmx5IHRvIGEgbGltaXRlZCBkZWdyZWUgb3BlbiB0byB0aGUg cHVibGljLiBXZSB3aWxsIHByb2JhYmx5IGFsc28gc2VlIGF0dGVtcHRzIGJ5IHNvbWUgbWFqb3Ig ZW50aXRpZXMsIGp1c3QgbGlrZSBlLmcuIE1pY3Jvc29mdCBOZXR3b3JrLA0KdG8gc2V0IHRoZWly IG93biBzdGFuZGFyZHMgYW5kIGJlbGlldmUgdGhleSBhcmUgYmlnIGVub3VnaCB0byBmb3JjZSBv dGhlcnMgdG8gYWRhcHQgdG8gdGhvc2Ugc3RhbmRhcmRzLCBhbmQgd2Ugd2lsbCBwcm9iYWJseSwg anVzdCBhcyB3YXMgdGhlIGNhc2Ugd2l0aCBNaWNyb3NvZnQgTmV0d29yaywgc2VlIHRob3NlIGF0 dGVtcHRzIGZhaWwuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JbiB0aGUgYmVnaW5u aW5nLCB0aGVyZSB3aWxsIHByb2JhYmx5IGJlIGEgZmV3IG1ham9yIHBsYXllcnMgd2l0aCBhIGhl YWQgc3RhcnRzIGFuZCBzZXJ2ZXIgcGFya3MsIGFuZCBhIG11bHRpdHVkZSBvZiBzbWFsbCBwbGF5 ZXJzLCBydW5uaW5nIHRoZWlyIHBpZWNlcyBvZiB0aGUgdmlydHVhbCB3b3JsZCB1c2luZyBlLmcu IE9wZW5TaW11bGF0b3IsIG9uIHRoZWlyIGRlc2t0b3Agb3IgbGFwdG9wIGNvbXB1dGVycy4gTWFu eSBvZiB0aGUgc21hbGwNCnBsYXllcnMgd2lsbCBwcm9iYWJseSBoYXZlIHRoZSB2ZXJ5IHNpbXBs ZSBwb2xpY3kgb2YgJnF1b3Q7SWYgeW91IHdhbnQgdG8gY29ubmVjdCwgd2VsY29tZSwgcmVnYXJk bGVzcyBvZiB5b3VyIGNyZWRlbnRpYWxzLCBidXQgaWYgeW91IG1pc2JlaGF2ZSBJIHdpbGwga2lj ayB5b3Ugb3V0LiZxdW90OyBJbiB0aW1lLCBzb21lIG9mIHRob3NlIHNtYWxsIHBsYXllcnMgd2ls bCBncm93IGJlY2F1c2UgdGhleSBzZXJ2ZSBpbnRlcmVzdGluZyBjb250ZW50IG9yIGNyZWF0ZQ0K c29jaWFsIG5ldHdvcmtzIHdpdGggbWFueSB1c2Vycy92aXNpdG9ycy4gTW9zdCBvZiB0aGVtIHdp bGwgcHJvYmFibHkgc2VlIGEgbmVlZCB0byBkZXZlbG9wIG1vcmUgc3RyaWN0IHBvbGljaWVzIHRv IGVuYWJsZSBhZG1pbmlzdHJhdGlvbiBvZiB0aGVpciBzZXJ2aWNlcyBhdCBhbGwsIHNvIHRoZXkg ZG9uJ3QgaGF2ZSB0byBzcGVuZCBhbGwgZGF5IGtpY2tpbmcgYWJ1c2VycyByZXR1cm5pbmcgdGlt ZSBhZnRlciB0aW1lIHdpdGggbmV3IGlkZW50aXRpZXMsDQpkaXNydXB0aW5nIHRoZSBleHBlcmll bmNlIGZvciBvdGhlciB1c2Vycy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRob3Nl IHNlcnZpY2UgYW5kIGRvbWFpbiBtYW5hZ2VycyByZXF1ZXN0aW5nIHNvbWUga2luZCBvZiB0cnVz dCBkb21haW4gdG8gYWxsb3cgb3RoZXJzIHVzaW5nIG9yIGNvbm5lY3RpbmcgdG8gdGhlaXIgc2Vy dmljZXMgYW5kIGRvbWFpbnMgd2lsbCBlaXRoZXIgY3V0IHRoZW1zZWx2ZXMgb2ZmIGZyb20gYWxs IHRob3NlIHNtYWxsIHBsYXllcnMgcnVubmluZyB0aGVpciBkb21haW5zIG9yIHNlcnZpY2VzIGhv bWUgaW4gdGhlaXIga2l0Y2hlbg0Kb3IgY3VwYm9hcmQsIGVhc2UgdXAgb24gdGhlaXIgZGVtYW5k cyBmb3IgZG9tYWlucyBvZiB0cnVzdCwgb3Igc2ltcGxpZnkgdGhlIHByb2NlZHVyZSBzbyB0aGF0 IHRoZSBuZWNlc3NhcnkgZG9tYWluIG9mIHRydXN0IGNhbiBiZSBlc3RhYmxpc2hlZCB2aWEgZWxl Y3Ryb25pYyBzaWduYXR1cmVzIG9uIHRoZSBmaXJzdCBjb25uZWN0aW9uLiBJZiB0aGV5IGNob29z ZSB0byByZW1haW4gY3V0IG9mZiBmcm9tIHRoZSByZXN0IG9mIHRoZSBtZXRhdmVyc2UsDQp0aGV5 IHdpbGwgcHJvYmFibHkgc29vbiBiZSBmb3Jnb3R0ZW4gaXNsYW5kcyBpbiB0aGUgc2VhIG9mIHRl bnMgb3IgaHVuZHJlZHMgb2YgdGhvdXNhbmRzIG1pbm9yIGRvbWFpbnMgYW5kIHNlcnZpY2VzIGlu dGVyb3BpbmcgbW9yZSBmcmVlbHkuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGUg cG9pbnQgaXMgdGhhdCB0aGUgVldSQVAgcHJvdG9jb2wgd2lsbCBub3QgcHJvc2NyaWJlIGhvdyB5 b3Ugc2hvdWxkIHJ1biB5b3VyIHNlcnZpY2UsIG9wZW4gb3IgYXMgYSB3YWxsZWQgZ2FyZGVuLCBz bWFsbCBvciBiaWcuIEl0IHdpbGwgcGVybWl0IHlvdSB0byBpbnRlcm9wIHRvIHRoZSBkZWdyZWUg eW91IGNob3NlIHlvdXJzZWxmLCBub3QgZm9yY2luZyB5b3UgdG8gaW50ZXJvcCBhbnkgbW9yZSBv ciBsZXNzIHRoYW4gdGhhdC4gT3RoZXINCmZhY3RvcnMsIGxpa2UgaW50ZXJuYXRpb25hbCBsYXcs IG5hdGlvbmFsIGxlZ2lzbGF0aW9uLCBJU1AgVE9TLCBvcmdhbml6YXRpb24gcG9saWNpZXMgYW5k IHN1Y2gsIG1heSBmb3JjZSB5b3UgdG8gc2V0IGxpbWl0YXRpb25zIG9yIHJhaXNlIHJlcXVpcmVt ZW50cyBvbiB3aXRoIHdobyBhbmQgaG93IHlvdSBpbnRlcm9wLCBidXQgVldSQVAgc2hvdWxkIG9m ZmVyIHlvdSB0aGUgdG9vbCB0byBkbyBzbywgcmVnYXJkbGVzcyBvZiBpZiB5b3Ugd2FudCwNCm9y IGFyZSBmb3JjZWQsIHRvIHJ1biBhIHN0cmljdGx5IHJlZ3VsYXRlZCB3YWxsZWQgZ2FyZGVuIGFs b25lIG9yIGluY2x1ZGluZyBhIGZldyB0cnVzdGVkIHBlZXJzLCBieSBzdXBwb3J0aW5nIHRoZSBj b21tdW5pY2F0aW9uIG5lZWRlZCBmb3IgcG9saWN5LWVuZm9yY2VtZW50LCBvciBydW4gYSBuby1o b2xkcy1iYXJyZWQgZnJlZS1mb3ItZXZlcnlvbmUgb3BlcmF0aW9uLCBieSBub3QgcmVxdWlyaW5n IHRoZSB1c2Ugb2YgYW55IHBvbGljeS1zdXBwb3J0DQp3aGF0c29ldmVyLjwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+TWFnbnVzPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+LSAtLS0tLVVyc3BydW5nbGlndCBtZWRkZWxhbmRlLS0tLS08L2Rpdj4NCjxkaXY+RnLD pW46IE1vcmdhaW5lIFs8YSBocmVmPSJtYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwu Y29tIj5tYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tPC9hPl0gPC9kaXY+DQo8 ZGl2PlNraWNrYXQ6IGRlbiA4IG9rdG9iZXIgMjAwOSAxMTo0MjwvZGl2Pg0KPGRpdj5UaWxsOiBN YWdudXMgWmVpc2lnPC9kaXY+DQo8ZGl2PktvcGlhOiBvZ3B4QGlldGYub3JnPC9kaXY+DQo8ZGl2 PsOEbW5lOiBSZTogW29ncHhdIFByb3RvY29sIGZvciBwZXJtaXR0aW5nIHBvbGljeSBkZWNpc2lv bnM8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1hZ251cyw8L2Rpdj4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8ZGl2PklmIEFEcyBhcmUgaW52b2x2ZWQgaW4gcmVnaW9uIHBvbGljeSwgdGhl biBpbiB0aGUgbXVsdGktd29ybGQgZGVwbG95bWVudCBwYXR0ZXJuLCBBRDIgd2lsbCBoYXZlIHRv IGJlIGNvbnN1bHRlZCB3aGVuIGFnZW50IEExIHRlbGVwb3J0cyBmcm9tIFJEMSB0byBSRDIsIGJl Y2F1c2UgQUQyIHdpbGwgYmUgaW52b2x2ZWQgaW4gcmVnaW9uIHBvbGljeSB0b28uJm5ic3A7IEl0 J3Mgc3ltbWV0cmljIHdpdGggQUQxLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+VGhp cyBpcyB3aGF0IEpvc2h1YSB3YW50ZWQgdG8gYXZvaWQsIGFuZCBpdCBjYW4gb25seSBiZSBhdm9p ZGVkIGJ5IG5vdCBnaXZpbmcgQURzIHBvbGljeSBjb250cm9sIG92ZXIgcmVnaW9ucywgb3RoZXJ3 aXNlIHN5bW1ldHJ5IHJlcXVpcmVzIHRoYXQgQUQyIGJlIGNvbnN1bHRlZCBhcyB3ZWxsLjwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SXQncyB0aGlzIGtpbmQgb2YgcHJvYmxlbSB0aGF0 IHJlaW5mb3JjZXMgd2hhdCBEYXZpZCdzIGJlZW4gc2F5aW5nIGFib3V0IHRoZSByaWdodCBtZXNz IHdlIGN1cnJlbnRseSBoYXZlIHdoZW4gdGFsa2luZyBhYm91dCBkb21haW5zIGRldGVybWluaW5n IHBvbGljeS4mbmJzcDsgVGhlIEFEL1JEIHNwbGl0IHdhcyByZWFzb25hYmx5IGFkZXF1YXRlIHdo ZW4gT0dQIHdhcyBvbmx5IGV4dGVuZGluZyBhIHNpbmdsZSB3b3JsZCB3aXRoIHBvbGljeS1mcmVl DQpyZWdpb25zLCBidXQgaXQgaXMgaW5zdWZmaWNpZW50IHRvIGRvIGEgZ29vZCBqb2Igb25jZSB3 ZSBnZXQgaW50byBtdWx0aS13b3JsZCBkZXBsb3ltZW50cyB3aXRoIG1vcmUgY29tcGxleCBzZXJ2 aWNlIGFuZCBwb2xpY3kgcGF0dGVybnMgd2hpY2ggcmVxdWlyZSBtdWNoIG1vcmUgZmxleGliaWxp dHkuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+TW9y Z2FpbmUuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+ LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS08L2Rpdj4NCjxkaXY+VmVyc2lvbjogOS44LjMg KEJ1aWxkIDQwMjgpPC9kaXY+DQo8ZGl2PkNoYXJzZXQ6IHV0Zi04PC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj53c0JWQXdVQlNzM0JPTzVNbFU5WHlhaVNBUWoyeVFnQWpyd0twL1loU2Um IzQzO284a2xzUGcvTFYmIzQzO0c2WFMxTGFCaDk8L2Rpdj4NCjxkaXY+MmtFYzMxbGlxdnR0dk9I WW9SZGhyQ01UMlloNUYwUEtqYi9kYURxSy8zZHVUZ1RiejI3N3NaUyYjNDM7UDV4bmZ6eHI8L2Rp dj4NCjxkaXY+Z3NKTjRZLy9rdUtjZG1jM3JRVGFZYWZvOWF6bDRKc2xQS05pUTJsU1RjS0R3QUEx am41aGFtQnVpUDFUZHhRRDwvZGl2Pg0KPGRpdj4xR1FINHpoT1B2RWtmUEpLQ1c0eUdKZHlwMzBk WWRZRnY2S2EvUmw1dkFlc1BYU3RtcG9CUTZ4OWZ4dFNwdlZUPC9kaXY+DQo8ZGl2PlZWNllNSnlF VVlDblUmIzQzOzF2b0dPL3JDSnQxQUtOSkNPVW5DWHgwTiYjNDM7YTVYcml4MG9XN2F6eDN4dzZH Ni9SQ3VWdjwvZGl2Pg0KPGRpdj5HWSYjNDM7bHdlaUUvYnFmVGI0UXI4L2VkVjRGZmV5MmZvMjFw bEtBQlE1d29ycEdLTDkva2ZnMml3PT08L2Rpdj4NCjxkaXY+PTFZQkU8L2Rpdj4NCjxkaXY+LS0t LS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_983F17705339E24699AA251B458249B50CC48CB6E4EXCHANGE2K7of_-- From carlo@alinoe.com Thu Oct 8 04:41:35 2009 Return-Path: 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 B4ED828C13F; Thu, 8 Oct 2009 04:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 VlwxKviOUNaF; Thu, 8 Oct 2009 04:41:35 -0700 (PDT) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id 38B5928C143; Thu, 8 Oct 2009 04:41:34 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep15-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091008114314.FFEX17988.viefep15-int.chello.at@edge01.upc.biz>; Thu, 8 Oct 2009 13:43:14 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id qBjC1c00m0FlQed01BjDg5; Thu, 08 Oct 2009 13:43:14 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MvrQB-0005t6-K6; Thu, 08 Oct 2009 13:44:35 +0200 Date: Thu, 8 Oct 2009 13:44:35 +0200 From: Carlo Wood To: Meadhbh Hamrick Message-ID: <20091008114435.GA22204@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Infinity Linden , "ogpx-bounces@ietf.org" , "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 11:41:36 -0000 On Wed, Oct 07, 2009 at 02:07:58PM -0700, Meadhbh Hamrick wrote: > anyway. just a though. i'm going to spend a little time trying to > understand a couple different country's regulations for online access > to adult materials by minors, just to get a sense for where the > differences would lie. Although admirable, this is just an EXAMPLE. We should look at it, and SOLVE it, in an abstract way; so that we will tackle every possible policy problem like it without that we have to think of an exhausted list now. Ie, if your investigation would show that every country in the world handles online access to adult materials by minors in the exact same way, than that doesn't make the abstract problem go away, we'd just have to think of another example to tackle the exact same problem. -- Carlo Wood From morgaine.dinova@googlemail.com Thu Oct 8 05:30:41 2009 Return-Path: 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 18CDB28C163 for ; Thu, 8 Oct 2009 05:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.266 X-Spam-Level: X-Spam-Status: No, score=-1.266 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=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 XZMX1peoi5zp for ; Thu, 8 Oct 2009 05:30:38 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 86BAE28C13A for ; Thu, 8 Oct 2009 05:30:37 -0700 (PDT) Received: by ewy4 with SMTP id 4so2822191ewy.37 for ; Thu, 08 Oct 2009 05:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KCc6KErdd05LLM4yRviohpMJAdncb9J1L7aPRDIBIjI=; b=l8IU4N3rBJmno4Krw4FvvPoeHqBCdRggFm5m2GuLcttMmr4EIET+nQnhOGvGenbj/c /U/Uqoaqzwzd5o20enbPELAqInVCjVYvF+yVF3KJX8iZ76MVbZjW68hEOU4+avu83mLq XIYlf7hZQ5P9LZaHZsaeVacAbmUuso8IwxqbA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MPNhvRA61MajJdFu/IdHPxiUHEzDokG6XCZEHuo6chRSmJuQ0TZ99eDsT/oxCtNjhT L1rphl7IL9jlcsKnV1Op/9z5YqR2DfSa02XWm7PWqVEZCK1rk1+Re9zkzcj03a5qNywS zkzL2xixCgpMbycS6fTn6v0+KdW1K3XrV4UO0= MIME-Version: 1.0 Received: by 10.211.155.16 with SMTP id h16mr1436512ebo.55.1255005135884; Thu, 08 Oct 2009 05:32:15 -0700 (PDT) In-Reply-To: <983F17705339E24699AA251B458249B50CC48CB6E2@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B50CC48CB6E2@EXCHANGE2K7.office.nic.se> Date: Thu, 8 Oct 2009 13:32:15 +0100 Message-ID: From: Morgaine To: Magnus Zeisig Content-Type: multipart/alternative; boundary=00504502c9e050d21604756ba724 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 12:30:41 -0000 --00504502c9e050d21604756ba724 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Magnus, you're mixing up my analysis of what's required for Joshua's scheme to work, with my recognition that we need a more flexible approach based no= t on this restrictive AD+RD split but on the much more flexible decoupled services behind them. When I speak of AD1+RD1 and AD2+RD2 in the analysis, this is *not at all *= the actual deployment scenario that any of us expects to see. It's just the smallest case that allows us to say something concrete about the problems with the original OGP design when extrapolated to the multi-world deploymen= t scenario. So please don't attribute any narrow vision in this scenario to me --- I'm fully aware that it's artificial and is going almost nowhere. I'm merely doing a smallest-possible scenario analysis. My personal interest is in the fully expanded and massively scaled deployments which the AWG group in SL was originally formed to consider 2 years ago (this might give you some idea of the scale --- https://wiki.secondlife.com/wiki/Project_Motivation ) , but there's no poin= t describing a massively complex deployment example when a simpler one suffices to make a specific point. :-) So to your post ... On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeisig wrote= : > Morgaine, > > No, you are still stuck in the concept of one virtual world equals one AD > plus one RD, even if you say you recognize a future more complex service > pattern. VW=3DAD+RD does not have to be the case with VWRAP. I know that it's artificial. We're merely examining this small scenario to highlight an elementary problem with distribution of services, and it has already been useful. It has demonstrated that even in this miniscule example, there need to be (i) asset service contributions from *both* world= s in the example, so just a single inventory service in AD1 is not adequate, and (ii) that if ADs control region policy then AD2 must be consulted as well since it has every bit as much right to determine policy in RD2 as doe= s AD1, or more. These are important constraints on the design, despite the deployment example being such a simple one. In addition to the case shown, there are simpler cases and there are more complex cases. The simpler cases, such as no AD2 exists, or only W1 asset services are use= d in W2, can be handled by the original OGP design, so they wouldn't have served the purpose here. More complex cases, such as multiple RDs in W2, d= o not add value to the particular point being made, so why complicate the scenario unnecessarily? We'll certainly need them later, but they don't help here. Obviously multi-world deployment scenarios such as we expect to be common i= n the metaverse are going to have much more complex deployment patterns involved a myriad of concurrent services, but adding that complexity at thi= s point doesn't enhance the present argument. If it _happens_ to be the case and the entity controlling AD2 and RD2 wants > to enforce AD2 policy for those visiting RD2, then they can move, duplica= te > or mirror the enforcement of that policy from AD2 to RD2, which they can = do > without problems as long as they control both. If they don't control both= , > then it's entirely up to the entity controlling RD2 if they for some reas= on > want to enforce the policy of the entity controlling AD2. So I see no rea= son > whatsoever why symmetry is required. > Ah, here you've simply misunderstood me: you think I'm talking about * deployment* symmetry, but I'm not. I'm talking about *definition*symmetry: if ADs are defined to be able to control region policies, then by symmetry that applies to all ADs. It wouldn't make sense to say "ADs are defined to carry region policy, but this only applies to our ADs and not to yours." ;-) That's what I mean by this applying symmetrically. Deployment patterns are of course arbitrary and don't have to be symmetrical: two interoperating worlds can individually be using any deployment pattern they choose, and one world of the pair will generally have no say on the deployment pattern used by the other. Across the whole metaverse, we can expect every single possible deployment pattern to be use= d by someone, and for added spice, tourists from every possible deployment could be visiting some common tourist world to create a kaleidescope of combined deployments in the region. > Policy is not decided and enforced by the AD, the RD or any service > connected with them, it is decided and enforced by the entities behind th= em. > If the same entity controls an AD and a RD, then it's meaningless to try = to > divide up that entity's policy into AD policy and RD policy, because it c= an > enforce that policy at any level, type of domain or connected service it > controls. > Sure, but someone has to code this stuff. It's not helpful to say "Anythin= g can be done anywhere", because that would mean that the protocol would at every decision point have to gather policy contributions from all possible endpoints. It *can* be done this way of course, but if a simpler design suffices then a more compex one may not be a good idea. That said, take note of David's advice about policy being best implemented in the services themselves. Domains are not necessarily bad, but they do actually restrict our flexibility substantially compared to using decoupled services alone. > > But, like you, I am totally in favor of letting the entity controlling th= e > destination RD decide policy once the agent is there. However, if the > agent's own AD for some reason wants to stop the agent from going there, > then I think it should have the possibility to do so. In all honesty, I > don't think an AD imposing undue restrictions on where people are allowed= to > go or what they are allowed to do there will survive for long though, onc= e > competition is in place. You may have to start out fresh, with a new AD, > without the assets and inventory connected to the old AD, but I think mos= t > people are willing to take that step if they feel their freedom is too > limited. Well in my case I'm not merely "*in favour*" of region policy control by regions. I don't think it's actually optional in multi-world deployments, because without Destination Determines Destination Policy there can be no viable multi-world tourism at all, and that's the primary use case with massive popular interest. We wouldn't have much of a metaverse without it. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeisig wrote= : > Morgaine, > > No, you are still stuck in the concept of one virtual world equals one AD > plus one RD, even if you say you recognize a future more complex service > pattern. VW=3DAD+RD does not have to be the case with VWRAP. If it _happe= ns_ > to be the case and the entity controlling AD2 and RD2 wants to enforce AD= 2 > policy for those visiting RD2, then they can move, duplicate or mirror th= e > enforcement of that policy from AD2 to RD2, which they can do without > problems as long as they control both. If they don't control both, then i= t's > entirely up to the entity controlling RD2 if they for some reason want to > enforce the policy of the entity controlling AD2. So I see no reason > whatsoever why symmetry is required. > > Policy is not decided and enforced by the AD, the RD or any service > connected with them, it is decided and enforced by the entities behind th= em. > If the same entity controls an AD and a RD, then it's meaningless to try = to > divide up that entity's policy into AD policy and RD policy, because it c= an > enforce that policy at any level, type of domain or connected service it > controls. > > But, like you, I am totally in favor of letting the entity controlling th= e > destination RD decide policy once the agent is there. However, if the > agent's own AD for some reason wants to stop the agent from going there, > then I think it should have the possibility to do so. In all honesty, I > don't think an AD imposing undue restrictions on where people are allowed= to > go or what they are allowed to do there will survive for long though, onc= e > competition is in place. You may have to start out fresh, with a new AD, > without the assets and inventory connected to the old AD, but I think mos= t > people are willing to take that step if they feel their freedom is too > limited. > > Best regards, > > Magnus > > > -----Ursprungligt meddelande----- > Fr=E5n: Morgaine [mailto:morgaine.dinova@googlemail.com] > Skickat: den 8 oktober 2009 11:42 > Till: Magnus Zeisig > Kopia: ogpx@ietf.org > =C4mne: Re: [ogpx] Protocol for permitting policy decisions > > Magnus, > > If ADs are involved in region policy, then in the multi-world deployment > pattern, AD2 will have to be consulted when agent A1 teleports from RD1 t= o > RD2, because AD2 will be involved in region policy too. It's symmetric w= ith > AD1. > > This is what Joshua wanted to avoid, and it can only be avoided by not > giving ADs policy control over regions, otherwise symmetry requires that = AD2 > be consulted as well. > > It's this kind of problem that reinforces what David's been saying about > the right mess we currently have when talking about domains determining > policy. The AD/RD split was reasonably adequate when OGP was only extend= ing > a single world with policy-free regions, but it is insufficient to do a g= ood > job once we get into multi-world deployments with more complex service an= d > policy patterns which require much more flexibility. > > > Morgaine. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig > wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I am strongly in favour of leaving policy descisions to the RD, bu= t > since there seems to be a need for at least some AD managers to be able t= o > make policy decisions as well, I guess the protocol handshake need even m= ore > flexibility than the versions scetched on by Meadhbh, Carlo and me so far= . I > will adapt the diagram style of Meadhbh and Carlo ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html), since > it's more readable than my text-flow variant. Also, I will leave out > parameter examples since there seem to be a risk people get hooked on if = a > certain parameter should be included or not, rather than the possibility = of > handling any parameter. > > I may be paranoid, but I still prefer agent domains to be allowed, > but not forced by protocol, to reduce the dissemination of information ab= out > their clients as far as possible, and there Carlo's AND version in the > response is a good step forward ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html). We migh= t > even wind up with negotiations where one domain requests the actual value= s > while the other domain only wants to disseminate a reply to if it fits a > range for one or more of the requested parameters. > > AD -------------------------(name, RDkey2?>)------------------------> RD > AD <--(name, agentkey2?>)--- RD > AD --(name, range?>)-> RD > AD <----------(name, range>)----------- RD > AD ----------------------------(name, agentkey2 > OK)---------------------------> RD > AD <-----------------------------(name, rez > cap)------------------------------- RD > > In this example, RD might have refused giving the required range f= or > agentvalue2, either because it technically doesn't support that kind of > negotiation or because of policy, in either case of which the rez cap wou= ld > have failed. It might on the other hand instead already from the beginnin= g > have supplied the required ranges instead of asking for the actual value.= I > think it would be good if the protocol would enable either of these cases > for maximum flexibility. > > It may also be an idea to permit caching of at least AD- and > RD-parameters or evaluations of them, especially if we're talking extensi= ve > sets with perhaps hundreds of parameters. Since the ADs and RDs should be > free to update their own parameters at any time, the handshake in that ca= se > must of course contain a check if cached parameters have been updated. Al= so, > if an AD or RD supports several sets of parameters depending on which dom= ain > or service it deals with, means to distinguish between them are required, > perhaps using policy URI's the way Meadhbh suggested ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html). A polic= y > could then basically be broken down into a set of own parameter values an= d > required parameter ranges for the domain or service connecting. > > I also think, like Meadhbh ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html), that we > will need to suggest, but not require, a number of parameter name and > formats to facilitate communication, so that not e.g. US and UK domains > can't connect, because one asks about "color" and the other one only can > respond about "colour". > > Best regards, > > Magnus > > > - -----Ursprungligt meddelande----- > Fr=E5n: Carlo Wood [mailto:carlo@alinoe.com] > Skickat: den 7 oktober 2009 22:36 > Till: Infinity Linden > Kopia: Magnus Zeisig; ogpx@ietf.org > =C4mne: Re: [ogpx] Protocol for permitting policy decisions > > On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden wrote: > > option 3: multi-message handshake > > > > AD --------------- (name) -------------> RD > > AD <-------- (X, age > X? cap) --------- RD > > > > AD ------------------------------------> RD (age > X? cap) > > AD <------------ (rez cap) ------------- RD > > Note, again, the need for a flexible protocol negotiation: > we can't know, already, what all will be needed. > > Nevertheless, the more flexibility the better imho. > I'd prefer to see this: > > AD ------(name, ) -----------> RD > AD <-----(name, ) --- RD > AD ------(name, yes/no)--------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > Where VWRAP will not define what keywords are possible. > > However, implementers might, for example, choose to use 'AGE' as > keyword > with an integer range, leading to a msg exchange like > > AD ------(name, (AGE)) -----------> RD > AD <-----(name, (AGE, 21)) -------- RD > AD ------(name, yes)--------------> RD > AD <-----(rez cap) ---------------- RD > > or some might implement > > AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD > AD <-----(name, (AGE, 13), YES) ------------------ RD > AD ------(name, yes, yes)------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > For privacy reasons, I think it would suffice to > just send the AND of all 'yes's, thus: > > AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD > AD <-----(name, (AGE, 13), YES) ------------------ RD > AD ------(name, yes)-----------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > or, > > AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD > AD <-----(name, (AGE, 13), DONTCARE) ------------- RD > AD ------(name, yes)-----------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > Again, neither 'AGE' nor 'LIKES_BUNNIES', would be defined by us, > but we would define how to handle integer ranges, booleans, > don't cares, string literals, and perhaps regular expressions. > > - -- > Carlo Wood > > -----BEGIN PGP SIGNATURE----- > Version: 9.8.3 (Build 4028) > Charset: utf-8 > > wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al3nKcL > JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfgs7Ta/ > cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9ByIbMJ > RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOzWzsWm > tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bldq/Bnd > 60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w=3D=3D > =3D2NSu > -----END PGP SIGNATURE----- > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --00504502c9e050d21604756ba724 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Magnus, you're mixing up my analysis of what's required for Joshua&= #39;s scheme to work, with my recognition that we need a more flexible appr= oach based not on this restrictive AD+RD split but on the much more flexibl= e decoupled services behind them.

When I speak of AD1+RD1 and AD2+RD2 in the analysis, this is not = at all=A0 the actual deployment scenario that any of us expects to = see.=A0 It's just the smallest case that allows us to say something con= crete about the problems with the original OGP design when extrapolated to = the multi-world deployment scenario.=A0 So please don't attribute any n= arrow vision in this scenario to me --- I'm fully aware that it's a= rtificial and is going almost nowhere.=A0 I'm merely doing a smallest-p= ossible scenario analysis.

My personal interest is in the fully expanded and massively scaled depl= oyments which the AWG group in SL was originally formed to consider 2 years= ago (this might give you some idea of the scale ---=A0 https://wiki.secondlife.com/wi= ki/Project_Motivation ) , but there's no point describing a massive= ly complex deployment example when a simpler one suffices to make a specifi= c point. :-)

So to your post ...

On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeis= ig <magnus.zei= sig@iis.se> wrote:
Morgaine,

No, you are still stuck in the concept of one virtual world equals one AD plus one RD, even if you say you recognize a future more complex service pattern. VW=3DAD+RD does not have to be the case with VWRAP.


I know that it's artificial.=A0 We're merely exa= mining this small scenario to highlight an elementary problem with distribu= tion of services, and it has already been useful.=A0 It has demonstrated th= at even in this miniscule example, there need to be (i) asset service contr= ibutions from both worlds in the example, so just a single inventory= service in AD1 is not adequate, and (ii) that if ADs control region policy= then AD2 must be consulted as well since it has every bit as much right to= determine policy in RD2 as does AD1, or more.=A0 These are important const= raints on the design, despite the deployment example being such a simple on= e.

In addition to the case shown, there are simpler cases and there are mo= re complex cases.

The simpler cases, such as no AD2 exists, or only = W1 asset services are used in W2, can be handled by the original OGP design= , so they wouldn't have served the purpose here.=A0 More complex cases,= such as multiple RDs in W2, do not add value to the particular point being= made, so why complicate the scenario unnecessarily?=A0 We'll certainly= need them later, but they don't help here.

Obviously multi-world deployment scenarios such as we expect to be comm= on in the metaverse are going to have much more complex deployment patterns= involved a myriad of concurrent services, but adding that complexity at th= is point doesn't enhance the present argument.
=A0

= If it _happens_ to be the case and the entity controlling AD2 and RD2 wants to enforce AD2 policy for those visiting RD2, then they can move, duplicate or mirror the enforcement of that policy from AD2 to RD2, which they can do without problems as long as they control both. If they don't control both, then it's entirely up to the entity controlling RD2 if they for some reason want to enforce the policy of the entity controlling AD2. So I see no reason whatsoever why symmetry is required.


Ah, here you've simply misund= erstood me:=A0 you think I'm talking about deployment symmetry, = but I'm not.=A0 I'm talking about definition symmetry:=A0 if= ADs are defined to be able to control region policies, then by symmetry th= at applies to all ADs.=A0 It wouldn't make sense to say "ADs are d= efined to carry region policy, but this only applies to our ADs and not to = yours."=A0 ;-)=A0 That's what I mean by this applying symmetricall= y.

Deployment patterns are of course arbitrary and don't ha= ve to be symmetrical:=A0 two interoperating worlds can individually be usin= g any deployment pattern they choose, and one world of the pair will genera= lly have no say on the deployment pattern used by the other.=A0 Across the = whole metaverse, we can expect every single possible deployment pattern to = be used by someone, and for added spice, tourists from every possible deplo= yment could be visiting some common tourist world to create a kaleidescope = of combined deployments in the region.

=A0
Policy is not decided and enforced by the AD, the RD or any service connected with them, it is decided and enforced by the entities behind them. If the same entity controls an AD and a RD, then it's meaningless to try to divide up that entity's policy into AD policy and RD policy, because it can enforce that policy at any level, type of domain or connected service it controls.


Sure, but someo= ne has to code this stuff.=A0 It's not helpful to say "Anything ca= n be done anywhere", because that would mean that the protocol would a= t every decision point have to gather policy contributions from all possibl= e endpoints.=A0 It can be done this way of course, but if a simpler = design suffices then a more compex one may not be a good idea.

That said, take note of David's advice about policy being best impl= emented in the services themselves.=A0 Domains are not necessarily bad, but= they do actually restrict our flexibility substantially compared to using = decoupled services alone.
=A0

But, like you, I am totally in favor of letting the entity controlling the destination RD decide policy once the agent is there. However, if the agent's own AD for some reason wants to stop the agent from going there, then I think it should have the possibility to do so. In all honesty, I don't think an AD imposing undue restrictions on where people are allowed to go or what they are allowed to do there will survive for long though, once competition is in place. You may have to start out fresh, with a new AD, without the assets and inventory connected to the old AD, but I think most people are willing to take that step if they feel their freedom is too limited.


We= ll in my case I'm not merely "in favour" of reg= ion policy control by regions.=A0 I don't think it's actually optio= nal in multi-world deployments, because without Destination Determines Dest= ination Policy there can be no viable multi-world tourism at all, and that&= #39;s the primary use case with massive popular interest.=A0 We wouldn'= t have much of a metaverse without it.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D


On Thu, Oct 8, 2009 at 11:3= 0 AM, Magnus Zeisig <magnus.zeisig@iis.se> wrote:
Morgaine,

No, you are still stuck in the concept of one virtual world equals one AD p= lus one RD, even if you say you recognize a future more complex service pat= tern. VW=3DAD+RD does not have to be the case with VWRAP. If it _happens_ t= o be the case and the entity controlling AD2 and RD2 wants to enforce AD2 p= olicy for those visiting RD2, then they can move, duplicate or mirror the e= nforcement of that policy from AD2 to RD2, which they can do without proble= ms as long as they control both. If they don't control both, then it= 9;s entirely up to the entity controlling RD2 if they for some reason want = to enforce the policy of the entity controlling AD2. So I see no reason wha= tsoever why symmetry is required.

Policy is not decided and enforced by the AD, the RD or any service connect= ed with them, it is decided and enforced by the entities behind them. If th= e same entity controls an AD and a RD, then it's meaningless to try to = divide up that entity's policy into AD policy and RD policy, because it= can enforce that policy at any level, type of domain or connected service = it controls.

But, like you, I am totally in favor of letting the entity controlling the = destination RD decide policy once the agent is there. However, if the agent= 's own AD for some reason wants to stop the agent from going there, the= n I think it should have the possibility to do so. In all honesty, I don= 9;t think an AD imposing undue restrictions on where people are allowed to = go or what they are allowed to do there will survive for long though, once = competition is in place. You may have to start out fresh, with a new AD, wi= thout the assets and inventory connected to the old AD, but I think most pe= ople are willing to take that step if they feel their freedom is too limite= d.

Best regards,

Magnus


-----Ursprungligt meddelande-----
Fr=E5n: Morgaine [mailto:morgaine.dinova@googlemail.com]
Skickat: den 8 oktober 2009 11:42
Till: Magnus Zeisig
Kopia: ogpx@ietf.org
=C4mne: Re: [ogpx] Protocol for permittin= g policy decisions

Magnus,

If ADs are involved in region policy, then in the multi-world deployment pa= ttern, AD2 will have to be consulted when agent A1 teleports from RD1 to RD= 2, because AD2 will be involved in region policy too. =A0It's symmetric= with AD1.

This is what Joshua wanted to avoid, and it can only be avoided by not givi= ng ADs policy control over regions, otherwise symmetry requires that AD2 be= consulted as well.

It's this kind of problem that reinforces what David's been saying = about the right mess we currently have when talking about domains determini= ng policy. =A0The AD/RD split was reasonably adequate when OGP was only ext= ending a single world with policy-free regions, but it is insufficient to d= o a good job once we get into multi-world deployments with more complex ser= vice and policy patterns which require much more flexibility.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D


On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig <magnus.zeisig@iis.se> wrote:



=A0 =A0 =A0 =A0-----BEGIN PGP SIGNED MESSAGE-----
=A0 =A0 =A0 =A0Hash: SHA256

=A0 =A0 =A0 =A0I am strongly in favour of leaving policy descisions to the= RD, but since there seems to be a need for at least some AD managers to be= able to make policy decisions as well, I guess the protocol handshake need= even more flexibility than the versions scetched on by Meadhbh, Carlo and = me so far. I will adapt the diagram style of Meadhbh and Carlo (http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html= ), since it's more readable than my text-flow variant. Also, I will lea= ve out parameter examples since there seem to be a risk people get hooked o= n if a certain parameter should be included or not, rather than the possibi= lity of handling any parameter.

=A0 =A0 =A0 =A0I may be paranoid, but I still prefer agent domains to be a= llowed, but not forced by protocol, to reduce the dissemination of informat= ion about their clients as far as possible, and there Carlo's AND versi= on in the response is a good step forward (http://www.ie= tf.org/mail-archive/web/ogpx/current/msg00520.html). We might even wind= up with negotiations where one domain requests the actual values while the= other domain only wants to disseminate a reply to if it fits a range for o= ne or more of the requested parameters.

=A0 =A0 =A0 =A0AD -------------------------(name, <RDkey1?, RDkey2?>= )------------------------> RD
=A0 =A0 =A0 =A0AD <--(name, <RDvalue1, RDvalue2, ADkey1?, ADkey2?, a= gentkey1?, agentkey2?>)--- RD
=A0 =A0 =A0 =A0AD --(name, <RDvalues OK, ADvalue1, ADvalue2, agentvalue= 1, agentkey2 range?>)-> RD
=A0 =A0 =A0 =A0AD <----------(name, <ADvalues OK, agentvalue1 OK, ag= entkey2 range>)----------- RD
=A0 =A0 =A0 =A0AD ----------------------------(name, agentkey2 OK)--------= -------------------> RD
=A0 =A0 =A0 =A0AD <-----------------------------(name, rez cap)--------= ----------------------- RD

=A0 =A0 =A0 =A0In this example, RD might have refused giving the required = range for agentvalue2, either because it technically doesn't support th= at kind of negotiation or because of policy, in either case of which the re= z cap would have failed. It might on the other hand instead already from th= e beginning have supplied the required ranges instead of asking for the act= ual value. I think it would be good if the protocol would enable either of = these cases for maximum flexibility.

=A0 =A0 =A0 =A0It may also be an idea to permit caching of at least AD- an= d RD-parameters or evaluations of them, especially if we're talking ext= ensive sets with perhaps hundreds of parameters. Since the ADs and RDs shou= ld be free to update their own parameters at any time, the handshake in tha= t case must of course contain a check if cached parameters have been update= d. Also, if an AD or RD supports several sets of parameters depending on wh= ich domain or service it deals with, means to distinguish between them are = required, perhaps using policy URI's the way Meadhbh suggested (http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html= ). A policy could then basically be broken down into a set of own param= eter values and required parameter ranges for the domain or service connect= ing.

=A0 =A0 =A0 =A0I also think, like Meadhbh (http://www.i= etf.org/mail-archive/web/ogpx/current/msg00523.html), that we will need= to suggest, but not require, a number of parameter name and formats to fac= ilitate communication, so that not e.g. US and UK domains can't connect= , because one asks about "color" and the other one only can respo= nd about "colour".

=A0 =A0 =A0 =A0Best regards,

=A0 =A0 =A0 =A0Magnus


=A0 =A0 =A0 =A0- -----Ursprungligt meddelande-----
=A0 =A0 =A0 =A0Fr=E5n: Carlo Wood [mailto:carlo@alinoe.com]
=A0 =A0 =A0 =A0Skickat: den 7 oktober 2009 22:36
=A0 =A0 =A0 =A0Till: Infinity Linden
=A0 =A0 =A0 =A0Kopia: Magnus Zeisig; ogpx= @ietf.org
=A0 =A0 =A0 =A0=C4mne: Re: [ogpx] Protocol for permitting policy decisions=

=A0 =A0 =A0 =A0On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden w= rote:
=A0 =A0 =A0 =A0> option 3: multi-message handshake
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> AD --------------- (name) -------------> RD
=A0 =A0 =A0 =A0> AD <-------- (X, age > X? cap) --------- RD
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> AD ------------------------------------> RD (age &g= t; X? cap)
=A0 =A0 =A0 =A0> AD <------------ (rez cap) ------------- RD

=A0 =A0 =A0 =A0Note, again, the need for a flexible protocol negotiation:<= br> =A0 =A0 =A0 =A0we can't know, already, what all will be needed.

=A0 =A0 =A0 =A0Nevertheless, the more flexibility the better imho.
=A0 =A0 =A0 =A0I'd prefer to see this:

=A0 =A0 =A0 =A0AD ------(name, <list with keywords>) ----------->= RD
=A0 =A0 =A0 =A0AD <-----(name, <list with keywords + ranges>) ---= RD
=A0 =A0 =A0 =A0AD ------(name, yes/no)--------------------------> RD =A0 =A0 =A0 =A0AD <-----(rez cap) ------------------------------- RD
=A0 =A0 =A0 =A0Where VWRAP will not define what keywords are possible.

=A0 =A0 =A0 =A0However, implementers might, for example, choose to use = 9;AGE' as keyword
=A0 =A0 =A0 =A0with an integer range, leading to a msg exchange like

=A0 =A0 =A0 =A0AD ------(name, (AGE)) -----------> RD
=A0 =A0 =A0 =A0AD <-----(name, (AGE, 21)) -------- RD
=A0 =A0 =A0 =A0AD ------(name, yes)--------------> RD
=A0 =A0 =A0 =A0AD <-----(rez cap) ---------------- RD

=A0 =A0 =A0 =A0or some might implement

=A0 =A0 =A0 =A0AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD =A0 =A0 =A0 =A0AD <-----(name, (AGE, 13), YES) ------------------ RD =A0 =A0 =A0 =A0AD ------(name, yes, yes)------------------------> RD =A0 =A0 =A0 =A0AD <-----(rez cap) ------------------------------- RD
=A0 =A0 =A0 =A0For privacy reasons, I think it would suffice to
=A0 =A0 =A0 =A0just send the AND of all 'yes's, thus:

=A0 =A0 =A0 =A0AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD =A0 =A0 =A0 =A0AD <-----(name, (AGE, 13), YES) ------------------ RD =A0 =A0 =A0 =A0AD ------(name, yes)-----------------------------> RD =A0 =A0 =A0 =A0AD <-----(rez cap) ------------------------------- RD
=A0 =A0 =A0 =A0or,

=A0 =A0 =A0 =A0AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD =A0 =A0 =A0 =A0AD <-----(name, (AGE, 13), DONTCARE) ------------- RD =A0 =A0 =A0 =A0AD ------(name, yes)-----------------------------> RD =A0 =A0 =A0 =A0AD <-----(rez cap) ------------------------------- RD
=A0 =A0 =A0 =A0Again, neither 'AGE' nor 'LIKES_BUNNIES', w= ould be defined by us,
=A0 =A0 =A0 =A0but we would define how to handle integer ranges, booleans,=
=A0 =A0 =A0 =A0don't cares, string literals, and perhaps regular expre= ssions.

=A0 =A0 =A0 =A0- --
=A0 =A0 =A0 =A0Carlo Wood <carlo@al= inoe.com>

=A0 =A0 =A0 =A0-----BEGIN PGP SIGNATURE-----
=A0 =A0 =A0 =A0Version: 9.8.3 (Build 4028)
=A0 =A0 =A0 =A0Charset: utf-8

=A0 =A0 =A0 =A0wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al= 3nKcL
=A0 =A0 =A0 =A0JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfg= s7Ta/
=A0 =A0 =A0 =A0cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9B= yIbMJ
=A0 =A0 =A0 =A0RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOz= WzsWm
=A0 =A0 =A0 =A0tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bld= q/Bnd
=A0 =A0 =A0 =A060Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w=3D= =3D
=A0 =A0 =A0 =A0=3D2NSu
=A0 =A0 =A0 =A0-----END PGP SIGNATURE-----



=A0 =A0 =A0 =A0_______________________________________________
=A0 =A0 =A0 =A0ogpx mailing list
=A0 =A0 =A0 =A0ogpx@ietf.org
=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/ogpx





--00504502c9e050d21604756ba724-- From magnus.zeisig@iis.se Thu Oct 8 05:37:58 2009 Return-Path: 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 1DDBD28C166 for ; Thu, 8 Oct 2009 05:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 7sL3fNwKEUkl for ; Thu, 8 Oct 2009 05:37:57 -0700 (PDT) Received: from cleaner.prod.iis.se (cleaner.prod.iis.se [212.247.7.212]) by core3.amsl.com (Postfix) with ESMTP id 54AD128C15C for ; Thu, 8 Oct 2009 05:37:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cleaner.prod.iis.se (Postfix) with ESMTP id 05F10A8008; Thu, 8 Oct 2009 12:39:38 +0000 (UTC) Received: from cleaner.prod.iis.se ([127.0.0.1]) by localhost (cleaner.prod.iis.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11706-03; Thu, 8 Oct 2009 12:39:32 +0000 (UTC) Received: from pgpkeys.office.nic.se (pgpkeys.office.nic.se [212.247.204.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cleaner.prod.iis.se (Postfix) with ESMTP id C8FE5A802F; Thu, 8 Oct 2009 12:39:27 +0000 (UTC) Received: from EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) by pgpkeys.office.nic.se (PGP Universal service); Thu, 08 Oct 2009 14:39:27 +0200 X-PGP-Universal: processed; by pgpkeys.office.nic.se on Thu, 08 Oct 2009 14:39:27 +0200 Received: from Exchange2k7.office.nic.se ([169.254.1.222]) by EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) with mapi; Thu, 8 Oct 2009 14:39:27 +0200 From: Magnus Zeisig To: Carlo Wood , Meadhbh Hamrick Date: Thu, 8 Oct 2009 14:39:26 +0200 Thread-Topic: [ogpx] Protocol for permitting policy decisions Thread-Index: AcpIDKeeAB+XLLXKQRS79NsuQD0bVQAAv6tA Message-ID: <983F17705339E24699AA251B458249B50CC48CB737@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> <20091008114435.GA22204@alinoe.com> In-Reply-To: <20091008114435.GA22204@alinoe.com> Accept-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-pgp-encoding-version: 2.0.2 x-pgp-mapi-encoding-version: 2.5.0 x-pgp-encoding-format: Partitioned x-pgp-universal-saved-content-codepage: utf-8 acceptlanguage: sv-SE MIME-Version: 1.0 Content-Language: sv-SE Content-Type: multipart/alternative; boundary="_000_983F17705339E24699AA251B458249B50CC48CB737EXCHANGE2K7of_" X-Virus-Scanned: Debian amavisd-new at cleaner.prod.iis.se Cc: Infinity Linden , "ogpx-bounces@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 12:37:58 -0000 --_000_983F17705339E24699AA251B458249B50CC48CB737EXCHANGE2K7of_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkhlaCwg ZG9uJ3Qgd29ycnkgYWJvdXQgZmluZGluZyBvdXQgcmVndWxhdGlvbnMgYWJvdXQgYWR1bHQgbWF0 ZXJpYWwgaXMgdGhlIHNhbWUgYWxsIG92ZXIgdGhlIHdvcmxkLiBJJ3ZlIGJlZW4gYXQgdGhhdCBj YW4gb2Ygd29ybXMgbXlzZWxmLCBhbmQgdGhlcmUgYXJlIHBsYWNlcyB3aGVyZSBpdCdzIHJlZ3Vs YXRlZCBvciBub3QsIGRpZmZlcmVudCBhZ2VzLCBmcm9tIDEzICh0aGUgbG93ZXN0IGFnZSBJIGtu b3cgb2YpIHRvIGZvcmJpZGRlbiBmb3IgImFkdWx0cyIgYXMgd2VsbCwgZGlmZmVyZW50IGRlZmlu aXRpb25zIG9mIHdoYXQncyBpbmNsdWRlZCBhbmQgbm90LCBkaWZmZXJlbnQgdHlwZSBkaXN0aW5j dGlvbnMgYW5kIGRlZ3JlZXMgcGVybWlzc2libGUuIFNvbWUgcGxhY2VzIHN1cHBvcnQgbGF3IHN1 aXRzIGFnYWluc3QgcHVibGlzaGVycyBpbiBvdGhlciBwbGFjZXMgZXZlbiBpZiBpdCdzIHBlcmZl Y3RseSBsZWdhbCBhdCB0aGUgcHVibGlzaGVyJ3MgaG9tZSBsb2NhdGlvbiwgYW5kIHNvIG9uLg0K DQpCdXQgeW91IGFyZSBxdWl0ZSByaWdodCBpbiB0aGF0IHdlIHNob3VsZG4ndCBzdGFyZSBvdXJz ZWx2ZXMgYmxpbmQgYXQgc3BlY2lhbCBjYXNlcyBsaWtlIGFkdWx0IGNvbnRlbnQsIGJ1dCBmaW5k IGdlbmVyYWwgbWVjaGFuaXNtcyB0byBoYW5kbGUgcG9saWN5IG5lZ290aWF0aW9uIGluIHRoZSBW V1JBUCBwcm90b2NvbC4gVGhlIGFjdHVhbCBwb2xpY3kgZGVjaXNpb25zIHNob3VsZCwgYXMgc3Rh dGVkIG1hbnkgdGltZXMgYmVmb3JlLCBiZSBvdXRzaWRlIHRoZSBwcm90b2NvbC4gSSB0aGluayBz b21lIGltcG9ydGFudCBxdWVzdGlvbnMgaW4gdGhhdCByZXNwZWN0IG1heSBiZSBpZiBzdWNoIG1l Y2hhbmlzbXMNCjEuIG5lZWQgdG8gYmUgZGlmZmVyZW50IGZyb20gZXhjaGFuZ2luZyBvdGhlciBp bmZvcm1hdGlvbj8NCjIuIHJlcXVpcmUgYW55IHNwZWNpYWwgc3VwcG9ydCBmb3IgZXhjaGFuZ2lu ZyBjcmVkZW50aWFscyBsaWtlIGUuZy4gZWxlY3Ryb25pYyBzaWduYXR1cmVzPw0KMy4gbmVlZCB0 byBzZXJ2ZSBhbHNvIHNlcnZpY2VzIG90aGVyIHRoYW4gQUQgYW5kIFJEPw0KNC4gcmVxdWlyZSBh bnkgc3BlY2lhbCBpbmZyYXN0cnVjdHVyZSBsaWtlIHNlcGFyYXRlIERURHMsIG1hY2hpbmUgcmVh ZGFibGUgcG9saWN5IGRvY3VtZW50cyBvciB0aGUgbGlrZT8NCjUuIHNob3VsZCBmYWNpbGl0YXRl IGF1dG9tYXRpYyBzZXR1cCBvZiB0cnVzdCBkb21haW5zPw0KDQpCZXN0IHJlZ2FyZHMsDQoNCk1h Z251cw0KDQoNCi0gLS0tLS1VcnNwcnVuZ2xpZ3QgbWVkZGVsYW5kZS0tLS0tDQpGcsOlbjogQ2Fy bG8gV29vZCBbbWFpbHRvOmNhcmxvQGFsaW5vZS5jb21dDQpTa2lja2F0OiBkZW4gOCBva3RvYmVy IDIwMDkgMTM6NDUNClRpbGw6IE1lYWRoYmggSGFtcmljaw0KS29waWE6IE1hZ251cyBaZWlzaWc7 IEluZmluaXR5IExpbmRlbjsgb2dweC1ib3VuY2VzQGlldGYub3JnOyBvZ3B4QGlldGYub3JnDQrD hG1uZTogUmU6IFtvZ3B4XSBQcm90b2NvbCBmb3IgcGVybWl0dGluZyBwb2xpY3kgZGVjaXNpb25z DQoNCk9uIFdlZCwgT2N0IDA3LCAyMDA5IGF0IDAyOjA3OjU4UE0gLTA3MDAsIE1lYWRoYmggSGFt cmljayB3cm90ZToNCj4gYW55d2F5LiBqdXN0IGEgdGhvdWdoLiBpJ20gZ29pbmcgdG8gc3BlbmQg YSBsaXR0bGUgdGltZSB0cnlpbmcgdG8NCj4gdW5kZXJzdGFuZCBhIGNvdXBsZSBkaWZmZXJlbnQg Y291bnRyeSdzIHJlZ3VsYXRpb25zIGZvciBvbmxpbmUgYWNjZXNzDQo+IHRvIGFkdWx0IG1hdGVy aWFscyBieSBtaW5vcnMsIGp1c3QgdG8gZ2V0IGEgc2Vuc2UgZm9yIHdoZXJlIHRoZQ0KPiBkaWZm ZXJlbmNlcyB3b3VsZCBsaWUuDQoNCkFsdGhvdWdoIGFkbWlyYWJsZSwgdGhpcyBpcyBqdXN0IGFu IEVYQU1QTEUuIFdlIHNob3VsZCBsb29rIGF0IGl0LA0KYW5kIFNPTFZFIGl0LCBpbiBhbiBhYnN0 cmFjdCB3YXk7IHNvIHRoYXQgd2Ugd2lsbCB0YWNrbGUgZXZlcnkNCnBvc3NpYmxlIHBvbGljeSBw cm9ibGVtIGxpa2UgaXQgd2l0aG91dCB0aGF0IHdlIGhhdmUgdG8gdGhpbmsgb2YNCmFuIGV4aGF1 c3RlZCBsaXN0IG5vdy4NCg0KSWUsIGlmIHlvdXIgaW52ZXN0aWdhdGlvbiB3b3VsZCBzaG93IHRo YXQgZXZlcnkgY291bnRyeSBpbiB0aGUNCndvcmxkIGhhbmRsZXMgb25saW5lIGFjY2VzcyB0byBh ZHVsdCBtYXRlcmlhbHMgYnkgbWlub3JzIGluIHRoZQ0KZXhhY3Qgc2FtZSB3YXksIHRoYW4gdGhh dCBkb2Vzbid0IG1ha2UgdGhlIGFic3RyYWN0IHByb2JsZW0gZ28NCmF3YXksIHdlJ2QganVzdCBo YXZlIHRvIHRoaW5rIG9mIGFub3RoZXIgZXhhbXBsZSB0byB0YWNrbGUgdGhlDQpleGFjdCBzYW1l IHByb2JsZW0uDQoNCi0gLS0NCkNhcmxvIFdvb2QgPGNhcmxvQGFsaW5vZS5jb20+DQoNCi0tLS0t QkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiA5LjguMyAoQnVpbGQgNDAyOCkNCkNo YXJzZXQ6IHV0Zi04DQoNCndzQlZBd1VCU3MzZGZ1NU1sVTlYeWFpU0FRaUMxZ2YrTjc2NG9yclNF R2ZmcXE1WUUyR0UzeDJvY2JNcGhIbE4NCnVIZkViaUtUT1pKajFRK0FCbXJzS21DQjVpeGczQlVZ OWoxNjlBanNRb2ZWQmcxSEJwZ2Y4cXhSU3BkWE5RK2QNCitOekw5NWM2L2RBY2VXOTB2dFJ3OE1Z OFh0cnNkMVlWM3ZJbS9ybUFIL0tQalIzSkVwUlZhdHpoenRDZ3poN20NCnU3a3E4VEFacFY0SzJw NFAwQk9VWFEwRVRXb0UxbkVONU4vOGxNWXg0b1hWUjVuc25HWDJmYk44Zks0dHV4cnINCnJ2MUsv U01GT1k5bkpNb2paV2drWSsxV2s4bVIxVzJDbzl6QUtSWjZiV1RSMjY0dTE1a3gvZXd6SlVmNTgv cUUNCnpxelZPTGR2VjhSYlAxd0RLQkJNeHdGY0c2cm1JRERKaWNvQjNzT3Vtdy9DMkdCMjgrQ01n QT09DQo9SjBxVQ0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQoNCg0K --_000_983F17705339E24699AA251B458249B50CC48CB737EXCHANGE2K7of_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+DQo8ZGl2Pi0tLS0t QkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS08L2Rpdj4NCjxkaXY+SGFzaDogU0hBMjU2PC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5IZWgsIGRvbid0IHdvcnJ5IGFib3V0IGZpbmRp bmcgb3V0IHJlZ3VsYXRpb25zIGFib3V0IGFkdWx0IG1hdGVyaWFsIGlzIHRoZSBzYW1lIGFsbCBv dmVyIHRoZSB3b3JsZC4gSSd2ZSBiZWVuIGF0IHRoYXQgY2FuIG9mIHdvcm1zIG15c2VsZiwgYW5k IHRoZXJlIGFyZSBwbGFjZXMgd2hlcmUgaXQncyByZWd1bGF0ZWQgb3Igbm90LCBkaWZmZXJlbnQg YWdlcywgZnJvbSAxMyAodGhlIGxvd2VzdCBhZ2UgSSBrbm93IG9mKSB0byBmb3JiaWRkZW4NCmZv ciAmcXVvdDthZHVsdHMmcXVvdDsgYXMgd2VsbCwgZGlmZmVyZW50IGRlZmluaXRpb25zIG9mIHdo YXQncyBpbmNsdWRlZCBhbmQgbm90LCBkaWZmZXJlbnQgdHlwZSBkaXN0aW5jdGlvbnMgYW5kIGRl Z3JlZXMgcGVybWlzc2libGUuIFNvbWUgcGxhY2VzIHN1cHBvcnQgbGF3IHN1aXRzIGFnYWluc3Qg cHVibGlzaGVycyBpbiBvdGhlciBwbGFjZXMgZXZlbiBpZiBpdCdzIHBlcmZlY3RseSBsZWdhbCBh dCB0aGUgcHVibGlzaGVyJ3MgaG9tZSBsb2NhdGlvbiwgYW5kDQpzbyBvbi48L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2PkJ1dCB5b3UgYXJlIHF1aXRlIHJpZ2h0IGluIHRoYXQgd2Ugc2hv dWxkbid0IHN0YXJlIG91cnNlbHZlcyBibGluZCBhdCBzcGVjaWFsIGNhc2VzIGxpa2UgYWR1bHQg Y29udGVudCwgYnV0IGZpbmQgZ2VuZXJhbCBtZWNoYW5pc21zIHRvIGhhbmRsZSBwb2xpY3kgbmVn b3RpYXRpb24gaW4gdGhlIFZXUkFQIHByb3RvY29sLiBUaGUgYWN0dWFsIHBvbGljeSBkZWNpc2lv bnMgc2hvdWxkLCBhcyBzdGF0ZWQgbWFueSB0aW1lcyBiZWZvcmUsIGJlDQpvdXRzaWRlIHRoZSBw cm90b2NvbC4gSSB0aGluayBzb21lIGltcG9ydGFudCBxdWVzdGlvbnMgaW4gdGhhdCByZXNwZWN0 IG1heSBiZSBpZiBzdWNoIG1lY2hhbmlzbXM8L2Rpdj4NCjxkaXY+MS4gbmVlZCB0byBiZSBkaWZm ZXJlbnQgZnJvbSBleGNoYW5naW5nIG90aGVyIGluZm9ybWF0aW9uPzwvZGl2Pg0KPGRpdj4yLiBy ZXF1aXJlIGFueSBzcGVjaWFsIHN1cHBvcnQgZm9yIGV4Y2hhbmdpbmcgY3JlZGVudGlhbHMgbGlr ZSBlLmcuIGVsZWN0cm9uaWMgc2lnbmF0dXJlcz88L2Rpdj4NCjxkaXY+My4gbmVlZCB0byBzZXJ2 ZSBhbHNvIHNlcnZpY2VzIG90aGVyIHRoYW4gQUQgYW5kIFJEPzwvZGl2Pg0KPGRpdj40LiByZXF1 aXJlIGFueSBzcGVjaWFsIGluZnJhc3RydWN0dXJlIGxpa2Ugc2VwYXJhdGUgRFREcywgbWFjaGlu ZSByZWFkYWJsZSBwb2xpY3kgZG9jdW1lbnRzIG9yIHRoZSBsaWtlPzwvZGl2Pg0KPGRpdj41LiBz aG91bGQgZmFjaWxpdGF0ZSBhdXRvbWF0aWMgc2V0dXAgb2YgdHJ1c3QgZG9tYWlucz88L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkJlc3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2Pk1hZ251czwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2Pi0gLS0tLS1VcnNwcnVuZ2xpZ3QgbWVkZGVsYW5kZS0tLS0tPC9kaXY+DQo8 ZGl2PkZyw6VuOiBDYXJsbyBXb29kIFs8YSBocmVmPSJtYWlsdG86Y2FybG9AYWxpbm9lLmNvbSI+ bWFpbHRvOmNhcmxvQGFsaW5vZS5jb208L2E+XSA8L2Rpdj4NCjxkaXY+U2tpY2thdDogZGVuIDgg b2t0b2JlciAyMDA5IDEzOjQ1PC9kaXY+DQo8ZGl2PlRpbGw6IE1lYWRoYmggSGFtcmljazwvZGl2 Pg0KPGRpdj5Lb3BpYTogTWFnbnVzIFplaXNpZzsgSW5maW5pdHkgTGluZGVuOyBvZ3B4LWJvdW5j ZXNAaWV0Zi5vcmc7IG9ncHhAaWV0Zi5vcmc8L2Rpdj4NCjxkaXY+w4RtbmU6IFJlOiBbb2dweF0g UHJvdG9jb2wgZm9yIHBlcm1pdHRpbmcgcG9saWN5IGRlY2lzaW9uczwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+T24gV2VkLCBPY3QgMDcsIDIwMDkgYXQgMDI6MDc6NThQTSAtMDcwMCwg TWVhZGhiaCBIYW1yaWNrIHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7IGFueXdheS4ganVzdCBhIHRo b3VnaC4gaSdtIGdvaW5nIHRvIHNwZW5kIGEgbGl0dGxlIHRpbWUgdHJ5aW5nIHRvPC9kaXY+DQo8 ZGl2PiZndDsgdW5kZXJzdGFuZCBhIGNvdXBsZSBkaWZmZXJlbnQgY291bnRyeSdzIHJlZ3VsYXRp b25zIGZvciBvbmxpbmUgYWNjZXNzPC9kaXY+DQo8ZGl2PiZndDsgdG8gYWR1bHQgbWF0ZXJpYWxz IGJ5IG1pbm9ycywganVzdCB0byBnZXQgYSBzZW5zZSBmb3Igd2hlcmUgdGhlPC9kaXY+DQo8ZGl2 PiZndDsgZGlmZmVyZW5jZXMgd291bGQgbGllLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+QWx0aG91Z2ggYWRtaXJhYmxlLCB0aGlzIGlzIGp1c3QgYW4gRVhBTVBMRS4gV2Ugc2hvdWxk IGxvb2sgYXQgaXQsPC9kaXY+DQo8ZGl2PmFuZCBTT0xWRSBpdCwgaW4gYW4gYWJzdHJhY3Qgd2F5 OyBzbyB0aGF0IHdlIHdpbGwgdGFja2xlIGV2ZXJ5PC9kaXY+DQo8ZGl2PnBvc3NpYmxlIHBvbGlj eSBwcm9ibGVtIGxpa2UgaXQgd2l0aG91dCB0aGF0IHdlIGhhdmUgdG8gdGhpbmsgb2Y8L2Rpdj4N CjxkaXY+YW4gZXhoYXVzdGVkIGxpc3Qgbm93LjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+SWUsIGlmIHlvdXIgaW52ZXN0aWdhdGlvbiB3b3VsZCBzaG93IHRoYXQgZXZlcnkgY291bnRy eSBpbiB0aGU8L2Rpdj4NCjxkaXY+d29ybGQgaGFuZGxlcyBvbmxpbmUgYWNjZXNzIHRvIGFkdWx0 IG1hdGVyaWFscyBieSBtaW5vcnMgaW4gdGhlPC9kaXY+DQo8ZGl2PmV4YWN0IHNhbWUgd2F5LCB0 aGFuIHRoYXQgZG9lc24ndCBtYWtlIHRoZSBhYnN0cmFjdCBwcm9ibGVtIGdvPC9kaXY+DQo8ZGl2 PmF3YXksIHdlJ2QganVzdCBoYXZlIHRvIHRoaW5rIG9mIGFub3RoZXIgZXhhbXBsZSB0byB0YWNr bGUgdGhlPC9kaXY+DQo8ZGl2PmV4YWN0IHNhbWUgcHJvYmxlbS48L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2Pi0gLS0gPC9kaXY+DQo8ZGl2PkNhcmxvIFdvb2QgJmx0O2NhcmxvQGFsaW5v ZS5jb20mZ3Q7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4tLS0tLUJFR0lOIFBHUCBT SUdOQVRVUkUtLS0tLTwvZGl2Pg0KPGRpdj5WZXJzaW9uOiA5LjguMyAoQnVpbGQgNDAyOCk8L2Rp dj4NCjxkaXY+Q2hhcnNldDogdXRmLTg8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pndz QlZBd1VCU3MzZGZ1NU1sVTlYeWFpU0FRaUMxZ2YmIzQzO043NjRvcnJTRUdmZnFxNVlFMkdFM3gy b2NiTXBoSGxOPC9kaXY+DQo8ZGl2PnVIZkViaUtUT1pKajFRJiM0MztBQm1yc0ttQ0I1aXhnM0JV WTlqMTY5QWpzUW9mVkJnMUhCcGdmOHF4UlNwZFhOUSYjNDM7ZDwvZGl2Pg0KPGRpdj4mIzQzO056 TDk1YzYvZEFjZVc5MHZ0Unc4TVk4WHRyc2QxWVYzdkltL3JtQUgvS1BqUjNKRXBSVmF0emh6dENn emg3bTwvZGl2Pg0KPGRpdj51N2txOFRBWnBWNEsycDRQMEJPVVhRMEVUV29FMW5FTjVOLzhsTVl4 NG9YVlI1bnNuR1gyZmJOOGZLNHR1eHJyPC9kaXY+DQo8ZGl2PnJ2MUsvU01GT1k5bkpNb2paV2dr WSYjNDM7MVdrOG1SMVcyQ285ekFLUlo2YldUUjI2NHUxNWt4L2V3ekpVZjU4L3FFPC9kaXY+DQo8 ZGl2PnpxelZPTGR2VjhSYlAxd0RLQkJNeHdGY0c2cm1JRERKaWNvQjNzT3Vtdy9DMkdCMjgmIzQz O0NNZ0E9PTwvZGl2Pg0KPGRpdj49SjBxVTwvZGl2Pg0KPGRpdj4tLS0tLUVORCBQR1AgU0lHTkFU VVJFLS0tLS08L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9m b250Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_983F17705339E24699AA251B458249B50CC48CB737EXCHANGE2K7of_-- From dwl@us.ibm.com Thu Oct 8 06:55:37 2009 Return-Path: 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 D16FD3A68C9; Thu, 8 Oct 2009 06:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.855 X-Spam-Level: X-Spam-Status: No, score=-3.855 tagged_above=-999 required=5 tests=[AWL=-1.257, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 4GatZ1u-BdJK; Thu, 8 Oct 2009 06:55:36 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 35AA13A6878; Thu, 8 Oct 2009 06:55:36 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n98DsSDg017887; Thu, 8 Oct 2009 09:54:28 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n98DvBSV219778; Thu, 8 Oct 2009 09:57:11 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n98DvALw018938; Thu, 8 Oct 2009 09:57:11 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n98DvAuL018913; Thu, 8 Oct 2009 09:57:10 -0400 In-Reply-To: <20091008114435.GA22204@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> <20091008114435.GA22204@alinoe.com> To: Carlo Wood MIME-Version: 1.0 X-KeepSent: 17263597:F074C846-85257649:004AC591; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Thu, 8 Oct 2009 09:57:04 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/08/2009 09:57:09, Serialize complete at 10/08/2009 09:57:09 Content-Type: multipart/alternative; boundary="=_alternative 004CA2BC85257649_=" Cc: Infinity Linden , Meadhbh Hamrick , "ogpx@ietf.org" , "ogpx-bounces@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 13:55:37 -0000 This is a multipart message in MIME format. --=_alternative 004CA2BC85257649_= Content-Type: text/plain; charset="US-ASCII" One thing to keep in mind in this whole discussion is the following: "All policy decisions are local" This doesn't mean they don't represent a way of solving a globally distributed use case, but it highlights the fact the one software element, hosted behind and endpoint can't impose behavior on another such endpoint. In the case of how a service in an Agent Domain interacts with the services in a region domain, the Agent Domain is limited to controlling what *it* does. So, in the case of an agent domain which has the policy of not permitting its users to be exposed to "mature" content. The agent domain, however, doesn't perform the delivery of content from the region. It handles authentication, and global presence management, and possibly inventory management, but, it doesn't control what happens in the region. (In fact, in the current model, it doesn't even see the traffic, but seeing it wouldn't help) The decision as to what happens inside the region is local to the region. Just as the agent Dorian in this example doesn't see what the region is doing, the region doesn't see what the agent domain is doing, nor can it influence it. >From the point of view of the use case "Keep my agents away from "mature" content" the Agent Domain's leverage is limited to looking at the information the region exports, and deciding whether or not this is a region where it is safe for its agents to travel. The region, of course, can say whatever it wants. So.. if the Agent Domain wants certainty, it needs for the region to not only export information it can use to make this decision, but to export it in a way that gives the agent domain increased certainty. Traditionally, this takes the form of a digital signature tied to real world, out of band assurances. I would argue this is all for the good. At the Protocol and Endpoint description level, most of what needs to happen to support this model is to make sure we know where services expose meta-data and how it is formatted. The protocol need not focus on what the meta-data represents, but that it is there and available for supporting policy decisions. >From the perspective of managing interop, I think that the bulk of our focus needs to be having the use cases which enable us to make sure we *can* export and understand the meta-data needed to allow policy decisions to be made. There is a related topic, namely how we might do a distributed policy language permitting various services to reason about the policies governing a given service they wish to interact with. But.. That's not needed to make the protocol work. I view this as a good thing, since it is a decidedly non trivial problem to solve. I would suggest that one good way forward on this is to develop a set of policy use cases to drive our analysis of the protocol and specifications, and then look at whether we can reasonably manage these use cases. My personal belief is that the bulk of our policy management is going to consist of checking for meta-data signed using existing PKI standards (x.509 is the obvious one) and making decisions based on this meta-data. - David W. Levine ~ Zha Ewry Carlo Wood Sent by: ogpx-bounces@ietf.org 10/08/2009 07:44 AM To Meadhbh Hamrick cc Infinity Linden , "ogpx-bounces@ietf.org" , "ogpx@ietf.org" , Magnus Zeisig Subject Re: [ogpx] Protocol for permitting policy decisions On Wed, Oct 07, 2009 at 02:07:58PM -0700, Meadhbh Hamrick wrote: > anyway. just a though. i'm going to spend a little time trying to > understand a couple different country's regulations for online access > to adult materials by minors, just to get a sense for where the > differences would lie. Although admirable, this is just an EXAMPLE. We should look at it, and SOLVE it, in an abstract way; so that we will tackle every possible policy problem like it without that we have to think of an exhausted list now. Ie, if your investigation would show that every country in the world handles online access to adult materials by minors in the exact same way, than that doesn't make the abstract problem go away, we'd just have to think of another example to tackle the exact same problem. -- Carlo Wood _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 004CA2BC85257649_= Content-Type: text/html; charset="US-ASCII"
One thing to keep in mind in this whole discussion is the following: "All policy decisions are local" This doesn't mean they don't represent a way of solving a globally distributed use case, but
it highlights the fact the one software element, hosted behind and endpoint can't impose behavior on another such endpoint. In the case of how a service in an Agent Domain interacts with the services in a region domain, the Agent Domain is limited to controlling what *it* does. So, in the case of an agent domain which has the policy of not permitting its users to be exposed to "mature" content. The agent domain, however, doesn't perform the delivery of content from the region. It handles authentication, and global presence management, and possibly inventory management, but, it doesn't control what happens in the region. (In fact, in the current model, it doesn't even see the traffic, but seeing it wouldn't help)

The decision as to what happens inside the region is local to the region. Just as the agent Dorian in this example doesn't see what the region is doing, the region doesn't see what the
agent domain is doing, nor can it influence it.

From the point of view of the use case "Keep my agents away from "mature" content" the Agent Domain's leverage is limited to looking at the information the region exports, and deciding whether or not this is a region where it is safe for its agents to travel. The region, of course, can say whatever it wants. So.. if the Agent Domain wants certainty, it needs for the
region to not only export information it can use to make this decision, but to export it in a way that gives the agent domain increased certainty.  Traditionally, this takes the form of a
digital signature tied to real world, out of band assurances.

I would argue this is all for the good. At the Protocol and Endpoint description level, most of what needs to happen to support this model is to make sure we know where services expose meta-data and how it is formatted. The protocol need not focus on what the meta-data represents, but that it is there and available for supporting policy decisions.

From the perspective of managing interop, I think that the bulk of our focus needs to be having the use cases which enable us to make sure we *can* export and understand
the meta-data needed to allow policy decisions to be made.

There is a related topic, namely how we might do a distributed policy language permitting various services to reason about the policies governing a given service they wish to interact with. But.. That's not needed to make the protocol work. I view this as a good thing, since it is a decidedly non trivial problem to solve.

I would suggest that one good way forward on this is to develop a set of policy use cases to drive our analysis of the protocol and specifications, and then look at whether we can reasonably manage these use cases.  My personal belief is that the bulk of our policy management is going to consist of checking for meta-data signed using existing PKI standards (x.509  is the obvious one) and making decisions based on this meta-data.

- David W. Levine
~ Zha Ewry




Carlo Wood <carlo@alinoe.com>
Sent by: ogpx-bounces@ietf.org

10/08/2009 07:44 AM

To
Meadhbh Hamrick <meadhbh.siobhan@gmail.com>
cc
Infinity Linden <infinity@lindenlab.com>, "ogpx-bounces@ietf.org" <ogpx-bounces@ietf.org>, "ogpx@ietf.org" <ogpx@ietf.org>, Magnus Zeisig <magnus.zeisig@iis.se>
Subject
Re: [ogpx] Protocol for permitting policy decisions





On Wed, Oct 07, 2009 at 02:07:58PM -0700, Meadhbh Hamrick wrote:
> anyway. just a though. i'm going to spend a little time trying to
> understand a couple different country's regulations for online access
> to adult materials by minors, just to get a sense for where the
> differences would lie.

Although admirable, this is just an EXAMPLE. We should look at it,
and SOLVE it, in an abstract way; so that we will tackle every
possible policy problem like it without that we have to think of
an exhausted list now.

Ie, if your investigation would show that every country in the
world handles online access to adult materials by minors in the
exact same way, than that doesn't make the abstract problem go
away, we'd just have to think of another example to tackle the
exact same problem.

--
Carlo Wood <carlo@alinoe.com>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 004CA2BC85257649_=-- From magnus.zeisig@iis.se Thu Oct 8 07:39:45 2009 Return-Path: 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 587C53A68E9 for ; Thu, 8 Oct 2009 07:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.637 X-Spam-Level: X-Spam-Status: No, score=-5.637 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_22=0.6, 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 vWHlpF78vRg7 for ; Thu, 8 Oct 2009 07:39:42 -0700 (PDT) Received: from cleaner.prod.iis.se (cleaner.prod.iis.se [212.247.7.212]) by core3.amsl.com (Postfix) with ESMTP id C5BEA3A691B for ; Thu, 8 Oct 2009 07:39:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cleaner.prod.iis.se (Postfix) with ESMTP id 958E8A8008; Thu, 8 Oct 2009 14:41:22 +0000 (UTC) Received: from cleaner.prod.iis.se ([127.0.0.1]) by localhost (cleaner.prod.iis.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15294-04; Thu, 8 Oct 2009 14:41:09 +0000 (UTC) Received: from pgpkeys.office.nic.se (pgpkeys.office.nic.se [212.247.204.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cleaner.prod.iis.se (Postfix) with ESMTP id BAE43A8007; Thu, 8 Oct 2009 14:41:09 +0000 (UTC) Received: from EXCH2K7HUB-BRG.office.nic.se ([212.247.3.5]) by pgpkeys.office.nic.se (PGP Universal service); Thu, 08 Oct 2009 16:41:09 +0200 X-PGP-Universal: processed; by pgpkeys.office.nic.se on Thu, 08 Oct 2009 16:41:09 +0200 Received: from Exchange2k7.office.nic.se ([169.254.1.222]) by EXCH2K7HUB-BRG.office.nic.se ([212.247.3.5]) with mapi; Thu, 8 Oct 2009 16:41:08 +0200 From: Magnus Zeisig To: Morgaine Date: Thu, 8 Oct 2009 16:41:07 +0200 Thread-Topic: [ogpx] Protocol for permitting policy decisions Thread-Index: AcpIE3hiyk/lglT+RAi7KHPnDsAgwgADq2tg Message-ID: <983F17705339E24699AA251B458249B50CC48CB7BF@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B50CC48CB6E2@EXCHANGE2K7.office.nic.se> In-Reply-To: Accept-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE MIME-Version: 1.0 Content-Language: sv-SE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Debian amavisd-new at cleaner.prod.iis.se Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 14:39:45 -0000 Morgain, I believe we're not that far off from each other, even if I think = the example you presented was not appropriate and I still can see no reason= for your symmetry in AD/RD requests. The latter notion has already been co= mmented upon by others in more detail. But like you, I also think it's reas= onable to leave or generalize away from the thought of domains and rather u= se services as protocol endpoints. Regardless of if we talk about domains o= r services, I think the basic negotiation pattern will always be the same: Client: I want your services but (may) have some (policy) demands to use th= em. Server/Service: I offer you my services but (may) have some (policy) demand= s to let you use them. Both client and server/service can be the agent or region domain, user/agen= t, authentication, presence, asset, inventory, simulation, voice or movie s= ervice, or any other domain or service you can think of, standalone or clus= tered in any combinations depending on technical issues, ownership and agre= ements. So, when any client (C) requests any service from a server/service (S), it = may look like this, if all work out: C ---(id, service?, S policy?)--> S C <--(id, S policy, C policy?)--- S C --(id, S policy OK, C policy)-> S C <-(id, C policy OK, service)--- S Policies in this case may refer both to things like data format (mesh forma= t, image format) and data classification (adult, require IP agreements). Th= e acceptance of policies, permitting the service performed, from both C and= S, may be negotiated directly between C and S, or between servers/services= connected to C and S respectively, negotiated at the time of service reque= st and/or stored in some form of access, token or cap, at C and/or S respec= tively, or servers/services connected to them. If C and S are controlled by the same entity, that entity may use any way, = including VWRAP, to negotiate and deliver the service, and the policy part = may be left out from the negotiation, e.g. because the entity use the same = policy for all services controlled. If C and S are controlled by different entities, those entities may use any= way, including VWRAP, to negotiate and deliver the service, and the policy= part may be left out from the negotiation, e.g. because the entities have = an already established agreement (format agreement, domain of trust) or don= 't require one. If the policy negotiation is left out, the request becomes: C --(id, service?)-> S C <-(id, service)--- S To support a flexible new infrastructure with many different domains or ser= vices interacting in many different constellations, including interop betwe= en the "classical" virtual worlds of today, VWRAP should be able to treat a= ny service request and/or policy negotiation the same or very similar, rega= rdless of endpoints and endpoint types. The endpoints will mutually decide = if to use VWRAP and to which extent. VWRAP should however be an attractive = enough way to handle the communication to be a first hand choice, both betw= een clients and servers/services of the same as well as different entities.= One advantage of using VWRAP will then be that outsourcing, exchange or ad= dition of services will be easy, since basically just addresses of servers/= services will need to be changed and transfer of old data to the new servic= es be performed. I know that some of the things above have already been stated on the list, = but I'm repeating them just for the clarity of argumentation. Best regards, Magnus -----Ursprungligt meddelande----- Fr=E5n: Morgaine [mailto:morgaine.dinova@googlemail.com] Skickat: den 8 oktober 2009 14:32 Till: Magnus Zeisig Kopia: ogpx@ietf.org =C4mne: Re: [ogpx] Protocol for permitting policy decisions Magnus, you're mixing up my analysis of what's required for Joshua's scheme= to work, with my recognition that we need a more flexible approach based n= ot on this restrictive AD+RD split but on the much more flexible decoupled = services behind them. When I speak of AD1+RD1 and AD2+RD2 in the analysis, this is not at all th= e actual deployment scenario that any of us expects to see. It's just the = smallest case that allows us to say something concrete about the problems w= ith the original OGP design when extrapolated to the multi-world deployment= scenario. So please don't attribute any narrow vision in this scenario to= me --- I'm fully aware that it's artificial and is going almost nowhere. = I'm merely doing a smallest-possible scenario analysis. My personal interest is in the fully expanded and massively scaled deployme= nts which the AWG group in SL was originally formed to consider 2 years ago= (this might give you some idea of the scale --- https://wiki.secondlife.c= om/wiki/Project_Motivation ) , but there's no point describing a massively = complex deployment example when a simpler one suffices to make a specific p= oint. :-) So to your post ... On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeisig wrote= : Morgaine, No, you are still stuck in the concept of one virtual world equals = one AD plus one RD, even if you say you recognize a future more complex ser= vice pattern. VW=3DAD+RD does not have to be the case with VWRAP. I know that it's artificial. We're merely examining this small scenario to= highlight an elementary problem with distribution of services, and it has = already been useful. It has demonstrated that even in this miniscule examp= le, there need to be (i) asset service contributions from both worlds in th= e example, so just a single inventory service in AD1 is not adequate, and (= ii) that if ADs control region policy then AD2 must be consulted as well si= nce it has every bit as much right to determine policy in RD2 as does AD1, = or more. These are important constraints on the design, despite the deploy= ment example being such a simple one. In addition to the case shown, there are simpler cases and there are more c= omplex cases. The simpler cases, such as no AD2 exists, or only W1 asset services are use= d in W2, can be handled by the original OGP design, so they wouldn't have s= erved the purpose here. More complex cases, such as multiple RDs in W2, do= not add value to the particular point being made, so why complicate the sc= enario unnecessarily? We'll certainly need them later, but they don't help= here. Obviously multi-world deployment scenarios such as we expect to be common i= n the metaverse are going to have much more complex deployment patterns inv= olved a myriad of concurrent services, but adding that complexity at this p= oint doesn't enhance the present argument. If it _happens_ to be the case and the entity controlling AD2 and R= D2 wants to enforce AD2 policy for those visiting RD2, then they can move, = duplicate or mirror the enforcement of that policy from AD2 to RD2, which t= hey can do without problems as long as they control both. If they don't con= trol both, then it's entirely up to the entity controlling RD2 if they for = some reason want to enforce the policy of the entity controlling AD2. So I = see no reason whatsoever why symmetry is required. Ah, here you've simply misunderstood me: you think I'm talking about deplo= yment symmetry, but I'm not. I'm talking about definition symmetry: if AD= s are defined to be able to control region policies, then by symmetry that = applies to all ADs. It wouldn't make sense to say "ADs are defined to carr= y region policy, but this only applies to our ADs and not to yours." ;-) = That's what I mean by this applying symmetrically. Deployment patterns are of course arbitrary and don't have to be symmetrica= l: two interoperating worlds can individually be using any deployment patt= ern they choose, and one world of the pair will generally have no say on th= e deployment pattern used by the other. Across the whole metaverse, we can= expect every single possible deployment pattern to be used by someone, and= for added spice, tourists from every possible deployment could be visiting= some common tourist world to create a kaleidescope of combined deployments= in the region. Policy is not decided and enforced by the AD, the RD or any service= connected with them, it is decided and enforced by the entities behind the= m. If the same entity controls an AD and a RD, then it's meaningless to try= to divide up that entity's policy into AD policy and RD policy, because it= can enforce that policy at any level, type of domain or connected service = it controls. Sure, but someone has to code this stuff. It's not helpful to say "Anythin= g can be done anywhere", because that would mean that the protocol would at= every decision point have to gather policy contributions from all possible= endpoints. It can be done this way of course, but if a simpler design suf= fices then a more compex one may not be a good idea. That said, take note of David's advice about policy being best implemented = in the services themselves. Domains are not necessarily bad, but they do a= ctually restrict our flexibility substantially compared to using decoupled = services alone. But, like you, I am totally in favor of letting the entity controll= ing the destination RD decide policy once the agent is there. However, if t= he agent's own AD for some reason wants to stop the agent from going there,= then I think it should have the possibility to do so. In all honesty, I do= n't think an AD imposing undue restrictions on where people are allowed to = go or what they are allowed to do there will survive for long though, once = competition is in place. You may have to start out fresh, with a new AD, wi= thout the assets and inventory connected to the old AD, but I think most pe= ople are willing to take that step if they feel their freedom is too limite= d. Well in my case I'm not merely "in favour" of region policy control by regi= ons. I don't think it's actually optional in multi-world deployments, beca= use without Destination Determines Destination Policy there can be no viabl= e multi-world tourism at all, and that's the primary use case with massive = popular interest. We wouldn't have much of a metaverse without it. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeisig wrote= : Morgaine, No, you are still stuck in the concept of one virtual world equals = one AD plus one RD, even if you say you recognize a future more complex ser= vice pattern. VW=3DAD+RD does not have to be the case with VWRAP. If it _ha= ppens_ to be the case and the entity controlling AD2 and RD2 wants to enfor= ce AD2 policy for those visiting RD2, then they can move, duplicate or mirr= or the enforcement of that policy from AD2 to RD2, which they can do withou= t problems as long as they control both. If they don't control both, then i= t's entirely up to the entity controlling RD2 if they for some reason want = to enforce the policy of the entity controlling AD2. So I see no reason wha= tsoever why symmetry is required. Policy is not decided and enforced by the AD, the RD or any service= connected with them, it is decided and enforced by the entities behind the= m. If the same entity controls an AD and a RD, then it's meaningless to try= to divide up that entity's policy into AD policy and RD policy, because it= can enforce that policy at any level, type of domain or connected service = it controls. But, like you, I am totally in favor of letting the entity controll= ing the destination RD decide policy once the agent is there. However, if t= he agent's own AD for some reason wants to stop the agent from going there,= then I think it should have the possibility to do so. In all honesty, I do= n't think an AD imposing undue restrictions on where people are allowed to = go or what they are allowed to do there will survive for long though, once = competition is in place. You may have to start out fresh, with a new AD, wi= thout the assets and inventory connected to the old AD, but I think most pe= ople are willing to take that step if they feel their freedom is too limite= d. Best regards, Magnus -----Ursprungligt meddelande----- Fr=E5n: Morgaine [mailto:morgaine.dinova@googlemail.com] Skickat: den 8 oktober 2009 11:42 Till: Magnus Zeisig Kopia: ogpx@ietf.org =C4mne: Re: [ogpx] Protocol for permitting policy decisions Magnus, If ADs are involved in region policy, then in the multi-world deplo= yment pattern, AD2 will have to be consulted when agent A1 teleports from R= D1 to RD2, because AD2 will be involved in region policy too. It's symmetr= ic with AD1. This is what Joshua wanted to avoid, and it can only be avoided by = not giving ADs policy control over regions, otherwise symmetry requires tha= t AD2 be consulted as well. It's this kind of problem that reinforces what David's been saying = about the right mess we currently have when talking about domains determini= ng policy. The AD/RD split was reasonably adequate when OGP was only exten= ding a single world with policy-free regions, but it is insufficient to do = a good job once we get into multi-world deployments with more complex servi= ce and policy patterns which require much more flexibility. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I am strongly in favour of leaving policy descisions to the = RD, but since there seems to be a need for at least some AD managers to be = able to make policy decisions as well, I guess the protocol handshake need = even more flexibility than the versions scetched on by Meadhbh, Carlo and m= e so far. I will adapt the diagram style of Meadhbh and Carlo (http://www.i= etf.org/mail-archive/web/ogpx/current/msg00520.html), since it's more reada= ble than my text-flow variant. Also, I will leave out parameter examples si= nce there seem to be a risk people get hooked on if a certain parameter sho= uld be included or not, rather than the possibility of handling any paramet= er. I may be paranoid, but I still prefer agent domains to be al= lowed, but not forced by protocol, to reduce the dissemination of informati= on about their clients as far as possible, and there Carlo's AND version in= the response is a good step forward (http://www.ietf.org/mail-archive/web/= ogpx/current/msg00520.html). We might even wind up with negotiations where = one domain requests the actual values while the other domain only wants to = disseminate a reply to if it fits a range for one or more of the requested = parameters. AD -------------------------(name, )------= ------------------> RD AD <--(name, )--- RD AD --(name, )-> RD AD <----------(name, )----------- RD AD ----------------------------(name, agentkey2 OK)---------= ------------------> RD AD <-----------------------------(name, rez cap)------------= ------------------- RD In this example, RD might have refused giving the required r= ange for agentvalue2, either because it technically doesn't support that ki= nd of negotiation or because of policy, in either case of which the rez cap= would have failed. It might on the other hand instead already from the beg= inning have supplied the required ranges instead of asking for the actual v= alue. I think it would be good if the protocol would enable either of these= cases for maximum flexibility. It may also be an idea to permit caching of at least AD- and= RD-parameters or evaluations of them, especially if we're talking extensiv= e sets with perhaps hundreds of parameters. Since the ADs and RDs should be= free to update their own parameters at any time, the handshake in that cas= e must of course contain a check if cached parameters have been updated. Al= so, if an AD or RD supports several sets of parameters depending on which d= omain or service it deals with, means to distinguish between them are requi= red, perhaps using policy URI's the way Meadhbh suggested (http://www.ietf.= org/mail-archive/web/ogpx/current/msg00523.html). A policy could then basic= ally be broken down into a set of own parameter values and required paramet= er ranges for the domain or service connecting. I also think, like Meadhbh (http://www.ietf.org/mail-archive= /web/ogpx/current/msg00523.html), that we will need to suggest, but not req= uire, a number of parameter name and formats to facilitate communication, s= o that not e.g. US and UK domains can't connect, because one asks about "co= lor" and the other one only can respond about "colour". Best regards, Magnus - -----Ursprungligt meddelande----- Fr=E5n: Carlo Wood [mailto:carlo@alinoe.com] Skickat: den 7 oktober 2009 22:36 Till: Infinity Linden Kopia: Magnus Zeisig; ogpx@ietf.org =C4mne: Re: [ogpx] Protocol for permitting policy decisions On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden wr= ote: > option 3: multi-message handshake > > AD --------------- (name) -------------> RD > AD <-------- (X, age > X? cap) --------- RD > > AD ------------------------------------> RD (age > X? cap) > AD <------------ (rez cap) ------------- RD Note, again, the need for a flexible protocol negotiation: we can't know, already, what all will be needed. Nevertheless, the more flexibility the better imho. I'd prefer to see this: AD ------(name, ) -----------> RD AD <-----(name, ) --- RD AD ------(name, yes/no)--------------------------> RD AD <-----(rez cap) ------------------------------- RD Where VWRAP will not define what keywords are possible. However, implementers might, for example, choose to use 'AGE= ' as keyword with an integer range, leading to a msg exchange like AD ------(name, (AGE)) -----------> RD AD <-----(name, (AGE, 21)) -------- RD AD ------(name, yes)--------------> RD AD <-----(rez cap) ---------------- RD or some might implement AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD AD <-----(name, (AGE, 13), YES) ------------------ RD AD ------(name, yes, yes)------------------------> RD AD <-----(rez cap) ------------------------------- RD For privacy reasons, I think it would suffice to just send the AND of all 'yes's, thus: AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD AD <-----(name, (AGE, 13), YES) ------------------ RD AD ------(name, yes)-----------------------------> RD AD <-----(rez cap) ------------------------------- RD or, AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD AD <-----(name, (AGE, 13), DONTCARE) ------------- RD AD ------(name, yes)-----------------------------> RD AD <-----(rez cap) ------------------------------- RD Again, neither 'AGE' nor 'LIKES_BUNNIES', would be defined b= y us, but we would define how to handle integer ranges, booleans, don't cares, string literals, and perhaps regular expression= s. - -- Carlo Wood -----BEGIN PGP SIGNATURE----- Version: 9.8.3 (Build 4028) Charset: utf-8 wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al3= nKcL JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfgs= 7Ta/ cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9By= IbMJ RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOzW= zsWm tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bldq= /Bnd 60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w=3D=3D =3D2NSu -----END PGP SIGNATURE----- _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx From carlo@alinoe.com Thu Oct 8 08:44:17 2009 Return-Path: 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 E18963A6AC5 for ; Thu, 8 Oct 2009 08:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 bDlBSbNb+Is7 for ; Thu, 8 Oct 2009 08:44:15 -0700 (PDT) Received: from viefep12-int.chello.at (viefep12-int.chello.at [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id AB45C3A6AA4 for ; Thu, 8 Oct 2009 08:43:58 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep12-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091008154540.SOEP4394.viefep12-int.chello.at@edge03.upc.biz>; Thu, 8 Oct 2009 17:45:40 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upc.biz with edge id qFlc1c09r0FlQed03FleCW; Thu, 08 Oct 2009 17:45:39 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MvvCn-0000Y4-0f; Thu, 08 Oct 2009 17:47:01 +0200 Date: Thu, 8 Oct 2009 17:47:01 +0200 From: Carlo Wood To: "Dickson, Mike (ISS Software)" Message-ID: <20091008154701.GB22204@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <4646639E08F58B42836FAC24C94624DD771A1BA1FA@GVW0433EXB.americas.hpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A1BA1FA@GVW0433EXB.americas.hpqcorp.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Infinity Linden , Meadhbh Hamrick , "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 15:44:18 -0000 On Thu, Oct 08, 2009 at 01:17:01AM +0000, Dickson, Mike (ISS Software) wrote: > Meadbah wrote: > > i still like this scheme because a) it's really similar to the way > seed caps work, b) it adds flexibility to our system(s), and c) it > does what i was hoping... gives the AD the ability to make policy > decisions (like am i going to let this 15 year old user access > material that may land me in hot water with the local authorities.) > > > I may be mis-understanding all this since I’m still trying to come up to speed > but isn’t it the region that’s making the policy decision here to allow/ > disallow a connect given what AD is representing about the user? And yes, I > agree that for this to work there must be trust established between the > services involved. I’m just confused by the above statement since it implies > the AD is making a policy decision while it’s really the RD that has the > content (and hence the possible issue). And the RD and AD may be run by two > different entities…. > > Mike Mike is correct, at least -- that is the way I intended it :p The AD gathers information about a user and tells the RD (in general terms) what information it has. Then the RD tells the AD under what circumstances the user can be allowed in (by giving a list of ranges (or values / reg.exp) that the given data has to match. In the end, the AD does not make the decision therefore. If the authority that runs the AD has a moral problem with letting in users of 15 into a mature region, then they can arrange in ADVANCE with the administration of the region that it either 1) doesn't contain mature content or 2) asks for an age > 18 (or whatever satisfies the AD administration). The real-time protocol exchange and per-user decisions however, are then in principle in the hands of the Region. That is a Good Thing. -- Carlo Wood From josh@lindenlab.com Thu Oct 8 09:44:18 2009 Return-Path: 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 C727228C1B4 for ; Thu, 8 Oct 2009 09:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 V-I1UfL59A62 for ; Thu, 8 Oct 2009 09:44:17 -0700 (PDT) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id B714428C18C for ; Thu, 8 Oct 2009 09:44:16 -0700 (PDT) Received: by pxi42 with SMTP id 42so5871203pxi.5 for ; Thu, 08 Oct 2009 09:45:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.32.2 with SMTP id k2mr206764rvj.12.1255020356506; Thu, 08 Oct 2009 09:45:56 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> Date: Thu, 8 Oct 2009 09:45:56 -0700 Message-ID: From: Joshua Bell To: ogpx Content-Type: multipart/alternative; boundary=000e0cd146368914c504756f32c7 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 16:44:18 -0000 --000e0cd146368914c504756f32c7 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 7, 2009 at 8:34 PM, Morgaine wrote: > > That's a great description of the ultimate interop dystopia in which, > through definition of arbitrary set membership criteria by an arbitrary > number of policy makers, the result of transitive policy transference and > policy intersection is that the set of visitable worlds is the empty set. > > Are we trying to create an interop protocol here, or a protocol for > preventing interop? > :) Honestly, I was trying to riff on the thread (AD and RD sharing information about agents to make policy decisions), rather than propose anything. I think an attempt to define a global set of characteristics about users that enable all policy decisions is hopeless - cultures, laws, and individuals are too varied and rich. That leaves pair-wise negotiation and/or trust networks, which IMHO needs to happen *if* there are to be service-level distinctions for most cases anyway. What I forgot to say is: on the Web, as you move between sites you accept various terms of service. Attempts to have your browser automatically negotiate with sites over content have been extremely limited - things like the defunct PICS (you tell your browser to allow a third party site to rate the site you intend to visit), or Google's features which block malware/phishing sites (and I believe are used by current browsers as well when you just type a URL). Your user-agent (Web browser) does *not* have a built-in lawyer that agrees to a TOS on your behalf, however. (I'm having flashbacks of "Diamond Age" here - is that the right novel?) In the VWRAP space, I don't believe your VW agent domain will be capable of doing that in a totally generalized, automated way either... so either it will have some a priori knowledge of the RD via some manner (pair-wise negotiation, trust network, etc), defer to the user to accept the TOS, or simply block access. In other words: "Just like the web, except where it's different" once again. I'm leaning ever more strongly towards David's position that only services > should carry expressions of policy, not domains, because in the direction in > which this discussion is heading there will be no widespread interop at all. > I need to re-read Meadhbh's drafts to internalize the formal terminology (yeah, my bad), but in my head a "domain" is a deployment model for a set of conceptually related services, but it's the service end-points that exist at the protocol level. We talk about domains as clusters of conceptually related services as a crutch so we don't have to enumerate the specific services in each conversation. --000e0cd146368914c504756f32c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 7, 2009 at 8:34 PM, Morgaine <morgaine.d= inova@googlemail.com> wrote:

That's a great description of the ultimate = interop dystopia in which, through definition of arbitrary set membership c= riteria by an arbitrary number of policy makers, the result of transitive p= olicy transference and policy intersection is that the set of visitable wor= lds is the empty set.

Are we trying to create an interop protocol here, or a protocol for pre= venting interop?

:) Honestly, I was trying to riff= on the thread (AD and RD sharing information about agents to make policy d= ecisions), rather than propose anything. I think an attempt to define a glo= bal set of characteristics about users that enable all policy decisions is = hopeless - cultures, laws, and individuals are too varied and rich. That le= aves pair-wise negotiation and/or trust networks, which IMHO needs to happe= n *if* there are to be service-level distinctions for most cases anyway.
What I forgot to say is: on the Web, as you move between sites you acce= pt various terms of service. Attempts to have your browser automatically ne= gotiate with sites over content have been extremely limited - things like t= he defunct PICS (you tell your browser to allow a third party site to rate = the site you intend to visit), or Google's features which block malware= /phishing sites (and I believe are used by current browsers as well when yo= u just type a URL). Your user-agent (Web browser) does *not* have a built-i= n lawyer that agrees to a TOS on your behalf, however. (I'm having flas= hbacks of "Diamond Age" here - is that the right novel?)

In the VWRAP space, I don't believe your VW agent domain will be ca= pable of doing that in a totally generalized, automated way either... so ei= ther it will have some a priori knowledge of the RD via some manner (pair-w= ise negotiation, trust network, etc), defer to the user to accept the TOS, = or simply block access.

In other words: "Just like the web, except where it's differen= t" once again.

I'm leaning ever more strongly towards David's position that only s= ervices should carry expressions of policy, not domains, because in the dir= ection in which this discussion is heading there will be no widespread inte= rop at all.

I need to re-read Meadhbh's drafts to internaliz= e the formal terminology (yeah, my bad), but in my head a "domain"= ; is a deployment model for a set of conceptually related services, but it&= #39;s the service end-points that exist at the protocol level. We talk abou= t domains as clusters of conceptually related services as a crutch so we do= n't have to enumerate the specific services in each conversation.



--000e0cd146368914c504756f32c7-- From infinity@lindenlab.com Thu Oct 8 10:25:02 2009 Return-Path: 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 ED6C328C1C3 for ; Thu, 8 Oct 2009 10:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.807 X-Spam-Level: X-Spam-Status: No, score=-1.807 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 DJ-Yj8j1Tfls for ; Thu, 8 Oct 2009 10:25:01 -0700 (PDT) Received: from mail-px0-f204.google.com (mail-px0-f204.google.com [209.85.216.204]) by core3.amsl.com (Postfix) with ESMTP id 887143A6878 for ; Thu, 8 Oct 2009 10:25:01 -0700 (PDT) Received: by pxi42 with SMTP id 42so5910342pxi.5 for ; Thu, 08 Oct 2009 10:26:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.248.39 with SMTP id v39mr121974wfh.227.1255022800625; Thu, 08 Oct 2009 10:26:40 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> From: "Infinity Linden (Meadhbh Hamrick)" Date: Thu, 8 Oct 2009 10:26:20 -0700 Message-ID: <3a880e2c0910081026v73de39f8k7c340295b2166dda@mail.gmail.com> To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 17:25:03 -0000 i wouldn't say that AD's are involved with region policy. i would say that the AD's have a policy of not placing avatars in regions that do not advertise certain metadata and the AD believes they can be trusted. getting back to the adult region example... let's say i'm an operator of a shared virtual experience. i have a bunch of underage customers. many of them have parents who both have money to pay lawyers and don't want their kids getting access to "adult content." also, i advertise my service in the united states, UK and other countries who have regulations or laws limiting access to adult material by minors. my policy, as a service operator, will probably very quickly become "comply with local regulations and with foreign regulation as required by international treaty to avoid criminal and civil liability." so i have an agent domain, because i have a relationship with my customers. i probably have several regions i operate on my own, but i want to stitch my regions up with regions operated by happy funco land, inc. (HFLI). HFLI operates an adults only service and there's adult content on their grid. in the US, it doesn't matter that HFLI operates the region. i was complicit in the act of connecting minors to adult content online. i have the relationship with the customer. guess who's going to get sued first? what i may do in this case is tell HFLI that if they want my bazillion users to connect to their land, they're going to have to segregate adult content into specific regions and mark those regions with an adults only maturity tag. before i place an avatar in that region, i (as the agent domain operator) will look at the age of the user and then look at the maturity tag on the region they want to teleport into. if the region is tagged "adult" and my avatar is underage, i will not try to rez their avatar. i do it this way because i really, really, really don't want to open myself up to liability. i don't want to depend on a foreign organization to enforce MY policy. so, this is not an example where i (as the agent domain) is interfering or setting the policy of a third party. i am not the authority for that domain. what i _can_ do, however, is contract that third party to follow certain procedural safeguards, and before allowing my users to set virtual foot in their land, force them to assume liability if they do not exercise due care in the execution of their contractual obligations. so this is a use case where we do not dynamically modify policy. we negotiate a policy and behavior through legal channels before allowing access from the AD to the RD. as the AD, i am not telling the RD during the protocol negotiation phase what my policy requirements are. i am not negotiating a policy at connect time. what i _am_ doing is i _am_ looking at a trusted identifier for that RD (like a TLS server certificate,) i am validating it, then i am doing a lookup in my system to see if i trust them, then i am determining the policy with regards to adult content on that region. if the policy is conformable with mine, i begin the process of teleporting the user's avatar to that region. there are several ways to determine policy: a. identity implies policy. maybe i happen to be connected to Dalt Wisney and know that they are an exclusively "family oriented" operation. ergo, i know i don't have to worry about adult material being in those regions. b. authenticator implies policy. maybe if we're using X.509 certificates, we've made a deal to stuff policy identifiers in the X.509 certificates. sure, there are a lot of reasons NOT to do this, but then again, maybe it works for some people. c. region metadata implies policy. maybe when we access the region meta data, there's a tag for "adult material here." these are the options for the way we anticipate our service operating. but i'm not prejudiced against the tourist model, so sure, let's allow, but not REQUIRE AD's to go through this negotiation process if we're in the virtual tourist model. -cheers -meadhbh/infinity -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden On Thu, Oct 8, 2009 at 02:41, Morgaine wro= te: > Magnus, > > If ADs are involved in region policy, then in the multi-world deployment > pattern, AD2 will have to be consulted when agent A1 teleports from RD1 t= o > RD2, because AD2 will be involved in region policy too. It's symmetric w= ith > AD1. > > This is what Joshua wanted to avoid, and it can only be avoided by not > giving ADs policy control over regions, otherwise symmetry requires that = AD2 > be consulted as well. > > It's this kind of problem that reinforces what David's been saying about = the > right mess we currently have when talking about domains determining polic= y. > The AD/RD split was reasonably adequate when OGP was only extending a sin= gle > world with policy-free regions, but it is insufficient to do a good job o= nce > we get into multi-world deployments with more complex service and policy > patterns which require much more flexibility. > > > Morgaine. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig wrot= e: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> I am strongly in favour of leaving policy descisions to the RD, but sinc= e >> there seems to be a need for at least some AD managers to be able to mak= e >> policy decisions as well, I guess the protocol handshake need even more >> flexibility than the versions scetched on by Meadhbh, Carlo and me so fa= r. I >> will adapt the diagram style of Meadhbh and Carlo >> (http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html), since >> it's more readable than my text-flow variant. Also, I will leave out >> parameter examples since there seem to be a risk people get hooked on if= a >> certain parameter should be included or not, rather than the possibility= of >> handling any parameter. >> >> I may be paranoid, but I still prefer agent domains to be allowed, but n= ot >> forced by protocol, to reduce the dissemination of information about the= ir >> clients as far as possible, and there Carlo's AND version in the respons= e is >> a good step forward >> (http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html). We mi= ght >> even wind up with negotiations where one domain requests the actual valu= es >> while the other domain only wants to disseminate a reply to if it fits a >> range for one or more of the requested parameters. >> >> AD -------------------------(name, > RDkey2?>)------------------------> RD >> AD <--(name, > agentkey2?>)--- RD >> AD --(name, > range?>)-> RD >> AD <----------(name, > range>)----------- RD >> AD ----------------------------(name, agentkey2 >> OK)---------------------------> RD >> AD <-----------------------------(name, rez >> cap)------------------------------- RD >> >> In this example, RD might have refused giving the required range for >> agentvalue2, either because it technically doesn't support that kind of >> negotiation or because of policy, in either case of which the rez cap wo= uld >> have failed. It might on the other hand instead already from the beginni= ng >> have supplied the required ranges instead of asking for the actual value= . I >> think it would be good if the protocol would enable either of these case= s >> for maximum flexibility. >> >> It may also be an idea to permit caching of at least AD- and RD-paramete= rs >> or evaluations of them, especially if we're talking extensive sets with >> perhaps hundreds of parameters. Since the ADs and RDs should be free to >> update their own parameters at any time, the handshake in that case must= of >> course contain a check if cached parameters have been updated. Also, if = an >> AD or RD supports several sets of parameters depending on which domain o= r >> service it deals with, means to distinguish between them are required, >> perhaps using policy URI's the way Meadhbh suggested >> (http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html). A pol= icy >> could then basically be broken down into a set of own parameter values a= nd >> required parameter ranges for the domain or service connecting. >> >> I also think, like Meadhbh >> (http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html), that = we >> will need to suggest, but not require, a number of parameter name and >> formats to facilitate communication, so that not e.g. US and UK domains >> can't connect, because one asks about "color" and the other one only can >> respond about "colour". >> >> Best regards, >> >> Magnus >> >> >> - -----Ursprungligt meddelande----- >> Fr=E5n: Carlo Wood [mailto:carlo@alinoe.com] >> Skickat: den 7 oktober 2009 22:36 >> Till: Infinity Linden >> Kopia: Magnus Zeisig; ogpx@ietf.org >> =C4mne: Re: [ogpx] Protocol for permitting policy decisions >> >> On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden wrote: >> > option 3: multi-message handshake >> > >> > AD --------------- (name) -------------> RD >> > AD <-------- (X, age > X? cap) --------- RD >> > >> > AD ------------------------------------> RD (age > X? cap) >> > AD <------------ (rez cap) ------------- RD >> >> Note, again, the need for a flexible protocol negotiation: >> we can't know, already, what all will be needed. >> >> Nevertheless, the more flexibility the better imho. >> I'd prefer to see this: >> >> AD ------(name, ) -----------> RD >> AD <-----(name, ) --- RD >> AD ------(name, yes/no)--------------------------> RD >> AD <-----(rez cap) ------------------------------- RD >> >> Where VWRAP will not define what keywords are possible. >> >> However, implementers might, for example, choose to use 'AGE' as keyword >> with an integer range, leading to a msg exchange like >> >> AD ------(name, (AGE)) -----------> RD >> AD <-----(name, (AGE, 21)) -------- RD >> AD ------(name, yes)--------------> RD >> AD <-----(rez cap) ---------------- RD >> >> or some might implement >> >> AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD >> AD <-----(name, (AGE, 13), YES) ------------------ RD >> AD ------(name, yes, yes)------------------------> RD >> AD <-----(rez cap) ------------------------------- RD >> >> For privacy reasons, I think it would suffice to >> just send the AND of all 'yes's, thus: >> >> AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD >> AD <-----(name, (AGE, 13), YES) ------------------ RD >> AD ------(name, yes)-----------------------------> RD >> AD <-----(rez cap) ------------------------------- RD >> >> or, >> >> AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD >> AD <-----(name, (AGE, 13), DONTCARE) ------------- RD >> AD ------(name, yes)-----------------------------> RD >> AD <-----(rez cap) ------------------------------- RD >> >> Again, neither 'AGE' nor 'LIKES_BUNNIES', would be defined by us, >> but we would define how to handle integer ranges, booleans, >> don't cares, string literals, and perhaps regular expressions. >> >> - -- >> Carlo Wood >> >> -----BEGIN PGP SIGNATURE----- >> Version: 9.8.3 (Build 4028) >> Charset: utf-8 >> >> wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al3nKcL >> JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfgs7Ta/ >> cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9ByIbMJ >> RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOzWzsWm >> tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bldq/Bnd >> 60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w=3D=3D >> =3D2NSu >> -----END PGP SIGNATURE----- >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From dwl@us.ibm.com Thu Oct 8 10:29:41 2009 Return-Path: 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 8ECB428C1B0; Thu, 8 Oct 2009 10:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.807 X-Spam-Level: X-Spam-Status: No, score=-3.807 tagged_above=-999 required=5 tests=[AWL=-1.209, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 3UCZuud3tIab; Thu, 8 Oct 2009 10:29:39 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 40DB83A6868; Thu, 8 Oct 2009 10:29:38 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n98HSVrC028954; Thu, 8 Oct 2009 13:28:31 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n98HVEAu242802; Thu, 8 Oct 2009 13:31:14 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n98HVDIT023839; Thu, 8 Oct 2009 13:31:13 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n98HVDi7023777; Thu, 8 Oct 2009 13:31:13 -0400 In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> To: Joshua Bell MIME-Version: 1.0 X-KeepSent: 2B289B05:EDF5C989-85257649:005F3FA2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Thu, 8 Oct 2009 13:31:12 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/08/2009 13:31:13, Serialize complete at 10/08/2009 13:31:13 Content-Type: multipart/alternative; boundary="=_alternative 00603D7385257649_=" Cc: ogpx-bounces@ietf.org, ogpx 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 17:29:41 -0000 This is a multipart message in MIME format. --=_alternative 00603D7385257649_= Content-Type: text/plain; charset="US-ASCII" ogpx-bounces@ietf.org wrote on 10/08/2009 12:45:56 PM: [snip] > > :) Honestly, I was trying to riff on the thread (AD and RD sharing > information about agents to make policy decisions), rather than > propose anything. I think an attempt to define a global set of > characteristics about users that enable all policy decisions is > hopeless - cultures, laws, and individuals are too varied and rich. > That leaves pair-wise negotiation and/or trust networks, which IMHO > needs to happen *if* there are to be service-level distinctions for > most cases anyway. > > What I forgot to say is: on the Web, as you move between sites you > accept various terms of service. Attempts to have your browser > automatically negotiate with sites over content have been extremely > limited - things like the defunct PICS (you tell your browser to > allow a third party site to rate the site you intend to visit), or > Google's features which block malware/phishing sites (and I believe > are used by current browsers as well when you just type a URL). Your > user-agent (Web browser) does *not* have a built-in lawyer that > agrees to a TOS on your behalf, however. (I'm having flashbacks of > "Diamond Age" here - is that the right novel?) > > In the VWRAP space, I don't believe your VW agent domain will be > capable of doing that in a totally generalized, automated way > either... so either it will have some a priori knowledge of the RD > via some manner (pair-wise negotiation, trust network, etc), defer > to the user to accept the TOS, or simply block access. > > In other words: "Just like the web, except where it's different" once again. > I'm leaning ever more strongly towards David's position that only > services should carry expressions of policy, not domains, because in > the direction in which this discussion is heading there will be no > widespread interop at all. > > I need to re-read Meadhbh's drafts to internalize the formal > terminology (yeah, my bad), but in my head a "domain" is a > deployment model for a set of conceptually related services, but > it's the service end-points that exist at the protocol level. We > talk about domains as clusters of conceptually related services as a > crutch so we don't have to enumerate the specific services in each > conversation. > I think this last is of the essence. Domains seem to be artifacts which arise out of deployment patterns and how people may administrate deployed systems. The clustering of services, the shared policies have very little to do with protocol and a lot to do with how the endpoints implementing the protocol are deployed. I am thinking that the overall model is very much that the protocols are the mechanisms to ensure that the endpoints encoding common services work in the same way, and the policies that specific endpoints apply will define bounds on how the mechanisms are used. I would argue that what we need, therefore (Once again sounding like a looping mp3) is to ensure we have the right mechanisms defined in the protocols to permit the range of policies for which we have use cases. I also think this ties to why I am pushing back a bit on how we are slinging the phrase "domain" around. If domains actually are reflections of deployment patterns, then to a large extent, you need to describe domains in a way that is closely coupled to specific deployments. If I assume one deployment pattern and you another, and we each say "agent domain" we end up talking at cross purposes, because our deployment assumptions create domains which have different properties, which we paper over in the language - David Levine ~ Zha Ewwy --=_alternative 00603D7385257649_= Content-Type: text/html; charset="US-ASCII"

ogpx-bounces@ietf.org wrote on 10/08/2009 12:45:56 PM:

[snip]
>
> :) Honestly, I was trying to riff on the thread (AD and RD sharing
> information about agents to make policy decisions), rather than
> propose anything. I think an attempt to define a global set of
> characteristics about users that enable all policy decisions is
> hopeless - cultures, laws, and individuals are too varied and rich.
> That leaves pair-wise negotiation and/or trust networks, which IMHO
> needs to happen *if* there are to be service-level distinctions for
> most cases anyway.
>
> What I forgot to say is: on the Web, as you move between sites you
> accept various terms of service. Attempts to have your browser
> automatically negotiate with sites over content have been extremely
> limited - things like the defunct PICS (you tell your browser to
> allow a third party site to rate the site you intend to visit), or
> Google's features which block malware/phishing sites (and I believe
> are used by current browsers as well when you just type a URL). Your
> user-agent (Web browser) does *not* have a built-in lawyer that
> agrees to a TOS on your behalf, however. (I'm having flashbacks of
> "Diamond Age" here - is that the right novel?)
>
> In the VWRAP space, I don't believe your VW agent domain will be
> capable of doing that in a totally generalized, automated way
> either... so either it will have some a priori knowledge of the RD
> via some manner (pair-wise negotiation, trust network, etc), defer
> to the user to accept the TOS, or simply block access.
>
> In other words: "Just like the web, except where it's different" once again.
> I'm leaning ever more strongly towards David's position that only
> services should carry expressions of policy, not domains, because in
> the direction in which this discussion is heading there will be no
> widespread interop at all.
>
> I need to re-read Meadhbh's drafts to internalize the formal
> terminology (yeah, my bad), but in my head a "domain" is a
> deployment model for a set of conceptually related services, but
> it's the service end-points that exist at the protocol level. We
> talk about domains as clusters of conceptually related services as a
> crutch so we don't have to enumerate the specific services in each
> conversation.
>

I think this last is of the essence. Domains seem to be artifacts which
arise out of deployment patterns and how people may administrate deployed
systems. The clustering of services, the shared policies have very little to
do with protocol and a lot to do with how the endpoints implementing the
protocol are deployed.

I am thinking that the overall model is very much that the protocols are the
mechanisms to ensure that the endpoints encoding common services work in the
same way, and the policies that specific endpoints apply will define bounds
on how the mechanisms are used. I would argue that what we need, therefore
(Once again sounding like a looping mp3) is to ensure we have the right
mechanisms defined in the protocols to permit the range of policies for which
we have use cases.

I also think this ties to why I am pushing back a bit on how we are slinging
the phrase "domain" around. If domains actually are reflections of
deployment patterns, then to a large extent, you need to describe
domains in a way that is closely coupled to specific deployments. If I
assume one deployment pattern and you another, and we each say "agent domain"
we end up talking at cross purposes, because our deployment assumptions create
domains which have different properties, which we paper over in the language



- David Levine
~ Zha Ewwy
--=_alternative 00603D7385257649_=-- From dwl@us.ibm.com Thu Oct 8 10:42:07 2009 Return-Path: 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 87A6328C1BA; Thu, 8 Oct 2009 10:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[AWL=-1.164, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Sb6LabY8IjuF; Thu, 8 Oct 2009 10:42:04 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id BB28128C1C5; Thu, 8 Oct 2009 10:42:02 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n98HeHKN026295; Thu, 8 Oct 2009 13:40:17 -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 n98HhirS255120; Thu, 8 Oct 2009 13:43:44 -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 n98HeKRg027919; Thu, 8 Oct 2009 13:40:20 -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 n98HeKO2027914; Thu, 8 Oct 2009 13:40:20 -0400 In-Reply-To: <3a880e2c0910081026v73de39f8k7c340295b2166dda@mail.gmail.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <3a880e2c0910081026v73de39f8k7c340295b2166dda@mail.gmail.com> To: "Infinity Linden (Meadhbh Hamrick)" MIME-Version: 1.0 X-KeepSent: 50D63A44:332F7F8E-85257649:00608E46; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Thu, 8 Oct 2009 13:43:43 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/08/2009 13:43:43, Serialize complete at 10/08/2009 13:43:43 Content-Type: multipart/alternative; boundary="=_alternative 006162B185257649_=" Cc: ogpx-bounces@ietf.org, "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 17:42:07 -0000 This is a multipart message in MIME format. --=_alternative 006162B185257649_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable This feels right. The leverage point the Agent Domain has on "protecting"=20 its users is choosing whether or not to send a user off to the region. If it has constraints, it is going to=20 need assurances they are being met by the region. These are policies on service endpoint requests=20 I will then note, that the region may turn around and need assurances from = services hosted by=20 other service providers, for example, an asset service. It may have a=20 local policy=20 which says "I will only request asset fetching caps from asset servers=20 which have a proof that they legally mark adult content, and will not send me adult content"=20 And.. now.. notice that the policy enforcement is local in both cases. The = region protects itself through a local choice to only accept content from "safe" sources. The=20 Agent Domain protect its users from "undesirable" content by ensuring that it checks=20 destination for conformance to its needs. before it hands users off to them. Neither=20 service imposes=20 behavior on other services, rather it only uses services which promise to=20 meet its standards.=20 - David Levine ~ Zha Ewry "Infinity Linden (Meadhbh Hamrick)" =20 Sent by: ogpx-bounces@ietf.org 10/08/2009 01:26 PM To Morgaine cc "ogpx@ietf.org" , Magnus Zeisig Subject Re: [ogpx] Protocol for permitting policy decisions i wouldn't say that AD's are involved with region policy. i would say that the AD's have a policy of not placing avatars in regions that do not advertise certain metadata and the AD believes they can be trusted. getting back to the adult region example... let's say i'm an operator of a shared virtual experience. i have a bunch of underage customers. many of them have parents who both have money to pay lawyers and don't want their kids getting access to "adult content." also, i advertise my service in the united states, UK and other countries who have regulations or laws limiting access to adult material by minors. my policy, as a service operator, will probably very quickly become "comply with local regulations and with foreign regulation as required by international treaty to avoid criminal and civil liability." so i have an agent domain, because i have a relationship with my customers. i probably have several regions i operate on my own, but i want to stitch my regions up with regions operated by happy funco land, inc. (HFLI). HFLI operates an adults only service and there's adult content on their grid. in the US, it doesn't matter that HFLI operates the region. i was complicit in the act of connecting minors to adult content online. i have the relationship with the customer. guess who's going to get sued first? what i may do in this case is tell HFLI that if they want my bazillion users to connect to their land, they're going to have to segregate adult content into specific regions and mark those regions with an adults only maturity tag. before i place an avatar in that region, i (as the agent domain operator) will look at the age of the user and then look at the maturity tag on the region they want to teleport into. if the region is tagged "adult" and my avatar is underage, i will not try to rez their avatar. i do it this way because i really, really, really don't want to open myself up to liability. i don't want to depend on a foreign organization to enforce MY policy. so, this is not an example where i (as the agent domain) is interfering or setting the policy of a third party. i am not the authority for that domain. what i =5Fcan=5F do, however, is contract that third party to follow certain procedural safeguards, and before allowing my users to set virtual foot in their land, force them to assume liability if they do not exercise due care in the execution of their contractual obligations. so this is a use case where we do not dynamically modify policy. we negotiate a policy and behavior through legal channels before allowing access from the AD to the RD. as the AD, i am not telling the RD during the protocol negotiation phase what my policy requirements are. i am not negotiating a policy at connect time. what i =5Fam=5F doing is i =5Fam=5F looking at a trusted identifier for that RD (like a TLS server certificate,) i am validating it, then i am doing a lookup in my system to see if i trust them, then i am determining the policy with regards to adult content on that region. if the policy is conformable with mine, i begin the process of teleporting the user's avatar to that region. there are several ways to determine policy: a. identity implies policy. maybe i happen to be connected to Dalt Wisney and know that they are an exclusively "family oriented" operation. ergo, i know i don't have to worry about adult material being in those regions. b. authenticator implies policy. maybe if we're using X.509 certificates, we've made a deal to stuff policy identifiers in the X.509 certificates. sure, there are a lot of reasons NOT to do this, but then again, maybe it works for some people. c. region metadata implies policy. maybe when we access the region meta data, there's a tag for "adult material here." these are the options for the way we anticipate our service operating. but i'm not prejudiced against the tourist model, so sure, let's allow, but not REQUIRE AD's to go through this negotiation process if we're in the virtual tourist model. -cheers -meadhbh/infinity -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity=5FLinden On Thu, Oct 8, 2009 at 02:41, Morgaine =20 wrote: > Magnus, > > If ADs are involved in region policy, then in the multi-world deployment > pattern, AD2 will have to be consulted when agent A1 teleports from RD1=20 to > RD2, because AD2 will be involved in region policy too. It's symmetric=20 with > AD1. > > This is what Joshua wanted to avoid, and it can only be avoided by not > giving ADs policy control over regions, otherwise symmetry requires that = AD2 > be consulted as well. > > It's this kind of problem that reinforces what David's been saying about = the > right mess we currently have when talking about domains determining=20 policy. > The AD/RD split was reasonably adequate when OGP was only extending a=20 single > world with policy-free regions, but it is insufficient to do a good job=20 once > we get into multi-world deployments with more complex service and policy > patterns which require much more flexibility. > > > Morgaine. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig =20 wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> I am strongly in favour of leaving policy descisions to the RD, but=20 since >> there seems to be a need for at least some AD managers to be able to=20 make >> policy decisions as well, I guess the protocol handshake need even more >> flexibility than the versions scetched on by Meadhbh, Carlo and me so=20 far. I >> will adapt the diagram style of Meadhbh and Carlo >> (http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html),=20 since >> it's more readable than my text-flow variant. Also, I will leave out >> parameter examples since there seem to be a risk people get hooked on=20 if a >> certain parameter should be included or not, rather than the=20 possibility of >> handling any parameter. >> >> I may be paranoid, but I still prefer agent domains to be allowed, but=20 not >> forced by protocol, to reduce the dissemination of information about=20 their >> clients as far as possible, and there Carlo's AND version in the=20 response is >> a good step forward >> (http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html). We=20 might >> even wind up with negotiations where one domain requests the actual=20 values >> while the other domain only wants to disseminate a reply to if it fits=20 a >> range for one or more of the requested parameters. >> >> AD -------------------------(name, > RDkey2?>)------------------------> RD >> AD <--(name, > agentkey2?>)--- RD >> AD --(name, > range?>)-> RD >> AD <----------(name, > range>)----------- RD >> AD ----------------------------(name, agentkey2 >> OK)---------------------------> RD >> AD <-----------------------------(name, rez >> cap)------------------------------- RD >> >> In this example, RD might have refused giving the required range for >> agentvalue2, either because it technically doesn't support that kind of >> negotiation or because of policy, in either case of which the rez cap=20 would >> have failed. It might on the other hand instead already from the=20 beginning >> have supplied the required ranges instead of asking for the actual=20 value. I >> think it would be good if the protocol would enable either of these=20 cases >> for maximum flexibility. >> >> It may also be an idea to permit caching of at least AD- and=20 RD-parameters >> or evaluations of them, especially if we're talking extensive sets with >> perhaps hundreds of parameters. Since the ADs and RDs should be free to >> update their own parameters at any time, the handshake in that case=20 must of >> course contain a check if cached parameters have been updated. Also, if = an >> AD or RD supports several sets of parameters depending on which domain=20 or >> service it deals with, means to distinguish between them are required, >> perhaps using policy URI's the way Meadhbh suggested >> (http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html). A=20 policy >> could then basically be broken down into a set of own parameter values=20 and >> required parameter ranges for the domain or service connecting. >> >> I also think, like Meadhbh >> (http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html), that = we >> will need to suggest, but not require, a number of parameter name and >> formats to facilitate communication, so that not e.g. US and UK domains >> can't connect, because one asks about "color" and the other one only=20 can >> respond about "colour". >> >> Best regards, >> >> Magnus >> >> >> - -----Ursprungligt meddelande----- >> Fr=E5n: Carlo Wood [mailto:carlo@alinoe.com] >> Skickat: den 7 oktober 2009 22:36 >> Till: Infinity Linden >> Kopia: Magnus Zeisig; ogpx@ietf.org >> =C4mne: Re: [ogpx] Protocol for permitting policy decisions >> >> On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden wrote: >> > option 3: multi-message handshake >> > >> > AD --------------- (name) -------------> RD >> > AD <-------- (X, age > X? cap) --------- RD >> > >> > AD ------------------------------------> RD (age > X? cap) >> > AD <------------ (rez cap) ------------- RD >> >> Note, again, the need for a flexible protocol negotiation: >> we can't know, already, what all will be needed. >> >> Nevertheless, the more flexibility the better imho. >> I'd prefer to see this: >> >> AD ------(name, ) -----------> RD >> AD <-----(name, ) --- RD >> AD ------(name, yes/no)--------------------------> RD >> AD <-----(rez cap) ------------------------------- RD >> >> Where VWRAP will not define what keywords are possible. >> >> However, implementers might, for example, choose to use 'AGE' as=20 keyword >> with an integer range, leading to a msg exchange like >> >> AD ------(name, (AGE)) -----------> RD >> AD <-----(name, (AGE, 21)) -------- RD >> AD ------(name, yes)--------------> RD >> AD <-----(rez cap) ---------------- RD >> >> or some might implement >> >> AD ------(name, (AGE, LIKES=5FBUNNIES)) -----------> RD >> AD <-----(name, (AGE, 13), YES) ------------------ RD >> AD ------(name, yes, yes)------------------------> RD >> AD <-----(rez cap) ------------------------------- RD >> >> For privacy reasons, I think it would suffice to >> just send the AND of all 'yes's, thus: >> >> AD ------(name, (AGE, LIKES=5FBUNNIES)) -----------> RD >> AD <-----(name, (AGE, 13), YES) ------------------ RD >> AD ------(name, yes)-----------------------------> RD >> AD <-----(rez cap) ------------------------------- RD >> >> or, >> >> AD ------(name, (AGE, LIKES=5FBUNNIES)) -----------> RD >> AD <-----(name, (AGE, 13), DONTCARE) ------------- RD >> AD ------(name, yes)-----------------------------> RD >> AD <-----(rez cap) ------------------------------- RD >> >> Again, neither 'AGE' nor 'LIKES=5FBUNNIES', would be defined by us, >> but we would define how to handle integer ranges, booleans, >> don't cares, string literals, and perhaps regular expressions. >> >> - -- >> Carlo Wood >> >> -----BEGIN PGP SIGNATURE----- >> Version: 9.8.3 (Build 4028) >> Charset: utf-8 >> >> wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al3nKcL >> JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfgs7Ta/ >> cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9ByIbMJ >> RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOzWzsWm >> tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bldq/Bnd >> 60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w=3D=3D >> =3D2NSu >> -----END PGP SIGNATURE----- >> >> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 006162B185257649_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
This feels right. The leverage point the Agent Domain has on "protecting" its users is choosing whether or not
to send a user off to the region. If it has constraints, it is going to need assurances they are being met by
the region. These are policies on se= rvice endpoint requests

I will then note, that the region may turn around and need assurances from services hosted by
other service providers, for example, an asset service. It may have a local policy
which says "I will only request asset fetching caps from asset servers which have a proof that
they legally mark adult content, and will not send me adult content"

And.. now.. notice that the policy e= nforcement is local in both cases. The region protects itself
through a local choice to only accept content from "safe" sources. The Agent Domain
protect its users from "undesir= able" content by ensuring that it checks destination for
conformance to its needs. before it hands users off to them. Neither service imposes
behavior on other services, rather it only uses services which promise to meet its
standards.

- David Levine
~ Zha Ewry






"Infinity Linden= (Meadhbh Hamrick)" <infinity@lindenlab.com>
Sent by: ogpx-bounces@ietf.org

10/08/2009 01:26 PM

To
Morgaine <morgaine.dinova@googlem= ail.com>
cc
"ogpx@ietf.org" <ogpx@i= etf.org>, Magnus Zeisig <magnus.zeisig@iis.se>
Subject
Re: [ogpx] Protocol for permitting p= olicy decisions





i wouldn't say that AD's are involved with region policy. i would say
that the AD's have a policy of not placing avatars in regions that do
not advertise certain metadata and the AD believes they can be
trusted.

getting back to the adult region example... let's say i'm an operator
of a shared virtual experience. i have a bunch of underage customers.
many of them have parents who both have money to pay lawyers and don't
want their kids getting access to "adult content." also, i advert= ise
my service in the united states, UK and other countries who have
regulations or laws limiting access to adult material by minors. my
policy, as a service operator, will probably very quickly become
"comply with local regulations and with foreign regulation as required=
by international treaty to avoid criminal and civil liability."

so i have an agent domain, because i have a relationship with my
customers. i probably have several regions i operate on my own, but i
want to stitch my regions up with regions operated by happy funco
land, inc. (HFLI). HFLI operates an adults only service and there's
adult content on their grid. in the US, it doesn't matter that HFLI
operates the region. i was complicit in the act of connecting minors
to adult content online. i have the relationship with the customer.
guess who's going to get sued first?

what i may do in this case is tell HFLI that if they want my bazillion
users to connect to their land, they're going to have to segregate
adult content into specific regions and mark those regions with an
adults only maturity tag. before i place an avatar in that region, i
(as the agent domain operator) will look at the age of the user and
then look at the maturity tag on the region they want to teleport
into. if the region is tagged "adult" and my avatar is underage, i
will not try to rez their avatar. i do it this way because i really,
really, really don't want to open myself up to liability. i don't want
to depend on a foreign organization to enforce MY policy.

so, this is not an example where i (as the agent domain) is
interfering or setting the policy of a third party. i am not the
authority for that domain. what i =5Fcan=5F do, however, is contract that third party to follow certain procedural safeguards, and before
allowing my users to set virtual foot in their land, force them to
assume liability if they do not exercise due care in the execution of
their contractual obligations.

so this is a use case where we do not dynamically modify policy. we
negotiate a policy and behavior through legal channels before allowing
access from the AD to the RD. as the AD, i am not telling the RD
during the protocol negotiation phase what my policy requirements are.
i am not negotiating a policy at connect time. what i =5Fam=5F doing is i =5Fam=5F looking at a trusted identifier for that RD (like a TLS server
certificate,) i am validating it, then i am doing a lookup in my
system to see if i trust them, then i am determining the policy with
regards to adult content on that region. if the policy is conformable
with mine, i begin the process of teleporting the user's avatar to
that region.

there are several ways to determine policy:

a. identity implies policy. maybe i happen to be connected to Dalt
Wisney and know that they are an exclusively "family oriented"
operation. ergo, i know i don't have to worry about adult material
being in those regions.

b. authenticator implies policy. maybe if we're using X.509
certificates, we've made a deal to stuff policy identifiers in the
X.509 certificates. sure, there are a lot of reasons NOT to do this,
but then again, maybe it works for some people.

c. region metadata implies policy. maybe when we access the region
meta data, there's a tag for "adult material here."

these are the options for the way we anticipate our service operating.
but i'm not prejudiced against the tourist model, so sure, let's
allow, but not REQUIRE AD's to go through this negotiation process if
we're in the virtual tourist model.

-cheers
-meadhbh/infinity

--
  infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
        http://wiki.secondlife.co= m/wiki/User:Infinity=5FLinden



On Thu, Oct 8, 2009 at 02:41, Morgaine <morgaine.dinova@googlemail.com&g= t; wrote:
> Magnus,
>
> If ADs are involved in region policy, then in the multi-world deployme= nt
> pattern, AD2 will have to be consulted when agent A1 teleports from RD1 to
> RD2, because AD2 will be involved in region policy too.  It's symmetric with
> AD1.
>
> This is what Joshua wanted to avoid, and it can only be avoided by not
> giving ADs policy control over regions, otherwise symmetry requires that AD2
> be consulted as well.
>
> It's this kind of problem that reinforces what David's been saying about the
> right mess we currently have when talking about domains determining policy.
> The AD/RD split was reasonably adequate when OGP was only extending a single
> world with policy-free regions, but it is insufficient to do a good job once
> we get into multi-world deployments with more complex service and policy
> patterns which require much more flexibility.
>
>
> Morgaine.
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig <magnus.zeisig@iis.se= > wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> I am strongly in favour of leaving policy descisions to the RD, but since
>> there seems to be a need for at least some AD managers to be able to make
>> policy decisions as well, I guess the protocol handshake need even more
>> flexibility than the versions scetched on by Meadhbh, Carlo and me so far. I
>> will adapt the diagram style of Meadhbh and Carlo
>> (http://www.ietf.org/mail-archive/= web/ogpx/current/msg00520.html), since
>> it's more readable than my text-flow variant. Also, I will leave out
>> parameter examples since there seem to be a risk people get hooked on if a
>> certain parameter should be included or not, rather than the possi= bility of
>> handling any parameter.
>>
>> I may be paranoid, but I still prefer agent domains to be allowed, but not
>> forced by protocol, to reduce the dissemination of information about their
>> clients as far as possible, and there Carlo's AND version in the response is
>> a good step forward
>> (http://www.ietf.org/mail-archive/= web/ogpx/current/msg00520.html). We might
>> even wind up with negotiations where one domain requests the actual values
>> while the other domain only wants to disseminate a reply to if it fits a
>> range for one or more of the requested parameters.
>>
>> AD -------------------------(name, <RDkey1?,
>> RDkey2?>)------------------------> RD
>> AD <--(name, <RDvalue1, RDvalue2, ADkey1?, ADkey2?, agentkey= 1?,
>> agentkey2?>)--- RD
>> AD --(name, <RDvalues OK, ADvalue1, ADvalue2, agentvalue1, agentkey2
>> range?>)-> RD
>> AD <----------(name, <ADvalues OK, agentvalue1 OK, agentkey2=
>> range>)----------- RD
>> AD ----------------------------(name, agentkey2
>> OK)---------------------------> RD
>> AD <-----------------------------(name, rez
>> cap)------------------------------- RD
>>
>> In this example, RD might have refused giving the required range for
>> agentvalue2, either because it technically doesn't support that kind of
>> negotiation or because of policy, in either case of which the rez cap would
>> have failed. It might on the other hand instead already from the beginning
>> have supplied the required ranges instead of asking for the actual value. I
>> think it would be good if the protocol would enable either of these cases
>> for maximum flexibility.
>>
>> It may also be an idea to permit caching of at least AD- and RD-pa= rameters
>> or evaluations of them, especially if we're talking extensive sets with
>> perhaps hundreds of parameters. Since the ADs and RDs should be free to
>> update their own parameters at any time, the handshake in that case must of
>> course contain a check if cached parameters have been updated. Also, if an
>> AD or RD supports several sets of parameters depending on which domain or
>> service it deals with, means to distinguish between them are requi= red,
>> perhaps using policy URI's the way Meadhbh suggested
>> (http://www.ietf.org/mail-archive/= web/ogpx/current/msg00523.html). A policy
>> could then basically be broken down into a set of own parameter values and
>> required parameter ranges for the domain or service connecting.
>>
>> I also think, like Meadhbh
>> (http://www.ietf.org/mail-archive/= web/ogpx/current/msg00523.html), that we
>> will need to suggest, but not require, a number of parameter name and
>> formats to facilitate communication, so that not e.g. US and UK domains
>> can't connect, because one asks about "color" and the other one only can
>> respond about "colour".
>>
>> Best regards,
>>
>> Magnus
>>
>>
>> - -----Ursprungligt meddelande-----
>> Fr=E5n: Carlo Wood [= mailto:carlo@alinoe.com]
>> Skickat: den 7 oktober 2009 22:36
>> Till: Infinity Linden
>> Kopia: Magnus Zeisig; ogpx@ietf.org
>> =C4mne: Re: [ogpx] Protocol for permitting policy decisions
>>
>> On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden wrote: >> > option 3: multi-message handshake
>> >
>> > AD --------------- (name) -------------> RD
>> > AD <-------- (X, age > X? cap) --------- RD
>> >
>> > AD ------------------------------------> RD (age > X? cap)
>> > AD <------------ (rez cap) ------------- RD
>>
>> Note, again, the need for a flexible protocol negotiation:
>> we can't know, already, what all will be needed.
>>
>> Nevertheless, the more flexibility the better imho.
>> I'd prefer to see this:
>>
>> AD ------(name, <list with keywords>) -----------> RD
>> AD <-----(name, <list with keywords + ranges>) --- RD
>> AD ------(name, yes/no)--------------------------> RD
>> AD <-----(rez cap) ------------------------------- RD
>>
>> Where VWRAP will not define what keywords are possible.
>>
>> However, implementers might, for example, choose to use 'AGE' as keyword
>> with an integer range, leading to a msg exchange like
>>
>> AD ------(name, (AGE)) -----------> RD
>> AD <-----(name, (AGE, 21)) -------- RD
>> AD ------(name, yes)--------------> RD
>> AD <-----(rez cap) ---------------- RD
>>
>> or some might implement
>>
>> AD ------(name, (AGE, LIKES=5FBUNNIES)) -----------> RD
>> AD <-----(name, (AGE, 13), YES) ------------------ RD
>> AD ------(name, yes, yes)------------------------> RD
>> AD <-----(rez cap) ------------------------------- RD
>>
>> For privacy reasons, I think it would suffice to
>> just send the AND of all 'yes's, thus:
>>
>> AD ------(name, (AGE, LIKES=5FBUNNIES)) -----------> RD
>> AD <-----(name, (AGE, 13), YES) ------------------ RD
>> AD ------(name, yes)-----------------------------> RD
>> AD <-----(rez cap) ------------------------------- RD
>>
>> or,
>>
>> AD ------(name, (AGE, LIKES=5FBUNNIES)) -----------> RD
>> AD <-----(name, (AGE, 13), DONTCARE) ------------- RD
>> AD ------(name, yes)-----------------------------> RD
>> AD <-----(rez cap) ------------------------------- RD
>>
>> Again, neither 'AGE' nor 'LIKES=5FBUNNIES', would be defined by us,
>> but we would define how to handle integer ranges, booleans,
>> don't cares, string literals, and perhaps regular expressions.
>>
>> - --
>> Carlo Wood <carlo@alinoe.com>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: 9.8.3 (Build 4028)
>> Charset: utf-8
>>
>> wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al3nKcL >> JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfgs7Ta/ >> cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9ByIbMJ >> RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOzWzsWm >> tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bldq/Bnd >> 60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w=3D=3D
>> =3D2NSu
>> -----END PGP SIGNATURE-----
>>
>>
>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
>> ogpx mailing list
>> ogpx@ietf.org
>> <= tt>https://www.ietf.org/mailman/listinfo/ogpx
>>
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> ogpx mailing list
> ogpx@ietf.org
> <= font size=3D2>https://www.ietf.org/mailman/listinfo/ogpx
>
>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 006162B185257649_=-- From carlo@alinoe.com Thu Oct 8 16:29:40 2009 Return-Path: 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 4CECF3A693D for ; Thu, 8 Oct 2009 16:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.213 X-Spam-Level: X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 tHue2hqChaL4 for ; Thu, 8 Oct 2009 16:29:39 -0700 (PDT) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by core3.amsl.com (Postfix) with ESMTP id 161933A691A for ; Thu, 8 Oct 2009 16:29:38 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep15-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091008233121.HZYA17988.viefep15-int.chello.at@edge01.upc.biz>; Fri, 9 Oct 2009 01:31:21 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id qPXJ1c01g0FlQed01PXK5J; Fri, 09 Oct 2009 01:31:21 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mw2TT-0006hf-Cy; Fri, 09 Oct 2009 01:32:43 +0200 Date: Fri, 9 Oct 2009 01:32:43 +0200 From: Carlo Wood To: Meadhbh Hamrick Message-ID: <20091008233243.GC13882@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <9b8a8de40910061305w56dc2b01qab60b7b7aaffa337@mail.gmail.com> <9b8a8de40910071112j600dea3fge21a35ffc0341e52@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 23:29:40 -0000 On Wed, Oct 07, 2009 at 03:30:26PM -0700, Meadhbh Hamrick wrote: > a service. but other than to acknowledge that it might happen, i don't > think it's in our best interest to define a protocol for transporting > policy descriptions between domains. what policies are possible will > differ between implementations, and the purpose of defining them as > part of the policy domain is to explicitly remove them from > negotiation during protocol exchanges. I do not agree with this... for some policies this is good, but for others it is not. Since we won't specify an exhausted list, but -hopefully- treat everything abstractly, there still is the need for some abstract list of policy negotiation in the protocol. Example. So far we concentrated on the decision "can this user teleport that region", so allow me to use that case again: * Problem: user can teleport from wherever to Region1 (R1) if both R1 and it's current Agent Service (A1) allow it. * The Agent Service will initiate this, if it (already) thinks it's ok for the user to go to R1 (or would never ask R1). So, A1 policies ARE removed from the protocol, as you said. * What remains are the policies of the region. If you eliminate those too from the protocol than the policy decision making becomes very unflexible. In effect, the right of the region to make also policy decisions would be at the mercy of the agent domain operators (ie, responsiveness) and very hard to change, certainly not frequently and not at all real-time. Surely some policies, like using md5 hashes for something, would be fine under such circumstances; but others, like FOR EXAMPLE (we don't KNOW what all else might pop up) banning certain users; or toggling 'region has mature content' (some region might have adult shows between 20:00 and 4:00, and PG-13 games between 12:00 and 17:00). -- Carlo Wood From carlo@alinoe.com Thu Oct 8 16:36:15 2009 Return-Path: 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 E15713A69E5 for ; Thu, 8 Oct 2009 16:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.216 X-Spam-Level: X-Spam-Status: No, score=-1.216 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 h-l43nNY1KtM for ; Thu, 8 Oct 2009 16:36:15 -0700 (PDT) Received: from viefep12-int.chello.at (viefep12-int.chello.at [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id ABBE63A69A4 for ; Thu, 8 Oct 2009 16:36:14 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep12-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091008233756.IYDH4394.viefep12-int.chello.at@edge05.upc.biz>; Fri, 9 Oct 2009 01:37:56 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id qPdt1c03J0FlQed05PduKy; Fri, 09 Oct 2009 01:37:56 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mw2Zq-0006ov-P2; Fri, 09 Oct 2009 01:39:18 +0200 Date: Fri, 9 Oct 2009 01:39:18 +0200 From: Carlo Wood To: Magnus Zeisig Message-ID: <20091008233918.GD13882@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Infinity Linden , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 23:36:16 -0000 On Thu, Oct 08, 2009 at 10:48:33AM +0200, Magnus Zeisig wrote: > AD -------------------------(name, )------------------------> > RD > AD <--(name, )--- > RD > AD --(name, )-> > RD > AD <----------(name, )----------- > RD > AD ----------------------------(name, agentkey2 OK)---------------------------> > RD > AD <-----------------------------(name, rez cap)------------------------------- > RD I'm ok with this extension, but also open to anyone suggesting it's too flexible, in which case I guess we need to discuss (more) details. Over all, I'd really like it if things go in basically this direction. -- Carlo Wood From carlo@alinoe.com Thu Oct 8 16:53:36 2009 Return-Path: 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 8BE9B3A69E5 for ; Thu, 8 Oct 2009 16:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 ZR7mlfRJmE3n for ; Thu, 8 Oct 2009 16:53:35 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id 0B74F3A69AD for ; Thu, 8 Oct 2009 16:53:33 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091008235515.QFLG13402.viefep18-int.chello.at@edge03.upc.biz>; Fri, 9 Oct 2009 01:55:15 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upc.biz with edge id qPvD1c02V0FlQed03PvEoR; Fri, 09 Oct 2009 01:55:14 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mw2qc-000704-Mt; Fri, 09 Oct 2009 01:56:38 +0200 Date: Fri, 9 Oct 2009 01:56:38 +0200 From: Carlo Wood To: Morgaine Message-ID: <20091008235638.GE13882@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "ogpx@ietf.org" , Magnus Zeisig 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 23:53:36 -0000 On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wrote: > Magnus, > > If ADs are involved in region policy, then in the multi-world deployment > pattern, AD2 will have to be consulted when agent A1 teleports from RD1 to RD2, > because AD2 will be involved in region policy too. It's symmetric with AD1. Morgaine, I'm pretty sure nobody on this list wants AD2 to be involved in anyway. I'm also convinced that there is some misunderstanding involved here, and it would be good to correct that... The following isn't consensus yet, but I feel it's basically the truth, and written down here as such because at least it is simple: In the end there are only services. Services can be grouped as 'domain' to make clear they are run by the same authority and therefore likely will have use the same policies, but for the sake of the protocol you can ignore that. There are several types of services, so far we only concentrated on two types: 1) A region (R1, R2, ...) 2) An authentication service (A1, A2, ...) in principle, every service can be run by a different authority and thus have different policies. One user only uses a single authentication service at a time, every other authentication service is not relevant (for that user). If a user wants to teleport from R1 to R2, while using A3, only A3 and R2 have a say in this. The only say that A3 has is true or false: yes or no allow the user to go to R2. Once the user gets into R2, no policy of A3 matters anymore. It makes no sense whatsoever to group A's with R's for the sake of understanding or designing the protocol. For a teleport decision (or initial connect) only ONE Agent service and ONE region are involved. Almost every policy (of both parties) can be negotiated out of band, yet some of us (including me) are arguing that we need to keep the possibility open for a region to change some abstract policies (based on trusted information from the agent service) more real-time. Here trust is needed in both directions: the region must trust the agent service to answer it's questions correctly and the agent service must trust the region not to fool it into allowing users in that the agent service based on it's own policy doesn't want to allow in. -- Carlo Wood From mike.dickson@hp.com Thu Oct 8 17:01:27 2009 Return-Path: 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 A68BC3A67DB for ; Thu, 8 Oct 2009 17:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 SbwzZ7sL2A9G for ; Thu, 8 Oct 2009 17:01:26 -0700 (PDT) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by core3.amsl.com (Postfix) with ESMTP id D3B1B3A67B2 for ; Thu, 8 Oct 2009 17:01:24 -0700 (PDT) Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id 0969614786; Fri, 9 Oct 2009 00:03:07 +0000 (UTC) Received: from G3W0058.americas.hpqcorp.net (16.232.1.3) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 9 Oct 2009 00:01:41 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G3W0058.americas.hpqcorp.net ([16.232.1.3]) with mapi; Fri, 9 Oct 2009 00:01:41 +0000 From: "Dickson, Mike (ISS Software)" To: Carlo Wood , Magnus Zeisig Date: Fri, 9 Oct 2009 00:01:33 +0000 Thread-Topic: [ogpx] Protocol for permitting policy decisions Thread-Index: AcpIcGAIDsFKffUzTSGXdM02fF37JgAAtVcw Message-ID: <4646639E08F58B42836FAC24C94624DD771A2113BB@GVW0433EXB.americas.hpqcorp.net> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <20091008233918.GD13882@alinoe.com> In-Reply-To: <20091008233918.GD13882@alinoe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Infinity Linden , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 00:01:27 -0000 +1 on this approach. =20 It makes sense to me and seems flexible enough to cover most all the scenar= ios we've discussed. This is the most complex case. In a simpler one there'= s no keys to negotiate over because they've been pre-agreed between AD and = RD so it's simply the first and last flow. All the exchanges in the middle= are driven by constraints that need to be negotiated between the services = involved. Mike -----Original Message----- From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of Car= lo Wood Sent: Thursday, October 08, 2009 6:39 PM To: Magnus Zeisig Cc: Infinity Linden; ogpx@ietf.org Subject: Re: [ogpx] Protocol for permitting policy decisions On Thu, Oct 08, 2009 at 10:48:33AM +0200, Magnus Zeisig wrote: > AD -------------------------(name, )-------------------= -----> > RD > AD <--(name, )--- > RD > AD --(name, )-> > RD > AD <----------(name, )-----= ------ > RD > AD ----------------------------(name, agentkey2 OK)----------------------= -----> > RD > AD <-----------------------------(name, rez cap)-------------------------= ------ > RD I'm ok with this extension, but also open to anyone suggesting it's too fle= xible, in which case I guess we need to discuss (more) details. Over all, I'd really like it if things go in basically this direction. --=20 Carlo Wood _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx From morgaine.dinova@googlemail.com Thu Oct 8 20:51:08 2009 Return-Path: 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 C481D3A68CE for ; Thu, 8 Oct 2009 20:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.268 X-Spam-Level: X-Spam-Status: No, score=-1.268 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=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 hQeXvhMBRKXY for ; Thu, 8 Oct 2009 20:51:05 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 1D1813A6931 for ; Thu, 8 Oct 2009 20:51:03 -0700 (PDT) Received: by ewy4 with SMTP id 4so283599ewy.37 for ; Thu, 08 Oct 2009 20:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bCDGW2VICe6unif7OjIyhHRwjdgSXzJDv3Jed1/k6II=; b=ivXVS1MOHDTbd/BvDEIcjho/7mzAoitIUQxGNNSz5qYH37MAKKAgGhyQ48SsBj2yjT ZJpq80MhRBB6S9NaG+nJdOzTZhEn6SyqMd7hlZ+FCTZ3i5/s2xXvFRnS0skzfiRxgyw7 PDGyrKmfGNM2rycON9E0oXk+77ob1g8OezZXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wY3XPvFlUVJf1xyQAawR2hsAKJ9AmfRzXVzqTdmdO5RYOeMi3nFr5829P2oGNuzo3B 27mwvsOtPWs1Nwh3MXXxOvurpvtT3oCXGFVnz7paqoz16dd/sX3Oeq2cVsap5UX+c9pL zlW6o9lUY/2TyN35KTspo9LWZL0C1HXyZ8Mmw= MIME-Version: 1.0 Received: by 10.211.146.39 with SMTP id y39mr9313881ebn.88.1255060364455; Thu, 08 Oct 2009 20:52:44 -0700 (PDT) In-Reply-To: <983F17705339E24699AA251B458249B50CC48CB7BF@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B50CC48CB6E2@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B50CC48CB7BF@EXCHANGE2K7.office.nic.se> Date: Fri, 9 Oct 2009 04:52:44 +0100 Message-ID: From: Morgaine To: Magnus Zeisig Content-Type: multipart/alternative; boundary=001636c5a51831ef8f04757883d2 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 03:51:08 -0000 --001636c5a51831ef8f04757883d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Magnus, I believe that we're fairly close on everything except the single issue of "symmetry", because you still think that I'm talking about deployment symmetry whereas I'm not at all, I'm talking about *definition*symmetry. However, I think I've found another way of expressing it that might come across better --- I'll focus on CODE. Let's try this new approach instead. :-) Protocols aren't much use until they have been encoded in programs. A program that implements a given protocol fully is written to be able to handle all the possible deployment patterns of that protocol. This allows the program to be used in many different situations to suit local requirements. Such a program is *NOT* written to suit *one single*deployment pattern --- that would be inefficient. Consequently the code that is written is *determined by the definition of the protocol and the definition of the entities in the protocol*. The code that is written is * NOT* determined by the chosen *deployment*, I hope that's clear. So now let's get back to ADs. We don't want ADs to carry region policy, bu= t let's examine what happens if ADs are defined to do so. If ADs are defined to specify region policy, then a program that needs to know about region policy would have to check the ADs --- there is no escaping that. *It would not be protocol-compliant if it did not check the ADs.* The deployment patterns in W1 and W2 (which could be completely different) are of no relevance whatsoever in this --- the program would still have to check for the presence of ADs in *both* worlds just in case the ADs exist, and *all* those ADs that exist would have to be queried for region policy because we've defined that region policy is carried by ADs. = *If the program did not check both ADs then it could be missing part of the region policy.* :-) See what I mean by definition symmetry now? However you define an AD, that definition always applies to both ADs in a 2-world deployment if they exist. The definition can never apply only to one world --- it should be clear that "*ADs carry region policies, but the region policies in my AD ar= e valid while the region policies in your AD will be ignored*" is completely bogus. :-) In protocol terms, this would be non-compliant because part of the region policy would be missed. As a result of this definitional symmetry, the only way we're going to be able to avoid consulting AD2 is our little example scenario is by not allowing ADs to express region policy at all, because if AD1 is allowed to express region policy then AD2 is allowed to express it as well, and hence the program *must try* to consult AD2 for its region policy, by definition of AD. It's very strong logic, and it has nothing to do with the chosen deployments, because it applies *in case* AD2 exists. Of course, as you pointed out, there are many more realistic deployments ou= t there, but this simple one is all that's needed to invalidate the idea that AD1 can express region policy while AD2 can be present but ignored. That cannot happen unless the protocol explicitly defines asymmetric relationships, which is not true in our case and cannot be true given that W1 and W2 are peers. That's all I wanted to describe in this particular reply. I hope the point was clearer this time. :-) Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Thu, Oct 8, 2009 at 3:41 PM, Magnus Zeisig wrote: > Morgain, I believe we're not that far off from each other, even if I thin= k > the example you presented was not appropriate and I still can see no reas= on > for your symmetry in AD/RD requests. The latter notion has already been > commented upon by others in more detail. But like you, I also think it's > reasonable to leave or generalize away from the thought of domains and > rather use services as protocol endpoints. Regardless of if we talk about > domains or services, I think the basic negotiation pattern will always be > the same: > > Client: I want your services but (may) have some (policy) demands to use > them. > Server/Service: I offer you my services but (may) have some (policy) > demands to let you use them. > > Both client and server/service can be the agent or region domain, > user/agent, authentication, presence, asset, inventory, simulation, voice= or > movie service, or any other domain or service you can think of, standalon= e > or clustered in any combinations depending on technical issues, ownership > and agreements. > > So, when any client (C) requests any service from a server/service (S), i= t > may look like this, if all work out: > C ---(id, service?, S policy?)--> S > C <--(id, S policy, C policy?)--- S > C --(id, S policy OK, C policy)-> S > C <-(id, C policy OK, service)--- S > > Policies in this case may refer both to things like data format (mesh > format, image format) and data classification (adult, require IP > agreements). The acceptance of policies, permitting the service performed= , > from both C and S, may be negotiated directly between C and S, or between > servers/services connected to C and S respectively, negotiated at the tim= e > of service request and/or stored in some form of access, token or cap, at= C > and/or S respectively, or servers/services connected to them. > > If C and S are controlled by the same entity, that entity may use any way= , > including VWRAP, to negotiate and deliver the service, and the policy par= t > may be left out from the negotiation, e.g. because the entity use the sam= e > policy for all services controlled. > > If C and S are controlled by different entities, those entities may use a= ny > way, including VWRAP, to negotiate and deliver the service, and the polic= y > part may be left out from the negotiation, e.g. because the entities have= an > already established agreement (format agreement, domain of trust) or don'= t > require one. > > If the policy negotiation is left out, the request becomes: > C --(id, service?)-> S > C <-(id, service)--- S > > To support a flexible new infrastructure with many different domains or > services interacting in many different constellations, including interop > between the "classical" virtual worlds of today, VWRAP should be able to > treat any service request and/or policy negotiation the same or very > similar, regardless of endpoints and endpoint types. The endpoints will > mutually decide if to use VWRAP and to which extent. VWRAP should however= be > an attractive enough way to handle the communication to be a first hand > choice, both between clients and servers/services of the same as well as > different entities. One advantage of using VWRAP will then be that > outsourcing, exchange or addition of services will be easy, since basical= ly > just addresses of servers/services will need to be changed and transfer o= f > old data to the new services be performed. > > I know that some of the things above have already been stated on the list= , > but I'm repeating them just for the clarity of argumentation. > > Best regards, > > Magnus > > > -----Ursprungligt meddelande----- > Fr=E5n: Morgaine [mailto:morgaine.dinova@googlemail.com] > Skickat: den 8 oktober 2009 14:32 > Till: Magnus Zeisig > Kopia: ogpx@ietf.org > =C4mne: Re: [ogpx] Protocol for permitting policy decisions > > Magnus, you're mixing up my analysis of what's required for Joshua's sche= me > to work, with my recognition that we need a more flexible approach based = not > on this restrictive AD+RD split but on the much more flexible decoupled > services behind them. > > When I speak of AD1+RD1 and AD2+RD2 in the analysis, this is not at all > the actual deployment scenario that any of us expects to see. It's just > the smallest case that allows us to say something concrete about the > problems with the original OGP design when extrapolated to the multi-worl= d > deployment scenario. So please don't attribute any narrow vision in this > scenario to me --- I'm fully aware that it's artificial and is going almo= st > nowhere. I'm merely doing a smallest-possible scenario analysis. > > My personal interest is in the fully expanded and massively scaled > deployments which the AWG group in SL was originally formed to consider 2 > years ago (this might give you some idea of the scale --- > https://wiki.secondlife.com/wiki/Project_Motivation ) , but there's no > point describing a massively complex deployment example when a simpler on= e > suffices to make a specific point. :-) > > So to your post ... > > On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeisig > wrote: > > > Morgaine, > > No, you are still stuck in the concept of one virtual world equals > one AD plus one RD, even if you say you recognize a future more complex > service pattern. VW=3DAD+RD does not have to be the case with VWRAP. > > > > I know that it's artificial. We're merely examining this small scenario = to > highlight an elementary problem with distribution of services, and it has > already been useful. It has demonstrated that even in this miniscule > example, there need to be (i) asset service contributions from both world= s > in the example, so just a single inventory service in AD1 is not adequate= , > and (ii) that if ADs control region policy then AD2 must be consulted as > well since it has every bit as much right to determine policy in RD2 as d= oes > AD1, or more. These are important constraints on the design, despite the > deployment example being such a simple one. > > In addition to the case shown, there are simpler cases and there are more > complex cases. > > The simpler cases, such as no AD2 exists, or only W1 asset services are > used in W2, can be handled by the original OGP design, so they wouldn't h= ave > served the purpose here. More complex cases, such as multiple RDs in W2,= do > not add value to the particular point being made, so why complicate the > scenario unnecessarily? We'll certainly need them later, but they don't > help here. > > Obviously multi-world deployment scenarios such as we expect to be common > in the metaverse are going to have much more complex deployment patterns > involved a myriad of concurrent services, but adding that complexity at t= his > point doesn't enhance the present argument. > > > > > If it _happens_ to be the case and the entity controlling AD2 and > RD2 wants to enforce AD2 policy for those visiting RD2, then they can mov= e, > duplicate or mirror the enforcement of that policy from AD2 to RD2, which > they can do without problems as long as they control both. If they don't > control both, then it's entirely up to the entity controlling RD2 if they > for some reason want to enforce the policy of the entity controlling AD2.= So > I see no reason whatsoever why symmetry is required. > > > > > Ah, here you've simply misunderstood me: you think I'm talking about > deployment symmetry, but I'm not. I'm talking about definition symmetry: > if ADs are defined to be able to control region policies, then by symmet= ry > that applies to all ADs. It wouldn't make sense to say "ADs are defined = to > carry region policy, but this only applies to our ADs and not to yours." > ;-) That's what I mean by this applying symmetrically. > > > Deployment patterns are of course arbitrary and don't have to be > symmetrical: two interoperating worlds can individually be using any > deployment pattern they choose, and one world of the pair will generally > have no say on the deployment pattern used by the other. Across the whol= e > metaverse, we can expect every single possible deployment pattern to be u= sed > by someone, and for added spice, tourists from every possible deployment > could be visiting some common tourist world to create a kaleidescope of > combined deployments in the region. > > > > Policy is not decided and enforced by the AD, the RD or any servic= e > connected with them, it is decided and enforced by the entities behind th= em. > If the same entity controls an AD and a RD, then it's meaningless to try = to > divide up that entity's policy into AD policy and RD policy, because it c= an > enforce that policy at any level, type of domain or connected service it > controls. > > > > > Sure, but someone has to code this stuff. It's not helpful to say > "Anything can be done anywhere", because that would mean that the protoco= l > would at every decision point have to gather policy contributions from al= l > possible endpoints. It can be done this way of course, but if a simpler > design suffices then a more compex one may not be a good idea. > > That said, take note of David's advice about policy being best implemente= d > in the services themselves. Domains are not necessarily bad, but they do > actually restrict our flexibility substantially compared to using decoupl= ed > services alone. > > > > But, like you, I am totally in favor of letting the entity > controlling the destination RD decide policy once the agent is there. > However, if the agent's own AD for some reason wants to stop the agent fr= om > going there, then I think it should have the possibility to do so. In all > honesty, I don't think an AD imposing undue restrictions on where people = are > allowed to go or what they are allowed to do there will survive for long > though, once competition is in place. You may have to start out fresh, wi= th > a new AD, without the assets and inventory connected to the old AD, but I > think most people are willing to take that step if they feel their freedo= m > is too limited. > > > > Well in my case I'm not merely "in favour" of region policy control by > regions. I don't think it's actually optional in multi-world deployments= , > because without Destination Determines Destination Policy there can be no > viable multi-world tourism at all, and that's the primary use case with > massive popular interest. We wouldn't have much of a metaverse without i= t. > > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeisig > wrote: > > > Morgaine, > > No, you are still stuck in the concept of one virtual world equals > one AD plus one RD, even if you say you recognize a future more complex > service pattern. VW=3DAD+RD does not have to be the case with VWRAP. If i= t > _happens_ to be the case and the entity controlling AD2 and RD2 wants to > enforce AD2 policy for those visiting RD2, then they can move, duplicate = or > mirror the enforcement of that policy from AD2 to RD2, which they can do > without problems as long as they control both. If they don't control both= , > then it's entirely up to the entity controlling RD2 if they for some reas= on > want to enforce the policy of the entity controlling AD2. So I see no rea= son > whatsoever why symmetry is required. > > Policy is not decided and enforced by the AD, the RD or any servic= e > connected with them, it is decided and enforced by the entities behind th= em. > If the same entity controls an AD and a RD, then it's meaningless to try = to > divide up that entity's policy into AD policy and RD policy, because it c= an > enforce that policy at any level, type of domain or connected service it > controls. > > But, like you, I am totally in favor of letting the entity > controlling the destination RD decide policy once the agent is there. > However, if the agent's own AD for some reason wants to stop the agent fr= om > going there, then I think it should have the possibility to do so. In all > honesty, I don't think an AD imposing undue restrictions on where people = are > allowed to go or what they are allowed to do there will survive for long > though, once competition is in place. You may have to start out fresh, wi= th > a new AD, without the assets and inventory connected to the old AD, but I > think most people are willing to take that step if they feel their freedo= m > is too limited. > > > Best regards, > > Magnus > > > -----Ursprungligt meddelande----- > > Fr=E5n: Morgaine [mailto:morgaine.dinova@googlemail.com] > Skickat: den 8 oktober 2009 11:42 > Till: Magnus Zeisig > Kopia: ogpx@ietf.org > > =C4mne: Re: [ogpx] Protocol for permitting policy decisions > > Magnus, > > If ADs are involved in region policy, then in the multi-world > deployment pattern, AD2 will have to be consulted when agent A1 teleports > from RD1 to RD2, because AD2 will be involved in region policy too. It's > symmetric with AD1. > > This is what Joshua wanted to avoid, and it can only be avoided by > not giving ADs policy control over regions, otherwise symmetry requires t= hat > AD2 be consulted as well. > > It's this kind of problem that reinforces what David's been saying > about the right mess we currently have when talking about domains > determining policy. The AD/RD split was reasonably adequate when OGP was > only extending a single world with policy-free regions, but it is > insufficient to do a good job once we get into multi-world deployments wi= th > more complex service and policy patterns which require much more > flexibility. > > > Morgaine. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig > wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I am strongly in favour of leaving policy descisions to the > RD, but since there seems to be a need for at least some AD managers to b= e > able to make policy decisions as well, I guess the protocol handshake nee= d > even more flexibility than the versions scetched on by Meadhbh, Carlo and= me > so far. I will adapt the diagram style of Meadhbh and Carlo ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html), since > it's more readable than my text-flow variant. Also, I will leave out > parameter examples since there seem to be a risk people get hooked on if = a > certain parameter should be included or not, rather than the possibility = of > handling any parameter. > > I may be paranoid, but I still prefer agent domains to be > allowed, but not forced by protocol, to reduce the dissemination of > information about their clients as far as possible, and there Carlo's AND > version in the response is a good step forward ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html). We migh= t > even wind up with negotiations where one domain requests the actual value= s > while the other domain only wants to disseminate a reply to if it fits a > range for one or more of the requested parameters. > > AD -------------------------(name, RDkey2?>)------------------------> RD > AD <--(name, agentkey1?, agentkey2?>)--- RD > AD --(name, agentkey2 range?>)-> RD > AD <----------(name, range>)----------- RD > AD ----------------------------(name, agentkey2 > OK)---------------------------> RD > AD <-----------------------------(name, rez > cap)------------------------------- RD > > In this example, RD might have refused giving the required > range for agentvalue2, either because it technically doesn't support that > kind of negotiation or because of policy, in either case of which the rez > cap would have failed. It might on the other hand instead already from th= e > beginning have supplied the required ranges instead of asking for the act= ual > value. I think it would be good if the protocol would enable either of th= ese > cases for maximum flexibility. > > It may also be an idea to permit caching of at least AD- an= d > RD-parameters or evaluations of them, especially if we're talking extensi= ve > sets with perhaps hundreds of parameters. Since the ADs and RDs should be > free to update their own parameters at any time, the handshake in that ca= se > must of course contain a check if cached parameters have been updated. Al= so, > if an AD or RD supports several sets of parameters depending on which dom= ain > or service it deals with, means to distinguish between them are required, > perhaps using policy URI's the way Meadhbh suggested ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html). A polic= y > could then basically be broken down into a set of own parameter values an= d > required parameter ranges for the domain or service connecting. > > I also think, like Meadhbh ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html), that we > will need to suggest, but not require, a number of parameter name and > formats to facilitate communication, so that not e.g. US and UK domains > can't connect, because one asks about "color" and the other one only can > respond about "colour". > > Best regards, > > Magnus > > > - -----Ursprungligt meddelande----- > Fr=E5n: Carlo Wood [mailto:carlo@alinoe.com] > Skickat: den 7 oktober 2009 22:36 > Till: Infinity Linden > Kopia: Magnus Zeisig; ogpx@ietf.org > =C4mne: Re: [ogpx] Protocol for permitting policy decisions > > On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infinity Linden > wrote: > > option 3: multi-message handshake > > > > AD --------------- (name) -------------> RD > > AD <-------- (X, age > X? cap) --------- RD > > > > AD ------------------------------------> RD (age > X? cap= ) > > AD <------------ (rez cap) ------------- RD > > Note, again, the need for a flexible protocol negotiation: > we can't know, already, what all will be needed. > > Nevertheless, the more flexibility the better imho. > I'd prefer to see this: > > AD ------(name, ) -----------> RD > AD <-----(name, ) --- RD > AD ------(name, yes/no)--------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > Where VWRAP will not define what keywords are possible. > > However, implementers might, for example, choose to use 'AG= E' > as keyword > with an integer range, leading to a msg exchange like > > AD ------(name, (AGE)) -----------> RD > AD <-----(name, (AGE, 21)) -------- RD > AD ------(name, yes)--------------> RD > AD <-----(rez cap) ---------------- RD > > or some might implement > > AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD > AD <-----(name, (AGE, 13), YES) ------------------ RD > AD ------(name, yes, yes)------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > For privacy reasons, I think it would suffice to > just send the AND of all 'yes's, thus: > > AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD > AD <-----(name, (AGE, 13), YES) ------------------ RD > AD ------(name, yes)-----------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > or, > > AD ------(name, (AGE, LIKES_BUNNIES)) -----------> RD > AD <-----(name, (AGE, 13), DONTCARE) ------------- RD > AD ------(name, yes)-----------------------------> RD > AD <-----(rez cap) ------------------------------- RD > > Again, neither 'AGE' nor 'LIKES_BUNNIES', would be defined = by > us, > but we would define how to handle integer ranges, booleans, > don't cares, string literals, and perhaps regular > expressions. > > - -- > Carlo Wood > > -----BEGIN PGP SIGNATURE----- > Version: 9.8.3 (Build 4028) > Charset: utf-8 > > > wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF/wu+7FSVzZ2al3nKcL > > JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12EhRynq4rmlSfgs7Ta/ > > cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18ll86EZr0qIqP9ByIbMJ > > RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7qI3XV6sKwuaUOzWzsWm > > tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT0iU25k78Y7bldq/Bnd > 60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38XtAbKieN8w=3D= =3D > =3D2NSu > -----END PGP SIGNATURE----- > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > > > > > > --001636c5a51831ef8f04757883d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Magnus, I believe that we're fairly close on everything except the sing= le issue of "symmetry", because you still think that I'm talk= ing about deployment symmetry whereas I'm not at all, I'm talking a= bout definition symmetry.=A0 However, I think I've found another= way of expressing it that might come across better --- I'll focus on C= ODE.=A0 Let's try this new approach instead. :-)

Protocols aren't much use until they have been encoded in programs.= =A0 A program that implements a given protocol fully is written to be able = to handle all the possible deployment patterns of that protocol.=A0 This al= lows the program to be used in many different situations to suit local requ= irements.=A0 Such a program is NOT written to suit one single= deployment pattern --- that would be inefficient.=A0 Consequently the code= that is written is determined by the definition of the protocol = and the definition of the entities in the protocol.=A0 The code = that is written is NOT determined by the chosen deployment, I= hope that's clear.

So now let's get back to ADs.=A0 We don't want ADs to carry reg= ion policy, but let's examine what happens if ADs are defined to do so.=

=A0If ADs are defined to specify region policy, then a program that= needs to know about region policy would have to check the ADs --- there is= no escaping that.=A0 It would not be protocol-compliant if it did not c= heck the ADs.=A0 The deployment patterns in W1 and W2 (which could be c= ompletely different) are of no relevance whatsoever in this --- the program= would still have to check for the presence of ADs in both worlds ju= st in case the ADs exist, and all those ADs that exist would have to= be queried for region policy because we've defined that region policy = is carried by ADs.=A0 If the program did not check both ADs then it coul= d be missing part of the region policy. :-)

See what I mean by definition symmetry now?=A0 However you define an AD= , that definition always applies to both ADs in a 2-world deployment if the= y exist.=A0 The definition can never apply only to one world --- it should = be clear that "ADs carry region policies, but the region policies i= n my AD are valid while the region policies in your AD will be ignored&= quot; is completely bogus. :-)=A0 In protocol terms, this would be non-comp= liant because part of the region policy would be missed.

As a result of this definitional symmetry, the only way we're going= to be able to avoid consulting AD2 is our little example scenario is by no= t allowing ADs to express region policy at all, because if AD1 is allowed t= o express region policy then AD2 is allowed to express it as well, and henc= e the program must try to consult AD2 for its region policy, by defi= nition of AD.=A0 It's very strong logic, and it has nothing to do with = the chosen deployments, because it applies in case AD2 exists= .

Of course, as you pointed out, there are many more realistic deployment= s out there, but this simple one is all that's needed to invalidate the= idea that AD1 can express region policy while AD2 can be present but ignor= ed.=A0 That cannot happen unless the protocol explicitly defines asymmetric= relationships, which is not true in our case and cannot be true given that= W1 and W2 are peers.

That's all I wanted to describe in this particular reply.=A0 I hope= the point was clearer this time. :-)


Morgaine.



<= br>


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

On Thu, Oct 8, 2009 at 3:41 PM, Magnus Zeisig <magnus.zeisig@iis.se> wrote:=
Morgain, I believe we're not that far off from each other, even if I th= ink the example you presented was not appropriate and I still can see no re= ason for your symmetry in AD/RD requests. The latter notion has already bee= n commented upon by others in more detail. But like you, I also think it= 9;s reasonable to leave or generalize away from the thought of domains and = rather use services as protocol endpoints. Regardless of if we talk about d= omains or services, I think the basic negotiation pattern will always be th= e same:

Client: I want your services but (may) have some (policy) demands to use th= em.
Server/Service: I offer you my services but (may) have some (policy) demand= s to let you use them.

Both client and server/service can be the agent or region domain, user/agen= t, authentication, presence, asset, inventory, simulation, voice or movie s= ervice, or any other domain or service you can think of, standalone or clus= tered in any combinations depending on technical issues, ownership and agre= ements.

So, when any client (C) requests any service from a server/service (S), it = may look like this, if all work out:
C ---(id, service?, S policy?)--> S
C <--(id, S policy, C policy?)--- S
C --(id, S policy OK, C policy)-> S
C <-(id, C policy OK, service)--- S

Policies in this case may refer both to things like data format (mesh forma= t, image format) and data classification (adult, require IP agreements). Th= e acceptance of policies, permitting the service performed, from both C and= S, may be negotiated directly between C and S, or between servers/services= connected to C and S respectively, negotiated at the time of service reque= st and/or stored in some form of access, token or cap, at C and/or S respec= tively, or servers/services connected to them.

If C and S are controlled by the same entity, that entity may use any way, = including VWRAP, to negotiate and deliver the service, and the policy part = may be left out from the negotiation, e.g. because the entity use the same = policy for all services controlled.

If C and S are controlled by different entities, those entities may use any= way, including VWRAP, to negotiate and deliver the service, and the policy= part may be left out from the negotiation, e.g. because the entities have = an already established agreement (format agreement, domain of trust) or don= 't require one.

If the policy negotiation is left out, the request becomes:
C --(id, service?)-> S
C <-(id, service)--- S

To support a flexible new infrastructure with many different domains or ser= vices interacting in many different constellations, including interop betwe= en the "classical" virtual worlds of today, VWRAP should be able = to treat any service request and/or policy negotiation the same or very sim= ilar, regardless of endpoints and endpoint types. The endpoints will mutual= ly decide if to use VWRAP and to which extent. VWRAP should however be an a= ttractive enough way to handle the communication to be a first hand choice,= both between clients and servers/services of the same as well as different= entities. One advantage of using VWRAP will then be that outsourcing, exch= ange or addition of services will be easy, since basically just addresses o= f servers/services will need to be changed and transfer of old data to the = new services be performed.

I know that some of the things above have already been stated on the list, = but I'm repeating them just for the clarity of argumentation.

Best regards,

Magnus


-----Ursprungligt meddelande-----
Fr=E5n: Morgaine [mailto:= morgaine.dinova@googlemail.com]
Skickat: den 8 oktober 2009 14:32
Till: Magnus Zeisig
Kopia: ogpx@ietf.org
=C4mne: Re: [ogpx] Protocol for permitting policy decisions

Magnus, you're mixing up my analysis of what's required for Joshua&= #39;s scheme to work, with my recognition that we need a more flexible appr= oach based not on this restrictive AD+RD split but on the much more flexibl= e decoupled services behind them.

When I speak of AD1+RD1 and AD2+RD2 in the analysis, this is not at all =A0= the actual deployment scenario that any of us expects to see. =A0It's j= ust the smallest case that allows us to say something concrete about the pr= oblems with the original OGP design when extrapolated to the multi-world de= ployment scenario. =A0So please don't attribute any narrow vision in th= is scenario to me --- I'm fully aware that it's artificial and is g= oing almost nowhere. =A0I'm merely doing a smallest-possible scenario a= nalysis.

My personal interest is in the fully expanded and massively scaled deployme= nts which the AWG group in SL was originally formed to consider 2 years ago= (this might give you some idea of the scale --- =A0https://wiki.sec= ondlife.com/wiki/Project_Motivation ) , but there's no point descri= bing a massively complex deployment example when a simpler one suffices to = make a specific point. :-)

So to your post ...

On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeisig <magnus.zeisig@iis.se> wrote:


=A0 =A0 =A0 =A0Morgaine,

=A0 =A0 =A0 =A0No, you are still stuck in the concept of one virtual world= equals one AD plus one RD, even if you say you recognize a future more com= plex service pattern. VW=3DAD+RD does not have to be the case with VWRAP.


I know that it's artificial. =A0We're merely examining this small s= cenario to highlight an elementary problem with distribution of services, a= nd it has already been useful. =A0It has demonstrated that even in this min= iscule example, there need to be (i) asset service contributions from both = worlds in the example, so just a single inventory service in AD1 is not ade= quate, and (ii) that if ADs control region policy then AD2 must be consulte= d as well since it has every bit as much right to determine policy in RD2 a= s does AD1, or more. =A0These are important constraints on the design, desp= ite the deployment example being such a simple one.

In addition to the case shown, there are simpler cases and there are more c= omplex cases.

The simpler cases, such as no AD2 exists, or only W1 asset services are use= d in W2, can be handled by the original OGP design, so they wouldn't ha= ve served the purpose here. =A0More complex cases, such as multiple RDs in = W2, do not add value to the particular point being made, so why complicate = the scenario unnecessarily? =A0We'll certainly need them later, but the= y don't help here.

Obviously multi-world deployment scenarios such as we expect to be common i= n the metaverse are going to have much more complex deployment patterns inv= olved a myriad of concurrent services, but adding that complexity at this p= oint doesn't enhance the present argument.




=A0 =A0 =A0 =A0If it _happens_ to be the case and the entity controlling A= D2 and RD2 wants to enforce AD2 policy for those visiting RD2, then they ca= n move, duplicate or mirror the enforcement of that policy from AD2 to RD2,= which they can do without problems as long as they control both. If they d= on't control both, then it's entirely up to the entity controlling = RD2 if they for some reason want to enforce the policy of the entity contro= lling AD2. So I see no reason whatsoever why symmetry is required.




Ah, here you've simply misunderstood me: =A0you think I'm talking a= bout deployment symmetry, but I'm not. =A0I'm talking about definit= ion symmetry: =A0if ADs are defined to be able to control region policies, = then by symmetry that applies to all ADs. =A0It wouldn't make sense to = say "ADs are defined to carry region policy, but this only applies to = our ADs and not to yours." =A0;-) =A0That's what I mean by this ap= plying symmetrically.


Deployment patterns are of course arbitrary and don't have to be symmet= rical: =A0two interoperating worlds can individually be using any deploymen= t pattern they choose, and one world of the pair will generally have no say= on the deployment pattern used by the other. =A0Across the whole metaverse= , we can expect every single possible deployment pattern to be used by some= one, and for added spice, tourists from every possible deployment could be = visiting some common tourist world to create a kaleidescope of combined dep= loyments in the region.



=A0 =A0 =A0 =A0Policy is not decided and enforced by the AD, the RD or any= service connected with them, it is decided and enforced by the entities be= hind them. If the same entity controls an AD and a RD, then it's meanin= gless to try to divide up that entity's policy into AD policy and RD po= licy, because it can enforce that policy at any level, type of domain or co= nnected service it controls.




Sure, but someone has to code this stuff. =A0It's not helpful to say &q= uot;Anything can be done anywhere", because that would mean that the p= rotocol would at every decision point have to gather policy contributions f= rom all possible endpoints. =A0It can be done this way of course, but if a = simpler design suffices then a more compex one may not be a good idea.

That said, take note of David's advice about policy being best implemen= ted in the services themselves. =A0Domains are not necessarily bad, but the= y do actually restrict our flexibility substantially compared to using deco= upled services alone.



=A0 =A0 =A0 =A0But, like you, I am totally in favor of letting the entity = controlling the destination RD decide policy once the agent is there. Howev= er, if the agent's own AD for some reason wants to stop the agent from = going there, then I think it should have the possibility to do so. In all h= onesty, I don't think an AD imposing undue restrictions on where people= are allowed to go or what they are allowed to do there will survive for lo= ng though, once competition is in place. You may have to start out fresh, w= ith a new AD, without the assets and inventory connected to the old AD, but= I think most people are willing to take that step if they feel their freed= om is too limited.



Well in my case I'm not merely "in favour" of region policy c= ontrol by regions. =A0I don't think it's actually optional in multi= -world deployments, because without Destination Determines Destination Poli= cy there can be no viable multi-world tourism at all, and that's the pr= imary use case with massive popular interest. =A0We wouldn't have much = of a metaverse without it.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



On Thu, Oct 8, 2009 at 11:30 AM, Magnus Zeisig <magnus.zeisig@iis.se> wrote:


=A0 =A0 =A0 =A0Morgaine,

=A0 =A0 =A0 =A0No, you are still stuck in the concept of one virtual world= equals one AD plus one RD, even if you say you recognize a future more com= plex service pattern. VW=3DAD+RD does not have to be the case with VWRAP. I= f it _happens_ to be the case and the entity controlling AD2 and RD2 wants = to enforce AD2 policy for those visiting RD2, then they can move, duplicate= or mirror the enforcement of that policy from AD2 to RD2, which they can d= o without problems as long as they control both. If they don't control = both, then it's entirely up to the entity controlling RD2 if they for s= ome reason want to enforce the policy of the entity controlling AD2. So I s= ee no reason whatsoever why symmetry is required.

=A0 =A0 =A0 =A0Policy is not decided and enforced by the AD, the RD or any= service connected with them, it is decided and enforced by the entities be= hind them. If the same entity controls an AD and a RD, then it's meanin= gless to try to divide up that entity's policy into AD policy and RD po= licy, because it can enforce that policy at any level, type of domain or co= nnected service it controls.

=A0 =A0 =A0 =A0But, like you, I am totally in favor of letting the entity = controlling the destination RD decide policy once the agent is there. Howev= er, if the agent's own AD for some reason wants to stop the agent from = going there, then I think it should have the possibility to do so. In all h= onesty, I don't think an AD imposing undue restrictions on where people= are allowed to go or what they are allowed to do there will survive for lo= ng though, once competition is in place. You may have to start out fresh, w= ith a new AD, without the assets and inventory connected to the old AD, but= I think most people are willing to take that step if they feel their freed= om is too limited.


=A0 =A0 =A0 =A0Best regards,

=A0 =A0 =A0 =A0Magnus


=A0 =A0 =A0 =A0-----Ursprungligt meddelande-----

=A0 =A0 =A0 =A0Fr=E5n: Morgaine [mailto:morgaine.dinova@googlemail.com]
=A0 =A0 =A0 =A0Skickat: den 8 oktober 2009 11:42
=A0 =A0 =A0 =A0Till: Magnus Zeisig
=A0 =A0 =A0 =A0Kopia: ogpx@ietf.org
=A0 =A0 =A0 =A0=C4mne: Re: [ogpx] Protocol for permitting policy decisions=

=A0 =A0 =A0 =A0Magnus,

=A0 =A0 =A0 =A0If ADs are involved in region policy, then in the multi-wor= ld deployment pattern, AD2 will have to be consulted when agent A1 teleport= s from RD1 to RD2, because AD2 will be involved in region policy too. =A0It= 's symmetric with AD1.

=A0 =A0 =A0 =A0This is what Joshua wanted to avoid, and it can only be avo= ided by not giving ADs policy control over regions, otherwise symmetry requ= ires that AD2 be consulted as well.

=A0 =A0 =A0 =A0It's this kind of problem that reinforces what David= 9;s been saying about the right mess we currently have when talking about d= omains determining policy. =A0The AD/RD split was reasonably adequate when = OGP was only extending a single world with policy-free regions, but it is i= nsufficient to do a good job once we get into multi-world deployments with = more complex service and policy patterns which require much more flexibilit= y.


=A0 =A0 =A0 =A0Morgaine.




=A0 =A0 =A0 =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


=A0 =A0 =A0 =A0On Thu, Oct 8, 2009 at 9:48 AM, Magnus Zeisig <magnus.zeisig@iis.se> wrote:



=A0 =A0 =A0 =A0 =A0 =A0 =A0 -----BEGIN PGP SIGNED MESSAGE-----
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Hash: SHA256

=A0 =A0 =A0 =A0 =A0 =A0 =A0 I am strongly in favour of leaving policy desc= isions to the RD, but since there seems to be a need for at least some AD m= anagers to be able to make policy decisions as well, I guess the protocol h= andshake need even more flexibility than the versions scetched on by Meadhb= h, Carlo and me so far. I will adapt the diagram style of Meadhbh and Carlo= (http://www.ietf.org/mail-archive/web/ogpx/current/msg0= 0520.html), since it's more readable than my text-flow variant. Als= o, I will leave out parameter examples since there seem to be a risk people= get hooked on if a certain parameter should be included or not, rather tha= n the possibility of handling any parameter.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 I may be paranoid, but I still prefer agent do= mains to be allowed, but not forced by protocol, to reduce the disseminatio= n of information about their clients as far as possible, and there Carlo= 9;s AND version in the response is a good step forward (= http://www.ietf.org/mail-archive/web/ogpx/current/msg00520.html). We mi= ght even wind up with negotiations where one domain requests the actual val= ues while the other domain only wants to disseminate a reply to if it fits = a range for one or more of the requested parameters.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD -------------------------(name, <RDkey1?= , RDkey2?>)------------------------> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <--(name, <RDvalue1, RDvalue2, ADkey1= ?, ADkey2?, agentkey1?, agentkey2?>)--- RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD --(name, <RDvalues OK, ADvalue1, ADvalue= 2, agentvalue1, agentkey2 range?>)-> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <----------(name, <ADvalues OK, agent= value1 OK, agentkey2 range>)----------- RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD ----------------------------(name, agentkey= 2 OK)---------------------------> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <-----------------------------(name, rez= cap)------------------------------- RD

=A0 =A0 =A0 =A0 =A0 =A0 =A0 In this example, RD might have refused giving = the required range for agentvalue2, either because it technically doesn'= ;t support that kind of negotiation or because of policy, in either case of= which the rez cap would have failed. It might on the other hand instead al= ready from the beginning have supplied the required ranges instead of askin= g for the actual value. I think it would be good if the protocol would enab= le either of these cases for maximum flexibility.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 It may also be an idea to permit caching of at= least AD- and RD-parameters or evaluations of them, especially if we'r= e talking extensive sets with perhaps hundreds of parameters. Since the ADs= and RDs should be free to update their own parameters at any time, the han= dshake in that case must of course contain a check if cached parameters hav= e been updated. Also, if an AD or RD supports several sets of parameters de= pending on which domain or service it deals with, means to distinguish betw= een them are required, perhaps using policy URI's the way Meadhbh sugge= sted (http://www.ietf.org/mail-archive/web/ogpx/current/= msg00523.html). A policy could then basically be broken down into a set= of own parameter values and required parameter ranges for the domain or se= rvice connecting.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 I also think, like Meadhbh (http://www.ietf.org/mail-archive/web/ogpx/current/msg00523.html), that= we will need to suggest, but not require, a number of parameter name and f= ormats to facilitate communication, so that not e.g. US and UK domains can&= #39;t connect, because one asks about "color" and the other one o= nly can respond about "colour".

=A0 =A0 =A0 =A0 =A0 =A0 =A0 Best regards,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 Magnus


=A0 =A0 =A0 =A0 =A0 =A0 =A0 - -----Ursprungligt meddelande-----
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Fr=E5n: Carlo Wood [mailto:carlo@alinoe.com]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Skickat: den 7 oktober 2009 22:36
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Till: Infinity Linden
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Kopia: Magnus Zeisig; ogpx@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =C4mne: Re: [ogpx] Protocol for permitting pol= icy decisions

=A0 =A0 =A0 =A0 =A0 =A0 =A0 On Mon, Oct 05, 2009 at 12:39:32PM -0700, Infi= nity Linden wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > option 3: multi-message handshake
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > AD --------------- (name) -------------&g= t; RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > AD <-------- (X, age > X? cap) ----= ----- RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > AD ------------------------------------&g= t; RD (age > X? cap)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 > AD <------------ (rez cap) -----------= -- RD

=A0 =A0 =A0 =A0 =A0 =A0 =A0 Note, again, the need for a flexible protocol = negotiation:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 we can't know, already, what all will be n= eeded.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 Nevertheless, the more flexibility the better = imho.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 I'd prefer to see this:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD ------(name, <list with keywords>) --= ---------> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <-----(name, <list with keywords + ra= nges>) --- RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD ------(name, yes/no)-----------------------= ---> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <-----(rez cap) ------------------------= ------- RD

=A0 =A0 =A0 =A0 =A0 =A0 =A0 Where VWRAP will not define what keywords are = possible.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 However, implementers might, for example, choo= se to use 'AGE' as keyword
=A0 =A0 =A0 =A0 =A0 =A0 =A0 with an integer range, leading to a msg exchan= ge like

=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD ------(name, (AGE)) -----------> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <-----(name, (AGE, 21)) -------- RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD ------(name, yes)--------------> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <-----(rez cap) ---------------- RD

=A0 =A0 =A0 =A0 =A0 =A0 =A0 or some might implement

=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD ------(name, (AGE, LIKES_BUNNIES)) --------= ---> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <-----(name, (AGE, 13), YES) -----------= ------- RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD ------(name, yes, yes)---------------------= ---> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <-----(rez cap) ------------------------= ------- RD

=A0 =A0 =A0 =A0 =A0 =A0 =A0 For privacy reasons, I think it would suffice = to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 just send the AND of all 'yes's, thus:=

=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD ------(name, (AGE, LIKES_BUNNIES)) --------= ---> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <-----(name, (AGE, 13), YES) -----------= ------- RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD ------(name, yes)--------------------------= ---> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <-----(rez cap) ------------------------= ------- RD

=A0 =A0 =A0 =A0 =A0 =A0 =A0 or,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD ------(name, (AGE, LIKES_BUNNIES)) --------= ---> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <-----(name, (AGE, 13), DONTCARE) ------= ------- RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD ------(name, yes)--------------------------= ---> RD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 AD <-----(rez cap) ------------------------= ------- RD

=A0 =A0 =A0 =A0 =A0 =A0 =A0 Again, neither 'AGE' nor 'LIKES_BU= NNIES', would be defined by us,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 but we would define how to handle integer rang= es, booleans,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 don't cares, string literals, and perhaps = regular expressions.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 - --
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Carlo Wood <carlo@alinoe.com>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 -----BEGIN PGP SIGNATURE-----
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Version: 9.8.3 (Build 4028)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Charset: utf-8

=A0 =A0 =A0 =A0 =A0 =A0 =A0 wsBVAwUBSs2nYe5MlU9XyaiSAQiJLAf/fye7HX0vp2JkZF= /wu+7FSVzZ2al3nKcL
=A0 =A0 =A0 =A0 =A0 =A0 =A0 JiB+Z1mxP3ICiGZrvdIojSCHL5+T8k23cj9Q9ggz7yQv12= EhRynq4rmlSfgs7Ta/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 cKrKh7vvQHsZsnsaiHaw29DA30rejSJWabkZ5c29zUd18l= l86EZr0qIqP9ByIbMJ
=A0 =A0 =A0 =A0 =A0 =A0 =A0 RrppGN98IaYd3rOclzK0/e3LdRKAgLhg1GotudPKJ4vU7q= I3XV6sKwuaUOzWzsWm
=A0 =A0 =A0 =A0 =A0 =A0 =A0 tDpcHxcCHhF9O4uDstGFAxbPVvZNnrmzQXRzlQ6pajmpzT= 0iU25k78Y7bldq/Bnd
=A0 =A0 =A0 =A0 =A0 =A0 =A0 60Ij9GcofockvBuWVUiIDZsxqZG982jnDGz3DQEorg38Xt= AbKieN8w=3D=3D
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D2NSu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 -----END PGP SIGNATURE-----



=A0 =A0 =A0 =A0 =A0 =A0 =A0 ______________________________________________= _
=A0 =A0 =A0 =A0 =A0 =A0 =A0 ogpx mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 ogpx@ietf.org=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/ogpx







--001636c5a51831ef8f04757883d2-- From morgaine.dinova@googlemail.com Thu Oct 8 21:09:09 2009 Return-Path: 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 BB2A43A698B for ; Thu, 8 Oct 2009 21:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 qRMMQEX4OEUt for ; Thu, 8 Oct 2009 21:09:08 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 046A43A68F7 for ; Thu, 8 Oct 2009 21:09:07 -0700 (PDT) Received: by ewy4 with SMTP id 4so290279ewy.37 for ; Thu, 08 Oct 2009 21:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=V10RGJsNw7cFa8+NcWutCKhXMDzfHZzhVfh6erEaMIU=; b=AgExoUFCwSf80OdLWLNtEObJoivef/A0bJTpxKmtABH18Mg/hYlTBuLTcZHB3OvevV 3fH6kAtzT138yPM194v4P+Qu+WcrkTRKxApKZ6eZq0BkyFhb42mJfUl6H0Bx51gFNxL2 86i8oc2OQJL6t3xif9HnvIf4krQ44i5AW9+jo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=GBha2F0OhjCx1ESPf9WmsUTL4N/mstursfEgAD4A4bYEbH6S/KaKuB9JQVs8MxiCEc 8vU2ILgrWq1yaOBlxkechuPrZ76+u5dPJ9yp2yz8nuNl2UnVsc80er9nX40nY2MIC0fP t6iP02IHDVMIH2eiAe36pacVqef5+Sp7sYXeQ= MIME-Version: 1.0 Received: by 10.211.157.7 with SMTP id j7mr2664085ebo.2.1255061448203; Thu, 08 Oct 2009 21:10:48 -0700 (PDT) In-Reply-To: <20091008235638.GE13882@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <20091008235638.GE13882@alinoe.com> Date: Fri, 9 Oct 2009 05:10:48 +0100 Message-ID: From: Morgaine To: "ogpx@ietf.org" Content-Type: multipart/alternative; boundary=00504502cd07ca9e62047578c3df 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 04:09:09 -0000 --00504502cd07ca9e62047578c3df Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood wrote: > > Morgaine, > > I'm pretty sure nobody on this list wants AD2 to be involved in anyway. > Yes, I think that everybody agrees with this, which is why I'm making sure that the implications are understood. I am highlighting this point of logic very strongly so that it is clear to everyone that *if we don't want AD2 to be consulted, then AD1 cannot be allowed to express region policy*. *AT ALL. EVER.* UNDER ANY CIRCUMSTANCES. Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to be consulted, :-) I hope we can end this here with total agreement. :-) I will however be referring back to this point if someone tries to give AD1 the power to set region policy over RD2. If that happens, then we're back to consulting AD2, no alternative, because W2 is not in any way inferior to W1. It's a crucial point, because it establishes *a limit to the power of an AD*. Think of it as a mini Constitution. ;-) Morgaine. =================================== On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood wrote: > On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wrote: > > Magnus, > > > > If ADs are involved in region policy, then in the multi-world deployment > > pattern, AD2 will have to be consulted when agent A1 teleports from RD1 > to RD2, > > because AD2 will be involved in region policy too. It's symmetric with > AD1. > > Morgaine, > > I'm pretty sure nobody on this list wants AD2 to be involved in anyway. > I'm also convinced that there is some misunderstanding involved here, > and it would be good to correct that... > > The following isn't consensus yet, but I feel it's basically the truth, > and written down here as such because at least it is simple: > > In the end there are only services. Services can be grouped as 'domain' > to make clear they are run by the same authority and therefore likely > will have use the same policies, but for the sake of the protocol you > can ignore that. > > There are several types of services, so far we only concentrated on two > types: > > 1) A region (R1, R2, ...) > 2) An authentication service (A1, A2, ...) > > in principle, every service can be run by a different authority and thus > have different policies. > > One user only uses a single authentication service at a time, every other > authentication service is not relevant (for that user). > > If a user wants to teleport from R1 to R2, while using A3, only A3 and R2 > have a say in this. > > The only say that A3 has is true or false: yes or no allow the user to go > to R2. Once the user gets into R2, no policy of A3 matters anymore. > > It makes no sense whatsoever to group A's with R's for the sake of > understanding > or designing the protocol. > > For a teleport decision (or initial connect) only ONE Agent service and ONE > region are involved. > > Almost every policy (of both parties) can be negotiated out of band, > yet some of us (including me) are arguing that we need to keep the > possibility > open for a region to change some abstract policies (based on trusted > information > from the agent service) more real-time. Here trust is needed in both > directions: > the region must trust the agent service to answer it's questions correctly > and the agent service must trust the region not to fool it into allowing > users in that the agent service based on it's own policy doesn't want to > allow in. > > -- > Carlo Wood > --00504502cd07ca9e62047578c3df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <carlo@alinoe.com> wrote:

Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.=


Yes, I think that everybody agrees with this, which is= why I'm making sure that the implications are understood.

I am = highlighting this point of logic very strongly so that it is clear to every= one that if we don't want AD2 to be consulted, then AD1 cannot be al= lowed to express region policy.=A0 AT ALL.=A0 EVER.=A0 UNDER ANY= CIRCUMSTANCES.

Because if AD1 is allowed to, then so is AD2, and hence AD2 will have t= o be consulted, :-)

I hope we can end this here with total agreement= . :-)

I will however be referring back to this point if someone trie= s to give AD1 the power to set region policy over RD2.=A0 If that happens, = then we're back to consulting AD2, no alternative, because W2 is not in= any way inferior to W1.

It's a crucial point, because it establishes a limit to the powe= r of an AD.=A0 Think of it as a mini Constitution. ;-)


Morgaine.








=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D


On Fri, Oct 9, 2009 at 12:5= 6 AM, Carlo Wood <= carlo@alinoe.com> wrote:
On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wrote:
> Magnus,
>
> If ADs are involved in region policy, then in the multi-world deployme= nt
> pattern, AD2 will have to be consulted when agent A1 teleports from RD= 1 to RD2,
> because AD2 will be involved in region policy too. =A0It's symmetr= ic with AD1.

Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.=
I'm also convinced that there is some misunderstanding involved here, and it would be good to correct that...

The following isn't consensus yet, but I feel it's basically the tr= uth,
and written down here as such because at least it is simple:

In the end there are only services. Services can be grouped as 'domain&= #39;
to make clear they are run by the same authority and therefore likely
will have use the same policies, but for the sake of the protocol you
can ignore that.

There are several types of services, so far we only concentrated on two
types:

1) A region (R1, R2, ...)
2) An authentication service (A1, A2, ...)

in principle, every service can be run by a different authority and thus have different policies.

One user only uses a single authentication service at a time, every other authentication service is not relevant (for that user).

If a user wants to teleport from R1 to R2, while using A3, only A3 and R2 have a say in this.

The only say that A3 has is true or false: yes or no allow the user to go to R2. Once the user gets into R2, no policy of A3 matters anymore.

It makes no sense whatsoever to group A's with R's for the sake of = understanding
or designing the protocol.

For a teleport decision (or initial connect) only ONE Agent service and ONE=
region are involved.

Almost every policy (of both parties) can be negotiated out of band,
yet some of us (including me) are arguing that we need to keep the possibil= ity
open for a region to change some abstract policies (based on trusted inform= ation
from the agent service) more real-time. Here trust is needed in both direct= ions:
the region must trust the agent service to answer it's questions correc= tly
and the agent service must trust the region not to fool it into allowing users in that the agent service based on it's own policy doesn't wa= nt to
allow in.

--
Carlo Wood <carlo@alinoe.com>

--00504502cd07ca9e62047578c3df-- From dwl@us.ibm.com Thu Oct 8 21:15:09 2009 Return-Path: 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 AC55728C1B1; Thu, 8 Oct 2009 21:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.72 X-Spam-Level: X-Spam-Status: No, score=-5.72 tagged_above=-999 required=5 tests=[AWL=0.878, BAYES_00=-2.599, 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 lXbqFA23Nss7; Thu, 8 Oct 2009 21:15:08 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 1B83128C1B0; Thu, 8 Oct 2009 21:15:08 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n994LfhQ002705; Fri, 9 Oct 2009 00:21:41 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n994GjuO250318; Fri, 9 Oct 2009 00:16:45 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n994Gi6S029340; Fri, 9 Oct 2009 00:16:44 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n994GipF029335; Fri, 9 Oct 2009 00:16:44 -0400 In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <20091008235638.GE13882@alinoe.com> To: Morgaine MIME-Version: 1.0 X-KeepSent: AF7E773D:828624D6-8525764A:001736F4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Fri, 9 Oct 2009 00:16:44 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/09/2009 00:16:44, Serialize complete at 10/09/2009 00:16:44 Content-Type: multipart/alternative; boundary="=_alternative 001781368525764A_=" Cc: ogpx-bounces@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 04:15:09 -0000 This is a multipart message in MIME format. --=_alternative 001781368525764A_= Content-Type: text/plain; charset="US-ASCII" I actually kind of defy anyone to impose a policy on a separately hosted remote service. Policy is enforced locally, Attempting to make other software components obey a policy you have is pretty much a non starter. You can request they do things, and you can insist they exhibit certain properties when choosing to interact with them, but you get no say in their workings. (Yes, there are systems with remote policy execution engines and such, but they still don't impose the policies on the services which use them, the services chose to invoke them) - David ~ Zha Morgaine Sent by: ogpx-bounces@ietf.org 10/09/2009 12:10 AM To "ogpx@ietf.org" cc Subject Re: [ogpx] Protocol for permitting policy decisions On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood wrote: Morgaine, I'm pretty sure nobody on this list wants AD2 to be involved in anyway. Yes, I think that everybody agrees with this, which is why I'm making sure that the implications are understood. I am highlighting this point of logic very strongly so that it is clear to everyone that if we don't want AD2 to be consulted, then AD1 cannot be allowed to express region policy. AT ALL. EVER. UNDER ANY CIRCUMSTANCES. Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to be consulted, :-) I hope we can end this here with total agreement. :-) I will however be referring back to this point if someone tries to give AD1 the power to set region policy over RD2. If that happens, then we're back to consulting AD2, no alternative, because W2 is not in any way inferior to W1. It's a crucial point, because it establishes a limit to the power of an AD . Think of it as a mini Constitution. ;-) Morgaine. =================================== On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood wrote: On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wrote: > Magnus, > > If ADs are involved in region policy, then in the multi-world deployment > pattern, AD2 will have to be consulted when agent A1 teleports from RD1 to RD2, > because AD2 will be involved in region policy too. It's symmetric with AD1. Morgaine, I'm pretty sure nobody on this list wants AD2 to be involved in anyway. I'm also convinced that there is some misunderstanding involved here, and it would be good to correct that... The following isn't consensus yet, but I feel it's basically the truth, and written down here as such because at least it is simple: In the end there are only services. Services can be grouped as 'domain' to make clear they are run by the same authority and therefore likely will have use the same policies, but for the sake of the protocol you can ignore that. There are several types of services, so far we only concentrated on two types: 1) A region (R1, R2, ...) 2) An authentication service (A1, A2, ...) in principle, every service can be run by a different authority and thus have different policies. One user only uses a single authentication service at a time, every other authentication service is not relevant (for that user). If a user wants to teleport from R1 to R2, while using A3, only A3 and R2 have a say in this. The only say that A3 has is true or false: yes or no allow the user to go to R2. Once the user gets into R2, no policy of A3 matters anymore. It makes no sense whatsoever to group A's with R's for the sake of understanding or designing the protocol. For a teleport decision (or initial connect) only ONE Agent service and ONE region are involved. Almost every policy (of both parties) can be negotiated out of band, yet some of us (including me) are arguing that we need to keep the possibility open for a region to change some abstract policies (based on trusted information from the agent service) more real-time. Here trust is needed in both directions: the region must trust the agent service to answer it's questions correctly and the agent service must trust the region not to fool it into allowing users in that the agent service based on it's own policy doesn't want to allow in. -- Carlo Wood _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 001781368525764A_= Content-Type: text/html; charset="US-ASCII"
I actually kind of defy anyone to impose a policy on a separately hosted remote service. Policy is enforced locally, Attempting to make other software components obey a
policy you have is pretty much a non starter. You can request they do things, and you can insist they exhibit certain properties when choosing to interact with them, but
you get no say in their workings.  (Yes, there are systems with remote policy execution engines and such, but they still don't impose the policies on the services which use
them, the services chose to invoke them)

- David
~ Zha





Morgaine <morgaine.dinova@googlemail.com>
Sent by: ogpx-bounces@ietf.org

10/09/2009 12:10 AM

To
"ogpx@ietf.org" <ogpx@ietf.org>
cc
Subject
Re: [ogpx] Protocol for permitting policy decisions





On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <carlo@alinoe.com> wrote:

Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.


Yes, I think that everybody agrees with this, which is why I'm making sure that the implications are understood.

I am highlighting this point of logic very strongly so that it is clear to everyone that if we don't want AD2 to be consulted, then AD1 cannot be allowed to express region policy.  AT ALL.  EVER.  UNDER ANY CIRCUMSTANCES.

Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to be consulted, :-)

I hope we can end this here with total agreement. :-)

I will however be referring back to this point if someone tries to give AD1 the power to set region policy over RD2.  If that happens, then we're back to consulting AD2, no alternative, because W2 is not in any way inferior to W1.

It's a crucial point, because it establishes a limit to the power of an AD.  Think of it as a mini Constitution. ;-)


Morgaine.








===================================
On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <carlo@alinoe.com> wrote:
On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wrote:
> Magnus,
>
> If ADs are involved in region policy, then in the multi-world deployment
> pattern, AD2 will have to be consulted when agent A1 teleports from RD1 to RD2,
> because AD2 will be involved in region policy too.  It's symmetric with AD1.
Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.
I'm also convinced that there is some misunderstanding involved here,
and it would be good to correct that...

The following isn't consensus yet, but I feel it's basically the truth,
and written down here as such because at least it is simple:

In the end there are only services. Services can be grouped as 'domain'
to make clear they are run by the same authority and therefore likely
will have use the same policies, but for the sake of the protocol you
can ignore that.

There are several types of services, so far we only concentrated on two
types:

1) A region (R1, R2, ...)
2) An authentication service (A1, A2, ...)

in principle, every service can be run by a different authority and thus
have different policies.

One user only uses a single authentication service at a time, every other
authentication service is not relevant (for that user).

If a user wants to teleport from R1 to R2, while using A3, only A3 and R2
have a say in this.

The only say that A3 has is true or false: yes or no allow the user to go
to R2. Once the user gets into R2, no policy of A3 matters anymore.

It makes no sense whatsoever to group A's with R's for the sake of understanding
or designing the protocol.

For a teleport decision (or initial connect) only ONE Agent service and ONE
region are involved.

Almost every policy (of both parties) can be negotiated out of band,
yet some of us (including me) are arguing that we need to keep the possibility
open for a region to change some abstract policies (based on trusted information
from the agent service) more real-time. Here trust is needed in both directions:
the region must trust the agent service to answer it's questions correctly
and the agent service must trust the region not to fool it into allowing
users in that the agent service based on it's own policy doesn't want to
allow in.

--
Carlo Wood <carlo@alinoe.com>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 001781368525764A_=-- From morgaine.dinova@googlemail.com Thu Oct 8 21:26:51 2009 Return-Path: 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 7B41A3A67A3 for ; Thu, 8 Oct 2009 21:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 A-E4uyoQtyPK for ; Thu, 8 Oct 2009 21:26:50 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 909F23A659B for ; Thu, 8 Oct 2009 21:26:49 -0700 (PDT) Received: by ewy4 with SMTP id 4so296820ewy.37 for ; Thu, 08 Oct 2009 21:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pDKxqkl2oDCLvjnQZks6jJmQkvuU4kFZSmNapGzQ6Qw=; b=J48POqiT1YnOr7FAFyS9UA5W+Au6xnmPiXGs1BUMqqnxR4yrIOjX/TxO2X2CnJD3Rp Mt+ma8Ah4sExyXpSuq59ClcCZhINIVMOgTxv4bkYk5YMPdltRNkM53Z5ApNyVn8PxQ4V ORmit+fj230QQi7p44fMyaw1+8hUsAfvaPQ1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NCCzs03gTfoRM1XFGIyZ3Wrv1lfenKaJSQoAqpewwkrbF2Wt0ygDpDkGW2jHtAOmPv TqOmnTYfDnVTyRd9+JqSbYA2mdezPfE1BqW9OcPu04Rvm6fN4pOap8pfMjiHv8MnwXrd WcR1/RsRUo3XXWpB88PXqORR/6QJTetk7dxR0= MIME-Version: 1.0 Received: by 10.211.174.13 with SMTP id b13mr2592839ebp.73.1255062510112; Thu, 08 Oct 2009 21:28:30 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> Date: Fri, 9 Oct 2009 05:28:29 +0100 Message-ID: From: Morgaine To: Joshua Bell Content-Type: multipart/alternative; boundary=00504502c6fb1613320475790337 Cc: ogpx 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 04:26:51 -0000 --00504502c6fb1613320475790337 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 8, 2009 at 5:45 PM, Joshua Bell wrote: On Wed, Oct 7, 2009 at 8:34 PM, Morgaine wrote: Are we trying to create an interop protocol here, or a protocol for preventing interop? > > :) Honestly, I was trying to riff on the thread (AD and RD sharing > information about agents to make policy decisions), rather than propose > anything. I think an attempt to define a global set of characteristics about > users that enable all policy decisions is hopeless - cultures, laws, and > individuals are too varied and rich. That leaves pair-wise negotiation > and/or trust networks, which IMHO needs to happen *if* there are to be > service-level distinctions for most cases anyway. > Don't worry, I was slightly chuckling as I wrote that --- it was more despondancy than objection. ;-) I do of course fully agree that everyone should be able to choose whatever policy they want. The only thing that worries me is that we are spending an inordinate amount of time examining how to deny interop, and almost no time on how to achieve it. I hope that this is a passing phase, and that we're about to embark on detailed discussion about how avatars, assets, objects and everything else actually move between regions spread across many worlds, as this is the end goal. Blocking interop has already been achieved *perfectly*, by not having the worlds connected. It's time to look at the opposite. :-) Morgaine. ======================================== On Thu, Oct 8, 2009 at 5:45 PM, Joshua Bell wrote: > On Wed, Oct 7, 2009 at 8:34 PM, Morgaine wrote: > >> >> That's a great description of the ultimate interop dystopia in which, >> through definition of arbitrary set membership criteria by an arbitrary >> number of policy makers, the result of transitive policy transference and >> policy intersection is that the set of visitable worlds is the empty set. >> >> Are we trying to create an interop protocol here, or a protocol for >> preventing interop? >> > > :) Honestly, I was trying to riff on the thread (AD and RD sharing > information about agents to make policy decisions), rather than propose > anything. I think an attempt to define a global set of characteristics about > users that enable all policy decisions is hopeless - cultures, laws, and > individuals are too varied and rich. That leaves pair-wise negotiation > and/or trust networks, which IMHO needs to happen *if* there are to be > service-level distinctions for most cases anyway. > > What I forgot to say is: on the Web, as you move between sites you accept > various terms of service. Attempts to have your browser automatically > negotiate with sites over content have been extremely limited - things like > the defunct PICS (you tell your browser to allow a third party site to rate > the site you intend to visit), or Google's features which block > malware/phishing sites (and I believe are used by current browsers as well > when you just type a URL). Your user-agent (Web browser) does *not* have a > built-in lawyer that agrees to a TOS on your behalf, however. (I'm having > flashbacks of "Diamond Age" here - is that the right novel?) > > In the VWRAP space, I don't believe your VW agent domain will be capable of > doing that in a totally generalized, automated way either... so either it > will have some a priori knowledge of the RD via some manner (pair-wise > negotiation, trust network, etc), defer to the user to accept the TOS, or > simply block access. > > In other words: "Just like the web, except where it's different" once > again. > > I'm leaning ever more strongly towards David's position that only services >> should carry expressions of policy, not domains, because in the direction in >> which this discussion is heading there will be no widespread interop at all. >> > > I need to re-read Meadhbh's drafts to internalize the formal terminology > (yeah, my bad), but in my head a "domain" is a deployment model for a set of > conceptually related services, but it's the service end-points that exist at > the protocol level. We talk about domains as clusters of conceptually > related services as a crutch so we don't have to enumerate the specific > services in each conversation. > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00504502c6fb1613320475790337 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 8, 2009 at 5:45 PM, Joshua Bell <josh@lindenlab.com> wrote:
=
On Wed, Oct 7, 2009 at 8:34 PM, Morgaine = <morgaine.dinova@googlemail.com> wrote:
Are we trying to create an interop protocol here, or a protocol for prevent= ing interop?
=A0
:) Honestly, I was trying to riff on the thread (AD and RD sharing information about agents to make policy decisions), rather than propose anything. I think an attempt to define a global set of characteristics about users that enable all policy decisions is hopeless - cultures, laws, and individuals are too varied and rich. That leaves pair-wise negotiation and/or trust networks, which IMHO needs to happen *if* there are to be service-level distinctions for most cases anyway.


Don't worry, I was slightly chuckling as I wrote= that --- it was more despondancy than objection. ;-)=A0=A0 I do of course = fully agree that everyone should be able to choose whatever policy they wan= t.=A0 The only thing that worries me is that we are spending an inordinate = amount of time examining how to deny interop, and almost no time on how to = achieve it.

I hope that this is a passing phase, and that we're about to embark= on detailed discussion about how avatars, assets, objects and everything e= lse actually move between regions spread across many worlds, as this is the= end goal.=A0 Blocking interop has already been achieved perfectly, = by not having the worlds connected.=A0 It's time to look at the opposit= e. :-)


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

On Thu, Oct 8, 2009 at 5:45 PM,= Joshua Bell <jo= sh@lindenlab.com> wrote:
On Wed, Oct 7, 2009 at 8:34 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:

That's a great description of the ultimate interop dysto= pia in which, through definition of arbitrary set membership criteria by an= arbitrary number of policy makers, the result of transitive policy transfe= rence and policy intersection is that the set of visitable worlds is the em= pty set.

Are we trying to create an interop protocol here, or a protocol for pre= venting interop?

:) Honestly, I was trying t= o riff on the thread (AD and RD sharing information about agents to make po= licy decisions), rather than propose anything. I think an attempt to define= a global set of characteristics about users that enable all policy decisio= ns is hopeless - cultures, laws, and individuals are too varied and rich. T= hat leaves pair-wise negotiation and/or trust networks, which IMHO needs to= happen *if* there are to be service-level distinctions for most cases anyw= ay.

What I forgot to say is: on the Web, as you move between sites you acce= pt various terms of service. Attempts to have your browser automatically ne= gotiate with sites over content have been extremely limited - things like t= he defunct PICS (you tell your browser to allow a third party site to rate = the site you intend to visit), or Google's features which block malware= /phishing sites (and I believe are used by current browsers as well when yo= u just type a URL). Your user-agent (Web browser) does *not* have a built-i= n lawyer that agrees to a TOS on your behalf, however. (I'm having flas= hbacks of "Diamond Age" here - is that the right novel?)

In the VWRAP space, I don't believe your VW agent domain will be ca= pable of doing that in a totally generalized, automated way either... so ei= ther it will have some a priori knowledge of the RD via some manner (pair-w= ise negotiation, trust network, etc), defer to the user to accept the TOS, = or simply block access.

In other words: "Just like the web, except where it's differen= t" once again.

I'm leaning ever more strongly towards David's position that only s= ervices should carry expressions of policy, not domains, because in the dir= ection in which this discussion is heading there will be no widespread inte= rop at all.

I need to re-read Meadhbh's drafts to inte= rnalize the formal terminology (yeah, my bad), but in my head a "domai= n" is a deployment model for a set of conceptually related services, b= ut it's the service end-points that exist at the protocol level. We tal= k about domains as clusters of conceptually related services as a crutch so= we don't have to enumerate the specific services in each conversation.=




_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00504502c6fb1613320475790337-- From morgaine.dinova@googlemail.com Thu Oct 8 21:41:21 2009 Return-Path: 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 54EAF3A6403 for ; Thu, 8 Oct 2009 21:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.582 X-Spam-Level: X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 BBu7CXRXBZA7 for ; Thu, 8 Oct 2009 21:41:19 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id DADFD3A635F for ; Thu, 8 Oct 2009 21:41:18 -0700 (PDT) Received: by ewy4 with SMTP id 4so301911ewy.37 for ; Thu, 08 Oct 2009 21:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Fa4/w0ZfE0p37fKpNQDhozabGTmVrV636lVPeuoF5rk=; b=SrFf+1Gizjs1E0QNGkJOyKqbUUd44Qmr84GuGe7XyjU8VKXITtaf7Y/LN8DIFc37Ja AxX21hZE2zlW1x0JthxwVCdwjMAKCecfNxW1bdOeuE/HaMpH5w7cf7Ge6DPm+CqMoSJM ubiEY3kX0NFzX7gV3hacNiQkVr6aRe/Oaudgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iS4rL8L6/EzBnB0R4Cl8LiiPqg/BQudYoGwzcsiTZaDgwFDQ+zcTxq2avYp8Ma3Ftq pply8xFUeH+l/JFxqKWmHpXCINSW6giCl23UQnyzv7tc9tv/pOz1iZNo705rmdVrFn+z x9rku4Hdy9TAZVNJ1nU7ckAara2Vrg9FU/h3U= MIME-Version: 1.0 Received: by 10.210.2.19 with SMTP id 19mr2555365ebb.94.1255063380323; Thu, 08 Oct 2009 21:43:00 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <20091008235638.GE13882@alinoe.com> Date: Fri, 9 Oct 2009 05:43:00 +0100 Message-ID: From: Morgaine To: David W Levine Content-Type: multipart/alternative; boundary=000e0cdff6f6f46d49047579368f Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 04:41:21 -0000 --000e0cdff6f6f46d49047579368f Content-Type: text/plain; charset=ISO-8859-1 A big +1, David! And yet, despite knowing that non-local policy enforcement is a fiction because it's *services* that express policy, I still see people attached to the delusion that a safe, protected environment will be achieved through some kind of transitive or viral contagion of local policy to create a widespread non-local policy, as if domains spread policy by contact. The implication permeates this thread, and we're going to have to examine it in detail to see who is right. Morgaine. ===================================== On Fri, Oct 9, 2009 at 5:16 AM, David W Levine wrote: > > I actually kind of defy anyone to impose a policy on a separately hosted > remote service. Policy is enforced locally, Attempting to make other > software components obey a > policy you have is pretty much a non starter. You can request they do > things, and you can insist they exhibit certain properties when choosing to > interact with them, but > you get no say in their workings. (Yes, there are systems with remote > policy execution engines and such, but they still don't impose the policies > on the services which use > them, the services chose to invoke them) > > - David > ~ Zha > > > > > > *Morgaine * > Sent by: ogpx-bounces@ietf.org > > 10/09/2009 12:10 AM > To > "ogpx@ietf.org" > cc > Subject > Re: [ogpx] Protocol for permitting policy decisions > > > > > On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <*carlo@alinoe.com*> > wrote: > > Morgaine, > > I'm pretty sure nobody on this list wants AD2 to be involved in anyway. > > > Yes, I think that everybody agrees with this, which is why I'm making sure > that the implications are understood. > > I am highlighting this point of logic very strongly so that it is clear to > everyone that *if we don't want AD2 to be consulted, then AD1 cannot be > allowed to express region policy*. *AT ALL. EVER.* UNDER ANY > CIRCUMSTANCES. > > Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to be > consulted, :-) > > I hope we can end this here with total agreement. :-) > > I will however be referring back to this point if someone tries to give AD1 > the power to set region policy over RD2. If that happens, then we're back > to consulting AD2, no alternative, because W2 is not in any way inferior to > W1. > > It's a crucial point, because it establishes *a limit to the power of an > AD*. Think of it as a mini Constitution. ;-) > > > Morgaine. > > > > > > > > > =================================== > > > On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <*carlo@alinoe.com*> > wrote: > On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wrote: > > Magnus, > > > > If ADs are involved in region policy, then in the multi-world deployment > > pattern, AD2 will have to be consulted when agent A1 teleports from RD1 > to RD2, > > because AD2 will be involved in region policy too. It's symmetric with > AD1. > > Morgaine, > > I'm pretty sure nobody on this list wants AD2 to be involved in anyway. > I'm also convinced that there is some misunderstanding involved here, > and it would be good to correct that... > > The following isn't consensus yet, but I feel it's basically the truth, > and written down here as such because at least it is simple: > > In the end there are only services. Services can be grouped as 'domain' > to make clear they are run by the same authority and therefore likely > will have use the same policies, but for the sake of the protocol you > can ignore that. > > There are several types of services, so far we only concentrated on two > types: > > 1) A region (R1, R2, ...) > 2) An authentication service (A1, A2, ...) > > in principle, every service can be run by a different authority and thus > have different policies. > > One user only uses a single authentication service at a time, every other > authentication service is not relevant (for that user). > > If a user wants to teleport from R1 to R2, while using A3, only A3 and R2 > have a say in this. > > The only say that A3 has is true or false: yes or no allow the user to go > to R2. Once the user gets into R2, no policy of A3 matters anymore. > > It makes no sense whatsoever to group A's with R's for the sake of > understanding > or designing the protocol. > > For a teleport decision (or initial connect) only ONE Agent service and ONE > region are involved. > > Almost every policy (of both parties) can be negotiated out of band, > yet some of us (including me) are arguing that we need to keep the > possibility > open for a region to change some abstract policies (based on trusted > information > from the agent service) more real-time. Here trust is needed in both > directions: > the region must trust the agent service to answer it's questions correctly > and the agent service must trust the region not to fool it into allowing > users in that the agent service based on it's own policy doesn't want to > allow in. > > -- > Carlo Wood <*carlo@alinoe.com* > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --000e0cdff6f6f46d49047579368f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A big +1, David!

And yet, despite knowing that non-local policy enfo= rcement is a fiction because it's services that express policy, = I still see people attached to the delusion that a safe, protected environm= ent will be achieved through some kind of transitive or viral contagion of = local policy to create a widespread non-local policy, as if domains spread = policy by contact.

The implication permeates this thread, and we're going to have to e= xamine it in detail to see who is right.


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Fri, Oct 9, 2009 at 5:16 AM, David W Levine <dwl@us.ibm.com> wrote:

I actually kind of defy anyone to = impose a policy on a separately hosted remote service. Policy is enforced locally, Attempting to make other software components obey a
policy you have is pretty much a n= on starter. You can request they do things, and you can insist they exhibit certain properties when choosing to interact with them, but
you get no say in their workings. = =A0(Yes, there are systems with remote policy execution engines and such, but they still don't impose the policies on the services which use
them, the services chose to invoke= them)

- David
~ Zha





Morgaine <morgaine.dinova@googlemail.com>
Sent by: <= a href=3D"mailto:ogpx-bounces@ietf.org" target=3D"_blank">ogpx-bounces@ietf= .org

10/09/2009 12:10 AM

To
"ogpx@ietf.org" <<= a href=3D"mailto:ogpx@ietf.org" target=3D"_blank">ogpx@ietf.org>
cc
Subject
Re: [ogpx] Protocol for= permitting policy decisions





On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <carlo@alinoe.com> wrote:

Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.=


Yes, I think that everybody agrees with this, which is why I'm making s= ure that the implications are understood.

I am highlighting this point of logic very strongly so that it is clear to everyone that if we don't want AD2 to be consulted, then AD1 cann= ot be allowed to express region policy.=A0 AT ALL.=A0 EVER.=A0 UNDER ANY CIRCUMSTANCES.

Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to be consulted, :-)

I hope we can end this here with total agreement. :-)

I will however be referring back to this point if someone tries to give AD1 the power to set region policy over RD2.=A0 If that happens, then we're back to consulting AD2, no alternative, because W2 is not in any way inferior to W1.

It's a crucial point, because it establishes a limit to the power of an AD.=A0 Think of it as a mini Constitution. ;-)


Morgaine.








=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <carlo@alinoe.com> wrote:
On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wro= te:
> Magnus,
>
> If ADs are involved in region policy, then in the multi-world deployme= nt
> pattern, AD2 will have to be consulted when agent A1 teleports from RD1 to RD2,
> because AD2 will be involved in region policy too. =A0It's symmetr= ic with AD1.
Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.=
I'm also convinced that there is some misunderstanding involved here, and it would be good to correct that...

The following isn't consensus yet, but I feel it's basically the tr= uth,
and written down here as such because at least it is simple:

In the end there are only services. Services can be grouped as 'domain&= #39;
to make clear they are run by the same authority and therefore likely
will have use the same policies, but for the sake of the protocol you
can ignore that.

There are several types of services, so far we only concentrated on two
types:

1) A region (R1, R2, ...)
2) An authentication service (A1, A2, ...)

in principle, every service can be run by a different authority and thus have different policies.

One user only uses a single authentication service at a time, every other authentication service is not relevant (for that user).

If a user wants to teleport from R1 to R2, while using A3, only A3 and R2
have a say in this.

The only say that A3 has is true or false: yes or no allow the user to go
to R2. Once the user gets into R2, no policy of A3 matters anymore.

It makes no sense whatsoever to group A's with R's for the sake of = understanding
or designing the protocol.

For a teleport decision (or initial connect) only ONE Agent service and ONE
region are involved.

Almost every policy (of both parties) can be negotiated out of band,
yet some of us (including me) are arguing that we need to keep the possibil= ity
open for a region to change some abstract policies (based on trusted inform= ation
from the agent service) more real-time. Here trust is needed in both direct= ions:
the region must trust the agent service to answer it's questions correc= tly
and the agent service must trust the region not to fool it into allowing users in that the agent service based on it's own policy doesn't wa= nt to
allow in.

--
Carlo Wood <carlo@alinoe.com>
____= ___________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx=


--000e0cdff6f6f46d49047579368f-- From vaughn.deluca@gmail.com Fri Oct 9 01:47:13 2009 Return-Path: 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 E05DF28C108; Fri, 9 Oct 2009 01:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 BNXZ1BOFyfIa; Fri, 9 Oct 2009 01:47:12 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id B71D528C0E9; Fri, 9 Oct 2009 01:47:11 -0700 (PDT) Received: by bwz6 with SMTP id 6so1409151bwz.37 for ; Fri, 09 Oct 2009 01:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=4NsP7d+rFUnGM/xZLu1Fzb23j/Cy8eNjL8USZNDswxM=; b=LdbU1emVhUGwAOKMWWNyJafHLZ6/I7P1uPLNnzPBDZYf6u8EgWfs1xx8EYqJiwqz0P SrbI+O1vA+i8ddc+bSCFwtqkFOkeul/ZK9FlwgfkXlszep+Yyt/+WxemBbY/zL0h+o2A CE3dohCXS+BogSzx5ux6aPCPmmdZAOx/V+9lo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Rq7Y6VWuH1lv+hTT4HXwcaVPCadkkDtTHLqIG2YSNNsvz2DOUG2omlEPRPYxLQGz7t DjfdhVp82bUnFB+ETnL6SNunXvdPnUxk2iyV3HbAlGTi0xUzvkV9i15Okkf4Y9sV6gPc fxX70egb0IGNLftjs3uv+bT9kKUhz2LKWVX7Q= MIME-Version: 1.0 Received: by 10.204.20.142 with SMTP id f14mr1977709bkb.64.1255078132562; Fri, 09 Oct 2009 01:48:52 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <20091008235638.GE13882@alinoe.com> Date: Fri, 9 Oct 2009 10:48:52 +0200 Message-ID: <9b8a8de40910090148m5e3361c5v243aa7758de59af7@mail.gmail.com> From: Vaughn Deluca To: David W Levine Content-Type: multipart/alternative; boundary=00032555505a41bace04757ca67d Cc: ogpx-bounces@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 08:47:14 -0000 --00032555505a41bace04757ca67d Content-Type: text/plain; charset=ISO-8859-1 Yes, this all sounds good!-Vaughn On Fri, Oct 9, 2009 at 6:16 AM, David W Levine wrote: > > I actually kind of defy anyone to impose a policy on a separately hosted > remote service. Policy is enforced locally, Attempting to make other > software components obey a > policy you have is pretty much a non starter. You can request they do > things, and you can insist they exhibit certain properties when choosing to > interact with them, but > you get no say in their workings. (Yes, there are systems with remote > policy execution engines and such, but they still don't impose the policies > on the services which use > them, the services chose to invoke them) > > - David > ~ Zha > > > > > > *Morgaine * > Sent by: ogpx-bounces@ietf.org > > 10/09/2009 12:10 AM > To > "ogpx@ietf.org" > cc > Subject > Re: [ogpx] Protocol for permitting policy decisions > > > > > On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <*carlo@alinoe.com*> > wrote: > > Morgaine, > > I'm pretty sure nobody on this list wants AD2 to be involved in anyway. > > > Yes, I think that everybody agrees with this, which is why I'm making sure > that the implications are understood. > > I am highlighting this point of logic very strongly so that it is clear to > everyone that *if we don't want AD2 to be consulted, then AD1 cannot be > allowed to express region policy*. *AT ALL. EVER.* UNDER ANY > CIRCUMSTANCES. > > Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to be > consulted, :-) > > I hope we can end this here with total agreement. :-) > > I will however be referring back to this point if someone tries to give AD1 > the power to set region policy over RD2. If that happens, then we're back > to consulting AD2, no alternative, because W2 is not in any way inferior to > W1. > > It's a crucial point, because it establishes *a limit to the power of an > AD*. Think of it as a mini Constitution. ;-) > > > Morgaine. > > > > > > > > > =================================== > > > On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <*carlo@alinoe.com*> > wrote: > On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wrote: > > Magnus, > > > > If ADs are involved in region policy, then in the multi-world deployment > > pattern, AD2 will have to be consulted when agent A1 teleports from RD1 > to RD2, > > because AD2 will be involved in region policy too. It's symmetric with > AD1. > > Morgaine, > > I'm pretty sure nobody on this list wants AD2 to be involved in anyway. > I'm also convinced that there is some misunderstanding involved here, > and it would be good to correct that... > > The following isn't consensus yet, but I feel it's basically the truth, > and written down here as such because at least it is simple: > > In the end there are only services. Services can be grouped as 'domain' > to make clear they are run by the same authority and therefore likely > will have use the same policies, but for the sake of the protocol you > can ignore that. > > There are several types of services, so far we only concentrated on two > types: > > 1) A region (R1, R2, ...) > 2) An authentication service (A1, A2, ...) > > in principle, every service can be run by a different authority and thus > have different policies. > > One user only uses a single authentication service at a time, every other > authentication service is not relevant (for that user). > > If a user wants to teleport from R1 to R2, while using A3, only A3 and R2 > have a say in this. > > The only say that A3 has is true or false: yes or no allow the user to go > to R2. Once the user gets into R2, no policy of A3 matters anymore. > > It makes no sense whatsoever to group A's with R's for the sake of > understanding > or designing the protocol. > > For a teleport decision (or initial connect) only ONE Agent service and ONE > region are involved. > > Almost every policy (of both parties) can be negotiated out of band, > yet some of us (including me) are arguing that we need to keep the > possibility > open for a region to change some abstract policies (based on trusted > information > from the agent service) more real-time. Here trust is needed in both > directions: > the region must trust the agent service to answer it's questions correctly > and the agent service must trust the region not to fool it into allowing > users in that the agent service based on it's own policy doesn't want to > allow in. > > -- > Carlo Wood <*carlo@alinoe.com* > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00032555505a41bace04757ca67d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, this all sounds good!
-Vaughn


On Fri, Oct 9, 2009 at 6:16 AM, David W Levine <dwl@us.ibm.com> wrote:

I actually kind of defy anyone to = impose a policy on a separately hosted remote service. Policy is enforced locally, Attempting to make other software components obey a
policy you have is pretty much a n= on starter. You can request they do things, and you can insist they exhibit certain properties when choosing to interact with them, but
you get no say in their workings. = =A0(Yes, there are systems with remote policy execution engines and such, but they still don't impose the policies on the services which use
them, the services chose to invoke= them)

- David
~ Zha





Morgaine <morgaine.dinova@googlemail.com>
Sent by: <= a href=3D"mailto:ogpx-bounces@ietf.org" target=3D"_blank">ogpx-bounces@ietf= .org

10/09/2009 12:10 AM

To
"ogpx@ietf.org" <<= a href=3D"mailto:ogpx@ietf.org" target=3D"_blank">ogpx@ietf.org>
cc
Subject
Re: [ogpx] Protocol for= permitting policy decisions





On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <carlo@alinoe.com> wrote:

Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.=


Yes, I think that everybody agrees with this, which is why I'm making s= ure that the implications are understood.

I am highlighting this point of logic very strongly so that it is clear to everyone that if we don't want AD2 to be consulted, then AD1 cann= ot be allowed to express region policy.=A0 AT ALL.=A0 EVER.=A0 UNDER ANY CIRCUMSTANCES.

Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to be consulted, :-)

I hope we can end this here with total agreement. :-)

I will however be referring back to this point if someone tries to give AD1 the power to set region policy over RD2.=A0 If that happens, then we're back to consulting AD2, no alternative, because W2 is not in any way inferior to W1.

It's a crucial point, because it establishes a limit to the power of an AD.=A0 Think of it as a mini Constitution. ;-)


Morgaine.








=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <carlo@alinoe.com> wrote:
On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wro= te:
> Magnus,
>
> If ADs are involved in region policy, then in the multi-world deployme= nt
> pattern, AD2 will have to be consulted when agent A1 teleports from RD1 to RD2,
> because AD2 will be involved in region policy too. =A0It's symmetr= ic with AD1.
Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.=
I'm also convinced that there is some misunderstanding involved here, and it would be good to correct that...

The following isn't consensus yet, but I feel it's basically the tr= uth,
and written down here as such because at least it is simple:

In the end there are only services. Services can be grouped as 'domain&= #39;
to make clear they are run by the same authority and therefore likely
will have use the same policies, but for the sake of the protocol you
can ignore that.

There are several types of services, so far we only concentrated on two
types:

1) A region (R1, R2, ...)
2) An authentication service (A1, A2, ...)

in principle, every service can be run by a different authority and thus have different policies.

One user only uses a single authentication service at a time, every other authentication service is not relevant (for that user).

If a user wants to teleport from R1 to R2, while using A3, only A3 and R2
have a say in this.

The only say that A3 has is true or false: yes or no allow the user to go
to R2. Once the user gets into R2, no policy of A3 matters anymore.

It makes no sense whatsoever to group A's with R's for the sake of = understanding
or designing the protocol.

For a teleport decision (or initial connect) only ONE Agent service and ONE
region are involved.

Almost every policy (of both parties) can be negotiated out of band,
yet some of us (including me) are arguing that we need to keep the possibil= ity
open for a region to change some abstract policies (based on trusted inform= ation
from the agent service) more real-time. Here trust is needed in both direct= ions:
the region must trust the agent service to answer it's questions correc= tly
and the agent service must trust the region not to fool it into allowing users in that the agent service based on it's own policy doesn't wa= nt to
allow in.

--
Carlo Wood <carlo@alinoe.com>
____= ___________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx=


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00032555505a41bace04757ca67d-- From magnus.zeisig@iis.se Fri Oct 9 02:59:25 2009 Return-Path: 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 E31DE3A682F for ; Fri, 9 Oct 2009 02:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.636 X-Spam-Level: X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, TRACKER_ID=2.003] 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 WSGMMl1qjxhm for ; Fri, 9 Oct 2009 02:59:24 -0700 (PDT) Received: from cleaner.prod.iis.se (cleaner.prod.iis.se [212.247.7.212]) by core3.amsl.com (Postfix) with ESMTP id 505033A67AA for ; Fri, 9 Oct 2009 02:59:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cleaner.prod.iis.se (Postfix) with ESMTP id D2F9EA8009; Fri, 9 Oct 2009 10:01:05 +0000 (UTC) Received: from cleaner.prod.iis.se ([127.0.0.1]) by localhost (cleaner.prod.iis.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14535-03; Fri, 9 Oct 2009 10:00:49 +0000 (UTC) Received: from pgpkeys.office.nic.se (pgpkeys.office.nic.se [212.247.204.14]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cleaner.prod.iis.se (Postfix) with ESMTP id D80EAA8004; Fri, 9 Oct 2009 10:00:49 +0000 (UTC) Received: from EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) by pgpkeys.office.nic.se (PGP Universal service); Fri, 09 Oct 2009 12:00:49 +0200 X-PGP-Universal: processed; by pgpkeys.office.nic.se on Fri, 09 Oct 2009 12:00:49 +0200 Received: from Exchange2k7.office.nic.se ([169.254.1.222]) by EXCH2K7HUB-RV.office.nic.se ([212.247.204.21]) with mapi; Fri, 9 Oct 2009 12:00:49 +0200 From: Magnus Zeisig To: Morgaine Date: Fri, 9 Oct 2009 12:00:48 +0200 Thread-Topic: [ogpx] Protocol for permitting policy decisions Thread-Index: AcpIlAZI57GSqqdISxC39zK1yec5JAAMv7/Q Message-ID: <983F17705339E24699AA251B458249B50CC48CB8CD@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B50CC48CB6E2@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B50CC48CB7BF@EXCHANGE2K7.office.nic.se> In-Reply-To: Accept-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-pgp-encoding-version: 2.0.2 x-pgp-mapi-encoding-version: 2.5.0 x-pgp-encoding-format: Partitioned x-pgp-universal-saved-content-codepage: utf-8 acceptlanguage: sv-SE MIME-Version: 1.0 Content-Language: sv-SE Content-Type: multipart/alternative; boundary="_000_983F17705339E24699AA251B458249B50CC48CB8CDEXCHANGE2K7of_" X-Virus-Scanned: Debian amavisd-new at cleaner.prod.iis.se Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 09:59:26 -0000 --_000_983F17705339E24699AA251B458249B50CC48CB8CDEXCHANGE2K7of_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCk1vcmdh aW5lLCBJIHRoaW5rIEkgdW5kZXJzdG9vZCB5b3VyIG1lYW5pbmcgd2l0aCB0aGUgZmlyc3QgZXhh bXBsZSwgYW5kIEkgYWxzbyB0aGluayBJIGRvIGl0IHdpdGggdGhlIHNlY29uZCBleGFtcGxlLiBB bmQgSSBzdGlsbCBzZWUgbm8gcmVxdWlyZW1lbnQgZm9yIHlvdXIgc3ltbWV0cnksIG9yIHdoYXRl dmVyIHlvdSBwcmVmZXIgdG8gY2FsbCBpdC4gTGV0J3MgcmVjYXBpdHVsYXRlIHNvIHBlb3BsZSBk b24ndCBuZWVkIHRvIGJyb3dzZSBiYWNrLiBBbiBhZ2VudCB1c2luZyBBRDEgd2FudHMgdG8gdGVs ZXBvcnQgKFRQKSBmcm9tIFZXMSwgY29uc2lzdGluZyBvZiBBRDEgYW5kIFJEMSwgdG8gVlcyLCBj b25zaXN0aW5nIG9mIEFEMiBhbmQgUkQyLg0KDQpGb3IgdGhlIFRQIHRvIGhhcHBlbiwgQUQxIG5l ZWRzIHRvIGFncmVlIHRvIHRyeSB0aGUgVFAgYmVjYXVzZSBpdCdzIHVzZWQgYnkgdGhlIGFnZW50 LiBSRDIgbmVlZHMgdG8gYWNjZXB0IHRoZSBUUCBiZWNhdXNlIGl0IHdpbGwgaGFuZGxlIHRoZSBh Z2VudCdzIHByZXNlbmNlLiBSRDEgc2hvdWxkIGhhdmUgbm8gc2F5IHNpbmNlIGl0IHdpbGwgbm90 IGJlIHVzZWQgYnkgb3IgaGFuZGxlIHRoZSBhZ2VudC4gQUQyIHNob3VsZCBoYXZlIG5vIHNheSBz aW5jZSBpdCB3aWxsIG5vdCBiZSB1c2VkIGJ5IG9yIGhhbmRsZSB0aGUgYWdlbnQuIFRoYXQncyBt eSBpZGVhIG9mIHBlcmZlY3Qgc3ltbWV0cnksIGJ1dC4uLg0KDQpBc3N1bWUgdGhhdCBBRDEgb3Ig UkQyIGZvciB0aGUgcmVhc29uIG9mICJzeW1tZXRyeSIsIG9yIHNvbWV0aGluZyBlbHNlLCB3YW50 cyBBRDIgdG8gaGF2ZSBhIHNheSBhYm91dCB0aGUgVFAuIFNpbmNlIEFEMSBhbmQgUkQyIGFyZSB0 aGUgb25seSBlbnRpdGllcyBpbnZvbHZlZCB3aXRoIHRoZSBhZ2VudCBhZnRlciBUUCwgdGhleSBh cmUgdGhlIG9ubHkgb25lcyB3aG8gc2hvdWxkIGJlIGFibGUgdG8gbWFrZSB0aGF0IGNhbGwsIGV4 Y2VwdCBmb3IgdGhlIGFnZW50IGl0c2VsZiwgZS5nLiBpZiBpdCB3b3VsZCBsaWtlIEFEMiB0byBh Y3QgTmV0LU5hbm55LiBUaGVuIEkgYmVsaWV2ZSB0aGlzIGlzIGhvdyBpdCBzaG91bGQgd29yazoN Cg0KQ2FzZSAxOiBBZ2VudCAoSUQxKSB3YW50cyB0byBjb25zdWx0IEFEMiBhYm91dCBUUDoNCg0K SUQxIC0tKElEMSwgVFAgUkQyPyktPiBBRDINCkFEMiAtLShJRCwgPFJEMmtleTE/LCBSRDJrZXky Pz4pLT4gUkQyDQpSRDIgLS0oSUQsIDxSRDJ2YWx1ZTEsIFJEMnZhbHVlMj4pLT4gQUQyDQpBRDIg LS0oSUQxLCA8UkQydmFsdWVzIE9LPiwgVFAgUkQyIE9LKS0+IElEMQ0KSUQxIC0tKElEMSwgVFAg UkQyKS0+IEFEMQ0KQUQxIC0tKElEMSwgPFJEMmtleTE/LCBSRDJrZXkyPz4pLT4gUkQyDQpSRDIg LS0oSUQxLCA8UkQydmFsdWUxLCBSRDJ2YWx1ZTIsIEFEMWtleTE/LCBBRDFrZXkyPywgSUQxa2V5 MSByYW5nZT8sIElEMWtleTIgcmFuZ2U/PiktPiBBRDENCkFEMSAtLShJRDEsIDxSRDJ2YWx1ZXMg T0ssIEFEMXZhbHVlMSwgQUQxdmFsdWUyLCBJRDFrZXlzIE9LPiktPiBSRDINClJEMiAtLShJRDEs IDxBRDF2YWx1ZXMgT0s+LCByZXogY2FwKS0+IEFEMQ0KDQpDYXNlIDI6IEFEMSB3YW50cyB0byBj b25zdWx0IEFEMiBhYm91dCBUUDoNCg0KSUQxIC0tKElEMSwgVFAgUkQyKS0+IEFEMQ0KQUQxIC0t KElELCBUUCBSRDI/KS0+IEFEMg0KQUQyIC0tKElELCA8QUQxa2V5MT8sIEFEMWtleTI/LCBJRGtl eTEgcmFuZ2U/LCBJRGtleTIgcmFuZ2U/PiktPiBBRDENCkFEMSAtLShJRCwgPEFEMXZhbHVlMSwg QUQxdmFsdWUyLCBJRGtleXMgT0s+KS0+IEFEMg0KQUQyIC0tKElELCA8QUQxdmFsdWVzIE9LPiwg VFAgUkQyIE9LKS0+IEFEMQ0KQUQxIC0tKElEMSwgPFJEMmtleTE/LCBSRDJrZXkyPz4pLT4gUkQy DQpSRDIgLS0oSUQxLCA8UkQydmFsdWUxLCBSRDJ2YWx1ZTIsIEFEMWtleTE/LCBBRDFrZXkyPywg SUQxa2V5MSByYW5nZT8sIElEMWtleTIgcmFuZ2U/PiktPiBBRDENCkFEMSAtLShJRDEsIDxSRHZh bHVlcyBPSywgQUQxdmFsdWUxLCBBRDF2YWx1ZTIsIElEMWtleXMgT0s+KS0+IFJEMg0KUkQyIC0t KElEMSwgPEFEMXZhbHVlcyBPSz4sIHJleiBjYXApLT4gQUQxDQoNCkNhc2UgMzogUkQyIHdhbnRz IHRvIGNvbnN1bHQgQUQyIGFib3V0IFRQOg0KDQpJRDEgLS0oSUQxLCBUUCBSRDIpLT4gQUQxDQpB RDEgLS0oSUQxLCA8UkQya2V5MT8sIFJEMmtleTI/PiktPiBSRDINClJEMiAtLShJRCwgcmV6IGNh cD8pLT4gQUQyDQpBRDIgLS0oSUQsIDxBRGtleTE/LCBBRGtleTI/LCBJRGtleTEgcmFuZ2U/LCBJ RGtleTIgcmFuZ2U/PiktPiBSRDINClJEMiAtLShJRDEsIDxSRDJ2YWx1ZTEsIFJEMnZhbHVlMiwg QUQxa2V5MT8sIEFEMWtleTI/LCBJRDFrZXkxIHJhbmdlPywgSUQxa2V5MiByYW5nZT8+KS0+IEFE MQ0KQUQxIC0tKElEMSwgPFJEdmFsdWVzIE9LLCBBRDF2YWx1ZTEsIEFEMXZhbHVlMiwgSUQxa2V5 cyBPSz4pLT4gUkQyDQpSRDIgLS0oSUQsIDxBRHZhbHVlMSwgQUR2YWx1ZTIsIElEa2V5cyBPSz4p LT4gQUQyDQpBRDIgLS0oSUQsIDxBRHZhbHVlcyBPSz4sIHJleiBjYXAgT0spLT4gUkQyDQpSRDIg LS0oSUQxLCA8QUQxdmFsdWVzIE9LPiwgcmV6IGNhcCktPiBBRDENCg0KVGhlIGNhbGxpbmcgZG9t YWluIG9yIHNlcnZpY2Ugc2hvdWxkIG5ldmVyIGJlIGZvcmNlZCB0byBjYWxsIG1vcmUgdGhhbiBv bmUgKHRoZSByZWNlaXZpbmcpIGRvbWFpbiBvciBzZXJ2aWNlLCBidXQgaXQgY291bGQgY2hvb3Nl IHRvIGRvIHNvIChDYXNlcyAxIGFuZCAyKS4gV2hhdCBoYXBwZW5zIGJlaGluZCB0aGUgZW5kcG9p bnQgaXQgc2VlcyBpcyByZWFsbHkgbm9uZSBvZiBpdHMgYnVzaW5lc3MgKENhc2UgMykuDQpJbiBj YXNlcyAyIGFuZCAzLCBtdWNoIG9mIHRoZSBleHRyYSBoYW5kLXNoYWtpbmcgY291bGQgYmUgcmVw bGFjZWQgYnkgcHJlLWFycmFuZ2VkIGFncmVlbWVudHMgb3IgZHVwbGljYXRpb24gb2YgcG9saWNp ZXMsIGFuZCBtYXkgYWxzbyByZXF1aXJlIHByZS1hcnJhbmdlZCBkb21haW5zIG9mIHRydXN0Lg0K VGhlIFZXUkFQIHByb3RvY29sIG1heSBiZSB1c2VkIGZvciB0aGUgY29uc3VsdGluZyBhcyB3ZWxs LCBpZiBpdCdzIGFzc3VtZWQgdG8gaGF2ZSB0aGUgZ2VuZXJhbGl6ZWQgZm9ybSBzdWdnZXN0ZWQg aW4gbXkgcHJldmlvdXMgcG9zdCAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L29ncHgvY3VycmVudC9tc2cwMDUzOC5odG1sKS4NClRoZSBjb25zdWx0aW5nIGNvdWxkIGJlIG1h ZGUgdGhlIHNhbWUgd2F5IHJlZ2FyZGxlc3Mgb2YgaWYgdGhlIGRvbWFpbnMgb3Igc2VydmljZXMg YXJlIGNvbnRyb2xsZWQgYnkgdGhlIHNhbWUgZW50aXR5IG9yIG5vdC4NCkFjdHVhbGx5LCBBRDIg Y291bGQgYmUgQUQzIG9yIHNlcnZpY2U0NzYyLCB3aXRob3V0IGFueSBhZG1pbmlzdHJhdGl2ZSBj b25uZWN0aW9uIHdoYXRzb2V2ZXIgd2l0aCBBRDEsIFJEMSBvciBSRDIgKG9yIEFEMiwgaWYgaXQg c3RpbGwgZXhpc3RzIGFuZCBmb3JtcyBWVzIgd2l0aCBSRDIpLg0KTm90ZSB0aGF0IHRoZSBjb25z dWx0aW5nIGRvbWFpbiBvciBzZXJ2aWNlIGRvZXNuJ3QgaGF2ZSB0byByZXZlYWwgdGhlIGlkZW50 aXR5IG9mIHRoZSBjYWxsaW5nIGFnZW50LCBkb21haW4gb3Igc2VydmljZSB0byB0aGUgY29uc3Vs dGVkIGRvbWFpbiBvciBzZXJ2aWNlLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCk1hZ251cw0KDQoNCi0g LS0tLS1VcnNwcnVuZ2xpZ3QgbWVkZGVsYW5kZS0tLS0tDQpGcsOlbjogTW9yZ2FpbmUgW21haWx0 bzptb3JnYWluZS5kaW5vdmFAZ29vZ2xlbWFpbC5jb21dDQpTa2lja2F0OiBkZW4gOSBva3RvYmVy IDIwMDkgMDU6NTMNClRpbGw6IE1hZ251cyBaZWlzaWcNCktvcGlhOiBvZ3B4QGlldGYub3JnDQrD hG1uZTogUmU6IFtvZ3B4XSBQcm90b2NvbCBmb3IgcGVybWl0dGluZyBwb2xpY3kgZGVjaXNpb25z DQoNCk1hZ251cywgSSBiZWxpZXZlIHRoYXQgd2UncmUgZmFpcmx5IGNsb3NlIG9uIGV2ZXJ5dGhp bmcgZXhjZXB0IHRoZSBzaW5nbGUgaXNzdWUgb2YgInN5bW1ldHJ5IiwgYmVjYXVzZSB5b3Ugc3Rp bGwgdGhpbmsgdGhhdCBJJ20gdGFsa2luZyBhYm91dCBkZXBsb3ltZW50IHN5bW1ldHJ5IHdoZXJl YXMgSSdtIG5vdCBhdCBhbGwsIEknbSB0YWxraW5nIGFib3V0IGRlZmluaXRpb24gc3ltbWV0cnku ICBIb3dldmVyLCBJIHRoaW5rIEkndmUgZm91bmQgYW5vdGhlciB3YXkgb2YgZXhwcmVzc2luZyBp dCB0aGF0IG1pZ2h0IGNvbWUgYWNyb3NzIGJldHRlciAtLS0gSSdsbCBmb2N1cyBvbiBDT0RFLiAg TGV0J3MgdHJ5IHRoaXMgbmV3IGFwcHJvYWNoIGluc3RlYWQuIDotKQ0KDQpQcm90b2NvbHMgYXJl bid0IG11Y2ggdXNlIHVudGlsIHRoZXkgaGF2ZSBiZWVuIGVuY29kZWQgaW4gcHJvZ3JhbXMuICBB IHByb2dyYW0gdGhhdCBpbXBsZW1lbnRzIGEgZ2l2ZW4gcHJvdG9jb2wgZnVsbHkgaXMgd3JpdHRl biB0byBiZSBhYmxlIHRvIGhhbmRsZSBhbGwgdGhlIHBvc3NpYmxlIGRlcGxveW1lbnQgcGF0dGVy bnMgb2YgdGhhdCBwcm90b2NvbC4gIFRoaXMgYWxsb3dzIHRoZSBwcm9ncmFtIHRvIGJlIHVzZWQg aW4gbWFueSBkaWZmZXJlbnQgc2l0dWF0aW9ucyB0byBzdWl0IGxvY2FsIHJlcXVpcmVtZW50cy4g IFN1Y2ggYSBwcm9ncmFtIGlzIE5PVCB3cml0dGVuIHRvIHN1aXQgb25lIHNpbmdsZSBkZXBsb3lt ZW50IHBhdHRlcm4gLS0tIHRoYXQgd291bGQgYmUgaW5lZmZpY2llbnQuICBDb25zZXF1ZW50bHkg dGhlIGNvZGUgdGhhdCBpcyB3cml0dGVuIGlzIGRldGVybWluZWQgYnkgdGhlIGRlZmluaXRpb24g b2YgdGhlIHByb3RvY29sIGFuZCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgZW50aXRpZXMgaW4gdGhl IHByb3RvY29sLiAgVGhlIGNvZGUgdGhhdCBpcyB3cml0dGVuIGlzIE5PVCBkZXRlcm1pbmVkIGJ5 IHRoZSBjaG9zZW4gZGVwbG95bWVudCwgSSBob3BlIHRoYXQncyBjbGVhci4NCg0KU28gbm93IGxl dCdzIGdldCBiYWNrIHRvIEFEcy4gIFdlIGRvbid0IHdhbnQgQURzIHRvIGNhcnJ5IHJlZ2lvbiBw b2xpY3ksIGJ1dCBsZXQncyBleGFtaW5lIHdoYXQgaGFwcGVucyBpZiBBRHMgYXJlIGRlZmluZWQg dG8gZG8gc28uDQoNCiBJZiBBRHMgYXJlIGRlZmluZWQgdG8gc3BlY2lmeSByZWdpb24gcG9saWN5 LCB0aGVuIGEgcHJvZ3JhbSB0aGF0IG5lZWRzIHRvIGtub3cgYWJvdXQgcmVnaW9uIHBvbGljeSB3 b3VsZCBoYXZlIHRvIGNoZWNrIHRoZSBBRHMgLS0tIHRoZXJlIGlzIG5vIGVzY2FwaW5nIHRoYXQu ICBJdCB3b3VsZCBub3QgYmUgcHJvdG9jb2wtY29tcGxpYW50IGlmIGl0IGRpZCBub3QgY2hlY2sg dGhlIEFEcy4gIFRoZSBkZXBsb3ltZW50IHBhdHRlcm5zIGluIFcxIGFuZCBXMiAod2hpY2ggY291 bGQgYmUgY29tcGxldGVseSBkaWZmZXJlbnQpIGFyZSBvZiBubyByZWxldmFuY2Ugd2hhdHNvZXZl ciBpbiB0aGlzIC0tLSB0aGUgcHJvZ3JhbSB3b3VsZCBzdGlsbCBoYXZlIHRvIGNoZWNrIGZvciB0 aGUgcHJlc2VuY2Ugb2YgQURzIGluIGJvdGggd29ybGRzIGp1c3QgaW4gY2FzZSB0aGUgQURzIGV4 aXN0LCBhbmQgYWxsIHRob3NlIEFEcyB0aGF0IGV4aXN0IHdvdWxkIGhhdmUgdG8gYmUgcXVlcmll ZCBmb3IgcmVnaW9uIHBvbGljeSBiZWNhdXNlIHdlJ3ZlIGRlZmluZWQgdGhhdCByZWdpb24gcG9s aWN5IGlzIGNhcnJpZWQgYnkgQURzLiAgSWYgdGhlIHByb2dyYW0gZGlkIG5vdCBjaGVjayBib3Ro IEFEcyB0aGVuIGl0IGNvdWxkIGJlIG1pc3NpbmcgcGFydCBvZiB0aGUgcmVnaW9uIHBvbGljeS4g Oi0pDQoNClNlZSB3aGF0IEkgbWVhbiBieSBkZWZpbml0aW9uIHN5bW1ldHJ5IG5vdz8gIEhvd2V2 ZXIgeW91IGRlZmluZSBhbiBBRCwgdGhhdCBkZWZpbml0aW9uIGFsd2F5cyBhcHBsaWVzIHRvIGJv dGggQURzIGluIGEgMi13b3JsZCBkZXBsb3ltZW50IGlmIHRoZXkgZXhpc3QuICBUaGUgZGVmaW5p dGlvbiBjYW4gbmV2ZXIgYXBwbHkgb25seSB0byBvbmUgd29ybGQgLS0tIGl0IHNob3VsZCBiZSBj bGVhciB0aGF0ICJBRHMgY2FycnkgcmVnaW9uIHBvbGljaWVzLCBidXQgdGhlIHJlZ2lvbiBwb2xp Y2llcyBpbiBteSBBRCBhcmUgdmFsaWQgd2hpbGUgdGhlIHJlZ2lvbiBwb2xpY2llcyBpbiB5b3Vy IEFEIHdpbGwgYmUgaWdub3JlZCIgaXMgY29tcGxldGVseSBib2d1cy4gOi0pICBJbiBwcm90b2Nv bCB0ZXJtcywgdGhpcyB3b3VsZCBiZSBub24tY29tcGxpYW50IGJlY2F1c2UgcGFydCBvZiB0aGUg cmVnaW9uIHBvbGljeSB3b3VsZCBiZSBtaXNzZWQuDQoNCkFzIGEgcmVzdWx0IG9mIHRoaXMgZGVm aW5pdGlvbmFsIHN5bW1ldHJ5LCB0aGUgb25seSB3YXkgd2UncmUgZ29pbmcgdG8gYmUgYWJsZSB0 byBhdm9pZCBjb25zdWx0aW5nIEFEMiBpcyBvdXIgbGl0dGxlIGV4YW1wbGUgc2NlbmFyaW8gaXMg Ynkgbm90IGFsbG93aW5nIEFEcyB0byBleHByZXNzIHJlZ2lvbiBwb2xpY3kgYXQgYWxsLCBiZWNh dXNlIGlmIEFEMSBpcyBhbGxvd2VkIHRvIGV4cHJlc3MgcmVnaW9uIHBvbGljeSB0aGVuIEFEMiBp cyBhbGxvd2VkIHRvIGV4cHJlc3MgaXQgYXMgd2VsbCwgYW5kIGhlbmNlIHRoZSBwcm9ncmFtIG11 c3QgdHJ5IHRvIGNvbnN1bHQgQUQyIGZvciBpdHMgcmVnaW9uIHBvbGljeSwgYnkgZGVmaW5pdGlv biBvZiBBRC4gIEl0J3MgdmVyeSBzdHJvbmcgbG9naWMsIGFuZCBpdCBoYXMgbm90aGluZyB0byBk byB3aXRoIHRoZSBjaG9zZW4gZGVwbG95bWVudHMsIGJlY2F1c2UgaXQgYXBwbGllcyBpbiBjYXNl IEFEMiBleGlzdHMuDQoNCk9mIGNvdXJzZSwgYXMgeW91IHBvaW50ZWQgb3V0LCB0aGVyZSBhcmUg bWFueSBtb3JlIHJlYWxpc3RpYyBkZXBsb3ltZW50cyBvdXQgdGhlcmUsIGJ1dCB0aGlzIHNpbXBs ZSBvbmUgaXMgYWxsIHRoYXQncyBuZWVkZWQgdG8gaW52YWxpZGF0ZSB0aGUgaWRlYSB0aGF0IEFE MSBjYW4gZXhwcmVzcyByZWdpb24gcG9saWN5IHdoaWxlIEFEMiBjYW4gYmUgcHJlc2VudCBidXQg aWdub3JlZC4gIFRoYXQgY2Fubm90IGhhcHBlbiB1bmxlc3MgdGhlIHByb3RvY29sIGV4cGxpY2l0 bHkgZGVmaW5lcyBhc3ltbWV0cmljIHJlbGF0aW9uc2hpcHMsIHdoaWNoIGlzIG5vdCB0cnVlIGlu IG91ciBjYXNlIGFuZCBjYW5ub3QgYmUgdHJ1ZSBnaXZlbiB0aGF0IFcxIGFuZCBXMiBhcmUgcGVl cnMuDQoNClRoYXQncyBhbGwgSSB3YW50ZWQgdG8gZGVzY3JpYmUgaW4gdGhpcyBwYXJ0aWN1bGFy IHJlcGx5LiAgSSBob3BlIHRoZSBwb2ludCB3YXMgY2xlYXJlciB0aGlzIHRpbWUuIDotKQ0KDQoN Ck1vcmdhaW5lLg0KDQoNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiA5 LjguMyAoQnVpbGQgNDAyOCkNCkNoYXJzZXQ6IHV0Zi04DQoNCndzQlZBd1VCU3M4SjBPNU1sVTlY eWFpU0FRZ2JOZ2YrS1ZNYnJ0Tld0dU9neE9XT1AzTXBOVSt4ejVxNDdrTkwNCkxsbUsxQ2hwMGI0 QVZuaUhZdVo1VTcrUHByY21GWnBrcG1VMlNBSmJVREhMVjZhT0RUNjA3Vml5Q2VJQzR2TU4NClYv T0tsRDhEREJSYVYyc3VJVDZkNFFLOVRBUTdLM0xuNFAvQmZFa21qOHpQa1FmSmNyclZSQmZXamsr amlRVmcNCnZvMEx1aWZaTEZPK3ZLVkJoWmh2U05oRDBIc1FaVHJmM094cllOMlk2VmRzejFaRmQv UmFaelFld3hBbXQ3ZUQNCk5NQmkzV0FzNHluWFVEejlwWm5oUGdZMWVHN2RSckhuelhjaWFPQ201 MW9IdGFEaGJ4TTdpb0RjdFpseVNWaTcNCmFiSXRkSTVOQVdXV2tNaFhxbEwxSGNheUZqaWd0SEdD Z3dWUXRhbHVKaWptcGt3TUZreEs4QT09DQo9bkhyZw0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0t LS0tDQoNCg0K --_000_983F17705339E24699AA251B458249B50CC48CB8CDEXCHANGE2K7of_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+DQo8ZGl2Pi0tLS0t QkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS08L2Rpdj4NCjxkaXY+SGFzaDogU0hBMjU2PC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Nb3JnYWluZSwgSSB0aGluayBJIHVuZGVyc3Rv b2QgeW91ciBtZWFuaW5nIHdpdGggdGhlIGZpcnN0IGV4YW1wbGUsIGFuZCBJIGFsc28gdGhpbmsg SSBkbyBpdCB3aXRoIHRoZSBzZWNvbmQgZXhhbXBsZS4gQW5kIEkgc3RpbGwgc2VlIG5vIHJlcXVp cmVtZW50IGZvciB5b3VyIHN5bW1ldHJ5LCBvciB3aGF0ZXZlciB5b3UgcHJlZmVyIHRvIGNhbGwg aXQuIExldCdzIHJlY2FwaXR1bGF0ZSBzbyBwZW9wbGUgZG9uJ3QgbmVlZCB0byBicm93c2UNCmJh Y2suIEFuIGFnZW50IHVzaW5nIEFEMSB3YW50cyB0byB0ZWxlcG9ydCAoVFApIGZyb20gVlcxLCBj b25zaXN0aW5nIG9mIEFEMSBhbmQgUkQxLCB0byBWVzIsIGNvbnNpc3Rpbmcgb2YgQUQyIGFuZCBS RDIuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Gb3IgdGhlIFRQIHRvIGhhcHBlbiwg QUQxIG5lZWRzIHRvIGFncmVlIHRvIHRyeSB0aGUgVFAgYmVjYXVzZSBpdCdzIHVzZWQgYnkgdGhl IGFnZW50LiBSRDIgbmVlZHMgdG8gYWNjZXB0IHRoZSBUUCBiZWNhdXNlIGl0IHdpbGwgaGFuZGxl IHRoZSBhZ2VudCdzIHByZXNlbmNlLiBSRDEgc2hvdWxkIGhhdmUgbm8gc2F5IHNpbmNlIGl0IHdp bGwgbm90IGJlIHVzZWQgYnkgb3IgaGFuZGxlIHRoZSBhZ2VudC4gQUQyIHNob3VsZCBoYXZlIG5v IHNheQ0Kc2luY2UgaXQgd2lsbCBub3QgYmUgdXNlZCBieSBvciBoYW5kbGUgdGhlIGFnZW50LiBU aGF0J3MgbXkgaWRlYSBvZiBwZXJmZWN0IHN5bW1ldHJ5LCBidXQuLi48L2Rpdj4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8ZGl2PkFzc3VtZSB0aGF0IEFEMSBvciBSRDIgZm9yIHRoZSByZWFzb24gb2Yg JnF1b3Q7c3ltbWV0cnkmcXVvdDssIG9yIHNvbWV0aGluZyBlbHNlLCB3YW50cyBBRDIgdG8gaGF2 ZSBhIHNheSBhYm91dCB0aGUgVFAuIFNpbmNlIEFEMSBhbmQgUkQyIGFyZSB0aGUgb25seSBlbnRp dGllcyBpbnZvbHZlZCB3aXRoIHRoZSBhZ2VudCBhZnRlciBUUCwgdGhleSBhcmUgdGhlIG9ubHkg b25lcyB3aG8gc2hvdWxkIGJlIGFibGUgdG8gbWFrZSB0aGF0IGNhbGwsIGV4Y2VwdA0KZm9yIHRo ZSBhZ2VudCBpdHNlbGYsIGUuZy4gaWYgaXQgd291bGQgbGlrZSBBRDIgdG8gYWN0IE5ldC1OYW5u eS4gVGhlbiBJIGJlbGlldmUgdGhpcyBpcyBob3cgaXQgc2hvdWxkIHdvcms6PC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj5DYXNlIDE6IEFnZW50IChJRDEpIHdhbnRzIHRvIGNvbnN1bHQg QUQyIGFib3V0IFRQOjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SUQxIC0tKElEMSwg VFAgUkQyPyktJmd0OyBBRDI8L2Rpdj4NCjxkaXY+QUQyIC0tKElELCAmbHQ7UkQya2V5MT8sIFJE MmtleTI/Jmd0OyktJmd0OyBSRDI8L2Rpdj4NCjxkaXY+UkQyIC0tKElELCAmbHQ7UkQydmFsdWUx LCBSRDJ2YWx1ZTImZ3Q7KS0mZ3Q7IEFEMjwvZGl2Pg0KPGRpdj5BRDIgLS0oSUQxLCAmbHQ7UkQy dmFsdWVzIE9LJmd0OywgVFAgUkQyIE9LKS0mZ3Q7IElEMTwvZGl2Pg0KPGRpdj5JRDEgLS0oSUQx LCBUUCBSRDIpLSZndDsgQUQxPC9kaXY+DQo8ZGl2PkFEMSAtLShJRDEsICZsdDtSRDJrZXkxPywg UkQya2V5Mj8mZ3Q7KS0mZ3Q7IFJEMjwvZGl2Pg0KPGRpdj5SRDIgLS0oSUQxLCAmbHQ7UkQydmFs dWUxLCBSRDJ2YWx1ZTIsIEFEMWtleTE/LCBBRDFrZXkyPywgSUQxa2V5MSByYW5nZT8sIElEMWtl eTIgcmFuZ2U/Jmd0OyktJmd0OyBBRDE8L2Rpdj4NCjxkaXY+QUQxIC0tKElEMSwgJmx0O1JEMnZh bHVlcyBPSywgQUQxdmFsdWUxLCBBRDF2YWx1ZTIsIElEMWtleXMgT0smZ3Q7KS0mZ3Q7IFJEMjwv ZGl2Pg0KPGRpdj5SRDIgLS0oSUQxLCAmbHQ7QUQxdmFsdWVzIE9LJmd0OywgcmV6IGNhcCktJmd0 OyBBRDE8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkNhc2UgMjogQUQxIHdhbnRzIHRv IGNvbnN1bHQgQUQyIGFib3V0IFRQOjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SUQx IC0tKElEMSwgVFAgUkQyKS0mZ3Q7IEFEMTwvZGl2Pg0KPGRpdj5BRDEgLS0oSUQsIFRQIFJEMj8p LSZndDsgQUQyPC9kaXY+DQo8ZGl2PkFEMiAtLShJRCwgJmx0O0FEMWtleTE/LCBBRDFrZXkyPywg SURrZXkxIHJhbmdlPywgSURrZXkyIHJhbmdlPyZndDspLSZndDsgQUQxPC9kaXY+DQo8ZGl2PkFE MSAtLShJRCwgJmx0O0FEMXZhbHVlMSwgQUQxdmFsdWUyLCBJRGtleXMgT0smZ3Q7KS0mZ3Q7IEFE MjwvZGl2Pg0KPGRpdj5BRDIgLS0oSUQsICZsdDtBRDF2YWx1ZXMgT0smZ3Q7LCBUUCBSRDIgT0sp LSZndDsgQUQxPC9kaXY+DQo8ZGl2PkFEMSAtLShJRDEsICZsdDtSRDJrZXkxPywgUkQya2V5Mj8m Z3Q7KS0mZ3Q7IFJEMjwvZGl2Pg0KPGRpdj5SRDIgLS0oSUQxLCAmbHQ7UkQydmFsdWUxLCBSRDJ2 YWx1ZTIsIEFEMWtleTE/LCBBRDFrZXkyPywgSUQxa2V5MSByYW5nZT8sIElEMWtleTIgcmFuZ2U/ Jmd0OyktJmd0OyBBRDE8L2Rpdj4NCjxkaXY+QUQxIC0tKElEMSwgJmx0O1JEdmFsdWVzIE9LLCBB RDF2YWx1ZTEsIEFEMXZhbHVlMiwgSUQxa2V5cyBPSyZndDspLSZndDsgUkQyPC9kaXY+DQo8ZGl2 PlJEMiAtLShJRDEsICZsdDtBRDF2YWx1ZXMgT0smZ3Q7LCByZXogY2FwKS0mZ3Q7IEFEMTwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Q2FzZSAzOiBSRDIgd2FudHMgdG8gY29uc3VsdCBB RDIgYWJvdXQgVFA6PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JRDEgLS0oSUQxLCBU UCBSRDIpLSZndDsgQUQxPC9kaXY+DQo8ZGl2PkFEMSAtLShJRDEsICZsdDtSRDJrZXkxPywgUkQy a2V5Mj8mZ3Q7KS0mZ3Q7IFJEMjwvZGl2Pg0KPGRpdj5SRDIgLS0oSUQsIHJleiBjYXA/KS0mZ3Q7 IEFEMjwvZGl2Pg0KPGRpdj5BRDIgLS0oSUQsICZsdDtBRGtleTE/LCBBRGtleTI/LCBJRGtleTEg cmFuZ2U/LCBJRGtleTIgcmFuZ2U/Jmd0OyktJmd0OyBSRDI8L2Rpdj4NCjxkaXY+UkQyIC0tKElE MSwgJmx0O1JEMnZhbHVlMSwgUkQydmFsdWUyLCBBRDFrZXkxPywgQUQxa2V5Mj8sIElEMWtleTEg cmFuZ2U/LCBJRDFrZXkyIHJhbmdlPyZndDspLSZndDsgQUQxPC9kaXY+DQo8ZGl2PkFEMSAtLShJ RDEsICZsdDtSRHZhbHVlcyBPSywgQUQxdmFsdWUxLCBBRDF2YWx1ZTIsIElEMWtleXMgT0smZ3Q7 KS0mZ3Q7IFJEMjwvZGl2Pg0KPGRpdj5SRDIgLS0oSUQsICZsdDtBRHZhbHVlMSwgQUR2YWx1ZTIs IElEa2V5cyBPSyZndDspLSZndDsgQUQyPC9kaXY+DQo8ZGl2PkFEMiAtLShJRCwgJmx0O0FEdmFs dWVzIE9LJmd0OywgcmV6IGNhcCBPSyktJmd0OyBSRDI8L2Rpdj4NCjxkaXY+UkQyIC0tKElEMSwg Jmx0O0FEMXZhbHVlcyBPSyZndDssIHJleiBjYXApLSZndDsgQUQxPC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj5UaGUgY2FsbGluZyBkb21haW4gb3Igc2VydmljZSBzaG91bGQgbmV2ZXIg YmUgZm9yY2VkIHRvIGNhbGwgbW9yZSB0aGFuIG9uZSAodGhlIHJlY2VpdmluZykgZG9tYWluIG9y IHNlcnZpY2UsIGJ1dCBpdCBjb3VsZCBjaG9vc2UgdG8gZG8gc28gKENhc2VzIDEgYW5kIDIpLiBX aGF0IGhhcHBlbnMgYmVoaW5kIHRoZSBlbmRwb2ludCBpdCBzZWVzIGlzIHJlYWxseSBub25lIG9m IGl0cyBidXNpbmVzcyAoQ2FzZSAzKS48L2Rpdj4NCjxkaXY+SW4gY2FzZXMgMiBhbmQgMywgbXVj aCBvZiB0aGUgZXh0cmEgaGFuZC1zaGFraW5nIGNvdWxkIGJlIHJlcGxhY2VkIGJ5IHByZS1hcnJh bmdlZCBhZ3JlZW1lbnRzIG9yIGR1cGxpY2F0aW9uIG9mIHBvbGljaWVzLCBhbmQgbWF5IGFsc28g cmVxdWlyZSBwcmUtYXJyYW5nZWQgZG9tYWlucyBvZiB0cnVzdC48L2Rpdj4NCjxkaXY+VGhlIFZX UkFQIHByb3RvY29sIG1heSBiZSB1c2VkIGZvciB0aGUgY29uc3VsdGluZyBhcyB3ZWxsLCBpZiBp dCdzIGFzc3VtZWQgdG8gaGF2ZSB0aGUgZ2VuZXJhbGl6ZWQgZm9ybSBzdWdnZXN0ZWQgaW4gbXkg cHJldmlvdXMgcG9zdCAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL29ncHgvY3VycmVudC9tc2cwMDUzOC5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvb2dweC9jdXJyZW50L21zZzAwNTM4Lmh0bWw8L2E+KS48L2Rpdj4NCjxkaXY+ VGhlIGNvbnN1bHRpbmcgY291bGQgYmUgbWFkZSB0aGUgc2FtZSB3YXkgcmVnYXJkbGVzcyBvZiBp ZiB0aGUgZG9tYWlucyBvciBzZXJ2aWNlcyBhcmUgY29udHJvbGxlZCBieSB0aGUgc2FtZSBlbnRp dHkgb3Igbm90LjwvZGl2Pg0KPGRpdj5BY3R1YWxseSwgQUQyIGNvdWxkIGJlIEFEMyBvciBzZXJ2 aWNlNDc2Miwgd2l0aG91dCBhbnkgYWRtaW5pc3RyYXRpdmUgY29ubmVjdGlvbiB3aGF0c29ldmVy IHdpdGggQUQxLCBSRDEgb3IgUkQyIChvciBBRDIsIGlmIGl0IHN0aWxsIGV4aXN0cyBhbmQgZm9y bXMgVlcyIHdpdGggUkQyKS48L2Rpdj4NCjxkaXY+Tm90ZSB0aGF0IHRoZSBjb25zdWx0aW5nIGRv bWFpbiBvciBzZXJ2aWNlIGRvZXNuJ3QgaGF2ZSB0byByZXZlYWwgdGhlIGlkZW50aXR5IG9mIHRo ZSBjYWxsaW5nIGFnZW50LCBkb21haW4gb3Igc2VydmljZSB0byB0aGUgY29uc3VsdGVkIGRvbWFp biBvciBzZXJ2aWNlLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRz LDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+TWFnbnVzPC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+LSAtLS0tLVVyc3BydW5nbGlndCBtZWRk ZWxhbmRlLS0tLS08L2Rpdj4NCjxkaXY+RnLDpW46IE1vcmdhaW5lIFs8YSBocmVmPSJtYWlsdG86 bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwuY29tIj5tYWlsdG86bW9yZ2FpbmUuZGlub3ZhQGdv b2dsZW1haWwuY29tPC9hPl0gPC9kaXY+DQo8ZGl2PlNraWNrYXQ6IGRlbiA5IG9rdG9iZXIgMjAw OSAwNTo1MzwvZGl2Pg0KPGRpdj5UaWxsOiBNYWdudXMgWmVpc2lnPC9kaXY+DQo8ZGl2PktvcGlh OiBvZ3B4QGlldGYub3JnPC9kaXY+DQo8ZGl2PsOEbW5lOiBSZTogW29ncHhdIFByb3RvY29sIGZv ciBwZXJtaXR0aW5nIHBvbGljeSBkZWNpc2lvbnM8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2Pk1hZ251cywgSSBiZWxpZXZlIHRoYXQgd2UncmUgZmFpcmx5IGNsb3NlIG9uIGV2ZXJ5dGhp bmcgZXhjZXB0IHRoZSBzaW5nbGUgaXNzdWUgb2YgJnF1b3Q7c3ltbWV0cnkmcXVvdDssIGJlY2F1 c2UgeW91IHN0aWxsIHRoaW5rIHRoYXQgSSdtIHRhbGtpbmcgYWJvdXQgZGVwbG95bWVudCBzeW1t ZXRyeSB3aGVyZWFzIEknbSBub3QgYXQgYWxsLCBJJ20gdGFsa2luZyBhYm91dCBkZWZpbml0aW9u IHN5bW1ldHJ5LiZuYnNwOyBIb3dldmVyLCBJIHRoaW5rIEkndmUgZm91bmQNCmFub3RoZXIgd2F5 IG9mIGV4cHJlc3NpbmcgaXQgdGhhdCBtaWdodCBjb21lIGFjcm9zcyBiZXR0ZXIgLS0tIEknbGwg Zm9jdXMgb24gQ09ERS4mbmJzcDsgTGV0J3MgdHJ5IHRoaXMgbmV3IGFwcHJvYWNoIGluc3RlYWQu IDotKTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+UHJvdG9jb2xzIGFyZW4ndCBtdWNo IHVzZSB1bnRpbCB0aGV5IGhhdmUgYmVlbiBlbmNvZGVkIGluIHByb2dyYW1zLiZuYnNwOyBBIHBy b2dyYW0gdGhhdCBpbXBsZW1lbnRzIGEgZ2l2ZW4gcHJvdG9jb2wgZnVsbHkgaXMgd3JpdHRlbiB0 byBiZSBhYmxlIHRvIGhhbmRsZSBhbGwgdGhlIHBvc3NpYmxlIGRlcGxveW1lbnQgcGF0dGVybnMg b2YgdGhhdCBwcm90b2NvbC4mbmJzcDsgVGhpcyBhbGxvd3MgdGhlIHByb2dyYW0gdG8gYmUgdXNl ZCBpbiBtYW55IGRpZmZlcmVudA0Kc2l0dWF0aW9ucyB0byBzdWl0IGxvY2FsIHJlcXVpcmVtZW50 cy4mbmJzcDsgU3VjaCBhIHByb2dyYW0gaXMgTk9UIHdyaXR0ZW4gdG8gc3VpdCBvbmUgc2luZ2xl IGRlcGxveW1lbnQgcGF0dGVybiAtLS0gdGhhdCB3b3VsZCBiZSBpbmVmZmljaWVudC4mbmJzcDsg Q29uc2VxdWVudGx5IHRoZSBjb2RlIHRoYXQgaXMgd3JpdHRlbiBpcyBkZXRlcm1pbmVkIGJ5IHRo ZSBkZWZpbml0aW9uIG9mIHRoZSBwcm90b2NvbCBhbmQgdGhlIGRlZmluaXRpb24gb2YgdGhlIGVu dGl0aWVzDQppbiB0aGUgcHJvdG9jb2wuJm5ic3A7IFRoZSBjb2RlIHRoYXQgaXMgd3JpdHRlbiBp cyBOT1QgZGV0ZXJtaW5lZCBieSB0aGUgY2hvc2VuIGRlcGxveW1lbnQsIEkgaG9wZSB0aGF0J3Mg Y2xlYXIuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5TbyBub3cgbGV0J3MgZ2V0IGJh Y2sgdG8gQURzLiZuYnNwOyBXZSBkb24ndCB3YW50IEFEcyB0byBjYXJyeSByZWdpb24gcG9saWN5 LCBidXQgbGV0J3MgZXhhbWluZSB3aGF0IGhhcHBlbnMgaWYgQURzIGFyZSBkZWZpbmVkIHRvIGRv IHNvLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+IElmIEFEcyBhcmUgZGVmaW5lZCB0 byBzcGVjaWZ5IHJlZ2lvbiBwb2xpY3ksIHRoZW4gYSBwcm9ncmFtIHRoYXQgbmVlZHMgdG8ga25v dyBhYm91dCByZWdpb24gcG9saWN5IHdvdWxkIGhhdmUgdG8gY2hlY2sgdGhlIEFEcyAtLS0gdGhl cmUgaXMgbm8gZXNjYXBpbmcgdGhhdC4mbmJzcDsgSXQgd291bGQgbm90IGJlIHByb3RvY29sLWNv bXBsaWFudCBpZiBpdCBkaWQgbm90IGNoZWNrIHRoZSBBRHMuJm5ic3A7IFRoZSBkZXBsb3ltZW50 IHBhdHRlcm5zIGluDQpXMSBhbmQgVzIgKHdoaWNoIGNvdWxkIGJlIGNvbXBsZXRlbHkgZGlmZmVy ZW50KSBhcmUgb2Ygbm8gcmVsZXZhbmNlIHdoYXRzb2V2ZXIgaW4gdGhpcyAtLS0gdGhlIHByb2dy YW0gd291bGQgc3RpbGwgaGF2ZSB0byBjaGVjayBmb3IgdGhlIHByZXNlbmNlIG9mIEFEcyBpbiBi b3RoIHdvcmxkcyBqdXN0IGluIGNhc2UgdGhlIEFEcyBleGlzdCwgYW5kIGFsbCB0aG9zZSBBRHMg dGhhdCBleGlzdCB3b3VsZCBoYXZlIHRvIGJlIHF1ZXJpZWQgZm9yIHJlZ2lvbg0KcG9saWN5IGJl Y2F1c2Ugd2UndmUgZGVmaW5lZCB0aGF0IHJlZ2lvbiBwb2xpY3kgaXMgY2FycmllZCBieSBBRHMu Jm5ic3A7IElmIHRoZSBwcm9ncmFtIGRpZCBub3QgY2hlY2sgYm90aCBBRHMgdGhlbiBpdCBjb3Vs ZCBiZSBtaXNzaW5nIHBhcnQgb2YgdGhlIHJlZ2lvbiBwb2xpY3kuIDotKTwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+U2VlIHdoYXQgSSBtZWFuIGJ5IGRlZmluaXRpb24gc3ltbWV0cnkg bm93PyZuYnNwOyBIb3dldmVyIHlvdSBkZWZpbmUgYW4gQUQsIHRoYXQgZGVmaW5pdGlvbiBhbHdh eXMgYXBwbGllcyB0byBib3RoIEFEcyBpbiBhIDItd29ybGQgZGVwbG95bWVudCBpZiB0aGV5IGV4 aXN0LiZuYnNwOyBUaGUgZGVmaW5pdGlvbiBjYW4gbmV2ZXIgYXBwbHkgb25seSB0byBvbmUgd29y bGQgLS0tIGl0IHNob3VsZCBiZSBjbGVhciB0aGF0ICZxdW90O0FEcyBjYXJyeSByZWdpb24gcG9s aWNpZXMsDQpidXQgdGhlIHJlZ2lvbiBwb2xpY2llcyBpbiBteSBBRCBhcmUgdmFsaWQgd2hpbGUg dGhlIHJlZ2lvbiBwb2xpY2llcyBpbiB5b3VyIEFEIHdpbGwgYmUgaWdub3JlZCZxdW90OyBpcyBj b21wbGV0ZWx5IGJvZ3VzLiA6LSkmbmJzcDsgSW4gcHJvdG9jb2wgdGVybXMsIHRoaXMgd291bGQg YmUgbm9uLWNvbXBsaWFudCBiZWNhdXNlIHBhcnQgb2YgdGhlIHJlZ2lvbiBwb2xpY3kgd291bGQg YmUgbWlzc2VkLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QXMgYSByZXN1bHQgb2Yg dGhpcyBkZWZpbml0aW9uYWwgc3ltbWV0cnksIHRoZSBvbmx5IHdheSB3ZSdyZSBnb2luZyB0byBi ZSBhYmxlIHRvIGF2b2lkIGNvbnN1bHRpbmcgQUQyIGlzIG91ciBsaXR0bGUgZXhhbXBsZSBzY2Vu YXJpbyBpcyBieSBub3QgYWxsb3dpbmcgQURzIHRvIGV4cHJlc3MgcmVnaW9uIHBvbGljeSBhdCBh bGwsIGJlY2F1c2UgaWYgQUQxIGlzIGFsbG93ZWQgdG8gZXhwcmVzcyByZWdpb24gcG9saWN5IHRo ZW4gQUQyIGlzDQphbGxvd2VkIHRvIGV4cHJlc3MgaXQgYXMgd2VsbCwgYW5kIGhlbmNlIHRoZSBw cm9ncmFtIG11c3QgdHJ5IHRvIGNvbnN1bHQgQUQyIGZvciBpdHMgcmVnaW9uIHBvbGljeSwgYnkg ZGVmaW5pdGlvbiBvZiBBRC4mbmJzcDsgSXQncyB2ZXJ5IHN0cm9uZyBsb2dpYywgYW5kIGl0IGhh cyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIGNob3NlbiBkZXBsb3ltZW50cywgYmVjYXVzZSBpdCBh cHBsaWVzIGluIGNhc2UgQUQyIGV4aXN0cy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2 Pk9mIGNvdXJzZSwgYXMgeW91IHBvaW50ZWQgb3V0LCB0aGVyZSBhcmUgbWFueSBtb3JlIHJlYWxp c3RpYyBkZXBsb3ltZW50cyBvdXQgdGhlcmUsIGJ1dCB0aGlzIHNpbXBsZSBvbmUgaXMgYWxsIHRo YXQncyBuZWVkZWQgdG8gaW52YWxpZGF0ZSB0aGUgaWRlYSB0aGF0IEFEMSBjYW4gZXhwcmVzcyBy ZWdpb24gcG9saWN5IHdoaWxlIEFEMiBjYW4gYmUgcHJlc2VudCBidXQgaWdub3JlZC4mbmJzcDsg VGhhdCBjYW5ub3QgaGFwcGVuIHVubGVzcyB0aGUNCnByb3RvY29sIGV4cGxpY2l0bHkgZGVmaW5l cyBhc3ltbWV0cmljIHJlbGF0aW9uc2hpcHMsIHdoaWNoIGlzIG5vdCB0cnVlIGluIG91ciBjYXNl IGFuZCBjYW5ub3QgYmUgdHJ1ZSBnaXZlbiB0aGF0IFcxIGFuZCBXMiBhcmUgcGVlcnMuPC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGF0J3MgYWxsIEkgd2FudGVkIHRvIGRlc2NyaWJl IGluIHRoaXMgcGFydGljdWxhciByZXBseS4mbmJzcDsgSSBob3BlIHRoZSBwb2ludCB3YXMgY2xl YXJlciB0aGlzIHRpbWUuIDotKTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2Pk1vcmdhaW5lLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8ZGl2Pi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tPC9kaXY+DQo8ZGl2 PlZlcnNpb246IDkuOC4zIChCdWlsZCA0MDI4KTwvZGl2Pg0KPGRpdj5DaGFyc2V0OiB1dGYtODwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+d3NCVkF3VUJTczhKME81TWxVOVh5YWlTQVFn Yk5nZiYjNDM7S1ZNYnJ0Tld0dU9neE9XT1AzTXBOVSYjNDM7eHo1cTQ3a05MPC9kaXY+DQo8ZGl2 PkxsbUsxQ2hwMGI0QVZuaUhZdVo1VTcmIzQzO1BwcmNtRlpwa3BtVTJTQUpiVURITFY2YU9EVDYw N1ZpeUNlSUM0dk1OPC9kaXY+DQo8ZGl2PlYvT0tsRDhEREJSYVYyc3VJVDZkNFFLOVRBUTdLM0xu NFAvQmZFa21qOHpQa1FmSmNyclZSQmZXamsmIzQzO2ppUVZnPC9kaXY+DQo8ZGl2PnZvMEx1aWZa TEZPJiM0Mzt2S1ZCaFpodlNOaEQwSHNRWlRyZjNPeHJZTjJZNlZkc3oxWkZkL1JhWnpRZXd4QW10 N2VEPC9kaXY+DQo8ZGl2Pk5NQmkzV0FzNHluWFVEejlwWm5oUGdZMWVHN2RSckhuelhjaWFPQ201 MW9IdGFEaGJ4TTdpb0RjdFpseVNWaTc8L2Rpdj4NCjxkaXY+YWJJdGRJNU5BV1dXa01oWHFsTDFI Y2F5RmppZ3RIR0Nnd1ZRdGFsdUppam1wa3dNRmt4SzhBPT08L2Rpdj4NCjxkaXY+PW5Icmc8L2Rp dj4NCjxkaXY+LS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_983F17705339E24699AA251B458249B50CC48CB8CDEXCHANGE2K7of_-- From vaughn.deluca@gmail.com Fri Oct 9 03:49:42 2009 Return-Path: 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 700B03A682A for ; Fri, 9 Oct 2009 03:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 7VDgOo0W0Mzt for ; Fri, 9 Oct 2009 03:49:41 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 6AE273A68AA for ; Fri, 9 Oct 2009 03:49:39 -0700 (PDT) Received: by bwz6 with SMTP id 6so1470873bwz.37 for ; Fri, 09 Oct 2009 03:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bV/HWHdmvJqAZF27KnVoimBjEHVGsWqPK4DtX19JtA0=; b=lE5+cnId2+lHX09uArpceih5IZ41H31NBfgIT4tWofx1E5NCvZgqbfGZhaegbS3o2J wHTw9wFr/Tmpp763XSSIW9E3zdh2I0zfIsLTDxS8FUrC3bx0dqqHGyUq5/fO0qWMpxUp AVnHVKCX6eNGYpkiiy320a+YFAdcNZEAnbdIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ezPtkz27c6LiDKRqoEuHtaOLEpMjgrT1f01CTralPINxKS52FPCZabnoUQVerqWXtp ijAAIbLedE5+Luf2Fo/jWumzmrOrCcjveNNXf8LelqMLp6GHEZtgvZW7+hloC128exAQ BKpNbeNeF6WpzzfeOSZ7feZVZWhrU0uoBkf78= MIME-Version: 1.0 Received: by 10.204.154.211 with SMTP id p19mr2069896bkw.3.1255085480493; Fri, 09 Oct 2009 03:51:20 -0700 (PDT) In-Reply-To: <983F17705339E24699AA251B458249B50CC48CB6E4@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B50CC48CB6E4@EXCHANGE2K7.office.nic.se> Date: Fri, 9 Oct 2009 12:51:20 +0200 Message-ID: <9b8a8de40910090351k65f328d0lb9bf1a8d920048a2@mail.gmail.com> From: Vaughn Deluca To: Magnus Zeisig Content-Type: multipart/alternative; boundary=0015175cd1303a43e104757e5c9b Cc: "ogpx@ietf.org" Subject: Re: [ogpx] VWRAP future (mostly out of protocol ramblings) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 10:49:42 -0000 --0015175cd1303a43e104757e5c9b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Maybe mostly out of protocol, but depicting the situation very well!-Vaughn On Thu, Oct 8, 2009 at 12:38 PM, Magnus Zeisig wrote= : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > In the future I think we will have a VWRAP metaverse similar to how the w= eb > works today. The VWRAP protocol will enable both private persons and majo= r > organizations to set up and interop, to the degree each entity wants, the= ir > own corner of the virtual world with the rest of that world. Just like on > the web, we will see entities running "intra-metaverses", totally shut of= f > or only to a limited degree open to the public. We will probably also see > attempts by some major entities, just like e.g. Microsoft Network, to set > their own standards and believe they are big enough to force others to ad= apt > to those standards, and we will probably, just as was the case with > Microsoft Network, see those attempts fail. > > In the beginning, there will probably be a few major players with a head > starts and server parks, and a multitude of small players, running their > pieces of the virtual world using e.g. OpenSimulator, on their desktop or > laptop computers. Many of the small players will probably have the very > simple policy of "If you want to connect, welcome, regardless of your > credentials, but if you misbehave I will kick you out." In time, some of > those small players will grow because they serve interesting content or > create social networks with many users/visitors. Most of them will probab= ly > see a need to develop more strict policies to enable administration of th= eir > services at all, so they don't have to spend all day kicking abusers > returning time after time with new identities, disrupting the experience = for > other users. > > Those service and domain managers requesting some kind of trust domain to > allow others using or connecting to their services and domains will eithe= r > cut themselves off from all those small players running their domains or > services home in their kitchen or cupboard, ease up on their demands for > domains of trust, or simplify the procedure so that the necessary domain = of > trust can be established via electronic signatures on the first connectio= n. > If they choose to remain cut off from the rest of the metaverse, they wil= l > probably soon be forgotten islands in the sea of tens or hundreds of > thousands minor domains and services interoping more freely. > > The point is that the VWRAP protocol will not proscribe how you should ru= n > your service, open or as a walled garden, small or big. It will permit yo= u > to interop to the degree you chose yourself, not forcing you to interop a= ny > more or less than that. Other factors, like international law, national > legislation, ISP TOS, organization policies and such, may force you to se= t > limitations or raise requirements on with who and how you interop, but VW= RAP > should offer you the tool to do so, regardless of if you want, or are > forced, to run a strictly regulated walled garden alone or including a fe= w > trusted peers, by supporting the communication needed for > policy-enforcement, or run a no-holds-barred free-for-everyone operation,= by > not requiring the use of any policy-support whatsoever. > > Best regards, > > Magnus > > > - -----Ursprungligt meddelande----- > Fr=E5n: Morgaine [mailto:morgaine.dinova@googlemail.com] > > Skickat: den 8 oktober 2009 11:42 > Till: Magnus Zeisig > Kopia: ogpx@ietf.org > =C4mne: Re: [ogpx] Protocol for permitting policy decisions > > Magnus, > > If ADs are involved in region policy, then in the multi-world deployment > pattern, AD2 will have to be consulted when agent A1 teleports from RD1 t= o > RD2, because AD2 will be involved in region policy too. It's symmetric w= ith > AD1. > > This is what Joshua wanted to avoid, and it can only be avoided by not > giving ADs policy control over regions, otherwise symmetry requires that = AD2 > be consulted as well. > > It's this kind of problem that reinforces what David's been saying about > the right mess we currently have when talking about domains determining > policy. The AD/RD split was reasonably adequate when OGP was only extend= ing > a single world with policy-free regions, but it is insufficient to do a g= ood > job once we get into multi-world deployments with more complex service an= d > policy patterns which require much more flexibility. > > > Morgaine. > > > -----BEGIN PGP SIGNATURE----- > Version: 9.8.3 (Build 4028) > Charset: utf-8 > > wsBVAwUBSs3BOO5MlU9XyaiSAQj2yQgAjrwKp/YhSe+o8klsPg/LV+G6XS1LaBh9 > 2kEc31liqvttvOHYoRdhrCMT2Yh5F0PKjb/daDqK/3duTgTbz277sZS+P5xnfzxr > gsJN4Y//kuKcdmc3rQTaYafo9azl4JslPKNiQ2lSTcKDwAA1jn5hamBuiP1TdxQD > 1GQH4zhOPvEkfPJKCW4yGJdyp30dYdYFv6Ka/Rl5vAesPXStmpoBQ6x9fxtSpvVT > VV6YMJyEUYCnU+1voGO/rCJt1AKNJCOUnCXx0N+a5Xrix0oW7azx3xw6G6/RCuVv > GY+lweiE/bqfTb4Qr8/edV4Ffey2fo21plKABQ5worpGKL9/kfg2iw=3D=3D > =3D1YBE > -----END PGP SIGNATURE----- > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0015175cd1303a43e104757e5c9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Maybe mostly out of protocol, but depicting the situation very well!
-V= aughn

On Thu, Oct 8, 2009 at 12:38 PM, Ma= gnus Zeisig <m= agnus.zeisig@iis.se> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
=A0
In the future I think we will have a VWRAP metaverse similar to how th= e web works today. The VWRAP protocol will enable both private persons and = major organizations to set up and interop, to the degree each entity wants,= their own corner of the virtual world with the rest of that world. Just like on the web, we will see entiti= es running "intra-metaverses", totally shut off or only to a limi= ted degree open to the public. We will probably also see attempts by some m= ajor entities, just like e.g. Microsoft Network, to set their own standards and believe they are big enough to force others = to adapt to those standards, and we will probably, just as was the case wit= h Microsoft Network, see those attempts fail.
=A0
In the beginning, there will probably be a few major players with a he= ad starts and server parks, and a multitude of small players, running their= pieces of the virtual world using e.g. OpenSimulator, on their desktop or = laptop computers. Many of the small players will probably have the very simple policy of "If you want to c= onnect, welcome, regardless of your credentials, but if you misbehave I wil= l kick you out." In time, some of those small players will grow becaus= e they serve interesting content or create social networks with many users/visitors. Most of them will probably see a = need to develop more strict policies to enable administration of their serv= ices at all, so they don't have to spend all day kicking abusers return= ing time after time with new identities, disrupting the experience for other users.
=A0
Those service and domain managers requesting some kind of trust domain= to allow others using or connecting to their services and domains will eit= her cut themselves off from all those small players running their domains o= r services home in their kitchen or cupboard, ease up on their demands for domains of trust, or simplify the= procedure so that the necessary domain of trust can be established via ele= ctronic signatures on the first connection. If they choose to remain cut of= f from the rest of the metaverse, they will probably soon be forgotten islands in the sea of tens or hundreds= of thousands minor domains and services interoping more freely.
=A0
The point is that the VWRAP protocol will not proscribe how you should= run your service, open or as a walled garden, small or big. It will permit= you to interop to the degree you chose yourself, not forcing you to intero= p any more or less than that. Other factors, like international law, national legislation, ISP TOS, organizatio= n policies and such, may force you to set limitations or raise requirements= on with who and how you interop, but VWRAP should offer you the tool to do= so, regardless of if you want, or are forced, to run a strictly regulated walled garden alone or including= a few trusted peers, by supporting the communication needed for policy-enf= orcement, or run a no-holds-barred free-for-everyone operation, by not requ= iring the use of any policy-support whatsoever.
=A0
Best regards,
=A0
Magnus
=A0
=A0
- -----Ursprungligt meddelande-----
Skickat: den 8 oktober 2009 11:42
Till: Magnus Zeisig
=C4mne: Re: [ogpx] Protocol for permitting policy decisions
=A0
Magnus,
=A0
If ADs are involved in region policy, then in the multi-world deployme= nt pattern, AD2 will have to be consulted when agent A1 teleports from RD1 = to RD2, because AD2 will be involved in region policy too.=A0 It's symm= etric with AD1.
=A0
This is what Joshua wanted to avoid, and it can only be avoided by not= giving ADs policy control over regions, otherwise symmetry requires that A= D2 be consulted as well.
=A0
It's this kind of problem that reinforces what David's been sa= ying about the right mess we currently have when talking about domains dete= rmining policy.=A0 The AD/RD split was reasonably adequate when OGP was onl= y extending a single world with policy-free regions, but it is insufficient to do a good job once we get into multi-wor= ld deployments with more complex service and policy patterns which require = much more flexibility.
=A0
=A0
Morgaine.
=A0
=A0
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8
=A0
wsBVAwUBSs3BOO5MlU9XyaiSAQj2yQgAjrwKp/YhSe+o8klsPg/LV+G6XS1LaBh9
2kEc31liqvttvOHYoRdhrCMT2Yh5F0PKjb/daDqK/3duTgTbz277sZS+P5xnfzxr
gsJN4Y//kuKcdmc3rQTaYafo9azl4JslPKNiQ2lSTcKDwAA1jn5hamBuiP1TdxQD
1GQH4zhOPvEkfPJKCW4yGJdyp30dYdYFv6Ka/Rl5vAesPXStmpoBQ6x9fxtSpvVT
VV6YMJyEUYCnU+1voGO/rCJt1AKNJCOUnCXx0N+a5Xrix0oW7azx3xw6G6/RCuVv
GY+lweiE/bqfTb4Qr8/edV4Ffey2fo21plKABQ5worpGKL9/kfg2iw=3D=3D
=3D1YBE
-----END PGP SIGNATURE-----
=A0
=A0

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--0015175cd1303a43e104757e5c9b-- From infinity@lindenlab.com Fri Oct 9 06:38:02 2009 Return-Path: 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 4DB3C28C150; Fri, 9 Oct 2009 06:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 TriAzMm-mES0; Fri, 9 Oct 2009 06:38:01 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id DD63E28C0DD; Fri, 9 Oct 2009 06:38:00 -0700 (PDT) Received: by pxi6 with SMTP id 6so7787072pxi.32 for ; Fri, 09 Oct 2009 06:39:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.75.17 with SMTP id x17mr219377wfa.154.1255095583099; Fri, 09 Oct 2009 06:39:43 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <20091008235638.GE13882@alinoe.com> From: "Infinity Linden (Meadhbh Hamrick)" Date: Fri, 9 Oct 2009 06:39:23 -0700 Message-ID: <3a880e2c0910090639v281c96ebq379b8ce6a8400281@mail.gmail.com> To: David W Levine Content-Type: multipart/alternative; boundary=001636e1fb6063cdf5047580b68c Cc: ogpx-bounces@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 13:38:02 -0000 --001636e1fb6063cdf5047580b68c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 8, 2009 at 21:16, David W Levine wrote: > > I actually kind of defy anyone to impose a policy on a separately hosted > remote service. Policy is enforced locally, Attempting to make other > software components obey a > policy you have is pretty much a non starter. +1. i don't know how we got off on talking about distributed policy, but yes, in my view of the world, "policy" describes the decisions that a domain's authorities have made for a particular entity accessing resources via service interfaces, not the description of decisions that one domain's authority wants services in another domain to make. > You can request they do things, and you can insist they exhibit certain > properties when choosing to interact with them, but > you get no say in their workings. (Yes, there are systems with remote > policy execution engines and such, but they still don't impose the policies > on the services which use > them, the services chose to invoke them) > > - David > ~ Zha > > > > > > *Morgaine * > Sent by: ogpx-bounces@ietf.org > > 10/09/2009 12:10 AM > To > "ogpx@ietf.org" > cc > Subject > Re: [ogpx] Protocol for permitting policy decisions > > > > > On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <*carlo@alinoe.com*> > wrote: > > Morgaine, > > I'm pretty sure nobody on this list wants AD2 to be involved in anyway. > > > Yes, I think that everybody agrees with this, which is why I'm making sure > that the implications are understood. > > I am highlighting this point of logic very strongly so that it is clear to > everyone that *if we don't want AD2 to be consulted, then AD1 cannot be > allowed to express region policy*. *AT ALL. EVER.* UNDER ANY > CIRCUMSTANCES. > > Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to be > consulted, :-) > > I hope we can end this here with total agreement. :-) > > I will however be referring back to this point if someone tries to give AD1 > the power to set region policy over RD2. If that happens, then we're back > to consulting AD2, no alternative, because W2 is not in any way inferior to > W1. > > It's a crucial point, because it establishes *a limit to the power of an > AD*. Think of it as a mini Constitution. ;-) > > > Morgaine. > > > > > > > > > =================================== > > > On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <*carlo@alinoe.com*> > wrote: > On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wrote: > > Magnus, > > > > If ADs are involved in region policy, then in the multi-world deployment > > pattern, AD2 will have to be consulted when agent A1 teleports from RD1 > to RD2, > > because AD2 will be involved in region policy too. It's symmetric with > AD1. > > Morgaine, > > I'm pretty sure nobody on this list wants AD2 to be involved in anyway. > I'm also convinced that there is some misunderstanding involved here, > and it would be good to correct that... > > The following isn't consensus yet, but I feel it's basically the truth, > and written down here as such because at least it is simple: > > In the end there are only services. Services can be grouped as 'domain' > to make clear they are run by the same authority and therefore likely > will have use the same policies, but for the sake of the protocol you > can ignore that. > > There are several types of services, so far we only concentrated on two > types: > > 1) A region (R1, R2, ...) > 2) An authentication service (A1, A2, ...) > > in principle, every service can be run by a different authority and thus > have different policies. > > One user only uses a single authentication service at a time, every other > authentication service is not relevant (for that user). > > If a user wants to teleport from R1 to R2, while using A3, only A3 and R2 > have a say in this. > > The only say that A3 has is true or false: yes or no allow the user to go > to R2. Once the user gets into R2, no policy of A3 matters anymore. > > It makes no sense whatsoever to group A's with R's for the sake of > understanding > or designing the protocol. > > For a teleport decision (or initial connect) only ONE Agent service and ONE > region are involved. > > Almost every policy (of both parties) can be negotiated out of band, > yet some of us (including me) are arguing that we need to keep the > possibility > open for a region to change some abstract policies (based on trusted > information > from the agent service) more real-time. Here trust is needed in both > directions: > the region must trust the agent service to answer it's questions correctly > and the agent service must trust the region not to fool it into allowing > users in that the agent service based on it's own policy doesn't want to > allow in. > > -- > Carlo Wood <*carlo@alinoe.com* > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --001636e1fb6063cdf5047580b68c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 8, 2009 at 21:16, David W Levine <dwl@us.ibm.com>= wrote:

I actually kind of defy anyone to = impose a policy on a separately hosted remote service. Policy is enforced locally, Attempting to make other software components obey a
policy you have is pretty much a n= on starter.

+1. i don't know how we= got off on talking about distributed policy, but yes, in my view of the wo= rld, "policy" describes the decisions that a domain's authori= ties have made for a particular entity accessing resources via service inte= rfaces, not the description of decisions that one domain's authority wa= nts services in another domain to make.
=A0
You can request they do things, and you can insist they exhibit certain properties when choosing to interact with them, but
you get no say in their workings. = =A0(Yes, there are systems with remote policy execution engines and such, but they still don't impose the policies on the services which use
them, the services chose to invoke= them)

- David
~ Zha





Morgaine <morgaine.dinova@googlemail.com>
Sent by: <= a href=3D"mailto:ogpx-bounces@ietf.org" target=3D"_blank">ogpx-bounces@ietf= .org

10/09/2009 12:10 AM

To
"ogpx@ietf.org" <<= a href=3D"mailto:ogpx@ietf.org" target=3D"_blank">ogpx@ietf.org>
cc
Subject
Re: [ogpx] Protocol for= permitting policy decisions





On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <carlo@alinoe.com> wrote:

Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.=


Yes, I think that everybody agrees with this, which is why I'm making s= ure that the implications are understood.

I am highlighting this point of logic very strongly so that it is clear to everyone that if we don't want AD2 to be consulted, then AD1 cann= ot be allowed to express region policy.=A0 AT ALL.=A0 EVER.=A0 UNDER ANY CIRCUMSTANCES.

Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to be consulted, :-)

I hope we can end this here with total agreement. :-)

I will however be referring back to this point if someone tries to give AD1 the power to set region policy over RD2.=A0 If that happens, then we're back to consulting AD2, no alternative, because W2 is not in any way inferior to W1.

It's a crucial point, because it establishes a limit to the power of an AD.=A0 Think of it as a mini Constitution. ;-)


Morgaine.








=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <carlo@alinoe.com> wrote:
On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wro= te:
> Magnus,
>
> If ADs are involved in region policy, then in the multi-world deployme= nt
> pattern, AD2 will have to be consulted when agent A1 teleports from RD1 to RD2,
> because AD2 will be involved in region policy too. =A0It's symmetr= ic with AD1.
Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.=
I'm also convinced that there is some misunderstanding involved here, and it would be good to correct that...

The following isn't consensus yet, but I feel it's basically the tr= uth,
and written down here as such because at least it is simple:

In the end there are only services. Services can be grouped as 'domain&= #39;
to make clear they are run by the same authority and therefore likely
will have use the same policies, but for the sake of the protocol you
can ignore that.

There are several types of services, so far we only concentrated on two
types:

1) A region (R1, R2, ...)
2) An authentication service (A1, A2, ...)

in principle, every service can be run by a different authority and thus have different policies.

One user only uses a single authentication service at a time, every other authentication service is not relevant (for that user).

If a user wants to teleport from R1 to R2, while using A3, only A3 and R2
have a say in this.

The only say that A3 has is true or false: yes or no allow the user to go
to R2. Once the user gets into R2, no policy of A3 matters anymore.

It makes no sense whatsoever to group A's with R's for the sake of = understanding
or designing the protocol.

For a teleport decision (or initial connect) only ONE Agent service and ONE
region are involved.

Almost every policy (of both parties) can be negotiated out of band,
yet some of us (including me) are arguing that we need to keep the possibil= ity
open for a region to change some abstract policies (based on trusted inform= ation
from the agent service) more real-time. Here trust is needed in both direct= ions:
the region must trust the agent service to answer it's questions correc= tly
and the agent service must trust the region not to fool it into allowing users in that the agent service based on it's own policy doesn't wa= nt to
allow in.

--
Carlo Wood <carlo@alinoe.com>
____= ___________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx=


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--001636e1fb6063cdf5047580b68c-- From morgaine.dinova@googlemail.com Fri Oct 9 07:29:35 2009 Return-Path: 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 2454428C164 for ; Fri, 9 Oct 2009 07:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.286 X-Spam-Level: X-Spam-Status: No, score=-0.286 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, TRACKER_ID=2.003] 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 dBWEmAmvEErY for ; Fri, 9 Oct 2009 07:29:33 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 6380F28C170 for ; Fri, 9 Oct 2009 07:29:32 -0700 (PDT) Received: by ewy4 with SMTP id 4so665223ewy.37 for ; Fri, 09 Oct 2009 07:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=6ert15QUl8pHySWWp+mDmnSx+dY9PBIRfupruefItZ4=; b=u7ldynxFoPWbpmxDZuLTpmyFPoxV2ZkYcQJobf2MiQ3c8cFFTxdw0RZ4fAcvTvyKoW QudqXYWoNIZDKZD8HME2S6eeNNCefYgtSYdWez7zoGpQDJPLAsQQeA0BcG00fJc+fdMF mnaaVWJsLnNMLnry2SlxpB1p8KJJZXB2jygzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ufUwDKsUj7yu9tDeOS74zIifIMVbP84zdWoSKqAPIVBVKBtNRPD63DgZzQb+pngY46 j8hhW0jZgC7xRHsqrGq+cixzJGlnFYZtRalOMyKBV40eUNFNZMjLh1uQmoXvoaLxfGZG vj4dD0Jj/gdbXkPFOtl8QeqlE+gHVGiW5A/n0= MIME-Version: 1.0 Received: by 10.210.2.19 with SMTP id 19mr3265171ebb.94.1255098671658; Fri, 09 Oct 2009 07:31:11 -0700 (PDT) In-Reply-To: <983F17705339E24699AA251B458249B50CC48CB8B6@EXCHANGE2K7.office.nic.se> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B50CC48CB6E2@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B50CC48CB7BF@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B50CC48CB8B6@EXCHANGE2K7.office.nic.se> Date: Fri, 9 Oct 2009 15:31:10 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cdff6f67b7b470475816e67 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 14:29:35 -0000 --000e0cdff6f67b7b470475816e67 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 9, 2009 at 10:43 AM, Magnus Zeisig wrote= : > > Morgaine, I think I understood your meaning with the first example, and I > also think I do it with the second example. > Cool. :-) I'll assume the point's taken then. If any doubt seems to remain then we can beat it into submission in private mails. :-) Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Fri, Oct 9, 2009 at 10:43 AM, Magnus Zeisig wrote= : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Morgaine, I think I understood your meaning with the first example, and I > also think I do it with the second example. And I still see no requiremen= t > for your symmetry, or whatever you prefer to call it. Let's recapitulate = so > people don't need to browse back. An agent using AD1 wants to teleport (T= P) > from VW1, consisting of AD1 and RD1, to VW2, consisting of AD2 and RD2. > > For the TP to happen, AD1 needs to agree to try the TP because it's used = by > the agent. RD2 needs to accept the TP because it will handle the agent's > presence. RD1 should have no say since it will not be used by or handle t= he > agent. AD2 should have no say since it will not be used by or handle the > agent. That's my idea of perfect symmetry, but... > > Assume that AD1 or RD2 for the reason of "symmetry", or something else, > wants AD2 to have a say about the TP. Since AD1 and RD2 are the only > entities involved with the agent after TP, they are the only ones who sho= uld > be able to make that call, except for the agent itself, e.g. if it would > like AD2 to act Net-Nanny. Then I believe this is how it should work. > > Case 1: Agent (ID1) wants to consult AD2 about TP: > > ID1 --(ID1, TP RD2?)-> AD2 > AD2 --(ID, )-> RD2 > RD2 --(ID, )-> AD2 > AD2 --(ID1, , TP RD2 OK)-> ID1 > ID1 --(ID1, TP RD2)-> AD1 > AD1 --(ID1, )-> RD2 > RD2 --(ID1, ID1key2 range?>)-> AD1 > AD1 --(ID1, )-> RD2 > RD2 --(ID1, , rez cap)-> AD1 > > Case 2: AD1 wants to consult AD2 about TP: > > ID1 --(ID1, TP RD2)-> AD1 > AD1 --(ID, TP RD2?)-> AD2 > AD2 --(ID, )-> AD1 > AD1 --(ID, )-> AD2 > AD2 --(ID, , TP RD2 OK)-> AD1 > AD1 --(ID1, )-> RD2 > RD2 --(ID1, ID1key2 range?>)-> AD1 > AD1 --(ID1, )-> RD2 > RD2 --(ID1, , rez cap)-> AD1 > > Case 3: RD2 wants to consult AD2 about TP: > > ID1 --(ID1, TP RD2)-> AD1 > AD1 --(ID1, )-> RD2 > RD2 --(ID, rez cap?)-> AD2 > AD2 --(ID, )-> RD2 > RD2 --(ID1, ID1key2 range?>)-> AD1 > AD1 --(ID1, )-> RD2 > RD2 --(ID, )-> AD2 > AD2 --(ID, , rez cap OK)-> RD2 > RD2 --(ID1, , rez cap)-> AD1 > > The calling domain or service should never be forced to call more than on= e > (the receiving) domain or service, but it could choose to do so (Cases 1 = and > 2). What happens behind the endpoint it sees is really none of its busine= ss > (Case 3). > In cases 2 and 3, much of the extra hand-shaking could be replaced by > pre-arranged agreements or duplication of policies, and may also require > pre-arranged domains of trust. > The VWRAP protocol may be used for the consulting as well, if it's assume= d > to have the generalized form suggested in my previous post ( > http://www.ietf.org/mail-archive/web/ogpx/current/msg00538.html). > The consulting could be made the same way regardless of if the domains or > services are controlled by the same entity or not. > Actually, AD2 could be AD3 or service4762, without any administrative > connection whatsoever with AD1, RD1 or RD2 (or AD2, if it still exists an= d > forms VW2 with RD2). > Note that the consulting domain or service doesn't have to reveal the > identity of the calling agent, domain or service to the consulted domain = or > service. > > Best regards, > > Magnus > > > - -----Ursprungligt meddelande----- > Fr=E5n: Morgaine [mailto:morgaine.dinova@googlemail.com] > > Skickat: den 9 oktober 2009 05:53 > Till: Magnus Zeisig > Kopia: ogpx@ietf.org > =C4mne: Re: [ogpx] Protocol for permitting policy decisions > > Magnus, I believe that we're fairly close on everything except the single > issue of "symmetry", because you still think that I'm talking about > deployment symmetry whereas I'm not at all, I'm talking about definition > symmetry. However, I think I've found another way of expressing it that > might come across better --- I'll focus on CODE. Let's try this new > approach instead. :-) > > Protocols aren't much use until they have been encoded in programs. A > program that implements a given protocol fully is written to be able to > handle all the possible deployment patterns of that protocol. This allow= s > the program to be used in many different situations to suit local > requirements. Such a program is NOT written to suit one single deploymen= t > pattern --- that would be inefficient. Consequently the code that is > written is determined by the definition of the protocol and the definitio= n > of the entities in the protocol. The code that is written is NOT determi= ned > by the chosen deployment, I hope that's clear. > > So now let's get back to ADs. We don't want ADs to carry region policy, > but let's examine what happens if ADs are defined to do so. > > If ADs are defined to specify region policy, then a program that needs t= o > know about region policy would have to check the ADs --- there is no > escaping that. It would not be protocol-compliant if it did not check th= e > ADs. The deployment patterns in W1 and W2 (which could be completely > different) are of no relevance whatsoever in this --- the program would > still have to check for the presence of ADs in both worlds just in case t= he > ADs exist, and all those ADs that exist would have to be queried for regi= on > policy because we've defined that region policy is carried by ADs. If th= e > program did not check both ADs then it could be missing part of the regio= n > policy. :-) > > See what I mean by definition symmetry now? However you define an AD, th= at > definition always applies to both ADs in a 2-world deployment if they > exist. The definition can never apply only to one world --- it should be > clear that "ADs carry region policies, but the region policies in my AD a= re > valid while the region policies in your AD will be ignored" is completely > bogus. :-) In protocol terms, this would be non-compliant because part o= f > the region policy would be missed. > > As a result of this definitional symmetry, the only way we're going to be > able to avoid consulting AD2 is our little example scenario is by not > allowing ADs to express region policy at all, because if AD1 is allowed t= o > express region policy then AD2 is allowed to express it as well, and henc= e > the program must try to consult AD2 for its region policy, by definition = of > AD. It's very strong logic, and it has nothing to do with the chosen > deployments, because it applies in case AD2 exists. > > Of course, as you pointed out, there are many more realistic deployments > out there, but this simple one is all that's needed to invalidate the ide= a > that AD1 can express region policy while AD2 can be present but ignored. > That cannot happen unless the protocol explicitly defines asymmetric > relationships, which is not true in our case and cannot be true given tha= t > W1 and W2 are peers. > > That's all I wanted to describe in this particular reply. I hope the poi= nt > was clearer this time. :-) > > > Morgaine. > > > -----BEGIN PGP SIGNATURE----- > Version: 9.8.3 (Build 4028) > Charset: utf-8 > > wsBVAwUBSs8FtO5MlU9XyaiSAQg8HAf8DHf30qo45JVvrYJ6Vv2essw+MJ1Rbkjk > BA34EazFEnqoR3krpD5ZOJrYVuG7HbUqBOz8Rl7p4l9lWZBkeeWnpeAk40gCHxNP > 8fE0cCnDT+n5XShzetNPo7H/VskJ3/niXWMrmI295DwErCKInzelkjUaI/9TgiSi > DOIwoPMQDPzrn3YM6vvBtDODjoTkajNRP+D5++XDE5gyZ3EJacl4KCOMqkz5ai1B > XUW5osTLTaDiFDF69QtJIwdl8/BTzN1OsUlBCFC+XlaWK2TgSnXMm1DQ8EWk3iHQ > DJ0VlRWpJJkmQVWZMsrGivjZi2WaeI3YlsxxCTbAeOaM7Jqvc0EPiw=3D=3D > =3DKZF3 > -----END PGP SIGNATURE----- > > > --000e0cdff6f67b7b470475816e67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 9, 2009 at 10:43 AM, Magnus Zeisig <magnus.zeisig@iis.se> wrote= :

Morgaine, = I think I understood your meaning with the first example, and I also think = I do it with the second example.


Coo= l.=A0 :-) =A0 I'll assume the point's taken then.=A0 If any doubt s= eems to remain then we can beat it into submission in private mails. :-)

Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

On Fri, Oct 9, 2009 at 10:43 AM, Magn= us Zeisig <mag= nus.zeisig@iis.se> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
=A0
Morgaine, I think I understood your meaning with the first examp= le, and I also think I do it with the second example. And I still see no re= quirement for your symmetry, or whatever you prefer to call it. Let's r= ecapitulate so people don't need to browse back. An agent using AD1 wants to teleport (TP) from VW1, consisting of AD1= and RD1, to VW2, consisting of AD2 and RD2.
=A0
For the TP to happen, AD1 needs to agree to try the TP because it'= s used by the agent. RD2 needs to accept the TP because it will handle the = agent's presence. RD1 should have no say since it will not be used by o= r handle the agent. AD2 should have no say since it will not be used by or handle the agent. That's my idea of per= fect symmetry, but...
=A0
Assume that AD1 or RD2 for the reason of "symmetry", or some= thing else, wants AD2 to have a say about the TP. Since AD1 and RD2 are the= only entities involved with the agent after TP, they are the only ones who= should be able to make that call, except for the agent itself, e.g. if it would like AD2 to act Net-Nanny. Then I be= lieve this is how it should work.
=A0
Case 1: Agent (ID1) wants to consult AD2 about TP:
=A0
ID1 --(ID1, TP RD2?)-> AD2
AD2 --(ID, <RD2key1?, RD2key2?>)-> RD2
RD2 --(ID, <RD2value1, RD2value2>)-> AD2
AD2 --(ID1, <RD2values OK>, TP RD2 OK)-> ID1
ID1 --(ID1, TP RD2)-> AD1
AD1 --(ID1, <RD2key1?, RD2key2?>)-> RD2
RD2 --(ID1, <RD2value1, RD2value2, AD1key1?, AD1key2?, ID1key1 rang= e?, ID1key2 range?>)-> AD1
AD1 --(ID1, <RD2values OK, AD1value1, AD1value2, ID1keys OK>)-&g= t; RD2
RD2 --(ID1, <AD1values OK>, rez cap)-> AD1
=A0
Case 2: AD1 wants to consult AD2 about TP:
=A0
ID1 --(ID1, TP RD2)-> AD1
AD1 --(ID, TP RD2?)-> AD2
AD2 --(ID, <AD1key1?, AD1key2?, IDkey1 range?, IDkey2 range?>)-&= gt; AD1
AD1 --(ID, <AD1value1, AD1value2, IDkeys OK>)-> AD2
AD2 --(ID, <AD1values OK>, TP RD2 OK)-> AD1
AD1 --(ID1, <RD2key1?, RD2key2?>)-> RD2
RD2 --(ID1, <RD2value1, RD2value2, AD1key1?, AD1key2?, ID1key1 rang= e?, ID1key2 range?>)-> AD1
AD1 --(ID1, <RDvalues OK, AD1value1, AD1value2, ID1keys OK>)->= ; RD2
RD2 --(ID1, <AD1values OK>, rez cap)-> AD1
=A0
Case 3: RD2 wants to consult AD2 about TP:
=A0
ID1 --(ID1, TP RD2)-> AD1
AD1 --(ID1, <RD2key1?, RD2key2?>)-> RD2
RD2 --(ID, rez cap?)-> AD2
AD2 --(ID, <ADkey1?, ADkey2?, IDkey1 range?, IDkey2 range?>)->= ; RD2
RD2 --(ID1, <RD2value1, RD2value2, AD1key1?, AD1key2?, ID1key1 rang= e?, ID1key2 range?>)-> AD1
AD1 --(ID1, <RDvalues OK, AD1value1, AD1value2, ID1keys OK>)->= ; RD2
RD2 --(ID, <ADvalue1, ADvalue2, IDkeys OK>)-> AD2
AD2 --(ID, <ADvalues OK>, rez cap OK)-> RD2
RD2 --(ID1, <AD1values OK>, rez cap)-> AD1
=A0
The calling domain or service should never be forced to call more than= one (the receiving) domain or service, but it could choose to do so (Cases= 1 and 2). What happens behind the endpoint it sees is really none of its b= usiness (Case 3).
In cases 2 and 3, much of the extra hand-shaking could be replaced by = pre-arranged agreements or duplication of policies, and may also require pr= e-arranged domains of trust.
The VWRAP protocol may be used for the consulting as well, if it's= assumed to have the generalized form suggested in my previous post (http://www.ietf.org/mail-archive/web/ogpx/current/msg00538.htm= l).
The consulting could be made the same way regardless of if the domains= or services are controlled by the same entity or not.
Actually, AD2 could be AD3 or service4762, without any administrative = connection whatsoever with AD1, RD1 or RD2 (or AD2, if it still exists and = forms VW2 with RD2).
Note that the consulting domain or service doesn't have to reveal = the identity of the calling agent, domain or service to the consulted domai= n or service.
=A0
Best regards,
=A0
Magnus
=A0
=A0
- -----Ursprungligt meddelande-----
Skickat: den 9 oktober 2009 05:53
Till: Magnus Zeisig
=C4mne: Re: [ogpx] Protocol for permitting policy decisions
=A0
Magnus, I believe that we're fairly close = on everything except the single issue of "symmetry", because you = still think that I'm talking about deployment symmetry whereas I'm = not at all, I'm talking about definition symmetry.=A0 However, I think = I've found another way of expressing it that might come across better --- I'll foc= us on CODE.=A0 Let's try this new approach instead. :-)
=A0
Protocols aren't much use until they have been encoded in programs= .=A0 A program that implements a given protocol fully is written to be able= to handle all the possible deployment patterns of that protocol.=A0 This a= llows the program to be used in many different situations to suit local requirements.=A0 Such a program is NOT written to = suit one single deployment pattern --- that would be inefficient.=A0 Conseq= uently the code that is written is determined by the definition of the prot= ocol and the definition of the entities in the protocol.=A0 The code that is written is NOT determined by the chose= n deployment, I hope that's clear.
=A0
So now let's get back to ADs.=A0 We don't want ADs to carry re= gion policy, but let's examine what happens if ADs are defined to do so= .
=A0
If ADs are defined to specify region policy, then a program that need= s to know about region policy would have to check the ADs --- there is no e= scaping that.=A0 It would not be protocol-compliant if it did not check the= ADs.=A0 The deployment patterns in W1 and W2 (which could be completely different) are of no relevance whatsoe= ver in this --- the program would still have to check for the presence of A= Ds in both worlds just in case the ADs exist, and all those ADs that exist = would have to be queried for region policy because we've defined that region policy is carried by ADs.=A0 I= f the program did not check both ADs then it could be missing part of the r= egion policy. :-)
=A0
See what I mean by definition symmetry now?=A0 However you define an A= D, that definition always applies to both ADs in a 2-world deployment if th= ey exist.=A0 The definition can never apply only to one world --- it should= be clear that "ADs carry region policies, but the region policies in my AD are valid while the region policies in you= r AD will be ignored" is completely bogus. :-)=A0 In protocol terms, t= his would be non-compliant because part of the region policy would be misse= d.
=A0
As a result of this definitional symmetry, the only way we're goin= g to be able to avoid consulting AD2 is our little example scenario is by n= ot allowing ADs to express region policy at all, because if AD1 is allowed = to express region policy then AD2 is allowed to express it as well, and hence the program must try to consult AD= 2 for its region policy, by definition of AD.=A0 It's very strong logic= , and it has nothing to do with the chosen deployments, because it applies = in case AD2 exists.
=A0
Of course, as you pointed out, there are many more realistic deploymen= ts out there, but this simple one is all that's needed to invalidate th= e idea that AD1 can express region policy while AD2 can be present but igno= red.=A0 That cannot happen unless the protocol explicitly defines asymmetric relationships, which is not true in = our case and cannot be true given that W1 and W2 are peers.
=A0
That's all I wanted to describe in this particular reply.=A0 I hop= e the point was clearer this time. :-)
=A0
=A0
Morgaine.
=A0
=A0
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8
=A0
wsBVAwUBSs8FtO5MlU9XyaiSAQg8HAf8DHf30qo45JVvrYJ6Vv2essw+MJ1Rbkjk=
BA34EazFEnqoR3krpD5ZOJrYVuG7HbUqBOz8Rl7p4l9lWZBkeeWnpeAk40gCHxNP
8fE0cCnDT+n5XShzetNPo7H/VskJ3/niXWMrmI295DwErCKInzelkjUaI/9TgiSi
DOIwoPMQDPzrn3YM6vvBtDODjoTkajNRP+D5++XDE5gyZ3EJacl4KCOMqkz5ai1B
XUW5osTLTaDiFDF69QtJIwdl8/BTzN1OsUlBCFC+XlaWK2TgSnXMm1DQ8EWk3iHQ
DJ0VlRWpJJkmQVWZMsrGivjZi2WaeI3YlsxxCTbAeOaM7Jqvc0EPiw=3D=3D
=3DKZF3
-----END PGP SIGNATURE-----
=A0
=A0

--000e0cdff6f67b7b470475816e67-- From josh@lindenlab.com Fri Oct 9 15:40:23 2009 Return-Path: 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 59F473A67FB for ; Fri, 9 Oct 2009 15:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 aF+El7-eMy6o for ; Fri, 9 Oct 2009 15:40:22 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 685623A6905 for ; Fri, 9 Oct 2009 15:40:22 -0700 (PDT) Received: by pxi6 with SMTP id 6so8216450pxi.32 for ; Fri, 09 Oct 2009 15:42:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.225.3 with SMTP id x3mr279628rvg.135.1255128125643; Fri, 09 Oct 2009 15:42:05 -0700 (PDT) Date: Fri, 9 Oct 2009 15:42:05 -0700 Message-ID: From: Joshua Bell To: ogpx Content-Type: multipart/alternative; boundary=000e0cd22f3a139d850475884a0d Subject: [ogpx] VWRAP Status X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 22:40:23 -0000 --000e0cd22f3a139d850475884a0d Content-Type: text/plain; charset=UTF-8 Now that we have consensus to bludgeon the policy conversation further only in private email for a while, how about a quick status check? Meetings: The next IETF meeting, IETF76, is coming up in a little under a month. In discussion among the co-chairs, area directors, and current slate of draft authors, we didn't feel that there were enough outstanding issues requiring a face-to-face meeting this soon after chartering the group. Given that other WGs needed time on the schedule, we've opted not to have a WG meeting this time. We expect to have plenty of issues that will benefit from face-to-face meetings (with mixed-reality components!) for the next several sessions. Should any issues arise which require broad working group input and cannot be resolved on the mailing list prior to the next session, http://www.ietf.org/iesg/statement/interim-meetings.html provide guidance on structuring such meetings. Again, at this point, the mailing list (and off-list pair-wise conversations) appear to be working sufficiently. Drafts: The charter calls out the goal of having the LLSD ('Abstract Type System for the Transmission of Dynamic Structured Data' - draft-hamrick-llsd-00) and Intro ('Introduction and Goals' - draft-hamrick-ogp-intro-00) drafts finished up and submitted by February 2010. Could the author of those drafts (that'd be you, Meadhbh) and the authors of other drafts referenced in the charter (Meadhbh/Infinity, David/Zha, Mark/Zero) comment for the group on the status of those drafts, what parts are under active work, when the next revisions should be expected, and what feedback and inputs are desired from group members at this time? Are any additional drafts being considered at this time by group members? Note that if anyone submits a new (-00) draft that they hope to have adopted by the working group, they should name it "draft-MYNAME-vwrap-OTHER-STUFF". That makes the tracking tools work better. The WG tools page ( http://tools.ietf.org/wg/vwrap/) will show them as related drafts, and if/when they become "draft-ietf-vwrap-OTHER-STUFF", the tools will understand that the WG version replaces the individual one. Thanks, Joshua (w/ input from Barry) --000e0cd22f3a139d850475884a0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Now that we have consensus to bludgeon the policy conversation further only= in private email for a while, how about a quick status check?

Meeti= ngs:

The next IETF meeting, IETF76, is coming up in a little under a= month. In discussion among the co-chairs, area directors, and current slat= e of draft authors, we didn't feel that there were enough outstanding i= ssues requiring a face-to-face meeting this soon after chartering the group= . Given that other WGs needed time on the schedule, we've opted not to = have a WG meeting this time. We expect to have plenty of issues that will b= enefit from face-to-face meetings (with mixed-reality components!) for the = next several sessions.

Should any issues arise which require broad working group input and can= not be resolved on the mailing list prior to the next session, http://www.ietf.or= g/iesg/statement/interim-meetings.html provide guidance on structuring = such meetings. Again, at this point, the mailing list (and off-list pair-wi= se conversations) appear to be working sufficiently.

Drafts:

The charter calls out the goal of having the LLSD ('= Abstract Type System for the Transmission of Dynamic Structured Data' -= draft-hamrick-llsd-00) and Intro ('Introduction and Goals' - draft= -hamrick-ogp-intro-00) drafts finished up and submitted by February 2010.
Could the author of those drafts (that'd be you, Meadhbh) and the a= uthors of other drafts referenced in the charter (Meadhbh/Infinity, David/Z= ha, Mark/Zero) comment for the group on the status of those drafts, what pa= rts are under active work, when the next revisions should be expected, and = what feedback and inputs are desired from group members at this time?

Are any additional drafts being considered at this time by group member= s?

Note that if anyone submits a new (-00) draft that they hope to h= ave adopted by the working group, they should name it "draft-MYNAME-vw= rap-OTHER-STUFF".=C2=A0 That makes the tracking tools work better.=C2= =A0 The WG tools page (http://t= ools.ietf.org/wg/vwrap/) will show them as related drafts, and if/when = they become "draft-ietf-vwrap-OTHER-STUFF", the tools will unders= tand that the WG version replaces the individual one.

Thanks,

Joshua (w/ input from Barry)


--000e0cd22f3a139d850475884a0d-- From infinity@lindenlab.com Fri Oct 9 16:14:19 2009 Return-Path: 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 3DEC23A69CF for ; Fri, 9 Oct 2009 16:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 q3jX7AJgswtp for ; Fri, 9 Oct 2009 16:14:18 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id D3BED3A679F for ; Fri, 9 Oct 2009 16:13:55 -0700 (PDT) Received: by pzk6 with SMTP id 6so3131679pzk.29 for ; Fri, 09 Oct 2009 16:15:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.8.38 with SMTP id 38mr240131wfh.58.1255130138150; Fri, 09 Oct 2009 16:15:38 -0700 (PDT) In-Reply-To: References: From: "Infinity Linden (Meadhbh Hamrick)" Date: Fri, 9 Oct 2009 16:15:18 -0700 Message-ID: <3a880e2c0910091615k4c77f5c4i682c26749403f4fe@mail.gmail.com> To: Joshua Bell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx Subject: Re: [ogpx] VWRAP Status X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 23:14:19 -0000 hey josh. intro and llsd have received a lot of input, so over the next three week's i'm going to be pushing out a new LLSD draft incorporating that feedback, so we can get a new round of discussions going before we have to have it finished. we're merging parts of david's deployment patterns draft into the intro draft. it also will be out soonish for comment. i'll work on an overview of what's changing on both documents for monday morning. -cheers -meadhbh On Fri, Oct 9, 2009 at 15:42, Joshua Bell wrote: > Now that we have consensus to bludgeon the policy conversation further on= ly > in private email for a while, how about a quick status check? > > Meetings: > > The next IETF meeting, IETF76, is coming up in a little under a month. In > discussion among the co-chairs, area directors, and current slate of draf= t > authors, we didn't feel that there were enough outstanding issues requiri= ng > a face-to-face meeting this soon after chartering the group. Given that > other WGs needed time on the schedule, we've opted not to have a WG meeti= ng > this time. We expect to have plenty of issues that will benefit from > face-to-face meetings (with mixed-reality components!) for the next sever= al > sessions. > > Should any issues arise which require broad working group input and canno= t > be resolved on the mailing list prior to the next session, > http://www.ietf.org/iesg/statement/interim-meetings.html provide guidance= on > structuring such meetings. Again, at this point, the mailing list (and > off-list pair-wise conversations) appear to be working sufficiently. > > Drafts: > > The charter calls out the goal of having the LLSD ('Abstract Type System = for > the Transmission of Dynamic Structured Data' - draft-hamrick-llsd-00) and > Intro ('Introduction and Goals' - draft-hamrick-ogp-intro-00) drafts > finished up and submitted by February 2010. > > Could the author of those drafts (that'd be you, Meadhbh) and the authors= of > other drafts referenced in the charter (Meadhbh/Infinity, David/Zha, > Mark/Zero) comment for the group on the status of those drafts, what part= s > are under active work, when the next revisions should be expected, and wh= at > feedback and inputs are desired from group members at this time? > > Are any additional drafts being considered at this time by group members? > > Note that if anyone submits a new (-00) draft that they hope to have adop= ted > by the working group, they should name it "draft-MYNAME-vwrap-OTHER-STUFF= ". > That makes the tracking tools work better.=A0 The WG tools page > (http://tools.ietf.org/wg/vwrap/) will show them as related drafts, and > if/when they become "draft-ietf-vwrap-OTHER-STUFF", the tools will > understand that the WG version replaces the individual one. > > Thanks, > > Joshua (w/ input from Barry) > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From alexey.melnikov@isode.com Fri Oct 9 16:23:02 2009 Return-Path: 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 C671D3A69FF for ; Fri, 9 Oct 2009 16:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] 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 rLxGyfAi0WGH for ; Fri, 9 Oct 2009 16:23:02 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BF0843A6A77 for ; Fri, 9 Oct 2009 16:23:01 -0700 (PDT) Received: from [92.40.79.44] (92.40.79.44.sub.mbb.three.co.uk [92.40.79.44]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 10 Oct 2009 00:24:46 +0100 Message-ID: <4ACFC2F4.3040105@isode.com> Date: Sat, 10 Oct 2009 00:10:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Joshua Bell References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ogpx Subject: Re: [ogpx] VWRAP Status X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 23:23:02 -0000 Hi Joshua, Joshua Bell wrote: > Note that if anyone submits a new (-00) draft that they hope to have > adopted by the working group, they should name it > "draft-MYNAME-vwrap-OTHER-STUFF". That makes the tracking tools work > better. The WG tools page (http://tools.ietf.org/wg/vwrap/) will show > them as related drafts, and if/when they become > "draft-ietf-vwrap-OTHER-STUFF", the tools will understand that the WG > version replaces the individual one. A small comment on "tool will understand that ...": I don't think this happens automatically. But the Secretariat can mark a WG draft as replacing an individual one. From dhc@dcrocker.net Fri Oct 9 19:02:58 2009 Return-Path: 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 1CD423A686E for ; Fri, 9 Oct 2009 19:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599] 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 OnAfJaJ0pS8Q for ; Fri, 9 Oct 2009 19:02:57 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7148]) by core3.amsl.com (Postfix) with ESMTP id DD1573A6A84 for ; Fri, 9 Oct 2009 19:02:56 -0700 (PDT) Received: from [192.168.1.107] (ppp-68-120-198-98.dsl.pltn13.pacbell.net [68.120.198.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n9A24ZPd021369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Oct 2009 19:04:41 -0700 Message-ID: <4ACFEBA8.6010508@dcrocker.net> Date: Fri, 09 Oct 2009 19:04:24 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ogpx References: <4ACFC2F4.3040105@isode.com> In-Reply-To: <4ACFC2F4.3040105@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/9878/Fri Oct 9 08:51:48 2009 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 09 Oct 2009 19:04:41 -0700 (PDT) Subject: Re: [ogpx] VWRAP Status X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 02:02:58 -0000 Alexey Melnikov wrote: >> Note that if anyone submits a new (-00) draft that they hope to have >> adopted by the working group, they should name it >> "draft-MYNAME-vwrap-OTHER-STUFF". That makes the tracking tools work >> better. The WG tools page (http://tools.ietf.org/wg/vwrap/) will show them >> as related drafts, and if/when they become "draft-ietf-vwrap-OTHER-STUFF", >> the tools will understand that the WG version replaces the individual one. > > A small comment on "tool will understand that ...": I don't think this > happens automatically. But the Secretariat can mark a WG draft as replacing > an individual one. The times I've been part of bringing a private draft into a working group, it required submitting a new draft under the draft-ietf-- label -- even if the text is identical with the the pre-working group version. (I don't know about the Secretariat marking step that Alexey references, but I believe it is in addition to, and after, the submission step I'm citing.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From alexey.melnikov@isode.com Sat Oct 10 05:46:30 2009 Return-Path: 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 A95723A68AB for ; Sat, 10 Oct 2009 05:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] 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 nD3ipdZqqHIt for ; Sat, 10 Oct 2009 05:46:29 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 8E8FB3A6838 for ; Sat, 10 Oct 2009 05:46:29 -0700 (PDT) Received: from [92.40.228.213] (92.40.228.213.sub.mbb.three.co.uk [92.40.228.213]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 10 Oct 2009 13:48:15 +0100 Message-ID: <4AD0827A.2090009@isode.com> Date: Sat, 10 Oct 2009 13:47:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: dcrocker@bbiw.net References: <4ACFC2F4.3040105@isode.com> <4ACFEBA8.6010508@dcrocker.net> In-Reply-To: <4ACFEBA8.6010508@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ogpx Subject: Re: [ogpx] VWRAP Status X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 12:46:30 -0000 Dave CROCKER wrote: > Alexey Melnikov wrote: > >>> Note that if anyone submits a new (-00) draft that they hope to have >>> adopted by the working group, they should name it >>> "draft-MYNAME-vwrap-OTHER-STUFF". That makes the tracking tools >>> work better. The WG tools page (http://tools.ietf.org/wg/vwrap/) >>> will show them as related drafts, and if/when they become >>> "draft-ietf-vwrap-OTHER-STUFF", >>> the tools will understand that the WG version replaces the >>> individual one. >> >> A small comment on "tool will understand that ...": I don't think >> this happens automatically. But the Secretariat can mark a WG draft >> as replacing >> an individual one. > > The times I've been part of bringing a private draft into a working > group, it > required submitting a new draft under the > draft-ietf-- > label -- even if the text is identical with the the pre-working group > version. Correct. I just realized that this might not be obvious to somebody new to IETF, so thank you for pointing this out. > (I don't know about the Secretariat marking step that Alexey > references, but I believe it is in addition to, and after, the > submission step I'm citing.) Yes. From vaughn.deluca@gmail.com Sat Oct 10 13:00:26 2009 Return-Path: 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 9B9A03A6805 for ; Sat, 10 Oct 2009 13:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 gUOQ6rHS-TJD for ; Sat, 10 Oct 2009 13:00:25 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 23F3C3A6830 for ; Sat, 10 Oct 2009 13:00:24 -0700 (PDT) Received: by bwz6 with SMTP id 6so2318274bwz.37 for ; Sat, 10 Oct 2009 13:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nY/9n2zDv+QoV06VGOSxifm/Jbrk5MywCG3QpOEo50E=; b=rw0s7K9ABoUuc0SOUY7vTzuH6lWeiQJ5owakpz3jLFoDYMxTc4HGbvFEJO795XKUYG ++EOy2MxOMMt6YNuUAJyKKcqcCe2tOadT11NkghvllMK6fQLWnc5aSwS2B0rx3GPv0ti DstgWm6+vjOCnCZl+axDyr79VSwa2FKvThriY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=roCSZN4Sh+9SJwAPHorT15yx9SOnYCj2DUJ2BNLoPna7KcZ/P5KYa4yBWjFXOvFDEo T4SrLDMlilCjGGmpnviSVFWasHS3OuVtxPB7C9LaZusQ41Gq/l1m6gEbM1HmNgK1FjAA 6ApOvzq+2dFxJMiMaBYzRgXhe1BuMtGMDuhYU= MIME-Version: 1.0 Received: by 10.204.153.27 with SMTP id i27mr3456299bkw.155.1255204928928; Sat, 10 Oct 2009 13:02:08 -0700 (PDT) In-Reply-To: References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156D0E@GVW0433EXB.americas.hpqcorp.net> Date: Sat, 10 Oct 2009 22:02:08 +0200 Message-ID: <9b8a8de40910101302l20c82ac5p4442ef12e568f5fd@mail.gmail.com> From: Vaughn Deluca To: Joshua Bell Content-Type: multipart/alternative; boundary=00151761ca58e8be1e04759a2bca Cc: "ogpx@ietf.org" Subject: Re: [ogpx] Reference material X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 20:00:26 -0000 --00151761ca58e8be1e04759a2bca Content-Type: text/plain; charset=ISO-8859-1 Does somebody have a suggestion were to start reading if i want to learn about the use and meaning of a "Public Region Seed Cap"? To put my question in context, i started with Davids layering document, working on the details of deployment pattern 5. I consulted the TP_draft_5, and used the high level description in that as a guide for my thinking. Looking at the details of the calls i stumbled over "Public Region Seed Cap". Before i start a random walk in the documentation, a call for some pointers here might save me some time. -Vaughn On Tue, Oct 6, 2009 at 10:06 PM, Joshua Bell wrote: > I made the trac/wiki updates in response to Mike's inquiry; your searching > skills are not at fault! > > Suggestions for other updates to the wiki are welcome. I cribbed the top > content to include from some other WGs. > > > On Tue, Oct 6, 2009 at 11:57 AM, Dickson, Mike (ISS Software) < > mike.dickson@hp.com> wrote: > >> were you looking at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ ? i >> >> know josh said that he's in the process of putting some content up >> >> there. >> >> >> >> -cheers >> >> -meadhbh >> >> -- >> >> >> >> Yep. I did find the charter just now as well so it should be easier for >> others to find these references. I don't recall seeing it before but I'm >> sure I just missed it. Now for some reading.... >> >> >> >> Mike >> >> >> >> >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00151761ca58e8be1e04759a2bca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Does somebody have a suggestion were to start reading if i want to learn ab= out the use and meaning of a "Public Region Seed Cap"?

To put my question in context, i started with Davids layering docu= ment, working on the details of deployment pattern 5. =A0I consulted the TP= _draft_5, and used the high level description in that as a guide for my thi= nking.=A0
Looking at the details of the calls i stumbled over=A0=A0"Public = Region Seed Cap". Before i start a random walk in the documentation, = =A0a call for some pointers here might save me some time.

-Vaughn



On Tue, Oct 6, 2009 at 10:06 PM, Joshua Bell <josh@lindenlab.com> wrote:
I made the trac/wiki updates in response to= Mike's inquiry; your searching skills are not at fault!

Suggest= ions for other updates to the wiki are welcome. I cribbed the top content t= o include from some other WGs.


On Tue, Oct 6, 2009 at 11:57 AM, Dickson, Mi= ke (ISS Software) <mike.dickson@hp.com> wrote:

were you looking at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ ? i

know josh said that he's in the process of putting some content up

there.

=A0

-cheers

-meadhbh

--

=A0

Yep.=A0 I did find the charter just now as well so it should be easier for others to find these references.=A0 I don't recall= seeing it before but I'm sure I just missed it.=A0=A0=A0 Now for some reading....=

=A0

Mike

=A0

=A0



_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00151761ca58e8be1e04759a2bca-- From vaughn.deluca@gmail.com Sun Oct 11 00:01:51 2009 Return-Path: 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 551923A6824 for ; Sun, 11 Oct 2009 00:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 9eN0K-iOFbzt for ; Sun, 11 Oct 2009 00:01:50 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id EAEE23A6781 for ; Sun, 11 Oct 2009 00:01:49 -0700 (PDT) Received: by bwz6 with SMTP id 6so2494971bwz.37 for ; Sun, 11 Oct 2009 00:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gWkJm6QclL+mTctbPFpGmt9rNPVtM4JUu+gly8e+izU=; b=ZPBgF2KQL8aOQQZWYsi8KvgkN2cf+wbQqCmhJ5jbuVwbBneo4yXaPo71ZSnSijo1EI 46cvxYbDVcOfVglbEDke5iTog5goNXa9QOi8pxwXVfy90Jf4w7AT6kCMLtZQPV1FmA82 X5B6yqO6yv773IdUfSG7E5aayunUv7zF1KzyA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=M3kh1RJ7GDTowz80xI+3EBzrZw3zQbRoGj/rvdZa40nucZgKh8L/73lKeMosOnlJ8+ M0QeZ9fpqa2OnJWXU5VD1R7ilqiiA6sIYhtdKsnRHg9xhH1K8is7xxHLqVJuL9RHx/69 9NzX6SMiGxR9wZWU/EBCs7qwKNTgNqbXfCE/Y= MIME-Version: 1.0 Received: by 10.204.24.75 with SMTP id u11mr3886882bkb.0.1255244615218; Sun, 11 Oct 2009 00:03:35 -0700 (PDT) In-Reply-To: <9b8a8de40910101302l20c82ac5p4442ef12e568f5fd@mail.gmail.com> References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156D0E@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910101302l20c82ac5p4442ef12e568f5fd@mail.gmail.com> Date: Sun, 11 Oct 2009 09:03:34 +0200 Message-ID: <9b8a8de40910110003x7a2aea1ehaf6ae0f788098cd1@mail.gmail.com> From: Vaughn Deluca To: Joshua Bell Content-Type: multipart/alternative; boundary=00032555815a6588560475a369a8 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] Reference material X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 07:01:51 -0000 --00032555815a6588560475a369a8 Content-Type: text/plain; charset=ISO-8859-1 I should like at the obvious places before asking... like the base document -- sorry-Vaughn On Sat, Oct 10, 2009 at 10:02 PM, Vaughn Deluca wrote: > Does somebody have a suggestion were to start reading if i want to learn > about the use and meaning of a "Public Region Seed Cap"? > To put my question in context, i started with Davids layering document, > working on the details of deployment pattern 5. I consulted the TP_draft_5, > and used the high level description in that as a guide for my thinking. > Looking at the details of the calls i stumbled over "Public Region Seed > Cap". Before i start a random walk in the documentation, a call for some > pointers here might save me some time. > > -Vaughn > > > > On Tue, Oct 6, 2009 at 10:06 PM, Joshua Bell wrote: > >> I made the trac/wiki updates in response to Mike's inquiry; your searching >> skills are not at fault! >> >> Suggestions for other updates to the wiki are welcome. I cribbed the top >> content to include from some other WGs. >> >> >> On Tue, Oct 6, 2009 at 11:57 AM, Dickson, Mike (ISS Software) < >> mike.dickson@hp.com> wrote: >> >>> were you looking at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ ? i >>> >>> know josh said that he's in the process of putting some content up >>> >>> there. >>> >>> >>> >>> -cheers >>> >>> -meadhbh >>> >>> -- >>> >>> >>> >>> Yep. I did find the charter just now as well so it should be easier for >>> others to find these references. I don't recall seeing it before but I'm >>> sure I just missed it. Now for some reading.... >>> >>> >>> >>> Mike >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > --00032555815a6588560475a369a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I should like at the obvious places before asking... like the base document= -- sorry
-Vaughn

On Sat, Oct 10, 200= 9 at 10:02 PM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
Does somebody have a suggestion were to sta= rt reading if i want to learn about the use and meaning of a "Public R= egion Seed Cap"?

To put my question in context, i started with Davids layerin= g document, working on the details of deployment pattern 5. =A0I consulted = the TP_draft_5, and used the high level description in that as a guide for = my thinking.=A0
Looking at the details of the calls i stumbled over=A0=A0"Public = Region Seed Cap". Before i start a random walk in the documentation, = =A0a call for some pointers here might save me some time.

-Vaughn



On Tue, Oct 6, 2009 at 10:06 PM, Joshu= a Bell <josh@lindenlab.com> wrote:
I made the trac/wiki updates in response to Mike's inquiry; your sear= ching skills are not at fault!

Suggestions for other updates to the wiki are welcome. I cribbed the to= p content to include from some other WGs.


On Tue, Oct 6, 2009 at 11:57 AM, Dickson, Mi= ke (ISS Software) <mike.dickson@hp.com> wrote:

were you looking at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ ? i

know josh said that he's in the process of putting some content up

there.

=A0

-cheers

-meadhbh

--

=A0

Yep.=A0 I did find the charter just now as well so it should be easier for others to find these references.=A0 I don't recall= seeing it before but I'm sure I just missed it.=A0=A0=A0 Now for some reading....=

=A0

Mike

=A0

=A0



_____________________________= __________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx



--00032555815a6588560475a369a8-- From morgaine.dinova@googlemail.com Sun Oct 11 01:49:24 2009 Return-Path: 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 A738D3A6851 for ; Sun, 11 Oct 2009 01:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 hERHOn8mb4Ye for ; Sun, 11 Oct 2009 01:49:23 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 0B1C73A681E for ; Sun, 11 Oct 2009 01:49:22 -0700 (PDT) Received: by ewy4 with SMTP id 4so1718427ewy.37 for ; Sun, 11 Oct 2009 01:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=277NQMS530zXyaJfGXNtHf9JNaj+a/2hXGh9g8An1ZI=; b=hzq3oCol2NHk8gkOBksiMa3G1WCNGtTaqhhxtvnFw2Lxdm+0lvjgw5B8dooucVF5H1 CYyPUHV2Y511mu1X1iTXb0YVRcbdLOwRfFqOMNG7TIFpcq/ihedudcg0v+Z19B0tLgQY OP03YazQyIgkg7lZbMWFNTEdiUauD8RsxkucA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uWV7WzKh2WjFIGJ40EN8oLiC9hlB9/kq5ZH+HrOy5kxbOZ52GBr+If3im9qZ68rqC7 brsol9QYL554VbplvH9TYdfrtqOLR4LEAdnQ3FcyWS07gUUI4l5PK+UxabdaKRABdpSA lWd8LNcvqI4bV/eDN+Wv+Ufs0RnTQGbQq8UX0= MIME-Version: 1.0 Received: by 10.211.153.2 with SMTP id f2mr2612300ebo.42.1255251069415; Sun, 11 Oct 2009 01:51:09 -0700 (PDT) In-Reply-To: <9b8a8de40910110003x7a2aea1ehaf6ae0f788098cd1@mail.gmail.com> References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156D0E@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910101302l20c82ac5p4442ef12e568f5fd@mail.gmail.com> <9b8a8de40910110003x7a2aea1ehaf6ae0f788098cd1@mail.gmail.com> Date: Sun, 11 Oct 2009 09:51:09 +0100 Message-ID: From: Morgaine To: "ogpx@ietf.org" Content-Type: multipart/alternative; boundary=00504502d11e18b36e0475a4ea0a Subject: Re: [ogpx] Reference material X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 08:49:24 -0000 --00504502d11e18b36e0475a4ea0a Content-Type: text/plain; charset=ISO-8859-1 The beginning is undoubtedly a good place to start. :-) So, let's start reviewing this! http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 The first task before us is immediately apparent. We need to do to this document what we did to the charter in order to make it acceptable for multi-world deployments --- in other words get rid of all occurrences of "the virtual world" so that the specification can be applied to our multiple virtual worlds. Morgaine. ====================================== On Sun, Oct 11, 2009 at 8:03 AM, Vaughn Deluca wrote: > I should like at the obvious places before asking... like the base document > -- sorry-Vaughn > > > On Sat, Oct 10, 2009 at 10:02 PM, Vaughn Deluca wrote: > >> Does somebody have a suggestion were to start reading if i want to learn >> about the use and meaning of a "Public Region Seed Cap"? >> To put my question in context, i started with Davids layering document, >> working on the details of deployment pattern 5. I consulted the TP_draft_5, >> and used the high level description in that as a guide for my thinking. >> Looking at the details of the calls i stumbled over "Public Region Seed >> Cap". Before i start a random walk in the documentation, a call for some >> pointers here might save me some time. >> >> -Vaughn >> >> >> >> On Tue, Oct 6, 2009 at 10:06 PM, Joshua Bell wrote: >> >>> I made the trac/wiki updates in response to Mike's inquiry; your >>> searching skills are not at fault! >>> >>> Suggestions for other updates to the wiki are welcome. I cribbed the top >>> content to include from some other WGs. >>> >>> >>> On Tue, Oct 6, 2009 at 11:57 AM, Dickson, Mike (ISS Software) < >>> mike.dickson@hp.com> wrote: >>> >>>> were you looking at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ ? i >>>> >>>> know josh said that he's in the process of putting some content up >>>> >>>> there. >>>> >>>> >>>> >>>> -cheers >>>> >>>> -meadhbh >>>> >>>> -- >>>> >>>> >>>> >>>> Yep. I did find the charter just now as well so it should be easier for >>>> others to find these references. I don't recall seeing it before but I'm >>>> sure I just missed it. Now for some reading.... >>>> >>>> >>>> >>>> Mike >>>> >>>> >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >>> >>> >> > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00504502d11e18b36e0475a4ea0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The beginning is undoubtedly a good place to start. :-)=A0 So, let's st= art reviewing this!



The first task before us is immediately apparent.=A0 We need = to do to this document what we did to the charter in order to make it accep= table for multi-world deployments --- in other words get rid of all occurre= nces of "the virtual world" so that the specification can be appl= ied to our multiple virtual worlds.

Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

On Sun, Oct 11, 2009 at 8:03 AM, Vaug= hn Deluca <= vaughn.deluca@gmail.com> wrote:
I should like at = the obvious places before asking... like the base document -- sorry
-Va= ughn


On Sat, Oct= 10, 2009 at 10:02 PM, Vaughn Deluca <vaughn.deluca@gmail.com>= ; wrote:
Does somebody hav= e a suggestion were to start reading if i want to learn about the use and m= eaning of a "Public Region Seed Cap"?

To put my question in context, i started with Davids layerin= g document, working on the details of deployment pattern 5. =A0I consulted = the TP_draft_5, and used the high level description in that as a guide for = my thinking.=A0
Looking at the details of the calls i stumbled over=A0=A0"Public = Region Seed Cap". Before i start a random walk in the documentation, = =A0a call for some pointers here might save me some time.

-Vaughn



On Tue, Oct 6, 2009 at 10:06 PM, Joshua Bell <jos= h@lindenlab.com> wrote:
=
I made the trac/wiki updates in response to Mike's inqu= iry; your searching skills are not at fault!

Suggestions for other updates to the wiki are welcome. I cribbed the to= p content to include from some other WGs.


On Tue, Oct 6, 2009 at 11:57 AM, Dickson, Mi= ke (ISS Software) <mike.dickson@hp.com> wrote:

were you looking at http://trac.tools.ietf.org/wg/vwrap/trac/wiki/ ? i

know josh said that he's in the process of putting some content up

there.

=A0

-cheers

-meadhbh

--

=A0

Yep.=A0 I did find the charter just now as well so it should be easier for others to find these references.=A0 I don't recall= seeing it before but I'm sure I just missed it.=A0=A0=A0 Now for some reading....=

=A0

Mike

=A0

=A0



__________________________________________= _____
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx




_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00504502d11e18b36e0475a4ea0a-- From vaughn.deluca@gmail.com Sun Oct 11 15:55:58 2009 Return-Path: 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 E4FC63A67F3 for ; Sun, 11 Oct 2009 15:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] 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 0bloCSrCsGb7 for ; Sun, 11 Oct 2009 15:55:57 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id D035D3A63D3 for ; Sun, 11 Oct 2009 15:55:53 -0700 (PDT) Received: by bwz6 with SMTP id 6so2776341bwz.37 for ; Sun, 11 Oct 2009 15:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OyipO0BuKsrjJZFUFB2+L6oL1ULTOdFORyh9vs3DlUM=; b=PBRpYYpLObKNFqBSyMjgvpgSAptqNzF2U0QBKF2UTDaIsaK+U6nneTgM3n1DgfCbbV M4LCnnMcqDuh2x+55fwK3EX1epC15oPqxHL5fKYvYkfl+klexOCuWOumEfRobcyHImwy 1VWV/AVPX16DoaJKdForDxy1SIjJhQG7lfSbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fcX/sDBdgKZxsYwpkUcl5D06Awl3D2G1qV2Q0ryp61Biuoa+c18Z0HMDc2ama5tErg CKIqJ3Fyi2obf5qVDVwl+06ZMrNwc0J+jNDi8V6CM9RBFYUqqlku+uypo4fvLJ3sg2x5 E0O2rvNMyOKEH/mHQs4DXgjGEFzY4qwctAVF0= MIME-Version: 1.0 Received: by 10.204.154.209 with SMTP id p17mr4457185bkw.104.1255301751040; Sun, 11 Oct 2009 15:55:51 -0700 (PDT) In-Reply-To: References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156D0E@GVW0433EXB.americas.hpqcorp.net> Date: Mon, 12 Oct 2009 00:55:51 +0200 Message-ID: <9b8a8de40910111555y76f7685fo248395cc9ef1cc61@mail.gmail.com> From: Vaughn Deluca To: David W Levine Content-Type: multipart/alternative; boundary=0015175cd0eaf4ec760475b0b610 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] (no subject) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 22:55:59 -0000 --0015175cd0eaf4ec760475b0b610 Content-Type: text/plain; charset=ISO-8859-1 I realise now I have been confused about the meaning of the Region Domain, but your post clears up a lot for me. Some of this has been voiced by others already, but here is my personal view. I think the notion of RD is very useful as a tool to specify *common* policy for some regions. Looking at the TP draft, its absolutely clear that the region is the endpoint, and a rez cap will also point to the region. Yet, as you already mentioned *behind* that interface, the region can get some of its policy from a region domain "service". Viewed like this the RD becomes a lookup service for information that otherwise has to be duplicated in possibly a lot if regions. The RD is not a *front*end containing the regions, but its a *back* end service *used* by the regions, and the fact that some regions do use this particular service places them de-facto *in* a that RD. Since policy it outside the protocol, it is not needed to specify how the regions consults the RD policy "service". All of that interaction is hidden behind the interface to the region, and it is up to the deployer of the region to decide how to deal with this problem. However, if somebody feels the need, I have no objection to formalising the interaction in *optional* protocol steps, that the region can take to help it making policy decisions. -Vaughn On Tue, Oct 6, 2009 at 11:45 PM, David W Levine wrote: > > From this mornings AWGroupies discussion, I want to try and pin down > some terminology: > > I've been saying "Policy happens at services." I think I need to make > this more precise, so: > > The current model grounds out in Web Services and streams of "events" > (Notionally delivered in UDP or over an event queue in the current > discussions) So.. From the bottom up: > > Web Services End point (URI + the LLIDL (encoded on LLSD, Binary, or > JSON) which defines a web service capability A set of "events" which > are notionally short, asynchronous and delivered quickly.. (How much, > content flows in this form is at yet unclear) > > Web service endpoints cluster into set of services, which describe the > bulk of the functionality in the specifications. (Loosely, this tends > to be the Authentication Services, Region Service, Inventory services, > Asset Services and IM services) There is nothing in this model which > dictates how to implement or deploy these services behind the defined > interfaces > > Laid over this lose description we have had the notion of "domains" in > particular, the Agent and Region domains. The current (somewhat > backlevel) intro document says: > > The Open Grid Protocol assumes a division between systems offering > user / avatar oriented services and systems offering virtual world > simulation services. OGP was designed to support the case where the > administrative authority for agent services is distinct from the > authority providing simulation and object persistence services. The > administrative authority of the former group is termed the "agent > domain" while the latter is termed the "region domain." The protocol > allows the agent domain and region domain to be distinct; in other > words, a user's identity may be managed by one person or organization > while the virtual world they inhabit may be simulated by hosts owned > by a completely different organization. > > Over the past few weeks, there has been a lot of discussion about the > possible deployment patterns people will support, and the last > definition of the split I have seen on the lists seems to be > > that if it holds the Authentication and Agent ID services its an agent > domain, and if it holds the Virtual Presence services its a region > domain. This seems quite reasonable. > > There is also the notion, that domains represent administrative > spans of control, and that services within a domain share policy. > > At the same time.. actual policy is mediated by service end > points. This is to say the moment we can actually apply policy is > when a remote service requests a capability, or invokes a capability > or (possibly) delivers an event or message to us on an asynchronous > connection. > > I see two or possibly three bits of confusion here. I'm going to start > with the basic one, which has come up over the past week. > > People keep saying "Region Domain Decides" or "Agent Domain Decides" > or "The service consults the Agent Domain" I think this muddies stuff > because it promotes the domain to an active element, when the real > behavior is "A service endpoint is called, possibly with some special > tokens, > possibly, with a negotiation ensuing and the service endpoint acts > according to its policy." > > Now, the service endpoint may well reside inside an administrative > domain, and may have its policy dictated by its deployer. But without > an active element, I don't think the domain "participates" > > The second thing which concerns me is that we're sort of conflating > two useful ideas here. One, the split between authenticator and > holders of agents, and virtual spaces, and the other, a pattern of > common use in deploying services. I think this becomes increasingly > strained, as you look at regions interacting with multiple services, > and with services which fall outside of the agent/region split, and > yet belong to one or more administrative domains. > > So.. I am not suggesting we throw away these concepts, I am suggesting > that we look carefully at how we are tossing the word around, whether > we are overloading it, and whether we could better serve our > developing a shared understanding by being more rigorous, and more > careful about how we attack some of these concepts > > - David Levine > ~ Zha Ewry > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0015175cd0eaf4ec760475b0b610 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I realise now I have been confused about the meaning of the Region Dom= ain, but your post clears up a lot for me.
Some of this has been = voiced by others already, but here is my personal view.

I think the notion of RD is very useful as a tool to specify *common* = policy for some regions.
Looking at the TP draft, its absolutely = clear that the region is the endpoint, and a rez cap will also point to the= region. Yet, as you already mentioned *behind* that interface, the region = can get some of its policy from a region domain "service". =A0Vie= wed like this the RD becomes a lookup service for information that otherwis= e has to be duplicated in possibly a lot if regions. The RD is not a *front= *end containing the regions, but its a *back* end service *used* by the reg= ions, and the fact that some regions do use this particular service places = them de-facto *in* a that RD.

Since policy it outside the protocol, it is not =A0need= ed to specify how the regions consults the RD policy "service". A= ll of that interaction is hidden behind the interface to the region, and it= is up to the deployer of the region to decide how to deal with this proble= m. However, if somebody feels the need, =A0I have no objection to formalisi= ng the interaction in =A0*optional* protocol steps, that the region can tak= e to help it making policy decisions.

-Vaughn

On Tue, Oct= 6, 2009 at 11:45 PM, David W Levine <dwl@us.ibm.com> wrote:

From this mornings AWGroupies disc= ussion, I want to try and pin down
some terminology:

I've been saying "Policy = happens at services." I think I need to make
this more precise, so:

The current model grounds out in W= eb Services and streams of "events"
(Notionally delivered in UDP or ov= er an event queue in the current
discussions) So.. From the bottom = up:

Web Services End point (URI + the = LLIDL (encoded on LLSD, Binary, or
JSON) which defines a web service = capability A set of "events" which
are notionally short, asynchronous= and delivered quickly.. (How much,
content flows in this form is at y= et unclear)

Web service endpoints cluster into= set of services, which describe the
bulk of the functionality in the s= pecifications. (Loosely, this tends
to be the Authentication Services,= Region Service, Inventory services,
Asset Services and IM services) Th= ere is nothing in this model which
dictates how to implement or deplo= y these services behind the defined
interfaces

Laid over this lose description we= have had the notion of "domains" in
particular, the Agent and Region d= omains. The current (somewhat
backlevel) intro document says:

=A0 =A0The Open Grid Protocol assumes a division between systems offering
=A0 =A0user / avatar oriented services and systems offering virtual world
=A0 =A0simulation services. =A0OGP was designed to support the case where the
=A0 =A0administrative authority for agent services is distinct from the
=A0 =A0authority providing simulat= ion and object persistence services. =A0The
=A0 =A0administrative authority of the former group is termed the "agent
=A0 =A0domain" while the latter is termed the "region domain." =A0The protocol
=A0 =A0allows the agent domain and region domain to be distinct; in other
=A0 =A0words, a user's identit= y may be managed by one person or organization
=A0 =A0while the virtual world they inhabit may be simulated by hosts owned
=A0 =A0by a completely different organization.

Over the past few weeks, there has= been a lot of discussion about the
possible deployment patterns peopl= e will support, and the last
definition of the split I have see= n on the lists seems to be

that if it holds the Authenticatio= n and Agent ID services its an agent
domain, and if it holds the Virtua= l Presence services its a region
domain. This seems quite reasonabl= e.

There is also the notion, that dom= ains represent administrative
spans of control, and that service= s within a domain share policy.

At the same time.. actual policy i= s mediated by service end
points. This is to say the moment = we can actually apply policy is
when a remote service requests a c= apability, or invokes a capability
or (possibly) delivers an event or= message to us on an asynchronous
connection.

I see two or possibly three bits o= f confusion here. I'm going to start
with the basic one, which has come= up over the past week.

People keep saying "Region Do= main Decides" or "Agent Domain Decides"
or "The service consults the = Agent Domain" I think this muddies stuff
because it promotes the domain to = an active element, when the real
behavior is "A service endpoi= nt is called, possibly with some special tokens,
possibly, with a negotiation ensui= ng and the service endpoint acts
according to its policy."

Now, the service endpoint may well= reside inside an administrative
domain, and may have its policy di= ctated by its deployer. But without
an active element, I don't thi= nk the domain "participates"

The second thing which concerns me= is that we're sort of conflating
two useful ideas here. One, the sp= lit between authenticator and
holders of agents, and virtual spa= ces, and the other, a pattern of
common use in deploying services. = I think this becomes increasingly
strained, as you look at regions i= nteracting with multiple services,
and with services which fall outsi= de of the agent/region split, and
yet belong to one or more administ= rative domains.

So.. I am not suggesting we throw = away these concepts, I am suggesting
that we look carefully at how we a= re tossing the word around, whether
we are overloading it, and whether= we could better serve our
developing a shared understanding = by being more rigorous, and more
careful about how we attack some o= f these concepts

- David Levine
~ Zha Ewry

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--0015175cd0eaf4ec760475b0b610-- From kari.lippert@gmail.com Sun Oct 11 16:30:42 2009 Return-Path: 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 5ECF53A6827 for ; Sun, 11 Oct 2009 16:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 1w6z-bbSXfiZ for ; Sun, 11 Oct 2009 16:30:41 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 8FF053A67F3 for ; Sun, 11 Oct 2009 16:30:40 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so528899eyf.5 for ; Sun, 11 Oct 2009 16:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1ZXqcwwSVljEgHlwtPSbPUOjAvdp4Oz36I/ISR+Vt6c=; b=t4J2a4xfuxnOKcFKyEdDz6Rf0sLYJP6/ye79k3zsiB18Lg6jWCM7kAkwDm7oqoeD0R NPqoZQeKvXl+cZJ0/T+85T9332Yb2Y4Qz6vMoPk0lqaoWDQjhp2/cFKjG/hms7VHIfMx cHEG8ermVmSxCyyY/ZdSYF4YGmx656fsp511U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XcwGo/Vbh6r47BtG7L0MFIot/icbtUlv0yPPcNxlNNC7AFSa2yRCYkerx3rHBrylQ6 KFBvhWRwRBUPeUyecE6jFecvWVQeulrpstdpzrLtyOB2gh8Apj+NKV+c5f9L8oJSUlYM JvyVcqpUmlVMnKaMILZfsW0n4ltnVH+nV3v1c= MIME-Version: 1.0 Received: by 10.216.86.17 with SMTP id v17mr1705841wee.192.1255303837076; Sun, 11 Oct 2009 16:30:37 -0700 (PDT) In-Reply-To: <9b8a8de40910111555y76f7685fo248395cc9ef1cc61@mail.gmail.com> References: <3a880e2c0910052217r187e2ccdiab34e39dcd80af1@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156D0E@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910111555y76f7685fo248395cc9ef1cc61@mail.gmail.com> Date: Sun, 11 Oct 2009 19:30:37 -0400 Message-ID: <382d73da0910111630p4a66d73dr29c24b8539eacc74@mail.gmail.com> From: Kari Lippert To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ogpx@ietf.org" Subject: Re: [ogpx] (no subject) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2009 23:30:42 -0000 Any service request, invocation, message delivery, or other type of communication attempt with either an AD or an RD will likely require the presentation of some sort of credential. Policy is outside the protocol as it is an implementation detail, but the protocol needs to indicate what would be (minimal) credentials. Clearly we need more than a notional idea of what that information entails. The policies that determine how (or even if) the domain uses that information is clearly up to the domain implementation and beyond the scope of the protocol. While we need to consider the types of things the domains might do so that the protocol supports the transmittal of the appropriate information, we are only specifying a format for communicating information between the domains. Unless I've missed some critical point somewhere, I believe we can largely treat the domains as black boxes and not worry their implementation or how they will use the information they receive. We only need to understand what information a domain would require to accept or react to a communication. True? Kari On Sun, Oct 11, 2009 at 6:55 PM, Vaughn Deluca wr= ote: > I realise now I have been confused about the meaning of the Region Domain= , > but your post clears up a lot for me. > Some of this has been voiced by others already, but here is my personal > view. > I think the notion of RD is very useful as a tool to specify *common* pol= icy > for some regions. > Looking at the TP draft, its absolutely clear that the region is the > endpoint, and a rez cap will also point to the region. Yet, as you alread= y > mentioned *behind* that interface, the region can get some of its policy > from a region domain "service". =A0Viewed like this the RD becomes a look= up > service for information that otherwise has to be duplicated in possibly a > lot if regions. The RD is not a *front*end containing the regions, but it= s a > *back* end service *used* by the regions, and the fact that some regions = do > use this particular service places them de-facto *in* a that RD. > Since policy it outside the protocol, it is not =A0needed to specify how = the > regions consults the RD policy "service". All of that interaction is hidd= en > behind the interface to the region, and it is up to the deployer of the > region to decide how to deal with this problem. However, if somebody feel= s > the need, =A0I have no objection to formalising the interaction in =A0*op= tional* > protocol steps, that the region can take to help it making policy decisio= ns. > -Vaughn > On Tue, Oct 6, 2009 at 11:45 PM, David W Levine wrote: >> >> From this mornings AWGroupies discussion, I want to try and pin down >> some terminology: >> >> I've been saying "Policy happens at services." I think I need to make >> this more precise, so: >> >> The current model grounds out in Web Services and streams of "events" >> (Notionally delivered in UDP or over an event queue in the current >> discussions) So.. From the bottom up: >> >> Web Services End point (URI + the LLIDL (encoded on LLSD, Binary, or >> JSON) which defines a web service capability A set of "events" which >> are notionally short, asynchronous and delivered quickly.. (How much, >> content flows in this form is at yet unclear) >> >> Web service endpoints cluster into set of services, which describe the >> bulk of the functionality in the specifications. (Loosely, this tends >> to be the Authentication Services, Region Service, Inventory services, >> Asset Services and IM services) There is nothing in this model which >> dictates how to implement or deploy these services behind the defined >> interfaces >> >> Laid over this lose description we have had the notion of "domains" in >> particular, the Agent and Region domains. The current (somewhat >> backlevel) intro document says: >> >> =A0 =A0The Open Grid Protocol assumes a division between systems offerin= g >> =A0 =A0user / avatar oriented services and systems offering virtual worl= d >> =A0 =A0simulation services. =A0OGP was designed to support the case wher= e the >> =A0 =A0administrative authority for agent services is distinct from the >> =A0 =A0authority providing simulation and object persistence services. = =A0The >> =A0 =A0administrative authority of the former group is termed the "agent >> =A0 =A0domain" while the latter is termed the "region domain." =A0The pr= otocol >> =A0 =A0allows the agent domain and region domain to be distinct; in othe= r >> =A0 =A0words, a user's identity may be managed by one person or organiza= tion >> =A0 =A0while the virtual world they inhabit may be simulated by hosts ow= ned >> =A0 =A0by a completely different organization. >> >> Over the past few weeks, there has been a lot of discussion about the >> possible deployment patterns people will support, and the last >> definition of the split I have seen on the lists seems to be >> >> that if it holds the Authentication and Agent ID services its an agent >> domain, and if it holds the Virtual Presence services its a region >> domain. This seems quite reasonable. >> >> There is also the notion, that domains represent administrative >> spans of control, and that services within a domain share policy. >> >> At the same time.. actual policy is mediated by service end >> points. This is to say the moment we can actually apply policy is >> when a remote service requests a capability, or invokes a capability >> or (possibly) delivers an event or message to us on an asynchronous >> connection. >> >> I see two or possibly three bits of confusion here. I'm going to start >> with the basic one, which has come up over the past week. >> >> People keep saying "Region Domain Decides" or "Agent Domain Decides" >> or "The service consults the Agent Domain" I think this muddies stuff >> because it promotes the domain to an active element, when the real >> behavior is "A service endpoint is called, possibly with some special >> tokens, >> possibly, with a negotiation ensuing and the service endpoint acts >> according to its policy." >> >> Now, the service endpoint may well reside inside an administrative >> domain, and may have its policy dictated by its deployer. But without >> an active element, I don't think the domain "participates" >> >> The second thing which concerns me is that we're sort of conflating >> two useful ideas here. One, the split between authenticator and >> holders of agents, and virtual spaces, and the other, a pattern of >> common use in deploying services. I think this becomes increasingly >> strained, as you look at regions interacting with multiple services, >> and with services which fall outside of the agent/region split, and >> yet belong to one or more administrative domains. >> >> So.. I am not suggesting we throw away these concepts, I am suggesting >> that we look carefully at how we are tossing the word around, whether >> we are overloading it, and whether we could better serve our >> developing a shared understanding by being more rigorous, and more >> careful about how we attack some of these concepts >> >> - David Levine >> ~ Zha Ewry >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From vaughn.deluca@gmail.com Sun Oct 11 23:19:56 2009 Return-Path: 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 C0D0028C112 for ; Sun, 11 Oct 2009 23:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 GePxm8vxp3Mh for ; Sun, 11 Oct 2009 23:19:54 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id 245DC28C0E6 for ; Sun, 11 Oct 2009 23:19:53 -0700 (PDT) Received: by fxm28 with SMTP id 28so7310800fxm.42 for ; Sun, 11 Oct 2009 23:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Gyo3BGx3yCTlqc1Xuyq1IEJzwtXTOn4o5JC2wFZN4jQ=; b=VFaSsDWobrDIgUTa8b3psjeffFQPCmeAPuJEjhL4lPMmO34PHCZEV5GZWyVWAF8MnS prTYDI89m3Oaakk0GSyltucDOJzJqigp9BrQCEpdtWeGQpxllwF/9Anx36H53gUX+azh HjAKqGDBnblIoxN3Z07+SB2prt7ROp99mpTpc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=G6uIhizCKRfYWxh6xaTDsTX3ZN++fggl02TKf7AKbqAYUq8u4HMZEoA9DxD8waara6 VmfDbCbpH9t2UBPpZN2qBtIdG/+Esayc5nBs2fSuYbte/VcQfn9fM6hnh08M0FSE4+jh XXm1qqgU2oMSmBAtcO6GwsPMhnku9PdyN69Tg= MIME-Version: 1.0 Received: by 10.204.150.69 with SMTP id x5mr4798058bkv.197.1255328388560; Sun, 11 Oct 2009 23:19:48 -0700 (PDT) In-Reply-To: <382d73da0910111630p4a66d73dr29c24b8539eacc74@mail.gmail.com> References: <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156D0E@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910111555y76f7685fo248395cc9ef1cc61@mail.gmail.com> <382d73da0910111630p4a66d73dr29c24b8539eacc74@mail.gmail.com> Date: Mon, 12 Oct 2009 08:19:48 +0200 Message-ID: <9b8a8de40910112319h6b3fcca7wbfcca9328696b10d@mail.gmail.com> From: Vaughn Deluca To: Kari Lippert Content-Type: multipart/alternative; boundary=0015175cdafaad38b70475b6ea2c Cc: "ogpx@ietf.org" Subject: Re: [ogpx] (no subject) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 06:19:56 -0000 --0015175cdafaad38b70475b6ea2c Content-Type: text/plain; charset=ISO-8859-1 Kari, I think we should treat AD and RD separately, since they are not completely similar in the way they are currently used. For now I like to stick to the region domain. You wrote: >I believe we can largely treat the domains as black boxes >and not worry their implementation or how they will use the >information they receive. Yes, absolutely, in any case as far as the region domain is concerned. That domain is only an instruments of policy and administration, and as such IMHO completely out of scope of the protocol, so not only can we can treat it as a black box, we could even completely forget about it in protocol terms, and leave it up to the administrators to use it in whatever way they like, behind the endpoints of the protocol. That said, I *do* think the region domain is a useful administrative concept, and an efficient way to implement policy. Given that fact, a case can be made that we should specify something, if only to make clear how we view the concept can be used effectively. I have no real desire to do so, but if we go that way, you re right: >We only need to understand what information a domain would require to accept or >react to a communication. True? Yes, i think so. Infinity gave 3 common ways to determine policy at the bottom of this post: http://www.ietf.org/mail-archive/web/ogpx/current/msg00541.html >a. identity implies policy. >b. authenticator implies policy. >c. region metadata implies policy. For the Region domain <-> Region service interaction, option a. will work perfectly. Since by definition all involved hosts are under the same administration, the identity of the hosts (is indicated by host name or IP address) is all that is needed to tell the domain it can trust the region service. The content of the message exchange does not concern us. But if we wished we could provide some examples along the lines Magnus and Infinity suggested here: http://www.ietf.org/mail-archive/web/ogpx/current/msg00492.html where they were discussing solutions for policy exchange between Agent Domain and Region Service. I like the third case, were the interaction follows the REST style. -Vaughn On Mon, Oct 12, 2009 at 1:30 AM, Kari Lippert wrote: > Any service request, invocation, message delivery, or other type of > communication attempt with either an AD or an RD will likely require > the presentation of some sort of credential. Policy is outside the > protocol as it is an implementation detail, but the protocol needs to > indicate what would be (minimal) credentials. Clearly we need more > than a notional idea of what that information entails. The policies > that determine how (or even if) the domain uses that information is > clearly up to the domain implementation and beyond the scope of the > protocol. > > While we need to consider the types of things the domains might do so > that the protocol supports the transmittal of the appropriate > information, we are only specifying a format for communicating > information between the domains. Unless I've missed some critical > point somewhere, I believe we can largely treat the domains as black > boxes and not worry their implementation or how they will use the > information they receive. We only need to understand what information > a domain would require to accept or react to a communication. True? > > > > Kari > > > > On Sun, Oct 11, 2009 at 6:55 PM, Vaughn Deluca > wrote: > > I realise now I have been confused about the meaning of the Region > Domain, > > but your post clears up a lot for me. > > Some of this has been voiced by others already, but here is my personal > > view. > > I think the notion of RD is very useful as a tool to specify *common* > policy > > for some regions. > > Looking at the TP draft, its absolutely clear that the region is the > > endpoint, and a rez cap will also point to the region. Yet, as you > already > > mentioned *behind* that interface, the region can get some of its policy > > from a region domain "service". Viewed like this the RD becomes a lookup > > service for information that otherwise has to be duplicated in possibly a > > lot if regions. The RD is not a *front*end containing the regions, but > its a > > *back* end service *used* by the regions, and the fact that some regions > do > > use this particular service places them de-facto *in* a that RD. > > Since policy it outside the protocol, it is not needed to specify how > the > > regions consults the RD policy "service". All of that interaction is > hidden > > behind the interface to the region, and it is up to the deployer of the > > region to decide how to deal with this problem. However, if somebody > feels > > the need, I have no objection to formalising the interaction in > *optional* > > protocol steps, that the region can take to help it making policy > decisions. > > -Vaughn > > On Tue, Oct 6, 2009 at 11:45 PM, David W Levine wrote: > >> > >> From this mornings AWGroupies discussion, I want to try and pin down > >> some terminology: > >> > >> I've been saying "Policy happens at services." I think I need to make > >> this more precise, so: > >> > >> The current model grounds out in Web Services and streams of "events" > >> (Notionally delivered in UDP or over an event queue in the current > >> discussions) So.. From the bottom up: > >> > >> Web Services End point (URI + the LLIDL (encoded on LLSD, Binary, or > >> JSON) which defines a web service capability A set of "events" which > >> are notionally short, asynchronous and delivered quickly.. (How much, > >> content flows in this form is at yet unclear) > >> > >> Web service endpoints cluster into set of services, which describe the > >> bulk of the functionality in the specifications. (Loosely, this tends > >> to be the Authentication Services, Region Service, Inventory services, > >> Asset Services and IM services) There is nothing in this model which > >> dictates how to implement or deploy these services behind the defined > >> interfaces > >> > >> Laid over this lose description we have had the notion of "domains" in > >> particular, the Agent and Region domains. The current (somewhat > >> backlevel) intro document says: > >> > >> The Open Grid Protocol assumes a division between systems offering > >> user / avatar oriented services and systems offering virtual world > >> simulation services. OGP was designed to support the case where the > >> administrative authority for agent services is distinct from the > >> authority providing simulation and object persistence services. The > >> administrative authority of the former group is termed the "agent > >> domain" while the latter is termed the "region domain." The protocol > >> allows the agent domain and region domain to be distinct; in other > >> words, a user's identity may be managed by one person or organization > >> while the virtual world they inhabit may be simulated by hosts owned > >> by a completely different organization. > >> > >> Over the past few weeks, there has been a lot of discussion about the > >> possible deployment patterns people will support, and the last > >> definition of the split I have seen on the lists seems to be > >> > >> that if it holds the Authentication and Agent ID services its an agent > >> domain, and if it holds the Virtual Presence services its a region > >> domain. This seems quite reasonable. > >> > >> There is also the notion, that domains represent administrative > >> spans of control, and that services within a domain share policy. > >> > >> At the same time.. actual policy is mediated by service end > >> points. This is to say the moment we can actually apply policy is > >> when a remote service requests a capability, or invokes a capability > >> or (possibly) delivers an event or message to us on an asynchronous > >> connection. > >> > >> I see two or possibly three bits of confusion here. I'm going to start > >> with the basic one, which has come up over the past week. > >> > >> People keep saying "Region Domain Decides" or "Agent Domain Decides" > >> or "The service consults the Agent Domain" I think this muddies stuff > >> because it promotes the domain to an active element, when the real > >> behavior is "A service endpoint is called, possibly with some special > >> tokens, > >> possibly, with a negotiation ensuing and the service endpoint acts > >> according to its policy." > >> > >> Now, the service endpoint may well reside inside an administrative > >> domain, and may have its policy dictated by its deployer. But without > >> an active element, I don't think the domain "participates" > >> > >> The second thing which concerns me is that we're sort of conflating > >> two useful ideas here. One, the split between authenticator and > >> holders of agents, and virtual spaces, and the other, a pattern of > >> common use in deploying services. I think this becomes increasingly > >> strained, as you look at regions interacting with multiple services, > >> and with services which fall outside of the agent/region split, and > >> yet belong to one or more administrative domains. > >> > >> So.. I am not suggesting we throw away these concepts, I am suggesting > >> that we look carefully at how we are tossing the word around, whether > >> we are overloading it, and whether we could better serve our > >> developing a shared understanding by being more rigorous, and more > >> careful about how we attack some of these concepts > >> > >> - David Levine > >> ~ Zha Ewry > >> > >> _______________________________________________ > >> ogpx mailing list > >> ogpx@ietf.org > >> https://www.ietf.org/mailman/listinfo/ogpx > >> > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --0015175cdafaad38b70475b6ea2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Kari,

I think we should treat AD and RD separ= ately, since they are not completely similar in the way they are currently = used. For now I like to stick to the region domain. You wrote:

>I believe we can largely treat the domains as black=A0bo= xes=A0
>and not worry their implementation or how they will us= e the
>information they receive.

Yes,= absolutely, in any case as far as the region domain is concerned. That dom= ain is only an instruments of policy and administration, and as such IMHO c= ompletely out of scope of the protocol, so not only can we can treat it as = a black box, we could even completely forget about it in protocol terms, an= d leave it up to the administrators to use it in whatever way they like, be= hind the endpoints of the protocol. =A0That said, I *do* think the region d= omain is a useful administrative concept, and an efficient way to implement= policy. =A0Given that fact, a case can be made that we should specify some= thing, if only to make clear how we view the concept can be used effectivel= y. I have no real desire to do so, but if we go that way, you re right:

>We only need to understand what information a domai= n would require to accept or >react to a communication. True?=A0

Yes, i think so. Infinity gave 3 common ways to determine= policy at the bottom of this post:
http://www.ietf.org/mail-archive/web/ogpx/current/msg00541.html

>a. identity implies policy.
>b. au= thenticator implies policy.=A0
>c. region metadata implies policy.

For th= e Region domain <-> Region service interaction, =A0option a. will wor= k perfectly. Since by definition all involved hosts are under the same admi= nistration, the identity of the hosts (is indicated by host name or IP addr= ess) is all that is needed to tell the domain it can trust the region servi= ce. The content of the message exchange does not concern us. But if we wish= ed we could provide some examples along the lines Magnus and Infinity sugge= sted here:=A0
http://www.ietf.org/mail-archive/web/ogpx/current/msg00492.html
where =A0they were discussing solutions for policy exchange betwee= n Agent Domain and Region Service. I like the third case, were the interact= ion follows the REST style.

-Vaughn

On Mon, Oct= 12, 2009 at 1:30 AM, Kari Lippert <kari.lippert@gmail.com> wrote:
=A0Any service request, invocation, message delivery, or other type of
communication attempt with either an AD or an RD will likely require
the presentation of some sort of credential. Policy is outside the
protocol as it is an implementation detail, but the protocol needs to
indicate what would be (minimal) credentials. Clearly we need more
than a notional idea of what that information entails. The policies
that determine how (or even if) the domain uses that information is
clearly up to the domain implementation and beyond the scope of the
protocol.

While we need to consider the types of things the domains might do so
that the protocol supports the transmittal of the appropriate
information, we are only specifying a format for communicating
information between the domains. =A0Unless I've missed some critical point somewhere, I believe we can largely treat the domains as black
boxes and not worry their implementation or how they will use the
information they receive. We only need to understand what information
a domain would require to accept or react to a communication. True?



Kari



On Sun, Oct 11, 2009 at 6:55 PM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
> I realise now I have been confused about the meaning of the Region Dom= ain,
> but your post clears up a lot for me.
> Some of this has been voiced by others already, but here is my persona= l
> view.
> I think the notion of RD is very useful as a tool to specify *common* = policy
> for some regions.
> Looking at the TP draft, its absolutely clear that the region is the > endpoint, and a rez cap will also point to the region. Yet, as you alr= eady
> mentioned *behind* that interface, the region can get some of its poli= cy
> from a region domain "service". =A0Viewed like this the RD b= ecomes a lookup
> service for information that otherwise has to be duplicated in possibl= y a
> lot if regions. The RD is not a *front*end containing the regions, but= its a
> *back* end service *used* by the regions, and the fact that some regio= ns do
> use this particular service places them de-facto *in* a that RD.
> Since policy it outside the protocol, it is not =A0needed to specify h= ow the
> regions consults the RD policy "service". All of that intera= ction is hidden
> behind the interface to the region, and it is up to the deployer of th= e
> region to decide how to deal with this problem. However, if somebody f= eels
> the need, =A0I have no objection to formalising the interaction in =A0= *optional*
> protocol steps, that the region can take to help it making policy deci= sions.
> -Vaughn
> On Tue, Oct 6, 2009 at 11:45 PM, David W Levine <dwl@us.ibm.com> wrote:
>>
>> From this mornings AWGroupies discussion, I want to try and pin do= wn
>> some terminology:
>>
>> I've been saying "Policy happens at services." I thi= nk I need to make
>> this more precise, so:
>>
>> The current model grounds out in Web Services and streams of "= ;events"
>> (Notionally delivered in UDP or over an event queue in the current=
>> discussions) So.. From the bottom up:
>>
>> Web Services End point (URI + the LLIDL (encoded on LLSD, Binary, = or
>> JSON) which defines a web service capability A set of "events= " which
>> are notionally short, asynchronous and delivered quickly.. (How mu= ch,
>> content flows in this form is at yet unclear)
>>
>> Web service endpoints cluster into set of services, which describe= the
>> bulk of the functionality in the specifications. (Loosely, this te= nds
>> to be the Authentication Services, Region Service, Inventory servi= ces,
>> Asset Services and IM services) There is nothing in this model whi= ch
>> dictates how to implement or deploy these services behind the defi= ned
>> interfaces
>>
>> Laid over this lose description we have had the notion of "do= mains" in
>> particular, the Agent and Region domains. The current (somewhat >> backlevel) intro document says:
>>
>> =A0 =A0The Open Grid Protocol assumes a division between systems o= ffering
>> =A0 =A0user / avatar oriented services and systems offering virtua= l world
>> =A0 =A0simulation services. =A0OGP was designed to support the cas= e where the
>> =A0 =A0administrative authority for agent services is distinct fro= m the
>> =A0 =A0authority providing simulation and object persistence servi= ces. =A0The
>> =A0 =A0administrative authority of the former group is termed the = "agent
>> =A0 =A0domain" while the latter is termed the "region do= main." =A0The protocol
>> =A0 =A0allows the agent domain and region domain to be distinct; i= n other
>> =A0 =A0words, a user's identity may be managed by one person o= r organization
>> =A0 =A0while the virtual world they inhabit may be simulated by ho= sts owned
>> =A0 =A0by a completely different organization.
>>
>> Over the past few weeks, there has been a lot of discussion about = the
>> possible deployment patterns people will support, and the last
>> definition of the split I have seen on the lists seems to be
>>
>> that if it holds the Authentication and Agent ID services its an a= gent
>> domain, and if it holds the Virtual Presence services its a region=
>> domain. This seems quite reasonable.
>>
>> There is also the notion, that domains represent administrative >> spans of control, and that services within a domain share policy.<= br> >>
>> At the same time.. actual policy is mediated by service end
>> points. This is to say the moment we can actually apply policy is<= br> >> when a remote service requests a capability, or invokes a capabili= ty
>> or (possibly) delivers an event or message to us on an asynchronou= s
>> connection.
>>
>> I see two or possibly three bits of confusion here. I'm going = to start
>> with the basic one, which has come up over the past week.
>>
>> People keep saying "Region Domain Decides" or "Agen= t Domain Decides"
>> or "The service consults the Agent Domain" I think this = muddies stuff
>> because it promotes the domain to an active element, when the real=
>> behavior is "A service endpoint is called, possibly with some= special
>> tokens,
>> possibly, with a negotiation ensuing and the service endpoint acts=
>> according to its policy."
>>
>> Now, the service endpoint may well reside inside an administrative=
>> domain, and may have its policy dictated by its deployer. But with= out
>> an active element, I don't think the domain "participates= "
>>
>> The second thing which concerns me is that we're sort of confl= ating
>> two useful ideas here. One, the split between authenticator and >> holders of agents, and virtual spaces, and the other, a pattern of=
>> common use in deploying services. I think this becomes increasingl= y
>> strained, as you look at regions interacting with multiple service= s,
>> and with services which fall outside of the agent/region split, an= d
>> yet belong to one or more administrative domains.
>>
>> So.. I am not suggesting we throw away these concepts, I am sugges= ting
>> that we look carefully at how we are tossing the word around, whet= her
>> we are overloading it, and whether we could better serve our
>> developing a shared understanding by being more rigorous, and more=
>> careful about how we attack some of these concepts
>>
>> - David Levine
>> ~ Zha Ewry
>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

--0015175cdafaad38b70475b6ea2c-- From kari.lippert@gmail.com Mon Oct 12 03:27:06 2009 Return-Path: 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 5B6733A6885 for ; Mon, 12 Oct 2009 03:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 3VNw47+7fXta for ; Mon, 12 Oct 2009 03:27:04 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 524FE3A68EA for ; Mon, 12 Oct 2009 03:27:03 -0700 (PDT) Received: by ewy4 with SMTP id 4so2329273ewy.37 for ; Mon, 12 Oct 2009 03:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=p1uuFxo7A8vO/yKwtqmBwW+aHGe6qyNzRV8K8QpYsFs=; b=mSnraA3oWfLV1zRDY8DceiImh+/Xl4OJ4r+cpNBwnkw9sfz/CvM1X9rivJW9MlhOaf ktscCfPvqmri7kCOE60GA5sCAupOZ5KHMEYrpumiCWR2nqkTsPRgYRMD7YM5Y2yRWmw9 iKJ0ctjYENSuhLBOKGsIKLS4Jd/8VGzBR0QUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Xc1cq0UY/LS2TmnlydcRi15ejrZrljcMeWr6YlY2VbOnd9XJU1uXK0qRWX//n0moVk JH00ostE5KB6ftOPEBo/d0vQTpGtPc+rxJd/Srw2VKBVQOrQ81vQOnukIkjSpC3QHka8 szBBUAAUrccoU/1lbGxcy9ZV5TCHRJ0DEj9WM= MIME-Version: 1.0 Received: by 10.216.86.204 with SMTP id w54mr1892368wee.54.1255343220806; Mon, 12 Oct 2009 03:27:00 -0700 (PDT) In-Reply-To: <9b8a8de40910112319h6b3fcca7wbfcca9328696b10d@mail.gmail.com> References: <4646639E08F58B42836FAC24C94624DD771A156C3E@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0910061144o66c609cbw1e649e91f7fd0cdb@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A156D0E@GVW0433EXB.americas.hpqcorp.net> <9b8a8de40910111555y76f7685fo248395cc9ef1cc61@mail.gmail.com> <382d73da0910111630p4a66d73dr29c24b8539eacc74@mail.gmail.com> <9b8a8de40910112319h6b3fcca7wbfcca9328696b10d@mail.gmail.com> Date: Mon, 12 Oct 2009 06:27:00 -0400 Message-ID: <382d73da0910120327t2cc34178n6934abf38b1b03e7@mail.gmail.com> From: Kari Lippert To: Vaughn Deluca Content-Type: multipart/alternative; boundary=0016e6d999e1bf54890475ba5ec4 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] (no subject) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 10:27:06 -0000 --0016e6d999e1bf54890475ba5ec4 Content-Type: text/plain; charset=ISO-8859-1 Thanks - and I see from the posts that you referenced that the discussion initiated in the AD <--> RD exchange. I think by "policy" what is meant is "access rights", where if I can't answer the questions at the door, I can't get in, and there may be a series of doors (I can stand in the vestibule, I can get to the whole place, etc.) which I think is a combination of both validating my identity (I am who I say I am) and then based on that identity (and other information TBD) a region implements an access policy. Regarding the three options, they should all be valid, as should the one we haven't thought of. The easiest way to do that is with a bit of metadata in the message header. Ultimately, I think that option a) is a bad idea since IPs can be spoofed and hijacked. Option b) will require regions to keep access control determination rules with potentially a third party (think corporate espionage here). Having a multi-level handshake seems the best idea. AD knocks (announcing who I am), RD answers with metadata that enables the AD to determine if they should/can proceed (this splits access control responsibility to both parties and is powerful for age based content restriction). After seeing the region's metadata the AD responds and, if it still wants access, presents credentials that validate and indicate access "level" entitlement or being sought. These messages should be of standardized format as specified in the protocol but should not be restricted to a particular implementation (e.g. REST). The first contact (who I am) could be IP-based and the rest could just be meaningless in a trusted domain situation. I can't envision (other than through hacking) where this dual message handshake approach would cause difficulty. It does give the RD a level of protection against inappropriate access by the AD if the AD presented false credentials. I have a bit of a problem with For the Region domain <-> Region service interaction, option a. will work perfectly. Since by definition all involved hosts are under the same administration, which is probably my misunderstanding but I thought it was not necessary that the RD and RS are under the same administration. It might be the reference to the RS that's throwing me here. I shall go read more.... Kari On Mon, Oct 12, 2009 at 2:19 AM, Vaughn Deluca wrote: > Kari, > I think we should treat AD and RD separately, since they are not completely > similar in the way they are currently used. For now I like to stick to the > region domain. You wrote: >>I believe we can largely treat the domains as black boxes >>and not worry their implementation or how they will use the >>information they receive. > Yes, absolutely, in any case as far as the region domain is concerned. That > domain is only an instruments of policy and administration, and as such IMHO > completely out of scope of the protocol, so not only can we can treat it as > a black box, we could even completely forget about it in protocol terms, and > leave it up to the administrators to use it in whatever way they like, > behind the endpoints of the protocol. That said, I *do* think the region > domain is a useful administrative concept, and an efficient way to implement > policy. Given that fact, a case can be made that we should specify > something, if only to make clear how we view the concept can be used > effectively. I have no real desire to do so, but if we go that way, you re > right: >>We only need to understand what information a domain would require to >> accept or >react to a communication. True? > Yes, i think so. Infinity gave 3 common ways to determine policy at the > bottom of this post: > http://www.ietf.org/mail-archive/web/ogpx/current/msg00541.html >>a. identity implies policy. >>b. authenticator implies policy. >>c. region metadata implies policy. > For the Region domain <-> Region service interaction, option a. will work > perfectly. Since by definition all involved hosts are under the same > administration, the identity of the hosts (is indicated by host name or IP > address) is all that is needed to tell the domain it can trust the region > service. The content of the message exchange does not concern us. But if we > wished we could provide some examples along the lines Magnus and Infinity > suggested here: > http://www.ietf.org/mail-archive/web/ogpx/current/msg00492.html > where they were discussing solutions for policy exchange between Agent > Domain and Region Service. I like the third case, were the interaction > follows the REST style. > -Vaughn > On Mon, Oct 12, 2009 at 1:30 AM, Kari Lippert > wrote: >> >> Any service request, invocation, message delivery, or other type of >> communication attempt with either an AD or an RD will likely require >> the presentation of some sort of credential. Policy is outside the >> protocol as it is an implementation detail, but the protocol needs to >> indicate what would be (minimal) credentials. Clearly we need more >> than a notional idea of what that information entails. The policies >> that determine how (or even if) the domain uses that information is >> clearly up to the domain implementation and beyond the scope of the >> protocol. >> >> While we need to consider the types of things the domains might do so >> that the protocol supports the transmittal of the appropriate >> information, we are only specifying a format for communicating >> information between the domains. Unless I've missed some critical >> point somewhere, I believe we can largely treat the domains as black >> boxes and not worry their implementation or how they will use the >> information they receive. We only need to understand what information >> a domain would require to accept or react to a communication. True? >> >> >> >> Kari >> >> >> >> On Sun, Oct 11, 2009 at 6:55 PM, Vaughn Deluca >> wrote: >> > I realise now I have been confused about the meaning of the Region >> > Domain, >> > but your post clears up a lot for me. >> > Some of this has been voiced by others already, but here is my personal >> > view. >> > I think the notion of RD is very useful as a tool to specify *common* >> > policy >> > for some regions. >> > Looking at the TP draft, its absolutely clear that the region is the >> > endpoint, and a rez cap will also point to the region. Yet, as you >> > already >> > mentioned *behind* that interface, the region can get some of its policy >> > from a region domain "service". Viewed like this the RD becomes a >> > lookup >> > service for information that otherwise has to be duplicated in possibly >> > a >> > lot if regions. The RD is not a *front*end containing the regions, but >> > its a >> > *back* end service *used* by the regions, and the fact that some regions >> > do >> > use this particular service places them de-facto *in* a that RD. >> > Since policy it outside the protocol, it is not needed to specify how >> > the >> > regions consults the RD policy "service". All of that interaction is >> > hidden >> > behind the interface to the region, and it is up to the deployer of the >> > region to decide how to deal with this problem. However, if somebody >> > feels >> > the need, I have no objection to formalising the interaction in >> > *optional* >> > protocol steps, that the region can take to help it making policy >> > decisions. >> > -Vaughn >> > On Tue, Oct 6, 2009 at 11:45 PM, David W Levine wrote: >> >> >> >> From this mornings AWGroupies discussion, I want to try and pin down >> >> some terminology: >> >> >> >> I've been saying "Policy happens at services." I think I need to make >> >> this more precise, so: >> >> >> >> The current model grounds out in Web Services and streams of "events" >> >> (Notionally delivered in UDP or over an event queue in the current >> >> discussions) So.. From the bottom up: >> >> >> >> Web Services End point (URI + the LLIDL (encoded on LLSD, Binary, or >> >> JSON) which defines a web service capability A set of "events" which >> >> are notionally short, asynchronous and delivered quickly.. (How much, >> >> content flows in this form is at yet unclear) >> >> >> >> Web service endpoints cluster into set of services, which describe the >> >> bulk of the functionality in the specifications. (Loosely, this tends >> >> to be the Authentication Services, Region Service, Inventory services, >> >> Asset Services and IM services) There is nothing in this model which >> >> dictates how to implement or deploy these services behind the defined >> >> interfaces >> >> >> >> Laid over this lose description we have had the notion of "domains" in >> >> particular, the Agent and Region domains. The current (somewhat >> >> backlevel) intro document says: >> >> >> >> The Open Grid Protocol assumes a division between systems offering >> >> user / avatar oriented services and systems offering virtual world >> >> simulation services. OGP was designed to support the case where the >> >> administrative authority for agent services is distinct from the >> >> authority providing simulation and object persistence services. The >> >> administrative authority of the former group is termed the "agent >> >> domain" while the latter is termed the "region domain." The >> >> protocol >> >> allows the agent domain and region domain to be distinct; in other >> >> words, a user's identity may be managed by one person or >> >> organization >> >> while the virtual world they inhabit may be simulated by hosts owned >> >> by a completely different organization. >> >> >> >> Over the past few weeks, there has been a lot of discussion about the >> >> possible deployment patterns people will support, and the last >> >> definition of the split I have seen on the lists seems to be >> >> >> >> that if it holds the Authentication and Agent ID services its an agent >> >> domain, and if it holds the Virtual Presence services its a region >> >> domain. This seems quite reasonable. >> >> >> >> There is also the notion, that domains represent administrative >> >> spans of control, and that services within a domain share policy. >> >> >> >> At the same time.. actual policy is mediated by service end >> >> points. This is to say the moment we can actually apply policy is >> >> when a remote service requests a capability, or invokes a capability >> >> or (possibly) delivers an event or message to us on an asynchronous >> >> connection. >> >> >> >> I see two or possibly three bits of confusion here. I'm going to start >> >> with the basic one, which has come up over the past week. >> >> >> >> People keep saying "Region Domain Decides" or "Agent Domain Decides" >> >> or "The service consults the Agent Domain" I think this muddies stuff >> >> because it promotes the domain to an active element, when the real >> >> behavior is "A service endpoint is called, possibly with some special >> >> tokens, >> >> possibly, with a negotiation ensuing and the service endpoint acts >> >> according to its policy." >> >> >> >> Now, the service endpoint may well reside inside an administrative >> >> domain, and may have its policy dictated by its deployer. But without >> >> an active element, I don't think the domain "participates" >> >> >> >> The second thing which concerns me is that we're sort of conflating >> >> two useful ideas here. One, the split between authenticator and >> >> holders of agents, and virtual spaces, and the other, a pattern of >> >> common use in deploying services. I think this becomes increasingly >> >> strained, as you look at regions interacting with multiple services, >> >> and with services which fall outside of the agent/region split, and >> >> yet belong to one or more administrative domains. >> >> >> >> So.. I am not suggesting we throw away these concepts, I am suggesting >> >> that we look carefully at how we are tossing the word around, whether >> >> we are overloading it, and whether we could better serve our >> >> developing a shared understanding by being more rigorous, and more >> >> careful about how we attack some of these concepts >> >> >> >> - David Levine >> >> ~ Zha Ewry >> >> >> >> _______________________________________________ >> >> ogpx mailing list >> >> ogpx@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ogpx >> >> >> > >> > >> > _______________________________________________ >> > ogpx mailing list >> > ogpx@ietf.org >> > https://www.ietf.org/mailman/listinfo/ogpx >> > >> > > > --0016e6d999e1bf54890475ba5ec4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks - and I see from the posts that you referenced that the discussion i= nitiated in the AD <--> RD exchange. I think by "policy" wh= at is meant is "access rights", where if I can't answer the q= uestions at the door, I can't get in, and there may be a series of door= s (I can stand in the vestibule, I can get to the whole place, etc.) which = I think is a combination of both validating my identity (I am who I say I a= m) and then based on that identity (and other information TBD) a region imp= lements an access policy.

Regarding the three options, they should all be valid, as should the on= e we haven't thought of. The easiest way to do that is with a bit of me= tadata in the message header. Ultimately, I think that option a) is a bad i= dea since IPs can be spoofed and hijacked. Option b) will require regions t= o keep access control determination rules with potentially a third party (t= hink corporate espionage here).=A0

Having a multi-level handshake seems the best idea. AD knock= s (announcing who I am), RD answers with metadata that enables the AD to de= termine if they should/can proceed (this splits access control responsibili= ty to both parties and is powerful for age based content restriction). Afte= r seeing the region's metadata the AD responds and, if it still wants a= ccess, presents credentials that validate and indicate access "level&q= uot; entitlement or being sought. These messages should be of standardized = format as specified in the protocol but should not be restricted to a parti= cular implementation (e.g. REST).

The first contact (who I am) could be IP-based and the rest could = just be meaningless in a trusted domain situation. I can't envision (ot= her than through hacking) where this dual message handshake approach would = cause difficulty. It does give the RD a level of protection against inappro= priate access by the AD if the AD presented false credentials.

I have a bit of a problem with
For the Region domain <-> Region service interacti= on, =A0option a. will work perfectly. Since by definition all involved host= s are under the same administration,
which is probably my misunderstanding but I thought it was not necessary th= at the RD and RS are under the same administration. It might be the referen= ce to the RS that's throwing me here. =A0I shall go read more....

Kari


On Mon, Oct 12, 2009 at 2:19 AM,= Vaughn Deluca <vaughn.deluca= @gmail.com> wrote:
> Kari,
> I think we should treat AD = and RD separately, since they are not completely
> similar in the way they are currently used. For now I like to stick to= the
> region domain. You wrote:
>>I believe we can largely = treat the domains as black=A0boxes=A0
>>and not worry their implem= entation or how they will use the
>>information they receive.
> Yes, absolutely, in any case as f= ar as the region domain is concerned. That
> domain is only an instru= ments of policy and administration, and as such IMHO
> completely out= of scope of the protocol, so not only can we can treat it as
> a black box, we could even completely forget about it in protocol term= s, and
> leave it up to the administrators to use it in whatever way = they like,
> behind the endpoints of the protocol. =A0That said, I *d= o* think the region
> domain is a useful administrative concept, and an efficient way to imp= lement
> policy. =A0Given that fact, a case can be made that we shoul= d specify
> something, if only to make clear how we view the concept = can be used
> effectively. I have no real desire to do so, but if we go that way, yo= u re
> right:
>>We only need to understand what information = a domain would require to
>> accept or >react to a communicatio= n. True?=A0
> Yes, i think so. Infinity gave 3 common ways to determine policy at th= e
> bottom of this post:
> http://www.ietf.org/mail-archive/we= b/ogpx/current/msg00541.html
>>a. identity implies policy.
>>b. authenticator implies pol= icy.=A0
>>c. region metadata implies policy.
> For the Regio= n domain <-> Region service interaction, =A0option a. will work
&g= t; perfectly. Since by definition all involved hosts are under the same
> administration, the identity of the hosts (is indicated by host name o= r IP
> address) is all that is needed to tell the domain it can trust= the region
> service. The content of the message exchange does not c= oncern us. But if we
> wished we could provide some examples along the lines Magnus and Infin= ity
> suggested here:=A0
> http://www.ietf.org/mail-archive/we= b/ogpx/current/msg00492.html
> where =A0they were discussing solutions for policy exchange between Ag= ent
> Domain and Region Service. I like the third case, were the inte= raction
> follows the REST style.
> -Vaughn
> On Mon, Oct= 12, 2009 at 1:30 AM, Kari Lippert <kari.lippert@gmail.com>
> wrote:
>>
>> =A0Any service request, invocation, mes= sage delivery, or other type of
>> communication attempt with eith= er an AD or an RD will likely require
>> the presentation of some = sort of credential. Policy is outside the
>> protocol as it is an implementation detail, but the protocol needs= to
>> indicate what would be (minimal) credentials. Clearly we ne= ed more
>> than a notional idea of what that information entails. = The policies
>> that determine how (or even if) the domain uses that information i= s
>> clearly up to the domain implementation and beyond the scope = of the
>> protocol.
>>
>> While we need to consi= der the types of things the domains might do so
>> that the protocol supports the transmittal of the appropriate
&= gt;> information, we are only specifying a format for communicating
&= gt;> information between the domains. =A0Unless I've missed some cri= tical
>> point somewhere, I believe we can largely treat the domains as bla= ck
>> boxes and not worry their implementation or how they will us= e the
>> information they receive. We only need to understand what= information
>> a domain would require to accept or react to a communication. True= ?
>>
>>
>>
>> Kari
>>
>&= gt;
>>
>> On Sun, Oct 11, 2009 at 6:55 PM, Vaughn Deluca = <vaughn.deluca@gmail.com&= gt;
>> wrote:
>> > I realise now I have been confused about t= he meaning of the Region
>> > Domain,
>> > but your= post clears up a lot for me.
>> > Some of this has been voiced= by others already, but here is my personal
>> > view.
>> > I think the notion of RD is very usefu= l as a tool to specify *common*
>> > policy
>> > fo= r some regions.
>> > Looking at the TP draft, its absolutely cl= ear that the region is the
>> > endpoint, and a rez cap will also point to the region. Yet, a= s you
>> > already
>> > mentioned *behind* that int= erface, the region can get some of its policy
>> > from a regio= n domain "service". =A0Viewed like this the RD becomes a
>> > lookup
>> > service for information that otherwis= e has to be duplicated in possibly
>> > a
>> > lot = if regions. The RD is not a *front*end containing the regions, but
>&= gt; > its a
>> > *back* end service *used* by the regions, and the fact that s= ome regions
>> > do
>> > use this particular servic= e places them de-facto *in* a that RD.
>> > Since policy it out= side the protocol, it is not =A0needed to specify how
>> > the
>> > regions consults the RD policy "ser= vice". All of that interaction is
>> > hidden
>> = > behind the interface to the region, and it is up to the deployer of th= e
>> > region to decide how to deal with this problem. However, if s= omebody
>> > feels
>> > the need, =A0I have no obje= ction to formalising the interaction in
>> > =A0*optional*
&= gt;> > protocol steps, that the region can take to help it making pol= icy
>> > decisions.
>> > -Vaughn
>> > On Tue, = Oct 6, 2009 at 11:45 PM, David W Levine <dwl@us.ibm.com> wrote:
>> >>
>> >> = >From this mornings AWGroupies discussion, I want to try and pin down
>> >> some terminology:
>> >>
>> >&g= t; I've been saying "Policy happens at services." I think I n= eed to make
>> >> this more precise, so:
>> >>= ;
>> >> The current model grounds out in Web Services and streams= of "events"
>> >> (Notionally delivered in UDP or= over an event queue in the current
>> >> discussions) So.. = >From the bottom up:
>> >>
>> >> Web Services End point (URI + the LL= IDL (encoded on LLSD, Binary, or
>> >> JSON) which defines a= web service capability A set of "events" which
>> >&= gt; are notionally short, asynchronous and delivered quickly.. (How much, >> >> content flows in this form is at yet unclear)
>>= >>
>> >> Web service endpoints cluster into set of se= rvices, which describe the
>> >> bulk of the functionality i= n the specifications. (Loosely, this tends
>> >> to be the Authentication Services, Region Service, Invent= ory services,
>> >> Asset Services and IM services) There is= nothing in this model which
>> >> dictates how to implement= or deploy these services behind the defined
>> >> interfaces
>> >>
>> >> Laid= over this lose description we have had the notion of "domains" i= n
>> >> particular, the Agent and Region domains. The curren= t (somewhat
>> >> backlevel) intro document says:
>> >>
&= gt;> >> =A0 =A0The Open Grid Protocol assumes a division between s= ystems offering
>> >> =A0 =A0user / avatar oriented services= and systems offering virtual world
>> >> =A0 =A0simulation services. =A0OGP was designed to suppor= t the case where the
>> >> =A0 =A0administrative authority f= or agent services is distinct from the
>> >> =A0 =A0authorit= y providing simulation and object persistence services. =A0The
>> >> =A0 =A0administrative authority of the former group is te= rmed the "agent
>> >> =A0 =A0domain" while the lat= ter is termed the "region domain." =A0The
>> >> pr= otocol
>> >> =A0 =A0allows the agent domain and region domain to be di= stinct; in other
>> >> =A0 =A0words, a user's identity m= ay be managed by one person or
>> >> organization
>>= ; >> =A0 =A0while the virtual world they inhabit may be simulated by = hosts owned
>> >> =A0 =A0by a completely different organization.
>>= ; >>
>> >> Over the past few weeks, there has been a l= ot of discussion about the
>> >> possible deployment pattern= s people will support, and the last
>> >> definition of the split I have seen on the lists seems to= be
>> >>
>> >> that if it holds the Authenti= cation and Agent ID services its an agent
>> >> domain, and = if it holds the Virtual Presence services its a region
>> >> domain. This seems quite reasonable.
>> >>=
>> >> There is also the notion, that domains represent admi= nistrative
>> >> spans of control, and that services within = a domain share policy.
>> >>
>> >> At the same time.. actual policy is = mediated by service end
>> >> points. This is to say the mom= ent we can actually apply policy is
>> >> when a remote serv= ice requests a capability, or invokes a capability
>> >> or (possibly) delivers an event or message to us on an as= ynchronous
>> >> connection.
>> >>
>>= ; >> I see two or possibly three bits of confusion here. I'm goin= g to start
>> >> with the basic one, which has come up over the past week.=
>> >>
>> >> People keep saying "Region = Domain Decides" or "Agent Domain Decides"
>> >&g= t; or "The service consults the Agent Domain" I think this muddie= s stuff
>> >> because it promotes the domain to an active element, when= the real
>> >> behavior is "A service endpoint is call= ed, possibly with some special
>> >> tokens,
>> >= ;> possibly, with a negotiation ensuing and the service endpoint acts >> >> according to its policy."
>> >>
&g= t;> >> Now, the service endpoint may well reside inside an adminis= trative
>> >> domain, and may have its policy dictated by it= s deployer. But without
>> >> an active element, I don't think the domain "par= ticipates"
>> >>
>> >> The second thing = which concerns me is that we're sort of conflating
>> >>= two useful ideas here. One, the split between authenticator and
>> >> holders of agents, and virtual spaces, and the other, a p= attern of
>> >> common use in deploying services. I think th= is becomes increasingly
>> >> strained, as you look at regio= ns interacting with multiple services,
>> >> and with services which fall outside of the agent/region = split, and
>> >> yet belong to one or more administrative do= mains.
>> >>
>> >> So.. I am not suggesting w= e throw away these concepts, I am suggesting
>> >> that we look carefully at how we are tossing the word aro= und, whether
>> >> we are overloading it, and whether we cou= ld better serve our
>> >> developing a shared understanding = by being more rigorous, and more
>> >> careful about how we attack some of these concepts
>= ;> >>
>> >> - David Levine
>> >> ~ Z= ha Ewry
>> >>
>> >> _________________________= ______________________
>> >> ogpx mailing list
>> >> ogpx@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/ogp= x
>> >>
>> >
>> >
>> > ______= _________________________________________
>> > ogpx mailing lis= t
>> > ogpx@ietf.org
>> > https:= //www.ietf.org/mailman/listinfo/ogpx
>> >
>> ><= br>>
>

--0016e6d999e1bf54890475ba5ec4-- From vaughn.deluca@gmail.com Mon Oct 12 12:45:07 2009 Return-Path: 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 AD3C53A6958; Mon, 12 Oct 2009 12:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 bBrDc5eJytnt; Mon, 12 Oct 2009 12:45:05 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id A08493A6919; Mon, 12 Oct 2009 12:45:01 -0700 (PDT) Received: by fxm28 with SMTP id 28so7812226fxm.42 for ; Mon, 12 Oct 2009 12:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ypekV7UO2ChRFIAtn4kYuTFuISYJwUqZe2IUw5j97zw=; b=lxsllCMKe1jqlqygYx5lvjCi/1dm+5mGARkLZWmdx6fhZTHhaSU2m+uohH9qNtlr81 CdEmavKvpGRRS7/ul4+m2f7H+UzwgDCXP5E4nsbmZDB1F/n7e6C2IhdWnzTGqYXpJRuM kVnB9KHNAtkqbu3FoxfA3MRqD6ZWCwX8GhX+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=I0o4NGV1UouAWCASXmAIOrfb3/BfdeY+8/XfNcuKZg+ICOScdQKup0Y2XYET9gVGxN ghaC+gocJqt2MdeXOFfuJrW6gvV5MOazJ03x+A5uX947LWFiI9p183KhP+moxhGv78Ed FlWPgHY6yS3eRPTeXG7kpsuOLqK3hWkAeq+fo= MIME-Version: 1.0 Received: by 10.204.154.150 with SMTP id o22mr5347249bkw.154.1255376696995; Mon, 12 Oct 2009 12:44:56 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> <20091008114435.GA22204@alinoe.com> Date: Mon, 12 Oct 2009 21:44:56 +0200 Message-ID: <9b8a8de40910121244l94e4f4ai4805692e224f70f@mail.gmail.com> From: Vaughn Deluca To: David W Levine Content-Type: multipart/alternative; boundary=0015175cf772156f750475c22a8c Cc: Magnus Zeisig , Infinity Linden , "ogpx-bounces@ietf.org" , Meadhbh Hamrick , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 19:45:07 -0000 --0015175cf772156f750475c22a8c Content-Type: text/plain; charset=ISO-8859-1 David wrote >I would suggest that one good way forward on this is to develop a set of policy use cases >to drive our analysis of the protocol and specifications, and then look at whether we can >reasonably manage these use cases." I agree, and the obvious place to start is http://tools.ietf.org/html/draft-levine-ogp-layering-00 were David provides a number of deployment patterns: >5. Second Life Agent Domain / Region Domain Split >6. Standalone OpenSim Region model >7. OpenSim OGP + Asset reflector + Agent Service >8. OpenSim UGAIM grid model >9. Hypergrid >10. Hypergrid and Cable Beach >11. Multi-hosted asset deployment >12. Factored Service Models I will try to extend pattern 5, and first see how far it can be applied to a TP between two Regions in different Region domains. I will work towards what Morgaine called the tourist model --Morgaine, if i am misrepresenting your idea please jump in and correct were needed :) Some features mentioned in pattern 5 are: (1) The agent domain acts as a unitary focus for all services associated with the agent. (2) When accessing other services hosted by a deployer other than the hoster of the agent domain, the agent domain acts as the trust source, managing the agent (and user's) access to other regions. (3) [not considered yet to keep things simple] I think that these two features can also be used in the tourist model. To keep things simple at first, lets leave out assets for now, and consentrate on TP. Also I find it easier to analyse the needs and constrains when using a real protocol example. The protocol steps for TP have been described in http://wiki.secondlife.com/wiki/OGP_Teleport_Draft_5. The high level description in this document is this: "In all cases, the sequence of resource invocations follows the same form. First, the Viewer invokes Place Avatar on the agent's Agent Domain. While processing Place Avatar, Agent Domain asks the destination region if the avatar can be placed by requesting and invoking the Request Rez Avatar resource. If the agent is already connected to a region, in the previous Teleport, the Agent Domain has already stored away the Derez Avatar capability for that agent. The Agent Domain passes the Rez Avatar capability to the (stored away) Derez Avatar capability, asking the current region to transfer the avatar to its destination. The current region in turn transfers the avatar to the destination by POST'ing to the Rez Avatar resource. The response to Rez Avatar is propagated all the way back to the Agent Domain, which passes the results overlayed with the response from Request Rez Avatar back to the Viewer. Finally, the Viewer establishes communication with destination region to begin simulation. " The Naming convention in the rest of this text is what we used in several post now: D for domain and S for service, A for agent, R for region. Services from different administrative domains get different numerical suffixes (e.g AD1, AD2). In addition instances of a particular servicetype within some domain could be given a second numerical suffix that identifies the particular instance (e.g. RS1.1, RS1.2 and RS1.3 for three region services belonging to RD1. The TP-Draft_5 high level description starts with an agent logged in into AD1, with a rezzed avatar in RS1.1 and a Derez cap for the avatar stored by AD1. I have numbered the steps for easy reference and write all calls from left to right. (1) Viewer---("place avatar" request for RS2.1)---> AD1 Note that AD1 is is domain, not a service, so i we might need to tighten the language here a bit also, but for now i will let that go. (2) AD1 can checks (behind its interface) if its policy will allow this TP, this is outside the protocol. If AD1 allows the TP it asks RS2.1 for a "rez avatar cap": (3) AD1---( "Rez avatar cap" request )---> RS2.1 (4) In this stage RS2.1 can apply its own policy and/or (behind its own interface) consult RD2 to check global domain policy, as suggested by David and after that by me, elsewhere in the discussion. RS2.1 might also want extra info about agent_ID@AD1. How to do this, and how wise it is has been the subject of much of the recent discussion. I liked the multi-message handshake suggestion of Magnus and Infinity, for example: (5) RS2.1---(X, age > X? cap)---> AD1 If AD1 does not want to give this information or cannot do so, it does not use the cap and reports a failure back to the viewer. Otherwise it uses the cap: (6) AD1 ---(POST)----> age > X? cap If RS2.1 now wants to allow the TP, the Rez avatar cap is returned (as well as some other caps that are a bit out of scope here) (7) RS2.1---( Rez avatar cap)---> AD1 (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 (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 (10) RS2.1---( Rez avatar result)---> RS1.1 (11) RS1.1---(Rez avatar result)---> AD1 (12) AD1---(Place avatar result, Rez avatar result)---> viewer The viewer can now contact the region. As far as I can see this fits the tourist model , as well as the deployment pattern under point 5 in the layering document. (ignoring assets for the moment). Am i right? or did i overlook something? On Thu, Oct 8, 2009 at 3:57 PM, David W Levine wrote: > > One thing to keep in mind in this whole discussion is the following: "All > policy decisions are local" This doesn't mean they don't represent a way of > solving a globally distributed use case, but > it highlights the fact the one software element, hosted behind and endpoint > can't impose behavior on another such endpoint. In the case of how a service > in an Agent Domain interacts with the services in a region domain, the Agent > Domain is limited to controlling what *it* does. So, in the case of an agent > domain which has the policy of not permitting its users to be exposed to > "mature" content. The agent domain, however, doesn't perform the delivery of > content from the region. It handles authentication, and global presence > management, and possibly inventory management, but, it doesn't control what > happens in the region. (In fact, in the current model, it doesn't even see > the traffic, but seeing it wouldn't help) > > The decision as to what happens inside the region is local to the region. > Just as the agent Dorian in this example doesn't see what the region is > doing, the region doesn't see what the > agent domain is doing, nor can it influence it. > > From the point of view of the use case "Keep my agents away from "mature" > content" the Agent Domain's leverage is limited to looking at the > information the region exports, and deciding whether or not this is a region > where it is safe for its agents to travel. The region, of course, can say > whatever it wants. So.. if the Agent Domain wants certainty, it needs for > the > region to not only export information it can use to make this decision, but > to export it in a way that gives the agent domain increased certainty. > Traditionally, this takes the form of a > digital signature tied to real world, out of band assurances. > > I would argue this is all for the good. At the Protocol and Endpoint > description level, most of what needs to happen to support this model is to > make sure we know where services expose meta-data and how it is formatted. > The protocol need not focus on what the meta-data represents, but that it is > there and available for supporting policy decisions. > > From the perspective of managing interop, I think that the bulk of our > focus needs to be having the use cases which enable us to make sure we *can* > export and understand > the meta-data needed to allow policy decisions to be made. > > There is a related topic, namely how we might do a distributed policy > language permitting various services to reason about the policies governing > a given service they wish to interact with. But.. That's not needed to make > the protocol work. I view this as a good thing, since it is a decidedly non > trivial problem to solve. > > I would suggest that one good way forward on this is to develop a set of > policy use cases to drive our analysis of the protocol and specifications, > and then look at whether we can reasonably manage these use cases. My > personal belief is that the bulk of our policy management is going to > consist of checking for meta-data signed using existing PKI standards (x.509 > is the obvious one) and making decisions based on this meta-data. > > - David W. Levine > ~ Zha Ewry > > > > > *Carlo Wood * > Sent by: ogpx-bounces@ietf.org > > 10/08/2009 07:44 AM > To > Meadhbh Hamrick > cc > Infinity Linden , "ogpx-bounces@ietf.org" < > ogpx-bounces@ietf.org>, "ogpx@ietf.org" , Magnus Zeisig < > magnus.zeisig@iis.se> Subject > Re: [ogpx] Protocol for permitting policy decisions > > > > > On Wed, Oct 07, 2009 at 02:07:58PM -0700, Meadhbh Hamrick wrote: > > anyway. just a though. i'm going to spend a little time trying to > > understand a couple different country's regulations for online access > > to adult materials by minors, just to get a sense for where the > > differences would lie. > > Although admirable, this is just an EXAMPLE. We should look at it, > and SOLVE it, in an abstract way; so that we will tackle every > possible policy problem like it without that we have to think of > an exhausted list now. > > Ie, if your investigation would show that every country in the > world handles online access to adult materials by minors in the > exact same way, than that doesn't make the abstract problem go > away, we'd just have to think of another example to tackle the > exact same problem. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0015175cf772156f750475c22a8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
David wrote

>I would suggest that one good= way forward on this is to develop a set of policy use cases=A0
&= gt;to drive our analysis of the protocol and specifications, and then look = at whether we can=A0
>reasonably manage these use cases."

= I agree, and the obvious place to start is
http://tool= s.ietf.org/html/draft-levine-ogp-layering-00 were David provides a numb= er of deployment patterns:

>5. =A0Second Life Agent Domain / Region Domain Spli= t
>6. =A0Standalone OpenSim Region model
>7. =A0O= penSim OGP + Asset reflector + Agent Service
>8. =A0OpenSim UG= AIM grid model
>9. =A0Hypergrid
>10. Hypergrid and Cable Beach
<= div>>11. Multi-hosted asset deployment
>12. Factored Servic= e Models

I will try to extend pattern 5, and first= see how far it can be applied to a TP between two Regions in different Reg= ion domains. I will work towards what =A0Morgaine called the tourist model = --Morgaine, if i am misrepresenting your idea please jump in and correct we= re needed :)

Some features mentioned in pattern 5 are:
(1) The agent domain acts as a unitary focus for all services a= ssociated with the agent.
(2) When accessing other services hoste= d by a deployer other than the hoster of the agent domain, the agent domain= acts as the trust source, managing the agent (and user's) access to ot= her regions.
(3) [not considered yet to keep things simple]

I think that these two features can also be used in the tourist model. To= keep things simple at first, lets leave out assets for now, and consentrat= e on TP. Also I find it easier to analyse the needs and constrains when usi= ng a real protocol example. The protocol steps for TP have been described i= n http://wiki.secondlife.com/wiki/OGP_Teleport_Draft_5. The h= igh level description in this document is this:

"In all cases, the sequence of resource invocation= s follows the same form.=A0
First, the Viewer invokes Place Avata= r on the agent's Agent Domain. While processing Place Avatar, Agent Dom= ain asks the destination region if the avatar can be placed by requesting a= nd invoking the Request Rez Avatar resource. If the agent is already connec= ted to a region, in the previous Teleport, the Agent Domain has already sto= red away the Derez Avatar capability for that agent.=A0
The Agent Domain passes the Rez Avatar capability to the (stored away)= Derez Avatar capability, asking the current region to transfer the avatar = to its destination. The current region in turn transfers the avatar to the = destination by POST'ing to the Rez Avatar resource. The response to Rez= Avatar is propagated all the way back to the Agent Domain, which passes th= e results overlayed with the response from Request Rez Avatar back to the V= iewer. Finally, the Viewer establishes communication with destination regio= n to begin simulation. "

The Naming convention in the rest of this text is what = we used in several post now: D for domain and S for service, A for agent, R= for region. =A0Services from different administrative domains get differen= t numerical suffixes (e.g AD1, AD2). In addition instances of a particular = =A0servicetype within some domain could be given a second =A0numerical suff= ix that identifies the particular instance =A0(e.g. RS1.1, RS1.2 and RS1.3 = for three region services belonging to RD1.

The TP-Draft_5 high level description starts with an ag= ent logged in into AD1, with a rezzed avatar in RS1.1 and a Derez cap for t= he avatar stored by AD1.=A0
I have numbered the steps for easy re= ference and write all calls from left to right.

(1) Viewer---("place avatar" request for RS2.= 1)---> AD1
Note that AD1 is is domain, not a service, so i we = might need to tighten the language here a bit also, but for now i will let = that go.

(2) AD1 can checks (behind its interface) if its policy= will allow this TP,
this is outside the protocol.
If A= D1 allows the TP it asks RS2.1 for a "rez avatar cap":

(3) AD1---( "Rez avatar cap" request )---> RS2.= 1

(4) In this stage RS2.1 can apply its own policy= and/or (behind its own interface) consult RD2 to check global domain polic= y, as suggested by David and after that by me, elsewhere in the discussion.= =A0RS2.1 might also want extra info about agent_ID@AD1. How to do this, an= d how wise it is has been the subject of much of the recent discussion. =A0=
I liked the multi-message handshake suggestion of Magnus and Infinity,= for example:

(5) RS2.1---(X, age > X? cap)---&= gt; AD1
If AD1 does not want to give this information or cannot d= o so, it does not use =A0the cap and reports a failure back to the viewer. = Otherwise it uses the cap:

(6) AD1 ---(POST)----> age > X? cap
If RS2.1 now wants to allow the TP, the =A0Rez avatar cap is re= turned (as well as some other caps that are a bit out of scope here)

(7) RS2.1---( Rez avatar cap)---> AD1

=
(8) AD1---(Rez avatar cap) ---> Derez avatar cap
Th= e stored Derez avatar cap is a URI pointing to the current region of the av= atar, in this case RS1.1

(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

(10) RS2.1---( Rez avatar resul= t)---> RS1.1

(11) RS1.1---(Rez avatar result)---> AD1
<= br>
(12) AD1---(Place avatar result, Rez avatar result)---> = =A0viewer
The viewer can now contact the region.

As far as I can see this fits the tourist model , as well as the deplo= yment pattern under point 5 in the layering document. (ignoring assets for = the moment). =A0Am i right? or did i overlook something?


On Thu, Oct 8, 2009 at 3:57 PM, David W Levi= ne <dwl@us.ibm.com> wrote:

One thing to keep in mind in this = whole discussion is the following: "All policy decisions are local" This doesn't mean they don't represent a way of solving a globally = distributed use case, but
it highlights the fact the one sof= tware element, hosted behind and endpoint can't impose behavior on another su= ch endpoint. In the case of how a service in an Agent Domain interacts with the services in a region domain, the Agent Domain is limited to controlling what *it* does. So, in the case of an agent domain which has the policy of not permitting its users to be exposed to "mature" content. The agent domain, however, doesn't perform the delivery of content from the region. It handles authentication, and global presence management, and possibly inventory management, but, it doesn't control what happens in the region. (In fact, in the current model, it doesn't even see the traffic, but seeing it wouldn't help)

The decision as to what happens in= side the region is local to the region. Just as the agent Dorian in this example doesn't see what the region is doing, the region doesn't see what t= he
agent domain is doing, nor can it = influence it.

From the point of view of the use = case "Keep my agents away from "mature" content" the Agent Domain's leverage is limited to looking at the information the region e= xports, and deciding whether or not this is a region where it is safe for its agent= s to travel. The region, of course, can say whatever it wants. So.. if the Agent Domain wants certainty, it needs for the
region to not only export informat= ion it can use to make this decision, but to export it in a way that gives the agent domain increased certainty. =A0Traditionally, this takes the form of a
digital signature tied to real wor= ld, out of band assurances.

I would argue this is all for the = good. At the Protocol and Endpoint description level, most of what needs to happe= n to support this model is to make sure we know where services expose meta-da= ta and how it is formatted. The protocol need not focus on what the meta-data represents, but that it is there and available for supporting policy decisi= ons.

From the perspective of managing i= nterop, I think that the bulk of our focus needs to be having the use cases which enable us to make sure we *can* export and understand
the meta-data needed to allow poli= cy decisions to be made.

There is a related topic, namely h= ow we might do a distributed policy language permitting various services to reason about the policies governing a given service they wish to interact with. But.. That's not needed to make the protocol work. I view this as a good thing, since it is a decidedly non trivial problem to solve.

I would suggest that one good way = forward on this is to develop a set of policy use cases to drive our analysis of the protocol and specifications, and then look at whether we can reasonably manage these use cases. =A0My personal belief is that the bulk of our policy management is going to consist of checking for meta-data signed using existing PKI standards (x.509 =A0is the obvious one) and making decisions based on this meta-data.

- David W. Levine
~ Zha Ewry




Carlo Wood &= lt;carlo@alinoe.com>

10/08/2009 07:44 AM

To
Meadhbh Hamrick <meadhbh.siobhan@= gmail.com>
cc
Infinity Linden <infinity@lindenlab.com= >, "ogpx-bounc= es@ietf.org" <ogpx-bounces@ietf.org>, "ogpx@ietf.org" <ogpx@ietf.org>= ;, Magnus Zeisig <magnus.zeisig@iis.se>
Subject
Re: [ogpx] Protocol for= permitting policy decisions





On Wed, Oct 07, 2009 at 02:07:58PM -0700, Meadhbh Hamrick wrote:
> anyway. just a though. i'm going to spend a little time trying to<= br> > understand a couple different country's regulations for online acc= ess
> to adult materials by minors, just to get a sense for where the
> differences would lie.

Although admirable, this is just an EXAMPLE. We should look at it,
and SOLVE it, in an abstract way; so that we will tackle every
possible policy problem like it without that we have to think of
an exhausted list now.

Ie, if your investigation would show that every country in the
world handles online access to adult materials by minors in the
exact same way, than that doesn't make the abstract problem go
away, we'd just have to think of another example to tackle the
exact same problem.

--
Carlo Wood <carlo@= alinoe.com>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx=


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--0015175cf772156f750475c22a8c-- From morgaine.dinova@googlemail.com Mon Oct 12 22:13:27 2009 Return-Path: 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 BE3F428C1FC for ; Mon, 12 Oct 2009 22:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.755 X-Spam-Level: X-Spam-Status: No, score=0.755 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_UNSUB18=0.131] 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 IATcKBBuc17N for ; Mon, 12 Oct 2009 22:13:24 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id D1B1828C107 for ; Mon, 12 Oct 2009 22:13:22 -0700 (PDT) Received: by ewy4 with SMTP id 4so3049284ewy.37 for ; Mon, 12 Oct 2009 22:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=yvFGfiRcLBq7y0gvdxWdQe2LgJaB0kbd6vXpf0/r3tg=; b=Wbl0fwquaubpMUH0OfUL7bHxH7AY5EBCxvmz1Um1tL+Cnv7FvMvWK+1jkmtAUK/qJx /FCxief8Ce5Kj2VdtHA+z1ZzVWFeNTk7vHWEX4FAIMPNmXW9dsXZpjPzfJqG+BO+zqev D3zPjCeyNVvMFi60IbBla7YADCQBdjKwNZOFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Y58fz6rnOCey1jLSEnd2AQp4AghfPKZ28Nfx0tdnM2ZbH+NhxE7hDVctbPbkSELl+E HfZVUmEHVWlG3jTCZcdP4OU3J/a55EPadWfnBQrYbTGaMuwgZnDglJGApGglY/PwfJ7c oLl8AFcuK653l2CMNcADjsRcYTtqOvcv2JTpo= MIME-Version: 1.0 Received: by 10.211.153.2 with SMTP id f2mr5066466ebo.42.1255410799196; Mon, 12 Oct 2009 22:13:19 -0700 (PDT) Date: Tue, 13 Oct 2009 06:13:19 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00504502d11ebbbbe50475ca1a2a Subject: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 05:13:28 -0000 --00504502d11ebbbbe50475ca1a2a Content-Type: text/plain; charset=ISO-8859-1 One of the advantages we have in developing the VWRAP protocols is that we are able to look back at legacy SL and Opensim protocols and recognize design mistakes or limitations in them. This allows us to avoid repeating such mistakes or limitations in the next generation of systems. One of the most common sources of frustration and dissatisfaction is simulator non-responsiveness. While this has many possible causes, in VWRAP we are not interested in the internal implementation of simulators, but we * ARE* interested in the ability of a protocol endpoint to perform its duty within the protocol. A jammed simulator host is in many cases quite unable to perform its protocol duties, or in some cases only exceedingly slowly, often timing out in a TP for example. We have a huge amount of experience of this happening in both SL and Opensim, so it is a practical reality. On occasion, simulators will be unable to fulfil their part in a protocol, and this needs to be taken into account because it is *not uncommon*. One key area in which the above is relevant is in teleports *OUT* of a simulator that is under distress. Quite often users wish nothing more than to *leave* the region being run by a dying simulator, but when teleport-out requires cooperation from the host that one is trying to leave then this is often not possible at all. In this situation, the only remedy in existing systems is to forcibly terminate the client and relog in another region. We should avoid such out-of-protocol remedies being necessary through good protocol design. In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, which lead to corresponding protocol operations during teleport. If R1 is a region being run by a non-responsive simulator from which we want to escape, and R2 is another region to which we wish to go, if the protocol requires a Derez in R1 to be completed before a Rez in R2 can commence then the user will have difficulties. Clearly we don't want this. In http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 , it is made clear that "*The agent domain MUST also remove the avatar from it's current location before placing the avatar in the destination location*." This suggests that the protocol will be sensitive to R1 non-responsiveness. While we do not yet have an actual VWRAP Teleport draft, it seems likely that its initial incarnation will have that same problem built in. I suggest that the protocol define Derez and Rez as *concurrent* and * non-dependent* operations to avoid this situation. The AD can mark R1 as disabled for all further agent state changes --- this will provide all the protection needed to prevent brief double-presence anomalies from being significant. If a jammed R1 refuses to give up its hold on the avatar, then at least the user will not suffer from it. Reaping dead simulator sessions then becomes a problem for the region operator alone, and not for the AD, the user, and the region as happens now. Morgaine. --00504502d11ebbbbe50475ca1a2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One of the advantages we have in developing the VWRAP protocols is that we = are able to look back at legacy SL and Opensim protocols and recognize desi= gn mistakes or limitations in them.=A0 This allows us to avoid repeating su= ch mistakes or limitations in the next generation of systems.

One of the most common sources of frustration and dissatisfaction is si= mulator non-responsiveness.=A0 While this has many possible causes, in VWRA= P we are not interested in the internal implementation of simulators, but w= e ARE interested in the ability of a protocol endpoint to perform it= s duty within the protocol.=A0 A jammed simulator host is in many cases qui= te unable to perform its protocol duties, or in some cases only exceedingly= slowly, often timing out in a TP for example.=A0 We have a huge amount of = experience of this happening in both SL and Opensim, so it is a practical r= eality.=A0 On occasion, simulators will be unable to fulfil their part in a= protocol, and this needs to be taken into account because it is not unc= ommon.

One key area in which the above is relevant is in teleports OUT = of a simulator that is under distress.=A0 Quite often users wish nothing mo= re than to leave the region being run by a dying simulator, but when= teleport-out requires cooperation from the host that one is trying to leav= e then this is often not possible at all.=A0 In this situation, the only re= medy in existing systems is to forcibly terminate the client and relog in a= nother region.=A0 We should avoid such out-of-protocol remedies being neces= sary through good protocol design.

In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, which = lead to corresponding protocol operations during teleport.=A0 If R1 is a re= gion being run by a non-responsive simulator from which we want to escape, = and R2 is another region to which we wish to go, if the protocol requires a= Derez in R1 to be completed before a Rez in R2 can commence then the user = will have difficulties.=A0 Clearly we don't want this.

In ht= tp://tools.ietf.org/html/draft-hamrick-ogp-intro-00 , it is made clear = that "The agent domain MUST also remove the avatar from it's cu= rrent location before placing the avatar in the destination location= ."=A0 This suggests that the protocol will be sensitive to R1 non-= responsiveness.=A0 While we do not yet have an actual VWRAP Teleport draft,= it seems likely that its initial incarnation will have that same problem b= uilt in.

I suggest that the protocol define Derez and Rez as concurrent and non-dependent operations to avoid this situation.= =A0 The AD can mark R1 as disabled for all further agent state changes --- = this will provide all the protection needed to prevent brief double-presenc= e anomalies from being significant.=A0 If a jammed R1 refuses to give up it= s hold on the avatar, then at least the user will not suffer from it.=A0 Re= aping dead simulator sessions then becomes a problem for the region operato= r alone, and not for the AD, the user, and the region as happens now.


Morgaine.



--00504502d11ebbbbe50475ca1a2a-- From kari.lippert@gmail.com Mon Oct 12 22:26:04 2009 Return-Path: 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 77E5C28C1DB for ; Mon, 12 Oct 2009 22:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[AWL=-1.272, BAYES_40=-0.185, HTML_MESSAGE=0.001, SARE_UNSUB18=0.131] 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 z3MoZcWGdF6B for ; Mon, 12 Oct 2009 22:26:03 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id ADD4B3A6875 for ; Mon, 12 Oct 2009 22:26:02 -0700 (PDT) Received: by ewy4 with SMTP id 4so3053424ewy.37 for ; Mon, 12 Oct 2009 22:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fb85zEQNS9AfbtB+wclp60KIHNc+ooSjZfsMftiieSs=; b=CSHct50cY2G2ywmrk2UB9Rq+Hi+L0AGIpb+TTgXJNXQVEd2JzLdoycV5zh4UdV3JXz ktQTCKsPhBvtIeewdfX9x2CWXukc8yb758pSY0/End3eMu3c/yPcqwbbOPYGoeZUD0rT HK0ivl2wzI4v0Ux1b2B1pqUjFpa3cQ/7hqpZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UxESIM3cqR/WKV3fZSZQM5se04QmsdXGoBXaVNxd/f3E4fxCyRS1UaN5s8DSQT7HCf hdOXxWwmAkch/yi2eHPQernmjSVsdHTWw+sM5LboFevgOW6jsfMasmaj0Y8eznKYEuu8 DP70NucvPnsaiRG7hT/unv866FN0L00EPbyTE= MIME-Version: 1.0 Received: by 10.216.89.73 with SMTP id b51mr2198143wef.125.1255411560014; Mon, 12 Oct 2009 22:26:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Oct 2009 01:25:59 -0400 Message-ID: <382d73da0910122225l73a48b7al44675dcb0abf709d@mail.gmail.com> From: Kari Lippert To: Morgaine Content-Type: multipart/alternative; boundary=0016e6d6448614e32a0475ca485f Cc: ogpx@ietf.org Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 05:26:04 -0000 --0016e6d6448614e32a0475ca485f Content-Type: text/plain; charset=ISO-8859-1 I suggest that the protocol define Derez and Rez as *concurrent* and * non-dependent* operations to avoid this situation. The AD can mark R1 as disabled for all further agent state changes --- this will provide all the protection needed to prevent brief double-presence anomalies from being significant. If a jammed R1 refuses to give up its hold on the avatar, then at least the user will not suffer from it. Reaping dead simulator sessions then becomes a problem for the region operator alone, and not for the AD, the user, and the region as happens now. +1 Kari On Tue, Oct 13, 2009 at 1:13 AM, Morgaine wrote: > One of the advantages we have in developing the VWRAP protocols is that we > are able to look back at legacy SL and Opensim protocols and recognize > design mistakes or limitations in them. This allows us to avoid repeating > such mistakes or limitations in the next generation of systems. > > One of the most common sources of frustration and dissatisfaction is > simulator non-responsiveness. While this has many possible causes, in VWRAP > we are not interested in the internal implementation of simulators, but we > *ARE* interested in the ability of a protocol endpoint to perform its duty > within the protocol. A jammed simulator host is in many cases quite unable > to perform its protocol duties, or in some cases only exceedingly slowly, > often timing out in a TP for example. We have a huge amount of experience > of this happening in both SL and Opensim, so it is a practical reality. On > occasion, simulators will be unable to fulfil their part in a protocol, and > this needs to be taken into account because it is *not uncommon*. > > One key area in which the above is relevant is in teleports *OUT* of a > simulator that is under distress. Quite often users wish nothing more than > to *leave* the region being run by a dying simulator, but when > teleport-out requires cooperation from the host that one is trying to leave > then this is often not possible at all. In this situation, the only remedy > in existing systems is to forcibly terminate the client and relog in another > region. We should avoid such out-of-protocol remedies being necessary > through good protocol design. > > In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, which lead > to corresponding protocol operations during teleport. If R1 is a region > being run by a non-responsive simulator from which we want to escape, and R2 > is another region to which we wish to go, if the protocol requires a Derez > in R1 to be completed before a Rez in R2 can commence then the user will > have difficulties. Clearly we don't want this. > > In http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 , it is made > clear that "*The agent domain MUST also remove the avatar from it's > current location before placing the avatar in the destination location*." > This suggests that the protocol will be sensitive to R1 non-responsiveness. > While we do not yet have an actual VWRAP Teleport draft, it seems likely > that its initial incarnation will have that same problem built in. > > I suggest that the protocol define Derez and Rez as *concurrent* and * > non-dependent* operations to avoid this situation. The AD can mark R1 as > disabled for all further agent state changes --- this will provide all the > protection needed to prevent brief double-presence anomalies from being > significant. If a jammed R1 refuses to give up its hold on the avatar, then > at least the user will not suffer from it. Reaping dead simulator sessions > then becomes a problem for the region operator alone, and not for the AD, > the user, and the region as happens now. > > > Morgaine. > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0016e6d6448614e32a0475ca485f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I suggest that the protocol define Derez and Rez as=A0concurrent<= font class=3D"Apple-style-span" color=3D"#FF9900">=A0and=A0non-dependent=A0operations to avoid = this situation.=A0 The AD can mark R1 as disabled for all further agent sta= te changes --- this will provide all the protection needed to prevent brief= double-presence anomalies from being significant.=A0 If a jammed R1 refuse= s to give up its hold on the avatar, then at least the user will not suffer= from it.=A0 Reaping dead simulator sessions then becomes a problem for the= region operator alone, and not for the AD, the user, and the region as hap= pens now.


+1


Kari



On Tue, Oct 13, 2009 at = 1:13 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
One of the advantages we have in developing= the VWRAP protocols is that we are able to look back at legacy SL and Open= sim protocols and recognize design mistakes or limitations in them.=A0 This= allows us to avoid repeating such mistakes or limitations in the next gene= ration of systems.

One of the most common sources of frustration and dissatisfaction is si= mulator non-responsiveness.=A0 While this has many possible causes, in VWRA= P we are not interested in the internal implementation of simulators, but w= e ARE interested in the ability of a protocol endpoint to perform it= s duty within the protocol.=A0 A jammed simulator host is in many cases qui= te unable to perform its protocol duties, or in some cases only exceedingly= slowly, often timing out in a TP for example.=A0 We have a huge amount of = experience of this happening in both SL and Opensim, so it is a practical r= eality.=A0 On occasion, simulators will be unable to fulfil their part in a= protocol, and this needs to be taken into account because it is not unc= ommon.

One key area in which the above is relevant is in teleports OUT = of a simulator that is under distress.=A0 Quite often users wish nothing mo= re than to leave the region being run by a dying simulator, but when= teleport-out requires cooperation from the host that one is trying to leav= e then this is often not possible at all.=A0 In this situation, the only re= medy in existing systems is to forcibly terminate the client and relog in a= nother region.=A0 We should avoid such out-of-protocol remedies being neces= sary through good protocol design.

In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, which = lead to corresponding protocol operations during teleport.=A0 If R1 is a re= gion being run by a non-responsive simulator from which we want to escape, = and R2 is another region to which we wish to go, if the protocol requires a= Derez in R1 to be completed before a Rez in R2 can commence then the user = will have difficulties.=A0 Clearly we don't want this.

In http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 ,= it is made clear that "The agent domain MUST also remove the avata= r from it's current location before placing the avatar in the de= stination location."=A0 This suggests that the protocol will be se= nsitive to R1 non-responsiveness.=A0 While we do not yet have an actual VWR= AP Teleport draft, it seems likely that its initial incarnation will have t= hat same problem built in.

I suggest that the protocol define Derez and Rez as concurrent and non-dependent operations to avoid this situation.= =A0 The AD can mark R1 as disabled for all further agent state changes --- = this will provide all the protection needed to prevent brief double-presenc= e anomalies from being significant.=A0 If a jammed R1 refuses to give up it= s hold on the avatar, then at least the user will not suffer from it.=A0 Re= aping dead simulator sessions then becomes a problem for the region operato= r alone, and not for the AD, the user, and the region as happens now.


Morgaine.




_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--0016e6d6448614e32a0475ca485f-- From infinity@lindenlab.com Tue Oct 13 05:20:38 2009 Return-Path: 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 592BC28C172 for ; Tue, 13 Oct 2009 05:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 LdKqXHfIj30g for ; Tue, 13 Oct 2009 05:20:37 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 4649128C15E for ; Tue, 13 Oct 2009 05:20:37 -0700 (PDT) Received: by pxi6 with SMTP id 6so13154pxi.31 for ; Tue, 13 Oct 2009 05:20:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.6.8 with SMTP id 8mr585220wff.326.1255436435171; Tue, 13 Oct 2009 05:20:35 -0700 (PDT) In-Reply-To: <382d73da0910122225l73a48b7al44675dcb0abf709d@mail.gmail.com> References: <382d73da0910122225l73a48b7al44675dcb0abf709d@mail.gmail.com> From: "Infinity Linden (Meadhbh Hamrick)" Date: Tue, 13 Oct 2009 05:20:15 -0700 Message-ID: <3a880e2c0910130520i69ca056asdeef38650855fbf9@mail.gmail.com> To: Kari Lippert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 12:20:38 -0000 the reason the teleport process removes a user from one region before placing it in another is to ensure that the user's avatar exists in at most one place. i understand that this is a non-issue with hypergrid or tourist models, as there's no assumption of coherence between regions. but, many of us want to provide a virtual world experience that includes this concept. thx m/=E2=88=9E -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden On Mon, Oct 12, 2009 at 22:25, Kari Lippert wrote: > I suggest that the protocol define Derez and Rez > as=C2=A0concurrent=C2=A0and=C2=A0non-dependent=C2=A0operations to avoid t= his situation.=C2=A0 The AD > can mark R1 as disabled for all further agent state changes --- this will > provide all the protection needed to prevent brief double-presence anomal= ies > from being significant.=C2=A0 If a jammed R1 refuses to give up its hold = on the > avatar, then at least the user will not suffer from it.=C2=A0 Reaping dea= d > simulator sessions then becomes a problem for the region operator alone, = and > not for the AD, the user, and the region as happens now. > > +1 > > Kari > > > On Tue, Oct 13, 2009 at 1:13 AM, Morgaine > wrote: >> >> One of the advantages we have in developing the VWRAP protocols is that = we >> are able to look back at legacy SL and Opensim protocols and recognize >> design mistakes or limitations in them.=C2=A0 This allows us to avoid re= peating >> such mistakes or limitations in the next generation of systems. >> >> One of the most common sources of frustration and dissatisfaction is >> simulator non-responsiveness.=C2=A0 While this has many possible causes,= in VWRAP >> we are not interested in the internal implementation of simulators, but = we >> ARE interested in the ability of a protocol endpoint to perform its duty >> within the protocol.=C2=A0 A jammed simulator host is in many cases quit= e unable >> to perform its protocol duties, or in some cases only exceedingly slowly= , >> often timing out in a TP for example.=C2=A0 We have a huge amount of exp= erience >> of this happening in both SL and Opensim, so it is a practical reality.= =C2=A0 On >> occasion, simulators will be unable to fulfil their part in a protocol, = and >> this needs to be taken into account because it is not uncommon. >> >> One key area in which the above is relevant is in teleports OUT of a >> simulator that is under distress.=C2=A0 Quite often users wish nothing m= ore than >> to leave the region being run by a dying simulator, but when teleport-ou= t >> requires cooperation from the host that one is trying to leave then this= is >> often not possible at all.=C2=A0 In this situation, the only remedy in e= xisting >> systems is to forcibly terminate the client and relog in another region.= =C2=A0 We >> should avoid such out-of-protocol remedies being necessary through good >> protocol design. >> >> In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, which >> lead to corresponding protocol operations during teleport.=C2=A0 If R1 i= s a >> region being run by a non-responsive simulator from which we want to esc= ape, >> and R2 is another region to which we wish to go, if the protocol require= s a >> Derez in R1 to be completed before a Rez in R2 can commence then the use= r >> will have difficulties.=C2=A0 Clearly we don't want this. >> >> In http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 , it is made >> clear that "The agent domain MUST also remove the avatar from it's curre= nt >> location before placing the avatar in the destination location."=C2=A0 T= his >> suggests that the protocol will be sensitive to R1 non-responsiveness. >> While we do not yet have an actual VWRAP Teleport draft, it seems likely >> that its initial incarnation will have that same problem built in. >> >> I suggest that the protocol define Derez and Rez as concurrent and >> non-dependent operations to avoid this situation.=C2=A0 The AD can mark = R1 as >> disabled for all further agent state changes --- this will provide all t= he >> protection needed to prevent brief double-presence anomalies from being >> significant.=C2=A0 If a jammed R1 refuses to give up its hold on the ava= tar, then >> at least the user will not suffer from it.=C2=A0 Reaping dead simulator = sessions >> then becomes a problem for the region operator alone, and not for the AD= , >> the user, and the region as happens now. >> >> >> Morgaine. >> >> >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From josh@lindenlab.com Tue Oct 13 08:53:21 2009 Return-Path: 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 2D2633A6774 for ; Tue, 13 Oct 2009 08:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 JNZMSPGqSJX0 for ; Tue, 13 Oct 2009 08:53:20 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id C5ED33A6822 for ; Tue, 13 Oct 2009 08:53:16 -0700 (PDT) Received: by pzk42 with SMTP id 42so3176856pzk.31 for ; Tue, 13 Oct 2009 08:53:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.177.3 with SMTP id z3mr821151rve.127.1255449195172; Tue, 13 Oct 2009 08:53:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Oct 2009 08:53:15 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cd1a6204fd2a50475d30bb7 Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 15:53:21 -0000 --000e0cd1a6204fd2a50475d30bb7 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 12, 2009 at 10:13 PM, Morgaine wrote: > I suggest that the protocol define Derez and Rez as *concurrent* and * > non-dependent* operations to avoid this situation. The AD can mark R1 as > disabled for all further agent state changes --- this will provide all the > protection needed to prevent brief double-presence anomalies from being > significant. If a jammed R1 refuses to give up its hold on the avatar, then > at least the user will not suffer from it. Reaping dead simulator sessions > then becomes a problem for the region operator alone, and not for the AD, > the user, and the region as happens now. > Unresponsive origin regions are an excellent use case to consider. One of the reasons that this fails today is that the origin RD maintains some amount of agent state (e.g. script state for attachments). For a sim-to-sim handoff, the origin RD must successfully transmit information either to the AD or the destination RD (or both), otherwise the user experience is poor (information is lost). Note that this needs to happen during a simple logoff/login as well. It seems to me that agent state in the AD should have ACID-ish characteristics, including the agent's current location. Given that we must be able to describe behavior of closing a client-AD connection when the RD is unresponsive (e.g. the host has dropped off the network, etc), I'd be inclined to tackle unresponsive origins in similar fashion for logout/login, region crossing, and teleport. (Which in the current drafts are indeed tackled together.) So: I would agree that the current behavior of SL is less than ideal - if the source region is unresponsive (for some TBD definition), a teleport should probably not fail. But to preserve user data (and preserve the user experience), the initial transport attempt must involve a transaction between the AD, source RD and destination RD. --000e0cd1a6204fd2a50475d30bb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Unresponsive origin regions are an excellent use cas= e to consider.

One of the reasons that this fails today is that the = origin RD maintains some amount of agent state (e.g. script state for attac= hments). For a sim-to-sim handoff, the origin RD must successfully transmit= information either to the AD or the destination RD (or both), otherwise th= e user experience is poor (information is lost).=C2=A0 Note that this needs= to happen during a simple logoff/login as well. It seems to me that agent = state in the AD should have ACID-ish characteristics, including the agent&#= 39;s current location.

Given that we must be able to describe behavior of closing a client-AD = connection when the RD is unresponsive (e.g. the host has dropped off the n= etwork, etc), I'd be inclined to tackle unresponsive origins in similar= fashion for logout/login, region crossing, and teleport. (Which in the cur= rent drafts are indeed tackled together.)

So: I would agree that the current behavior of SL is less than ideal - = if the source region is unresponsive (for some TBD definition), a teleport = should probably not fail. But to preserve user data (and preserve the user = experience), the initial transport attempt must involve a transaction betwe= en the AD, source RD and destination RD.

--000e0cd1a6204fd2a50475d30bb7-- From dwl@us.ibm.com Tue Oct 13 09:25:32 2009 Return-Path: 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 5ECF728C195; Tue, 13 Oct 2009 09:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Lc7AvdS6tCf1; Tue, 13 Oct 2009 09:25:31 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 2BBBD28C21B; Tue, 13 Oct 2009 09:25:31 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9DGHcHa012909; Tue, 13 Oct 2009 12:17:38 -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 n9DGPOPA253974; Tue, 13 Oct 2009 12:25:25 -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 n9DGLwq5019555; Tue, 13 Oct 2009 12:21:58 -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 n9DGLpUZ019252; Tue, 13 Oct 2009 12:21:53 -0400 In-Reply-To: References: To: Joshua Bell MIME-Version: 1.0 X-KeepSent: B8E4F058:345DE78D-8525764E:005956DF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Tue, 13 Oct 2009 12:25:16 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/13/2009 12:25:18, Serialize complete at 10/13/2009 12:25:18 Content-Type: multipart/alternative; boundary="=_alternative 005A34B48525764E_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 16:25:32 -0000 This is a multipart message in MIME format. --=_alternative 005A34B48525764E_= Content-Type: text/plain; charset="US-ASCII" I think this gets even messier when you look at multiple deployment patterns. With a range of possible ways people might build out the services, its going to be interesting to work out what one expects at a region That said, one assumes that the key services which matter for attempting to determine if a "region" is live are those which emit the agent's in world component's current state. Working out what's needed, and why, might well, help us put some bounds on this. - David Joshua Bell Sent by: ogpx-bounces@ietf.org 10/13/2009 11:53 AM To ogpx@ietf.org cc Subject Re: [ogpx] Teleports and protocol resilience On Mon, Oct 12, 2009 at 10:13 PM, Morgaine wrote: I suggest that the protocol define Derez and Rez as concurrent and non-dependent operations to avoid this situation. The AD can mark R1 as disabled for all further agent state changes --- this will provide all the protection needed to prevent brief double-presence anomalies from being significant. If a jammed R1 refuses to give up its hold on the avatar, then at least the user will not suffer from it. Reaping dead simulator sessions then becomes a problem for the region operator alone, and not for the AD, the user, and the region as happens now. Unresponsive origin regions are an excellent use case to consider. One of the reasons that this fails today is that the origin RD maintains some amount of agent state (e.g. script state for attachments). For a sim-to-sim handoff, the origin RD must successfully transmit information either to the AD or the destination RD (or both), otherwise the user experience is poor (information is lost). Note that this needs to happen during a simple logoff/login as well. It seems to me that agent state in the AD should have ACID-ish characteristics, including the agent's current location. Given that we must be able to describe behavior of closing a client-AD connection when the RD is unresponsive (e.g. the host has dropped off the network, etc), I'd be inclined to tackle unresponsive origins in similar fashion for logout/login, region crossing, and teleport. (Which in the current drafts are indeed tackled together.) So: I would agree that the current behavior of SL is less than ideal - if the source region is unresponsive (for some TBD definition), a teleport should probably not fail. But to preserve user data (and preserve the user experience), the initial transport attempt must involve a transaction between the AD, source RD and destination RD. _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 005A34B48525764E_= Content-Type: text/html; charset="US-ASCII"
I think this gets even messier when you look at multiple deployment patterns. With a range of possible ways people might build out the services, its going to be interesting to work out what one expects at a region That said, one assumes that the key services which matter for attempting to determine if a "region" is live are those which emit the agent's in world component's current state. Working out what's needed, and why, might well, help us put some bounds on this.

- David




Joshua Bell <josh@lindenlab.com>
Sent by: ogpx-bounces@ietf.org

10/13/2009 11:53 AM

To
ogpx@ietf.org
cc
Subject
Re: [ogpx] Teleports and protocol resilience





On Mon, Oct 12, 2009 at 10:13 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:
I suggest that the protocol define Derez and Rez as concurrent and non-dependent operations to avoid this situation.  The AD can mark R1 as disabled for all further agent state changes --- this will provide all the protection needed to prevent brief double-presence anomalies from being significant.  If a jammed R1 refuses to give up its hold on the avatar, then at least the user will not suffer from it.  Reaping dead simulator sessions then becomes a problem for the region operator alone, and not for the AD, the user, and the region as happens now.

Unresponsive origin regions are an excellent use case to consider.

One of the reasons that this fails today is that the origin RD maintains some amount of agent state (e.g. script state for attachments). For a sim-to-sim handoff, the origin RD must successfully transmit information either to the AD or the destination RD (or both), otherwise the user experience is poor (information is lost).  Note that this needs to happen during a simple logoff/login as well. It seems to me that agent state in the AD should have ACID-ish characteristics, including the agent's current location.

Given that we must be able to describe behavior of closing a client-AD connection when the RD is unresponsive (e.g. the host has dropped off the network, etc), I'd be inclined to tackle unresponsive origins in similar fashion for logout/login, region crossing, and teleport. (Which in the current drafts are indeed tackled together.)

So: I would agree that the current behavior of SL is less than ideal - if the source region is unresponsive (for some TBD definition), a teleport should probably not fail. But to preserve user data (and preserve the user experience), the initial transport attempt must involve a transaction between the AD, source RD and destination RD.
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 005A34B48525764E_=-- From meadhbh.siobhan@gmail.com Tue Oct 13 09:33:30 2009 Return-Path: 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 1E12E3A672E; Tue, 13 Oct 2009 09:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 qegXNHRYyCQG; Tue, 13 Oct 2009 09:33:28 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id A2CF33A6869; Tue, 13 Oct 2009 09:33:01 -0700 (PDT) Received: by pxi6 with SMTP id 6so264292pxi.31 for ; Tue, 13 Oct 2009 09:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2QynM7DsOJr95OBKM/p40VbDFW7x421VDVXHgBOavVU=; b=oxt29NMLlfQTPJb3fXn9NORzCa9jcMTsfSHD4o6Qs6hXeiu9fsZMDtAKavY3tpMnzi S2eNdl7Tzm0ohSNZe856ofAvftk9/AHiW+7ayH86iZ7CySEGxSv7XxSRL0+a6ToRolMn ti2x4zkblVh0x9cqEyCm1jFyp+vMz1VigLNlw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uNiQYPcT99cDcK6GWUWAJNe3IaTg7h6q9Y1lEpoSOl6GHVJ3/xU4OGrgWmecTJ0noz XipTCzCP1BJR5enYlTuLFieS0LMJi+/HixmAAjHE9iOPhF0+5QyCx/rnp4ND/huxUbVP WLFS/CnDmejT93Ok6pALcQ2f39B13Bmnh1tac= MIME-Version: 1.0 Received: by 10.115.101.10 with SMTP id d10mr12850468wam.61.1255451580346; Tue, 13 Oct 2009 09:33:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Oct 2009 09:33:00 -0700 Message-ID: From: Meadhbh Hamrick To: David W Levine Content-Type: multipart/alternative; boundary=0016e64b901a7ab2190475d399ca Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 16:33:30 -0000 --0016e64b901a7ab2190475d399ca Content-Type: text/plain; charset=ISO-8859-1 josh: two phase commit for teleport? i guess it _could_ work, but it would make things more complicated. david: this is why i want to limit the number of supported deployment patterns. while it would be a great research project to work out a "design language" for describing deployments, i think we should stick with the few deployment patterns we have before us: Second Life, Second Life with client mediated Services, Tourist and OpenSim standalone mode. (OpenSim UGAIM grid mode would probably be something like "Second Life with client mediated Services") my primary concern is, i don't want to standardize a teleport protocol that works ONLY with the tourist model. On Tue, Oct 13, 2009 at 9:25 AM, David W Levine wrote: > > I think this gets even messier when you look at multiple deployment > patterns. With a range of possible ways people might build out the services, > its going to be interesting to work out what one expects at a region That > said, one assumes that the key services which matter for attempting to > determine if a "region" is live are those which emit the agent's in world > component's current state. Working out what's needed, and why, might well, > help us put some bounds on this. > > - David > > > > > *Joshua Bell * > Sent by: ogpx-bounces@ietf.org > > 10/13/2009 11:53 AM > To > ogpx@ietf.org cc > Subject > Re: [ogpx] Teleports and protocol resilience > > > > > On Mon, Oct 12, 2009 at 10:13 PM, Morgaine <* > morgaine.dinova@googlemail.com* > wrote: > I suggest that the protocol define Derez and Rez as *concurrent* and * > non-dependent* operations to avoid this situation. The AD can mark R1 as > disabled for all further agent state changes --- this will provide all the > protection needed to prevent brief double-presence anomalies from being > significant. If a jammed R1 refuses to give up its hold on the avatar, then > at least the user will not suffer from it. Reaping dead simulator sessions > then becomes a problem for the region operator alone, and not for the AD, > the user, and the region as happens now. > > Unresponsive origin regions are an excellent use case to consider. > > One of the reasons that this fails today is that the origin RD maintains > some amount of agent state (e.g. script state for attachments). For a > sim-to-sim handoff, the origin RD must successfully transmit information > either to the AD or the destination RD (or both), otherwise the user > experience is poor (information is lost). Note that this needs to happen > during a simple logoff/login as well. It seems to me that agent state in the > AD should have ACID-ish characteristics, including the agent's current > location. > > Given that we must be able to describe behavior of closing a client-AD > connection when the RD is unresponsive (e.g. the host has dropped off the > network, etc), I'd be inclined to tackle unresponsive origins in similar > fashion for logout/login, region crossing, and teleport. (Which in the > current drafts are indeed tackled together.) > > So: I would agree that the current behavior of SL is less than ideal - if > the source region is unresponsive (for some TBD definition), a teleport > should probably not fail. But to preserve user data (and preserve the user > experience), the initial transport attempt must involve a transaction > between the AD, source RD and destination RD. > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0016e64b901a7ab2190475d399ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable josh: two phase commit for teleport? i guess it _could_ work, but it would = make things more complicated.

david: this is why i want = to limit the number of supported deployment patterns. while it would be a g= reat research project to work out a "design language" for describ= ing deployments, i think we should stick with the few deployment patterns w= e have before us: Second Life, Second Life with client mediated Services, T= ourist and OpenSim standalone mode. (OpenSim UGAIM grid mode would probably= be something like "Second Life with client mediated Services")

my primary concern is, i don't want to standardize = a teleport protocol that works ONLY with the tourist model.

On Tue, Oct 13, 2009 at 9:25 AM, David W Levine <dwl@us.ibm.com> wrote:

I think this gets even messier whe= n you look at multiple deployment patterns. With a range of possible ways people might build out the services, its going to be interesting to work out what one expects at a region That said, one assumes that the key servic= es which matter for attempting to determine if a "region" is live are those which emit the agent's in world component's current state= . Working out what's needed, and why, might well, help us put some bounds on this= .

- David




Joshua Bell <<= a href=3D"mailto:josh@lindenlab.com" target=3D"_blank">josh@lindenlab.com>
Sent by: ogpx-bounces@ietf.org

10/13/2009 11:53 AM

To
ogpx@ietf.org
cc
Subject
Re: [ogpx] Teleports and prot= ocol resilience





On Mon, Oct 12, 2009 at 10:13 PM, Morgaine <= morgaine.dinova@googlemail.com> wrote:
I suggest that the protocol define Derez and Rez as concurrent and non-dependent operations to avoid this situation.=A0 The AD can mark R1 as disabled for all further agent state changes --- this will provide all the protection needed to prevent brief double-presenc= e anomalies from being significant.=A0 If a jammed R1 refuses to give up its hold on the avatar, then at least the user will not suffer from it.=A0 Reaping dead simulator sessions then becomes a problem for the region operator alone, and not for the AD, the user, and the region as happens now.

Unresponsive origin regions are an excellent use case to consider.

One of the reasons that this fails today is that the origin RD maintains some amount of agent state (e.g. script state for attachments). For a sim-t= o-sim handoff, the origin RD must successfully transmit information either to the AD or the destination RD (or both), otherwise the user experience is poor (information is lost).=A0 Note that this needs to happen during a simple logoff/login as well. It seems to me that agent state in the AD should have ACID-ish characteristics, including the agent's current loc= ation.

Given that we must be able to describe behavior of closing a client-AD connection when the RD is unresponsive (e.g. the host has dropped off the network, etc), I'd be inclined to tackle unresponsive origins in simila= r fashion for logout/login, region crossing, and teleport. (Which in the current drafts are indeed tackled together.)

So: I would agree that the current behavior of SL is less than ideal - if the source region is unresponsive (for some TBD definition), a teleport should probably not fail. But to preserve user data (and preserve the user experience), the initial transport attempt must involve a transaction betwe= en the AD, source RD and destination RD.
_= ______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx=


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--0016e64b901a7ab2190475d399ca-- From mike.dickson@hp.com Tue Oct 13 09:55:35 2009 Return-Path: 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 0C87528C1DF for ; Tue, 13 Oct 2009 09:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1HyxNaOIywTS for ; Tue, 13 Oct 2009 09:55:34 -0700 (PDT) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by core3.amsl.com (Postfix) with ESMTP id 47D6E28C1B6 for ; Tue, 13 Oct 2009 09:55:34 -0700 (PDT) Received: from g5t0012.atlanta.hp.com (g5t0012.atlanta.hp.com [15.192.0.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id 0490E2C0D8; Tue, 13 Oct 2009 16:55:35 +0000 (UTC) Received: from [192.168.1.139] (conr-adsl-209-169-71-194.consolidated.net [209.169.71.194]) by g5t0012.atlanta.hp.com (Postfix) with ESMTPSA id AFCE51001A; Tue, 13 Oct 2009 16:55:34 +0000 (UTC) From: Mike Dickson To: Joshua Bell In-Reply-To: References: Content-Type: text/plain Organization: HP ISB Date: Tue, 13 Oct 2009 11:55:33 -0500 Message-Id: <1255452933.4156.21.camel@mdickson-linux.local> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: "ogpx@ietf.org" Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 16:55:35 -0000 On Tue, 2009-10-13 at 15:53 +0000, Joshua Bell wrote: > One of the reasons that this fails today is that the origin RD > maintains some amount of agent state (e.g. script state for > attachments). For a sim-to-sim handoff, the origin RD must > successfully transmit information either to the AD or the destination > RD (or both), otherwise the user experience is poor (information is > lost). Note that this needs to happen during a simple logoff/login as > well. It seems to me that agent state in the AD should have ACID-ish > characteristics, including the agent's current location. The scripting comment is interesting re: interoperability also. What does that imply if I'm going from an OpenSim instance for example which has additional scripting functions enabled that a SL region might not support. How does the destination region determine it can run the scripts in attachments and that its safe to do so? Mike From cfk@pacbell.net Tue Oct 13 10:09:13 2009 Return-Path: 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 E60AA3A6967 for ; Tue, 13 Oct 2009 10:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 npvttNJHJ9cj for ; Tue, 13 Oct 2009 10:09:13 -0700 (PDT) Received: from web82603.mail.mud.yahoo.com (web82603.mail.mud.yahoo.com [68.142.201.120]) by core3.amsl.com (Postfix) with SMTP id EAD3F3A67DD for ; Tue, 13 Oct 2009 10:09:12 -0700 (PDT) Received: (qmail 28038 invoked by uid 60001); 13 Oct 2009 17:09:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gCcQUpDW6SVubReh184b39JB6BOe4UjCOXFm8wVeozlNYryTq095L3to1j5ZakkoxEy2gQy5TjnhLFSbpQn+xYxB7b5/cmMVe9IZ67FEyxNyP2guZHQFEYIzlhlAFw/MQvO+TLB9gIUSzcpucSZrxuNJep2f2/uZCbEKNiBPiZM=; Message-ID: <929772.26592.qm@web82603.mail.mud.yahoo.com> X-YMail-OSG: W4qyONoVM1nX6YJUT7FnoHyQl8FAduGAY1rADpwkpdKgenUVYtP21sb4GSHvIJOhtA_HDE3OWqa9cnMbqHf6LhT4NuaCtDtvWA8Ct_IzqE.iDO8EUAucD3XNaxMGsqyjPngHCkscqFpqmNaQ8YX.UnWplrQAg.cMUAaOxxwKnCi5MM6wGasf8D4c0.3_z01S_cVm.IrRw23fG_DcnYFqiIc2E66nmVZ5nqiQ6P4N3XaCCy3fU6_9gBdVMFzcSIm85MQJGd6NSRn6HpBrVhZRI.LBk.V3crTXE4q4ck8mDWCMgnXF4TIzbK6EPO2AAgJOFRWh3tYwMYynnTzGHOmgHNKPHFp2LdFwWTmZyfQNgd9ItnaYP7nNtpA4gM_Wi4g47F1yfoeU6EngPNm7IBXagkAawe0RbA1Tq2wo9wJKLD3t Received: from [216.156.179.114] by web82603.mail.mud.yahoo.com via HTTP; Tue, 13 Oct 2009 10:09:10 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 References: <1255452933.4156.21.camel@mdickson-linux.local> Date: Tue, 13 Oct 2009 10:09:10 -0700 (PDT) From: Charles Krinke To: Mike Dickson , Joshua Bell In-Reply-To: <1255452933.4156.21.camel@mdickson-linux.local> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-248207747-1255453750=:26592" Cc: "ogpx@ietf.org" Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 17:09:14 -0000 --0-248207747-1255453750=:26592 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Good point, Mike. I suspect the answer is going to be in how the protocol h= andles 'graceful' failure for teleports when the 'toRegion' has one or more= settings that are different then the 'fromRegion'.=0A=0ACharles=0A=0A=0A= =0A=0A________________________________=0AFrom: Mike Dickson =0ATo: Joshua Bell =0ACc: "ogpx@ietf.org" =0ASent: Tuesday, October 13, 2009 9:55:33 AM=0ASubject: Re: [ogpx]= Teleports and protocol resilience=0A=0AOn Tue, 2009-10-13 at 15:53 +0000, = Joshua Bell wrote:=0A=0A=0A> One of the reasons that this fails today is th= at the origin RD=0A> maintains some amount of agent state (e.g. script stat= e for=0A> attachments). For a sim-to-sim handoff, the origin RD must=0A> su= ccessfully transmit information either to the AD or the destination=0A> RD = (or both), otherwise the user experience is poor (information is=0A> lost).= =A0 Note that this needs to happen during a simple logoff/login as=0A> well= . It seems to me that agent state in the AD should have ACID-ish=0A> charac= teristics, including the agent's current location.=0A=0AThe scripting comme= nt is interesting re: interoperability also.=A0 What=0Adoes that imply if I= 'm going from an OpenSim instance for example which=0Ahas additional script= ing functions enabled that a SL region might not=0Asupport.=A0 How does the= destination region determine it can run the=0Ascripts in attachments and t= hat its safe to do so?=0A=0AMike=0A=0A=0A=0A_______________________________= ________________=0Aogpx mailing list=0Aogpx@ietf.org=0Ahttps://www.ietf.org= /mailman/listinfo/ogpx=0A --0-248207747-1255453750=:26592 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Good point, Mike. I suspect the answer is = going to be in how the protocol handles 'graceful' failure for teleports wh= en the 'toRegion' has one or more settings that are different then the 'fro= mRegion'.
=0A
 
=0A
Charles
=0A

=0A
=0A
=0AFrom: Mike Dickson <mike.dickson@= hp.com>
To: Joshua Be= ll <josh@lindenlab.com>
Cc: "ogpx@ietf.org" <ogpx@ietf.org>
Sent: Tuesday, October 13, 2009 9:55:33 AM
Subject: Re: [ogpx] Teleports an= d protocol resilience

On Tue, 2009-10-13 at 15:53 +0000, Josh= ua Bell wrote:


> One of the reasons that this fails today is = that the origin RD
> maintains some amount of agent state (e.g. scrip= t state for
> attachments). For a sim-to-sim handoff, the origin RD m= ust
> successfully transmit information either to the AD or the desti= nation
> RD (or both), otherwise the user experience is poor (informa= tion is
> lost).  Note that this needs to happen during a simple logoff/login as
> well. It seems to me that agent state in th= e AD should have ACID-ish
> characteristics, including the agent's cu= rrent location.

The scripting comment is interesting re: interoperab= ility also.  What
does that imply if I'm going from an OpenSim inst= ance for example which
has additional scripting functions enabled that a= SL region might not
support.  How does the destination region dete= rmine it can run the
scripts in attachments and that its safe to do so?<= BR>
Mike



_______________________________________________<= BR>ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx<= /A>
--0-248207747-1255453750=:26592-- From josh@lindenlab.com Tue Oct 13 10:25:14 2009 Return-Path: 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 680EF3A6358 for ; Tue, 13 Oct 2009 10:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.676 X-Spam-Level: X-Spam-Status: No, score=-0.676 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 6NBw8GPNc6xb for ; Tue, 13 Oct 2009 10:25:13 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 974AF3A63C9 for ; Tue, 13 Oct 2009 10:25:13 -0700 (PDT) Received: by pxi6 with SMTP id 6so320322pxi.31 for ; Tue, 13 Oct 2009 10:25:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.163.13 with SMTP id l13mr637757rve.263.1255454710509; Tue, 13 Oct 2009 10:25:10 -0700 (PDT) In-Reply-To: <1255452933.4156.21.camel@mdickson-linux.local> References: <1255452933.4156.21.camel@mdickson-linux.local> Date: Tue, 13 Oct 2009 10:25:10 -0700 Message-ID: From: Joshua Bell To: "ogpx@ietf.org" Content-Type: multipart/alternative; boundary=000e0cd2e2ba0d30010475d4541c Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 17:25:14 -0000 --000e0cd2e2ba0d30010475d4541c Content-Type: text/plain; charset=UTF-8 On Tue, Oct 13, 2009 at 9:55 AM, Mike Dickson wrote: > On Tue, 2009-10-13 at 15:53 +0000, Joshua Bell wrote: > > > One of the reasons that this fails today is that the origin RD > > maintains some amount of agent state (e.g. script state for > > attachments). For a sim-to-sim handoff, the origin RD must > > successfully transmit information either to the AD or the destination > > RD (or both), otherwise the user experience is poor (information is > > lost). Note that this needs to happen during a simple logoff/login as > > well. It seems to me that agent state in the AD should have ACID-ish > > characteristics, including the agent's current location. > > The scripting comment is interesting re: interoperability also. What > does that imply if I'm going from an OpenSim instance for example which > has additional scripting functions enabled that a SL region might not > support. How does the destination region determine it can run the > scripts in attachments and that its safe to do so? > > Awesome scenario to dive into. FWIW, we've dodged the bullet on this so far with Second Life. While an SL grid can operate in a heterogeneous state, we typically deploy new features with forward/backward compat issues in a "disabled" state until all hosts are updated to support the new feature, then flip a switch to enable it. In the script case, this would mean that the ability to author/compile scripts with new functionality would be disabled grid-wide until all hosts had been updated. Obviously that doesn't work once agents and data are crossing authoritative domains. :) Can any implementers of OpenSim (or other non-SL systems using the agent/region paradigm) describe how this is handled in those systems today? Is there region-specific state to an agent (attachments, scripts, etc) and how is this updated/maintained? How much effort falls on the content creator vs. the system administrators, how aware of this is the user, etc? --000e0cd2e2ba0d30010475d4541c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 13, 2009 at 9:55 AM, Mike Dickson <mike.dickson@hp.= com> wrote:
On Tue, 2009-10-13 at 15:53 +0000, Joshua Bell wrote:

> One of the reasons that this fails today is that the origin RD
> maintains some amount of agent state (e.g. script state for
> attachments). For a sim-to-sim handoff, the origin RD must
> successfully transmit information either to the AD or the destination<= br> > RD (or both), otherwise the user experience is poor (information is > lost). =C2=A0Note that this needs to happen during a simple logoff/log= in as
> well. It seems to me that agent state in the AD should have ACID-ish > characteristics, including the agent's current location.

The scripting comment is interesting re: interoperability also. =C2= =A0What
does that imply if I'm going from an OpenSim instance for example which=
has additional scripting functions enabled that a SL region might not
support. =C2=A0How does the destination region determine it can run the
scripts in attachments and that its safe to do so?


Awesome scenario to dive into.

FWIW, we&#= 39;ve dodged the bullet on this so far with Second Life. While an SL grid c= an operate in a heterogeneous state, we typically deploy new features with = forward/backward compat issues in a "disabled" state until all ho= sts are updated to support the new feature, then flip a switch to enable it= . In the script case, this would mean that the ability to author/compile sc= ripts with new functionality would be disabled grid-wide until all hosts ha= d been updated. Obviously that doesn't work once agents and data are cr= ossing authoritative domains. :)

Can any implementers of OpenSim (or other non-SL systems using the agen= t/region paradigm) describe how this is handled in those systems today? Is = there region-specific state to an agent (attachments, scripts, etc) and how= is this updated/maintained? How much effort falls on the content creator v= s. the system administrators, how aware of this is the user, etc?

--000e0cd2e2ba0d30010475d4541c-- From vaughn.deluca@gmail.com Tue Oct 13 10:31:34 2009 Return-Path: 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 BA2763A697C for ; Tue, 13 Oct 2009 10:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 rO9j+tIDpoxX for ; Tue, 13 Oct 2009 10:31:33 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id 32A043A69C6 for ; Tue, 13 Oct 2009 10:31:33 -0700 (PDT) Received: by fxm28 with SMTP id 28so8681629fxm.42 for ; Tue, 13 Oct 2009 10:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=PIBrdqfpP/P3sl/Sunvpgr4zLdKsowW6c6aCrs8QV60=; b=fuDHDll/vCnP2Vbylm33yLdi664ganhlWRPolEBHmvLEzegTK1AYz4jhlm3pEUBCji 3Vsyp8OIsjGCHOuHn1aIc4Y45uZQHb8XTrYzsEQ8f1Q9r0AV2ZYlVrBhrrgB/fXa/0hU BZm9UNI2kjUQqni0LUjo6siRUJzXVLp84DiIc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=yEHMWBEawC7hd0Ezvus3aNSOocrr1tODd1ZU4xG7WLzG5cc+WmBazzqLhKy0A3nQ6G X0cvJ4h8QzycV5Q0xYf3b57X/k4dd6ZjFtDNYvy/FxwCMngD44DqBDqvxkNNE99bJrPh qv+wZt/ybgmq4wZP9IRkUEFU+ahtIGtTjaFj8= MIME-Version: 1.0 Received: by 10.204.154.209 with SMTP id p17mr6356541bkw.104.1255455090994; Tue, 13 Oct 2009 10:31:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Oct 2009 19:31:30 +0200 Message-ID: <9b8a8de40910131031u3c4822eeo665021057514177a@mail.gmail.com> From: Vaughn Deluca To: Joshua Bell Content-Type: multipart/alternative; boundary=0015175cd0eabaef2f0475d46af9 Cc: ogpx@ietf.org Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 17:31:34 -0000 --0015175cd0eabaef2f0475d46af9 Content-Type: text/plain; charset=ISO-8859-1 Regarding the serialisation and passing-off of avatar data, the present TP draft keeps the source region in the communication path, even *after* a successful Derez and serialisation. The result from the new Rez is passed via the source region back to the agent domain. There might be good reasons for that path (efficiency?), but for sure it complicates things if the source region is dying. @Joshua RD is not the same as Region, in the TP drafs its the Region(service) that has the interface. @Infinity, the tourist use case is not very well defined as yet (working on that) but in my interpretation if will for sure specify the same constraint of "no duplication of avatars". -Vaughn On Tue, Oct 13, 2009 at 5:53 PM, Joshua Bell wrote: > On Mon, Oct 12, 2009 at 10:13 PM, Morgaine > wrote: > >> I suggest that the protocol define Derez and Rez as *concurrent* and * >> non-dependent* operations to avoid this situation. The AD can mark R1 as >> disabled for all further agent state changes --- this will provide all the >> protection needed to prevent brief double-presence anomalies from being >> significant. If a jammed R1 refuses to give up its hold on the avatar, then >> at least the user will not suffer from it. Reaping dead simulator sessions >> then becomes a problem for the region operator alone, and not for the AD, >> the user, and the region as happens now. >> > > Unresponsive origin regions are an excellent use case to consider. > > One of the reasons that this fails today is that the origin RD maintains > some amount of agent state (e.g. script state for attachments). For a > sim-to-sim handoff, the origin RD must successfully transmit information > either to the AD or the destination RD (or both), otherwise the user > experience is poor (information is lost). Note that this needs to happen > during a simple logoff/login as well. It seems to me that agent state in the > AD should have ACID-ish characteristics, including the agent's current > location. > > Given that we must be able to describe behavior of closing a client-AD > connection when the RD is unresponsive (e.g. the host has dropped off the > network, etc), I'd be inclined to tackle unresponsive origins in similar > fashion for logout/login, region crossing, and teleport. (Which in the > current drafts are indeed tackled together.) > > So: I would agree that the current behavior of SL is less than ideal - if > the source region is unresponsive (for some TBD definition), a teleport > should probably not fail. But to preserve user data (and preserve the user > experience), the initial transport attempt must involve a transaction > between the AD, source RD and destination RD. > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0015175cd0eabaef2f0475d46af9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Regarding the serialisation and passing-off of avatar data, the presen= t TP draft keeps the source region in the communication path, even *after* = a successful Derez and serialisation. The result from the new Rez is passed= via the source region back to the agent domain.=A0
There might be good reasons for that path (efficiency?), but for= sure it complicates things if the source region is dying.

@Joshua
RD is not the same as Region, in the TP= drafs its the Region(service) that has the interface.

@Infinity, the tourist use case is not very well define= d as yet (working on that) but in my interpretation if will for sure specif= y the same constraint of "no duplication of avatars".

-Vaughn


On Tue, Oct 13, 2009 at 5:53 PM, Joshua Bell <josh@lindenlab.com> wrote:=
On Mon, Oct 12, 2009 at 10:13 PM, Morgaine <morgaine.dinov= a@googlemail.com> wrote:
I suggest that the protocol define Derez and Rez as concurrent and non-dependent operations to avoid this situation.=A0 Th= e AD can mark R1 as disabled for all further agent state changes --- this w= ill provide all the protection needed to prevent brief double-presence anom= alies from being significant.=A0 If a jammed R1 refuses to give up its hold= on the avatar, then at least the user will not suffer from it.=A0 Reaping = dead simulator sessions then becomes a problem for the region operator alon= e, and not for the AD, the user, and the region as happens now.

Unresponsive origin regions are an excellent u= se case to consider.

One of the reasons that this fails today is tha= t the origin RD maintains some amount of agent state (e.g. script state for= attachments). For a sim-to-sim handoff, the origin RD must successfully tr= ansmit information either to the AD or the destination RD (or both), otherw= ise the user experience is poor (information is lost).=A0 Note that this ne= eds to happen during a simple logoff/login as well. It seems to me that age= nt state in the AD should have ACID-ish characteristics, including the agen= t's current location.

Given that we must be able to describe behavior of closing a client-AD = connection when the RD is unresponsive (e.g. the host has dropped off the n= etwork, etc), I'd be inclined to tackle unresponsive origins in similar= fashion for logout/login, region crossing, and teleport. (Which in the cur= rent drafts are indeed tackled together.)

So: I would agree that the current behavior of SL is less than ideal - = if the source region is unresponsive (for some TBD definition), a teleport = should probably not fail. But to preserve user data (and preserve the user = experience), the initial transport attempt must involve a transaction betwe= en the AD, source RD and destination RD.


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--0015175cd0eabaef2f0475d46af9-- From josh@lindenlab.com Tue Oct 13 11:12:20 2009 Return-Path: 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 B448D28C15C for ; Tue, 13 Oct 2009 11:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.582 X-Spam-Level: X-Spam-Status: No, score=-0.582 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 q-YSjIQnUkQF for ; Tue, 13 Oct 2009 11:12:20 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 072A828C0E1 for ; Tue, 13 Oct 2009 11:12:19 -0700 (PDT) Received: by pzk42 with SMTP id 42so3323355pzk.31 for ; Tue, 13 Oct 2009 11:12:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.34.9 with SMTP id m9mr922134rvj.84.1255457538970; Tue, 13 Oct 2009 11:12:18 -0700 (PDT) In-Reply-To: <9b8a8de40910131031u3c4822eeo665021057514177a@mail.gmail.com> References: <9b8a8de40910131031u3c4822eeo665021057514177a@mail.gmail.com> Date: Tue, 13 Oct 2009 11:12:18 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cd29bd4a4149a0475d4fcd7 Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 18:12:20 -0000 --000e0cd29bd4a4149a0475d4fcd7 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 13, 2009 at 10:31 AM, Vaughn Deluca wrote: > @Joshua > RD is not the same as Region, in the TP drafs its the Region(service) that > has the interface. > > Oops - you're right, of course. Everything we're talking about on this thread can occur within a single RD or between two RDs. I was sloppily using "RD" as shorthand for "collection of services that implement region behavior" but in this case we need to be more precise. --000e0cd29bd4a4149a0475d4fcd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 13, 2009 at 10:31 AM, Vaughn Del= uca <vaughn= .deluca@gmail.com> wrote:
@Joshua
RD is not the same as Region, in= the TP drafs its the Region(service) that has the interface.


Oops - you're right, of course. Everything we&= #39;re talking about on this thread can occur within a single RD or between= two RDs. I was sloppily using "RD" as shorthand for "collec= tion of services that implement region behavior" but in this case we n= eed to be more precise.
--000e0cd29bd4a4149a0475d4fcd7-- From vaughn.deluca@gmail.com Tue Oct 13 11:31:02 2009 Return-Path: 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 9A93728C0E0 for ; Tue, 13 Oct 2009 11:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 AiyYYY0drmvR for ; Tue, 13 Oct 2009 11:31:01 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id 6018B3A657C for ; Tue, 13 Oct 2009 11:31:01 -0700 (PDT) Received: by fxm28 with SMTP id 28so8751545fxm.42 for ; Tue, 13 Oct 2009 11:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=T92eUkwJzqjfRQ8Q7OwDt/UKZ9TbX9qWZzD3oqWTj4g=; b=lYxq7uJ/65KTb8CKNh4/mdJx3WfJMs9IkKZ7IVqA77n1PHvIbxMfe5U3SFvODbjBvs F7VTWSvZ4d+kJ84WTUE7gN8Iv2p8D5zWmHCg8+sCmcD73pll9toYUAkQHyMKWPR77QeR xBsKevRyqyfCEMO1aoTemAUmjGu+wpVvLZJfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iFI3SsE1eorvLXHcbGWtQ4ZpOEnYrg+qyf+W/uhE/AxUH2+htBSyQIS6XLhs+oj1Fu EfDIZ1IaexyO2cK3DIjzvXWcmdQ0erskavtgIjRLRycvq4Bj0Mol43DCn6cz4LXrcD9c biRf1VRIbp0L8iNSLF1RZ0Ag/11T76TXSU09I= MIME-Version: 1.0 Received: by 10.204.7.195 with SMTP id e3mr6469759bke.118.1255458657953; Tue, 13 Oct 2009 11:30:57 -0700 (PDT) In-Reply-To: References: <9b8a8de40910131031u3c4822eeo665021057514177a@mail.gmail.com> Date: Tue, 13 Oct 2009 20:30:57 +0200 Message-ID: <9b8a8de40910131130h54f58910had4805c5c544f03b@mail.gmail.com> From: Vaughn Deluca To: Joshua Bell Content-Type: multipart/alternative; boundary=00151750e9505666960475d53f78 Cc: ogpx@ietf.org Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 18:31:02 -0000 --00151750e9505666960475d53f78 Content-Type: text/plain; charset=ISO-8859-1 :) I fell in that trap many times. But what about the the entity to serialise the avatar data to at derez? You mentioned either agent domain or destination region. the tp draft uses the region, with as a consequence a second pass trough the source region. What are the argument pro and contra this solution compared to serialising to the AD? I have the feeling the slightly non-obvious path in the draft was picked for a good reason, but i do not know enough about the details to see why. -Vaughn On Tue, Oct 13, 2009 at 8:12 PM, Joshua Bell wrote: > > On Tue, Oct 13, 2009 at 10:31 AM, Vaughn Deluca wrote: > >> @Joshua >> RD is not the same as Region, in the TP drafs its the Region(service) that >> has the interface. >> >> > Oops - you're right, of course. Everything we're talking about on this > thread can occur within a single RD or between two RDs. I was sloppily using > "RD" as shorthand for "collection of services that implement region > behavior" but in this case we need to be more precise. > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00151750e9505666960475d53f78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable :) I fell in that trap many times.

But what about the the enti= ty to serialise the avatar data to at derez? You mentioned either agent dom= ain or destination region.
the tp draft uses the region, with as = a consequence a second pass trough the source region.
What are the argument pro and contra this solution compared to seriali= sing to the AD?
I have the feeling the slightly non-obvious path = in the draft was picked for a good reason, but i do not know enough about t= he details to see why.=A0

-Vaughn=A0


On Tue, Oct 13, 2009 at 8:12 PM, Joshua Bell = <josh@lindenlab.com>= wrote:

On Tue, Oct 13, 2009 at 10:31 AM, Vaughn Deluca <= ;vaughn.deluca= @gmail.com> wrote:
@Joshua
RD is not the same as Region, in= the TP drafs its the Region(service) that has the interface.


Oops - you're right, of course. Everythi= ng we're talking about on this thread can occur within a single RD or b= etween two RDs. I was sloppily using "RD" as shorthand for "= collection of services that implement region behavior" but in this cas= e we need to be more precise.

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00151750e9505666960475d53f78-- From meadhbh.siobhan@gmail.com Tue Oct 13 12:40:32 2009 Return-Path: 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 0C88928C320 for ; Tue, 13 Oct 2009 12:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 5MVvqNj1jXQC for ; Tue, 13 Oct 2009 12:40:30 -0700 (PDT) Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id A253528C2CC for ; Tue, 13 Oct 2009 12:40:30 -0700 (PDT) Received: by pxi6 with SMTP id 6so445628pxi.31 for ; Tue, 13 Oct 2009 12:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8iuIMO9ABijPJohylHOQwOhrcGOHtP7WuPL2y0y0JhY=; b=eHpNU0m+/venKU3WQT6k04vbBN3e9k018siN+TQoXwhMlRezbNqIUsO1QJ+axUdAwg 48gfMboHQ7AGpd4s+Ajsf0q/M/5SE4AOsd8FibhrO6+YPQ4iKWsKedmKiUixSdKQ+mre Nrfyz2uaG6mwFjrAubGFtv/x7Y7R5b5xRkuTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cRETcC55bnvuN8EGnJPHky1uNyrVO7zbsumWGcNq2drkc0rcnhYEtdvhm+RnWiyGqX 6caUyamsHiaZIe6gEeoUbx8l5onZNI8MWRSxjZX+6gtX/JAKWtyFwvcS6Y+qL6Ymhode UnHiPLlTriHoOx8637aCPhog0ZDCbGa6ccVvI= MIME-Version: 1.0 Received: by 10.114.253.23 with SMTP id a23mr13126341wai.155.1255462828226; Tue, 13 Oct 2009 12:40:28 -0700 (PDT) In-Reply-To: <9b8a8de40910131031u3c4822eeo665021057514177a@mail.gmail.com> References: <9b8a8de40910131031u3c4822eeo665021057514177a@mail.gmail.com> Date: Tue, 13 Oct 2009 12:40:28 -0700 Message-ID: From: Meadhbh Hamrick To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 19:40:32 -0000 hmm.. there were several iterations of the teleport protocol. i'm not really sure this is how it was deployed. and if it is, i would argue it _shouldn't_ be deployed this way 'cause of the trust issue. in the typical "Second Life" use case, the client trusts the agent domain, and the agent domain trusts region domains 1 and 2. the two region domains do not necessarily trust each other. or rather, there may be utility to a future where all region domains do not need to directly trust all other region domains. in the "tourist" use case, the agent domain can be seen as an actor of the client, so it's really the client who directly trusts the two region domains. but, you retain the benefit when you do not depend on the two region domains trusting each other. man. we seriously need some diagrams. -cheers -meadhbh/infinity On Tue, Oct 13, 2009 at 10:31 AM, Vaughn Deluca w= rote: > Regarding the serialisation and passing-off of avatar data, the present T= P > draft keeps the source region in the communication path, even *after* a > successful Derez and serialisation. The result from the new Rez is passed > via the source region back to the agent domain. > There might be good reasons for that path (efficiency?), but for sure it > complicates things if the source region is dying. > @Joshua > RD is not the same as Region, in the TP drafs its the Region(service) tha= t > has the interface. > @Infinity, the tourist use case is not very well defined as yet (working = on > that) but in my interpretation if will for sure specify the same constrai= nt > of "no duplication of avatars". > -Vaughn > > On Tue, Oct 13, 2009 at 5:53 PM, Joshua Bell wrote: >> >> On Mon, Oct 12, 2009 at 10:13 PM, Morgaine >> wrote: >>> >>> I suggest that the protocol define Derez and Rez as concurrent and >>> non-dependent operations to avoid this situation.=A0 The AD can mark R1= as >>> disabled for all further agent state changes --- this will provide all = the >>> protection needed to prevent brief double-presence anomalies from being >>> significant.=A0 If a jammed R1 refuses to give up its hold on the avata= r, then >>> at least the user will not suffer from it.=A0 Reaping dead simulator se= ssions >>> then becomes a problem for the region operator alone, and not for the A= D, >>> the user, and the region as happens now. >> >> Unresponsive origin regions are an excellent use case to consider. >> >> One of the reasons that this fails today is that the origin RD maintains >> some amount of agent state (e.g. script state for attachments). For a >> sim-to-sim handoff, the origin RD must successfully transmit information >> either to the AD or the destination RD (or both), otherwise the user >> experience is poor (information is lost).=A0 Note that this needs to hap= pen >> during a simple logoff/login as well. It seems to me that agent state in= the >> AD should have ACID-ish characteristics, including the agent's current >> location. >> >> Given that we must be able to describe behavior of closing a client-AD >> connection when the RD is unresponsive (e.g. the host has dropped off th= e >> network, etc), I'd be inclined to tackle unresponsive origins in similar >> fashion for logout/login, region crossing, and teleport. (Which in the >> current drafts are indeed tackled together.) >> >> So: I would agree that the current behavior of SL is less than ideal - i= f >> the source region is unresponsive (for some TBD definition), a teleport >> should probably not fail. But to preserve user data (and preserve the us= er >> experience), the initial transport attempt must involve a transaction >> between the AD, source RD and destination RD. >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From dcolivares@gmail.com Tue Oct 13 12:55:09 2009 Return-Path: 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 345FD28C103 for ; Tue, 13 Oct 2009 12:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 e0o6h3ShZWIf for ; Tue, 13 Oct 2009 12:55:08 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id B1F713A67E2 for ; Tue, 13 Oct 2009 12:55:07 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so839255fgg.12 for ; Tue, 13 Oct 2009 12:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dSZY17Myf2m78sknCokzksWm4WxgVx9hMZKNM6FamdM=; b=q/TjZnaePzYkeWnNntm2EwTRJAqWR9mOrPjtDRHORQzCxuYah1y9Imyd74IoDy/6xR OjqOwNNmclvoV02u3EBV8ZdqXgLTvIvkX37NhwW9xJYn+ECcjOZVf5ys0TJCfpOsZHDN raqkNMdlyGB+GO75eUOIhLQfsfJt6e1FLaZEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EmUqtQjpPnbBPcx53whOCK+Dlcltx8ml1MTal0RX66Vv6oL6wGNpanSZyUfW4gXLpO efP/61Mjr4otsDPLMnWqrhnggRtM28jG4CnhxHLXxlJrS4epMBwLlqWQly41bKac8KmV xVDiZChM3NKLw2ySEuV+3Vj4PvEjSmArJqjbE= MIME-Version: 1.0 Received: by 10.86.195.29 with SMTP id s29mr2824797fgf.73.1255463705069; Tue, 13 Oct 2009 12:55:05 -0700 (PDT) In-Reply-To: References: <9b8a8de40910131031u3c4822eeo665021057514177a@mail.gmail.com> Date: Tue, 13 Oct 2009 15:55:04 -0400 Message-ID: From: Dan Olivares To: Meadhbh Hamrick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 19:55:09 -0000 One option here is to have a timeout within the agent domain for a response from the source region with a cap for the destination region and go over the source region's head to directly request it from the destination region. While this isn't always optimal (in the script and attachment state), it would provide a 'graceful failure' scenario. This would also necessitate the need to describe some kind of a priority 'state backup' mechanism that gets saved to periodically for when failures occur. It's my guess that some state is more important then others.. such as.. financial transaction state.. is more important then say.. who's within 20m on a sensor. Even though we've not discussed inventory itself yet, it would seem like we're heading in the direction of having the Agent Domain manage inventory, therefore the inventory transactions that take place themselves wouldn't be affected.. just the state of any item that's 'rezzed' in a simulator and not instanced (Attachments). Would people be okay with having old data on their attachments if they didn't have to log-off and log back on in a failure case? Regards Dan Olivares On Tue, Oct 13, 2009 at 3:40 PM, Meadhbh Hamrick wrote: > hmm.. there were several iterations of the teleport protocol. i'm not > really sure this is how it was deployed. and if it is, i would argue > it _shouldn't_ be deployed this way 'cause of the trust issue. > > in the typical "Second Life" use case, the client trusts the agent > domain, and the agent domain trusts region domains 1 and 2. the two > region domains do not necessarily trust each other. or rather, there > may be utility to a future where all region domains do not need to > directly trust all other region domains. in the "tourist" use case, > the agent domain can be seen as an actor of the client, so it's really > the client who directly trusts the two region domains. but, you retain > the benefit when you do not depend on the two region domains trusting > each other. > > man. we seriously need some diagrams. > > -cheers > -meadhbh/infinity > > On Tue, Oct 13, 2009 at 10:31 AM, Vaughn Deluca = wrote: >> Regarding the serialisation and passing-off of avatar data, the present = TP >> draft keeps the source region in the communication path, even *after* a >> successful Derez and serialisation. The result from the new Rez is passe= d >> via the source region back to the agent domain. >> There might be good reasons for that path (efficiency?), but for sure it >> complicates things if the source region is dying. >> @Joshua >> RD is not the same as Region, in the TP drafs its the Region(service) th= at >> has the interface. >> @Infinity, the tourist use case is not very well defined as yet (working= on >> that) but in my interpretation if will for sure specify the same constra= int >> of "no duplication of avatars". >> -Vaughn >> >> On Tue, Oct 13, 2009 at 5:53 PM, Joshua Bell wrote: >>> >>> On Mon, Oct 12, 2009 at 10:13 PM, Morgaine >>> wrote: >>>> >>>> I suggest that the protocol define Derez and Rez as concurrent and >>>> non-dependent operations to avoid this situation.=A0 The AD can mark R= 1 as >>>> disabled for all further agent state changes --- this will provide all= the >>>> protection needed to prevent brief double-presence anomalies from bein= g >>>> significant.=A0 If a jammed R1 refuses to give up its hold on the avat= ar, then >>>> at least the user will not suffer from it.=A0 Reaping dead simulator s= essions >>>> then becomes a problem for the region operator alone, and not for the = AD, >>>> the user, and the region as happens now. >>> >>> Unresponsive origin regions are an excellent use case to consider. >>> >>> One of the reasons that this fails today is that the origin RD maintain= s >>> some amount of agent state (e.g. script state for attachments). For a >>> sim-to-sim handoff, the origin RD must successfully transmit informatio= n >>> either to the AD or the destination RD (or both), otherwise the user >>> experience is poor (information is lost).=A0 Note that this needs to ha= ppen >>> during a simple logoff/login as well. It seems to me that agent state i= n the >>> AD should have ACID-ish characteristics, including the agent's current >>> location. >>> >>> Given that we must be able to describe behavior of closing a client-AD >>> connection when the RD is unresponsive (e.g. the host has dropped off t= he >>> network, etc), I'd be inclined to tackle unresponsive origins in simila= r >>> fashion for logout/login, region crossing, and teleport. (Which in the >>> current drafts are indeed tackled together.) >>> >>> So: I would agree that the current behavior of SL is less than ideal - = if >>> the source region is unresponsive (for some TBD definition), a teleport >>> should probably not fail. But to preserve user data (and preserve the u= ser >>> experience), the initial transport attempt must involve a transaction >>> between the AD, source RD and destination RD. >>> >>> >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >>> >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From meadhbh.siobhan@gmail.com Tue Oct 13 13:45:39 2009 Return-Path: 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 E09DD28C117 for ; Tue, 13 Oct 2009 13:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 oDnpVUmEAwlC for ; Tue, 13 Oct 2009 13:45:38 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id CB07728C108 for ; Tue, 13 Oct 2009 13:45:38 -0700 (PDT) Received: by pzk42 with SMTP id 42so88334pzk.31 for ; Tue, 13 Oct 2009 13:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=9O340Q1ubYVyIowicVrTmJ7drQZCC2U/CSUxPySig4c=; b=uKsZxMTRjQGGqBug7WVo2A6MtUGtAx0nTIZZX1Z2/485pzCtUWCFNeidfjioSP6gXI 0NnKjHQ+fjyL7Y8Ugp7OwMDqsCu/Hy22YIKOGCm2bs0W1UtSoiHQqhCohE9UGDE0sG1A a42VEJhbaN3rAqvH5+smnVcwNBzbkBOHwiyg0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Wqg8cgBcOcjfjRK+K62QAhLgNLuVJ2/5k3h/joWxnejfrMxeXjBHU23ZnTPgfqwiTj VYaam106Pr984a+PzER+iIMCZpdEx7VYK3bZdilRIjnORl9udUyjuk6JAGjx7IBs0YP4 OrLLeaOr+6/guS9hPMH5EWY+vyrOMIow0T4Jo= MIME-Version: 1.0 Received: by 10.114.253.23 with SMTP id a23mr13270707wai.155.1255466736667; Tue, 13 Oct 2009 13:45:36 -0700 (PDT) In-Reply-To: References: <9b8a8de40910131031u3c4822eeo665021057514177a@mail.gmail.com> Date: Tue, 13 Oct 2009 13:45:36 -0700 Message-ID: From: Meadhbh Hamrick To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 20:45:40 -0000 ack. this was supposed to go out to the list. On Tue, Oct 13, 2009 at 1:36 PM, Meadhbh Hamrick wrote: > but before we go too far down the rabbit hole with solutions, can we > make sure we understand the problem domain? > > if i understand it, there's a preference that a user's avatar be > rezzable in the destination region before it is derez'd in the source > region. so in other words, we don't want to derez the user's av from > where it is until we know it can be rezzed where it's going. > > is this a fair discussion of the problem? i mean irrespective of the > proposed solutions, this is a feature of teleport that we want, right? > > assuming there is consensus on this point, we may want to gingerly > inject the requirement that the agent domain or the destination region > domain MAY want to deny the user's teleport. (remember the fuss over > adult content and underaged users?) > > it seems that this is a reasonable place to consider this topic. > however, it doesn't seem like there's radical consensus over the > question of whether it's the AD's responsibility to block underage rez > attempts in adult sims or the destination RD's responsibility or both. > so when discussing teleport, maybe we could add some verbiage like > "the AD has the option to block the teleport request here" or "the RD > has the option to block the teleport here" in flow diagrams. > > -cheers > -meadhbh > > On Tue, Oct 13, 2009 at 12:40 PM, Meadhbh Hamrick > wrote: >> hmm.. there were several iterations of the teleport protocol. i'm not >> really sure this is how it was deployed. and if it is, i would argue >> it _shouldn't_ be deployed this way 'cause of the trust issue. >> >> in the typical "Second Life" use case, the client trusts the agent >> domain, and the agent domain trusts region domains 1 and 2. the two >> region domains do not necessarily trust each other. or rather, there >> may be utility to a future where all region domains do not need to >> directly trust all other region domains. in the "tourist" use case, >> the agent domain can be seen as an actor of the client, so it's really >> the client who directly trusts the two region domains. but, you retain >> the benefit when you do not depend on the two region domains trusting >> each other. >> >> man. we seriously need some diagrams. >> >> -cheers >> -meadhbh/infinity >> >> On Tue, Oct 13, 2009 at 10:31 AM, Vaughn Deluca wrote: >>> Regarding the serialisation and passing-off of avatar data, the present= TP >>> draft keeps the source region in the communication path, even *after* a >>> successful Derez and serialisation. The result from the new Rez is pass= ed >>> via the source region back to the agent domain. >>> There might be good reasons for that path (efficiency?), but for sure i= t >>> complicates things if the source region is dying. >>> @Joshua >>> RD is not the same as Region, in the TP drafs its the Region(service) t= hat >>> has the interface. >>> @Infinity, the tourist use case is not very well defined as yet (workin= g on >>> that) but in my interpretation if will for sure specify the same constr= aint >>> of "no duplication of avatars". >>> -Vaughn >>> >>> On Tue, Oct 13, 2009 at 5:53 PM, Joshua Bell wrote= : >>>> >>>> On Mon, Oct 12, 2009 at 10:13 PM, Morgaine >>>> wrote: >>>>> >>>>> I suggest that the protocol define Derez and Rez as concurrent and >>>>> non-dependent operations to avoid this situation.=A0 The AD can mark = R1 as >>>>> disabled for all further agent state changes --- this will provide al= l the >>>>> protection needed to prevent brief double-presence anomalies from bei= ng >>>>> significant.=A0 If a jammed R1 refuses to give up its hold on the ava= tar, then >>>>> at least the user will not suffer from it.=A0 Reaping dead simulator = sessions >>>>> then becomes a problem for the region operator alone, and not for the= AD, >>>>> the user, and the region as happens now. >>>> >>>> Unresponsive origin regions are an excellent use case to consider. >>>> >>>> One of the reasons that this fails today is that the origin RD maintai= ns >>>> some amount of agent state (e.g. script state for attachments). For a >>>> sim-to-sim handoff, the origin RD must successfully transmit informati= on >>>> either to the AD or the destination RD (or both), otherwise the user >>>> experience is poor (information is lost).=A0 Note that this needs to h= appen >>>> during a simple logoff/login as well. It seems to me that agent state = in the >>>> AD should have ACID-ish characteristics, including the agent's current >>>> location. >>>> >>>> Given that we must be able to describe behavior of closing a client-AD >>>> connection when the RD is unresponsive (e.g. the host has dropped off = the >>>> network, etc), I'd be inclined to tackle unresponsive origins in simil= ar >>>> fashion for logout/login, region crossing, and teleport. (Which in the >>>> current drafts are indeed tackled together.) >>>> >>>> So: I would agree that the current behavior of SL is less than ideal -= if >>>> the source region is unresponsive (for some TBD definition), a telepor= t >>>> should probably not fail. But to preserve user data (and preserve the = user >>>> experience), the initial transport attempt must involve a transaction >>>> between the AD, source RD and destination RD. >>>> >>>> >>>> _______________________________________________ >>>> ogpx mailing list >>>> ogpx@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ogpx >>>> >>> >>> >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >>> >>> >> > From vaughn.deluca@gmail.com Tue Oct 13 15:17:10 2009 Return-Path: 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 B77733A68A5 for ; Tue, 13 Oct 2009 15:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 LFSyiPHJNLNa for ; Tue, 13 Oct 2009 15:17:09 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id AF6AA3A6898 for ; Tue, 13 Oct 2009 15:17:08 -0700 (PDT) Received: by fxm28 with SMTP id 28so9016172fxm.42 for ; Tue, 13 Oct 2009 15:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=aaKQmncIA1NxGjQG5rXxsDQ5LaxvG0miZSHPiS1yGE0=; b=g+Ya1AB1Y7ykz4kqMalViXrtV8V81NS+wUVmpgWodWwPpKGhRd82On1Oe2mRT6f/lX SWX7S+mrvV8iNKp79yNnY6HyCLK0R3oJxO2ZtSIxarGNOdvVYWtGuDGrAKS2psmy2zeQ rzw88YjTGHryVfBPjWCCwwazTxE9SptakOiaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=WnFl931WNNg/mGL/tP/yPf/mo2WDCKJ3iMsEC7wLiRf2435vNQJKTjVRz657hVM5cR r37t6iWBl0eMXvTQ8o/Xfa5ZlfJFGgmdj1Q8lcdDqdwU4xWYYchaVq6MBaMOtn8nPX/A u7z0XFOSlg3wslpbofxc+Z4a2nNILuZSGeZVY= MIME-Version: 1.0 Received: by 10.204.154.85 with SMTP id n21mr2613995bkw.171.1255472226001; Tue, 13 Oct 2009 15:17:06 -0700 (PDT) In-Reply-To: References: <9b8a8de40910131031u3c4822eeo665021057514177a@mail.gmail.com> Date: Wed, 14 Oct 2009 00:17:05 +0200 Message-ID: <9b8a8de40910131517l4c3c02f9u7d16ada6068c2414@mail.gmail.com> From: Vaughn Deluca To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015175d0a3c0e63180475d868bf Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 22:17:10 -0000 --0015175d0a3c0e63180475d868bf Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 13, 2009 at 10:36 PM, Meadhbh Hamrick wrote: > but before we go too far down the rabbit hole with solutions, can we > make sure we understand the problem domain? > > if i understand it, there's a preference that a user's avatar be > rezzable in the destination region before it is derez'd in the source > region. so in other words, we don't want to derez the user's av from > where it is until we know it can be rezzed where it's going. > > is this a fair discussion of the problem? i mean irrespective of the > proposed solutions, this is a feature of teleport that we want, right? > Yes, i definitely think so. > assuming there is consensus on this point, we may want to gingerly > inject the requirement that the agent domain or the destination region > domain MAY want to deny the user's teleport. (remember the fuss over > adult content and underaged users?) > > it seems that this is a reasonable place to consider this topic. > however, it doesn't seem like there's radical consensus over the > question of whether it's the AD's responsibility to block underage rez > attempts in adult sims or the destination RD's responsibility or both. > I think there was reasonable consensus that both can block the TP, simply because its local policy that rules. > so when discussing teleport, maybe we could add some verbiage like > "the AD has the option to block the teleport request here" or "the RD > has the option to block the teleport here" in flow diagrams. > Absolutely, and I did so in this example: http://www.ietf.org/mail-archive/web/ogpx/current/msg00570.html :) -Vaughn > -cheers > -meadhbh > > On Tue, Oct 13, 2009 at 12:40 PM, Meadhbh Hamrick > wrote: > > hmm.. there were several iterations of the teleport protocol. i'm not > > really sure this is how it was deployed. and if it is, i would argue > > it _shouldn't_ be deployed this way 'cause of the trust issue. > > > > in the typical "Second Life" use case, the client trusts the agent > > domain, and the agent domain trusts region domains 1 and 2. the two > > region domains do not necessarily trust each other. or rather, there > > may be utility to a future where all region domains do not need to > > directly trust all other region domains. in the "tourist" use case, > > the agent domain can be seen as an actor of the client, so it's really > > the client who directly trusts the two region domains. but, you retain > > the benefit when you do not depend on the two region domains trusting > > each other. > > > > man. we seriously need some diagrams. > > > > -cheers > > -meadhbh/infinity > > > > On Tue, Oct 13, 2009 at 10:31 AM, Vaughn Deluca > wrote: > >> Regarding the serialisation and passing-off of avatar data, the present > TP > >> draft keeps the source region in the communication path, even *after* a > >> successful Derez and serialisation. The result from the new Rez is > passed > >> via the source region back to the agent domain. > >> There might be good reasons for that path (efficiency?), but for sure it > >> complicates things if the source region is dying. > >> @Joshua > >> RD is not the same as Region, in the TP drafs its the Region(service) > that > >> has the interface. > >> @Infinity, the tourist use case is not very well defined as yet (working > on > >> that) but in my interpretation if will for sure specify the same > constraint > >> of "no duplication of avatars". > >> -Vaughn > >> > >> On Tue, Oct 13, 2009 at 5:53 PM, Joshua Bell > wrote: > >>> > >>> On Mon, Oct 12, 2009 at 10:13 PM, Morgaine > >>> wrote: > >>>> > >>>> I suggest that the protocol define Derez and Rez as concurrent and > >>>> non-dependent operations to avoid this situation. The AD can mark R1 > as > >>>> disabled for all further agent state changes --- this will provide all > the > >>>> protection needed to prevent brief double-presence anomalies from > being > >>>> significant. If a jammed R1 refuses to give up its hold on the > avatar, then > >>>> at least the user will not suffer from it. Reaping dead simulator > sessions > >>>> then becomes a problem for the region operator alone, and not for the > AD, > >>>> the user, and the region as happens now. > >>> > >>> Unresponsive origin regions are an excellent use case to consider. > >>> > >>> One of the reasons that this fails today is that the origin RD > maintains > >>> some amount of agent state (e.g. script state for attachments). For a > >>> sim-to-sim handoff, the origin RD must successfully transmit > information > >>> either to the AD or the destination RD (or both), otherwise the user > >>> experience is poor (information is lost). Note that this needs to > happen > >>> during a simple logoff/login as well. It seems to me that agent state > in the > >>> AD should have ACID-ish characteristics, including the agent's current > >>> location. > >>> > >>> Given that we must be able to describe behavior of closing a client-AD > >>> connection when the RD is unresponsive (e.g. the host has dropped off > the > >>> network, etc), I'd be inclined to tackle unresponsive origins in > similar > >>> fashion for logout/login, region crossing, and teleport. (Which in the > >>> current drafts are indeed tackled together.) > >>> > >>> So: I would agree that the current behavior of SL is less than ideal - > if > >>> the source region is unresponsive (for some TBD definition), a teleport > >>> should probably not fail. But to preserve user data (and preserve the > user > >>> experience), the initial transport attempt must involve a transaction > >>> between the AD, source RD and destination RD. > >>> > >>> > >>> _______________________________________________ > >>> ogpx mailing list > >>> ogpx@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ogpx > >>> > >> > >> > >> _______________________________________________ > >> ogpx mailing list > >> ogpx@ietf.org > >> https://www.ietf.org/mailman/listinfo/ogpx > >> > >> > > > --0015175d0a3c0e63180475d868bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 13, 2009 at 10:36 PM, Meadhb= h Hamrick <meadhbh.siobhan@gmail.com> wrote:
but before we go too far down the rabbit hole with solutions, can we
make sure we understand the problem domain?

if i understand it, there's a preference that a user's avatar be rezzable in the destination region before it is derez'd in the source region. so in other words, we don't want to derez the user's av fro= m
where it is until we know it can be rezzed where it's going.

is this a fair discussion of the problem? i mean irrespective of the
proposed solutions, this is a feature of teleport that we want, right?
<= /blockquote>

Yes, i definitely think so.=A0
=A0
assuming there is consensus on this point, we may want to gingerly
inject the requirement that the agent domain or the destination region
domain MAY want to deny the user's teleport. (remember the fuss over adult content and underaged users?)

it seems that this is a reasonable place to consider this topic.
however, it doesn't seem like there's radical consensus over the question of whether it's the AD's responsibility to block underage = rez
attempts in adult sims or the destination RD's responsibility or both.<= br>

I think there was reasonable consensus that= both can block the TP, simply because its local policy that rules.
=A0
so when discussing teleport, maybe we could add some verbiage like
"the AD has the option to block the teleport request here" or &qu= ot;the RD
has the option to block the teleport here" in flow diagrams.

Absolutely, and I did so in this example:

:)
-Vaughn
=A0
-cheers
-meadhbh

On Tue, Oct 13, 2009 at 12:40 PM, Meadhbh Hamrick
<meadhbh.= siobhan@gmail.com> wrote:
> hmm.. there were several itera= tions of the teleport protocol. i'm not
> really sure this is how it was deployed. and if it is, i would argue > it _shouldn't_ be deployed this way 'cause of the trust issue.=
>
> in the typical "Second Life" use case, the client trusts the= agent
> domain, and the agent domain trusts region domains 1 and 2. the two > region domains do not necessarily trust each other. or rather, there > may be utility to a future where all region domains do not need to
> directly trust all other region domains. in the "tourist" us= e case,
> the agent domain can be seen as an actor of the client, so it's re= ally
> the client who directly trusts the two region domains. but, you retain=
> the benefit when you do not depend on the two region domains trusting<= br> > each other.
>
> man. we seriously need some diagrams.
>
> -cheers
> -meadhbh/infinity
>
> On Tue, Oct 13, 2009 at 10:31 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
>> Regarding the serialisation and passing-off of avatar data, the pr= esent TP
>> draft keeps the source region in the communication path, even *aft= er* a
>> successful Derez and serialisation. The result from the new Rez is= passed
>> via the source region back to the agent domain.
>> There might be good reasons for that path (efficiency?), but for s= ure it
>> complicates things if the source region is dying.
>> @Joshua
>> RD is not the same as Region, in the TP drafs its the Region(servi= ce) that
>> has the interface.
>> @Infinity, the tourist use case is not very well defined as yet (w= orking on
>> that) but in my interpretation if will for sure specify the same c= onstraint
>> of "no duplication of avatars".
>> -Vaughn
>>
>> On Tue, Oct 13, 2009 at 5:53 PM, Joshua Bell <josh@lindenlab.com> wrote:
>>>
>>> On Mon, Oct 12, 2009 at 10:13 PM, Morgaine
>>> <morgaine= .dinova@googlemail.com> wrote:
>>>>
>>>> I suggest that the protocol define Derez and Rez as concur= rent and
>>>> non-dependent operations to avoid this situation.=A0 The A= D can mark R1 as
>>>> disabled for all further agent state changes --- this will= provide all the
>>>> protection needed to prevent brief double-presence anomali= es from being
>>>> significant.=A0 If a jammed R1 refuses to give up its hold= on the avatar, then
>>>> at least the user will not suffer from it.=A0 Reaping dead= simulator sessions
>>>> then becomes a problem for the region operator alone, and = not for the AD,
>>>> the user, and the region as happens now.
>>>
>>> Unresponsive origin regions are an excellent use case to consi= der.
>>>
>>> One of the reasons that this fails today is that the origin RD= maintains
>>> some amount of agent state (e.g. script state for attachments)= . For a
>>> sim-to-sim handoff, the origin RD must successfully transmit i= nformation
>>> either to the AD or the destination RD (or both), otherwise th= e user
>>> experience is poor (information is lost).=A0 Note that this ne= eds to happen
>>> during a simple logoff/login as well. It seems to me that agen= t state in the
>>> AD should have ACID-ish characteristics, including the agent&#= 39;s current
>>> location.
>>>
>>> Given that we must be able to describe behavior of closing a c= lient-AD
>>> connection when the RD is unresponsive (e.g. the host has drop= ped off the
>>> network, etc), I'd be inclined to tackle unresponsive orig= ins in similar
>>> fashion for logout/login, region crossing, and teleport. (Whic= h in the
>>> current drafts are indeed tackled together.)
>>>
>>> So: I would agree that the current behavior of SL is less than= ideal - if
>>> the source region is unresponsive (for some TBD definition), a= teleport
>>> should probably not fail. But to preserve user data (and prese= rve the user
>>> experience), the initial transport attempt must involve a tran= saction
>>> between the AD, source RD and destination RD.
>>>
>>>
>>> _______________________________________________
>>> ogpx mailing list
>>> ogpx@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>
>>
>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>>
>

--0015175d0a3c0e63180475d868bf-- From carlo@alinoe.com Thu Oct 15 03:53:53 2009 Return-Path: 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 902563A689F; Thu, 15 Oct 2009 03:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.984 X-Spam-Level: X-Spam-Status: No, score=0.984 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 QlrNRm5nSsak; Thu, 15 Oct 2009 03:53:53 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id 3DC323A6876; Thu, 15 Oct 2009 03:53:52 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091015105350.BGKX10721.viefep18-int.chello.at@edge03.upc.biz>; Thu, 15 Oct 2009 12:53:50 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upc.biz with edge id syto1c03L0FlQed03ytpDo; Thu, 15 Oct 2009 12:53:50 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MyNyY-0007Ca-4k; Thu, 15 Oct 2009 12:54:30 +0200 Date: Thu, 15 Oct 2009 12:54:30 +0200 From: Carlo Wood To: Vaughn Deluca Message-ID: <20091015105430.GA26932@alinoe.com> References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> <20091008114435.GA22204@alinoe.com> <9b8a8de40910121244l94e4f4ai4805692e224f70f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b8a8de40910121244l94e4f4ai4805692e224f70f@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Magnus Zeisig , Infinity Linden , "ogpx-bounces@ietf.org" , Meadhbh Hamrick , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 10:53:53 -0000 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 From dwl@us.ibm.com Thu Oct 15 09:59:07 2009 Return-Path: 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> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> <20091008114435.GA22204@alinoe.com> <9b8a8de40910121244l94e4f4ai4805692e224f70f@mail.gmail.com> <20091015105430.GA26932@alinoe.com> To: Carlo Wood 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: From: David W Levine 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 , Infinity Linden , "ogpx-bounces@ietf.org" , Meadhbh Hamrick , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 16:59:07 -0000 This is a multipart message in MIME format. --=_alternative 005D496585257650_= Content-Type: text/plain; charset="US-ASCII" 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 10/15/2009 06:54 AM To Vaughn Deluca cc David W Levine/Watson/IBM@IBMUS, Infinity Linden , Meadhbh Hamrick , "ogpx@ietf.org" , "ogpx-bounces@ietf.org" , Magnus Zeisig 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 --=_alternative 005D496585257650_= Content-Type: text/html; charset="US-ASCII"
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>, Meadhbh Hamrick <meadhbh.siobhan@gmail.com>, "ogpx@ietf.org" <ogpx@ietf.org>, "ogpx-bounces@ietf.org" <ogpx-bounces@ietf.org>, 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>
--=_alternative 005D496585257650_=-- From morgaine.dinova@googlemail.com Thu Oct 15 23:36:02 2009 Return-Path: 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 203B03A6A16 for ; Thu, 15 Oct 2009 23:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 FbMAQON4Go3c for ; Thu, 15 Oct 2009 23:36:00 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 5152C3A6889 for ; Thu, 15 Oct 2009 23:36:00 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so419275eyd.51 for ; Thu, 15 Oct 2009 23:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=+fHYgcv40LThqHHzHztZfhLhzT9e7Nd2e0w/1+9uYcI=; b=M2v5SOBIWrMut7tvkDCuhYhQ24K9I2fGcD7INeidmPkTN1DXUDTC7sS3j6Opj9sBdg NcEk3qBs5W9KmnZ48Ve+M0j6FSJovJDyoTrlE1jA9tKdV4oWF/qPVaosR7YkXSwwRBaJ WAtuhsCbxZBYev45l3yJuWl0suZr4nmCK641Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=bpLr1Gf2iI6PMT5kyERk6iUWCOE3k5eL1c9S4tkObaW5+MKZ0zsU55aZHDq68Ik7+m MpycLotMRExRSQ/a/Jv7P0lxqWns3TRwea4mxGc9r0+4u2UqWeBZDS0fkxoXwsn+M5vw 8LRNnC3uBPDz0sTQ+8vr9EasbcWM2ZrEF/jb0= MIME-Version: 1.0 Received: by 10.211.161.16 with SMTP id n16mr1079001ebo.20.1255674959627; Thu, 15 Oct 2009 23:35:59 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> <20091008114435.GA22204@alinoe.com> <9b8a8de40910121244l94e4f4ai4805692e224f70f@mail.gmail.com> <20091015105430.GA26932@alinoe.com> Date: Fri, 16 Oct 2009 07:35:59 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636c5bf0cec07fe0476079bdc 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 06:36:02 -0000 --001636c5bf0cec07fe0476079bdc Content-Type: text/plain; charset=ISO-8859-1 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 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 * > > 10/15/2009 06:54 AM > To > Vaughn Deluca > cc > David W Levine/Watson/IBM@IBMUS, Infinity Linden , > Meadhbh Hamrick , "ogpx@ietf.org" < > ogpx@ietf.org>, "ogpx-bounces@ietf.org" , Magnus > Zeisig > 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 > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --001636c5bf0cec07fe0476079bdc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are two cases here:

  1. When the source R1 and destination= R2 regions belong to the same administering authority, then it is a reason= able optimization for serialized agent data to be transferred directly from= R1 to R2.
  2. In contrast, when they belong to different administrations then there i= s a privacy concern (as various people have mentioned), since it is no busi= ness 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 lo= cal optimization, we're fine, since both privacy and efficie= ncy can be satisfied in the distinct cases where each one is appropriate.= =A0 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).<= br>

Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

On Thu, Oct 15, 2009 at 5:58 PM, David W Lev= ine <dwl@us.ibm.com<= /a>> wrote:

Region 1 (the source) holds the cu= rrent 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. =A0Now.. 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 Delu= ca <vaughn.= deluca@gmail.com>
cc
David W Levine/Watson/IBM@IBM= US, Infinity Linden <infi= nity@lindenlab.com>, Meadhbh Hamrick <meadhbh.siobhan@gmail.com>, "ogpx@ietf.org&= quot; <ogpx@ietf.org<= /a>>, "o= gpx-bounces@ietf.org" <ogpx-bounces= @ietf.org>, Magnus Zeisig <magnus.zeisig@iis.se>
Subject
Re: [ogpx] Protocol for permi= tting policy decisions





On Mon, Oct 12, 2009 at 09:44:56PM +0200, Vaughn D= eluca 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)---> =A0viewer > The viewer can now contact the region.

--
Carlo Wood <carlo@= alinoe.com>

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--001636c5bf0cec07fe0476079bdc-- From vaughn.deluca@gmail.com Fri Oct 16 00:07:04 2009 Return-Path: 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 2ECCB3A6A19 for ; Fri, 16 Oct 2009 00:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 ace9VubN3Ipn for ; Fri, 16 Oct 2009 00:07:03 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 5FECA3A68A2 for ; Fri, 16 Oct 2009 00:07:02 -0700 (PDT) Received: by fxm18 with SMTP id 18so2043232fxm.37 for ; Fri, 16 Oct 2009 00:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tXuX9vDYdSdnt4TSQ5eQiDOjcQ0YeAfhFEPwWEFjf+8=; b=HhIZlBfqplpy8AnzIb31O5cVbHWcXdYNuUUoJvdyN8NOwX8QIcFUvwSmDvAy4uAJEc 4o+QVdoO3YBYdTXR+/SypUKwimTsjPKy9KqR3z9/K1O2qn3datDjXRbH6i0+VXGXZICi tBtV8wgvX+t1QTxJQbDOiuKvMHcVcnPl49Ohs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fkHS3OA1gIvJAkXNpabEpoI7G+bYg8O/de2i9CDN+wjJrELbK91wW/Wvh7j2VxHW0X YOq4JR6qSXGLdtPrQSYnA64knBxQ+QvY82+UPM0O6oTBolkqYeMG3Pjd7MPHBKufodAK Mg5t3ep18BeBgo5m5ykBS6d2sFQxdPjcME6bE= MIME-Version: 1.0 Received: by 10.204.153.217 with SMTP id l25mr903020bkw.108.1255676824015; Fri, 16 Oct 2009 00:07:04 -0700 (PDT) In-Reply-To: References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se> <20091007204917.GB13882@alinoe.com> <20091008114435.GA22204@alinoe.com> <9b8a8de40910121244l94e4f4ai4805692e224f70f@mail.gmail.com> <20091015105430.GA26932@alinoe.com> Date: Fri, 16 Oct 2009 09:07:03 +0200 Message-ID: <9b8a8de40910160007xd8c15b1o5c34cabb4e097fe@mail.gmail.com> From: Vaughn Deluca To: Morgaine Content-Type: multipart/alternative; boundary=0015175d094e0c533c0476080be6 Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 07:07:04 -0000 --0015175d094e0c533c0476080be6 Content-Type: text/plain; charset=ISO-8859-1 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 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 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 * >> >> 10/15/2009 06:54 AM >> To >> Vaughn Deluca >> cc >> David W Levine/Watson/IBM@IBMUS, Infinity Linden , >> Meadhbh Hamrick , "ogpx@ietf.org" < >> ogpx@ietf.org>, "ogpx-bounces@ietf.org" , Magnus >> Zeisig >> 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 >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0015175d094e0c533c0476080be6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I =A0agree with this conceptual split, yet i would like to stick to the mor= e precise terminology I outlined above.
R1 and R2 are *by definition* i= n different domains.=A0
The case you mention in 1. is a =A0R1.1 -= > R1.2 transfer. =A0

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 pr= otocol *allows* a region transfer via the AD rather than requiring the dire= ct 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 <morgaine.dinova@googlemail.com> wrote:
There are two cases here:

  1. Wh= en the source R1 and destination R2 regions belong to the same administerin= g 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 i= s a privacy concern (as various people have mentioned), since it is no busi= ness 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 lo= cal optimization, we're fine, since both privacy and efficie= ncy can be satisfied in the distinct cases where each one is appropriate.= =A0 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).<= br>

Morgaine.





=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= /div>

Region 1 (the source) holds the cu= rrent 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. =A0Now.. 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 &= lt;carlo@alinoe.com>

10/15/2009 06:54 AM

To
Vaughn Deluca <vaughn.deluca@gmail.= com>
cc
David W Levine/Watson/IBM@IBM= US, Infinity Linden <infi= nity@lindenlab.com>, Meadhbh Hamrick <meadhbh.siobhan@gmail.com>, "ogpx@ietf.org&= quot; <ogpx@ietf.org<= /a>>, "o= gpx-bounces@ietf.org" <ogpx-bounces= @ietf.org>, Magnus Zeisig <magnus.zeisig@iis.se>
Subject
Re: [ogpx] Protocol for permi= tting policy decisions





On Mon, Oct 12, 2009 at 09:44:56PM +0200, Vaughn D= eluca 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)---> =A0viewer > The viewer can now contact the region.

--
Carlo Wood <carlo@= alinoe.com>

_________________________= ______________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx



_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--0015175d094e0c533c0476080be6-- From vaughn.deluca@gmail.com Fri Oct 16 00:34:01 2009 Return-Path: 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 8DCB63A6989 for ; Fri, 16 Oct 2009 00:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 4CtZDCL6e9q2 for ; Fri, 16 Oct 2009 00:34:00 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 1F5C13A67DA for ; Fri, 16 Oct 2009 00:33:59 -0700 (PDT) Received: by fxm18 with SMTP id 18so2063139fxm.37 for ; Fri, 16 Oct 2009 00:34:03 -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=F1fskYQANFMdDLocHZXT2BwDR7cY4lMP7YrAc/EkU4Q=; b=fviJPMSE4E/riA5KbfFnU3Eeig3ObuxndgLS+1vTrTXDB1Cwrz+czksNNI+SDHpaB0 m4JB+mklPqOhTX08usyAVMSui9tQPogYfP3Wtf7Tu3Z/RuG5OUiN1jPZ7UHPCH+7eJub lcqrDDXuLpzEflFfnN10YQ0RTd9w2WJ+nAwLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=PHDDy7XIo3Xv10JLgXtyoWAG1MhL/WAK6aCnfqQuirXuJOXHDaQqrvrIphvdiFBQgn orq3/mf6vvzKyxbsXEO5Hj3L0HotBYGpG1ZEea5PZyGvD27ScjVWiaUYHSBmQFf/SZ/G 9lyTliel2ZjYZ8ONJK/msf2w7xAHWtVHuqkjk= MIME-Version: 1.0 Received: by 10.204.16.88 with SMTP id n24mr976403bka.52.1255678442705; Fri, 16 Oct 2009 00:34:02 -0700 (PDT) Date: Fri, 16 Oct 2009 09:34:02 +0200 Message-ID: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> From: Vaughn Deluca To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0003255597fe8793630476086b6b Subject: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 07:34:01 -0000 --0003255597fe8793630476086b6b Content-Type: text/plain; charset=ISO-8859-1 The "tourist use case" has been brought up several times, but the concept is not always used in the same way, and needs to be more precisely defined. Morgaines original definition of the "Free Worlds Tourist use case" in http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html mentions two characteristics: 1. Travel requires no prior arrangement. 2. Your avatar is defined by you, not by the target worlds, and it appears in those worlds with no prior arrangement. Point 1 is only dependent the policies of the users AD as well as that of the destination region. It is not dependent on the protocol, so in principle solved. The second point is actually extending the SL use case beyond what is in my view needed for a basic tourist model (and that is why the post was in the mmox list). In my view a basic tourist use case has two main characteristics: 1. Travel requires no prior arrangement. 2. Agent domains can use external asset services Point 2 requires that assets services expose an interface (in the current ogp description of the AD that is not the case). Note that this models does *not* assumes that all assets in a services should be useable by the agent in all domains, but only that an interface is available so an asset service in one domain can be contacted by another AD. I think exposing the asset service interface directly is essential for meaningful interop. I think it would benefit the discussion if some diagrams were added to http://wiki.secondlife.com/wiki/Structural_Designand/or to the VWRAP wiki to document this possibility. -Vaughn --0003255597fe8793630476086b6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The "tourist use case" has been brought up several times, bu= t the concept is not always used in the same way, and needs to be more prec= isely defined.

Morgaines original definition of th= e "Free Worlds Tourist use case"=A0in http://www.ietf.org/mail-a= rchive/web/mmox/current/msg01392.html
mentions two characteristics:

1. Travel requires no prior arrangem= ent.
2. Your avatar i= s defined by you, not by the target worlds, and it appears in those worlds = with no prior arrangement.=A0

Point 1 is only dependent the policies of the users AD = as well as that of the destination region. It is not dependent on the proto= col, so in principle solved.

The second point is a= ctually extending the SL use case beyond what is in my view needed for a ba= sic tourist model (and that is why the post was in the mmox list). =A0In my= view =A0a basic tourist use case has two main characteristics:

1. =A0Travel requires no prior arrangement.
=A0=A0 =A0 = =A0 =A02. =A0Agent domains can use external asset services

Point 2 requires that assets services expose an interface (in the = current ogp description of the AD that is not the case).=A0

Note that this models does *not* assumes that all asset= s in a services should be useable by the agent in all domains, but only tha= t an interface is available so an asset service in one domain can be contac= ted by another AD.=A0

I think exposing the asset service interface directly i= s essential for meaningful interop. =A0I think it would benefit the discuss= ion if some diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design= and/or to the VWRAP wiki to document this possibility.

-Vaughn
--0003255597fe8793630476086b6b-- From infinity@lindenlab.com Fri Oct 16 01:16:54 2009 Return-Path: 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 A36B13A6993 for ; Fri, 16 Oct 2009 01:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 d1u-T77Cz1ar for ; Fri, 16 Oct 2009 01:16:53 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 868F03A698E for ; Fri, 16 Oct 2009 01:16:53 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so142323fge.13 for ; Fri, 16 Oct 2009 01:16:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.139.161 with SMTP id t33mr99398hbt.115.1255681014171; Fri, 16 Oct 2009 01:16:54 -0700 (PDT) In-Reply-To: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> From: "Infinity Linden (Meadhbh Hamrick)" Date: Fri, 16 Oct 2009 01:16:34 -0700 Message-ID: <3a880e2c0910160116g2f4f394ag763822dbd35c80e1@mail.gmail.com> To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 08:16:54 -0000 i had assumed that the "tourist model" also implied that the client assumes no transitive trust on behalf of the agent domain, or includes the agent domain as part of a client implementation. also. we should tighten up the language. i would argue that from the client's perspective, teleporting between Sim 1 and Sim 2 requires no prior arrangement (for the client.) it does, however, require the agent domain to trust both sims. maybe we could define the various models in terms of who trusts whom and how service endpoint addresses are resolved? so the "second life" model [1] would essentially be that the client and the agent domain trust each other, and the agent domain and all of the region domains trust each other. service endpoints for agent services are given to the client by the agent domain, while region service are given to the client by the agent domain or the region domain. in the "tourist model" you would have no trust, and the client is responsible for resolving the address of all services. in the "cable beach" model, you have the same trust as the "second life" model, but you bring the asset service into it's own domain which is explicitly trusted by the agent domain, the region domains and the client. asset service endpoints are resolved by the client. -cheers -meadhbh -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden On Fri, Oct 16, 2009 at 00:34, Vaughn Deluca wrot= e: > The "tourist use case" has been brought up several times, but the concept= is > not always used in the same way, and needs to be more precisely defined. > Morgaines original definition of the "Free Worlds Tourist use case"=A0in > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html > mentions two characteristics: > 1. Travel requires no prior arrangement. > 2. Your avatar is defined by you, not by the target worlds, and it appear= s > in those worlds with no prior arrangement. > Point 1 is only dependent the policies of the users AD as well as that of > the destination region. It is not dependent on the protocol, so in princi= ple > solved. > The second point is actually extending the SL use case beyond what is in = my > view needed for a basic tourist model (and that is why the post was in th= e > mmox list). =A0In my view =A0a basic tourist use case has two main > characteristics: > 1. =A0Travel requires no prior arrangement. > =A0=A0 =A0 =A0 =A02. =A0Agent domains can use external asset services > Point 2 requires that assets services expose an interface (in the current > ogp description of the AD that is not the case). > Note that this models does *not* assumes that all assets in a services > should be useable by the agent in all domains, but only that an interface= is > available so an asset service in one domain can be contacted by another A= D. > I think exposing the asset service interface directly is essential for > meaningful interop. =A0I think it would benefit the discussion if some > diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design > and/or to the VWRAP wiki to document this possibility. > -Vaughn > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From infinity@lindenlab.com Fri Oct 16 01:17:16 2009 Return-Path: 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 4E63A3A6993 for ; Fri, 16 Oct 2009 01:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 dJHZ1DG+NMsq for ; Fri, 16 Oct 2009 01:17:15 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 423633A68B3 for ; Fri, 16 Oct 2009 01:17:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so142323fge.13 for ; Fri, 16 Oct 2009 01:17:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.183.37 with SMTP id s37mr90499hbg.90.1255681039129; Fri, 16 Oct 2009 01:17:19 -0700 (PDT) In-Reply-To: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> From: "Infinity Linden (Meadhbh Hamrick)" Date: Fri, 16 Oct 2009 01:16:59 -0700 Message-ID: <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 08:17:16 -0000 also. just a show of hands. who's planning on implementing the tourist mode= l? -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden On Fri, Oct 16, 2009 at 00:34, Vaughn Deluca wrot= e: > The "tourist use case" has been brought up several times, but the concept= is > not always used in the same way, and needs to be more precisely defined. > Morgaines original definition of the "Free Worlds Tourist use case"=A0in > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html > mentions two characteristics: > 1. Travel requires no prior arrangement. > 2. Your avatar is defined by you, not by the target worlds, and it appear= s > in those worlds with no prior arrangement. > Point 1 is only dependent the policies of the users AD as well as that of > the destination region. It is not dependent on the protocol, so in princi= ple > solved. > The second point is actually extending the SL use case beyond what is in = my > view needed for a basic tourist model (and that is why the post was in th= e > mmox list). =A0In my view =A0a basic tourist use case has two main > characteristics: > 1. =A0Travel requires no prior arrangement. > =A0=A0 =A0 =A0 =A02. =A0Agent domains can use external asset services > Point 2 requires that assets services expose an interface (in the current > ogp description of the AD that is not the case). > Note that this models does *not* assumes that all assets in a services > should be useable by the agent in all domains, but only that an interface= is > available so an asset service in one domain can be contacted by another A= D. > I think exposing the asset service interface directly is essential for > meaningful interop. =A0I think it would benefit the discussion if some > diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design > and/or to the VWRAP wiki to document this possibility. > -Vaughn > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From morgaine.dinova@googlemail.com Fri Oct 16 01:51:40 2009 Return-Path: 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 B6CE13A67D8 for ; Fri, 16 Oct 2009 01:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=1.365, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 reQpvmaXhpw4 for ; Fri, 16 Oct 2009 01:51:39 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 17F8D3A67D2 for ; Fri, 16 Oct 2009 01:51:38 -0700 (PDT) Received: by ewy4 with SMTP id 4so1364985ewy.37 for ; Fri, 16 Oct 2009 01:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=sSr81BXYgWnvNLDc2R1hXVL+8lOsReLOCXEMwwmEbOc=; b=uu5NFnUUXgNfYenWM5QfBq790jg8Id7QxSokRZpUsPZMND0rzbWfxCjqArqr+88C4K 4OpmXMkGblsyWZaj8ZGGeoeSDVhXW8GbhA16zHxhSh6o35UJUVYaCAVcUg+JheRFSDRT j4Th7V6IY2JqJHcGRLvjEb2t6WQ/zCdBmwjCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=enEtHcbiOk6GnpWhhTS4Bviti0fHZuQ3bKEbCLZjfVRgAUcaoGYpxGoWEbVH9wi6a7 8FAcMZleWhMbZSDHqSK+ipIGj6ZxmmplJRzdgYDxUJUJAzGXIu+KqCdrOc/xUF/fkiJS 3HwgJF28Zs6lJ+69OpUaeApPKYLGZcqdxedP8= MIME-Version: 1.0 Received: by 10.211.147.8 with SMTP id z8mr571886ebn.87.1255683099938; Fri, 16 Oct 2009 01:51:39 -0700 (PDT) In-Reply-To: <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> Date: Fri, 16 Oct 2009 09:51:39 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636c5b8631f524704760981da Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 08:51:40 -0000 --001636c5b8631f524704760981da Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick) < infinity@lindenlab.com> wrote: also. just a show of hands. who's planning on implementing the tourist > model? Almost everybody who will operate virtual worlds, I assume --- that could be hundreds of thousands of world operators, if not millions, mostly small. We certainly can't foretell! And we can't get them to raise a show of hands either. :-) I doubt that it will be common to operate walled gardens once everyone else is allowing their users to travel freely among the huge diversity of the metaverse. It certainly seems like a recipe for failure to deny tourism to one's residents as a matter of policy, given that tourism is so popular in the physical world today. However, this is a policy issue of course, and therefore not something that VWRAP will dictate. We merely provide the mechanisms to allow tourism when desired, not mandate or deny it to any given world operator. Morgaine. ================================== On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick) < infinity@lindenlab.com> wrote: > also. just a show of hands. who's planning on implementing the tourist > model? > > -- > infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" > http://wiki.secondlife.com/wiki/User:Infinity_Linden > > > > On Fri, Oct 16, 2009 at 00:34, Vaughn Deluca > wrote: > > The "tourist use case" has been brought up several times, but the concept > is > > not always used in the same way, and needs to be more precisely defined. > > Morgaines original definition of the "Free Worlds Tourist use case" in > > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html > > mentions two characteristics: > > 1. Travel requires no prior arrangement. > > 2. Your avatar is defined by you, not by the target worlds, and it > appears > > in those worlds with no prior arrangement. > > Point 1 is only dependent the policies of the users AD as well as that of > > the destination region. It is not dependent on the protocol, so in > principle > > solved. > > The second point is actually extending the SL use case beyond what is in > my > > view needed for a basic tourist model (and that is why the post was in > the > > mmox list). In my view a basic tourist use case has two main > > characteristics: > > 1. Travel requires no prior arrangement. > > 2. Agent domains can use external asset services > > Point 2 requires that assets services expose an interface (in the current > > ogp description of the AD that is not the case). > > Note that this models does *not* assumes that all assets in a services > > should be useable by the agent in all domains, but only that an interface > is > > available so an asset service in one domain can be contacted by another > AD. > > I think exposing the asset service interface directly is essential for > > meaningful interop. I think it would benefit the discussion if some > > diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design > > and/or to the VWRAP wiki to document this possibility. > > -Vaughn > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --001636c5b8631f524704760981da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick) <infinity@lindenlab.= com> wrote:

also. just a show of hands. who's planning on implementing the tourist = model?


Almost everybody who will operate virtual worlds= , I assume --- that could be hundreds of thousands of world operators, if n= ot millions, mostly small.=A0 We certainly can't foretell!=A0 And we ca= n't get them to raise a show of hands either. :-)

I doubt that it will be common to operate walled gardens once everyone = else is allowing their users to travel freely among the huge diversity of t= he metaverse.=A0 It certainly seems like a recipe for failure to deny touri= sm to one's residents as a matter of policy, given that tourism is so p= opular in the physical world today.

However, this is a policy issue of course, and therefore not something = that VWRAP will dictate.=A0 We merely provide the mechanisms to allow touri= sm when desired, not mandate or deny it to any given world operator.

Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadh= bh Hamrick) <infinity@lindenlab.com> wrote:
also. just a show= of hands. who's planning on implementing the tourist model?

--
=A0 infinity linden (aka meadhbh hamrick) =A0* =A0it's pronounced &quo= t;maeve"
=A0 =A0 =A0 =A0 http://wiki.secondlife.com/wiki/User:Infinity_Lind= en



On Fri, Oct 16, 2009 at 00:34, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
> The "tourist use case&quo= t; has been brought up several times, but the concept is
> not always used in the same way, and needs to be more precisely define= d.
> Morgaines original definition of the "Free Worlds Tourist use cas= e"=A0in
> http://www.ietf.org/mail-archive/web/mmox/current/m= sg01392.html
> mentions two characteristics:
> 1. Travel requires no prior arrangement.
> 2. Your avatar is defined by you, not by the target worlds, and it app= ears
> in those worlds with no prior arrangement.
> Point 1 is only dependent the policies of the users AD as well as that= of
> the destination region. It is not dependent on the protocol, so in pri= nciple
> solved.
> The second point is actually extending the SL use case beyond what is = in my
> view needed for a basic tourist model (and that is why the post was in= the
> mmox list). =A0In my view =A0a basic tourist use case has two main
> characteristics:
> 1. =A0Travel requires no prior arrangement.
> =A0=A0 =A0 =A0 =A02. =A0Agent domains can use external asset services<= br> > Point 2 requires that assets services expose an interface (in the curr= ent
> ogp description of the AD that is not the case).
> Note that this models does *not* assumes that all assets in a services=
> should be useable by the agent in all domains, but only that an interf= ace is
> available so an asset service in one domain can be contacted by anothe= r AD.
> I think exposing the asset service interface directly is essential for=
> meaningful interop. =A0I think it would benefit the discussion if some=
> diagrams were added to http://wiki.secondlife.com/wiki/Structural= _Design
> and/or to the VWRAP wiki to document this possibility.
> -Vaughn
> ________________________= _______________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--001636c5b8631f524704760981da-- From vaughn.deluca@gmail.com Fri Oct 16 03:16:53 2009 Return-Path: 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 363723A6859 for ; Fri, 16 Oct 2009 03:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 CboMuSK460zh for ; Fri, 16 Oct 2009 03:16:51 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 2DF693A69CC for ; Fri, 16 Oct 2009 03:16:51 -0700 (PDT) Received: by fxm18 with SMTP id 18so2209902fxm.37 for ; Fri, 16 Oct 2009 03:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9629xpNAoM52XRITkcHZ0ZrRTpcDsPcNWJ6J5J+/IxM=; b=LnJ8CX/JkY6T+W1ln1JNghnJ0GJf24Q5hSR0VSYhh4gTaMJSEUdGCmBTAyd7JcUUOp frmMkPuQpuToVwdXsnx6dQFOBOvGoxh52UZ04mjmeyHcjbvWj9rqqVgzQTjf/xejH27h CR6aeqcopMiZm44SL3uqTXezSlgbxGSofeu/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=B67YD5E2htLQSvMVBBAt92bNRhWlUiJg2NysCwXpLXAiR28+2hc6+dFVBvRdRb6NWh IHW7yhidzFpXx8vsM9CsDoZo0F7klDl5ZOHOudL/RAyYZWQ75K577MEW/opE3tuTmcql zGCygEyCeQGU4WwwXEW5AgQoPmnYRSqXjc0wQ= MIME-Version: 1.0 Received: by 10.204.155.79 with SMTP id r15mr1115652bkw.142.1255688211645; Fri, 16 Oct 2009 03:16:51 -0700 (PDT) In-Reply-To: <3a880e2c0910160116g2f4f394ag763822dbd35c80e1@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g2f4f394ag763822dbd35c80e1@mail.gmail.com> Date: Fri, 16 Oct 2009 12:16:51 +0200 Message-ID: <9b8a8de40910160316w364a2695t8e8dd8992e0b524f@mail.gmail.com> From: Vaughn Deluca To: "Infinity Linden (Meadhbh Hamrick)" Content-Type: multipart/alternative; boundary=0015175d07d2cdc62404760ab1e7 Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 10:16:53 -0000 --0015175d07d2cdc62404760ab1e7 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 16, 2009 at 10:16 AM, Infinity Linden (Meadhbh Hamrick) < infinity@lindenlab.com> wrote: > i had assumed that the "tourist model" also implied that the client > assumes no transitive trust on behalf of the agent domain, or includes > the agent domain as part of a client implementation. > Not in the most basic case, Morgaine indeed defined it that way, but i feel that that is a more complicated use case, and we would benefit from treating it separately from the more basic case. > also. we should tighten up the language. i would argue that from the > client's perspective, teleporting between Sim 1 and Sim 2 requires no > prior arrangement (for the client.) it does, however, require the > agent domain to trust both sims. > Yes, but note that the asset service will have its own policy in this model, so the needed reasons to distrust the destination region are limited. One obvious reason would be that promises were made to the user to protect the avatar from exposure to adult material. But if the user indicates is has no problem, i would think in the majority of cases the Agent service can trust the region. In the worst case the avatar would have to be ruthed because the avatar shape can not be exported. > maybe we could define the various models in terms of who trusts whom > and how service endpoint addresses are resolved? > Yes, i like that suggestion. > so the "second life" model [1] would essentially be that the client > and the agent domain trust each other, and the agent domain and all of > the region domains trust each other. service endpoints for agent > services are given to the client by the agent domain, while region > service are given to the client by the agent domain or the region > domain. > Yes, although you specify a bit more trust that is needed in my view because you do not allow assets services there own policy, distinct from the agent service policy, but if you want to make a blanket statement this is correct. > > in the "tourist model" you would have no trust, and the client is > responsible for resolving the address of all services. No, you loose me here. The client *does* trust the agent service, there is no difference here with the SL case. The client logs in to an AD, and by definition trusts that service. that AD has its own asset service, just like in the SL case, and the user can use those assets (as far as the Asset service allows the assets to go out to other domains). In addition to using its own asset services the Agent service can use other Asset services. > in the "cable beach" model, you have the same trust as the "second > life" model, but you bring the asset service into it's own domain > which is explicitly trusted by the agent domain, the region domains > and the client. asset service endpoints are resolved by the client. > I did not yet look in detail at cable beach, but I clearly should, since this sounds a lot like what i was thinking of. However, I do not think its needed to put the asset service in its own domain, because by definition a domain is under a different administration, and in many cases the asset service will be in some domain. So the critical point is that the asset service in some domain exposes an interface to the world so its assets *can* be used, if by anybody if policy allows it. -Vaughn > -cheers > -meadhbh > > -- > infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" > http://wiki.secondlife.com/wiki/User:Infinity_Linden > > > > On Fri, Oct 16, 2009 at 00:34, Vaughn Deluca > wrote: > > The "tourist use case" has been brought up several times, but the concept > is > > not always used in the same way, and needs to be more precisely defined. > > Morgaines original definition of the "Free Worlds Tourist use case" in > > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html > > mentions two characteristics: > > 1. Travel requires no prior arrangement. > > 2. Your avatar is defined by you, not by the target worlds, and it > appears > > in those worlds with no prior arrangement. > > Point 1 is only dependent the policies of the users AD as well as that of > > the destination region. It is not dependent on the protocol, so in > principle > > solved. > > The second point is actually extending the SL use case beyond what is in > my > > view needed for a basic tourist model (and that is why the post was in > the > > mmox list). In my view a basic tourist use case has two main > > characteristics: > > 1. Travel requires no prior arrangement. > > 2. Agent domains can use external asset services > > Point 2 requires that assets services expose an interface (in the current > > ogp description of the AD that is not the case). > > Note that this models does *not* assumes that all assets in a services > > should be useable by the agent in all domains, but only that an interface > is > > available so an asset service in one domain can be contacted by another > AD. > > I think exposing the asset service interface directly is essential for > > meaningful interop. I think it would benefit the discussion if some > > diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design > > and/or to the VWRAP wiki to document this possibility. > > -Vaughn > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --0015175d07d2cdc62404760ab1e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 16, 2009 at 10:16 AM, Infini= ty Linden (Meadhbh Hamrick) <infinity@lindenlab.com> wrote:
i had assumed that the "tourist model" also implied that the clie= nt
assumes no transitive trust on behalf of the agent domain, or includes
the agent domain as part of a client implementation.
<= br>
Not in the most basic case, Morgaine indeed defined it that w= ay, but i feel that that is a more complicated use case, and we would benef= it from treating =A0it separately from the more basic case.
=A0
also. we should tighten up the language. i would argue that from the
client's perspective, teleporting between Sim 1 and Sim 2 requires no prior arrangement (for the client.) it does, however, require the
agent domain to trust both sims.

Yes, b= ut note that the asset service will have its own policy in this model, so t= he needed reasons to distrust the destination region are limited. One obvio= us reason would be that promises were made to the user to protect the avata= r from exposure to adult material.
But if the user indicates is has no problem, i would think in the majo= rity of cases the Agent service can trust the region. In the worst case the= avatar would have to be ruthed because the avatar shape can not be exporte= d.
=A0
maybe we could define the various models in terms of who trusts whom
and how service endpoint addresses are resolved?

<= /div>
Yes, i like that suggestion.=A0
=A0
so the "second life" model [1] would essentially be that the clie= nt
and the agent domain trust each other, and the agent domain and all of
the region domains trust each other. service endpoints for agent
services are given to the client by the agent domain, while region
service are given to the client by the agent domain or the region
domain.

Yes, although you specify a bit= more trust that is needed in my view because you do not =A0 =A0allow asset= s services there own policy, distinct from the agent service policy, but if= you want to make a blanket statement this is correct.=A0

in the "tourist model" you would have no trust, and the client is=
responsible for resolving the address of all services.
No, you loose me here. The client *does* =A0trust the agent ser= vice, there is no difference here with the SL case. The client logs in to a= n AD, and by definition trusts that service.
that AD has its own asset service, =A0just like in the SL case, and th= e user can use those assets (as far as the Asset service allows the assets = to go out to other domains).
In addition to using its own asset s= ervices the Agent service can use other Asset services.
=A0=A0
in the "cable beach&q= uot; model, you have the same trust as the "second
life" model, but you bring the asset service into it's own domain<= br> which is explicitly trusted by the agent domain, the region domains
and the client. asset service endpoints are resolved by the client.

I did not yet look in detail at cable beach, b= ut I clearly =A0should, since this sounds a lot like what i was thinking of= . =A0However, =A0I do not think its needed to put the asset service in its = own domain, because by definition a domain is under a different administrat= ion, and in many cases the asset service will be in some domain. So the cri= tical point is that the asset service in some domain exposes an interface t= o the world so its assets *can* be used, if by anybody if policy allows it.=

-Vaughn


-cheers
-meadhbh

--
=A0 infinity linden (aka meadhbh hamrick) =A0* =A0it's pronounced &quo= t;maeve"
=A0 =A0 =A0 =A0 http://wiki.secondlife.com/wiki/User:Infinity_Lind= en



On Fri, Oct 16, 2009 at 00:34, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
> The "tourist use case" has been brought up several times, bu= t the concept is
> not always used in the same way, and needs to be more precisely define= d.
> Morgaines original definition of the "Free Worlds Tourist use cas= e"=A0in
> http://www.ietf.org/mail-archive/web/mmox/current/m= sg01392.html
> mentions two characteristics:
> 1. Travel requires no prior arrangement.
> 2. Your avatar is defined by you, not by the target worlds, and it app= ears
> in those worlds with no prior arrangement.
> Point 1 is only dependent the policies of the users AD as well as that= of
> the destination region. It is not dependent on the protocol, so in pri= nciple
> solved.
> The second point is actually extending the SL use case beyond what is = in my
> view needed for a basic tourist model (and that is why the post was in= the
> mmox list). =A0In my view =A0a basic tourist use case has two main
> characteristics:
> 1. =A0Travel requires no prior arrangement.
> =A0=A0 =A0 =A0 =A02. =A0Agent domains can use external asset services<= br> > Point 2 requires that assets services expose an interface (in the curr= ent
> ogp description of the AD that is not the case).
> Note that this models does *not* assumes that all assets in a services=
> should be useable by the agent in all domains, but only that an interf= ace is
> available so an asset service in one domain can be contacted by anothe= r AD.
> I think exposing the asset service interface directly is essential for=
> meaningful interop. =A0I think it would benefit the discussion if some=
> diagrams were added to http://wiki.secondlife.com/wiki/Structural= _Design
> and/or to the VWRAP wiki to document this possibility.
> -Vaughn
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

--0015175d07d2cdc62404760ab1e7-- From morgaine.dinova@googlemail.com Fri Oct 16 05:00:12 2009 Return-Path: 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 7661628C20B for ; Fri, 16 Oct 2009 05:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 6yDqVcm5RODB for ; Fri, 16 Oct 2009 05:00:11 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id B016428B23E for ; Fri, 16 Oct 2009 05:00:10 -0700 (PDT) Received: by ewy4 with SMTP id 4so1494125ewy.37 for ; Fri, 16 Oct 2009 05:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hYYHtph4FuF9H5+JqLn5rPyWjSjB8qhCzG9aMoiJOiA=; b=h/mM6RoS1vkxq/sjPeMM/JbGcwOv+X1FsO3z3F+J2JKOhNWOS13dFSyhK5qg/EAiMF WZHh8qa2jBxrTiIb9a4mVq2rqDu5IHfoUpsz5Fzwst2NPJqYzr1QmH19wmBAlvVNgBD1 aqKgJut1XBB+fRO6kc2I094hVtOwQUaZLShxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CBK/NW4w9TCZzRn5c2DLCUSjNQB3YMYaWbBp2vdG5Z/GyNlQLkmKf8HDCA1QmNy/8N htM7l1i1yfOMqqXRRnF5ekvRinoUcrbGH3Z79C3Belak8nAjLycor1LtVt2OMoWQZ//j EZgyevv7PNZDPBDl3g4eGw04X/ESUJdzO7KLE= MIME-Version: 1.0 Received: by 10.211.155.16 with SMTP id h16mr1456464ebo.55.1255694412117; Fri, 16 Oct 2009 05:00:12 -0700 (PDT) In-Reply-To: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> Date: Fri, 16 Oct 2009 13:00:12 +0100 Message-ID: From: Morgaine To: Vaughn Deluca Content-Type: multipart/alternative; boundary=00504502c9e06177de04760c233e Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 12:00:12 -0000 --00504502c9e06177de04760c233e Content-Type: text/plain; charset=ISO-8859-1 Vaughn, You've correctly represented my MMOX post, thanks! ( http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html ) I must stress, as you did yourself, that the "*Free Worlds Tourist*" use case which I described there in MMOX is *different * to the simpler "tourist use case" which we have been discussing here. It's great that you're shining some light into this corner. Hopefully this will allow us to affix labels to the various cases to keep our discussions simple yet clear. Before addressing your actual point, I should first state that I consider it unfortunate that the "*Free Worlds Tourist*" use case is not considered an integral part of VWRAP requirements --- this is a practical conclusion on my part. On the basis of our discussions so far, I think it would be too much to expect that a mode of operation offering such a high degree of freedom of travel and of avatar appearance would achieve rough consensus in the group, given that its considerable distance from Second Life policies would almost certainly lead to intense opposition. This is not a battle I wish to fight. As a practical matter then, "*Free Worlds Tourist*" as defined above is not a use case that I am pushing in VWRAP at this time, despite it being entirely compatible with the SL/Opensim model and hence deserving inclusion. I'm simply going to express regret that it is likely to be a bridge too far on political grounds and leave it at that. I would wish it were otherwise. With that disclaimer, I'll answer your point about our more constrained "tourist use case" (which perhaps needs a better name), this being a much easier target but still a very useful one. I will however answer it in the immediately following post, because I don't want to get this confused with the "*Free Worlds Tourist*" case that I described in MMOX. Morgaine. ===================================== On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca wrote: > The "tourist use case" has been brought up several times, but the concept > is not always used in the same way, and needs to be more precisely defined. > > Morgaines original definition of the "Free Worlds Tourist use case" in > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html > mentions two characteristics: > > 1. Travel requires no prior arrangement. > 2. Your avatar is defined by you, not by the target worlds, and it > appears in those worlds with no prior arrangement. > > Point 1 is only dependent the policies of the users AD as well as that of > the destination region. It is not dependent on the protocol, so in principle > solved. > > The second point is actually extending the SL use case beyond what is in my > view needed for a basic tourist model (and that is why the post was in the > mmox list). In my view a basic tourist use case has two main > characteristics: > > 1. Travel requires no prior arrangement. > 2. Agent domains can use external asset services > > Point 2 requires that assets services expose an interface (in the current > ogp description of the AD that is not the case). > > Note that this models does *not* assumes that all assets in a services > should be useable by the agent in all domains, but only that an interface is > available so an asset service in one domain can be contacted by another AD. > > I think exposing the asset service interface directly is essential for > meaningful interop. I think it would benefit the discussion if some > diagrams were added to http://wiki.secondlife.com/wiki/Structural_Designand/or to the VWRAP wiki to document this possibility. > > -Vaughn > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00504502c9e06177de04760c233e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vaughn,

You've correctly represented my MMOX post, thanks!=A0 ( = http://www.ietf.org/mail-archive/web/mmox/current/msg013= 92.html )

I must stress, as you did yourself, that the "Free Worlds Touri= st" use case which I described there in MMOX is different=A0 to the simpler "tourist use case" which we have been discussing= here.=A0 It's great that you're shining some light into this corne= r.=A0 Hopefully this will allow us to affix labels to the various cases to = keep our discussions simple yet clear.

Before addressing your actual point, I should first state that I consid= er it unfortunate that the "Free Worlds Tourist" use case = is not considered an integral part of VWRAP requirements --- this is a prac= tical conclusion on my part.=A0 On the basis of our discussions so far, I t= hink it would be too much to expect that a mode of operation offering such = a high degree of freedom of travel and of avatar appearance would achieve r= ough consensus in the group, given that its considerable distance from Seco= nd Life policies would almost certainly lead to intense opposition.=A0 This= is not a battle I wish to fight.

As a practical matter then, "Free Worlds Tourist" as d= efined above is not a use case that I am pushing in VWRAP at this time, des= pite it being entirely compatible with the SL/Opensim model and hence deser= ving inclusion.=A0 I'm simply going to express regret that it is likely= to be a bridge too far on political grounds and leave it at that.=A0 I wou= ld wish it were otherwise.

With that disclaimer, I'll answer your point about our more constra= ined "tourist use case" (which perhaps needs a better name), this= being a much easier target but still a very useful one.=A0 I will however = answer it in the immediately following post, because I don't want to ge= t this confused with the "Free Worlds Tourist" case that I= described in MMOX.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

On Fri, Oct 16, 2009 at 8:34 AM, Vaug= hn Deluca <vaughn.deluca@gmail.com> wrote:
The "to= urist use case" has been brought up several times, but the concept is = not always used in the same way, and needs to be more precisely defined.

Morgaines original definition of the "Free Worlds = Tourist use case"=A0in http://www.ietf.org/mail-arc= hive/web/mmox/current/msg01392.html
mentions two characteristics:

1. Trav= el requires no prior arrangement.
2. Your avatar is defined by you, not by the target worlds, an= d it appears in those worlds with no prior arrangement.=A0

Point 1 is only dependent the policies of the users AD = as well as that of the destination region. It is not dependent on the proto= col, so in principle solved.

The second point is a= ctually extending the SL use case beyond what is in my view needed for a ba= sic tourist model (and that is why the post was in the mmox list). =A0In my= view =A0a basic tourist use case has two main characteristics:

1. =A0Travel = requires no prior arrangement.
=A0=A0 =A0 =A0 =A02. =A0Agent doma= ins can use external asset services

Point 2 requir= es that assets services expose an interface (in the current ogp description= of the AD that is not the case).=A0

Note that this models does *not* assumes that all asset= s in a services should be useable by the agent in all domains, but only tha= t an interface is available so an asset service in one domain can be contac= ted by another AD.=A0

I think exposing the asset service interface directly i= s essential for meaningful interop. =A0I think it would benefit the discuss= ion if some diagrams were added to http://wiki.secondlife.com/wiki/Str= uctural_Design and/or to the VWRAP wiki to document this possibility.

-Vaughn

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00504502c9e06177de04760c233e-- From vaughn.deluca@gmail.com Fri Oct 16 06:35:59 2009 Return-Path: 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 13F8A3A69DF for ; Fri, 16 Oct 2009 06:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 eig4EcwoM-uB for ; Fri, 16 Oct 2009 06:35:57 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 33B0D3A68D2 for ; Fri, 16 Oct 2009 06:35:57 -0700 (PDT) Received: by fxm18 with SMTP id 18so2414313fxm.37 for ; Fri, 16 Oct 2009 06:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=40dRlydgjumgjUbnDlyS3dFSJs8FoBfLXA6GeR1Fzso=; b=SaIhrGHRRWyxgxQafev9fJuKR+HkG7vNnId6KR/mIyposA4O5qjB4EgW7jRtvlOTX+ gi9Fn1u6Qy15bYmYVyBpookum/6Q46s4nS+0sEofDqqlzjZrp6cneK8U5Xxmob7oP4hp 1FIFIFUBT/uf+Hc5rCJvLbyL1pYtq1XamgLZk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Hp9OX916UM3/J2DKkV4BFz0wR5HPevk/JXPCPxS9LNEKAT5X1H+nlB3YZjEVvkzteA 4MHs8+J8Admz1EUgnO7sBUjfOIpWIqIZqKZ99rw/xyOMpygm6BxEupXKYXGqVi0C82YD vfhY7uvvOUrPZFje0WVAEVlKA8OPV3Nna+1Mg= MIME-Version: 1.0 Received: by 10.204.2.211 with SMTP id 19mr1362408bkk.6.1255700157785; Fri, 16 Oct 2009 06:35:57 -0700 (PDT) In-Reply-To: <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> Date: Fri, 16 Oct 2009 15:35:57 +0200 Message-ID: <9b8a8de40910160635j268ef9c9mae55781221c94d7e@mail.gmail.com> From: Vaughn Deluca To: "Infinity Linden (Meadhbh Hamrick)" Content-Type: multipart/alternative; boundary=000e0cd1d6ead9686504760d79b8 Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 13:35:59 -0000 --000e0cd1d6ead9686504760d79b8 Content-Type: text/plain; charset=ISO-8859-1 Well, for what its worth, i would :), *Raises hand* But I see this use case in the first place as a vehicle for our thinking, and a way to spot implict assumptions that would limit the general usability of VWRAP. I think that just based on good design principles a strong argument can be made for asset services that expose their interface, rather than keeping them internal to the agent domain. Especially since there is nothing to prevent a configuration that works exactly as the current SL use case. So nothing has to be sacrificed, yet a much richer set of deployment patterns becomes possible. -Vaughn On Fri, Oct 16, 2009 at 10:16 AM, Infinity Linden (Meadhbh Hamrick) < infinity@lindenlab.com> wrote: > also. just a show of hands. who's planning on implementing the tourist > model? > > -- > infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" > http://wiki.secondlife.com/wiki/User:Infinity_Linden > > > > On Fri, Oct 16, 2009 at 00:34, Vaughn Deluca > wrote: > > The "tourist use case" has been brought up several times, but the concept > is > > not always used in the same way, and needs to be more precisely defined. > > Morgaines original definition of the "Free Worlds Tourist use case" in > > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html > > mentions two characteristics: > > 1. Travel requires no prior arrangement. > > 2. Your avatar is defined by you, not by the target worlds, and it > appears > > in those worlds with no prior arrangement. > > Point 1 is only dependent the policies of the users AD as well as that of > > the destination region. It is not dependent on the protocol, so in > principle > > solved. > > The second point is actually extending the SL use case beyond what is in > my > > view needed for a basic tourist model (and that is why the post was in > the > > mmox list). In my view a basic tourist use case has two main > > characteristics: > > 1. Travel requires no prior arrangement. > > 2. Agent domains can use external asset services > > Point 2 requires that assets services expose an interface (in the current > > ogp description of the AD that is not the case). > > Note that this models does *not* assumes that all assets in a services > > should be useable by the agent in all domains, but only that an interface > is > > available so an asset service in one domain can be contacted by another > AD. > > I think exposing the asset service interface directly is essential for > > meaningful interop. I think it would benefit the discussion if some > > diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design > > and/or to the VWRAP wiki to document this possibility. > > -Vaughn > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --000e0cd1d6ead9686504760d79b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Well, for what its worth, i would =A0:), =A0*Raises hand*

But I see this use case in the first place as a = vehicle for our thinking, and a way to spot implict assumptions that would = limit the general usability of VWRAP.

I think that just based on good design principles a str= ong argument can be made for asset services that expose their interface, ra= ther than keeping them internal to the agent domain.
Especially s= ince there is nothing to prevent a configuration that works exactly as the = current SL use case. So nothing =A0has to be sacrificed, yet a much richer = set of deployment patterns becomes possible.

-Vaughn=A0


=


On Fri, Oct 16, 2009 at 10:16 AM, Infinity Linde= n (Meadhbh Hamrick) <infinity@lindenlab.com> wrote:
=
also. just a show of hands. who's planning on implementing the tourist = model?

--
=A0 infinity linden (aka meadhbh hamrick) =A0* =A0it's pronounced &quo= t;maeve"
=A0 =A0 =A0 =A0 http://wiki.secondlife.com/wiki/User:Infinity_Lind= en



On Fri, Oct 16, 2009 at 00:34, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
> The "tourist use case" has been b= rought up several times, but the concept is
> not always used in the same way, and needs to be more precisely define= d.
> Morgaines original definition of the "Free Worlds Tourist use cas= e"=A0in
> http://www.ietf.org/mail-archive/web/mmox/current/m= sg01392.html
> mentions two characteristics:
> 1. Travel requires no prior arrangement.
> 2. Your avatar is defined by you, not by the target worlds, and it app= ears
> in those worlds with no prior arrangement.
> Point 1 is only dependent the policies of the users AD as well as that= of
> the destination region. It is not dependent on the protocol, so in pri= nciple
> solved.
> The second point is actually extending the SL use case beyond what is = in my
> view needed for a basic tourist model (and that is why the post was in= the
> mmox list). =A0In my view =A0a basic tourist use case has two main
> characteristics:
> 1. =A0Travel requires no prior arrangement.
> =A0=A0 =A0 =A0 =A02. =A0Agent domains can use external asset services<= br> > Point 2 requires that assets services expose an interface (in the curr= ent
> ogp description of the AD that is not the case).
> Note that this models does *not* assumes that all assets in a services=
> should be useable by the agent in all domains, but only that an interf= ace is
> available so an asset service in one domain can be contacted by anothe= r AD.
> I think exposing the asset service interface directly is essential for=
> meaningful interop. =A0I think it would benefit the discussion if some=
> diagrams were added to http://wiki.secondlife.com/wiki/Structural= _Design
> and/or to the VWRAP wiki to document this possibility.
> -Vaughn
> _____________________________________= __________
> ogpx mailing list
> ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx
>
>

--000e0cd1d6ead9686504760d79b8-- From meadhbh.siobhan@gmail.com Fri Oct 16 06:39:49 2009 Return-Path: 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 80AC93A6A1D for ; Fri, 16 Oct 2009 06:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] 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 8Hbucqh0JMkd for ; Fri, 16 Oct 2009 06:39:48 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 62E3B3A6873 for ; Fri, 16 Oct 2009 06:39:48 -0700 (PDT) Received: by pxi3 with SMTP id 3so2528322pxi.29 for ; Fri, 16 Oct 2009 06:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rQ/o0XzvJK+Ezb/uCZozhh3ks1GA9nlIYzdABOcYUBg=; b=X6Tq1G84ycLHIaVuE2XzyHh1rBmEVJ/BTvoRNJjdlp+1cWa5eOYy0aEMwOcmBqBoT/ MNM+5D7j80lGBKpNEI2quc+6gCX9x4vtnUemrRW3RtlI4c4bx/Shsct66JEvIRimh4LN DkZcKHYEnbXARlRsj+6vpS4mcpqCy/4c3Y58k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iIayCipYZmahztowN9sOPIt0JFtgFD9xkgCWyT/GzanfF5t5KKXNFHQCSwbkTPk9jG OUEJOtMWP1O8PfNHVZ7w0U8Krn1i0AILcudfgr8Uf6sOragRH8KIra/hIXFv296jR/n3 toCXr51e5JYULPKexUXGKQtthlg8lQG43z/NU= MIME-Version: 1.0 Received: by 10.115.38.39 with SMTP id q39mr1571135waj.27.1255700389462; Fri, 16 Oct 2009 06:39:49 -0700 (PDT) In-Reply-To: References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> Date: Fri, 16 Oct 2009 06:39:49 -0700 Message-ID: From: Meadhbh Hamrick To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 13:39:49 -0000 On Fri, Oct 16, 2009 at 1:51 AM, Morgaine wrote: > On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick) > wrote: > >> also. just a show of hands. who's planning on implementing the tourist >> model? > > Almost everybody who will operate virtual worlds, I assume --- that could= be > hundreds of thousands of world operators, if not millions, mostly small.= =A0 We > certainly can't foretell!=A0 And we can't get them to raise a show of han= ds > either. :-) you mean you think they're all going to be implementing their own software? i think that's unrealistic. even with the http servers, which i think we could agree is slightly less complicated than any virtual world protocol would be, web site operators use one of a handful of implementations: (Apache, IIS, WebSTAR?, ...) > I doubt that it will be common to operate walled gardens once everyone el= se > is allowing their users to travel freely among the huge diversity of the > metaverse.=A0 It certainly seems like a recipe for failure to deny touris= m to > one's residents as a matter of policy, given that tourism is so popular i= n > the physical world today. well. the examples of large virtual worlds that exist today are, as you call them, walled gardens. > However, this is a policy issue of course, and therefore not something th= at > VWRAP will dictate.=A0 We merely provide the mechanisms to allow tourism = when > desired, not mandate or deny it to any given world operator. i think it _is_ definitely important. we've set dates for the publication of standard documentations, and i think it's unrealistic to say that we are going to develop a standard that is infinitely flexible. we will need to focus on a small collection of deployment models. again, i have no problem including models that _will_ actually be used. i'm just not sure it behooves us to spend a fair amount of time ensuring our protocol flows work in deployment models that no one is currently planning on deploying. there's very clearly interest from linden for the "second life" [1] deployment model; intel has show a clear interest in the "cable beach" deployment model; OpenSim's UGAIM/Grid Mode and standalone deployment models. i'm just curious who is going to be coding software for the "tourist model." -cheers. -meadhbh/infinity From meadhbh.siobhan@gmail.com Fri Oct 16 06:44:17 2009 Return-Path: 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 2E0463A6A1D for ; Fri, 16 Oct 2009 06:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] 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 nNO4Nk38k6BJ for ; Fri, 16 Oct 2009 06:44:13 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 185A33A69E0 for ; Fri, 16 Oct 2009 06:44:13 -0700 (PDT) Received: by pzk42 with SMTP id 42so1849244pzk.31 for ; Fri, 16 Oct 2009 06:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d7cV46bolSzw5h4/hRo2ugPEUBO65LoDzhN+9Q/73U0=; b=ppvSfFnQux1frqw2lYu6TabafnwV/ZdWSf+oTVbNpAU/C08GyRJ+N413/ZSVve72iM e4uy4cln7B4mfrFOOlFKy+dAc8GbIeBCJorghA4+KhHzPlHjomepBrzDlai8i1deGWbW ndHihpdK1JwbPxa0JbAa+uCrpBDEGJlcuSZt4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fQFasF6hYhQDkU4+otn69WuLxIK64HBx0p2MsUdiXiXzddBb7amRQeSYosaDX1+jf+ 7PFAQHHxAmJ5bnsHSQa7Sk4dZh3gbI3ggKo2sKiY8Rcvqr5YVj3HdsuLjP1LgJoQ6kqQ SDBq17Sr+B1Zadud+QjbJwrK9YTosMeV39F7Y= MIME-Version: 1.0 Received: by 10.114.253.14 with SMTP id a14mr1544749wai.160.1255700652036; Fri, 16 Oct 2009 06:44:12 -0700 (PDT) In-Reply-To: References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> Date: Fri, 16 Oct 2009 06:44:11 -0700 Message-ID: From: Meadhbh Hamrick To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 13:44:17 -0000 but didn't we say that we were going to focus on "second life-like" worlds in this WG? isn't that why it was formed? shouldn't the tourist model be an effort of the MMOX group? i thought that was the reason we kept the MMOX mailing list up, so work could continue on that type of virtual world. -meadhbh/infinity On Fri, Oct 16, 2009 at 5:00 AM, Morgaine wrote: > Vaughn, > > You've correctly represented my MMOX post, thanks!=A0 ( > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html ) > > I must stress, as you did yourself, that the "Free Worlds Tourist" use ca= se > which I described there in MMOX is different=A0 to the simpler "tourist u= se > case" which we have been discussing here.=A0 It's great that you're shini= ng > some light into this corner.=A0 Hopefully this will allow us to affix lab= els > to the various cases to keep our discussions simple yet clear. > > Before addressing your actual point, I should first state that I consider= it > unfortunate that the "Free Worlds Tourist" use case is not considered an > integral part of VWRAP requirements --- this is a practical conclusion on= my > part.=A0 On the basis of our discussions so far, I think it would be too = much > to expect that a mode of operation offering such a high degree of freedom= of > travel and of avatar appearance would achieve rough consensus in the grou= p, > given that its considerable distance from Second Life policies would almo= st > certainly lead to intense opposition.=A0 This is not a battle I wish to f= ight. > > As a practical matter then, "Free Worlds Tourist" as defined above is not= a > use case that I am pushing in VWRAP at this time, despite it being entire= ly > compatible with the SL/Opensim model and hence deserving inclusion.=A0 I'= m > simply going to express regret that it is likely to be a bridge too far o= n > political grounds and leave it at that.=A0 I would wish it were otherwise= . > > With that disclaimer, I'll answer your point about our more constrained > "tourist use case" (which perhaps needs a better name), this being a much > easier target but still a very useful one.=A0 I will however answer it in= the > immediately following post, because I don't want to get this confused wit= h > the "Free Worlds Tourist" case that I described in MMOX. > > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca > wrote: >> >> The "tourist use case" has been brought up several times, but the concep= t >> is not always used in the same way, and needs to be more precisely defin= ed. >> Morgaines original definition of the "Free Worlds Tourist use case"=A0in >> http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html >> mentions two characteristics: >> 1. Travel requires no prior arrangement. >> 2. Your avatar is defined by you, not by the target worlds, and it appea= rs >> in those worlds with no prior arrangement. >> Point 1 is only dependent the policies of the users AD as well as that o= f >> the destination region. It is not dependent on the protocol, so in princ= iple >> solved. >> The second point is actually extending the SL use case beyond what is in >> my view needed for a basic tourist model (and that is why the post was i= n >> the mmox list). =A0In my view =A0a basic tourist use case has two main >> characteristics: >> 1. =A0Travel requires no prior arrangement. >> =A0=A0 =A0 =A0 =A02. =A0Agent domains can use external asset services >> Point 2 requires that assets services expose an interface (in the curren= t >> ogp description of the AD that is not the case). >> Note that this models does *not* assumes that all assets in a services >> should be useable by the agent in all domains, but only that an interfac= e is >> available so an asset service in one domain can be contacted by another = AD. >> I think exposing the asset service interface directly is essential for >> meaningful interop. =A0I think it would benefit the discussion if some >> diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design >> and/or to the VWRAP wiki to document this possibility. >> -Vaughn >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From vaughn.deluca@gmail.com Fri Oct 16 07:29:18 2009 Return-Path: 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 344773A6941 for ; Fri, 16 Oct 2009 07:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 HNE3lwHe16ig for ; Fri, 16 Oct 2009 07:29:16 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 1D03A3A68C3 for ; Fri, 16 Oct 2009 07:29:15 -0700 (PDT) Received: by fxm18 with SMTP id 18so2474839fxm.37 for ; Fri, 16 Oct 2009 07:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=fHMN20fDx5JW6lBXqYL82d21z7Uvn1CRQ7My2ubsd4g=; b=YOBKHBggdGeK/gS6YaOcyEFVKi2auX3V48tzaoOqHAOYe515xImuuq24MqINrncCNb UVoEsoOMUnLkb2YdWyCIeAZ9mdeOa9wa3v6tQ462S76387ZEAbhqqZ/1BCCt0S99NKzV PWKS1uLpLrkXFjYNbdQP+q64avMMgYKkSMLsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SnKJv///BdCFpoD5MhssvdfuziLpgZRpUSt5kad10vi+Axlki0H29mGOLBeyRU+Eh9 FsnpJLZVUYlsvknc+uqizak4nszCQG9AhUK0UhgD0rlzzJlDl3SlAvoxWKEs2GXa9WVb ryn6kBZPYRW4IAteTjLI68wBRrA9OXoeMbz7E= MIME-Version: 1.0 Received: by 10.204.5.75 with SMTP id 11mr1352801bku.20.1255703356654; Fri, 16 Oct 2009 07:29:16 -0700 (PDT) In-Reply-To: References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> Date: Fri, 16 Oct 2009 16:29:16 +0200 Message-ID: <9b8a8de40910160729s5dca2d8u7963b0b0fbfc9975@mail.gmail.com> From: Vaughn Deluca To: Meadhbh Hamrick Content-Type: multipart/alternative; boundary=00151743f7548447da04760e38fe Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 14:29:18 -0000 --00151743f7548447da04760e38fe Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 16, 2009 at 3:44 PM, Meadhbh Hamrick wrote: > but didn't we say that we were going to focus on "second life-like" > worlds in this WG? I strongly believe the basic mode *is* "second life like", even much more so than some of the other use cases considered in Davids layering draft. Also i do not think this needs to delay us much *at all*, since the basics idea has always been part of the deployment pattern considered. Look at the description of "adding a Organization domain" on the wiki: http://wiki.secondlife.com/wiki/Multiple_Domains#Adding_a_Organization_Domain . The figure legend states: > [...] The blue dotted line means that an agent can be linked > to another agent (e.g. the more public agent from the SL Agent domain > (== Linden Lab's grid)). This can mean the following: > > The company agent can access the inventory from the > company agent domain and from the SL Agent Domain This is in principle the tourist use case i have been describing! However, the wiki is not clear about the way to actually implement the restrictions: >So what we need here is a list of what should be restrictable >and a means of how to define it. My suggestion is to define the restrictions at the level of the services, completely analogous to the discussion we had about the Region Domain i.e. All policy is local -but the regions can use a global policy derived from the domain if they wish to do so). I therefore argue strongly for a design were Agent service and Asset service are both expressing policy, and both exposing an interface to the world. In this way it becomes fairly easy to configure any type of domain behaviour. I really see very few problems here, but maybe i am naive :) -Vaughn > isn't that why it was formed? shouldn't the tourist > model be an effort of the MMOX group? i thought that was the reason we > kept the MMOX mailing list up, so work could continue on that type of > virtual world. > > -meadhbh/infinity > > > On Fri, Oct 16, 2009 at 5:00 AM, Morgaine > wrote: > > Vaughn, > > > > You've correctly represented my MMOX post, thanks! ( > > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html ) > > > > I must stress, as you did yourself, that the "Free Worlds Tourist" use > case > > which I described there in MMOX is different to the simpler "tourist use > > case" which we have been discussing here. It's great that you're shining > > some light into this corner. Hopefully this will allow us to affix > labels > > to the various cases to keep our discussions simple yet clear. > > > > Before addressing your actual point, I should first state that I consider > it > > unfortunate that the "Free Worlds Tourist" use case is not considered an > > integral part of VWRAP requirements --- this is a practical conclusion on > my > > part. On the basis of our discussions so far, I think it would be too > much > > to expect that a mode of operation offering such a high degree of freedom > of > > travel and of avatar appearance would achieve rough consensus in the > group, > > given that its considerable distance from Second Life policies would > almost > > certainly lead to intense opposition. This is not a battle I wish to > fight. > > > > As a practical matter then, "Free Worlds Tourist" as defined above is not > a > > use case that I am pushing in VWRAP at this time, despite it being > entirely > > compatible with the SL/Opensim model and hence deserving inclusion. I'm > > simply going to express regret that it is likely to be a bridge too far > on > > political grounds and leave it at that. I would wish it were otherwise. > > > > With that disclaimer, I'll answer your point about our more constrained > > "tourist use case" (which perhaps needs a better name), this being a much > > easier target but still a very useful one. I will however answer it in > the > > immediately following post, because I don't want to get this confused > with > > the "Free Worlds Tourist" case that I described in MMOX. > > > > > > Morgaine. > > > > > > > > > > > > ===================================== > > > > On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca > > wrote: > >> > >> The "tourist use case" has been brought up several times, but the > concept > >> is not always used in the same way, and needs to be more precisely > defined. > >> Morgaines original definition of the "Free Worlds Tourist use case" in > >> http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html > >> mentions two characteristics: > >> 1. Travel requires no prior arrangement. > >> 2. Your avatar is defined by you, not by the target worlds, and it > appears > >> in those worlds with no prior arrangement. > >> Point 1 is only dependent the policies of the users AD as well as that > of > >> the destination region. It is not dependent on the protocol, so in > principle > >> solved. > >> The second point is actually extending the SL use case beyond what is in > >> my view needed for a basic tourist model (and that is why the post was > in > >> the mmox list). In my view a basic tourist use case has two main > >> characteristics: > >> 1. Travel requires no prior arrangement. > >> 2. Agent domains can use external asset services > >> Point 2 requires that assets services expose an interface (in the > current > >> ogp description of the AD that is not the case). > >> Note that this models does *not* assumes that all assets in a services > >> should be useable by the agent in all domains, but only that an > interface is > >> available so an asset service in one domain can be contacted by another > AD. > >> I think exposing the asset service interface directly is essential for > >> meaningful interop. I think it would benefit the discussion if some > >> diagrams were added to > http://wiki.secondlife.com/wiki/Structural_Design > >> and/or to the VWRAP wiki to document this possibility. > >> -Vaughn > >> _______________________________________________ > >> ogpx mailing list > >> ogpx@ietf.org > >> https://www.ietf.org/mailman/listinfo/ogpx > >> > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --00151743f7548447da04760e38fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 16, 2009 at 3:44 PM, Meadhbh= Hamrick <meadhbh.siobhan@gmail.com> wrote:
but didn't we say that we were going to focus on "second life-like= "
worlds in this WG?

I strongly believe= the basic =A0mode *is* "second life like", even much more so tha= n some of the other use cases considered in Davids layering draft.

Also i do not think this needs to delay us much *at all= *, since the basics idea has =A0always been part of the deployment pattern = considered. Look at the description of "adding a Organization domain&q= uot; on the wiki:

The figure legend stat= es:

> [...] The blue dotted line means that an agent can= be linked=A0
> to another agent (e.g. the more public agent f= rom the SL Agent domain=A0
> (=3D=3D Linden Lab's grid)). = This can mean the following:
>
> The company agent can access the inventory from th= e=A0
> company agent domain and from the SL Agent Domain
=

This is in principle the tourist use case i have been d= escribing!
However, the wiki is not clear about the way to actually implement the= restrictions:

>So what we need here is a list = of what should be restrictable
>and a means of how to define i= t.

My suggestion is to define the restrictions at the leve= l of the services, completely analogous to the discussion we had about the = Region Domain i.e. All policy is local -but the regions can use a global po= licy derived from the domain if they wish to do so).

I therefore argue strongly for a design were Agent serv= ice and Asset service are both expressing policy, and both exposing an inte= rface to the world.
In this way it becomes fairly easy to configu= re any type of domain behaviour.

I really see very few problems here, but maybe i am nai= ve =A0:)

-Vaughn

=A0
isn't that why it was formed? shouldn't the tourist
model be an effort of the MMOX group? i thought that was the reason we
kept the MMOX mailing list up, so work could continue on that type of
virtual world.

-meadhbh/infinity


On Fri, Oct 16, 2009 at 5:00 AM, Morgaine
<mor= gaine.dinova@googlemail.com> wrote:
> Vaughn,
>
> You've correctly represented my MMOX post, thanks!=A0 (
> http://www.ietf.org/mail-archive/web/mmox/current/m= sg01392.html )
>
> I must stress, as you did yourself, that the "Free Worlds Tourist= " use case
> which I described there in MMOX is different=A0 to the simpler "t= ourist use
> case" which we have been discussing here.=A0 It's great that = you're shining
> some light into this corner.=A0 Hopefully this will allow us to affix = labels
> to the various cases to keep our discussions simple yet clear.
>
> Before addressing your actual point, I should first state that I consi= der it
> unfortunate that the "Free Worlds Tourist" use case is not c= onsidered an
> integral part of VWRAP requirements --- this is a practical conclusion= on my
> part.=A0 On the basis of our discussions so far, I think it would be t= oo much
> to expect that a mode of operation offering such a high degree of free= dom of
> travel and of avatar appearance would achieve rough consensus in the g= roup,
> given that its considerable distance from Second Life policies would a= lmost
> certainly lead to intense opposition.=A0 This is not a battle I wish t= o fight.
>
> As a practical matter then, "Free Worlds Tourist" as defined= above is not a
> use case that I am pushing in VWRAP at this time, despite it being ent= irely
> compatible with the SL/Opensim model and hence deserving inclusion.=A0= I'm
> simply going to express regret that it is likely to be a bridge too fa= r on
> political grounds and leave it at that.=A0 I would wish it were otherw= ise.
>
> With that disclaimer, I'll answer your point about our more constr= ained
> "tourist use case" (which perhaps needs a better name), this= being a much
> easier target but still a very useful one.=A0 I will however answer it= in the
> immediately following post, because I don't want to get this confu= sed with
> the "Free Worlds Tourist" case that I described in MMOX.
>
>
> Morgaine.
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca <vaughn.deluca@gmail.com>
> wrote:
>>
>> The "tourist use case" has been brought up several times= , but the concept
>> is not always used in the same way, and needs to be more precisely= defined.
>> Morgaines original definition of the "Free Worlds Tourist use= case"=A0in
>> http://www.ietf.org/mail-archive/web/mmox/curre= nt/msg01392.html
>> mentions two characteristics:
>> 1. Travel requires no prior arrangement.
>> 2. Your avatar is defined by you, not by the target worlds, and it= appears
>> in those worlds with no prior arrangement.
>> Point 1 is only dependent the policies of the users AD as well as = that of
>> the destination region. It is not dependent on the protocol, so in= principle
>> solved.
>> The second point is actually extending the SL use case beyond what= is in
>> my view needed for a basic tourist model (and that is why the post= was in
>> the mmox list). =A0In my view =A0a basic tourist use case has two = main
>> characteristics:
>> 1. =A0Travel requires no prior arrangement.
>> =A0=A0 =A0 =A0 =A02. =A0Agent domains can use external asset servi= ces
>> Point 2 requires that assets services expose an interface (in the = current
>> ogp description of the AD that is not the case).
>> Note that this models does *not* assumes that all assets in a serv= ices
>> should be useable by the agent in all domains, but only that an in= terface is
>> available so an asset service in one domain can be contacted by an= other AD.
>> I think exposing the asset service interface directly is essential= for
>> meaningful interop. =A0I think it would benefit the discussion if = some
>> diagrams were added to http://wiki.secondlife.com/wiki/Struct= ural_Design
>> and/or to the VWRAP wiki to document this possibility.
>> -Vaughn
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

--00151743f7548447da04760e38fe-- From sean@uci.edu Fri Oct 16 08:43:57 2009 Return-Path: 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 3810528C0F9 for ; Fri, 16 Oct 2009 08:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 hkAZCVVkoDTm for ; Fri, 16 Oct 2009 08:43:56 -0700 (PDT) Received: from smtp2.es.uci.edu (smtp2.es.uci.edu [128.200.80.28]) by core3.amsl.com (Postfix) with ESMTP id 42B1928C10B for ; Fri, 16 Oct 2009 08:43:56 -0700 (PDT) Received: from [128.200.62.123] (sean.nac.uci.edu [128.200.62.123]) (authenticated bits=0) by smtp2.es.uci.edu (8.13.1/8.13.1) with ESMTP id n9GFhxME021793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Oct 2009 08:44:00 -0700 X-UCInetID: sean Message-ID: <4AD894BE.30501@uci.edu> Date: Fri, 16 Oct 2009 08:43:58 -0700 From: Sean Hennessee Organization: NACS CCS User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ogpx@ietf.org References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 15:43:57 -0000 Meadhbh Hamrick wrote: > On Fri, Oct 16, 2009 at 1:51 AM, Morgaine > wrote: >> On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick) >> wrote: >> >>> also. just a show of hands. who's planning on implementing the tourist >>> model? >> Almost everybody who will operate virtual worlds, I assume --- that could be >> hundreds of thousands of world operators, if not millions, mostly small. We >> certainly can't foretell! And we can't get them to raise a show of hands >> either. :-) > > you mean you think they're all going to be implementing their own > software? i think that's unrealistic. even with the http servers, > which i think we could agree is slightly less complicated than any > virtual world protocol would be, web site operators use one of a > handful of implementations: (Apache, IIS, WebSTAR?, ...) I think this is completely realistic. With the progress that OpenSim is making towards standalone (SL Like) grids, there will very likely be services popping up all over the interweb providing standalone virtual worlds for free or at a very low cost, much like services today provide blog spaces, photo spaces, and a host of other web based services for free and for fee. I don't have to host my own Apache web server just to have a tumblr.com blog or a flickr.com photo site. The blog and photo site of the future will be SL like virtual worlds, (or perhaps more accurately, "virtual homes"). >> I doubt that it will be common to operate walled gardens once everyone else >> is allowing their users to travel freely among the huge diversity of the >> metaverse. It certainly seems like a recipe for failure to deny tourism to >> one's residents as a matter of policy, given that tourism is so popular in >> the physical world today. > > well. the examples of large virtual worlds that exist today are, as > you call them, walled gardens. This is only because the idea of treating your "virtual home" as its' own space that can have "virtual tourists" come and visit is only now being implemented in OpenSim with standalones and hypergrids. In the past the focus was more on creating a system too much like SL in the sense that SL is one huge virtual world. I would assume that "SL Like" implies the 3d experience that is SL and not also the hugeness that is SL. Peace, Sean > >> However, this is a policy issue of course, and therefore not something that >> VWRAP will dictate. We merely provide the mechanisms to allow tourism when >> desired, not mandate or deny it to any given world operator. > > i think it _is_ definitely important. we've set dates for the > publication of standard documentations, and i think it's unrealistic > to say that we are going to develop a standard that is infinitely > flexible. we will need to focus on a small collection of deployment > models. again, i have no problem including models that _will_ actually > be used. i'm just not sure it behooves us to spend a fair amount of > time ensuring our protocol flows work in deployment models that no one > is currently planning on deploying. > > there's very clearly interest from linden for the "second life" [1] > deployment model; intel has show a clear interest in the "cable beach" > deployment model; OpenSim's UGAIM/Grid Mode and standalone deployment > models. i'm just curious who is going to be coding software for the > "tourist model." > > -cheers. > -meadhbh/infinity -- Sean Hennessee Central Computing Support Office of Information Technology UC Irvine ... . .- -. / .... . -. -. . ... ... . . From josh@lindenlab.com Fri Oct 16 10:03:33 2009 Return-Path: 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 EFA8D28C0D8 for ; Fri, 16 Oct 2009 10:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 biDHXPuGKkOS for ; Fri, 16 Oct 2009 10:03:33 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 088AE28C0FE for ; Fri, 16 Oct 2009 10:03:32 -0700 (PDT) Received: by pxi3 with SMTP id 3so2697591pxi.29 for ; Fri, 16 Oct 2009 10:03:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.35.18 with SMTP id n18mr77481rvj.245.1255712613700; Fri, 16 Oct 2009 10:03:33 -0700 (PDT) In-Reply-To: <4AD894BE.30501@uci.edu> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <4AD894BE.30501@uci.edu> Date: Fri, 16 Oct 2009 10:03:33 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cd148be4795a80476106019 Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 17:03:34 -0000 --000e0cd148be4795a80476106019 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 16, 2009 at 8:43 AM, Sean Hennessee wrote: > Meadhbh Hamrick wrote: > >> On Fri, Oct 16, 2009 at 1:51 AM, Morgaine >> wrote: >> >>> On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick) >>> wrote: >>> >>> also. just a show of hands. who's planning on implementing the tourist >>>> model? >>>> >>> Almost everybody who will operate virtual worlds, I assume --- that could >>> be >>> hundreds of thousands of world operators, if not millions, mostly small. >>> We >>> certainly can't foretell! And we can't get them to raise a show of hands >>> either. :-) >>> >> >> you mean you think they're all going to be implementing their own >> software? i think that's unrealistic. even with the http servers, >> which i think we could agree is slightly less complicated than any >> virtual world protocol would be, web site operators use one of a >> handful of implementations: (Apache, IIS, WebSTAR?, ...) >> > > I think this is completely realistic. With the progress that OpenSim is > making towards standalone (SL Like) grids, there will very likely be > services popping up all over the interweb providing standalone virtual > worlds for free or at a very low cost, > Before this gets out of hand, let's clarify the meaning of "implement" There are two distinct definitions in extremely common use on the 'net: (1) to implement: write the code for something (2) to implement: configure and deploy code for something With definition #1, as an example, the Apache Software Foundation is the only implementer of the apache HTTP server (ignoring any distro/site customizations for the moment) - those millions of web sites that operate services using apache are NOT implementers. Definition #2 is used a lot as well, e.g. "our corporate IT department implemented Microsoft Exchange Server for our mail and calendar services". With this definition, ANYONE who rolls out the code (with configuration on top of it) is considered an implementer. So far as I can tell, IETF discussions almost exclusively use meaning #1. With this definition, we would expect a small number of initial implementers of VWRAP-based software (the usual suspects - OpenSim, Linden Lab, and so forth), orders of more magnitude more people deploying services based on that software, and over time more VW providers with independent code bases adopting the protocol either during their initial design phase or to enable interop. My interpretation of this thread is that Infinity is using definition #1, Sean and Morgaine are using definition #2. Infinity is asking specifically: "who will write the code that adds support for the protocol to a piece of software?" not "who will make use of software that implements the protocol?" --000e0cd148be4795a80476106019 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 16, 2009 at 8:43 AM, Sean Hennessee = <sean@uci.edu><= /span> wrote:
Meadhbh Hamrick wrote:
On Fri, Oct 16, 2009 at 1:51 AM, Morgaine
<mor= gaine.dinova@googlemail.com> wrote:
On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick)
<infinity@li= ndenlab.com> wrote:

also. just a show of hands. who's planning on implementing the tourist<= br> model?
Almost everybody who will operate virtual worlds, I assume --- that could b= e
hundreds of thousands of world operators, if not millions, mostly small. = =C2=A0We
certainly can't foretell! =C2=A0And we can't get them to raise a sh= ow of hands
either. :-)

you mean you think they're all going to be implementing their own
software? i think that's unrealistic. even with the http servers,
which i think we could agree is slightly less complicated than any
virtual world protocol would be, web site operators use one of a
handful of implementations: (Apache, IIS, WebSTAR?, ...)

I think this is completely realistic. With the progress that OpenSim is mak= ing towards standalone (SL Like) grids, there will very likely be services = popping up all over the interweb providing standalone virtual worlds for fr= ee or at a very low cost,

Before this gets out of hand, let's clarify the = meaning of "implement"

There are two distinct definitions = in extremely common use on the 'net:

(1) to implement: write the= code for something
(2) to implement: configure and deploy code for something

With defin= ition #1, as an example, the Apache Software Foundation is the only impleme= nter of the apache HTTP server (ignoring any distro/site customizations for the = moment) - those millions of web sites that operate services using apache ar= e NOT implementers.

Definition #2 is used a lot as well, e.g. "= ;our corporate IT department implemented Microsoft Exchange Server for our = mail and calendar services". With this definition, ANYONE who rolls ou= t the code (with configuration on top of it) is considered an implementer.<= br>
So far as I can tell, IETF discussions almost exclusively use meaning #= 1.

With this definition, we would expect a small number of initial implementers of VWRAP-based softw= are (the usual suspects - OpenSim, Linden Lab, and so forth), orders of mor= e magnitude more people deploying services based on that software, and over= time more VW providers with independent code bases adopting the protocol e= ither during their initial design phase or to enable interop.

My interpretation of this thread is that Infinity is using definition #= 1, Sean and Morgaine are using definition #2. Infinity is asking specifical= ly: "who will write the code that adds support for the protocol to a p= iece of software?" not "who will make use of software that implem= ents the protocol?"

--000e0cd148be4795a80476106019-- From meadhbh.siobhan@gmail.com Fri Oct 16 11:01:45 2009 Return-Path: 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 B9E223A68AB for ; Fri, 16 Oct 2009 11:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] 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 k+DRiwH-nNcV for ; Fri, 16 Oct 2009 11:01:45 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id E93C83A635F for ; Fri, 16 Oct 2009 11:01:44 -0700 (PDT) Received: by pxi3 with SMTP id 3so2744222pxi.29 for ; Fri, 16 Oct 2009 11:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WZN3kFJmamHiLQRegLuVP7LYqCJTiwfw48GztlBQLeA=; b=LMwLzGY6Etqa4H/yPw3L8NrL/Qu/5cd7rQNwf2L+tQ3fegANWCAeWbXVl+nkrkobLY iuKlfawX5RcyIPR3UlGWs+snDmduzXgPe58W9dA+w+PgJfgWRNT64j/0vl23J10JN9Rb Bjo/RTu1vIWYG9S80wKHS9i5frR7p3hq9SrCQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=n9e7tcUF7AgP8wSMBImEfSDYVgBypyvhcWaQYP00BMGySwRsuRpiABiTD6qprha8eQ 4eMkuRP68AcqEY0MaOINewSQ6JF518xK3nWwfdCYEmnuO2+IznN7VpBi44wYTbCKxRgb jVhoGpkmRwim0Chg1Zc7JjLuY8TjsvSusqiNA= MIME-Version: 1.0 Received: by 10.115.87.33 with SMTP id p33mr1722181wal.101.1255716106837; Fri, 16 Oct 2009 11:01:46 -0700 (PDT) In-Reply-To: <9b8a8de40910160635j268ef9c9mae55781221c94d7e@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <9b8a8de40910160635j268ef9c9mae55781221c94d7e@mail.gmail.com> Date: Fri, 16 Oct 2009 11:01:46 -0700 Message-ID: From: Meadhbh Hamrick To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Infinity Linden \(Meadhbh Hamrick\)" , ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 18:01:45 -0000 On Fri, Oct 16, 2009 at 6:35 AM, Vaughn Deluca wr= ote: > Well, for what its worth, i would =A0:), =A0*Raises hand* cool! code is always welcome. more comments to follow. > But I see this use case in the first place as a vehicle for our thinking, > and a way to spot implict assumptions that would limit the general usabil= ity > of VWRAP. sure. i kinda see the tourist model as being one end of the spectrum and the standalone sim being the other. once you bracket the two ends of the design space, you can start working to the middle where you'll find cable beach and second life. > I think that just based on good design principles a strong argument can b= e > made for asset services that expose their interface, rather than keeping > them internal to the agent domain. absolutely! one of the things jhurliman and i have been discussing is the concept of having a unified access protocol to reference assets in someone's inventory AND assets that are rezzed in a simulator. having the asset server expose an API directly would allow third party tools to interact with and modify assets in one's inventory. obviously we want to be very careful about this for security reasons, but i think you could do some very compelling things (like integrate facebook and your inventory. that way i would be able to rez all those pink elephants people keep giving me and shoot at them in damage enabled sims.) and a use case for exposing the "asset service" on the simulator for rezzed objects is it would allow them to expose a web interface like the current http-in function in SL today. that way you could have your online google docs presentation signal a presenter in world to change slides so you can more easily do mixed reality presentations. the decision to expose any or all of an asset service's interfaces to systems outside the agent or region domains is entirely a policy matter. i absolutely agree we should design a protocol that COULD expose everything publicly, though i would suggest that it's unlikely anyone would ever deploy a service without reasonable access controls. well. not on the public intarwebz directly. > Especially since there is nothing to prevent a configuration that works > exactly as the current SL use case. So nothing =A0has to be sacrificed, y= et a > much richer set of deployment patterns becomes possible. > -Vaughn agreed. any dissenting voices? -meadhbh/infinity From meadhbh.siobhan@gmail.com Fri Oct 16 11:13:37 2009 Return-Path: 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 1EB273A67EF for ; Fri, 16 Oct 2009 11:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] 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 nLRVmMBKTRK6 for ; Fri, 16 Oct 2009 11:13:36 -0700 (PDT) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 5E5413A67D8 for ; Fri, 16 Oct 2009 11:13:36 -0700 (PDT) Received: by pwi4 with SMTP id 4so320762pwi.29 for ; Fri, 16 Oct 2009 11:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vMRQTTh23MryE+FIftq2D0UPe7lHT86NZP7IObW4F20=; b=nOe6Xmk8E605PA5ZX02Ue6GkpEeYeHY/TST5XhiUqh2MIcjOJdTrsBPA6s3AXvlOWn /njvnqPa6z4HbshRqgM4serXHq5OqI02TBZ1hJOw7gmYMRKg/z9iKlEbflu8x22/X0qs oxwoiLLvTnwUBSza9lFRcJeq0o1+4M00Fn3vA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jy5FeoKoH/bETh4kfZfBHLTqX6eEXvPlNfSQNcDTd5zDFiotWfxD7s/6P0Yqe6XNoH Pq9ZP5HSYCaikFO3YLLLxsHehEXLS4erEjt5ge9k5kySxHABZ2SzfhDsx4254jKROwju +fm+imOGGe1et6WlOjNFhthb85avx6YGOLg3k= MIME-Version: 1.0 Received: by 10.114.2.34 with SMTP id 34mr1712196wab.213.1255716818383; Fri, 16 Oct 2009 11:13:38 -0700 (PDT) In-Reply-To: <9b8a8de40910160635j268ef9c9mae55781221c94d7e@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <9b8a8de40910160635j268ef9c9mae55781221c94d7e@mail.gmail.com> Date: Fri, 16 Oct 2009 11:13:38 -0700 Message-ID: From: Meadhbh Hamrick To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Cc: "Infinity Linden \(Meadhbh Hamrick\)" , ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 18:13:37 -0000 On Fri, Oct 16, 2009 at 6:35 AM, Vaughn Deluca wrote: > > Well, for what its worth, i would :), *Raises hand* okay. cool. as long as we don't put anything in a normative document that requires a particular deployment pattern, i think we're good. knowing that someone who's taken the time to participate in the list discussion is interested in coding "tourist deployment model" software is probably good enough justification to include it in the intro doc (which is non-normative) as an identified use case. i don't want to speak for david, but i think he would be hip to defining deployment models as "who trusts whom directly, what domain services are in, and how does the initiator of protocol get the address for a service's resources." david is working on typing up the descriptions of deployment models for inclusion in the intro document, and since we have a finite amount of space in the doc (i understand it that the IETF frowns on infinite length drafts,) i propose we focus on a finite number of deployment models. as i see it we have four deployment models: SL, OpenSim Standalone, Cable Beach and Tourist. if we find this list is insufficient, we can always revisit it later. if we find we've exposed a new deployment model after the intro draft is published, we can publish it's details in a subsequent draft / RFC. if the model is important enough, i'm sure we can negotiate with our Area Director to have it added to the list of "official" WG deliverables. the reason i suggest this is we _do_ have a deadline, and we have to start typing. lemme kick off a discussion of the details of the deployment models in a different thread. From cfk@pacbell.net Fri Oct 16 12:39:35 2009 Return-Path: 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 B935C3A68B7 for ; Fri, 16 Oct 2009 12:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 BRfXQ9mQQpDU for ; Fri, 16 Oct 2009 12:39:34 -0700 (PDT) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id 2A38A3A63D3 for ; Fri, 16 Oct 2009 12:39:34 -0700 (PDT) Received: (qmail 23373 invoked by uid 60001); 16 Oct 2009 19:39:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=bqoBmqhFHMZZR0ILfipkwT16MaEZETMKeZMdIzXs+bAZbqRK2DuY03y/x29yDP6vd2wtflhwm4ab8GzbOcSScJY93T+TWLGnRIMtp0fNYf4EfhJsDXgx2uTB4ZNsw83yfESu16nWS4129Mqcg2Aj0TR2A1L5kxAkweyllrDKbJ8=; Message-ID: <80997.23355.qm@web82605.mail.mud.yahoo.com> X-YMail-OSG: Ovg0mLMVM1leoR8BjzZH2iVzlKO1pBQP9tZ9ldKYUxMgb3B8NAymnP0LG60p3ICMcveZ7YsCHyWYIJ4MZEWHf8X0Q0dIJisURb51E6Zs65T8xV2MAXq2QhtPlURnGlHQQNd7BwYTrRgAF2nPdpsQXBo3BR4CcNBVmAI_gMngrKWF5fAD8PiTzoSDxfSVZpOW3UnFv5cuGSObtFIL8bVCck2.70tmTops6XYnOPzX0MsLxPGwI_H8UK_jy0NePxtJ2SUxEOL_FZGEA25LHLz5zEa2eNB3ExFynEV25AY029c2uRusTD8J4QpvQRQ2qb7wrEzYALmfAlvYGBtxaN36kZlJFfAY9MWCfiI80KbDLRF8mbT2ohPJDKUl7ippMjl6_.vdRxtg3gChrNVDIEZSoYOdqZodx5FsJAKnE_w- Received: from [67.120.11.67] by web82605.mail.mud.yahoo.com via HTTP; Fri, 16 Oct 2009 12:39:35 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g2f4f394ag763822dbd35c80e1@mail.gmail.com> <9b8a8de40910160316w364a2695t8e8dd8992e0b524f@mail.gmail.com> Date: Fri, 16 Oct 2009 12:39:35 -0700 (PDT) From: Charles Krinke To: Vaughn Deluca , "Infinity Linden \(Meadhbh Hamrick\)" In-Reply-To: <9b8a8de40910160316w364a2695t8e8dd8992e0b524f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-850011631-1255721975=:23355" Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 19:39:35 -0000 --0-850011631-1255721975=:23355 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Is it reasonable to consider that in some (or all) of the normal use cases,= that when some key element fails in the protocol related to authentication= , inventory or the like, that we can consider completing the teleport as a = "Tourist" ??=0A=0AThat might simplify debugging this monster we are creatin= g.=0A=0ACharles=0A=0A=0A=0A=0A________________________________=0AFrom: Vaug= hn Deluca =0ATo: Infinity Linden (Meadhbh Hamrick)= =0ACc: ogpx@ietf.org=0ASent: Friday, October 16, 2= 009 3:16:51 AM=0ASubject: Re: [ogpx] Tourist use case=0A=0A=0A=0A=0AOn Fri,= Oct 16, 2009 at 10:16 AM, Infinity Linden (Meadhbh Hamrick) wrote:=0A=0Ai had assumed that the "tourist model" also implied = that the client=0A>assumes no transitive trust on behalf of the agent domai= n, or includes=0A>the agent domain as part of a client implementation.=0A>= =0A=0ANot in the most basic case, Morgaine indeed defined it that way, but = i feel that that is a more complicated use case, and we would benefit from = treating =A0it separately from the more basic case.=0A=A0=0A=0Aalso. we sho= uld tighten up the language. i would argue that from the=0A>client's perspe= ctive, teleporting between Sim 1 and Sim 2 requires no=0A>prior arrangement= (for the client.) it does, however, require the=0A>agent domain to trust b= oth sims.=0A>=0A=0AYes, but note that the asset service will have its own p= olicy in this model, so the needed reasons to distrust the destination regi= on are limited. One obvious reason would be that promises were made to the = user to protect the avatar from exposure to adult material.=0ABut if the us= er indicates is has no problem, i would think in the majority of cases the = Agent service can trust the region. In the worst case the avatar would have= to be ruthed because the avatar shape can not be exported.=0A=0Amaybe we c= ould define the various models in terms of who trusts whom=0A>and how servi= ce endpoint addresses are resolved?=0A>=0A=0AYes, i like that suggestion.= =A0=0A=0Aso the "second life" model [1] would essentially be that the clien= t=0A>and the agent domain trust each other, and the agent domain and all of= =0A>the region domains trust each other. service endpoints for agent=0A>ser= vices are given to the client by the agent domain, while region=0A>service = are given to the client by the agent domain or the region=0A>domain.=0A>=0A= =0AYes, although you specify a bit more trust that is needed in my view bec= ause you do not =A0 =A0allow assets services there own policy, distinct fro= m the agent service policy, but if you want to make a blanket statement thi= s is correct.=A0=0A=0A>in the "tourist model" you would have no trust, and = the client is=0A>responsible for resolving the address of all services.=0A= =0ANo, you loose me here. The client *does* =A0trust the agent service, the= re is no difference here with the SL case. The client logs in to an AD, and= by definition trusts that service.=0Athat AD has its own asset service, = =A0just like in the SL case, and the user can use those assets (as far as t= he Asset service allows the assets to go out to other domains).=0AIn additi= on to using its own asset services the Agent service can use other Asset se= rvices.=0A=A0=A0=0Ain the "cable beach" model, you have the same trust as t= he "second=0A>life" model, but you bring the asset service into it's own do= main=0A>which is explicitly trusted by the agent domain, the region domains= =0A>and the client. asset service endpoints are resolved by the client.=0A>= =0A=0AI did not yet look in detail at cable beach, but I clearly =A0should,= since this sounds a lot like what i was thinking of. =A0However, =A0I do n= ot think its needed to put the asset service in its own domain, because by = definition a domain is under a different administration, and in many cases = the asset service will be in some domain. So the critical point is that the= asset service in some domain exposes an interface to the world so its asse= ts *can* be used, if by anybody if policy allows it.=0A=0A-Vaughn=0A=0A=0A>= -cheers=0A>-meadhbh=0A>=0A>--=0A>=A0 infinity linden (aka meadhbh hamrick) = =A0* =A0it's pronounced "maeve"=0A>=A0 =A0 =A0 =A0 http://wiki.secondlife.c= om/wiki/User:Infinity_Linden=0A>=0A>=0A>=0A>=0A>On Fri, Oct 16, 2009 at 00:= 34, Vaughn Deluca wrote:=0A>> The "tourist use ca= se" has been brought up several times, but the concept is=0A>> not always u= sed in the same way, and needs to be more precisely defined.=0A>> Morgaines= original definition of the "Free Worlds Tourist use case"=A0in=0A>> http:/= /www.ietf.org/mail-archive/web/mmox/current/msg01392.html=0A>> mentions two= characteristics:=0A>> 1. Travel requires no prior arrangement.=0A>> 2. You= r avatar is defined by you, not by the target worlds, and it appears=0A>> i= n those worlds with no prior arrangement.=0A>> Point 1 is only dependent th= e policies of the users AD as well as that of=0A>> the destination region. = It is not dependent on the protocol, so in principle=0A>> solved.=0A>> The = second point is actually extending the SL use case beyond what is in my=0A>= > view needed for a basic tourist model (and that is why the post was in th= e=0A>> mmox list). =A0In my view =A0a basic tourist use case has two main= =0A>> characteristics:=0A>> 1. =A0Travel requires no prior arrangement.=0A>= > =A0=A0 =A0 =A0 =A02. =A0Agent domains can use external asset services=0A>= > Point 2 requires that assets services expose an interface (in the current= =0A>> ogp description of the AD that is not the case).=0A>> Note that this = models does *not* assumes that all assets in a services=0A>> should be usea= ble by the agent in all domains, but only that an interface is=0A>> availab= le so an asset service in one domain can be contacted by another AD.=0A>> I= think exposing the asset service interface directly is essential for=0A>> = meaningful interop. =A0I think it would benefit the discussion if some=0A>>= diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design= =0A>> and/or to the VWRAP wiki to document this possibility.=0A>> -Vaughn= =0A>> _______________________________________________=0A>> ogpx mailing lis= t=0A>> ogpx@ietf.org=0A>> https://www.ietf.org/mailman/listinfo/ogpx=0A>>= =0A>>=0A>=0A --0-850011631-1255721975=:23355 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Is it reasonable to consider that in some = (or all) of the normal use cases, that when some key element fails in the p= rotocol related to authentication, inventory or the like, that we can consi= der completing the teleport as a "Tourist" ??
=0A
 
=0A<= DIV>That might simplify debugging this monster we are creating.
=0A 
=0A
Charles
=0A

=0A=0A
=0AFrom: Vaughn Deluca <vaughn.deluca@gmail.com&= gt;
To: Infinity Linden = (Meadhbh Hamrick) <infinity@lindenlab.com>
Cc: ogpx@ietf.org
Sent: Friday, October 16, 2009 3:16:51 AM
Subject: Re: [ogpx] Tourist use case


=0A
On Fri, Oct 16, 2009 at 10= :16 AM, Infinity Linden (Meadhbh Hamrick) <infinity@lindenlab.com> wrote:
= =0A
i had assumed that the "tourist= model" also implied that the client
assumes no transitive trust on beha= lf of the agent domain, or includes
the agent domain as part of a client= implementation.
=0A

=0A
Not in the most = basic case, Morgaine indeed defined it that way, but i feel that that is a = more complicated use case, and we would benefit from treating  it sepa= rately from the more basic case.
=0A
 
=0Aalso. we should tighten up the language. i w= ould argue that from the
client's perspective, teleporting between Sim 1= and Sim 2 requires no
prior arrangement (for the client.) it does, howe= ver, require the
agent domain to trust both sims.
=0A
=0A
Yes, but note that the asset service will have its own = policy in this model, so the needed reasons to distrust the destination reg= ion are limited. One obvious reason would be that promises were made to the= user to protect the avatar from exposure to adult material.
=0A
B= ut if the user indicates is has no problem, i would think in the majority o= f cases the Agent service can trust the region. In the worst case the avata= r would have to be ruthed because the avatar shape can not be exported.=0A
 
=0A
maybe we = could define the various models in terms of who trusts whom
and how serv= ice endpoint addresses are resolved?
=0A

=0A<= DIV>Yes, i like that suggestion. 
=0A
 
=0Aso the "second life" model [1] would essen= tially be that the client
and the agent domain trust each other, and the= agent domain and all of
the region domains trust each other. service en= dpoints for agent
services are given to the client by the agent domain, = while region
service are given to the client by the agent domain or the = region
domain.
=0A

=0A
Yes, although y= ou specify a bit more trust that is needed in my view because you do not &n= bsp;  allow assets services there own policy, distinct from the agent = service policy, but if you want to make a blanket statement this is correct= . 
=0A

in the "touris= t model" you would have no trust, and the client is
responsible for reso= lving the address of all services.
=0A

=0A
No= , you loose me here. The client *does*  trust the agent service, there= is no difference here with the SL case. The client logs in to an AD, and b= y definition trusts that service.
=0A
that AD has its own asset se= rvice,  just like in the SL case, and the user can use those assets (a= s far as the Asset service allows the assets to go out to other domains).=0A
In addition to using its own asset services the Agent service c= an use other Asset services.
=0A
  
=0A
in the "cable beach" model, you have the same = trust as the "second
life" model, but you bring the asset service into i= t's own domain
which is explicitly trusted by the agent domain, the regi= on domains
and the client. asset service endpoints are resolved by the c= lient.
=0A

=0A
I did not yet look in deta= il at cable beach, but I clearly  should, since this sounds a lot like= what i was thinking of.  However,  I do not think its needed to = put the asset service in its own domain, because by definition a domain is = under a different administration, and in many cases the asset service will = be in some domain. So the critical point is that the asset service in some = domain exposes an interface to the world so its assets *can* be used, if by= anybody if policy allows it.
=0A

=0A
-Vaughn
= =0A

=0A

-cheers-meadhbh

--
  infinity linden (aka meadhbh hamrick)  = *  it's pronounced "maeve"
        http://wiki.= secondlife.com/wiki/User:Infinity_Linden
=0A
=0A
=0A



On Fri, Oct 16, 2009 at 00:34, Vaughn Deluca <vaughn.deluca@gmail.com> wrote= :
> The "tourist use case" has been brought up several times, but the= concept is
> not always used in the same way, and needs to be more p= recisely defined.
> Morgaines original definition of the "Free Worlds= Tourist use case" in
> http://www.ietf.org/mail-archive/web/mmo= x/current/msg01392.html
> mentions two characteristics:
> 1. Tr= avel requires no prior arrangement.
> 2. Your avatar is defined by yo= u, not by the target worlds, and it appears
> in those worlds with no= prior arrangement.
> Point 1 is only dependent the policies of the u= sers AD as well as that of
> the destination region. It is not depend= ent on the protocol, so in principle
> solved.
> The second point is actually extending the SL use case beyond what is in my
> v= iew needed for a basic tourist model (and that is why the post was in the> mmox list).  In my view  a basic tourist use case has two = main
> characteristics:
> 1.  Travel requires no prior arr= angement.
>         2.  Agent domains c= an use external asset services
> Point 2 requires that assets service= s expose an interface (in the current
> ogp description of the AD tha= t is not the case).
> Note that this models does *not* assumes that a= ll assets in a services
> should be useable by the agent in all domai= ns, but only that an interface is
> available so an asset service in = one domain can be contacted by another AD.
> I think exposing the ass= et service interface directly is essential for
> meaningful interop. =  I think it would benefit the discussion if some
> diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design> and/or to the VWRAP wiki to document this possibility.
> -Vaug= hn
> _______________________________________________
&= gt; ogpx mailing list
> ogpx@ietf.org
&g= t; https://www.ietf.org/mailman/listinfo/ogpx
>
>= ;

On Mon, Oct 12, 2009 at 10:13 PM, Morgaine <morgaine= .dinova@googlemail.com> wrote:
I suggest that the protocol define Derez and Rez as concurrent and non-dependent operations to avoid this situation.=C2=A0= The AD can mark R1 as disabled for all further agent state changes --- thi= s will provide all the protection needed to prevent brief double-presence a= nomalies from being significant.=C2=A0 If a jammed R1 refuses to give up it= s hold on the avatar, then at least the user will not suffer from it.=C2=A0= Reaping dead simulator sessions then becomes a problem for the region oper= ator alone, and not for the AD, the user, and the region as happens now.
--0-850011631-1255721975=:23355-- From cfk@pacbell.net Fri Oct 16 12:44:44 2009 Return-Path: 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 48F8F3A68C3 for ; Fri, 16 Oct 2009 12:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 sZ+fcgABUQkD for ; Fri, 16 Oct 2009 12:44:43 -0700 (PDT) Received: from web82606.mail.mud.yahoo.com (web82606.mail.mud.yahoo.com [68.142.201.123]) by core3.amsl.com (Postfix) with SMTP id D77DE3A659A for ; Fri, 16 Oct 2009 12:44:42 -0700 (PDT) Received: (qmail 28501 invoked by uid 60001); 16 Oct 2009 19:44:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=O2m7TLscPAOA8XwGbmzFWArnnm6kHpgMzVgdwmYjO+y21rqdoZhHnJiZxqKpryLJvshTHPgkfP89D3gVfIiTQY8y5ySDagIN/ntpmAjCH8z2LNgY/Vw35nMU17IdZcX1zszbPrwgaxL/hMN/gLD8xTaXaRojDfriQfnB4W6E+EE=; Message-ID: <659107.28476.qm@web82606.mail.mud.yahoo.com> X-YMail-OSG: 5aRWupEVM1kflb4qet.4QxhLLmK2DD9a8WAEAUQZtJoAgRTGxo3LOaOTW6avYg2wCiU2EDIhge5goaqDtqec3IhpwhO4L9X9EJxSXurBK.AhMT4cwMHb8BkBm44.iNgOr2SspAcrti4wJjg5CHfA5TsBWYgMXNaKreGNyh7JQR9M5gMp5QOYIEAM5cXVZA2oqqhQjVp2BQReISJeGAOP7NBXVvntaSNzIWzXzzJChv61RP2WjfsP_NsqJem2FWZdDbpH7gJeEQEOzRx91VmQrrVHNaiWKCjWjPLYGgoGkO_PUoLcDAY6GoMiCcjY7QcowxTyuoC2P_5B.Y9i7ZPV58f6JxKqQhQpX2iPzL6qWc9WK6r14hNMekMGUosXKkjQ5kFWF228lN4zy99ep0ozZd1JWwVgL6mrw7bqoJ4- Received: from [67.120.11.67] by web82606.mail.mud.yahoo.com via HTTP; Fri, 16 Oct 2009 12:44:45 PDT X-Mailer: YahooMailRC/182.10 YahooMailWebService/0.7.347.3 References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <4AD894BE.30501@uci.edu> Date: Fri, 16 Oct 2009 12:44:45 -0700 (PDT) From: Charles Krinke To: Sean Hennessee , ogpx@ietf.org In-Reply-To: <4AD894BE.30501@uci.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1222441179-1255722285=:28476" Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 19:44:44 -0000 --0-1222441179-1255722285=:28476 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A+1 to Sean on this one. I think he accurately describes some of the o= ngoing notions happening now.=0A=0ACharles=0A=0A=0A________________________= ________=0AFrom: Sean Hennessee =0ATo: ogpx@ietf.org=0ASent: = Friday, October 16, 2009 8:43:58 AM=0ASubject: Re: [ogpx] Tourist use case= =0A=0AMeadhbh Hamrick wrote:=0A> On Fri, Oct 16, 2009 at 1:51 AM, Morgaine= =0A> wrote:=0A>> On Fri, Oct 16, 2009 at 9= :16 AM, Infinity Linden (Meadhbh Hamrick)=0A>> wro= te:=0A>> =0A>>> also. just a show of hands. who's planning on implementing = the tourist=0A>>> model?=0A>> Almost everybody who will operate virtual wor= lds, I assume --- that could be=0A>> hundreds of thousands of world operato= rs, if not millions, mostly small.=A0 We=0A>> certainly can't foretell!=A0 = And we can't get them to raise a show of hands=0A>> either. :-)=0A> =0A> yo= u mean you think they're all going to be implementing their own=0A> softwar= e? i think that's unrealistic. even with the http servers,=0A> which i thin= k we could agree is slightly less complicated than any=0A> virtual world pr= otocol would be, web site operators use one of a=0A> handful of implementat= ions: (Apache, IIS, WebSTAR?, ...)=0A=0AI think this is completely realisti= c. With the progress that OpenSim is making towards standalone (SL Like) gr= ids, there will very likely be services popping up all over the interweb pr= oviding standalone virtual worlds for free or at a very low cost, much like= services today provide blog spaces, photo spaces, and a host of other web = based services for free and for fee. I don't have to host my own Apache web= server just to have a tumblr.com blog or a flickr.com photo site. The blog= and photo site of the future will be SL like virtual worlds, (or perhaps m= ore accurately, "virtual homes").=0A=0A>> I doubt that it will be common to= operate walled gardens once everyone else=0A>> is allowing their users to = travel freely among the huge diversity of the=0A>> metaverse.=A0 It certain= ly seems like a recipe for failure to deny tourism to=0A>> one's residents = as a matter of policy, given that tourism is so popular in=0A>> the physica= l world today.=0A> =0A> well. the examples of large virtual worlds that exi= st today are, as=0A> you call them, walled gardens.=0A=0AThis is only becau= se the idea of treating your "virtual home" as its' own space that can have= "virtual tourists" come and visit is only now being implemented in OpenSim= with standalones and hypergrids. In the past the focus was more on creatin= g a system too much like SL in the sense that SL is one huge virtual world.= I would assume that "SL Like" implies the 3d experience that is SL and not= also the hugeness that is SL.=0A=0APeace,=0ASean=0A=0A> =0A>> However, thi= s is a policy issue of course, and therefore not something that=0A>> VWRAP = will dictate.=A0 We merely provide the mechanisms to allow tourism when=0A>= > desired, not mandate or deny it to any given world operator.=0A> =0A> i t= hink it _is_ definitely important. we've set dates for the=0A> publication = of standard documentations, and i think it's unrealistic=0A> to say that we= are going to develop a standard that is infinitely=0A> flexible. we will n= eed to focus on a small collection of deployment=0A> models. again, i have = no problem including models that _will_ actually=0A> be used. i'm just not = sure it behooves us to spend a fair amount of=0A> time ensuring our protoco= l flows work in deployment models that no one=0A> is currently planning on = deploying.=0A> =0A> there's very clearly interest from linden for the "seco= nd life" [1]=0A> deployment model; intel has show a clear interest in the "= cable beach"=0A> deployment model; OpenSim's UGAIM/Grid Mode and standalone= deployment=0A> models. i'm just curious who is going to be coding software= for the=0A> "tourist model."=0A> =0A> -cheers.=0A> -meadhbh/infinity=0A=0A= -- =0ASean Hennessee=0ACentral Computing Support=0AOffice of Information Te= chnology=0AUC Irvine=0A=0A=0A... . .- -. /=A0 .... . -. -. . ... ... . .=0A= _______________________________________________=0Aogpx mailing list=0Aogpx@= ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/ogpx=0A --0-1222441179-1255722285=:28476 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A
+1 to S= ean on this one. I think he accurately describes some of the ongoing notion= s happening now.
=0A
 
=0A
Charles
=0A
=0A
= =0AFrom: Sean Hennessee <= ;sean@uci.edu>
To: og= px@ietf.org
Sent: Friday= , October 16, 2009 8:43:58 AM
Subje= ct: Re: [ogpx] Tourist use case

Meadhbh Hamrick wr= ote:
> On Fri, Oct 16, 2009 at 1:51 AM, Morgaine
> <morgaine.dinova@googlemail.com> wrote:
>>= On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick)
>= > <infinity@lindenlab.com> wrote:
>>
>= ;>> also. just a show of hands. who's planning on implementing the to= urist
>>> model?
>> Almost everybody who will operate = virtual worlds, I assume --- that could be
>> hundreds of thousands of wo= rld operators, if not millions, mostly small.  We
>> certainl= y can't foretell!  And we can't get them to raise a show of hands
&= gt;> either. :-)
>
> you mean you think they're all going t= o be implementing their own
> software? i think that's unrealistic. e= ven with the http servers,
> which i think we could agree is slightly= less complicated than any
> virtual world protocol would be, web sit= e operators use one of a
> handful of implementations: (Apache, IIS, = WebSTAR?, ...)

I think this is completely realistic. With the progre= ss that OpenSim is making towards standalone (SL Like) grids, there will ve= ry likely be services popping up all over the interweb providing standalone= virtual worlds for free or at a very low cost, much like services today pr= ovide blog spaces, photo spaces, and a host of other web based services for free and for fee. I don't have to host my own Apache web serv= er just to have a tumblr.com= blog or a flickr.com photo site. The blog and photo site of the future will be SL like virtual= worlds, (or perhaps more accurately, "virtual homes").

>> I d= oubt that it will be common to operate walled gardens once everyone else>> is allowing their users to travel freely among the huge diversity= of the
>> metaverse.  It certainly seems like a recipe for f= ailure to deny tourism to
>> one's residents as a matter of policy= , given that tourism is so popular in
>> the physical world today.=
>
> well. the examples of large virtual worlds that exist tod= ay are, as
> you call them, walled gardens.

This is only becau= se the idea of treating your "virtual home" as its' own space that can have "virtual tourists" come and visit is only now being implemented in OpenSim= with standalones and hypergrids. In the past the focus was more on creatin= g a system too much like SL in the sense that SL is one huge virtual world.= I would assume that "SL Like" implies the 3d experience that is SL and not= also the hugeness that is SL.

Peace,
Sean

>
>&g= t; However, this is a policy issue of course, and therefore not something t= hat
>> VWRAP will dictate.  We merely provide the mechanisms = to allow tourism when
>> desired, not mandate or deny it to any gi= ven world operator.
>
> i think it _is_ definitely important. = we've set dates for the
> publication of standard documentations, and= i think it's unrealistic
> to say that we are going to develop a sta= ndard that is infinitely
> flexible. we will need to focus on a small= collection of deployment
> models. again, i have no problem including models that _will_ actually
> be used. i'm just not sure i= t behooves us to spend a fair amount of
> time ensuring our protocol = flows work in deployment models that no one
> is currently planning o= n deploying.
>
> there's very clearly interest from linden for= the "second life" [1]
> deployment model; intel has show a clear int= erest in the "cable beach"
> deployment model; OpenSim's UGAIM/Grid M= ode and standalone deployment
> models. i'm just curious who is going= to be coding software for the
> "tourist model."
>
> -c= heers.
> -meadhbh/infinity

--
Sean Hennessee
Central Co= mputing Support
Office of Information Technology
UC Irvine

... . .- -. /  .... . -. -. . ... ... . .
________________________= _______________________
ogpx mailing list
ogpx@ietf.org
https:= //www.ietf.org/mailman/listinfo/ogpx
--0-1222441179-1255722285=:28476-- From vaughn.deluca@gmail.com Fri Oct 16 15:46:52 2009 Return-Path: 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 8324C3A68CD for ; Fri, 16 Oct 2009 15:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_OEM_OBFU=1] 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 kf0EwgUy3SBD for ; Fri, 16 Oct 2009 15:46:51 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 3D6373A6949 for ; Fri, 16 Oct 2009 15:46:51 -0700 (PDT) Received: by fxm18 with SMTP id 18so2995393fxm.37 for ; Fri, 16 Oct 2009 15:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6eY4uO2bLqs2BLDYstl8TkDTceGwvseWzqDVxa9X00o=; b=ayW6WT+GY2AZCQCc2ECdJ7t/NvQLZoOsvqVyw0NPmy0wvhCcn0ZFk//LP8LpJVw/kU Qsv0yCZswAyfrj8LFpeuw19T3DKIVLJNBtN5ad/FmB8PmYZj/Ydsl4nvaOEVzf+ENo71 g/q2HC46MxAlt6xL8EB6mGn0fJ8EirnFG1cC8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nezp63c8E85qmv6gPQrF08GFOhuXOrBlVk2V6hTpz4AB5GNvkCP6db8wc5MnFP5+nr oWQoexFd5KHXU+oRWKC3FBO3j28gxijceKauMB5wSoU1IzRUN1m4OHodFoZZGfEKlyW+ Vvzkp2pWRTpWr9X+uGICaJ0nFXQP9GmQxt1sg= MIME-Version: 1.0 Received: by 10.204.175.80 with SMTP id w16mr1796666bkz.207.1255733212292; Fri, 16 Oct 2009 15:46:52 -0700 (PDT) In-Reply-To: References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <4AD894BE.30501@uci.edu> Date: Sat, 17 Oct 2009 00:46:52 +0200 Message-ID: <9b8a8de40910161546h9e54dcah59cb423a0ac096af@mail.gmail.com> From: Vaughn Deluca To: Joshua Bell Content-Type: multipart/alternative; boundary=00032555b93a0d2a5f0476152c95 Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 22:46:52 -0000 --00032555b93a0d2a5f0476152c95 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 16, 2009 at 7:03 PM, Joshua Bell wrote: > On Fri, Oct 16, 2009 at 8:43 AM, Sean Hennessee wrote: > >> Meadhbh Hamrick wrote: >> >>> On Fri, Oct 16, 2009 at 1:51 AM, Morgaine >>> wrote: >>> >>>> On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick) >>>> wrote: >>>> >>>> also. just a show of hands. who's planning on implementing the tourist >>>>> model? >>>> >>>> [...] > There are two distinct definitions in extremely common use on the 'net: > > (1) to implement: write the code for something > (2) to implement: configure and deploy code for something > > My interpretation of this thread is that Infinity is using definition #1, > Sean and Morgaine are using definition #2. Infinity is asking specifically: > "who will write the code that adds support for the protocol to a piece of > software?" not "who will make use of software that implements the protocol?" > *ahum* I was most definitely using definition #2. Yet, i *can* code, and given the importance of this aspect, i am certainly willing to assist in making this use case happen. However, i am not a professional programer, but just a scientist, coding my own analysis softeware. So i am likely to need a bit of help from some friends :) On the other hand, i am convinced that a proper implementation of the SL use case (this time in the sense of definition #1) will generate about all the code we need for the tourist case. The difference between the SL model and the tourist model is largely at the policy level. But when we get down to the specs, that will become clear soon enough. Regarding the coding, i think Agent Domain code was written this summer. Is that available somewhere? i would like to have a look at that, to get a better feel for the size of the problem. -Vaughn > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00032555b93a0d2a5f0476152c95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 16, 2009 at 7:03 PM, Joshua Bell= <josh@lindenlab.com> wrote:
On Fri, Oct 16, 2009 at 8:43 AM, Sean Henne= ssee <sean@uci.edu> wrote:
Meadhbh Hamrick wrote:
On Fri, Oct 16, 2009 at 1:51 AM, Morgaine
<mor= gaine.dinova@googlemail.com> wrote:
On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick)
<infinity@li= ndenlab.com> wrote:

also. just a show of hands. who's planning on implementing the tourist<= br> model?
=A0[...]
=A0
There are two distinct definitions in extremely common use on the 'net:=

(1) to implement: write the code for something
(2) to implement: configure and deploy code for something

My interpr= etation of this thread is that Infinity is using definition #1, Sean and Mo= rgaine are using definition #2. Infinity is asking specifically: "who = will write the code that adds support for the protocol to a piece of softwa= re?" not "who will make use of software that implements the proto= col?"

*ahum* I was most definitely=A0using =A0de= finition #2. Yet, i *can* code, and given the importance of this aspect, i = am certainly willing to assist in making this use case happen. However, i a= m not a professional programer, but just a scientist, coding my own analysi= s softeware. So i am likely to need a bit of help from some friends :)

On the other hand, i am convinced that a proper impleme= ntation of the SL use case (this time in the sense of definition =A0#1) wil= l generate about =A0all the code we need for the tourist case. The differen= ce between the SL model and the tourist model is largely at the policy leve= l. =A0But when we get down to the specs, that will become clear soon enough= .

Regarding the coding, i think Agent Domain code was wri= tten this summer. Is that available somewhere? i would like to have a look = at that, to get a better feel for the size of the problem.=A0

-Vaughn
=A0
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00032555b93a0d2a5f0476152c95-- From infinity@lindenlab.com Fri Oct 16 15:47:29 2009 Return-Path: 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 C9BAE3A6905 for ; Fri, 16 Oct 2009 15:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ZiGhfusyF9WY for ; Fri, 16 Oct 2009 15:47:28 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 0709E3A67AA for ; Fri, 16 Oct 2009 15:47:27 -0700 (PDT) Received: by fxm18 with SMTP id 18so2995847fxm.37 for ; Fri, 16 Oct 2009 15:47:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.183.22 with SMTP id s22mr204567hbg.6.1255733248102; Fri, 16 Oct 2009 15:47:28 -0700 (PDT) In-Reply-To: <9b8a8de40910160729s5dca2d8u7963b0b0fbfc9975@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <9b8a8de40910160729s5dca2d8u7963b0b0fbfc9975@mail.gmail.com> From: "Infinity Linden (Meadhbh Hamrick)" Date: Fri, 16 Oct 2009 15:47:08 -0700 Message-ID: <3a880e2c0910161547n523115b3qc6025d9ef97c54d2@mail.gmail.com> To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Meadhbh Hamrick , ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 22:47:29 -0000 okay. i think we're heading towards nomenclature communication fail. what you describe below is part of what i call the "Second Life" deployment pattern. what i'm calling the tourist pattern is that "trust is managed by the client; services may be deployed in different domains or all in the same domain; the client decides which URLs to use for each service it wants to use for service establishment." maybe we should be asking, what is the aspect of the tourist model that differentiates it from the others. based on what i _think_ i hear people saying (david's deployment and layering doc aside,) it sounds to me that the fundamental aspect of the tourist model is the ability for the client application to tell the agent domain to rez in a region at an arbitrary URI and to use credentials given to it by the client at the time the user requests placement in a region. this is contrasted to what i'm calling the "second life model" where the user establishes a credential for use exclusively between the client and the agent domain. and the agent domain and different region domains establish some authentication or authorization regime between themselves that is distinct from the client <-> agent domain authenticator. when the user wants their avatar moved into a particular region, the client provides the URI or an arbitrary map reference to the agent domain. the agent domain then resolves the map reference to a service URI if one wasn't provided by the client. assuming that the destination URI resolves to a host inside a region domain with whom the agent domain has a trust relationship, it begins the protocol to place the user's avatar in that region. the destination region authenticates the agent domain and not the user's avatar before placing it in the region. what i'm calling the "cable beach model" is that the client tells the agent domain where it will find it's preferred asset server. this is different from the "second life model" where the agent domain provides caps for inventory access after the client has authenticated itself. i chatted with jhurliman about this, and he seems big on OAuth to be the carrier of authorization information. the essential difference here is that an independent authentication to the asset service is required, but once that's done, you can use OAuth to give asset access to the AD, the RD or the client. in fact, you could probably just have the agent domain authenticate OAuth tokens from the domain containing the asset service. but the essential notion here is that multiple region domains and multiple agent domains could use the services of the same external asset service. and the standalone mode is basically everything is on one box. discussion? -cheers -meadhbh/infinity -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden On Fri, Oct 16, 2009 at 07:29, Vaughn Deluca wrot= e: > > > On Fri, Oct 16, 2009 at 3:44 PM, Meadhbh Hamrick > wrote: >> >> but didn't we say that we were going to focus on "second life-like" >> worlds in this WG? > > I strongly believe the basic =A0mode *is* "second life like", even much m= ore > so than some of the other use cases considered in Davids layering draft. > Also i do not think this needs to delay us much *at all*, since the basic= s > idea has =A0always been part of the deployment pattern considered. Look a= t the > description of "adding a Organization domain" on the wiki: > http://wiki.secondlife.com/wiki/Multiple_Domains#Adding_a_Organization_Do= main. > The figure legend states: >> [...] The blue dotted line means that an agent can be linked >> to another agent (e.g. the more public agent from the SL Agent domain >> (=3D=3D Linden Lab's grid)). This can mean the following: >> >> The company agent can access the inventory from the >> company agent domain and from the SL Agent Domain > This is in principle the tourist use case i have been describing! > However, the wiki is not clear about the way to actually implement the > restrictions: >>So what we need here is a list of what should be restrictable >>and a means of how to define it. > My suggestion is to define the restrictions at the level of the services, > completely analogous to the discussion we had about the Region Domain i.e= . > All policy is local -but the regions can use a global policy derived from > the domain if they wish to do so). > I therefore argue strongly for a design were Agent service and Asset serv= ice > are both expressing policy, and both exposing an interface to the world. > In this way it becomes fairly easy to configure any type of domain > behaviour. > I really see very few problems here, but maybe i am naive =A0:) > -Vaughn > > >> >> isn't that why it was formed? shouldn't the tourist >> model be an effort of the MMOX group? i thought that was the reason we >> kept the MMOX mailing list up, so work could continue on that type of >> virtual world. >> >> -meadhbh/infinity >> >> >> On Fri, Oct 16, 2009 at 5:00 AM, Morgaine >> wrote: >> > Vaughn, >> > >> > You've correctly represented my MMOX post, thanks!=A0 ( >> > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html ) >> > >> > I must stress, as you did yourself, that the "Free Worlds Tourist" use >> > case >> > which I described there in MMOX is different=A0 to the simpler "touris= t >> > use >> > case" which we have been discussing here.=A0 It's great that you're >> > shining >> > some light into this corner.=A0 Hopefully this will allow us to affix >> > labels >> > to the various cases to keep our discussions simple yet clear. >> > >> > Before addressing your actual point, I should first state that I >> > consider it >> > unfortunate that the "Free Worlds Tourist" use case is not considered = an >> > integral part of VWRAP requirements --- this is a practical conclusion >> > on my >> > part.=A0 On the basis of our discussions so far, I think it would be t= oo >> > much >> > to expect that a mode of operation offering such a high degree of >> > freedom of >> > travel and of avatar appearance would achieve rough consensus in the >> > group, >> > given that its considerable distance from Second Life policies would >> > almost >> > certainly lead to intense opposition.=A0 This is not a battle I wish t= o >> > fight. >> > >> > As a practical matter then, "Free Worlds Tourist" as defined above is >> > not a >> > use case that I am pushing in VWRAP at this time, despite it being >> > entirely >> > compatible with the SL/Opensim model and hence deserving inclusion.=A0= I'm >> > simply going to express regret that it is likely to be a bridge too fa= r >> > on >> > political grounds and leave it at that.=A0 I would wish it were otherw= ise. >> > >> > With that disclaimer, I'll answer your point about our more constraine= d >> > "tourist use case" (which perhaps needs a better name), this being a >> > much >> > easier target but still a very useful one.=A0 I will however answer it= in >> > the >> > immediately following post, because I don't want to get this confused >> > with >> > the "Free Worlds Tourist" case that I described in MMOX. >> > >> > >> > Morgaine. >> > >> > >> > >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca >> > wrote: >> >> >> >> The "tourist use case" has been brought up several times, but the >> >> concept >> >> is not always used in the same way, and needs to be more precisely >> >> defined. >> >> Morgaines original definition of the "Free Worlds Tourist use case"= =A0in >> >> http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html >> >> mentions two characteristics: >> >> 1. Travel requires no prior arrangement. >> >> 2. Your avatar is defined by you, not by the target worlds, and it >> >> appears >> >> in those worlds with no prior arrangement. >> >> Point 1 is only dependent the policies of the users AD as well as tha= t >> >> of >> >> the destination region. It is not dependent on the protocol, so in >> >> principle >> >> solved. >> >> The second point is actually extending the SL use case beyond what is >> >> in >> >> my view needed for a basic tourist model (and that is why the post wa= s >> >> in >> >> the mmox list). =A0In my view =A0a basic tourist use case has two mai= n >> >> characteristics: >> >> 1. =A0Travel requires no prior arrangement. >> >> =A0=A0 =A0 =A0 =A02. =A0Agent domains can use external asset services >> >> Point 2 requires that assets services expose an interface (in the >> >> current >> >> ogp description of the AD that is not the case). >> >> Note that this models does *not* assumes that all assets in a service= s >> >> should be useable by the agent in all domains, but only that an >> >> interface is >> >> available so an asset service in one domain can be contacted by anoth= er >> >> AD. >> >> I think exposing the asset service interface directly is essential fo= r >> >> meaningful interop. =A0I think it would benefit the discussion if som= e >> >> diagrams were added to >> >> http://wiki.secondlife.com/wiki/Structural_Design >> >> and/or to the VWRAP wiki to document this possibility. >> >> -Vaughn >> >> _______________________________________________ >> >> ogpx mailing list >> >> ogpx@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ogpx >> >> >> > >> > >> > _______________________________________________ >> > ogpx mailing list >> > ogpx@ietf.org >> > https://www.ietf.org/mailman/listinfo/ogpx >> > >> > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From lenglish5@cox.net Fri Oct 16 16:38:24 2009 Return-Path: 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 554503A69B0 for ; Fri, 16 Oct 2009 16:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 qtJIRgiJ8yUs for ; Fri, 16 Oct 2009 16:38:23 -0700 (PDT) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id 8CFE03A6405 for ; Fri, 16 Oct 2009 16:38:23 -0700 (PDT) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao106.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20091016233827.YVJR21192.fed1rmmtao106.cox.net@fed1rmimpo02.cox.net>; Fri, 16 Oct 2009 19:38:27 -0400 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo02.cox.net with bizsmtp id tbeT1c00S2l1Ksg04beU4x; Fri, 16 Oct 2009 19:38:28 -0400 X-VR-Score: -100.00 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=LjVozOZdUFbmcqBJa84A:9 a=qNCyov4X387CfwzB1Yd5sLX5WiYA:4 X-CM-Score: 0.00 Message-ID: <4AD903F3.6080809@cox.net> Date: Fri, 16 Oct 2009 16:38:27 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Meadhbh Hamrick References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 23:38:24 -0000 Meadhbh Hamrick wrote: > but didn't we say that we were going to focus on "second life-like" > worlds in this WG? isn't that why it was formed? shouldn't the tourist > model be an effort of the MMOX group? i thought that was the reason we > kept the MMOX mailing list up, so work could continue on that type of > virtual world. > > -meadhbh/infinity > It seems to me that the MOST touristy mode we will ever see is the free-for-all from the original OGP test where simple TP and naught else was supported. Will all worlds be willing to support that one? Obviously not (e.g firewalled corporate site), but I think many will, including LL on the PG section of its main grid. Lawson From infinity@lindenlab.com Fri Oct 16 16:39:42 2009 Return-Path: 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 AF8BF3A69BF for ; Fri, 16 Oct 2009 16:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_OEM_OBFU=1] 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 xbaZfubBfRfH for ; Fri, 16 Oct 2009 16:39:42 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 7CCF93A69BD for ; Fri, 16 Oct 2009 16:39:41 -0700 (PDT) Received: by fxm18 with SMTP id 18so3029484fxm.37 for ; Fri, 16 Oct 2009 16:39:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.144.137 with SMTP id o9mr186943hba.199.1255736381123; Fri, 16 Oct 2009 16:39:41 -0700 (PDT) In-Reply-To: <9b8a8de40910161546h9e54dcah59cb423a0ac096af@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <4AD894BE.30501@uci.edu> <9b8a8de40910161546h9e54dcah59cb423a0ac096af@mail.gmail.com> From: "Infinity Linden (Meadhbh Hamrick)" Date: Fri, 16 Oct 2009 16:39:21 -0700 Message-ID: <3a880e2c0910161639x4d5bf462u47f0db4c8736bf93@mail.gmail.com> To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 23:39:42 -0000 On Fri, Oct 16, 2009 at 15:46, Vaughn Deluca wrot= e: > > On Fri, Oct 16, 2009 at 7:03 PM, Joshua Bell wrote: >> >> On Fri, Oct 16, 2009 at 8:43 AM, Sean Hennessee wrote: >>> >>> Meadhbh Hamrick wrote: >>>> >>>> On Fri, Oct 16, 2009 at 1:51 AM, Morgaine >>>> wrote: >>>>> >>>>> On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick) >>>>> wrote: >>>>> >>>>>> also. just a show of hands. who's planning on implementing the touri= st >>>>>> model? > > =A0[...] > >> >> There are two distinct definitions in extremely common use on the 'net: >> >> (1) to implement: write the code for something >> (2) to implement: configure and deploy code for something >> >> My interpretation of this thread is that Infinity is using definition #1= , >> Sean and Morgaine are using definition #2. Infinity is asking specifical= ly: >> "who will write the code that adds support for the protocol to a piece o= f >> software?" not "who will make use of software that implements the protoc= ol?" > > *ahum* I was most definitely=A0using =A0definition #2. Yet, i *can* code,= and > given the importance of this aspect, i am certainly willing to assist in > making this use case happen. However, i am not a professional programer, = but > just a scientist, coding my own analysis softeware. So i am likely to nee= d a > bit of help from some friends :) okay. my bad. i was just kinda shocked by what i perceived as an assertion by morgaine that there was going to be a 1:1 relation between developers and users. i'll let her make that case if that's what she really believes, but will assume she interpreted my question to be "who's interested in deploying services that implement protocol transactions in accord with the tourist model?" rather than "who's interested in implementing the tourist model in code?" as it was intended to mean. i think one of the most important outcomes of this process will be an open standard that anyone can implement without royalty payments, including FLOSS developers. an operator like linden cannot be all things to all people and implement every feature. but maybe in the future we'll be able to point people to OpenSim and say "we can't implement the feature you want, but maybe you can implement it yourself using this nice codebase the community has put together for you." and then, "hey look over there! there's an archipelago of tourist sites or here's our more locked down world. maybe it makes sense for you to deploy here." i think if we can do that, we will have won. (and not just SL or OpenSim or realXtend or whomever, but all of us.) > On the other hand, i am convinced that a proper implementation of the SL = use > case (this time in the sense of definition =A0#1) will generate about =A0= all the > code we need for the tourist case. The difference between the SL model an= d > the tourist model is largely at the policy level. =A0But when we get down= to > the specs, that will become clear soon enough. > Regarding the coding, i think Agent Domain code was written this summer. = Is > that available somewhere? i would like to have a look at that, to get a > better feel for the size of the problem. > -Vaughn > >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From vaughn.deluca@gmail.com Sat Oct 17 16:10:25 2009 Return-Path: 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 DF19B3A689B for ; Sat, 17 Oct 2009 16:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 l5c84wdHY8kJ for ; Sat, 17 Oct 2009 16:10:25 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id B24ED3A6898 for ; Sat, 17 Oct 2009 16:10:24 -0700 (PDT) Received: by fxm18 with SMTP id 18so3729781fxm.37 for ; Sat, 17 Oct 2009 16:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sJcgrZlQIvIu36Ja7uFI3grJCS8ac81vrFGsNHjIJ4s=; b=xE6Bah2GKAnOKDyht5DeUVOw8Z7tzoQDqebq5Hp9H01Js0Os+8sog9Ps4wBFg4q0bu e263VpEsyvBIJMWwBBdmShvQgWPFjLFpRd7BpZvT10Xc3WWzFdN5pS61YbxeJoM6uvCb YQ00AXmJGYSz+nqpkBSQ3/CP/1aYj7RKgbgnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X1+XGT6HWQXaacBrybMY+U6BWpduvmo68h/ZRYvWsMxvqcUwOfz9H8JfFfOA98AdQh EegOMMbqajACi3pXzie/hYOgOviMr3aeA0ta+N+veyysNvtakESzjTQna7HI0ivbFKCK BX9Ezwyet/A+2gr/ambSAaF5aPzIfWrVaffOY= MIME-Version: 1.0 Received: by 10.204.155.79 with SMTP id r15mr3124045bkw.142.1255821025484; Sat, 17 Oct 2009 16:10:25 -0700 (PDT) In-Reply-To: <4AD903F3.6080809@cox.net> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <4AD903F3.6080809@cox.net> Date: Sun, 18 Oct 2009 01:10:25 +0200 Message-ID: <9b8a8de40910171610m6e415635m85bf715f86f35c4@mail.gmail.com> From: Vaughn Deluca To: lenglish5@cox.net Content-Type: multipart/alternative; boundary=0015175d07d2201ed00476299e3a Cc: Meadhbh Hamrick , ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 23:10:26 -0000 --0015175d07d2201ed00476299e3a Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 17, 2009 at 1:38 AM, Lawson English wrote: > Meadhbh Hamrick wrote: > >> but didn't we say that we were going to focus on "second life-like" >> worlds in this WG? isn't that why it was formed? shouldn't the tourist >> model be an effort of the MMOX group? i thought that was the reason we >> kept the MMOX mailing list up, so work could continue on that type of >> virtual world. >> >> -meadhbh/infinity >> >> > > It seems to me that the MOST touristy mode we will ever see is the > free-for-all from the original OGP test where > simple TP and naught else was supported. > I find that a deeply depressing thought. I would *really* hope that at least transfer of free to copy assets will also be possible. > > Will all worlds be willing to support that one? Obviously not (e.g > firewalled corporate site), but I think many will, including LL on the PG > section of its main grid. > > > Lawson > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0015175d07d2201ed00476299e3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Oct 17, 2009 at 1:38 AM, Lawson = English <lenglish= 5@cox.net> wrote:
Meadhbh Hamrick wrote:
but didn't we say that we were going to focus on "second life-like= "
worlds in this WG? isn't that why it was formed? shouldn't the tour= ist
model be an effort of the MMOX group? i thought that was the reason we
kept the MMOX mailing list up, so work could continue on that type of
virtual world.

-meadhbh/infinity
=A0

It seems to me that the MOST touristy mode we will ever see is the free-for= -all from the original OGP test where
simple TP and naught else was supported.

I find that a deeply depressing thought. =A0I would *really* hope that at= least =A0transfer of free to copy assets will also be possible.=A0

Will all worlds be willing to support that one? Obviously not (e.g firewall= ed corporate site), but I think many will, including LL on the PG
section of its main grid.


Lawson

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--0015175d07d2201ed00476299e3a-- From vaughn.deluca@gmail.com Sat Oct 17 16:12:06 2009 Return-Path: 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 A3AD73A6898 for ; Sat, 17 Oct 2009 16:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 KJKP17sSm2RT for ; Sat, 17 Oct 2009 16:12:04 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id B7C903A687C for ; Sat, 17 Oct 2009 16:12:03 -0700 (PDT) Received: by fxm18 with SMTP id 18so3730462fxm.37 for ; Sat, 17 Oct 2009 16:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=+W7de0igVlm3isfIVxG4yxVqSbd2lyCx6PxQ0uot4sA=; b=SpwEusU7w6+SAZEbxdRXOhKBom7OMn4PawZkGiKy9lKqrq/G49xzr59mb4wuYNWWko 8DIq7iy7K8wXVOWC+g4yGhUVifKDxufJt1K966XdPNn/9UGPu+7iWwSOMcTLvL8fiF/l wPePV7U/V+4QV5rh3HpyRgIfXnNQ2nXz/QevI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=lXjE79ELlEhVf85phntawj64V5TpednHNYg0Kv+Fiwq5U6plXZU6pFgOqc+hgENPkh kHRVhDEG+fcxFyeVsi642CU2pcPd5PGcWOPveZJyWWxUytuZFy4Dm0bEzByg+1HoA1w9 ZDaXY2FjkdydSsN8y0jsAbkbj9y984T92gun8= MIME-Version: 1.0 Received: by 10.204.20.82 with SMTP id e18mr2957105bkb.168.1255821122336; Sat, 17 Oct 2009 16:12:02 -0700 (PDT) In-Reply-To: <9b8a8de40910171559g4b728486w9cfde1f3fc4b319c@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <9b8a8de40910160729s5dca2d8u7963b0b0fbfc9975@mail.gmail.com> <3a880e2c0910161547n523115b3qc6025d9ef97c54d2@mail.gmail.com> <9b8a8de40910171559g4b728486w9cfde1f3fc4b319c@mail.gmail.com> Date: Sun, 18 Oct 2009 01:12:02 +0200 Message-ID: <9b8a8de40910171612r4365d622o89299a15297950c@mail.gmail.com> From: Vaughn Deluca To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000325559f56e5f933047629a300 Subject: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 23:12:06 -0000 --000325559f56e5f933047629a300 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 17, 2009 at 12:47 AM, Infinity Linden (Meadhbh Hamrick) < infinity@lindenlab.com> wrote: > okay. i think we're heading towards nomenclature communication fail. > Wrong, we were right in the middle of it! > what you describe below is part of what i call the "Second Life" > deployment pattern. what i'm calling the tourist pattern is that > "trust is managed by the client; services may be deployed in different > domains or all in the same domain; the client decides which URLs to > use for each service it wants to use for service establishment." > In what I called the tourist pattern trust is managed by the services in the agent domain (or maybe OAuth); services may be deployed in different domains or all in the same domain; The agent service keeps track of all asset servers the agent uses; The agent service policy determines which URLs can actually be used for TP, Asset servers policies determines what assets can actually be rezzed in a particular destination region. Agent domain is just as Region domain an administrative term, and its main purpose is that of a policy server for domain wide policy. maybe we should be asking, what is the aspect of the tourist model > that differentiates it from the others. based on what i _think_ i hear > people saying (david's deployment and layering doc aside,) it sounds > to me that the fundamental aspect of the tourist model is the ability > for the client application to tell the agent domain to rez in a region > at an arbitrary URI and to use credentials given to it by the client > at the time the user requests placement in a region. > Hmm, the credentials could be managed by the agent service after login of the user, but might come from a third party service. Rezzing assets is possible if the asset server is willing to let go of that particular asset and sent it to the destination region. The key feature of this model is the distributed way assets are managed, and the fact that not the TP is the key event (in most cases there is no reason to prevent a TP of a ruthed tourist avatar) but the transfer of assets based on asset server policy (and ultimately on characteristics of the asset, i.e. its license) I need to think about the actual control flows, look at cable beach in more detail and study the available documentation more. Things turn out to be more complicated than I envisioned. -Vaughn this is contrasted to what i'm calling the "second life model" where > the user establishes a credential for use exclusively between the > client and the agent domain. and the agent domain and different region > domains establish some authentication or authorization regime between > themselves that is distinct from the client <-> agent domain > authenticator. when the user wants their avatar moved into a > particular region, the client provides the URI or an arbitrary map > reference to the agent domain. the agent domain then resolves the map > reference to a service URI if one wasn't provided by the client. > assuming that the destination URI resolves to a host inside a region > domain with whom the agent domain has a trust relationship, it begins > the protocol to place the user's avatar in that region. the > destination region authenticates the agent domain and not the user's > avatar before placing it in the region. > > what i'm calling the "cable beach model" is that the client tells the > agent domain where it will find it's preferred asset server. this is > different from the "second life model" where the agent domain provides > caps for inventory access after the client has authenticated itself. i > chatted with jhurliman about this, and he seems big on OAuth to be the > carrier of authorization information. the essential difference here is > that an independent authentication to the asset service is required, > but once that's done, you can use OAuth to give asset access to the > AD, the RD or the client. in fact, you could probably just have the > agent domain authenticate OAuth tokens from the domain containing the > asset service. but the essential notion here is that multiple region > domains and multiple agent domains could use the services of the same > external asset service. > > and the standalone mode is basically everything is on one box. > > discussion? > > -cheers > -meadhbh/infinity > > > > -- > infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" > http://wiki.secondlife.com/wiki/User:Infinity_Linden > > > > On Fri, Oct 16, 2009 at 07:29, Vaughn Deluca > wrote: > > > > > > On Fri, Oct 16, 2009 at 3:44 PM, Meadhbh Hamrick < > meadhbh.siobhan@gmail.com> > > wrote: > >> > >> but didn't we say that we were going to focus on "second life-like" > >> worlds in this WG? > > > > I strongly believe the basic mode *is* "second life like", even much > more > > so than some of the other use cases considered in Davids layering draft. > > Also i do not think this needs to delay us much *at all*, since the > basics > > idea has always been part of the deployment pattern considered. Look at > the > > description of "adding a Organization domain" on the wiki: > > > http://wiki.secondlife.com/wiki/Multiple_Domains#Adding_a_Organization_Domain > . > > The figure legend states: > >> [...] The blue dotted line means that an agent can be linked > >> to another agent (e.g. the more public agent from the SL Agent domain > >> (== Linden Lab's grid)). This can mean the following: > >> > >> The company agent can access the inventory from the > >> company agent domain and from the SL Agent Domain > > This is in principle the tourist use case i have been describing! > > However, the wiki is not clear about the way to actually implement the > > restrictions: > >>So what we need here is a list of what should be restrictable > >>and a means of how to define it. > > My suggestion is to define the restrictions at the level of the services, > > completely analogous to the discussion we had about the Region Domain > i.e. > > All policy is local -but the regions can use a global policy derived from > > the domain if they wish to do so). > > I therefore argue strongly for a design were Agent service and Asset > service > > are both expressing policy, and both exposing an interface to the world. > > In this way it becomes fairly easy to configure any type of domain > > behaviour. > > I really see very few problems here, but maybe i am naive :) > > -Vaughn > > > > > >> > >> isn't that why it was formed? shouldn't the tourist > >> model be an effort of the MMOX group? i thought that was the reason we > >> kept the MMOX mailing list up, so work could continue on that type of > >> virtual world. > >> > >> -meadhbh/infinity > >> > >> > >> On Fri, Oct 16, 2009 at 5:00 AM, Morgaine > >> wrote: > >> > Vaughn, > >> > > >> > You've correctly represented my MMOX post, thanks! ( > >> > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html ) > >> > > >> > I must stress, as you did yourself, that the "Free Worlds Tourist" use > >> > case > >> > which I described there in MMOX is different to the simpler "tourist > >> > use > >> > case" which we have been discussing here. It's great that you're > >> > shining > >> > some light into this corner. Hopefully this will allow us to affix > >> > labels > >> > to the various cases to keep our discussions simple yet clear. > >> > > >> > Before addressing your actual point, I should first state that I > >> > consider it > >> > unfortunate that the "Free Worlds Tourist" use case is not considered > an > >> > integral part of VWRAP requirements --- this is a practical conclusion > >> > on my > >> > part. On the basis of our discussions so far, I think it would be too > >> > much > >> > to expect that a mode of operation offering such a high degree of > >> > freedom of > >> > travel and of avatar appearance would achieve rough consensus in the > >> > group, > >> > given that its considerable distance from Second Life policies would > >> > almost > >> > certainly lead to intense opposition. This is not a battle I wish to > >> > fight. > >> > > >> > As a practical matter then, "Free Worlds Tourist" as defined above is > >> > not a > >> > use case that I am pushing in VWRAP at this time, despite it being > >> > entirely > >> > compatible with the SL/Opensim model and hence deserving inclusion. > I'm > >> > simply going to express regret that it is likely to be a bridge too > far > >> > on > >> > political grounds and leave it at that. I would wish it were > otherwise. > >> > > >> > With that disclaimer, I'll answer your point about our more > constrained > >> > "tourist use case" (which perhaps needs a better name), this being a > >> > much > >> > easier target but still a very useful one. I will however answer it > in > >> > the > >> > immediately following post, because I don't want to get this confused > >> > with > >> > the "Free Worlds Tourist" case that I described in MMOX. > >> > > >> > > >> > Morgaine. > >> > > >> > > >> > > >> > > >> > > >> > ===================================== > >> > > >> > On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca < > vaughn.deluca@gmail.com> > >> > wrote: > >> >> > >> >> The "tourist use case" has been brought up several times, but the > >> >> concept > >> >> is not always used in the same way, and needs to be more precisely > >> >> defined. > >> >> Morgaines original definition of the "Free Worlds Tourist use > case" in > >> >> http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html > >> >> mentions two characteristics: > >> >> 1. Travel requires no prior arrangement. > >> >> 2. Your avatar is defined by you, not by the target worlds, and it > >> >> appears > >> >> in those worlds with no prior arrangement. > >> >> Point 1 is only dependent the policies of the users AD as well as > that > >> >> of > >> >> the destination region. It is not dependent on the protocol, so in > >> >> principle > >> >> solved. > >> >> The second point is actually extending the SL use case beyond what is > >> >> in > >> >> my view needed for a basic tourist model (and that is why the post > was > >> >> in > >> >> the mmox list). In my view a basic tourist use case has two main > >> >> characteristics: > >> >> 1. Travel requires no prior arrangement. > >> >> 2. Agent domains can use external asset services > >> >> Point 2 requires that assets services expose an interface (in the > >> >> current > >> >> ogp description of the AD that is not the case). > >> >> Note that this models does *not* assumes that all assets in a > services > >> >> should be useable by the agent in all domains, but only that an > >> >> interface is > >> >> available so an asset service in one domain can be contacted by > another > >> >> AD. > >> >> I think exposing the asset service interface directly is essential > for > >> >> meaningful interop. I think it would benefit the discussion if some > >> >> diagrams were added to > >> >> http://wiki.secondlife.com/wiki/Structural_Design > >> >> and/or to the VWRAP wiki to document this possibility. > >> >> -Vaughn > >> >> _______________________________________________ > >> >> ogpx mailing list > >> >> ogpx@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/ogpx > >> >> > >> > > >> > > >> > _______________________________________________ > >> > ogpx mailing list > >> > ogpx@ietf.org > >> > https://www.ietf.org/mailman/listinfo/ogpx > >> > > >> > > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --000325559f56e5f933047629a300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sat, Oct 17, 2009 at 12:47 AM, Infinity Linden (Meadhbh Hamrick) <infinity@lindenlab.com> wrote:
okay. i think we're heading towards nomenclature communication fail.

Wrong, we were right in the mi= ddle of it!=A0
=A0
what you describe below is part of what i call the "Second Life"<= br> deployment pattern. what i'm calling the tourist pattern is that
"trust is managed by the client; services may be deployed in different=
domains or all in the same domain; the client decides which URLs to
use for each service it wants to use for service establishment."

In what I called the tourist patt= ern trust is managed by the services in the agent domain (or maybe OAuth); = services may be deployed in different domains or all in the same domain; Th= e agent service keeps track of all asset servers the agent uses; The agent = service policy =A0determines which URLs can actually be used for TP, Asset = servers policies determines what assets can actually be rezzed in a particu= lar destination region.=A0Agent domain is just as =A0Region domain an admin= istrative term, and its main purpose is that of a =A0policy server for doma= in wide policy.

maybe we should be asking, what is the aspect of the tourist model
that differentiates it from the others. based on what i _think_ i hear
people saying (david's deployment and layering doc aside,) it sounds to me that the fundamental aspect of the tourist model is the ability
for the client application to tell the agent domain to rez in a region
at an arbitrary URI and to use credentials given to it by the client
at the time the user requests placement in a region.
<= br>
Hmm, the credentials could be managed by the agent serv= ice after login of the user, but might come from a third party service.
Rezzing assets is possible if the asset server is willing to let go of= that particular asset and sent it to the destination region. The key featu= re of this model is the distributed way assets are managed, and the fact th= at not the TP is the key event (in most cases there is no reason to prevent= a TP of a ruthed tourist avatar) but the transfer of assets based on asset= server policy (and ultimately on characteristics of the asset, i.e. its li= cense)=A0

I need to think about the actual =A0control flows, look= at cable beach in more detail and study the available documentation more. = =A0Things turn out to be more complicated than I envisioned.

-Vaughn

this is contrasted to what i'm calling the "second life model"= ; where
the user establishes a credential for use exclusively between the
client and the agent domain. and the agent domain and different region
domains establish some authentication or authorization regime between
themselves that is distinct from the client <-> agent domain
authenticator. when the user wants their avatar moved into a
particular region, the client provides the URI or an arbitrary map
reference to the agent domain. the agent domain then resolves the map
reference to a service URI if one wasn't provided by the client.
assuming that the destination URI resolves to a host inside a region
domain with whom the agent domain has a trust relationship, it begins
the protocol to place the user's avatar in that region. the
destination region authenticates the agent domain and not the user's avatar before placing it in the region.

what i'm calling the "cable beach model" is that the client t= ells the
agent domain where it will find it's preferred asset server. this is different from the "second life model" where the agent domain pro= vides
caps for inventory access after the client has authenticated itself. i
chatted with jhurliman about this, and he seems big on OAuth to be the
carrier of authorization information. the essential difference here is
that an independent authentication to the asset service is required,
but once that's done, you can use OAuth to give asset access to the
AD, the RD or the client. in fact, you could probably just have the
agent domain authenticate OAuth tokens from the domain containing the
asset service. but the essential notion here is that multiple region
domains and multiple agent domains could use the services of the same
external asset service.

and the standalone mode is basically everything is on one box.

discussion?

-cheers
-meadhbh/infinity



--
=A0 infinity linden (aka meadhbh hamrick) =A0* =A0it's pronounced &quo= t;maeve"
=A0 =A0 =A0 =A0 http://wiki.secondlife.com/wiki/User:Infinit= y_Linden



On Fri, Oct 16, 2009 at 07:29, Vaughn Deluca <vaughn.deluca@gmail.com> wrote: >
>
> On Fri, Oct 16, 2009 at 3:44 PM, Meadhbh Hamrick <meadhbh.siobhan@gmail.com= >
> wrote:
>>
>> but didn't we say that we were going to focus on "second = life-like"
>> worlds in this WG?
>
> I strongly believe the basic =A0mode *is* "second life like"= , even much more
> so than some of the other use cases considered in Davids layering draf= t.
> Also i do not think this needs to delay us much *at all*, since the ba= sics
> idea has =A0always been part of the deployment pattern considered. Loo= k at the
> description of "adding a Organization domain" on the wiki: > http://wiki.secondlife.com/wiki/Multi= ple_Domains#Adding_a_Organization_Domain.
> The figure legend states:
>> [...] The blue dotted line means that an agent can be linked
>> to another agent (e.g. the more public agent from the SL Agent dom= ain
>> (=3D=3D Linden Lab's grid)). This can mean the following:
>>
>> The company agent can access the inventory from the
>> company agent domain and from the SL Agent Domain
> This is in principle the tourist use case i have been describing!
> However, the wiki is not clear about the way to actually implement the=
> restrictions:
>>So what we need here is a list of what should be restrictable
>>and a means of how to define it.
> My suggestion is to define the restrictions at the level of the servic= es,
> completely analogous to the discussion we had about the Region Domain = i.e.
> All policy is local -but the regions can use a global policy derived f= rom
> the domain if they wish to do so).
> I therefore argue strongly for a design were Agent service and Asset s= ervice
> are both expressing policy, and both exposing an interface to the worl= d.
> In this way it becomes fairly easy to configure any type of domain
> behaviour.
> I really see very few problems here, but maybe i am naive =A0:)
> -Vaughn
>
>
>>
>> isn't that why it was formed? shouldn't the tourist
>> model be an effort of the MMOX group? i thought that was the reaso= n we
>> kept the MMOX mailing list up, so work could continue on that type= of
>> virtual world.
>>
>> -meadhbh/infinity
>>
>>
>> On Fri, Oct 16, 2009 at 5:00 AM, Morgaine
>> <morgaine.dinova@googlemail.com> wrote:
>> > Vaughn,
>> >
>> > You've correctly represented my MMOX post, thanks!=A0 ( >> > http://www.ietf.org/mail-archive/web/mmox/= current/msg01392.html )
>> >
>> > I must stress, as you did yourself, that the "Free World= s Tourist" use
>> > case
>> > which I described there in MMOX is different=A0 to the simple= r "tourist
>> > use
>> > case" which we have been discussing here.=A0 It's gr= eat that you're
>> > shining
>> > some light into this corner.=A0 Hopefully this will allow us = to affix
>> > labels
>> > to the various cases to keep our discussions simple yet clear= .
>> >
>> > Before addressing your actual point, I should first state tha= t I
>> > consider it
>> > unfortunate that the "Free Worlds Tourist" use case= is not considered an
>> > integral part of VWRAP requirements --- this is a practical c= onclusion
>> > on my
>> > part.=A0 On the basis of our discussions so far, I think it w= ould be too
>> > much
>> > to expect that a mode of operation offering such a high degre= e of
>> > freedom of
>> > travel and of avatar appearance would achieve rough consensus= in the
>> > group,
>> > given that its considerable distance from Second Life policie= s would
>> > almost
>> > certainly lead to intense opposition.=A0 This is not a battle= I wish to
>> > fight.
>> >
>> > As a practical matter then, "Free Worlds Tourist" a= s defined above is
>> > not a
>> > use case that I am pushing in VWRAP at this time, despite it = being
>> > entirely
>> > compatible with the SL/Opensim model and hence deserving incl= usion.=A0 I'm
>> > simply going to express regret that it is likely to be a brid= ge too far
>> > on
>> > political grounds and leave it at that.=A0 I would wish it we= re otherwise.
>> >
>> > With that disclaimer, I'll answer your point about our mo= re constrained
>> > "tourist use case" (which perhaps needs a better na= me), this being a
>> > much
>> > easier target but still a very useful one.=A0 I will however = answer it in
>> > the
>> > immediately following post, because I don't want to get t= his confused
>> > with
>> > the "Free Worlds Tourist" case that I described in = MMOX.
>> >
>> >
>> > Morgaine.
>> >
>> >
>> >
>> >
>> >
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> >
>> > On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca <vaughn.deluca@gmail.com<= /a>>
>> > wrote:
>> >>
>> >> The "tourist use case" has been brought up seve= ral times, but the
>> >> concept
>> >> is not always used in the same way, and needs to be more = precisely
>> >> defined.
>> >> Morgaines original definition of the "Free Worlds To= urist use case"=A0in
>> >> http://www.ietf.org/mail-archive/web/m= mox/current/msg01392.html
>> >> mentions two characteristics:
>> >> 1. Travel requires no prior arrangement.
>> >> 2. Your avatar is defined by you, not by the target world= s, and it
>> >> appears
>> >> in those worlds with no prior arrangement.
>> >> Point 1 is only dependent the policies of the users AD as= well as that
>> >> of
>> >> the destination region. It is not dependent on the protoc= ol, so in
>> >> principle
>> >> solved.
>> >> The second point is actually extending the SL use case be= yond what is
>> >> in
>> >> my view needed for a basic tourist model (and that is why= the post was
>> >> in
>> >> the mmox list). =A0In my view =A0a basic tourist use case= has two main
>> >> characteristics:
>> >> 1. =A0Travel requires no prior arrangement.
>> >> =A0=A0 =A0 =A0 =A02. =A0Agent domains can use external as= set services
>> >> Point 2 requires that assets services expose an interface= (in the
>> >> current
>> >> ogp description of the AD that is not the case).
>> >> Note that this models does *not* assumes that all assets = in a services
>> >> should be useable by the agent in all domains, but only t= hat an
>> >> interface is
>> >> available so an asset service in one domain can be contac= ted by another
>> >> AD.
>> >> I think exposing the asset service interface directly is = essential for
>> >> meaningful interop. =A0I think it would benefit the discu= ssion if some
>> >> diagrams were added to
>> >> http://wiki.secondlife.com/wiki/Structural_Design
>> >> and/or to the VWRAP wiki to document this possibility. >> >> -Vaughn
>> >> _______________________________________________
>> >> ogpx mailing list
>> >> ogpx@i= etf.org
>> >> https://www.ietf.org/mailman/listinfo/ogpx
>> >>
>> >
>> >
>> > _______________________________________________
>> > ogpx mailing list
>> > ogpx@ietf.= org
>> > https://www.ietf.org/mailman/listinfo/ogpx
>> >
>> >
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx
>
>


--000325559f56e5f933047629a300-- From vaughn.deluca@gmail.com Sat Oct 17 16:13:55 2009 Return-Path: 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 2F7C63A687C for ; Sat, 17 Oct 2009 16:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 dp2LQLIV-RGq for ; Sat, 17 Oct 2009 16:13:54 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 049DD3A6358 for ; Sat, 17 Oct 2009 16:13:53 -0700 (PDT) Received: by fxm18 with SMTP id 18so3731191fxm.37 for ; Sat, 17 Oct 2009 16:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=FfkcfCWqV/yFPK2gZ+lxT5fsi2ocRjx30MXrWJGt77c=; b=EXZfLOsmx/+NtcM1gcVk0ERaUiZR6wDt63Ufznb3siDOU7r60fzYR9hkayM66cCTWQ LKMSjSRmYkPumBL8L+mXod/McQpH3sp3u4YSgqLMNLuwzQxN0uUVGVApLlmzgh8QU8C5 gngz6YlzUR/ePfxW9oMW4+zGyZbPn/E1h5p30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U6ZTd08WOAE2p9V1V4uG18vifEuYQ0CaEGPJPVPgMX11MOvy4KnfHhLmjOE6Lz59Bq NPWE2P9+A0Bs0NsV2k1CxMMo2httCwDzvXU21Zc45BckIdQXouYW3QzKn/IhR1EizChF LA32t1y+HWAD6ctFgHNt7yNfA7II4CCBknRkk= MIME-Version: 1.0 Received: by 10.204.155.79 with SMTP id r15mr3126479bkw.142.1255821237863; Sat, 17 Oct 2009 16:13:57 -0700 (PDT) In-Reply-To: References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <4AD894BE.30501@uci.edu> <9b8a8de40910161546h9e54dcah59cb423a0ac096af@mail.gmail.com> Date: Sun, 18 Oct 2009 01:13:57 +0200 Message-ID: <9b8a8de40910171613g33d7c8d3v95e221df99abd1f2@mail.gmail.com> From: Vaughn Deluca To: Suzy Deffeyes Content-Type: multipart/alternative; boundary=0015175d07d2c8c50f047629aa04 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2009 23:13:55 -0000 --0015175d07d2c8c50f047629aa04 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 17, 2009 at 3:32 AM, Suzy Deffeyes wrote: > We open sourced an implementation of agent domain recently. > http://forge.opensimulator.org/gf/project/ogp/ > > Also note that OGP functionality is included in the snowglobe viewer. It > was recently added as jira SNOW-215. > > Lastly, these two implementation tidbits have started adding extensions to > the original OGP spec in the area of inventory and wearables. > Great! *starts reading code* > > Suzy Deffeyes > Pixel Gausman > IBM > --0015175d07d2c8c50f047629aa04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 17, 2009 at 3:32 AM, Suzy Deffeyes <= span dir=3D"ltr"><suzyque@gmail.com= > wrote:
We open sourced an implementation of agent domain recentl= y.
=A0http://forge.opensimulator.org/gf/project/ogp/

Also note that OGP functionality is included in the snowglobe viewer. It wa= s recently added as jira SNOW-215.

Lastly, these two implementation tidbits have started adding extensions to = the original OGP spec in the area of inventory and wearables.

Great! =A0*starts reading code*=A0

Suzy Deffeyes
Pixel Gausman
IBM

--0015175d07d2c8c50f047629aa04-- From lenglish5@cox.net Sun Oct 18 07:12:04 2009 Return-Path: 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 284BB3A68B8 for ; Sun, 18 Oct 2009 07:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 LD-GAlXDYQJB for ; Sun, 18 Oct 2009 07:12:03 -0700 (PDT) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 646AD3A681C for ; Sun, 18 Oct 2009 07:12:03 -0700 (PDT) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao107.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20091018141207.KUH21470.fed1rmmtao107.cox.net@fed1rmimpo03.cox.net>; Sun, 18 Oct 2009 10:12:07 -0400 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo03.cox.net with bizsmtp id uEC71c0012l1Ksg04EC7Yk; Sun, 18 Oct 2009 10:12:07 -0400 X-VR-Score: -200.00 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=kviXuzpPAAAA:8 a=0BQNvx9boqSyOV6AjGAA:9 a=Tq3o6-D9NB9Bwn8PP2gA:7 a=wLiDyTKHOg-7Qk-XoOcKAN2UbbMA:4 a=4vB-4DCPJfMA:10 a=wirOPJqAE7hWx4Fy:21 a=A_7PMD4s9WadQ8PL:21 X-CM-Score: 0.00 Message-ID: <4ADB2236.3030908@cox.net> Date: Sun, 18 Oct 2009 07:12:06 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Vaughn Deluca References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <4AD903F3.6080809@cox.net> <9b8a8de40910171610m6e415635m85bf715f86f35c4@mail.gmail.com> In-Reply-To: <9b8a8de40910171610m6e415635m85bf715f86f35c4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Meadhbh Hamrick , ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 14:12:04 -0000 Vaughn Deluca wrote: > > > On Sat, Oct 17, 2009 at 1:38 AM, Lawson English > wrote: > > Meadhbh Hamrick wrote: > > but didn't we say that we were going to focus on "second > life-like" > worlds in this WG? isn't that why it was formed? shouldn't the > tourist > model be an effort of the MMOX group? i thought that was the > reason we > kept the MMOX mailing list up, so work could continue on that > type of > virtual world. > > -meadhbh/infinity > > > > It seems to me that the MOST touristy mode we will ever see is the > free-for-all from the original OGP test where > simple TP and naught else was supported. > > > I find that a deeply depressing thought. I would *really* hope that > at least transfer of free to copy assets will also be possible. > > Well, me too. I was merely pointing out that "tourism" was built into the system from the start, so to suggest that tourism was MMOX rather than VRAM was a false dichotomy. We already have an example of the "most touristy" mode possible and things will be built *on top of* it. The idea that few vendors would support it misses the fact that it is the _de facto_ model that everything else is built on. Now, tourism with non-SL-compatible worlds is certainly an MMOX issue, but tourism is inherent in ANY interop scenario, period. It's just the state of NULL trust. Whether NULL trust is allowed is a policy issue, but its inherent in the nature of the system. Lawson From vaughn.deluca@gmail.com Sun Oct 18 08:31:37 2009 Return-Path: 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 AC7E53A68B8 for ; Sun, 18 Oct 2009 08:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 VvZ1-vp+Nh9z for ; Sun, 18 Oct 2009 08:31:36 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 4C4CF3A689A for ; Sun, 18 Oct 2009 08:31:36 -0700 (PDT) Received: by fxm18 with SMTP id 18so4129934fxm.37 for ; Sun, 18 Oct 2009 08:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=It6VKfUPOaWikqRz2oHHXn6JdkbLM3fsv8Pdk+senHQ=; b=BbAmTBdRNyMMguxYFMX2y37KSMdZkERyQEo7WMZEZytBg36Vf9pj1ov5k7cHhOcXqC YwNQNDrX5QAKq5LtHYHVC8xPU9ld0jPcYsqLbkQGd6o2G4NrUn19mtT0icrz60kNV11I 6UA8ASHHDv+5ia3NO6ZmwNaAKIOO+AA4GMA50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V9UaKX0/7Q8YtYJAtVgKDfdmlvncecKjMBxgg+jF+fTQNSedBxQ0Y2+213/m3CTGt/ mZnraglmHCDUFm1SlF6xTjm0bBknD7aHAiSLPEF4V2yWCu0NBF99zjtlq7JCpzJFV9Q5 kwv7lePaPNsBxuPI60NtbXABarYFBQIMvYhs4= MIME-Version: 1.0 Received: by 10.204.155.79 with SMTP id r15mr3869383bkw.142.1255879898024; Sun, 18 Oct 2009 08:31:38 -0700 (PDT) In-Reply-To: <4ADB2236.3030908@cox.net> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <4AD903F3.6080809@cox.net> <9b8a8de40910171610m6e415635m85bf715f86f35c4@mail.gmail.com> <4ADB2236.3030908@cox.net> Date: Sun, 18 Oct 2009 17:31:37 +0200 Message-ID: <9b8a8de40910180831t1cac602fq12da03c36d662d4a@mail.gmail.com> From: Vaughn Deluca To: lenglish5@cox.net Content-Type: multipart/alternative; boundary=0015175d07d233cbd304763753d0 Cc: Meadhbh Hamrick , ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 15:31:37 -0000 --0015175d07d233cbd304763753d0 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Oct 18, 2009 at 4:12 PM, Lawson English wrote: > Vaughn Deluca wrote: > >> >> >> On Sat, Oct 17, 2009 at 1:38 AM, Lawson English > lenglish5@cox.net>> wrote: >> >> Meadhbh Hamrick wrote: >> >> but didn't we say that we were going to focus on "second >> life-like" >> worlds in this WG? isn't that why it was formed? shouldn't the >> tourist >> model be an effort of the MMOX group? i thought that was the >> reason we >> kept the MMOX mailing list up, so work could continue on that >> type of >> virtual world. >> >> -meadhbh/infinity >> >> >> It seems to me that the MOST touristy mode we will ever see is the >> free-for-all from the original OGP test where >> simple TP and naught else was supported. >> >> >> I find that a deeply depressing thought. I would *really* hope that at >> least transfer of free to copy assets will also be possible. >> >> > Well, me too. I was merely pointing out that "tourism" was built into the > system from the start, so to suggest that tourism was MMOX > rather than VRAM was a false dichotomy. We already have an example of the > "most touristy" mode possible and things will be built > *on top of* it. The idea that few vendors would support it misses the fact > that it is the _de facto_ model that everything else is built on. > > Now, tourism with non-SL-compatible worlds is certainly an MMOX issue, but > tourism is inherent in ANY interop scenario, period. > > It's just the state of NULL trust. Whether NULL trust is allowed is a > policy issue, but its inherent in the nature of the system. > > > Lawson > Mmmm, yes, "tourist" was badly chosen. But somehow i got the impression we were heading towards a system were assets would only be available from the Asset server of the world currently visited, so you would need to either duplicate assets to different servers to have access, or just live with the fact that in each visited world you have a different set of assets, like what we have now when going to OSGrid. Seems I was a bit too pessimistic. Anyhow, i realised i need read some more to make a meaningful contribution here. Also without the new versions of the draft up its hard to discuss anything. So I will take a pause and study the backgound documents in some more dept. -Vaughn --0015175d07d233cbd304763753d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Oct 18, 2009 at 4:12 PM, Lawson = English <lenglish= 5@cox.net> wrote:
Vaughn Deluca wrote:



On Sat, Oct 17, 2009 at 1:38 AM, Lawson English <lenglish5@cox.net <mailto:lenglish5@cox.net>> = wrote:

=A0 =A0Meadhbh Hamrick wrote:

=A0 =A0 =A0 =A0but didn't we say that we were going to focus on "= second
=A0 =A0 =A0 =A0life-like"
=A0=A0 =A0 =A0 worlds in this WG? isn= 9;t that why it was formed? shouldn't the
=A0 =A0 =A0 =A0tourist
=A0 =A0 =A0 =A0model be an effort of the MMOX group? i thought that was th= e
=A0 =A0 =A0 =A0reason we
=A0 =A0 =A0 =A0kept the MMOX mailing list up, so work could continue on th= at
=A0 =A0 =A0 =A0type of
=A0 =A0 =A0 =A0virtual world.

=A0 =A0 =A0 =A0-meadhbh/infinity
=A0 =A0 =A0 =A0

=A0 =A0It seems to me that the MOST touristy mode we will ever see is the<= br> =A0 =A0free-for-all from the original OGP test where
=A0 =A0simple TP and naught else was supported.


I find that a deeply depressing thought. =A0I would *really* hope that at l= east =A0transfer of free to copy assets will also be possible.


Well, me too. I was merely pointing out that "tourism" was built = into the system from the start, so to suggest that tourism was MMOX
rather than VRAM was a false dichotomy. We already have an example of the &= quot;most touristy" mode possible and things will be built
*on top of* it. The idea that few vendors would support it misses the fact = that it is the _de facto_ model that everything else is built on.

Now, tourism with non-SL-compatible worlds is certainly an MMOX issue, but = tourism is inherent in ANY interop scenario, period.

It's just the state of NULL trust. Whether NULL trust is allowed is a p= olicy issue, but its inherent in the nature of the system.


Lawson
Mmmm, yes, "tourist" was badly chosen.= =A0But somehow=A0i got the impression we were heading towards a system were= assets would only be available from the Asset server of the world =A0curre= ntly visited, so you would need to either duplicate assets to different ser= vers to have access, or just live with the fact that in each visited world = you have a different set of assets, like what we have now when going to OSG= rid. =A0Seems I was a bit too pessimistic.

Anyhow, i realised i need read some more to make a= meaningful contribution here. Also without the new versions of the draft u= p its hard to discuss anything.=A0So I will take a pause and study =A0the b= ackgound documents in some =A0more dept.=A0

-Vaughn

--0015175d07d233cbd304763753d0-- From dwl@us.ibm.com Sun Oct 18 10:26:22 2009 Return-Path: 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 A7CC53A6964; Sun, 18 Oct 2009 10:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 tlqT0i1Z962r; Sun, 18 Oct 2009 10:26:21 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 3F7823A6941; Sun, 18 Oct 2009 10:26:21 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9IHNH0K015841; Sun, 18 Oct 2009 13:23:17 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9IHQKFg235934; Sun, 18 Oct 2009 13:26:20 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n9IHQKS5015541; Sun, 18 Oct 2009 13:26:20 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n9IHQK9v015537; Sun, 18 Oct 2009 13:26:20 -0400 In-Reply-To: <9b8a8de40910180831t1cac602fq12da03c36d662d4a@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <4AD903F3.6080809@cox.net> <9b8a8de40910171610m6e415635m85bf715f86f35c4@mail.gmail.com> <4ADB2236.3030908@cox.net> <9b8a8de40910180831t1cac602fq12da03c36d662d4a@mail.gmail.com> To: Vaughn Deluca MIME-Version: 1.0 X-KeepSent: 72D150A2:4ACB58CB-85257653:005F26CE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Sun, 18 Oct 2009 13:26:19 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1|September 28, 2009) at 10/18/2009 13:26:19, Serialize complete at 10/18/2009 13:26:19 Content-Type: multipart/alternative; boundary="=_alternative 005FCA9985257653_=" Cc: lenglish5@cox.net, ogpx@ietf.org, ogpx-bounces@ietf.org, Meadhbh Hamrick Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 17:26:22 -0000 This is a multipart message in MIME format. --=_alternative 005FCA9985257653_= Content-Type: text/plain; charset="US-ASCII" Keep in mind the model separates mechanism from policy. The mechanism will allow it, how people define policies will determine how easily assets flow across the extended grid. My personal guess is that we will end up with some sets of assets which flow very broadly across a lot of grids, but it will take time for this to settle down. I also equally expect that we will see lots of clusters of walled gardens by policy, for various reasons, and that assets from these gardens will live within them. My goal for the specifications to support this range of use cases, and to focus on the mechanisms, and keep debates as to which policy is appropriate off this list. (Enable the policy choices, and let the real world determine which policies are successful) - David ~ Zha Vaughn Deluca Sent by: ogpx-bounces@ietf.org 10/18/2009 11:31 AM To lenglish5@cox.net cc Meadhbh Hamrick , ogpx@ietf.org Subject Re: [ogpx] Tourist use case On Sun, Oct 18, 2009 at 4:12 PM, Lawson English wrote: Vaughn Deluca wrote: On Sat, Oct 17, 2009 at 1:38 AM, Lawson English > wrote: Meadhbh Hamrick wrote: but didn't we say that we were going to focus on "second life-like" worlds in this WG? isn't that why it was formed? shouldn't the tourist model be an effort of the MMOX group? i thought that was the reason we kept the MMOX mailing list up, so work could continue on that type of virtual world. -meadhbh/infinity It seems to me that the MOST touristy mode we will ever see is the free-for-all from the original OGP test where simple TP and naught else was supported. I find that a deeply depressing thought. I would *really* hope that at least transfer of free to copy assets will also be possible. Well, me too. I was merely pointing out that "tourism" was built into the system from the start, so to suggest that tourism was MMOX rather than VRAM was a false dichotomy. We already have an example of the "most touristy" mode possible and things will be built *on top of* it. The idea that few vendors would support it misses the fact that it is the _de facto_ model that everything else is built on. Now, tourism with non-SL-compatible worlds is certainly an MMOX issue, but tourism is inherent in ANY interop scenario, period. It's just the state of NULL trust. Whether NULL trust is allowed is a policy issue, but its inherent in the nature of the system. Lawson Mmmm, yes, "tourist" was badly chosen. But somehow i got the impression we were heading towards a system were assets would only be available from the Asset server of the world currently visited, so you would need to either duplicate assets to different servers to have access, or just live with the fact that in each visited world you have a different set of assets, like what we have now when going to OSGrid. Seems I was a bit too pessimistic. Anyhow, i realised i need read some more to make a meaningful contribution here. Also without the new versions of the draft up its hard to discuss anything. So I will take a pause and study the backgound documents in some more dept. -Vaughn _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 005FCA9985257653_= Content-Type: text/html; charset="US-ASCII"
Keep in mind the model separates mechanism from policy. The mechanism will allow it, how people define policies will determine how easily assets flow across the extended grid. My personal guess is that we will end up with some sets of assets which flow very broadly across a lot of grids, but it will take time for this to settle down. I also equally expect that we will see lots of  clusters of walled gardens by policy, for various reasons, and that assets from these gardens will live within them. My goal for the specifications  to support this range of use cases, and to focus on the mechanisms, and keep debates as to which policy is appropriate off this list. (Enable the policy choices, and let the real world determine which policies are successful)

- David
~ Zha


Vaughn Deluca <vaughn.deluca@gmail.com>
Sent by: ogpx-bounces@ietf.org

10/18/2009 11:31 AM

To
lenglish5@cox.net
cc
Meadhbh Hamrick <meadhbh.siobhan@gmail.com>, ogpx@ietf.org
Subject
Re: [ogpx] Tourist use case
On Sun, Oct 18, 2009 at 4:12 PM, Lawson English <lenglish5@cox.net> wrote:
Vaughn Deluca wrote:



On Sat, Oct 17, 2009 at 1:38 AM, Lawson English <lenglish5@cox.net <mailto:lenglish5@cox.net>> wrote:

   Meadhbh Hamrick wrote:

       but didn't we say that we were going to focus on "second
       life-like"
       worlds in this WG? isn't that why it was formed? shouldn't the
       tourist
       model be an effort of the MMOX group? i thought that was the
       reason we
       kept the MMOX mailing list up, so work could continue on that
       type of
       virtual world.

       -meadhbh/infinity
       

   It seems to me that the MOST touristy mode we will ever see is the
   free-for-all from the original OGP test where
   simple TP and naught else was supported.


I find that a deeply depressing thought.  I would *really* hope that at least  transfer of free to copy assets will also be possible.


Well, me too. I was merely pointing out that "tourism" was built into the system from the start, so to suggest that tourism was MMOX
rather than VRAM was a false dichotomy. We already have an example of the "most touristy" mode possible and things will be built
*on top of* it. The idea that few vendors would support it misses the fact that it is the _de facto_ model that everything else is built on.

Now, tourism with non-SL-compatible worlds is certainly an MMOX issue, but tourism is inherent in ANY interop scenario, period.

It's just the state of NULL trust. Whether NULL trust is allowed is a policy issue, but its inherent in the nature of the system.


Lawson
Mmmm, yes, "tourist" was badly chosen. But somehow i got the impression we were heading towards a system were assets would only be available from the Asset server of the world  currently visited, so you would need to either duplicate assets to different servers to have access, or just live with the fact that in each visited world you have a different set of assets, like what we have now when going to OSGrid.  Seems I was a bit too pessimistic.

Anyhow, i realised i need read some more to make a meaningful contribution here. Also without the new versions of the draft up its hard to discuss anything. So I will take a pause and study  the backgound documents in some  more dept. 

-Vaughn
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 005FCA9985257653_=-- From vaughn.deluca@gmail.com Sun Oct 18 11:41:46 2009 Return-Path: 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 7B9D83A6907; Sun, 18 Oct 2009 11:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 viRzYJGfyvtF; Sun, 18 Oct 2009 11:41:44 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 3090F3A680C; Sun, 18 Oct 2009 11:41:43 -0700 (PDT) Received: by fxm18 with SMTP id 18so4248757fxm.37 for ; Sun, 18 Oct 2009 11:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MTt46HUhhvZDNQEcICyfe7YKS+vybrDiKAujLXNQ8Ws=; b=gTQgdnHsOc+/QGjhQi6Y7wOuOSz2RBCWtGhn/kJB+rmChSFJiIrh8OQa/otP0p1piR 65vY4HKHcEcIjtVwkpYUwf3jbOwp2L3pLcnRjYxktqOh7QvubuzBr9GY1EujEeEkgx15 Syelm+fUapgLQ1P9fOTj+2X7/d3xx6urP72gA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U5NLUfLF9NR5EXaGGtdgV/CgcIV3LYr4+Gv/da0f6L8JsLvpKAAFHdVSxqRFAEGH9a viNvdlQhcPyyzelewOW9lPb4hEV8FcXjmKYzzodXltH/+1hh6rWiSUY1HkxcVHaCHLFg ZyzG3qFeZ4GeOkNGvCCCWaRSWn5XigMeW4FFw= MIME-Version: 1.0 Received: by 10.204.2.73 with SMTP id 9mr3933312bki.159.1255891305048; Sun, 18 Oct 2009 11:41:45 -0700 (PDT) In-Reply-To: References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <4AD903F3.6080809@cox.net> <9b8a8de40910171610m6e415635m85bf715f86f35c4@mail.gmail.com> <4ADB2236.3030908@cox.net> <9b8a8de40910180831t1cac602fq12da03c36d662d4a@mail.gmail.com> Date: Sun, 18 Oct 2009 20:41:44 +0200 Message-ID: <9b8a8de40910181141h616121cfxf7e2186dbe59557e@mail.gmail.com> From: Vaughn Deluca To: David W Levine Content-Type: multipart/alternative; boundary=0015174c45801d2c12047639fbef Cc: lenglish5@cox.net, ogpx@ietf.org, ogpx-bounces@ietf.org, Meadhbh Hamrick Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 18:41:47 -0000 --0015174c45801d2c12047639fbef Content-Type: text/plain; charset=ISO-8859-1 I could not agree more! On Sun, Oct 18, 2009 at 7:26 PM, David W Levine wrote: > > Keep in mind the model separates mechanism from policy. The mechanism will > allow it, how people define policies will determine how easily assets flow > across the extended grid. My personal guess is that we will end up with some > sets of assets which flow very broadly across a lot of grids, but it will > take time for this to settle down. I also equally expect that we will see > lots of clusters of walled gardens by policy, for various reasons, and that > assets from these gardens will live within them. My goal for the > specifications to support this range of use cases, and to focus on the > mechanisms, and keep debates as to which policy is appropriate off this > list. (Enable the policy choices, and let the real world determine which > policies are successful) > > - David > ~ Zha > > > *Vaughn Deluca * > Sent by: ogpx-bounces@ietf.org > > 10/18/2009 11:31 AM > To > lenglish5@cox.net cc > Meadhbh Hamrick , ogpx@ietf.org > Subject > Re: [ogpx] Tourist use case > > > > > > > On Sun, Oct 18, 2009 at 4:12 PM, Lawson English <*lenglish5@cox.net*> > wrote: > Vaughn Deluca wrote: > > > > On Sat, Oct 17, 2009 at 1:38 AM, Lawson English <*lenglish5@cox.net* *lenglish5@cox.net* >> wrote: > > Meadhbh Hamrick wrote: > > but didn't we say that we were going to focus on "second > life-like" > worlds in this WG? isn't that why it was formed? shouldn't the > tourist > model be an effort of the MMOX group? i thought that was the > reason we > kept the MMOX mailing list up, so work could continue on that > type of > virtual world. > > -meadhbh/infinity > > > It seems to me that the MOST touristy mode we will ever see is the > free-for-all from the original OGP test where > simple TP and naught else was supported. > > > I find that a deeply depressing thought. I would *really* hope that at > least transfer of free to copy assets will also be possible. > > > Well, me too. I was merely pointing out that "tourism" was built into the > system from the start, so to suggest that tourism was MMOX > rather than VRAM was a false dichotomy. We already have an example of the > "most touristy" mode possible and things will be built > *on top of* it. The idea that few vendors would support it misses the fact > that it is the _de facto_ model that everything else is built on. > > Now, tourism with non-SL-compatible worlds is certainly an MMOX issue, but > tourism is inherent in ANY interop scenario, period. > > It's just the state of NULL trust. Whether NULL trust is allowed is a > policy issue, but its inherent in the nature of the system. > > > Lawson > Mmmm, yes, "tourist" was badly chosen. But somehow i got the impression we > were heading towards a system were assets would only be available from the > Asset server of the world currently visited, so you would need to either > duplicate assets to different servers to have access, or just live with the > fact that in each visited world you have a different set of assets, like > what we have now when going to OSGrid. Seems I was a bit too pessimistic. > > Anyhow, i realised i need read some more to make a meaningful contribution > here. Also without the new versions of the draft up its hard to discuss > anything. So I will take a pause and study the backgound documents in some > more dept. > > -Vaughn > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0015174c45801d2c12047639fbef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I could not agree more!

On Sun, Oct 18, 2= 009 at 7:26 PM, David W Levine <dwl@us.ibm.com> wrote:

Keep in mind the model separates m= echanism from policy. The mechanism will allow it, how people define policies will determine how easily assets flow across the extended grid. My personal guess is that we will end up with some sets of assets which flow very broad= ly across a lot of grids, but it will take time for this to settle down. I also equally expect that we will see lots of =A0clusters of walled gardens by policy, for various reasons, and that assets from these gardens will live within them. My goal for the specifications =A0to support this range of use cases, and to focus on the mechanisms, and keep debates as to which policy is appropriate off this list. (Enable the policy choices, and let the real world determine which policies are successful)

- David
~ Zha


Vaughn Deluca <vaughn.deluca@gmail.com>
Sent by: ogpx-bounces@ietf.org

10/18/2009 11:31 AM

To
lenglish5@cox.net
cc
Meadhbh Hamrick <meadhbh.siobhan@gma= il.com>, ogpx@ietf.org=
Subject
Re: [ogpx] Tourist use case







On Sun, Oct 18, 2009 at 4:12 PM, Lawson English <lenglish5@cox.net> wrote:
Vaughn Deluca wrote:



On Sat, Oct 17, 2009 at 1:38 AM, Lawson English <l= english5@cox.net <mailto:lenglish5@cox.net>> wrote:

=A0 =A0Meadhbh Hamrick wrote:

=A0 =A0 =A0 =A0but didn't we say that we were going to focus on "second
=A0 =A0 =A0 =A0life-like"
=A0=A0 =A0 =A0 worlds in this WG? isn't that why it was formed? shouldn't the
=A0 =A0 =A0 =A0tourist
=A0 =A0 =A0 =A0model be an effort of the MMOX group? i thought that was the
=A0 =A0 =A0 =A0reason we
=A0 =A0 =A0 =A0kept the MMOX mailing list up, so work could continue on that
=A0 =A0 =A0 =A0type of
=A0 =A0 =A0 =A0virtual world.

=A0 =A0 =A0 =A0-meadhbh/infinity
=A0 =A0 =A0 =A0

=A0 =A0It seems to me that the MOST touristy mode we will ever see is the
=A0 =A0free-for-all from the original OGP test where
=A0 =A0simple TP and naught else was supported.


I find that a deeply depressing thought. =A0I would *really* hope that at least =A0transfer of free to copy assets will also be possible.


Well, me too. I was merely pointing out that "tou= rism" was built into the system from the start, so to suggest that tourism was MMOX
rather than VRAM was a false dichotomy. We already have an example of the "most touristy" mode possible and things will be built
*on top of* it. The idea that few vendors would support it misses the fact that it is the _de facto_ model that everything else is built on.

Now, tourism with non-SL-compatible worlds is certainly an MMOX issue, but tourism is inherent in ANY interop scenario, period.

It's just the state of NULL trust. Whether NULL trust is allowed is a p= olicy issue, but its inherent in the nature of the system.


Lawson
Mmmm, yes, "tourist" was badly chosen.=A0But somehow=A0i got the impression we were heading towards a system were assets would only be available from the Asset server of the world =A0curren= tly visited, so you would need to either duplicate assets to different servers to have access, or just live with the fact that in each visited world you have a different set of assets, like what we have now when going to OSGrid. =A0Seems I was a bit too pessimistic.

Anyhow, i realised i need read some more to make a mea= ningful contribution here. Also without the new versions of the draft up its hard to discuss anything.=A0So I will take a pause and study =A0the backgound documents in some =A0more dept.=A0

-Vaughn
____= ___________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx=


--0015174c45801d2c12047639fbef-- From morgaine.dinova@googlemail.com Mon Oct 19 03:56:29 2009 Return-Path: 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 CC1EA28C159 for ; Mon, 19 Oct 2009 03:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.276 X-Spam-Level: X-Spam-Status: No, score=-0.276 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_OEM_OBFU=1] 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 rqyWMHNXhGmO for ; Mon, 19 Oct 2009 03:56:28 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 21EA428C16B for ; Mon, 19 Oct 2009 03:56:27 -0700 (PDT) Received: by ewy28 with SMTP id 28so4260090ewy.42 for ; Mon, 19 Oct 2009 03:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=w81GplMUFyPMhSTv08DR0pHosdJn5NR+IiRG9U5POHw=; b=COQlspE345NagNTmnyCSdMJs+OpwQI71XNg3/TAjPQ8wUGSR0gG8ltbEQgUF/ekUem EFF46Vgdrujjr05Plmy32tfXKUOHtqFOwvkRXZ3tlMuNsMBRhntGZIjhNtdSRQhH2TM0 90KKtcNQ6H15xGQU7ZqSEDmYb4tOr7EjzJuZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fvH/pP9xWFqe9r8mb+nrfxFIxHuex0jRt7j6BwQJZy4nRVu+wxcNva0NTUFf+qOi4B 9RSQ4uQyGIsXwUfP/QdZXsEK8C1WsbCoGOvrve0IMyXAzqXQIYDHFsp2Wlpkn85kszj4 x77BbvivhgAuQhXZ5Nh/XqEtAKiE+x3nOBZQ8= MIME-Version: 1.0 Received: by 10.211.147.8 with SMTP id z8mr4855404ebn.87.1255949794311; Mon, 19 Oct 2009 03:56:34 -0700 (PDT) In-Reply-To: <3a880e2c0910161639x4d5bf462u47f0db4c8736bf93@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <4AD894BE.30501@uci.edu> <9b8a8de40910161546h9e54dcah59cb423a0ac096af@mail.gmail.com> <3a880e2c0910161639x4d5bf462u47f0db4c8736bf93@mail.gmail.com> Date: Mon, 19 Oct 2009 11:56:34 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636c5b863587ecb0476479910 Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 10:56:29 -0000 --001636c5b863587ecb0476479910 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 17, 2009 at 12:39 AM, Infinity Linden (Meadhbh Hamrick) < infinity@lindenlab.com> wrote: > > okay. my bad. i was just kinda shocked by what i perceived as an > assertion by morgaine that there was going to be a 1:1 relation > between developers and users. i'll let her make that case if that's > what she really believes, > Is there a need for this kind of wording, fabrication, and targetting of individuals? We have a lot of work to do. Please let's try to focus on the work, not on people. Morgaine. ======================================== On Sat, Oct 17, 2009 at 12:39 AM, Infinity Linden (Meadhbh Hamrick) < infinity@lindenlab.com> wrote: > On Fri, Oct 16, 2009 at 15:46, Vaughn Deluca > wrote: > > > > On Fri, Oct 16, 2009 at 7:03 PM, Joshua Bell wrote: > >> > >> On Fri, Oct 16, 2009 at 8:43 AM, Sean Hennessee wrote: > >>> > >>> Meadhbh Hamrick wrote: > >>>> > >>>> On Fri, Oct 16, 2009 at 1:51 AM, Morgaine > >>>> wrote: > >>>>> > >>>>> On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick) > >>>>> wrote: > >>>>> > >>>>>> also. just a show of hands. who's planning on implementing the > tourist > >>>>>> model? > > > > [...] > > > >> > >> There are two distinct definitions in extremely common use on the 'net: > >> > >> (1) to implement: write the code for something > >> (2) to implement: configure and deploy code for something > >> > >> My interpretation of this thread is that Infinity is using definition > #1, > >> Sean and Morgaine are using definition #2. Infinity is asking > specifically: > >> "who will write the code that adds support for the protocol to a piece > of > >> software?" not "who will make use of software that implements the > protocol?" > > > > *ahum* I was most definitely using definition #2. Yet, i *can* code, and > > given the importance of this aspect, i am certainly willing to assist in > > making this use case happen. However, i am not a professional programer, > but > > just a scientist, coding my own analysis softeware. So i am likely to > need a > > bit of help from some friends :) > > okay. my bad. i was just kinda shocked by what i perceived as an > assertion by morgaine that there was going to be a 1:1 relation > between developers and users. i'll let her make that case if that's > what she really believes, but will assume she interpreted my question > to be "who's interested in deploying services that implement protocol > transactions in accord with the tourist model?" rather than "who's > interested in implementing the tourist model in code?" as it was > intended to mean. > > i think one of the most important outcomes of this process will be an > open standard that anyone can implement without royalty payments, > including FLOSS developers. an operator like linden cannot be all > things to all people and implement every feature. but maybe in the > future we'll be able to point people to OpenSim and say "we can't > implement the feature you want, but maybe you can implement it > yourself using this nice codebase the community has put together for > you." and then, "hey look over there! there's an archipelago of > tourist sites or here's our more locked down world. maybe it makes > sense for you to deploy here." > > i think if we can do that, we will have won. (and not just SL or > OpenSim or realXtend or whomever, but all of us.) > > > On the other hand, i am convinced that a proper implementation of the SL > use > > case (this time in the sense of definition #1) will generate about all > the > > code we need for the tourist case. The difference between the SL model > and > > the tourist model is largely at the policy level. But when we get down > to > > the specs, that will become clear soon enough. > > Regarding the coding, i think Agent Domain code was written this summer. > Is > > that available somewhere? i would like to have a look at that, to get a > > better feel for the size of the problem. > > -Vaughn > > > >> > >> _______________________________________________ > >> ogpx mailing list > >> ogpx@ietf.org > >> https://www.ietf.org/mailman/listinfo/ogpx > >> > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --001636c5b863587ecb0476479910 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 17, 2009 at 12:39 AM, Infinity Linden (Meadhbh Hamrick) <= infinity@lindenlab.com> wrote:

okay. my bad. i was just kinda shoc= ked by what i perceived as an
assertion by morgaine that there was going to be a 1:1 relation
between developers and users. i'll let her make that case if that's=
what she really believes,


Is there a need for= this kind of wording, fabrication, and targetting of individuals?

W= e have a lot of work to do.=A0 Please let's try to focus on the work, n= ot on people.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

On Sat, Oct 17, 2009 at 12:39 AM, Inf= inity Linden (Meadhbh Hamrick) <infinity@lindenlab.com>= wrote:
On Fri, Oct = 16, 2009 at 15:46, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
>
> On Fri, Oct 16, 2009 at 7:03 PM, Joshua Bell <josh@lindenlab.com> wrote:
>>
>> On Fri, Oct 16, 2009 at 8:43 AM, Sean Hennessee <sean@uci.edu> wrote:
>>>
>>> Meadhbh Hamrick wrote:
>>>>
>>>> On Fri, Oct 16, 2009 at 1:51 AM, Morgaine
>>>> <morgaine.dinova@googlemail.com> wrote:
>>>>>
>>>>> On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Mead= hbh Hamrick)
>>>>> <infinity@lindenlab.com> wrote:
>>>>>
>>>>>> also. just a show of hands. who's planning on = implementing the tourist
>>>>>> model?
>
> =A0[...]
>
>>
>> There are two distinct definitions in extremely common use on the = 'net:
>>
>> (1) to implement: write the code for something
>> (2) to implement: configure and deploy code for something
>>
>> My interpretation of this thread is that Infinity is using definit= ion #1,
>> Sean and Morgaine are using definition #2. Infinity is asking spec= ifically:
>> "who will write the code that adds support for the protocol t= o a piece of
>> software?" not "who will make use of software that imple= ments the protocol?"
>
> *ahum* I was most definitely=A0using =A0definition #2. Yet, i *can* co= de, and
> given the importance of this aspect, i am certainly willing to assist = in
> making this use case happen. However, i am not a professional programe= r, but
> just a scientist, coding my own analysis softeware. So i am likely to = need a
> bit of help from some friends :)

okay. my bad. i was just kinda shocked by what i perceived as an
assertion by morgaine that there was going to be a 1:1 relation
between developers and users. i'll let her make that case if that's=
what she really believes, but will assume she interpreted my question
to be "who's interested in deploying services that implement proto= col
transactions in accord with the tourist model?" rather than "who&= #39;s
interested in implementing the tourist model in code?" as it was
intended to mean.

i think one of the most important outcomes of this process will be an
open standard that anyone can implement without royalty payments,
including FLOSS developers. an operator like linden cannot be all
things to all people and implement every feature. but maybe in the
future we'll be able to point people to OpenSim and say "we can= 9;t
implement the feature you want, but maybe you can implement it
yourself using this nice codebase the community has put together for
you." and then, "hey look over there! there's an archipelago = of
tourist sites or here's our more locked down world. maybe it makes
sense for you to deploy here."

i think if we can do that, we will have won. (and not just SL or
OpenSim or realXtend or whomever, but all of us.)

> On the other hand, i am convinced that a proper implementation of the = SL use
> case (this time in the sense of definition =A0#1) will generate about = =A0all the
> code we need for the tourist case. The difference between the SL model= and
> the tourist model is largely at the policy level. =A0But when we get d= own to
> the specs, that will become clear soon enough.
> Regarding the coding, i think Agent Domain code was written this summe= r. Is
> that available somewhere? i would like to have a look at that, to get = a
> better feel for the size of the problem.
> -Vaughn
>
>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx
>
>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--001636c5b863587ecb0476479910-- From morgaine.dinova@googlemail.com Mon Oct 19 04:00:58 2009 Return-Path: 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 0FE3D3A68D5 for ; Mon, 19 Oct 2009 04:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 zMRQTMhZjx3A for ; Mon, 19 Oct 2009 04:00:56 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 57D8628C193 for ; Mon, 19 Oct 2009 04:00:54 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id d26so560834eyd.5 for ; Mon, 19 Oct 2009 04:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=EwQU391HxbxPyByt29zy4FrjjyjtJiIijMxQrI9o/Qg=; b=at6NrRTKsdxh3NMA4DhuYalnaemrhLZPgxZdabmkKW6U24Is4DK767aBIrmBYCRxV8 +J0H6evaABHD7iyawDfkhKDlL84zQefXXayB+jVhcCnCceOO1o6b0kKgGxRUpgg6Y75V lxm6CsycNxxS2g1jrby6U2Jntr9M3Y5Ggs0Kc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=TBWiZNNbB4XWzdFTRBnRx/8oa0dH5uBX5I1m9D1ZLGwfSNLe4LG/0r+e5S6lmf3+0h wq4mGo3lanxwfctQjh3E2h+nixSlafRBVfPAVW8rFbTFWJrxkBn+UWJRJQxbNMNEDG2M ojrVyHjjLTTejEeT6NxWklPf+9pM5WfwehqH0= MIME-Version: 1.0 Received: by 10.211.129.20 with SMTP id g20mr4694467ebn.14.1255950057894; Mon, 19 Oct 2009 04:00:57 -0700 (PDT) In-Reply-To: <4AD894BE.30501@uci.edu> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <4AD894BE.30501@uci.edu> Date: Mon, 19 Oct 2009 12:00:57 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00504502ce400e7280047647a956 Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 11:00:58 -0000 --00504502ce400e7280047647a956 Content-Type: text/plain; charset=ISO-8859-1 +1 Sean! I've really been enthused and heartened by the rapid progress in Opensim on such a wide variety of fronts, including multiple forms of interop. Anyone who's been keeping a finger on the pulse of what's happening in virtual worlds today can see the pent-up desire for having your own virtual worlds and allowing good interop between them. Undoubtedly there is a need for restrictive worlds as well (often required for business or education), and here we are of course embracing their needs as much as the needs of people who wish to enjoy a high degree of inter-world travel. No party is being excluded in VWRAP. By focussing on the services that can be put together in a variety of useful deployment patterns, anyone can configure a world to their own specification and interoperate with other worlds in accordance with their own chosen policies. This includes both ends of the spectrum, and points between. As you say, the tourist model is completely realistic, and indeed it is demanded widely. Morgaine. =================================== On Fri, Oct 16, 2009 at 4:43 PM, Sean Hennessee wrote: > Meadhbh Hamrick wrote: > >> On Fri, Oct 16, 2009 at 1:51 AM, Morgaine >> wrote: >> >>> On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick) >>> wrote: >>> >>> also. just a show of hands. who's planning on implementing the tourist >>>> model? >>>> >>> Almost everybody who will operate virtual worlds, I assume --- that could >>> be >>> hundreds of thousands of world operators, if not millions, mostly small. >>> We >>> certainly can't foretell! And we can't get them to raise a show of hands >>> either. :-) >>> >> >> you mean you think they're all going to be implementing their own >> software? i think that's unrealistic. even with the http servers, >> which i think we could agree is slightly less complicated than any >> virtual world protocol would be, web site operators use one of a >> handful of implementations: (Apache, IIS, WebSTAR?, ...) >> > > I think this is completely realistic. With the progress that OpenSim is > making towards standalone (SL Like) grids, there will very likely be > services popping up all over the interweb providing standalone virtual > worlds for free or at a very low cost, much like services today provide blog > spaces, photo spaces, and a host of other web based services for free and > for fee. I don't have to host my own Apache web server just to have a > tumblr.com blog or a flickr.com photo site. The blog and photo site of the > future will be SL like virtual worlds, (or perhaps more accurately, "virtual > homes"). > > I doubt that it will be common to operate walled gardens once everyone >>> else >>> is allowing their users to travel freely among the huge diversity of the >>> metaverse. It certainly seems like a recipe for failure to deny tourism >>> to >>> one's residents as a matter of policy, given that tourism is so popular >>> in >>> the physical world today. >>> >> >> well. the examples of large virtual worlds that exist today are, as >> you call them, walled gardens. >> > > This is only because the idea of treating your "virtual home" as its' own > space that can have "virtual tourists" come and visit is only now being > implemented in OpenSim with standalones and hypergrids. In the past the > focus was more on creating a system too much like SL in the sense that SL is > one huge virtual world. I would assume that "SL Like" implies the 3d > experience that is SL and not also the hugeness that is SL. > > Peace, > Sean > > >> However, this is a policy issue of course, and therefore not something >>> that >>> VWRAP will dictate. We merely provide the mechanisms to allow tourism >>> when >>> desired, not mandate or deny it to any given world operator. >>> >> >> i think it _is_ definitely important. we've set dates for the >> publication of standard documentations, and i think it's unrealistic >> to say that we are going to develop a standard that is infinitely >> flexible. we will need to focus on a small collection of deployment >> models. again, i have no problem including models that _will_ actually >> be used. i'm just not sure it behooves us to spend a fair amount of >> time ensuring our protocol flows work in deployment models that no one >> is currently planning on deploying. >> >> there's very clearly interest from linden for the "second life" [1] >> deployment model; intel has show a clear interest in the "cable beach" >> deployment model; OpenSim's UGAIM/Grid Mode and standalone deployment >> models. i'm just curious who is going to be coding software for the >> "tourist model." >> >> -cheers. >> -meadhbh/infinity >> > > -- > > Sean Hennessee > Central Computing Support > Office of Information Technology > UC Irvine > > > ... . .- -. / .... . -. -. . ... ... . . > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --00504502ce400e7280047647a956 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 Sean!

I've really been enthused and heartened by the rapid pr= ogress in Opensim on such a wide variety of fronts, including multiple form= s of interop.

Anyone who's been keeping a finger on the pulse of= what's happening in virtual worlds today can see the pent-up desire fo= r having your own virtual worlds and allowing good interop between them.=A0= Undoubtedly there is a need for restrictive worlds as well (often required= for business or education), and here we are of course embracing their need= s as much as the needs of people who wish to enjoy a high degree of inter-w= orld travel.

No party is being excluded in VWRAP.=A0 By focussing on the services th= at can be put together in a variety of useful deployment patterns, anyone c= an configure a world to their own specification and interoperate with other= worlds in accordance with their own chosen policies.=A0 This includes both= ends of the spectrum, and points between.

As you say, the tourist model is completely realistic, and indeed it is= demanded widely.


Morgaine.






=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

On Fri, Oct 16, 200= 9 at 4:43 PM, Sean Hennessee <sean@uci.edu> wrote:
Meadhbh Hamr= ick wrote:
On Fri, Oct 16, 2009 at 1:51 AM, Morgaine
<mor= gaine.dinova@googlemail.com> wrote:
On Fri, Oct 16, 2009 at 9:16 AM, Infinity Linden (Meadhbh Hamrick)
<infinity@li= ndenlab.com> wrote:

also. just a show of hands. who's planning on implementing the tourist<= br> model?
Almost everybody who will operate virtual worlds, I assume --- that could b= e
hundreds of thousands of world operators, if not millions, mostly small. = =A0We
certainly can't foretell! =A0And we can't get them to raise a show = of hands
either. :-)

you mean you think they're all going to be implementing their own
software? i think that's unrealistic. even with the http servers,
which i think we could agree is slightly less complicated than any
virtual world protocol would be, web site operators use one of a
handful of implementations: (Apache, IIS, WebSTAR?, ...)

I think this is completely realistic. With the progress that OpenSim is mak= ing towards standalone (SL Like) grids, there will very likely be services = popping up all over the interweb providing standalone virtual worlds for fr= ee or at a very low cost, much like services today provide blog spaces, pho= to spaces, and a host of other web based services for free and for fee. I d= on't have to host my own Apache web server just to have a tumblr.com blog or a flickr.com photo site. The blog and ph= oto site of the future will be SL like virtual worlds, (or perhaps more acc= urately, "virtual homes").


I doubt that it will be common to operate walled gardens once everyone else=
is allowing their users to travel freely among the huge diversity of the metaverse. =A0It certainly seems like a recipe for failure to deny tourism = to
one's residents as a matter of policy, given that tourism is so popular= in
the physical world today.

well. the examples of large virtual worlds that exist today are, as
you call them, walled gardens.

This is only because the idea of treating your "virtual home" as = its' own space that can have "virtual tourists" come and visi= t is only now being implemented in OpenSim with standalones and hypergrids.= In the past the focus was more on creating a system too much like SL in th= e sense that SL is one huge virtual world. I would assume that "SL Lik= e" implies the 3d experience that is SL and not also the hugeness that= is SL.

Peace,
Sean



However, this is a policy issue of course, and therefore not something that=
VWRAP will dictate. =A0We merely provide the mechanisms to allow tourism wh= en
desired, not mandate or deny it to any given world operator.

i think it _is_ definitely important. we've set dates for the
publication of standard documentations, and i think it's unrealistic to say that we are going to develop a standard that is infinitely
flexible. we will need to focus on a small collection of deployment
models. again, i have no problem including models that _will_ actually
be used. i'm just not sure it behooves us to spend a fair amount of
time ensuring our protocol flows work in deployment models that no one
is currently planning on deploying.

there's very clearly interest from linden for the "second life&quo= t; [1]
deployment model; intel has show a clear interest in the "cable beach&= quot;
deployment model; OpenSim's UGAIM/Grid Mode and standalone deployment models. i'm just curious who is going to be coding software for the
"tourist model."

-cheers.
-meadhbh/infinity

--

Sean Hennessee
Central Computing Support
Office of Information Technology
UC Irvine


... . .- -. / =A0.... . -. -. . ... ... . .

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--00504502ce400e7280047647a956-- From morgaine.dinova@googlemail.com Mon Oct 19 04:04:42 2009 Return-Path: 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 0EEAE3A67AC for ; Mon, 19 Oct 2009 04:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.324 X-Spam-Level: X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=0.652, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 8mGEo+EeWk1O for ; Mon, 19 Oct 2009 04:04:40 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 323253A681B for ; Mon, 19 Oct 2009 04:04:40 -0700 (PDT) Received: by ewy28 with SMTP id 28so4269101ewy.42 for ; Mon, 19 Oct 2009 04:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=/O3wx2dFaX7hT3gPKw+EdChMXZ/yn2ySLzqwZLb5zD0=; b=bYoiJN2xjL2gqkJQpFFhx7LpTJWppQLArUYZyOAO5SnZOfOZ7tvbeq0J7VPsWKFW6E /fP45SxnryRlaHfW8o1KnGy/IiklvSHqs9rHNy3ljlUr6r/NbwZTzfI0Q6LF71Bp/qir whYwTEhgUbwkRUnaGMAs0Zo0Az4HOkHcO/Ris= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=WFXRtM2Ryb153CIF7gtHhqious+5fBqrGQoLug2DJUl0PKxq0boqsJkoGFRYIeyHS8 ZY0IzN1nC+v36lR6E3k+4axfzu1l7u08N7e+2gEUgsi5runvk/5NOtaZ814KO5c/54EL jrCjy48KBA3AOthjKin3VtIhLYVtVzk1059QY= MIME-Version: 1.0 Received: by 10.211.131.34 with SMTP id i34mr5333328ebn.35.1255950283083; Mon, 19 Oct 2009 04:04:43 -0700 (PDT) In-Reply-To: <4AD903F3.6080809@cox.net> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <4AD903F3.6080809@cox.net> Date: Mon, 19 Oct 2009 12:04:42 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636c5ba2f7a90b8047647b6ff Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 11:04:42 -0000 --001636c5ba2f7a90b8047647b6ff Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 17, 2009 at 12:38 AM, Lawson English wrote: > > It seems to me that the MOST touristy mode we will ever see is the > free-for-all from the original OGP test where simple TP and naught else was > supported. > There was no "free-for-all" interop in the original OGP test: there was merely TP from an SL grid to several separately-administered sims, with no framework in place for such sims to express their independent policies, nor any design for such a framework. This was unable to support a tourism model at all since that requires DDP otherwise travellers from multiple worlds having distinct policies can't meet up in a common tourist resort. It was very far indeed from a free-for-all. In fact it was much more like a plan for region assimilation by an advancing empire. ;-) All it could ever do is build walled gardens. Your comment also needs to be examined in another light. "The MOST touristy mode we will ever see" *from whom*? Your words seem to presuppose that only the deployments by the current majority provider are relevant. It's important not to confuse what an individual world provider such as LL will do, and what the whole set of deployers of the protocol will do. If we are successful in specifying VWRAP services flexibly as envisaged by David, we can expect all the possible deployment patterns to be exercised to different degrees across the breadth of the Internet by many different providers and many individuals. More specifically, it is reasonable to assume that the Opensim developers, deployers and users who are present in the workgroup are here because they believe that the protocol can be designed in a manner that is useful to their intended interop and world models. They're already working on various kinds of open interop model, with or without VWRAP, so the need to support tourism flexibly is not just a theory. If we do a good job and VWRAP becomes an effective means of implementing the kind of interop that the very broad Opensim-based community finds useful, then there is every likelihood that the high-tourism deployments will become very popular indeed, *in that community*. That's my answer to the *from whom* question. People want to travel to far-off places, in virtual worlds as much as in the physical world. This desire is fueled by world *diversity*, not by seeing more of the same thing within one's own world alone. We can reasonably expect this to make tourism between independent worlds hugely attractive, even exciting, and hence popular. Morgaine. ====================================== On Sat, Oct 17, 2009 at 12:38 AM, Lawson English wrote: > Meadhbh Hamrick wrote: > >> but didn't we say that we were going to focus on "second life-like" >> worlds in this WG? isn't that why it was formed? shouldn't the tourist >> model be an effort of the MMOX group? i thought that was the reason we >> kept the MMOX mailing list up, so work could continue on that type of >> virtual world. >> >> -meadhbh/infinity >> >> > > It seems to me that the MOST touristy mode we will ever see is the > free-for-all from the original OGP test where > simple TP and naught else was supported. > > Will all worlds be willing to support that one? Obviously not (e.g > firewalled corporate site), but I think many will, including LL on the PG > section of its main grid. > > > Lawson > --001636c5ba2f7a90b8047647b6ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 17, 2009 at 12:38 AM, Lawson English <lenglish5@cox.net>= ; wrote:
It seems to me that the MOST touristy mode we will ever see is the free-for= -all from the original OGP test where simple TP and naught else was support= ed.


There was no "free-for-all" interop in the o= riginal OGP test:=A0 there was merely TP from an SL grid to several separat= ely-administered sims, with no framework in place for such sims to express = their independent policies, nor any design for such a framework.=A0 This wa= s unable to support a tourism model at all since that requires DDP otherwis= e travellers from multiple worlds having distinct policies can't meet u= p in a common tourist resort.=A0 It was very far indeed from a free-for-all= .=A0 In fact it was much more like a plan for region assimilation by an adv= ancing empire. ;-)=A0 All it could ever do is build walled gardens.

Your comment also needs to be examined in another light.=A0 "The M= OST touristy mode we will ever see" from whom?=A0 Your w= ords seem to presuppose that only the deployments by the current majority p= rovider are relevant.

It's important not to confuse what an individual world provider suc= h as LL will do, and what the whole set of deployers of the protocol will d= o.=A0 If we are successful in specifying VWRAP services flexibly as envisag= ed by David, we can expect all the possible deployment patterns to be exerc= ised to different degrees across the breadth of the Internet by many differ= ent providers and many individuals.

More specifically, it is reasonable to assume that the Opensim develope= rs, deployers and users who are present in the workgroup are here because t= hey believe that the protocol can be designed in a manner that is useful to= their intended interop and world models.=A0 They're already working on= various kinds of open interop model, with or without VWRAP, so the need to= support tourism flexibly is not just a theory.

If we do a good job and VWRAP becomes an effective means of implementin= g the kind of interop that the very broad Opensim-based community finds use= ful, then there is every likelihood that the high-tourism deployments will = become very popular indeed, in that community.=A0 That's my answ= er to the from whom question.

People want to travel to far-off places, in virtual worlds as much as i= n the physical world.=A0 This desire is fueled by world diversity, n= ot by seeing more of the same thing within one's own world alone.=A0 We= can reasonably expect this to make tourism between independent worlds huge= ly attractive, even exciting, and hence popular.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

On Sat, Oct 17, 2009 at 12:38 AM, = Lawson English <lenglish5@cox.net> wrote:
Meadhbh Hamr= ick wrote:
but didn't we say that we were going to focus on "second life-like= "
worlds in this WG? isn't that why it was formed? shouldn't the tour= ist
model be an effort of the MMOX group? i thought that was the reason we
kept the MMOX mailing list up, so work could continue on that type of
virtual world.

-meadhbh/infinity
=A0

It seems to me that the MOST touristy mode we will ever see is the free-for= -all from the original OGP test where
simple TP and naught else was supported.

Will all worlds be willing to support that one? Obviously not (e.g firewall= ed corporate site), but I think many will, including LL on the PG
section of its main grid.


Lawson

--001636c5ba2f7a90b8047647b6ff-- From morgaine.dinova@googlemail.com Mon Oct 19 04:36:58 2009 Return-Path: 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 BFF9E3A6862 for ; Mon, 19 Oct 2009 04:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 DqNMVEIlYGuB for ; Mon, 19 Oct 2009 04:36:57 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id DBD983A6952 for ; Mon, 19 Oct 2009 04:36:56 -0700 (PDT) Received: by ewy28 with SMTP id 28so4305457ewy.42 for ; Mon, 19 Oct 2009 04:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=iCrnlyOgE6G0dSJy7FtUxc0Dew6OnbD2GOf4QAf8LgU=; b=I2IeEFrXfK1kZFpB+ZYxBqvneRdeK3CYGrNiUuQ1QfRsSvv8v1NhtTfBJBCgN4KlCc nwSFGrZgSA4RIACEKsQHSZ6uYghhm/Gbl/j+bt+J7yFTOCFJoVy6iDm8tqYMU0NcnTCr ixlGhbMk7CHEmKCQCr7AG+Y8zrRbLlO5RArZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=x/wTbDSM1JXKoCWvKv+RgZa/lLZnn/V0R9N7a7J1KJJeAWZp+ksiWxjayapzKvh+m2 dcDRnHaJRdcRh2mHyVIyAT1M78MZYqlzaf5uK9s2Xg7EKMLZG7A6j+AkmZtV77Btc9sy sjKjV+++NqJjWwNFIwSc+K9lUnGEgbh70PuXY= MIME-Version: 1.0 Received: by 10.211.147.12 with SMTP id z12mr5359701ebn.37.1255952219768; Mon, 19 Oct 2009 04:36:59 -0700 (PDT) In-Reply-To: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> Date: Mon, 19 Oct 2009 12:36:59 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636c5bb4dea08fa04764829e1 Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 11:36:58 -0000 --001636c5bb4dea08fa04764829e1 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca wrote: The second point is actually extending the SL use case beyond what is in my view needed for a basic tourist model (and that is why the post was in the mmox list). In my view a basic tourist use case has two main characteristics: 1. Travel requires no prior arrangement. 2. Agent domains can use external asset services I agree with this, so I have dealt separately in an earlier email with that more ambitious use case (which I'm leaving to MMOX), so that we can pursue this simpler tourist use case here. I think you're very right to identify it as distinct. Point 2 requires that assets services expose an interface (in the current ogp description of the AD that is not the case). Note that this models does *not* assumes that all assets in a services should be useable by the agent in all domains, but only that an interface is available so an asset service in one domain can be contacted by another AD. I think exposing the asset service interface directly is essential for meaningful interop. I agree entirely with your suggestion that the asset service interfaces be exposed. Indeed, I believed this to be implicit in David's breakdown of services anyway, as a natural consequence of service decoupling, but it's good that you're making it explicit. We looked at one aspect of the issue a few weeks ago with Joshua when we examined what would happen when world W1's agent A1 was in W2's RD2. For the visual mashup of assets on the user's screen to work, the agent would need to have access to at least two asset services simultaneously, which gave us a hint of what's to come. It's this exposing of services (asset services in particular) that is going to provide the *Destination Determines [Destination] Policy* principle which allows tourism. It never existed in the original OGP, because there was no mechanism by which regions nor RDs could express their own policy, so all policy expression was through the so-called trust agreements enforced at the AD which gaves access to the seed caps. That essentially boiled down to creating ever-expanding walled garden empires that could never interoperate except through nil-trust. In contrast, now we're solidly on the road to allowing RDs to determine their own policies through their own services, so it's a very different proposition. As David has described, once you have multiple service providers over which individual RDs have policy control, any attempt at making policy non-local is not likely to bear much fruit. That's the key ingredient that allows DD[D]P, and hence tourism. And for that, the service interfaces need to be exposed. So +1. :-) Morgaine. ====================================== On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca wrote: > The "tourist use case" has been brought up several times, but the concept > is not always used in the same way, and needs to be more precisely defined. > > Morgaines original definition of the "Free Worlds Tourist use case" in > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html > mentions two characteristics: > > 1. Travel requires no prior arrangement. > 2. Your avatar is defined by you, not by the target worlds, and it > appears in those worlds with no prior arrangement. > > Point 1 is only dependent the policies of the users AD as well as that of > the destination region. It is not dependent on the protocol, so in principle > solved. > > The second point is actually extending the SL use case beyond what is in my > view needed for a basic tourist model (and that is why the post was in the > mmox list). In my view a basic tourist use case has two main > characteristics: > > 1. Travel requires no prior arrangement. > 2. Agent domains can use external asset services > > Point 2 requires that assets services expose an interface (in the current > ogp description of the AD that is not the case). > > Note that this models does *not* assumes that all assets in a services > should be useable by the agent in all domains, but only that an interface is > available so an asset service in one domain can be contacted by another AD. > > I think exposing the asset service interface directly is essential for > meaningful interop. I think it would benefit the discussion if some > diagrams were added to http://wiki.secondlife.com/wiki/Structural_Designand/or to the VWRAP wiki to document this possibility. > > -Vaughn > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --001636c5bb4dea08fa04764829e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca <vaughn.deluca@gmail.= com> wrote:

The second point is actually extending the SL use case beyond what is in my view needed for a basic tourist model (and that is why the post was in the mmox list). =A0In my view =A0a basic tourist use case has two main characteristics:

1. =A0Travel requires no prior= arrangement.
=A0=A0 =A0 =A0 =A02. = =A0Agent domains can use external asset services


I agree with this, so I have dealt separately in an earlier email w= ith that more ambitious use case (which I'm leaving to MMOX), so that w= e can pursue this simpler tourist use case here.=A0 I think you're very= right to identify it as distinct.


Point 2 requires that assets services expose an interface (in the current o= gp description of the AD that is not the case).=A0

Note that this models does *not* assumes that all assets in a services should be useable by the agent in all domains, but only that an interface is available so an asset service in one domain can be contacted by another AD.=A0

I think exposing the asset service interface directly is essential for m= eaningful interop.



I agree entirely with your suggesti= on that the asset service interfaces be exposed.=A0 Indeed, I believed this to be implicit in David's breakd= own of services anyway, as a natural consequence of service decoupling, but it's good that you're making it explicit.

We looked at one aspect of the issue a few weeks ago with Joshua when w= e examined what would happen when world W1's agent A1 was in W2's R= D2.=A0 For the visual mashup of assets on the user's screen to work, th= e agent would need to have access to at least two asset services simultaneo= usly, which gave us a hint of what's to come.

It's this exposing of services (asset services in particular) that = is going to provide the Destination Determines [Destination] Policy = principle which allows tourism.=A0 It never existed in the original OGP, be= cause there was no mechanism by which regions nor RDs could express their o= wn policy, so all policy expression was through the so-called trust agreeme= nts enforced at the AD which gaves access to the seed caps.=A0 That essenti= ally boiled down to creating ever-expanding walled garden empires that coul= d never interoperate except through nil-trust.

In contrast, now we're solidly on the road to allowing RDs to deter= mine their own policies through their own services, so it's a very diff= erent proposition.=A0 As David has described, once you have multiple servic= e providers over which individual RDs have policy control, any attempt at m= aking policy non-local is not likely to bear much fruit.=A0 That's the = key ingredient that allows DD[D]P, and hence tourism.

And for that, the service interfaces need to be exposed.=A0 So +1. :-)<= br>

Morgaine.







=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

On Fri, Oct 16, 2009 a= t 8:34 AM, Vaughn Deluca <vaughn.deluca@gmail.com> wro= te:
The "to= urist use case" has been brought up several times, but the concept is = not always used in the same way, and needs to be more precisely defined.

Morgaines original definition of the "Free Worlds = Tourist use case"=A0in http://www.ietf.org/mail-arc= hive/web/mmox/current/msg01392.html
mentions two characteristics:

1. Trav= el requires no prior arrangement.
2. Your avatar is defined by you, not by the target worlds, an= d it appears in those worlds with no prior arrangement.=A0

Point 1 is only dependent the policies of the users AD = as well as that of the destination region. It is not dependent on the proto= col, so in principle solved.

The second point is a= ctually extending the SL use case beyond what is in my view needed for a ba= sic tourist model (and that is why the post was in the mmox list). =A0In my= view =A0a basic tourist use case has two main characteristics:

1. =A0Travel = requires no prior arrangement.
=A0=A0 =A0 =A0 =A02. =A0Agent doma= ins can use external asset services

Point 2 requir= es that assets services expose an interface (in the current ogp description= of the AD that is not the case).=A0

Note that this models does *not* assumes that all asset= s in a services should be useable by the agent in all domains, but only tha= t an interface is available so an asset service in one domain can be contac= ted by another AD.=A0

I think exposing the asset service interface directly i= s essential for meaningful interop. =A0I think it would benefit the discuss= ion if some diagrams were added to http://wiki.secondlife.com/wiki/Str= uctural_Design and/or to the VWRAP wiki to document this possibility.

-Vaughn

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--001636c5bb4dea08fa04764829e1-- From lenglish5@cox.net Mon Oct 19 10:51:45 2009 Return-Path: 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 11DDB3A681E for ; Mon, 19 Oct 2009 10:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_05=-1.11, MISSING_HEADERS=1.292] 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 VKxZ0ToZ+4k5 for ; Mon, 19 Oct 2009 10:51:44 -0700 (PDT) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id 288843A67EC for ; Mon, 19 Oct 2009 10:51:41 -0700 (PDT) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao103.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20091019175147.ZIVI11920.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net> for ; Mon, 19 Oct 2009 13:51:47 -0400 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo01.cox.net with bizsmtp id uhrn1c00L2l1Ksg03hroN8; Mon, 19 Oct 2009 13:51:48 -0400 X-VR-Score: -70.00 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=kviXuzpPAAAA:8 a=eaLIYhk0euBL7kPy250A:9 a=VelZWnnQZ3PoVE7Uy0EA:7 a=ezeLcsIWP2-kGjMwr8D3pH7EhEMA:4 a=4vB-4DCPJfMA:10 X-CM-Score: 0.00 Message-ID: <4ADCA733.8010402@cox.net> Date: Mon, 19 Oct 2009 10:51:47 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 CC: ogpx@ietf.org References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <4AD903F3.6080809@cox.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 17:51:45 -0000 Morgaine wrote: > On Sat, Oct 17, 2009 at 12:38 AM, Lawson English > wrote: > > > It seems to me that the MOST touristy mode we will ever see is the > free-for-all from the original OGP test where simple TP and naught > else was supported. > > > > There was no "free-for-all" interop in the original OGP test: there > was merely TP from an SL grid to several separately-administered sims, > with no framework in place for such sims to express their independent > policies, nor any design for such a framework. This was unable to > support a tourism model at all since that requires DDP otherwise > travellers from multiple worlds having distinct policies can't meet up > in a common tourist resort. It was very far indeed from a > free-for-all. In fact it was much more like a plan for region > assimilation by an advancing empire. ;-) All it could ever do is > build walled gardens. Since the test required no agreements of any kind, but merely announcing the relative position of the sim on the grid to avoid technical issues with overlapping coordinates, I'm not sure how you can say that it was NOT a free-for-all. With no room for policy implementation, there's no policy period. > > Your comment also needs to be examined in another light. "The MOST > touristy mode we will ever see" /*from whom*/? Your words seem to > presuppose that only the deployments by the current majority provider > are relevant. I would HOPE that any tourism mode that is implemented in the future by some provider for interop between two or more separate services will provide more than a default avatar with no asset sharing, no policy agreements, no appearance sharing, no nuttin'. Are you implying that we will see LESS features in a future service from someone or another? How low can we go? Tourism mode is, in my mind, the lowest common denominator of services that a minimal VWAP protocol will support. > > It's important not to confuse what an individual world provider such > as LL will do, and what the whole set of deployers of the protocol > will do. If we are successful in specifying VWRAP services flexibly > as envisaged by David, we can expect all the possible deployment > patterns to be exercised to different degrees across the breadth of > the Internet by many different providers and many individuals. Well, no policy agreement, no money, no assets, no individual appearance, etc., seems like a pretty low bar to shoot for. I hope that the most minimal VWRAP definition will include at least as much as the original OGP test provided. Lawson (Saijanai ISL) From morgaine.dinova@googlemail.com Mon Oct 19 12:33:32 2009 Return-Path: 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 9303328C10E for ; Mon, 19 Oct 2009 12:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.386 X-Spam-Level: X-Spam-Status: No, score=-1.386 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 1x05rSro4-mO for ; Mon, 19 Oct 2009 12:33:31 -0700 (PDT) Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 7FD9028C128 for ; Mon, 19 Oct 2009 12:33:27 -0700 (PDT) Received: by ewy28 with SMTP id 28so4939700ewy.42 for ; Mon, 19 Oct 2009 12:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=LgWUnLBHgv/LsHkrzaSZUIQ6NufhvSzkB+L7OmECU8g=; b=h3xsCp5Wdeq2cwOmEzJtCRbte3fYHtfrCXmUUr7R6+PVo90XznaQdUgm/vPmk47dae CnaaQjPhm3+NMs61hexDKm97f2bonbFlAaZtAoH4JfjhCJrpCpDMoiu6KTg8zqtnsAkG lGRjOe8GkTPNf30Hg7sPKsGUAABnlcwYrQ4uo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=OylQw8UOCk+DNUGdDZPPq3FWoHcBbYNpt3e7iDwbxecVfa2UPEuBZTOZOEd8cdn0RX G8h4zRxKaIAkEMgQYw25mSMKCyT9/79wcRm2c3hBSaBkTwBvgFScCtrVWsGsrBDUx2ZA WPGlIlfF1pTfIJAjH2TCR/k7uOh/M4YaOUg+k= MIME-Version: 1.0 Received: by 10.211.161.16 with SMTP id n16mr6045346ebo.20.1255980810970; Mon, 19 Oct 2009 12:33:30 -0700 (PDT) In-Reply-To: <4ADCA733.8010402@cox.net> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <4AD903F3.6080809@cox.net> <4ADCA733.8010402@cox.net> Date: Mon, 19 Oct 2009 20:33:30 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636c5bf0c15271704764ed204 Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 19:33:32 -0000 --001636c5bf0c15271704764ed204 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 19, 2009 at 6:51 PM, Lawson English wrote: > > Since the test required no agreements of any kind, but merely announcing > the relative position of the sim on the grid to avoid technical issues with > overlapping coordinates, I'm not sure how you can say that it was NOT a > free-for-all. With no room for policy implementation, there's no policy > period. > Policy was established by the AD controlling the authentication and being the only source of seed caps. No interop was possible *except* that allowed by the AD. That's a "free-for-all" where only one side has any say, which is quite the opposite of the usual meaning of "free-for-all". :-) > > I would HOPE that any tourism mode that is implemented in the future by > some provider for interop between two or more separate services will provide > *more* than a default avatar with no asset sharing, no policy agreements, > no appearance sharing, no nuttin'. Are you implying that we will see LESS > features in a future service from someone or another? How low can we go? > Tourism mode is, in my mind, the lowest common denominator of services that > a minimal VWAP protocol will support. That's confusing the word "more" as meaning "implementing services that were missing in the OGP trial" with the word "more" as meaning "allowing the RD to determine its own region policy". The first is a given. The second was not in the OGP design at all. With the old OGP model in which the only source of seed caps was the AD, it would have changed nothing if the RD had provided additional services, because the agent would have had no access to them. The AD's policy control was *total*. As such, no foreign tourism would have been possible at all, only travel within one's own world of regions authenticated by the same AD. This is because the regions in the intersection between N such AD-controlled worlds is the empty set, except under nil trust. That was very different to the inter-world tourism that we've been talking about here for several weeks now, in which RDs are in effect sections of autonomous worlds each with their own region policies determined by their own asset services and other services which they proxy from their own AD. > > Well, no policy agreement, no money, no assets, no individual appearance, > etc., seems like a pretty low bar to shoot for. I hope that the most minimal > VWRAP definition will include at least as much as the original OGP test > provided. > I think that we're aiming for a bit more than that. ;-) Morgaine. ======================================= On Mon, Oct 19, 2009 at 6:51 PM, Lawson English wrote: > Morgaine wrote: > >> On Sat, Oct 17, 2009 at 12:38 AM, Lawson English > lenglish5@cox.net>> wrote: >> >> >> It seems to me that the MOST touristy mode we will ever see is the >> free-for-all from the original OGP test where simple TP and naught >> else was supported. >> >> >> >> There was no "free-for-all" interop in the original OGP test: there was >> merely TP from an SL grid to several separately-administered sims, with no >> framework in place for such sims to express their independent policies, nor >> any design for such a framework. This was unable to support a tourism model >> at all since that requires DDP otherwise travellers from multiple worlds >> having distinct policies can't meet up in a common tourist resort. It was >> very far indeed from a free-for-all. In fact it was much more like a plan >> for region assimilation by an advancing empire. ;-) All it could ever do is >> build walled gardens. >> > > > Since the test required no agreements of any kind, but merely announcing > the relative position of the sim on the grid to avoid technical issues with > overlapping coordinates, I'm not sure how you can say that it was NOT a > free-for-all. With no room for policy implementation, there's no policy > period. > >> >> Your comment also needs to be examined in another light. "The MOST >> touristy mode we will ever see" /*from whom*/? Your words seem to >> presuppose that only the deployments by the current majority provider are >> relevant. >> > > I would HOPE that any tourism mode that is implemented in the future by > some provider for interop between two or more separate services will provide > more than a default avatar with no asset sharing, no policy agreements, no > appearance sharing, no nuttin'. Are you implying that we will see LESS > features in a future service from someone or another? How low can we go? > Tourism mode is, in my mind, the lowest common denominator of services that > a minimal VWAP protocol will support. > > >> It's important not to confuse what an individual world provider such as LL >> will do, and what the whole set of deployers of the protocol will do. If we >> are successful in specifying VWRAP services flexibly as envisaged by David, >> we can expect all the possible deployment patterns to be exercised to >> different degrees across the breadth of the Internet by many different >> providers and many individuals. >> > > Well, no policy agreement, no money, no assets, no individual appearance, > etc., seems like a pretty low bar to shoot for. I hope that the most minimal > VWRAP definition will include at least as much as the original OGP test > provided. > > > > > Lawson (Saijanai ISL) > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --001636c5bf0c15271704764ed204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 19, 2009 at 6:51 PM, Lawson English <lenglish5@cox.net> wrote:
=

Since the test required no agreements of any kind, but merely announcing the relative position of the sim on the grid to avoid technical issues with overlapping coordinates, I'm not sure how you can say that it was NOT a free-for-all. With no room for policy implementation, there's no policy period.


Policy was established by the AD controlling the auth= entication and being the only source of seed caps.=A0 No interop was possib= le except that allowed by the AD.=A0 That's a "free-= for-all" where only one side has any say, which is quite the opposite = of the usual meaning of "free-for-all". :-)

=A0
I would HOPE that any tourism mode that is implemented in the future by some provider for interop between two or more separate services will provide more than a default avatar with no asset sharing, no policy agreements, no appearance sharing, no nuttin'. Are you implying that we will see LESS features in a future service from someone or another? How low can we go? Tourism mode is, in my mind, the lowest common denominator of services that a minimal VWAP protocol will support.


That's confusing the word "more" as meaning "implementin= g services that were missing in the OGP trial" with the word "mor= e" as meaning "allowing the RD to determine its own region policy= ".=A0 The first is a given.=A0 The second was not in the OGP design at= all.

With the old OGP model in which the only source of seed caps was the AD= , it would have changed nothing if the RD had provided additional services,= because the agent would have had no access to them.=A0 The AD's policy= control was total.=A0 As such, no foreign tourism would have= been possible at all, only travel within one's own world of regions au= thenticated by the same AD.=A0 This is because the regions in the intersect= ion between N such AD-controlled worlds is the empty set, except under nil = trust.

That was very different to the inter-world tourism that we've been = talking about here for several weeks now, in which RDs are in effect sectio= ns of autonomous worlds each with their own region policies determined by t= heir own asset services and other services which they proxy from their own = AD.

=A0
Well, no policy agreement, no money, no assets, no individual appearance, etc., seems like a pretty low bar to shoot for. I hope that the most minimal VWRAP definition will include at least as much as the original OGP test provided.


I think that we're aiming for a bit more than that. ;-)

Morgaine.







=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

On Mon, Oct 19, 2009 at 6:51= PM, Lawson English <lenglish5@cox.net> wrote:
Morgaine wrote:
On Sat, Oct 17, 2009 at 12:38 AM, Lawson English <lenglish5@cox.net <mailto:lenglish5@cox.net>&g= t; wrote:


=A0 =A0It seems to me that the MOST touristy mode we will ever see is the<= br> =A0 =A0free-for-all from the original OGP test where simple TP and naught<= br> =A0 =A0else was supported.



There was no "free-for-all" interop in the original OGP test: =A0= there was merely TP from an SL grid to several separately-administered sims= , with no framework in place for such sims to express their independent pol= icies, nor any design for such a framework. =A0This was unable to support a= tourism model at all since that requires DDP otherwise travellers from mul= tiple worlds having distinct policies can't meet up in a common tourist= resort. =A0It was very far indeed from a free-for-all. =A0In fact it was m= uch more like a plan for region assimilation by an advancing empire. ;-) = =A0All it could ever do is build walled gardens.


Since the test required no agreements of any kind, but merely announcing th= e relative position of the sim on the grid to avoid technical issues with o= verlapping coordinates, I'm not sure how you can say that it was NOT a = free-for-all. With no room for policy implementation, there's no policy= period.


Your comment also needs to be examined in another light. =A0"The MOST = touristy mode we will ever see" /*from whom*/? =A0Your words seem to p= resuppose that only the deployments by the current majority provider are re= levant.

I would HOPE that any tourism mode that is implemented in the future by som= e provider for interop between two or more separate services will provide m= ore than a default avatar with no asset sharing, no policy agreements, no a= ppearance sharing, no nuttin'. Are you implying that we will see LESS f= eatures in a future service from someone or another? How low can we go? Tou= rism mode is, in my mind, the lowest common denominator of services that a = minimal VWAP protocol will support.



It's important not to confuse what an individual world provider such as= LL will do, and what the whole set of deployers of the protocol will do. = =A0If we are successful in specifying VWRAP services flexibly as envisaged = by David, we can expect all the possible deployment patterns to be exercise= d to different degrees across the breadth of the Internet by many different= providers and many individuals.

Well, no policy agreement, no money, no assets, no individual appearance, e= tc., seems like a pretty low bar to shoot for. I hope that the most minimal= VWRAP definition will include at least as much as the original OGP test pr= ovided.




Lawson (Saijanai ISL)

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--001636c5bf0c15271704764ed204-- From morgaine.dinova@googlemail.com Fri Oct 23 09:47:04 2009 Return-Path: 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 5222F3A697A for ; Fri, 23 Oct 2009 09:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_UNSUB18=0.131] 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 OXFbCywVmd9G for ; Fri, 23 Oct 2009 09:47:02 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id D5C703A68B8 for ; Fri, 23 Oct 2009 09:47:01 -0700 (PDT) Received: by mail-ew0-f208.google.com with SMTP id 4so1809445ewy.37 for ; Fri, 23 Oct 2009 09:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=GGy6/fdxKgbSFGQlBK9GOA/XZQsExMXAGxm+D0LuzOM=; b=byV0hE+k5Qe8HCMQYkUe7BVc4FdKo1XRkC7VDfGBVyoO/P+uiVQq8tnahUV645yrOd wCh9AMUjKuIQafga9pmR4briOLHQYp8ahOU+CcA7u0IHRpGAiK48rIezJLMwWnEcjAKp RKfNsIYzh9+gWzuNUomy0OiMl1FZtKD6hLgF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=yCpnuzLPJ71ZAGH6hOsa/inX59O/u+SHd4fLeTXopLwhyUgXgFZLIJoP6WGx0kpbGn i0Ma/MeMqcVBSfHfe5AGpItKBXYTvEtdNFtv4NotPhzf0ceu8h9XbcRcvomE31QAlztg nSTZBEoBVtlj4+W7XwClbU4BA3uzt3vGpjz+M= MIME-Version: 1.0 Received: by 10.211.174.10 with SMTP id b10mr273743ebp.39.1256316432700; Fri, 23 Oct 2009 09:47:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Oct 2009 17:47:12 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00504502c64eb2550104769cf6ce Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 16:47:04 -0000 --00504502c64eb2550104769cf6ce Content-Type: text/plain; charset=ISO-8859-1 Looking back at the replies in this thread, I think that the goal and the means to achieve it didn't quite come across. I was trying to address only a very specific issue, just protocol resilience under source region non-responsiveness, since this is common enough that it merits addressing. I did not suggest that there be any perceivable change of teleport semantics under normal operation (because no such change is needed), only a change in service coupling. The semantics we experience in SL and in Opensim would remain completely unchanged, except in the single case of source region non-responsiveness. Under this single anomalous case there *would* be a perceivable change, but that change would be a huge improvement. There would be no new decoherence introduced since exactly the same state changes would occur on TP as before, with no possibiity of agent state change in the source region once the AD accepts the TP. All that's needed to achieve such resilience for teleport at the protocol level is a slight revision of operation phasing to permit greater execution overlap, as I outlined. This is independent of anything else that happens in the course of the overall teleport operation --- the change of phasing would affect only the transfer of *agent location* alone, nothing else. In particular, it should not be confused with the separate requirement for instantiation of assets or objects at destination, nor with the matter of serializing and deserializing script states. The latter has not even been defined for VWRAP, so it's hard to talk about changing it. In any event, this isn't about those aspects of teleport, and doesn't affect them --- they would continue to work as before. One of the central aspects of VWRAP is that the protocol is based on a multiple services model, and one of the key approaches in highly scalable systems design is to keep services decoupled to the largest extent possible. That's what I'm proposing here, a *partial decoupling* that has no normal semantic change but which does have benefits in anomalous situations. Agent location change *can* be decoupled significantly from asset instantiation change and script state transfer. My suggestion referred to this decoupled *agent location change* only, not to asset and simulation services. Those other two services undergo state transitions at the same time as change of agent location does on TP, but services should never be coupled together unnecessarily, and in this case the coupling can be left very weak. The three types of service operations can proceed each at their own independent rates, coupled at TP initiation time and nowhere else. It should be noted that the legacy protocols do some of this already, in that the agent is already active in the destination region long before her avatar or objects have appeared. Furthermore, the avatar currently continues to be visible in the source region for a while after the agent becomes active in the destination region, because of normal operation latencies, sim-side queueing, and client lag. This is a normal part of current operation, and is not considered an anomaly. What's important is that no new state change to the agent is possible in the source region after TP is initiated, and that would remain true. The impact of this on the other parts of the puzzle needs to wait until those other parts are examined. We're not there yet, but I would hope that improving teleport protocol resilience would be a desireable goal when the only noticeable change in semantics occurs under fault conditions and provides a major improvement on current behaviour. Morgaine. ====================================== On Tue, Oct 13, 2009 at 6:13 AM, Morgaine wrote: > One of the advantages we have in developing the VWRAP protocols is that we > are able to look back at legacy SL and Opensim protocols and recognize > design mistakes or limitations in them. This allows us to avoid repeating > such mistakes or limitations in the next generation of systems. > > One of the most common sources of frustration and dissatisfaction is > simulator non-responsiveness. While this has many possible causes, in VWRAP > we are not interested in the internal implementation of simulators, but we > *ARE* interested in the ability of a protocol endpoint to perform its duty > within the protocol. A jammed simulator host is in many cases quite unable > to perform its protocol duties, or in some cases only exceedingly slowly, > often timing out in a TP for example. We have a huge amount of experience > of this happening in both SL and Opensim, so it is a practical reality. On > occasion, simulators will be unable to fulfil their part in a protocol, and > this needs to be taken into account because it is *not uncommon*. > > One key area in which the above is relevant is in teleports *OUT* of a > simulator that is under distress. Quite often users wish nothing more than > to *leave* the region being run by a dying simulator, but when > teleport-out requires cooperation from the host that one is trying to leave > then this is often not possible at all. In this situation, the only remedy > in existing systems is to forcibly terminate the client and relog in another > region. We should avoid such out-of-protocol remedies being necessary > through good protocol design. > > In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, which lead > to corresponding protocol operations during teleport. If R1 is a region > being run by a non-responsive simulator from which we want to escape, and R2 > is another region to which we wish to go, if the protocol requires a Derez > in R1 to be completed before a Rez in R2 can commence then the user will > have difficulties. Clearly we don't want this. > > In http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 , it is made > clear that "*The agent domain MUST also remove the avatar from it's > current location before placing the avatar in the destination location*." > This suggests that the protocol will be sensitive to R1 non-responsiveness. > While we do not yet have an actual VWRAP Teleport draft, it seems likely > that its initial incarnation will have that same problem built in. > > I suggest that the protocol define Derez and Rez as *concurrent* and * > non-dependent* operations to avoid this situation. The AD can mark R1 as > disabled for all further agent state changes --- this will provide all the > protection needed to prevent brief double-presence anomalies from being > significant. If a jammed R1 refuses to give up its hold on the avatar, then > at least the user will not suffer from it. Reaping dead simulator sessions > then becomes a problem for the region operator alone, and not for the AD, > the user, and the region as happens now. > > > Morgaine. > > > > --00504502c64eb2550104769cf6ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Looking back at the replies in this thread, I think that the goal and the m= eans to achieve it didn't quite come across.

I was trying to add= ress only a very specific issue, just protocol resilience under source regi= on non-responsiveness, since this is common enough that it merits addressin= g.=A0 I did not suggest that there be any perceivable change of teleport se= mantics under normal operation (because no such change is needed), only a c= hange in service coupling.=A0 The semantics we experience in SL and in Open= sim would remain completely unchanged, except in the single case of source = region non-responsiveness.=A0 Under this single anomalous case there = would be a perceivable change, but that change would be a huge impr= ovement.

There would be no new decoherence introduced since exactly the same sta= te changes would occur on TP as before, with no possibiity of agent state c= hange in the source region once the AD accepts the TP.

All that'= s needed to achieve such resilience for teleport at the protocol level is a= slight revision of operation phasing to permit greater execution overlap, = as I outlined.=A0 This is independent of anything else that happens in the = course of the overall teleport operation --- the change of phasing would af= fect only the transfer of agent location alone, nothing else.

In particular, it should not be confused with the separate requirement = for instantiation of assets or objects at destination, nor with the matter = of serializing and deserializing script states.=A0 The latter has not even = been defined for VWRAP, so it's hard to talk about changing it.=A0 In a= ny event, this isn't about those aspects of teleport, and doesn't a= ffect them --- they would continue to work as before.

One of the central aspects of VWRAP is that the protocol is based on a = multiple services model, and one of the key approaches in highly scalable s= ystems design is to keep services decoupled to the largest extent possible.= =A0 That's what I'm proposing here, a partial decoupling tha= t has no normal semantic change but which does have benefits in anomalous s= ituations.

Agent location change can be decoupled significantly from asset = instantiation change and script state transfer.=A0 My suggestion referred t= o this decoupled agent location change only, not to asset and simula= tion services.=A0 Those other two services undergo state transitions at the= same time as change of agent location does on TP, but services should neve= r be coupled together unnecessarily, and in this case the coupling can be l= eft very weak.=A0 The three types of service operations can proceed each at= their own independent rates, coupled at TP initiation time and nowhere els= e.

It should be noted that the legacy protocols do some of this already, i= n that the agent is already active in the destination region long before he= r avatar or objects have appeared.=A0 Furthermore, the avatar currently con= tinues to be visible in the source region for a while after the agent becom= es active in the destination region, because of normal operation latencies,= sim-side queueing, and client lag.=A0 This is a normal part of current ope= ration, and is not considered an anomaly. What's important is that no n= ew state change to the agent is possible in the source region after TP is i= nitiated, and that would remain true.

The impact of this on the other parts of the puzzle needs to wait until= those other parts are examined.=A0 We're not there yet, but I would ho= pe that improving teleport protocol resilience would be a desireable goal w= hen the only noticeable change in semantics occurs under fault conditions a= nd provides a major improvement on current behaviour.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

On Tue, Oct 13, 2009 at 6:13 AM= , Morgaine <morgaine.dinova@googlemail.com> wro= te:
One of the advant= ages we have in developing the VWRAP protocols is that we are able to look = back at legacy SL and Opensim protocols and recognize design mistakes or li= mitations in them.=A0 This allows us to avoid repeating such mistakes or li= mitations in the next generation of systems.

One of the most common sources of frustration and dissatisfaction is si= mulator non-responsiveness.=A0 While this has many possible causes, in VWRA= P we are not interested in the internal implementation of simulators, but w= e ARE interested in the ability of a protocol endpoint to perform it= s duty within the protocol.=A0 A jammed simulator host is in many cases qui= te unable to perform its protocol duties, or in some cases only exceedingly= slowly, often timing out in a TP for example.=A0 We have a huge amount of = experience of this happening in both SL and Opensim, so it is a practical r= eality.=A0 On occasion, simulators will be unable to fulfil their part in a= protocol, and this needs to be taken into account because it is not unc= ommon.

One key area in which the above is relevant is in teleports OUT = of a simulator that is under distress.=A0 Quite often users wish nothing mo= re than to leave the region being run by a dying simulator, but when= teleport-out requires cooperation from the host that one is trying to leav= e then this is often not possible at all.=A0 In this situation, the only re= medy in existing systems is to forcibly terminate the client and relog in a= nother region.=A0 We should avoid such out-of-protocol remedies being neces= sary through good protocol design.

In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, which = lead to corresponding protocol operations during teleport.=A0 If R1 is a re= gion being run by a non-responsive simulator from which we want to escape, = and R2 is another region to which we wish to go, if the protocol requires a= Derez in R1 to be completed before a Rez in R2 can commence then the user = will have difficulties.=A0 Clearly we don't want this.

In http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 ,= it is made clear that "The agent domain MUST also remove the avata= r from it's current location before placing the avatar in the de= stination location."=A0 This suggests that the protocol will be se= nsitive to R1 non-responsiveness.=A0 While we do not yet have an actual VWR= AP Teleport draft, it seems likely that its initial incarnation will have t= hat same problem built in.

I suggest that the protocol define Derez and Rez as concurrent and non-dependent operations to avoid this situation.= =A0 The AD can mark R1 as disabled for all further agent state changes --- = this will provide all the protection needed to prevent brief double-presenc= e anomalies from being significant.=A0 If a jammed R1 refuses to give up it= s hold on the avatar, then at least the user will not suffer from it.=A0 Re= aping dead simulator sessions then becomes a problem for the region operato= r alone, and not for the AD, the user, and the region as happens now.


Morgaine.




--00504502c64eb2550104769cf6ce-- From dwl@us.ibm.com Fri Oct 23 11:09:47 2009 Return-Path: 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 C42E23A691A; Fri, 23 Oct 2009 11:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.133 X-Spam-Level: X-Spam-Status: No, score=-5.133 tagged_above=-999 required=5 tests=[AWL=0.734, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB18=0.131] 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 K8G5kK8oaEfa; Fri, 23 Oct 2009 11:09:46 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id A024F3A6927; Fri, 23 Oct 2009 11:09:42 -0700 (PDT) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9NI1qdV028778; Fri, 23 Oct 2009 14:01:52 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9NI9qu8094654; Fri, 23 Oct 2009 14:09:52 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9NI9qC8030666; Fri, 23 Oct 2009 14:09:52 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9NI9p9e030658; Fri, 23 Oct 2009 14:09:51 -0400 In-Reply-To: References: To: Morgaine MIME-Version: 1.0 X-KeepSent: 1FEFE8EB:C2DA4EA2-85257658:005C9A89; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Fri, 23 Oct 2009 14:09:50 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1|September 28, 2009) at 10/23/2009 14:09:51, Serialize complete at 10/23/2009 14:09:51 Content-Type: multipart/alternative; boundary="=_alternative 0063C6C385257658_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 18:09:47 -0000 This is a multipart message in MIME format. --=_alternative 0063C6C385257658_= Content-Type: text/plain; charset="US-ASCII" This is a good point, and highlights a very tricky issue in any distributed system design. A protocol should behave gracefully in the face of failure. One of the definite challenges here is partition vs. failure. Its impossible to distinguish between a failed service and one which is lost behind a network partition. In the case of a partition, with an avatar continuing to run on momentarily isolated region, care needs to be taken to recover gracefully not only from the "can't get to the region service" to get it to release the agent, but also the "The region has returned to contact" So,I think when we talk about being resilient we need to think about the range of failure, from "the service I was using has crashed" to "the service I was using has become invisible due to a network partition." Of course, they look identical. This rather strongly implies good semantics on what happens to a "Stub" session which becomes isolated as well as the "new" session which we create by bypassing a failed service. (In the case of teleport, the old region's idea of agent state and the new ones, in other cases, possibly other isolated state) Food for thought - David ~ Zha Morgaine Sent by: ogpx-bounces@ietf.org 10/23/2009 12:47 PM To ogpx@ietf.org cc Subject Re: [ogpx] Teleports and protocol resilience Looking back at the replies in this thread, I think that the goal and the means to achieve it didn't quite come across. I was trying to address only a very specific issue, just protocol resilience under source region non-responsiveness, since this is common enough that it merits addressing. I did not suggest that there be any perceivable change of teleport semantics under normal operation (because no such change is needed), only a change in service coupling. The semantics we experience in SL and in Opensim would remain completely unchanged, except in the single case of source region non-responsiveness. Under this single anomalous case there would be a perceivable change, but that change would be a huge improvement. There would be no new decoherence introduced since exactly the same state changes would occur on TP as before, with no possibiity of agent state change in the source region once the AD accepts the TP. All that's needed to achieve such resilience for teleport at the protocol level is a slight revision of operation phasing to permit greater execution overlap, as I outlined. This is independent of anything else that happens in the course of the overall teleport operation --- the change of phasing would affect only the transfer of agent location alone, nothing else. In particular, it should not be confused with the separate requirement for instantiation of assets or objects at destination, nor with the matter of serializing and deserializing script states. The latter has not even been defined for VWRAP, so it's hard to talk about changing it. In any event, this isn't about those aspects of teleport, and doesn't affect them --- they would continue to work as before. One of the central aspects of VWRAP is that the protocol is based on a multiple services model, and one of the key approaches in highly scalable systems design is to keep services decoupled to the largest extent possible. That's what I'm proposing here, a partial decoupling that has no normal semantic change but which does have benefits in anomalous situations. Agent location change can be decoupled significantly from asset instantiation change and script state transfer. My suggestion referred to this decoupled agent location change only, not to asset and simulation services. Those other two services undergo state transitions at the same time as change of agent location does on TP, but services should never be coupled together unnecessarily, and in this case the coupling can be left very weak. The three types of service operations can proceed each at their own independent rates, coupled at TP initiation time and nowhere else. It should be noted that the legacy protocols do some of this already, in that the agent is already active in the destination region long before her avatar or objects have appeared. Furthermore, the avatar currently continues to be visible in the source region for a while after the agent becomes active in the destination region, because of normal operation latencies, sim-side queueing, and client lag. This is a normal part of current operation, and is not considered an anomaly. What's important is that no new state change to the agent is possible in the source region after TP is initiated, and that would remain true. The impact of this on the other parts of the puzzle needs to wait until those other parts are examined. We're not there yet, but I would hope that improving teleport protocol resilience would be a desireable goal when the only noticeable change in semantics occurs under fault conditions and provides a major improvement on current behaviour. Morgaine. ====================================== On Tue, Oct 13, 2009 at 6:13 AM, Morgaine wrote: One of the advantages we have in developing the VWRAP protocols is that we are able to look back at legacy SL and Opensim protocols and recognize design mistakes or limitations in them. This allows us to avoid repeating such mistakes or limitations in the next generation of systems. One of the most common sources of frustration and dissatisfaction is simulator non-responsiveness. While this has many possible causes, in VWRAP we are not interested in the internal implementation of simulators, but we ARE interested in the ability of a protocol endpoint to perform its duty within the protocol. A jammed simulator host is in many cases quite unable to perform its protocol duties, or in some cases only exceedingly slowly, often timing out in a TP for example. We have a huge amount of experience of this happening in both SL and Opensim, so it is a practical reality. On occasion, simulators will be unable to fulfil their part in a protocol, and this needs to be taken into account because it is not uncommon. One key area in which the above is relevant is in teleports OUT of a simulator that is under distress. Quite often users wish nothing more than to leave the region being run by a dying simulator, but when teleport-out requires cooperation from the host that one is trying to leave then this is often not possible at all. In this situation, the only remedy in existing systems is to forcibly terminate the client and relog in another region. We should avoid such out-of-protocol remedies being necessary through good protocol design. In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, which lead to corresponding protocol operations during teleport. If R1 is a region being run by a non-responsive simulator from which we want to escape, and R2 is another region to which we wish to go, if the protocol requires a Derez in R1 to be completed before a Rez in R2 can commence then the user will have difficulties. Clearly we don't want this. In http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 , it is made clear that "The agent domain MUST also remove the avatar from it's current location before placing the avatar in the destination location." This suggests that the protocol will be sensitive to R1 non-responsiveness. While we do not yet have an actual VWRAP Teleport draft, it seems likely that its initial incarnation will have that same problem built in. I suggest that the protocol define Derez and Rez as concurrent and non-dependent operations to avoid this situation. The AD can mark R1 as disabled for all further agent state changes --- this will provide all the protection needed to prevent brief double-presence anomalies from being significant. If a jammed R1 refuses to give up its hold on the avatar, then at least the user will not suffer from it. Reaping dead simulator sessions then becomes a problem for the region operator alone, and not for the AD, the user, and the region as happens now. Morgaine. _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 0063C6C385257658_= Content-Type: text/html; charset="US-ASCII"
This is a good point, and highlights a very tricky issue in any distributed system design. A protocol should behave gracefully in the face of failure. One of the definite challenges here is partition vs. failure. Its impossible to distinguish between a failed service and one which is lost behind a network partition. In the case of a partition, with an avatar continuing to run on momentarily isolated region, care needs to be taken to recover gracefully not only from the "can't get to the region service" to get it to release the agent, but also the "The region has returned to contact"  So,I think  when we talk about being resilient we need to think about the range of failure, from "the service I was using has crashed" to "the service I was using has become invisible due
to a network partition." Of course, they look identical. This rather strongly implies good semantics on what happens to a "Stub" session which  becomes isolated as well as the "new" session
which we create by bypassing a failed service. (In the case of teleport, the old region's idea of agent state and the new ones, in other cases, possibly other isolated state)  

Food for thought

- David
~ Zha



Morgaine <morgaine.dinova@googlemail.com>
Sent by: ogpx-bounces@ietf.org

10/23/2009 12:47 PM

To
ogpx@ietf.org
cc
Subject
Re: [ogpx] Teleports and protocol resilience





Looking back at the replies in this thread, I think that the goal and the means to achieve it didn't quite come across.

I was trying to address only a very specific issue, just protocol resilience under source region non-responsiveness, since this is common enough that it merits addressing.  I did not suggest that there be any perceivable change of teleport semantics under normal operation (because no such change is needed), only a change in service coupling.  The semantics we experience in SL and in Opensim would remain completely unchanged, except in the single case of source region non-responsiveness.  Under this single anomalous case there would be a perceivable change, but that change would be a huge improvement.

There would be no new decoherence introduced since exactly the same state changes would occur on TP as before, with no possibiity of agent state change in the source region once the AD accepts the TP.

All that's needed to achieve such resilience for teleport at the protocol level is a slight revision of operation phasing to permit greater execution overlap, as I outlined.  This is independent of anything else that happens in the course of the overall teleport operation --- the change of phasing would affect only the transfer of agent location alone, nothing else.

In particular, it should not be confused with the separate requirement for instantiation of assets or objects at destination, nor with the matter of serializing and deserializing script states.  The latter has not even been defined for VWRAP, so it's hard to talk about changing it.  In any event, this isn't about those aspects of teleport, and doesn't affect them --- they would continue to work as before.

One of the central aspects of VWRAP is that the protocol is based on a multiple services model, and one of the key approaches in highly scalable systems design is to keep services decoupled to the largest extent possible.  That's what I'm proposing here, a partial decoupling that has no normal semantic change but which does have benefits in anomalous situations.

Agent location change can be decoupled significantly from asset instantiation change and script state transfer.  My suggestion referred to this decoupled agent location change only, not to asset and simulation services.  Those other two services undergo state transitions at the same time as change of agent location does on TP, but services should never be coupled together unnecessarily, and in this case the coupling can be left very weak.  The three types of service operations can proceed each at their own independent rates, coupled at TP initiation time and nowhere else.

It should be noted that the legacy protocols do some of this already, in that the agent is already active in the destination region long before her avatar or objects have appeared.  Furthermore, the avatar currently continues to be visible in the source region for a while after the agent becomes active in the destination region, because of normal operation latencies, sim-side queueing, and client lag.  This is a normal part of current operation, and is not considered an anomaly. What's important is that no new state change to the agent is possible in the source region after TP is initiated, and that would remain true.

The impact of this on the other parts of the puzzle needs to wait until those other parts are examined.  We're not there yet, but I would hope that improving teleport protocol resilience would be a desireable goal when the only noticeable change in semantics occurs under fault conditions and provides a major improvement on current behaviour.


Morgaine.






======================================
On Tue, Oct 13, 2009 at 6:13 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
One of the advantages we have in developing the VWRAP protocols is that we are able to look back at legacy SL and Opensim protocols and recognize design mistakes or limitations in them.  This allows us to avoid repeating such mistakes or limitations in the next generation of systems.

One of the most common sources of frustration and dissatisfaction is simulator non-responsiveness.  While this has many possible causes, in VWRAP we are not interested in the internal implementation of simulators, but we ARE interested in the ability of a protocol endpoint to perform its duty within the protocol.  A jammed simulator host is in many cases quite unable to perform its protocol duties, or in some cases only exceedingly slowly, often timing out in a TP for example.  We have a huge amount of experience of this happening in both SL and Opensim, so it is a practical reality.  On occasion, simulators will be unable to fulfil their part in a protocol, and this needs to be taken into account because it is not uncommon.

One key area in which the above is relevant is in teleports OUT of a simulator that is under distress.  Quite often users wish nothing more than to leave the region being run by a dying simulator, but when teleport-out requires cooperation from the host that one is trying to leave then this is often not possible at all.  In this situation, the only remedy in existing systems is to forcibly terminate the client and relog in another region.  We should avoid such out-of-protocol remedies being necessary through good protocol design.

In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, which lead to corresponding protocol operations during teleport.  If R1 is a region being run by a non-responsive simulator from which we want to escape, and R2 is another region to which we wish to go, if the protocol requires a Derez in R1 to be completed before a Rez in R2 can commence then the user will have difficulties.  Clearly we don't want this.

In http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 , it is made clear that "The agent domain MUST also remove the avatar from it's current location before placing the avatar in the destination location."  This suggests that the protocol will be sensitive to R1 non-responsiveness.  While we do not yet have an actual VWRAP Teleport draft, it seems likely that its initial incarnation will have that same problem built in.

I suggest that the protocol define Derez and Rez as concurrent and non-dependent operations to avoid this situation.  The AD can mark R1 as disabled for all further agent state changes --- this will provide all the protection needed to prevent brief double-presence anomalies from being significant.  If a jammed R1 refuses to give up its hold on the avatar, then at least the user will not suffer from it.  Reaping dead simulator sessions then becomes a problem for the region operator alone, and not for the AD, the user, and the region as happens now.


Morgaine.
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 0063C6C385257658_=-- From morgaine.dinova@googlemail.com Fri Oct 23 20:45:37 2009 Return-Path: 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 1E1C23A63D3 for ; Fri, 23 Oct 2009 20:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SARE_UNSUB18=0.131] 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 Q3aB4vbMAzx6 for ; Fri, 23 Oct 2009 20:45:35 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 6841A3A635F for ; Fri, 23 Oct 2009 20:45:34 -0700 (PDT) Received: by ewy4 with SMTP id 4so2193547ewy.37 for ; Fri, 23 Oct 2009 20:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=gA+humdm6H1VR2mRXzWXEU9VfxCnNqjF2i8lZPhIsBM=; b=QQbyqXCN0dpa+0i8tr1PNPSx6ugEsfGvevh4K51+rQJkOgSTLr6horKyh3NyUjjdSc DrZyH39T6pV7K0UtJlNeNEE6F9fk6W2hfCjQUXLp2mg2T7UTlfba0iKWQEkoiyaR7YBe qLhu7C+33xkWqrL2YKtzcjdQVO7e+ftU4KBIs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=M1xQR6DGlMobT9PQtnEncL73Kt21y1n/OG/Vw15ilYrczJ/QsQhaYBtKu/LnA6EQ+a ZuB0BZ3Qde43yNmaSVi7ZaB6auOR5HQqq52sAM0MC0ZKRwL/gQA0YhY3jOHwDfSDmd4k oosG0xGwzweYxUcpbJbKUBNP8KQxl22U37sbk= MIME-Version: 1.0 Received: by 10.210.4.13 with SMTP id 13mr1435380ebd.64.1256355940629; Fri, 23 Oct 2009 20:45:40 -0700 (PDT) In-Reply-To: References: Date: Sat, 24 Oct 2009 04:45:40 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0ce03f128d7d550476a629f0 Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 03:45:37 -0000 --000e0ce03f128d7d550476a629f0 Content-Type: text/plain; charset=ISO-8859-1 Excellent observation, David! To use a different form of words, fault conditions can occur in all the possible states of the system, and if we want the protocol to be robust then we'll probably have to examine all its major states and ensure that there are always state transitions available out of them. In that light, being able to TP out of a stuck region is just one of those recovery transitions without which the protocol would simply break as a result of the exception. There is of course no need to design VWRAP such that exception handling always ends in session termination --- this would result in a very poor user experience by default, and so it should be avoided wherever possible. My suggestion is therefore likely to be just one of many designed to avoid session termination under conditions that, while not normal, are nevertheless unfortunately rather common in practice. The user's client application should never be forced to disconnect completely (or even worse to terminate) unless there is absolutely no alternative, and it's up to us to provide such alternatives wherever we can. Breaking the user's immersive experience through termination should only be a solution of last resort. Morgaine. ==================================== On Fri, Oct 23, 2009 at 7:09 PM, David W Levine wrote: > > This is a good point, and highlights a very tricky issue in any distributed > system design. A protocol should behave gracefully in the face of failure. > One of the definite challenges here is partition vs. failure. Its impossible > to distinguish between a failed service and one which is lost behind a > network partition. In the case of a partition, with an avatar continuing to > run on momentarily isolated region, care needs to be taken to recover > gracefully not only from the "can't get to the region service" to get it to > release the agent, but also the "The region has returned to contact" So,I > think when we talk about being resilient we need to think about the range > of failure, from "the service I was using has crashed" to "the service I was > using has become invisible due > to a network partition." Of course, they look identical. This rather > strongly implies good semantics on what happens to a "Stub" session which > becomes isolated as well as the "new" session > which we create by bypassing a failed service. (In the case of teleport, > the old region's idea of agent state and the new ones, in other cases, > possibly other isolated state) > > Food for thought > > - David > ~ Zha > > > > *Morgaine * > Sent by: ogpx-bounces@ietf.org > > 10/23/2009 12:47 PM > To > ogpx@ietf.org > cc > Subject > Re: [ogpx] Teleports and protocol resilience > > > > > Looking back at the replies in this thread, I think that the goal and the > means to achieve it didn't quite come across. > > I was trying to address only a very specific issue, just protocol > resilience under source region non-responsiveness, since this is common > enough that it merits addressing. I did not suggest that there be any > perceivable change of teleport semantics under normal operation (because no > such change is needed), only a change in service coupling. The semantics we > experience in SL and in Opensim would remain completely unchanged, except in > the single case of source region non-responsiveness. Under this single > anomalous case there *would* be a perceivable change, but that change > would be a huge improvement. > > There would be no new decoherence introduced since exactly the same state > changes would occur on TP as before, with no possibiity of agent state > change in the source region once the AD accepts the TP. > > All that's needed to achieve such resilience for teleport at the protocol > level is a slight revision of operation phasing to permit greater execution > overlap, as I outlined. This is independent of anything else that happens > in the course of the overall teleport operation --- the change of phasing > would affect only the transfer of *agent location* alone, nothing else. > > In particular, it should not be confused with the separate requirement for > instantiation of assets or objects at destination, nor with the matter of > serializing and deserializing script states. The latter has not even been > defined for VWRAP, so it's hard to talk about changing it. In any event, > this isn't about those aspects of teleport, and doesn't affect them --- they > would continue to work as before. > > One of the central aspects of VWRAP is that the protocol is based on a > multiple services model, and one of the key approaches in highly scalable > systems design is to keep services decoupled to the largest extent > possible. That's what I'm proposing here, a *partial decoupling* that has > no normal semantic change but which does have benefits in anomalous > situations. > > Agent location change *can* be decoupled significantly from asset > instantiation change and script state transfer. My suggestion referred to > this decoupled *agent location change* only, not to asset and simulation > services. Those other two services undergo state transitions at the same > time as change of agent location does on TP, but services should never be > coupled together unnecessarily, and in this case the coupling can be left > very weak. The three types of service operations can proceed each at their > own independent rates, coupled at TP initiation time and nowhere else. > > It should be noted that the legacy protocols do some of this already, in > that the agent is already active in the destination region long before her > avatar or objects have appeared. Furthermore, the avatar currently > continues to be visible in the source region for a while after the agent > becomes active in the destination region, because of normal operation > latencies, sim-side queueing, and client lag. This is a normal part of > current operation, and is not considered an anomaly. What's important is > that no new state change to the agent is possible in the source region after > TP is initiated, and that would remain true. > > The impact of this on the other parts of the puzzle needs to wait until > those other parts are examined. We're not there yet, but I would hope that > improving teleport protocol resilience would be a desireable goal when the > only noticeable change in semantics occurs under fault conditions and > provides a major improvement on current behaviour. > > > Morgaine. > > > > > > > ====================================== > > On Tue, Oct 13, 2009 at 6:13 AM, Morgaine <*morgaine.dinova@googlemail.com > * > wrote: > One of the advantages we have in developing the VWRAP protocols is that we > are able to look back at legacy SL and Opensim protocols and recognize > design mistakes or limitations in them. This allows us to avoid repeating > such mistakes or limitations in the next generation of systems. > > One of the most common sources of frustration and dissatisfaction is > simulator non-responsiveness. While this has many possible causes, in VWRAP > we are not interested in the internal implementation of simulators, but we > *ARE* interested in the ability of a protocol endpoint to perform its duty > within the protocol. A jammed simulator host is in many cases quite unable > to perform its protocol duties, or in some cases only exceedingly slowly, > often timing out in a TP for example. We have a huge amount of experience > of this happening in both SL and Opensim, so it is a practical reality. On > occasion, simulators will be unable to fulfil their part in a protocol, and > this needs to be taken into account because it is *not uncommon*. > > One key area in which the above is relevant is in teleports *OUT* of a > simulator that is under distress. Quite often users wish nothing more than > to *leave* the region being run by a dying simulator, but when > teleport-out requires cooperation from the host that one is trying to leave > then this is often not possible at all. In this situation, the only remedy > in existing systems is to forcibly terminate the client and relog in another > region. We should avoid such out-of-protocol remedies being necessary > through good protocol design. > > In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, which lead > to corresponding protocol operations during teleport. If R1 is a region > being run by a non-responsive simulator from which we want to escape, and R2 > is another region to which we wish to go, if the protocol requires a Derez > in R1 to be completed before a Rez in R2 can commence then the user will > have difficulties. Clearly we don't want this. > > In *http://tools.ietf.org/html/draft-hamrick-ogp-intro-00*, it is made clear that " > *The agent domain MUST also remove the avatar from it's current location > before** placing the avatar in the destination location*." This suggests > that the protocol will be sensitive to R1 non-responsiveness. While we do > not yet have an actual VWRAP Teleport draft, it seems likely that its > initial incarnation will have that same problem built in. > > I suggest that the protocol define Derez and Rez as *concurrent* and * > non-dependent* operations to avoid this situation. The AD can mark R1 as > disabled for all further agent state changes --- this will provide all the > protection needed to prevent brief double-presence anomalies from being > significant. If a jammed R1 refuses to give up its hold on the avatar, then > at least the user will not suffer from it. Reaping dead simulator sessions > then becomes a problem for the region operator alone, and not for the AD, > the user, and the region as happens now. > > > Morgaine. > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --000e0ce03f128d7d550476a629f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Excellent observation, David!

To use a different form of words, faul= t conditions can occur in all the possible states of the system, and if we = want the protocol to be robust then we'll probably have to examine all = its major states and ensure that there are always state transitions availab= le out of them.

In that light, being able to TP out of a stuck region is just one of th= ose recovery transitions without which the protocol would simply break as a= result of the exception.=A0 There is of course no need to design VWRAP suc= h that exception handling always ends in session termination --- this would= result in a very poor user experience by default, and so it should be avoi= ded wherever possible.

My suggestion is therefore likely to be just one of many designed to av= oid session termination under conditions that, while not normal, are nevert= heless unfortunately rather common in practice.=A0 The user's client ap= plication should never be forced to disconnect completely (or even worse to= terminate) unless there is absolutely no alternative, and it's up to u= s to provide such alternatives wherever we can.

Breaking the user's immersive experience through termination should= only be a solution of last resort.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Fri, Oct 23, 2009 at 7:09 PM, David W Levine <dwl@us.ibm.com> wrote:

This is a good point, and highligh= ts a very tricky issue in any distributed system design. A protocol should behave gracefully in the face of failure. One of the definite challenges here is partition vs. failure. Its impossible to distinguish between a failed service and one which is lost behind a network partition. In the case of a partition, with an avatar continuing to run on momentarily isolat= ed region, care needs to be taken to recover gracefully not only from the "can't get to the region service" to get it to release the ag= ent, but also the "The region has returned to contact" =A0So,I think =A0when we talk about being resilient we need to think about the range of failure, from "the service I was using has crashed" to "the service I was using has become invisible due
to a network partition." Of c= ourse, they look identical. This rather strongly implies good semantics on what happens to a "Stub" session which =A0becomes isolated as well as the "new" session
which we create by bypassing a fai= led service. (In the case of teleport, the old region's idea of agent state and the new ones, in other cases, possibly other isolated state) =A0

Food for thought

- David
~ Zha



Morgaine <morgaine.dinova@googlemail.com>
Sent by: <= a href=3D"mailto:ogpx-bounces@ietf.org" target=3D"_blank">ogpx-bounces@ietf= .org

10/23/2009 12:47 PM

To
ogpx@ietf.org
cc
Subject
Re: [ogpx] Teleports and prot= ocol resilience





Looking back at the replies in this thread, I think th= at the goal and the means to achieve it didn't quite come across.

I was trying to address only a very specific issue, just protocol resilienc= e under source region non-responsiveness, since this is common enough that it merits addressing.=A0 I did not suggest that there be any perceivable change of teleport semantics under normal operation (because no such change is needed), only a change in service coupling.=A0 The semantics we experien= ce in SL and in Opensim would remain completely unchanged, except in the singl= e case of source region non-responsiveness.=A0 Under this single anomalous case there would be a perceivable change, but that change would be a huge improvement.

There would be no new decoherence introduced since exactly the same state changes would occur on TP as before, with no possibiity of agent state change in the source region once the AD accepts the TP.

All that's needed to achieve such resilience for teleport at the protoc= ol level is a slight revision of operation phasing to permit greater execution overlap, as I outlined.=A0 This is independent of anything else that happens in the course of the overall teleport operation --- the change of phasing would affect only the transfer of agent location alone, nothing else.

In particular, it should not be confused with the separate requirement for instantiation of assets or objects at destination, nor with the matter of serializing and deserializing script states.=A0 The latter has not even been defined for VWRAP, so it's hard to talk about changing it.=A0 In any event, this isn't about those aspects of teleport, and doesn'= ;t affect them --- they would continue to work as before.

One of the central aspects of VWRAP is that the protocol is based on a multiple services model, and one of the key approaches in highly scalable systems design is to keep services decoupled to the largest extent possible= .=A0 That's what I'm proposing here, a partial decoupling that ha= s no normal semantic change but which does have benefits in anomalous situations= .

Agent location change can be decoupled significantly from asset instantiation change and script state transfer.=A0 My suggestion referred to this decoupled agent location change only, not to asset and simul= ation services.=A0 Those other two services undergo state transitions at the same time as change of agent location does on TP, but services should never be coupled together unnecessarily, and in this case the coupling can be left very weak.=A0 The three types of service operations can proceed each at their own independent rates, coupled at TP initiation time and nowhere else.

It should be noted that the legacy protocols do some of this already, in that the agent is already active in the destination region long before her avatar or objects have appeared.=A0 Furthermore, the avatar currently continues to be visible in the source region for a while after the agent becomes active in the destination region, because of normal operation laten= cies, sim-side queueing, and client lag.=A0 This is a normal part of current operation, and is not considered an anomaly. What's important is that n= o new state change to the agent is possible in the source region after TP is initiated, and that would remain true.

The impact of this on the other parts of the puzzle needs to wait until those other parts are examined.=A0 We're not there yet, but I would hope that improving teleport protocol resilience would be a desireable goal when the only noticeable change in semantics occurs under fault condit= ions and provides a major improvement on current behaviour.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Tue, Oct 13, 2009 at 6:13 AM, Morgaine <<= a href=3D"mailto:morgaine.dinova@googlemail.com" target=3D"_blank">morgaine.dinova@googlemail.com> wrote:
One of the advantages we have in developing the VWRAP protocols is that we are able to look back at legacy SL and Opensim protoco= ls and recognize design mistakes or limitations in them.=A0 This allows us to avoid repeating such mistakes or limitations in the next generation of systems.

One of the most common sources of frustration and dissatisfaction is simula= tor non-responsiveness.=A0 While this has many possible causes, in VWRAP we are not interested in the internal implementation of simulators, but we ARE interested in the ability of a protocol endpoint to perform its duty within the protocol.=A0 A jammed simulator host is in many cases quite unable to perform its protocol duties, or in some cases only exceedingly slowly, often timing out in a TP for example.=A0 We have a huge amount of experience of this happening in both SL and Opensim, so it is a practical reality.=A0 On occasion, simulators will be unable to fulfil their part in a protocol, and this needs to be taken into account because it is not uncommon.

One key area in which the above is relevant is in teleports OUT of a simulator that is under distress.=A0 Quite often users wish nothing more than to leave the region being run by a dying simulator, but when teleport-out requires cooperation from the host that one is trying to leave then this is often not possible at all.=A0 In this situation, the only remedy in existing systems is to forcibly terminate the client and relog in another region.=A0 We should avoid such out-of-protocol remedies being necessary through good protocol design.

In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, which lead to corresponding protocol operations during teleport.=A0 If R1 is a region being run by a non-responsive simulator from which we want to escape, and R2 is another region to which we wish to go, if the protocol requires a Derez in R1 to be completed before a Rez in R2 can commence then the user will have difficulties.=A0 Clearly we don't want this.
In http://tools.ietf.org= /html/draft-hamrick-ogp-intro-00 , it is made clear that "The agent domain MUST also remove the avatar from it's current location before placing the avat= ar in the destination location."=A0 This suggests that the protocol will be sensitive to R1 non-responsiveness.=A0 While we do not yet have an actual VWRAP Teleport draft, it seems likely that its initial incarnatio= n will have that same problem built in.

I suggest that the protocol define Derez and Rez as concurrent and non-dependent operations to avoid this situation.=A0 The AD can mark R1 as disabled for all further agent state changes --- this will provide all the protection needed to prevent brief double-presenc= e anomalies from being significant.=A0 If a jammed R1 refuses to give up its hold on the avatar, then at least the user will not suffer from it.=A0 Reaping dead simulator sessions then becomes a problem for the region operator alone, and not for the AD, the user, and the region as happens now.


Morgaine.
____= ___________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx=


--000e0ce03f128d7d550476a629f0-- From lenglish5@cox.net Fri Oct 23 23:21:10 2009 Return-Path: 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 31A5B28C12D for ; Fri, 23 Oct 2009 23:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, J_CHICKENPOX_21=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 RdzZFNs+C2iT for ; Fri, 23 Oct 2009 23:21:08 -0700 (PDT) Received: from fed1rmmtao101.cox.net (fed1rmmtao101.cox.net [68.230.241.45]) by core3.amsl.com (Postfix) with ESMTP id DF69F28C126 for ; Fri, 23 Oct 2009 23:21:08 -0700 (PDT) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao101.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20091024062120.ROGN16492.fed1rmmtao101.cox.net@fed1rmimpo01.cox.net>; Sat, 24 Oct 2009 02:21:20 -0400 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo01.cox.net with bizsmtp id wWMK1c0052l1Ksg03WMKwn; Sat, 24 Oct 2009 02:21:20 -0400 X-VR-Score: -80.00 X-Authority-Analysis: v=1.0 c=1 a=BeAJBb8iiRAA:10 a=Wajolswj7cQA:10 a=VnNF1IyMAAAA:8 a=mK_AVkanAAAA:8 a=48vgC7mUAAAA:8 a=m9yfab4Tx7oqNDPCVQ8A:9 a=p3LDC2BWjPggG5v0EjsA:7 a=mpI-T5OJzEqztX5Wn0ypmQcv57cA:4 a=oXxgVVfU3OUA:10 a=9xyTavCNlvEA:10 a=lZB815dzVvQA:10 a=7bAUKRnXkj018P6B:21 a=mHiKjMpIVDPq6J5h:21 X-CM-Score: 0.00 Message-ID: <4AE29CDF.1070208@cox.net> Date: Fri, 23 Oct 2009 23:21:19 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Morgaine References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 06:21:10 -0000 Morgaine wrote: > Excellent observation, David! > > To use a different form of words, fault conditions can occur in all > the possible states of the system, and if we want the protocol to be > robust then we'll probably have to examine all its major states and > ensure that there are always state transitions available out of them. > > In that light, being able to TP out of a stuck region is just one of > those recovery transitions without which the protocol would simply > break as a result of the exception. There is of course no need to > design VWRAP such that exception handling always ends in session > termination --- this would result in a very poor user experience by > default, and so it should be avoided wherever possible. > > My suggestion is therefore likely to be just one of many designed to > avoid session termination under conditions that, while not normal, are > nevertheless unfortunately rather common in practice. The user's > client application should never be forced to disconnect completely (or > even worse to terminate) unless there is absolutely no alternative, > and it's up to us to provide such alternatives wherever we can. > > Breaking the user's immersive experience through termination should > only be a solution of last resort. > > > Morgaine. > > > > > > ==================================== > > On Fri, Oct 23, 2009 at 7:09 PM, David W Levine > wrote: > > > This is a good point, and highlights a very tricky issue in any > distributed system design. A protocol should behave gracefully in > the face of failure. One of the definite challenges here is > partition vs. failure. Its impossible to distinguish between a > failed service and one which is lost behind a network partition. > In the case of a partition, with an avatar continuing to run on > momentarily isolated region, care needs to be taken to recover > gracefully not only from the "can't get to the region service" to > get it to release the agent, but also the "The region has returned > to contact" So,I think when we talk about being resilient we > need to think about the range of failure, from "the service I was > using has crashed" to "the service I was using has become > invisible due > to a network partition." Of course, they look identical. This > rather strongly implies good semantics on what happens to a "Stub" > session which becomes isolated as well as the "new" session > which we create by bypassing a failed service. (In the case of > teleport, the old region's idea of agent state and the new ones, > in other cases, possibly other isolated state) > > Food for thought > > - David > ~ Zha > > > > *Morgaine >* > Sent by: ogpx-bounces@ietf.org > > 10/23/2009 12:47 PM > > > To > ogpx@ietf.org > cc > > Subject > Re: [ogpx] Teleports and protocol resilience > > > > > > > > > > Looking back at the replies in this thread, I think that the goal > and the means to achieve it didn't quite come across. > > I was trying to address only a very specific issue, just protocol > resilience under source region non-responsiveness, since this is > common enough that it merits addressing. I did not suggest that > there be any perceivable change of teleport semantics under normal > operation (because no such change is needed), only a change in > service coupling. The semantics we experience in SL and in > Opensim would remain completely unchanged, except in the single > case of source region non-responsiveness. Under this single > anomalous case there */would/* be a perceivable change, but that > change would be a huge improvement. > > There would be no new decoherence introduced since exactly the > same state changes would occur on TP as before, with no possibiity > of agent state change in the source region once the AD accepts the TP. > > All that's needed to achieve such resilience for teleport at the > protocol level is a slight revision of operation phasing to permit > greater execution overlap, as I outlined. This is independent of > anything else that happens in the course of the overall teleport > operation --- the change of phasing would affect only the transfer > of /agent location/ alone, nothing else. > > In particular, it should not be confused with the separate > requirement for instantiation of assets or objects at destination, > nor with the matter of serializing and deserializing script > states. The latter has not even been defined for VWRAP, so it's > hard to talk about changing it. In any event, this isn't about > those aspects of teleport, and doesn't affect them --- they would > continue to work as before. > > One of the central aspects of VWRAP is that the protocol is based > on a multiple services model, and one of the key approaches in > highly scalable systems design is to keep services decoupled to > the largest extent possible. That's what I'm proposing here, a > /partial decoupling/ that has no normal semantic change but which > does have benefits in anomalous situations. > > Agent location change /can/ be decoupled significantly from asset > instantiation change and script state transfer. My suggestion > referred to this decoupled /agent location change/ only, not to > asset and simulation services. Those other two services undergo > state transitions at the same time as change of agent location > does on TP, but services should never be coupled together > unnecessarily, and in this case the coupling can be left very > weak. The three types of service operations can proceed each at > their own independent rates, coupled at TP initiation time and > nowhere else. > > It should be noted that the legacy protocols do some of this > already, in that the agent is already active in the destination > region long before her avatar or objects have appeared. > Furthermore, the avatar currently continues to be visible in the > source region for a while after the agent becomes active in the > destination region, because of normal operation latencies, > sim-side queueing, and client lag. This is a normal part of > current operation, and is not considered an anomaly. What's > important is that no new state change to the agent is possible in > the source region after TP is initiated, and that would remain true. > > The impact of this on the other parts of the puzzle needs to wait > until those other parts are examined. We're not there yet, but I > would hope that improving teleport protocol resilience would be a > desireable goal when the only noticeable change in semantics > occurs under fault conditions and provides a major improvement on > current behaviour. > > > Morgaine. > > > > > > > ====================================== > > On Tue, Oct 13, 2009 at 6:13 AM, Morgaine > <_morgaine.dinova@googlemail.com_ > > wrote: > One of the advantages we have in developing the VWRAP protocols is > that we are able to look back at legacy SL and Opensim protocols > and recognize design mistakes or limitations in them. This allows > us to avoid repeating such mistakes or limitations in the next > generation of systems. > > One of the most common sources of frustration and dissatisfaction > is simulator non-responsiveness. While this has many possible > causes, in VWRAP we are not interested in the internal > implementation of simulators, but we *ARE* interested in the > ability of a protocol endpoint to perform its duty within the > protocol. A jammed simulator host is in many cases quite unable > to perform its protocol duties, or in some cases only exceedingly > slowly, often timing out in a TP for example. We have a huge > amount of experience of this happening in both SL and Opensim, so > it is a practical reality. On occasion, simulators will be unable > to fulfil their part in a protocol, and this needs to be taken > into account because it is /not uncommon/. > > One key area in which the above is relevant is in teleports *OUT* > of a simulator that is under distress. Quite often users wish > nothing more than to /leave/ the region being run by a dying > simulator, but when teleport-out requires cooperation from the > host that one is trying to leave then this is often not possible > at all. In this situation, the only remedy in existing systems is > to forcibly terminate the client and relog in another region. We > should avoid such out-of-protocol remedies being necessary through > good protocol design. > > In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, > which lead to corresponding protocol operations during teleport. > If R1 is a region being run by a non-responsive simulator from > which we want to escape, and R2 is another region to which we wish > to go, if the protocol requires a Derez in R1 to be completed > before a Rez in R2 can commence then the user will have > difficulties. Clearly we don't want this. > > In _http://tools.ietf.org/html/draft-hamrick-ogp-intro-00_ , it is > made clear that "/The agent domain MUST also remove the avatar > from it's current location *before*// placing the avatar in the > destination location/." This suggests that the protocol will be > sensitive to R1 non-responsiveness. While we do not yet have an > actual VWRAP Teleport draft, it seems likely that its initial > incarnation will have that same problem built in. > > I suggest that the protocol define Derez and Rez as */concurrent/* > and */non-dependent/* operations to avoid this situation. The AD > can mark R1 as disabled for all further agent state changes --- > this will provide all the protection needed to prevent brief > double-presence anomalies from being significant. If a jammed R1 > refuses to give up its hold on the avatar, then at least the user > will not suffer from it. Reaping dead simulator sessions then > becomes a problem for the region operator alone, and not for the > AD, the user, and the region as happens now. > Beware of one-size-fits-all requirements. I can easily imagine there will be users who wouldn't want to have a degraded/alternate/unexpected experience on TP failure and who WOULD want the system just to reset. And no doubt other scenarios will make sense as well. After all, if someone uses VWRAP as the foundation for a gaming platform, they may have completely different rules that they expect users participating to follow as long as they are participating. Lawson Lawson From morgaine.dinova@googlemail.com Sat Oct 24 03:08:28 2009 Return-Path: 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 29C673A68A4 for ; Sat, 24 Oct 2009 03:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 dnWMvh+BGbL8 for ; Sat, 24 Oct 2009 03:08:25 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 1F93E3A683D for ; Sat, 24 Oct 2009 03:08:24 -0700 (PDT) Received: by ewy4 with SMTP id 4so2307509ewy.37 for ; Sat, 24 Oct 2009 03:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=2fJxyzF9BO/d4AKS2xOuM8MvmDyxj+H7SdY43IN3ztE=; b=qQCDDT3cVtIYbVjNfmMJcKdoCD9YoO/3ofji0CeI3Qm06vcDYIA8iFMWmizKpenabF Pxw/KPkEsgcP8a39KYX3CKpzmv3Zm8QIgXoVemFKM5/5Ri1ZXbcRILeuZvJGDe/0W3op xWO5Dx2/vgKtLtz+UQePd+XLKXglPLLoH2tU8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=sCkt9VuKMuuJcGzg+LxXXisIGkhcTLNrf//iAf2fXSsUt1UrcOICw5a9E2sDR0H/+w B0e2cVW6TLuE0dpO0Akfp5qeLZmjdz46Ymsl1KeFoYrHZmARS8R+ReAVwubxaj7JegCD V+aOJVw1hBzZaY9MQLPEMTnZM4FxWVf6K1LTE= MIME-Version: 1.0 Received: by 10.211.147.26 with SMTP id z26mr1726081ebn.73.1256378913134; Sat, 24 Oct 2009 03:08:33 -0700 (PDT) In-Reply-To: <4AE29CDF.1070208@cox.net> References: <4AE29CDF.1070208@cox.net> Date: Sat, 24 Oct 2009 11:08:33 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636c5bd9dd21a7e0476ab829b Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 10:08:28 -0000 --001636c5bd9dd21a7e0476ab829b Content-Type: text/plain; charset=ISO-8859-1 Indeed! Not only are extra user options always a good thing, but a TP from a region in one world could be to a region in a highly different world with very specific requirements. As you point out, "one size fits all" is definitely inappropriate. In this particular case, that could be handled by the AD sending the client an event notification to the effect that the source region did not respond within the timeout period. The client would then be free to implement disconnection if this is the user's configured choice. I think it's fair to expect that most people would not choose that option, but it should certainly be available to them if needed. The agent would probably already be located in the destination region by this time from the AD's perspective (depending on timout length), but not necessarily from the client's perspective --- that's a matter of client implementation and user options. Some Second Life clients already implement "Don't blank screen on TP", "Don't show TP progress bar" and "Display avatar before wearables are available" as options, so they're already handling the component parts of the overall TP operation quite flexibly. The AD of a world may itself have a policy of not allowing TPs to complete when the source region is unavailable, but this should not be hardwired into the protocol. As you say, one size does not fit all, particularly in the case of choices that provide a bad user experience. Morgaine. =========================================== On Sat, Oct 24, 2009 at 7:21 AM, Lawson English wrote: > Morgaine wrote: > >> Excellent observation, David! >> >> To use a different form of words, fault conditions can occur in all the >> possible states of the system, and if we want the protocol to be robust then >> we'll probably have to examine all its major states and ensure that there >> are always state transitions available out of them. >> >> In that light, being able to TP out of a stuck region is just one of those >> recovery transitions without which the protocol would simply break as a >> result of the exception. There is of course no need to design VWRAP such >> that exception handling always ends in session termination --- this would >> result in a very poor user experience by default, and so it should be >> avoided wherever possible. >> >> My suggestion is therefore likely to be just one of many designed to avoid >> session termination under conditions that, while not normal, are >> nevertheless unfortunately rather common in practice. The user's client >> application should never be forced to disconnect completely (or even worse >> to terminate) unless there is absolutely no alternative, and it's up to us >> to provide such alternatives wherever we can. >> >> Breaking the user's immersive experience through termination should only >> be a solution of last resort. >> >> >> Morgaine. >> >> >> >> >> >> ==================================== >> >> On Fri, Oct 23, 2009 at 7:09 PM, David W Levine > dwl@us.ibm.com>> wrote: >> >> >> This is a good point, and highlights a very tricky issue in any >> distributed system design. A protocol should behave gracefully in >> the face of failure. One of the definite challenges here is >> partition vs. failure. Its impossible to distinguish between a >> failed service and one which is lost behind a network partition. >> In the case of a partition, with an avatar continuing to run on >> momentarily isolated region, care needs to be taken to recover >> gracefully not only from the "can't get to the region service" to >> get it to release the agent, but also the "The region has returned >> to contact" So,I think when we talk about being resilient we >> need to think about the range of failure, from "the service I was >> using has crashed" to "the service I was using has become >> invisible due >> to a network partition." Of course, they look identical. This >> rather strongly implies good semantics on what happens to a "Stub" >> session which becomes isolated as well as the "new" session >> which we create by bypassing a failed service. (In the case of >> teleport, the old region's idea of agent state and the new ones, >> in other cases, possibly other isolated state) >> Food for thought >> >> - David >> ~ Zha >> >> >> >> *Morgaine > >* >> Sent by: ogpx-bounces@ietf.org >> >> >> 10/23/2009 12:47 PM >> >> >> To >> ogpx@ietf.org >> >> cc >> >> Subject >> Re: [ogpx] Teleports and protocol resilience >> >> >> >> >> >> >> >> >> >> Looking back at the replies in this thread, I think that the goal >> and the means to achieve it didn't quite come across. >> >> I was trying to address only a very specific issue, just protocol >> resilience under source region non-responsiveness, since this is >> common enough that it merits addressing. I did not suggest that >> there be any perceivable change of teleport semantics under normal >> operation (because no such change is needed), only a change in >> service coupling. The semantics we experience in SL and in >> Opensim would remain completely unchanged, except in the single >> case of source region non-responsiveness. Under this single >> anomalous case there */would/* be a perceivable change, but that >> change would be a huge improvement. >> >> There would be no new decoherence introduced since exactly the >> same state changes would occur on TP as before, with no possibiity >> of agent state change in the source region once the AD accepts the TP. >> >> All that's needed to achieve such resilience for teleport at the >> protocol level is a slight revision of operation phasing to permit >> greater execution overlap, as I outlined. This is independent of >> anything else that happens in the course of the overall teleport >> operation --- the change of phasing would affect only the transfer >> of /agent location/ alone, nothing else. >> >> In particular, it should not be confused with the separate >> requirement for instantiation of assets or objects at destination, >> nor with the matter of serializing and deserializing script >> states. The latter has not even been defined for VWRAP, so it's >> hard to talk about changing it. In any event, this isn't about >> those aspects of teleport, and doesn't affect them --- they would >> continue to work as before. >> >> One of the central aspects of VWRAP is that the protocol is based >> on a multiple services model, and one of the key approaches in >> highly scalable systems design is to keep services decoupled to >> the largest extent possible. That's what I'm proposing here, a >> /partial decoupling/ that has no normal semantic change but which >> does have benefits in anomalous situations. >> >> Agent location change /can/ be decoupled significantly from asset >> instantiation change and script state transfer. My suggestion >> referred to this decoupled /agent location change/ only, not to >> asset and simulation services. Those other two services undergo >> state transitions at the same time as change of agent location >> does on TP, but services should never be coupled together >> unnecessarily, and in this case the coupling can be left very >> weak. The three types of service operations can proceed each at >> their own independent rates, coupled at TP initiation time and >> nowhere else. >> >> It should be noted that the legacy protocols do some of this >> already, in that the agent is already active in the destination >> region long before her avatar or objects have appeared. Furthermore, >> the avatar currently continues to be visible in the >> source region for a while after the agent becomes active in the >> destination region, because of normal operation latencies, >> sim-side queueing, and client lag. This is a normal part of >> current operation, and is not considered an anomaly. What's >> important is that no new state change to the agent is possible in >> the source region after TP is initiated, and that would remain true. >> >> The impact of this on the other parts of the puzzle needs to wait >> until those other parts are examined. We're not there yet, but I >> would hope that improving teleport protocol resilience would be a >> desireable goal when the only noticeable change in semantics >> occurs under fault conditions and provides a major improvement on >> current behaviour. >> >> >> Morgaine. >> >> >> >> >> >> >> ====================================== >> >> On Tue, Oct 13, 2009 at 6:13 AM, Morgaine >> <_morgaine.dinova@googlemail.com_ >> >> > wrote: >> One of the advantages we have in developing the VWRAP protocols is >> that we are able to look back at legacy SL and Opensim protocols >> and recognize design mistakes or limitations in them. This allows >> us to avoid repeating such mistakes or limitations in the next >> generation of systems. >> >> One of the most common sources of frustration and dissatisfaction >> is simulator non-responsiveness. While this has many possible >> causes, in VWRAP we are not interested in the internal >> implementation of simulators, but we *ARE* interested in the >> ability of a protocol endpoint to perform its duty within the >> protocol. A jammed simulator host is in many cases quite unable >> to perform its protocol duties, or in some cases only exceedingly >> slowly, often timing out in a TP for example. We have a huge >> amount of experience of this happening in both SL and Opensim, so >> it is a practical reality. On occasion, simulators will be unable >> to fulfil their part in a protocol, and this needs to be taken >> into account because it is /not uncommon/. >> >> One key area in which the above is relevant is in teleports *OUT* >> of a simulator that is under distress. Quite often users wish >> nothing more than to /leave/ the region being run by a dying >> simulator, but when teleport-out requires cooperation from the >> host that one is trying to leave then this is often not possible >> at all. In this situation, the only remedy in existing systems is >> to forcibly terminate the client and relog in another region. We >> should avoid such out-of-protocol remedies being necessary through >> good protocol design. >> >> In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, >> which lead to corresponding protocol operations during teleport. If >> R1 is a region being run by a non-responsive simulator from >> which we want to escape, and R2 is another region to which we wish >> to go, if the protocol requires a Derez in R1 to be completed >> before a Rez in R2 can commence then the user will have >> difficulties. Clearly we don't want this. >> >> In _http://tools.ietf.org/html/draft-hamrick-ogp-intro-00_ , it is >> made clear that "/The agent domain MUST also remove the avatar >> from it's current location *before*// placing the avatar in the >> destination location/." This suggests that the protocol will be >> sensitive to R1 non-responsiveness. While we do not yet have an >> actual VWRAP Teleport draft, it seems likely that its initial >> incarnation will have that same problem built in. >> >> I suggest that the protocol define Derez and Rez as */concurrent/* >> and */non-dependent/* operations to avoid this situation. The AD >> can mark R1 as disabled for all further agent state changes --- >> this will provide all the protection needed to prevent brief >> double-presence anomalies from being significant. If a jammed R1 >> refuses to give up its hold on the avatar, then at least the user >> will not suffer from it. Reaping dead simulator sessions then >> becomes a problem for the region operator alone, and not for the >> AD, the user, and the region as happens now. >> >> Beware of one-size-fits-all requirements. I can easily imagine there will > be users who wouldn't want to have a degraded/alternate/unexpected > experience on TP failure and who WOULD want the system just to reset. And no > doubt other scenarios will make sense as well. After all, if someone uses > VWRAP as the foundation for a gaming platform, they may have completely > different rules that they expect users participating to follow as long as > they are participating. > > > Lawson > > Lawson > --001636c5bd9dd21a7e0476ab829b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Indeed!=A0=A0 Not only are extra user options always a good thing, but a TP= from a region in one world could be to a region in a highly different worl= d with very specific requirements.=A0 As you point out, "one size fits= all" is definitely inappropriate.

In this particular case, that could be handled by the AD sending the cl= ient an event notification to the effect that the source region did not res= pond within the timeout period.

The client would then be free to imp= lement disconnection if this is the user's configured choice.=A0 I thin= k it's fair to expect that most people would not choose that option, bu= t it should certainly be available to them if needed.

The agent would probably already be located in the destination region b= y this time from the AD's perspective (depending on timout length), but not ne= cessarily from the client's perspective --- that's a matter of client implementation and user optio= ns.=A0 Some Second Life clients already implement "Don't blank scr= een on TP", "Don't show TP progress bar" and "Displ= ay avatar before wearables are available" as options, so they're a= lready handling the component parts of the overall TP operation quite flexi= bly.

The AD of a world may itself have a policy of not allowing TPs to compl= ete when the source region is unavailable, but this should not be hardwired= into the protocol.=A0 As you say, one size does not fit all, particularly = in the case of choices that provide a bad user experience.


Morgaine.







=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Sat, Oc= t 24, 2009 at 7:21 AM, Lawson English <lenglish5@cox.net> wrote:
Morgaine wrote:
Excellent observation, David!

To use a different form of words, fault conditions can occur in all the pos= sible states of the system, and if we want the protocol to be robust then w= e'll probably have to examine all its major states and ensure that ther= e are always state transitions available out of them.

In that light, being able to TP out of a stuck region is just one of those = recovery transitions without which the protocol would simply break as a res= ult of the exception. =A0There is of course no need to design VWRAP such th= at exception handling always ends in session termination --- this would res= ult in a very poor user experience by default, and so it should be avoided = wherever possible.

My suggestion is therefore likely to be just one of many designed to avoid = session termination under conditions that, while not normal, are neverthele= ss unfortunately rather common in practice. =A0The user's client applic= ation should never be forced to disconnect completely (or even worse to ter= minate) unless there is absolutely no alternative, and it's up to us to= provide such alternatives wherever we can.

Breaking the user's immersive experience through termination should onl= y be a solution of last resort.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Fri, Oct 23, 2009 at 7:09 PM, David W Levine <dwl@us.ibm.com <mailto:dwl@us.ibm.com>> wrote:


=A0 =A0This is a good point, and highlights a very tricky issue in any
=A0 =A0distributed system design. A protocol should behave gracefully in =A0 =A0the face of failure. One of the definite challenges here is
=A0 =A0partition vs. failure. Its impossible to distinguish between a
=A0 =A0failed service and one which is lost behind a network partition. =A0 =A0In the case of a partition, with an avatar continuing to run on
=A0 =A0momentarily isolated region, care needs to be taken to recover
=A0 =A0gracefully not only from the "can't get to the region serv= ice" to
=A0 =A0get it to release the agent, but also the "The region has retu= rned
=A0 =A0to contact" =A0So,I think =A0when we talk about being resilien= t we
=A0 =A0need to think about the range of failure, from "the service I = was
=A0 =A0using has crashed" to "the service I was using has become=
=A0 =A0invisible due
=A0 =A0to a network partition." Of course, they look identical. This<= br> =A0 =A0rather strongly implies good semantics on what happens to a "S= tub"
=A0 =A0session which =A0becomes isolated as well as the "new" se= ssion
=A0 =A0which we create by bypassing a failed service. (In the case of
=A0 =A0teleport, the old region's idea of agent state and the new ones= ,
=A0 =A0in other cases, possibly other isolated state) =A0
=A0 =A0Food for thought

=A0 =A0- David
=A0 =A0~ Zha



=A0 =A0*Morgaine <morgaine.dinova@googlemail.com
=A0 =A0<mailto:morgaine.dinova@googlemail.com>>*
=A0 =A0Sent by: ogpx-bounces@ietf.org <mailto:ogpx-bounces@ietf.org>


=A0 =A010/23/2009 12:47 PM

=A0 =A0 =A0 =A0
=A0 =A0To
=A0 =A0 =A0 =A0ogpx@iet= f.org <mailto:ogp= x@ietf.org>

=A0 =A0cc
=A0 =A0 =A0 =A0
=A0 =A0Subject
=A0 =A0 =A0 =A0Re: [ogpx] Teleports and protocol resilience



=A0 =A0 =A0 =A0





=A0 =A0Looking back at the replies in this thread, I think that the goal =A0 =A0and the means to achieve it didn't quite come across.

=A0 =A0I was trying to address only a very specific issue, just protocol =A0 =A0resilience under source region non-responsiveness, since this is =A0 =A0common enough that it merits addressing. =A0I did not suggest that<= br> =A0 =A0there be any perceivable change of teleport semantics under normal<= br> =A0 =A0operation (because no such change is needed), only a change in
=A0 =A0service coupling. =A0The semantics we experience in SL and in
=A0 =A0Opensim would remain completely unchanged, except in the single
=A0 =A0case of source region non-responsiveness. =A0Under this single
=A0 =A0anomalous case there */would/* be a perceivable change, but that =A0 =A0change would be a huge improvement.

=A0 =A0There would be no new decoherence introduced since exactly the
=A0 =A0same state changes would occur on TP as before, with no possibiity<= br> =A0 =A0of agent state change in the source region once the AD accepts the = TP.

=A0 =A0All that's needed to achieve such resilience for teleport at th= e
=A0 =A0protocol level is a slight revision of operation phasing to permit<= br> =A0 =A0greater execution overlap, as I outlined. =A0This is independent of=
=A0 =A0anything else that happens in the course of the overall teleport =A0 =A0operation --- the change of phasing would affect only the transfer<= br> =A0 =A0of /agent location/ alone, nothing else.

=A0 =A0In particular, it should not be confused with the separate
=A0 =A0requirement for instantiation of assets or objects at destination,<= br> =A0 =A0nor with the matter of serializing and deserializing script
=A0 =A0states. =A0The latter has not even been defined for VWRAP, so it= 9;s
=A0 =A0hard to talk about changing it. =A0In any event, this isn't abo= ut
=A0 =A0those aspects of teleport, and doesn't affect them --- they wou= ld
=A0 =A0continue to work as before.

=A0 =A0One of the central aspects of VWRAP is that the protocol is based =A0 =A0on a multiple services model, and one of the key approaches in
=A0 =A0highly scalable systems design is to keep services decoupled to
=A0 =A0the largest extent possible. =A0That's what I'm proposing h= ere, a
=A0 =A0/partial decoupling/ that has no normal semantic change but which =A0 =A0does have benefits in anomalous situations.

=A0 =A0Agent location change /can/ be decoupled significantly from asset =A0 =A0instantiation change and script state transfer. =A0My suggestion =A0 =A0referred to this decoupled /agent location change/ only, not to
=A0 =A0asset and simulation services. =A0Those other two services undergo<= br> =A0 =A0state transitions at the same time as change of agent location
=A0 =A0does on TP, but services should never be coupled together
=A0 =A0unnecessarily, and in this case the coupling can be left very
=A0 =A0weak. =A0The three types of service operations can proceed each at<= br> =A0 =A0their own independent rates, coupled at TP initiation time and
=A0 =A0nowhere else.

=A0 =A0It should be noted that the legacy protocols do some of this
=A0 =A0already, in that the agent is already active in the destination
=A0 =A0region long before her avatar or objects have appeared. =A0 =A0Fur= thermore, the avatar currently continues to be visible in the
=A0 =A0source region for a while after the agent becomes active in the
=A0 =A0destination region, because of normal operation latencies,
=A0 =A0sim-side queueing, and client lag. =A0This is a normal part of
=A0 =A0current operation, and is not considered an anomaly. What's
=A0 =A0important is that no new state change to the agent is possible in =A0 =A0the source region after TP is initiated, and that would remain true= .

=A0 =A0The impact of this on the other parts of the puzzle needs to wait =A0 =A0until those other parts are examined. =A0We're not there yet, b= ut I
=A0 =A0would hope that improving teleport protocol resilience would be a =A0 =A0desireable goal when the only noticeable change in semantics
=A0 =A0occurs under fault conditions and provides a major improvement on =A0 =A0current behaviour.


=A0 =A0Morgaine.






=A0 =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=A0 =A0On Tue, Oct 13, 2009 at 6:13 AM, Morgaine
=A0 =A0<_morgaine.dinova@googlemail.com_

=A0 =A0<mailto:morgaine.dinova@googlemail.com>> wrote:
=A0 =A0One of the advantages we have in developing the VWRAP protocols is<= br> =A0 =A0that we are able to look back at legacy SL and Opensim protocols =A0 =A0and recognize design mistakes or limitations in them. =A0This allow= s
=A0 =A0us to avoid repeating such mistakes or limitations in the next
=A0 =A0generation of systems.

=A0 =A0One of the most common sources of frustration and dissatisfaction =A0 =A0is simulator non-responsiveness. =A0While this has many possible =A0 =A0causes, in VWRAP we are not interested in the internal
=A0 =A0implementation of simulators, but we *ARE* interested in the
=A0 =A0ability of a protocol endpoint to perform its duty within the
=A0 =A0protocol. =A0A jammed simulator host is in many cases quite unable<= br> =A0 =A0to perform its protocol duties, or in some cases only exceedingly =A0 =A0slowly, often timing out in a TP for example. =A0We have a huge
=A0 =A0amount of experience of this happening in both SL and Opensim, so =A0 =A0it is a practical reality. =A0On occasion, simulators will be unabl= e
=A0 =A0to fulfil their part in a protocol, and this needs to be taken
=A0 =A0into account because it is /not uncommon/.

=A0 =A0One key area in which the above is relevant is in teleports *OUT* =A0 =A0of a simulator that is under distress. =A0Quite often users wish =A0 =A0nothing more than to /leave/ the region being run by a dying
=A0 =A0simulator, but when teleport-out requires cooperation from the
=A0 =A0host that one is trying to leave then this is often not possible =A0 =A0at all. =A0In this situation, the only remedy in existing systems i= s
=A0 =A0to forcibly terminate the client and relog in another region. =A0We=
=A0 =A0should avoid such out-of-protocol remedies being necessary through<= br> =A0 =A0good protocol design.

=A0 =A0In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, =A0 =A0which lead to corresponding protocol operations during teleport. = =A0 =A0If R1 is a region being run by a non-responsive simulator from
=A0 =A0which we want to escape, and R2 is another region to which we wish<= br> =A0 =A0to go, if the protocol requires a Derez in R1 to be completed
=A0 =A0before a Rez in R2 can commence then the user will have
=A0 =A0difficulties. =A0Clearly we don't want this.

=A0 =A0In _http://tools.ietf.org/html/draft-hamrick-ogp-intro-00= _ , it is
=A0 =A0made clear that "/The agent domain MUST also remove the avatar=
=A0 =A0from it's current location *before*// placing the avatar in the=
=A0 =A0destination location/." =A0This suggests that the protocol wil= l be
=A0 =A0sensitive to R1 non-responsiveness. =A0While we do not yet have an<= br> =A0 =A0actual VWRAP Teleport draft, it seems likely that its initial
=A0 =A0incarnation will have that same problem built in.

=A0 =A0I suggest that the protocol define Derez and Rez as */concurrent/*<= br> =A0 =A0and */non-dependent/* operations to avoid this situation. =A0The AD=
=A0 =A0can mark R1 as disabled for all further agent state changes ---
=A0 =A0this will provide all the protection needed to prevent brief
=A0 =A0double-presence anomalies from being significant. =A0If a jammed R1=
=A0 =A0refuses to give up its hold on the avatar, then at least the user =A0 =A0will not suffer from it. =A0Reaping dead simulator sessions then =A0 =A0becomes a problem for the region operator alone, and not for the =A0 =A0AD, the user, and the region as happens now.

Beware of one-size-fits-all requirements. I can easily imagine there will b= e users who wouldn't want to have a degraded/alternate/unexpected exper= ience on TP failure and who WOULD want the system just to reset. And no dou= bt other scenarios will make sense as well. After all, if someone uses VWRA= P as the foundation for a gaming platform, they may have completely differe= nt rules that they expect users participating to follow as long as they are= participating.


Lawson

Lawson

--001636c5bd9dd21a7e0476ab829b-- From vaughn.deluca@gmail.com Sat Oct 24 06:59:14 2009 Return-Path: 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 3FAD53A6843 for ; Sat, 24 Oct 2009 06:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 795twTGJMo1r for ; Sat, 24 Oct 2009 06:59:11 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id DFFAB3A67F8 for ; Sat, 24 Oct 2009 06:59:10 -0700 (PDT) Received: by fxm18 with SMTP id 18so11006473fxm.37 for ; Sat, 24 Oct 2009 06:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GTJ8S76+z0CBw4P2qYkSiFivsa6Zdkupxj5VRVDxQaA=; b=QB0aMUYcxVjf/xnL6XPY8LHr1g73AkVE+84Mzdr6srNbFxidCb6pQFUrf/1E5WPWAs jfT4QaUZdVKax6emQS9cECNkGeCvfqExaKSxpvUY+8JB153kpvQ9JjW72m7BWu14DvxR ghFUMz+5H0+fsMoCqOA3/S5ew4c5u6tLw14/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Inq2XfBzSeWinGoev3JzaWEWSp3VYECQEz3tF76MpZRLljQYrTE3AkTfsOHli4JABn TTjHxa3mQH0pXwbQ+nFY+vRdgpXDImEyRLkRwPyBy95hRSEFUojlnrSNu7Gds+IdKxOB PV2WqEPfej35t1Lr9R1KJm+XO2nMhvkI5Oncg= MIME-Version: 1.0 Received: by 10.204.162.210 with SMTP id w18mr3498863bkx.174.1256392759048; Sat, 24 Oct 2009 06:59:19 -0700 (PDT) In-Reply-To: References: <4AE29CDF.1070208@cox.net> Date: Sat, 24 Oct 2009 15:59:18 +0200 Message-ID: <9b8a8de40910240659h649d0c35kab5706b5a2cd6caf@mail.gmail.com> From: Vaughn Deluca To: Morgaine Content-Type: multipart/alternative; boundary=000325559f3e19f9d90476aebc3b Cc: ogpx@ietf.org Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 13:59:14 -0000 --000325559f3e19f9d90476aebc3b Content-Type: text/plain; charset=ISO-8859-1 Morgaine, If I understand you right, you are suggesting the following: - The agent domain is able to complete a teleport (after a timeout period) even if the original region completley fails to respond, so *even* if there is no guarantee the invocation of the derez cap has been processed. - To prevent true duplication of avatars, the again domain keeps some record of the old connection, to be able to deal gracefully with the case that the old region comes back to life. This implies that in some cases two copies of the avatar might be visible, one "dead body" in the old region, and the live version in the new region. This might in some cases be preferable to a stranded avatar, yet in other situation could be unacceptable (e.g. in a combat game, were mere visual presence might be enough to influence the game). -Therefore, in spite of the freedom of the agent domain to complete a tp from a non-responding region, its left up to the region to decide if it wants to accept the rezzing of an avatar that has not completed the de-rezzing in the old region. - Since there is no way to get the most recent agent state from the old region, this special TP without conformation from the originating region would bring back the agent in some default state in the new region. This process would lead to a graceful degradation of the system. With some clever setting of defaults it might not be too disturbing for the avatar. It is left up to the client to instruct the agent service about the way to deal with these types of anomalies. -Finally, your suggestions imply that the Agent service MAY acts as an intermediate in the TP, rather than the two regions communicating directly as the current TP draft specifies. At first sight is all looks reasonably realistic, yet it is for sure more complicated than the current TP draft, and I am not really able to judge what we are actually bringing onto our selfs here. - Vaughn . On Sat, Oct 24, 2009 at 12:08 PM, Morgaine wrote: > Indeed! Not only are extra user options always a good thing, but a TP > from a region in one world could be to a region in a highly different world > with very specific requirements. As you point out, "one size fits all" is > definitely inappropriate. > > In this particular case, that could be handled by the AD sending the client > an event notification to the effect that the source region did not respond > within the timeout period. > > The client would then be free to implement disconnection if this is the > user's configured choice. I think it's fair to expect that most people > would not choose that option, but it should certainly be available to them > if needed. > > The agent would probably already be located in the destination region by > this time from the AD's perspective (depending on timout length), but not > necessarily from the client's perspective --- that's a matter of client > implementation and user options. Some Second Life clients already implement > "Don't blank screen on TP", "Don't show TP progress bar" and "Display avatar > before wearables are available" as options, so they're already handling the > component parts of the overall TP operation quite flexibly. > > The AD of a world may itself have a policy of not allowing TPs to complete > when the source region is unavailable, but this should not be hardwired into > the protocol. As you say, one size does not fit all, particularly in the > case of choices that provide a bad user experience. > > > Morgaine. > > > > > > > > =========================================== > > > On Sat, Oct 24, 2009 at 7:21 AM, Lawson English wrote: > >> Morgaine wrote: >> >>> Excellent observation, David! >>> >>> To use a different form of words, fault conditions can occur in all the >>> possible states of the system, and if we want the protocol to be robust then >>> we'll probably have to examine all its major states and ensure that there >>> are always state transitions available out of them. >>> >>> In that light, being able to TP out of a stuck region is just one of >>> those recovery transitions without which the protocol would simply break as >>> a result of the exception. There is of course no need to design VWRAP such >>> that exception handling always ends in session termination --- this would >>> result in a very poor user experience by default, and so it should be >>> avoided wherever possible. >>> >>> My suggestion is therefore likely to be just one of many designed to >>> avoid session termination under conditions that, while not normal, are >>> nevertheless unfortunately rather common in practice. The user's client >>> application should never be forced to disconnect completely (or even worse >>> to terminate) unless there is absolutely no alternative, and it's up to us >>> to provide such alternatives wherever we can. >>> >>> Breaking the user's immersive experience through termination should only >>> be a solution of last resort. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> ==================================== >>> >>> On Fri, Oct 23, 2009 at 7:09 PM, David W Levine >> dwl@us.ibm.com>> wrote: >>> >>> >>> This is a good point, and highlights a very tricky issue in any >>> distributed system design. A protocol should behave gracefully in >>> the face of failure. One of the definite challenges here is >>> partition vs. failure. Its impossible to distinguish between a >>> failed service and one which is lost behind a network partition. >>> In the case of a partition, with an avatar continuing to run on >>> momentarily isolated region, care needs to be taken to recover >>> gracefully not only from the "can't get to the region service" to >>> get it to release the agent, but also the "The region has returned >>> to contact" So,I think when we talk about being resilient we >>> need to think about the range of failure, from "the service I was >>> using has crashed" to "the service I was using has become >>> invisible due >>> to a network partition." Of course, they look identical. This >>> rather strongly implies good semantics on what happens to a "Stub" >>> session which becomes isolated as well as the "new" session >>> which we create by bypassing a failed service. (In the case of >>> teleport, the old region's idea of agent state and the new ones, >>> in other cases, possibly other isolated state) >>> Food for thought >>> >>> - David >>> ~ Zha >>> >>> >>> >>> *Morgaine >> >* >>> Sent by: ogpx-bounces@ietf.org >>> >>> >>> 10/23/2009 12:47 PM >>> >>> >>> To >>> ogpx@ietf.org >>> >>> cc >>> >>> Subject >>> Re: [ogpx] Teleports and protocol resilience >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Looking back at the replies in this thread, I think that the goal >>> and the means to achieve it didn't quite come across. >>> >>> I was trying to address only a very specific issue, just protocol >>> resilience under source region non-responsiveness, since this is >>> common enough that it merits addressing. I did not suggest that >>> there be any perceivable change of teleport semantics under normal >>> operation (because no such change is needed), only a change in >>> service coupling. The semantics we experience in SL and in >>> Opensim would remain completely unchanged, except in the single >>> case of source region non-responsiveness. Under this single >>> anomalous case there */would/* be a perceivable change, but that >>> change would be a huge improvement. >>> >>> There would be no new decoherence introduced since exactly the >>> same state changes would occur on TP as before, with no possibiity >>> of agent state change in the source region once the AD accepts the TP. >>> >>> All that's needed to achieve such resilience for teleport at the >>> protocol level is a slight revision of operation phasing to permit >>> greater execution overlap, as I outlined. This is independent of >>> anything else that happens in the course of the overall teleport >>> operation --- the change of phasing would affect only the transfer >>> of /agent location/ alone, nothing else. >>> >>> In particular, it should not be confused with the separate >>> requirement for instantiation of assets or objects at destination, >>> nor with the matter of serializing and deserializing script >>> states. The latter has not even been defined for VWRAP, so it's >>> hard to talk about changing it. In any event, this isn't about >>> those aspects of teleport, and doesn't affect them --- they would >>> continue to work as before. >>> >>> One of the central aspects of VWRAP is that the protocol is based >>> on a multiple services model, and one of the key approaches in >>> highly scalable systems design is to keep services decoupled to >>> the largest extent possible. That's what I'm proposing here, a >>> /partial decoupling/ that has no normal semantic change but which >>> does have benefits in anomalous situations. >>> >>> Agent location change /can/ be decoupled significantly from asset >>> instantiation change and script state transfer. My suggestion >>> referred to this decoupled /agent location change/ only, not to >>> asset and simulation services. Those other two services undergo >>> state transitions at the same time as change of agent location >>> does on TP, but services should never be coupled together >>> unnecessarily, and in this case the coupling can be left very >>> weak. The three types of service operations can proceed each at >>> their own independent rates, coupled at TP initiation time and >>> nowhere else. >>> >>> It should be noted that the legacy protocols do some of this >>> already, in that the agent is already active in the destination >>> region long before her avatar or objects have appeared. >>> Furthermore, the avatar currently continues to be visible in the >>> source region for a while after the agent becomes active in the >>> destination region, because of normal operation latencies, >>> sim-side queueing, and client lag. This is a normal part of >>> current operation, and is not considered an anomaly. What's >>> important is that no new state change to the agent is possible in >>> the source region after TP is initiated, and that would remain true. >>> >>> The impact of this on the other parts of the puzzle needs to wait >>> until those other parts are examined. We're not there yet, but I >>> would hope that improving teleport protocol resilience would be a >>> desireable goal when the only noticeable change in semantics >>> occurs under fault conditions and provides a major improvement on >>> current behaviour. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> >>> ====================================== >>> >>> On Tue, Oct 13, 2009 at 6:13 AM, Morgaine >>> <_morgaine.dinova@googlemail.com_ >>> >>> > wrote: >>> One of the advantages we have in developing the VWRAP protocols is >>> that we are able to look back at legacy SL and Opensim protocols >>> and recognize design mistakes or limitations in them. This allows >>> us to avoid repeating such mistakes or limitations in the next >>> generation of systems. >>> >>> One of the most common sources of frustration and dissatisfaction >>> is simulator non-responsiveness. While this has many possible >>> causes, in VWRAP we are not interested in the internal >>> implementation of simulators, but we *ARE* interested in the >>> ability of a protocol endpoint to perform its duty within the >>> protocol. A jammed simulator host is in many cases quite unable >>> to perform its protocol duties, or in some cases only exceedingly >>> slowly, often timing out in a TP for example. We have a huge >>> amount of experience of this happening in both SL and Opensim, so >>> it is a practical reality. On occasion, simulators will be unable >>> to fulfil their part in a protocol, and this needs to be taken >>> into account because it is /not uncommon/. >>> >>> One key area in which the above is relevant is in teleports *OUT* >>> of a simulator that is under distress. Quite often users wish >>> nothing more than to /leave/ the region being run by a dying >>> simulator, but when teleport-out requires cooperation from the >>> host that one is trying to leave then this is often not possible >>> at all. In this situation, the only remedy in existing systems is >>> to forcibly terminate the client and relog in another region. We >>> should avoid such out-of-protocol remedies being necessary through >>> good protocol design. >>> >>> In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, >>> which lead to corresponding protocol operations during teleport. If >>> R1 is a region being run by a non-responsive simulator from >>> which we want to escape, and R2 is another region to which we wish >>> to go, if the protocol requires a Derez in R1 to be completed >>> before a Rez in R2 can commence then the user will have >>> difficulties. Clearly we don't want this. >>> >>> In _http://tools.ietf.org/html/draft-hamrick-ogp-intro-00_ , it is >>> made clear that "/The agent domain MUST also remove the avatar >>> from it's current location *before*// placing the avatar in the >>> destination location/." This suggests that the protocol will be >>> sensitive to R1 non-responsiveness. While we do not yet have an >>> actual VWRAP Teleport draft, it seems likely that its initial >>> incarnation will have that same problem built in. >>> >>> I suggest that the protocol define Derez and Rez as */concurrent/* >>> and */non-dependent/* operations to avoid this situation. The AD >>> can mark R1 as disabled for all further agent state changes --- >>> this will provide all the protection needed to prevent brief >>> double-presence anomalies from being significant. If a jammed R1 >>> refuses to give up its hold on the avatar, then at least the user >>> will not suffer from it. Reaping dead simulator sessions then >>> becomes a problem for the region operator alone, and not for the >>> AD, the user, and the region as happens now. >>> >>> Beware of one-size-fits-all requirements. I can easily imagine there >> will be users who wouldn't want to have a degraded/alternate/unexpected >> experience on TP failure and who WOULD want the system just to reset. And no >> doubt other scenarios will make sense as well. After all, if someone uses >> VWRAP as the foundation for a gaming platform, they may have completely >> different rules that they expect users participating to follow as long as >> they are participating. >> >> >> Lawson >> >> Lawson >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --000325559f3e19f9d90476aebc3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Morgaine,=A0

If I understand you right, you a= re suggesting the following:

- The agent domain is= able to complete a teleport (after a timeout period) even if the original = region completley fails to respond, so *even* if there is no guarantee the = invocation of the derez cap has been processed.

- To prevent true=A0duplication of avatars, the again domain keeps som= e record of the old connection, to be able to deal gracefully with the =A0c= ase that the old region comes back to life. This implies that in some cases= two copies of the avatar might be visible, one "dead body" in th= e old region, and the live version in the new region. This might in some ca= ses be preferable to a stranded avatar, yet in other situation could be una= cceptable (e.g. in a combat game, were mere visual presence might be enough= to influence the game).=A0

-Therefore, in spite of the freedom of the agent domain= to complete a tp from a non-responding region, its left up to the region t= o decide if it wants to accept the rezzing of an avatar that has not =A0com= pleted the de-rezzing in the old region.

- Since there is no way to get the most recent agent st= ate from the old region, this special TP without conformation from the orig= inating region would bring back the agent in some default state in the new = region. This process would lead to a graceful degradation of the system. Wi= th some clever setting of defaults it might not be too disturbing for the a= vatar. =A0It is left up to the client to instruct the agent service about t= he way to deal with these types of anomalies.

-Finally, your suggestions imply that the Agent = =A0service MAY acts as an intermediate in the TP, rather than the two regio= ns communicating directly as the current TP draft specifies.

At first sight is all looks reasonably realistic, yet it is for = sure more complicated than the current TP draft, and I am not really able t= o judge what we are actually bringing onto our selfs here.

- Vaughn
.

On Sat, Oct 24, 2009 at 12:08 PM, Mo= rgaine <morgaine.dinova@googlemail.com> wrote:<= br>
Indeed!=A0=A0 Not only are extra user option= s always a good thing, but a TP from a region in one world could be to a re= gion in a highly different world with very specific requirements.=A0 As you= point out, "one size fits all" is definitely inappropriate.

In this particular case, that could be handled by the AD sending the cl= ient an event notification to the effect that the source region did not res= pond within the timeout period.

The client would then be free to imp= lement disconnection if this is the user's configured choice.=A0 I thin= k it's fair to expect that most people would not choose that option, bu= t it should certainly be available to them if needed.

The agent would probably already be located in the destination region b= y this time from the AD's perspective (depending on timout length), but not ne= cessarily from the client's perspective --- that's a matter of client implementation and user optio= ns.=A0 Some Second Life clients already implement "Don't blank scr= een on TP", "Don't show TP progress bar" and "Displ= ay avatar before wearables are available" as options, so they're a= lready handling the component parts of the overall TP operation quite flexi= bly.

The AD of a world may itself have a policy of not allowing TPs to compl= ete when the source region is unavailable, but this should not be hardwired= into the protocol.=A0 As you say, one size does not fit all, particularly = in the case of choices that provide a bad user experience.


Morgaine.







=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On Sat, Oct 24, 2009 at 7:21 AM, Lawson English <lenglish5@cox.= net> wrote:
Morgaine wrote:
Excellent observation, David!

To use a different form of words, fault conditions can occur in all the pos= sible states of the system, and if we want the protocol to be robust then w= e'll probably have to examine all its major states and ensure that ther= e are always state transitions available out of them.

In that light, being able to TP out of a stuck region is just one of those = recovery transitions without which the protocol would simply break as a res= ult of the exception. =A0There is of course no need to design VWRAP such th= at exception handling always ends in session termination --- this would res= ult in a very poor user experience by default, and so it should be avoided = wherever possible.

My suggestion is therefore likely to be just one of many designed to avoid = session termination under conditions that, while not normal, are neverthele= ss unfortunately rather common in practice. =A0The user's client applic= ation should never be forced to disconnect completely (or even worse to ter= minate) unless there is absolutely no alternative, and it's up to us to= provide such alternatives wherever we can.

Breaking the user's immersive experience through termination should onl= y be a solution of last resort.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Fri, Oct 23, 2009 at 7:09 PM, David W Levine <dwl@us.ibm.com <mailto:dwl@us.ibm.com>> wrote:


=A0 =A0This is a good point, and highlights a very tricky issue in any
=A0 =A0distributed system design. A protocol should behave gracefully in =A0 =A0the face of failure. One of the definite challenges here is
=A0 =A0partition vs. failure. Its impossible to distinguish between a
=A0 =A0failed service and one which is lost behind a network partition. =A0 =A0In the case of a partition, with an avatar continuing to run on
=A0 =A0momentarily isolated region, care needs to be taken to recover
=A0 =A0gracefully not only from the "can't get to the region serv= ice" to
=A0 =A0get it to release the agent, but also the "The region has retu= rned
=A0 =A0to contact" =A0So,I think =A0when we talk about being resilien= t we
=A0 =A0need to think about the range of failure, from "the service I = was
=A0 =A0using has crashed" to "the service I was using has become=
=A0 =A0invisible due
=A0 =A0to a network partition." Of course, they look identical. This<= br> =A0 =A0rather strongly implies good semantics on what happens to a "S= tub"
=A0 =A0session which =A0becomes isolated as well as the "new" se= ssion
=A0 =A0which we create by bypassing a failed service. (In the case of
=A0 =A0teleport, the old region's idea of agent state and the new ones= ,
=A0 =A0in other cases, possibly other isolated state) =A0
=A0 =A0Food for thought

=A0 =A0- David
=A0 =A0~ Zha



=A0 =A0*Morgaine <morgaine.dinova@googlemail.com
=A0 =A0<mailto:morgaine.dinova@googlemail.com>>*
=A0 =A0Sent by: ogpx-bounces@ietf.org <mailto:ogpx-bounces@ietf.org>


=A0 =A010/23/2009 12:47 PM

=A0 =A0 =A0 =A0
=A0 =A0To
=A0 =A0 =A0 =A0ogpx@iet= f.org <mailto:ogp= x@ietf.org>

=A0 =A0cc
=A0 =A0 =A0 =A0
=A0 =A0Subject
=A0 =A0 =A0 =A0Re: [ogpx] Teleports and protocol resilience



=A0 =A0 =A0 =A0





=A0 =A0Looking back at the replies in this thread, I think that the goal =A0 =A0and the means to achieve it didn't quite come across.

=A0 =A0I was trying to address only a very specific issue, just protocol =A0 =A0resilience under source region non-responsiveness, since this is =A0 =A0common enough that it merits addressing. =A0I did not suggest that<= br> =A0 =A0there be any perceivable change of teleport semantics under normal<= br> =A0 =A0operation (because no such change is needed), only a change in
=A0 =A0service coupling. =A0The semantics we experience in SL and in
=A0 =A0Opensim would remain completely unchanged, except in the single
=A0 =A0case of source region non-responsiveness. =A0Under this single
=A0 =A0anomalous case there */would/* be a perceivable change, but that =A0 =A0change would be a huge improvement.

=A0 =A0There would be no new decoherence introduced since exactly the
=A0 =A0same state changes would occur on TP as before, with no possibiity<= br> =A0 =A0of agent state change in the source region once the AD accepts the = TP.

=A0 =A0All that's needed to achieve such resilience for teleport at th= e
=A0 =A0protocol level is a slight revision of operation phasing to permit<= br> =A0 =A0greater execution overlap, as I outlined. =A0This is independent of=
=A0 =A0anything else that happens in the course of the overall teleport =A0 =A0operation --- the change of phasing would affect only the transfer<= br> =A0 =A0of /agent location/ alone, nothing else.

=A0 =A0In particular, it should not be confused with the separate
=A0 =A0requirement for instantiation of assets or objects at destination,<= br> =A0 =A0nor with the matter of serializing and deserializing script
=A0 =A0states. =A0The latter has not even been defined for VWRAP, so it= 9;s
=A0 =A0hard to talk about changing it. =A0In any event, this isn't abo= ut
=A0 =A0those aspects of teleport, and doesn't affect them --- they wou= ld
=A0 =A0continue to work as before.

=A0 =A0One of the central aspects of VWRAP is that the protocol is based =A0 =A0on a multiple services model, and one of the key approaches in
=A0 =A0highly scalable systems design is to keep services decoupled to
=A0 =A0the largest extent possible. =A0That's what I'm proposing h= ere, a
=A0 =A0/partial decoupling/ that has no normal semantic change but which =A0 =A0does have benefits in anomalous situations.

=A0 =A0Agent location change /can/ be decoupled significantly from asset =A0 =A0instantiation change and script state transfer. =A0My suggestion =A0 =A0referred to this decoupled /agent location change/ only, not to
=A0 =A0asset and simulation services. =A0Those other two services undergo<= br> =A0 =A0state transitions at the same time as change of agent location
=A0 =A0does on TP, but services should never be coupled together
=A0 =A0unnecessarily, and in this case the coupling can be left very
=A0 =A0weak. =A0The three types of service operations can proceed each at<= br> =A0 =A0their own independent rates, coupled at TP initiation time and
=A0 =A0nowhere else.

=A0 =A0It should be noted that the legacy protocols do some of this
=A0 =A0already, in that the agent is already active in the destination
=A0 =A0region long before her avatar or objects have appeared. =A0 =A0Fur= thermore, the avatar currently continues to be visible in the
=A0 =A0source region for a while after the agent becomes active in the
=A0 =A0destination region, because of normal operation latencies,
=A0 =A0sim-side queueing, and client lag. =A0This is a normal part of
=A0 =A0current operation, and is not considered an anomaly. What's
=A0 =A0important is that no new state change to the agent is possible in =A0 =A0the source region after TP is initiated, and that would remain true= .

=A0 =A0The impact of this on the other parts of the puzzle needs to wait =A0 =A0until those other parts are examined. =A0We're not there yet, b= ut I
=A0 =A0would hope that improving teleport protocol resilience would be a =A0 =A0desireable goal when the only noticeable change in semantics
=A0 =A0occurs under fault conditions and provides a major improvement on =A0 =A0current behaviour.


=A0 =A0Morgaine.






=A0 =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=A0 =A0On Tue, Oct 13, 2009 at 6:13 AM, Morgaine
=A0 =A0<_morgaine.dinova@googlemail.com_

=A0 =A0<mailto:morgaine.dinova@googlemail.com>> wrote:
=A0 =A0One of the advantages we have in developing the VWRAP protocols is<= br> =A0 =A0that we are able to look back at legacy SL and Opensim protocols =A0 =A0and recognize design mistakes or limitations in them. =A0This allow= s
=A0 =A0us to avoid repeating such mistakes or limitations in the next
=A0 =A0generation of systems.

=A0 =A0One of the most common sources of frustration and dissatisfaction =A0 =A0is simulator non-responsiveness. =A0While this has many possible =A0 =A0causes, in VWRAP we are not interested in the internal
=A0 =A0implementation of simulators, but we *ARE* interested in the
=A0 =A0ability of a protocol endpoint to perform its duty within the
=A0 =A0protocol. =A0A jammed simulator host is in many cases quite unable<= br> =A0 =A0to perform its protocol duties, or in some cases only exceedingly =A0 =A0slowly, often timing out in a TP for example. =A0We have a huge
=A0 =A0amount of experience of this happening in both SL and Opensim, so =A0 =A0it is a practical reality. =A0On occasion, simulators will be unabl= e
=A0 =A0to fulfil their part in a protocol, and this needs to be taken
=A0 =A0into account because it is /not uncommon/.

=A0 =A0One key area in which the above is relevant is in teleports *OUT* =A0 =A0of a simulator that is under distress. =A0Quite often users wish =A0 =A0nothing more than to /leave/ the region being run by a dying
=A0 =A0simulator, but when teleport-out requires cooperation from the
=A0 =A0host that one is trying to leave then this is often not possible =A0 =A0at all. =A0In this situation, the only remedy in existing systems i= s
=A0 =A0to forcibly terminate the client and relog in another region. =A0We=
=A0 =A0should avoid such out-of-protocol remedies being necessary through<= br> =A0 =A0good protocol design.

=A0 =A0In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, =A0 =A0which lead to corresponding protocol operations during teleport. = =A0 =A0If R1 is a region being run by a non-responsive simulator from
=A0 =A0which we want to escape, and R2 is another region to which we wish<= br> =A0 =A0to go, if the protocol requires a Derez in R1 to be completed
=A0 =A0before a Rez in R2 can commence then the user will have
=A0 =A0difficulties. =A0Clearly we don't want this.

=A0 =A0In _http://tools.ietf.org/html/draft-hamrick-ogp-intro-00= _ , it is
=A0 =A0made clear that "/The agent domain MUST also remove the avatar=
=A0 =A0from it's current location *before*// placing the avatar in the=
=A0 =A0destination location/." =A0This suggests that the protocol wil= l be
=A0 =A0sensitive to R1 non-responsiveness. =A0While we do not yet have an<= br> =A0 =A0actual VWRAP Teleport draft, it seems likely that its initial
=A0 =A0incarnation will have that same problem built in.

=A0 =A0I suggest that the protocol define Derez and Rez as */concurrent/*<= br> =A0 =A0and */non-dependent/* operations to avoid this situation. =A0The AD=
=A0 =A0can mark R1 as disabled for all further agent state changes ---
=A0 =A0this will provide all the protection needed to prevent brief
=A0 =A0double-presence anomalies from being significant. =A0If a jammed R1=
=A0 =A0refuses to give up its hold on the avatar, then at least the user =A0 =A0will not suffer from it. =A0Reaping dead simulator sessions then =A0 =A0becomes a problem for the region operator alone, and not for the =A0 =A0AD, the user, and the region as happens now.

Beware of one-size-fits-all requirements. I can easily imagine there will b= e users who wouldn't want to have a degraded/alternate/unexpected exper= ience on TP failure and who WOULD want the system just to reset. And no dou= bt other scenarios will make sense as well. After all, if someone uses VWRA= P as the foundation for a gaming platform, they may have completely differe= nt rules that they expect users participating to follow as long as they are= participating.


Lawson

Lawson


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--000325559f3e19f9d90476aebc3b-- From morgaine.dinova@googlemail.com Sat Oct 24 19:47:35 2009 Return-Path: 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 B51843A63EB for ; Sat, 24 Oct 2009 19:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 8w5IiknUQ4Ge for ; Sat, 24 Oct 2009 19:47:32 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 990AB3A677D for ; Sat, 24 Oct 2009 19:47:31 -0700 (PDT) Received: by ewy4 with SMTP id 4so2706731ewy.37 for ; Sat, 24 Oct 2009 19:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=/T86+TtcGDU1jSUri6xpw4JfWrB328usURwO7I3u4uk=; b=d67bU42Nx2jg3ZDe5Xpuiz2YKxQOsAgmsntNbw8q57kK6/etmv/kyKcFHkGNJUYnNA iN6Akk88DqVA+gUPqAVSrlooplGwsZ9ujYI3gs3PX+RD+w2hIhlW3rbJSgBNk+tNwfS4 r5eoFvBtQL4gpjVOh5aOBUyaHLKeIuxCjN4Nc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=DMYUBCXJfslbMaJqbZPS5AG3jDAraDeh6g6aIDk0gAI+6hqBldh2hg5HGJGmc1+035 fo8lpXz5vFgv4luI5nIVea9XlT7kIu6T10oxyCFmHJi6r4p3OjiraSz0D6oMi/S5A3sj wubzKQSrEMuyB21qvWrU6Ot+Sc2K7sFDloL0U= MIME-Version: 1.0 Received: by 10.211.184.14 with SMTP id l14mr2593413ebp.18.1256438859494; Sat, 24 Oct 2009 19:47:39 -0700 (PDT) In-Reply-To: <9b8a8de40910240659h649d0c35kab5706b5a2cd6caf@mail.gmail.com> References: <4AE29CDF.1070208@cox.net> <9b8a8de40910240659h649d0c35kab5706b5a2cd6caf@mail.gmail.com> Date: Sun, 25 Oct 2009 03:47:39 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001517476732e6f78a0476b977f8 Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 02:47:35 -0000 --001517476732e6f78a0476b977f8 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 24, 2009 at 2:59 PM, Vaughn Deluca wrote: > > - The agent domain is able to complete a teleport (after a timeout period) > even if the original region completley fails to respond, so *even* if there > is no guarantee the invocation of the derez cap has been processed. > By "complete a teleport" I mean "*succeed in placing the agent in the destination region independent of the state of its avatar*". I'm making this distinction because that's precisely the semantic we have right now in SL and Opensim --- the avatar wearables and attachments arrive much later, asynchronously. The *avatar* does *not* obey a semantic of "one place only" but has parallel existence for a short while in both regions even under normal operation. (Under abnormal operation of the source region, that overlap can last a very long time.) It's the *active agent* that has unique existence in only one region at a time, and that's the semantic which I want to preserve as well. (It's worth mentioning that the avatar and its equiped objects are left to appear/disappear at their own sweet rate for a very good pragmatic reason. Teleport would take an eternity if it were defined as a fully synchronous operation for all relevant parts of agent and avatar together.) > - To prevent true duplication of avatars, the again domain keeps some > record of the old connection, to be able to deal gracefully with the case > that the old region comes back to life. This implies that in some cases two > copies of the avatar might be visible, one "dead body" in the old region, > and the live version in the new region. This might in some cases be > preferable to a stranded avatar, yet in other situation could be > unacceptable (e.g. in a combat game, were mere visual presence might be > enough to influence the game). > Note that this dual presence of avatars is exactly the situation that we have currently, as I outlined above. It's important to be clear about the distinction between agents and avatars in this area. The key semantic is that, even if an avatar is still visible in the source region after a teleport, there be *no active agent* associated with it. In other words, any events which the source region may send the agent after the AD has accepted the TP are discarded. Under normal operation there should be no such inappropriate events arriving because the source region will have processed the Derez, but under abnormal operation anything can happen so one has to handle it defensively. As concurrent programming becomes more common in this emerging "age of multicore", we're going to be seeing these kinds of anomalies arise with ever greater frequency, particularly as regions become virtualized or implemented scalably on clusters. > -Therefore, in spite of the freedom of the agent domain to complete a tp > from a non-responding region, its left up to the region to decide if it > wants to accept the rezzing of an avatar that has not completed the > de-rezzing in the old region. > Yes. As Lawson highlighted, "one size fits all" is not appropriate. > > - Since there is no way to get the most recent agent state from the old > region, this special TP without conformation from the originating region > would bring back the agent in some default state in the new region. This > process would lead to a graceful degradation of the system. With some clever > setting of defaults it might not be too disturbing for the avatar. It is > left up to the client to instruct the agent service about the way to deal > with these types of anomalies. > Fortunately it's a very easy anomaly to handle, since the TP simply acquires the semantic of a first-time rez in the destination region at the point of source region timeout. > > -Finally, your suggestions imply that the Agent service MAY acts as an > intermediate in the TP, rather than the two regions communicating directly > as the current TP draft specifies. > The AD carries the "first say" responsibility for agent teleport policy, that's its key role in teleports, and therefore it must always be an intermediary in teleports otherwise it cannot effect such agent policy. Region-to-region communication should really be seen as a behind-the-scenes optimization or an implementation detail for *avatar* asset/object/state transfer --- notice clearly it's *avatar* here, not agent. And since it breaks resilient teleport under source region anomalies, it needs to be optional. > > At first sight is all looks reasonably realistic, yet it is for sure more > complicated than the current TP draft, and I am not really able to judge > what we are actually bringing onto our selfs here. > These are pre-draft discussions for VWRAP --- I've purposely avoided focussing on the original OGP Teleport drafts since many things are changing for VWRAP anyway as a result of the introduction of RD-controlled services that do not feature in the original drafts. We've got to get the VWRAP teleport semantics well understood in our minds first before churning out a VWRAP Teleport draft spec for it. There are still many unknowns in this area. :-) Morgaine. ======================================== On Sat, Oct 24, 2009 at 2:59 PM, Vaughn Deluca wrote: > Morgaine, > > If I understand you right, you are suggesting the following: > > - The agent domain is able to complete a teleport (after a timeout period) > even if the original region completley fails to respond, so *even* if there > is no guarantee the invocation of the derez cap has been processed. > > - To prevent true duplication of avatars, the again domain keeps some > record of the old connection, to be able to deal gracefully with the case > that the old region comes back to life. This implies that in some cases two > copies of the avatar might be visible, one "dead body" in the old region, > and the live version in the new region. This might in some cases be > preferable to a stranded avatar, yet in other situation could be > unacceptable (e.g. in a combat game, were mere visual presence might be > enough to influence the game). > > -Therefore, in spite of the freedom of the agent domain to complete a tp > from a non-responding region, its left up to the region to decide if it > wants to accept the rezzing of an avatar that has not completed the > de-rezzing in the old region. > > - Since there is no way to get the most recent agent state from the old > region, this special TP without conformation from the originating region > would bring back the agent in some default state in the new region. This > process would lead to a graceful degradation of the system. With some clever > setting of defaults it might not be too disturbing for the avatar. It is > left up to the client to instruct the agent service about the way to deal > with these types of anomalies. > > -Finally, your suggestions imply that the Agent service MAY acts as an > intermediate in the TP, rather than the two regions communicating directly > as the current TP draft specifies. > > At first sight is all looks reasonably realistic, yet it is for sure more > complicated than the current TP draft, and I am not really able to judge > what we are actually bringing onto our selfs here. > > - Vaughn > . > > > On Sat, Oct 24, 2009 at 12:08 PM, Morgaine > wrote: > >> Indeed! Not only are extra user options always a good thing, but a TP >> from a region in one world could be to a region in a highly different world >> with very specific requirements. As you point out, "one size fits all" is >> definitely inappropriate. >> >> In this particular case, that could be handled by the AD sending the >> client an event notification to the effect that the source region did not >> respond within the timeout period. >> >> The client would then be free to implement disconnection if this is the >> user's configured choice. I think it's fair to expect that most people >> would not choose that option, but it should certainly be available to them >> if needed. >> >> The agent would probably already be located in the destination region by >> this time from the AD's perspective (depending on timout length), but not >> necessarily from the client's perspective --- that's a matter of client >> implementation and user options. Some Second Life clients already implement >> "Don't blank screen on TP", "Don't show TP progress bar" and "Display avatar >> before wearables are available" as options, so they're already handling the >> component parts of the overall TP operation quite flexibly. >> >> The AD of a world may itself have a policy of not allowing TPs to complete >> when the source region is unavailable, but this should not be hardwired into >> the protocol. As you say, one size does not fit all, particularly in the >> case of choices that provide a bad user experience. >> >> >> Morgaine. >> >> >> >> >> >> >> >> =========================================== >> >> >> On Sat, Oct 24, 2009 at 7:21 AM, Lawson English wrote: >> >>> Morgaine wrote: >>> >>>> Excellent observation, David! >>>> >>>> To use a different form of words, fault conditions can occur in all the >>>> possible states of the system, and if we want the protocol to be robust then >>>> we'll probably have to examine all its major states and ensure that there >>>> are always state transitions available out of them. >>>> >>>> In that light, being able to TP out of a stuck region is just one of >>>> those recovery transitions without which the protocol would simply break as >>>> a result of the exception. There is of course no need to design VWRAP such >>>> that exception handling always ends in session termination --- this would >>>> result in a very poor user experience by default, and so it should be >>>> avoided wherever possible. >>>> >>>> My suggestion is therefore likely to be just one of many designed to >>>> avoid session termination under conditions that, while not normal, are >>>> nevertheless unfortunately rather common in practice. The user's client >>>> application should never be forced to disconnect completely (or even worse >>>> to terminate) unless there is absolutely no alternative, and it's up to us >>>> to provide such alternatives wherever we can. >>>> >>>> Breaking the user's immersive experience through termination should only >>>> be a solution of last resort. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> >>>> ==================================== >>>> >>>> On Fri, Oct 23, 2009 at 7:09 PM, David W Levine >>> dwl@us.ibm.com>> wrote: >>>> >>>> >>>> This is a good point, and highlights a very tricky issue in any >>>> distributed system design. A protocol should behave gracefully in >>>> the face of failure. One of the definite challenges here is >>>> partition vs. failure. Its impossible to distinguish between a >>>> failed service and one which is lost behind a network partition. >>>> In the case of a partition, with an avatar continuing to run on >>>> momentarily isolated region, care needs to be taken to recover >>>> gracefully not only from the "can't get to the region service" to >>>> get it to release the agent, but also the "The region has returned >>>> to contact" So,I think when we talk about being resilient we >>>> need to think about the range of failure, from "the service I was >>>> using has crashed" to "the service I was using has become >>>> invisible due >>>> to a network partition." Of course, they look identical. This >>>> rather strongly implies good semantics on what happens to a "Stub" >>>> session which becomes isolated as well as the "new" session >>>> which we create by bypassing a failed service. (In the case of >>>> teleport, the old region's idea of agent state and the new ones, >>>> in other cases, possibly other isolated state) >>>> Food for thought >>>> >>>> - David >>>> ~ Zha >>>> >>>> >>>> >>>> *Morgaine >>> >* >>>> Sent by: ogpx-bounces@ietf.org >>>> >>>> >>>> 10/23/2009 12:47 PM >>>> >>>> >>>> To >>>> ogpx@ietf.org >>>> >>>> cc >>>> >>>> Subject >>>> Re: [ogpx] Teleports and protocol resilience >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Looking back at the replies in this thread, I think that the goal >>>> and the means to achieve it didn't quite come across. >>>> >>>> I was trying to address only a very specific issue, just protocol >>>> resilience under source region non-responsiveness, since this is >>>> common enough that it merits addressing. I did not suggest that >>>> there be any perceivable change of teleport semantics under normal >>>> operation (because no such change is needed), only a change in >>>> service coupling. The semantics we experience in SL and in >>>> Opensim would remain completely unchanged, except in the single >>>> case of source region non-responsiveness. Under this single >>>> anomalous case there */would/* be a perceivable change, but that >>>> change would be a huge improvement. >>>> >>>> There would be no new decoherence introduced since exactly the >>>> same state changes would occur on TP as before, with no possibiity >>>> of agent state change in the source region once the AD accepts the >>>> TP. >>>> >>>> All that's needed to achieve such resilience for teleport at the >>>> protocol level is a slight revision of operation phasing to permit >>>> greater execution overlap, as I outlined. This is independent of >>>> anything else that happens in the course of the overall teleport >>>> operation --- the change of phasing would affect only the transfer >>>> of /agent location/ alone, nothing else. >>>> >>>> In particular, it should not be confused with the separate >>>> requirement for instantiation of assets or objects at destination, >>>> nor with the matter of serializing and deserializing script >>>> states. The latter has not even been defined for VWRAP, so it's >>>> hard to talk about changing it. In any event, this isn't about >>>> those aspects of teleport, and doesn't affect them --- they would >>>> continue to work as before. >>>> >>>> One of the central aspects of VWRAP is that the protocol is based >>>> on a multiple services model, and one of the key approaches in >>>> highly scalable systems design is to keep services decoupled to >>>> the largest extent possible. That's what I'm proposing here, a >>>> /partial decoupling/ that has no normal semantic change but which >>>> does have benefits in anomalous situations. >>>> >>>> Agent location change /can/ be decoupled significantly from asset >>>> instantiation change and script state transfer. My suggestion >>>> referred to this decoupled /agent location change/ only, not to >>>> asset and simulation services. Those other two services undergo >>>> state transitions at the same time as change of agent location >>>> does on TP, but services should never be coupled together >>>> unnecessarily, and in this case the coupling can be left very >>>> weak. The three types of service operations can proceed each at >>>> their own independent rates, coupled at TP initiation time and >>>> nowhere else. >>>> >>>> It should be noted that the legacy protocols do some of this >>>> already, in that the agent is already active in the destination >>>> region long before her avatar or objects have appeared. >>>> Furthermore, the avatar currently continues to be visible in the >>>> source region for a while after the agent becomes active in the >>>> destination region, because of normal operation latencies, >>>> sim-side queueing, and client lag. This is a normal part of >>>> current operation, and is not considered an anomaly. What's >>>> important is that no new state change to the agent is possible in >>>> the source region after TP is initiated, and that would remain true. >>>> >>>> The impact of this on the other parts of the puzzle needs to wait >>>> until those other parts are examined. We're not there yet, but I >>>> would hope that improving teleport protocol resilience would be a >>>> desireable goal when the only noticeable change in semantics >>>> occurs under fault conditions and provides a major improvement on >>>> current behaviour. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> >>>> >>>> ====================================== >>>> >>>> On Tue, Oct 13, 2009 at 6:13 AM, Morgaine >>>> <_morgaine.dinova@googlemail.com_ >>>> >>>> > wrote: >>>> One of the advantages we have in developing the VWRAP protocols is >>>> that we are able to look back at legacy SL and Opensim protocols >>>> and recognize design mistakes or limitations in them. This allows >>>> us to avoid repeating such mistakes or limitations in the next >>>> generation of systems. >>>> >>>> One of the most common sources of frustration and dissatisfaction >>>> is simulator non-responsiveness. While this has many possible >>>> causes, in VWRAP we are not interested in the internal >>>> implementation of simulators, but we *ARE* interested in the >>>> ability of a protocol endpoint to perform its duty within the >>>> protocol. A jammed simulator host is in many cases quite unable >>>> to perform its protocol duties, or in some cases only exceedingly >>>> slowly, often timing out in a TP for example. We have a huge >>>> amount of experience of this happening in both SL and Opensim, so >>>> it is a practical reality. On occasion, simulators will be unable >>>> to fulfil their part in a protocol, and this needs to be taken >>>> into account because it is /not uncommon/. >>>> >>>> One key area in which the above is relevant is in teleports *OUT* >>>> of a simulator that is under distress. Quite often users wish >>>> nothing more than to /leave/ the region being run by a dying >>>> simulator, but when teleport-out requires cooperation from the >>>> host that one is trying to leave then this is often not possible >>>> at all. In this situation, the only remedy in existing systems is >>>> to forcibly terminate the client and relog in another region. We >>>> should avoid such out-of-protocol remedies being necessary through >>>> good protocol design. >>>> >>>> In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, >>>> which lead to corresponding protocol operations during teleport. >>>> If R1 is a region being run by a non-responsive simulator from >>>> which we want to escape, and R2 is another region to which we wish >>>> to go, if the protocol requires a Derez in R1 to be completed >>>> before a Rez in R2 can commence then the user will have >>>> difficulties. Clearly we don't want this. >>>> >>>> In _http://tools.ietf.org/html/draft-hamrick-ogp-intro-00_ , it is >>>> made clear that "/The agent domain MUST also remove the avatar >>>> from it's current location *before*// placing the avatar in the >>>> destination location/." This suggests that the protocol will be >>>> sensitive to R1 non-responsiveness. While we do not yet have an >>>> actual VWRAP Teleport draft, it seems likely that its initial >>>> incarnation will have that same problem built in. >>>> >>>> I suggest that the protocol define Derez and Rez as */concurrent/* >>>> and */non-dependent/* operations to avoid this situation. The AD >>>> can mark R1 as disabled for all further agent state changes --- >>>> this will provide all the protection needed to prevent brief >>>> double-presence anomalies from being significant. If a jammed R1 >>>> refuses to give up its hold on the avatar, then at least the user >>>> will not suffer from it. Reaping dead simulator sessions then >>>> becomes a problem for the region operator alone, and not for the >>>> AD, the user, and the region as happens now. >>>> >>>> Beware of one-size-fits-all requirements. I can easily imagine there >>> will be users who wouldn't want to have a degraded/alternate/unexpected >>> experience on TP failure and who WOULD want the system just to reset. And no >>> doubt other scenarios will make sense as well. After all, if someone uses >>> VWRAP as the foundation for a gaming platform, they may have completely >>> different rules that they expect users participating to follow as long as >>> they are participating. >>> >>> >>> Lawson >>> >>> Lawson >>> >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > --001517476732e6f78a0476b977f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 24, 2009 at 2:59 PM, Vaughn Deluca <vaughn.deluca@gmail.com>= wrote:

- The agent domain is able to complete a teleport (after a timeout period) even if the original region completley fails to respond, so *even* if there is no guarantee the invocation of the derez cap has been processed.


By "complete a teleport= " I mean "succeed in placing the agent in the destination regi= on independent of the state of its avatar".=A0 I'm making this= distinction because that's precisely the semantic we have right now in= SL and Opensim --- the avatar wearables and attachments arrive much later,= asynchronously.=A0 The avatar does not obey a semanti= c of "one place only" but has parallel existence for a short whil= e in both regions even under normal operation.=A0 (Under abnormal operation= of the source region, that overlap can last a very long time.)=A0 It's= the active agent that has unique existence in only one regio= n at a time, and that's the semantic which I want to preserve as well.<= br>
(It's worth mentioning that the avatar and its equiped objects are = left to appear/disappear at their own sweet rate for a very good pragmatic = reason.=A0 Teleport would take an eternity if it were defined as a fully sy= nchronous operation for all relevant parts of agent and avatar together.)
=A0
- To prevent true=A0duplication of avatar= s, the again domain keeps some record of the old connection, to be able to deal gracefully with the =A0case that the old region comes back to life. This implies that in some cases two copies of the avatar might be visible, one "dead body&q= uot; in the old region, and the live version in the new region. This might in some cases be preferable to a stranded avatar, yet in other situation could be unacceptable (e.g. in a combat game, were mere visual presence might be enough to influence the game).=A0


Note that this dual presence of avatars is exactly the situa= tion that we have currently, as I outlined above.=A0 It's important to = be clear about the distinction between agents and avatars in this area.=A0 = The key semantic is that, even if an avatar is still visible in the source = region after a teleport, there be no active agent associated with it= .=A0 In other words, any events which the source region may send the agent = after the AD has accepted the TP are discarded.=A0 Under normal operation t= here should be no such inappropriate events arriving because the source reg= ion will have processed the Derez, but under abnormal operation anything ca= n happen so one has to handle it defensively.
=A0
As concurrent programming becomes more common in this emerging "= ;age of multicore", we're going to be seeing these kinds of anomal= ies arise with ever greater frequency, particularly as regions become virtu= alized or implemented scalably on clusters.


-Therefore, in spite of the freedom of the agent domain to complete a tp from a non-responding region, its left up to the region to decide if it wants to accept the rezzing of an avatar that has not =A0completed the de-rezzing in the old region.


Yes.=A0 As Lawson highlighted, "one size fits all"= ; is not appropriate.
=A0

- Since there is no way to get the most recent agent state from the old region, this special TP without conformation from the originating region would bring back the agent in some default state in the new region. This process would lead to a graceful degradation of the system. With some clever setting of defaults it might not be too disturbing for the avatar. =A0It is left up to the client to instruct the agent service about the way to deal with these types of anomalies.


Fortunately it's= a very easy anomaly to handle, since the TP simply acquires the semantic o= f a first-time rez in the destination region at the point of source region = timeout.
=A0

-Finally, your suggestions imply that the Agent =A0service MAY acts as an intermediate in the TP, rather than the two regions communicating directly as the current TP draft specifies.
=


The AD carries the "first say" responsi= bility for agent teleport policy, that's its key role in teleports, and= therefore it must always be an intermediary in teleports otherwise it cann= ot effect such agent policy.=A0 Region-to-region communication should reall= y be seen as a behind-the-scenes optimization or an implementation detail f= or avatar=A0 asset/object/state transfer --- notice clearly i= t's avatar=A0 here, not agent.=A0 And since it breaks resilient = teleport under source region anomalies, it needs to be optional.
=A0

At first sight is all looks reasona= bly realistic, yet it is for sure more complicated than the current TP draft, and I am not really able to judge what we are actually bringing onto our selfs here.=A0

These are pre-draft discussions for VWRAP --- I'v= e purposely avoided focussing on the original OGP Teleport drafts since man= y things are changing for VWRAP anyway as a result of the introduction of R= D-controlled services that do not feature in the original drafts.=A0 We'= ;ve got to get the VWRAP teleport semantics well understood in our minds fi= rst before churning out a VWRAP Teleport draft spec for it.=A0 There are st= ill many unknowns in this area. :-)


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

On Sat, Oct 24, 2009 at 2:59= PM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
Morgaine,=A0=

If I understand you right, you are suggesting the= following:

- The agent domain is able to complete a teleport (afte= r a timeout period) even if the original region completley fails to respond= , so *even* if there is no guarantee the invocation of the derez cap has be= en processed.

- To prevent true=A0duplication of avatars, the again domain keeps som= e record of the old connection, to be able to deal gracefully with the =A0c= ase that the old region comes back to life. This implies that in some cases= two copies of the avatar might be visible, one "dead body" in th= e old region, and the live version in the new region. This might in some ca= ses be preferable to a stranded avatar, yet in other situation could be una= cceptable (e.g. in a combat game, were mere visual presence might be enough= to influence the game).=A0

-Therefore, in spite of the freedom of the agent domain= to complete a tp from a non-responding region, its left up to the region t= o decide if it wants to accept the rezzing of an avatar that has not =A0com= pleted the de-rezzing in the old region.

- Since there is no way to get the most recent agent st= ate from the old region, this special TP without conformation from the orig= inating region would bring back the agent in some default state in the new = region. This process would lead to a graceful degradation of the system. Wi= th some clever setting of defaults it might not be too disturbing for the a= vatar. =A0It is left up to the client to instruct the agent service about t= he way to deal with these types of anomalies.

-Finally, your suggestions imply that the Agent = =A0service MAY acts as an intermediate in the TP, rather than the two regio= ns communicating directly as the current TP draft specifies.

At first sight is all looks reasonably realistic, yet it is for = sure more complicated than the current TP draft, and I am not really able t= o judge what we are actually bringing onto our selfs here.

- Vaughn
.

On= Sat, Oct 24, 2009 at 12:08 PM, Morgaine <morgaine.dinova@goo= glemail.com> wrote:
=
Indeed!=A0=A0 Not only are extra user options = always a good thing, but a TP from a region in one world could be to a regi= on in a highly different world with very specific requirements.=A0 As you p= oint out, "one size fits all" is definitely inappropriate.

In this particular case, that could be handled by the AD sending the cl= ient an event notification to the effect that the source region did not res= pond within the timeout period.

The client would then be free to imp= lement disconnection if this is the user's configured choice.=A0 I thin= k it's fair to expect that most people would not choose that option, bu= t it should certainly be available to them if needed.

The agent would probably already be located in the destination region b= y this time from the AD's perspective (depending on timout length), but not ne= cessarily from the client's perspective --- that's a matter of client implementation and user optio= ns.=A0 Some Second Life clients already implement "Don't blank scr= een on TP", "Don't show TP progress bar" and "Displ= ay avatar before wearables are available" as options, so they're a= lready handling the component parts of the overall TP operation quite flexi= bly.

The AD of a world may itself have a policy of not allowing TPs to compl= ete when the source region is unavailable, but this should not be hardwired= into the protocol.=A0 As you say, one size does not fit all, particularly = in the case of choices that provide a bad user experience.


Morgaine.







=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On Sat, Oct 24, 2009 at 7:21 AM, Lawson English <lenglish5@cox.= net> wrote:
Morgaine wrote:
Excellent observation, David!

To use a different form of words, fault conditions can occur in all the pos= sible states of the system, and if we want the protocol to be robust then w= e'll probably have to examine all its major states and ensure that ther= e are always state transitions available out of them.

In that light, being able to TP out of a stuck region is just one of those = recovery transitions without which the protocol would simply break as a res= ult of the exception. =A0There is of course no need to design VWRAP such th= at exception handling always ends in session termination --- this would res= ult in a very poor user experience by default, and so it should be avoided = wherever possible.

My suggestion is therefore likely to be just one of many designed to avoid = session termination under conditions that, while not normal, are neverthele= ss unfortunately rather common in practice. =A0The user's client applic= ation should never be forced to disconnect completely (or even worse to ter= minate) unless there is absolutely no alternative, and it's up to us to= provide such alternatives wherever we can.

Breaking the user's immersive experience through termination should onl= y be a solution of last resort.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Fri, Oct 23, 2009 at 7:09 PM, David W Levine <dwl@us.ibm.com <mailto:dwl@us.ibm.com>> wrote:


=A0 =A0This is a good point, and highlights a very tricky issue in any
=A0 =A0distributed system design. A protocol should behave gracefully in =A0 =A0the face of failure. One of the definite challenges here is
=A0 =A0partition vs. failure. Its impossible to distinguish between a
=A0 =A0failed service and one which is lost behind a network partition. =A0 =A0In the case of a partition, with an avatar continuing to run on
=A0 =A0momentarily isolated region, care needs to be taken to recover
=A0 =A0gracefully not only from the "can't get to the region serv= ice" to
=A0 =A0get it to release the agent, but also the "The region has retu= rned
=A0 =A0to contact" =A0So,I think =A0when we talk about being resilien= t we
=A0 =A0need to think about the range of failure, from "the service I = was
=A0 =A0using has crashed" to "the service I was using has become=
=A0 =A0invisible due
=A0 =A0to a network partition." Of course, they look identical. This<= br> =A0 =A0rather strongly implies good semantics on what happens to a "S= tub"
=A0 =A0session which =A0becomes isolated as well as the "new" se= ssion
=A0 =A0which we create by bypassing a failed service. (In the case of
=A0 =A0teleport, the old region's idea of agent state and the new ones= ,
=A0 =A0in other cases, possibly other isolated state) =A0
=A0 =A0Food for thought

=A0 =A0- David
=A0 =A0~ Zha



=A0 =A0*Morgaine <morgaine.dinova@googlemail.com
=A0 =A0<mailto:morgaine.dinova@googlemail.com>>*
=A0 =A0Sent by: ogpx-bounces@ietf.org <mailto:ogpx-bounces@ietf.org>


=A0 =A010/23/2009 12:47 PM

=A0 =A0 =A0 =A0
=A0 =A0To
=A0 =A0 =A0 =A0ogpx@iet= f.org <mailto:ogp= x@ietf.org>

=A0 =A0cc
=A0 =A0 =A0 =A0
=A0 =A0Subject
=A0 =A0 =A0 =A0Re: [ogpx] Teleports and protocol resilience



=A0 =A0 =A0 =A0





=A0 =A0Looking back at the replies in this thread, I think that the goal =A0 =A0and the means to achieve it didn't quite come across.

=A0 =A0I was trying to address only a very specific issue, just protocol =A0 =A0resilience under source region non-responsiveness, since this is =A0 =A0common enough that it merits addressing. =A0I did not suggest that<= br> =A0 =A0there be any perceivable change of teleport semantics under normal<= br> =A0 =A0operation (because no such change is needed), only a change in
=A0 =A0service coupling. =A0The semantics we experience in SL and in
=A0 =A0Opensim would remain completely unchanged, except in the single
=A0 =A0case of source region non-responsiveness. =A0Under this single
=A0 =A0anomalous case there */would/* be a perceivable change, but that =A0 =A0change would be a huge improvement.

=A0 =A0There would be no new decoherence introduced since exactly the
=A0 =A0same state changes would occur on TP as before, with no possibiity<= br> =A0 =A0of agent state change in the source region once the AD accepts the = TP.

=A0 =A0All that's needed to achieve such resilience for teleport at th= e
=A0 =A0protocol level is a slight revision of operation phasing to permit<= br> =A0 =A0greater execution overlap, as I outlined. =A0This is independent of=
=A0 =A0anything else that happens in the course of the overall teleport =A0 =A0operation --- the change of phasing would affect only the transfer<= br> =A0 =A0of /agent location/ alone, nothing else.

=A0 =A0In particular, it should not be confused with the separate
=A0 =A0requirement for instantiation of assets or objects at destination,<= br> =A0 =A0nor with the matter of serializing and deserializing script
=A0 =A0states. =A0The latter has not even been defined for VWRAP, so it= 9;s
=A0 =A0hard to talk about changing it. =A0In any event, this isn't abo= ut
=A0 =A0those aspects of teleport, and doesn't affect them --- they wou= ld
=A0 =A0continue to work as before.

=A0 =A0One of the central aspects of VWRAP is that the protocol is based =A0 =A0on a multiple services model, and one of the key approaches in
=A0 =A0highly scalable systems design is to keep services decoupled to
=A0 =A0the largest extent possible. =A0That's what I'm proposing h= ere, a
=A0 =A0/partial decoupling/ that has no normal semantic change but which =A0 =A0does have benefits in anomalous situations.

=A0 =A0Agent location change /can/ be decoupled significantly from asset =A0 =A0instantiation change and script state transfer. =A0My suggestion =A0 =A0referred to this decoupled /agent location change/ only, not to
=A0 =A0asset and simulation services. =A0Those other two services undergo<= br> =A0 =A0state transitions at the same time as change of agent location
=A0 =A0does on TP, but services should never be coupled together
=A0 =A0unnecessarily, and in this case the coupling can be left very
=A0 =A0weak. =A0The three types of service operations can proceed each at<= br> =A0 =A0their own independent rates, coupled at TP initiation time and
=A0 =A0nowhere else.

=A0 =A0It should be noted that the legacy protocols do some of this
=A0 =A0already, in that the agent is already active in the destination
=A0 =A0region long before her avatar or objects have appeared. =A0 =A0Fur= thermore, the avatar currently continues to be visible in the
=A0 =A0source region for a while after the agent becomes active in the
=A0 =A0destination region, because of normal operation latencies,
=A0 =A0sim-side queueing, and client lag. =A0This is a normal part of
=A0 =A0current operation, and is not considered an anomaly. What's
=A0 =A0important is that no new state change to the agent is possible in =A0 =A0the source region after TP is initiated, and that would remain true= .

=A0 =A0The impact of this on the other parts of the puzzle needs to wait =A0 =A0until those other parts are examined. =A0We're not there yet, b= ut I
=A0 =A0would hope that improving teleport protocol resilience would be a =A0 =A0desireable goal when the only noticeable change in semantics
=A0 =A0occurs under fault conditions and provides a major improvement on =A0 =A0current behaviour.


=A0 =A0Morgaine.






=A0 =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=A0 =A0On Tue, Oct 13, 2009 at 6:13 AM, Morgaine
=A0 =A0<_morgaine.dinova@googlemail.com_

=A0 =A0<mailto:morgaine.dinova@googlemail.com>> wrote:
=A0 =A0One of the advantages we have in developing the VWRAP protocols is<= br> =A0 =A0that we are able to look back at legacy SL and Opensim protocols =A0 =A0and recognize design mistakes or limitations in them. =A0This allow= s
=A0 =A0us to avoid repeating such mistakes or limitations in the next
=A0 =A0generation of systems.

=A0 =A0One of the most common sources of frustration and dissatisfaction =A0 =A0is simulator non-responsiveness. =A0While this has many possible =A0 =A0causes, in VWRAP we are not interested in the internal
=A0 =A0implementation of simulators, but we *ARE* interested in the
=A0 =A0ability of a protocol endpoint to perform its duty within the
=A0 =A0protocol. =A0A jammed simulator host is in many cases quite unable<= br> =A0 =A0to perform its protocol duties, or in some cases only exceedingly =A0 =A0slowly, often timing out in a TP for example. =A0We have a huge
=A0 =A0amount of experience of this happening in both SL and Opensim, so =A0 =A0it is a practical reality. =A0On occasion, simulators will be unabl= e
=A0 =A0to fulfil their part in a protocol, and this needs to be taken
=A0 =A0into account because it is /not uncommon/.

=A0 =A0One key area in which the above is relevant is in teleports *OUT* =A0 =A0of a simulator that is under distress. =A0Quite often users wish =A0 =A0nothing more than to /leave/ the region being run by a dying
=A0 =A0simulator, but when teleport-out requires cooperation from the
=A0 =A0host that one is trying to leave then this is often not possible =A0 =A0at all. =A0In this situation, the only remedy in existing systems i= s
=A0 =A0to forcibly terminate the client and relog in another region. =A0We=
=A0 =A0should avoid such out-of-protocol remedies being necessary through<= br> =A0 =A0good protocol design.

=A0 =A0In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, =A0 =A0which lead to corresponding protocol operations during teleport. = =A0 =A0If R1 is a region being run by a non-responsive simulator from
=A0 =A0which we want to escape, and R2 is another region to which we wish<= br> =A0 =A0to go, if the protocol requires a Derez in R1 to be completed
=A0 =A0before a Rez in R2 can commence then the user will have
=A0 =A0difficulties. =A0Clearly we don't want this.

=A0 =A0In _http://tools.ietf.org/html/draft-hamrick-ogp-intro-00= _ , it is
=A0 =A0made clear that "/The agent domain MUST also remove the avatar=
=A0 =A0from it's current location *before*// placing the avatar in the=
=A0 =A0destination location/." =A0This suggests that the protocol wil= l be
=A0 =A0sensitive to R1 non-responsiveness. =A0While we do not yet have an<= br> =A0 =A0actual VWRAP Teleport draft, it seems likely that its initial
=A0 =A0incarnation will have that same problem built in.

=A0 =A0I suggest that the protocol define Derez and Rez as */concurrent/*<= br> =A0 =A0and */non-dependent/* operations to avoid this situation. =A0The AD=
=A0 =A0can mark R1 as disabled for all further agent state changes ---
=A0 =A0this will provide all the protection needed to prevent brief
=A0 =A0double-presence anomalies from being significant. =A0If a jammed R1=
=A0 =A0refuses to give up its hold on the avatar, then at least the user =A0 =A0will not suffer from it. =A0Reaping dead simulator sessions then =A0 =A0becomes a problem for the region operator alone, and not for the =A0 =A0AD, the user, and the region as happens now.

Beware of one-size-fits-all requirements. I can easily imagine there will b= e users who wouldn't want to have a degraded/alternate/unexpected exper= ience on TP failure and who WOULD want the system just to reset. And no dou= bt other scenarios will make sense as well. After all, if someone uses VWRA= P as the foundation for a gaming platform, they may have completely differe= nt rules that they expect users participating to follow as long as they are= participating.


Lawson

Lawson


_____________________________= __________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx



--001517476732e6f78a0476b977f8-- From carlo@alinoe.com Sun Oct 25 03:48:22 2009 Return-Path: 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 CD8E63A6975 for ; Sun, 25 Oct 2009 03:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.984 X-Spam-Level: X-Spam-Status: No, score=0.984 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 I6gN13LFvtUC for ; Sun, 25 Oct 2009 03:48:21 -0700 (PDT) Received: from viefep20-int.chello.at (viefep20-int.chello.at [62.179.121.40]) by core3.amsl.com (Postfix) with ESMTP id 7CE7C3A695D for ; Sun, 25 Oct 2009 03:48:20 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep20-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091025104831.SMMC14186.viefep20-int.chello.at@edge01.upc.biz>; Sun, 25 Oct 2009 11:48:31 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id wyoU1c05x0FlQed01yoWw6; Sun, 25 Oct 2009 11:48:31 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1N20eA-0002Cp-6i; Sun, 25 Oct 2009 11:48:26 +0100 Date: Sun, 25 Oct 2009 11:48:26 +0100 From: Carlo Wood To: "Infinity Linden (Meadhbh Hamrick)" Message-ID: <20091025104826.GA7775@alinoe.com> References: <382d73da0910122225l73a48b7al44675dcb0abf709d@mail.gmail.com> <3a880e2c0910130520i69ca056asdeef38650855fbf9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3a880e2c0910130520i69ca056asdeef38650855fbf9@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ogpx@ietf.org Subject: Re: [ogpx] Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 10:48:22 -0000 On Tue, Oct 13, 2009 at 05:20:15AM -0700, Infinity Linden (Meadhbh Hamrick) wrote: > the reason the teleport process removes a user from one region before > placing it in another is to ensure that the user's avatar exists in at > most one place. i understand that this is a non-issue with hypergrid > or tourist models, as there's no assumption of coherence between > regions. but, many of us want to provide a virtual world experience > that includes this concept. > > thx > m/∞ That is hardly a good argument. What is the *reason* you want this? The reason users want to TP away from a region is usually to start over somewhere else as soon as possible. I'm pretty sure that most users don't like having to wait very long. Surely there is a good technical solution to this problem, so lets just solve it. -- Carlo Wood PS "many of us" is a bit vague... personally I have the feeling that most users will agree with Morgaine that tp-ing away from a region should never be impossible because that region is non-responsive. From carlo@alinoe.com Sun Oct 25 05:15:44 2009 Return-Path: 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 E41123A690F for ; Sun, 25 Oct 2009 05:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.077 X-Spam-Level: * X-Spam-Status: No, score=1.077 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 WqPskactz1BJ for ; Sun, 25 Oct 2009 05:15:44 -0700 (PDT) Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id 80D9D3A68A7 for ; Sun, 25 Oct 2009 05:15:43 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091025121553.XFJN7738.viefep16-int.chello.at@edge04.upc.biz> for ; Sun, 25 Oct 2009 13:15:53 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id x0Fq1c05J0FlQed040Fr8v; Sun, 25 Oct 2009 13:15:53 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1N220h-00030O-SL for ogpx@ietf.org; Sun, 25 Oct 2009 13:15:47 +0100 Date: Sun, 25 Oct 2009 13:15:47 +0100 From: Carlo Wood To: ogpx@ietf.org Message-ID: <20091025121547.GB7775@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [ogpx] My take on Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 12:15:45 -0000 Lets start with some brainstorming... Things that might be relevant, in no particular order. * State of avatar * State of attachments * Location of avatar * Time of unresponsiveness of avatar (position) towards viewer * Time of unresponsiveness of attachments (attaching/detaching/scripts) * Perception of the viewer * Perception of other viewers * Region boundary crossing * Teleport over larger distance * User configurable parameters * did I miss something important? Real message starts here: Something that protocol (or implementation)- wise leads to problems are copies of the same data on different hosts; this always leads to desynchronization of this data with heaps of untrackable problems (bugs). The ONLY way to keep a copy of some data reliably synchrononized is by having a stream of state changes being sent from one host to another, where the messages that contain that state changes always keep the same order and the stream is never terminated/lost (in which case a full-resynchronization would be necessary). Note that this means that the source of the state changes has to be a single point of origin, which automatically means that we can identify the REAL (original) copy of the data. Thus: [original] ---> stream of state changes --> [copy] Lets call this an "unidirectional state" by lack of a better word. [PS I'm ignoring actual implementation details here. I'm NOT saying that currently anyone is using a TCP-stream of state changes, so don't quote JUST this part with the comment that this is not how it current works, Infinity :p Instead, this is an mathematical approach, the abstract equivalent of any possible deployment case]. Basically, we want to avoid copies of the same data. The simulator contains a lot of state information that cannot be moved away from the simulator though: because the state is needed to calculate the interactions between all objects and avatars in the region, which would become way too slow if, for example, several agent domain services would have to be queried all the time. I can imagine that this also holds for the attachments on an avatar. This means that if an avatar moves from one region to another, all this state information has to be transfered too. Thus, the origin sends state information to the new region. If this fails, then we want the user to resume at it's old location: we need to keep a copy of the state until we know the teleport was successful. In other words, we will have a copy of data at two different hosts, temporarily. One way to make sure that this is not a problem is by freezing all state; then copy it, and only once the copy is successful, destroy the old data and resume the simulation in the other region. The problem we try to tackle now is the case were the old region is not responsive... In this case we have to notice that the AD can ALSO detect that at least the new region is able to host the avatar: the teleport can *partly* succeed. This can be detected independent of copying all the state information. Secondly, we have to realize that the 'location' of the avatar is (state) data that does NOT have to be copied (we're changing it anyway) and therefore is not part of said state, and does not suffer from the copy-problem. The same could be said about animations (which is currently broken in Second Life: you must stop all animations before teleporting or a desync happens): we could state that after a teleport no animations are active, and leave it to the viewer to re-initiate and required animations. However, animations can be made unidirectional (meaning that if anyone but the agent service wants to change the animation, it has to send a request message to the AD, which then grants it, so that the actual state change always originates from the agent service (AS)). As a result, we can think of the animation state as: [AS:animation state] --- message stream --> [simulator:animation state copy] which means that we can teleport, keeping the correct animation(s) without bothering with the source region. The only clear case where this kind of 'trick' doesn't work (I think it's not a trick, but the best way to implement this) is for script states: those change way too frequent to host them on the AS. Conclusion Thus, in the case of an unresponsive source region, we CAN - without risks of desynchronization - immediately transfer the avatar (location) and animations, and any other INFREQUENTLY CHANGING, UNIDIRECTIONAL DATA that can be stored on the AS (and buffered on the simulator), like clothing UUIDs, and attachments. However, the scripts in the attachments will not run until their state is transfered from the old region. Imho, this is hardly a problem: after user configurable timeout we leave it to the user what he wants to do: logout or reset the scripts :p... Ok, we just reset the scripts after some time, where the timeout is determined by the AD with possible input from the user. -- Carlo Wood From vaughn.deluca@gmail.com Sun Oct 25 15:30:43 2009 Return-Path: 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 12D8028C1A9 for ; Sun, 25 Oct 2009 15:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_20=-0.74, HTML_MESSAGE=0.001, SARE_UNSUB18=0.131] 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 nFzhOKrRSf5q for ; Sun, 25 Oct 2009 15:30:41 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id D81DE28C1A8 for ; Sun, 25 Oct 2009 15:30:40 -0700 (PDT) Received: by fxm18 with SMTP id 18so11652824fxm.37 for ; Sun, 25 Oct 2009 15:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aiGIx3SBG3p8nSmSJpSeFQt8b6pWI3XtFwIeDGDU+CE=; b=Gth7/07w7FappXCE0OJzaK/B57cUIiNLFU9YbukjYJNQCr1/p5u6Pi6UJAZQCl4C9u 7veG5yBwJK5UxKlq+S7CzuT2fSYVEWYR7qNqYtemiKPUMwN3oPtNUCslEjGR7ZMaSiK7 S2kilneY4BbT0dsQUndzIfycmU1rRBpoRV1k4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IKcmYKdAK+nTfVP0bIOYjV1rXsjyAvOCd56agR57Vk5Jpx9d1iESXOlhvKiUUdO4N8 s1gaCOlTitC4C537PQ/QmyHZENsyqEddv246zs1BIdL3Qu2oD4PtVgRzkbQOIwbSEeH/ Yx46k4pZQJsE1r/VZpUP7B/0DFZMmfmp/OFJE= MIME-Version: 1.0 Received: by 10.204.23.203 with SMTP id s11mr5175521bkb.17.1256509848599; Sun, 25 Oct 2009 15:30:48 -0700 (PDT) In-Reply-To: <20091025121547.GB7775@alinoe.com> References: <20091025121547.GB7775@alinoe.com> Date: Sun, 25 Oct 2009 23:30:48 +0100 Message-ID: <9b8a8de40910251530u273830a5k47bdd8927b7efc76@mail.gmail.com> From: Vaughn Deluca To: Carlo Wood Content-Type: multipart/alternative; boundary=000325559f1a2ebd540476c9ffae Cc: ogpx@ietf.org Subject: Re: [ogpx] My take on Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 22:30:43 -0000 --000325559f1a2ebd540476c9ffae Content-Type: text/plain; charset=ISO-8859-1 > [AS:animation state] --- message stream --> [simulator:animation state copy] What you are suggesting here is keeping a copy of the avatar state. We would be increasing bandwith and storage space to gain flexibility. I do not think storage space is a real problem. I am not sure about bandwidth. Is there anybody who can put some real numbers on this? How much extra work would the region have to do? Is it still acceptable if the Agent service is in Australia and the region in Europe? -Vaughn On Sun, Oct 25, 2009 at 1:15 PM, Carlo Wood wrote: > Lets start with some brainstorming... > > Things that might be relevant, in no particular order. > > * State of avatar > * State of attachments > * Location of avatar > * Time of unresponsiveness of avatar (position) towards viewer > * Time of unresponsiveness of attachments (attaching/detaching/scripts) > * Perception of the viewer > * Perception of other viewers > * Region boundary crossing > * Teleport over larger distance > * User configurable parameters > * did I miss something important? > > > Real message starts here: > > Something that protocol (or implementation)- wise leads to problems > are copies of the same data on different hosts; this always leads > to desynchronization of this data with heaps of untrackable problems > (bugs). > > The ONLY way to keep a copy of some data reliably synchrononized is by > having a stream of state changes being sent from one host to another, > where the messages that contain that state changes always keep > the same order and the stream is never terminated/lost (in which case > a full-resynchronization would be necessary). Note that this means > that the source of the state changes has to be a single point of > origin, which automatically means that we can identify the REAL > (original) copy of the data. Thus: > > [original] ---> stream of state changes --> [copy] > > Lets call this an "unidirectional state" by lack of a better word. > > [PS I'm ignoring actual implementation details here. I'm NOT > saying that currently anyone is using a TCP-stream of > state changes, so don't quote JUST this part with the comment > that this is not how it current works, Infinity :p > Instead, this is an mathematical approach, the abstract > equivalent of any possible deployment case]. > > Basically, we want to avoid copies of the same data. > > > The simulator contains a lot of state information that cannot > be moved away from the simulator though: because the state is > needed to calculate the interactions between all objects and > avatars in the region, which would become way too slow if, > for example, several agent domain services would have to be > queried all the time. I can imagine that this also holds for > the attachments on an avatar. > > This means that if an avatar moves from one region to another, > all this state information has to be transfered too. > > Thus, the origin sends state information to the new region. > If this fails, then we want the user to resume at it's old > location: we need to keep a copy of the state until we know > the teleport was successful. In other words, we will have > a copy of data at two different hosts, temporarily. > > One way to make sure that this is not a problem is by > freezing all state; then copy it, and only once the copy > is successful, destroy the old data and resume the simulation > in the other region. > > The problem we try to tackle now is the case were the old > region is not responsive... > > > In this case we have to notice that the AD can ALSO detect > that at least the new region is able to host the avatar: > the teleport can *partly* succeed. This can be detected > independent of copying all the state information. > > Secondly, we have to realize that the 'location' of the > avatar is (state) data that does NOT have to be copied > (we're changing it anyway) and therefore is not part of > said state, and does not suffer from the copy-problem. > > The same could be said about animations (which is currently > broken in Second Life: you must stop all animations > before teleporting or a desync happens): we could state > that after a teleport no animations are active, and leave > it to the viewer to re-initiate and required animations. > However, animations can be made unidirectional (meaning > that if anyone but the agent service wants to change the > animation, it has to send a request message to the AD, > which then grants it, so that the actual state change always > originates from the agent service (AS)). > > As a result, we can think of the animation state as: > > > [AS:animation state] --- message stream --> [simulator:animation state > copy] > > which means that we can teleport, keeping the correct > animation(s) without bothering with the source region. > > > The only clear case where this kind of 'trick' doesn't work > (I think it's not a trick, but the best way to implement this) > is for script states: those change way too frequent to host > them on the AS. > > > Conclusion > > Thus, in the case of an unresponsive source region, > we CAN - without risks of desynchronization - immediately > transfer the avatar (location) and animations, and > any other INFREQUENTLY CHANGING, UNIDIRECTIONAL DATA > that can be stored on the AS (and buffered on the > simulator), like clothing UUIDs, and attachments. > > However, the scripts in the attachments will not run > until their state is transfered from the old region. > > Imho, this is hardly a problem: after user configurable > timeout we leave it to the user what he wants to do: > logout or reset the scripts :p... Ok, we just reset > the scripts after some time, where the timeout is > determined by the AD with possible input from the user. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --000325559f1a2ebd540476c9ffae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> [AS:animation state] --- message stream --> [simulator:animati= on state copy]

What you are suggesting here is kee= ping a copy of the avatar state. We would be increasing bandwith and storag= e space to gain flexibility. I do =A0not think storage space is a real prob= lem. I am not sure about bandwidth.

Is there anybody who can put some real numbers on this?= How much extra work would the region have to do? Is it still acceptable if= the Agent service is in Australia and the region in Europe?

-Vaughn

On Sun, Oct 25, = 2009 at 1:15 PM, Carlo Wood <carlo@alinoe.com> wrote:
Lets start with some brainstorming...

Things that might be relevant, in no particular order.

* State of avatar
* State of attachments
* Location of avatar
* Time of unresponsiveness of avatar (position) towards viewer
* Time of unresponsiveness of attachments (attaching/detaching/scripts)
* Perception of the viewer
* Perception of other viewers
* Region boundary crossing
* Teleport over larger distance
* User configurable parameters
* did I miss something important?


Real message starts here:

Something that protocol (or implementation)- wise leads to problems
are copies of the same data on different hosts; this always leads
to desynchronization of this data with heaps of untrackable problems
(bugs).

The ONLY way to keep a copy of some data reliably synchrononized is by
having a stream of state changes being sent from one host to another,
where the messages that contain that state changes always keep
the same order and the stream is never terminated/lost (in which case
a full-resynchronization would be necessary). Note that this means
that the source of the state changes has to be a single point of
origin, which automatically means that we can identify the REAL
(original) copy of the data. Thus:

=A0[original] ---> stream of state changes --> [copy]

Lets call this an "unidirectional state" by lack of a better word= .

[PS I'm ignoring actual implementation details here. I'm NOT
=A0 =A0saying that currently anyone is using a TCP-stream of
=A0 =A0state changes, so don't quote JUST this part with the comment =A0 =A0that this is not how it current works, Infinity :p
=A0 =A0Instead, this is an mathematical approach, the abstract
=A0 =A0equivalent of any possible deployment case].

Basically, we want to avoid copies of the same data.


The simulator contains a lot of state information that cannot
be moved away from the simulator though: because the state is
needed to calculate the interactions between all objects and
avatars in the region, which would become way too slow if,
for example, several agent domain services would have to be
queried all the time. I can imagine that this also holds for
the attachments on an avatar.

This means that if an avatar moves from one region to another,
all this state information has to be transfered too.

Thus, the origin sends state information to the new region.
If this fails, then we want the user to resume at it's old
location: we need to keep a copy of the state until we know
the teleport was successful. In other words, we will have
a copy of data at two different hosts, temporarily.

One way to make sure that this is not a problem is by
freezing all state; then copy it, and only once the copy
is successful, destroy the old data and resume the simulation
in the other region.

The problem we try to tackle now is the case were the old
region is not responsive...


In this case we have to notice that the AD can ALSO detect
that at least the new region is able to host the avatar:
the teleport can *partly* succeed. This can be detected
independent of copying all the state information.

Secondly, we have to realize that the 'location' of the
avatar is (state) data that does NOT have to be copied
(we're changing it anyway) and therefore is not part of
said state, and does not suffer from the copy-problem.

The same could be said about animations (which is currently
broken in Second Life: you must stop all animations
before teleporting or a desync happens): we could state
that after a teleport no animations are active, and leave
it to the viewer to re-initiate and required animations.
However, animations can be made unidirectional (meaning
that if anyone but the agent service wants to change the
animation, it has to send a request message to the AD,
which then grants it, so that the actual state change always
originates from the agent service (AS)).

As a result, we can think of the animation state as:


=A0[AS:animation state] --- message stream --> [simulator:animation sta= te copy]

which means that we can teleport, keeping the correct
animation(s) without bothering with the source region.


The only clear case where this kind of 'trick' doesn't work
(I think it's not a trick, but the best way to implement this)
is for script states: those change way too frequent to host
them on the AS.


Conclusion

Thus, in the case of an unresponsive source region,
we CAN - without risks of desynchronization - immediately
transfer the avatar (location) and animations, and
any other INFREQUENTLY CHANGING, UNIDIRECTIONAL DATA
that can be stored on the AS (and buffered on the
simulator), like clothing UUIDs, and attachments.

However, the scripts in the attachments will not run
until their state is transfered from the old region.

Imho, this is hardly a problem: after user configurable
timeout we leave it to the user what he wants to do:
logout or reset the scripts :p... Ok, we just reset
the scripts after some time, where the timeout is
determined by the AD with possible input from the user.

--
Carlo Wood <carlo@alinoe.com>=
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--000325559f1a2ebd540476c9ffae-- From carlo@alinoe.com Mon Oct 26 08:02:40 2009 Return-Path: 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 B716F3A6A8F for ; Mon, 26 Oct 2009 08:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 QkjChfgx8icL for ; Mon, 26 Oct 2009 08:02:39 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id EAD7A3A6A90 for ; Mon, 26 Oct 2009 08:02:38 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091026150250.XKME10721.viefep18-int.chello.at@edge05.upc.biz>; Mon, 26 Oct 2009 16:02:50 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id xT2n1c0DK0FlQed05T2oeN; Mon, 26 Oct 2009 16:02:49 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1N2R5j-0001xv-RR; Mon, 26 Oct 2009 16:02:39 +0100 Date: Mon, 26 Oct 2009 16:02:39 +0100 From: Carlo Wood To: Vaughn Deluca Message-ID: <20091026150239.GA6496@alinoe.com> References: <20091025121547.GB7775@alinoe.com> <9b8a8de40910251530u273830a5k47bdd8927b7efc76@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b8a8de40910251530u273830a5k47bdd8927b7efc76@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ogpx@ietf.org Subject: Re: [ogpx] My take on Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:02:40 -0000 That's not how I'd put it Vaughn... First of all, for the data proposed (for example, the currently active animation(s)), the AS *is* the natural authority and origin to begin with. Allow me to introduce some more theory / jargon. Consider some variable that changes over time (lets call it 'data'). The value of the variable plays a role in more than one host, and synchronization is done via a network. Because networks are not reliable it must be defined who is the authority, so that in case of failure, things can be re-synchronized from the authority. This means automatically that the authority must keep a copy of the data, of course. Now consider the following: Authority Remote value --------> value I call this a 'downstream' synchronization: the data is always and only first changed on the authority, and then propagated away from it. 'Upstream' messages that would change the value almost garanteed lead to problems, simple example: assume some variable has value 'A', the authority changes it to 'B', and some downstream host changes it at the same time to 'C'. You'd then have: Authority Remote 'B' ---B--> <--C--- 'C' ending in Authority Remote 'C' 'B' Hence that it is much better to work with requests upstream: Authority Remote 'B' ---B--> <--request:C--- 'A' Authority Remote 'C' ---C--> 'B' Authority Remote 'C' 'C' where there exists a race condition whether or not we end up with 'C' or 'B', but at least things stay synchronized. Ok, back to the animation state of an avatar. If we state that the AS is the authority, then you can hardly speak of 'keeping a copy', it's a trivial thing that both the AS as well as the simulator need to know this value. AS Simulator 'animation' -----> 'animation' If you'd want to avoid this (minimal!?) RAM usage on the AS then you are forced to drop the AS as authority, and there is no way you can recover gracefully in case of network failure. Worse, in case of a teleport, you need to CHANGE who the authority is, which gives heaps and heaps of potential problems. On Sun, Oct 25, 2009 at 11:30:48PM +0100, Vaughn Deluca wrote: > > [AS:animation state] --- message stream --> [simulator:animation state copy] > > What you are suggesting here is keeping a copy of the avatar state. We would be > increasing bandwith and storage space to gain flexibility. I do not think > storage space is a real problem. I am not sure about bandwidth. There would be NO increase in bandwidth imho, because the AS *is* the natural authority to begin with: if the user controls the avatar, changes it, then the source/origin is the AS (well, the viewer, but it's no big deal to use the AS as authority; this DOES mean however that the viewer basically only sends requests, and not real state changes). This picture also shows that the most logical place for HUD scripts is the AS as well, not the simulator. > Is there anybody who can put some real numbers on this? How much extra work > would the region have to do? Is it still acceptable if the Agent service is in > Australia and the region in Europe? > > -Vaughn > > On Sun, Oct 25, 2009 at 1:15 PM, Carlo Wood wrote: > > Lets start with some brainstorming... > > Things that might be relevant, in no particular order. > > * State of avatar > * State of attachments > * Location of avatar > * Time of unresponsiveness of avatar (position) towards viewer > * Time of unresponsiveness of attachments (attaching/detaching/scripts) > * Perception of the viewer > * Perception of other viewers > * Region boundary crossing > * Teleport over larger distance > * User configurable parameters > * did I miss something important? > > > Real message starts here: > > Something that protocol (or implementation)- wise leads to problems > are copies of the same data on different hosts; this always leads > to desynchronization of this data with heaps of untrackable problems > (bugs). > > The ONLY way to keep a copy of some data reliably synchrononized is by > having a stream of state changes being sent from one host to another, > where the messages that contain that state changes always keep > the same order and the stream is never terminated/lost (in which case > a full-resynchronization would be necessary). Note that this means > that the source of the state changes has to be a single point of > origin, which automatically means that we can identify the REAL > (original) copy of the data. Thus: > > [original] ---> stream of state changes --> [copy] > > Lets call this an "unidirectional state" by lack of a better word. > > [PS I'm ignoring actual implementation details here. I'm NOT > saying that currently anyone is using a TCP-stream of > state changes, so don't quote JUST this part with the comment > that this is not how it current works, Infinity :p > Instead, this is an mathematical approach, the abstract > equivalent of any possible deployment case]. > > Basically, we want to avoid copies of the same data. > > > The simulator contains a lot of state information that cannot > be moved away from the simulator though: because the state is > needed to calculate the interactions between all objects and > avatars in the region, which would become way too slow if, > for example, several agent domain services would have to be > queried all the time. I can imagine that this also holds for > the attachments on an avatar. > > This means that if an avatar moves from one region to another, > all this state information has to be transfered too. > > Thus, the origin sends state information to the new region. > If this fails, then we want the user to resume at it's old > location: we need to keep a copy of the state until we know > the teleport was successful. In other words, we will have > a copy of data at two different hosts, temporarily. > > One way to make sure that this is not a problem is by > freezing all state; then copy it, and only once the copy > is successful, destroy the old data and resume the simulation > in the other region. > > The problem we try to tackle now is the case were the old > region is not responsive... > > > In this case we have to notice that the AD can ALSO detect > that at least the new region is able to host the avatar: > the teleport can *partly* succeed. This can be detected > independent of copying all the state information. > > Secondly, we have to realize that the 'location' of the > avatar is (state) data that does NOT have to be copied > (we're changing it anyway) and therefore is not part of > said state, and does not suffer from the copy-problem. > > The same could be said about animations (which is currently > broken in Second Life: you must stop all animations > before teleporting or a desync happens): we could state > that after a teleport no animations are active, and leave > it to the viewer to re-initiate and required animations. > However, animations can be made unidirectional (meaning > that if anyone but the agent service wants to change the > animation, it has to send a request message to the AD, > which then grants it, so that the actual state change always > originates from the agent service (AS)). > > As a result, we can think of the animation state as: > > > [AS:animation state] --- message stream --> [simulator:animation state > copy] > > which means that we can teleport, keeping the correct > animation(s) without bothering with the source region. > > > The only clear case where this kind of 'trick' doesn't work > (I think it's not a trick, but the best way to implement this) > is for script states: those change way too frequent to host > them on the AS. > > > Conclusion > > Thus, in the case of an unresponsive source region, > we CAN - without risks of desynchronization - immediately > transfer the avatar (location) and animations, and > any other INFREQUENTLY CHANGING, UNIDIRECTIONAL DATA > that can be stored on the AS (and buffered on the > simulator), like clothing UUIDs, and attachments. > > However, the scripts in the attachments will not run > until their state is transfered from the old region. > > Imho, this is hardly a problem: after user configurable > timeout we leave it to the user what he wants to do: > logout or reset the scripts :p... Ok, we just reset > the scripts after some time, where the timeout is > determined by the AD with possible input from the user. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > -- Carlo Wood From vaughn.deluca@gmail.com Mon Oct 26 12:22:22 2009 Return-Path: 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 0186928C13D for ; Mon, 26 Oct 2009 12:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_05=-1.11, HTML_MESSAGE=0.001, SARE_UNSUB18=0.131] 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 9C1IGTn8yp9e for ; Mon, 26 Oct 2009 12:22:19 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 01C193A697C for ; Mon, 26 Oct 2009 12:22:18 -0700 (PDT) Received: by fxm18 with SMTP id 18so12373814fxm.37 for ; Mon, 26 Oct 2009 12:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=samewgWzwnN4Z56MEExjXvpmul42HqD/qx1SDGLmntg=; b=Et5dcEY2MIUdBdalMjqLXmdXIFzycxUQFOVRc89Pkue+9Lc20LujcdLZ87L8KwxmtT SkBQp4UOQ8nS3Xjh9rYDcgzGu4+OyQHn96FWmwoA9xslogvCm1LvzfLYM8Wb0TV62PRA wkzvWfDOweXA4X5Q104KMD4XkbpiMBHayDFa8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bmSm3LjGeF8ePfrYVix7tVdH9I1F/AQWv9rR8M/X3YqF6U3ICQ2vCQErF98J6kppKc 8QZgzlXi8++UNEeW9m2iHoKWXdLL1QDYNEDpd9qIpD94gLD/151li6i+FeAOfY9t2u88 q6I/Sk3meXg0P8r0e38TP8CQvHr8Uj2PXQ7Oo= MIME-Version: 1.0 Received: by 10.204.156.19 with SMTP id u19mr1044560bkw.62.1256584946326; Mon, 26 Oct 2009 12:22:26 -0700 (PDT) In-Reply-To: <20091026150239.GA6496@alinoe.com> References: <20091025121547.GB7775@alinoe.com> <9b8a8de40910251530u273830a5k47bdd8927b7efc76@mail.gmail.com> <20091026150239.GA6496@alinoe.com> Date: Mon, 26 Oct 2009 20:22:26 +0100 Message-ID: <9b8a8de40910261222q30780f0fp1c8f4fa38383ab5d@mail.gmail.com> From: Vaughn Deluca To: Carlo Wood Content-Type: multipart/alternative; boundary=0015175cd1625b1ccf0476db7b3a Cc: ogpx@ietf.org Subject: Re: [ogpx] My take on Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 19:22:22 -0000 --0015175cd1625b1ccf0476db7b3a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 26, 2009 at 4:02 PM, Carlo Wood wrote: > That's not how I'd put it Vaughn... > First of all, for the data proposed (for example, the currently active > LOL, I have the strong feeling we agree on almost all counts, I was merely pointing out some side effects and trying to get a handle on the actual costs your solution would carry. Your post explains again very clearly the logic behind your proposal, but that was not my point. I fully agree with you that it is a very logical and robust solution, my question related to the efficiency costs. At the end of your post you come to that point: >If you'd want to avoid this (minimal!?) RAM usage on the AS >then you are forced to drop the AS as authority, First, my question was how much data we are *actually* talking about here. You use the animation as an example, but there is much more in the Avatars state than just the current animations. If we serialise the Avatars state to send it over to the next region, how much data is that, and what if I am a full size Dragon with a thousand active scripts and hundreds and hundreds of attachments? And what can we expect it to be in the future? I *suspect* its on average not a critical amount, yet, i was hoping somebody who *knows* would chime in. Second, as i mentioned in my post i am not very concerned about the storage space, but more about the *bandwidth*. In your proposal all changes pass from viewer to AS to region instead of directly from viewer to region. No matter how you call the info a copy, it is present at *both* locations i and since you want to keep the AS in the loop, all updates pass trough the AS, potentially crossing the whole real world. How much traffic is that, and shopuld we be worried? >and there is no way you can recover gracefully in case of >network failure. Right, that is the consequence of being more efficient. I am trying to get some good estimates for the price of that robustness. But maybe i should look at the sourcecode and get an estimation myself... >Worse, in case of a teleport, you need to CHANGE >who the authority is, which gives heaps and heaps of potential >problems. It depends what you are aiming for. You are paying in network traffic and storage space for robustness and flexibility. In some use cases you will want to optimise the robustness of the system yet, if i am running an Agent Domain as a business, i might really not be pleased with he traffic your solution makes me carry, just in case some region i do not own fails... Again, it might be all peanuts, but i would like to *know* Finally, there might actually be another solution. After all, the *real* "natural" authority is the viewer. The viewer can keep a local copy of avatar state. In case of a network failure the AS could ask the viewer to send the authoritative info so it can re-create the state and send it over to the new region. Would that work? -Vaughn > animation(s)), the AS *is* the natural authority and origin to begin with. > > Allow me to introduce some more theory / jargon. Consider some variable > that changes over time (lets call it 'data'). The value of the variable > plays a role in more than one host, and synchronization is done via a > network. Because networks are not reliable it must be defined who is > the authority, so that in case of failure, things can be re-synchronized > from the authority. This means automatically that the authority must > keep a copy of the data, of course. > > Now consider the following: > > Authority Remote > value --------> value > > I call this a 'downstream' synchronization: the data is always and only > first changed on the authority, and then propagated away from it. > > 'Upstream' messages that would change the value almost garanteed lead > to problems, simple example: assume some variable has value 'A', > the authority changes it to 'B', and some downstream host changes it > at the same time to 'C'. You'd then have: > > Authority Remote > 'B' ---B--> <--C--- 'C' > > ending in > > Authority Remote > 'C' 'B' > > Hence that it is much better to work with requests upstream: > > Authority Remote > 'B' ---B--> <--request:C--- 'A' > > Authority Remote > 'C' ---C--> 'B' > > Authority Remote > 'C' 'C' > > where there exists a race condition whether or not we end > up with 'C' or 'B', but at least things stay synchronized. > > > Ok, back to the animation state of an avatar. > If we state that the AS is the authority, then you can hardly > speak of 'keeping a copy', it's a trivial thing that both > the AS as well as the simulator need to know this value. > > AS Simulator > 'animation' -----> 'animation' > > If you'd want to avoid this (minimal!?) RAM usage on the AS > then you are forced to drop the AS as authority, and there > is no way you can recover gracefully in case of network > failure. Worse, in case of a teleport, you need to CHANGE > who the authority is, which gives heaps and heaps of potential > problems. > > On Sun, Oct 25, 2009 at 11:30:48PM +0100, Vaughn Deluca wrote: > > > [AS:animation state] --- message stream --> [simulator:animation state > copy] > > > > What you are suggesting here is keeping a copy of the avatar state. We > would be > > increasing bandwith and storage space to gain flexibility. I do not > think > > storage space is a real problem. I am not sure about bandwidth. > > There would be NO increase in bandwidth imho, because the AS *is* the > natural authority to begin with: if the user controls the avatar, changes > it, then the source/origin is the AS (well, the viewer, but it's no > big deal to use the AS as authority; this DOES mean however that the > viewer basically only sends requests, and not real state changes). > > This picture also shows that the most logical place for HUD scripts > is the AS as well, not the simulator. > > > Is there anybody who can put some real numbers on this? How much extra > work > > would the region have to do? Is it still acceptable if the Agent service > is in > > Australia and the region in Europe? > > > > -Vaughn > > > > On Sun, Oct 25, 2009 at 1:15 PM, Carlo Wood wrote: > > > > Lets start with some brainstorming... > > > > Things that might be relevant, in no particular order. > > > > * State of avatar > > * State of attachments > > * Location of avatar > > * Time of unresponsiveness of avatar (position) towards viewer > > * Time of unresponsiveness of attachments > (attaching/detaching/scripts) > > * Perception of the viewer > > * Perception of other viewers > > * Region boundary crossing > > * Teleport over larger distance > > * User configurable parameters > > * did I miss something important? > > > > > > Real message starts here: > > > > Something that protocol (or implementation)- wise leads to problems > > are copies of the same data on different hosts; this always leads > > to desynchronization of this data with heaps of untrackable problems > > (bugs). > > > > The ONLY way to keep a copy of some data reliably synchrononized is > by > > having a stream of state changes being sent from one host to another, > > where the messages that contain that state changes always keep > > the same order and the stream is never terminated/lost (in which case > > a full-resynchronization would be necessary). Note that this means > > that the source of the state changes has to be a single point of > > origin, which automatically means that we can identify the REAL > > (original) copy of the data. Thus: > > > > [original] ---> stream of state changes --> [copy] > > > > Lets call this an "unidirectional state" by lack of a better word. > > > > [PS I'm ignoring actual implementation details here. I'm NOT > > saying that currently anyone is using a TCP-stream of > > state changes, so don't quote JUST this part with the comment > > that this is not how it current works, Infinity :p > > Instead, this is an mathematical approach, the abstract > > equivalent of any possible deployment case]. > > > > Basically, we want to avoid copies of the same data. > > > > > > The simulator contains a lot of state information that cannot > > be moved away from the simulator though: because the state is > > needed to calculate the interactions between all objects and > > avatars in the region, which would become way too slow if, > > for example, several agent domain services would have to be > > queried all the time. I can imagine that this also holds for > > the attachments on an avatar. > > > > This means that if an avatar moves from one region to another, > > all this state information has to be transfered too. > > > > Thus, the origin sends state information to the new region. > > If this fails, then we want the user to resume at it's old > > location: we need to keep a copy of the state until we know > > the teleport was successful. In other words, we will have > > a copy of data at two different hosts, temporarily. > > > > One way to make sure that this is not a problem is by > > freezing all state; then copy it, and only once the copy > > is successful, destroy the old data and resume the simulation > > in the other region. > > > > The problem we try to tackle now is the case were the old > > region is not responsive... > > > > > > In this case we have to notice that the AD can ALSO detect > > that at least the new region is able to host the avatar: > > the teleport can *partly* succeed. This can be detected > > independent of copying all the state information. > > > > Secondly, we have to realize that the 'location' of the > > avatar is (state) data that does NOT have to be copied > > (we're changing it anyway) and therefore is not part of > > said state, and does not suffer from the copy-problem. > > > > The same could be said about animations (which is currently > > broken in Second Life: you must stop all animations > > before teleporting or a desync happens): we could state > > that after a teleport no animations are active, and leave > > it to the viewer to re-initiate and required animations. > > However, animations can be made unidirectional (meaning > > that if anyone but the agent service wants to change the > > animation, it has to send a request message to the AD, > > which then grants it, so that the actual state change always > > originates from the agent service (AS)). > > > > As a result, we can think of the animation state as: > > > > > > [AS:animation state] --- message stream --> [simulator:animation > state > > copy] > > > > which means that we can teleport, keeping the correct > > animation(s) without bothering with the source region. > > > > > > The only clear case where this kind of 'trick' doesn't work > > (I think it's not a trick, but the best way to implement this) > > is for script states: those change way too frequent to host > > them on the AS. > > > > > > Conclusion > > > > Thus, in the case of an unresponsive source region, > > we CAN - without risks of desynchronization - immediately > > transfer the avatar (location) and animations, and > > any other INFREQUENTLY CHANGING, UNIDIRECTIONAL DATA > > that can be stored on the AS (and buffered on the > > simulator), like clothing UUIDs, and attachments. > > > > However, the scripts in the attachments will not run > > until their state is transfered from the old region. > > > > Imho, this is hardly a problem: after user configurable > > timeout we leave it to the user what he wants to do: > > logout or reset the scripts :p... Ok, we just reset > > the scripts after some time, where the timeout is > > determined by the AD with possible input from the user. > > > > -- > > Carlo Wood > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > > -- > Carlo Wood > --0015175cd1625b1ccf0476db7b3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 26, 2009 at 4:02 PM, Carlo Wood <carlo@alinoe.com&= gt; wrote:
That's not how I'd put it Vaughn...
First of all, for the data proposed (for example, the currently active
<= /blockquote>

LOL, I have the strong feeling we agre= e on almost all counts, I was merely pointing out some side effects and try= ing to get a handle on the actual costs your solution would carry. Your pos= t explains again very clearly the logic behind your proposal, but that was = not my point. I fully agree with you that it is a very logical and robust s= olution, my question related to the efficiency costs.

At the end of your post you come to that point:

>If you'd want to avoid this (minimal!?) RAM usage= on the AS
>then you are forced to drop the AS as authorit= y,

First, my question was how much data we are *actua= lly* talking about here. You use the animation as an example, but there is = much more in the Avatars state than just the current animations. If we seri= alise the Avatars state to send it over to the next region, how much data i= s that, and what if I am a full size Dragon with a thousand active scripts = and hundreds and hundreds of attachments? And =A0what can we expect it to b= e in the future?=A0
I *suspect* its on average not a critical amount, yet, i was hoping so= mebody who *knows* would chime in.=A0

Second, as i= mentioned in my post i am not very concerned about the storage space, but = more about the *bandwidth*. In your proposal all changes pass from viewer t= o AS to region instead of directly from viewer to region. No matter how you= call the info a copy, it is present at *both* locations i and since you wa= nt to keep the AS in the loop, all updates pass trough the AS, potentially = crossing the whole real world. How much traffic is that, and shopuld we be = worried?

>and there=A0is no way you can recover gracefu= lly in case of=A0
>network=A0failure.=A0

<= div>
Right, that is the consequence of being more efficient. =A0I am = =A0trying to get some good estimates for the price of that robustness. But = maybe i should look at the sourcecode and get an estimation myself...

>Worse, in case of a teleport, you need = to CHANGE
>who the authority is, which gives heaps and heaps of poten= tial
>problems.

It depends what you= are aiming for. You are paying in network traffic and storage space for ro= bustness and flexibility. In some use cases you will want to optimise the r= obustness of the system yet, if i am running an Agent Domain as a business,= i might really not be pleased with he traffic your solution makes me carry= , just in case some region i do not own fails... =A0Again, it might be all = peanuts, but i would like to *know*

Finally, there might actually be another solution. Afte= r all, the *real* "natural" authority is the viewer. =A0The viewe= r can keep a local copy of avatar state. In case of a network failure the A= S could ask the viewer to send the authoritative info so it can re-create t= he state and send it over to the new region. Would that work?

-Vaughn


= =A0
animation(s)), the AS *is* the natural authority and origin to begin with.<= br>
Allow me to introduce some more theory / jargon. Consider some variable
that changes over time (lets call it 'data'). The value of the vari= able
plays a role in more than one host, and synchronization is done via a
network. Because networks are not reliable it must be defined who is
the authority, so that in case of failure, things can be re-synchronized from the authority. This means automatically that the authority must
keep a copy of the data, of course.

Now consider the following:

=A0Authority =A0 =A0 =A0 =A0 =A0 =A0 Remote
=A0value =A0 =A0 =A0--------> =A0value

I call this a 'downstream' synchronization: the data is always and = only
first changed on the authority, and then propagated away from it.

'Upstream' messages that would change the value almost garanteed le= ad
to problems, simple example: assume some variable has value 'A', the authority changes it to 'B', and some downstream host changes i= t
at the same time to 'C'. You'd then have:

=A0Authority =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Remote
=A0'B' =A0 =A0 =A0 ---B--> =A0<--C--- =A0'C'

ending in

=A0Authority =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Remote
=A0'C' =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 'B'=

Hence that it is much better to work with requests upstream:

=A0Authority =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Remote =A0'B' =A0 =A0 =A0 ---B--> =A0<--request:C--- =A0'A'=

=A0Authority =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Remote =A0'C' =A0 =A0 =A0 ---C--> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 'B'

=A0Authority =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Remote =A0'C' =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 'C'

where there exists a race condition whether or not we end
up with 'C' or 'B', but at least things stay synchronized.<= br>

Ok, back to the animation state of an avatar.
If we state that the AS is the authority, then you can hardly
speak of 'keeping a copy', it's a trivial thing that both
the AS as well as the simulator need to know this value.

=A0AS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Simulator
=A0'animation' =A0 =A0-----> =A0 =A0'animation'

If you'd want to avoid this (minimal!?) RAM usage on the AS
then you are forced to drop the AS as authority, and there
is no way you can recover gracefully in case of network
failure. Worse, in case of a teleport, you need to CHANGE
who the authority is, which gives heaps and heaps of potential
problems.

On Sun, Oct 25, 2009 at 11:30:48PM +0100, Vaughn Deluca wrote:
> > [AS:animation state] --- message stream --> [simulator:animati= on state copy]
>
> What you are suggesting here is keeping a copy of the avatar state. We= would be
> increasing bandwith and storage space to gain flexibility. I do =A0not= think
> storage space is a real problem. I am not sure about bandwidth.

There would be NO increase in bandwidth imho, because the AS *is* the=
natural authority to begin with: if the user controls the avatar, changes it, then the source/origin is the AS (well, the viewer, but it's no
big deal to use the AS as authority; this DOES mean however that the
viewer basically only sends requests, and not real state changes).

This picture also shows that the most logical place for HUD scripts
is the AS as well, not the simulator.

> Is there anybody who can put some real numbers on this? How much extra= work
> would the region have to do? Is it still acceptable if the Agent servi= ce is in
> Australia and the region in Europe?
>
> -Vaughn
>
> On Sun, Oct 25, 2009 at 1:15 PM, Carlo Wood <carlo@alinoe.com> wrote:
>
> =A0 =A0 Lets start with some brainstorming...
>
> =A0 =A0 Things that might be relevant, in no particular order.
>
> =A0 =A0 * State of avatar
> =A0 =A0 * State of attachments
> =A0 =A0 * Location of avatar
> =A0 =A0 * Time of unresponsiveness of avatar (position) towards viewer=
> =A0 =A0 * Time of unresponsiveness of attachments (attaching/detaching= /scripts)
> =A0 =A0 * Perception of the viewer
> =A0 =A0 * Perception of other viewers
> =A0 =A0 * Region boundary crossing
> =A0 =A0 * Teleport over larger distance
> =A0 =A0 * User configurable parameters
> =A0 =A0 * did I miss something important?
>
>
> =A0 =A0 Real message starts here:
>
> =A0 =A0 Something that protocol (or implementation)- wise leads to pro= blems
> =A0 =A0 are copies of the same data on different hosts; this always le= ads
> =A0 =A0 to desynchronization of this data with heaps of untrackable pr= oblems
> =A0 =A0 (bugs).
>
> =A0 =A0 The ONLY way to keep a copy of some data reliably synchrononiz= ed is by
> =A0 =A0 having a stream of state changes being sent from one host to a= nother,
> =A0 =A0 where the messages that contain that state changes always keep=
> =A0 =A0 the same order and the stream is never terminated/lost (in whi= ch case
> =A0 =A0 a full-resynchronization would be necessary). Note that this m= eans
> =A0 =A0 that the source of the state changes has to be a single point = of
> =A0 =A0 origin, which automatically means that we can identify the REA= L
> =A0 =A0 (original) copy of the data. Thus:
>
> =A0 =A0 =A0[original] ---> stream of state changes --> [copy] >
> =A0 =A0 Lets call this an "unidirectional state" by lack of = a better word.
>
> =A0 =A0 [PS I'm ignoring actual implementation details here. I'= ;m NOT
> =A0 =A0 =A0 =A0saying that currently anyone is using a TCP-stream of > =A0 =A0 =A0 =A0state changes, so don't quote JUST this part with t= he comment
> =A0 =A0 =A0 =A0that this is not how it current works, Infinity :p
> =A0 =A0 =A0 =A0Instead, this is an mathematical approach, the abstract=
> =A0 =A0 =A0 =A0equivalent of any possible deployment case].
>
> =A0 =A0 Basically, we want to avoid copies of the same data.
>
>
> =A0 =A0 The simulator contains a lot of state information that cannot<= br> > =A0 =A0 be moved away from the simulator though: because the state is<= br> > =A0 =A0 needed to calculate the interactions between all objects and > =A0 =A0 avatars in the region, which would become way too slow if,
> =A0 =A0 for example, several agent domain services would have to be > =A0 =A0 queried all the time. I can imagine that this also holds for > =A0 =A0 the attachments on an avatar.
>
> =A0 =A0 This means that if an avatar moves from one region to another,=
> =A0 =A0 all this state information has to be transfered too.
>
> =A0 =A0 Thus, the origin sends state information to the new region. > =A0 =A0 If this fails, then we want the user to resume at it's old=
> =A0 =A0 location: we need to keep a copy of the state until we know > =A0 =A0 the teleport was successful. In other words, we will have
> =A0 =A0 a copy of data at two different hosts, temporarily.
>
> =A0 =A0 One way to make sure that this is not a problem is by
> =A0 =A0 freezing all state; then copy it, and only once the copy
> =A0 =A0 is successful, destroy the old data and resume the simulation<= br> > =A0 =A0 in the other region.
>
> =A0 =A0 The problem we try to tackle now is the case were the old
> =A0 =A0 region is not responsive...
>
>
> =A0 =A0 In this case we have to notice that the AD can ALSO detect
> =A0 =A0 that at least the new region is able to host the avatar:
> =A0 =A0 the teleport can *partly* succeed. This can be detected
> =A0 =A0 independent of copying all the state information.
>
> =A0 =A0 Secondly, we have to realize that the 'location' of th= e
> =A0 =A0 avatar is (state) data that does NOT have to be copied
> =A0 =A0 (we're changing it anyway) and therefore is not part of > =A0 =A0 said state, and does not suffer from the copy-problem.
>
> =A0 =A0 The same could be said about animations (which is currently > =A0 =A0 broken in Second Life: you must stop all animations
> =A0 =A0 before teleporting or a desync happens): we could state
> =A0 =A0 that after a teleport no animations are active, and leave
> =A0 =A0 it to the viewer to re-initiate and required animations.
> =A0 =A0 However, animations can be made unidirectional (meaning
> =A0 =A0 that if anyone but the agent service wants to change the
> =A0 =A0 animation, it has to send a request message to the AD,
> =A0 =A0 which then grants it, so that the actual state change always > =A0 =A0 originates from the agent service (AS)).
>
> =A0 =A0 As a result, we can think of the animation state as:
>
>
> =A0 =A0 =A0[AS:animation state] --- message stream --> [simulator:a= nimation state
> =A0 =A0 copy]
>
> =A0 =A0 which means that we can teleport, keeping the correct
> =A0 =A0 animation(s) without bothering with the source region.
>
>
> =A0 =A0 The only clear case where this kind of 'trick' doesn&#= 39;t work
> =A0 =A0 (I think it's not a trick, but the best way to implement t= his)
> =A0 =A0 is for script states: those change way too frequent to host > =A0 =A0 them on the AS.
>
>
> =A0 =A0 Conclusion
>
> =A0 =A0 Thus, in the case of an unresponsive source region,
> =A0 =A0 we CAN - without risks of desynchronization - immediately
> =A0 =A0 transfer the avatar (location) and animations, and
> =A0 =A0 any other INFREQUENTLY CHANGING, UNIDIRECTIONAL DATA
> =A0 =A0 that can be stored on the AS (and buffered on the
> =A0 =A0 simulator), like clothing UUIDs, and attachments.
>
> =A0 =A0 However, the scripts in the attachments will not run
> =A0 =A0 until their state is transfered from the old region.
>
> =A0 =A0 Imho, this is hardly a problem: after user configurable
> =A0 =A0 timeout we leave it to the user what he wants to do:
> =A0 =A0 logout or reset the scripts :p... Ok, we just reset
> =A0 =A0 the scripts after some time, where the timeout is
> =A0 =A0 determined by the AD with possible input from the user.
>
> =A0 =A0 --
> =A0 =A0 Carlo Wood <carlo@alino= e.com>
> =A0 =A0 _______________________________________________
> =A0 =A0 ogpx mailing list
> =A0 =A0 ogpx@ietf.org
> =A0 =A0 https://www.ietf.org/mailman/listinfo/ogpx
>
>

--
Carlo Wood <carlo@alinoe.com>

--0015175cd1625b1ccf0476db7b3a-- From carlo@alinoe.com Mon Oct 26 15:03:45 2009 Return-Path: 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 8654F28C18B for ; Mon, 26 Oct 2009 15:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.985 X-Spam-Level: X-Spam-Status: No, score=0.985 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 dGxJI34pE1az for ; Mon, 26 Oct 2009 15:03:44 -0700 (PDT) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id 51C2A28C181 for ; Mon, 26 Oct 2009 15:03:44 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091026220356.JEIG27358.viefep19-int.chello.at@edge01.upc.biz>; Mon, 26 Oct 2009 23:03:56 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id xa3t1c02r0FlQed01a3uxN; Mon, 26 Oct 2009 23:03:56 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1N2XfE-0006N8-9e; Mon, 26 Oct 2009 23:03:44 +0100 Date: Mon, 26 Oct 2009 23:03:44 +0100 From: Carlo Wood To: Vaughn Deluca Message-ID: <20091026220344.GA24111@alinoe.com> References: <20091025121547.GB7775@alinoe.com> <9b8a8de40910251530u273830a5k47bdd8927b7efc76@mail.gmail.com> <20091026150239.GA6496@alinoe.com> <9b8a8de40910261222q30780f0fp1c8f4fa38383ab5d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b8a8de40910261222q30780f0fp1c8f4fa38383ab5d@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ogpx@ietf.org Subject: Re: [ogpx] My take on Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 22:03:45 -0000 On Mon, Oct 26, 2009 at 08:22:26PM +0100, Vaughn Deluca wrote: > Second, as i mentioned in my post i am not very concerned about the storage > space, but more about the *bandwidth*. In your proposal all changes pass from > viewer to AS to region instead of directly from viewer to region. No matter how Nah, only the avatar state changes, which are really minimal... The bulk, all traffic FROM the region TO the viewer can go directly to the viewer for start (except avatar state change requests: scripts changing the avatars animation - which is really minimal). Also real data, like texture uploads will most likely go directly to the simulator, but well... those are things that are not done often: * changing animation * changing attachments * changing clothes * movement (even!) the reason movement doesn't carry lots of data is simply because it's generated by a few typed characters: human input. Each of those are small messages (sone UUID's) and with a low frequency. In fact, I can't think of anything from viewer to simulator that uses any significant bandwidth :/ Script state might be "significant", but 1) smaller than the average texture, and 2) only needed when someone teleports. Besides, scripts run on the simulator, not on the AS (although I think HUD scripts should; but THOSE don't need their state to be sent to the simulator). Non-avatar state data can just go directly to the simulator anyway, thus. For example, local chat. -- Carlo Wood From morgaine.dinova@googlemail.com Mon Oct 26 18:48:59 2009 Return-Path: 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 D179928C151 for ; Mon, 26 Oct 2009 18:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 PRVK25mIlToH for ; Mon, 26 Oct 2009 18:48:58 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id EB13A28C0DB for ; Mon, 26 Oct 2009 18:48:57 -0700 (PDT) Received: by ewy4 with SMTP id 4so4230780ewy.37 for ; Mon, 26 Oct 2009 18:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=OiwfenDUteo58JY5sRJU5j/C/9zpJtJcIc6s9BEIUBI=; b=Wun2Hcf3uG6wJ1asWj6HdD60xl7oCSEi87CU1G7v+tvRTVp4aw0V2ejS6rA27PYcnj GP3rrSh9CT1VhcGoYK2Egx2Gqar2gBLQ7VkZQSPXtJNBGu1eJdgj/XU3rJNt4fESXXFH FkCyDuF9il9iRD/jntoIWadFjEnyIzoYpUmUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=GJAkiFa5RGFVXKLwRvderNjiLfXB5LlhOoFlsdmXu4bWUvuSKhpIohlRZZ14NbGLfV zaz0SMZfZVS7lBuwXWRdQgBwJBFJRMphUc2UVZoHw1AjTYOM6ilvZ4Z9oNf/MLUYFw3B X0/ucLXxhOHK6nM39gBl/KzF8Ffya9N+YqIcw= MIME-Version: 1.0 Received: by 10.216.86.142 with SMTP id w14mr898107wee.74.1256608148452; Mon, 26 Oct 2009 18:49:08 -0700 (PDT) In-Reply-To: <20091026220344.GA24111@alinoe.com> References: <20091025121547.GB7775@alinoe.com> <9b8a8de40910251530u273830a5k47bdd8927b7efc76@mail.gmail.com> <20091026150239.GA6496@alinoe.com> <9b8a8de40910261222q30780f0fp1c8f4fa38383ab5d@mail.gmail.com> <20091026220344.GA24111@alinoe.com> Date: Tue, 27 Oct 2009 02:49:08 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016e6dab6dc4f81650476e0e274 Subject: Re: [ogpx] My take on Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 01:48:59 -0000 --0016e6dab6dc4f81650476e0e274 Content-Type: text/plain; charset=ISO-8859-1 There are many different pathways and data semantics involved during a teleport event. Almost every permutation of one client, one AD, two regions, two RDs, and a potentially unlimited number of asset services can yield a pathway that may be exercised during the overall teleport avatar operation. There is no single rule that applies to them all and allows one to claim that it's efficient. And it gets even more complex when you consider that some service pathways may be proxied by regions and others not, as a provider design choice. Furthermore, more than one type of data can flow along each pathway, so even a single pathway can involve many different semantics. This makes generalized answers very unhelpful. This is why I decoupled the operation of *agent* teleport from the other * avatar*-related operations that are triggered at the same time but which are very distinct from agent teleport. This allows us to make progress on TP protocol resilience without having to consider the numerous pathways for avatar data first. Morgaine, ================================ On Mon, Oct 26, 2009 at 11:03 PM, Carlo Wood wrote: > On Mon, Oct 26, 2009 at 08:22:26PM +0100, Vaughn Deluca wrote: > > Second, as i mentioned in my post i am not very concerned about the > storage > > space, but more about the *bandwidth*. In your proposal all changes pass > from > > viewer to AS to region instead of directly from viewer to region. No > matter how > > Nah, only the avatar state changes, which are really minimal... > The bulk, all traffic FROM the region TO the viewer can go directly > to the viewer for start (except avatar state change requests: > scripts changing the avatars animation - which is really minimal). > Also real data, like texture uploads will most likely go directly > to the simulator, but well... those are things that are not done > often: > > * changing animation > * changing attachments > * changing clothes > * movement (even!) > > the reason movement doesn't carry lots of data is simply because > it's generated by a few typed characters: human input. > > Each of those are small messages (sone UUID's) and with a low > frequency. > > In fact, I can't think of anything from viewer to simulator > that uses any significant bandwidth :/ > > Script state might be "significant", but 1) smaller than the > average texture, and 2) only needed when someone teleports. > Besides, scripts run on the simulator, not on the AS (although > I think HUD scripts should; but THOSE don't need their state > to be sent to the simulator). > > Non-avatar state data can just go directly to the simulator > anyway, thus. For example, local chat. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0016e6dab6dc4f81650476e0e274 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are many different pathways and data semantics involved during a tele= port event.

Almost every permutation of one client, one AD, two regi= ons, two RDs, and a potentially unlimited number of asset services can yiel= d a pathway that may be exercised during the overall teleport avatar operat= ion.=A0 There is no single rule that applies to them all and allows one to = claim that it's efficient.=A0 And it gets even more complex when you co= nsider that some service pathways may be proxied by regions and others not,= as a provider design choice.

Furthermore,=A0 more than one type of data can flow along each pathway,= so even a single pathway can involve many different semantics.=A0 This mak= es generalized answers very unhelpful.

This is why I decoupled the o= peration of agent teleport from the other avatar-relat= ed operations that are triggered at the same time but which are very distin= ct from agent teleport.=A0 This allows us to make progress on TP protocol r= esilience without having to consider the numerous pathways for avatar data = first.


Morgaine,




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Oct 26, 2009 at 11:03 PM, Carlo Wood <carlo@alinoe.com> wrote:
On Mon, Oct 26, 2009 at 08:22:26PM +0100, Vaughn Deluca wrote:
> Second, as i mentioned in my post i am not very concerned about the st= orage
> space, but more about the *bandwidth*. In your proposal all changes pa= ss from
> viewer to AS to region instead of directly from viewer to region. No m= atter how

Nah, only the avatar state changes, which are really minimal...
The bulk, all traffic FROM the region TO the viewer can go directly
to the viewer for start (except avatar state change requests:
scripts changing the avatars animation - which is really minimal).
Also real data, like texture uploads will most likely go directly
to the simulator, but well... those are things that are not done
often:

* changing animation
* changing attachments
* changing clothes
* movement (even!)

the reason movement doesn't carry lots of data is simply because
it's generated by a few typed characters: human input.

Each of those are small messages (sone UUID's) and with a low
frequency.

In fact, I can't think of anything from viewer to simulator
that uses any significant bandwidth :/

Script state might be "significant", but 1) smaller than the
average texture, and 2) only needed when someone teleports.
Besides, scripts run on the simulator, not on the AS (although
I think HUD scripts should; but THOSE don't need their state
to be sent to the simulator).

Non-avatar state data can just go directly to the simulator
anyway, thus. For example, local chat.

--
Carlo Wood <carlo@alinoe.com>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--0016e6dab6dc4f81650476e0e274-- From morgaine.dinova@googlemail.com Mon Oct 26 22:15:31 2009 Return-Path: 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 C9EB73A67F2 for ; Mon, 26 Oct 2009 22:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 qdDiURdR6YV2 for ; Mon, 26 Oct 2009 22:15:30 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 022343A635F for ; Mon, 26 Oct 2009 22:15:29 -0700 (PDT) Received: by ewy4 with SMTP id 4so4321160ewy.37 for ; Mon, 26 Oct 2009 22:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=YTHtWcZpbztV58Waxf7l8U0aA0EkyKOv8qym5Q4ZC38=; b=ifGVwyNXq4inuR9ZQj9cfy28RUYmy8XExHIgKVMfNPKnC56ypMYbeSvxFdhSYzNXuZ l5dkFN9wkraj2F95cUSEjc5FDGMS3VSPqSBDuvNbBuH/QkeMf6dtl7qsJIDSKPSrHuta 5hs/sa6NPOp+WeyZETENFwar8hMbiWucGSw3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rhKeR27q5+gRXATwJldrKQRJHgN9doMKiikimxFaON/6F/DFZnQ2Ql75r1GWMHXVCZ GPOFzeAM7QTtwOpata+GzsVoMqazrunjpAMkf5CI/pDY3BFwEuB4ANQ2iBO8eV5geWar TMVk0/ll3iLvHxV2mQO0fOfaetwZYSRTV/MsE= MIME-Version: 1.0 Received: by 10.216.87.7 with SMTP id x7mr4100931wee.53.1256620541414; Mon, 26 Oct 2009 22:15:41 -0700 (PDT) Date: Tue, 27 Oct 2009 06:15:41 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636c5b1e2fd0d9d0476e3c47e Subject: [ogpx] Limits to interoperability of scripted objects X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 05:15:31 -0000 --001636c5b1e2fd0d9d0476e3c47e Content-Type: text/plain; charset=ISO-8859-1 There has been some mention here of script state transfer between regions on teleport over the last week. Some caution may be needed. VWRAP has not (yet) examined object scripting, and therefore to discuss transfer of script states has very little concrete meaning at the moment. Unfortunately the situation is worse than merely "not yet known", because as things stand today, there is very little likelihood that script states are interoperable at all. Script state is intrinsically linked to scripting engine implementation, and there is no proposal on the table for standardizing on a common scripting engine implementation for use by interoperating parties. The only reason why script state is maintained across region handovers or teleports in Second Life is because all the regions use the same scripting engines. The same is true for script state movement between regions in Opensim-based worlds. However, you can't transfer script states between SL and Opensim regions because they use different scripting engines with different state requirements, even when using a common scripting language. It's easy enough to conceive of a mechanism by which script states *could*be made portable irrespective of varying scripting engine implementations: it just requires an extensible state descriptor unit (SDU) to be defined using a portable ADT such as LLSD, thus making state transfer portable at the protocol level. Unfortunately this just passes the problem along to the language and scripting engine implementers who then have to map their incompatible scripting engines to a common SDU. While this is certainly possible, it doesn't get us much closer to effective interop for script states. While the above is bad enough, unfortunately it gets worse still. Object scripts interact with the local simulator environment, and that environment is: - undefined except by common practice, - continually changing under pressure from progress and policy, - semantically different in different worlds because the implementations differ, - programmatically different because the set of callable functions differs among interoperable worlds. What the above boils down to is that, without wholesale new design in this area, VWRAP is not going to be able to deliver continuity of script states across teleports between regions in different worlds, because neither the mechanisms nor the common environments are there to support this. Being pragmatic about the situation, if we wish to see interop of scripting in the relatively near future, we need to find an approach that is inherently interoperable. Here are some ideas that might be relevant to this end (these are alternatives, they don't all apply simultaneously): 1. Make script state transfer a deployment option: both source and destination regions have to allow script state transfer for it to happen. 2. Worlds running different scripting engine implementations do not transfer state and hence scripts are initialized on teleport. 3. Define a common scripting language and virtual machine environment --- ie. a web-like Javascript approach but for regions. 4. If script state continuity is desired on teleports between worlds running different script engines, let such scripts run client-side. Points 1 and 2 offer near-term solutions, but the functionality varies depending on the particular deployment. Points 3 and 4 offer much broader functionality, but have a much larger design effort penalty that is probably beyond our present scope. Morgaine. --001636c5b1e2fd0d9d0476e3c47e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There has been some mention here of script state transfer between regions o= n teleport over the last week.=A0 Some caution may be needed.

VWRAP = has not (yet) examined object scripting, and therefore to discuss transfer = of script states has very little concrete meaning at the moment.

Unfortunately the situation is worse than merely "not yet known&qu= ot;, because as things stand today, there is very little likelihood that sc= ript states are interoperable at all.=A0 Script state is intrinsically link= ed to scripting engine implementation, and there is no proposal on the tabl= e for standardizing on a common scripting engine implementation for use by = interoperating parties.

The only reason why script state is maintained across region handovers = or teleports in Second Life is because all the regions use the same scripti= ng engines.=A0 The same is true for script state movement between regions i= n Opensim-based worlds.=A0 However, you can't transfer script states be= tween SL and Opensim regions because they use different scripting engines w= ith different state requirements, even when using a common scripting langua= ge.

It's easy enough to conceive of a mechanism by which script states = could be made portable irrespective of varying scripting engi= ne implementations:=A0 it just requires an extensible state descriptor unit= (SDU) to be defined using a portable ADT such as LLSD, thus making state t= ransfer portable at the protocol level.=A0 Unfortunately this just passes t= he problem along to the language and scripting engine implementers who then= have to map their incompatible scripting engines to a common SDU.=A0 While= this is certainly possible, it doesn't get us much closer to effective= interop for script states.

While the above is bad enough, unfortunately it gets worse still.
Object scripts interact with the local simulator environment, and that en= vironment is:

  • undefined except by common practice,
  • continually changing under pressure from progress and policy,
  • s= emantically different in different worlds because the implementations diffe= r,
  • programmatically different because the set of callable functions= differs among interoperable worlds.

What the above boils down to is that, without wholesale new design= in this area, VWRAP is not going to be able to deliver continuity of scrip= t states across teleports between regions in different worlds, because neit= her the mechanisms nor the common environments are there to support this.
Being pragmatic about the situation, if we wish to see interop of scrip= ting in the relatively near future, we need to find an approach that is inh= erently interoperable.=A0 Here are some ideas that might be relevant to thi= s end (these are alternatives, they don't all apply simultaneously):
  1. Make script state transfer a deployment option:=A0 both source = and destination regions have to allow script state transfer for it to happe= n.
  2. Worlds running different scripting engine implementations do not= transfer state and hence scripts are initialized on teleport.
  3. Define a common scripting language and virtual machine environment --- = ie. a web-like Javascript approach but for regions.
  4. If script state= continuity is desired on teleports between worlds running different script= engines, let such scripts run client-side.

Points 1 and 2 offer near-term solutions, but the functionali= ty varies depending on the particular deployment.

Points 3 and 4 off= er much broader functionality, but have a much larger design effort penalty= that is probably beyond our present scope.


Morgaine.


--001636c5b1e2fd0d9d0476e3c47e-- From josh@lindenlab.com Tue Oct 27 09:51:28 2009 Return-Path: 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 2D43228C0EC for ; Tue, 27 Oct 2009 09:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.536 X-Spam-Level: X-Spam-Status: No, score=-1.536 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 Yr-MyI2kehed for ; Tue, 27 Oct 2009 09:51:27 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id DA4CD28C1F9 for ; Tue, 27 Oct 2009 09:51:26 -0700 (PDT) Received: by iwn16 with SMTP id 16so263458iwn.29 for ; Tue, 27 Oct 2009 09:51:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.5.23 with SMTP id 23mr6762362ibt.45.1256662295537; Tue, 27 Oct 2009 09:51:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Oct 2009 09:51:35 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00151773da30ba67d90476ed7d4a Subject: Re: [ogpx] Limits to interoperability of scripted objects X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:51:28 -0000 --00151773da30ba67d90476ed7d4a Content-Type: text/plain; charset=UTF-8 Good analysis as usual, Morgaine! On Mon, Oct 26, 2009 at 10:15 PM, Morgaine wrote: > Being pragmatic about the situation, if we wish to see interop of scripting > in the relatively near future, we need to find an approach that is > inherently interoperable. Here are some ideas that might be relevant to > this end (these are alternatives, they don't all apply simultaneously): > > > 1. Make script state transfer a deployment option: both source and > destination regions have to allow script state transfer for it to happen. > 2. Worlds running different scripting engine implementations do not > transfer state and hence scripts are initialized on teleport. > 3. Define a common scripting language and virtual machine environment > --- ie. a web-like Javascript approach but for regions. > 4. If script state continuity is desired on teleports between worlds > running different script engines, let such scripts run client-side. > > A few thoughts on the above: * Even though the Web appears to have given up on content negotiation over HTTP, I'm still a fan and I think cross-system interop like this is a good place for it. During Region-to-Region state transfer, you could imagine the destination region advertising the script state types it accepts (vendor/com.lindenlab.secondlife.lsl2mono, vendor/org.opensim.dotnetengine, ...), and the source region delivering one tagged with appropriate type. I would imagine we'll need similar logic for static content as well - articles of clothing could have have "prim" or "mesh" based versions, and regions may prefer one type to another. (Although it would be more likely to have both available on the region, and have content negotiation occur on the region->viewer resource transfer.) * Given the desire for "tourist" models (using the term loosely - I "live" on my home grid, but like to visit other grids), it doesn't seem like there's a one-size-fits-all approach (since region-to-region teleports in my home grid and region-to-region teleports between grids utilize the same protocol). So... this is definitely part of the protocol's mandate to sort out. * Combining the above two points, it implies that attachments will have to cope with moving from areas where they have scripts running to scripts not running (if the code/state is not compatible with the hosting region). Fortunately, we have precedent for that. :) * Infinity and I very briefly hand-waved about whether "portable" content (primarily, attachments to avatars) should even be executed within the region domain. Perhaps they should be executing in the agent domain? That's a radical departure from how SL or OpenSim work today. (If you squint your eyes and partition the current services, at least.) - at any rate, today there is no script execution outside of a region. It's an intriguing idea, but by no means complete - how such fine grained state might be updated between domains, for example. Vehicles come to mind as another case, and those have no clear "home base" for script execution. I suspect this is not tractable for the first iteration of VWRAP, but I don't want to dismiss it. * Your (3) (common scripting environment) is intriguing. Sun's Project Wonderland uses Java (obviously...) as the common format, and (vastly simplifying) all objects in the VW are Java objects. I'd love to learn more from them about the challenges and successes. That said, at a protocol level, I don't think we'd ever dictate a common environment, so going down this road might turn into a de-facto common case of the content negotiation (just as the Web technically allows for client-side scripting languages other than Javascript, although they are used incredibly infrequently in practice). * Client-side scripts are also intriguing. If I think about what this means in practice, it's that the client is able to manipulate the state of objects in-world. Well, duh - that's what editing and appearance tools do! So... that capability (pun intended!) is a requirement at the protocol level, although I don't think we've even brushed on how to define it yet. It would be intriguing if the protocol were such that the client could expose a DOM-like view of the world to local scripts to observe and mutate. --00151773da30ba67d90476ed7d4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good analysis as usual, Morgaine!

On Mon,= Oct 26, 2009 at 10:15 PM, Morgaine <morgaine.dinova@googlemail.com> wrote:
Being pragmatic a= bout the situation, if we wish to see interop of scripting in the relativel= y near future, we need to find an approach that is inherently interoperable= .=C2=A0 Here are some ideas that might be relevant to this end (these are a= lternatives, they don't all apply simultaneously):

  1. Make script state transfer a deployment option:=C2=A0 both sour= ce and destination regions have to allow script state transfer for it to ha= ppen.
  2. Worlds running different scripting engine implementations do = not transfer state and hence scripts are initialized on teleport.
  3. Define a common scripting language and virtual machine environment --- = ie. a web-like Javascript approach but for regions.
  4. If script state= continuity is desired on teleports between worlds running different script= engines, let such scripts run client-side.

A few thoughts on the above:

* Even= though the Web appears to have given up on content negotiation over HTTP, = I'm still a fan and I think cross-system interop like this is a good pl= ace for it. During Region-to-Region state transfer, you could imagine the d= estination region advertising the script state types it accepts (vendor/com= .lindenlab.secondlife.lsl2mono, vendor/org.opensim.dotnetengine, ...), and = the source region delivering one tagged with appropriate type. I would imag= ine we'll need similar logic for static content as well - articles of c= lothing could have have "prim" or "mesh" based versions= , and regions may prefer one type to another. (Although it would be more li= kely to have both available on the region, and have content negotiation occ= ur on the region->viewer resource transfer.)

* Given the desire for "tourist" models (using the term loose= ly - I "live" on my home grid, but like to visit other grids), it= doesn't seem like there's a one-size-fits-all approach (since regi= on-to-region teleports in my home grid and region-to-region teleports betwe= en grids utilize the same protocol). So... this is definitely part of the p= rotocol's mandate to sort out.

* Combining the above two points, it implies that attachments will have= to cope with moving from areas where they have scripts running to scripts = not running (if the code/state is not compatible with the hosting region). = Fortunately, we have precedent for that. :)

* Infinity and I very briefly hand-waved about whether "portable&q= uot; content (primarily, attachments to avatars) should even be executed wi= thin the region domain. Perhaps they should be executing in the agent domai= n? That's a radical departure from how SL or OpenSim work today. (If yo= u squint your eyes and partition the current services, at least.) - at any = rate, today there is no script execution outside of a region. It's an i= ntriguing idea, but by no means complete - how such fine grained state migh= t be updated between domains, for example. Vehicles come to mind as another= case, and those have no clear "home base" for script execution. = I suspect this is not tractable for the first iteration of VWRAP, but I don= 't want to dismiss it.

* Your (3) (common scripting environment) is intriguing. Sun's Proj= ect Wonderland uses Java (obviously...) as the common format, and (vastly s= implifying) all objects in the VW are Java objects. I'd love to learn m= ore from them about the challenges and successes. That said, at a protocol = level, I don't think we'd ever dictate a common environment, so goi= ng down this road might turn into a de-facto common case of the content neg= otiation (just as the Web technically allows for client-side scripting lang= uages other than Javascript, although they are used incredibly infrequently= in practice).=C2=A0

* Client-side scripts are also intriguing. If I think about what this m= eans in practice, it's that the client is able to manipulate the state = of objects in-world. Well, duh - that's what editing and appearance too= ls do! So... that capability (pun intended!) is a requirement at the protoc= ol level, although I don't think we've even brushed on how to defin= e it yet. It would be intriguing if the protocol were such that the client = could expose a DOM-like view of the world to local scripts to observe and m= utate.

--00151773da30ba67d90476ed7d4a-- From vaughn.deluca@gmail.com Tue Oct 27 14:32:29 2009 Return-Path: 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 2CE6A3A69BB for ; Tue, 27 Oct 2009 14:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 kHocsKD7WclE for ; Tue, 27 Oct 2009 14:32:28 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id A0EB53A6950 for ; Tue, 27 Oct 2009 14:32:27 -0700 (PDT) Received: by bwz23 with SMTP id 23so205374bwz.29 for ; Tue, 27 Oct 2009 14:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TkD5pYkMgE8+r+1XEy0s22GGNGNNfij6sSwkLXgXIrc=; b=BjXa/EwPRDE9VMJjaQ3DQbHbdmnHs/tJTMj1l3YTqLEGGyZjO+1NHCev6JU+3rchkj IRWhvdMg05LQ31G9BM7cSQi6sKuD7Fqk6ZGHXjwLBf5YdwelwYDlzt/q31gL/kZy+Bsp 30XrLuIp+0WuefRxwTp3hvG6aUFDNlEzqOEWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f6C8H41n0BzuyMlH62fIRSsW82CFrog7GOug5/XvJXJjga51LlDkEgq+3w21RtHFuI o5q2OXQkuL5vyob5Nwlfb2ZUU+rEl/WnIXl9mazzuSpDOQhvHvLSjrfjiP6nVJP+T9zP CQweM+q0+UjVcA5+NrXWjV7tVWuX8KeTInyik= MIME-Version: 1.0 Received: by 10.204.154.131 with SMTP id o3mr9394797bkw.66.1256679159757; Tue, 27 Oct 2009 14:32:39 -0700 (PDT) In-Reply-To: <20091026220344.GA24111@alinoe.com> References: <20091025121547.GB7775@alinoe.com> <9b8a8de40910251530u273830a5k47bdd8927b7efc76@mail.gmail.com> <20091026150239.GA6496@alinoe.com> <9b8a8de40910261222q30780f0fp1c8f4fa38383ab5d@mail.gmail.com> <20091026220344.GA24111@alinoe.com> Date: Tue, 27 Oct 2009 22:32:39 +0100 Message-ID: <9b8a8de40910271432n7ce70496vffd4076614335303@mail.gmail.com> From: Vaughn Deluca To: Carlo Wood Content-Type: multipart/alternative; boundary=0015175cae66e9ff150476f16ae4 Cc: ogpx@ietf.org Subject: Re: [ogpx] My take on Teleports and protocol resilience X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 21:32:29 -0000 --0015175cae66e9ff150476f16ae4 Content-Type: text/plain; charset=ISO-8859-1 OK, you convinced me regarding the bandwith. We are talking very low frequency user generated changes, and a small amount of data is passed by reference. Should be no problem. I am still worried about the detour, but i have no argument, just a gut feeling :) I do not see the need to send the movement instructions via the AS. It will ony generate unneeded delays, and that info is not part of the avatar state anyhow. Why "even" movment? On Mon, Oct 26, 2009 at 11:03 PM, Carlo Wood wrote: > On Mon, Oct 26, 2009 at 08:22:26PM +0100, Vaughn Deluca wrote: > > Second, as i mentioned in my post i am not very concerned about the > storage > > space, but more about the *bandwidth*. In your proposal all changes pass > from > > viewer to AS to region instead of directly from viewer to region. No > matter how > > Nah, only the avatar state changes, which are really minimal... > The bulk, all traffic FROM the region TO the viewer can go directly > to the viewer for start (except avatar state change requests: > scripts changing the avatars animation - which is really minimal). > Also real data, like texture uploads will most likely go directly > to the simulator, but well... those are things that are not done > often: > > * changing animation > * changing attachments > * changing clothes > * movement (even!) > > the reason movement doesn't carry lots of data is simply because > it's generated by a few typed characters: human input. > > Each of those are small messages (sone UUID's) and with a low > frequency. > > In fact, I can't think of anything from viewer to simulator > that uses any significant bandwidth :/ > > Script state might be "significant", but 1) smaller than the > average texture, and 2) only needed when someone teleports. > Besides, scripts run on the simulator, not on the AS (although > I think HUD scripts should; but THOSE don't need their state > to be sent to the simulator). > > Non-avatar state data can just go directly to the simulator > anyway, thus. For example, local chat. > > -- > Carlo Wood > --0015175cae66e9ff150476f16ae4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
OK, you convinced me regarding the bandwith. We are talking very low f= requency user generated changes, and a small amount of data is passed by re= ference. Should be no problem.

I am still worried = about the detour, but =A0i have no argument, just a gut feeling =A0:)

I do not see the need to send the movement instructions= via the AS. It will ony generate unneeded delays, and that info is not par= t of the avatar state anyhow.
Why "even" movment?


On Mon, Oct 26, 2009 at 11:03= PM, Carlo Wood <c= arlo@alinoe.com> wrote:
On Mon, Oct 26, 2009 at 08:22:26PM +0100, Vaughn Deluca w= rote:
> Second, as i mentioned in my post i am not very concerned about the st= orage
> space, but more about the *bandwidth*. In your proposal all changes pa= ss from
> viewer to AS to region instead of directly from viewer to region. No m= atter how

Nah, only the avatar state changes, which are really minimal...
The bulk, all traffic FROM the region TO the viewer can go directly
to the viewer for start (except avatar state change requests:
scripts changing the avatars animation - which is really minimal).
Also real data, like texture uploads will most likely go directly
to the simulator, but well... those are things that are not done
often:

* changing animation
* changing attachments
* changing clothes
* movement (even!)

the reason movement doesn't carry lots of data is simply because
it's generated by a few typed characters: human input.

Each of those are small messages (sone UUID's) and with a low
frequency.

In fact, I can't think of anything from viewer to simulator
that uses any significant bandwidth :/

Script state might be "significant", but 1) smaller than the
average texture, and 2) only needed when someone teleports.
Besides, scripts run on the simulator, not on the AS (although
I think HUD scripts should; but THOSE don't need their state
to be sent to the simulator).

Non-avatar state data can just go directly to the simulator
anyway, thus. For example, local chat.

--
Carlo Wood <carlo@alinoe.com>

--0015175cae66e9ff150476f16ae4-- From carlo@alinoe.com Wed Oct 28 05:03:33 2009 Return-Path: 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 0CAD228C11B for ; Wed, 28 Oct 2009 05:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[AWL=1.074, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, SUBJECT_FUZZY_TION=0.156] 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 wE2J01DUmuKz for ; Wed, 28 Oct 2009 05:03:32 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id A61903A67DD for ; Wed, 28 Oct 2009 05:03:31 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091028120343.XII10721.viefep18-int.chello.at@edge05.upc.biz>; Wed, 28 Oct 2009 13:03:43 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id yC3f1c03y0FlQed05C3g2k; Wed, 28 Oct 2009 13:03:43 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1N37FL-0003Bj-Uh; Wed, 28 Oct 2009 13:03:23 +0100 Date: Wed, 28 Oct 2009 13:03:23 +0100 From: Carlo Wood To: Vaughn Deluca Message-ID: <20091028120323.GA9827@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ogpx@ietf.org Subject: [ogpx] State "Partitions" should be Abelian (was: My take on Teleports and protocol resilience) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 12:03:33 -0000 On Tue, Oct 27, 2009 at 10:32:39PM +0100, Vaughn Deluca wrote: > OK, you convinced me regarding the bandwith. We are talking very low frequency > user generated changes, and a small amount of data is passed by reference. > Should be no problem. > > I am still worried about the detour, but i have no argument, just a gut > feeling :) > > I do not see the need to send the movement instructions via the AS. It will ony > generate unneeded delays, and that info is not part of the avatar state anyhow. > Why "even" movment? I meant that even movement of the avatar is low bandwidth. But you're right that for teleportation it is not needed to use the AS as authority, because movements are location updates and that state is replaced during change of region. --- Note that, apart from the authority- and unidirectional- story, it is in general also important that state changes are ordered. If we expect messages that update state to be lost, then there two several ways to recover: 1) ask for a resent and queue "later" messages until the missing one is received. 2) send a full resync every time. 1 introduces possible lag, and in the case of extreme packetloss might even cause memory problems because the later messages have to be queued. 2 is only possible when the total state data is very small, but possible for example in the case of attachments. Abstract example: Consider a case where a state has three possible values: A, B or C; which are internally represented by 1, 2 and 3. Instead of sending only *changes*: +1, -1, +2, -1, -1, ... It makes much more sense to send "full updates": B, A, C, B, A, .. In both cases however it is necessary to include a sequence number if the messages can be received out of order. --- Thus, assuming that sending "full states" makes sense in most cases, we have to try to devide a state into uncorrelated parts. Example, suppose a state exists of a vector of uncorrelated data: { d1, d2, d3, d4, ... }, then instead of sending the whole vector when 'd3' changes, it suffices to only send the "full update" for 'd3'. The question is: what means uncorrelated here? In the light of synchronization (our main concern), I believe that it means that a commutating operator can be defined. That means, if two (or more) state-parts correlate but the net result is the same, independent of the order they are applied in, then we can treat them as "uncorrelated" in the light of the above, and send separate "full state changes" for each (or state updates if we wish, of course). Example: If the sum (f) of states a and b can be considered as a binary operator f(a, b), and f(a, b) = f(b, a) (commutative) then a and b can be treated as uncorrelated because their order (in which they are applied) doesn't matter. This is the case for animations of different priority (I believe, but I might be wrong), and for animations that act on a different part of the avatar. It is also the case for attachments of different attachment points. Hence, we can send "full updates" PER attachment point (just send "attachment point XYZ now contains attachment ABC"), and ignore all the other attachment points, BECAUSE the net result of such operations of all attachments points is order-insensitive. The reason I brought this up is because, in the past, I've been thinking about the implementation of multiple attachments on a single attachment point and from a (human) management point of view came to the conclusion that attach/detach operations for a single attachment point also have to commute. Meaning, if you attach X to point P, and then attach Y to point P, then the result must be the same as first attaching Y to point P and then X to point P. Now note that if that is the case, then you can consider the full set of attachments as a binary vector of zeroes and ones, one for each attachment (not point), and send "full updates" per bit. Basically you'd be saying: XYZ is now attached (plus sequence number) and XYZ is now detached, etc. So, in that case we have all the benefits :)... these ARE "full updates", but clearly they are also "state CHANGES" for the whole-state "attachments". Conclusion, we have to keep a close eye on the commutativity of operations and use it to dissect larger states into smaller parts and use that to our advantange. We have to be aware of the crucial part that commutativity plays, down to the lowest level of protocol and synchronization issues. -- Carlo Wood From carlo@alinoe.com Thu Oct 29 06:03:12 2009 Return-Path: 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 CC61E3A69BD for ; Thu, 29 Oct 2009 06:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.828 X-Spam-Level: X-Spam-Status: No, score=0.828 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, SUBJECT_FUZZY_TION=0.156] 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 7ZPcz5iyNOa6 for ; Thu, 29 Oct 2009 06:03:12 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id AFA883A67EC for ; Thu, 29 Oct 2009 06:03:11 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091029130324.MOYY10721.viefep18-int.chello.at@edge02.upc.biz> for ; Thu, 29 Oct 2009 14:03:24 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upc.biz with edge id yd3P1c01n0FlQed02d3Qia; Thu, 29 Oct 2009 14:03:24 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1N3Ued-0000d1-8w for ogpx@ietf.org; Thu, 29 Oct 2009 14:03:03 +0100 Date: Thu, 29 Oct 2009 14:03:03 +0100 From: Carlo Wood To: ogpx@ietf.org Message-ID: <20091029130303.GA2298@alinoe.com> References: <20091028120323.GA9827@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091028120323.GA9827@alinoe.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [ogpx] State "Partitions" should be Abelian (was: My take on Teleports and protocol resilience) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 13:03:12 -0000 On Wed, Oct 28, 2009 at 01:03:23PM +0100, Carlo Wood wrote: > If we expect messages that update state to be lost, then there > two several ways to recover: Excuse my English :p ... Obviously I meant "then there two ways..." While I value Vaughn's responses highly, I was hoping on eactions to my posts from others as well... Is it my English, making me look like a noob maybe? Or is it too trivial/technical? -- Carlo Wood From carlo@alinoe.com Thu Oct 29 06:44:02 2009 Return-Path: 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 73B203A697D for ; Thu, 29 Oct 2009 06:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.517 X-Spam-Level: X-Spam-Status: No, score=0.517 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_20=-0.74, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 D6SP4BkIxReE for ; Thu, 29 Oct 2009 06:44:01 -0700 (PDT) Received: from viefep13-int.chello.at (viefep13-int.chello.at [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id 451583A696B for ; Thu, 29 Oct 2009 06:44:01 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep13-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091029134416.UDAE16274.viefep13-int.chello.at@edge04.upc.biz>; Thu, 29 Oct 2009 14:44:16 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id ydkD1c01j0FlQed04dkEdN; Thu, 29 Oct 2009 14:44:16 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1N3VI9-00013W-AR; Thu, 29 Oct 2009 14:43:53 +0100 Date: Thu, 29 Oct 2009 14:43:53 +0100 From: Carlo Wood To: Vaughn Deluca Message-ID: <20091029134353.GB2298@alinoe.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <9b8a8de40910160635j268ef9c9mae55781221c94d7e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b8a8de40910160635j268ef9c9mae55781221c94d7e@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Infinity Linden \(Meadhbh Hamrick\)" , ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 13:44:02 -0000 On Fri, Oct 16, 2009 at 03:35:57PM +0200, Vaughn Deluca wrote: > Especially since there is nothing to prevent a configuration that works exactly > as the current SL use case. So nothing has to be sacrificed, yet a much richer > set of deployment patterns becomes possible. > > -Vaughn +1 I think that as soon as a user runs into "sorry, can't do-- because we don't trust this or that service", they will be ANNOYED, and nothing else. As a result, people will find the path of least resistance where apparently two demands can be conflicting: 1) Being able to TP to that other destination 2) Being able to access ones inventory Personally I feel not very confident that the combination of both is going to work anywhere satisfactory given the intentions shown so far; therefore I think it will be very important to have the possibility of separate asset services. Suddenly I see a glimpse of light: why can't it be possible to run my OWN (personal!) inventory? Surely nobody is going to forbid me to put FULL-PERM stuff in it? And even more surely nobody is going to stop others from accessing my inventory when I use it (ie, to see my attachments; or to see what I just rezzed). I'd be very happy with my own personal inventory, even if on some worlds they only allow me to put 'full perm' stuff in it. At least I'll know what I can use everywhere: if I can put it in my inventory, I will have it at my disposal everywhere. Dream or not, this is definitely not going to happen if VWRAP demands that the asset service is part of the agent service. -- Carlo Wood From morgaine.dinova@googlemail.com Fri Oct 30 00:29:32 2009 Return-Path: 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 A790C3A694D for ; Fri, 30 Oct 2009 00:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 pBPkskufw7QD for ; Fri, 30 Oct 2009 00:29:31 -0700 (PDT) Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id A5A1F3A69D9 for ; Fri, 30 Oct 2009 00:29:30 -0700 (PDT) Received: by ewy5 with SMTP id 5so755252ewy.37 for ; Fri, 30 Oct 2009 00:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=RSVqnnUDUH9CZDJfXQ1Jtz29QGbcRWeD6zC/YeBSb3c=; b=Zdhn16IZuwZ+L5QkBAxGCp+5iGtuiN5HauY62TRaO5tbprGZruZULw7pAus7y40Arj GIcunEeuUDR4m6cougkSynjIAh6iZO2WckK8Mc37MemujE6JeIBRPFZggq32V5nJSpbR ay3KKih+h865g5Va89enhjidR9xZGMahyodWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=jNT7ZlFhgraFqPUlXAe/s01zHgPg/PXbIQ7nWoand2HmMlvD+YY8iWgzCzoelsD/Gl avXIAJ2NdlSEWIbaDuHJ+zIrx4sLsWcAwcUc2K9eKa25OZYh7sguKoZleF9QlX+QTLLe ps4y00kmDPSII0qbaTuPtfWlPNIUUrQO8Vq0o= MIME-Version: 1.0 Received: by 10.216.87.197 with SMTP id y47mr428884wee.202.1256887784336; Fri, 30 Oct 2009 00:29:44 -0700 (PDT) In-Reply-To: <20091029134353.GB2298@alinoe.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <9b8a8de40910160635j268ef9c9mae55781221c94d7e@mail.gmail.com> <20091029134353.GB2298@alinoe.com> Date: Fri, 30 Oct 2009 07:29:44 +0000 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016e6d63ffbe86d11047721fd77 Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 07:29:32 -0000 --0016e6d63ffbe86d11047721fd77 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 29, 2009 at 1:43 PM, Carlo Wood wrote: > > As a result, people will find the path of least resistance where apparently > two demands can be conflicting: > > 1) Being able to TP to that other destination > 2) Being able to access ones inventory > > Personally I feel not very confident that the combination of both is > going to work anywhere satisfactory given the intentions shown so far; > therefore I think it will be very important to have the possibility of > separate asset services. > Very true. This is of course why we headed down the path of giving RDs control over their own region policies, reinforced by David's observation that ADs could not impose non-local policies even if they wished. ADs won't exercise control over region policies anyway but stick to agent policies alone, according to previous discussions, so the assets present in a region are of no concern to the AD at all. This directly implies that asset services must be quite separate from ADs. Although we haven't spelled it out, clients must have access to an arbitrary list of asset services, because as agents travel around the VWRAP-compatible metaverse, the regions they visit will contain objects from an arbitrary number of asset service providers. *Without access to these asset services, the visited regions would not be visualizable at all. And denying visualization is no business of the AD's. * This makes it clear that access to asset services should not be mediated by the AD at all --- the AD's role should be limited to allowing or denying entrance to a region. Once inside a region, it is the region that offers capabilities for access to the asset services of assets within the region. > > Suddenly I see a glimpse of light: why can't it be possible to run > my OWN (personal!) inventory? Surely nobody is going to forbid me to > put FULL-PERM stuff in it? And even more surely nobody is going to > stop others from accessing my inventory when I use it (ie, to see > my attachments; or to see what I just rezzed). > > I'd be very happy with my own personal inventory, even if on some > worlds they only allow me to put 'full perm' stuff in it. At least > I'll know what I can use everywhere: if I can put it in my inventory, > I will have it at my disposal everywhere. > I think it's quite clear that SL's single-world / single asset service / single inventory model is not appropriate to the needs of VWRAP. As you suggest, an agent's inventory needs have very little to do with the asset service of the single world in which the agent is registered. It's very difficult to extrapolate from that monolithic model to a multi-world setting. > > Dream or not, this is definitely not going to happen if VWRAP > demands that the asset service is part of the agent service. > Indeed, but fortunately it hasn't been proposed that asset services be part of the agent service in VWRAP. The legacy SL model of assets and inventories clearly doesn't apply in our extended scenarios, and the OGP documents never covered asset services at all, so we're defining the asset services and inventory model of VWRAP as we speak. :-) Morgaine. ====================================== On Thu, Oct 29, 2009 at 1:43 PM, Carlo Wood wrote: > On Fri, Oct 16, 2009 at 03:35:57PM +0200, Vaughn Deluca wrote: > > Especially since there is nothing to prevent a configuration that works > exactly > > as the current SL use case. So nothing has to be sacrificed, yet a much > richer > > set of deployment patterns becomes possible. > > > > -Vaughn > > +1 > > > I think that as soon as a user runs into "sorry, can't do-- because we > don't > trust this or that service", they will be ANNOYED, and nothing else. > > As a result, people will find the path of least resistance where apparently > two demands can be conflicting: > > 1) Being able to TP to that other destination > 2) Being able to access ones inventory > > Personally I feel not very confident that the combination of both is > going to work anywhere satisfactory given the intentions shown so far; > therefore I think it will be very important to have the possibility of > separate asset services. > > Suddenly I see a glimpse of light: why can't it be possible to run > my OWN (personal!) inventory? Surely nobody is going to forbid me to > put FULL-PERM stuff in it? And even more surely nobody is going to > stop others from accessing my inventory when I use it (ie, to see > my attachments; or to see what I just rezzed). > > I'd be very happy with my own personal inventory, even if on some > worlds they only allow me to put 'full perm' stuff in it. At least > I'll know what I can use everywhere: if I can put it in my inventory, > I will have it at my disposal everywhere. > > Dream or not, this is definitely not going to happen if VWRAP > demands that the asset service is part of the agent service. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0016e6d63ffbe86d11047721fd77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 29, 2009 at 1:43 PM, Carlo Wood <carlo@alinoe.com> wrote:

As a result, people will find the path of least resistance where apparently=
two demands can be conflicting:

1) Being able to TP to that other destination
2) Being able to access ones inventory

Personally I feel not very confident that the combination of both is
going to work anywhere satisfactory given the intentions shown so far;
therefore I think it will be very important to have the possibility of
separate asset services.


Very true.=A0 T= his is of course why we headed down the path of giving RDs control over the= ir own region policies, reinforced by David's observation that ADs coul= d not impose non-local policies even if they wished.=A0 ADs won't exerc= ise control over region policies anyway but stick to agent policies alone, = according to previous discussions, so the assets present in a region are of= no concern to the AD at all.

This directly implies that asset services must be quite separate from A= Ds.=A0 Although we haven't spelled it out, clients must have access to = an arbitrary list of asset services, because as agents travel around the VW= RAP-compatible metaverse, the regions they visit will contain objects from = an arbitrary number of asset service providers.

Without access to these asset services, the visited regions would= not be visualizable at all.=A0 And denying visualization is no business of= the AD's.=A0 This makes it clear that access to asset services= should not be mediated by the AD at all --- the AD's role should be li= mited to allowing or denying entrance to a region.=A0 Once inside a region,= it is the region that offers capabilities for access to the asset services= of assets within the region.
=A0

Suddenly I see a glimpse of light: why can't it be possible to run
my OWN (personal!) inventory? Surely nobody is going to forbid me to
put FULL-PERM stuff in it? And even more surely nobody is going to
stop others from accessing my inventory when I use it (ie, to see
my attachments; or to see what I just rezzed).

I'd be very happy with my own personal inventory, even if on some
worlds they only allow me to put 'full perm' stuff in it. At least<= br> I'll know what I can use everywhere: if I can put it in my inventory, I will have it at my disposal everywhere.

I think it's quite clear that SL's single-world / single asset se= rvice / single inventory model is not appropriate to the needs of VWRAP.=A0= As you suggest, an agent's inventory needs have very little to do with= the asset service of the single world in which the agent is registered.=A0= It's very difficult to extrapolate from that monolithic model to a mul= ti-world setting.
=A0

Dream or not, this is definitely not going to happen if VWRAP
demands that the asset service is part of the agent service.


Indeed, but fortunately it hasn't been proposed th= at asset services be part of the agent service in VWRAP.=A0 The legacy SL m= odel of assets and inventories clearly doesn't apply in our extended sc= enarios, and the OGP documents never covered asset services at all, so we&#= 39;re defining the asset services and inventory model of VWRAP as we speak.= :-)


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

On Thu, Oct 29, 2009 at 1:43 PM, Carl= o Wood <carlo@alin= oe.com> wrote:
On Fri, Oct 16, 2009 at 03:35:57PM +0200, Vaughn Deluca wrote:
> Especially since there is nothing to prevent a configuration that work= s exactly
> as the current SL use case. So nothing =A0has to be sacrificed, yet a = much richer
> set of deployment patterns becomes possible.
>
> -Vaughn

+1


I think that as soon as a user runs into "sorry, can't do-- becaus= e we don't
trust this or that service", they will be ANNOYED, and nothing else.
As a result, people will find the path of least resistance where apparently=
two demands can be conflicting:

1) Being able to TP to that other destination
2) Being able to access ones inventory

Personally I feel not very confident that the combination of both is
going to work anywhere satisfactory given the intentions shown so far;
therefore I think it will be very important to have the possibility of
separate asset services.

Suddenly I see a glimpse of light: why can't it be possible to run
my OWN (personal!) inventory? Surely nobody is going to forbid me to
put FULL-PERM stuff in it? And even more surely nobody is going to
stop others from accessing my inventory when I use it (ie, to see
my attachments; or to see what I just rezzed).

I'd be very happy with my own personal inventory, even if on some
worlds they only allow me to put 'full perm' stuff in it. At least<= br> I'll know what I can use everywhere: if I can put it in my inventory, I will have it at my disposal everywhere.

Dream or not, this is definitely not going to happen if VWRAP
demands that the asset service is part of the agent service.

--
Carlo Wood <carlo@alinoe.com>=
__________________________________= _____________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--0016e6d63ffbe86d11047721fd77-- From vaughn.deluca@gmail.com Fri Oct 30 04:56:04 2009 Return-Path: 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 77CDF28B797 for ; Fri, 30 Oct 2009 04:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, SUBJECT_FUZZY_TION=0.156] 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 Wy1P9ivtNxXH for ; Fri, 30 Oct 2009 04:56:03 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 588753A68A5 for ; Fri, 30 Oct 2009 04:56:01 -0700 (PDT) Received: by bwz23 with SMTP id 23so3483552bwz.29 for ; Fri, 30 Oct 2009 04:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DQErnJWS2ZQZb4/UqVN6IIoXpxiXHz8ezde3XyV6rVA=; b=PST8th+Vsxd20JBuCqmAsYBdBW144Xges6fCz90rnkBs+ja5jppoo2GcyaifOCBB4N nlAVqArohiugwzTOs1UW6Ux5vvGTA+ihyRvsp+PXGnZADFSRzRudDgjacyshnmDwKs8k NSsZqsuF4s1leCRnfbkoWY0IcS5BHy5TBZtiE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xZjujS5hi08KP0+3i15+R5tD+msoz51BHN51XGNKBDqLSbZ43pPr9iDf/LGgSH2qpD y1WB4QRYYHRxQuhaJ/ulihcN0gh9fkFBPwNNdqXmyQRXvN7xerX0BB98peNEar23LNCD qxD5BelcsnrR5+k5PqLOL0JP3rQf/Z40+HHXQ= MIME-Version: 1.0 Received: by 10.204.154.69 with SMTP id n5mr1073449bkw.43.1256903774953; Fri, 30 Oct 2009 04:56:14 -0700 (PDT) In-Reply-To: <20091029130303.GA2298@alinoe.com> References: <20091028120323.GA9827@alinoe.com> <20091029130303.GA2298@alinoe.com> Date: Fri, 30 Oct 2009 12:56:14 +0100 Message-ID: <9b8a8de40910300456s62ff44ana481e676af6e2a72@mail.gmail.com> From: Vaughn Deluca To: Carlo Wood Content-Type: multipart/alternative; boundary=0015175cfbca05e015047725b7a0 Cc: ogpx@ietf.org Subject: Re: [ogpx] State "Partitions" should be Abelian (was: My take on Teleports and protocol resilience) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 11:56:04 -0000 --0015175cfbca05e015047725b7a0 Content-Type: text/plain; charset=ISO-8859-1 Nothing wrong with your writing, it is just hard to discuss *anything* without underlaying documents. What we need are new versions of the drafts. -Vaughn On Thu, Oct 29, 2009 at 2:03 PM, Carlo Wood wrote: > On Wed, Oct 28, 2009 at 01:03:23PM +0100, Carlo Wood wrote: > > If we expect messages that update state to be lost, then there > > two several ways to recover: > > Excuse my English :p ... Obviously I meant "then there two ways..." > > While I value Vaughn's responses highly, I was hoping on > eactions to my posts from others as well... Is it my English, > making me look like a noob maybe? Or is it too trivial/technical? > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0015175cfbca05e015047725b7a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nothing wrong with your writing, it is just hard to discuss *anything* with= out underlaying documents. What we need are new versions of the drafts.
-Vaughn

On Thu, Oct 29, 2= 009 at 2:03 PM, Carlo Wood <carlo@alinoe.com> wrote:
On Wed, Oct 28, 2009 at 0= 1:03:23PM +0100, Carlo Wood wrote:
> If we expect messages that update state to be lost, then there
> two several ways to recover:

Excuse my English :p ... Obviously I meant "then there two ways.= .."

While I value Vaughn's responses highly, I was hoping on
eactions to my posts from others as well... Is it my English,
making me look like a noob maybe? Or is it too trivial/technical?

--
Carlo Wood <carlo@alinoe.com>=
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--0015175cfbca05e015047725b7a0-- From meadhbh.siobhan@gmail.com Fri Oct 30 07:42:29 2009 Return-Path: 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 43B7A3A69DF for ; Fri, 30 Oct 2009 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] 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 z8+jPgbjDp4d for ; Fri, 30 Oct 2009 07:42:28 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 72B683A69B9 for ; Fri, 30 Oct 2009 07:42:28 -0700 (PDT) Received: by pxi1 with SMTP id 1so2037732pxi.32 for ; Fri, 30 Oct 2009 07:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EpH20JJ/Cc9LYRvsIuf1Jtci7wRQFeWR79Keui75x5M=; b=pkmsxXbnTvKkoOY+q2xSFdBXHLLHfGjal2O7/WfNB9R1NZb763exQ07giVdI5XmPRs VD20lS6kaiH7Z1/n2xf1RSwzVcxHhYx4gpoqqEGGpE6OIukuCRxYFYx8Px0PKtemJCRP 5aWs5JZDmqNPJ7TpualEp4MMiww9IdBWpMtBk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JDBpK2ZwFTvQaTQ/1ld0S4l8nSrNpMhSyO6YS5zTXuUxBI2nuYkXTojUy39bktiRrF qDy/M7I2fXJJ+vsKNgRl5H/WSits14XtBue8tRJL+AefRYsrTM5beWHFhdqVg+ocyPqv I9RI4FV5yJQxgqPNU6pGDWG/LxnOxTe7ACGBg= MIME-Version: 1.0 Received: by 10.115.37.37 with SMTP id p37mr1332346waj.11.1256913762771; Fri, 30 Oct 2009 07:42:42 -0700 (PDT) In-Reply-To: <9b8a8de40910300456s62ff44ana481e676af6e2a72@mail.gmail.com> References: <20091028120323.GA9827@alinoe.com> <20091029130303.GA2298@alinoe.com> <9b8a8de40910300456s62ff44ana481e676af6e2a72@mail.gmail.com> Date: Fri, 30 Oct 2009 07:42:42 -0700 Message-ID: From: Meadhbh Hamrick To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Cc: ogpx@ietf.org Subject: Re: [ogpx] State "Partitions" should be Abelian (was: My take on Teleports and protocol resilience) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 14:42:29 -0000 actually, the documents are being written to reflect the discussion here. but i guess what i'm hearing is that you would prefer to see how all the ideas we're presenting line up in a single document. okay. lemme get on that. -cheers -meadhbh On Fri, Oct 30, 2009 at 4:56 AM, Vaughn Deluca wrote: > Nothing wrong with your writing, it is just hard to discuss *anything* > without underlaying documents. What we need are new versions of the drafts. > -Vaughn > > On Thu, Oct 29, 2009 at 2:03 PM, Carlo Wood wrote: >> >> On Wed, Oct 28, 2009 at 01:03:23PM +0100, Carlo Wood wrote: >> > If we expect messages that update state to be lost, then there >> > two several ways to recover: >> >> Excuse my English :p ... Obviously I meant "then there two ways..." >> >> While I value Vaughn's responses highly, I was hoping on >> eactions to my posts from others as well... Is it my English, >> making me look like a noob maybe? Or is it too trivial/technical? >> >> -- >> Carlo Wood >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From josh@lindenlab.com Fri Oct 30 10:23:31 2009 Return-Path: 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 52D863A6836 for ; Fri, 30 Oct 2009 10:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 aMWN3-zw4Bwl for ; Fri, 30 Oct 2009 10:23:30 -0700 (PDT) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id 06C2B3A67BD for ; Fri, 30 Oct 2009 10:23:29 -0700 (PDT) Received: by iwn40 with SMTP id 40so2541141iwn.32 for ; Fri, 30 Oct 2009 10:23:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.28.143 with SMTP id m15mr5386083ibc.23.1256923423838; Fri, 30 Oct 2009 10:23:43 -0700 (PDT) In-Reply-To: References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <9b8a8de40910160635j268ef9c9mae55781221c94d7e@mail.gmail.com> <20091029134353.GB2298@alinoe.com> Date: Fri, 30 Oct 2009 10:23:43 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00151774126c3011e304772a4a60 Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 17:23:31 -0000 --00151774126c3011e304772a4a60 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 30, 2009 at 12:29 AM, Morgaine wrote: > > This directly implies that asset services must be quite separate from ADs. > Although we haven't spelled it out, clients must have access to an arbitrary > list of asset services, because as agents travel around the VWRAP-compatible > metaverse, the regions they visit will contain objects from an arbitrary > number of asset service providers. > > *Without access to these asset services, the visited regions would not be > visualizable at all. And denying visualization is no business of the AD's. > * This makes it clear that access to asset services should not be > mediated by the AD at all --- the AD's role should be limited to allowing or > denying entrance to a region. Once inside a region, it is the region that > offers capabilities for access to the asset services of assets within the > region. > After reading this a few times, I agree with the high level sentiment - but be careful regarding the terminology, as specific wording tripped me up the first few times through. In the SL protocol today, clients only ever communicate with a region. It's the region's responsibility to provide the data for what the agent sees. This occurs both for items that would be considered aspects of the region (chairs, buildings, trees, waterfalls) and "transient" items (other avatars with attachments). The region exposes a data source (today, the byte-efficient but fairly grotesque family of UDP packets) of the description of objects (prims, textures, sourds, animations, ...) which the client consumes. Behind the scenes, the region may be pulling those object definitions from an asset service, or they may be present in the region definition itself. The client is unaware of this - it's hidden behind the services the region exposes. Now for the terminology bit: we can call the services the region is exposing "asset services" but these could be quite distinct from the sorts of things present in an agent's inventory. One phrase that's potentially confusing is "the regions they visit will contain objects from an arbitrary number of asset service providers" - while I agree with the high-level interpretation of that statement, I think it paints a picture that as you're exploring a region, the client is *necessarily* going off and making connections to a variety of asset servers to fetch the data. I don't think VWRAP should *preclude* that (I imagine it's only sensible for things like textures to be referenced by URLs which could be coming off of any old place), but my initial reading of your text was that the client would necessarily be fetching things from external asset services. For example, if I buy a chair on FooGrid and drop it on BarGrid, when you visit BarGrid you're having to ask FooGrid's asset service for the description. Again, I think that's *conceivable*, but shouldn't be *necessary*. (And I don't think you're claiming that - but my first read-through came away with that impression.) And, of course, one can conceive of clients that implement a policy of not trusting FooGrid for anything and wouldn't make such a connection - FooGrid could be blacklisted by some large search company, my ISP, or perhaps my AD. Indeed, but fortunately it hasn't been proposed that asset services be part > of the agent service in VWRAP. The legacy SL model of assets and > inventories clearly doesn't apply in our extended scenarios, and the OGP > documents never covered asset services at all, so we're defining the asset > services and inventory model of VWRAP as we speak. :-) > Be careful about blurring the use of "asset services" between "stuff in regions" and "stuff I have". I think there is a big intersection - and may have the same characteristics and/or protocols, but I also think they are are distinct. I would guess that there will be asset services associated with both agents and regions - off the top of my head: Uses of an agent-associated "asset" service: * content to client app (inspect your inventory) * content from client app (upload/import to inventory) * content to region (rez something) * content from region (buy/take something) * content to agent (give something) * content from agent (receive something) Uses of an region-associated "asset" service: * content to client app (see the world) * content from client app (upload/import to region) * content to region (during teleport/region crossing) * content from region (during teleport/region crossing) * content to agent (buy/take something) * content from agent (rez something) I'm using "asset" in quotes since that term may be overloaded. "Content" might be a better term. --00151774126c3011e304772a4a60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 30, 2009 at 12:29 AM, Morgaine <morgaine= .dinova@googlemail.com> wrote:

This directly implies that asset services must be quite separate f= rom ADs.=C2=A0 Although we haven't spelled it out, clients must have ac= cess to an arbitrary list of asset services, because as agents travel aroun= d the VWRAP-compatible metaverse, the regions they visit will contain objec= ts from an arbitrary number of asset service providers.

Without access to these asset services, the visited regions would= not be visualizable at all.=C2=A0 And denying visualization is no business= of the AD's.=C2=A0 This makes it clear that access to asset se= rvices should not be mediated by the AD at all --- the AD's role should= be limited to allowing or denying entrance to a region.=C2=A0 Once inside = a region, it is the region that offers capabilities for access to the asset= services of assets within the region.

After reading this a few times, I agree with th= e high level sentiment - but be careful regarding the terminology, as speci= fic wording tripped me up the first few times through.

In the SL pro= tocol today, clients only ever communicate with a region. It's the region's responsibility to provide the data for what the a= gent sees. This occurs both for items that would be considered aspects of the region (chairs, buildings, trees, waterfalls) and "transient"= items (other avatars with attachments). The region exposes a data source (today, the byte-efficient but fairly grotesque family of UDP packets) of the description of objects (prims, textures, sourds, animations, ...) which the client consumes.

Behind the scenes, the region may be pulling those object definitions from an asset service, or they may be present in the region definition itself. The client is unaware of this - it's hidden behind the services the region exposes.

Now for the terminology bit: we can call the services the region is exp= osing "asset services" but these could be quite distinct from the= sorts of things present in an agent's inventory. One phrase that's= potentially confusing is "the regions they visit will contain objects= from an arbitrary number of asset service providers" - while I agree = with the high-level interpretation of that statement, I think it paints a p= icture that as you're exploring a region, the client is *necessarily* g= oing off and making connections to a variety of asset servers to fetch the = data.

I don't think VWRAP should *preclude* that (I imagine it's only= sensible for things like textures to be referenced by URLs which could be = coming off of any old place), but my initial reading of your text was that = the client would necessarily be fetching things from external asset service= s. For example, if I buy a chair on FooGrid and drop it on BarGrid, when yo= u visit BarGrid you're having to ask FooGrid's asset service for th= e description. Again, I think that's *conceivable*, but shouldn't b= e *necessary*. (And I don't think you're claiming that - but my fir= st read-through came away with that impression.)

And, of course, one can conceive of clients that implement a policy of = not trusting FooGrid for anything and wouldn't make such a connection -= FooGrid could be blacklisted by some large search company, my ISP, or perh= aps my AD.

Indeed, but fortunately it hasn't been proposed that a= sset services be part of the agent service in VWRAP.=C2=A0 The legacy SL mo= del of assets and inventories clearly doesn't apply in our extended sce= narios, and the OGP documents never covered asset services at all, so we= 9;re defining the asset services and inventory model of VWRAP as we speak. = :-)

Be careful about blurring the use of "asset ser= vices" between "stuff in regions" and "stuff I have&quo= t;. I think there is a big intersection - and may have the same characteris= tics and/or protocols, but I also think they are are distinct. I would gues= s that there will be asset services associated with both agents and regions= - off the top of my head:

Uses of an agent-associated "asset" service:
* content to= client app (inspect your inventory)
* content from client app (upload/i= mport to inventory)
* content to region (rez something)
* content fro= m region (buy/take something)
* content to agent (give something)
* content from agent (receive someth= ing)

Uses of an region-associated "asset" service:
* c= ontent to client app (see the world)
* content from client app (upload/import to region)
* content to region = (during teleport/region crossing)
* content from region (during teleport= /region crossing)
* content to agent (buy/take something)
* content from agent (rez something)

I'm using "asset" in quotes since that term may be overlo= aded. "Content" might be a better term.



--00151774126c3011e304772a4a60-- From infinity@lindenlab.com Fri Oct 30 10:33:12 2009 Return-Path: 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 363153A684E for ; Fri, 30 Oct 2009 10:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 qGAxlRyTchTN for ; Fri, 30 Oct 2009 10:33:11 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 0DAEE3A6768 for ; Fri, 30 Oct 2009 10:33:10 -0700 (PDT) Received: by bwz23 with SMTP id 23so3847767bwz.29 for ; Fri, 30 Oct 2009 10:33:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.144.101 with SMTP id n37mr194191hba.182.1256924004364; Fri, 30 Oct 2009 10:33:24 -0700 (PDT) In-Reply-To: <9b8a8de40910171613g33d7c8d3v95e221df99abd1f2@mail.gmail.com> References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <4AD894BE.30501@uci.edu> <9b8a8de40910161546h9e54dcah59cb423a0ac096af@mail.gmail.com> <9b8a8de40910171613g33d7c8d3v95e221df99abd1f2@mail.gmail.com> From: "Infinity Linden (Meadhbh Hamrick)" Date: Fri, 30 Oct 2009 10:33:04 -0700 Message-ID: <3a880e2c0910301033x31506d33pfb2e47b386ed1a72@mail.gmail.com> To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Suzy Deffeyes , "ogpx@ietf.org" Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 17:33:12 -0000 though.. should probably point out. that code implements the OGP auth spec from early summer '08, not the one that was published earlier this year. however... they are pretty similar. -- infinity linden (aka meadhbh hamrick) * it's pronounced "maeve" http://wiki.secondlife.com/wiki/User:Infinity_Linden On Sat, Oct 17, 2009 at 16:13, Vaughn Deluca wrot= e: > On Sat, Oct 17, 2009 at 3:32 AM, Suzy Deffeyes wrote: >> >> We open sourced an implementation of agent domain recently. >> =A0http://forge.opensimulator.org/gf/project/ogp/ >> >> Also note that OGP functionality is included in the snowglobe viewer. It >> was recently added as jira SNOW-215. >> >> Lastly, these two implementation tidbits have started adding extensions = to >> the original OGP spec in the area of inventory and wearables. > > Great! =A0*starts reading code* >> >> Suzy Deffeyes >> Pixel Gausman >> IBM > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From morgaine.dinova@googlemail.com Sat Oct 31 06:52:57 2009 Return-Path: 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 01BE93A67F0 for ; Sat, 31 Oct 2009 06:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 Aa7EYR8mGl5P for ; Sat, 31 Oct 2009 06:52:54 -0700 (PDT) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id 3C1A63A6814 for ; Sat, 31 Oct 2009 06:52:52 -0700 (PDT) Received: by ewy18 with SMTP id 18so3416594ewy.43 for ; Sat, 31 Oct 2009 06:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=D8IQeg4JABHSphpEqPAcTJFOz0lGpIgvnj4CyZC09L4=; b=QVK0P/P7k6WGQxZChgNyACtyEq1YfKrlje09zAZ0lCxwNPlWl/5gW6pgcHwwGlzBgO JIJtusJx319oBJ4k6AbstV889XndZLCXfkGhg4oxGCX4Vx1pyCHfjTFuJnQzYjJiVD9T tkJIPP6B13hyKlT0uP6l2GFenOjNdiEJLVKrg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=rbk5nZc3m1xXFFwlT11K40XXM3ovX0xW2g/1H5FEo+QTRlP0tQigdO7BXCUt6Etc/g QR9koleEwYX27C58nvfEOV96QO3IvTDeBdxPQhTPDxWU8UV02H/K+6nmF229/4ThYu3z QTe3OTFbGw+24LyMFA+YLc3Dk2j471F4ZSyQY= MIME-Version: 1.0 Received: by 10.216.88.21 with SMTP id z21mr1654595wee.60.1256997187814; Sat, 31 Oct 2009 06:53:07 -0700 (PDT) In-Reply-To: References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g7a7e488fpe03b10d9b534aa35@mail.gmail.com> <9b8a8de40910160635j268ef9c9mae55781221c94d7e@mail.gmail.com> <20091029134353.GB2298@alinoe.com> Date: Sat, 31 Oct 2009 13:53:07 +0000 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016e6d9677edd0f2704773b76d9 Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 13:52:57 -0000 --0016e6d9677edd0f2704773b76d9 Content-Type: text/plain; charset=ISO-8859-1 Great post Joshua, leading to many key issues! On Fri, Oct 30, 2009 at 5:23 PM, Joshua Bell wrote: > On Fri, Oct 30, 2009 at 12:29 AM, Morgaine > wrote: > >> >> This directly implies that asset services must be quite separate from >> ADs. Although we haven't spelled it out, clients must have access to an >> arbitrary list of asset services, because as agents travel around the >> VWRAP-compatible metaverse, the regions they visit will contain objects from >> an arbitrary number of asset service providers. >> >> *Without access to these asset services, the visited regions would not be >> visualizable at all. And denying visualization is no business of the AD's. >> * This makes it clear that access to asset services should not be >> mediated by the AD at all --- the AD's role should be limited to allowing or >> denying entrance to a region. Once inside a region, it is the region that >> offers capabilities for access to the asset services of assets within the >> region. >> > > After reading this a few times, I agree with the high level sentiment - but > be careful regarding the terminology, as specific wording tripped me up the > first few times through. > My writing style tends to be preoccupied with precision, and readability can suffer, sorry. ;-) I did however mean exactly what I wrote, and I chose the term *mediate*deliberately for its breadth of coverage, because I wanted to convey strongly that the AD should have nothing whatsoever to do with allowing or denying access to *specific* asset services relevant to a region, directly or indirectly, in any manner at all other than by permitting entry in the first place. This may seem like major anathema from a centrally-controlled, single asset service perspective. However, it falls out naturally when you consider: - David's point about no AD policy control over remote services, - Carlo's point about users having control over their own inventory, - the quite widespread support for an agent/region split in policy controls, - John's support for strongly decoupled asset services as in Cable Beach, - my point about not breaking region visualization once in a region. All of these points shout loudly that considering assets and inventory to be part of the agent service is badly structured because it creates unnecessary constraints. It seem far more appropriate to consider asset services as independent, so that whoever needs them can gain access to them if the services permit it. (This doesn't imply a free-for-all, to be clear, but only that there should be no *a priori* barriers *by design*, such as would occur if ADs were given exclusive power to grant caps for all asset services.) Instead, if an AD provides an inventory service (a policy choice), then this is just one contributor to the client's inventory. [*I'll cover this explicitly further below.*] In the SL protocol today, clients only ever communicate with a region. It's > the region's responsibility to provide the data for what the agent sees. > This occurs both for items that would be considered aspects of the region > (chairs, buildings, trees, waterfalls) and "transient" items (other avatars > with attachments). The region exposes a data source (today, the > byte-efficient but fairly grotesque family of UDP packets) of the > description of objects (prims, textures, sourds, animations, ...) which the > client consumes. > > Behind the scenes, the region may be pulling those object definitions from > an asset service, or they may be present in the region definition itself. > The client is unaware of this - it's hidden behind the services the region > exposes. > That's fine. :-) Right from the earliest days of the AWG, it has many times been said that the proxying performed by SL sims is merely a design choice or implementation detail, and that other implementations of the same protocols could choose to proxy fewer services, or none at all. This is actually a very important issue for the protocol, because proxying has a major impact on the scalability and availability of a sim, and also on the scalability and availability of any services that it proxies, so flexibility of choice is crucial. If services are decoupled then such flexibility can be achieved with nothing more than appropriate configuration of service endpoint locations to permit the whole gamut of proxying choices to be expressed, including no proxying. And REST was chosen among other reasons for its flexibility in allocation of endpoints, so we already have the means to do this. :-) > Now for the terminology bit: we can call the services the region is > exposing "asset services" but these could be quite distinct from the sorts > of things present in an agent's inventory. One phrase that's potentially > confusing is "the regions they visit will contain objects from an arbitrary > number of asset service providers" - while I agree with the high-level > interpretation of that statement, I think it paints a picture that as you're > exploring a region, the client is *necessarily* going off and making > connections to a variety of asset servers to fetch the data. > > I don't think VWRAP should *preclude* that (I imagine it's only sensible > for things like textures to be referenced by URLs which could be coming off > of any old place), but my initial reading of your text was that the client > would necessarily be fetching things from external asset services. For > example, if I buy a chair on FooGrid and drop it on BarGrid, when you visit > BarGrid you're having to ask FooGrid's asset service for the description. > Again, I think that's *conceivable*, but shouldn't be *necessary*. (And I > don't think you're claiming that - but my first read-through came away with > that impression.) > I certainly agree on the principle of deployment choice! :-) We periodically tell each other that we're interested in defining only mechanisms, not policies, but this is implied all the time, I hope. The principle is so clear and uncontested that it's widely seen as universal in IETF protocol work, although the latter is my own personal reading of it. For us here it means that nothing important is precluded, and that a given provider may choose not to implement or configure a given feature or facility, yet the mechanism that we provide should allow it. In the current case, it means that service proxying must be a deployment choice, neither required nor precluded by the protocol. Perhaps I should explain further the phrase that gave you trouble above. I was trying to indicate that once an agent is in a region, denying the user the ability to visualize the world around her would be a very bad idea, as it would break the intended perceptual mashup. "Breaking the perceived world" is such a poor idea on many fronts that nobody has proposed it as far as I know, and if we have a legacy design that may be interpreted as suggesting exactly this then it should raise immediate red flags with us. (I'm not saying that it does.) The original OGP idea was almost always described with the AD as sole provider of seed caps, but the caps concept is of course not actually limited in this regard, and I've been working towards a flexible interpretation. In my preferred interpretation stemming from our discussions about tourism, it *includes* the semantic that *the AD can provide cap access to other sources of seed caps*. It is through this mechanism that we would implement the variously described key concept of "*separation of agent and region policies*" or "*policies are local*" or "*no policy export*", and it is this that would allow us to support the DDP principle through which we achieve tourism in those VWRAP deployments where it is desired. I hope that this explains it better. Such choices are not precluded nor mandated -- the AD doesn't have to provide a cap to any given region or RD, that's a policy decision. But if it chooses to grant the cap for access to a particular region then that region's policies now apply within the region. It is then up to the region to grant the seed caps that give access to the assets that allow the region to be visualized, as one crucial operation. Here is is my design principle for a caps system that would meet multiple requirements: *Gaining access to resources via caps is akin to exploring a caps tree. Each inner node (region) provides a seed cap that gives access to any number of leaf nodes (asset services) and to any number of child nodes (other regions). What distinguishes the AD is that it's the root node of the tree. * Now I can fill in my earlier forward reference to how inventories should be structured: if the AD provides an inventory service (a policy choice), then the items in the inventory offered by the AD are the items delivered by the asset services linked at the leaf nodes of the AD's initial caps tree. Not only is this elegant and extensible through tree-structured design, but it also supports an unlimited set of policies and deployments without prescribing nor proscribing anything. > And, of course, one can conceive of clients that implement a policy of not > trusting FooGrid for anything and wouldn't make such a connection - FooGrid > could be blacklisted by some large search company, my ISP, or perhaps my AD. > Definitely. That's a policy choice, just don't grant the region cap! :-) > > Indeed, but fortunately it hasn't been proposed that asset services be part >> of the agent service in VWRAP. The legacy SL model of assets and >> inventories clearly doesn't apply in our extended scenarios, and the OGP >> documents never covered asset services at all, so we're defining the asset >> services and inventory model of VWRAP as we speak. :-) >> > > Be careful about blurring the use of "asset services" between "stuff in > regions" and "stuff I have". I think there is a big intersection - and may > have the same characteristics and/or protocols, but I also think they are > are distinct. I would guess that there will be asset services associated > with both agents and regions - off the top of my head: > > Uses of an agent-associated "asset" service: > * content to client app (inspect your inventory) > * content from client app (upload/import to inventory) > * content to region (rez something) > * content from region (buy/take something) > * content to agent (give something) > * content from agent (receive something) > > Uses of an region-associated "asset" service: > * content to client app (see the world) > * content from client app (upload/import to region) > * content to region (during teleport/region crossing) > * content from region (during teleport/region crossing) > * content to agent (buy/take something) > * content from agent (rez something) > > I'm using "asset" in quotes since that term may be overloaded. "Content" > might be a better term. This is a great analysis, which we hadn't approached previously. I think your list could be used directly to drive our use case analysis to be sure that we're covering all the bases. Note that at this stage I'm considering all resources to be accessible through caps, not only for symmetry and simplicity but because we haven't defined any other access mechanism yet, so my reference to "assets" was intended to apply to all "content" in the widest sense. This broad use of the word "asset" stems from our choice of phrase "asset service" --- if we don't use the broad meaning then we're precluding storage of data such as objects and terrain on asset services, which would be a bad idea as we'd have to invent yet another type of storage service. I think this hints at the problem caused by using SL-defined terms in our wider setting. Perhaps we should spend a week revising the terminology that applies to VWRAP. (We did this at the start of AWG to create an AWG Glossary, and it was very illuminating.) Morgaine. ============================================= On Fri, Oct 30, 2009 at 5:23 PM, Joshua Bell wrote: > On Fri, Oct 30, 2009 at 12:29 AM, Morgaine > wrote: > >> >> This directly implies that asset services must be quite separate from >> ADs. Although we haven't spelled it out, clients must have access to an >> arbitrary list of asset services, because as agents travel around the >> VWRAP-compatible metaverse, the regions they visit will contain objects from >> an arbitrary number of asset service providers. >> >> *Without access to these asset services, the visited regions would not be >> visualizable at all. And denying visualization is no business of the AD's. >> * This makes it clear that access to asset services should not be >> mediated by the AD at all --- the AD's role should be limited to allowing or >> denying entrance to a region. Once inside a region, it is the region that >> offers capabilities for access to the asset services of assets within the >> region. >> > > After reading this a few times, I agree with the high level sentiment - but > be careful regarding the terminology, as specific wording tripped me up the > first few times through. > > In the SL protocol today, clients only ever communicate with a region. It's > the region's responsibility to provide the data for what the agent sees. > This occurs both for items that would be considered aspects of the region > (chairs, buildings, trees, waterfalls) and "transient" items (other avatars > with attachments). The region exposes a data source (today, the > byte-efficient but fairly grotesque family of UDP packets) of the > description of objects (prims, textures, sourds, animations, ...) which the > client consumes. > > Behind the scenes, the region may be pulling those object definitions from > an asset service, or they may be present in the region definition itself. > The client is unaware of this - it's hidden behind the services the region > exposes. > > Now for the terminology bit: we can call the services the region is > exposing "asset services" but these could be quite distinct from the sorts > of things present in an agent's inventory. One phrase that's potentially > confusing is "the regions they visit will contain objects from an arbitrary > number of asset service providers" - while I agree with the high-level > interpretation of that statement, I think it paints a picture that as you're > exploring a region, the client is *necessarily* going off and making > connections to a variety of asset servers to fetch the data. > > I don't think VWRAP should *preclude* that (I imagine it's only sensible > for things like textures to be referenced by URLs which could be coming off > of any old place), but my initial reading of your text was that the client > would necessarily be fetching things from external asset services. For > example, if I buy a chair on FooGrid and drop it on BarGrid, when you visit > BarGrid you're having to ask FooGrid's asset service for the description. > Again, I think that's *conceivable*, but shouldn't be *necessary*. (And I > don't think you're claiming that - but my first read-through came away with > that impression.) > > And, of course, one can conceive of clients that implement a policy of not > trusting FooGrid for anything and wouldn't make such a connection - FooGrid > could be blacklisted by some large search company, my ISP, or perhaps my AD. > > > Indeed, but fortunately it hasn't been proposed that asset services be part >> of the agent service in VWRAP. The legacy SL model of assets and >> inventories clearly doesn't apply in our extended scenarios, and the OGP >> documents never covered asset services at all, so we're defining the asset >> services and inventory model of VWRAP as we speak. :-) >> > > Be careful about blurring the use of "asset services" between "stuff in > regions" and "stuff I have". I think there is a big intersection - and may > have the same characteristics and/or protocols, but I also think they are > are distinct. I would guess that there will be asset services associated > with both agents and regions - off the top of my head: > > Uses of an agent-associated "asset" service: > * content to client app (inspect your inventory) > * content from client app (upload/import to inventory) > * content to region (rez something) > * content from region (buy/take something) > * content to agent (give something) > * content from agent (receive something) > > Uses of an region-associated "asset" service: > * content to client app (see the world) > * content from client app (upload/import to region) > * content to region (during teleport/region crossing) > * content from region (during teleport/region crossing) > * content to agent (buy/take something) > * content from agent (rez something) > > I'm using "asset" in quotes since that term may be overloaded. "Content" > might be a better term. > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0016e6d9677edd0f2704773b76d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Great post Joshua, leading to many key issues!

On Fri, Oct 30, 2009 = at 5:23 PM, Joshua Bell <josh@lindenlab.com> wrote:
On Fri, Oct 30, 2009 at 12:29 = AM, Morgaine <morgaine.dinova@googlemail.com> w= rote:

This directly implies that asset serv= ices must be quite separate from ADs.=A0 Although we haven't spelled it out, clients must have access to an arbitrary list of asset services, because as agents travel around the VWRAP-compatible metaverse, the regions they visit will contain objects from an arbitrary number of asset service providers.

Without access to these asset services, the visited regions would not be visualizable at all.=A0 And denying visualization is no business of the AD's.=A0 This makes it clear that access to ass= et services should not be mediated by the AD at all --- the AD's role should be limited to allowing or denying entrance to a region.=A0 Once inside a region, it is the region that offers capabilities for access to the asset services of assets within the region.

After reading this a few times, I agree with the high level sentiment - but be careful regarding the terminology, as specific wording tripped me up the first few times through.

My writing style tends to be preoccupied with precision, and readability = can suffer, sorry. ;-)

I did however mean exactly what I wrote, and = I chose the term mediate deliberately for its breadth of coverage, b= ecause I wanted to convey strongly that the AD should have nothing whatsoev= er to do with allowing or denying access to specific asset services = relevant to a region, directly or indirectly, in any manner at all other th= an by permitting entry in the first place.

This may seem like major anathema from a centrally-controlled, single a= sset service perspective.=A0 However, it falls out naturally when you consi= der:
  • David's point about no AD policy control over remote se= rvices,
  • Carlo's point about users having control over their own invent= ory,
  • the quite widespread support for an agent/region split in = policy controls,
  • John's support for strongly decoupled asset se= rvices as in Cable Beach,
  • my point about not breaking region visualization once in a region.=

All of these points shout loudly that considering assets and = inventory to be part of the agent service is badly structured because it cr= eates unnecessary constraints.=A0 It seem far more appropriate to consider = asset services as independent, so that whoever needs them can gain access t= o them if the services permit it.=A0 (This doesn't imply a free-for-all= , to be clear, but only that there should be no a priori barriers by design, such as would occur if ADs were given exclusive power to gr= ant caps for all asset services.)

Instead, if an AD provides an inventory service (a policy choice), then= this is just one contributor to the client's inventory.=A0 [I'l= l cover this explicitly further below.]


In the SL protocol today, clients only ever= communicate with a region. It's the region's responsibility to provide the data for what the a= gent sees. This occurs both for items that would be considered aspects of the region (chairs, buildings, trees, waterfalls) and "transient"= items (other avatars with attachments). The region exposes a data source (today, the byte-efficient but fairly grotesque family of UDP packets) of the description of objects (prims, textures, sourds, animations, ...) which the client consumes.

Behind the scenes, the region may be pulling those object definitions from an asset service, or they may be present in the region definition itself. The client is unaware of this - it's hidden behind the services the region exposes.


That's fin= e. :-) =A0 Right from the earliest days of the AWG, it has many times been = said that the proxying performed by SL sims is merely a design choice or im= plementation detail, and that other implementations of the same protocols c= ould choose to proxy fewer services, or none at all.

This is actually a very important issue for the protocol, because proxy= ing has a major impact on the scalability and availability of a sim, and al= so on the scalability and availability of any services that it proxies, so = flexibility of choice is crucial.

If services are decoupled then such flexibility can be achieved with no= thing more than appropriate configuration of service endpoint locations to = permit the whole gamut of proxying choices to be expressed, including no pr= oxying.=A0 And REST was chosen among other reasons for its flexibility in a= llocation of endpoints, so we already have the means to do this. :-)


Now for the terminology bit: we can call the services the region is exposing "asset services" but these could be quite distinct from = the sorts of things present in an agent's inventory. One phrase that's potentially confusing is "the regions they visit will contain objects from an arbitrary number of asset service providers" - while I agree with the high-level interpretation of that statement, I think it paints a picture that as you're exploring a region, the client is *necessarily* going off and making connections to a variety of asset servers to fetch the data.

I don't think VWRAP should *preclude* that (I imagine it's only sensible for things like textures to be referenced by URLs which could be coming off of any old place), but my initial reading of your text was that the client would necessarily be fetching things from external asset services. For example, if I buy a chair on FooGrid and drop it on BarGrid, when you visit BarGrid you're having to ask FooGrid's asse= t service for the description. Again, I think that's *conceivable*, but shouldn't be *necessary*. (And I don't think you're claiming th= at - but my first read-through came away with that impression.)


I certainly agree on the principle of deployment choic= e!=A0 :-)

We periodically tell each other that we're interested = in defining only mechanisms, not policies, but this is implied all the time= , I hope.=A0 The principle is so clear and uncontested that it's widely= seen as universal in IETF protocol work, although the latter is my own per= sonal reading of it.=A0 For us here it means that nothing important is prec= luded, and that a given provider may choose not to implement or configure a= given feature or facility, yet the mechanism that we provide should allow = it.=A0 In the current case, it means that service proxying must be a deploy= ment choice, neither required nor precluded by the protocol.

Perhaps I should explain further the phrase that gave you trouble above= .=A0 I was trying to indicate that once an agent is in a region, denying th= e user the ability to visualize the world around her would be a very bad id= ea, as it would break the intended perceptual mashup.=A0 "Breaking the= perceived world" is such a poor idea on many fronts that nobody has p= roposed it as far as I know, and if we have a legacy design that may be int= erpreted as suggesting exactly this then it should raise immediate red flag= s with us.=A0 (I'm not saying that it does.)

The original OGP idea was almost always described with the AD as sole p= rovider of seed caps, but the caps concept is of course not actually limite= d in this regard, and I've been working towards a flexible interpretati= on.=A0 In my preferred interpretation stemming from our discussions about t= ourism, it includes the semantic that the AD can provide cap a= ccess to other sources of seed caps.=A0 It is through this mechanis= m that we would implement the variously described key concept of "s= eparation of agent and region policies" or "policies are l= ocal" or "no policy export", and it is this that = would allow us to support the DDP principle through which we achieve touris= m in those VWRAP deployments where it is desired.

I hope that this explains it better.=A0 Such choices are not precluded = nor mandated -- the AD doesn't have to provide a cap to any given regio= n or RD, that's a policy decision.=A0 But if it chooses to grant the ca= p for access to a particular region then that region's policies now app= ly within the region.=A0 It is then up to the region to grant the seed caps= that give access to the assets that allow the region to be visualized, as = one crucial operation.

Here is is my design principle for a caps system that would meet multip= le requirements:


Gaining= access to resources via caps is akin to exploring a caps tree.=A0 Each inn= er node (region) provides a seed cap that gives access to any number of lea= f nodes (asset services) and to any number of child nodes (other regions).= =A0 What distinguishes the AD is that it's the root node of the tree.


Now I can fill in my earlier forward reference to how invento= ries should be structured:=A0 if the AD provides an inventory service (a po= licy choice), then the items in the inventory offered by the AD are the ite= ms delivered by the asset services linked at the leaf nodes of the AD's= initial caps tree.=A0 Not only is this elegant and extensible through tree= -structured design, but it also supports an unlimited set of policies and d= eployments without prescribing nor proscribing anything.


And, of course, one can conceive of clients that implement a policy of not trusting FooGrid for anything and wouldn't make such a connection - FooGrid could be blacklisted by some large search company, my ISP, or perhaps my AD.


Definite= ly.=A0 That's a policy choice, just don't grant the region cap!=A0 = :-)
=A0

Indeed, but fortunately it hasn't been proposed that asset services be part of the agent service in VWRAP.=A0 The legacy SL model of assets and inventories clearly doesn't apply in our extended scenarios, and the OGP documents never covered asset services at all, so we're defining the asset services and inventory model of VWRAP as we speak. :-)

Be careful about blurring the use of "asset services" between "stuff in regions" and "s= tuff I have". I think there is a big intersection - and may have the same characteristics and/or protocols, but I also think they are are distinct. I would guess that there will be asset services associated with both agents and regions - off the top of my head:

Uses of an agent-associated "asset" service:
* content to= client app (inspect your inventory)
* content from client app (upload/i= mport to inventory)
* content to region (rez something)
* content fro= m region (buy/take something)
* content to agent (give something)
* content from agent (receive someth= ing)

Uses of an region-associated "asset" service:
* c= ontent to client app (see the world)
* content from client app (upload/import to region)
* content to region = (during teleport/region crossing)
* content from region (during teleport= /region crossing)
* content to agent (buy/take something)
* content from agent (rez something)

I'm using "asset" in quotes since that term may be overlo= aded. "Content" might be a better term.


This = is a great analysis, which we hadn't approached previously.=A0 I think = your list could be used directly to drive our use case analysis to be sure = that we're covering all the bases.

Note that at this stage I'm considering all resources to be accessi= ble through caps, not only for symmetry and simplicity but because we haven= 't defined any other access mechanism yet, so my reference to "ass= ets" was intended to apply to all "content" in the widest se= nse.=A0 This broad use of the word "asset" stems from our choice = of phrase "asset service" --- if we don't use the broad meani= ng then we're precluding storage of data such as objects and terrain on= asset services, which would be a bad idea as we'd have to invent yet a= nother type of storage service.

I think this hints at the problem caused by using SL-defined terms in o= ur wider setting.=A0 Perhaps we should spend a week revising the terminolog= y that applies to VWRAP.=A0 (We did this at the start of AWG to create an A= WG Glossary, and it was very illuminating.)


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

On Fri, Oct 30, = 2009 at 5:23 PM, Joshua Bell <josh@lindenlab.com> wrote:
On Fri, Oct 30, 2009 at 12:29 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:

This directly implies that asset services must be quite separate f= rom ADs.=A0 Although we haven't spelled it out, clients must have acces= s to an arbitrary list of asset services, because as agents travel around t= he VWRAP-compatible metaverse, the regions they visit will contain objects = from an arbitrary number of asset service providers.

Without access to these asset services, the visited regions would= not be visualizable at all.=A0 And denying visualization is no business of= the AD's.=A0 This makes it clear that access to asset services= should not be mediated by the AD at all --- the AD's role should be li= mited to allowing or denying entrance to a region.=A0 Once inside a region,= it is the region that offers capabilities for access to the asset services= of assets within the region.

After reading this a few times, I agree w= ith the high level sentiment - but be careful regarding the terminology, as= specific wording tripped me up the first few times through.

In the = SL protocol today, clients only ever communicate with a region. It's the region's responsibility to provide the data for what the a= gent sees. This occurs both for items that would be considered aspects of the region (chairs, buildings, trees, waterfalls) and "transient"= items (other avatars with attachments). The region exposes a data source (today, the byte-efficient but fairly grotesque family of UDP packets) of the description of objects (prims, textures, sourds, animations, ...) which the client consumes.

Behind the scenes, the region may be pulling those object definitions from an asset service, or they may be present in the region definition itself. The client is unaware of this - it's hidden behind the services the region exposes.

Now for the terminology bit: we can call the services the region is exp= osing "asset services" but these could be quite distinct from the= sorts of things present in an agent's inventory. One phrase that's= potentially confusing is "the regions they visit will contain objects= from an arbitrary number of asset service providers" - while I agree = with the high-level interpretation of that statement, I think it paints a p= icture that as you're exploring a region, the client is *necessarily* g= oing off and making connections to a variety of asset servers to fetch the = data.

I don't think VWRAP should *preclude* that (I imagine it's only= sensible for things like textures to be referenced by URLs which could be = coming off of any old place), but my initial reading of your text was that = the client would necessarily be fetching things from external asset service= s. For example, if I buy a chair on FooGrid and drop it on BarGrid, when yo= u visit BarGrid you're having to ask FooGrid's asset service for th= e description. Again, I think that's *conceivable*, but shouldn't b= e *necessary*. (And I don't think you're claiming that - but my fir= st read-through came away with that impression.)

And, of course, one can conceive of clients that implement a policy of = not trusting FooGrid for anything and wouldn't make such a connection -= FooGrid could be blacklisted by some large search company, my ISP, or perh= aps my AD.

Indeed, but fortunately it hasn't been proposed t= hat asset services be part of the agent service in VWRAP.=A0 The legacy SL = model of assets and inventories clearly doesn't apply in our extended s= cenarios, and the OGP documents never covered asset services at all, so we&= #39;re defining the asset services and inventory model of VWRAP as we speak= . :-)

Be careful about blurring the use of "ass= et services" between "stuff in regions" and "stuff I ha= ve". I think there is a big intersection - and may have the same chara= cteristics and/or protocols, but I also think they are are distinct. I woul= d guess that there will be asset services associated with both agents and r= egions - off the top of my head:

Uses of an agent-associated "asset" service:
* content to= client app (inspect your inventory)
* content from client app (upload/i= mport to inventory)
* content to region (rez something)
* content fro= m region (buy/take something)
* content to agent (give something)
* content from agent (receive someth= ing)

Uses of an region-associated "asset" service:
* c= ontent to client app (see the world)
* content from client app (upload/import to region)
* content to region = (during teleport/region crossing)
* content from region (during teleport= /region crossing)
* content to agent (buy/take something)
* content from agent (rez something)

I'm using "asset" in quotes since that term may be overlo= aded. "Content" might be a better term.




_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--0016e6d9677edd0f2704773b76d9-- From dyerbrookme@juno.com Sat Oct 31 08:00:14 2009 Return-Path: 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 7E1C13A66B4 for ; Sat, 31 Oct 2009 08:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] 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 AmmrUZzijj+k for ; Sat, 31 Oct 2009 08:00:11 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 3DA043A68B3 for ; Sat, 31 Oct 2009 08:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1257001224; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=X-UNTD-OriginStamp:From:Date:To:Cc:Subject:Message-Id: Content-Type; b=gvcwAVlrDg53XgpkEK/XbeeAABQr1py8l+JqUR4rS5f2ElIbRuzYM9oFgiew4h+Ee rOfqnLUxz7c96kxr3Suy1cCQ52THY7CgefBnYAJehcylU3nFW0JE75lCu3UOSa01ve M4FKXfX9MzSDARAloguY6hNbm4uhMVQYU4o0hjmU= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail24.vgs.untd.com [10.181.12.164]) by smtpout05.vgs.untd.com with SMTP id AABFQ2WG2A5PR7V2 for (sender ); Sat, 31 Oct 2009 07:59:36 -0700 (PDT) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucfxt0SOiKypRPPmrMfZAf9SwXwyiP1n8XQ== Received: (from dyerbrookme@juno.com) by webmail24.vgs.untd.com (jqueuemail) id PV78RBZR; Sat, 31 Oct 2009 07:58:42 PDT Received: from [141.157.224.117] by webmail24.vgs.untd.com with HTTP: Sat, 31 Oct 2009 14:58:07 GMT X-Originating-IP: [141.157.224.117] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 31 Oct 2009 14:58:07 GMT To: morgaine.dinova@googlemail.com X-Mailer: Webmail Version 4.0 Message-Id: <20091031.105807.24932.1@webmail24.vgs.untd.com> Content-Type: multipart/mixed;boundary="===============0748480279==" X-UNTD-BodySize: 41977 X-ContentStamp: 48:24:1552397323 X-MAIL-INFO: 3f21c4d1895dc4893939451919e031a4991550f9b450b5a435d004b475a435542df4b9f4d4417dd121f43079a98d543038347df03915345d1979255515e01101d9a5d1548560f54d809dbd4da1506009841020058944e99129e92920a591e0d46459c0d060019049c0a924c18df0248d152d3150 X-UNTD-Peer-Info: 10.181.12.164|webmail24.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: ogpx@ietf.org Subject: Re: [ogpx] Tourist use case X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 15:00:14 -0000 --===============0748480279== Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 In other words, now the copylefists appear to have set up the propositio= n, and have been setting it up for months and months, that if we want in= teroperability and interworld travel, we will have to further shed prope= rty rights in the name of "seeing" other worlds because the agent "must"= access every other asset server in the metaverse without anything block= ing him. I've been following this discussion for awhile, and I want to point out = again that it is not a technical discussion, but a political discussion,= and it's a profoundly political discussion about sharing the power and = property of the Metaverse which some conceive of as collectivized and fr= ee, and others view as having ownership rights = required to sustain economies. It involves the constant, relentless refrain of the copyleftists and ext= reme Extropians in Second Life: "I "must" have access to "my" inventory = for which I have permissions and the system "must" deliver the assets to= my view or I can't see it." Says who? You completely overlook that the creator of the assets may hav= e intended their permissions to exist only in that world, and not availa= ble to spread at will throughout the metaverse just because you own one = copy. Many non-transfer items are on copy for that world, but that doesn= 't mean they were intended for copy elsewhere. The copy permissions syst= em could evolve to designate "transit" or "other world" permissions but = that should be an opt-in by the creator, not an opt-out. Sure, there mig= ht be people who want their wares copyable or transportable throughout t= he metaverse but *not everybody* and we're all aware that just as soon a= s you mandate the "must copy it to see it" mantra *everywhere* you have = handed over all property to all agents. = The "right" to access inventory and view assets isn't the agent's, it's = the right of the owner of the platform and the right of the creator of t= he object, *the copyright* and *that's ok*. The right of visitors/touris= ts has to be balanced against the right of existing *citizens* as in the= RL analogy. Invocation of "walled gardens" and such doesn't hold, becau= se there must be choice. You can't say "all tourists and immigrants can = have everything for free and have it copyable to resell" whereas the cit= izens who pay the platform owner's costs have to pay for it, and wish to= pay for content to support creators who in turn want their intellectual= property rights = sustained. You persistently claim that property rights are metadata that have to be= stripped away in the interest of the technicalities of building "the pi= pes," but that is a profoundly political act, not a technical one, as it= turns over all the assets of the Metaverse to every passing "tourist". What's especially contradictory is that the same people pushing for the = ability to derender content and people they don't like, through alternat= ive viewers, are demanding the ability to see and access every asset on = every asset server "just because". This looks to me like a blatant grab for all the assets of the Metaverse= by one company, or by one small group grabbing the interoperability top= ic. Interoperability is not consumer-driven and there is no demonstrable nee= d for it except for that manufactured by a few companies for their own a= genda. ____________________________________________________________ Medical Insurance Quotes Compare medical insurance companies and save money now. http://thirdpartyoffers.juno.com/TGL2141/c?cp=3D1wJOeTBdfDuXhCBbabgBWgAA= J1BAkQUOY6racJgsKTPwXVdzAAQAAAAFAAAAAN8H_T4AAAMlAAAAAAAAAAAAAAAAABJQNgAA= AAA=3D --===============0748480279== Content-Type: multipart/alternative; boundary=0016e6d9677edd0f2704773b76d9 --0016e6d9677edd0f2704773b76d9 Content-Type: text/plain; charset=ISO-8859-1 Great post Joshua, leading to many key issues! On Fri, Oct 30, 2009 at 5:23 PM, Joshua Bell wrote: > On Fri, Oct 30, 2009 at 12:29 AM, Morgaine > wrote: > >> >> This directly implies that asset services must be quite separate from >> ADs. Although we haven't spelled it out, clients must have access to an >> arbitrary list of asset services, because as agents travel around the >> VWRAP-compatible metaverse, the regions they visit will contain objects from >> an arbitrary number of asset service providers. >> >> *Without access to these asset services, the visited regions would not be >> visualizable at all. And denying visualization is no business of the AD's. >> * This makes it clear that access to asset services should not be >> mediated by the AD at all --- the AD's role should be limited to allowing or >> denying entrance to a region. Once inside a region, it is the region that >> offers capabilities for access to the asset services of assets within the >> region. >> > > After reading this a few times, I agree with the high level sentiment - but > be careful regarding the terminology, as specific wording tripped me up the > first few times through. > My writing style tends to be preoccupied with precision, and readability can suffer, sorry. ;-) I did however mean exactly what I wrote, and I chose the term *mediate*deliberately for its breadth of coverage, because I wanted to convey strongly that the AD should have nothing whatsoever to do with allowing or denying access to *specific* asset services relevant to a region, directly or indirectly, in any manner at all other than by permitting entry in the first place. This may seem like major anathema from a centrally-controlled, single asset service perspective. However, it falls out naturally when you consider: - David's point about no AD policy control over remote services, - Carlo's point about users having control over their own inventory, - the quite widespread support for an agent/region split in policy controls, - John's support for strongly decoupled asset services as in Cable Beach, - my point about not breaking region visualization once in a region. All of these points shout loudly that considering assets and inventory to be part of the agent service is badly structured because it creates unnecessary constraints. It seem far more appropriate to consider asset services as independent, so that whoever needs them can gain access to them if the services permit it. (This doesn't imply a free-for-all, to be clear, but only that there should be no *a priori* barriers *by design*, such as would occur if ADs were given exclusive power to grant caps for all asset services.) Instead, if an AD provides an inventory service (a policy choice), then this is just one contributor to the client's inventory. [*I'll cover this explicitly further below.*] In the SL protocol today, clients only ever communicate with a region. It's > the region's responsibility to provide the data for what the agent sees. > This occurs both for items that would be considered aspects of the region > (chairs, buildings, trees, waterfalls) and "transient" items (other avatars > with attachments). The region exposes a data source (today, the > byte-efficient but fairly grotesque family of UDP packets) of the > description of objects (prims, textures, sourds, animations, ...) which the > client consumes. > > Behind the scenes, the region may be pulling those object definitions from > an asset service, or they may be present in the region definition itself. > The client is unaware of this - it's hidden behind the services the region > exposes. > That's fine. :-) Right from the earliest days of the AWG, it has many times been said that the proxying performed by SL sims is merely a design choice or implementation detail, and that other implementations of the same protocols could choose to proxy fewer services, or none at all. This is actually a very important issue for the protocol, because proxying has a major impact on the scalability and availability of a sim, and also on the scalability and availability of any services that it proxies, so flexibility of choice is crucial. If services are decoupled then such flexibility can be achieved with nothing more than appropriate configuration of service endpoint locations to permit the whole gamut of proxying choices to be expressed, including no proxying. And REST was chosen among other reasons for its flexibility in allocation of endpoints, so we already have the means to do this. :-) > Now for the terminology bit: we can call the services the region is > exposing "asset services" but these could be quite distinct from the sorts > of things present in an agent's inventory. One phrase that's potentially > confusing is "the regions they visit will contain objects from an arbitrary > number of asset service providers" - while I agree with the high-level > interpretation of that statement, I think it paints a picture that as you're > exploring a region, the client is *necessarily* going off and making > connections to a variety of asset servers to fetch the data. > > I don't think VWRAP should *preclude* that (I imagine it's only sensible > for things like textures to be referenced by URLs which could be coming off > of any old place), but my initial reading of your text was that the client > would necessarily be fetching things from external asset services. For > example, if I buy a chair on FooGrid and drop it on BarGrid, when you visit > BarGrid you're having to ask FooGrid's asset service for the description. > Again, I think that's *conceivable*, but shouldn't be *necessary*. (And I > don't think you're claiming that - but my first read-through came away with > that impression.) > I certainly agree on the principle of deployment choice! :-) We periodically tell each other that we're interested in defining only mechanisms, not policies, but this is implied all the time, I hope. The principle is so clear and uncontested that it's widely seen as universal in IETF protocol work, although the latter is my own personal reading of it. For us here it means that nothing important is precluded, and that a given provider may choose not to implement or configure a given feature or facility, yet the mechanism that we provide should allow it. In the current case, it means that service proxying must be a deployment choice, neither required nor precluded by the protocol. Perhaps I should explain further the phrase that gave you trouble above. I was trying to indicate that once an agent is in a region, denying the user the ability to visualize the world around her would be a very bad idea, as it would break the intended perceptual mashup. "Breaking the perceived world" is such a poor idea on many fronts that nobody has proposed it as far as I know, and if we have a legacy design that may be interpreted as suggesting exactly this then it should raise immediate red flags with us. (I'm not saying that it does.) The original OGP idea was almost always described with the AD as sole provider of seed caps, but the caps concept is of course not actually limited in this regard, and I've been working towards a flexible interpretation. In my preferred interpretation stemming from our discussions about tourism, it *includes* the semantic that *the AD can provide cap access to other sources of seed caps*. It is through this mechanism that we would implement the variously described key concept of "*separation of agent and region policies*" or "*policies are local*" or "*no policy export*", and it is this that would allow us to support the DDP principle through which we achieve tourism in those VWRAP deployments where it is desired. I hope that this explains it better. Such choices are not precluded nor mandated -- the AD doesn't have to provide a cap to any given region or RD, that's a policy decision. But if it chooses to grant the cap for access to a particular region then that region's policies now apply within the region. It is then up to the region to grant the seed caps that give access to the assets that allow the region to be visualized, as one crucial operation. Here is is my design principle for a caps system that would meet multiple requirements: *Gaining access to resources via caps is akin to exploring a caps tree. Each inner node (region) provides a seed cap that gives access to any number of leaf nodes (asset services) and to any number of child nodes (other regions). What distinguishes the AD is that it's the root node of the tree. * Now I can fill in my earlier forward reference to how inventories should be structured: if the AD provides an inventory service (a policy choice), then the items in the inventory offered by the AD are the items delivered by the asset services linked at the leaf nodes of the AD's initial caps tree. Not only is this elegant and extensible through tree-structured design, but it also supports an unlimited set of policies and deployments without prescribing nor proscribing anything. > And, of course, one can conceive of clients that implement a policy of not > trusting FooGrid for anything and wouldn't make such a connection - FooGrid > could be blacklisted by some large search company, my ISP, or perhaps my AD. > Definitely. That's a policy choice, just don't grant the region cap! :-) > > Indeed, but fortunately it hasn't been proposed that asset services be part >> of the agent service in VWRAP. The legacy SL model of assets and >> inventories clearly doesn't apply in our extended scenarios, and the OGP >> documents never covered asset services at all, so we're defining the asset >> services and inventory model of VWRAP as we speak. :-) >> > > Be careful about blurring the use of "asset services" between "stuff in > regions" and "stuff I have". I think there is a big intersection - and may > have the same characteristics and/or protocols, but I also think they are > are distinct. I would guess that there will be asset services associated > with both agents and regions - off the top of my head: > > Uses of an agent-associated "asset" service: > * content to client app (inspect your inventory) > * content from client app (upload/import to inventory) > * content to region (rez something) > * content from region (buy/take something) > * content to agent (give something) > * content from agent (receive something) > > Uses of an region-associated "asset" service: > * content to client app (see the world) > * content from client app (upload/import to region) > * content to region (during teleport/region crossing) > * content from region (during teleport/region crossing) > * content to agent (buy/take something) > * content from agent (rez something) > > I'm using "asset" in quotes since that term may be overloaded. "Content" > might be a better term. This is a great analysis, which we hadn't approached previously. I think your list could be used directly to drive our use case analysis to be sure that we're covering all the bases. Note that at this stage I'm considering all resources to be accessible through caps, not only for symmetry and simplicity but because we haven't defined any other access mechanism yet, so my reference to "assets" was intended to apply to all "content" in the widest sense. This broad use of the word "asset" stems from our choice of phrase "asset service" --- if we don't use the broad meaning then we're precluding storage of data such as objects and terrain on asset services, which would be a bad idea as we'd have to invent yet another type of storage service. I think this hints at the problem caused by using SL-defined terms in our wider setting. Perhaps we should spend a week revising the terminology that applies to VWRAP. (We did this at the start of AWG to create an AWG Glossary, and it was very illuminating.) Morgaine. ============================================= On Fri, Oct 30, 2009 at 5:23 PM, Joshua Bell wrote: > On Fri, Oct 30, 2009 at 12:29 AM, Morgaine > wrote: > >> >> This directly implies that asset services must be quite separate from >> ADs. Although we haven't spelled it out, clients must have access to an >> arbitrary list of asset services, because as agents travel around the >> VWRAP-compatible metaverse, the regions they visit will contain objects from >> an arbitrary number of asset service providers. >> >> *Without access to these asset services, the visited regions would not be >> visualizable at all. And denying visualization is no business of the AD's. >> * This makes it clear that access to asset services should not be >> mediated by the AD at all --- the AD's role should be limited to allowing or >> denying entrance to a region. Once inside a region, it is the region that >> offers capabilities for access to the asset services of assets within the >> region. >> > > After reading this a few times, I agree with the high level sentiment - but > be careful regarding the terminology, as specific wording tripped me up the > first few times through. > > In the SL protocol today, clients only ever communicate with a region. It's > the region's responsibility to provide the data for what the agent sees. > This occurs both for items that would be considered aspects of the region > (chairs, buildings, trees, waterfalls) and "transient" items (other avatars > with attachments). The region exposes a data source (today, the > byte-efficient but fairly grotesque family of UDP packets) of the > description of objects (prims, textures, sourds, animations, ...) which the > client consumes. > > Behind the scenes, the region may be pulling those object definitions from > an asset service, or they may be present in the region definition itself. > The client is unaware of this - it's hidden behind the services the region > exposes. > > Now for the terminology bit: we can call the services the region is > exposing "asset services" but these could be quite distinct from the sorts > of things present in an agent's inventory. One phrase that's potentially > confusing is "the regions they visit will contain objects from an arbitrary > number of asset service providers" - while I agree with the high-level > interpretation of that statement, I think it paints a picture that as you're > exploring a region, the client is *necessarily* going off and making > connections to a variety of asset servers to fetch the data. > > I don't think VWRAP should *preclude* that (I imagine it's only sensible > for things like textures to be referenced by URLs which could be coming off > of any old place), but my initial reading of your text was that the client > would necessarily be fetching things from external asset services. For > example, if I buy a chair on FooGrid and drop it on BarGrid, when you visit > BarGrid you're having to ask FooGrid's asset service for the description. > Again, I think that's *conceivable*, but shouldn't be *necessary*. (And I > don't think you're claiming that - but my first read-through came away with > that impression.) > > And, of course, one can conceive of clients that implement a policy of not > trusting FooGrid for anything and wouldn't make such a connection - FooGrid > could be blacklisted by some large search company, my ISP, or perhaps my AD. > > > Indeed, but fortunately it hasn't been proposed that asset services be part >> of the agent service in VWRAP. The legacy SL model of assets and >> inventories clearly doesn't apply in our extended scenarios, and the OGP >> documents never covered asset services at all, so we're defining the asset >> services and inventory model of VWRAP as we speak. :-) >> > > Be careful about blurring the use of "asset services" between "stuff in > regions" and "stuff I have". I think there is a big intersection - and may > have the same characteristics and/or protocols, but I also think they are > are distinct. I would guess that there will be asset services associated > with both agents and regions - off the top of my head: > > Uses of an agent-associated "asset" service: > * content to client app (inspect your inventory) > * content from client app (upload/import to inventory) > * content to region (rez something) > * content from region (buy/take something) > * content to agent (give something) > * content from agent (receive something) > > Uses of an region-associated "asset" service: > * content to client app (see the world) > * content from client app (upload/import to region) > * content to region (during teleport/region crossing) > * content from region (during teleport/region crossing) > * content to agent (buy/take something) > * content from agent (rez something) > > I'm using "asset" in quotes since that term may be overloaded. "Content" > might be a better term. > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0016e6d9677edd0f2704773b76d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Great post Joshua, leading to many key issues!

On Fri, Oct 30, 2009 = at 5:23 PM, Joshua Bell <josh@lindenlab.com> wrote:
On Fri, Oct 30, 2009 at 12:29 = AM, Morgaine <morgaine.dinova@googlemail.com> w= rote:

This directly implies that asset serv= ices must be quite separate from ADs.=A0 Although we haven't spelled it out, clients must have access to an arbitrary list of asset services, because as agents travel around the VWRAP-compatible metaverse, the regions they visit will contain objects from an arbitrary number of asset service providers.

Without access to these asset services, the visited regions would not be visualizable at all.=A0 And denying visualization is no business of the AD's.=A0 This makes it clear that access to ass= et services should not be mediated by the AD at all --- the AD's role should be limited to allowing or denying entrance to a region.=A0 Once inside a region, it is the region that offers capabilities for access to the asset services of assets within the region.

After reading this a few times, I agree with the high level sentiment - but be careful regarding the terminology, as specific wording tripped me up the first few times through.
In the SL protocol today, clients only ever= communicate with a region. It's the region's responsibility to provide the data for what the a= gent sees. This occurs both for items that would be considered aspects of the region (chairs, buildings, trees, waterfalls) and "transient"= items (other avatars with attachments). The region exposes a data source (today, the byte-efficient but fairly grotesque family of UDP packets) of the description of objects (prims, textures, sourds, animations, ...) which the client consumes.

Behind the scenes, the region may be pulling those object definitions from an asset service, or they may be present in the region definition itself. The client is unaware of this - it's hidden behind the services the region exposes.

My writing style tends to be preoccupied with precision, and readability = can suffer, sorry. ;-)

I did however mean exactly what I wrote, and = I chose the term mediate deliberately for its breadth of coverage, b= ecause I wanted to convey strongly that the AD should have nothing whatsoev= er to do with allowing or denying access to specific asset services = relevant to a region, directly or indirectly, in any manner at all other th= an by permitting entry in the first place.

This may seem like major anathema from a centrally-controlled, single a= sset service perspective.=A0 However, it falls out naturally when you consi= der:
  • David's point about no AD policy control over remote se= rvices,
  • Carlo's point about users having control over their own invent= ory,
  • the quite widespread support for an agent/region split in = policy controls,
  • John's support for strongly decoupled asset se= rvices as in Cable Beach,
  • my point about not breaking region visualization once in a region.=

All of these points shout loudly that considering assets and = inventory to be part of the agent service is badly structured because it cr= eates unnecessary constraints.=A0 It seem far more appropriate to consider = asset services as independent, so that whoever needs them can gain access t= o them if the services permit it.=A0 (This doesn't imply a free-for-all= , to be clear, but only that there should be no a priori barriers by design, such as would occur if ADs were given exclusive power to gr= ant caps for all asset services.)

Instead, if an AD provides an inventory service (a policy choice), then= this is just one contributor to the client's inventory.=A0 [I'l= l cover this explicitly further below.]




That's fin= e. :-) =A0 Right from the earliest days of the AWG, it has many times been = said that the proxying performed by SL sims is merely a design choice or im= plementation detail, and that other implementations of the same protocols c= ould choose to proxy fewer services, or none at all.

This is actually a very important issue for the protocol, because proxy= ing has a major impact on the scalability and availability of a sim, and al= so on the scalability and availability of any services that it proxies, so = flexibility of choice is crucial.

If services are decoupled then such flexibility can be achieved with no= thing more than appropriate configuration of service endpoint locations to = permit the whole gamut of proxying choices to be expressed, including no pr= oxying.=A0 And REST was chosen among other reasons for its flexibility in a= llocation of endpoints, so we already have the means to do this. :-)


Now for the terminology bit: we can call the services the region is exposing "asset services" but these could be quite distinct from = the sorts of things present in an agent's inventory. One phrase that's potentially confusing is "the regions they visit will contain objects from an arbitrary number of asset service providers" - while I agree with the high-level interpretation of that statement, I think it paints a picture that as you're exploring a region, the client is *necessarily* going off and making connections to a variety of asset servers to fetch the data.

I don't think VWRAP should *preclude* that (I imagine it's only sensible for things like textures to be referenced by URLs which could be coming off of any old place), but my initial reading of your text was that the client would necessarily be fetching things from external asset services. For example, if I buy a chair on FooGrid and drop it on BarGrid, when you visit BarGrid you're having to ask FooGrid's asse= t service for the description. Again, I think that's *conceivable*, but shouldn't be *necessary*. (And I don't think you're claiming th= at - but my first read-through came away with that impression.)


I certainly agree on the principle of deployment choic= e!=A0 :-)

We periodically tell each other that we're interested = in defining only mechanisms, not policies, but this is implied all the time= , I hope.=A0 The principle is so clear and uncontested that it's widely= seen as universal in IETF protocol work, although the latter is my own per= sonal reading of it.=A0 For us here it means that nothing important is prec= luded, and that a given provider may choose not to implement or configure a= given feature or facility, yet the mechanism that we provide should allow = it.=A0 In the current case, it means that service proxying must be a deploy= ment choice, neither required nor precluded by the protocol.

Perhaps I should explain further the phrase that gave you trouble above= .=A0 I was trying to indicate that once an agent is in a region, denying th= e user the ability to visualize the world around her would be a very bad id= ea, as it would break the intended perceptual mashup.=A0 "Breaking the= perceived world" is such a poor idea on many fronts that nobody has p= roposed it as far as I know, and if we have a legacy design that may be int= erpreted as suggesting exactly this then it should raise immediate red flag= s with us.=A0 (I'm not saying that it does.)

The original OGP idea was almost always described with the AD as sole p= rovider of seed caps, but the caps concept is of course not actually limite= d in this regard, and I've been working towards a flexible interpretati= on.=A0 In my preferred interpretation stemming from our discussions about t= ourism, it includes the semantic that the AD can provide cap a= ccess to other sources of seed caps.=A0 It is through this mechanis= m that we would implement the variously described key concept of "s= eparation of agent and region policies" or "policies are l= ocal" or "no policy export", and it is this that = would allow us to support the DDP principle through which we achieve touris= m in those VWRAP deployments where it is desired.

I hope that this explains it better.=A0 Such choices are not precluded = nor mandated -- the AD doesn't have to provide a cap to any given regio= n or RD, that's a policy decision.=A0 But if it chooses to grant the ca= p for access to a particular region then that region's policies now app= ly within the region.=A0 It is then up to the region to grant the seed caps= that give access to the assets that allow the region to be visualized, as = one crucial operation.

Here is is my design principle for a caps system that would meet multip= le requirements:


Gaining= access to resources via caps is akin to exploring a caps tree.=A0 Each inn= er node (region) provides a seed cap that gives access to any number of lea= f nodes (asset services) and to any number of child nodes (other regions).= =A0 What distinguishes the AD is that it's the root node of the tree.


Now I can fill in my earlier forward reference to how invento= ries should be structured:=A0 if the AD provides an inventory service (a po= licy choice), then the items in the inventory offered by the AD are the ite= ms delivered by the asset services linked at the leaf nodes of the AD's= initial caps tree.=A0 Not only is this elegant and extensible through tree= -structured design, but it also supports an unlimited set of policies and d= eployments without prescribing nor proscribing anything.


And, of course, one can conceive of clients that implement a policy of not trusting FooGrid for anything and wouldn't make such a connection - FooGrid could be blacklisted by some large search company, my ISP, or perhaps my AD.


Definite= ly.=A0 That's a policy choice, just don't grant the region cap!=A0 = :-)
=A0

Indeed, but fortunately it hasn't been proposed that asset services be part of the agent service in VWRAP.=A0 The legacy SL model of assets and inventories clearly doesn't apply in our extended scenarios, and the OGP documents never covered asset services at all, so we're defining the asset services and inventory model of VWRAP as we speak. :-)

Be careful about blurring the use of "asset services" between "stuff in regions" and "s= tuff I have". I think there is a big intersection - and may have the same characteristics and/or protocols, but I also think they are are distinct. I would guess that there will be asset services associated with both agents and regions - off the top of my head:

Uses of an agent-associated "asset" service:
* content to= client app (inspect your inventory)
* content from client app (upload/i= mport to inventory)
* content to region (rez something)
* content fro= m region (buy/take something)
* content to agent (give something)
* content from agent (receive someth= ing)

Uses of an region-associated "asset" service:
* c= ontent to client app (see the world)
* content from client app (upload/import to region)
* content to region = (during teleport/region crossing)
* content from region (during teleport= /region crossing)
* content to agent (buy/take something)
* content from agent (rez something)

I'm using "asset" in quotes since that term may be overlo= aded. "Content" might be a better term.


This = is a great analysis, which we hadn't approached previously.=A0 I think = your list could be used directly to drive our use case analysis to be sure = that we're covering all the bases.

Note that at this stage I'm considering all resources to be accessi= ble through caps, not only for symmetry and simplicity but because we haven= 't defined any other access mechanism yet, so my reference to "ass= ets" was intended to apply to all "content" in the widest se= nse.=A0 This broad use of the word "asset" stems from our choice = of phrase "asset service" --- if we don't use the broad meani= ng then we're precluding storage of data such as objects and terrain on= asset services, which would be a bad idea as we'd have to invent yet a= nother type of storage service.

I think this hints at the problem caused by using SL-defined terms in o= ur wider setting.=A0 Perhaps we should spend a week revising the terminolog= y that applies to VWRAP.=A0 (We did this at the start of AWG to create an A= WG Glossary, and it was very illuminating.)


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

On Fri, Oct 30, = 2009 at 5:23 PM, Joshua Bell <josh@lindenlab.com> wrote:
On Fri, Oct 30, 2009 at 12:29 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:

This directly implies that asset services must be quite separate f= rom ADs.=A0 Although we haven't spelled it out, clients must have acces= s to an arbitrary list of asset services, because as agents travel around t= he VWRAP-compatible metaverse, the regions they visit will contain objects = from an arbitrary number of asset service providers.

Without access to these asset services, the visited regions would= not be visualizable at all.=A0 And denying visualization is no business of= the AD's.=A0 This makes it clear that access to asset services= should not be mediated by the AD at all --- the AD's role should be li= mited to allowing or denying entrance to a region.=A0 Once inside a region,= it is the region that offers capabilities for access to the asset services= of assets within the region.

After reading this a few times, I agree w= ith the high level sentiment - but be careful regarding the terminology, as= specific wording tripped me up the first few times through.

In the = SL protocol today, clients only ever communicate with a region. It's the region's responsibility to provide the data for what the a= gent sees. This occurs both for items that would be considered aspects of the region (chairs, buildings, trees, waterfalls) and "transient"= items (other avatars with attachments). The region exposes a data source (today, the byte-efficient but fairly grotesque family of UDP packets) of the description of objects (prims, textures, sourds, animations, ...) which the client consumes.

Behind the scenes, the region may be pulling those object definitions from an asset service, or they may be present in the region definition itself. The client is unaware of this - it's hidden behind the services the region exposes.

Now for the terminology bit: we can call the services the region is exp= osing "asset services" but these could be quite distinct from the= sorts of things present in an agent's inventory. One phrase that's= potentially confusing is "the regions they visit will contain objects= from an arbitrary number of asset service providers" - while I agree = with the high-level interpretation of that statement, I think it paints a p= icture that as you're exploring a region, the client is *necessarily* g= oing off and making connections to a variety of asset servers to fetch the = data.

I don't think VWRAP should *preclude* that (I imagine it's only= sensible for things like textures to be referenced by URLs which could be = coming off of any old place), but my initial reading of your text was that = the client would necessarily be fetching things from external asset service= s. For example, if I buy a chair on FooGrid and drop it on BarGrid, when yo= u visit BarGrid you're having to ask FooGrid's asset service for th= e description. Again, I think that's *conceivable*, but shouldn't b= e *necessary*. (And I don't think you're claiming that - but my fir= st read-through came away with that impression.)

And, of course, one can conceive of clients that implement a policy of = not trusting FooGrid for anything and wouldn't make such a connection -= FooGrid could be blacklisted by some large search company, my ISP, or perh= aps my AD.

Indeed, but fortunately it hasn't been proposed t= hat asset services be part of the agent service in VWRAP.=A0 The legacy SL = model of assets and inventories clearly doesn't apply in our extended s= cenarios, and the OGP documents never covered asset services at all, so we&= #39;re defining the asset services and inventory model of VWRAP as we speak= . :-)

Be careful about blurring the use of "ass= et services" between "stuff in regions" and "stuff I ha= ve". I think there is a big intersection - and may have the same chara= cteristics and/or protocols, but I also think they are are distinct. I woul= d guess that there will be asset services associated with both agents and r= egions - off the top of my head:

Uses of an agent-associated "asset" service:
* content to= client app (inspect your inventory)
* content from client app (upload/i= mport to inventory)
* content to region (rez something)
* content fro= m region (buy/take something)
* content to agent (give something)
* content from agent (receive someth= ing)

Uses of an region-associated "asset" service:
* c= ontent to client app (see the world)
* content from client app (upload/import to region)
* content to region = (during teleport/region crossing)
* content from region (during teleport= /region crossing)
* content to agent (buy/take something)
* content from agent (rez something)

I'm using "asset" in quotes since that term may be overlo= aded. "Content" might be a better term.




_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--0016e6d9677edd0f2704773b76d9-- --===============0748480279==--