Subject: [ogpx] OGPX Draft Charter, 2009 08 25 edition

From: Infinity Linden <[email-masked]>
Date: Tue, 25 Aug 2009 14:18:44 -0700

Working Group Name:

  Open Grid Protocol (OGPX)

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  Open  Grid Protocol  (OGP)  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.

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: Carlo Wood <[email-masked]>
Date: Thu, 27 Aug 2009 13:02:03 +0200

On Tue, Aug 25, 2009 at 02:18:44PM -0700, Infinity Linden wrote:
>                               Within  a single virtual  world, avatars
> exist in  at most one location  in a shared  virtual space.
...
> administered  by distinct organizations.

I see you insist on using a definition for "virtual world" that does
NOT mean "different administrations", but rather means "all reachable
regions".

However,

> Though these  virtual worlds

this paragraph reveals the actual (or additional?) view of what
"a virtual world" is:

  A virtual world are all regions that collaborate under a single avatar domain.

Correct me if I'm wrong, but from this I conclude that your vision of
a virtual world is a collection of regions that all use a single point
(and administration) for authentication of a users avatar (and inventory).

For example, one logs in with the agent domain run by LL and than can
move between regions and IM every other avatar in "the virtual world"
(using the handle of this agent domain provider). If one would prefer
to login with a different agent domain provider, it would not be possible
to IM every other avatar, or have other interactions  such as 'giving'
inventory objects to other avatars, and thus one would not be able to
be part of the same virtual world.

> virtual world  services to interoperate, when permitted  by policy and

This paragraph is OK.

> and  will  define  the use  of  HTTP(S)  as  a transport  of  protocol

OK

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

-- 
Carlo Wood <[email-masked]>

---

From: Infinity Linden <[email-masked]>
Date: Thu, 27 Aug 2009 08:16:22 -0700

> NOT mean "different administrations", but rather means "all reachable

yes. as discussed earlier, "virtual world" is a non-normative
definition, and defined from the user's point of view. this definition
also allows us to say that "OSGrid is a single virtual world, and not
a collection of adjacent virtual worlds."

> be part of the same virtual world.

yes. kind of. there is no reason a region may limit the number of
agent domains it accepts to one. so as i said earlier, you could have
agent domain A that is trusted by region domains 1, 2 and 3 and agent
domain B that is trusted by region domains 3, 4 and 5. Avatars
representing users from agent domain A and agent domain B can meet in
region domain 3.

so, some might say that region domains 1 through 5 are the same
virtual world. others might say that domains 1,2 and 3 and 3, 4 and 5
define distinct virtual worlds.

ultimately it doesn't matter to the protocol because the term "virtual
world" is not used in the protocol definition. or rather, it's not
used in a normative fashion.

there is no requirement in the protocol that asset services
(inventory) be offered by the same administrative entity that offers
the user authentication service. this is to support cable beach (or
anyone else who wants to decouple user authentication from asset
management.)

the protocol does not REQUIRE Linden Lab (or any other region domain
provider) to choose only a single agent domain to trust. however, it
does not REQUIRE that they trust multiple agent domains. it assumes
that the region domain will establish a policy of which agent domains
it trusts (or even a permissive policy where it will accept protocol
interactions from all agent domains.

since this is a policy issue, we don't mention it in the charter.

that being said, Linden Lab has a number of policies regarding
acceptable behavior in it's virtual world, so i would imagine that by
policy, Linden would require a foreign agent domain to agree to
enforce those policies as a precondition to allowing avatars defined
by those agent domains to rez in regions it administers. but again,
it's policy, not protocol.

which is why we have the next paragraph.

---

From: Infinity Linden <[email-masked]>
Date: Thu, 27 Aug 2009 08:40:53 -0700

oh, one more point about IM. lemme cut out everything else but your
relevant comments on IM.

> be part of the same virtual world.

the protocol does not describe the policy for where IM messages may
flow, but rather the mechanism for how the client establishes an IM or
voice connection. it does not REQUIRE systems to operate in the way
you define. and, in fact, one of the motivations to describing a
globally unique URI for each avatar is to allow user agents and client
agent domains a service endpoint to query about agent specific
features like "how do i IM you?"

i think everyone agrees that the existing, legacy user-to-user and
group IM system for second life is sub-optimal, won't scale to the
bazillions of users we want to enable with this protocol and shouldn't
be used in a new design. many people think we should just use XMPP or
IRC and be done with it. and there are some compelling arguments in
favor of this approach.

the work of this group would be to define the mechanism of
establishing, maintaining and closing chat or voice communication
sessions, and the format for addresses used to identify the source and
destination of messages.

this is a very roundabout way of saying, it SHOULD be possible that a
group hosted on a Linden Lab agent domain may contain members that are
themselves registered by a foreign agent domain (let's say OSGrid.)
but before the Linden Lab agent domain would allow messages to flow to
(or from) users with accounts on a foreign agent domain, policy may
require that foreign agent domain to agree to enforce various bits of
Linden's terms of service.

so in other words, i think the prevailing thinking is that we define
mechanisms that defines how to get a message across the wire and how
to identify endpoints so you can use someone's avatar descriptor or
group descriptor to resolve the IP address of the system you want to
start speaking this protocol to. once that is defined, individual
operators will decide what they want to do with regards to letting
messages from foreign agent domains into their systems.

so, in other words, the "virtual world" is also not defined by the
agent domain. it's another reason i kind of dislike the term from a
protocol perspective. it is evocative, but clearly non-normative.

-cheers
-meadhbh

---

From: Infinity Linden <[email-masked]>
Date: Thu, 27 Aug 2009 09:14:53 -0700

hmm, so we expanded the single sentence fragment describing the
existence of policy into a paragraph and got this...

> virtual world  services to interoperate, when permitted  by policy and

should we explicitly say that the work of the group will include
defining a non-exhaustive list of places in the protocol where policy
may be inserted?

so we would get something like this instead:

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

so the idea here is that if it makes sense to define a policy for the
purpose of explaining the protocol, we will. but just because a policy
is described does not mean it must be implemented or that policies
other than the ones included in the text are invalid.

thoughts?

---

From: Carlo Wood <[email-masked]>
Date: Fri, 28 Aug 2009 14:17:31 +0200

> other than the ones included in the text are invalid.

Seems like a good idea. It would clarify things a lot.