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

[<[e-mail]>]

May I suggest we stop arbitrarily trying to define things in emails and come
up with some kind of process into how to define what the first draft
specification should include?  Doesn't W3C have a process on how this works?
I think this is the fundamental problem of this group; we are mixing vision,
requirements, and design in the same email.  We are making design decisions
when we haven't even defined the requirements.

 

I have so many conflicts with the existing VWRAP document because so many
assumptions they are making about the architecture and design of virtual
worlds that I don't know where to start.

 

To me there are some very basic and simple things we need, like how John's
email specified.

 

Teleport to a world.

Authenticate with that world

Import avatar

Import asset

 

These are the basic verbs that connect the nouns.  We can make any
assumptions about the architecture or structure of a virtual world.  What we
need to define are the external behaviors that it needs to support to allow
interop to occur.

 

I am focusing on web based distributed virtual worlds, and most of
everything we talk about doesn't fit.  But the verbs like teleporting,
importing do fit.

 

I like reading all your guys emails but this is getting a little crazy, in
my humble opinion.

 

K.

 

 

 

 

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Cristina Videira Lopes
Sent: Wednesday, September 22, 2010 1:23 PM
To: Morgaine
Cc: [e-mail]
Subject: Re: [vwrap] Consensus? What exactly should be in the protocol

 

Definitions here:
http://www.ietf.org/mail-archive/web/vwrap/current/msg00317.html

Morgaine wrote: 

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

 

(1) Goal of the group: develop standards for portable user agent simulation
state (expand on that)



I think we may be witnessing the bow shock from a collision of meme systems
here. :P

VWRAP has honed its terminology rather well over the years, as has the
OpenSimulator project I'm sure, but the two sets of terminology seem to be
different.  We need to bridge this gap fast. :-)

What is "user agent simulation state"?

In VWRAP we have:

*	users (humans driving a "client application");
*	agents (the server-side embodiment of a connection from a client
application);
*	regions that are primarily spatial but may orchestrate many
services;
*	simulations that were traditionally run within a region but which in
VWRAP may be performed by a discrete "simulation service" that could be
external;
*	world state which is primarily held and manipulated by a region
service.


(Note that the above may sound a bit like SL, but it's not really. VWRAP
services can be arranged in numerous different deployment patterns, and an
SL-like configuration is merely one possible deployment out of many.)

To the above should be added that we employ a REST-type protocol for all
upstream communication between client application and server-side services,
and being REST, clients and servers both have application state which is
accessed and modified through CRUD operations, but the protocol is stateless
as usual to provide us with the normal benefits of REST, such as
addressibility, cacheability, etc.

What we don't have is simulation state in the client application, so the
phrase you used is a bit hard to tie down using our form of language.
Explanation needed please --- I'll try to help you fit it into our
terminology if I can. :-)


Morgaine.





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

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

Fair, Morgaine.
Here's an attempt at a plan for what could be in that draft.

(1) Goal of the group: develop standards for portable user agent simulation
state (expand on that)
(2) Granularity of portability: virtual world application (expand on that)
(3) Principles of such standards: as close to the design principles of the
Web as possible (summarize)

For (1) we need definitions for just about every word in there, which I
started to do, and we also need a good definition of "state" itself. What is
that state that gets ported around?

For (2), I liked your long analysis, but I think there's a shorter way to
get where you got, we really don't need to reinvent the Web :) But we can
work on that.


Morgaine wrote: 

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:

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]] 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 list
[e-mail]
https://www.ietf.org/mailman/listinfo/vwrap
      

_______________________________________________
vwrap mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/vwrap
    

_______________________________________________
vwrap mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/vwrap
  

 


_______________________________________________
vwrap mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/vwrap

 






  _____  



 
_______________________________________________
vwrap mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/vwrap
  

 





 





  _____  



 
_______________________________________________
vwrap mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/vwrap