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

[Morgaine <[e-mail]>]

On Thu, Feb 26, 2009 at 10:26 PM, Meadhbh Hamrick (Infinity) <
[e-mail]> wrote:

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

Nobody said "*MMOX [would] be limited to pursuing only OGP if we want to
define OGP in a standards body*", so it's not an argument you get to knock
down.

Quite the opposite is true.  MMOX would *NOT* be limited to pursuing only
OGP if the "OGP-only" work were being done in an OGP workgroup.  The MMOX
group would then be free to pursue the broad interop implied in the "MMOX"
name and affirmed by many MMOX posts.  In contrast, conflating the two goals
(both of them very worthy) is causing a lot of conflict, and we could avoid
that with some honest workgroup naming.

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


Re-chartering MMOX to be OGP-only would be a less than upstanding attempt to
acquire the generic "MMOX" label for a technology that is clearly not
vendor-neutral.  It would inherently exclude all participants who have
strong interest in MMO interop but no interest at all in the SL model.  It
would also conflict with the numerous statements made on this list about the
broad aspirations of the group.  OGP-only work should be labelled "OGP",
that would be honest and helpful.



>
> 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.
>
>
>
Excellent, there is *HUGE* merit in that, which is why I would support such
OGP-oriented work directly and avidly.  But it should be done in an "OGP"
workgroup so that there is clear understanding that the work is devoted to
one particular implementation and does not seek to embrace the world
diversity (and implementation diversity) of "MMOX".

I'm just trying to give everybody the elbow room to be able to work
productively.  Saying that the goal is broad VW interop while simultaneously
requiring the MMOX group to use the SL model is not a recipe for effective
group cooperation.


Morgaine.








On Thu, Feb 26, 2009 at 10:26 PM, Meadhbh Hamrick (Infinity) <
[e-mail]> wrote:

> 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"<http://www.ietf.org/mail-archive/web/mmox/current/msg00724.html>,
> 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"<http://www.ietf.org/mail-archive/web/mmox/current/msg00025.html>and in even more detail under "Strawman
> scope/goals/approach"<http://www.ietf.org/mail-archive/web/mmox/current/msg00626.html>,
> 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
>>
>
>
>