Re: [mmox] what does it mean to be interoperable?

["Meadhbh Hamrick (Infinity)" <[e-mail]>]

why would MMOX be limited to pursuing only OGP if we want to define  
OGP in a standards body?

POP3 and IMAP are both defined in RFCs, after all. ( though i believe  
they did come out of different working groups )

maybe we _should_ re-charter with a more OGP-centric view and pursue  
interoperability option 5, but this would effectively move any OLIVE  
standardization effort into a different WG, and with two different VW  
"regimes," interop options 1 and 2 would be impossible. JW spoke in  
support of option 4.5 (which yes, has the same intent as what i was  
going for with option 4.)

i don't know if linden could ever support an option-4, because of our  
desire to have interoperability drive "user innovation." in other  
words, we'll always be interested in a situation where developers  
could extend the protocol to support value-added services. we're not  
terribly frightened of option-5 because our view of the world has VW  
operators deploying client software unique to their solution to handle  
these value-added services.

in short, we expect OGP to never be a complete specification of a  
virtual world protocol, but rather a protocol framework that together  
with an interoperability profile sufficiently specifies client and  
server behavior to achieve some measure of interoperability.

On Feb 26, 2009, at 1:58 PM, Morgaine wrote:

> On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick <[e-mail] 
> > wrote:
>
> 5. interoperability means some virtual worlds use some of the same  
> protocols, without a universal client
> ...
> personally.. i'm kind of interested in option 5.
>
>
> Options 5 is a perfectly good option for a workgroup formed around  
> the common goal of implementing some specific protocols in a  
> similarly-focused group.  As you pointed out in your paragraph that  
> I quoted concerning "taxonomy of topics", the protocols which you  
> intend to use are those based on the OGP model.  This sounds like an  
> excellent thing to tackle, in an OGP workgroup.  I would look  
> forward to that work, as it would undoubtedly help advance interop  
> between SL-like worlds.  Furthermore, the workgroup name and charter  
> would honestly reflect the intent, allowing participants interested  
> in such a goal to work productively with helpful consensus.
>
> In contrast, as pointed out by our co-chair under "Charter, Scope,  
> Activities" and in even more detail under "Strawman scope/goals/ 
> approach", the goals and intent of MMOX are very different to the  
> above, and the name of the group reinforces that.  The narrow scope  
> of Option 5 and the specific focus on LL technologies doesn't come  
> anwhere near the catchment area that MMOX participants have been  
> discussing.
>
> I think that both of the above are worthy goals to be handled under  
> the aegis of the IETF.  But work on OGP is hampered by the very  
> clear fact that MMOX discussions and requirements are far broader  
> and can't be forced into an a priori straightjacket.  By the same  
> token, work on MMOX is likewise being hampered by a narrow focus on  
> near-term Linden goals.
>
> This is why I am trying to find an approach that will allow both  
> groups of interests to be successful and productive.  Currently  
> there is little commonality owing to the gulf between the actual  
> narrow intent stated in your "taxonomy of topics" and the very much  
> broader goals of MMOX.
>
>
> Morgaine.
>
>
>
>
>
>
>
> On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick <[e-mail] 
> > wrote:
> so it seems clear we all have different ideas of what it means to be  
> interoperable.
>
> i thought i might try to define a couple of the definitions i think  
> i've seen people use:
>
> 1. interoperability means all virtual worlds, wherever they are, may  
> be accessed via a single unified client.
>
> 2. interoperability means all virtual worlds, wherever they are, use  
> precisely the same protocol(s) and all virtual worlds represent data  
> in formats understandable by all other virtual worlds, with a  
> universal client.
>
> 3. interoperability means some virtual worlds may be accessed via a  
> single unified client.
>
> 4. interoperability means some virtual worlds use precisely the same  
> protocol(s) and all virtual worlds represent data in formats  
> understandable by all other virtual worlds, without a universal  
> client.
>
> 5. interoperability means some virtual worlds use some of the same  
> protocols, without a universal client
>
> 6. interoperability means the "model" is the same, but with  
> different protocols that may be bridged with protocol gateways.
>
> it seems to me that many of us are using different descriptions for  
> the word "interoperable" and it's causing mild discord and at least  
> a couple instances of us talking past each other.
>
> personally.. i'm kind of interested in option 5. it has the benefit  
> of producing a protocol that is identifiable by routers, network  
> management software, etc. it also provides a "slowly moving target"  
> for open source developers (as opposed to the "fast moving target"  
> of linden's existing protocol(s)). by making it public, VW operators  
> can choose whether or not they wish to implement it. it also doesn't  
> require VW operators to implement it (as if we could anyway) and it  
> allows VW operators to avoid having to test interoperability with  
> every other virtual world.
>
> but it's not without drawbacks... this model can lead to a "MOSS- 
> like" environment. (for those of you who don't remember MOSS or MIME  
> Object(?) Security Services... it was a response to the drawbacks of  
> PEM (privacy enhanced mail) which had a relative paucity of  
> encryption options. but IMHO, MOSS introduced so many options that  
> it was VERY easy for two implementations to adhere to the spec, but  
> not actually be interoperable.)
>
> so... i recommend that if we (as a group) wanted to pursue  
> option-5.. we also explicitly define what goes in an  
> "interoperability profile." that way you could get the benefit of  
> having a relatively stable protocol that could be targeted by open  
> source developers which could be used by VW operators to help make  
> client / server apps.
>
> VW operators could publish their "interoperability profile" to tell  
> people who wanted to build tools, extra services, or interoperable  
> worlds what options would be available and how they would work.
>
> -cheers
> -m
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox
>