Subject: [ogpx] Next Steps for OGPX WG Charter

From: Joshua Bell <[email-masked]>
Date: Thu, 30 Jul 2009 09:39:32 +0200

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.)

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 30 Jul 2009 13:09:03 +0300

What about VIP - Virtual-worlds Integration Protocol for a name?

Thanks
--Avshalom

From:
Joshua Bell <[email-masked]>
To:
[email-masked]
Date:
30/07/2009 10:40 AM
Subject:
[ogpx] Next Steps for OGPX WG Charter
Sent by:
[email-masked]

_______________________________________________
ogpx mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ogpx

---

From: Carlo Wood <[email-masked]>
Date: Fri, 31 Jul 2009 02:31:26 +0200

> Can mailing list participants come up with something short, accurate,  

Someone once said: "Of course it's not working perfectly: this is
the VERY first version of the Matrix".

-- 
Carlo Wood <[email-masked]>

---

From: Carlo Wood <[email-masked]>
Date: Fri, 31 Jul 2009 02:59:52 +0200

> the VERY first version of the Matrix".

So, what about:  MAP ... Matrix Alpha Protocol

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 01 Aug 2009 06:10:07 +0200

> So, what about:  MAP ... Matrix Alpha Protocol

A pronounceable acronym can be quite nice.

My own suspicion is that one based on being humorous, ironic, or otherwise 
clever, probably isn't, if the effort is to be taken seriously.  The fun 
component resonates initially, but then grows stale on constant repetition (over 
the years.)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Morgaine <[email-masked]>
Date: Sat, 1 Aug 2009 05:44:14 +0100

On Thu, Jul 30, 2009 at 8:39 AM, Joshua Bell <[email-masked]> 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.
>

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 <[email-masked]> wrote:

> A draft WG charter was discussed at the BOF, the text of which can be found
> here:
>
> 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.
>
>
> 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.
>
> 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."
>
>
> 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:
>
> (b) guidelines for the use of existing authentication & confidentiality
> mechanisms,
> (c) mechanisms for:
> 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?
>
>
> 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:
>
> 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:
>
> 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.
>
>
> 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.
>
>
> 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?
>