Re: [ogpx] Next Steps for OGPX WG Charter

[Morgaine <[e-mail]>]

On Thu, Jul 30, 2009 at 8:39 AM, Joshua Bell <[e-mail]> wrote:

>
> Necessary charter changes:
>
> 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?
>


Joshua, I've been looking at one particular aspect of how to define our
problem space in such a way that it is concise and narrow enough to exclude
the "interop all worlds" of MMOX, while at the same time flexible and broad
enough to make it apply to more than just exact Second Life clones.  In
other words, how to define the catchment area such that OGP becomes a
worthwhile protocol for more than just one company's goals.

One of the best ways of tackling this is to directly ask *who it actually
applies to*.  What kinds of worlds could interoperate through OGP?

This question is often answered in an informal way:  "OGP allows
interoperation between SL-like worlds."  That answer is fair enough when
given loosely and informally, but it is not good enough for an IETF spec,
for obvious reasons.  We may know what we mean, informally, but we need a
more objective way of expressing it, so that people without any background
in Second Life can still find it precise and informative.

I would like to propose that a different informal answer is appropriate
here, an answer which, while equally simple, is enormously more embracing
while still being just as concise and specific and inherently implementable:

*"OGP allows interoperation between any virtual worlds that implement the
protocol."*

This almost sounds recursive, but it is not:  it makes it clear that it
doesn't matter how different and divergent the worlds may be, they can still
interoperate through OGP as long as they implement that common protocol.  It
no longer mentions Second Life.  It does not refer to a totally fictitious
unit of "the world".  It does not require interoperating worlds to be
clones, either implicitly or explicitly.  It clearly states that the ONLY
requirement for interop is implementing this one protocol, or suite.

In other words, it avoids being prescriptive about worlds, and it lets
adherence to the protocol define the universe of interop.

That sounds to me like a very good basis for a charter upon which to build a
protocol that  satisfies the known goals of OGP as we have discussed for
almost two years, while at the same time being in tune with the Mission
Statement of the IETF in respect of wide deployment and interoperation on
the Internet.

I propose that the current charter be rephrased to make the above plain,
because in its current form it is unnecessarily restrictive and inconsistent
in its reference to virtual worlds.  I can have a go at this myself if you
like.


Morgaine.









On Thu, Jul 30, 2009 at 8:39 AM, Joshua Bell <[e-mail]> wrote:

> A draft WG charter was discussed at the BOF, the text of which can be found
> here:
>
> http://www.ietf.org/proceedings/75/slides/ogpx-2.txt
>
> Our highest priority goal is to refine the charter. The BOF provided us
> with an excellent set of questions and issues to address. These have not yet
> been incorporated, and are listed below along with open questions.
>
> * We are looking for feedback in the form of specific changes to make to
> the proposed charter and rationale for the language used.
>
> * We have an explicit goal of submitting the charter within 2 weeks to the
> ISEG and IAB for approval.
>
>
> Necessary charter changes:
>
>
> 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?
>
>
> 2. Larry Masinter and Dave Crocker argued persuasively for a functional
> description of the protocol's uses. Rather than describe the protocol only
> in abstract terms, provide a non-exhaustive list of protocol effects. 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."
>
>
> 3. The text of the charter should have a clear list of working group
> deliverables.
>
> 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,
>
> Are there any deliverables missing? Have we covered the functional needs.
> When proposing additional deliverables, please describe them in sufficient
> detail to enable discussion.
>
>
> 4. A small number of key terms should be introduced and briefly described,
> especially any used in the functional description (#2, above). Suggestions
> for these terms include agent, avatar, user, region, asset, domain, service,
> resource, agent domain and region domain.
>
> Ultimately the list of terms to include will be derived from other parts of
> the charter to make it independent of other texts, but are there other terms
> that must be defined?
>
>
> 5. Should the working group investigate operational aspects of virtual
> worlds? If so, what language should be added to the charter?
>
>
> 6. "OGP" is not an appropriate name for the WG or protocol - "grid" is
> ambiguous. (Our usage plays off the double meaning of a square subdivision
> of regions, and a computing cluster, neither of which are expected to be
> explicit in the protocol.) Suggestions so far include:
>
> * "Region Access Protocol" (RAP) - captures region-based VW specificity
> * "Agent/Region Interaction Protocol" (ARIP) - highlights the active
> entities
>
> Are there any other suggestions, preferences, or vetos? Does the proposed
> protocol name need to be reflected in a revised Working Group name?
> Contrariwise, does the WG name need to be reflected in protocols it
> develops? (Strictly: "no" and "no", but in practice...?) Serious name
> suggestions which promote clever acronyms for future IETF sessions are
> encouraged.
>
>
> 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?
>
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
> 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?
>
> (This may affect the terminology used for #11.)
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>