[ogpx] Next Steps for OGPX WG Charter

[Joshua Bell <[e-mail]>]

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