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

[Sean Hennessee <[e-mail]>]

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.
>
> 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.
>
>
>
>
>
>
> ==========================
>
> On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Katherine wrote:
>      >It seems to me that accomodating "full" interop only would reduce the
>      >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 <[e-mail]
>     <mailto:[e-mail]>> wrote:
>      > 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
>      >
>     ----------------------------------------------------------------------------------------------
>      > _______________________________________________
>      > vwrap mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/vwrap
>      >
>     _______________________________________________
>     vwrap mailing list
>     [e-mail] <mailto:[e-mail]>
>     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


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