Subject: [vwrap] Statements of Consensus. Flexibity First.

From: Carlo Wood <[email-masked]>
Date: Wed, 30 Mar 2011 03:14:58 +0200

Perhaps we should also start a wiki page (it's nice
to have a stable url that one can refer to, which still
is editable; that give me at least a feeling of progress),
about statements that we reached consensus over.

Being an abstract thinker and analyst, I believe we
can tackle many of the current discussions at a much
higer abstraction level first, making it easier, or
even possible, to deal with the more detailed points
of discussion.

I'd like to start with one such statement and ask
for consensus on it (and if not, give your rationale
why not).

* Whenever a change X in the protocol is proposed
  (which might be an addition, a change of existing
  protocol or even deletion: any change, making
  the protocol (VWRAP) go from A --> B), then that
  change is accepted as part of VWRAP provided that:
  1) Protocol B can do everything that A could do.
  2) No substantial extra demands are being made on
     an implementation that only implements the
     functionality of A.

In other words: we choose for flexibility.

Under no circumstances we want the *protocol* itself
to be a limitation in what is possible, when that
extra flexibility/possibility doesn't cost much for
those not needing or using it.

Companies be warned: that DOES mean that you lose
control: sometimes it is "nice" if it's impossible
to do with a protocol what your company doesn't
want. However, if that is what you want-- I'd like
to hear good reasons for that at THIS abstraction
level, and not while discussion details, because then
it's too easy to go against some proposal for "different"
reasons (not really saying that what you really want
is that something is just not possible with the protocol,
in order to garantee that things will deviate from YOUR
goals and ideas).

I sincerely hope we can reach consensus on this and
ask everyone to give their 'yes' or 'reasons for their
no'.

-- 
Carlo Wood <[email-masked]>

---

From: Morgaine <[email-masked]>
Date: Wed, 30 Mar 2011 10:01:33 +0100

I support Carlo's call for maintaining a page on the IETF wiki that lists
requirements and implementation details in a concise format,and hence marks
our progress along the path.  The items on the wiki would then be required
to be included in subsequent released specification drafts, at least through
placeholders.

Carlo, your suggested paragraph for consensus is a good one, but is too easy
to evade .  It makes it trivial for a detractor to argue that "substantial
extra demands are being made [by B] on an implementation that only
implements the functionality of A", because every B will impose extra
demands on A."  That exception contains the recipe for neutralizing all
progress.

Instead of providing such an easy opportunity for veto by people who only
want A, place the onus on the people requiring B, which is much more forward
looking.  I suggest something like this:

   - Whenever a change X in the protocol is proposed (which might be an
   addition, a change of existing protocol or even deletion: any change, making
   the protocol (VWRAP) go from A --> B), then that change is accepted as part
   of VWRAP provided that:

   1. Protocol B can do everything that A could do.
   2. Good use-case justification for B is provided.
   3. Implementation requirements of B are listed.

This would make it clear that features are incremental (A+B must always be a
superset of A), offer an initial level of technical detail about how
functionality B can be achieved, and most importantly, make everyone aware
of the impact that B has on A.  It will also ensure that an implementation
that provides A but not B is by choice a subset implementation.

Morgaine.

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

On Wed, Mar 30, 2011 at 2:14 AM, Carlo Wood <[email-masked]> wrote:

> _______________________________________________
> vwrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vwrap
>

---

From: Boroondas Gupte <[email-masked]>
Date: Wed, 30 Mar 2011 13:29:56 +0200

> about statements that we reached consensus over.
Good idea.

> even possible, to deal with the more detailed points
We'll probably have to switch back and forth between levels of
abstraction during the discussion. A pure top-down design often won't
work. But I feel it's indeed reasonable to start at a higher abstraction
and see where we can go from there.

>   change is accepted as part of VWRAP provided that:
Formulated like this, it sounds like the following requirements together
would be sufficient for acceptance. I guess you rather wanted to express
that they should be necessary for acceptance, but might not be
sufficient (further requirements might apply).

>      an implementation that only implements the
As necessary but not sufficient acceptance requirements, I can consent
to these. I cannot consent to them as sufficient acceptance requirements.

> In other words: we choose for flexibility.
Or more specifically, total backwards compatibility between versions of
VWRAP. However, to make it easy (or at least easier/possible) to design
changes X or new versions B, such that they fulfill these backwards
compatibility requirements, we should already design previous versions A
for "forward compatibility".

If I remember correctly, you have made suggestions in past messages on
how to achieve such forward compatibility (e.g. protocol versioning
combined with protocol negotiation).

> those not needing or using it.
Agreed.

Cheers,
Boroondas

---

From: "Dickson, Mike (ISS Software)" <[email-masked]>
Date: Wed, 30 Mar 2011 14:27:27 +0000

> about statements that we reached consensus over.

We don't need to make a process that forces agreement under a set of terms.  That's not how the IETF 
works.  We need consensus and documents.  As a contributor I'll choose to agree or disagree based on
the topic.  And in some cases I'm not sure I'd choose flexibility over stability, etc.

It seems to me we've sorted drifted to a point we're there are 2 camps and a proposal was made for how to
deal with it.  There are those that want to work on service level interop.  And others want to define the
whole concept of virtual world interop. IMO we need to either agree that seperation exists and arrange the 
docs so it describes the 2 work streams or agree that we can't agree and disband.  The service level interop.
is a subset of the other and given our track record I prefer to walk rather than run.  And I don't buy the "evil 
corporate interests" argument.  Ideally if  we do this right there *should* be some participation from business
interests that are looking at the space.

So in summary, no, I'm not going to agree to a fixed process that favours flexibility.  The IETF already has
a process for how this stuff gets worked.   And we need to decide what we're working on and move on. I 
think there's room for 2 work streams here and that personally would be my vote.  I'll put my energy into
service level interop personally.

Mike (speaking as me and not for HP)

---

From: Morgaine <[email-masked]>
Date: Wed, 30 Mar 2011 16:23:19 +0100

Mike, if you don't need the flexibility available in a protocol, simply
don't use the flexible features that you don't want.  But denying those who
require a flexible and extensible protocol with a degree of future-proofing
to it is, I believe, not in line with the goals expressed here from the
start of this process.

Perhaps closed enterprises don't need flexibility, but open communities
certainly do, and they are typically long-lived and hence require the
ability to evolve and to adapt to change.  And open communities most
certainly need interoperability between their many virtual worlds.

The needs of inwardly-focused companies do not override the needs of open
Internet communities.  This IETF protocol project serves both sets of
interests, and it will need to satisfy both sets of requirements.

Morgaine.

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

---

From: Mike Dickson <[email-masked]>
Date: Wed, 30 Mar 2011 11:40:45 -0400

On Wed, 2011-03-30 at 15:23 +0000, Morgaine wrote:
> Mike, if you don't need the flexibility available in a protocol,
> simply don't use the flexible features that you don't want.  But
> denying those who require a flexible and extensible protocol with a
> degree of future-proofing to it is, I believe, not in line with the
> goals expressed here from the start of this process.

That's not actually consistent with what I thought Carlo wrote.  There's
only one set of specs and I didn't see a commitment to backwards
compatibility, only that flexibility to evolve features would take
precedence over other factors.  And honestly all of this is moot.  I'm
not personally going to agree to any overriding principle other than to
participate in the process and try and reach consensus in the documents
produced. This whole discussion is a proverbial "red herring".  We don't
need to agree on how to produce consensus we need to agree on what goes
into the documents.

> 
> Perhaps closed enterprises don't need flexibility, but open
> communities certainly do, and they are typically long-lived and hence
> require the ability to evolve and to adapt to change.  And open
> communities most certainly need interoperability between their many
> virtual worlds.

I personally believe that focusing on services definitions and interop
will produce the needed "flexibility" your after.   I really want that
level of flexibilty (to be able to compose "virtual worlds" flexibly)
hence the reason I think focusing on the services is important.  And I
doubt that corporate needs and individual needs are that different in
this respect. Use models for VW technologies are still evolving.

> The needs of inwardly-focused companies do not override the needs of
> open Internet communities.  This IETF protocol project serves both
> sets of interests, and it will need to satisfy both sets of
> requirements.

Yes, I get that. I have lots of standards experience, even serving on
the board of one organization in the past.  I honestly find the whole us
vs. them rhetoric tiring.  A healthy community will include both
individual and corporate interests.  And its to be expected that they'll
all argue from their respective POV.  That's healthy.

Mike

> 
> 
> Morgaine.
> 
> 
> 
> 
> 
> ========================
> 
> 
> On Wed, Mar 30, 2011 at 3:27 PM, Dickson, Mike (ISS Software)
> <[email-masked]> wrote:
>         
>         works.  We need consensus and documents.  As a contributor
>         I'll choose to agree or disagree based on
>         It seems to me we've sorted drifted to a point we're there are
>         2 camps and a proposal was made for how to
>         deal with it.  There are those that want to work on service
>         level interop.  And others want to define the
>         whole concept of virtual world interop. IMO we need to either
>         agree that seperation exists and arrange the
>         docs so it describes the 2 work streams or agree that we can't
>         agree and disband.  The service level interop.
>         is a subset of the other and given our track record I prefer
>         to walk rather than run.  And I don't buy the "evil
>         corporate interests" argument.  Ideally if  we do this right
>         there *should* be some participation from business
>         So in summary, no, I'm not going to agree to a fixed process
>         that favours flexibility.  The IETF already has
>         a process for how this stuff gets worked.   And we need to
>         decide what we're working on and move on. I
>         think there's room for 2 work streams here and that personally
>         would be my vote.  I'll put my energy into

---

From: Mike Dickson <[email-masked]>
Date: Wed, 30 Mar 2011 12:20:34 -0400

On Wed, 2011-03-30 at 17:02 +0000, Kopilo Hallard wrote:
> On 31-03-2011 1-10, Mike Dickson wrote:
> Huh, Morgaine was writing about interoperability in regards to future 
> flexibility not backwards compatibility...

Yes, and I'm saying I'm not going to agree that flexibility is *the*
most important guiding principle over other factors like compatibility.
That was the original assertion (that we should agree that flexibility
is most important).   I'm going to agree or disagree to things that go
into documents based on their individual merit and not an overriding
principle. I don't see any benefit in trying to get agreement that
flexibility is most important.

Here's a for instance...  I happen to like LLSD not because its elegant
and wonderful but because there are actually viewers I can use that
implement it.  I bet we can sort out a protocol mechanism that could
support other encoding formats between services but I don't want to
throw out LLSD because its not forward thinking or "most flexible".  I'm
guessing we can make the best decision about issues like that when
discussing specific examples of service level interoperability.  So
agreeing in advance that we should focus on "flexibility" doesn't help.
It simply derails the important discussion about what we're talking
about; wether service level interoperability is what we need to be
focused on or something more (or both as 2 work streams).

Mike

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 30 Mar 2011 10:11:12 -0700

Mike Dickson wrote:
> [...] So

This pretty much concludes we need solid definition of "service level 
interoperability" due to the fact that it is being used flexibly at the 
moment to whatever best interest of said-defined parties. I know 
everyone hates to hear it that way, yet let's not future push away by 
such newer terminology.

Documents exist that define partitions to region/agent protocols, so why 
can't we start there? Are they too drafty?

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Morgaine <[email-masked]>
Date: Wed, 30 Mar 2011 18:13:28 +0100

> all argue from their respective POV.  That's healthy.

Unfortunately that tension will not go away, because the needs of businesses
and the needs of user communities are inherently in conflict in our area,

To put it bluntly, VW *business* thinks it is best served by denying interop
between worlds, because denying interop holds users captive and prevents
them from easily leaving with their virtual possessions to better worlds.
(A myopic business model, I agree, but we have many current examples of it.)

In contrast, interop between worlds serves *individuals* and *user
communities* wonderfully in numerous ways:

   - It frees users from being at the mercy of a large but poor VW operator.
   - It greatly increases competition and puts downward pressure on prices.
   - It allows users to visit potentially thousands of worlds without having
   to register new accounts everywhere just to be able to visit.
   - It creates a whole culture out of virtual tourism, and probably a
   business.
   - It avoids having to recreate avatars and obtain new virtual clothing in
   each new world visited, which is a major pain point for all VW tourists.
   - it greatly increases the value of virtual goods to their owners when
   they can use them everywhere, particularly virtual clothing. Items that are
   imprisoned in their home worlds are highly unsatisfactory, analogous to
   music that you cannot move from one music player to another.
   - It aids in cooperative working when there are no artificial barriers
   erected between worlds, and this advantage spans a huge number of realms,
   from higher education and research through to the smallest groupings of
   people getting together to share common interests.
   - Philosophically, it removes the stranglehold of world operators on the
   virtual items created by their residents, and makes taxation on items much
   more difficult to impose without negative repercussions.

The disparity between VW business and VW community goals is so vast that
this tension is here to stay, as long as VW businesses believe in the
short-term gains of closed systems versus the big picture of a huge open
metaverse of millions of interoperating worlds, full of opportunities.

Morgaine.

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

---

From: Mike Dickson <[email-masked]>
Date: Wed, 30 Mar 2011 13:46:03 -0400

> can't we start there? Are they too drafty?

If we can get agreement amongst a set of folks that want to work from
that perspective (I do) then I agree that starting with existing
"service" definitions and the partitioning of work into services and
protocols is the appropriate place to (re)start.

Mike

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 30 Mar 2011 10:45:23 -0700

> communities* wonderfully in numerous ways:

I wouldn't doubt that some of this can be address in the same theme 
COLLADA has done with conditioners and refineries. The only reason to 
make sure the protocols work abroad would be for the most optimal 
network usage. The mere effort, otherwise, to get data from one system 
to another can be in various formats.

As for VW to VW... I don't see the need for consistent optimal protocol 
that is custom to VWRAP. The only need (maybe illusionary) here is that 
being the monolithic client can connect to any of these VWs. We could, 
however, just pass COLLADA data to the client and that would do the same 
justice. Of course, this is a bit rough.

--

---

From: Morgaine <[email-masked]>
Date: Wed, 30 Mar 2011 19:07:46 +0100

No Dzonatas, that's not enough to handle the requirement.

When I TP from world X to world Y (which I may never have visited before),
my identity, avatar and clothing need to persist across the teleport, and
the elements that I carry with me (such as clothing) may come from many
different worlds which I have visited previously, and be served from their
individual asset services while I'm away touring in world Y.

What's more, visiting thousands of worlds and having to make accounts at
each of them is untenable, and will stop virtual worlds from flourishing.
It creates a major stumbling block for user acceptance.

What's needed cannot be accomplished with client-side trickery.  It needs
regions to understand multiple non-local asset services, and portable
avatars, and single sign on, and it needs many of the protocols that we use
in our region-proxied worlds to change, not only to cater for this required
flexibility, but also for scalability and robustness in a distributed
architecture which we've discussed here before.

Morgaine.

On Wed, Mar 30, 2011 at 6:45 PM, Dzonatas Sol <[email-masked]> wrote:

> I wouldn't doubt that some of this can be address in the same theme COLLADA
> has done with conditioners and refineries. The only reason to make sure the
> protocols work abroad would be for the most optimal network usage. The mere
> effort, otherwise, to get data from one system to another can be in various
> formats.
>

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 30 Mar 2011 11:23:53 -0700

Morgaine wrote:
> When I TP from world X to world Y (which I may never have visited 
> before), my identity, avatar and clothing need to persist across the 
> teleport, and the elements that I carry with me (such as clothing) may 
> come from many different worlds which I have visited previously, and 
> be served from their individual asset services while I'm away touring 
> in world Y.

Of course, like I said, it is rough, so there is no need to assume that 
it will not be handled by even less optimal formats. That point being 
that even the COLLADA format has conditioners/refineries  that document 
how to do such above. The difference only being doing it LIVE and doing 
it through asset servers, which still are not separated from the region.

>
> What's more, visiting thousands of worlds and having to make accounts 
> at each of them is untenable, and will stop virtual worlds from 
> flourishing.� It creates a major stumbling block for user acceptance.
>
> What's needed cannot be accomplished with client-side trickery.� It 
> needs regions to understand multiple non-local asset services, and 
> portable avatars, and single sign on, and it needs many of the 
> protocols that we use in our region-proxied worlds to change, not only 
> to cater for this required flexibility, but also for scalability and 
> robustness in a distributed architecture which we've discussed here 
> before.
>
>

Please be sure to read up on COLLADA format and notice that it is a 
digital asset exchange format for doing much of the above. We just need 
to make sure we do not reinvent the wheel (its "rough").

I think what "client-side trickery" is the pretense that there will be 
no need for "manufactured" objects. You stated above, however, the 
"manufactured" case of which assets may come from different non-local 
areas. No need to spin this or make such assumption as you did. Please 
do your homework.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 30 Mar 2011 11:45:01 -0700

I hope authentication with optional PGP/GPG signed assets are part of 
the first level of service definitions/partitions. This may be as simple 
as the optional sign-on authentication debated about half-year or so ago 
on this list.

--

---

From: Mike Dickson <[email-masked]>
Date: Wed, 30 Mar 2011 16:51:42 -0400

> be served from their individual asset services while I'm away touring

And the content you carry with you may be scripted with state that needs
to be propogated. And physical objects (if there is such a thing on teh
target, may behave differently,... etc...).   Oh yeah, and some content
providers may not permit content on certain grids.  

The problem you want to solve is, at present, intractable.  There are
solvable ones that moves us in the right direction. If we take those
steps just maybe we can solve the harder problems.  If you make the
problem impossible then we never make progress.  This is BTW the
different IMO between VW interop and service level interop.  To do the
latter I don't need to insure exactly the same behavior across
platforms. Just that I can share some service definitions and therefore
identity, content, etc.  And that to me is a good start.

Mike

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 30 Mar 2011 14:07:28 -0700

Yes, this has all been taken into consideration (state, script state, 
omegas, targets, etc)... and even considered what scripts run 
client-side and which will run region-domain.

With the monolithic design, we know it's still mainly region-side, which 
has been also called server-side (and quite backwards in concepts to X11).

Right now, if you just want to share content, there are various export 
and import means. I think people would want to upgrade that level with 
authentication, however.

In the end, the region-side need not to know anything except physics and 
presence, as the client does most of the graphic work already. That 
means most of the information in the files can persist at the 
client-to-client level and never really needs to reach across the 
region-domain. This is nothing new and has been discussed before.

--

---

From: Morgaine <[email-masked]>
Date: Wed, 30 Mar 2011 22:21:54 +0100

On Wed, Mar 30, 2011 at 9:51 PM, Mike Dickson <[email-masked]> wrote:

> The problem you want to solve is, at present, intractable.

Wrong, Mike.

It's you who added two "intractable" problems just now (scripting and
simulation), not me. Every piece that I mentioned is easily tractable, and
indeed we have been discussing elements of how to do it here all along.
It's not a hard problem at all.  It mostly just requires avoiding singletons
for services.

Of course if you wanted to replicate Second Life portably as a standard,
that is a highly intractable problem, but we have never had that as a goal
here, and I in particular have never suggested that any such thing is needed
for VW tourism.  Not only is it not needed, but nobody would implement those
things as Linden Lab has done them anyway if they were doing it afresh for a
spec.  (They would undoubtedly be using an industry standard scripting
language, for starters.)

So no, you've just raised a straw man of your own invention and then knocked
it down.  Your response is incorrect for the requirement given.

Morgaine.

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