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

From: Katherine Mancuso <[email-masked]>
Date: Tue, 29 Mar 2011 13:42:14 -0700

Hi everyone,

I want to speak up for agreeing with Meadhbh & Mike about keeping a
role for service level interop in this group.  We've made good
progress towards this goal and can continue to work on it.

Here is an alternative proposal to any which has been brought up so
far.  I'm aware this may not be fully correct in its technical
details, as I am not a software architect:

Could the partisans of "full" VW interop consider working together on
a draft specification that is something like the intro or David's
piece in scope that lays out which specific capacities would need to
be supported at a minimum to allow for "full" interop, perhaps getting
input from implementers such as the Hypergrid folks and the folks who
coordinated the teleport test at Linden?  Citing existing service
specifications (either ones developed within this WG, or outside
specifications like XML, Collada, etc) is preferred, and for
capabilities for which there are not existing service specifications
or the existing specifications don't work well enough, address that to
lay out a clear roadmap of what must be developed.

My vision here is that folks who are doing service-level work could
continue developing and implementing their individual services, and
the folks who wish to do "full" interop could define a menu of
services which must be implemented for "full" interop.  Implementers
could then choose their path based on their use cases: implement the
"full" interop specification including all the specifications called
for, or implement individual services.  I believe that both of these
concepts can exist under our existing charter or with limited
amendment to the charter and intro, which is much easier for everyone
to agree to than entirely rewriting both, and does not require
trashing years of work.

It seems to me that accomodating "full" interop only would reduce the
number of possible implementers and use cases for our work
dramatically, not to mention cut out a productive body of folks in
this group who have been contributing an awful lot of documents and
implementing.

For example, to illustrate my point:

>From my work as a SL developer focusing in education, I know there's a
substantial use case in K-12 education in the US for walled gardens,
because schools have big legal liability problems with letting minors
wander unwalled virtual worlds (most school libraries in the US have
internet filters for the same reasons) and have fairly intense
supervision requirements which require substantial moderation &
surveillance tools.  However, a shared asset server that contains a
core of "safe" content might be of interest to these folks, since
educators don't necessarily need to reinvent the wheel for their
classrooms every year.  This is a really good case for service level
interop ... implement the asset server specification only, not the
"full" one that allows you to teleport to other worlds.

On the other hand, universities have far greater interest in letting
students and professors teleport among university spaces (which
happens metaphorically in the real world all the time), and fewer
liability issues.  Sharing an asset server might be of interest to
them, but so too might "full" interop.  They'd want to implement the
"full" interop specification.

(Paging Fleep Tuque, are you here to make this case better for me?)

TL;DR - Proposal is to amend the charter & intro so that they allow
the "full" interop people to work in one community on their ideas and
the service level interop people to work in parallel on their ideas,
rather than assuming that one model has to exclusively dominate the
group.

I will be unavailable to post anything else much lengthy through 3 April, FYI.

Katherine

-- 
---------------------------------------------------------------------------------------------
Katherine Mancuso

ISIS Inc, Community Manager (http://www.isis-inc.org)
Sex::Tech Conference, Social Media Chair (http://www.sextech.org)
The Vesuvius Group: metaverse community builders
(http://www.thevesuviusgroup.com)
GimpGirl Community Liaison (http://www.gimpgirl.com)

http://twitter.com/musingvirtual
http://facebook.com/kmancuso
http://www.linkedin.com/in/kathymancuso
Second Life: Muse Carmona
----------------------------------------------------------------------------------------------

---

From: Mike Dickson <[email-masked]>
Date: Tue, 29 Mar 2011 17:04:05 -0400

> details, as I am not a software architect:
Just saying up front I'd give this approach a strong +1 from me.  It
recognizes the fact that others are interested in full VW interop while
placing the short term focus on service definition and interaction for
which we have some existing documents and experience that can be
leveraged.   Its a walk before you run approach and personally I think
it would be far more productive in the short term versus the VW interop
approach.
> lay out a clear roadmap of what must be developed.
Again yes, strongly agree.  Full VW interop needs a roadmap to have a
chance to be successful.  At present there are lots of cart paths that
can sort of get you there. And tons of unanswered questions.   Its
valuable to spend cycles on that but not at the expense of specifying
existing services and approaches that work now.

> this group who have been contributing an awful lot of documents and
Yes, again I think thats been what we've seen.  Too little agreement
over a hard problem that limits progress on something for which we do
have some experience.
> I will be unavailable to post anything else much lengthy through 3 April, FYI.
Well said overall.  I hope teh group gives this approach real consideration.

Mike

---

From: Vaughn Deluca <[email-masked]>
Date: Wed, 30 Mar 2011 23:07:21 +0200

>number of possible implementers and use cases for our work

I am sure that nobody  suggested to we restrict ourselves to "full"
interop only.
"Service level interop" is clearly subset of VW interoperability. You
can't have VW interoperability without service level interoperability!
However, If i understand Morgaine right, she is worried that the VWRAP
specs will be *restricted* to service level interop only.

It has been argued (sorry, I forgot by whom) that proper
specifications of service level interop will give us virtual world
interop for free. I think we need a bit more, but i really have a hard
time envisioning how service level interop can be specified in such a
way that it *prevents* VW interop, at least not if we pay attention to
this aspect, and clearly we do. So in conclusion i do not see much of
a problem.

Izzy wrote in another tread "This whole argument between service level
interop and 'full' interop eludes me." At first it eluded me to, but
now i think that what is actually expressed in these discussions is
the question of the scope of our effort as well as design approach.
Some prefer to work bottom up, following their primary interests in
getting the low level protocols working, especially since that will
already be good enough for (all?) of their use cases . Some prefer a
more top-down approach, first sketching the high level picture of the
users perception of VW interop,  and from there working downwards,
obviously also because that approach optimises the realisation of
*their* use cases.

I think we need both, and above all, i do feel that the two approaches
are not al all incompatible and both are without any doubt square
within the current charter.
Formally splitting our effort in two working parties along the current
visible fissures and getting each to work on their own interest is a
recipe for disaster. It will only strengthen the animosity that is
already slowing us down tremendously, and will sustain the infighting.
Rather than spitting efforts off, we need to address the causes for
the current disagreement and found common ground.  In my view that is
not all all hard.

I have been reviewing the discussion we had in September and i am
actually amazed at the level of consensus that is expressed in those
email exchanges. Unfortuanately we have been very bad at consolidating
that consensus. As a result we recycle the same problems time and time
again. The archives make very depressing reading from that point of
view. We need to do more documentation for sure.

I am currently going over the September discussion and looking up the
places were we all agreed on the way forward.  Much of that is still
undocumented, and my aim is to get those points written down in the
wiki.

As i final point i want to make clear how I understand the term
"Service Level Interop". I used the term, and since the glosary entry
is still emtpy, i feel obliged to add at least my personal reading. If
somebody disagrees, please add an improved version.

Service level interoperability:
	A subset of "Virtual World Interoperability" as defined by the VWRAP
protocol. Service level interoperabity loosely describes specific
interactions between VWRAP endpoints. These inteactions form the glue
that hold a particular virtual world together, but might just as well
be used for communication between different VWRAP compatible virtual
worlds (i.e. crossing trust domains).

I intend to put this up in the glossary, but first will see how it
flies here  :)

On 3/29/11, Katherine Mancuso <[email-masked]> wrote:
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 30 Mar 2011 14:56:12 -0700

Maybe some see "interop" the same and as seamless as "region-crossing" 
now does with such speed and nature. Perhaps that is where some would 
like to redefine VW interop and service level interop.

For now, I'm mainly concerned about what has been said "agent-domain" in 
order to localize inventory such that it is not stuck in the said 
"region-domain." I'd imagine this will mean start a-new due to the many 
issues of licenses with current inventory design stuck on the said 
server/region-domain.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Morgaine <[email-masked]>
Date: Wed, 30 Mar 2011 23:40:38 +0100

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.  I'll try to explain.

Client-server systems for example have at least two distinct parts with
distinct roles, server(s) and client(s).  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.  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).  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.  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*.  Is it relevant to us?  Yes, a little.
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.  So yes, there is a little more for us to consider here, but it's
not a lot.  In most part we have already stated the solution every time that
we have mentioned MIME types for describing content.  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.  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.

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

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 30 Mar 2011 15:49:28 -0700

Remember, that COLLADA is only an exchange format, not the format for 
which something is being rendered from or to. Please make sure your 
semantic usage of such at least complies when you try to argue with it.

Morgaine wrote:
> as *Service Level Semantic Interoperability*.� Is it relevant to us?� 
> Yes, a little.� 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.� So yes, there is a little 
> more for us to consider here, but it's not a lot.� In most part we 
> have already stated the solution every time that we have mentioned 
> MIME types for describing content.� This is mostly a solved problem.
>

--

---

From: Morgaine <[email-masked]>
Date: Thu, 31 Mar 2011 00:09:02 +0100

COLLADA is not *only* an interchange format, despite being defined for that
purpose originally.  Many applications now use it as their native graphics
file format, the archetypal case being Google Earth.  I expect such use to
become ever more common in the future.

Morgaine.

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

On Wed, Mar 30, 2011 at 11:49 PM, Dzonatas Sol <[email-masked]> wrote:

> Remember, that COLLADA is only an exchange format, not the format for which
> something is being rendered from or to. Please make sure your semantic usage
> of such at least complies when you try to argue with it.
>
>
> Morgaine wrote:
>
>> This is the last vestige of where that term is commonly encountered, as
>> *Service Level Semantic Interoperability*.� Is it relevant to us?� Yes, a
>> little.� 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.� So yes, there is a little more for us to consider here, but it's
>> not a lot.� In most part we have already stated the solution every time that
>> we have mentioned MIME types for describing content.� This is mostly a
>> solved problem.
>>
>>
>
> --

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 30 Mar 2011 16:14:23 -0700

That would be assume that COLLADA would get rid of all conditioners and 
refineries and the purpose of such to exist. That doesn't make any sense.

Morgaine wrote:
> COLLADA is not /only/ an interchange format, despite being defined for 
> that purpose originally.  Many applications now use it as their native 
> graphics file format, the archetypal case being Google Earth.  I 
> expect such use to become ever more common in the future.
>
>
> Morgaine.
>
>
>
>
>
> =======================
>
> On Wed, Mar 30, 2011 at 11:49 PM, Dzonatas Sol <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Remember, that COLLADA is only an exchange format, not the format
>     for which something is being rendered from or to. Please make sure
>     your semantic usage of such at least complies when you try to
>     argue with it.
>
>
>     Morgaine wrote:
>
>         This is the last vestige of where that term is commonly
>         encountered, as *Service Level Semantic Interoperability*.� Is
>         it relevant to us?� Yes, a little.� 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.� So yes, there is a little more
>         for us to consider here, but it's not a lot.� In most part we
>         have already stated the solution every time that we have
>         mentioned MIME types for describing content.� This is mostly a
>         solved problem.
>
>
>
>     -- 
> ------------------------------------------------------------------------
>

--

---

From: Sean Hennessee <[email-masked]>
Date: Wed, 30 Mar 2011 16:20:59 -0700

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.  I'll try to
> explain.
>
> 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.  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).  There is only one other area
> of this topic where a little more needs to be said.
>
> immediately upon syntactic validation.  Unfortunately, that is not
> always the end of the story, because protocols can transport complex
> data items which are valid syntactically yet invalid semantically.
>
> *Service Level Semantic Interoperability*.  Is it relevant to us?  Yes,
> a little.  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.  So yes, there is a little more for
> us to consider here, but it's not a lot.  In most part we have already
> stated the solution every time that we have mentioned MIME types for
> describing content.  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.  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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Katherine wrote:
>     On 3/29/11, Katherine Mancuso <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      > Hi everyone,
>      >
>      > I will be unavailable to post anything else much lengthy through
>     3 April,
>      > FYI.
>      >
>      > Katherine
>      >
>      > --
>      >
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 

Sean Hennessee
Central Computing Support
Office of Information Technology
UC Irvine

... . .- -. /  .... . -. -. . ... ... . .

---

From: Morgaine <[email-masked]>
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.  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.  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.  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.  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.  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.  However, in
respect of teleports the analogy is a direct one.  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.  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 <[email-masked]> wrote:

> 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
>
>

---

From: Sean Hennessee <[email-masked]>
Date: Wed, 30 Mar 2011 21:44:38 -0700

On 3/30/11 5:17 PM, Morgaine wrote:
> However, you're suggesting a rather inflexible way of achieving it, 
> because it would rely on one world giving you access to another 
> world.  This doesn't scale at all when you consider thousands, let 
> alone millions, of destination worlds.
I think you misunderstand my example.

The 'Grid Y' authentication service that was used in the example is the 
one that the end user _chose_ to use, not forced by a restriction of 
it's current grid or poor protocol definition. They would have the 
option to choose any authentication service they want, like OpenID, 
Facebook, Google, their home grid's authentication service, or their own 
home grown authentication service they are running for themselves. They 
could even have the option to connect to a grid that does not require 
authentication. Some grids will allow only a few authentication 
methods/services; some grids won't allow any except their own, and some 
grids won't care.

An additional thought would be having the ability to have a list of 
authentication services that you, the end user, are willing to use, (via 
some preferences in the client viewer application), leaving the 
negotiation process to determine which one to use, (or none at all), for 
that particular destination grid.

Other options that could be negotiated during the authentication phase 
could be asset services used, IM services used, voice services used, 
etc. These would not necessarily be options set by the end users current 
grid, but by the end user herself, (through the viewer client program 
likely). As above, some grids may accept any asset service, or only a 
limited list of trusted asset services, or none at all except it's own. 
This should not be limited to only one of each service, either. I 
commonly login to Yahoo and AIM at the same time to connect with friends 
that are only connect to one service or the other.

There really has to be some kind of negotiations, otherwise you could be 
doing the equivalent of telling Google that you planned to login to 
their webmail service using AOL's Instant Messenger authentication 
services, whether they allow it or not.

Peace,
Sean
> 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.  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.  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.  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.  
> 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.  
> However, in respect of teleports the analogy is a direct one.  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.  
> 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 <[email-masked] 
> <mailto:[email-masked]>> 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
>
>
>         encountered, as
>         On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>            Katherine wrote:
>                    A subset of "Virtual World Interoperability" as
>         defined by
>            the VWRAP
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>         > Hi everyone,
>         >
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>

---

From: Morgaine <[email-masked]>
Date: Thu, 31 Mar 2011 07:35:12 +0100

Oh, that sounds fine then, Sean.

(It was only your final part concerning grid-to-grid authentication that
gave it all the bad properties and dangers that I highlighted.)

Your suggestion about multiple authentication services seems to be very much
in line with our avoidance of singletons.  No matter how much one might like
a universal single sign on, worlds are going to employ a diversity of
authentication systems and we will need to adapt to that, otherwise users
will be unnecessarily restricted in the worlds to which they can travel.

Morgaine.

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

On Thu, Mar 31, 2011 at 5:44 AM, Sean Hennessee <[email-masked]> wrote:

>> because it would rely on one world giving you access to another world.  This
>> doesn't scale at all when you consider thousands, let alone millions, of
>> destination worlds.
>>
> The 'Grid Y' authentication service that was used in the example is the one
> that the end user _chose_ to use, not forced by a restriction of it's
> current grid or poor protocol definition. They would have the option to
> choose any authentication service they want, like OpenID, Facebook, Google,
> their home grid's authentication service, or their own home grown
> authentication service they are running for themselves. They could even have
> the option to connect to a grid that does not require authentication. Some
> grids will allow only a few authentication methods/services; some grids
> won't allow any except their own, and some grids won't care.
>
> some preferences in the client viewer application), leaving the negotiation
> process to determine which one to use, (or none at all), for that particular
> destination grid.
>
> could be asset services used, IM services used, voice services used, etc.
> These would not necessarily be options set by the end users current grid,
> but by the end user herself, (through the viewer client program likely). As
> above, some grids may accept any asset service, or only a limited list of
> trusted asset services, or none at all except it's own. This should not be
> limited to only one of each service, either. I commonly login to Yahoo and
> AIM at the same time to connect with friends that are only connect to one
> service or the other.
>
> doing the equivalent of telling Google that you planned to login to their
> webmail service using AOL's Instant Messenger authentication services,
> whether they allow it or not.
>
> Peace,
> Sean
>
>> 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
>> 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.
>>
>> shared asset services which can serve content to multiple worlds.  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
>> On Thu, Mar 31, 2011 at 12:20 AM, Sean Hennessee <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>

---

From: Vaughn Deluca <[email-masked]>
Date: Thu, 31 Mar 2011 16:34:04 +0200

Morgaine,

Thanks a lot for the explanation, i now realise that "service level
interoperability is an existing technical term, and  not something
that was manufactured on the fly here in the group...my bad.

I will update my definition in the glossary a bit, (and use an existing source).
In the process of doing my homework, and reading up on the topic, i
stumbled over a very  interesting piece on the web that i would like
to bring up here for discussion.

It is a powerpoint presentation with teaching material from the OGCII
(Open Geospatial Consortium Interoperability Institute).  Processing
Geospatial data appears to have many problems in common with our
virtual worlds. See:
http://portal.ogcii.org/files/?artifact_id=168   (warning: powerpoint download)

The core idea is simple. A standard intermediate data format, that is
used to match possibly very disparate datasets (like our assets from
different virtual worlds) and some mechanisms to extend this.

I might have missed this, but it seems to me that this concept has up
till now not figured this explicitly in our thinking. It would be good
if people on this list have a look at this material, if only to point
out that it matches closely to stuff we *did*specify, or alternatively
why it is *not* applicable to our case, and bad idea.  However,  I
think it is very useful, and could easily be adapted for the VWRAP
problem domain with its many disparate and  distributed data sources.

It anyhow nicely addresses the differences between working service
level interoperability and the semantic mismatch you mentioned.

--Vaughn

On 3/31/11, Morgaine <[email-masked]> wrote:
> <[email-masked]>wrote:
>
>> Katherine wrote:
>> > I will be unavailable to post anything else much lengthy through 3
>> > April,
>> > FYI.
>> >
>> > Katherine
>> >
>> > --
>> >

---

From: Morgaine <[email-masked]>
Date: Thu, 31 Mar 2011 16:00:28 +0100

That sounds interesting, Vaughn.

Unfortunately my Firefox browser and Gmail on Linux appear to have a
semantic problem with Powerpoint, despite the success of Service Level
(Syntactic) Interoperability because it is a recognized type.  Is the OGCII
material available in any other format?

:P

Morgaine.

On Thu, Mar 31, 2011 at 3:34 PM, Vaughn Deluca <[email-masked]>wrote:

> VW
> interfaces
> service
> services

---

From: Fleep Tuque <[email-masked]>
Date: Thu, 31 Mar 2011 11:11:01 -0400

The formatting got a little wonky, but I printed the PPT to PDF and uploaded
it to google docs.  Should be a public document now, try
https://docs.google.com/document/pub?id=1WsjarTozebPG8f7HRh_Qyg9PO6dD603cnUzzLUCRSFA
.

- Chris/Fleep

Chris M. Collins (SL: Fleep Tuque)
Project Manager, UC Second Life
Second Life Ambassador, Ohio Learning Network
UCit Instructional & Research Computing
University of Cincinnati
406E Zimmer Hall
PO Box 210088
Cincinnati, OH 45221-0088
(513)556-3018
[email-masked]

UC Second Life:   http://homepages.uc.edu/secondlife
OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php

It is a powerpoint presentation with teaching material from the OGCII
(Open Geospatial Consortium Interoperability Institute).  Processing
Geospatial data appears to have many problems in common with our
virtual worlds. See:
http://portal.ogcii.org/files/?artifact_id=168   (warning: powerpoint
download)

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 31 Mar 2011 08:20:40 -0700

fwiw... in terms of data formats,

a couple years ago, this group was indicating we wanted to re-use
existing formats as much as possible. Assets were to be COLLADA
objects, textures were to be JPEGs or PNGs, audio files were to be
MP3, WAV, AU or whatever. group chat, when it was considered "in
scope" for this initiative, was hoped tobe IRC or XMPP.

LLSD based services were supposed to provide the "glue" that held them
together or to define things we couldn't find existing services for.

A typical example might be... you use an LLSD over HTTPS service to
authenticate to a auth service. Some magic happens and your client is
given a URL on a target region / simulator system the client can use
to retrieve the scene graph. Maybe that scene graph was represented as
X3D/VRML (though some of us had some issues with X3D) and objects in
the world were represented as URLs to COLLADA objects.

it sounds philosophically similar to what you describe above, but
probably different in execution. but the core idea is the same: "use
existing standards where they apply, build new things only when an
existing standard doesn't apply and use new things as 'glue' to glue
things together."

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

---

From: Vaughn Deluca <[email-masked]>
Date: Thu, 31 Mar 2011 17:32:48 +0200

Thanks for that upload, but it stops working for me after slide 9, and
the interesting bits are starting at 17... Let me see if i can make a
pdf out of the presentation.
brb.

---

From: Vaughn Deluca <[email-masked]>
Date: Thu, 31 Mar 2011 17:43:09 +0200

I am not sure if i am allowed to upload this to the VWRAP wiki, for
now  put it here:

http://ddscripting.net/Module_1_-_Overview.pdf

---

From: Morgaine <[email-masked]>
Date: Thu, 31 Mar 2011 17:28:43 +0100

Thanks Fleep, Vaughn, and Sean!

Between the three of you, I have something that is readable here, :DDD

Morgaine.

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