[ogpx] proposed scope of OGPX group [was: Re: revised draft charter for OGPX working group]

[Infinity Linden <[e-mail]>]

hey dave. you've got some really good comments here, but i'm going to
split up my responses in an effort to make it easier to carry on
different parts of the conversation. i'm going to assume that readers
are familiar with the OGP : Intro and Requirements draft (
http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 ), and have at
least passing familiarity with previous list conversations.

On Sat, Jul 18, 2009 at 11:39 AM, Dave CROCKER<[e-mail]> wrote:

> The fact that it touches such large problem, design and solutions spaces is
> a problem, not a benefit.  If the group is to have any focus, it needs to
> say what it is going to work on, rather specifically.  Otherwise it will
> spend forever trying to decide just that.  I believe that, in fact, there is
> a core of folk, here, who share a specific set of choices.  That's what
> should be documented. And it needs to be documented in a way that those of
> us outside that core -- and even outside the world of experts in VW, but
> with protocol design experience -- can understand.

yes. this was, i believe, the problem with MMOX. we (the OGP
implementers) felt that OGP was a fine core for a series of internet
standards, but felt it was inappropriate to move forward with such an
effort without involvement from users / developers of other protocols.
we were hoping that after discussions, we could agree on a set of
requirements for a common protocol. instead, what happened was we were
unable to even speak the same language, even to the point where there
was protracted debate as to what the word "interoperability" meant.

that is why, at the end of the MMOX BoF in San Francisco, Lisa asked
if there was sufficient interest in forming a group to focus on OGP. i
was asked to write a document describing the common assumptions the
OGP developers have about the virtual world and it's operating
environment. this document became the intro and requirements draft.
you can see the core features of the virtual world described in the
draft charter reflected in this document. the core points being:

* the Virtual World exists independent of the participating clients
* users have a single, unique presence in the virtual world
* the virtual world contains persistent objects
* the virtual world may be partitioned
* presence, state and simulation occur on authoritative hosts

within the domain of virtual worlds, we believe that this is
sufficient to differentiate this effort from other efforts.

for example, virtual worlds compliant with the IEEE HLA and DIS
specifications make extensive use of co-simulation (where each client
application performs virtual world simulation in lock-step with other
clients, communicates a digest of the changes it has made to every
other client and if other clients provide a different digest, a
recovery protocol is entered.) this approach is untenable for an
"internet scale" virtual world.

> A charter says what work is to be done.  It needs to have enough detail for
> that statement to be meaningful to outside readers, so they can tell whether
> they want to participate, and to give focus to folks working within the
> group, so that they know not only what the group is trying to do, but what
> it is NOT trying to do.

i think the charter is fairly solid in this regard. for instance, we
list the following items as being within the scope of the working
group:

1. an abstract dynamic structured data system, suitable for describing
the application protocol in a transport-neutral manner,
2. clear semantics and mechanisms for carrying OGP messages over
message-oriented transports with request/response semantics,
3. guidelines and mechanisms for host and user authentication and
confidentiality,
4. an application-layer protocol for establishing the user's presence,
5. an application-layer protocol for moving a user's presence from one
authoritative host to another,
6. format descriptions for objects and avatars in the virtual world, and
7. an application-layer protocol for identifying agents, and
requesting information about them.

and while i agree that a successful working group must know what it
shouldn't be working on, there's a problem with enumerating the things
a working group isn't. the set of things the proposed working group
isn't is untractably large.

i understand your concern and you're clearly not saying we have to
explicitly mention in the charter that we think "a packet protocol for
inter-kitchen-utensil status updates is not within the scope of this
working group." (you're not saying that, right?)

we are hoping that a "constructive" approach to the working group
charter is workable, where we list aspects that are in-scope rather
than a "reductive" approach where you assume everything is in scope
and explicitly enumerate those which are not.

> The "charter and then figure out what we are going to do" approach only
> works with a topic and participants who have extensive history and focus
> doing similar work.  As soon as the topic is this interesting (ie, complex)
> and this unfamiliar to open standards space and has this potential diversity
> of participation, the group usually has difficulty getting adequate
> agreement.  For one thing, there is no charter -- ie, group contract -- for
> reining in participants who want to push the group into stray areas.

we are not proposing the "charter and then figure out what we're going
to do." that is why we created the requirements and introduction draft
and the draft charter and published it on the list: to define those
things which we propose to do.

> By way of being more concrete, here's a version of the charter with some
> re-working and some comments I've already shared with a few folks privately:

can you please share your version of the charter with the list? i
understand that you have made it available privately to some people,
but i can't incorporate your changes without knowing what those
changes are.