Re: [vwrap] vwrap Digest, Vol 11, Issue 24

["[e-mail]" <[e-mail]>]

I thought this project had died a deserved death and been revealed long ago for the Trojan horse of the radical open source cult that it is. Interoperability is not a demand of paying customers in Second Life; it's a sectarian demand of a few ideological educators and coders who are using it as a cover to advance their agenda. There is no demonstrable need to link Second Life to the open sims that are reverse engineered (yes indeed they are) from SL -- given the rampant flushing of content theft already underway. I've outlined all the problems with this ideological gambit here:http://secondthoughts.typepad.com/second_thoughts/2011/02/the-berne-inherency-and-the-interop-flop-reply-to-meadh.html?cid=6a00d83451cfe069e2014e5f6737c6970c in answer toMeadhbh's article here herehttp://blog.meadhbh.org/2011/01/boiling-ocean-and-profit-motive.html
Proprietary worlds are not "prisons". Far from being something to be scorned as they were by earlier ideologues in the AOL/Netscape/ etc wars, walled gardens are valued. Today, the walled gardens of Facebook, Twitter and yes, Second Life have millions of happy customers precisely because they can hold in value better than the Leninist sandboxes devised by the Internet's early adapters. All of these lovely walled gardens represent progress for civilization, more freedom, not less. While imperfect, as they still present problems for privacy, IP rights, monetarization, etc. they are still moving in the direction of *real life* and its *values* and not in the direction of discredited ideologies from failed states of the last century. It's not an imposition to *gasp* log out and then log into another world. The user find that it takes a second. And that's an important firewall and membrane to keep intact against theft, griefing and crime. It's all good. It's not "balkanization" to have realms of civilization that in fact can deter intellectual property theft, harassment and stalking, and crime like child pornography. It's *ok*.The real world does not consist of warring Balkan-like states merely because they have customs & immigration and regulations and passports. These are all normal things and their transposition on line is normal and expected and healthy, despite the screeching we hear from people still clinging to a misguided and insular notion that everything has to be some communist utopia with everything coercively shared for the "good of humankind". WHEN worlds are ready to hook up to each other -- because they have what are the analogies of treaties that uphold the rule of law *like content permissions* -- THEN they will hook up. Fiddling around and making technical standards for this execise now is merely an ideological gambit to force the open source cult on the worlds. When companies *and their customers* have a need for interoperability, they will FIRST develop the relevant terms of service and POLICIES, THEN they will develop the tech *that supports that, instead of attempts to drive that*. That's it. That's how it's going to be. Efforts to abstractly enforce this in advance will likely be out of date even on the tech needed, and they will *MOST CERTAINLY* be undemocratic and out of step with CUSTOMER REQUIREMENTS. Nobody but those who need to steal them has a felt need to share the assets of Second Life. These are made by hard-working people who have copyrighted these assets. *Get your furry paws off them*. Prokofy Neva     ---------- Original Message ----------
From: Morgaine <[e-mail]>
To: [e-mail]
Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24
Date: Thu, 31 Mar 2011 01:17:01 +0100

That's a good requirement, Sean.

However, you're suggesting a rather inflexible way of achieving it, because it would rely on one world giving you access to another world.&#65533; This doesn't scale at all when you consider thousands, let alone millions, of destination worlds.
 
Also, it would result in balkanization of the metaverse, as restrictive world operators seek to prevent you from travelling to worlds they don't like.&#65533; We'd end up with prison enclaves in which the only way for inmates to "escape" to visit friends in non-permitted worlds would be to log out from this prison and log in to a different one, which defeats most of the benefits of VW interop.&#65533; It's a poor approach.
 
Fortunately there is a much better way to achieve this, and David hinted at it when he wrote about the near impossibility of one world forcing local policy onto services run by somebody else.&#65533; If your assets are not held by a world operator but in an independent external asset service (which could even be on your local system), then you don't need to ask the current world for "permission" to teleport to some other world, since you (or your external asset service) can supply all of the resources needed by the destination world directly.&#65533; No more prison planet.
 
The Web doesn't usually provide a good analogy with virtual worlds because its architecture is substantially different in several areas.&#65533; However, in respect of teleports the analogy is a direct one.&#65533; One world should not limit your ability to teleport to another world any more than one website should have a say on which website you visit next.
 
In summary, the inter-world teleport requirement that you describe is a good one, but it should not be implemented as a cooperative agreement between worlds because that has very negative repercussions for residents, turning them into hapless inmates and splitting communities apart.
 
Instead, VWRAP provides the excellent concept of independent external shared asset services which can serve content to multiple worlds.&#65533; Using them we can design a teleport protocol that empowers users and helps the open metaverse bloom, instead of enslaving them and balkanizing worlds into non-communicating factions.
 

Morgaine.





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


On Thu, Mar 31, 2011 at 12:20 AM, Sean Hennessee <[e-mail]> wrote:
 So, for example, one protocol we would like to define, in the name of VW interoperability, is how a client, (a viewer and it's user in this case), communicates, to a specific grid X authentication server, that it wants to connect to that grid using grid Y authentication server, which could be another grid or facebook, etc. The communication that happens there needs to have some way to determine if that grid Y authentication service is allowed or known, and if it was successful in authenticating you, among other things. So, this is, in a way, service level interop, but like you said, a bit orthogonal. Also, in addition to the communication between the above service and client, there would have to be communication between grid X authentication service and grid Y authentication service. More protocol this group would likely specify, I assume.
 
 Peace,
 Sean
 
 On 03/30/2011 03:40 PM, Morgaine wrote:Very well put, Vaughn.
 
 Regarding "service level interoperability", it's not really a subset of
 VW interoperability at all, but lies orthogonal to it because it is a
 property of all multipart systems that implement services. &#65533;I'll try to
 explain.
 
 Client-server systems for example have at least two distinct parts with
 distinct roles, server(s) and client(s). &#65533;Service-level interoperability
 typically consists of designing and specifying the protocols or
 interfaces between them in such a way that any part of the system is
 interchangeable with another equivalent part that performs the same
 role, say from a different manufacturer, and the system as a whole still
 continues to work normally.
 
 This rarely needs to be honored with a fancy title such as "service
 level interoperability" in these days of IETF standards and highly
 cross-platform web applications. &#65533;Historically however, applications did
 not behave quite so nicely, and vendors often sought to lock customers
 in with hidden proprietary interfaces, so there was a need for adding
 "service level interoperability" to the tendering documentation in days
 gone by, to avoid surprises later on.
 
 Today, the need for that has almost disappeared, and if your online
 service has a documented protocol interface then "service level
 interoperability" is virtually assured without doing anything at all,
 assuming normal commonsense has prevailed during development (and there
 is no deliberate obfuscation of course). &#65533;There is only one other area
 of this topic where a little more needs to be said.
 
 Protocol messages can normally be validated syntactically to a strong
 degree, and whether a message is correct or not is normally known
 immediately upon syntactic validation. &#65533;Unfortunately, that is not
 always the end of the story, because protocols can transport complex
 data items which are valid syntactically yet invalid semantically.
 
 This is the last vestige of where that term is commonly encountered, as
 *Service Level Semantic Interoperability*. &#65533;Is it relevant to us? &#65533;Yes,
 a little. &#65533;For example, it would do us no good to transport Collada
 meshes from an asset service to a client that tries to render them as
 some other graphics format --- that would create a semantic mishap,
 because one party thinks that the items means one thing and another
 party applies a different semantic. &#65533;So yes, there is a little more for
 us to consider here, but it's not a lot. &#65533;In most part we have already
 stated the solution every time that we have mentioned MIME types for
 describing content. &#65533;This is mostly a solved problem.
 
 There may be one or two other areas where we have to specify the
 required semantic alongside the simple matter of protocol syntax, but
 that's a standard part of defining protocols. &#65533;There is nothing really
 new here.
 
 Lastly, service level interoperability focuses entirely on single
 services and their clients, so it's unrelated to interoperability
 between multiple services, such as a set of virtual world services.
 This means that, apart from defining type semantics, it doesn't get us
 even a step closer towards interop between virtual worlds.
 
 
 Morgaine.
 
 
 
 
 
 
 ==========================
 
 On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca <[e-mail]<mailto:[e-mail]>> wrote:
 
 &#65533; &#65533;Katherine wrote:
 &#65533; &#65533; >It seems to me that accomodating "full" interop only would reduce the
 &#65533; &#65533; >number of possible implementers and use cases for our work
 
 &#65533; &#65533;I am sure that nobody &#65533;suggested to we restrict ourselves to "full"
 &#65533; &#65533;interop only.
 &#65533; &#65533;"Service level interop" is clearly subset of VW interoperability. You
 &#65533; &#65533;can't have VW interoperability without service level interoperability!
 &#65533; &#65533;However, If i understand Morgaine right, she is worried that the VWRAP
 &#65533; &#65533;specs will be *restricted* to service level interop only.
 
 &#65533; &#65533;It has been argued (sorry, I forgot by whom) that proper
 &#65533; &#65533;specifications of service level interop will give us virtual world
 &#65533; &#65533;interop for free. I think we need a bit more, but i really have a hard
 &#65533; &#65533;time envisioning how service level interop can be specified in such a
 &#65533; &#65533;way that it *prevents* VW interop, at least not if we pay attention to
 &#65533; &#65533;this aspect, and clearly we do. So in conclusion i do not see much of
 &#65533; &#65533;a problem.
 
 &#65533; &#65533;Izzy wrote in another tread "This whole argument between service level
 &#65533; &#65533;interop and 'full' interop eludes me." At first it eluded me to, but
 &#65533; &#65533;now i think that what is actually expressed in these discussions is
 &#65533; &#65533;the question of the scope of our effort as well as design approach.
 &#65533; &#65533;Some prefer to work bottom up, following their primary interests in
 &#65533; &#65533;getting the low level protocols working, especially since that will
 &#65533; &#65533;already be good enough for (all?) of their use cases . Some prefer a
 &#65533; &#65533;more top-down approach, first sketching the high level picture of the
 &#65533; &#65533;users perception of VW interop, &#65533;and from there working downwards,
 &#65533; &#65533;obviously also because that approach optimises the realisation of
 &#65533; &#65533;*their* use cases.
 
 &#65533; &#65533;I think we need both, and above all, i do feel that the two approaches
 &#65533; &#65533;are not al all incompatible and both are without any doubt square
 &#65533; &#65533;within the current charter.
 &#65533; &#65533;Formally splitting our effort in two working parties along the current
 &#65533; &#65533;visible fissures and getting each to work on their own interest is a
 &#65533; &#65533;recipe for disaster. It will only strengthen the animosity that is
 &#65533; &#65533;already slowing us down tremendously, and will sustain the infighting.
 &#65533; &#65533;Rather than spitting efforts off, we need to address the causes for
 &#65533; &#65533;the current disagreement and found common ground. &#65533;In my view that is
 &#65533; &#65533;not all all hard.
 
 &#65533; &#65533;I have been reviewing the discussion we had in September and i am
 &#65533; &#65533;actually amazed at the level of consensus that is expressed in those
 &#65533; &#65533;email exchanges. Unfortuanately we have been very bad at consolidating
 &#65533; &#65533;that consensus. As a result we recycle the same problems time and time
 &#65533; &#65533;again. The archives make very depressing reading from that point of
 &#65533; &#65533;view. We need to do more documentation for sure.
 
 &#65533; &#65533;I am currently going over the September discussion and looking up the
 &#65533; &#65533;places were we all agreed on the way forward. &#65533;Much of that is still
 &#65533; &#65533;undocumented, and my aim is to get those points written down in the
 &#65533; &#65533;wiki.
 
 &#65533; &#65533;As i final point i want to make clear how I understand the term
 &#65533; &#65533;"Service Level Interop". I used the term, and since the glosary entry
 &#65533; &#65533;is still emtpy, i feel obliged to add at least my personal reading. If
 &#65533; &#65533;somebody disagrees, please add an improved version.
 
 &#65533; &#65533;Service level interoperability:
 &#65533; &#65533; &#65533; &#65533; &#65533; &#65533;A subset of "Virtual World Interoperability" as defined by
 &#65533; &#65533;the VWRAP
 &#65533; &#65533;protocol. Service level interoperabity loosely describes specific
 &#65533; &#65533;interactions between VWRAP endpoints. These inteactions form the glue
 &#65533; &#65533;that hold a particular virtual world together, but might just as well
 &#65533; &#65533;be used for communication between different VWRAP compatible virtual
 &#65533; &#65533;worlds (i.e. crossing trust domains).
 
 &#65533; &#65533;I intend to put this up in the glossary, but first will see how it
 &#65533; &#65533;flies here &#65533;:)
 
 &#65533; &#65533;On 3/29/11, Katherine Mancuso <[e-mail]&#65533; &#65533;<mailto:[e-mail]>> wrote:
 &#65533; &#65533; > Hi everyone,
 &#65533; &#65533; >
 &#65533; &#65533; > I want to speak up for agreeing with Meadhbh & Mike about keeping a
 &#65533; &#65533; > role for service level interop in this group. &#65533;We've made good
 &#65533; &#65533; > progress towards this goal and can continue to work on it.
 &#65533; &#65533; >
 &#65533; &#65533; > Here is an alternative proposal to any which has been brought up so
 &#65533; &#65533; > far. &#65533;I'm aware this may not be fully correct in its technical
 &#65533; &#65533; > details, as I am not a software architect:
 &#65533; &#65533; >
 &#65533; &#65533; > Could the partisans of "full" VW interop consider working together on
 &#65533; &#65533; > a draft specification that is something like the intro or David's
 &#65533; &#65533; > piece in scope that lays out which specific capacities would need to
 &#65533; &#65533; > be supported at a minimum to allow for "full" interop, perhaps
 &#65533; &#65533;getting
 &#65533; &#65533; > input from implementers such as the Hypergrid folks and the folks who
 &#65533; &#65533; > coordinated the teleport test at Linden? &#65533;Citing existing service
 &#65533; &#65533; > specifications (either ones developed within this WG, or outside
 &#65533; &#65533; > specifications like XML, Collada, etc) is preferred, and for
 &#65533; &#65533; > capabilities for which there are not existing service specifications
 &#65533; &#65533; > or the existing specifications don't work well enough, address
 &#65533; &#65533;that to
 &#65533; &#65533; > lay out a clear roadmap of what must be developed.
 &#65533; &#65533; >
 &#65533; &#65533; > My vision here is that folks who are doing service-level work could
 &#65533; &#65533; > continue developing and implementing their individual services, and
 &#65533; &#65533; > the folks who wish to do "full" interop could define a menu of
 &#65533; &#65533; > services which must be implemented for "full" interop. &#65533;Implementers
 &#65533; &#65533; > could then choose their path based on their use cases: implement the
 &#65533; &#65533; > "full" interop specification including all the specifications called
 &#65533; &#65533; > for, or implement individual services. &#65533;I believe that both of these
 &#65533; &#65533; > concepts can exist under our existing charter or with limited
 &#65533; &#65533; > amendment to the charter and intro, which is much easier for everyone
 &#65533; &#65533; > to agree to than entirely rewriting both, and does not require
 &#65533; &#65533; > trashing years of work.
 &#65533; &#65533; >
 &#65533; &#65533; > It seems to me that accomodating "full" interop only would reduce the
 &#65533; &#65533; > number of possible implementers and use cases for our work
 &#65533; &#65533; > dramatically, not to mention cut out a productive body of folks in
 &#65533; &#65533; > this group who have been contributing an awful lot of documents and
 &#65533; &#65533; > implementing.
 &#65533; &#65533; >
 &#65533; &#65533; > For example, to illustrate my point:
 &#65533; &#65533; >
 &#65533; &#65533; > From my work as a SL developer focusing in education, I know
 &#65533; &#65533;there's a
 &#65533; &#65533; > substantial use case in K-12 education in the US for walled gardens,
 &#65533; &#65533; > because schools have big legal liability problems with letting minors
 &#65533; &#65533; > wander unwalled virtual worlds (most school libraries in the US have
 &#65533; &#65533; > internet filters for the same reasons) and have fairly intense
 &#65533; &#65533; > supervision requirements which require substantial moderation &
 &#65533; &#65533; > surveillance tools. &#65533;However, a shared asset server that contains a
 &#65533; &#65533; > core of "safe" content might be of interest to these folks, since
 &#65533; &#65533; > educators don't necessarily need to reinvent the wheel for their
 &#65533; &#65533; > classrooms every year. &#65533;This is a really good case for service level
 &#65533; &#65533; > interop ... implement the asset server specification only, not the
 &#65533; &#65533; > "full" one that allows you to teleport to other worlds.
 &#65533; &#65533; >
 &#65533; &#65533; > On the other hand, universities have far greater interest in letting
 &#65533; &#65533; > students and professors teleport among university spaces (which
 &#65533; &#65533; > happens metaphorically in the real world all the time), and fewer
 &#65533; &#65533; > liability issues. &#65533;Sharing an asset server might be of interest to
 &#65533; &#65533; > them, but so too might "full" interop. &#65533;They'd want to implement the
 &#65533; &#65533; > "full" interop specification.
 &#65533; &#65533; >
 &#65533; &#65533; > (Paging Fleep Tuque, are you here to make this case better for me?)
 &#65533; &#65533; >
 &#65533; &#65533; > TL;DR - Proposal is to amend the charter & intro so that they allow
 &#65533; &#65533; > the "full" interop people to work in one community on their ideas and
 &#65533; &#65533; > the service level interop people to work in parallel on their ideas,
 &#65533; &#65533; > rather than assuming that one model has to exclusively dominate the
 &#65533; &#65533; > group.
 &#65533; &#65533; >
 &#65533; &#65533; > I will be unavailable to post anything else much lengthy through
 &#65533; &#65533;3 April,
 &#65533; &#65533; > FYI.
 &#65533; &#65533; >
 &#65533; &#65533; > Katherine
 &#65533; &#65533; >
 &#65533; &#65533; > --
 &#65533; &#65533; >
 &#65533; &#65533;---------------------------------------------------------------------------------------------
 &#65533; &#65533; > Katherine Mancuso
 &#65533; &#65533; >
 &#65533; &#65533; > ISIS Inc, Community Manager (http://www.isis-inc.org)
 &#65533; &#65533; > Sex::Tech Conference, Social Media Chair (http://www.sextech.org)
 &#65533; &#65533; > The Vesuvius Group: metaverse community builders
 &#65533; &#65533; > (http://www.thevesuviusgroup.com)
 &#65533; &#65533; > GimpGirl Community Liaison (http://www.gimpgirl.com)
 &#65533; &#65533; >
 &#65533; &#65533; > http://twitter.com/musingvirtual
 &#65533; &#65533; > http://facebook.com/kmancuso
 &#65533; &#65533; > http://www.linkedin.com/in/kathymancuso
 &#65533; &#65533; > Second Life: Muse Carmona
 &#65533; &#65533; >
 &#65533; &#65533;----------------------------------------------------------------------------------------------
 &#65533; &#65533; > _______________________________________________
 &#65533; &#65533; > vwrap mailing list &#65533; &#65533; > [e-mail] <mailto:[e-mail]>
 &#65533; &#65533; > https://www.ietf.org/mailman/listinfo/vwrap
 &#65533; &#65533; >
 &#65533; &#65533;_______________________________________________
 &#65533; &#65533;vwrap mailing list &#65533; &#65533;[e-mail] <mailto:[e-mail]>
 &#65533; &#65533;https://www.ietf.org/mailman/listinfo/vwrap
 
 
 
 
 _______________________________________________
 vwrap mailing list
 [e-mail]
 https://www.ietf.org/mailman/listinfo/vwrap 
 -- 
 
 Sean Hennessee
 Central Computing Support
 Office of Information Technology
 UC Irvine
 
 
 ... . .- -. / &#65533;.... . -. -. . ... ... . .
 _______________________________________________
 vwrap mailing list
 [e-mail]
 https://www.ietf.org/mailman/listinfo/vwrap 
____________________________________________________________
Groupon.com Official Site
1 huge daily deal on the best stuff to do in your city. Try it today!
http://thirdpartyoffers.juno.com/TGL3141/4d94e0321d2534822c1st05vuc