Re: [vwrap] Comments on http://tools.ietf.org/html/draft-ietf-vwrap-intro-00

[Meadhbh Hamrick <[e-mail]>]

i think it's a language issue. VWRAP does not define interop between
Second Life and World of Warcraft (two different virtual worlds.) it
DOES define mechanisms individual hosts can use to communicate between
each other to simulate a virtual world. it does not require there to
be a single virtual world (like DNS "requires" you to point at the 13
canonical root servers.)

VWRAP allows simulation services to be provided by organizations
distinct from user authentication. in the "original" VWRAP model, the
user authentication service would direct the client to a space server
that defined the shape of the world and the
adjacency of regions. for the sake of discussion, let's call a virtual
world the set of all simulation regions and the adjacency graph that
connects them. so in the "original" model, the user authentication
service effectively dictates the shape of the virtual world the client
sees because it gives the client a capability to the space server.

but VWRAP virtual worlds separate simulation from user authentication;
so it's possible (but not required) that regions may be operated by
organizations other than those that provided the user authentication
service.

but VWRAP is a protocol, not an implementation. it defines mechanism,
but not policy. that means if all the parties are hip to it, a single
simulator could exist in two virtual worlds. that is, it is possibly
for user authentication service 'A' to place region '1' on one place
on the map while authentication service 'B' places region '1' at a
completely different location.

so the question is... if two avatars are in region 1; one of which
logged in with auth service A and the other with auth service B, are
they in the same "virtual world?" what happens when they start walking
together towards a region boundary? when they cross the region
boundary, they could potentially wind up in radically different
places.

the hypergrid solution is to define a single virtual world. regions
live in ONE place on a single global map. there's a single adjacency
map and everyone gets the same map. authentication services do not
direct clients to different space servers, there's only one.

the linden legacy solution is to define a single virtual world.
regions live in ONE place on a single global map, but there's only one
auth service.

the tourist model is that the regions maintain their own adjacency
graph, but it's really the clients that maintain the graph (and can
change it if they really want to.)

so when we say that VWRAP _COULD_ be used to build a single virtual
world, it means that you COULD build the linden model, the "original"
VWRAP model or the tourist model virtual worlds, but there is no
requirement (in the protocol) to do so.

i think the big confusion here is what the word "COULD" means. it
doesn't mean you MUST build in a single virtual world, but that you (a
deployer) COULD build a single virtual world if everyone else wants
to.

hope this clarifies things.

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



On Sat, Sep 18, 2010 at 9:36 PM, Hurliman, John <[e-mail]> wrote:
> You completely lost me. We're not addressing interoperability between virtual worlds, but we are addressing communication between multiple virtual worlds? What is the purpose of the communication if not for interop? And then,
>
> "...consensus of this group has generally been to describe the mechanisms one could use to build a single virtual world..."
>
> I don't remember reaching that consensus. Wasn't Joshua's whole talk about how we don't want to describe the mechanisms to build a virtual world, but only the mechanisms for communication between worlds? And we're calling this something other than interoperability now?
>
> I'm sure this is just a misinterpretation of your e-mail as we've been on roughly the same page this far, I just want to make sure I still understand.
>
> John
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Meadhbh Hamrick
>> Sent: Saturday, September 18, 2010 9:09 PM
>> To: Morgaine
>> Cc: [e-mail]
>> Subject: Re: [vwrap] Comments on http://tools.ietf.org/html/draft-ietf-
>> vwrap-intro-00
>>
>> morgaine,
>>
>> thanks for your viewpoint. i feel compelled to respond with a few
>> points.
>>
>> first, if you remember from the conversation last year about whether
>> the VW in VWRAP stood for "Virtual World" or "Virtual Worlds," the
>> consensus was we wanted to describe mechanism, not policy. that is to
>> say, an operator of a VWRAP compliant region could make up their own
>> mind whom they allowed to rez avatars in their region and which
>> service providers they trust. so if someone like linden wanted to
>> setup a walled garden, that would be perfectly acceptable. (though i
>> agree with you that this example is the least interesting type of
>> thing you could do with a virtual world.)
>>
>> secondly, VWRAP is not now, nor has it ever been a protocol to enable
>> interoperability BETWEEN virtual worlds. there is a mailing list for
>> such discussions: [e-mail]. at the MMOX BoF, we were unable to
>> find consensus on terminology, much less a consensus view on how to
>> achieve it. VWRAP is not a mechanism for teleporting between two
>> worlds (like Second Life or World of Warcraft.) at the end of the MMOX
>> BoF, you mentioned your interest in this use case and Lisa Dusseault
>> suggested the MMOX mailing list remain open for discussion of this use
>> case. the OGPX mailing list and later this group were chartered to
>> develop a protocol used to communicate information between hosts
>> simulating one ore more virtual worlds.
>>
>> in short, the consensus of this group has generally been to describe
>> the mechanisms one could use to build a single virtual world but does
>> not dictate that this world be a singleton. in other words, we do not
>> force operators of virtual world services to play in a single, global
>> virtual world. if they want to do that, great. but i suspect there may
>> be governmental, corporate and educational participants who will want
>> to have "private" virtual worlds, much like enterprises frequently
>> operate corporate intranets.
>>
>> while i understand that your interest is solely in the "tourist
>> model," i would remind you that supporting only this model would
>> require us to recharter this working group. pitching the existing
>> intro draft and starting from scratch would not give you what you
>> want. the intro draft MUST reflect the working groups charter.
>>
>> david and i, as authors of the intro draft, have solicited your input
>> on several occasions to ensure that your interests were reflected in
>> the documents. i was holding up on publishing a new revision of the
>> intro because (like i mentioned earlier) i wanted to include your use
>> case in the next draft revision. what you should probably do now is
>> provide us (the authors) with a detailed analysis of the text in
>> question along with recommended changes.
>>
>> please note, however, you cannot remove other participant's use cases.
>> but you can more accurately describe the use case you would like to
>> have added to the text. this is what diva did and her comments will
>> definitely be taken into consideration.
>>
>> so please. please. please. if you want your use case added to the
>> intro, please write down what your detailed concerns are with the
>> existing document. send those concerns to either david or i in private
>> or to the list.
>>
>> -cheers
>> -meadhbh
>>
>> i appreciate your comments about the intro draft and am waiting to see
>> comments on specific sections of the document.
>> -
>> meadhbh hamrick * it's pronounced "maeve"
>> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>>
>>
>>
>> On Sat, Sep 18, 2010 at 5:00 PM, Morgaine
>> <[e-mail]> wrote:
>> > Welcome Cristina to the working group!  And without further ado, let
>> me say
>> > that you are spot on.
>> >
>> > I had made it known previously that I was trying to rewrite the intro
>> > document.  Those who have followed my specific areas of interest
>> throughout
>> > the 3-year process of AWG/OGP/MMOX/OGPX/VWRAP will have known what to
>> > expect:  a complete dismissal of any attempt to create a single
>> world, a
>> > focus on interop between multiple worlds, separation of world
>> policies, and
>> > a specific use case that embodies all of these:  the direct support
>> for
>> > tourism between virtual worlds.
>> >
>> > David spoke to me yesterday to find out how my document editing work
>> was
>> > going, and I admitted to him that I was somewhere between desperation
>> and
>> > failure.  I had started off making relatively small changes to
>> eradicate
>> > "single world" thinking from the document, but after some pages'
>> worth of
>> > such changes, I realized that this was applying band aids to cure a
>> broken
>> > leg.  The document is simply wrong in its entire approach.  I asked
>> for
>> > David's advice and offered to explain the problem I saw to the group
>> this
>> > weekend, at which point I noticed Crista's post.
>> >
>> > I believe that you are 100% right in your observations, Crista.  The
>> intro
>> > document is way off base as an introduction to the work of a group
>> whose
>> > fundamental purpose is to provide protocol standards for VW interop.
>> It
>> > doesn't even mention interop between VWs at all!  It's hard to
>> imagine how
>> > it could be further from the intended goal.
>> >
>> > This problem is with us because it all started with OGP, a product of
>> a
>> > single-minded desire to grow Second Life by adding individual or
>> multiple
>> > regions to the existing SL world (or similar walled garden worlds),
>> without
>> > any policy rights of their own and without interoperability between
>> such
>> > worlds.  I'm not guessing about this.  I've been with the process
>> from the
>> > start, and attempts to discuss asset sharing for VW interop were
>> rejected in
>> > OGP.  In the last half year we have at least managed to put multi-
>> world
>> > deployments on the agenda through the help of David's "deployment
>> patterns",
>> > but nowhere is this reflected in the existing protocol
>> documentation.  The
>> > core (legacy) documents which originated with OGP do not reflect our
>> goals,
>> > at all.
>> >
>> > A few words on the scope of our "VWRAP deployments".  These are
>> expected to
>> > cover the entire gamut from individual walled garden worlds through
>> to a
>> > metaverse full of interoperating but otherwise independent virtual
>> worlds.
>> > Clusters of access-controlled worlds of various kinds would fall
>> somewhere
>> > in the middle, perhaps the VW counterparts of business VPNs.  Because
>> of the
>> > OGP legacy, we have been unable to document anything but the closed
>> worlds
>> > part of this spectrum.  We haven't even established a vocabulary for
>> > examining the key process of VW interop, which is the shared access
>> to
>> > assets that gives rise to the visual client-side mashup which is the
>> end
>> > product of all this.
>> >
>> > I've tried on numerous occasions to bring our discussions to focus on
>> the
>> > worlds tourist use case, because this is the one that highlights the
>> areas
>> > of difficulty.  Restricting a full-interop protocol to create walled
>> gardens
>> > is easy, whereas expanding a protocol for walled gardens into one
>> that
>> > handles VW interoperation is not, so we need to focus on the larger
>> issue
>> > first and only create mechanisms for restriction in passing.  Just in
>> case
>> > this point isn't clear, we should note that even in the most tightly
>> > controlled networks (such as military ones), there is always a need
>> to
>> > interoperate with the world outside.  Thinking about only the closed
>> system
>> > as your primary requirement just gets you in trouble later.
>> >
>> > Thank you Crista for describing in detail the "impedance mismatch"
>> between
>> > our documents and OpenSimulator's model or goals.  Since
>> OpenSimulator (or
>> > more accurately the worlds that use it) provides our primary example
>> of
>> > worlds for which VWRAP would be expected to be relevant, your
>> observations
>> > are more than just accurate and devastating --- they are also the key
>> to
>> > getting us to where we want to go, if VW interop is our goal.  It
>> certainly
>> > is mine.
>> >
>> > I recommend that we start from scratch on an entirely new intro
>> document, in
>> > which we establish first, very explicitly, that our problem domain is
>> that
>> > of multiple virtual worlds and interoperation between them.  We tried
>> to
>> > approach this in the past, but all attempts were blocked by the
>> incongruous
>> > proposition that "we don't know what virtual worlds are", which
>> verges on
>> > comedy.  More importantly however, as Crista has pointed out, it
>> should be
>> > none of our business "what virtual worlds are" --- all we need to
>> discuss is
>> > how they can interoperate.  After all, SMTP doesn't need to know how
>> MTAs or
>> > MUAs are structured, all that matters is how they communicate, and
>> the same
>> > is true here.
>> >
>> > Crista, while our current IETF drafts seem not to address the main
>> issue at
>> > all, you may find that the following article is more closely aligned
>> with
>> > what I believe is our intended direction, written by Joshua, David
>> and
>> > myself for IEEE Internet Computing, published in February.  The
>> article is
>> > embarrassingly over-optimistic in suggesting that the OGP model leads
>> > towards VW tourism despite no such operation having been designed,
>> but at
>> > least it expresses the intent.  We need to go beyond intent though.
>> > http://internetmessagingtechnology.org/pubs/VWRAP-for-Virtual-Worlds-
>> Interoperability-mic2010010073.pdf
>> >
>> > Thank you very much for your effective post.  I think we should use
>> it as a
>> > catalyst for affirming our interop direction to be between multiple
>> > independent worlds, and actually getting ourselves on the right road
>> to
>> > achieve it.
>> >
>> >
>> > Morgaine.
>> >
>> >
>> >
>> >
>> >
>> > ====================================
>> >
>> > On Tue, Sep 7, 2010 at 4:56 PM, Cristina Videira Lopes
>> <[e-mail]>
>> > wrote:
>> >>
>> >> This is my first time participating in an IETF WG, so apologies in
>> advance
>> >> for any mis-steps on the process. I believe it's ok to send comments
>> at this
>> >> point. But I understand that the work has been going on for about a
>> year
>> >> without me being involved, so my comments may be out of order. This
>> is one
>> >> year's worth of comments, long and heavy email :-)
>> >> I leave to the Chairs of this WG the right to dismiss them, and I'll
>> >> accept it if that happens.
>> >>
>> >> I'm still not entirely sure the world is ready for "standards" for
>> virtual
>> >> world interoperability, but given that this working group exists, I
>> hope my
>> >> comments help strengthen the technical aspects of the work that has
>> been
>> >> going on here, so that, in the end, this document will appeal to
>> others who
>> >> have absolutely nothing to do with the Linden Lab family of virtual
>> worlds
>> >> -- so as to make good on the word "interoperability."
>> >>
>> >> The document seems to be establishing the underlying assumptions and
>> scope
>> >> for the protocols recommended by this group. That's great.
>> >>
>> >> The gist of my comments is that the particular assumptions
>> established by
>> >> the document do not accurately reflect the underlying assumptions
>> and goals
>> >> of the OpenSimulator platform in important ways, and I suspect they
>> also
>> >> don't reflect many other VW platforms. I don't know if that is a
>> good thing
>> >> or a bad thing or an irrelevant thing for the purposes of this
>> working
>> >> group; I'm just making this observation. Assuming that the Chairs
>> accept my
>> >> commentary for discussion, I delegate to the group the judgment on
>> the
>> >> consequences of this observation.
>> >>
>> >> Let me expand on it by going through the document, and pointing out
>> the
>> >> differences in assumptions and goals, as well as the parts of the
>> text that
>> >> aren't clear to me, the parts that I think are good, and some
>> general
>> >> technical commentary.
>> >>
>> >> ----- Comment 1 -----
>> >> Section 1: "...This document introduces the
>> >>  Virtual World Region Agent Protocol (VWRAP) suite.  This protocol
>> >>  suite is intended to carry information about a virtual world: its
>> >>  shape, its residents and objects existing within it.  VWRAP's goal
>> is
>> >>  to define an extensible set of messages for carrying state and
>> state
>> >>  change information between hosts participating in the simulation of
>> >>  the virtual world."
>> >>
>> >> This starting statement offers the concept of a single virtual
>> world;
>> >> reading further  it seems to mean that the ecosystem of VWRAP is,
>> indeed,
>> >> treated here as one single system involving a multitude of
>> organizations.
>> >> Section 2.1, par 5:
>> >> "The VWRAP suite assumes network hosts, likely operated by distinct
>> >>  organizations will collaborate to simulate the virtual world."
>> >>
>> >> The OpenSimulator platform has been designed with a plurality of
>> virtual
>> >> worlds in mind, not just one. This plurality is a fundamental
>> assumption of
>> >> our platform, as it makes aggressive use of plugins for two
>> important
>> >> aspects of virtual worlds: (1) the scene server -- scene renderer
>> client
>> >> interaction; (2) the scene service -- resource services interaction.
>> >>
>> >> What the use of these plugins means is that we strongly believe that
>> each
>> >> virtual world is an independent system that should be designed and
>> >> implemented in a way that best fits that world's goals. We believe
>> this for
>> >> OpenSimulator-based worlds already by providing those important
>> aspects as
>> >> plugins, so we also believe it for virtual worlds that aren't based
>> in
>> >> OpenSimulator software. The decisions made by, say, Blue Mars, with
>> respect
>> >> to how to send scenes to client software and how to manage their
>> resources,
>> >> are to be respected and treated independently of the decisions made
>> by, say,
>> >> ReactionGrid. But that doesn't mean that worlds operated by these
>> >> organizations can't interoperate. They can, given a minimum
>> interoperability
>> >> protocol. In summary, and this will recur throughout my commentary:
>> >>
>> >> OpenSimulator does not assume the existence of one single virtual
>> world
>> >> involving a multitude of organizations; it assumes the existence of
>> multiple
>> >> virtual worlds, each one under the authority of one single
>> organization --
>> >> which, in turn, may make its own internal decisions about sharing
>> ownership
>> >> and resources of parts of that world with other organizations, but
>> that is
>> >> an internal decision that is irrelevant for purposes of virtual
>> world
>> >> interoperability.
>> >> For some background on the virtual world model assumed by
>> OpenSimulator,
>> >> see
>> >> http://opensimulator.org/wiki/Virtual_World_Model
>> >>
>> >> ----- Comment 2 -----
>> >> Section 2.1, the list of 3 characteristics:
>> >>
>> >> "1. The virtual world exists independent of the participating
>> >>  clients." ... "VWRAP assumes the state virtual world is "always
>> on"... "
>> >>
>> >> OpenSimulator does not make these assumptions. While OpenSimulator
>> worlds
>> >> are usually run on servers to which clients connect over the
>> network, it is
>> >> possible to take the OpenSimulator framework and merge it with a
>> renderer
>> >> component, producing a virtual world that is both a client and,
>> eventually,
>> >> a server if that virtual world is to support multiple users over a
>> network.
>> >>
>> >> Also, OpenSimulator does not assume that the virtual world is
>> "always on",
>> >> on the contrary. Many OpenSimulator-based virtual worlds that
>> already exist
>> >> seem to be ran on people's personal computers in their home
>> networks, which
>> >> are often turned off.
>> >>
>> >> "2. Avatars have a single, unique presence in the virtual world."
>> >>
>> >> OpenSimulator does not make this assumption. It is possible to have
>> >> multiple presences (sessions) for the same user on the same virtual
>> world.
>> >> This supports use cases of users wanting to be in two different
>> places of
>> >> the world at the same time, e.g. for attending two different events.
>> The
>> >> decision on whether to allow this or not pertains entirely to the
>> virtual
>> >> world operator.
>> >>
>> >> ----- Comment 3 -----
>> >> Section 2.2, architectural patterns:
>> >>
>> >> "1. Systems implementing virtual world services must be
>> distributed."
>> >> ...
>> >> "But however large (or small) a virtual world deployment is, or
>> >>      how many distinct organizations contribute to its operation,
>> >>      software implementing virtual world services MUST assume
>> >>      resources required to perform its function are distributed
>> >>      amongst multiple hosts."
>> >>
>> >> OpenSimulator does not impose this. In fact, the most popular
>> >> configuration of OpenSimulator-based worlds is a "standalone"
>> configuration
>> >> where both the scene service and all the resource services of that
>> world
>> >> execute in one single process of one machine. In a standalone VW
>> system,
>> >> none of the services (e.g. assets, inventory, etc) are
>> "distributed."
>> >> Furthermore, as explained above, the OpenSimulator framework also
>> supports
>> >> the existence of single-process virtual worlds that include the
>> renderer
>> >> itself.
>> >>
>> >> The only two requirements imposed by OpenSimulator, and indeed by
>> any
>> >> software system, are: (1) in cases where these worlds wish to serve
>> multiple
>> >> users over the network, then network endpoints must exist that serve
>> the
>> >> scene to the clients used by those users; (2) in cases where these
>> worlds
>> >> wish to interoperate, then network endpoints must exist that serve
>> certain
>> >> resources from those worlds to other worlds.
>> >>
>> >> "2. Services supporting collaboration are hosted on 'central'
>> >>  systems."
>> >>
>> >> No such assumption in OpenSimulator. The way that virtual world
>> operators
>> >> decide to design and implement their collaborative features are
>> entirely up
>> >> to them.
>> >>
>> >> For example, in OpenSimulator the default implementation of Instant
>> >> Messaging is peer-to-peer, with only presence being looked up
>> centrally;
>> >> there is no central IM server. This feature is implemented as a
>> plugin, so
>> >> other implementations (e.g. centralized) are possible.
>> >>
>> >> Maybe this architectural pattern pertains to inter-world
>> collaboration? If
>> >> that is the case, then this is clearly not a desired goal, as most
>> >> OpenSimulator virtual worlds want to operate their own collaboration
>> >> sub-systems, and do not wish to depend on third parties, unless
>> there is no
>> >> alternative. As an example, take the Groups service, which is
>> implemented
>> >> outside of the OpenSimulator core distribution. While there is an
>> instance
>> >> of that group service ran by an individual (the original developer)
>> that can
>> >> support groups for many virtual worlds, most grid operators choose
>> to run
>> >> their own instance.
>> >>
>> >> "3. Virtual world services default to being 'open'."
>> >> ...
>> >> "In other words, requiring
>> >>      two services (e.g. - physics simulation and asset storage) be
>> >>      managed by the same organization's servers is an issue of local
>> >>      policy, not of protocol."
>> >>
>> >> I don't understand what 'open' means. Does it mean that they default
>> to
>> >> being available on the internet? The quoted sentence doesn't seem to
>> relate
>> >> to the headline, so I'm not sure what this architectural pattern is
>> saying,
>> >> I think it needs to find its message.
>> >>
>> >> ----- Comment 4 -----
>> >> Section 3.1:
>> >>
>> >> This is the best section of the document, but it needs a lot more
>> depth. I
>> >> would go as far as suggesting that protocol flexibility (and not
>> just data
>> >> presentation flexibility) may very well be the single most important
>> >> contribution that an interoperability standard in this area might
>> make.
>> >>
>> >> Indeed, this document fails to address one critical question: what
>> >> assumptions do we make wrt how the server serves scenes to the
>> clients? Do
>> >> we assume that this is a fixed part for interoperability (i.e.
>> there's only
>> >> one protocol for doing this in the entire collection of
>> interoperable
>> >> virtual worlds) or so we assume that each virtual world does it in
>> whichever
>> >> way it wants?
>> >>
>> >> To illustrate the issue, let me point out the spectrum of
>> possibilities.
>> >>
>> >> On one extreme we have what is currently emerging on the Web: on-
>> line,
>> >> multi-user 3D scene servers that simply send their "viewer code" to
>> the web
>> >> browsers in JavaScript. You go from one game to another, and you get
>> >> radically different pieces of JavaScript code that get the data from
>> the
>> >> servers and render it; these JavaScript "viewers" are black boxes
>> that have
>> >> nothing to do with each other.
>> >>
>> >> On the other extreme of this spectrum, we have systems like Second
>> Life
>> >> and World of Warcraft, with customized, non-programmable viewers
>> that do
>> >> things in exactly one way, tightly coupling the protocol with the
>> fixed
>> >> game-specific UI.
>> >>
>> >> Somewhere in the middle, we have Flash-based worlds (and others)
>> that run
>> >> on the general-purpose Web browser and that are identified by
>> certain MIME
>> >> types (e.g. application/x-shockwave-flash).
>> >>
>> >> So where does this group stand wrt this critical issue?
>> >>
>> >> As I said above, in principle, OpenSimulator assumes that each
>> virtual
>> >> world has its own client-server protocol -- so in line with what is
>> emerging
>> >> on the Web. Unfortunately we still don't have viewers capable of
>> doing this
>> >> well: Web browsers still can't render the kinds of content we need,
>> and
>> >> existing VW clients aren't general enough. But that should not be an
>> >> impediment to accepting the underlying principle of letting VW
>> systems do it
>> >> their way, and having that be a programmable component of a possible
>> >> interoperability framework.
>> >>
>> >> With this, we set up an interoperabilty framework that accommodates
>> the
>> >> variety of protocols that already exist, and that are unlikely to be
>> let go
>> >> by their implementers. We also set up the stage for accommodating
>> the
>> >> variety of protocols that still don't exist but that are bound to
>> happen as
>> >> the Web starts experimenting with 3D immersion.
>> >>
>> >> ----- Comment 5 -----
>> >> Section 3.2:
>> >>
>> >> This section expands more on the basic VWRAP premise of "the single
>> >> virtual world" composed of multiple services under the authority of
>> multiple
>> >> organizations. As explained before, this is very different from the
>> VW model
>> >> assumed by OpenSimulator, where a myriad of virtual worlds, each
>> under one
>> >> authority, are assumed to exist, and where the internals of those
>> virtual
>> >> worlds are out of scope.
>> >>
>> >> ----- Comment 6 -----
>> >> Section 3.3:
>> >>
>> >> This section is contrary to the design philosophy of OpenSimulator,
>> where
>> >> very few conditions are imposed on the internal implementation of
>> virtual
>> >> worlds.
>> >>
>> >> ----- Comment 7 -----
>> >> Section 4.1:
>> >>
>> >> This section seems to be a summary of the document
>> >> http://tools.ietf.org/html/draft-ietf-vwrap-authentication-00
>> >>
>> >> That document seems to describe a straightforward login procedure,
>> similar
>> >> to all login procedures out there that authenticate a user onto a
>> service
>> >> running on a server. It defines specific on-the-wire data
>> representations,
>> >> and a specific protocol for error handling.
>> >>
>> >> I understand that the introduction of the seed CAP, and subsequent
>> >> invocation, is a new thing that most login procedures don't have.
>> >>
>> >> But I'm at loss as to why this matters for interoperability
>> purposes. Each
>> >> virtual world should be free to do the initial user authentication
>> in
>> >> whichever way it finds most suitable, and to send whichever
>> information it
>> >> needs to send, in whichever way, to the client.
>> >>
>> >> Maybe CAPs has a special role in inter-world authentication in
>> VWRAP?
>> >> Unfortunately, I read all the available documents, and I couldn't
>> find
>> >> anything that explains inter-world authentication in VWRAP.
>> >>
>> >> ----- Comment 8 -----
>> >> Section 4.2:
>> >>
>> >> This section introduces concepts that haven't been explained before
>> and
>> >> that aren't explained here either, specifically "agent domain" and
>> "region
>> >> domain". I know what these are, as I've read the AWG documents on
>> the Web;
>> >> but another  less informed reader won't know.
>> >>
>> >> Many other things in this section are unclear because of the non-
>> existence
>> >> of referenced materials e.g. "VWRAP Teleport specification", so
>> perhaps
>> >> these summaries shouldn't be in this intro document at all. But
>> since they
>> >> are, let me offer some comments.
>> >>
>> >> In 4.2.2: unclear, but I'm assuming this section pertains to inter-
>> world
>> >> movements? That should be made clear. Because intra-world movements
>> should
>> >> be out of scope for interoperability purposes: the way that virtual
>> worlds
>> >> choose to move the agents within themselves, if they do at all, is
>> >> irrelevant.
>> >>
>> >> I believe there is some confusion here between model and mechanism,
>> but
>> >> maybe I know too much. I'm assuming that the word "capability" in
>> VWRAP
>> >> means "capability URL"; if I'm wrong, and if it means just
>> "capability" as
>> >> given by the Webster dictionary (roughly, authorization), then that
>> would be
>> >> great!
>> >>
>> >> Also in 4.2.2 there is an underlying assumption that the client
>> keeps a
>> >> direct connection to the "agent domain". For example "The client
>> signals to
>> >> the agent domain its desire to move..."
>> >> The standard Linden client does not do this. But more important than
>> the
>> >> Linden client, Web browsers, i.e. stateless clients, also don't keep
>> state.
>> >> So if we ever were to have a Web-browser-based viewer for a web of
>> virtual
>> >> worlds, we wouldn't be able to do what is suggested in this entire
>> section.
>> >>
>> >> These protocols hinted at in this section are the crux of
>> >> interoperability. I understand this is just the intro document, and
>> it's not
>> >> supposed to have all the details, that's fine. If you go ahead with
>> the
>> >> protocol hinted at here, then it is important to note somewhere in
>> this
>> >> intro document that it assumes stateful clients, and that Web
>> browser
>> >> viewers (that aren't browser plugins) are N/A.
>> >>
>> >> As I said in comment #4, I would like to see a better analysis of
>> what
>> >> virtual world inteoperability demands from the viewer software. I
>> used to
>> >> think that web browsers were an evolutionary dead-end, but with the
>> >> introduction of HTML5 and all the exciting work that is going on
>> with
>> >> running verifiably-secure native code on Web browsers, I came to
>> change my
>> >> mind about this. Since the Web browser is the ubiquitous client
>> software, it
>> >> seems like a bad move to exclude this client from interoperability
>> for
>> >> virtual worlds, because we're only going to see more 3D immersion,
>> not less,
>> >> on web browsers.
>> >>
>> >> ----- Comment 9 -----
>> >> Section 4.3:
>> >>
>> >> This has nothing to do with interoperability and seems to be
>> focusing
>> >> exclusively on how the Linden Lab world works. Statements like "The
>> host
>> >>  in the region domain responsible for managing spatial chat applies
>> a
>> >>  proximity algorithm to the chat to determine which avatars or
>> objects
>> >>  are close enough to hear it."
>> >> are too specific to be worth mentioning in this document. Other
>> virtual
>> >> worlds may apply different schemes wrt chat.
>> >>
>> >> ----- Comment 10 -----
>> >> Section 4.4:
>> >>
>> >> I suggest replacing the ad-hoc terminology "at rest" and "in world"
>> with
>> >> more standard terminology. Assets are stored in persistent storage.
>> There's
>> >> technical terminology for "in world":  assets that are referenced by
>> a 3D
>> >> scene. There's also technical terminology for "at rest": assets that
>> are not
>> >> referenced by a 3D scene directly but that are referenced by other
>> resources
>> >> like a user's inventory or scripts.
>> >>
>> >> This section is full of details that should not be here:
>> >> (1) how the scene server decides to manage the assets is an internal
>> >> decision of each virtual world. The scene server may have its own
>> assets, or
>> >> it may have its own asset storage server on the same data center, or
>> it may
>> >> use amazon. It may pre-fetch or may perform lazy fetch. It may cache
>> or it
>> >> may not. It doesn't matter for the purposes of interoperability.
>> >> (2) how the scene server decides to make the assets available to the
>> >> clients is an internal decision of each virtual world; in fact, a
>> central
>> >> part of the client(viewer)-server protocol, of which there should be
>> many.
>> >> It may send them on-line via UDP; it may zip them up in a zip file
>> and send
>> >> them; it may tell the client to fetch them from another server. It
>> doesn't
>> >> matter.
>> >>
>> >> Interoperability should not impose any conditions whatsoever on how
>> these
>> >> things are done, or the word "interoperability" will start moving
>> into the
>> >> realm of internal virtual world architecture, which is something
>> this group
>> >> probably should not be doing, lest alienating potential parties.
>> Even in the
>> >> small ecosystem of OpenSimulator, we are already seeing a variety of
>> new
>> >> clients being developed that have nothing to do with the Linden Lab
>> client
>> >> (e.g. Unity3D). That's a direction that we very much encourage.
>> >>
>> >> ----- Comment 11 -----
>> >> Section 4.2.2:
>> >>
>> >> This section seems to be implying that host based trust carried by
>> X.509 /
>> >> PKIX certificates will ensure that the receiving party will honor
>> the
>> >> asset's metadata. These (i.e. certificates and honoring the
>> metadata) are
>> >> two different things. It should be made clear that, just because all
>> parties
>> >> are who they say they are, it doesn't mean that they will honor the
>> >> metadata.
>> >>
>> >> Again, I wish I knew more of what people in this group have in mind
>> for
>> >> authentication, but I couldn't find any information.
>> >>
>> >> _______________________________________________
>> >> vwrap mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/vwrap
>> >
>> >
>> > _______________________________________________
>> > vwrap mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/vwrap
>> >
>> >
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>