Re: [ogpx] revised draft charter for OGPX working group

[Dave CROCKER <[e-mail]>]

(Apologies for the length of this note.  It opened a door, and I've tried to 
make it as short is practical...)


Meadhbh Siobhan wrote:
> @dave crocker . mmm... good feedback, but i think a number of us
> thought this was such a large design space that it was appropriate to
> move some details out of the charter and into the "intro and
> requirements" doc.

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.

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.

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.

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:


-----


My original posting to the ogpx list was because there are some very basic 
things that I could not discern from the current draft charter. Things that I'd 
expect from any charter.  As a small example, the first paragraph of the charter 
does not satisfy the requirements of the Working Group Guidlines and Procedures 
document.  Even without that requirement, I see the semantics of the paragraph 
reducing to: "VW is popular and we should do some standards work on it."  That's 
not my trying to be clever or nasty.  I mean that is literally all of the 
paragraph's semantics.  I mean that quite literally:  it provides no substantive 
information to a typical charter reader, in terms of specific problems to be 
solved, capabilities to be enabled or protocols to be specified.

As for the Guidelines requirement(Section 2.2), the essential point is that the 
first paragraph is circulated independent of the rest of the charter and needs 
to serve as an abstract, a summary of what the working group is going to 
accomplish, as a technical effort:

      "The first
       paragraph must give a brief summary of the problem area, basis,
       goal(s) and approach(es) planned for the working group.  This
       paragraph can be used as an overview of the working group's
       effort."


By way of a deeper example of the draft's problems please note that the draft 
provides no technical explanation for any of the domain that it will be working 
on.  So it uses many terms, such as "virtual worlds" without any technical 
basis.  Let me be clear:  As a technical term, I do not know what it means and 
what it does not mean.  Really.  But I've got enough technical and standards 
experience that I should be able to read a charter and tell what is and is not 
being solved and created, that is, what the concrete value proposition is.  But 
here, I can't.

If one already is an expert in the topic, then this stuff is probably clear,
although I'll also note that the technical perspectives of long-standing VW
workers appears quite divergent, based on the mailing list discussions I've
seen.  This is what I'd expect for something with a long proprietary history but
just entering standardization.  If these disparities persist, it is going to be
virtually (...) impossible for different views to be understood, nevermind
reconciled.

When a topic is well-established within the profession, no its nature and 
technical implications don't need to be explained.  But here, yes, we have 
something that is relatively new and a community that has little or no 
experience developing standards for it.

I believe this is a very basic difference, and one that greatly increases the 
risk of failure.  Over the years, I've come to believe that the technical work 
of standards is actually the easiest part.  Getting everyone on the same page 
about the problem to be solved and the functionality to be created seems to be 
the hardest.  This requires common perspective and vocabulary. I believe that 
most working group efforts fail because they do not take care of these basics, 
along with failing to limit scope sufficiently... BEFORE chartering.

While I do realize that a number of the folk participating in this effort have 
extensive background in this topic and very much ARE on the same page, the 
question is whether this is to be only a sandbox for them or whether it is to be 
started and run in a way that encourages participation by others.  I hope the 
latter; it makes the chartering and management side a lot more difficult, but 
the results a lot more useful, IMO.

With respect to explaining terms and concepts, in between a 10-page tutorial and 
a complete lack of any explanation, there can be summary information and 
pointers.  I give the barest hint of this, below, in a revised the draft.  No 
doubt it's insufficient.  A bit -- but only a bit -- more tutorial text and some 
well-placed citations, would probably be sufficient.

Side comment:  The charter's repeated use of "application-layer" is something I 
find distracting, since I do not know what technical import it has, but its use 
implies substantive import.  (By contrast, I don't mind saying "transport" when 
citing HTTP -- even though HTTP is classed as an apps protocol -- because it 
properly characterizes the actual role HTTP, or the like, will play for this work.)

Equally, is the group:

    1. Starting from scratch and creating brand new protocols,

    2. Starting with some existing ones but using them only for guidance,

    3. Starting with existing ones but making whatever major changes are deemed 
"useful", or

    4. Starting with existing ones and making only "essential" (and minor) 
changes?

Each of these choice has a history of sometimes being appropriate, but they 
entail wildly different charters and types of work.

My guess is that the group's intention is #2 or #3, but I really can't tell from 
the charter or from the mailing list discussion.  Also, to the extent that 
documents are being used as input, they need to be cited.  I see that a number 
have been released as Internet Drafts that look extremely helpful.  They need to 
be cited, and in terms of the 1-4 list, above.

Let me stress that what I am referring to is quite different from trying to get 
them to agree on resolving differences in solution paradigms.  So I'm not 
suggesting that ogpx should really try to do what mmox couldn't. Rather, the 
ogpx work should at least be accessible to others.  Folks from other VW 
disciplines and folks from other protocol experience.  Based on the current
draft charter and the discussion on the list, it isn't. Too much jargon and too
little explanation.  On the other hand, there were some constructive responses
to my query, until you posted a request not to pursue it.

In addition, the charter is filled with references that have no obvious
technical meaning.  As such, the text does not really provide much meaningful
guidance about goals and scope, except in the most generic terms.

I've attempted to do some re-working of the draft text, at least fixing the
first paragraph, but could not get very far with the remainder, because I found
so much of the remaining text in need of significant clarification.

Here's what I got, along with the questions:


       {{ Open questions are marked by {{...}} }}


Description of Working Group:

       Virtual Worlds (VWs) and other Massively Multi-Party Online
       Applications (MMOs) are simulation environments consisting of many
       objects, object types and virtual actors and users (participants).  There
       are many examples VW and MMO applications, most using proprietary
       protocols. With their roots in games and social interaction, Virtual
       Worlds are now being used increasingly in business, education and
       information exchange. The working group will develop a protocol to enable
       user clients to access multiple, independently-operated servers. It will
       also permit servers to share simulation objects and user participant data.
       For example, a user  will be able to have a single, unique presence among
       independent services.  The Open Grid Protocol (OGP) will describe
       semantics and protocol  interaction for the virtual world, independent of
       transport, though bindings for carrying OGP over HTTP will be defined.
       {{ one protocol or multiple?  the draft charter says "The objective of the
          OGPX working group is to provide an application-layer wire protocol "
          and "the Open Grid Protocol suite (OGP), a set of application
          protocols".  Which is it? }}

       The Open Grid Protocol will define virtual worlds with the following
       assumptions:

       *     The Virtual World exists independent of the participating clients.
             {{ what does this mean? }}

       *     Users have a single, unique presence in the virtual world.

       *     The virtual world contains persistent objects.
             {{ define persistent }}

       *     The virtual world may be partitioned
             {{ define partitioned }}

       *     Presence, state and simulation occur on authoritative hosts.
             {{ where else might they occur?  what choice is being made here? }}


       Foundational components of the Open Grid Protocol include the publication
       of:

       1.    an abstract dynamic structured data system, suitable for describing
             the application protocol in a transport-neutral manner,
             {{ what does dynamic mean, here?  what is the alternative? }}

       2.    clear semantics and mechanisms for carrying OGP messages over
             message-oriented transports with request/response semantics,
             {{ UDP is a 'message-oriented' transport, but I suspect that's not
                what is meant. }}

       3.    guidelines and mechanisms for host and user authentication and
             confidentiality,
             {{ OGPX will define authentication mechanisms? Perhaps is means
                "Guidines for using existing mutual authentication and
                confidentiality mechanisms"? }}

       4.    an application-layer protocol for establishing the user's presence,
             {{ is 'establishing a presence' different from logging in?  if so,
                how?  if not, why not say log in? Given Item #3, I'm guessing
                this item does NOT mean logging in, since that's the same as
                authentication, isn't it?  Perhaps this item's calling for
                creating a presence protocol, given that a couple already exist
                and are used, conflicts with the "use existing" approach of item
                #3.  Why invent a new one?  (There might be a good reason to, but
                it should be justified and maybe debated.) }}

       5.    an protocol for moving a user's presence from one authoritative host
             to another,
             {{ if there are "authoritative" hosts, what other kinds of hosts are
                there? }}

       6.    format descriptions for objects and avatars in the virtual world,
             {{descriptions=specifications?  and avatars are not objects?  what
             are they? }}

       7.    an application-layer protocol for identifying agents, and
             requesting information about them.
             {{ is this client/server or server/server?  this is a distinct
                protocol, from any other ogpx work?  what does it mean to
               "identify" agents? }}


d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net