[ogpx] Protocol negotiation and evolution

[Carlo Wood <[e-mail]>]

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:
> 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
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx

-- 
Carlo Wood <[e-mail]>