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

From: Infinity Linden <[email-masked]>
Date: Mon, 6 Jul 2009 11:16:38 -0700

thanks to the many people who offered suggestions concerning the OGPX
draft charter, we now have a new revision. please look it over,
especially if you're attending the BoF in Stockholm.

-cheers
-meadhbh hamrick

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 06 Jul 2009 13:05:43 -0700

Infinity Linden wrote:
> draft charter, we now have a new revision. 

Hi.  A few questions:

Although it might be implied from some comments later in the draft, the 
beginning of the draft charter does not make explicit what value-add is being 
pursued.

That is,

    What problems will be solved?

    What will be possible after the work is done that isn't possible now?

I'll offer some guesses, but have no faith in my understanding of things:

    1.  There are multiple VW instances that exist independently and cannot 
interoperate.  This work will permit exchange of virtual objects and (...?) 
among independent virtual worlds.

    2.  Currently, a user must have a distinct and unrelated presence in each 
virtual world that they participate in.  This work will permit a user to have a 
single, unique presence, across multiple VW instances.

First, are these two statements correct?

Second, will the work solve other problems or create other enhancements?

Also:  A topic that's been discussed frequently is the difference between having 
a client able to access multiple servers, versus having independent servers 
directly interact.  From the draft charter, I cannot tell which of these will be 
covered or how.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Meadhbh Siobhan <[email-masked]>
Date: Mon, 6 Jul 2009 14:14:08 -0700

Dave. we're actually going for a much narrower scope. MMOX was about
what you mention, an integrated protocol for _all_ virtual worlds.
OGPX is about OGPish systems; drawing on what we learned from two
years of interop experiments with "second lifelike" systems such as
Second Life(tm), OpenSim(tm?) and arguably realXtend(tm).

the statement "The objective of the OGPX working group is to provide
an application-layer wire protocol for Virtual Worlds to enable
interoperability between applications and provide for access and
exchange with other systems on the internet such as web services,
e-mail and other information storage systems." describes the objective
of the working group and it's value add. right now in the domain of
"second lifelike" systems there are a collection of protocols (opensim
and SL are very close, realXtend a litter further away, but still
pretty close.) the work of OGPX is to get agreement amongst this set
of participants.

the charter does not detail the architecture of a OGP "compliant"
virtual world, but defers to the introduction and requirements draft.
and even then, there's some wiggle-room depending on how you want to
deploy your services. OGP defines an application layer protocol, it
does not mandate your architecture. this is analogous to the way
services are deployed for a web application. you could, if you wanted,
put the endpoints for your service on a single host (
http://www.example.com/login or http://www.example.com/chat ) or on
distinct hosts ( http://login.example.com/ or http://chat.example.com/
.) ultimately it doesn't affect HTTP.

that being said, the intro and requirements doc describes a situation
where a client application authenticates itself to a single agent
domain through which services addresses are resolved. the alternative
approach, like what is being used in hypergrid, where the client logs
into each service individually could make use of some of the
underlying primitives in OGP (capabilities, LLSD / LLIDL, OGP<->HTTP
binding, etc.) though it does sort of break the OGP trust model.

so... to answer your questions... will this permit transfer of digital
assets from one arbitrary virtual world to another? no. digital asset
transfers in OGP will be limited from/to OGP compliant worlds; OGP
won't let you transfer an object from World of Warcraft(tm) to The
Sims Online(tm) using their native protocols.

and.. will this work will permit a user to have a single, unique
presence, across multiple VW instances? no. you won't be able to login
to World of Warcraft(tm) with your Second Life(tm) username and
password using their native protocols.

what it does allow is for a digital asset access protocol to be
defined so you can have a digital assets maintained by a distinct
administrative domain and have those assets appear in a virtual world,
where the hosts that provide simulation services belong to distinct
administrative domains.

or... in OGP lingo... a client's agent domain may tell the client it's
user's assets "live" on servers operated by a third party. and that
user's avatar may rez those assets in a portion of a virtual world
being simulated by yet a different third party.

ultimately however, OGP is more about mechanism than policy. the OGP
draft specs do not disallow a client from connecting to multiple agent
domains, but the intent of OGP is that it will define a protocol that
provides a meaningful experience with a single agent domain per user
account.

clear as mud, eh?

On Mon, Jul 6, 2009 at 1:05 PM, Dave CROCKER<[email-masked]> wrote:
> beginning of the draft charter does not make explicit what value-add is
> being pursued.
>
> That is,
>
> virtual world that they participate in.  This work will permit a user to
> have a single, unique presence, across multiple VW instances.
>
>
> Also:  A topic that's been discussed frequently is the difference between
> having a client able to access multiple servers, versus having independent
> servers directly interact.  From the draft charter, I cannot tell which of
> these will be covered or how.
>
> d/
> --
>
>  Dave Crocker
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>

---

From: Meadhbh Siobhan <[email-masked]>
Date: Mon, 6 Jul 2009 14:19:07 -0700

personally, i think we're pretty clear about the value add and i would
prefer to not have to say "OGPX is not about things that didn't get
done in MMOX."

but, if you're unclear after reading the draft charter and the intro
and requirements draft, chances are other people would be as well.

what verbiage would you recommend to make it more clear that OGPX is not MMOX?

-cheers
-m

---

From: Barry Leiba <[email-masked]>
Date: Mon, 6 Jul 2009 18:50:29 -0400

> what verbiage would you recommend to make it more clear that OGPX is not MMOX?

Indeed; what Meadhbh said.  As one of the BOF chairs, I'll say that
I'm happy with the charter now, after some side-bashing we had (the
chairs and the ADs).  The dates for the work items are unrealistic,
but we'll sort them out when we're at the stage of finalizing the
charter.

So at this point, if you have a better understanding of the goals and
have specific text to suggest, that'd be wonderful.  Though, please,
not "verbiage"[1]; concise wording that's to the point would be best.

Barry Leiba, ODPX BOF co-chair

[1] "You keep using that word. I do not think it means what you think
it means. " -- Inigo Montoya

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 18 Jul 2009 11:57:55 +0100

Hi Dave,

Dave CROCKER wrote:

> Also:  A topic that's been discussed frequently is the difference 
> between having a client able to access multiple servers, versus having 
> independent servers directly interact.  From the draft charter, I 
> cannot tell which of these will be covered or how.

I think this is an important question. There are 3 groups of entities 
involved in OGP and the charter doesn't make this clear.

---

From: Kajikawa Jeremy <[email-masked]>
Date: Sat, 18 Jul 2009 18:22:53 +0900

Well a sketch I recently worked up has
  AgentDomain and RegionDomain

these can be instanced...

  but both need "SI" or Service Interfaces
  basically abstracting U G A I M into classes for re-use
  and standardizing the protocol chatter

---

From: David W Levine <[email-masked]>
Date: Sat, 18 Jul 2009 10:42:33 -0400

If you look at:
http://www.ietf.org/id/draft-levine-ogp-layering-00.txt 

It begins to address this at the requirements and design pattern level. 
I'd strongly argue, that if its not clear that we want to permit the 
protocols to work properly in *all* of those deployments patterns, we need 
to update the charter to make that clear.

My personal perspective is that the OGPX specifications are going to end 
up defining several hundred "REST" and "RESTish" resources/services, and 
that grouping and we need to describe how to group and deploy them as 
deployers see fit. There re some natural clusterings which will be very 
hard to decouple, but, beyond those, the specifications should strive to 
give deployers and implementers as much flexibility as possible. 

-  David W. Levine
~ Zha Ewry, In Second Life

Kajikawa Jeremy <[email-masked]> 
Sent by: [email-masked]
07/18/2009 05:22 AM

To
[email-masked]
cc

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

---

From: Meadhbh Siobhan <[email-masked]>
Date: Sat, 18 Jul 2009 10:10:14 -0700

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

@kajikawa . right, the role of the agent domain and the region domain
are crucial to the protocol. and the LLIDL resource descriptions +
documentation of their semantics are supposed to define service
interfaces. strictly speaking, we're not developing a software
architecture here, but processing expectations _are_ in scope, so
understanding what the software looks like would be a "good idea"
(tm).

@david . right . it CRITICAL that we not create a deployment design
space that is so large that we find ourselves working through use
cases 10 years from now. the linden deployment pattern is well
documented. OpenSIm has a couple deployment patterns: standalone,
grid, and probably both with 3rd party cable beach service. we should
probably also chat with ryan @ realXtend to see if realXtend and 3di
deployment patterns are different from OpenSim.

-cheers

On Sat, Jul 18, 2009 at 7:42 AM, David W Levine<[email-masked]> wrote:
> It begins to address this at the requirements and design pattern level. I'd
> strongly argue, that if its not clear that we want to permit the protocols
> to work properly in *all* of those deployments patterns, we need to update
> the charter to make that clear.
>
> My personal perspective is that the OGPX specifications are going to end up
> defining several hundred "REST" and "RESTish" resources/services, and that
> grouping and we need to describe how to group and deploy them as deployers
> see fit. There re some natural clusterings which will be very hard to
> decouple, but, beyond those, the specifications should strive to give
> deployers and implementers as much flexibility as possible.
>
> -  David W. Levine

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 18 Jul 2009 11:39:08 -0700

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

> move some details out of the charter and into the "intro and

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

-- 

   Dave Crocker

---

From: Meadhbh Siobhan <[email-masked]>
Date: Sat, 18 Jul 2009 11:51:55 -0700

again. dave, many of the questions you raise _are_ covered in the
intro and requirements doc.

On Sat, Jul 18, 2009 at 11:39 AM, Dave CROCKER<[email-masked]> 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.
>
> 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.
>
> 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
> 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.
>
> 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:
>
>   3. Starting with existing ones but making whatever major changes are
> deemed "useful", or
>
> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 21 Jul 2009 17:08:37 +0100

>intro and requirements doc.
This doesn't matter. The charter should be readable without consulting 
external documents.