Subject: [ogpx] VWRAP Draft Charter: 2009 08 28 revision

From: Infinity Linden <[email-masked]>
Date: Fri, 28 Aug 2009 11:27:08 -0700

okay... here's what i think we've all agreed to. i've taken the
liberty of using the VWRAP name since it seems to me we have consensus
around that name.

also note that i still have the [email-masked] email list in the
charter text, since we don't have the VWRAP mailing list up yet.

but the rest of it should be "correct" based on discussions. please
look it over and tell me if i've missed something.

-cheers
-meadhbh

Working Group Name:

  Virtual Worlds Region Agent Protocol (VWRAP)

Chairs:

  TBD

Area and Area Directors:

  Applications Area

  Lisa Dusseault <[email-masked]>
  Alexey Melnikov <[email-masked]>

Responsible Area Director:

  TBD

Mailing List:

  [email-masked]
  http://www.ietf.org/mailman/listinfo/ogpx

Description of Working Group:

The working group will define the Virtual Worlds Region Agent Protocol
(VWRAP) for  collaborative 3-dimensional virtual  worlds. The protocol
permits  users  to  interact  with  each other  while  represented  as
"avatars,"  or digital representations  of the  user. Within  a single
virtual  world, avatars  exist in  at most  one location  in  a shared
virtual  space. Conforming  client  applications use  the protocol  to
manipulate and  move the  user's avatar, create  objects in  a virtual
world, interact  with other users  and their surroundings  and consume
and create media and information from sources inside and outside their
virtual world.

Adjacent locations  in virtual worlds accessible by  this protocol may
be   explicitly   partitioned  into   "regions"   to  facilitate   the
computational  and communication load  balancing required  to simulate
the virtual  environment. Such virtual  worlds may consist  of regions
administered  by distinct organizations.  Though these  virtual worlds
may  be partitioned,  they  remain "un-sharded;"  all inhabitants  and
objects  in a  particular location  in  a virtual  world may  initiate
interaction with  all other inhabitants and objects  in that location;
and, service  endpoint addresses  refer to at  most one  location. The
state of  a virtual  world is independent  of the  client applications
that access it and may persist between user sessions.

Regions and  services implemented according to  the specifications may
be deployed by separate  organizations with varying policies and trust
domains.  The OGPX  protocols will  provide the  mechanisms  for these
virtual world  services to interoperate, when permitted  by policy and
shared trust  domains. To support the exegesis  of the specifications,
the group  may define a  non-exhaustive set of  non-normative policies
protocol participants may enforce.

The protocol  should describe interaction semantics  for these virtual
worlds, independent of  transport, leveraging existing standards where
practical. It  should define interoperability  expectations for server
to server  interactions as well as  client-server interactions. Though
the  protocol  is  independent  of transport,  early  interoperability
trials used HTTP(S) for non-real-time messages. The working group will
define specific  features that must be replicated  in other transports
and  will  define  the use  of  HTTP(S)  as  a transport  of  protocol
messages.

Foundational components of the protocol include the publication of:

  * an abstract  type system, suitable for  describing the application
    protocol in an implementation neutral manner,

  * a   security   model   describing  trust   relationships   between
    participating entities,

  * guidelines   for   the   use   of  existing   authentication   and
    confidentiality mechanisms,

  * an application-layer  protocol for establishing  the user's avatar
    in a virtual world,

  * an application-layer  protocol for moving a  user's avatar between
    adjacent and remote locations in a virtual world,

  * format descriptions for objects and avatars in a virtual world, and

  * an   application-layer  protocol   for  identifying   agents,  and
    requesting information about them.

The protocol  defined by this  group will carry information  about the
virtual  environment,  its contents  and  its  inhabitants.  It is  an
application layer protocol,  independent of transport, based partially
on these previously published internet drafts:

  * http://tools.ietf.org/html/draft-hamrick-ogp-intro
  * http://tools.ietf.org/html/draft-hamrick-llsd
  * http://tools.ietf.org/html/draft-hamrick-ogp-auth
  * http://tools.ietf.org/html/draft-hamrick-ogp-launch
  * http://tools.ietf.org/html/draft-lentczner-ogp-base
  * http://tools.ietf.org/html/draft-levine-ogp-clientcap
  * http://tools.ietf.org/html/draft-levine-ogp-layering

Goals and Milestones:

  * October  2009   "Introduction  and  Goals"  to  the   IESG  as  an
    Informational RFC

  * October 2009 "Abstract Type System for the Transmission of Dynamic
    Structured Data" to the IESG as Proposed Standard

  * October 2010 "Foundational Concepts and Transport Expectations" to
    the IESG as Proposed Standard

  * February 2010 "Guidelines for  Host Authentication" to the IESG as
    an Informational RFC

  * February  2010 "Service  Establishment"  to the  IESG as  Proposed
    Standard

  * February 2010  "Client Application Launch Message" to  the IESG as
    an Informational RFC

  * February 2010  "Simulation Presence Establishment" to  the IESG as
    Proposed Standard

  * June  2010  "Primitive Object  Format"  to  the  IESG as  Proposed
    Standard

  * June 2010 "Digital Asset Access" to the IESG as Proposed Standard

  * June 2010 "Entity Identifiers" to the IESG as Proposed standard

---

From: Joshua Bell <[email-masked]>
Date: Fri, 28 Aug 2009 12:35:49 -0700

Looks like one more find/replace for "OGPX" will be necessary on the text.
:)

Also, I wonder if we should include a note around the "previously published
internet drafts" mentioning that "OGP" was an earlier name used for this
effort, to explain why many of the drafts mention OGP. Meh... probably not
necessary.

On Fri, Aug 28, 2009 at 11:27 AM, Infinity Linden <[email-masked]>wrote:

> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>

---

From: Infinity Linden <[email-masked]>
Date: Fri, 28 Aug 2009 12:46:31 -0700

nah. i actually kind of like it, cause if you put OGP or OGPX the
names in the IDs don't seem alien, and if someone googles these old
initialisms, there's a good chance they'll get the VWRAP charter
somewhere on the first page of results.

so maybe if we changed

"The protocol  defined by this  group will carry information  about
the virtual  environment,  its contents  and  its  inhabitants.  It is
 an application layer protocol,  independent of transport, based
partially on these previously published internet drafts:"

to

"The protocol  defined by this  group will carry information  about
the virtual  environment,  its contents  and  its  inhabitants.  It is
 an application layer protocol,  independent of transport, based
partially on previous work under the name "Open Grid Protocol (OGP)"
and these internet drafts, previously published in preparation for the
OGPX Birds of a Feather session:"

---

From: Morgaine <[email-masked]>
Date: Sat, 29 Aug 2009 01:49:18 +0100

>
> To support the exegesis  of the specifications, the group  may define a
> non-exhaustive set of  non-normative policies protocol participants may
> enforce.
>

I'm not sure whether to laugh or cry at this sentence in the 3rd paragraph,
but one thing's certain, it doesn't help at all.  In fact, the world would
be a far better place without it. ;-)

I would normally give reasons, but in this case the sentence is just so far
beyond the pale that with a bit of luck it'll just disappear without further
ado through universal revulsion. ;-)

Morgaine.

Plain English Campaign.

---

From: Morgaine <[email-masked]>
Date: Sat, 29 Aug 2009 03:10:06 +0100

This charter still does not mention in plain English that the group and the
protocol *will* address cross-world interop.

It is not enough to claim that cross-world interop is included through lack
of explicit exclusion.  That can lead to disputes about what was intended to
be in scope and what was not.  The charter needs to express the group's
scope clearly, that is its purpose.

What's more, because cross-world interop is the area of greatest complexity
in this work, it needs to be prominent as a deliverable.  Currently there is
not even a hint of it in the deliverables, which is a major and extremely
important omission.

Among the *Foundational Components* (the bullet list of paragraph 5), we
need a clause something like:

   - A model describing the use of the protocol for interoperation between
   multiple distinct virtual worlds and involving multiple region/agent domains
   and services.

Unless the many possible scenarios of cross-world interop are carefully
considered, the protocol has no hope of working in such scenarios.  This is
work we must do, or cross-world interop was just lip service after all.

Morgaine.

=======================

---

From: Meadhbh Siobhan <[email-masked]>
Date: Fri, 28 Aug 2009 19:46:43 -0700

i like where you're going with this, but i have to say, i really think
we should use the term "virtual world" only in a non-normative manner.
the term is simultaneously evocative as an descriptive term and a
lightning rod for disagreement when we attempt to define it.

david's work on deployment patterns should definitely be included
somewhere. i think it _would_ help people new to the group to
understand what we're working on, and it seems like what you're asking
is to talk about deployment patterns. some people might shy away from
the term "model" (myself included) in favor of "pattern" since the
latter admits more abstraction to the process.

how 'bout, "Deployment patterns for describing the use of the protocol
for interoperation between multiple region/agent domains and
services."

-cheers
-meadhbh

On Fri, Aug 28, 2009 at 7:10 PM, Morgaine<[email-masked]> wrote:
> protocol will address cross-world interop.
>
> Among the Foundational Components (the bullet list of paragraph 5), we need
> a clause something like:
>
> A model describing the use of the protocol for interoperation between

---

From: Morgaine <[email-masked]>
Date: Sat, 29 Aug 2009 12:57:27 +0100

> lightning rod for disagreement when we attempt to define it.

This has nothing to do with whether "virtual world" is used normatively or
not.  It has to do with whether our terminology allows us to discuss the
problem space, and then later whether it allows us to propose solutions that
work within that problem space.

Our problem space contains *multiple virtual world*s which need to be able
to interoperate, fully independent worlds employing a common VWRAP protocol
for interop but differing in absolutely everything else.  We need to be able
to refer to those worlds because they are first-class entities in our
problem space, and your terminology prevents us from doing so.

The suggestion that making "virtual world" normative would lead to
disagreement misses the point that it is the highly non-standard use of
"virtual world" to mean "the communicating parties" that has led to this
disagreement in the first place.  Indeed, we retained the "VW"  in "VWRAP"
because we agreed that it has a generally accepted meaning.

And it does.  In these days of interplanetary travel, the meaning of "world"
is quite universal, and communication between worlds is an established
physical process.  The virtual analogues in "VW" and "VW interop" have
exactly the same semantics.

There are no disagreements at the implementation level about this because
each implementor determines individually whether they are building a virtual
world or not.  LL knows that SL is a virtual world, and the owners of OSgrid
know that OSgrid is a virtual world, and so will GALACTICuniverse and so
will DRAGONSworld.  The only thing that matters to us is whether those
worlds employ VWRAP, and if they do so then interop between them is clearly
in scope.

Attempting to define "virtual world" prescriptively would of course create
disagreement, but that is *neither intended nor required here*.  We are not
defining what worlds are like, but only how worlds communicate --- the only
definition of "virtual world" that is required to enable cross-world interop
is *as an endpoint of a communication*.

Specifically, our terminology must be able to handle "avatar A teleports
from region R1 in world W1 to region R2 in world W2".  The virtual worlds W1
and W2 are key entities in our problem space because they are sets of
regions and services which can be either disjoint or intersect in one or
more elements.  Those sets are crucially important to everyone concerned, as
they define the identity and flavour and ownership and policies that make
each virtual world distinct and interesting in its own right.

Your redefinition of "virtual world" no longer allows us to discuss those
endpoint worlds as distinct entities.  When we cannot talk about world W1
and world W2, this presents a near-total impediment to delivering
cross-world interop between them.

Perhaps the question should be turned around.  Why do the current OGP
documents redefine "virtual world" contrary to common usage and seek to bar
multiple virtual worlds from the discussion space?

Morgaine.

================================

On Sat, Aug 29, 2009 at 3:46 AM, Meadhbh Siobhan
<[email-masked]>wrote:

> > On Fri, Aug 28, 2009 at 7:27 PM, Infinity Linden <[email-masked]
> >
> > wrote:
> >>

---

From: Carlo Wood <[email-masked]>
Date: Sun, 30 Aug 2009 02:30:55 +0200

> that access it and may persist between user sessions.

Going with the definition that "virtual world" is from the perspective
of the user (every place reachable), I think that using "a virtual world"
is less confusing, and I'd rewrite the above paragraph as follows:

Adjacent locations in a virtual world accessible by  this protocol may
be   explicitly   partitioned  into   "regions"   to  facilitate   the
computational  and communication load  balancing required  to simulate
the virtual  environment. Such a virtual world may consist  of regions
administered  by distinct organizations.         Though virtual worlds
may  be partitioned,  they  remain "un-sharded;"  all inhabitants  and
objects  in a  particular location  in  a virtual  world may  initiate
interaction with  all other inhabitants and objects  in that location;
and service  endpoint addresses  refer to at  most one  location.  The
state of  a virtual  world is independent  of the  client applications
that access it and may persist between user sessions.

(also removed the comma after 'and').

> domains.  The OGPX  protocols will  provide the  mechanisms  for these

s/The OGPX protocols/VWRAP/

> protocol participants may enforce.

s/protocol/that protocol/

> worlds, independent of  transport, leveraging existing standards where

Idem, in order to not confuse people in thinking that the collection
of all reachable regions exists of multiple virtual worlds, I'd use
"a virtual world" here. Thus:

The protocol  should describe interaction semantics  for the regions of
a virtual world independent of  transport, leveraging existing standards where

>   * June 2010 "Entity Identifiers" to the IESG as Proposed standard

However, I remain sceptical about the lack of stressing
the importance of making interop possible as much as possible
between regions where little overlap in ToS exist, or only partial
trust exists.

Imho, the whole effort of this group is meaningless unless the end result
will make it possible for many independent parties to take part in
creating one big virtual world. The more (policy) restrictions are
*necessary* for an acceptable interop, the less this effort will
have succeeded; hence, it should be an important, of not the most
important goal of this working group!

-- 
Carlo Wood <[email-masked]>

---

From: Meadhbh Siobhan <[email-masked]>
Date: Sat, 29 Aug 2009 17:54:08 -0700

> important goal of this working group!

+1

---

From: Morgaine <[email-masked]>
Date: Sun, 30 Aug 2009 10:25:58 +0100

> > important goal of this working group!

That expression of support looks promising.  The main barriers preventing us
from achieving this are:

   1. Our inability to even discuss multiple virtual worlds because the
   language in the drafts overloads the term with a fictitious new "virtual
   world" that clashes with the normal usage.
   2. The lack of a listed deliverable that would require us to ensure that
   the proposed protocol does actually deliver interop between distinct virtual
   worlds that implement VWRAP.

I hope we can turn the expressed desire for cross-world interop into
something concrete.

Morgaine.

==========================

---

From: Kari Lippert <[email-masked]>
Date: Sun, 30 Aug 2009 08:05:32 -0400

My two cents....

The first paragraph (where the purpose is being laid out) says:

Conforming  client  applications use  the protocol  to manipulate and
move the  user's avatar, create  objects in  a virtual world, interact
 with other users  and their surroundings  and consume and create
media and information from sources inside and outside their virtual
world.

I normally lurk in this group but I have to say this surprised me.
This statement says that I will use this protocol within my virtual
world, not that I will use this protocol to interface with different
virtual worlds. This doesn't speak to what I thought the thrust was -
interoperability of worlds for transportability of avatars. While once
could argue that the use of the same protocol intra-world would help
in the inter-world communication, this is not the case and should not
be assumed to be so. I'm actually saddened that you're all thinking of
interoperability as achievable only if everyone uses the same
intra-world protocol.

"Enforcing" the use of a standard intra-world for every world will be
impossible and quite possibly viewed as some by an intrusion into
their IP, not to mention that it would kill innovation. Transfer
between worlds will be lossy: existing worlds are not the same, nor do
they have the same types of virtual property associated with them.
This standard is going to either have to address the bare minimum, or
become obsolete prior to completion with the introduction of a novel
virtual world into the virtual universe.

I concur with many of the discussions that have been put forth
regarding this draft and have the following suggestions:

Infinity Linden - good rewording to include OGP history; too confusing
to leave in the main body (a reader will think it a typo)

Morgaine - agree to remove sentence that begins "To support the
exegesis  of the specifications..."

meadhbh - deployment patterns are very different from models of
protocols; deployment patterns may be useful but should not replace a
good model

Morgaine - agree with the addition of the Foundation Component but
argue that it should also be the focus in the first paragraph of the
description

meadhbh/Morgaine/Carlo - redefinition of virtual world is a bad idea
but what you are really talking about is the virtual universe as
composed by a variety of virtual worlds - and I like the plain English
of Region 1 in VW 1 to Region 2 in VW 2 expression put forth as it is
very clear, easily understood, not easily misunderstood,  and I
believe captures the intent of the standard to be developed

Once we figure out the focus (which I take to be inter-world, or
cross-world, transfer) then we can begin capturing the requirements
for a "successful transfer". From that the model, the deployment
pattern(s), the conformance guidelines, and other associated parts of
the standard will come. So I ask, what is the focus (purpose) of the
working group? Why are you making all this effort? Is it to bring the
multitudes of virtual worlds to one protocol or to make transfer
between them possible? I posit those are two different standards and
only the latter is worth standardization.

<step off soapbox>
My two cents anyway....

Kari

---

From: Carlo Wood <[email-masked]>
Date: Sun, 30 Aug 2009 14:24:22 +0200

> is less confusing, and I'd rewrite the above paragraph as follows:

After reading Morgaine's comments, I have to agree with her ...

There is no consensus on the way you defined Virtual World. I'm very
unhappy with it.

The only argument you gave was that (in the future) a "world" would
be perceived by users as all regions reachable and that it would be
confusing to talk about multiple worlds for that reason.

But that's not really a good argument; "World" and "Planet" are close
enough for not seeing any reason not to allow multiple worlds
to be reachable without confusing users, after all, you can also
travel to different planets.

For the working group and our effort however it is, I feel, ESSENTIAL
that we come to an agreement on what 'Virtual World' means and
everything seems to scream "Second Life" / "OSGrid" / kgrid / DragonsWorld
and all-what-not: the currently existing, independent worlds that
seek interop. That is what most people think of when you say "a virtual world".

In the end we'll have simulators, or regions, partitioned land,
for scalability reasons.

Simulator:

	R

Some regions will be adjacent, forming one "island", or just "land".

Island/Land:

      RRRRR
     RRRR
     RRRRR
      RR 

These Regions might be run by different administration, but I'm sure
there can be consensus about them being tightly bound in terms of
regulations; for example, the same ToS, the same set of accepted
Agent Domain Providers, and so on. In fact, so tight that it's
not worth mentioning. This is what YOU think of when we talk
about "multiple administrations" that form one World.

Lets envision this by using an 'r' for a different administration:

Island/(main)land/continent:

      RRRRR
     RRRR
     Rrrrr
      rr 

But no new word other then "distinct organizations" is needed.

Then, of course, there can be more than one island. I have to agree
with Morgaine here that it is NOT wise to use the word "World" here,
simply because of the major confusion. The charter is full of
sentences with the word World used in this way however; so you
cannot delay it's definition.

Note that there is no need to use more than two "distinct organizations"
for a set of islands under one tight regulation, like a single
island, like "Second Life" at the moment. Lets call THAT "(virtual) world":

Virtual World (W):

      RRRRR	          
     RRRR       rr          
     Rrrrr      rr            RRRR
      rr             R  R      RRR

	      rrrr
	      rrrrrr
	       rrrrRRRR
                  RRRRRR
		    RRRRR

Then finally, we have multiple Worlds, each of which should as
much as possible allow to be separated in terms of administration
and regulations as much as possible. This will not be anything
as tightly coupled as (the administration) of a single island,
or a World like "Second Life".

Lets call a collection of collaborating Worlds (that have at least
SOME interop and (thus) all use VWRAP) "Galaxy" for now:

Galaxy:

    W   X

    Y   Z

Again (from a previous post), I think that the coupling between
these "galaxies" are the real challenge of this group, comprising
a very important goal of our task. Special care and attention
WILL be needed, as opposed to the coupling of two R's, or even
on R and a an 'r': that already exists (ie, Second Life) and it
will be easy to write down what protocol is used there, since
we can assume any level of trust at *that* level.

We need to aware at a very early point that this difference exists,
and thanks to Morgaine, we are-- or at least, I am at this point.

We NEED a new term, if only for internal use within this group.

I propose "Galaxy" (to replace your definition of "Virtual World")
and then use the term "Virtual World" for (sets of) Region Domains
where we need to concentrate on demanding as little as possible
in terms of trust or regulations in order for the protocol to deliver
some form of interop.

---

From: Carlo Wood <[email-masked]>
Date: Sun, 30 Aug 2009 14:31:15 +0200

/me notes that Kari also uses the term "Virtual World" in the
same way as Morgaine, and me, and many others.

(In fact, so far only Infinity has used it in a different way,
that I know of)

---

From: Carlo Wood <[email-masked]>
Date: Sun, 30 Aug 2009 14:35:26 +0200

> exegesis  of the specifications..."

That was added to allow to avoid confusion that did arise here
about the difference between policy and protocol.

I think it will make the end-document a lot more clear if we are
allowed to give examples that include how policy may be implemented
using the protocol, even though the protocol itself will have no
notion of policies at all.

[...]

+1

---

From: Kari Lippert <[email-masked]>
Date: Sun, 30 Aug 2009 08:58:05 -0400

> notion of policies at all.

Absolutely, I agree. However, I don't think this needs to be stated in
the charter.

(That makes 4 cents... I'm almost at my daily limit!)

Kari

---

From: Morgaine <[email-masked]>
Date: Sun, 30 Aug 2009 15:12:02 +0100

Kari, that was an excellent review of a long series of subthreads.

You have identified something that the rest of us seem to have missed:  that
OGP / VWRAP conflates the protocol(s) used to implement a single virtual
world with the protocol(s) used to implement interop between multiple
virtual worlds.  No wonder we have a severe problem.

That was a very insightful observation, kudos.

The protocol used to implement a given virtual world is *an implementation
detail* of that world.

Is VWRAP intended to be an implementation protocol for a VW, or an *interop
protocol* between them?

Morgaine.

=====================================

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 30 Aug 2009 07:41:01 -0700

Carlo Wood wrote:
>    I think that using "a virtual world"

This reads well, with two exceptions:

Minor:
      Though virtual worlds may be partitioned
      ->
      Though a virtual world may  be partitioned

Substantial:

      The meaning and import of "un-sharded" is missing.  From the last time I
asked about this, I gather the term is familiar in VW circles, but it sure isn't
in the IETF or, I believe, anywhere outside /some/ database and /some/ or all VW
environs.

      Note that the language, here, is saying that it is /not/ sharded.
Jumping into a negative reference like this suggests that sharding is to be 
expected.  Is it?  Why?  Is reference to sharding essential for the charter?  Why?

      So, this reduces down to two different issues.  One is a concept and the 
other is a vocabulary term.  If the concept is essential, what's some terse text 
that makes sense for the charter?  If the term is essential, marry it to that 
terse text.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 30 Aug 2009 08:40:10 -0700

Folks,

Pre-game.

Confusion and disagreement that includes the term "virtual world" is proving
tenacious, in spite of extensive and substantive discussion.  Typically,
something this persistent means either that some concept(s) lack shared
definition or that competing technical paradigms are present.

As was noted many message ago, there's a good chance that much of the
disagreement is really about the meaning of the term.  That is, that apparent
disagreements about such things as scope of work is really about scope of this 
one term.  That, at least, is my own reading of the discussions.  I think people 
are using the term differently.  If we can get to the point of using it the same
way, my sense is that we will find that disagreements about actual work to be 
done, and its use, are rather small.

In other words, I think the persistence of debate that keeps using that term 
"virtual world" means we have to resolve it before we can make serious progress. 
These sorts of things never seem to go away without explicit resolution.  While 
much of the earlier attempts to resolve this look like they helped quite a bit, 
it seems clear that a bit more effort is needed.

The wind-up.

Since the crux of the challenge keeps coming back to what interoperability will
or will not be provided -- with at least one additional point about whether the
current work must be used internal to a service or only used /between/ services
-- permit me a moment of theft from Internet history and constructs.  I think it
can be applicable here:

    Network vs. Internetwork.

    "A" virtual world vs. Multiple virtual worlds.

But hold on.  I'm not necessarily going to suggest mapping the two sets as
one-to-one directly...

Originally, a network was a discrete technical set.  X.25.  NCP.  XNS. Netware.
Whatever.  Both technology and administration had the same boundary.  Your
network might use one technology and mine might use another.  But even if they
used the same technology, one was mine and the other was yours.  So I tend to
view interaction across administrative boundaries as far more interesting to
internetworking than whether different technologies are used:

    <http://www.faqs.org/rfcs/rfc1775.html>

The term Internet has come to mean a single, unified, global service.  It
crosses administrative boundaries.  Does IBM internally operate a 'network' or
an 'internetwork'?  Either choice is reasonable, depending on what is the focus. 
I think we don't need to resolve the equivalent question here.

There is universal agreement that there is a single global service, comprising 
many independent smaller services, and that that single, larger thing is "The" 
Internet.

What we tend to forget is that there probably are other Internets that don't
(directly) interoperate with the global one.  They are off "The Internet" grid
and are on their own.  They are likely also "an" Internet.  These days, they
might be running TCP/IP, but they don't have to.  For example:

    <http://www.dtnrg.org/wiki>

Some uses of "virtual world" appear to mean an administrative boundary and 
others appear to mean a technical boundary. This is the sort of thing we need to 
resolve.

The pitch.

I suggest ignoring technical differences within an administrative domain and
even across different administrative domains.  Simply, VWrap is used to connect 
together administrative domains running simulations.

      I'm running one simulation and you are running another.  We use
      VWrap to interoperate.

      Are we connecting two virtual worlds or is the result a single
      virtual world?

Some other folk might not interoperate with our unified service.  They are
running their own thing.  Are they running a different virtual world or,
perhaps, a different set of multiple virtual worlds?

The swing.

I suggest that:

      Any set of independent administrative domains that interoperate
      together, using VWrap, creates a /single/ virtual world.

      Each independent administrative domain is running /part/ of that single
      virtual world.  (The part might be one Region, or Agent, or it might be
      many of both or any combination.)

      Hence, I am suggesting that an integrated VWrap environment has a
      comparable quality to an integrated internet environment that we call
      "The" Internet.  One service.

If you are running a simulation that is not part of an integrated, interoperable
VWrap environment, you are in a different virtual world.

      If you are part of an interoperable VWrap service, you are in a
      single virtual world.

It doesn't matter what you run internally.  What matters is integration to the
interoperable service using VWrap.

Base hit or strikeout?

d/
-- 

   Dave Crocker

---

From: Meadhbh Siobhan <[email-masked]>
Date: Sun, 30 Aug 2009 09:36:22 -0700

hey kari. thanks' for chiming in.

> interoperability as achievable only if everyone uses the same

we do not define the term "virtual world." there is considerable
disagreement as to what the term means. in the previous effort (MMOX)
we attempted to start talking about the term and discovered there was
considerable disagreement as to what it meant. part of the reason the
OGPX BoF was formed was to illuminate a smaller section of the problem
domain. in the part of the problem domain we are choosing to work on,
we do not discuss interoperability between "virtual worlds" as this
term is not used normatively. instead, we define the terms "region
domain" and "simulator" and "agent domain" and a few others and define
interoperability expectations and protocol between _them_.

morgaine uses the term "virtual world" to mean what we call a "region
domain." so if this is your definition, then we are talking about an
inter-virtual world protocol.

we are shying away from using it in this effort because it's use was
so contentious in previous standardization efforts (VWIF, AWG, MMOX.)

interoperability of avatar formats is one aspect of this protocol, but
not the only one.

it should also be noted that we are not attempting to say that our
model is the _ONLY_ valid models for virtual worlds. this is one of
the reasons that OGPX is a distinct effort from MMOX. MMOX retains the
wider focus, and as i understand it, there's no reason someone else
can't continue it's work, or define a separate part of the problem
domain and form another working group.

> virtual world into the virtual universe.

unlike MMOX, we are not attempting, in this group, to define a generic
protocol to be used by every virtual world. OGPX is intended to
provide interoperability, not between worlds, but between hosts that
work together to simulate a virtual world.

nor are we trying to mandate a virtual world protocol that everyone
MUST implement. in the same way that POP3 did nothing to supplant the
use of Microsoft's proprietary Exchange protocol, or from the effort
to define IMAP, we think that the OGPX/VWRAP effort will cover one
part of the problem domain.

> protocols; deployment patterns may be useful but should not replace a

are we talking about a processing model? we really want to define a
processing model for conforming implementations?

> believe captures the intent of the standard to be developed

again. this is one of the reasons we're trying to focus on terms we
have agreement on.

> only the latter is worth standardization.

we've actually been working on a focus for the past six months. first
we were broad with MMOX, but couldn't get agreement. then with OGPX we
stated a focus on what's come to be called "second life-like" worlds.
the focus of the group is to define an interoperability profile and
protocol, deployment patterns and processing expectations for these
worlds.

---

From: Meadhbh Siobhan <[email-masked]>
Date: Sun, 30 Aug 2009 09:53:51 -0700

morgaine, i don't think this is a consensus view of the protocol implementers.

MMOX was the effort to define inter-world interoperability. that
effort could not reach consensus in a reasonable time frame. this
effort was organized to constrain the problem domain to define
interoperability between systems that implement a virtual world, not
to define a protocol for inter-world interoperability.

the practical consequence of this constrained scope include:

a. we're not working on a protocol for interoperability between worlds
with radically different operating assumptions. (i.e. - this is not a
protocol intended to provide interoperability between WoW, EVE Online
and Second Life.)

b. we're not working on a protocol that requires all systems that
implement it to be part of the same "virtual world" (defined from the
perspective of user.) that is, deployers of systems that implement the
protocol may, but are not required to interoperate with other
deployers.

the OGPX effort does not preclude this work, but avoids it because it
does not want to repeat the failures of MMOX.

-cheers
-meadhbh

On Sun, Aug 30, 2009 at 7:12 AM, Morgaine<[email-masked]> wrote:
> The protocol used to implement a given virtual world is an implementation
> detail of that world.
>
> Is VWRAP intended to be an implementation protocol for a VW, or an interop
> protocol between them?
>
> Morgaine.
>
>
>
>
>
>

---

From: Meadhbh Siobhan <[email-masked]>
Date: Sun, 30 Aug 2009 10:13:26 -0700

>     Though a virtual world may  be partitioned

hmm... i thought we had changed that to "Though these virtual worlds
may be partitioned"

> in the IETF or, I believe, anywhere outside /some/ database and /some/ or

the text reads:

"Though these virtual worlds may  be partitioned,  they  remain
"un-sharded;"  all inhabitants  and objects  in a  particular location
 in  a virtual  world may  initiate interaction with  all other
inhabitants and objects  in that location; and, service  endpoint
addresses  refer to at  most one  location."

the clause after "they remain un-sharded" is the definition we use for
sharded worlds. we could change this to:

"Though { these virtual worlds | a virtual world } may  be
partitioned,  they  remain "un-sharded;"  that is, all inhabitants
and objects  in a  particular location  in  a virtual  world may
initiate interaction with  all other inhabitants and objects  in that
location; and, service  endpoint addresses  refer to at  most one
location."

> expected.  Is it?  Why?  Is reference to sharding essential for the charter?

we introduce the relationship between VWRAP region partitioning to
sharding, because sharding is well understood with a wider audience
than region partitioning. the intent is to further define region
partitioning.

> other is a vocabulary term.  If the concept is essential, what's some terse
> text that makes sense for the charter?  If the term is essential, marry it
> to that terse text.
>
> d/
>
> --
>
>  Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 30 Aug 2009 10:37:23 -0700

> hmm... i thought we had changed that to "Though these virtual worlds

I'll admit to the preference expressed in my later note, which is that vwrap 
talk about exactly one virtual world.  That is, the set of interoperable regions 
that use vwrap to do the interoperating defines a single virtual world.

If the group preference is to say something like a virtual world is defined as a 
cohesively administered domain - of one or more regions -- and that the 
interoperation of these is multiple virtual worlds, then something like the 
existing use of plurals is probably better.

> location; and, service  endpoint addresses  refer to at  most one

Ok.  And your point that the term shard is common amongst vw folk also explains 
the desire to have it in the charter.  And I think I understand why the negative 
reference to it makes sense here.  Hmmm.  I think what this really means is that 
the explanatory "that is" sentence is really the focus.  So I suggest making it 
be that:

      All inhabitants and objects in a particular location in a virtual world 
can initiate interaction with all other inhabitants and objects in that 
location.  That is, the virtual world can be partitioned, but it remains 
unsharded.  Also, service endpoing addresses refer to at most one location.

Further hmmmm...  "in that location" doesn't say that the interaction can cross 
administrative domains or regions.  So is the non-sharding within a single 
administrative environment, or is it across boundaries that use vwrap?

(By the way, I'm still not understanding the relationship between a "location" 
and a "region".  The text essentially defines a region, but not location.)

d/
-- 

   Dave Crocker

---

From: Morgaine <[email-masked]>
Date: Sun, 30 Aug 2009 19:05:09 +0100

Meadhbh has misrepresented the points that are being made.

On Sun, Aug 30, 2009 at 5:53 PM, Meadhbh Siobhan
<[email-masked]>wrote:

> *with radically different operating assumptions*. (i.e. - this is not a
> protocol intended to provide interoperability between *WoW, EVE Online*
> and Second Life.)
>

Nobody has ever referred to anything that might fall under the scope of MMOX
here.

This discussion has been entirely about interoperation between worlds that
implement OGP/VWRAP, and to put it even more strongly, SL-compatible worlds,
such as Opensim-based worlds and SL itself.

Continually adding an irrelevant detail like "radically different
assumptions" and naming "WoW, EVE Online" only to reject them is a plain
straw man.  It does not help advance the discussion.

Morgaine.

====================================

---

From: Kari Lippert <[email-masked]>
Date: Sun, 30 Aug 2009 14:20:01 -0400

The network/internet analogy is great. I vote base hit.... and would
like to emphasize that, given current usage of the words, the answer
to

>     Are we connecting two virtual worlds or is the result a single

is yes, sort of.

As I understand it, VWRAP is designed to connect/allow
interoperability between two or more independent/distinct/individual
virtual environments/regions/worlds into what appears to the user as a
single environment/region/world/universe. This single
environment/region/world/universe is in fact multiple
independent/distinct/individual virtual environments/regions/worlds
whose boundaries could be administrative or technological but the
distinction matters not.

Is that right?

Kari

On Sun, Aug 30, 2009 at 11:40 AM, Dave CROCKER<[email-masked]> wrote:
> disagreements about such things as scope of work is really about scope of
> this one term.  That, at least, is my own reading of the discussions.  I
> think people are using the term differently.  If we can get to the point of
> using it the same
> way, my sense is that we will find that disagreements about actual work to
> be done, and its use, are rather small.
>
> "virtual world" means we have to resolve it before we can make serious
> progress. These sorts of things never seem to go away without explicit
> resolution.  While much of the earlier attempts to resolve this look like
> they helped quite a bit, it seems clear that a bit more effort is needed.
>
>
>
> The wind-up.
>
> an 'internetwork'?  Either choice is reasonable, depending on what is the
> focus. I think we don't need to resolve the equivalent question here.
>
> There is universal agreement that there is a single global service,
> comprising many independent smaller services, and that that single, larger
> thing is "The" Internet.
>
> others appear to mean a technical boundary. This is the sort of thing we
> need to resolve.
>
>
>
> The pitch.
>
> even across different administrative domains.  Simply, VWrap is used to
> connect together administrative domains running simulations.
>

---

From: Meadhbh Siobhan <[email-masked]>
Date: Sun, 30 Aug 2009 11:34:18 -0700

so. this is an interesting one.

those of us who called for the OGPX BoF are in agreement that the term
"virtual world" is informational only. it is evocative of the problem
domain, but yeah, difficult to pin down. we explicitly used the terms
"region domain" and "agent domain" and "client application" to avoid
having to define the term "virtual world."

our intent is to define terms that are consensus based, germane to the
standards effort and necessary.

i think introducing "virtual world" as a normative term would be akin
to introducing terms for "the web" or "an intranet" to a protocol
document like RFC2616. it is informational, but not a requirement to
specifying the protocol. further, defining "the web" or "an intranet"
or a "virtual world" may artificially limit future options.

for example, when HTTP was first under development, important features
of "the web" weren't deployed (like the "behind the firewall"
deployment pattern commonly thought to be core to the term "intranet"
or the wide-spread use of ECMAscript for enhanced interactivity in web
applications.)

my feeling is that we're at the same place with "virtual worlds" right
now; we're at the beginning of process rather than the end. defining a
"virtual world" to be limited to a specific area of the problem domain
could be interpreted as precluding this protocol's use in other, yet
to be imagined, applications. imagine, for example, that at the time
that HTTP just started attracting attention and people started using
the term "the web" someone suggested that gopher sites should not be
considered part of "the web."

this actually did happen... i was actually in a conversation in 1993
where people asked whether it was considered appropriate for legacy
gopher services to be accessible while their content was moved to HTTP
access. because the ambiguously defined term "the web" was introduced
into a formal statement of work, we had to actually spend cycles
defining it. ultimately we were able to do this because the term is
defined in an ambiguous manner; we were able to argue that the web
should be defined in terms of the content accessible to the user, and
not in terms of the protocol used to access that content or in the
precise manner it is deployed. had the term "the web" been defined at
that time to be limited to information accessible via HTTP, there
would have been unfortunate and unintended consequences.

this is why a number of us are concerned with efforts to define the
term in a normative fashion.

if we start by saying the virtual world is defined as being "all the
places an avatar can go," does this mean that information that comes
into the virtual world by way of web protocols, from web sites
intended to be used by traditional web browsers is or is not part of
the virtual world? or what about two "worlds" that only share a single
region? are they simultaneously part of the same "overworld" and part
of distinct "subordinate worlds"?

but still... part of the reason we came to this forum was to get
feedback, and it's starting to sound like we want to have at least a
working definition of the term, if for no other reason than to evoke
an intuitive understanding of the problem domain.

if we want to define a meaning for the term "virtual world," let's be
clear that the definition is non-normative.

for related reasons, i'm reticent to say that the collection of
distinct existent virtual worlds combine to make "the" virtual world.

is it possible to move the definition of "virtual world" to the intro
document? i would assert we have sufficient interest in the problem
domain to establish a working group, and that the definition of the
term "virtual world" is orthogonal to this group's initial efforts.
(why do we need to get hung up on the definition of the term when the
specifications do not use the term in a normative fashion? it's like
saying we can't work on HTTP because we can't decide whether resources
accessed by GOPHER are part of "the web.")

-cheers
-meadhbh / infinity

---

From: Kari Lippert <[email-masked]>
Date: Sun, 30 Aug 2009 14:37:06 -0400

My bad - I thought this was, in fact, a continuation of the MMOX
effort. I stand corrected.

In defense of my earlier thoughts....
> disagreement as to what the term means.

Yes, and this is the core of the problem.

>  in the part of the problem domain we are choosing to work on,

Missed the part where those were defined, although I think the group
charter should not rely on having to include
definitions/redefinitions. I was thrown by the words "region",
"domain", and "agent" as they all have pretty strong meaning which
didn't quite fit for me. Not that it can't be done this way, it's just
going to be hard because you're creating definitions for a terms in a
context where they are already used.

> inter-virtual world protocol.

Awesome!

> interoperability of avatar formats is one aspect of this protocol, but

So if I have a virtual place that implements the VWRAP protocol I can
do more than move avatars - again, awesome. I will refer here to the
other email regarding the "subsumption theory of virtual places".

> domain and form another working group.

MMOX is dead (or just resting)? I really did think this group was one
and the same.

> work together to simulate a virtual world.

So it is a generic protocol to be used by every "unit" that wishes to
become part of the whole. You will still need enforcement, compliance
measures, etc.

> processing model for conforming implementations?

I was actually talking about a protocol model, not a process model. A
process model is not necessary; definition of what entails conformance
will be.

> protocol, deployment patterns and processing expectations for these

This isn't quite what the charter says, which is what I was getting
at. There are a couple of very key points missing which have been more
or less fleshed out in these various emails today.

Kari

---

From: Meadhbh Siobhan <[email-masked]>
Date: Sun, 30 Aug 2009 11:50:46 -0700

> whose boundaries could be administrative or technological but the

this is an interesting use case, but not what OGPX/VWRAP was proposed
to address.

MMOX remains as a venue for the discussion of integrating technically
diverse virtual worlds.

---

From: Kari Lippert <[email-masked]>
Date: Sun, 30 Aug 2009 14:54:50 -0400

> of distinct "subordinate worlds"?

Consider the "explosion" of "virtual" 3D "world" spaces such as those
associated with http://www.gogofrog.com/. I don't think this is quite
what is desired at this point, nor do I think we have to tackle the
elephant "all the places an avatar can go".

> an intuitive understanding of the problem domain.

More than that, to include a term that will be defined later in the
charter is inviting discord and misunderstanding.

> document?

It must be - and a new, less overloaded word (or acronym) could be
used instead. I saw some great acronyms earlier (those folk may have a
future with the government!) so wondered if the easiest way out is to
establish a term that is what we mean.

> accessed by GOPHER are part of "the web.")

IMHO, I think a decision was made when work on HTTP was begun and that
was to exclude gopher sites. I don't know if that was done to allow
the work to proceed technically or to deal with an issue that could
well have been exactly like this.

I believe our problem only comes when someone not privy to all the
back conversation comes to the charter and misinterprets. I sense a
decent consensus within this group but a lack of proper vocabulary to
express the concepts.

Kari

---

From: Kari Lippert <[email-masked]>
Date: Sun, 30 Aug 2009 14:58:11 -0400

> MMOX remains as a venue for the discussion of integrating technically

So OGPX/VWRAP is being proposed to address the problem of the
integration of non-technically diverse virtual worlds all implementing
the same protocol?

Perhaps I should interact with the MMOX group. Since I thought I was,
can you point me in their direction? Thanks!

Kari

---

From: Meadhbh Siobhan <[email-masked]>
Date: Sun, 30 Aug 2009 12:34:24 -0700

> elephant "all the places an avatar can go".

we are not proposing a protocol that will span technically distinct
virtual worlds. we are defining a protocol for interoperation between
systems that share common assumptions about a virtual world. (which
are defined in the intro doc, and were mentioned in the charter until
the consensus was to remove them.)

MMOX was setup to address the problem interoperability between worlds
that do not support the same set of operating assumptions.

> charter is inviting discord and misunderstanding.

cool. i think this means we're in agreement.

> establish a term that is what we mean.

yeah. i think there was a lot of pairwise discussion about this before
and after the BoF in Stockholm. If I remember correctly, a lot of us
felt that though the term "virtual world" had baggage, it was so
evocative, it's use was warranted. don't know if you saw the previous
discussion about reasons how we figured out that the name OGP was
sub-optimal for use in the IETF.

and. it looks like we're starting to hum on the name, and it includes
the term "virtual world."

maybe the thing to do would be to use the term "virtual world" in an
expressly non-normative manner in the charter and introduce a term
like "virtual social space" in the intro to further refine the
consensus view of what we're working on.

> well have been exactly like this.

sorry. i think i was unclear in my example. i wasn't saying that
GOPHER should be considered part of HTTP, but whether the term "the
web" should be considered to include information resources accessible
by a web browser or simply all resources accessible by HTTP. as it
turns out, browsers from that era dutifully spoke GOPHER as well as
HTTP.

---

From: Meadhbh Siobhan <[email-masked]>
Date: Sun, 30 Aug 2009 12:48:52 -0700

OGPX/VWRAP is an effort to define interoperability between systems
that implement a virtual world that share a list of common features.
these features can be found in the "intro and requirements" document.

MMOX was a previous effort to address address interoperability between
"virtual worlds." A mailing list exists for MMOX, but currently seems
unreachable. It was considered a failure by some because after two
months of discussion and a face to face meeting, we were unable to
agree even on the definition of the term "interoperability." At the
MMOX BoF, we could not reach consensus, but rather than abandoning the
effort, a recommendation was made to constrain the scope of the effort
to "second life-like" worlds. This was the focus of the OGP
interoperability work over the last two years and serves as the basis
for the OGPX/VWRAP effort.

---

From: Kari Lippert <[email-masked]>
Date: Sun, 30 Aug 2009 16:09:09 -0400

> these features can be found in the "intro and requirements" document.

Super! I think this - perhaps substituting "place" for "world" - is a
very good description of the focus of the group.

>  It was considered a failure by some because after two
> agree even on the definition of the term "interoperability."

Sad (but I had to laugh as the terms we all know so well are the
hardest to reach consensus on!).

>  but rather than abandoning the

Hmmm... and what does one mean by "second life-like worlds"? User
content supporting frameworks? Or the physical computing fabric
beneath? (This question is driven more by curiosity than anything as
it sounds like there is general agreement to restrict the current work
to this more manageable subset of the problem space.)

Kari

---

From: Meadhbh Siobhan <[email-masked]>
Date: Sun, 30 Aug 2009 15:00:39 -0700

> to this more manageable subset of the problem space.)

and i forgot to mention... the definition of "second life-like" worlds
is also in the intro definition, which i repeat here:

•	The Virtual World exists independent of the participating clients.
•	Avatars 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 is managed on authoritative servers.
•	Version skew between simulation hosts be tolerable.
•	The protocol to access the state of hosts participating in the
virtual world simulation uses Representational State Transfer (REST)
style interaction over HTTP.
•	A persistent, ubiquitous identity accompanies requests between hosts
involved in the virtual world simulation.

---

From: Carlo Wood <[email-masked]>
Date: Mon, 31 Aug 2009 01:08:32 +0200

I think that any effort to work on the final wording
should be stopped until we finally agree on what "virtual world" means...

I understand that you don't want to define what virtual world means,
in which case you shouldn't use it at all in the charter and also
not in the protocol name (VWrap).

There are several levels of 'locations' in an SL-like whatever:

First, the words that are already in use by the community:

1) simulator
2) estate
3) region
4) land
5) island
6) virtual world

Then the locations that we need terms for to be able to even
TALK about them:

A) A smallest partition
B) A collection of adjacent A's run by a single administration
C) A collection of adjecent B's run by different administrations (which very likely use the same TOS etc)
D) A collection of C's that are not adjacent but still fall under the same TOS etc.
E) A collection of D's that have totally different administrations and possibly different TOS etc, but which interoperate.
F) The whole of all E's that do not interoperate, but still use VWRAP.
G) The rest that use the term "virtual world", but do not use VWRAP.

MMOX and WoW is part of G. I consider that not relevant as it should be
clear by now what is part of G and what not.

Meadhbh, do you disagree with my list(s)?
Anything you want to add, or change my rough definitions of things?

Please don't reply with "we don't want to define this" :p
We NEED to define this, or we can't TALK about this!

PS I hope it should be clear by now: the problem we are having
   is that you call 'E' "a virtual world", while Morgaine, Kari,
   me and others want to call 'D' "virtual world". Moreover,
   you do as if D or E do not exist, so that we will not
   be able to talk about them separately later on :/

   You might convince me to call 'E' "virtual world", but
   then we need a well defined term for 'D' in order to
   communicate about D, too.

   In my previous post I proposed to use "Galaxy" for E.

---

From: Carlo Wood <[email-masked]>
Date: Mon, 31 Aug 2009 01:24:16 +0200

> involved in the virtual world simulation.

Since there is no consensus about the meaning of "virtual world",
this list is pretty meaningless.

Imho, you mean to say that

•	Each 'E' exists independent of the participating clients.
•	Avatars have a single, unique presence in a given 'D'.
•	Each 'C' contains persistent objects.
•	Each 'C' may be partitioned.
•	Presence, state and simulation is managed on authoritative servers.
•	Version skew between 'A' hosts be tolerable.
•	The protocol to access the state of hosts participating in
'A' simulation uses Representational State Transfer (REST)
style interaction over HTTP.
•	A persistent, ubiquitous identity accompanies requests between hosts
involved in the 'E' simulation.

Where I defined 'A', 'C', 'D' and 'E' in my previous post.

---

From: Charles Krinke <[email-masked]>
Date: Sun, 30 Aug 2009 18:19:42 -0700 (PDT)

I'm confused with all that is going on and need to ask my two main questions again.

"Are we considering interop with virtual worlds running OpenSim which do not run agent domains but rather a similar, but not quite identical notion we call UGAIM (User, Grid, Asset, Inventory, Messaging) servers?"

"Are we considering a full handoff? That is, a user on an OpenSim grid may teleport to a SecondLife grid and retain its connection to the OpenSim UGAIM, in an analogous fashion that a user has been demonstrated to teleport from the Betagrid to OSGrid using OGP last year?"

Charles

________________________________
From: Meadhbh Siobhan <[email-masked]>
To: Kari Lippert <[email-masked]>
Cc: [email-masked]; [email-masked]
Sent: Sunday, August 30, 2009 11:50:46 AM
Subject: Re: [ogpx] one virtual world, or many?

---

From: Morgaine <[email-masked]>
Date: Mon, 31 Aug 2009 05:27:05 +0100

I support Carlo's request that we define the terms that we use before we use
them.

As Carlo's says, undefined terms should not be used in the charter or in the
group name --- it introduces uncertainty and confusion.  I would add that *even
less* should undefined terms appear in our protocol specifications, which
are relatively precise documents of interest to implementors.  If we don't
know what a virtual world is, the term should be abandoned in favour of one
that we do understand.

Carlo offers one way of defining the topological entities in our problem
space, based on size and administration, which sounds quite viable.  A
meaning of virtual world might be agreed in this way.

As an alternative, I propose a simpler and much more flexible approach:
define virtual worlds as anything that implements the required endpoints of
the VWRAP protocol.  We do not need to know anything else about them.  This
lets the people who actually design the virtual worlds decide what
constitutes a virtual world.  The only thing that interests us is that these
"virtual worlds" implement the VWRAP endpoints.

This is highly workable in practice.  After all, Linden Lab knows that SL is
a virtual world, they don't need it defined.  Likewise, the owners of OSgrid
know that OSgrid is a virtual world too, they don't need it defined.  As a
result, a definition of "virtual world" by an IETF workgroup will have
little practical effect outside of the specifications, because the
implementors will design their worlds as it suits them.  If they are to
interoperate through VWRAP however, then both LL and OSgrid will ensure that
they implement the protocol correctly, no matter their internal differences.

Note that this is the approach taken in a large number of IETF protocols:
the implementation behind the endpoint is just an *implementation detail*,
and is of no consequence as long as it implements the protocol correctly.
Precedent suggests that this is the right approach.

I believe that this is simpler, more powerful, and much more flexible than
defining "virtual world" on the basis of topology.  All we need to know is
that VWRAP endpoints are available, and not what kind of entity actually
implements them.

Morgaine.

===================================

On Mon, Aug 31, 2009 at 12:08 AM, Carlo Wood <[email-masked]> wrote:

> E) A collection of D's that have totally different administrations and
> possibly different TOS etc, but which interoperate.

---

From: Kari Lippert <[email-masked]>
Date: Mon, 31 Aug 2009 07:52:49 -0400

This sounds like a good plan.

Kari

On Mon, Aug 31, 2009 at 12:27 AM,
Morgaine<[email-masked]> wrote:
> group name --- it introduces uncertainty and confusion.  I would add that
> even less should undefined terms appear in our protocol specifications,
> which are relatively precise documents of interest to implementors.  If we
> don't know what a virtual world is, the term should be abandoned in favour
> of one that we do understand.
>
> the implementation behind the endpoint is just an implementation detail, and
> is of no consequence as long as it implements the protocol correctly.

---

From: Carlo Wood <[email-masked]>
Date: Mon, 31 Aug 2009 15:00:28 +0200

On Mon, Aug 31, 2009 at 05:27:05AM +0100, Morgaine wrote:
> As an alternative, I propose a simpler and much more flexible approach: define
> virtual worlds as anything that implements the required endpoints of the VWRAP
> protocol.  We do not need to know anything else about them.  This lets the
> people who actually design the virtual worlds decide what constitutes a virtual
> world.  The only thing that interests us is that these "virtual worlds"
> implement the VWRAP endpoints.

Very smart :)

I have just one side note here; if someone creates a 'D' (sorry, can't use
"virtual world" until we agree) using VWRAP internally too, again confusion
might arise about the exact boundary of that "virtual world" (it could be
the 'C's in that case).

But you are very correct to realize that one aspect of a region domain
run by a "single administration" (could be multiple administrations that
work very close together: a 'D' thus) is that for all we care they use
a different protocol inter-world (or extensions to VWRAP). Therefore
you can replace my definition ("administrative boundary") very well
with "VWRAP endpoints", without setting demands on internally used
protocol.

HOWEVER...

the above only applies to server-server protocol, not to server-client
protocol: "shared experience" is of utmost importance; part of our
standardization efforts is in order to make it possible for viewers
to represent "the world"/galaxy as much as possible in a consistent
way to different users, which gives rize to the need of a consistent
client protocol!

Therefore, VWRAP would not only describe the protocol between the
end-points of a virtual world ('D') but also the protocol used to
communicate with viewers (clients). Though, I guess you can see
that interface as an external boundary too.

PS. The only way to keep wild growth at bay in the client-server protocol
area, where, I expect, different 'D's (virtual worlds) will add extensions
and start to release their own viewers to support those, is to add
support for protocol negotion in VWRAP. Without support, it will still
happen, but out of control, and become a total mess.

---

From: Kari Lippert <[email-masked]>
Date: Mon, 31 Aug 2009 09:15:33 -0400

But isn't the client just another endpoint? I didn't see that a
distinction was being made referring only to server endpoints.

Kari

On Mon, Aug 31, 2009 at 9:00 AM, Carlo Wood<[email-masked]> wrote:
>> implement the VWRAP endpointst.
>
> Very smart :)
>

---

From: Morgaine <[email-masked]>
Date: Mon, 31 Aug 2009 14:57:07 +0100

Yes indeed, the client is just another protocol endpoint.

Notice that many alternative implementations of the SL viewer exist because
the only requirement is adherence to the protocol at the endpoint, with no
specific implementation or client structure being mandated.  This results in
great flexibility.

Also, it is common among the developer community to place a proxy in front
of the normal viewer, either to extend the client functionality with Jabber
IM support or to assist in protocol debugging.  This is possible because the
protocols do not mandate any particular client-side implementation, so the
proxy takes on the role of the client endpoint at one or more levels.

The ideal network protocol is one which is wholly independent of the
architecture behind its endpoints, at both client and server ends.  This
provides the greatest room for developing more efficient and scalable
implementations.  Given the importance of scalability in this area, I
believe we should strive to give VWRAP these well known benefits too.

Morgaine.

On Mon, Aug 31, 2009 at 2:15 PM, Kari Lippert <[email-masked]>wrote:

> define

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 31 Aug 2009 07:39:44 -0700

Meadhbh Siobhan wrote:
> "virtual world" is informational only. 

This calls for an alternative that hadn't occurred to me.

The charter currently has the string "virtual world" thirteen times.  And it is 
used heavily in discussions on this list.

That level use of use essentially guarantees that the string is not merely 
informative.  It really does have to have specific technical meaning that folks 
agree on.

But since this latest round suggests, once again, that gaining agreement on 
consistent technical use of the string will remain problematic, and since you 
are pointing out that there was an intent to have it NOT BE a technical term...

      My suggest is to remove all occurrences of the term from the charter,
      except for the two in the first sentence of the draft charters Description
      section.

In other words, say that vwrap provides a service in virtual world simulation, 
but then make all other references be in terms of vwrap-specific technical 
constructs.  regions, agents, etc.

-- 

   Dave Crocker

---

From: Joshua Bell <[email-masked]>
Date: Mon, 31 Aug 2009 09:05:57 -0700

> should be stopped until we finally agree on what "virtual world" means...

Please note that we are attempting to craft a CHARTER at this point that
describes the problem space that a working group will tackle. Do you feel
that we can't proceed with the creation of a working group until specific
terminology is nailed down?

> not in the protocol name (VWrap).

I believe "virtual world" is as well defined as "web site". It should not be
used in a normative fashion, but is extremely clear to lay-persons what is
under discussion, and is clear enough to distinguish the problem domain from
others (i.e. it's not tackling email, IPv6, etc).

I assert that this is sufficient for the charter. (And, personally, beyond.)

> G) The rest that use the term "virtual world", but do not use VWRAP.

If we were to agree that consensus terminology for the above concepts was
something we needed to come up with, wouldn't a Working Group be a great
place to try and achieve that consensus?

> We NEED to define this, or we can't TALK about this!

HTTP can be defined irrespective of a formal definition for "web site".

Both technical and marketing terms are extremely valuable, but shouldn't be
confused.

---

From: Joshua Bell <[email-masked]>
Date: Mon, 31 Aug 2009 09:25:30 -0700

I apologize for the potentially unclear responses. These are decidedly
non-trivial questions being asked, and demand an attempt at rigorous
answers. Saying "yes" would imply policy decisions and extensive technical
work by independent parties. Saying "no" would incorrectly imply a
limitation on the scope of the intended work.

On Sun, Aug 30, 2009 at 6:19 PM, Charles Krinke <[email-masked]> wrote:

> "Are we considering interop with virtual worlds running OpenSim which do
> not run agent domains but rather a similar, but not quite identical notion
> we call UGAIM (User, Grid, Asset, Inventory, Messaging) servers?"
>

It's unclear what you mean by "interop with" in the above sentence. What are
the end-points involved? What is the data and/or user experience being
shared?

And, of course, a protocol specification doesn't dictate implementation in
any way. Second Life today doesn't implement the parts of OGP that have been
drafted yet, and of course there is a lot more to be drafted! I couldn't say
what OpenSim will do in the future!

However, I can take a guess at your intent, but let me state my guess:

"Will the output of the VWRAP group be protocol definitions that would prove
useful for implementing movement of agents between OpenSim instances?"

To that question, I'd answer: "Hopefully, yes."

> "Are we considering a full handoff? That is, a user on an OpenSim grid may
> teleport to a SecondLife grid and retain its connection to the OpenSim
> UGAIM, in an analogous fashion that a user has been demonstrated to teleport
> from the Betagrid to OSGrid using OGP last year?"
>

First off, any such interoperation is subject to the whims of policy.

I'm unfamiliar with the details of OpenSim UGAIM, but I would posit that the
VWRAP group would define protocols that an OpenSim instance would need to
implement to support such interop with a VWRAP-implementing non-OpenSim
system. I believe UGAIM would be an "implementation detail" hidden behind
the protocol facades. This may imply that the properties of UGAIM (again,
I'm ignorant of any details) will be beneficial to the specification of the
protocols.

The worst-case analogy that comes to mind is taking a pre-web server
application and slapping a web interface (HTTP+HTML) on it. Depending on the
design of the server application, that may be trivial and clean, or may be a
hideous hack. In this case, we have the advantage that the server
application engineers are active (it's not a defunct legacy system!) and can
inform the creation of the protocol to potentially ease the migration.

Joshua

---

From: Carlo Wood <[email-masked]>
Date: Mon, 31 Aug 2009 18:48:30 +0200

I'm sorry you just ignored my list :(
Just quoting it, and then refusing to make an effort to give
those concepts a term...

As you will have noted... I NEEDED those terms in each and every
post of me since I posted this list.

So far I used 'A', 'C', 'D' and 'E' in my posts, but I refuse
to continue to do that.

If there are a few here that refuse to define a few terms for
the sake of discussions (on this list) then I will, and I will
consistently keep using those terms.

On Mon, Aug 31, 2009 at 09:05:57AM -0700, Joshua Bell wrote:
> describes the problem space that a working group will tackle. Do you feel that
> we can't proceed with the creation of a working group until specific
> something we needed to come up with, wouldn't a Working Group be a great place
> to try and achieve that consensus?
> 
>

---

From: Meadhbh Siobhan <[email-masked]>
Date: Mon, 31 Aug 2009 11:23:54 -0700

carlo.

OGP/VWRAP is the continuation of a standardization effort that has
been ongoing for about two years.

there is a history of using the terms we have listed, and we even have
deployed systems that are based on earlier versions of these specs.

if you sense reticence to stop work because people involved in this
effort choose to use a different set of definitions than the ones
you're promoting, i'm sorry.

at the end of the day, there are a number of us who would like to
continue working on virtual worlds standardization and feel we can do
it without applying a definition to a COMPLETELY non-normative term.

i am disappointed that you do not wish to continue working with us,
but i believe is speak for many of us when i say that there are much
more important things we can talk about. there is NOT consensus to
apply a definition to a non-normative term, but there is consensus to
continue working on this problem domain.

i support your effort to refine a definition of the term "virtual
world," but as the term does not appear normatively in any
specification produced to date, i have to say, your request to stop
all work on this effort until it _is_ defined satisfactorily to all
parties seems a bit obstructionist.

i am happy to continue to work on a definition with you, but not in
this forum and not until the charter is finished.

i truly value your contributions, but the reason we are here it to
define interoperability protocols, not to quibble about the definition
of terms that do not need to be defined.

-sincerely
-meadhbh hamrick

---

From: Meadhbh Siobhan <[email-masked]>
Date: Mon, 31 Aug 2009 11:38:00 -0700

charles,

we're not defining interop with respect to any currently defined platform.

the SL platform is going to need a lot of re-tooling to implement the
protocols we're supporting, and since opensim was originally based no
the SL legacy protocols, my guess is that it also will need some
retooling.

we have, however, deployed patches to opensim to implement a previous
version of OGP, so we know it's not impossible.

your knowledge of OpenSim deployment patterns is of great interest to
me personally; mostly because OpenSim tends to experiment a lot more
than SL. and honestly... the OSGrid deployment pattern of "some
centralized, some federated" services is one of the things i think all
the people working on OGP are interested in.

so i think to answer your question precisely, i'd have to invoke Zen
and say "mu!"

that is, i think it's not _completely_ related. we're not defining the
protocol in terms of the current structure of OpenSim, but i think all
of us are interested in making it possible to use OGP/VWRAP to define
a protocol that is equally useful to Linden as it is to you at OSGrid
and zha, et al at IBM as it is to anyone interested in open virtual
worlds.

so rather than saying "yeah, we're going to support this specific mode
of OpenSim," it's probably more appropriate to say, "we're very
interested in the operational experiences of people who have used
OpenSim in both stand-alone and UGAIM mode. since it's an open
standard, we invite Teravus, Adam, JHurliman and yourself to tell us
what's easy to do in OpenSim and what's hard to do, and after we get
through the chartering process, there's likely to be several more
rounds of discussions about what people think can and can't be easily
implemented and deployed."

but at the end of the day, i think there's going to be code changes
for both OpenSim, Linden and all the viewers.

-cheers
-meadhbh

On Sun, Aug 30, 2009 at 6:19 PM, Charles Krinke<[email-masked]> wrote:
> "Are we considering interop with virtual worlds running OpenSim which do not
> run agent domains but rather a similar, but not quite identical notion we
> call UGAIM (User, Grid, Asset, Inventory, Messaging) servers?"
>
>>> Since the crux of the challenge keeps coming back to what
>>> interoperability
>>> will
>>> or will not be provided -- with at least one additional point about
>>> whether
>>> the
>>> used the same technology, one was mine and the other was yours.  So I
>>> tend
>>> to
>>> crosses administrative boundaries.  Does IBM internally operate a
>>> 'network'
>>> or
>>> It doesn't matter what you run internally.  What matters is integration
>>> to
>>> the

---

From: Suzy Deffeyes <[email-masked]>
Date: Mon, 31 Aug 2009 15:07:09 -0400

Hi Infinity,

I think the Charter looks good, and I support moving forward with submitting
this to the IETF.  I think it accurately describes the scope of what we want
to do, and is clear in its description.

I am ready to move to working on the protocol and implementation. Let the
interface definitions commence!

Suzy Deffeyes / Pixel Gausman
IBM

---

From: Dan Olivares <[email-masked]>
Date: Mon, 31 Aug 2009 15:55:49 -0400

Hey there,

I think the charter looks reasonable as well.    As I said earlier,
i'm not entirely convinced the messages should all be 'HTTP' based
however, I'm willing to give it a try as a 1st protocol.   At this
point in time, I'd like to take part in discussions about the future
protocols and work with others on implementations of the server side
of the protocols so that there is some solid, result based, feedback
that can come back to this list.

Dan Olivares
(OpenSimulator core developer)

---

From: Charles Krinke <[email-masked]>
Date: Mon, 31 Aug 2009 13:42:35 -0700 (PDT)

Dear Infinity:

Thank you for your considered answer. I think our hearts are all headed in the same place. For some reason, all this discussion of names has my head spinning. 

But, ... that aside, as I look at interop between different grids (or virtual worlds, if you wish), I see these as analogous to transitting customs between countries.

That is, there will be some things that will connect back to ones home or originating country and some things that are intrinsic to the country one is visiting, to try to draw an analogy.

The things connecting back to ones home country (or grid, if we prefer), will most likely be the avatar, inventory and attachments, or at least part of the inventory and all of the avatar and attachments.

The things intrinsic to the country one is visiting will most likely be the rules dealing with transactions such as buying and selling objects, permissions of editing, and ability to visit certain parts of the visiting country.

To me, as long as that is a reciprocal relationship, that is, a visit from a SecondLife grid to an OpenSim is a mirror image of permissions to a visit from an OpenSim grid citizen to a SecondLife grid, then I think my enthusiasm is still "full speed ahead regardless of whether we call a pear a banana or not".

Charles

________________________________
From: Meadhbh Siobhan <[email-masked]>
To: Charles Krinke <[email-masked]>
Cc: [email-masked]
Sent: Monday, August 31, 2009 11:38:00 AM
Subject: Re: [ogpx] one virtual world, or many?

charles,

-cheers
-meadhbh

---

From: Infinity Linden <[email-masked]>
Date: Mon, 31 Aug 2009 14:28:53 -0700

hmm... okay... i think i see what you're saying.

i would paraphrase it as "if you're not proposing using the term
'virtual world' to mean something with a specific meaning, maybe use
it a couple times in the beginning of the charter to be evocative of
the group's intended work, but go through most of the other uses in
the charter and see if we can't substitute it's use for a more
specific term, one that has less ambiguity."

sure. i can sign on to that effort. i think it's probably a good idea.
that way we can maintain the term as a more abstract description and
use it only when we need to maintain that ambiguity.

lemme go fire up the text editor and see what i can come up with.

On Mon, Aug 31, 2009 at 7:39 AM, Dave CROCKER<[email-masked]> wrote:
> The charter currently has the string "virtual world" thirteen times.  And it
> is used heavily in discussions on this list.
>
> informative.  It really does have to have specific technical meaning that
> folks agree on.
>
> consistent technical use of the string will remain problematic, and since
> you are pointing out that there was an intent to have it NOT BE a technical
> term...
>
> In other words, say that vwrap provides a service in virtual world
> simulation, but then make all other references be in terms of vwrap-specific
> technical constructs.  regions, agents, etc.
>
>
>
> --
>
>  Dave Crocker

---

From: Infinity Linden <[email-masked]>
Date: Mon, 31 Aug 2009 15:10:03 -0700

yes. i agree with what you say here.

and.. i would go a little further

when i pick up a virtual banana in Levenhall/192/168/32 (in second
life), then pass through "customs" to get to OSGridTest/252/391/22 (on
OSGrid) and drop the banana, it should show up as a banana (and not a
pear) to other people who are are in the same area.

since second life and OSGrid share a number of assumptions about how
avatars and assets are defined, this isn't too radical a goal. and it
sort of informally defines a minimum interoperability "experience."

so just 'cause you can have a banana on both grids, it doesn't mean
that you can't do things that are region domain or region specific.
one grid might implement the "banana auction" service that the other
doesn't. one grid might implement the rule that bananas will always
glow green on alternate tuesdays. (and hopefully, the other won't.)

and ultimately this is the challenge. can all of us from the OpenSim
world and Linden and IBM and whomever else sit in the same room long
enough to get general agreement on how to share descriptions of
objects, avatars and protocol sufficient to allow for the general
migration of fruit from one person's simulator to another. i think we
can. and further, doing it in the IETF puts us in an environment where
if we say things like "hey! let's re-implement TFTP poorly two and a
half times!" we'll hopefully have people who will remind us of our
folly.

still further, we're all going to probably want to do slightly
different things in our worlds. one advantage that OpenSim brings to
this party is that it's source is open and if people have a business
reason for deploying a sim with the glowing green bananas option, they
can. and they might want to do things like attach meta-data that only
they can interpret to people's bananas. and that's okay.

and i think i'm about to very quickly run out of things to say about
glowing green bananas, so let me just say, i think at this point we're
really only trying to say, "we all agree we should work on protocols
that allow us to move avatars and assets between regions, possibly
limited by policy." but we have a little bit of runway left to
describe how it needs to be done.

On Mon, Aug 31, 2009 at 1:42 PM, Charles Krinke<[email-masked]> wrote:
> Dear Infinity:
>
> Thank you for your considered answer. I think our hearts are all headed in
> the same place. For some reason, all this discussion of names has my head
> spinning.
>
> But, ... that aside, as I look at interop between different grids (or
> virtual worlds, if you wish), I see these as analogous to transitting
> customs between countries.
>
> That is, there will be some things that will connect back to ones home or
> originating country and some things that are intrinsic to the country one is
> visiting, to try to draw an analogy.
>
> The things connecting back to ones home country (or grid, if we prefer),
> will most likely be the avatar, inventory and attachments, or at least part
> of the inventory and all of the avatar and attachments.
>
> The things intrinsic to the country one is visiting will most likely be the
> rules dealing with transactions such as buying and selling objects,
> permissions of editing, and ability to visit certain parts of the visiting
> country.
>
> To me, as long as that is a reciprocal relationship, that is, a visit from a
> SecondLife grid to an OpenSim is a mirror image of permissions to a visit
> from an OpenSim grid citizen to a SecondLife grid, then I think my
> enthusiasm is still "full speed ahead regardless of whether we call a pear a
> banana or not".
>
> Charles
>
>> I'm confused with all that is going on and need to ask my two main
>> questions
>> again.
>>
>> not
>>>> network might use one technology and mine might use another.  But even
>>>> if
>>>> they
>>>> view interaction across administrative boundaries as far more
>>>> interesting
>>>> to
>>>> (directly) interoperate with the global one.  They are off "The
>>>> Internet"
>>>> grid

---

From: Morgaine <[email-masked]>
Date: Tue, 1 Sep 2009 00:19:28 +0100

Hi Suzy!

On Mon, Aug 31, 2009 at 8:07 PM, Suzy Deffeyes <[email-masked]> wrote:

>
> I think the Charter looks good, and I support moving forward with
> submitting this to the IETF.  I think it *accurately describes the scope
> of what we want to do*, and is *clear in its description*.
>

We've just spent the last 10 days or longer trying to understand the wording
and scope, without success.  That the charter is "clear in its description"
is sadly not a widespread view.  This is why several of us are trying to get
the terms defined in order to add the missing clarity.

Note that this confusion is present despite the very extensive OGP
background within the group.  For new readers of the charter, its meaning
will be even less clear, if not completely obscure.

In the absense of this understanding, it is not possible to say that the
document "accurately describes the scope of what we want to do", since we
don't know what it describes.  The scope is currently unknown to a
significant number of participants.

As the charter is clear to you, perhaps you could assist in the process of
clarification by answering some of the recent questions made to the list?  I
am sure that this would be widely appreciated.

Morgaine.

==============================

On Mon, Aug 31, 2009 at 8:07 PM, Suzy Deffeyes <[email-masked]> wrote:

>
> Hi Infinity,
>
> I think the Charter looks good, and I support moving forward with
> submitting this to the IETF.  I think it accurately describes the scope of
> what we want to do, and is clear in its description.
>

---

From: Joshua Bell <[email-masked]>
Date: Mon, 31 Aug 2009 16:38:34 -0700

On Mon, Aug 31, 2009 at 7:39 AM, Dave CROCKER <[email-masked]> wrote:

> The charter currently has the string "virtual world" thirteen times.  And
> it is used heavily in discussions on this list.
>

I agree that this is problematic. We should alter uses of "virtual world" in
the charter are not necessary. I'll work on this tomorrow with Meadhbh.

One is particularly interesting, on review:

"Within a single virtual world, avatars exist in at most one location in a
shared virtual space."

This line actually points at the loose working consensus we seem to share
about what a "virtual world" really is - the set of places "you" can "go" as
"yourself". This includes both the technological aspects (i.e. services
adhering to common protocols; network access) and policy aspects (i.e.
permission to access, trust agreements).

Again, it seems like we agree on what we're talking about, even if we're
loathe to define it precisely.

> technical constructs.  regions, agents, etc.

Agreed. We'll probably retain "virtual world" where the description is
entirely to evoke the problem space, but avoid it elsewhere.

We should have a new draft charter out tomorrow.

---

From: Suzy Deffeyes <[email-masked]>
Date: Mon, 31 Aug 2009 20:32:18 -0400

Meow Morgaine!

Not sure last email went thru ....

We've had some great input to the Charter, and now it feels like some
nitting on definitions.  I think the people that find the wording
clear are probably  just being quiet and not posting to the list, so I
am unsure I would claim it is a 'widespread' view that the Charter is
not clear.

For purposes of defining the scope, I think we are there.

I've been implementing the existing OGP spec in snowglobe, and I am
anxious to get more of the protocol designed.

Suzy Deffeyes/Pixel Gausman
IBM

On Monday, August 31, 2009, Morgaine <[email-masked]> wrote:
> I
> think the Charter looks good, and I support moving forward with
> submitting this to the IETF.  I think it accurately describes the scope
> of what we want to do, and is clear in its description.
>
>
>
> We've just spent the last 10 days or longer trying to understand the wording and scope, without success.  That the charter is "clear in its description" is sadly not a widespread view.  This is why several of us are trying to get the terms defined in order to add the missing clarity.
>
> Note that this confusion is present despite the very extensive OGP background within the group.  For new readers of the charter, its meaning will be even less clear, if not completely obscure.
>
> In the absense of this understanding, it is not possible to say that the document "accurately describes the scope of what we want to do", since we don't know what it describes.  The scope is currently unknown to a significant number of participants.
>
> As the charter is clear to you, perhaps you could assist in the process of clarification by answering some of the recent questions made to the list?  I am sure that this would be widely appreciated.
>
>
> Morgaine.
>
>
>
>
>
>
>
> I think the Charter looks good, and I support moving forward with submitting this to the IETF.  I think it accurately describes the scope of what we want to do, and is clear in its description.
>
> I am ready to move to working on the protocol and implementation. Let the interface definitions commence!
>
> On Fri, Aug 28, 2009 at 2:27 PM, Infinity Linden <[email-masked]> wrote:
>   *