[ogpx] refined idea for documents..

[Infinity Linden <[e-mail]>]

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