Subject: [mmox] Vendor Neutral

From: Mark Lentczner <[email-masked]>
Date: Fri, 6 Mar 2009 08:00:10 -0800

Jon -

I think you take this term to mean something very different than most  
of the people on this list, or as David and Meadhbh used when they  
drafted the first version of the charter.

I'm not sure what it means to you, since you seem to define it by  
calling out what isn't "vendor neutral" to you: If a standard means it  
will be easier for one vendor to code than another, if a standard  
favors one model of operation over another, if a standard isn't  
designed to support all vendor's use cases, or if it incorporates any  
prior design work that not all vendors may have been involved with.  
These seem punitive definitions, and not concerned with what will  
practically achieve the aims.

The original proposed charter [1] references "vendor neutral" with  
respect to the IETF's IPR policy.  The charter points to IETF's IPR  
policy that standards track work strongly favors results that will  
either not require licenses, or licenses reasonable and non- 
discriminatory. Please see RFC 2026, RFC 3979, and related drafts.

[1] http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter
[RFC 2026] http://tools.ietf.org/html/rfc2026
[RFC 3979] http://tools.ietf.org/html/rfc3979

	- Mark

---

From: Charles Krinke <[email-masked]>
Date: Fri, 6 Mar 2009 08:50:25 -0800

Good point, Mark.

I also take this to mean "that which we all could use if we so choose" and
not "that which does not fit my personal or companies vision".

I can imagine (and write) all sorts of emotionally charged words to attempt
to sway opinion. But, I think we do all of ourselves a disservice by doing
that. So, trying to concentrate on the problem space in the spirit of the
IETF seems like a really good idea.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Fri, Mar 6, 2009 at 8:00 AM, Mark Lentczner <[email-masked]> wrote:

> Jon -
>
> I think you take this term to mean something very different than most of
> the people on this list, or as David and Meadhbh used when they drafted the
> first version of the charter.
>
> I'm not sure what it means to you, since you seem to define it by calling
> out what isn't "vendor neutral" to you: If a standard means it will be
> easier for one vendor to code than another, if a standard favors one model
> of operation over another, if a standard isn't designed to support all
> vendor's use cases, or if it incorporates any prior design work that not all
> vendors may have been involved with. These seem punitive definitions, and
> not concerned with what will practically achieve the aims.
>
> The original proposed charter [1] references "vendor neutral" with respect
> to the IETF's IPR policy.  The charter points to IETF's IPR policy that
> standards track work strongly favors results that will either not require
> licenses, or licenses reasonable and non-discriminatory. Please see RFC
> 2026, RFC 3979, and related drafts.
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Jon Watte <[email-masked]>
Date: Mon, 09 Mar 2009 12:14:07 -0700

> drafted the first version of the charter.

To me, "vendor neutral virtual world interoperability" is pretty clear. 
It is a set of standards that allow vendors of different virtual worlds 
to achieve useful interoperability between their separately architected 
virtual worlds, no matter what the specific technology is of each 
particular world's implementation.

If a standard makes an assumption that the source system and destination 
system in a scenario always use the same underlying technology, then 
that is not a vendor neutral virtual world interoperability standard, 
because it does not achieve vendor neutral interoperability, only vendor 
specific interoperability.

What, specifically, do you think is wrong with that interpretation? Do 
you want to standardize methods that do not achieve vendor neutral 
virtual world interoperability, as part of the MMOX group?

Sincerely,

jw