Re: [ogpx] VWRAP Draft Charter - 2009 09 01

[Morgaine <[e-mail]>]

Joshua, this draft of the charter reads a lot better than the previous ones,
the iterations are definitely helping. :-)

Admittedly, our job has been simplified tremendously by knowing that VWRAP
will not address interop between VWs, so that we can focus on the
single-world building aspects of the work.  This is good.  (Not ideal but
still very useful.)  We could have been here already on the 20th August if
my call for clarity had been accepted.

The following is worth noting:  because you still have not spelled out that
the protocol does not allow for more than one world to be mentioned (it
never talks to a peer world), the workgroup will probably continue to
receive input from people expecting VWRAP to be a VW interop protocol.  I
think it would have been to the benefit of all readers to add Meadhbh's
clear words to the charter so that the scope of the workgroup is not subject
to the whims of interpretation.  This will probably come back to haunt us,
so it's a pity that the advice was not taken.

One great benefit of excluding cross-VW interop is that our deliverables do
not need to be expanded, which immediately gets us closer to a viable
charter.  That's a clear win.

 In respect of referenced documents,
http://tools.ietf.org/html/draft-hamrick-ogp-launch has no direct relevance
to our network protocols at all and should probably be dropped, but the rest
of the list seems reasonable.

The sentence "Regions uniquely represent their partition of  the virtual
space (that is, they are not a "sharding" mechanism)." is probably
superfluous.  The protocol is only concerned with endpoint reachability, not
with how a region wishes to arrange or present its population or objects, so
other arrangements are possible.  Really this is just a world implementation
detail.

If you're going to mention "sharding" then you probably need to mention
"instancing" too, which is a related partitioning on the local scale instead
of on the world scale.  Neither reference is really helpful or necessary
though.  Mentioning sharding has probably reduced rather than enhanced
comprehension, and it is close to being a cultural reference which will date
it.  I would drop the reference to "sharding", and possibly drop the whole
sentence.

Finally, the sentence "*To support the exegesis of the specifications, the
group may define a non-exhaustive set of non-normative policies protocol
participants may enforce*" is obscure in the extreme, and when analysed
deeply means almost nothing because everything is doubly optional.  It
pretty much says "*The group may do stuff*."  This needs to disappear, as it
makes a charter that is progressing well become entirely meaningless for
scoping.

Good progress, but it will need some more iterations, particularly in view
of Carlo's work on terminology.


Morgaine.






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

On Wed, Sep 2, 2009 at 12:48 AM, Joshua Bell <[e-mail]> wrote:

> Thanks for sending out the latest draft of the charter, Infinity. I have my
> fingers crossed that this is the last iteration...
>
> We made several changes in this latest version incorporating the targeted
> feedback a few list contributors have provided. A few examples:
>
> * Where "virtual worlds" was used in a way that could lead to
> misinterpretation, we reworked the text or used a more neutral term like
> "virtual environment". We did leave the term "virtual world" in a few
> places, namely the introduction and in places where it was qualified like
> "virtual world services" - it didn't seem to make that a definition and
> would remind casual readers what we're talking about.
>
> * We worked the "un-sharded" text, to define more clearly what regions are,
> and parenthetically that they are not a sharding mechanism (which becomes
> implicitly defined as a way of non-uniquely representing locations to
> provide load balancing - huzzah!)
>
> * By beefing up the definition of region, we believe this text clarifies
> the interop goals: "Regions and  other services ... may be deployed by
> separate organizations with varying policies and trust domains.  The VWRAP
> protocol will  provide the mechanisms for these virtual world  services to
> interoperate, ..."
>
> Again, this is a charter, so we have avoided diving into detail about, say,
> the agent/region domain split (which presupposes the solution to the
> problem) and other definitions except where strictly necessary (i.e.
> "avatar", "region"). We toyed with text around such as "service providers
> and end users may choose to call collections of VWRAP-implementing services
> a virtual world or virtual worlds" but it seemed obvious and/or confusing...
> and downright limiting to implementers.
>
>
> On Tue, Sep 1, 2009 at 3:49 PM, Infinity Linden <[e-mail]>wrote:
>
>> Working Group Name:
>>
>>  Virtual Worlds Region Agent Protocol (VWRAP)
>>
>> Chairs:
>>
>>  TBD
>>
>> Area and Area Directors:
>>
>>  Applications Area
>>
>>  Lisa Dusseault <[e-mail]>
>>  Alexey Melnikov <[e-mail]>
>>
>> Responsible Area Director:
>>
>>  TBD
>>
>> Mailing List:
>>
>>  [e-mail]
>>  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  environment.  The
>> protocol permits  users to interact as  digital representations called
>> "avatars".  Avatars exist  in at  most  one location  within a  shared
>> virtual  space. Conforming  client  applications use  the protocol  to
>> manipulate  and  move  the  user's  avatar,  create  virtual  objects,
>> interactd with other users  and their surroundings, consume and create
>> media and information from  sources inside and outside their simulated
>> environment.
>>
>> Adjacent points in  virtual spaces 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  environments  may   consist  of  regions
>> administered  by distinct organizations.  Regions provide  the service
>> endpoints  for  interacting  with  the inhabitants  and  objects  they
>> contain.  Regions uniquely  represent their  partition of  the virtual
>> space (that is,  they are not a "sharding" mechanism).  The state of a
>> virtual world is independent of the client applications that access it
>> and may persist between user sessions.
>>
>> Regions and other services implemented according to the specifications
>> may be  deployed by separate  organizations with varying  policies and
>> trust  domains. The  VWRAP protocol  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.
>>
>> 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 region,
>>
>>  * an application-layer  protocol for changing  an avatar's position,
>>    including moving between regions,
>>
>>  * format descriptions for objects and avatars, and
>>
>>  * an  application-layer  protocol   for  identifying  entities,  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
>>
>> The  protocol  should describe  interaction  semantics 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.
>>
>> Goals and Milestones:
>>
>>  * December  2009  "Introduction  and   Goals"  to  the  IESG  as  an
>>    Informational RFC
>>
>>  * March 2010  "Abstract Type System for the  Transmission of Dynamic
>>    Structured Data" to the IESG as Proposed Standard
>>
>>  * March 2010  "Foundational Concepts and  Transport Expectations" to
>>    the IESG as Proposed Standard
>>
>>  * March  2010  "Service  Establishment"  to  the  IESG  as  Proposed
>>    Standard
>>
>>  * July 2010 "Guidelines  for Host Authentication" to the  IESG as an
>>    Informational RFC
>>
>>  * July 2010  "Client Application Launch  Message" to the IESG  as an
>>    Informational RFC
>>
>>  * July  2010  "Simulation Presence  Establishment"  to  the IESG  as
>>    Proposed Standard
>>
>>  * November 2010  "Primitive Object Format"  to the IESG  as Proposed
>>    Standard
>>
>>  * March 2011 "Digital Asset Access" to the IESG as Proposed Standard
>>
>>  * June 2011 "Entity Identifiers" to the IESG as Proposed standard
>> _______________________________________________
>> ogpx mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>