Re: [vwrap] Consensus? What exactly should be in the protocol

[Morgaine <[e-mail]>]

Discussing what should be in draft protocol documents prior to actually
writing them would be a good idea.  We've suffered from this problem here
repeatedly, in that documents are just sprung on us and then it's a major
fight to get them back to a mutually acceptable common base.

It would be infinitely more useful to find the common base first.  Documents
have immense inertia, and the less in them that needs revising at a core
conceptual level, the less time is wasted by everyone.  A little planning is
a major time saver here.


Morgaine.




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

On Wed, Sep 22, 2010 at 4:28 PM, Cristina Videira Lopes
<[e-mail]>wrote;wrote:

>  OK. If more people are interested in this formulation, let's go ahead with
> this.
> It looks like Meadhbh, who has been the only active draft writer as far as
> I can tell (!),  doesn't like/want/? this formulation, so she is not in a
> position to write it down. It is completely unfair of us, and mutually
> frustrating, to expect that she is going to write down things that she
> doesn't like/want. So someone else needs put their money where their mouth
> is, and spend a couple of days writing an intro draft that's alternative to
> the one that is currently active, and that reflects everyone else's
> expectations on the existence of [virtual world] application domains of
> trust.
>
> Maybe once we have an alternative intro document, we can all converge.
>
> Any takers?
>
>
> Hurliman, John wrote:
>
> This is closer to what I had in my head for VWRAP. Start with the goal of a portable virtual world presence, and a couple of necessary services fall out of that:
>
> * Identity/Authentication
> * Assets (possibly Inventory, maybe)
> * Teleport (both login and simulation to simulation)
>
> Which will in turn require:
>
> * Type system
> * Capabilities/X.509/insert_security_here
> * Avatar file format?
> * Event queue?
>
> And leave everything else for VWRAP2. If we can standardize those services and meet that first goal it will be much easier to tackle things like friends or groups or avatar movement / state simulation or anything else. I don't know if there is any industry demand for a virtual world avatar movement RFC, but other people have different perspectives. I'm strongly in favor of working toward the portable virtual world presence and supporting service definitions first though.
>
> John
>
>
>
>  -----Original Message-----
> From: [e-mail] [mailto:[e-mail] <[e-mail]>] On Behalf
> Of Cristina Videira Lopes
> Sent: Tuesday, September 21, 2010 5:47 PM
> To: Meadhbh Hamrick
> Cc: [e-mail]
> Subject: Re: [vwrap] Consensus? What exactly should be in the protocol
>
> On Sep 21, 2010, at 11:15 AM, Meadhbh Hamrick wrote:
>
>
>
>  so after yesterday's fireworks, i think it's safe to say the group
> agrees we're trying to build standards for "some kind of virtual
> experience."
>
>
>  I think this can be nailed down a lot better, Meadhbh. Or maybe there
> are completely different goals at play here. Probably the latter,
> let's see.
>
> Here's what I think would be really cool for this group to do: this
> group could be trying to build standards for portable user agent
> simulation state, a part of which, but not all, is portable identity.
> Where:
>
> 1) "portable" means what it means on the Web: communicated between
> sites in different trust domains
> 2) "user agent" means what it already means on the web: the data that
> represents the user on the web server
> 3) "simulation" is the new thing that these web apps do: they take the
> user agent data and place it in a  simulation of a 3D environment,
> possibly, but not necessarily, giving the user a visual representation
> called 'avatar'. As the simulation proceeds, the user agent data may
> change.
>
> I think it's very uninteresting -- and mostly void of any effect in
> practice -- that this group engages in the design of a standardized
> virtual world user experience, e.g. making the SL features be a
> standard for all virtual worlds. For example, they all have maps! they
> all have IM! they all have currency! etc. -- that's as pointless as
> trying to standardize the user experience for social network
> applications.
>
>
>
>
>  we agree that the group should define "services," to
> simulate the virtual world.
> and we should define enough services that
> a software developer could take our documents and code something that
> has a good chance of a) interoperating with other software
>
>
>  developer's
>
>
>  output and b) provides a reasonably complete virtual world
>
>
>  experience.
>
>
>  further, i _think_ we agreed there should be no requirement that a
> service deployer should have to deploy ALL the services we define;
> it's up to the individual deployer what services they want to offer.
>
> a lot of people on this list have experience with Linden's Second
>
>
>  Life
>
>
>  Viewer (and similar programs.) i think the experience of a virtual
> world through this program has shaped a lot of people's recent
> opinions of what should and what shouldn't be in a virtual world.
>
> josh bell gave a presentation titled "what's *not* in VWRAP" at last
> spring's IETF face to face in anaheim. you can find the notes here:http://www.ietf.org/proceedings/10mar/slides/vwrap-6.pdf [warning,
> PDF.]
>
> to begin the discussion, i'm going to list a few things i think
>
>
>  should
>
>
>  be standardized by this group, then a few things that i think
> shouldn't. please note that i'm all for standardization, it's just
> that for some of these features we may want to rely on what josh
> refers to as "convention" rather than standardization. in other
>
>
>  words,
>
>
>  peeps should definitely develop standards for enough stuff to be able
> to render a virtual world with terrain, objects and avatars, but i
> don't think this group has to standardize everything (like postcards.
> why the heck do postcards go through linden's servers when it's
> EXTREMELY likely that if you have a second life account you also have
> an email account. but i digress.)
>
> so here's my list. i'm not trying to tell people the is the only list
> that would ever work. they're just my thoughts...
>
> * type system - in
>
> i'm a big fan of the abstract type system and it's related
> serialization schemes. i'm not the world's biggest fan of LLIDL. i
> like what it's trying to do, but all that line noise used to define
> resources is annoying.
>
> * authentication - in or out? BOTH
>
> so now that linden has de-emphasized their participation in this
> group, and we probably won't know for a while if they'll ever
> implement anything we specify, why bother with legacy linden
> authentication. their current "legacy" auth goes over XML-RPC which
> IMHO is the internet equivalent of a skin disease that you just can't
> get to go away. it also uses MD5. i can't express my feelings for MD5
> in polite company.
>
> there are some very interesting conversations / arguments going on
> regarding OAuth. it's a well understood authorization technology that
> many of us on the list have used in the past. OpenID is also vaguely
> popular, though i'm not it's biggest fan. i do know that some of the
> .edu peeps are supporting shibboleth which is (correct me if i'm
> wrong) layered on top of SAML.
>
> however... there is one aspect of the current auth spec that is
>
>
>  (IMHO)
>
>
>  "really cool." and that's the part that provisions a seed capability.
> zha and i have bounced up and down about how caps solve some vexing
> problems dealing with loosely coupled collections of services.
>
> also, most current OAuth instances like to direct people to HTML web
> pages. this can be a problem for peeps with desktop  apps. yes, you
> can integrate a web browser with your viewer and capture the final
> redirect. btw, one of linden's problems with this idea was you got
> software distributed by linden that redirects people to web pages
> owned by other people, and this sorta freaks some corporate users
>
>
>  out.
>
>
>  so... were i the empress of all the internet, i would decree that
> linden legacy auth and linden OGP auth be deprecated and declare that
> implementers were free to use whatever auth technology they want to
> use to authenticate the user prior to giving them their seed cap. but
> because i was a kind monarch, i would define one or two standard,
> thought non-normative, techniques for using other auth technologies.
>
> so instead of calling this auth, i would go back to calling it
> "service establishment."
>
> * maintenance - IN
>
> if you look at the existing auth spec, there's a resource defined for
> login-time user maintenance. it's pretty straight forward to support
> on the client side, and there's no requirement that you have to use
>
>
>  it
>
>
>  on the server side.
>
> * account properties - some IN, mostly OUT
>
> i think we should have a standard way for a client or service to
> request basic information about a user, an agent or an avatar. but
> honestly, i think a lot of the stuff that get's displayed in the
> Second Life Viewer's profile floater could just as easily be rendered
> as a web page.
>
> * agent / avatar control - IN
>
> yes, we should define a standard set of messages for controlling the
> user's avatar. however, i think we should build an extensible control
> sub-protocol. so maybe we start with messages labeled 'CONTROL-
>
>
>  MOVETO'
>
>
>  to define how the user's
> avatar should be moving around the virtual world. later we may want
>
>
>  to
>
>
>  add 'CONTROL-ANIMATION' for synchronizing an avatar's animation with
> real-life events from the client.
>
> * asset access - IN
>
> there's lotsa fun stuff that's been hypothesized for next generation
> assets. suffice to say, at the very least manipulation of meta-data
> and a way get link objects in user's inventories and objects in world
> with objects in an asset server is "a good thing."
>
> * asset upload - OUT? maybe? IN? kinda
>
> there are plenty of great protocols and data formats for defining
> assets. X3D, COLLADA, etc. and HTTP PUT is well understood. so i
>
>
>  don't
>
>
>  know that we have to create any new protocols for uploading assets.
> but we may want to define a technique by which a user can tell an
> asset server it's wants to upload something and then the asset server
> gives the client a URL to a HTTP PUT resource where it can upload it.
>
> * build tools - OUT
>
> the ability to do "group builds" in second life and OpenSim instances
> is one of the compelling things about those worlds. i think there
> should be a standardized way to do builds "in world." but IMHO, SL
> does it wrong. OpenSim inherited SL's wrongness. we could do it MUCH
> better. but i would recommend we pass on building a standard for it
>
>
>  in
>
>
>  this group.
>
> * communication - some IN, some OUT
>
> anyone who's experienced the "joy" of second life's group chat
>
>
>  feature
>
>
>  can quickly see how it's not up to the task. XMPP is a PERFECTLY GOOD
> chat protocol. however, for spatial chat, you would probably want
>
>
>  some
>
>
>  way to identify a location in the virtual world as the endpoint of a
> chat message, so at the very least we should have enough
>
>
>  specification
>
>
>  for how to represent locations or avatars in the virtual world for
> XMPP or SIMPLE or IRC or whatever chat protocol we would want to use.
>
> but the existing linden legacy protocol chat should definitely be
> deprecated. or caught in a dark alleyway when no one's around and put
> out of it's misery.
>
> * event profiles - OUT
>
> this is something that should be a web page
>
> * friends and groups - OUT? IN?
>
> this is a tough one. groups are kind of an important part of second
> life's social fabric. but i have a hard time justifying a group
>
>
>  access
>
>
>  and management protocol when i know that the first thing a third
>
>
>  party
>
>
>  is going to do is ignore the protocol and implement something that
> talks to twitter or facebook.
>
> but... it is still nice to have some standard way to query a user's
> presence. maybe the thing to do is to define a
> "presence field" in a user or avatar's public profile. you could then
> stuff the URL to your public profile on your facebook page or some
> twitter app somewhere and virtual world clients could "do the right
> thing" by querying your social network on facebook / twitter /
>
>
>  avatars
>
>
>  united / etc, reaping the links to user's public profiles and then
> querying their presence status.
>
> or maybe i should just shut up and go code some examples.
>
> anyway... thoughts?
>
> * parcels - OUT! OUT! A THOUSAND TIMES OUT!
>
> parcels are a linden invention that (IMHO) should not be part of this
> protocol standard. i'm all for lindens making publicly defined
> extensions to describe their parcel system, but i don't think every
> region should be forced to carry this bit of linden baggage.
>
> * land and region profile - IN
>
> on the other hand, it's good to know a thing or two about the virtual
> land upon which your avatar stands (like where to go to get the scene
> graph). that should definitely be in the protocol.
>
> * search - OUT
>
> this should be a web page.
>
> * teleport - IN
>
> * virtual currency - OUT
>
> * world map - OUT
>
> * "space server" - IN
>
> this is the resource that defines the adjacency and shape of various
> regions. i don't think we could have a meaningful virtual world
> experience without it.
>
>
> okay... these are just some ideas to kick-start the conversation. i'm
> interested to hear what other peeps think. if i didn't mention your
> favorite service it was an oversight, not a slight.
>
> -cheers
> -meadhbh
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
> _______________________________________________
> vwrap mailing [e-mail]://www.ietf.org/mailman/listinfo/vwrap
>
>  _______________________________________________
> vwrap mailing [e-mail]://www.ietf.org/mailman/listinfo/vwrap
>
>  _______________________________________________
> vwrap mailing [e-mail]://www.ietf.org/mailman/listinfo/vwrap
>
>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>