Re: [vwrap] Definition of "Virtual World", in a protocols context

[Dan Olivares <[e-mail]>]

There are three ways to get heard here in the context of the working
group.   Convince a draft writer to include your suggestions in the draft
that they're writing, write a draft yourself, and vote when a general
consensus is called for.

:)

Regards

Dan



On Wed, Sep 22, 2010 at 9:18 AM, Carlo Wood <[e-mail]> wrote:

> As you might have noticed, I stopped writing to this list
> a while ago (and reading it I must admit). The reason
> for that being that I "gave up". I had the strong feeling
> that people don't listen and any time invested in this
> project from my side is wasted.
>
> Nevertheless, I decided to write another post...
>
> So, why would you listen to me? Who am I? I can only
> answer that with something that will sound rather arrogant,
> but I assure you, are just facts, not opinions: It is
> not uncommon for me to understand things that everyone
> else around me seems to miss (until they listen to me).
> I've been tested officially (with an official test,
> in an official test room by an official psychologist)
> to have an average intelligence in the top 0.01% of
> the general population. But I REALLY have a gift for
> the things: abstract comprehension, spacial insight
> and analytic insight. Imho, the latter matters in
> this case. I've also experience with related matters
> (see http://www.xs4all.nl/~carlo17/irc/run-irc.htm<http://www.xs4all.nl/%7Ecarlo17/irc/run-irc.htm>
> ).
> The things in the design for IRC that map 100% to a
> protocol for VW's are... well, almost everything:
> targets, (routing?), uniqueness, scalability, flow control,
> Identities,... And the same holds for other design issues.
> In other words, years of thought and experience.
>
> ========================================================
>
> Back to VWRAP.
>
> There are a lot commonalities between "the web" with
> http as the protocol, and VWRAP. It's absolutely not
> the same, but it seems an access point to understanding
> that works with most people.
>
> Down to earth, we are and will be dealing with (virtual)
> servers: machines on the internet with some IP number
> (ipv4 or ipv6 who cares).
>
> The most important difference between those servers is
> and will be who controls them. That can be an individual,
> or an organisation. For common understanding lets say
> that servers that belong to the same "who controls it"-class
> have an internet domain name that is the same.
> Remember, this is just a model to allow understanding.
>
> [In reality it's not the virtual server that is the
> smallest element in the whole, but the applications
> running on them. And then I don't even mention that
> I left the viewers (clients) out, although you can
> call them 'server' too if you wish. Clients are
> "leafs" (sort of) however, and therefore not a source
> of great confusion here. For the purpose of understanding
> we can (work with a model that) assume(s) that applications
> running on the same machine and that have the same IP
> number -- or even that have different IP numbers but
> with the same internet domain (ie, if both run in
> a virtual server each with their own IP number) --
> are controlled by the same organisation.]
>
> Conclusion: it is very workable, for understanding
> and analysis purposes, to consider applictions running
> on servers with IP numbers in the same internet domain
> to be controlled by the same organisation.
> I'm sorry to overload your terminology, but let me
> call this simply a DOMAIN from now on (in this post).
>
> A (network) "protocol" is a language for communication
> between *applications*, however it has never been needed
> to have a *standard* for a protocol used within one
> and the same DOMAIN. Examples are secondlife.com,
> efnet.org, etc. Put very simplistically, that is
> because every server within a given DOMAIN runs the
> same (version of) application, and therefore automatically
> use the same protocol-- defined by the source code of
> the application (it is communicating with itself so to
> say). Here the special role of the viewers comes into
> play: the viewers are in many cases not directly
> controlled by the same organisation (after all, they
> run on machines owned by others, not by that organisation),
> which DOES give rise to the need of a client-server protocol
> document, but not as much as we need (see below) because
> the DOMAIN owner usually has a lot of power and can
> control which clients connect...
>
> I use(d) DOMAIN here, surely colliding with the meaning
> of that word ELSEWHERE, because I don't want to type
> "Applications connected over a network, most likely
> the internet, and communicating using some protocol,
> whose version, and therefore the protocol (version)
> is controlled by a single entity (called 'organization'
> above)" every time.
>
> We must realize however that this model so far is FUZZY.
> It is NOT exactly defined. We already saw the problem
> of needing a protocol document "some how" for the
> client-server protocol (although one approach is to
> release binary clients by the SAME organisation).
> But at least as important, probably even MORE important
> is the fact that a protocol evolves over time: it
> changes! Lets call this a "protocol version", even
> though the protocol may not be clearly documented and
> as a result doesn't really have a version. But wait,
> we only have ONE domain (so far) and thus the SAME
> server application everywhere and since that controls
> which clients can connect, there is hardly a difference
> between the *application* version of the server, and
> the protocol version.
>
> In this model, with a single DOMAIN, it is almost
> trivial to "solve" the protocol changes over time
> by constantly having at most two *server* versions
> running: N and N+1 and making sure they are compatible.
> Then it is possible to "slowly" migrate from 'protocol'
> version N to N+1, by upgrading the servers one by one
> from version N to N+1, and so on.
>
> ----------------------------------------------------
>
> Our Problem
>
> I've seen the question on this list 'what we are doing'
> too many times. "What are virtual worlds?", "how
> many virtual worlds do we have?"... Blah.
> Forget all that. Empty your mind and just consider
> the text that I wrote above.
>
> What problem do we REALLY face here? When designing VWRAP.
>
> ... I almost decided to mail this post right here,
> because if it isn't obvious at this point you will
> never get it.
>
> Nevertheless, let me continue.
>
> The goal of this commitee is to design a well documented
> protocol to allow communication of applications from
> *different* DOMAIN's (as defined above). And that opens
> a lot of cans with worms:
>
> 1 The protocol suddenly becomes static. It cannot be
>  upgraded anymore (unless we specifically builtin
>  a method for that!)
> 2 The trust (level) between DOMAINS comes into play,
>  which was non-existent before.
> 3 There might be differences between DOMAINS: from
>  the fact that they run their own server implementations
>  that are radically different from the others (no
>  more version N and N+1, or anything that compares)
>  to any thinkable difference at any level of the
>  whole experience.
>
> It is our goal to define and write a protocol that
> addresses these three things. In general terms the
> solutions are:
>
> 1 Include protocol negotiation IN the protocol, to
>  allow the protocol to evolve (slowly change over
>  time).
> 2 While writing out the protocol details, keep in
>  mind that we can't necessarily trust the other
>  server.
> 3 Make the protocol as flexible as possible for
>  possible differences between DOMAINS, without
>  making a finite list of those possibilities.
>
> Imho opinion-- ok, not so humble-- point 3 is nearly
> the same as point 1: It can ONLY be satisfactory
> solved with protocol negotiations. That will allow
> *future* differences to be resolved that we can't
> take into account at this moment.
>
> --------------------------------------------------------
>
> Prologue
>
> If one considers the virtual experience while connected
> with a server of a given DOMAIN to be "the same", and
> this experience is (slighty) different while connected
> to a server of another DOMAIN (because that organisation
> wants things different), then it is logical to speak
> of different virtual "worlds": when teleporting from
> one DOMAIN to the other, it is as if you travel between
> planets.
>
> On the other hand, if the protocol succeeds and you
> can as flawlessly as possibly teleport from one DOMAIN
> to the next in a way that is painless and realistic (ie,
> you still look the same, and it is mostly a feeling of
> having travelled between places) then you might more
> think of it like travelling between countries and still
> be on the same world. In that case ONE virtual world
> would be the whole of places you can reach with teleporting.
>
> None of that matters however. What we should concentrate
> on is a description of the protocol in the light of
> the three points mentioned above.
>
> --
> Carlo Wood <[e-mail]>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>