Re: [ogpx] Next Steps for OGPX WG Charter

[Dave CROCKER <[e-mail]>]

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