Re: [ogpx] Next Steps for OGPX WG Charter

Regarding Joshua's 12 points, I think that Dave Crocker's post below
addresses the issues most clearly so far, so I'll treat that as a base and
fill in some details.  The following brings together the common elements of
points 1, 2, 4, 8 and 9, which are all descriptive and together explain "*what
we're trying to do*".

On Sun, Aug 2, 2009 at 2:54 AM, Dave CROCKER <dhc@dcrocker.net> wrote:

Joshua Bell wrote:

Can mailing list participants come up with something short, accurate,
educational, and catchy?

You suggested:

  "The working group will define a protocol to support a 3-D virtual world
simulation environment between users and independently operated simulation
regions, and amongst those regions."

This is neither as concise nor as sexy as Chris' summary, but it also lacks
the proprietary reference. I think it also describes the core technical
activity, as I understand the goal.

I think that's fine as an introductory phrase, Dave. While it may not really
explain much, that's OK as long as more detailed explanations follow it.
And sexiness isn't required. :-)  Indeed, the allegedly "sexy" phrase used
at the BoF obscured far more than it illuminated.

One or more people then suggested:

For example: "The protocol produced by this working group should provide a
mechanism for authenticating a client to a server, cause a user's avatar to
be placed in the virtual world, move the user's avatar, receive a list of
objects in the user's avatar, etc."

I don't think Larry or I formulated the above sentence, and in spite of
that, I
quite like it...  I think it's clear, direct, and contains the salient
information.

I like the immediate detailing of key features here, as it anchors the topic
very firmly right from the beginning.  However, the choice of words raises
questions rather than building on prior terms and explaining them.  In
particular, let's avoid "placing in a virtual world", since the reader has
no notion of virtual world at this point, only of regions as simulations.
So, let's stick to the aforementioned "regions" and explain the words as we
go, gently sliding in the notion of services, something like this:

"The protocol provides mechanisms for access to regions, each of which is a
virtual area or space implemented through one or more servers.  Access to a
region may involve authentication with an authentication service.  Regions
provide a 3D simulation of a shared environment that may contain avatars (3D
representations of users) and 3D objects of various kinds."

The above starts with "regions", explains what they are in broad physical
terms to aid understanding, and in a short paragraph brings together all the
main elements in the overall picture with the exception of object behaviours
(scripting) and asset services.  We can elaborate on those later, but first
let's build upon the concepts in the preceding paragraph and make clear the
demarcation between regions and clients in our protocol, because it's
fundamental:

"Regions perform spatial or environmental simulation of avatars and 3D
objects, while the graphic rendering of avatars and 3D objects is performed
within users' own client applications, commonly called *viewers*.  This is a
key separation in the protocol, which distinguishes it from other
approaches.  The combination of spatial simulation in regions and graphic
rendering in clients together provides the illusion of shared virtual spaces
that are commonly called *virtual worlds*."

Here at last we've defined what we mean by *virtual world* based on prior
terms.  It's not some kind of mandated conscription of participants into a
global federation (:P), but just a natural consequence of interop:  it
provides a unified visual mashup between graphic elements from various
sources in the user's viewer, driven by the simulation in the region with
added input from the user.  We need to say more about objects though to make
this clear, and crucially, to say what we mean by *interop*:

"The current protocol is an *interoperability* protocol, in other words it
provides communication between end points hosted by more than one party or
organization which provide *services*.  Typical services include identity,
authentication and authorization, region simulation, avatar and/or asset
provision (assets are the components of objects and avatars), and
communication services such as instant messaging."

"While a given organization may choose to implement many or all such
functions itself, the protocol treats all services as decoupled for maximum
flexibility.  For example, a region operated by one provider may be
simulating an environment in which avatars and objects originate from
several different asset providers and are supplied to the user's viewer from
their respective asset services."

And finally, I think it's worthwhile summarizing what this interop protocol
aims to do in respect of all the bits of the puzzle that we have explained
above:

"It is the purpose of the protocol to communicate between the user's client
application and services from diverse providers, in order to deliver the
experience of interoperating virtual worlds to the end user."

Hopefully this kind of progressive explanation can provide the desired level
of readability for the descriptive part of a good charter, while at the same
time mentioning all the required elements and defining what we mean by
interop.

 I've purposely left out object behaviours or scripting as it is a complex
topic and would probably detract from an otherwise easily readable charter.

Putting those snippets together, we get the following description:

"The working group will define a protocol to support a 3-D virtual world
simulation environment between users and independently operated simulation
regions, and amongst those regions."

"The protocol provides mechanisms for access to regions, each of which is a
virtual area or space implemented through one or more servers.  Access to a
region may involve authentication with an authentication service.  Regions
provide a 3D simulation of a shared environment that may contain avatars (3D
representations of users) and 3D objects of various kinds."

"Regions perform spatial or environmental simulation of avatars and 3D
objects, while the graphic rendering of avatars and 3D objects is performed
within users' own client applications, commonly called *viewers*.  This is a
key separation in the protocol, which distinguishes it from other
approaches.  The combination of spatial simulation in regions and graphic
rendering in clients together provides the illusion of shared virtual spaces
that are commonly called *virtual worlds*."

"The current protocol is an *interoperability* protocol, in other words it
provides communication between end points hosted by more than one party or
organization which provide *services*.  Typical services include identity,
authentication and authorization, region simulation, avatar and/or asset
provision (assets are the components of objects and avatars), and
communication services such as instant messaging."

"While a given organization may choose to implement many or all such
functions itself, the protocol treats all services as decoupled for maximum
flexibility.  For example, a region operated by one provider may be
simulating an environment in which avatars and objects originate from
several different asset providers and are supplied to the user's viewer from
their respective asset services."

"It is the purpose of the protocol to communicate between the user's client
application and services from diverse providers, in order to deliver the
experience of interoperating virtual worlds to the end user."

For the high complexity of what we're trying to achieve, that seems to
combine good coverage and readability, defines interop, and limits the scope
to our particular worlds model.  Comments?

Morgaine.

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

On Sun, Aug 2, 2009 at 2:54 AM, Dave CROCKER <dhc@dcrocker.net> wrote:
>
> Joshua,
>
> g'day.
>
>
> This latest draft is indeed very much better!
>
>
> Joshua Bell wrote:
>>
>> 1. Include a succinct but realistic summary of what the problem space and
protocol are. At the BOF, Chris Newman made the comment "The impression I've
got is this is a 3-D multi-vendor Facebook. I think that's really cool."
(thanks, Chris!). This really helped BOF participants unfamiliar with VWs
understand what the heck we were talking about.
>>
>> Can mailing list participants come up with something short, accurate,
educational, and catchy?
>
>   "The working group will define a protocol to support a 3-D virtual world
> simulation environment between users and independently operated simulation
> regions, and amongst those regions."
>
> This is neither as concise nor as sexy as Chris' summary, but it also
lacks the
> proprietary reference.  (Perhaps the social networking usage aspect,
however, needs to be included? But then, I'm not clear how the protocol work
mandates that usage.)  I think is also describes the core technical
activity, as I understand the goal.  That presumes that I understand it
correctly...
>
>
>>   For example: "The protocol produced by this working group should
provide a mechanism for authenticating a client to a server, cause a user's
avatar to be placed in the virtual world, move the user's avatar, receive a
list of objects in the user's avatar, etc."
>
> I don't think Larry or I formulated the above sentence, and in spite of
that, I
> quite like it...  I think it's clear, direct, and contains the salient
information.
>
>
>> 3. The text of the charter should have a clear list of working group
deliverables.
>
> The current draft does not specify what existing documents it is drawing
from,
> what it will/might/must do with them, nor what the limits on modification
to those documents are -- if any.
>
>> The "what is needed" slide from the OGPX Draft Charter Issues
presentation ( http://www.ietf.org/proceedings/75/slides/ogpx-2.pdf) was
mentioned as a possible source for this list for both (2) and (3), but needs
massaging:
>>
>> (a) a security model describing trust relationships between hosts,
>> (b) guidelines for the use of existing authentication & confidentiality
mechanisms,
>> (c) mechanisms for:
>>  (i) establishing the user's presence in the virtual world
>>  (ii) moving a user's presence from one authoritative host to another,
>>  (iii) for identifying agents, and requesting information about them.
>> (d) format descriptions for objects and avatars in a virtual world,
>
> For c.ii should it really be 'host' or is it actually 'region'?  Also, the
use of 'authoritative' implies there can non-authoritative hosts.  Is that
correct?
>
> As for what might be missing, I'm not seeing any semantics cited for any
actions other than defining and moving users.  Nothing about simulation
activity.
>
>
>> Are there any other suggestions, preferences, or vetos? Does the proposed
protocol name need to be reflected in a revised Working Group name?
>
> They certainly don't have to be the same, but they do need to be useful,
of course.
>
>> 7. Explicitly list extant drafts which will be the starting point for the
WG effort:
>>
>> * http://tools.ietf.org/html/draft-hamrick-ogp-intro
>> * http://tools.ietf.org/html/draft-hamrick-llsd-00
>> * 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
>>
>> Is this list complete and accurate?
>
> Since these document represent a substantial history, it really is
important for the charter to cite them explicitly and specify how maleable
their content is. "Starting point" could mean that the final result has no
visible relationship to these documents and that they merely used for
initial discussion. As I've noted earlier, I am pretty sure you folks want
more constraints than that.  Whatever you choose, it's likely to be a point
of negotiation with the IESG, but you should state what role these docs are
expected/required to play.
>
>
>> 8. The protocols are intended to provide a clear seperation of concerns
between mechanisms  used to access resources and policies controlling use of
those mechanisms. Many deployment choices will be defined by policy, not
protocol. This needs to be clear in the charter.
>
> yup!
>
>
>> 9. Ensure that while the charter scopes down the Virtual World problem
space, it does it in an inclusive way rather than focusing on what is out of
scope and thus indecipherable to non-subject matter experts. It is expected
that output of the WG may be useful in scenarios beyond those specifically
under consideration, much as RFC 2068 is not simply used for hypertext.
>
> This type of goal is often present, but I'm pretty sure I've never seen
any chartering text about it that had any meaning or any impact.  For
example, what objective criteria could the IESG apply during document
approval, to tell whether the goal has been satisfied?
>
>
>> 10. Remove references to "wire" in "wire protocol"; this is implicit in
the scope of work for IETF. The phrase "application-layer protocol" (as
distinct from a novel transport-layer protocol) is accurate and sufficient.
>
> Yes, but I'll also vote for removing "application-layer".  I now
understand that it's meant to imply that it's above transport, but there's
already specific language about using transports.
>
> No, this isn't a big deal, but in spite of primarily being as apps guy, I
think removing the phrase makes the text cleaner, with no loss of meaning.
>
>
>> 11. Add text specifying: The WG will define interfaces for a set of
HTTP-based services ("web services") but not provide language specific
bindings ("API") onto those services.
>
> Huh?  What's this about?  Sounds like the working group is going to do web
enhancements, rather than virtual world simulation.
>
>
>> 12. Clarify the charter that we're explicitly targetting HTTP as the
default transport.
>>
>> A concern was raised that reusing HTTP will lead to unnecessary and tight
coupling with that protocol's capabilities and semantics; a suggestion was
made that if we wish to state that the protocols will be transport-neutral,
the WG will investigate at least one other transport. Should we just target
HTTP, or make the effort?
>
> If transport-independence is claimed, the claim won't really be meaningful
unless at least two different transport mappings are provided.
>
> d/
> --
>
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx