Subject: [ogpx] refined idea for documents..

From: Infinity Linden <[email-masked]>
Date: Thu, 3 Sep 2009 11:49:41 -0700

hey peeps...

i was thinking about it, and came up with a slightly different list of
documents:

* intro and goals (used to be called intro and requirements)
* abstract type system (used to be called LLSD)
* foundations
* the VWRAP trust/security model
* virtual world description format
* client application launch message
* agent presence establishment
* avatar format
* asset format and access
* chat/voice establishment
* user profile access
* time sensitive messages

and here's what i think would be in each one. it's my first attempt at
mapping bits of the problem domain to topics in the solution domain.

this is a big list, but i am pretty sure it's all stuff we've talked
about on the MMOX list, on the OGPX list or at the F2F meetings. in
other words, i think all the stuff listed here is covered by the
charter, so i'm not expanding the scope of the charter with this list,
even though the names of the documents are different. it's a lot to
digest, and i'm sure i've made omissions and mistakes, but i'm
beginning to think we should definitely have an overview like this.

* intro and goals ( based on
http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 )
  * social context of virtual worlds - why they're interesting
  * very high level description of virtual world characteristics - not
what a virtual world "is" as much as features of a virtual world you
may not have thought about.
  * how VWRAP virtual worlds differ from other virtual worlds - how
OpenSim and SecondLife differ on a technology level from WoW
  * protocol objectives and goals - specific features of the protocol

  * this doc is it's own document because we think there's a need for
a lot of background, and it's mostly non-technical.

* abstract type system ( based on
http://tools.ietf.org/html/draft-hamrick-llsd-00 )
  * what the heck is an abstract type system and why should i care?
  * serialization formats for representing structured data in JSON,
XML and a binary format.
  * the interface description language for defining message flows
  * open question : LLSD / LLIDL include features that support a
specific style of programming. (look at
http://www.ietf.org/mail-archive/web/mmox/current/msg00679.html for
more details.) should we include a section about this in this
document?
  * note that we DO NOT talk about language bindings for LLSD 'cause
it's independent of the wire protocol.

  * if other people have the need to develop their own serializations,
it would be nice if they could simply reference this doc for the
discussion of the abstract type system, and then include details of
the new serialization in an IANA issues section.

* VWRAP Foundation ( based on
http://tools.ietf.org/html/draft-lentczner-ogp-base-00 and
http://tools.ietf.org/html/draft-hamrick-ogp-auth-01 )
  * what does REST-like mean?
  * requirements for transporting VWRAP messages
  * HTTP(S) bindings
  * the event queue
  * capabilities & resources
  * the service establishment pattern

* the VWRAP trust/security model ( based partially on
http://tools.ietf.org/html/draft-hamrick-ogp-auth-00 )
  * what needs to be protected?
  * description of a general trust model and how it achieves the
security objectives
  * using OAuth in service establishment
  * using PKIX in service establishment
  * user authentication - i.e. authenticating users to agent domains
(this is what was originally in the ietf-hamrick-ogp-auth doc.)

* virtual world description format
  * how do we communicate the geometry of an entire virtual world to
the client, if we want to have a fixed virtual world?
  * when we teleport into a region, what is the format of the data the
region gives us? like where is the land and water? what are the
textures applied to the landscape?
  * if we wanted to backup an entire region, what information would be
in that backup?
  * open question : is there any way to leverage VRML or WebGL or COLLADA?

* client application launch message (based on
http://tools.ietf.org/html/draft-hamrick-ogp-launch-00 )
  * info : Second Life has the secondlife:/// URI scheme. but it was
intended for use only by SL, not OpenSim.
  * the client application launch message replaces the URI scheme, and
defines an XML message with a distinct MIME Type with information
about a location in the virtual world
  * open question : do we keep the message format AND the processing
expectations in the same document, or do they need to be separate?

* agent presence establishment
  * overall process for rezzing an avatar in a region.
  * what resources does the agent domain export to allow the client
application to tell the agent domain it want's to be rezzed into a
specific region?
  * what resources does the region domain export to allow the agent
domain to rez an avatar in a region on the client's behalf?
  * when we teleport into a region, how does the client tell the
region what objects it's interested in? i.e. - the client may want to
tell the region, "i'm only interested in being told about objects that
are within 20m of me."

* avatar format
  * how is an avatar specified?
  * how do you add assets as attachments to the avatar?

* asset format and reference
  * what are assets? what's the difference between an asset at rest
(i.e. - in an asset store) and an asset in world?
  * what kinds of assets are there? prims, textures, sounds, HTML
files? MIME messages? etc.
  * what is the format for each asset type? (unless there's a current,
widely defined format)
  * how are assets referenced?
  * when you have a reference to an asset, how do you request it's content?

* chat / voice session establishment
  * overview of how spatial chat/voice works
  * how do you reference a location in world to be the destination or
origin of a chat/voice message?
  * how does the region tell the client that someone just typed something?
  * how do you setup a voice channel with a region?
  * how does group chat/voice work?
  * how to you start a group chat (or voice chat) session
  * how does the originating agent domain tell foreign agent domains
there's a group message for one ore more agents defined in their
domain?
  * how does the agent domain tell the client there's a message for them?

* user profile access
  * what bits of data will an agent domain keep about a user and the
avatars controlled by the user?
  * how do users and 3rd parties access this information?
  * how do users select which bits of information (if any) about
themselves or their avatars is made public?
  * what does a user or avatar or group reference look like? (i.e. -
so that the protocol can uniquely identify a user or avatar for the
purpose of referencing them in a protocol message.)
  * how do you add/remove users to groups?

* time sensitive messages
  * what are time sensitive messages?
  * how does the client communicate avatar position changes to the region?
  * how does the region communicate time sensitive messages like
object updates to the client?

-cheers
-meadhbh

---

From: Infinity Linden <[email-masked]>
Date: Sat, 5 Sep 2009 07:26:06 -0700

whoops. sent this to carlo, but forgot to send this to the list.

the current technique for "feature negotiation" is part of service
establishment. the way it works now is that after authentication or
authorization the service returns a seed capability to the client, and
the client requests named capabilities from the service. if a client
doesn't know how to utilize a particular service, it doesn't request
it. if the service doesn't know how to provide a requested service, it
doesn't return a capability for it. if there are multiple,
incompatible versions of the service, each version gets it's own
distinct capability name.

additionally, to reduce the effect of version skew, we use the
technique described in the MMOX list at
http://www.ietf.org/mail-archive/web/mmox/current/msg00679.html .

for content negotiation for protocol messages carried over HTTP, we
use the HTTP semantics: the client identifies the content type if the
request with the Content-Type: header on the request. if the client
needs a particular content type, it uses the  Accept: header to
identify acceptable content types. And the server uses the
Content-Type: header on the response to identify the content type of
the response. if the server cannot generate a response of the media
type requested, it will send a 415  response.

but more options is always better, so to support situations where the
previous technique doesn't work or isn't appropriate or just to give
options, consider documenting it as a draft, then later we can have
the discussion about integrating it into other drafts or releasing it
as it's own draft.

-cheers
-meadhbh

---

From: Carlo Wood <[email-masked]>
Date: Sat, 5 Sep 2009 15:36:32 +0200

I'd like to have added the topic of 'protocol negotiation',
which I think should be part of VWRAP to allow (protocol)
extensions in different implementation to be clean.

Starting point for the argument that this is necessary is that I
expect that extensions will inevitably be made.

Region Domain providers will think of "improvements" for
which they need 'extra information or messages' to be exchanged
with a viewer.

Whether or not that can be seen as Good or Bad is debatable, but
rather irrelevant. It will happen.

Compare this situation with IRC: many different IRC networks
exist; IRC viewers (clients) want to be compatible with every network.
Each network implemented their own extensions. In the beginning
the clients had to use heuristics to guess what network they
were connecting to and what features had to be supported.
Later, the number of features did grow so much that each network
NEEDED a protocol negotiation with the viewers, but since nothing
of that was defined in the official RFC, even that was an extension
and every network invented their own server-client protocol negotion
semantics, often in a rather poor way.

I suppose some will argue that any 'extension' would be bad
and therefore should be battled, let alone that we should add
explicit support for protocol negotiation. If that is the case
then we should discuss first if we really want to try to make
extension impossible and force VWRAP to be a static, non-evolving
protocol, or not.

--

The protocol negotion that I have in mind is a dynamic one
that basically comes down to the following:

* There is a mandatory "base protocol" (the one we will create
  at first), this will be VWRAP version x.y.
* Protocol negotiation at the very start of a 'connection'
  allows for negotiation of optional features that are both,
  available at the server end-point, as well as supported
  and requested by the client.
* Features can also be made mandatory (on top of the base
  protocol).
And last but not least(!):
* The base protocol can be 'shifted', which allows everyone
  to forget the history and literally move on to an evolved
  protocol.

Documentation of features will be a central point in this sheme
(I've mentioned this before on this list too, you might remember).

In practise this will allow for *arbitrary* evolution of the
protocol to new versions (equally well documented as the first
version) while constantly keeping backwards compatibility with
older viewers for as long as needed and desired by a given
administrative entity. For example, LL could decide to support
viewers as old as three years but not older (at which point
users would be forced to upgrade).

It will also allow more diversion between different Regions,
everything entirely subject to policies of course (nothing
will be forced).

In other words, I think of this as a Good Thing(tm); but only
if we add support for the RIGHT KIND of protocol negotiation
from the very start! The impact of the protocol negotion
for the first VWRAP version will be minimal, but the future
benefits will be enormous; the difference between very well
documented features and a well defined way for viewers to
determine what features are supported, plus a way to gradually
improve VWRAP with things that we overlook now or just are
not relevant in 2009 but unmisable in 2019... versus a total
mess and wild growth of endless added features and extensions
that will drive virtual worlds apart and frustrate viewer
coders endlessly.

On Thu, Sep 03, 2009 at 11:49:41AM -0700, Infinity Linden wrote:
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx

-- 
Carlo Wood <[email-masked]>

---

From: Infinity Linden <[email-masked]>
Date: Sun, 27 Sep 2009 08:11:45 -0700

yup. we're actually in the process of adding the deployment pattern
stuff to the intro doc. great minds think alike!

On Sun, Sep 27, 2009 at 7:16 AM, Vaughn Deluca <[email-masked]> wrote:
> On Thu, Sep 3, 2009 at 8:49 PM, Infinity
> Linden <[email-masked]> wrote:
>>
>> hey peeps...
>>
>> [snip]
> [snip ]
> I would suggest to add some stuff
> from http://tools.ietf.org/html/draft-levine-ogp-layering
> The use cases given there would come a long way to clarify the current
> confusion over what we can call a virtual world and what the main seat of
> policy is in these cases.
> Vaughn

---

From: Morgaine <[email-masked]>
Date: Mon, 28 Sep 2009 08:26:37 +0100

A good way of proceeding would be to discuss David's deployment patterns
first, before cranking out a new intro document.  After all, there is a lot
of good material there, hinting at many useful use cases.  Then any new
document would have a chance of reflecting the viewpoints of the group so
far, and building on the consensus.

Ref:  http://tools.ietf.org/html/draft-levine-ogp-layering-00

Morgaine.

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

---

From: Meadhbh Siobhan <[email-masked]>
Date: Mon, 28 Sep 2009 06:33:03 -0700

okay. discuss away!

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 27 Sep 2009 16:16:25 +0200

[snip ]

I would suggest to add some stuff from
http://tools.ietf.org/html/draft-levine-ogp-layering
The use cases given there would come a long way to clarify the current
confusion over what we can call a virtual world and what the main seat of
policy is in these cases.

Vaughn