Subject: [vwrap] Status and future of the VWRAP working group

From: Barry Leiba <[email-masked]>
Date: Fri, 14 Jan 2011 12:13:36 -0500

Good day, all.
The chairs and area directors have been talking about the status and
future of the VWRAP working group.  Owing to changes in focus and
commitment by both companies and individuals, things have been
languishing, and it's not clear to us that we have what we need to get
the chartered work done.  The introduction document looked close to
ready, until some controversy on its content and direction brewed, and
the result of that discussion was inconclusive.  The normative drafts
that have seen some implementation (type system, launch message, etc.)
also appear nearly technically complete, but some issues have been
identified and not resolved by subsequent discussion, consensus, and
editing.

At this point, the mailing list has been too quiet for too long, all
the draft documents have expired, and we need to make a decision about
what to do.

The chairs and ADs see three possibilities:

1. Find new document editors, pick up the chartered work with the
existing document base, and get moving again.  Get the introduction
document finished by the end of February, and make progress on the
others.

2. Come to consensus on significant changes to the direction of the
VWRAP specs, find new document editors, revamp the introduction
document, and get that finished, or substantially so, by the end of
February.  Have some clear consensus, clear direction, and enthusiasm
to continue.  Consider rechartering, if the direction has changed
enough to require that.

3. Accept that we no longer have enough core participation, consensus,
and enthusiasm to make progress, and close the working group.  Future
work in the virtual world area could charter a new working group
later.

Note that options 1 and 2 both require that we demonstrate sufficient
energy and participation to really get work done and to demonstrate
consensus.  That means that we need people to commit to
writing/editing documents, actively discussing the technical issues
with the goal of reaching consensus on the content of the documents,
and, importantly, reviewing documents and showing that we have
consensus.  Three or four participants isn't enough, and conflicting
ideas that can't be resolved into a consensus-based position won't
work.

What say you, VWRAP participants?  Can we pick up the work and make
progress?  Shall we close the working group, and perhaps consider
something in future?  Do you favour options 1, 2, or 3?  Or do you see
an alternative option you'd like to bring up?

Barry and Joshua, VWRAP chairs

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 14 Jan 2011 09:57:57 -0800

hey barry,

comments on options:

option 1 : find new editors

as the author of the overwhelming majority of words in VWRAP IDs, i
would LOVE to hand off responsibility for everything except the type
system to someone else. the most recent drafts of the IDs are in SVN,
and i'm happy to email them to the list or to individuals. i am (more
than) happy to discuss the motivations or historical context of
various "controversial" phrases.

i have some personal stake in the type system since my company is
using it for a commercial service. i have numerous issues with the
existing type system draft, many are documented in a blog post at:

http://blog.meadhbh.org/2010/07/abstract-resource-definitions-vs-llidl.html

the changes i'm calling for are kind of extensive, so i changed the
name of my type system to DSD (dynamic structured data.) for the last
couple of months, the sl8.us service and a couple other services we
haven't announced have been using the X-application/dsd+xml and
X-application/dsd+json content type. we would like to remove the X-
from the front of that since we're developing types that are of
general use, implemented using open source software.

if we can't find another editor for VWRAP, i'm happy to publish DSD as
an individual / informational RFC for the purpose of registering the
mime type and to document DSD's use. if we do find another editor and
this working group continues, i would yield to group consensus on
whether we want to move away from LLSD to DSD.

either way, i should finish the documentation i've been saying i would
finish for the last three months.

option 2 : recharter

go for it! (assuming there's consensus.) again, because i'm barred
from contributing code to the OpenSim core and i have no interest in
maintaining a fork, i'm not personally interested in participating in
standardizing hypergrid. but if anyone from the OpenSim group wants to
document it in this forum, i'm happy to lend advice, encouragement and
whatever minor work the OpenSim peeps think i can contribute without
introducing intellectual property weirdness.

option 3 : death, coma or hibernation

as a casual observer, i'm putting my money on this option. Linden's no
longer supporting open virtual worlds. Smithee, et all (my current
employer) is only interested in a subsection of the VWRAP work. IBM &
Intel seems to be focusing on other things. I know we participate here
as individuals, but at the end of the day, it's a lot easier to
participate if someone is paying you to do so.

the core hypergrid folk always regarded this group as a "linden
marketing stunt," so i don't know if there's much interest from that
corner to recharter. the OpenSim core, for better or worse, seems to
be focused on their implementation, not on protocol standardization.
maybe that will change in the future.

maybe in a few years there'll be renewed interest in this domain. if
there's a snowball's chance in hades that work could get completed,
i'll probably try to participate.

anyway... i wish everyone here good luck. i think there were some
great people here who contributed some great ideas, even if i didn't
agree with all of them.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [email-masked]

On Fri, Jan 14, 2011 at 9:13 AM, Barry Leiba <[email-masked]> wrote:
> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Morgaine <[email-masked]>
Date: Fri, 14 Jan 2011 20:25:27 +0000

As a point of information and perhaps a call for patience, the period of low
progress coincided with December, a month in which traditionally nothing
gets done (in the West) for reasons that need no explanation.

In October/November, a number of us embarked on a collective edit of a wiki
page as *input* to the next version of an Intro draft, starting from
scratch.  This was a direct followup to our rather epic list discussions of
September precipitated by Diva, which had finally made explicit what had
been known implicitly from the beginning of OGPX/VWRAP, but which was never
openly expressed until then:  that some central documents produced by the
original OGP designers were completely out of step with this group's
near-unanimous desire to provide a protocol foundation for interop
*between*virtual worlds.

September was a watershed month in that respect, and change was inevitable
after that point.  We're not going back (I believe) to a destructive
worldview that denies a central goal of the group, a goal which, it's worth
stating, is wholly aligned with the IETF Mission Statement in respect of
interoperation on the Internet.

Yes, it does mean that (some) previous drafts have become not only expired
but actually wrong.  Yes, it does mean that our schedule is unlikely to be
met, but then the schedule was a result of commercial interests more than
anything else.  It shouldn't come as a big surprise that earlier
business-driven deadlines became inappropriate after the commercial interest
disappeared.  But IETF WG participants are individuals rather than
corporations, and loss of commercial interest does not necessarily mean that
participants' interest has disappeared as well.

I can only speak for myself, but I am still very keen to work towards a
standards track specification to underpin interop between VWs.  I think this
is important work, because even if it does not take the world by storm, it
provides a very valuable Internet community focus for protocol design
efforts in this area, and most importantly, an *open participatory* focus.
There is no shortage of less participatory groups dealing with VW interop,
each doing whatever their main designer thinks is the right thing, but an
IETF group is "constitutionally" open, and that is healthy.

So what's our future?  Well assuming that the IETF is flexible on deadlines,
I don't see a huge problem.  It's always hard to start the initial version
of something, but people tend to contribute more easily once a framework
exists, ready to be improved.  And documents are like software:  they're
ready when they're ready.  Extra resourcing does not necessarily speed up
the process, and whipping is probably the wrong approach for accelerating
intellectual goals. :P

Perhaps we need to change our focus a little.  We have been working top-down
(service orchestration through caps) and bottom-up (LLSD), but there has
been no meat in the sandwich:  for example, we've left asset services
languishing as little more than a cloud in a mental picture, despite asset
services being the very core of interop between worlds.

I think there is much work to be done, many good reasons for doing it, and
no reason to force the pace.  Indeed, the best standards are those that
reflect *de facto* mechanisms in use in the industry, and the "VW industry"
is very actively working on methods that we can incorporate into our
specifications.  As an example, the VWRAP emphasis on services using Web
infrastructure has become quite popular as a general approach, which tells
me that we were on the right track.

In summary, I see change happening in VWRAP, but no reason for despair.
John's exit from the VW arena to pursue different interests is undoubtedly a
setback for us, as he was leading the exploration of protocols consistent
with the VWRAP model and his enthusiasm knew no bounds.  But Opensim,
realXtend and many other groups continue to work on protocols, and so a
working group that is able to assimilate their ideas will be central for
interoperation between them.

If our options are the three presented, then I support #2, and I see no
reason for doom and gloom. :-)

PS. The wiki page for the new Intro document which I mentioned earlier is
available here ---
http://vwrap-playpen.wikispaces.com/New+VWRAP+intro+draft.  Editing is
of course open to all VWRAP contributors (I believe David is
coordinating access).  This pre-draft has the purpose of overcoming a major
failing in VWRAP so far:  drafts were written, extensive discussions were
held, and the comments were totally ignored by the draft writers and never
made it into subsequent versions.  The interactive wiki approach overcomes
that (human) problem by technical means.  The general goal is to put us on
the right road for an official IETF draft that reflects the group's desired
direction on interop.  Previously we were on the wrong road entirely.

Morgaine.

PS. Happy New Year to all ! :-)

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

---

From: Cristina Videira Lopes <[email-masked]>
Date: Fri, 14 Jan 2011 17:23:10 -0800

I'm leaning towards #2 and #3 simultaneously :)
Let me explain.

The goal of achieving virtual world interoperability always felt like a 
niche goal to me, but one that, given the nature of these applications, 
touched on a couple of more foundational issues: single sign ons and Web 
services security -- in short, federations that cross enterprise boundaries.

There is a variety of implementations for SSOs out there, more recently 
the one in the Hypergrid, and a variety of ways of securing Web 
services. But no standards that I know of -- apart from the SOAP stuff. 
Perhaps this group should band with others who may be interested in 
standardizing these things -- SSO seems like it's ripe for that. In 
other words, let's join with others on common foundational issues, 
rather than separating from them along the lines of application domains 
(VWs vs everything else).

In that sense I'd argue for #3, because doing an IETF SSO working group 
properly would require substantial change and outreach. There's a long 
history in SSOs. The good news is that from what I read in [1], there is 
now some interest in the IETF on this.

However, some issues are application-domain-specific -- e.g. avatars, 
assets;  in the Web model, these are MIME type issues. They need 
standardization too -- or at least generalized agreement on the data 
that gets passed around.

In that sense I'd argue for #2. There are MIME type standards that this 
group can define specifically for virtual worlds. That's one part of 
interoperability that only ppl in the VW field can tackle.

Crista / Diva

[1] http://isoc.org/wp/ietfjournal/?p=1715

---

From: Vaughn Deluca <[email-masked]>
Date: Sat, 15 Jan 2011 11:49:14 +0100

Although i have only been operating in the fringe of this group, i
would like to argue for #2

It clear that some refocussing and consensus building is needed, but
we should at least  give that a try. To me it seems definitely to
early to give up. If we try #2  it will become clear if  #3 can
indedeed be avoided.

I see christina's point of starting at the basis, and fixing SSO
first. However, I feel that from the perspective of VWRAP SSO is
actually a well described sub-problem that can be left to others to
solve, while we focus on the specific  of avatars and assets.

In  terms of actual commitment, i think the wiki idea is great, and i
will try to free some time to contribute there in the near future.

--Vaughn

---

From: Fleep Tuque <[email-masked]>
Date: Sat, 15 Jan 2011 09:04:38 -0500

I still feel too new to this effort to voice an opinion that counts for
much, but my sense is #1 is truly not feasible since it doesn't seem there
is general consensus on the existing document base at all.

Nevertheless, I would like to see #2 happen.  From this newcomer's
perspective, there are a number of issues that DO seem to have consensus.  I
would suggest tackling the introductory document and the parts that aren't
as controversial first.  An introductory document doesn't have to have all
the answers, it can address the outlines of the issues up for debate, no?

I also have volunteered to assist with editing and compiling feedback into
draft documents, though I don't feel the least bit qualified to be a primary
author.  I can help wordsmith, edit for readability, and help keep track of
suggested edits and I'm still 100% willing to do that.

Sincerely,

- Chris/Fleep

Chris M. Collins (SL: Fleep Tuque)
Project Manager, UC Second Life
Second Life Ambassador, Ohio Learning Network
UCit Instructional & Research Computing
University of Cincinnati
406E Zimmer Hall
PO Box 210088
Cincinnati, OH 45221-0088
(513)556-3018
[email-masked]

UC Second Life:   http://homepages.uc.edu/secondlife
OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php

---

From: Morgaine <[email-masked]>
Date: Sat, 15 Jan 2011 14:14:29 +0000

That's well said.

Frankly I've never understood why OGP/OGPX/VWRAP focussed so strongly on
login and authentication when these issues have been addressed very
thoroughly by numerous other groups.  All we ever needed was a means of
associating an agent ID with a protected credential, and that credential
could be obtained through any of the common login / authentication systems,
giving the user the choice of method.  We really didn't need to roll our
own.

Far more interesting than login would have been for us to focus on the
relationship between asset services and agents, since access to shared asset
services from various worlds is really the heart of interop.  Yet, we never
even touched on it, because for historical reasons the documents were
heading in a completely different direction.

I think we can do a lot better from here on as a result of this new group
focus on interop between worlds as the primary goal.  Option #2 looks good
to me.

Morgaine.

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

On Sat, Jan 15, 2011 at 1:23 AM, Cristina Videira Lopes
<[email-masked]>wrote:

> There is a variety of implementations for SSOs out there, more recently the
> one in the Hypergrid, and a variety of ways of securing Web services. But no
> standards that I know of -- apart from the SOAP stuff. Perhaps this group
> should band with others who may be interested in standardizing these things
> -- SSO seems like it's ripe for that. In other words, let's join with others
> on common foundational issues, rather than separating from them along the
> lines of application domains (VWs vs everything else).
>
> history in SSOs. The good news is that from what I read in [1], there is now
> some interest in the IETF on this.
>
> standardization too -- or at least generalized agreement on the data that
> gets passed around.
>

---

From: Mark Bannon <[email-masked]>
Date: Sat, 15 Jan 2011 14:00:49 +0000

Hey everyone.
Up until recently I have been more of an observer in the group due to other
committee work related to 3D development.  Now being transferred onto this
end of things so should be a lot more active in this group in the future.

With regards to our options, I would personally suggest for number two.
 Certainly some refocus is required!  Number three would be a last option
situation. At least option two would give us a chance to gather our thoughts
again and then if that didn't work, option three would be there further down
the road.  Don't think we are at the point of giving up yet.

Wiki idea sounds great.  Actually I have a bit of suggestion or question to
ask.  One of the organisations I do volunteer work for (IDCAS) has created
an excellent project management system which has a wiki built into it.  Its
just one of the things incorporated into the system but has a lot of other
helpful tools.  IDCAS currently provides a lot of free services to a number
of technology groups and even help manage a quite active registered opensim
grid association as a side project in the field of 3D internet development (
http://opensimulator.org/wiki/Grid_Associations). Mostly their work relates
to opensim but they work on other platforms too.  A lot of the discussion in
their grid association for the last 6 months has been related to
standardization of avatars, meshing and other properties.  So from what I
can tell IDCAS itself could be open to perhaps helping a group like ours out
if we asked them.  Would anyone like me to enquire about this, since they
are already heavily involved in the area of vwap and have a lot of members
in ICANN groups it may be good to see what support they could provide us.
I was using an internal volunteer/demo version of this developers system for
a different purpose last week and it has support ticketing systems,
project/task allocation, code/version management etc in addition to the wiki
so could be very useful.  Anyway basic question is would you like me to ask
if they could give us all access?  Word of warning though,
they typically dont grant access to individuals, they mostly only give it to
official non-profit based organisations and groups.  I think though that if
we asked as a "working group of IETF" there should not be a problem, after
all they granted access to a various ICANN groups in the past, precidence
thus has been set so think we would have a good chance of getting a lot of
help from them.  Who knows what else they might supply, know they are in
process of developing a framework/bridge for connecting opensim and websites
and are in partnership with the development team of ICMS (integrated client
messaging service) which is IANA port recognised (I know that because it was
one of the committees I got involved in a while ago so am aware of the
partnership that way), perhaps it could be a clever move on our part of ask
for help in "general" terms off them?

Returning to our group options though, so that we can go further from here.
I would certainly like to see us go for option two as its always difficult
with any project at the start, that can be equated to initial documentation
in the same way.  Once an initial version exists then people can work on it
and thus the framework develops further.

Mark

---

From: peter host <[email-masked]>
Date: Sat, 15 Jan 2011 16:11:56 +0100

Agreed too.

I'm not involved in the VWRAP working group but I've followed it with
interest. I'll give more of an "external" and "candid" opinion.

First, there is nothing wrong in re-purposing work (#2, #3). We might
once have thought that LL could be a key player in VW research, and
obviously they aren't anymore as most the motivated/interesting
Lindens have left the LL boat anyway. VWRAP is very much marked by
(now legacy with Humble, most likely) LL views, and they ditched the
baby.

Second, I happen to have implemented XML as soon as it appeared in
1998 for the INSEE (the main French Statistics Governmental
organization) in order to exchange data between services, and we had
tried SGML before. We eventually managed it, and designed a pipeline
based on that standard. But very soon we found ourselves trapped in
layers of complexity (xsl, xpath, namespace hell...), big bosses
liking nothing more than presenting *their* bosses a nice reassuring
report assessing that all they do is 100% standard based... Whether
the standard is appropriate not being an issue, and at the cost of a
huge developer/maintainer/education overload. As it came out, XML was
fine for a very little subset of what we did, and horrible for most of
the rest (especially tabular data and http transactions).
Then JSON came out in 2002/2003. At first, our hierarchy thought it
was a joke. But after 1 year of developing a parallel pipeline, JSON
based, they were with us. Same with Ecmascript. We ditched java
although most of the French ministries were engulfing in it (and still
suffer from it). By the way, Ecma initially is a 1guy, 4weeks project,
and Crockford did JSON in a few days. How much effort took XML ? XML
at least taught us one thing in my team, it's that it was not needed
in most of our use cases (which *is* important to know), though we
*did* manage a lot of document oriented data.

Reason why I do agree with Christa. What we need most is a SSO
standard. Corporations need to have their networks of trust, and to be
able connect them together. This is exactly, on another level, what
Hypergrid is addressing. And It's lightweight to the core, so it's
good standard material.

No decent, open economy can develop without SSO. What we're seeing now
is the proliferation of mostly closed appstores/contentstores... of
all sorts. Because these models bring accountability and enable
enforcement. (at the *ghastly* cost of monopolies). Time for a
standard. In the same line of thoughts, securing web services is the
main focus of the 'Harmony' version of  TC39 - ECMAScript.

Second area (yes i know, it's not VWRAP related) that will likely have
be addressed is re-purposing LSL to something more inter-operable,
which can run in lightweight, platform (ie mono) independent VMs too.
llHTTPrequest is fine, but well... We've all tortured it already.
LSL's event-driven, finite state machine is brilliant. Strong Type,...
not so brilliant. Interop, awfull. Most flaws relate in one way or
another to the built-in requirements of a money module. Which brings
us back to SSO.

Enough rambling on my part.
Last, I wish to thank all the people who've really worked hard on
this, because it's always very tough when key initiators and founders
of a technical project withdraw for non-technical, but
political/commercial reasons.

Reading you all is always a pleasure.

>  All we ever needed was a means of
> associating an agent ID with a protected credential,

yup

> On Sat, Jan 15, 2011 at 1:23 AM, Cristina Videira Lopes <[email-masked]>
> wrote:
>>

yup

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 15 Jan 2011 08:17:21 -0800

> lines of application domains (VWs vs everything else).

i'm sorry, i missed your counter-proposal to vwrap auth. where was it?

> some interest in the IETF on this.

also. what the heck does SSO have to do with virtual worlds? vwrap
auth was a small portion of the effort and was even considered
non-core by the implementers. the more important bits was the trust
model + service establishment (which is not part of an SSO i've been
able to fine) + control messages and request formats for assets.

> standardization too -- or at least generalized agreement on the data that

yeah. that's actually what we were working on.

> interoperability that only ppl in the VW field can tackle.

are you volunteering to write a new charter?

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 15 Jan 2011 08:26:07 -0800

Hey Barry,

so it seems like there's at least some interest for rechartering.
what's the mechanics for that? do we call for a new BoF or just hash
out a new charter on the mailing list?

-cheers
-meadhbh

---

From: Vaughn Deluca <[email-masked]>
Date: Sat, 15 Jan 2011 19:11:31 +0100

I am not convinced rechartering is actually needed. The introduction
document certainly needs an overhaul, and we to need to reaffirm we
are all on the same track, but I think that the existing charter might
still work for us. I suggest we work with it, at least until it
becomes the obvious obstacle for progress.

-- Vaughn

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 15 Jan 2011 10:48:25 -0800

you're voting for option 1 then, but are you volunteering to do the work?

the current intro XML is in SVN at http://svn.tools.ietf.org/svn/wg/vwrap/

you can check them out with the command:

svn co http://svn.tools.ietf.org/svn/wg/vwrap/ vwrap_documents

if there's interest, i'm happy to put on a 30 minute "how to edit,
write and publish an internet draft" presentation in world somewhere.

-cheers
-meadhbh

---

From: Vaughn Deluca <[email-masked]>
Date: Sat, 15 Jan 2011 21:12:20 +0100

No, i am voting for option 2. Barry wrote:

"2. Come to consensus on significant changes to the direction of the
VWRAP specs[...]  Consider rechartering, if the direction has changed
enough to require that."

All i am saying is that i don't see the need for rechartering *yet*.

--Vaughn

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 15 Jan 2011 13:27:42 -0800

whoops. yes.  meant to say "you're voting for option #2"

but my original point was that there's a fair amount of work to be
done, and i was asking if you were going to re-write the intro. if we
can't find anyone willing to do the work, we might have to go with
option #3.

-cheers
-meadhbh

---

From: Vaughn Deluca <[email-masked]>
Date: Sun, 16 Jan 2011 00:17:45 +0100

Meadhbh,
Meadhbh,

As i stated a few mails back, i am certainly willing to help, but I am
not  a proffesional in this field, and my expertise is insufficient to
play an editors role. -and to be honnest, i do not have the needed
time for such a role either. But for sure i will be making
contributions to intro document where possible.

Option 3 is conflating core participation and consensus/enthusiasm. I
am fairly optimistic about the possibility to (eventually) reach
consensus, but we might indeed be critically low on core
participation. Barry wrote "Three or four participants isn't enough"
and he is right. This tread has only a handfull of responses,
dangerously close to that level.

Close, but not there yet, we will see what happens on the wiki. If
*that* fails its time for option 3.

--Vaughn

On 1/15/11, Meadhbh Hamrick <[email-masked]> wrote:
>>>>> On Sat, Jan 15, 2011 at 2:49 AM, Vaughn Deluca
>>>>> <[email-masked]>
>>>>> wrote:

---

From: Meadhbh Hamrick <[email-masked]>
Date: Sat, 15 Jan 2011 16:05:43 -0800

options 1 & 2 require someone to step up and volunteer to author new docs.

any takers?

if no one will step up, then i think option #3 is most appropriate.

if i read barry's email correctly, euthanizing VWRAP now does not
preclude rechartering in the future if there's renewed interest.

-cheers
-meadhbh

---

From: Barry Leiba <[email-masked]>
Date: Wed, 19 Jan 2011 11:04:50 -0500

> preclude rechartering in the future if there's renewed interest.

Meadhbh is correct.  The chairs and ADs need to talk about the recent
postings, but my personal sense of it is that there are enough people
who want to continue and want to do it by steering in at least a
somewhat different direction.  That works if and only if people
actually step up and do the editing, reviews, and so on.

So, yes, if we do continue, the first step will be to have someone (or
some set of people; I'd actually be happier with at least two editors)
take over the introduction document, lead the discussion of what
should be in it, and post a revised version that starts turning the
wheel.

(And, yes, Meadhbh's last statement is also correct: we could close
the current effort and charter something related later.  On the other
hand, if "later" would be within the next year or so, I'd rather try
to continue from where we are.)

Barry, sort of as chair, but mostly just talking out of his a[vatar]

---

From: Morgaine <[email-masked]>
Date: Wed, 19 Jan 2011 19:57:19 +0000

On Wed, Jan 19, 2011 at 4:04 PM, Barry Leiba <[email-masked]>wrote:

> On the other hand, if "later" would be within the next year or so, I'd
> rather try

That's good to hear Barry, and I agree fully that continuing makes more
sense.

A change of emphasis that makes interop between worlds a central goal
doesn't require a new IETF group, since that goal is the one that most VWRAP
contributors have expressed support for all along.  There is much more
continuity in this change than discontinuity.

As for timescales, we already started work on a new Intro in October and
November, as I described in my first email in this thread.  It was being
done informally, not as an official draft but as input to a totally new
draft.  It was not being done as a revision because the previous Intro
simply did not meet key requirements for many contributors, as was clear
from the group's very intense discussions of September.

While progress is slow currently, I have the feeling that it would pick up
steam if only we didn't have to continually revisit previous battlegrounds.
Incompatible interop goals has a very chilling effect on writing
specifications for interop protocols.

Morgaine.

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 19 Jan 2011 15:15:49 -0500

> from the group's very intense discussions of September.

Can you see if you can get it into reasonable shape to introduce
publicly, and then submit it as draft-morgaine-vwrap-intro-00 ?  That
would give people something concrete to work from.

Barry

---

From: Morgaine <[email-masked]>
Date: Wed, 19 Jan 2011 21:01:01 +0000

The idea of putting this "pre-draft" on a wiki was not mine (the work was
started by two other contributors).  I fully support the goal though:  to
use a medium where lots of people can have input, even if it's just a single
paragraph or just a word correction, so that the initial draft doesn't
suffer the problem of inertia while massive changes are afoot.

It also overcomes the personalization issue that arises when drafts are
tagged officially with a particular person's name.  Since this is being done
as a collaborative effort, perhaps it would be fairer if some impartial
party tags this initial draft of the "new" Intro instead.  We've suffered
somewhat with draft personalization issues in the past.

Be that as it may, we have much work ahead of us to make this Intro a
document that reflects the group's rough consensus of aspirations on
interop, even for an initial draft.  We need more people to contribute some
typing time.  Those who found the current draft lacking in respect of
interop, this is your chance for change. :-)

Morgaine.

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 20 Jan 2011 20:04:16 -0700

With my area director hat on:

a.) I like the idea of collaborative effort at a wiki. This lowers the
barriers to entry. A big +1.

b.) I'd prefer to see this happen at the official working group wiki:

    http://trac.tools.ietf.org/wg/vwrap/trac/wiki

The main factor here is the IETF's policy on contributions, a.k.a. "Note
Well"...

    http://www.ietf.org/about/note-well.html

I am not a lawyer, but I doubt that work happening at a wiki site
somewhere else is covered under "Note Well". The last thing we want is
ambiguity about copyrights and patents, so I strongly encourage folks to
do this work at the Trac URL I posted above.

To request login credentials, go here:

    http://trac.tools.ietf.org/tools/loginmgr/newlogin

Thanks!

Peter

On 1/19/11 2:01 PM, Morgaine wrote:
> The idea of putting this "pre-draft" on a wiki was not mine (the work
> was started by two other contributors).  I fully support the goal
> though:  to use a medium where lots of people can have input, even if
> it's just a single paragraph or just a word correction, so that the
> initial draft doesn't suffer the problem of inertia while massive
> changes are afoot.
> 
> tagged officially with a particular person's name.  Since this is being
> done as a collaborative effort, perhaps it would be fairer if some
> impartial party tags this initial draft of the "new" Intro instead. 
> We've suffered somewhat with draft personalization issues in the past.
> 
> interop, even for an initial draft.  We need more people to contribute
> some typing time.  Those who found the current draft lacking in respect
> of interop, this is your chance for change. :-)
> 
> 
> Morgaine.
> 
> 
> 
> 
> On Wed, Jan 19, 2011 at 8:15 PM, Barry Leiba <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 20 Jan 2011 20:13:32 -0700

With my area director hat still on...

On 1/19/11 12:57 PM, Morgaine wrote:

> doesn't require a new IETF group, since that goal is the one that most
> VWRAP contributors have expressed support for all along.  There is much
> more continuity in this change than discontinuity.

Agreed. However, it does require a rechartered IETF group, because our
current charter is heavily focused on defining an abstract type system,
specifying data formats for objects and avatars, and developing
application-layer protocols establishing and moving avatars in a region,
identifying and requesting information about entities, etc.

The current charter is here:

    http://tools.ietf.org/wg/vwrap/charters

How would folks in this group modify the charter to properly scope the
revised effort?

Feel free to discuss that topic on this list, and to use the wiki as a
sketchboard:

Oh, and did I mention that you can obtain login credentials for the Trac
wiki at the following URL? ;-)

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Lawson English <[email-masked]>
Date: Thu, 20 Jan 2011 20:23:05 -0700

I personally like the book + wiki + forum approach found here: 
http://book.seaside.st/book

But I'm weird.

Rendering of the wiki markup can be output to PDF, latex, HTML or plain 
text and there's no reason why an IETF RFC output object couldn't be 
devised as well, to turn the finished product into the old school text 
RFCs require.

Lawson

On 1/20/11 8:04 PM, Peter Saint-Andre wrote:
>> On Wed, Jan 19, 2011 at 8:15 PM, Barry Leiba<[email-masked]

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 20 Jan 2011 20:09:35 -0800

may i ask what our success metric is?

i mean, there's not a lot of material at the wiki morgaine pointed to,
nor has anyone volunteered to implement anything.

i have to figure out whether the DSD drafts are going into this WG or
will go as individual / informational submissions for the purpose of
registering their MIME types (as well as publicly describing the type
system used by sl8.us and various unannounced augmented reality
projects.)

i was able to crank out a reviewed 30 page intro in about four months.
could i ask that since there are no implementers, morgaine et al be
held to a reasonable page count and time frame? say at least 8 good
pages (that pass the general consensus review) in four months that
describe things like:

* terminology : virtual world, avatar, etc.
* "style" of interoperability: it is sufficient to define only object
formats? are we defining wire protocols for components that make up
virtual worlds? are we defining high level "interop between world"
(whatever the hell that means)
* what's in scope of the WG (since the charter was designed to be
intentionally vague and depend on the intro for a more detailed
description of the the group's scope)
* protocol objectives (assuming we're going to define wire protocols)
* protocol "architecture" ( are we going to send everything over UDP?
raw TCP sockets? layered on top of HTTP? XMPP? BEEP? SMTP/MIME? is
anyone left that cares about abstract type systems in this group? )
* use cases : what are we expecting to happen when a user sits down in
front of a user agent?
* deployment patterns : are we requiring a grid? are we going to run
simulator responders at known ports (i.e. - one sim responder per IP
address)?
* trust model : what if i want to have a region in a virtual world
accessable only to trusted entities? what if i want to make sure they
can't take certain virtual goods out of that region?

or... if we know peeps here aren't interested in an abstract type
system, with the chair's permission, i'll take my draft directly to
the rfc editors and ask them nicely to publish it as an informational
RFC / individual submission.

-cheers
-meadhbh

---

From: Fleep Tuque <[email-masked]>
Date: Thu, 20 Jan 2011 23:40:21 -0500

Thanks Peter!  I didn't realize IETF offered a wiki for the group's use when
I suggested using the wikispaces platform - so I'll apologize for that.
 This is my first time participating and I'm still learning the ropes.  :)

As someone who's volunteered to help with editing, a wiki certainly makes it
easier to contribute meaningfully and I hope that whoever steps up as
primary authors will be willing to give it a try.

Sincerely,

- Chris/Fleep

---

From: Morgaine <[email-masked]>
Date: Fri, 21 Jan 2011 15:11:46 +0000

Good advice there, thank you Peter.

I've made myself a login at the IETF wiki and am currently playing with
markup in Trac's sandbox.  It seems very simple indeed, and clearly takes
markup ideas from MediaWiki which is so very widely known.

Where would pre-drafts, outlines, and other auxiliary /  temporary documents
go in the IETF wiki space?  (I haven't found a guidelines or best practices
page on IETF wiki use yet, but will keep looking.)

Morgaine.

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