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

From: Carlo Wood <[email-masked]>
Date: Fri, 1 Apr 2011 15:45:09 +0200

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

I meant it to be "sufficient".
If both statements are satisfied then it would be
completely weird and suspicious if anyone would go
against the proposal.

If not both statements are satisfied, or when
it's not clear, then that does not mean that X
shouldn't be part of the protocol, but then more
discussion is necessary.

-- 
Carlo Wood <[email-masked]>

---

From: Carlo Wood <[email-masked]>
Date: Fri, 1 Apr 2011 15:58:03 +0200

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

> 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.

True... it might be too vague and senseless discussion might
take place about what is substantial... Therefore I hope that
by far most, if not all, people involved TRUELY think, like me,
that in principle the protocol should support everything that
is even remotely possibly necessary for some use case. Especially
when it adds no complexity for those implementers who aren't
interested in the extra functionality.

For example, someone could propose to add 'X' that would allow
something that 'Grid Y' doesn't want on THEIR grid. However,
all that is required for them is to add a single parameter to
some protocol message, ie - the parameter FALSE, to signal they
don't want it. Then based on that it should be impossible to
try and bar support for X from the protocol itself: Y would
be "forced" to add that 'FALSE' in order to support X passively.

> 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.

Although I do not protest against the reformulation,
I have to note that it's as easy to go against point 2:
people can always argue that it's not a "good use-case";
and it isn't in their eyes when they are really opposed
to the whole idea.  Therefore I think it's better to
say something like: if two or three people think it's
a good use case. After all, the whole idea is that those
who don't think that it is, will have to ability to
not support it on their grid, but should not have the
ability to bar it from the protocol.
 
> 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.

I don't see it like that. A 'subset' seems to suggest
incompatiblity. For example, if one world allows it's visitors
to use assets from any source, including their own harddisk,
while another world doesn't want to allow that for various
(non-technical) reasons, then the protocol had to support it
nevertheless. The latter world would just reply differently
to certain protocol messages, but still be within the protocol
and AWARE of the possiblity that allowing it is possible.
They'd only refuse it.

I don't really see that as supporting a subset of the protocol,
if you understand what I mean.

Carlo Wood

---

From: Carlo Wood <[email-masked]>
Date: Fri, 1 Apr 2011 16:13:32 +0200

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

> 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.

Nobody forces you to anything. I'm asking if there is consensus
about this point. Frankly, I'm disappointed that you disagree
already - at THIS level of abstraction. Perhaps it's caused by
a false sense of fear that you would be forced to accept things
into the protocol: you clearly want control. You want to decide
on a case by case basis if you like it or not.

But hell, that is NOT possible at this abstraction level.
Please rethink carefully what the proposal means: do you REALLY
want to reject the Ideal of an open protocol that doesn't deny
support for use-cases that YOU don't want?

>  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.

I don't see the 'etc' here. And IF the minimal support that
an implementer would have to add who does NOT needed X would
lead to instability then surely you wouldn't be able to speak
of "No substantial extra demands are being made"!

If implementation is so difficult, even for implementers NOT
needing it, that it causes the danger of instability then you
have EVER possibility to go against it, even if now you agree
with the Principle of trying to be flexible.
 
> 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.

I am not really sure how this applies to making the choice if
you want to be flexible, or - put differently - want to cripple
the protocol to make certain applications of it impossible.

>  And I don't buy the "evil corporate interests" argument.

... unless this is the case. And you just want to win a battle
before it started.

>  Ideally if we do this right there *should* be some participation
> from business interests that are looking at the space.

A flexible protocol would be superset of what those businesses
need (see point 1: Protocol B can do everything that A could do).
So, if they would be interested when the protocol can only do A,
please explain why they won't be interested anymore when it
can do B?

> Mike (speaking as me and not for HP)

---

From: Carlo Wood <[email-masked]>
Date: Fri, 1 Apr 2011 16:19:29 +0200

On Wed, 30 Mar 2011 11:40:45 -0400
Mike Dickson <[email-masked]> wrote: 
> 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

Then please explain to me again why you want
to make it impossible for some party to use
VWRAP for their specific use case, and apparently,
are only interested to create a protocol that
supports your use case (and those things that
you are not going to oppose to when they are
proposed, for the sake of creating a standard
at all).

What is the problem to make it possible to use
VWRAP by an as wide as possible group of people?

---

From: Carlo Wood <[email-masked]>
Date: Fri, 1 Apr 2011 16:27:15 +0200

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

> 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).

You really misunderstood the intention (so maybe there is still hope).

The statement: protocol B can do everything that protocol A can do
completely eliminates this extra flexibility override ANYTHING.

You seem to fear that "flexibility" is going to be "more important"
than something else and "push something else aside". But that is not
the case: the whole point is to not do what makes no sense (read
that again).

And in my eyes, it makes no sense to not add support to the protocol
for X when that has not a single disadvantage.

Then when it has a tiny little disadvantage; like you need to spend
5 minutes to think about it and it will add a chapter to the documents
that you'll have to skip when reading it, or even you need to write
10 extra code lines to deal with procotol commands that you won't
implement... then why want to deny all that to those who DO need it?
That still makes no sense.

I'm not trying to force anything specifically upon you. Not at all.
I'm trying to reason something that is just pure logic imho.
  
I had not expected that anyone would have had ALREADY a problem
with the very first, almost trivial logical proposal for consensus :(

---

From: Boroondas Gupte <[email-masked]>
Date: Fri, 01 Apr 2011 16:27:53 +0200

On 04/01/2011 03:45 PM, Carlo Wood wrote:
> discussion is necessary
I probably had some misconception of what this is about. You are talking
about what can go into the protocol at all? Or how different (released,
not just proposed) versions of the protocol might differ?

In my first answer, I assumed the latter. If it's the former, I think I
can agree even to the "sufficient" notion.

Cheers,
Boroondas

---

From: Carlo Wood <[email-masked]>
Date: Fri, 1 Apr 2011 16:36:21 +0200

On Wed, 30 Mar 2011 18:13:28 +0100
Morgaine <[email-masked]> wrote:
> 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:

While this is probably all true.

PLEASE EVERYONE - adding some SUPPORT to the protocol
does NOT mean it has to be USED.

If the VWRAP protocol supports *all* interop at any level,
then the large business can STILL deny their users to level
and take their assets with them.

The protocol will NEVER demand you do something that you
don't want.

What we speak about here is that the standard - VWRAP - will or
will not allow "others" to *use* VWRAP for THEIR purposes.

So, I'm sorry - but if anyone is against THAT.. and even has
the slightest hesitation to agree that VWRAP should support
all interests out there (ie, the business model above, as well as
the more user oriented one) then I have a good case to believe
in the "evil corporate" theory.

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 01 Apr 2011 07:59:54 -0700

> for X when that has not a single disadvantage.

The use-case of optional parameters as given previously on this list is 
easy to add. I'm sure those that want the flexibility for proprietary 
reason will want the optional context allowance, not the actual content 
specified.

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

---

From: Morgaine <[email-masked]>
Date: Fri, 1 Apr 2011 16:01:12 +0100

I agree 100% with every point made by Carlo in this post.

Please note that I have extended Carlo's 2-clause proposal from his earlier
email, because in his original formulation, flexibility in the protocol is
easily vetoed by backward-looking detractors or vested interests.

My formulation is here --
http://www.ietf.org/mail-archive/web/vwrap/current/msg00637.html .  I am
sure it can be improved still further.

My goal is that (i) new areas of flexibility should be justified by use
cases and supported by engineering solutions, and (ii) not subject to veto
by those who are not interested in those use cases.  That's how you make
technical progress.

Morgaine.

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

On Fri, Apr 1, 2011 at 3:13 PM, Carlo Wood <[email-masked]> wrote:

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

---

From: Mike Dickson <[email-masked]>
Date: Fri, 01 Apr 2011 16:55:53 -0400

> You really misunderstood the intention (so maybe there is still hope).

I think perhaps I did misunderstand. It's just that I don't feel that
discussion at a purely semantic level makes sense in cases like this.  

For instance if you said you wanted to build flexibility into protocols
used between service endpoint A and service endpoint B and proposed:

- That stateful communications would negotiate capabilities from a set
of required and optional capabilities.
- That an implementer was free to NAK those optional capabilities they
didn't wish to implement.
- For stateless communication, that if a service is unable to fulfill a
request they can fail it in a way that the caller understands the
service isn't implemented.

All of these statements being focused on flexibly evolving the set of
protocols in order to maximize benefit to the implementers.

That is a concrete example directly related to the work we're doing.
And something I could agree to.  But saying we value flexibility as a
principle doesn't help me when it comes to protocol design.

So in general I think we agree, yes.  Assuming this example made sense.

Mike

---

From: Izzy Alanis <[email-masked]>
Date: Mon, 4 Apr 2011 23:02:14 -0400

I applaud the effort to further the documentation... but, what does it
mean to say "then that change is accepted as part of VWRAP"?

> * Whenever a change X in the protocol is proposed (which might be
> change, making the protocol > *# (VWRAP) go from A --> B), then
> that change is accepted as part of VWRAP provided that:
> *# Protocol B can do everything that A could do.
> *# Good use-case justification for B is provided.
> *# Implementation requirements of B are listed.

Things that have *consensus* become part of the protocol. If changes
meet reasonable criteria (such as the above), they will be more likely
have consensus. Changes that do things like break backwards
compatibility or limit 'flexibility' will likely be hard to get
consensus on.

But I agree with Mike when he said "We don't need to make a process
that forces agreement under a set of terms...".

That's not an argument against flexibility. But I do question why we
need to have consensus on this abstract meta-issue? Do we really need
explicit written consensus on overly general principles like
"flexibility is good", or "scalability is good" or "sunshine and
puppies are good" to make progress? Specific features and details will
or will not become part of the protocol based on their merits.

If a minority interest (a potential "vetoer") has no interest in a
particular use case, and their concerns are resolved or mitigated --
by limiting the impact to their implementation of the previous version
of the protocol, making the change/proposed feature optional, etc --
then we can still reach consensus. Consensus doesn't mean unanimity.

---

From: Morgaine <[email-masked]>
Date: Tue, 5 Apr 2011 05:30:28 +0100

I expect that Carlo wanted prior agreement on the principle of generally
accepting superset requirements simply to avoid perpetual wrangling between
progressives and regressives.  Or if that term is disliked (nobody likes to
admit that they are regressive after all), between those who want to design
for tomorrow and those who want to design for today.

And it's not only a theoretical worry either, because we've already seen
several instances of participants not wanting to design for tomorrow, for
example in not wanting the open metaverse of VW tourism, or arguing against
open extensibility, or rejecting IPv6-specific enhancements.

I'm on the "design for tomorrow" platform, but I do recognize that if you
want the cart pulled in a specific direction then you have to be the
principle puller yourself.  You can't expect others who don't share your
interest to pull it for you.

This is why I added points #2 and #3 so that the onus is on the people who
have the superset requirements to justify them and do the design legwork for
them.

Point #1 is just as important though.  As long as a new requirement results
in a protocol that is a superset of the previous one, detractors argue
against it either because they see very strong engineering reasons why it is
bad or else they argue unconvincingly, because having your requirement
included but vetoing someone else's requirement just because you don't want
it is unacceptable.  This is why supersets are important:  they replace
one-side-wins either/or arguments by both-sides-win either/and arguments,
which gain agreement much more easily.

Funnily enough, we've already heard arguments against the motherhood and
apple pie of scalability, so I had to chuckle when I read your penultimate
paragraph. :-)

I support Carlo's suggestion very strongly.  These are such early days in
the evolution of virtual worlds that designing for today seems just plain
silly to me, and I would like to see "design for tomorrow" enshrined by
agreement.

Morgaine.

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

---

From: Carlo Wood <[email-masked]>
Date: Tue, 5 Apr 2011 15:20:25 +0200

On Mon, 4 Apr 2011 23:02:14 -0400
> or will not become part of the protocol based on their merits.

Clearly we do: we already can't reach consensus on
something as logical (aka Spock) and trivial as my very first
meta-issue as you call it. That baffles me, and to be
honest, that alone is reason again for me to abandon this
project.

It is ridiculous that not everyone just said: Aye / Ok / Of course /
trivial!

I can only guess to the reasons (varying from stupidity (you'd never
see such reactions on a mailinglist with math researchers) to paranoia),
but it definitely is working against any progress.

The discussions (and non-progress) on this mailinglist makes me
think of a book I once called read, "Surely you're joking, Mr.Feynman"
(http://buffman.net/ebooks/Richard_P_Feynman-Surely_Youre_Joking_Mr_Feynman_v5.pdf
about page 67, starting with "This committee had men like Compton and
Tolman...").

---

From: Carlo Wood <[email-masked]>
Date: Tue, 5 Apr 2011 17:15:00 +0200

Well said. A lot less specific and "mathematical" but
I agree that the phrase "design for tomorrow" captures
a great deal of the idea behind it.

As I said a few times before now... We can impossibly
know what the future will bring, or require. In fact,
we will very likely be unable to design the protocol
the Right Way for today either, on our first attempt.

We should realize this and think ahead: flexibility is
the only way to deal with that in the future. [For the
not so "great men": the picture I have in my head with
this is several large virtual worlds that are using VWRAP,
with hundred of thousands of users. Then we discover
that something is inefficient or just can't be gotten
right. There is a solution but it would require to
change the definition of VWRAP. This IS going
to happen. Don't ignore it until it's too late (until
that day where already thousands are using the protocol)]

On Tue, 5 Apr 2011 05:30:28 +0100
Morgaine <[email-masked]> wrote:
> I support Carlo's suggestion very strongly.  These are such early
> days in the evolution of virtual worlds that designing for today
> seems just plain silly to me, and I would like to see "design for
> tomorrow" enshrined by agreement.
>
> Morgaine.

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 05 Apr 2011 09:38:30 -0700

Carlo,

Do you think we are ready to implement some asset services now, 
with/without complete documentation?

What more do you think is needed?

--

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 05 Apr 2011 09:44:19 -0700

Izzy,

After the months that have gone by I would like to see what we can 
implement. I pointed out asset services as the obvious piece we can 
unitize somehow.

I think we got the login process documented enough to move in this 
direction. It just seems stuck at the actual transfer of assets due to 
the load of comments about this main task.

Some implementation would help us take further steps to document more.

--

---

From: Izzy Alanis <[email-masked]>
Date: Tue, 5 Apr 2011 13:03:36 -0400

I'm not against the "design for tomorrow" platform. I'm pro-"design
for tomorrow", but I believe the proposition, as currently worded,
does not appropriately communicate those intentions.

I could agree with the following wording (though I still don't believe
it communicates your 'design for tomorrow intentions'):

* 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
*# Protocol B SHOULD do everything that A could do.
*# Good use-case justification for B MUST be provided.
*# Implementation requirements of B MUST be listed.

---

From: Morgaine <[email-masked]>
Date: Tue, 5 Apr 2011 19:56:21 +0100

On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol <[email-masked]> wrote:

> Two or three things seem to be needed:

   - Defining the asset addressing concept is an extremely important matter,
   almost certainly the most important matter of all, because that determines
   how robust and scalable our worlds will be.  I've already examined
   alternatives for that in some depth, and the design with the best
   engineering properties so far seems to be universal hash-based addressing.
   I first described that approach on the list here ---
   http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html , and
   referred to it in various subsequent discussions.

   - Defining the data flows between regions, clients, and asset services
   and which parameters control the flows needs to be done before a test asset
   service can be implemented.  Without that, an asset service is just a
   network-accessible storage service, not an asset service in the VWRAP
   sense.  Network storage services exist already, so just implementing one of
   those would not advance VWRAP.

   - We need to examine how various deployment patterns will use the asset
   services, and how the *multiple* asset services that interop introduces
   are handled.  I am working on this currently.

None of the above is particularly hard.  I think it won't be long before we
have a scheme worked out and are ready for some implementation work.

Morgaine.

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 05 Apr 2011 12:56:05 -0700

Morgaine, we mooted your hash-based idea. This does nothing to help 
implement asset services. The only significant point you made is some 
expression for optimization, not correct functionality, which is needed 
first

As for your other two, we can summarize those with public resources and 
flow (forward/reverse). Any more specific network topology than that 
only makes it harder to address. The only thing to worry about is 
already custom resources that overlap with newer public resources.

Morgaine wrote:
> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     * Defining the asset addressing concept is an extremely important
>       matter, almost certainly the most important matter of all,
>       because that determines how robust and scalable our worlds will
>       be.� I've already examined alternatives for that in some depth,
>       and the design with the best engineering properties so far seems
>       to be universal hash-based addressing.� I first described that
>       approach on the list here ---
>       http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html
>       , and referred to it in various subsequent discussions.
>
>     * Defining the data flows between regions, clients, and asset
>       services and which parameters control the flows needs to be done
>       before a test asset service can be implemented.� Without that,
>       an asset service is just a network-accessible storage service,
>       not an asset service in the VWRAP sense.� Network storage
>       services exist already, so just implementing one of those would
>       not advance VWRAP.
>
>     * We need to examine how various deployment patterns will use the
>       asset services, and how the /multiple/ asset services that
>       interop introduces are handled.� I am working on this currently.
>
>
> None of the above is particularly hard.� I think it won't be long 
> before we have a scheme worked out and are ready for some 
> implementation work.
>
>
> Morgaine.
>
>
>
>
> ------------------------------------------------------------------------
>

--

---

From: Carlo Wood <[email-masked]>
Date: Tue, 5 Apr 2011 23:11:44 +0200

On Tue, 5 Apr 2011 13:03:36 -0400
Izzy Alanis <[email-masked]> wrote:
> change, making the protocol (VWRAP) go from A --> B), then

That completely changes the whole intent of the proposal:
to make progress by reaching consensus on an (abstract) goal.

My goal is to have less discussion about whether or not something
should be supported by making clear that if there is even a single
use case, maybe, that might need it, then why not? Then people wont
have to defend anymore why that use case is essential, or morally ok,
or not endangering the private agenda of someone. Then it's just
clear from the start that "Oh yes, someone might want that, so VWRAP
HAS to support that"... There shouldn't be any discussion about
something like that.

In your bullet points, I don't see that goal back at all anymore.

Worse, I oppose to it.  If A then B is NOT the same as if B then A.
You changed the meaning completely. What you are saying that it
is forbidden to even make a proposal for a change unless the result can
still do exactly what it could be before that. That means we can't make
any real CHANGES anymore. Everything we have done so far is set in
stone and apparently holy (correct, without errors).

---

From: Morgaine <[email-masked]>
Date: Tue, 5 Apr 2011 22:21:51 +0100

Unfortunately your response was devoid of technical content, Dzonatas.

If you have something technical to say about hash-based addressing, I would
love to hear it.

I have detailed in some depth the many benefits of hash-based addressing in
the article I linked, and subsequently.  If other good schemes exist, we
should of course analyze them for technical merit and compare their benefits
against those of hash-based addressing.

That's the engineering process for making VWRAP as good as it can be.

Morgaine.

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

On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol <[email-masked]> wrote:

> flow (forward/reverse). Any more specific network topology than that only
> makes it harder to address. The only thing to worry about is already custom
> resources that overlap with newer public resources.
>
> Morgaine wrote:
>
>> On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
>>
>> None of the above is particularly hard.� I think it won't be long before
>> we have a scheme worked out and are ready for some implementation work.
>>
>>
>> Morgaine.
>>
>>
>>
>>

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 05 Apr 2011 14:34:18 -0700

Again Morgaine, your appeals alone don't support themselves, and your 
ridicule is unwelcome. If you can not honestly make any serious 
response, please move on and don't reply to my posts just to further 
ridicule. It's very RUDE.

If you have any implementation of your hash-based idea or actual 
technical detailed documentation ready for implementation, then 
introduce it. Until then, it's stuck in your head, and sounds other's 
ideas just with your name on it. Plus security by obscurity makes it as 
moot point.

Documentation... ?

Remember people tried to take one temp variable away from the JPEG2000 
int multiple/divide routine because the idea it looks good (on paper) 
with one less variable. Actual implementation reveals, with timed tests, 
it is slower when anybody takes away that one temp variable.

Morgaine wrote:
> If you have something technical to say about hash-based addressing, I 
> would love to hear it.
>
> I have detailed in some depth the many benefits of hash-based 
> addressing in the article I linked, and subsequently.  If other good 
> schemes exist, we should of course analyze them for technical merit 
> and compare their benefits against those of hash-based addressing.
>
> On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol <[email-masked] 
>     Morgaine, we mooted your hash-based idea. This does nothing to
>     help implement asset services. The only significant point you made
>     is some expression for optimization, not correct functionality,
>     which is needed first
>
>     As for your other two, we can summarize those with public
>     resources and flow (forward/reverse). Any more specific network
>     topology than that only makes it harder to address. The only thing
>     to worry about is already custom resources that overlap with newer
>     public resources.
>
>     Morgaine wrote:
>
>         On Tue, Apr 5, 2011 at 5:38 PM, Dzonatas Sol
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>
>         None of the above is particularly hard.� I think it won't be
>         long before we have a scheme worked out and are ready for some
>         implementation work.
>
>
>         Morgaine.
>
>
>
>
>         [email-masked] <mailto:[email-masked]>

--

---

From: Morgaine <[email-masked]>
Date: Tue, 5 Apr 2011 22:48:32 +0100

How hash-based addressing works and is how the addresses are structured and
used in URIs is fully specified in my first article, Dzonatas.

The only element of the design not specified is *WHICH* particular hash
digest algorithm is employed, since the choice is not particularly
significant.  The merits of the design are attained regardless of the
particular digest chosen.  Because we are trying to achieve extensibility
for future proofing, a good approach would be to use an URI style that makes
choice of digest algorithm explicit.

As for implementations, a test implementation is already running in Mojito
Sorbet's experimental world and client, which are open source.

I welcome analysis of this addressing scheme, and of alternative addressing
schemes.  I haven't yet seen one with engineering properties that are
anywhere near as good as this, as I detailed in the article.  Hash-based
addressing sets the merit bar very high.

Morgaine.

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

On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol <[email-masked]> wrote:

> ridicule is unwelcome. If you can not honestly make any serious response,
> please move on and don't reply to my posts just to further ridicule. It's
> very RUDE.
>
> If you have any implementation of your hash-based idea or actual technical
> detailed documentation ready for implementation, then introduce it. Until
> then, it's stuck in your head, and sounds other's ideas just with your name
> on it. Plus security by obscurity makes it as moot point.
>
> Documentation... ?
>
> Remember people tried to take one temp variable away from the JPEG2000 int
> multiple/divide routine because the idea it looks good (on paper) with one
> less variable. Actual implementation reveals, with timed tests, it is slower
> when anybody takes away that one temp variable.
>
> Morgaine wrote:
>
>> I have detailed in some depth the many benefits of hash-based addressing
>> in the article I linked, and subsequently.  If other good schemes exist, we
>> On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol <[email-masked] <mailto:
>>    --     --- https://twitter.com/Dzonatas_Sol ---

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 05 Apr 2011 14:49:31 -0700

IETF seems to already have this nailed down on the political side. The 
working groups help.

Any proposal needs documentation, so that is where any consensus happens 
aside from implementation (actual or attempted).

We can assume succession of RFCs.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 05 Apr 2011 15:11:08 -0700

I don't see any description of LLIDL or anything trivially like it being 
described or based on documents now provided on the ietf vwrap wiki. 
Therefore, documentation incomplete. Moot point.

Local cache is still internal design, so what happen internally for 
cache optimizations does not mean all other aspect of the network are 
"the best design" by default. Again, correct functionality first. Local 
cache is not part of vwrap.

Digest URIs seem similar to the combined resources I already implemented 
and used even a year before you wrote that. Despite that, it seems like 
the age old IHAVE/SENDME protocols you can find RFCs dated before the 
late 80s. IHAVE/SENDME just didn't have to deal with public resource 
(combinable), as I have implemented: 
http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375

Your approach, besides exploitations, has the typical problem to assume 
asset IDs are only needed and are hash-able. I don't think you 
comprehend the moot point here, and thus probably have an agenda. 
(whatever it is... the ridicule and mockery make it apparent)

I think what you really want is the same thing I described with 
asset-"manafacturing", universal identifiers in URIs. Simple, it looks 
like "UUID:UUID", like any basic public key.

Documentation...?

Morgaine wrote:
> How hash-based addressing works and is how the addresses are 
> structured and used in URIs is fully specified in my first article, 
> Dzonatas.
>
> The only element of the design not specified is *WHICH* particular 
> hash digest algorithm is employed, since the choice is not 
> particularly significant.  The merits of the design are attained 
> regardless of the particular digest chosen.  Because we are trying to 
> achieve extensibility for future proofing, a good approach would be to 
> use an URI style that makes choice of digest algorithm explicit.
>
> As for implementations, a test implementation is already running in 
> Mojito Sorbet's experimental world and client, which are open source.
>
> I welcome analysis of this addressing scheme, and of alternative 
> addressing schemes.  I haven't yet seen one with engineering 
> properties that are anywhere near as good as this, as I detailed in 
> the article.  Hash-based addressing sets the merit bar very high.
>
>
> Morgaine.
>
>
>
>
>
> ==================
>
> On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol <[email-masked] 
>     Again Morgaine, your appeals alone don't support themselves, and
>     your ridicule is unwelcome. If you can not honestly make any
>     serious response, please move on and don't reply to my posts just
>     to further ridicule. It's very RUDE.
>
>     introduce it. Until then, it's stuck in your head, and sounds
>     other's ideas just with your name on it. Plus security by
>     obscurity makes it as moot point.
>
>     Documentation... ?
>
>     Remember people tried to take one temp variable away from the
>     JPEG2000 int multiple/divide routine because the idea it looks
>     good (on paper) with one less variable. Actual implementation
>     reveals, with timed tests, it is slower when anybody takes away
>     that one temp variable.
>
>     Morgaine wrote:
>
>         If you have something technical to say about hash-based
>         addressing, I would love to hear it.
>
>         addressing in the article I linked, and subsequently.  If
>         other good schemes exist, we should of course analyze them for
>         technical merit and compare their benefits against those of
>         hash-based addressing.
>
>         On Tue, Apr 5, 2011 at 8:56 PM, Dzonatas Sol
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>
>
>                     be.� I've already examined alternatives for that
>         in some
>                depth,
>                     to be universal hash-based addressing.� I first
>         described
>                that
>                     services and which parameters control the flows
>         needs to
>                be done
>                     before a test asset service can be implemented.�
>         Without
>                that,
>                     services exist already, so just implementing one
>         of those
>                would
>                     not advance VWRAP.
>
>                   * We need to examine how various deployment patterns
>         will
>                use the
>         <mailto:[email-masked] <mailto:[email-masked]>>
>

--

---

From: Morgaine <[email-masked]>
Date: Tue, 5 Apr 2011 23:24:13 +0100

On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol <[email-masked]> wrote:

> asset IDs are only needed and are hash-able.
>

Asset IDs are not hash-able, it is the asset data that is hashed.  The asset
identifier is the hash of the asset data using a defined hash digest
algorithm.  The asset identifier is not guessable unless you already have
access to the asset.

Morgaine.

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

>
>>
>> ==================
>>
>> On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol <[email-masked]<mailto:

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 05 Apr 2011 15:52:58 -0700

And... still local cache.. not vwrap.

I think it would be more wise to go with the implementations of Google's 
and/or Siemens object identification to RFID codes. At least we know 
this part won't exploit content.

It has further advantages than just that. I went into detail awhile ago, 
yet with basic QM: 
http://icyspherical.blogspot.com/2010/07/optimizing-simulations-with-basic.html

No, even given the possibilities presented, I don't think your idea 
comes close to anything new in regards to the best. It's just your 
preference.

Morgaine wrote:
> On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol <[email-masked] 
>     Your approach, besides exploitations, has the typical problem to
>     assume asset IDs are only needed and are hash-able.
>
>
>
> Asset IDs are not hash-able, it is the asset data that is hashed.  The 
> asset identifier is the hash of the asset data using a defined hash 
> digest algorithm.  The asset identifier is not guessable unless you 
> already have access to the asset.
>
>
> Morgaine.
>
>
>
>
>         On Tue, Apr 5, 2011 at 10:34 PM, Dzonatas Sol
>                Unfortunately your response was devoid of technical
>         content,
>                Dzonatas.
>
>                That's the engineering process for making VWRAP as good
>         as it
>                can be.
>
>
>                Morgaine.
>
>
>
>
>                   help implement asset services. The only significant
>         point
>                you made
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>                       <mailto:[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
>
>
>                          * Defining the asset addressing concept is an
>         extremely
>                       important
>                            matter, almost certainly the most important
>         matter
>                of all,
>                            because that determines how robust and
>         scalable our
>                       worlds will
>                            and the design with the best engineering
>         properties so
>                       far seems
>                          * Defining the data flows between regions,
>         clients,
>                and asset
>                            an asset service is just a
>         network-accessible storage
>                       service,
>                            not an asset service in the VWRAP sense.�
>         Network
>                storage
>                            interop introduces are handled.� I am
>         working on this
>                       currently.
>
>
>                       long before we have a scheme worked out and are
>         ready
>                for some
>                       implementation work.
>
>
>                       Morgaine.
>
>
>
>
>                            
>                <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>
>

--

---

From: Morgaine <[email-masked]>
Date: Wed, 6 Apr 2011 00:31:52 +0100

Before those 3 bullet points that I listed earlier disappear from immediate
scope, I would like to point out an important issue that fits under bullet
point #2 about data flows and fetch queries.

The parameters that need to be supplied to an asset service when a
particular asset is requested will not be the same in all cases.  There are
at least two different issues that will result in variations in fetch
parameters:

   - Firstly, different VWRAP deployment patterns may affect the nature of
   the query.  For example, in a deployment pattern that proxies all asset
   accesses, the query parameters all come from a server-side host (typically
   but not necessarily the region simulator), and the region credentials are
   quite likely to be implicit in the session between region and asset
   service.  In contrast, in a deployment in which the client issues fetch
   requests to asset services directly, the region credentials are likely to
   take the form of an extra parameter supplied in each fetch request, and in
   addition, other user-oriented credentials may need to be supplied by the
   client.  Other deployments may result in still different query
   parametrization to reflect the varying architecture.  This is an area which
   we have not yet examined against different forms of deployment.

   - Secondly, different types of asset can require different types of query
   parametrization.  For example, all the usual open content licenses (taking
   the Creative Commons licenses as an example) share the common property that
   the licenses are non-revocable and that the covered content is
   redistributable to all parties without exception in perpetuity.  As a
   result, there is no point in supplying a credential of any kind in order to
   fetch such an asset, and therefore the fetch operation can be made slimmer
   and hence more efficient.  The burden of encrypted sessions and endpoint
   identification certificates can be omitted entirely.  This saves both time
   and other resources, and applies similarly to queries from both the client
   and the server side.  It is easy to foresee that some community asset
   services will choose to serve open-licensed content only, as a matter of
   principle, in the same way that some Linux distribution provide only
   free/libre software as a matter of principle.  Such asset services will not
   need the mechanisms of authorization that commercial or proprietary services
   are likely to require, and will gain a simplification and a performance gain
   as a result.

Although the issues in this area are fairly straightforward, it will require
quite a lot of work to catch all the likely deployments.  Since we do not
have advocates for more than 2 or 3 common deployments in this group, we had
better make sure that the protocol machinery we provide is extensible to
cater for others that are bound to emerge.

Morgaine.

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

On Tue, Apr 5, 2011 at 7:56 PM, Morgaine <[email-masked]>wrote:

>    - Defining the asset addressing concept is an extremely important
>    matter, almost certainly the most important matter of all, because that
>    determines how robust and scalable our worlds will be.  I've already
>    examined alternatives for that in some depth, and the design with the best

---

From: Morgaine <[email-masked]>
Date: Wed, 6 Apr 2011 01:04:20 +0100

The asset fetch performance gain of a protocol in which asset identifiers
make cross-world assets cacheable versus a protocol whose asset identifiers
do not allow this is an extremely large factor of *many orders of
magnitude*on all but the first occurrence of an asset.  For all
intents and purposes,
avoiding the need to fetch an asset over the network represents a gain of
infinity, and this gain may be repeated many times over.

I think it's pretty uncontestable that giving VWRAP an asset addressing
scheme which is orders of magnitude more efficient than any other scheme
that has yet been proposed would be an important benefit for the protocol,
and highly likely to make it popular.  Conversely, if it lacks this benefit
then another protocol will use it and will hugely out-perform VWRAP.

We were talking about designing for the future.  Hash-based asset addressing
is a case in point, and how we handle this proposal is apparently our first
test case.

Morgaine.

On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol <[email-masked]> wrote:

> and/or Siemens object identification to RFID codes. At least we know this
> part won't exploit content.
>
> No, even given the possibilities presented, I don't think your idea comes
> close to anything new in regards to the best. It's just your preference.
>
> Morgaine wrote:
>
>> On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol <[email-masked]<mailto:
>> asset identifier is the hash of the asset data using a defined hash digest

---

From: Izzy Alanis <[email-masked]>
Date: Tue, 5 Apr 2011 20:09:13 -0400

I agree, this is a purely academic exercise, but I think Carlo wanted to practice attempting to reach a consensus. Proposal, counter proposal, discuss the ramifications of specific verbiage, etc... ;)

  - Izzy

On Apr 5, 2011, at 5:49 PM, Dzonatas Sol <[email-masked]> wrote:

> IETF seems to already have this nailed down on the political side. The working groups help.
> 
> Any proposal needs documentation, so that is where any consensus happens aside from implementation (actual or attempted).
>

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 05 Apr 2011 17:26:42 -0700

We were and still are in discussion about VWRAP documents.

As someone that implements, they don't want to read anything like "many 
orders of magnitude" or "the best idea" or such exaggerated adjectives. 
Don't expect your ideas ever to get implemented based on such language.

Need just the facts, and the documents. Please, stop with how great you 
think your idea is and produce the documents! Please include specific 
use of the resources, LLIDL, DSD, etc.

If this continues to be just discussion and neither documentation nor 
implementation than I'm with the chair(s) to disband.

Morgaine wrote:
> The asset fetch performance gain of a protocol in which asset 
> identifiers make cross-world assets cacheable versus a protocol whose 
> asset identifiers do not allow this is an extremely large factor of 
> *many orders of magnitude* on all but the first occurrence of an 
> asset.  For all intents and purposes, avoiding the need to fetch an 
> asset over the network represents a gain of infinity, and this gain 
> may be repeated many times over.
>
> I think it's pretty uncontestable that giving VWRAP an asset 
> addressing scheme which is orders of magnitude more efficient than any 
> other scheme that has yet been proposed would be an important benefit 
> for the protocol, and highly likely to make it popular.  Conversely, 
> if it lacks this benefit then another protocol will use it and will 
> hugely out-perform VWRAP.
>
> We were talking about designing for the future.  Hash-based asset 
> addressing is a case in point, and how we handle this proposal is 
> apparently our first test case.
>
>
> Morgaine.
>
>
>
>
>
> On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol <[email-masked] 
>     I think it would be more wise to go with the implementations of
>     Google's and/or Siemens object identification to RFID codes. At
>     least we know this part won't exploit content.
>
>     It has further advantages than just that. I went into detail
>     awhile ago, yet with basic QM:
>     No, even given the possibilities presented, I don't think your
>     idea comes close to anything new in regards to the best. It's just
>     your preference.
>
>     Morgaine wrote:
>
>         On Tue, Apr 5, 2011 at 11:11 PM, Dzonatas Sol
>         Asset IDs are not hash-able, it is the asset data that is
>         hashed.  The asset identifier is the hash of the asset data
>         using a defined hash digest algorithm.  The asset identifier
>         is not guessable unless you already have access to the asset.
>
>
>         Morgaine.
>
>
>
>
>                   If you have any implementation of your hash-based
>         idea or
>                actual
>                       other good schemes exist, we should of course
>         analyze
>                them for
>                          Morgaine, we mooted your hash-based idea.
>         This does
>                nothing to
>                          As for your other two, we can summarize those
>         with
>                public
>                          topology than that only makes it harder to
>         address. The
>                       only thing
>                          to worry about is already custom resources
>         that overlap
>                       with newer
>                          public resources.
>
>                          Morgaine wrote:
>
>                              <[email-masked]
>         <mailto:[email-masked] <mailto:[email-masked]>>>>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>>>> wrote:
>
>
>                                 Do you think we are ready to implement
>         some asset
>                       services now,
>                                   be.� I've already examined
>         alternatives for
>                that
>                       in some
>                              depth,
>                                   , and referred to it in various
>         subsequent
>                       discussions.
>
>                                 * We need to examine how various
>         deployment
>                patterns
>                       will
>                              use the
>                                   asset services, and how the
>         /multiple/ asset
>                       services that
>                              None of the above is particularly hard.�
>         I think it
>                       won't be
>         <mailto:[email-masked] <mailto:[email-masked]>>>>
>
>
>                          Web Development, Software Engineering,
>         Virtual Reality,
>                       Consultant
>
>
>                            

--

---

From: Morgaine <[email-masked]>
Date: Wed, 6 Apr 2011 02:01:03 +0100

*"Facts and documents*":  Link already provided.  Hash-based asset
addressing is just one protocol design element out of many hundreds in
VWRAP, and it would appear as a small technical detail in a future VWRAP
document, not a VWRAP document in its own right.

"*Many orders of magnitude*":  Performance Gain = (time to fetch an asset
over the network) / (time to fetch an asset from client cache with no
network access required) .  This could easily be 5 orders of magnitude under
normal operation, and a lot more under conditions of service congestion.

Morgaine.

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

On Wed, Apr 6, 2011 at 1:26 AM, Dzonatas Sol <[email-masked]> wrote:

> think your idea is and produce the documents! Please include specific use of
> the resources, LLIDL, DSD, etc.
>
>> do not allow this is an extremely large factor of *many orders of magnitude*
>> on all but the first occurrence of an asset.  For all intents and purposes,
>> addressing is a case in point, and how we handle this proposal is apparently
>> our first test case.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>> On Tue, Apr 5, 2011 at 11:52 PM, Dzonatas Sol <[email-masked]<mailto:

---

From: Izzy Alanis <[email-masked]>
Date: Tue, 5 Apr 2011 21:24:56 -0400

Along the lines of documentation... are we salvaging the last draft
intro doc or scrapping it? If we're scrapping it, what about it didn't
we like, what about it was good? The work on shoring up definitions is
directly applicable to the intro doc, but the minute details of asset
addressability and cacheability are leading us down a rat hole -- it's
interesting conversation, but just not productive right now.

Toward Carlo's mission of 'flexibility first': how would a statement
about the flexibility of the protocol appear in such a document?

- Izzy

---

From: Morgaine <[email-masked]>
Date: Wed, 6 Apr 2011 03:12:03 +0100

I'm not sure at what stage you joined us Izzy, but support for flexibility
and extensibility in the protocol has been preached by us regularly
throughout the entire lifetime of the MMOX, OGPX and now VWRAP groups, so
it's nothing new, really.  It could be said to have been lip service before
though, seeing as no new features ever materialized from it.

The only significant difference now is that Carlo has tried to turn that lip
service into an agreed process for promoting proposals that are aimed at
providing extra flexibility and extensibility.  The fact that this idea
hasn't received much support is a bit worrying.

It wouldn't matter at all if the group was by its nature strongly focused on
creating a protocol "designed for the future", eagerly selecting the ideas
with the best outlook for a massively scaled and buoyant metaverse, a
protocol that recognizes that virtual worlds will evolve rapidly once they
gain synergy from interoperation.  Indeed, Carlo's a priori agreement would
then be entirely superfluous.  But instead of eagerly welcoming
forward-looking proposals with excellent engineering merits, the few we've
had so far seem to be greeted with intense resistance and avoidance of
technical discussion.  It's an uphill struggle.

I can see why Carlo was so highly despondent in his last post.  Conditions
aren't too encouraging at the moment for an advanced, extensible protocol.

And perhaps there is no solution.  You can't make a horse drink, even when
there is plenty of water provided.

Morgaine.

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

On Wed, Apr 6, 2011 at 2:24 AM, Izzy Alanis <[email-masked]> wrote:

> identifiers
> magnitude*

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 05 Apr 2011 19:28:48 -0700

I'm interested in in implementation of the asset services, even 
completely fake, with mainly login like the simulators now. This is 
something just to give backbone to the current documents combined with 
implementations since then without any specific group behind the 
backbone. It doesn't have to support real simulator details, it could 
just forward proxy if it really want to turn into something. That's just 
the scrape for implementation sake. We need something like this, yet to 
justify it beyond people's agendas is... not productive.

I mainly wanted asset services unitized in order to support the 
multi-point/multi-client perspective, yet, like last year, I'm tired of 
being harassed by... agendas. We could always fallback to the proxy 
being on the viewer-side. *sigh*

On the documentation side, I think we could take the current proposed 
RFCs and simplify the type system into split documents instead one (that 
mainly reflects the monolithic design). That way we could come back 
later and easily update the more simplified versions. Just my 2 cents on 
the current state of them...

--

---

From: Izzy Alanis <[email-masked]>
Date: Wed, 6 Apr 2011 23:30:47 -0400

Yes, yes, yes... The question was more about how you want those ideas reflected in the documents.

- Izzy

On Apr 5, 2011, at 10:12 PM, Morgaine <[email-masked]> wrote:

> I'm not sure at what stage you joined us Izzy, but support for flexibility and extensibility in the protocol has been preached by us regularly throughout the entire lifetime of the MMOX, OGPX and now VWRAP groups, so it's nothing new, really.  It could be said to have been lip service before though, seeing as no new features ever materialized from it.
> 
> The only significant difference now is that Carlo has tried to turn that lip service into an agreed process for promoting proposals that are aimed at providing extra flexibility and extensibility.  The fact that this idea hasn't received much support is a bit worrying.
> 
> It wouldn't matter at all if the group was by its nature strongly focused on creating a protocol "designed for the future", eagerly selecting the ideas with the best outlook for a massively scaled and buoyant metaverse, a protocol that recognizes that virtual worlds will evolve rapidly once they gain synergy from interoperation.  Indeed, Carlo's a priori agreement would then be entirely superfluous.  But instead of eagerly welcoming forward-looking proposals with excellent engineering merits, the few we've had so far seem to be greeted with intense resistance and avoidance of technical discussion.  It's an uphill struggle.
> 
> I can see why Carlo was so highly despondent in his last post.  Conditions aren't too encouraging at the moment for an advanced, extensible protocol.
> 
> And perhaps there is no solution.  You can't make a horse drink, even when there is plenty of water provided.
> 
> 
> Morgaine.
> 
> 
> 
> 
> 
> =======================
>