From dhc@dcrocker.net Sat Aug 1 18:55:08 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4EC13A6767 for ; Sat, 1 Aug 2009 18:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4ssND2bweT1 for ; Sat, 1 Aug 2009 18:55:07 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7147]) by core3.amsl.com (Postfix) with ESMTP id 135163A67E6 for ; Sat, 1 Aug 2009 18:55:04 -0700 (PDT) Received: from [10.43.1.104] ([82.99.1.116]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n721ssIF026262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Aug 2009 18:55:01 -0700 Message-ID: <4A74F1E4.8080209@dcrocker.net> Date: Sun, 02 Aug 2009 03:54:44 +0200 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Joshua Bell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 01 Aug 2009 18:55:05 -0700 (PDT) Cc: ogpx@ietf.org Subject: Re: [ogpx] Next Steps for OGPX WG Charter X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2009 01:55:08 -0000 Joshua, g'day. This latest draft is indeed very much better! Joshua Bell wrote: > 1. Include a succinct but realistic summary of what the problem space > and protocol are. At the BOF, Chris Newman made the comment "The > impression I've got is this is a 3-D multi-vendor Facebook. I think > that's really cool." (thanks, Chris!). This really helped BOF > participants unfamiliar with VWs understand what the heck we were > talking about. > > Can mailing list participants come up with something short, accurate, > educational, and catchy? "The working group will define a protocol to support a 3-D virtual world simulation environment between users and independently operated simulation regions, and amongst those regions." This is neither as concise nor as sexy as Chris' summary, but it also lacks the proprietary reference. (Perhaps the social networking usage aspect, however, needs to be included? But then, I'm not clear how the protocol work mandates that usage.) I think is also describes the core technical activity, as I understand the goal. That presumes that I understand it correctly... > For example: "The protocol produced by this working group > should provide a mechanism for authenticating a client to a server, > cause a user's avatar to be placed in the virtual world, move the user's > avatar, receive a list of objects in the user's avatar, etc." I don't think Larry or I formulated the above sentence, and in spite of that, I quite like it... I think it's clear, direct, and contains the salient information. > 3. The text of the charter should have a clear list of working group > deliverables. The current draft does not specify what existing documents it is drawing from, what it will/might/must do with them, nor what the limits on modification to those documents are -- if any. > The "what is needed" slide from the OGPX Draft Charter Issues > presentation ( http://www.ietf.org/proceedings/75/slides/ogpx-2.pdf) was > mentioned as a possible source for this list for both (2) and (3), but > needs massaging: > > (a) a security model describing trust relationships between hosts, > (b) guidelines for the use of existing authentication & confidentiality > mechanisms, > (c) mechanisms for: > (i) establishing the user's presence in the virtual world > (ii) moving a user's presence from one authoritative host to another, > (iii) for identifying agents, and requesting information about them. > (d) format descriptions for objects and avatars in a virtual world, For c.ii should it really be 'host' or is it actually 'region'? Also, the use of 'authoritative' implies there can non-authoritative hosts. Is that correct? As for what might be missing, I'm not seeing any semantics cited for any actions other than defining and moving users. Nothing about simulation activity. > Are there any other suggestions, preferences, or vetos? Does the > proposed protocol name need to be reflected in a revised Working Group > name? They certainly don't have to be the same, but they do need to be useful, of course. > 7. Explicitly list extant drafts which will be the starting point for > the WG effort: > > * http://tools.ietf.org/html/draft-hamrick-ogp-intro > * http://tools.ietf.org/html/draft-hamrick-llsd-00 > * http://tools.ietf.org/html/draft-hamrick-ogp-auth > * http://tools.ietf.org/html/draft-hamrick-ogp-launch > * http://tools.ietf.org/html/draft-lentczner-ogp-base > * http://tools.ietf.org/html/draft-levine-ogp-clientcap > * http://tools.ietf.org/html/draft-levine-ogp-layering > > Is this list complete and accurate? Since these document represent a substantial history, it really is important for the charter to cite them explicitly and specify how maleable their content is. "Starting point" could mean that the final result has no visible relationship to these documents and that they merely used for initial discussion. As I've noted earlier, I am pretty sure you folks want more constraints than that. Whatever you choose, it's likely to be a point of negotiation with the IESG, but you should state what role these docs are expected/required to play. > 8. The protocols are intended to provide a clear seperation of concerns > between mechanisms used to access resources and policies controlling > use of those mechanisms. Many deployment choices will be defined by > policy, not protocol. This needs to be clear in the charter. yup! > 9. Ensure that while the charter scopes down the Virtual World problem > space, it does it in an inclusive way rather than focusing on what is > out of scope and thus indecipherable to non-subject matter experts. It > is expected that output of the WG may be useful in scenarios beyond > those specifically under consideration, much as RFC 2068 is not simply > used for hypertext. This type of goal is often present, but I'm pretty sure I've never seen any chartering text about it that had any meaning or any impact. For example, what objective criteria could the IESG apply during document approval, to tell whether the goal has been satisfied? > 10. Remove references to "wire" in "wire protocol"; this is implicit in > the scope of work for IETF. The phrase "application-layer protocol" (as > distinct from a novel transport-layer protocol) is accurate and sufficient. Yes, but I'll also vote for removing "application-layer". I now understand that it's meant to imply that it's above transport, but there's already specific language about using transports. No, this isn't a big deal, but in spite of primarily being as apps guy, I think removing the phrase makes the text cleaner, with no loss of meaning. > 11. Add text specifying: The WG will define interfaces for a set of > HTTP-based services ("web services") but not provide language specific > bindings ("API") onto those services. Huh? What's this about? Sounds like the working group is going to do web enhancements, rather than virtual world simulation. > 12. Clarify the charter that we're explicitly targetting HTTP as the > default transport. > > A concern was raised that reusing HTTP will lead to unnecessary and > tight coupling with that protocol's capabilities and semantics; a > suggestion was made that if we wish to state that the protocols will be > transport-neutral, the WG will investigate at least one other transport. > Should we just target HTTP, or make the effort? If transport-independence is claimed, the claim won't really be meaningful unless at least two different transport mappings are provided. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From alexey.melnikov@isode.com Sun Aug 2 23:00:35 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20823A6AF3 for ; Sun, 2 Aug 2009 23:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+6itNEIduRD for ; Sun, 2 Aug 2009 23:00:35 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 02A203A683E for ; Sun, 2 Aug 2009 23:00:11 -0700 (PDT) Received: from [78.64.9.181] (host-78-64-9-181.homerun.telia.com [78.64.9.181]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 3 Aug 2009 07:00:11 +0100 Message-ID: <4A756318.4000201@isode.com> Date: Sun, 02 Aug 2009 11:57:44 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: dcrocker@bbiw.net References: <20090731003126.GA9863@alinoe.com> <20090731005952.GB9863@alinoe.com> <4A73C01F.6010600@dcrocker.net> In-Reply-To: <4A73C01F.6010600@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] Next Steps for OGPX WG Charter X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 06:00:36 -0000 Dave CROCKER wrote: > Carlo Wood wrote: > >> On Fri, Jul 31, 2009 at 02:31:26AM +0200, Carlo Wood wrote: >> >>> Someone once said: "Of course it's not working perfectly: this is >>> the VERY first version of the Matrix". >> >> So, what about: MAP ... Matrix Alpha Protocol > > A pronounceable acronym can be quite nice. > > My own suspicion is that one based on being humorous, ironic, or > otherwise clever, probably isn't, if the effort is to be taken > seriously. The fun component resonates initially, but then grows > stale on constant repetition (over the years.) Agreed. I also think the name should be reasonably unique so that it comes up high in web searches. From infinity@lindenlab.com Mon Aug 3 11:12:22 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA833A6E77 for ; Mon, 3 Aug 2009 11:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwecUeMoQUP4 for ; Mon, 3 Aug 2009 11:12:20 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id 7CB163A6E74 for ; Mon, 3 Aug 2009 11:12:20 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1628135anc.4 for ; Mon, 03 Aug 2009 11:12:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.135.16 with SMTP id i16mr1877400and.85.1249323139015; Mon, 03 Aug 2009 11:12:19 -0700 (PDT) In-Reply-To: <4A74F1E4.8080209@dcrocker.net> References: <4A74F1E4.8080209@dcrocker.net> Date: Mon, 3 Aug 2009 11:12:18 -0700 Message-ID: <3a880e2c0908031112g4813a46bx3e4edfdb76119926@mail.gmail.com> From: Infinity Linden To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Next Steps for OGPX WG Charter X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 18:12:22 -0000 On Sat, Aug 1, 2009 at 6:54 PM, Dave CROCKER wrote: [stuff removed] > >> =A0 For example: "The protocol produced by this working group should pro= vide >> a mechanism for authenticating a client to a server, cause a user's avat= ar >> to be placed in the virtual world, move the user's avatar, receive a lis= t of >> objects in the user's avatar, etc." > > I don't think Larry or I formulated the above sentence, and in spite of > that, I > quite like it... =A0I think it's clear, direct, and contains the salient > information. > fair enough. i think it was more my synthesis of a sequence of sentences... not trying to say it was a direct quote really. but since we all seem to like it, it's probably okay. > >> 3. The text of the charter should have a clear list of working group >> deliverables. > > The current draft does not specify what existing documents it is drawing > from, > what it will/might/must do with them, nor what the limits on modification= to > those documents are -- if any. hmm... i had thought i had some advice from someone to remove the list of drafts we're basing the current definition of "the protocol formerly known as OGP." but for the record... we have two sets of documents: first, the internet drafts that have been circulating over the last 6 months or so. the list of these drafts is on the mailing list and at http://wiki.secondlife.com/wiki/User:Infinity_Linden/IETF_Draft= s_and_Meetings . second, are the previous wiki pages from last summer's interop work. the IETF drafts were distillations of what we learned from the work last summer. they're supposed to reflect the state of the protocol that was actually deployed last summer. also... are we really going to have the "what are the limits on IETF modification?" discussion again? rather than try to address that question, which i feel i'm interpreting differently than what you're trying to say, let me answer this question... "given that we all know that the IETF has change control on these documents and can make whatever changes it wishes with them, how much change can be introduced to their current form before they represent a protocol that is wholly incompatible with the installed OGP base and difficult to use by existing implementers?" in other words... i think we all understand that if the IETF (as represented by the majority of participants with working code) wanted to, it could change these docs to a form that would be different enough that significant engineering would be required by existing implementers to come into accords with the standard. this would be a "good thing" (tm) if the changes led to a system that was more stable, more scalable, and otherwise better. it would be a "bad thing" (tm) if it was done for no reason and without evidence that such changes would make solutions based on it better. those of us from the "second life-like" virtual worlds community that have come to the IETF to continue our work here understand this. i guess what i'm trying to say is, this is a very difficult question to answer. the drafts are not gospel, but they do reflect previous engineering work. changing them will lead to some software engineer somewhere having to at least typing "make" a few times on the command line. but if the change is "good" then it'll be worth it. that's why we're here, to bring the work we've done to a larger community for review and to get recommendations for making it better. so... if someone suggested changing the protocol to better support OGP over avian carriers, i don't know how much support that change request would garner (though i might have a slightly different answer on April 1st.) though if someone suggested "make it a little more obvious how you're mapping application layer protocol on top of an HTTP(S) transport in a way that you could also map the app layer protocol messages on top of XMPP." that's a very serious request, and one i've been thinking about a lot lately, even though i'm personally convinced my organization is a long way off from using that transport. > >> The "what is needed" slide from the OGPX Draft Charter Issues presentati= on >> ( http://www.ietf.org/proceedings/75/slides/ogpx-2.pdf) was mentioned as= a >> possible source for this list for both (2) and (3), but needs massaging: >> >> (a) a security model describing trust relationships between hosts, >> (b) guidelines for the use of existing authentication & confidentiality >> mechanisms, >> (c) mechanisms for: >> =A0(i) establishing the user's presence in the virtual world >> =A0(ii) moving a user's presence from one authoritative host to another, >> =A0(iii) for identifying agents, and requesting information about them. >> (d) format descriptions for objects and avatars in a virtual world, > > For c.ii should it really be 'host' or is it actually 'region'? =A0Also, = the > use of 'authoritative' implies there can non-authoritative hosts. =A0Is t= hat > correct? yup. i think we're hitting the "mixing the abstract virtual worldy layer with the concrete implementationish layer" confusion again. and yes, after i type this, i'm going to go off and work on some more definitions to make things a bit more clear. "region" is a logical concept; it's a space inside a virtual world which contains objects (avatars and assets) whose services are bound to a single server instance. server instances are logical concepts in that you can have multiple regions on the same host, and the protocol shouldn't make assumptions about the service split. ergo... yes... i think you're right, we are talking about regions. but... when we come around again to start talking about trust, we may want to make access control decisions based on host aspects: IP address, client certificate to name a couple. and yes, we could put that info into the PDUs being transferred, but we were hoping to support a use model that allows us to make basic access control decisions before parsing the message content. the details of that discussion can probably be hammered out later... but yeah, we have to come up with some verbiage that accurately describes what we're trying to do so it can be inserted into the charter. as for the "authoritative" vs. "non-authoritative" split between hosts. i'm using this term to differentiate our protocol from others (DIS and HLA come to mind) and other virtual worlds implementations (WoW and Diablo II come to mind) that make extensive use of co-simulation. the second life-like worlds all use centralized simulation. so i guess you could say there is probably at most one machine that is "authoritative" for each region. so rather than saying the host itself is authoritative, we could say that it's calculations are authoritative in that while other hosts are free to co-simulate, the "authoritative" host won't participate in a co-simulation protocol with those hosts and will instead just send object updates to interested clients. so we could probably use the terms "client" and "server" and drop the term "authoritative" all together. but at some point we have to make it clear we're not supporting co-simulation. > As for what might be missing, I'm not seeing any semantics cited for any > actions other than defining and moving users. =A0Nothing about simulation > activity. if you're talking about "simulating a virtual world" i would argue that defining and moving user's avatars DOES simulate certain aspects of consensus reality: specifically those aspects dealing with object presence. if you're talking about "physics simulation" then yes, it's not in the spec, and might not need to be. again, we're not doing co-simulation, so there's no need for clients to know physics simulation parameters. they just need to accept updates about how objects are translating, rotating, scaling and deforming. whether these modifications are the result of physics simulation or script action should not be the concern of the non-co-simulating client. > >> 9. Ensure that while the charter scopes down the Virtual World problem >> space, it does it in an inclusive way rather than focusing on what is ou= t of >> scope and thus indecipherable to non-subject matter experts. It is expec= ted >> that output of the WG may be useful in scenarios beyond those specifical= ly >> under consideration, much as RFC 2068 is not simply used for hypertext. > > This type of goal is often present, but I'm pretty sure I've never seen a= ny > chartering text about it that had any meaning or any impact. =A0For examp= le, > what objective criteria could the IESG apply during document approval, to > tell whether the goal has been satisfied? hmm. are you implying that the IESG will get upset if our work product is used for something other than virtual world simulation? i don't think you are. i fear that turning the charter into a feature list of virtual worlds isn't the answer either (though it would make it easier to verify.) > > >> 10. Remove references to "wire" in "wire protocol"; this is implicit in >> the scope of work for IETF. The phrase "application-layer protocol" (as >> distinct from a novel transport-layer protocol) is accurate and sufficie= nt. > > Yes, but I'll also vote for removing "application-layer". =A0I now unders= tand > that it's meant to imply that it's above transport, but there's already > specific language about using transports. but again, we're not trying to create a new transport. and we're applying the argument that "the group's work product must be clear to technical non-specialists." it seems that if we want a charter that clearly identifies the groups scope, adding the words "application layer" to the charter make it very clear that this is not the group that will be developing LESS. > > No, this isn't a big deal, but in spite of primarily being as apps guy, I > think removing the phrase makes the text cleaner, with no loss of meaning= . > > >> 11. Add text specifying: The WG will define interfaces for a set of >> HTTP-based services ("web services") but not provide language specific >> bindings ("API") onto those services. > > Huh? =A0What's this about? =A0Sounds like the working group is going to d= o web > enhancements, rather than virtual world simulation. no. this is not about adding enhancements to HTTP(S). it is about layering the application layer protocol onto HTTP(S) as it exists now and is expected to exist in the near future. >> 12. Clarify the charter that we're explicitly targetting HTTP as the >> default transport. >> >> A concern was raised that reusing HTTP will lead to unnecessary and tigh= t >> coupling with that protocol's capabilities and semantics; a suggestion w= as >> made that if we wish to state that the protocols will be transport-neutr= al, >> the WG will investigate at least one other transport. Should we just tar= get >> HTTP, or make the effort? > > If transport-independence is claimed, the claim won't really be meaningfu= l > unless at least two different transport mappings are provided. > hmm... maybe it's time to advertise in the XMPP community. From dwl@us.ibm.com Mon Aug 3 12:56:03 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211BA3A6EC0; Mon, 3 Aug 2009 12:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=-0.976, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3b-U-c4hFSZ; Mon, 3 Aug 2009 12:56:02 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id EEE213A6EB9; Mon, 3 Aug 2009 12:56:01 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n73JtLAb007553; Mon, 3 Aug 2009 15:55:21 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n73Jtjec220208; Mon, 3 Aug 2009 15:55:50 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n73JtiYO027491; Mon, 3 Aug 2009 15:55:44 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n73JtiAs027484; Mon, 3 Aug 2009 15:55:44 -0400 In-Reply-To: References: To: Morgaine MIME-Version: 1.0 X-KeepSent: 5C64A22F:91BA9F9D-85257607:006B1DFF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Mon, 3 Aug 2009 15:55:44 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 08/03/2009 15:55:44, Serialize complete at 08/03/2009 15:55:44 Content-Type: multipart/alternative; boundary="=_alternative 006D794885257607_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] Next Steps for OGPX WG Charter X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 19:56:03 -0000 This is a multipart message in MIME format. --=_alternative 006D794885257607_= Content-Type: text/plain; charset="US-ASCII" ogpx-bounces@ietf.org wrote on 08/01/2009 12:44:14 AM: > Morgaine > Sent by: ogpx-bounces@ietf.org > > One of the best ways of tackling this is to directly ask who it > actually applies to. What kinds of worlds could interoperate through OGP? > > This question is often answered in an informal way: "OGP allows > interoperation between SL-like worlds." That answer is fair enough > when given loosely and informally, but it is not good enough for an > IETF spec, for obvious reasons. We may know what we mean, > informally, but we need a more objective way of expressing it, so > that people without any background in Second Life can still find it > precise and informative. > > I would like to propose that a different informal answer is > appropriate here, an answer which, while equally simple, is > enormously more embracing while still being just as concise and > specific and inherently implementable: > "OGP allows interoperation between any virtual worlds that implement > the protocol." > > This almost sounds recursive, but it is not: it makes it clear that > it doesn't matter how different and divergent the worlds may be, > they can still interoperate through OGP as long as they implement > that common protocol. It no longer mentions Second Life. It does > not refer to a totally fictitious unit of "the world". It does not > require interoperating worlds to be clones, either implicitly or > explicitly. It clearly states that the ONLY requirement for interop > is implementing this one protocol, or suite. > > In other words, it avoids being prescriptive about worlds, and it > lets adherence to the protocol define the universe of interop. > > > > Morgaine. > Please note that the "constraint" language in the charter is about the the requirements the specifications address. If you look at the constraint language in the most recent draft, while it suffers from requiring understanding a lot of terms in the space, it does permit a pretty easy decision as to whether a requirement is within the remit of the working group. The feedback from the BOF was not that the constraints are wrong, but that they are hard to understand. We're looking for edits and new language which can be more readily understood, but does not change the basic nature of the constraints. - David Levine ~ Zha Ewry ISL --=_alternative 006D794885257607_= Content-Type: text/html; charset="US-ASCII"

ogpx-bounces@ietf.org wrote on 08/01/2009 12:44:14 AM:

> Morgaine <morgaine.dinova@googlemail.com>
> Sent by: ogpx-bounces@ietf.org
>
> One of the best ways of tackling this is to directly ask who it
> actually applies to.  What kinds of worlds could interoperate through OGP?
>
> This question is often answered in an informal way:  "OGP allows
> interoperation between SL-like worlds."  That answer is fair enough
> when given loosely and informally, but it is not good enough for an
> IETF spec, for obvious reasons.  We may know what we mean,
> informally, but we need a more objective way of expressing it, so
> that people without any background in Second Life can still find it
> precise and informative.
>
> I would like to propose that a different informal answer is
> appropriate here, an answer which, while equally simple, is
> enormously more embracing while still being just as concise and
> specific and inherently implementable:
> "OGP allows interoperation between any virtual worlds that implement
> the protocol."
>
> This almost sounds recursive, but it is not:  it makes it clear that
> it doesn't matter how different and divergent the worlds may be,
> they can still interoperate through OGP as long as they implement
> that common protocol.  It no longer mentions Second Life.  It does
> not refer to a totally fictitious unit of "the world".  It does not
> require interoperating worlds to be clones, either implicitly or
> explicitly.  It clearly states that the ONLY requirement for interop
> is implementing this one protocol, or suite.
>
> In other words, it avoids being prescriptive about worlds, and it
> lets adherence to the protocol define the universe of interop.
>

>
>
> Morgaine.
>
Please note that the "constraint" language in the charter is about the
the requirements the specifications address.  If you look at the constraint
language in the most recent draft, while it suffers from requiring understanding
a lot of terms in the space, it does permit a pretty  easy decision as to whether
a requirement is within the remit of the working group. The feedback from the
BOF was not that the constraints are wrong, but that they are hard to understand.

We're looking for edits and new language which can be more readily understood, but does not
change the basic nature of the constraints.


- David Levine
~ Zha Ewry ISL
--=_alternative 006D794885257607_=-- From robla@lindenlab.com Tue Aug 4 17:31:54 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651DE3A709E for ; Tue, 4 Aug 2009 17:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeI8f92GEwTj for ; Tue, 4 Aug 2009 17:31:53 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [216.82.11.128]) by core3.amsl.com (Postfix) with ESMTP id AB9A03A68CB for ; Tue, 4 Aug 2009 17:31:53 -0700 (PDT) Received: from [10.1.23.136] (ip65-47-28-158.z28-47-65.customer.algx.net [65.47.28.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 5976C1414001; Tue, 4 Aug 2009 17:31:56 -0700 (PDT) Message-ID: <4A78D2F7.5080401@lindenlab.com> Date: Tue, 04 Aug 2009 17:31:51 -0700 From: Rob Lanphier User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4A74F1E4.8080209@dcrocker.net> In-Reply-To: <4A74F1E4.8080209@dcrocker.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: [ogpx] Transport independence (Re: Next Steps for OGPX WG Charter) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 00:31:54 -0000 On 08/01/2009 06:54 PM, Dave CROCKER wrote: > Joshua Bell wrote: >> 12. Clarify the charter that we're explicitly targetting HTTP as the >> default transport. >> >> A concern was raised that reusing HTTP will lead to unnecessary and >> tight coupling with that protocol's capabilities and semantics; a >> suggestion was made that if we wish to state that the protocols will >> be transport-neutral, the WG will investigate at least one other >> transport. Should we just target HTTP, or make the effort? > > If transport-independence is claimed, the claim won't really be > meaningful unless at least two different transport mappings are provided. For the claim to be watertight, two different transport mappings would need to be provided. However, it's still possible to make a meaningful claim of transport-independence mainly by making sure that: 1. The transport requirements (and non-requirements) are clearly specified 2. Everyone remains vigilant about ensuring that transport expectations are specified in the requirements Unless there's a great deal of interest from implementors to implement some other transport, it seems silly to waste the effort specifying another transport in the name of making a watertight claim of transport independence. Rob From mojitotech@gmail.com Tue Aug 4 19:05:06 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2AA3A7139 for ; Tue, 4 Aug 2009 19:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtVcKucOgpF3 for ; Tue, 4 Aug 2009 19:05:05 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 25B563A7147 for ; Tue, 4 Aug 2009 19:04:23 -0700 (PDT) Received: by qyk41 with SMTP id 41so5500058qyk.29 for ; Tue, 04 Aug 2009 19:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=BsF1N7Anke6JPYR7WMwkxc5yhI/VN3noMo7YrXupXow=; b=HEhrmBXOKyzImo+84r/KWklsFSC2S+EKAyU042DL3pwQXyNNwgO5gOchnXSYH1Hl+i 2zJr0LEZAWgU7rNke/sr4FlAbTKRB/vdvPX5Vt/JTkWBvU9s7kd+RyRZFfB7Ooui1lNo GToJD+fyVUcNtqHiQluUtZ5SAMEppReNkk72k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=hQBI377koJkSSEUpnfLpUAzr2zwsY9hSAdILM7WpKS7LJpVBkvRb4RFduY7OjSRn5P tQ5qCuuaISHzkgNOMrZwzLSpAjtYnob3o/xPc7aG4hoPSN3GS8cm5qiXNBfyrsTE3w6A L+1w+KQt4djZesWWqNpcIq1X9bdE7EuYf93uI= Received: by 10.224.80.211 with SMTP id u19mr6603683qak.263.1249437863941; Tue, 04 Aug 2009 19:04:23 -0700 (PDT) Received: from ?192.168.2.2? (c-75-68-60-158.hsd1.nh.comcast.net [75.68.60.158]) by mx.google.com with ESMTPS id 5sm16779425qwg.5.2009.08.04.19.04.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Aug 2009 19:04:22 -0700 (PDT) Message-ID: <4A78E879.2020504@gmail.com> Date: Tue, 04 Aug 2009 22:03:37 -0400 From: Mojito Sorbet User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: ogpx@ietf.org References: <4A74F1E4.8080209@dcrocker.net> <4A78D2F7.5080401@lindenlab.com> In-Reply-To: <4A78D2F7.5080401@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ogpx] Transport independence (Re: Next Steps for OGPX WG Charter) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 02:11:27 -0000 I observe that the Shoutcast audio streaming service uses HTTP. They initiate the connection with the headers and them leave it open for a loooong time sending data packets. Similarly XMPP sends an XML 'document' that takes HOURS to send, very slowly, one stanza at a time; in fact both ways at once. With those examples I see no problem in using HTTP(s) headers to describe the desired service endpoint (as Dave Crocker pointed out) and maybe encoding format, for a connection that stays open for a long time. I do think an exchange of HTTP headers per operation would be huge overkill for all but bulk transfers: textures, sounds, etc. This meets the needs for both supra-transport addressing and wide network reach, without imposing unreasonable end-to-end round-trip delays blocking the channel. Independent services, such as messaging, asset downloading, locality information, might even use separate connections, to different endpoints, depending how capabilities are managed within a given virtual world administrative domain. -Mo Rob Lanphier wrote: > On 08/01/2009 06:54 PM, Dave CROCKER wrote: > >> Joshua Bell wrote: >> >>> 12. Clarify the charter that we're explicitly targetting HTTP as the >>> default transport. >>> >>> A concern was raised that reusing HTTP will lead to unnecessary and >>> tight coupling with that protocol's capabilities and semantics; a >>> suggestion was made that if we wish to state that the protocols will >>> be transport-neutral, the WG will investigate at least one other >>> transport. Should we just target HTTP, or make the effort? >>> >> If transport-independence is claimed, the claim won't really be >> meaningful unless at least two different transport mappings are provided. >> > > For the claim to be watertight, two different transport mappings would > need to be provided. However, it's still possible to make a meaningful > claim of transport-independence mainly by making sure that: > 1. The transport requirements (and non-requirements) are clearly specified > 2. Everyone remains vigilant about ensuring that transport expectations > are specified in the requirements > > Unless there's a great deal of interest from implementors to implement > some other transport, it seems silly to waste the effort specifying > another transport in the name of making a watertight claim of transport > independence. > > Rob > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From dwl@us.ibm.com Tue Aug 4 20:32:35 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3883A70D3; Tue, 4 Aug 2009 20:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.411 X-Spam-Level: X-Spam-Status: No, score=-5.411 tagged_above=-999 required=5 tests=[AWL=1.187, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA+fgIE85lN6; Tue, 4 Aug 2009 20:32:34 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 9CBEC3A67E2; Tue, 4 Aug 2009 20:32:34 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n753QKHA017339; Tue, 4 Aug 2009 23:26:20 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n753WRE5135940; Tue, 4 Aug 2009 23:32:29 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n753WRID012595; Tue, 4 Aug 2009 23:32:27 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n753WRId012585; Tue, 4 Aug 2009 23:32:27 -0400 In-Reply-To: <4A78D2F7.5080401@lindenlab.com> References: <4A74F1E4.8080209@dcrocker.net> <4A78D2F7.5080401@lindenlab.com> To: ogpx@ietf.org, ogpx-bounces@ietf.org MIME-Version: 1.0 X-KeepSent: B4233516:8DB00FA4-85257609:000B8F47; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Tue, 4 Aug 2009 23:32:27 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 08/04/2009 23:32:27, Serialize complete at 08/04/2009 23:32:27 Content-Type: multipart/alternative; boundary="=_alternative 0013734D85257609_=" Subject: [ogpx] Event Streams, Realtime and transport X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 03:32:35 -0000 This is a multipart message in MIME format. --=_alternative 0013734D85257609_= Content-Type: text/plain; charset="US-ASCII" Based on some discussion after the BOF, i want to offer up the following to provoke discussion: Language to be included in the charter, in the properties of the protocol section: * The protocol needs to support the efficient delivery of asynchronous update streams between services, including, specifically between regions and clients. * The protocol needs to support the processing of real time user inputs and low level state changes As part of its work, the working group will characterize the required performance, and validate the suitability of transports for these needs. - David Levine ~ Zha Ewry In Second Life --=_alternative 0013734D85257609_= Content-Type: text/html; charset="US-ASCII"
Based on some discussion after the BOF, i want to offer up the following to provoke discussion:

Language to be included in the charter, in the properties of the protocol section:

* The protocol needs to support the efficient delivery of asynchronous update streams between services,
    including, specifically between regions and clients.
 
* The protocol needs to support the processing of real time user inputs and low level state changes As part
   of its work, the working group will characterize the required performance, and validate the suitability of
   transports for these needs.

- David Levine
~ Zha Ewry In Second Life
--=_alternative 0013734D85257609_=-- From meadhbh.siobhan@gmail.com Wed Aug 5 05:00:31 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E523A69FB; Wed, 5 Aug 2009 05:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvJD2PvypVQQ; Wed, 5 Aug 2009 05:00:30 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by core3.amsl.com (Postfix) with ESMTP id 14BE43A6A97; Wed, 5 Aug 2009 05:00:30 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so10447anc.4 for ; Wed, 05 Aug 2009 05:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aIFUwkFjzbcT0ZpZSiVlxWcM20aGNDJVLnctIFyTJak=; b=Cnaehc7Ssw74lKHGnlqlK4KZOfqRonBj0l0CbgNbVCTwFqFZC256hqLGRkV3BD67l/ joRFtkeyfOFqRUQO/5X98i1bP1ITUDe+alKe+CDtjl6nO2waW3X7ZF9P1KnIgvKxgZwj zIht2A7hG24bsvGvYNruDVqN0cx6EvCbit8XI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=avmeyFdFUd+UW5nK/eBKu4Xlu5UnN7NL9Sd41cXT4MrMG9Arcbip2S8ArlRVbUTfOe Vm6DpiIeWavYM6W+qDDlADoUPU3U626d37B6/q3pTaIp99+q4rvftIvO9zDAxdIXN9JS brxDyClkaJjWddP3pB2xfeSuEO53f3WcOe8dk= MIME-Version: 1.0 Received: by 10.100.43.14 with SMTP id q14mr10453224anq.47.1249473631051; Wed, 05 Aug 2009 05:00:31 -0700 (PDT) In-Reply-To: References: <4A74F1E4.8080209@dcrocker.net> <4A78D2F7.5080401@lindenlab.com> Date: Wed, 5 Aug 2009 05:00:31 -0700 Message-ID: From: Meadhbh Siobhan To: David W Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] Event Streams, Realtime and transport X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 12:00:31 -0000 experience tells us that real time formats and protocol are a surprisingly small portion of the solution space. also, the term "real time" is sometimes used to mean a number of different things. we also don't have a demonstrated need for real time data, only a perceived need for it. i would recommend we say that the definition of "real time" behavior is "in scope" and give ourselves the option of defining real-time behavior if needed. an example solution might be the use and definition of RTP payload formats for delivering object updates. but let's keep it an option at this point. having performance characteristics for various transactions is a good idea, but i don't know that we can mandate performance characteristics of any transport without introducing QoS. our assumptions up to this point was that the protocol defined messages that signaled state transitions and that these messages used REST-like request/response semantics. that is, the client sent the message and was responsible for receiving the response. if the response did not come in a "reasonable" amount of time, the client could repeat it. This is why REST resource accesses are supposed to be idempotent. We did not attempt to define the definition of "reasonable" but rather gave that intelligence to the client. i think we should be very clear that there's a difference between the desire that information be transmitted in a low-latency manner and the requirement that a protocol transaction be "real time." RT(C)P is designed to carry information that if it arrives too late, is useless. VoIP is the classic example; if a voice packet arrives too late it is discarded, you can't integrate it back into the voice stream. many virtual worlds and MMORPGs do not operate in this fashion today. instead of discarding late packets, the user experience just seems to freeze for a few moments followed by a rapid application of messages received. additionally, real time data can come over TCP or UDP (i would recommend keeping SCTP as an experimental option for the time being.) when it comes as UDP, it frequently has to compete with TCP traffic. as the network approaches its network rate and packets start disappearing, it's frequently the UDP messages that suffer the most. ergo, you'll start seeing real time data disappear. if you send it over TCP, then you get latency induced by recovering from congestion control. so.. in short... we should be EXTREMELY certain that this is what we want to do. we should also be EXTREMELY certain as to which parts of the protocol should be given a "real time" option. and we should keep it an option. for example, defining object updates in terms of RTP would effectively eliminate a web client using XMLHttpRequest() as it's primary mode of interaction from accessing state change information. ditto for XMPP clients. -cheers -meadhbh On Tue, Aug 4, 2009 at 8:32 PM, David W Levine wrote: > > Based on some discussion after the BOF, i want to offer up the following = to > provoke discussion: > > Language to be included in the charter, in the properties of the protocol > section: > > * The protocol needs to support the efficient delivery of asynchronous > update streams between services, > =A0 =A0 including, specifically between regions and clients. > > * The protocol needs to support the processing of real time user inputs a= nd > low level state changes As part > =A0 =A0of its work, the working group will characterize the required > performance, and validate the suitability of > =A0 =A0transports for these needs. > > - David Levine > ~ Zha Ewry In Second Life > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From meadhbh.siobhan@gmail.com Wed Aug 5 05:13:24 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B793A6860 for ; Wed, 5 Aug 2009 05:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FxrbFiQFEUo for ; Wed, 5 Aug 2009 05:13:23 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) by core3.amsl.com (Postfix) with ESMTP id 0E90E3A67A4 for ; Wed, 5 Aug 2009 05:13:22 -0700 (PDT) Received: by yxe3 with SMTP id 3so56050yxe.29 for ; Wed, 05 Aug 2009 05:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3ZP/tx4tvCb4GWs0MvzW2qBi8rwOpdw6YOrAHlkEFcQ=; b=UT/bdBa2jPYwCw5F2mABXE4/XKL26nn5uWgVtnnnEd7tcfcv3tCVQpQfKzU6xc+KRt nEdoKkJyrNy5zyKwBT2JTP4RUCoMT85qbL0iwJcbBO6xjGNDSfwI5M62DKmqUxG7OcTJ iBuQCMpjYbVmEF2gdO4ZxO8rga11V48cMbi3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BMR3vD3ciFO1/QjUf14imxBI442vTxh2H2+/jb6YodPE4rE/I8dMPWtoXAbpQeE4bo /f4kCro90eQd9LzNwArLsYd31zgWMc81Pq5isvGCNp4KnJwlPDyKEYl0cLPHA+fNkY0k n3tfmvrNDK5uXmIxOe1lrmLnGhxPVYSO9F5us= MIME-Version: 1.0 Received: by 10.100.252.13 with SMTP id z13mr10515152anh.24.1249474403996; Wed, 05 Aug 2009 05:13:23 -0700 (PDT) In-Reply-To: <4A78E879.2020504@gmail.com> References: <4A74F1E4.8080209@dcrocker.net> <4A78D2F7.5080401@lindenlab.com> <4A78E879.2020504@gmail.com> Date: Wed, 5 Aug 2009 05:13:23 -0700 Message-ID: From: Meadhbh Siobhan To: Mojito Sorbet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Transport independence (Re: Next Steps for OGPX WG Charter) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 12:13:24 -0000 On Tue, Aug 4, 2009 at 7:03 PM, Mojito Sorbet wrote: > I observe that the Shoutcast audio streaming service uses HTTP. =A0They > initiate the connection with the headers and them leave it open for a > loooong time sending data packets. =A0Similarly XMPP sends an XML 'docume= nt' > that takes HOURS to send, very slowly, one stanza at a time; =A0in fact b= oth > ways at once. i think the XMPP people would argue that it's sending event stream updates using XML stanzas, not complete documents. also, i think the reason people started streaming over HTTP was to get through firewalls. i can't imagine that taking real time data, base64 encoding it and putting it on a HTTP transport was their first choice. though a lesson might be gleaned from the fact that people had to do these things. > With those examples I see no problem in using HTTP(s) headers to describe > the desired service endpoint (as Dave Crocker pointed out) and maybe > encoding format, for a connection that stays open for a long time. =A0I d= o > think an exchange of HTTP headers per operation would be huge overkill fo= r > all but bulk transfers: =A0textures, sounds, etc. mmm... i would argue exactly the opposite. sending a single texture or sound in a single HTTP exchange is... well... it's what HTTP was designed to do, and several ISPs optimize for this use case. also, the reason we want to use HTTP as a transport has less to do with it's ability to get through firewalls or to make use of ISP optimizations, and more to do with the fact that it defines messaging semantics that are useful. if you look at the second life legacy protocol, there were several points where we wanted the "fast" behavior of UDP, but then realized we needed to get message confirmation. we thus defined request/response semantics using UDP. this was fine unless one of the request or response packets was dropped, so we started developing per message rules on retransmitting messages. down this path leads insanity. this is why we like HTTP. it has well defined request/response semantics. this means that we don't have to redefine the concept of a request in a custom UDP protocol. it is layered on top of TCP, so if there's packet loss, an optimized software module in each hosts' operating system will handle the recovery. if those features did not exist in any existing protocol, it is likely we would re-invent them. but, as it turns out, you do get them in HTTP and you get a mature tool chain and you get the ability to interact with OGP systems in a web browser. > This meets the needs for both supra-transport addressing and wide network > reach, without imposing unreasonable end-to-end round-trip delays blockin= g > the channel. i'm kind of at a loss to understand what "end to end round trip delays" we're talking about. > > Independent services, such as messaging, asset downloading, locality > information, might even use separate connections, to different endpoints, > depending how capabilities are managed within a given virtual world > administrative domain. > > -Mo > > Rob Lanphier wrote: >> >> On 08/01/2009 06:54 PM, Dave CROCKER wrote: >> >>> >>> Joshua Bell wrote: >>> >>>> >>>> 12. Clarify the charter that we're explicitly targetting HTTP as the >>>> default transport. >>>> >>>> A concern was raised that reusing HTTP will lead to unnecessary and >>>> tight coupling with that protocol's capabilities and semantics; a >>>> suggestion was made that if we wish to state that the protocols will >>>> be transport-neutral, the WG will investigate at least one other >>>> transport. Should we just target HTTP, or make the effort? >>>> >>> >>> If transport-independence is claimed, the claim won't really be >>> meaningful unless at least two different transport mappings are provide= d. >>> >> >> For the claim to be watertight, two different transport mappings would >> need to be provided. However, it's still possible to make a meaningful >> claim of transport-independence mainly by making sure that: >> 1. The transport requirements (and non-requirements) are clearly specifi= ed >> 2. Everyone remains vigilant about ensuring that transport expectations >> are specified in the requirements >> >> Unless there's a great deal of interest from implementors to implement >> some other transport, it seems silly to waste the effort specifying >> another transport in the name of making a watertight claim of transport >> independence. >> >> Rob >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From dwl@us.ibm.com Wed Aug 5 11:41:34 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C303A3A68F2; Wed, 5 Aug 2009 11:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.581 X-Spam-Level: X-Spam-Status: No, score=-5.581 tagged_above=-999 required=5 tests=[AWL=1.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vcvgrn5G-aVs; Wed, 5 Aug 2009 11:41:30 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id E5FB53A695C; Wed, 5 Aug 2009 11:41:29 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n75Ia4O8028375; Wed, 5 Aug 2009 14:36:04 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n75IfV1D180916; Wed, 5 Aug 2009 14:41:31 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n75IfUfC011330; Wed, 5 Aug 2009 14:41:31 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n75IfUVi011281; Wed, 5 Aug 2009 14:41:30 -0400 In-Reply-To: References: <4A74F1E4.8080209@dcrocker.net> <4A78D2F7.5080401@lindenlab.com> To: Meadhbh Siobhan MIME-Version: 1.0 X-KeepSent: 1F6FC7D5:4F6A8CE6-85257609:005DF72A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Wed, 5 Aug 2009 14:41:24 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 08/05/2009 14:41:29, Serialize complete at 08/05/2009 14:41:29 Content-Type: multipart/alternative; boundary="=_alternative 0066AAC085257609_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] Event Streams, Realtime and transport X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 18:41:34 -0000 This is a multipart message in MIME format. --=_alternative 0066AAC085257609_= Content-Type: text/plain; charset="US-ASCII" So... Infinity made some very fair points. Lets try this. For streaming: I want to take a moment to walk the why... So, speaking a bit abstractly... When we inject an Avatar into a Region, we model this as a pretty straight forward request/response call. The region gets called, accepts the agent's avatar information and adds it to the local state. The region is maintaining and continually updating the state of the virtual space it manages. The region needs to push down to the client, the current state, and then, incrementally updates to that state. So, a side effect of entering the region is that the region sends its current state, and then begins to stream updates. This is, of course, the core business of the region. The Legacy Second Life Protocol streams down a series of "object updates" which consist of the shapes of things, along with pointers to the textures and (in the case of scuplties, the sculpt map) The client then can consult its cache, and either fetch these bulky items from the cache, or from the Region. The current charter doesn't say a lot about the nature of the Client / Region relationship. So.. lets try this... First, the attributes we want to address: * Regions hold and manage the "state" of the virtual space they represent. They accept agent actions, simulate the region, and send updates to the clients who can see their portion of virtual space. Then.. in protocol characteristics: * The specifications will include an asynchronous, region driven set of updates which are delivered to clients. The specifications will include a balanced blend of notifying clients of updates, over available transports, and pulling data from the region as needed. For realtime: In the attributes of worlds we want to address section: add: * Bounded by Latency constraints, are expected to be responsive to simple user inputs without queuing delays. This does not mean complex actions will be performed in real time, but that the overall specification set accepts the requirement that some low level operations happen without protocol imposed delays. (One wants forward step, turn and such, to be fast, we are NOT mandating "Rez 12,000 prim object in 400 mseconds" ) In the protocol characteristics: * Managing the desired response time goals for low level user inputs may require routing some traffic on protocols optimized for low latency use. The working group will characterize these goals. The Working group will evaluate the suitability of proposed transports in light of these characterizations. NOTE: these are coupled. The goal is to deliver a near simultaneous experience, in which the collective actions of all the present avatars, along with scripted objects, physics simulations and other computational artifacts are updated in a smooth, continuous fashion. One could easily model the set of updates as a resource, which the client "gets" once every so often. At the several minute perspective, this would likely deliver all the needed data. At the user level, it would not permit the client to create a smooth, shared immersive experience. - David --=_alternative 0066AAC085257609_= Content-Type: text/html; charset="US-ASCII"
So... Infinity made some very fair points. Lets try this.





For streaming:

I want to take a moment to walk the why...

So, speaking a bit abstractly...

When we inject an Avatar into a Region, we model this as a pretty straight forward request/response call. The region gets called, accepts the agent's avatar information and adds it to the
local state. The region is maintaining and continually updating the state of the virtual space it manages. The region needs to push down to the client, the current state, and then, incrementally
updates to that state. So, a side effect of entering the region is that the region sends its current state, and then begins to stream updates. This is, of course, the core business of the region.

The Legacy Second Life Protocol streams down a series of "object updates" which consist of the shapes of things, along with pointers to the textures and (in the case of scuplties, the sculpt map) The client then can consult its cache, and either fetch these bulky items from the cache, or from the Region.

The current charter doesn't say a lot about the nature of the Client / Region relationship. So.. lets try this...

First, the attributes we want to address:

* Regions hold and manage the "state" of the virtual space they represent. They accept agent actions, simulate the region, and send updates to the clients who can see their portion of virtual space.

Then.. in protocol characteristics:

* The specifications will include an asynchronous, region driven set of updates which are delivered to clients. The specifications will include a balanced blend of notifying clients of updates, over available transports, and pulling data from the region as needed.


For realtime:

In the attributes of worlds we want to address section:

add:

* Bounded by Latency constraints, are expected to be responsive to simple user inputs without queuing delays. This does not mean complex actions will be performed in real time, but that the overall specification set accepts the requirement that some low level operations happen without protocol imposed delays.

(One wants forward step, turn and such, to be fast, we are NOT mandating "Rez 12,000 prim object in 400 mseconds" )

In the protocol characteristics:

* Managing the desired response time goals for low level user inputs may require routing some traffic on protocols optimized for low latency use. The working group will characterize these goals. The Working group will  evaluate the suitability of proposed transports in light of these characterizations.


NOTE: these are coupled. The goal is to deliver a near simultaneous experience, in which the collective actions of all the present avatars, along with scripted objects, physics simulations and other computational artifacts are updated in a smooth, continuous fashion. One could easily model the set of updates as a resource, which the client "gets" once every so often. At the several minute perspective,
this would likely deliver all the needed data. At the user level, it would not  permit the client to create a smooth, shared immersive experience.

- David
--=_alternative 0066AAC085257609_=-- From mojitotech@gmail.com Wed Aug 5 16:40:17 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84303A67D4 for ; Wed, 5 Aug 2009 16:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KU3oq0sOqLS for ; Wed, 5 Aug 2009 16:40:13 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 208AB3A6C68 for ; Wed, 5 Aug 2009 16:39:23 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so199714qwi.31 for ; Wed, 05 Aug 2009 16:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mVfmTaz+OZ5ye5E7TCjePlLSa0YrrgBCBtMgHt7iRJA=; b=IUbF57TI1vC/Zxsf8gxUJ3MdubAbZacFNQCKy3FdPCEKWFZpCIanRAfFkZ2wGSbzDx jpIFC631WpJAUoEoVYceAswFZaL9ABN/0TTATXPznTBTAoqwZzPEAiVv7+2nyO3UU3Jq upStsGdqDjHLn7RhDapthgpBiqrJ6zyOvnu9Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=EwW/SoWcZJNqk+UbwgwNGkvTOLQSoCa9yjzY6StYjAfytz8xRoWPUtwpvQ0sH/Xx7U 9m+FFnwK2UjNbX+hne7+ckyRpsF8Hz2tgYOynsHLDtBltdBEVFgwZ6LxSorw9gbrb7+V YxqRC1O0R2HwcMRW7iGJwViOZyFSImixS/8Kk= Received: by 10.224.28.75 with SMTP id l11mr7794537qac.172.1249515564091; Wed, 05 Aug 2009 16:39:24 -0700 (PDT) Received: from ?192.168.2.2? (c-75-68-60-158.hsd1.nh.comcast.net [75.68.60.158]) by mx.google.com with ESMTPS id 7sm1767658qwf.18.2009.08.05.16.39.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Aug 2009 16:39:22 -0700 (PDT) Message-ID: <4A7A180B.3020001@gmail.com> Date: Wed, 05 Aug 2009 19:38:51 -0400 From: Mojito Sorbet User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: ogpx@ietf.org References: <4A74F1E4.8080209@dcrocker.net> <4A78D2F7.5080401@lindenlab.com> <4A78E879.2020504@gmail.com> In-Reply-To: <4A78E879.2020504@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ogpx] Transport independence (Re: Next Steps for OGPX WG Charter) X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 23:40:17 -0000 Meadhbh missinterpreted my points. I did not say that XMPP is transferring multiple documents, but exactly ONE document, according to what the syntax rules of XML are. There is an opening tag when the session opens, and the closing tag is not sent until the session closes. At a syntax level, they are transferring xml stanzas, very slowly. In fact those represent events, but they have the the form of xml. Similarly we could send an HTTP header, followed by a series of (and certainly not base64 coded), and claim to be using an HTTP transport. Also, I specifically said that large objects like textures WERE an obvious candidate to send as independent HTTP transfers. I would do that over a separate channel, so as not to tie up the shorter events. ------------------------------------------------------------------------ On Tue, Aug 4, 2009 at 7:03 PM, Mojito Sorbet wrote: >> Similarly XMPP sends an XML 'document' >> that takes HOURS to send, very slowly, one stanza at a time; in fact both >> ways at once. Meadhbh Siobhan wrote: >i think the XMPP people would argue that it's sending event stream >updates using XML stanzas, not complete documents. From infinity@lindenlab.com Wed Aug 12 17:54:27 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F343A690A for ; Wed, 12 Aug 2009 17:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIGWvRHQuqZC for ; Wed, 12 Aug 2009 17:54:26 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 380CF3A6AD7 for ; Wed, 12 Aug 2009 17:54:21 -0700 (PDT) Received: by fxm26 with SMTP id 26so322149fxm.42 for ; Wed, 12 Aug 2009 17:53:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.144.67 with SMTP id y3mr181663fau.11.1250124784228; Wed, 12 Aug 2009 17:53:04 -0700 (PDT) Date: Wed, 12 Aug 2009 17:53:04 -0700 Message-ID: <3a880e2c0908121753s34bacba7k59fae708752d3d6a@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ogpx] HTTP(S) and XMPP as transports of OGP application layer messages X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 00:54:27 -0000 Hey people! So... looping back around to some of the comments from the f2f BoF meeting... Original work with OGP used HTTP(S) to carry application messages. There's been enough talk about alternate transports that it feels very bad to dismiss them without discussion. However, I'm wondering if there's anyone out there planning on implementing OGP over XMPP? The reason I ask is that a number of us who worked on the early pre-IETF interop trials are heavily invested in HTTP(S). Though i can't speak for everyone involved, i would anticipate resistance to mandating a new transport. HTTP(S) has it's weaknesses as a transport, to be sure, but it's a well deployed and well understood protocol with a mature tool chain. This makes it attractive to many people. On the other hand, if someone else thinks they want to produce an OGP implementation over XMPP, that seems really cool. But if no one's going to implement it, an argument could be made that putting the effort into specifying it would be a waste of time. On yet another hand, going through the exercise of figuring out what aspects of HTTP are required to transport OGP messages might reveal subtle dependencies between components. Back on the other hand again, can we do this without re-writing BCP56? So I was thinking of this as a proposal: If there is strong interest in implementing OGP over XMPP, let's mention that it's an "officially supported" transport in the charter. (for some definition of the words "officially supported.") If there's not strong interest in implementing OGP over XMPP, let's not put it in the charter. In either case, I think there's sufficient justification for describing the set of requirements OGP makes on it's transport. For instance, does it REQUIRE request/response semantics? (i.e. - if i'm writing a compliant server layering OGP over XMPP, and i receive an OGP "request" in an XML stanza, am i REQUIRED to send a response?) Or... does it REQUIRE specific content negotiation semantics? (i.e. - do we need to explicitly describe or reference a technique for identifying the content type of a response in XMPP?) Or... does the protocol explicitly depend on caching behavior of some HTTP proxies? if so, how? etc. etc. -sincerely -meadhbh From mojitotech@gmail.com Thu Aug 13 07:24:27 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7043A684F for ; Thu, 13 Aug 2009 07:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1kwCIqv-M5o for ; Thu, 13 Aug 2009 07:24:23 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id AF4353A6834 for ; Thu, 13 Aug 2009 07:24:10 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so285754qwi.31 for ; Thu, 13 Aug 2009 07:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xtlCxswRd4Uk0gE/wEDAYegXkeMYzJVUP3+7J67VAM4=; b=k8CBjpr2SDj/Em6gUQVXm14gdunubwTHk9asVFCp/1l9ekOgyYYI6et7dnWcpnD0hj 9aEENECYEW4i4qpkOQUIuXoWOGPFPBJ/KPty2EjZlG7nOfS5Il/H3+xzF0Uc2Ey8PyUo IxpA0E1mF66aQQjCX4MpHtKSZ8vK3gzB42/iw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=BrO3S4dgLHNJoyJ86gHk3RRgL+0WikYWZ9zPVdtsBH1cp1UMNCWGpulU2VlBbR8Nhj je3twHRIpd1EWHomjhlCBzXxpbP7HU7+zJa5G/YmtvsztnDtSq5aTj3lCvrvqHX2jDy4 wUjblXNl/B0LUjqCHvig8exbf8GGLalhLF5Vs= Received: by 10.224.116.196 with SMTP id n4mr1239133qaq.320.1250172892358; Thu, 13 Aug 2009 07:14:52 -0700 (PDT) Received: from ?192.168.2.95? (c-75-68-60-158.hsd1.nh.comcast.net [75.68.60.158]) by mx.google.com with ESMTPS id 6sm710605qwd.38.2009.08.13.07.14.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Aug 2009 07:14:50 -0700 (PDT) Message-ID: <4A841FD5.7020602@gmail.com> Date: Thu, 13 Aug 2009 10:14:45 -0400 From: Mojito Sorbet User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ogpx@ietf.org References: <3a880e2c0908121753s34bacba7k59fae708752d3d6a@mail.gmail.com> In-Reply-To: <3a880e2c0908121753s34bacba7k59fae708752d3d6a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ogpx] HTTP(S) and XMPP as transports of OGP application layer messages X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 14:24:27 -0000 Infinity Linden wrote: > For > instance, does it REQUIRE request/response semantics? (i.e. - if i'm > writing a compliant server layering OGP over XMPP, and i receive an > OGP "request" in an XML stanza, am i REQUIRED to send a response?) Well, if you are "requesting" something, that should "require" a response. For example, the stanza in XMPP does this. for both "get" and "set" operations. The need for a response does not block the channel from carrying other stanzas in the meantime, which I think is an advantage over HTTP. But if you are just reporting an event, as in a or stanza, I do not see the need for any reply at all. The whole reason for using something over TCP is so that we do not have to worry "did it get there?" I am not suggesting that , , or stanzas as-is are appropriate for OGP. I only mention them as examples of how an XMPP stream can carry both types. XMPP today does some form of negotiation at session startup, mostly for determining login credentials and encryption level, so there is some precedent for that. From infinity@lindenlab.com Thu Aug 13 07:42:05 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BD133A6AAF for ; Thu, 13 Aug 2009 07:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONKvXpCVIzeW for ; Thu, 13 Aug 2009 07:42:04 -0700 (PDT) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by core3.amsl.com (Postfix) with ESMTP id 558B63A68B8 for ; Thu, 13 Aug 2009 07:42:04 -0700 (PDT) Received: by fxm26 with SMTP id 26so622304fxm.42 for ; Thu, 13 Aug 2009 07:41:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.145.3 with SMTP id b3mr360179fav.67.1250174492372; Thu, 13 Aug 2009 07:41:32 -0700 (PDT) In-Reply-To: <4A841FD5.7020602@gmail.com> References: <3a880e2c0908121753s34bacba7k59fae708752d3d6a@mail.gmail.com> <4A841FD5.7020602@gmail.com> Date: Thu, 13 Aug 2009 07:41:32 -0700 Message-ID: <3a880e2c0908130741lface1fck49bc7b2ec9214bf7@mail.gmail.com> From: Infinity Linden To: Mojito Sorbet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] HTTP(S) and XMPP as transports of OGP application layer messages X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 14:42:05 -0000 right. i think this is the kind of stuff we need to explicitly call out to provide guidance for implementers. i.e. - that clients can't require the next message from an XMPP peer to be the response to the previous request. for content negotiation, i was thinking more for the external references and responses where the type is something other than an XML stanza or an XML stanza that encapsulates something other than XML. (like maybe you were sending LSL over the wire. in HTTP, you could tag it with a Content-Type:. in XMPP, you could define a message format that included the content type as an XML element.) -cheers -meadhbh On Thu, Aug 13, 2009 at 7:14 AM, Mojito Sorbet wrote: > Infinity Linden wrote: >> >> For >> instance, does it REQUIRE request/response semantics? (i.e. - if i'm >> writing a compliant server layering OGP over XMPP, and i receive an >> OGP "request" in an XML stanza, am i REQUIRED to send a response?) > > Well, if you are "requesting" something, that should "require" a response= . > =A0For example, the stanza in XMPP does this. for both "get" and "s= et" > operations. =A0The need for a response does not block the channel from > carrying other stanzas in the meantime, which I think is an advantage ove= r > HTTP. > > But if you are just reporting an event, as in a or > stanza, I do not see the need for any reply at all. =A0 The whole reason = for > using something over TCP is so that we do not have to worry "did it get > there?" > > I am not suggesting that , , or stanzas as-is = are > appropriate for OGP. =A0I only mention them as examples of how an XMPP st= ream > can carry both types. > > XMPP today does some form of negotiation at session startup, mostly for > determining login credentials and encryption level, so there is some > precedent for that. > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From morgaine.dinova@googlemail.com Thu Aug 13 09:56:26 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059053A6C43 for ; Thu, 13 Aug 2009 09:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8o0i1aOR90T for ; Thu, 13 Aug 2009 09:56:24 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id C091D3A6A71 for ; Thu, 13 Aug 2009 09:56:23 -0700 (PDT) Received: by ewy10 with SMTP id 10so926677ewy.37 for ; Thu, 13 Aug 2009 09:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ytObEFX1rsBeDtrC2INGxYXyZzz+jhAY0rojPFbpeIY=; b=WCV/ccrk/NJq3lp0O0Kh7BI1AGlOYTBjOS6PqbZDF6PgcsKv7h2BuBlrEo6KyUEt8y V4IOfi1dOSbmv3yG5CHb9RIIfUoa916EhJwSW4hzPtkW7eqT/rup2z1ebkO2sOAdU32D x96Rvqzcmke19jlCwBgNEKH1NiNdZ7h/67Gi8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=CZrcrZ60zaiSwChBV7q9QyaZ81Tokpj3LaSZBVXNdoNmP1Z6/SSOz0wq4VhduVgzm+ 5gY7l9nnxBvs7fjimI8GJmNODo3QgnnuW+2WC7FWFG2f69pqS+WkZG4bUTWZtBHnQiWE 7RN6XiuB8rfzUlSzHX/R2U+pep1J6TLy1nbTA= MIME-Version: 1.0 Received: by 10.210.82.13 with SMTP id f13mr1873781ebb.95.1250182482621; Thu, 13 Aug 2009 09:54:42 -0700 (PDT) In-Reply-To: <3a880e2c0908121753s34bacba7k59fae708752d3d6a@mail.gmail.com> References: <3a880e2c0908121753s34bacba7k59fae708752d3d6a@mail.gmail.com> Date: Thu, 13 Aug 2009 17:54:42 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174c17b4c7f6cc047108cafd Subject: Re: [ogpx] HTTP(S) and XMPP as transports of OGP application layer messages X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 16:56:26 -0000 --0015174c17b4c7f6cc047108cafd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden wrote: > > Original work with OGP used HTTP(S) to carry application messages. > There's been enough talk about alternate transports that it feels very > bad to dismiss them without discussion. However, I'm wondering if > there's anyone out there planning on implementing OGP over XMPP? > Asking the question in this form creates a bit of a false dichotomy. HTTP(S) and XMPP cover different areas of the solution space, so they are not simple alternatives. It's better to first disentangle the requirements, and then see what is applicable to each part. OGP networking requirements (as far as we know them) comprise at least three different types of functionality, although the 3rd is a matter of some debate: 1. HTTP(S) client-server request/response calls to OGP services. 2. Server-client streaming object updates, over an unspecified reliable transport. 3. HTTP(S) server-client request/response calls to client-side services. Type 1 is wonderfully served by HTTP(S), while XMPP leaves a lot to be desired in this role, for which it was not designed. Type 2 is not served naturally by HTTP(S) at all, but because this requirement is so common in many types of applications, the "web everywhere" fraternity has tried to shoehorn this type into HTTP as well, using a variety of proposed strategies ranging from COMET's Long Poll and Streamed Response through to the latest WebSockets, with debateable success. XMPP was designed to serve this type of networking functionality, although its targetted application area is somewhat different to that of VWs. Whether it would be able to carry object updates with sufficient efficiency would require analysis and testing. Type 3 is poorly specified at present, and it may turn out to be a non-existent requirement stemming only from a misguided attempt to poll clients instead of receiving streamed asynchronous updates from them. On the other hand it may turn out to be an essential networking facility for providing symmetry between clients and servers, for instance when decoupled OGP services run on the client --- this will need much more discussion. Assuming for now that there is indeed such a requirement, HTTP may serve it adequately when run over Reverse HTTP, whereas XMPP would leave a lot to be desired in this role for which it was not designed. The above is confusing and fragmented enough, but it gets worse. There is yet another networking type common to VWs which has not even been mentioned in our two years of AWG and the 6 months of MMOX deliberations, yet is an essential type with its own properties: streaming of input events and objects from client to server. This is (roughly) lumped in with Type 2 in current SL and Opensim implementations, and it appears to be destined to be lumped in with Type 1 in OGP, where it fits poorly for reasons of latency on realtime inputs. Neither HTTP(S) nor XMPP seem ideal for this, although XMPP has a much closer semantic fit owing to its Jabber heritage. So where does this leave us? Well the first thing that should be clear is that we are not facing a simple question of "Should we do it all over HTTP alone, or also allow for implementation over XMPP?". The design requirements aren't like that at all. In particular, HTTP(S) just doesn't fit the Type 2 semantic requirement, and XMPP may not either. Given that our current task is only to define the charter and not to constrain the solutions, I think that any form of wording that suggests that HTTP(S) alone is sufficient should be avoided, because it is not sufficient for Type 2 based on our existing experience in virtual worlds. To put it bluntly, it's too slow, and the polling model has inadequate latency properties. I suggest therefore that this question of "HTTP(S) and/or XMPP" not be addressed in the charter, because the requirements have not yet been examined in sufficient detail to be able to make that call. Indeed, Type 2 may require a different protocol altogether. Morgaine. On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden wrote: > Hey people! > > So... looping back around to some of the comments from the f2f BoF > meeting... > > Original work with OGP used HTTP(S) to carry application messages. > There's been enough talk about alternate transports that it feels very > bad to dismiss them without discussion. However, I'm wondering if > there's anyone out there planning on implementing OGP over XMPP? > > The reason I ask is that a number of us who worked on the early > pre-IETF interop trials are heavily invested in HTTP(S). Though i > can't speak for everyone involved, i would anticipate resistance to > mandating a new transport. HTTP(S) has it's weaknesses as a transport, > to be sure, but it's a well deployed and well understood protocol with > a mature tool chain. This makes it attractive to many people. > > On the other hand, if someone else thinks they want to produce an OGP > implementation over XMPP, that seems really cool. But if no one's > going to implement it, an argument could be made that putting the > effort into specifying it would be a waste of time. On yet another > hand, going through the exercise of figuring out what aspects of HTTP > are required to transport OGP messages might reveal subtle > dependencies between components. Back on the other hand again, can we > do this without re-writing BCP56? > > So I was thinking of this as a proposal: > > If there is strong interest in implementing OGP over XMPP, let's > mention that it's an "officially supported" transport in the charter. > (for some definition of the words "officially supported.") > > If there's not strong interest in implementing OGP over XMPP, let's > not put it in the charter. > > In either case, I think there's sufficient justification for > describing the set of requirements OGP makes on it's transport. For > instance, does it REQUIRE request/response semantics? (i.e. - if i'm > writing a compliant server layering OGP over XMPP, and i receive an > OGP "request" in an XML stanza, am i REQUIRED to send a response?) > Or... does it REQUIRE specific content negotiation semantics? (i.e. - > do we need to explicitly describe or reference a technique for > identifying the content type of a response in XMPP?) Or... does the > protocol explicitly depend on caching behavior of some HTTP proxies? > if so, how? etc. etc. > > -sincerely > -meadhbh > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0015174c17b4c7f6cc047108cafd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden <infinity@lindenlab.com>= wrote:

Original work with OGP used HTTP(S) to carry application messages.
There's been enough talk about alternate transports that it feels very<= br> bad to dismiss them without discussion. However, I'm wondering if
there's anyone out there planning on implementing OGP over XMPP?


Asking the question in this form creates a bit of a fa= lse dichotomy.=A0 HTTP(S) and XMPP cover different areas of the solution sp= ace, so they are not simple alternatives.=A0 It's better to first disen= tangle the requirements, and then see what is applicable to each part.

OGP networking requirements (as far as we know them) comprise at least = three different types of functionality, although the 3rd is a matter of som= e debate:

  1. HTTP(S) client-server request/response calls to OG= P services.
  2. Server-client streaming object updates, over an unspecified reliable tr= ansport.
  3. HTTP(S) server-client request/response calls to client-sid= e services.

Type 1 is wonderfully served by HTTP(S), while XMP= P leaves a lot to be desired in this role, for which it was not designed.
Type 2 is not served naturally by HTTP(S) at all, but because this requ= irement is so common in many types of applications, the "web everywher= e" fraternity has tried to shoehorn this type into HTTP as well, using= a variety of proposed strategies ranging from COMET's Long Poll and St= reamed Response through to the latest WebSockets, with debateable success.= =A0 XMPP was designed to serve this type of networking functionality, altho= ugh its targetted application area is somewhat different to that of VWs.=A0= Whether it would be able to carry object updates with sufficient efficienc= y would require analysis and testing.

Type 3 is poorly specified at present, and it may turn out to be a non-= existent requirement stemming only from a misguided attempt to poll clients= instead of receiving streamed asynchronous updates from them.=A0 On the ot= her hand it may turn out to be an essential networking facility for providi= ng symmetry between clients and servers, for instance when decoupled OGP se= rvices run on the client --- this will need much more discussion.=A0 Assumi= ng for now that there is indeed such a requirement, HTTP may serve it adequ= ately when run over Reverse HTTP, whereas XMPP would leave a lot to be desi= red in this role for which it was not designed.

The above is confusing and fragmented enough, but it gets worse.
There is yet another networking type common to VWs which has not even been= mentioned in our two years of AWG and the 6 months of MMOX deliberations, = yet is an essential type with its own properties: =A0 streaming of input ev= ents and objects from client to server.=A0 This is (roughly) lumped in with= Type 2 in current SL and Opensim=A0 implementations, and it appears to be = destined to be lumped in with Type 1 in OGP, where it fits poorly for reaso= ns of latency on realtime inputs.=A0 Neither HTTP(S) nor XMPP seem ideal fo= r this, although XMPP has a much closer semantic fit owing to its Jabber he= ritage.

So where does this leave us?=A0 Well the first thing that should be cle= ar is that we are not facing a simple question of=A0 "Should we do it = all over HTTP alone, or also allow for implementation over XMPP?".=A0 = The design requirements aren't like that at all.=A0 In particular, HTTP= (S) just doesn't fit the Type 2 semantic requirement, and XMPP may not = either.

Given that our current task is only to define the charter and not to co= nstrain the solutions, I think that any form of wording that suggests that = HTTP(S) alone is sufficient should be avoided, because it is not sufficient= for Type 2 based on our existing experience in virtual worlds.=A0 To put i= t bluntly, it's too slow, and the polling model has inadequate latency = properties.

I suggest therefore that this question of "HTTP(S) and/or XMPP&quo= t; not be addressed in the charter, because the requirements have not yet b= een examined in sufficient detail to be able to make that call.=A0 Indeed, = Type 2 may require a different protocol altogether.


Morgaine.







On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden <infinity@lindenlab.com> wrote:
Hey people!

So... looping back around to some of the comments from the f2f BoF meeting.= ..

Original work with OGP used HTTP(S) to carry application messages.
There's been enough talk about alternate transports that it feels very<= br> bad to dismiss them without discussion. However, I'm wondering if
there's anyone out there planning on implementing OGP over XMPP?

The reason I ask is that a number of us who worked on the early
pre-IETF interop trials are heavily invested in HTTP(S). Though i
can't speak for everyone involved, i would anticipate resistance to
mandating a new transport. HTTP(S) has it's weaknesses as a transport,<= br> to be sure, but it's a well deployed and well understood protocol with<= br> a mature tool chain. This makes it attractive to many people.

On the other hand, if someone else thinks they want to produce an OGP
implementation over XMPP, that seems really cool. But if no one's
going to implement it, an argument could be made that putting the
effort into specifying it would be a waste of time. On yet another
hand, going through the exercise of figuring out what aspects of HTTP
are required to transport OGP messages might reveal subtle
dependencies between components. Back on the other hand again, can we
do this without re-writing BCP56?

So I was thinking of this as a proposal:

If there is strong interest in implementing OGP over XMPP, let's
mention that it's an "officially supported" transport in the = charter.
(for some definition of the words "officially supported.")

If there's not strong interest in implementing OGP over XMPP, let's=
not put it in the charter.

In either case, I think there's sufficient justification for
describing the set of requirements OGP makes on it's transport. For
instance, does it REQUIRE request/response semantics? (i.e. - if i'm writing a compliant server layering OGP over XMPP, and i receive an
OGP "request" in an XML stanza, am i REQUIRED to send a response?= )
Or... does it REQUIRE specific content negotiation semantics? (i.e. -
do we need to explicitly describe or reference a technique for
identifying the content type of a response in XMPP?) Or... does the
protocol explicitly depend on caching behavior of some HTTP proxies?
if so, how? etc. etc.

-sincerely
-meadhbh
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--0015174c17b4c7f6cc047108cafd-- From morgaine.dinova@googlemail.com Mon Aug 17 05:59:40 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D093A6EF3 for ; Mon, 17 Aug 2009 05:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYmaj2aJorhB for ; Mon, 17 Aug 2009 05:59:37 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 0F14228C18F for ; Mon, 17 Aug 2009 05:59:33 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so660674eye.31 for ; Mon, 17 Aug 2009 05:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=vJpL7MWpT5QJcL7I7sf7NFRjBukJGLfvEEmCdcKFLtE=; b=HhFIVEKShie80g28JtCxKAr7eVH8gDVndilPsRr39VXzNMAojdvRZRqPjsCl0v7u3F 4SwZLeOs216rGwoh3ZoapgLV/tZylkNKjr8BjrOnoePd+s2qz+Q7t9hbYzOv98SvbQ0n 0IyrItnKQV4q3PHgwag066pTfaW7jbFtipTMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=r8jv5g1UfmrBH7nsD5BQvhGUv/OtFhnVGBwevZyz5L/saGKVGxq2zki72KpWBM0v8l 0w1FLcwBJBUx4Q6YxDFrj4VJJHtJV2lH9AwaSnKCuc9+8/4G6Qgm3LecIsIRx6sf3p+h nbQW87PcWCkAxXPrMhyRn9YfyHBq+hLwMRTI0= MIME-Version: 1.0 Received: by 10.210.33.17 with SMTP id g17mr3160002ebg.79.1250513975853; Mon, 17 Aug 2009 05:59:35 -0700 (PDT) In-Reply-To: <4A74F1E4.8080209@dcrocker.net> References: <4A74F1E4.8080209@dcrocker.net> Date: Mon, 17 Aug 2009 13:59:35 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174c190e51450d047155f9a0 Subject: Re: [ogpx] Next Steps for OGPX WG Charter X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 12:59:40 -0000 --0015174c190e51450d047155f9a0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Regarding Joshua's 12 points, I think that Dave Crocker's post below addresses the issues most clearly so far, so I'll treat that as a base and fill in some details. The following brings together the common elements of points 1, 2, 4, 8 and 9, which are all descriptive and together explain "*what we're trying to do*". On Sun, Aug 2, 2009 at 2:54 AM, Dave CROCKER wrote: Joshua Bell wrote: Can mailing list participants come up with something short, accurate, educational, and catchy? You suggested: "The working group will define a protocol to support a 3-D virtual world simulation environment between users and independently operated simulation regions, and amongst those regions." This is neither as concise nor as sexy as Chris' summary, but it also lacks the proprietary reference. I think it also describes the core technical activity, as I understand the goal. I think that's fine as an introductory phrase, Dave. While it may not really explain much, that's OK as long as more detailed explanations follow it. And sexiness isn't required. :-) Indeed, the allegedly "sexy" phrase used at the BoF obscured far more than it illuminated. One or more people then suggested: For example: "The protocol produced by this working group should provide a mechanism for authenticating a client to a server, cause a user's avatar to be placed in the virtual world, move the user's avatar, receive a list of objects in the user's avatar, etc." I don't think Larry or I formulated the above sentence, and in spite of that, I quite like it... I think it's clear, direct, and contains the salient information. I like the immediate detailing of key features here, as it anchors the topic very firmly right from the beginning. However, the choice of words raises questions rather than building on prior terms and explaining them. In particular, let's avoid "placing in a virtual world", since the reader has no notion of virtual world at this point, only of regions as simulations. So, let's stick to the aforementioned "regions" and explain the words as we go, gently sliding in the notion of services, something like this: "The protocol provides mechanisms for access to regions, each of which is a virtual area or space implemented through one or more servers. Access to a region may involve authentication with an authentication service. Regions provide a 3D simulation of a shared environment that may contain avatars (3D representations of users) and 3D objects of various kinds." The above starts with "regions", explains what they are in broad physical terms to aid understanding, and in a short paragraph brings together all the main elements in the overall picture with the exception of object behaviours (scripting) and asset services. We can elaborate on those later, but first let's build upon the concepts in the preceding paragraph and make clear the demarcation between regions and clients in our protocol, because it's fundamental: "Regions perform spatial or environmental simulation of avatars and 3D objects, while the graphic rendering of avatars and 3D objects is performed within users' own client applications, commonly called *viewers*. This is a key separation in the protocol, which distinguishes it from other approaches. The combination of spatial simulation in regions and graphic rendering in clients together provides the illusion of shared virtual spaces that are commonly called *virtual worlds*." Here at last we've defined what we mean by *virtual world* based on prior terms. It's not some kind of mandated conscription of participants into a global federation (:P), but just a natural consequence of interop: it provides a unified visual mashup between graphic elements from various sources in the user's viewer, driven by the simulation in the region with added input from the user. We need to say more about objects though to make this clear, and crucially, to say what we mean by *interop*: "The current protocol is an *interoperability* protocol, in other words it provides communication between end points hosted by more than one party or organization which provide *services*. Typical services include identity, authentication and authorization, region simulation, avatar and/or asset provision (assets are the components of objects and avatars), and communication services such as instant messaging." "While a given organization may choose to implement many or all such functions itself, the protocol treats all services as decoupled for maximum flexibility. For example, a region operated by one provider may be simulating an environment in which avatars and objects originate from several different asset providers and are supplied to the user's viewer from their respective asset services." And finally, I think it's worthwhile summarizing what this interop protocol aims to do in respect of all the bits of the puzzle that we have explained above: "It is the purpose of the protocol to communicate between the user's client application and services from diverse providers, in order to deliver the experience of interoperating virtual worlds to the end user." Hopefully this kind of progressive explanation can provide the desired level of readability for the descriptive part of a good charter, while at the same time mentioning all the required elements and defining what we mean by interop. I've purposely left out object behaviours or scripting as it is a complex topic and would probably detract from an otherwise easily readable charter. Putting those snippets together, we get the following description: "The working group will define a protocol to support a 3-D virtual world simulation environment between users and independently operated simulation regions, and amongst those regions." "The protocol provides mechanisms for access to regions, each of which is a virtual area or space implemented through one or more servers. Access to a region may involve authentication with an authentication service. Regions provide a 3D simulation of a shared environment that may contain avatars (3D representations of users) and 3D objects of various kinds." "Regions perform spatial or environmental simulation of avatars and 3D objects, while the graphic rendering of avatars and 3D objects is performed within users' own client applications, commonly called *viewers*. This is a key separation in the protocol, which distinguishes it from other approaches. The combination of spatial simulation in regions and graphic rendering in clients together provides the illusion of shared virtual spaces that are commonly called *virtual worlds*." "The current protocol is an *interoperability* protocol, in other words it provides communication between end points hosted by more than one party or organization which provide *services*. Typical services include identity, authentication and authorization, region simulation, avatar and/or asset provision (assets are the components of objects and avatars), and communication services such as instant messaging." "While a given organization may choose to implement many or all such functions itself, the protocol treats all services as decoupled for maximum flexibility. For example, a region operated by one provider may be simulating an environment in which avatars and objects originate from several different asset providers and are supplied to the user's viewer from their respective asset services." "It is the purpose of the protocol to communicate between the user's client application and services from diverse providers, in order to deliver the experience of interoperating virtual worlds to the end user." For the high complexity of what we're trying to achieve, that seems to combine good coverage and readability, defines interop, and limits the scope to our particular worlds model. Comments? Morgaine. ======================================== On Sun, Aug 2, 2009 at 2:54 AM, Dave CROCKER wrote: > > Joshua, > > g'day. > > > This latest draft is indeed very much better! > > > Joshua Bell wrote: >> >> 1. Include a succinct but realistic summary of what the problem space and protocol are. At the BOF, Chris Newman made the comment "The impression I've got is this is a 3-D multi-vendor Facebook. I think that's really cool." (thanks, Chris!). This really helped BOF participants unfamiliar with VWs understand what the heck we were talking about. >> >> Can mailing list participants come up with something short, accurate, educational, and catchy? > > "The working group will define a protocol to support a 3-D virtual world > simulation environment between users and independently operated simulation > regions, and amongst those regions." > > This is neither as concise nor as sexy as Chris' summary, but it also lacks the > proprietary reference. (Perhaps the social networking usage aspect, however, needs to be included? But then, I'm not clear how the protocol work mandates that usage.) I think is also describes the core technical activity, as I understand the goal. That presumes that I understand it correctly... > > >> For example: "The protocol produced by this working group should provide a mechanism for authenticating a client to a server, cause a user's avatar to be placed in the virtual world, move the user's avatar, receive a list of objects in the user's avatar, etc." > > I don't think Larry or I formulated the above sentence, and in spite of that, I > quite like it... I think it's clear, direct, and contains the salient information. > > >> 3. The text of the charter should have a clear list of working group deliverables. > > The current draft does not specify what existing documents it is drawing from, > what it will/might/must do with them, nor what the limits on modification to those documents are -- if any. > >> The "what is needed" slide from the OGPX Draft Charter Issues presentation ( http://www.ietf.org/proceedings/75/slides/ogpx-2.pdf) was mentioned as a possible source for this list for both (2) and (3), but needs massaging: >> >> (a) a security model describing trust relationships between hosts, >> (b) guidelines for the use of existing authentication & confidentiality mechanisms, >> (c) mechanisms for: >> (i) establishing the user's presence in the virtual world >> (ii) moving a user's presence from one authoritative host to another, >> (iii) for identifying agents, and requesting information about them. >> (d) format descriptions for objects and avatars in a virtual world, > > For c.ii should it really be 'host' or is it actually 'region'? Also, the use of 'authoritative' implies there can non-authoritative hosts. Is that correct? > > As for what might be missing, I'm not seeing any semantics cited for any actions other than defining and moving users. Nothing about simulation activity. > > >> Are there any other suggestions, preferences, or vetos? Does the proposed protocol name need to be reflected in a revised Working Group name? > > They certainly don't have to be the same, but they do need to be useful, of course. > >> 7. Explicitly list extant drafts which will be the starting point for the WG effort: >> >> * http://tools.ietf.org/html/draft-hamrick-ogp-intro >> * http://tools.ietf.org/html/draft-hamrick-llsd-00 >> * http://tools.ietf.org/html/draft-hamrick-ogp-auth >> * http://tools.ietf.org/html/draft-hamrick-ogp-launch >> * http://tools.ietf.org/html/draft-lentczner-ogp-base >> * http://tools.ietf.org/html/draft-levine-ogp-clientcap >> * http://tools.ietf.org/html/draft-levine-ogp-layering >> >> Is this list complete and accurate? > > Since these document represent a substantial history, it really is important for the charter to cite them explicitly and specify how maleable their content is. "Starting point" could mean that the final result has no visible relationship to these documents and that they merely used for initial discussion. As I've noted earlier, I am pretty sure you folks want more constraints than that. Whatever you choose, it's likely to be a point of negotiation with the IESG, but you should state what role these docs are expected/required to play. > > >> 8. The protocols are intended to provide a clear seperation of concerns between mechanisms used to access resources and policies controlling use of those mechanisms. Many deployment choices will be defined by policy, not protocol. This needs to be clear in the charter. > > yup! > > >> 9. Ensure that while the charter scopes down the Virtual World problem space, it does it in an inclusive way rather than focusing on what is out of scope and thus indecipherable to non-subject matter experts. It is expected that output of the WG may be useful in scenarios beyond those specifically under consideration, much as RFC 2068 is not simply used for hypertext. > > This type of goal is often present, but I'm pretty sure I've never seen any chartering text about it that had any meaning or any impact. For example, what objective criteria could the IESG apply during document approval, to tell whether the goal has been satisfied? > > >> 10. Remove references to "wire" in "wire protocol"; this is implicit in the scope of work for IETF. The phrase "application-layer protocol" (as distinct from a novel transport-layer protocol) is accurate and sufficient. > > Yes, but I'll also vote for removing "application-layer". I now understand that it's meant to imply that it's above transport, but there's already specific language about using transports. > > No, this isn't a big deal, but in spite of primarily being as apps guy, I think removing the phrase makes the text cleaner, with no loss of meaning. > > >> 11. Add text specifying: The WG will define interfaces for a set of HTTP-based services ("web services") but not provide language specific bindings ("API") onto those services. > > Huh? What's this about? Sounds like the working group is going to do web enhancements, rather than virtual world simulation. > > >> 12. Clarify the charter that we're explicitly targetting HTTP as the default transport. >> >> A concern was raised that reusing HTTP will lead to unnecessary and tight coupling with that protocol's capabilities and semantics; a suggestion was made that if we wish to state that the protocols will be transport-neutral, the WG will investigate at least one other transport. Should we just target HTTP, or make the effort? > > If transport-independence is claimed, the claim won't really be meaningful unless at least two different transport mappings are provided. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx --0015174c190e51450d047155f9a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Regarding Joshua's 12 points, I think that Dave Crocker's post belo= w addresses the issues most clearly so far, so I'll treat that as a bas= e and fill in some details.=A0 The following brings together the common ele= ments of points 1, 2, 4, 8 and 9, which are all descriptive and together ex= plain "what we're trying to do".


On Sun, Aug 2, 2009 at 2:54 AM, Dave CROCKER <dhc@dcrocker.net> wrote:

Joshua Bell wrote:

Can mailing list participants come up with something short, accurate, educ= ational, and catchy?

You suggested:

= =A0 "The working group will define a protocol to support a 3-D virtual= world
simulation environment between users and independently operated s= imulation regions, and amongst those regions."

This is neither as concise nor as sexy as Chris' summary, but it al= so lacks the proprietary reference. I think it also describes the core tech= nical activity, as I understand the goal.


I think that'= ;s fine as an introductory phrase, Dave. While it may not really explain mu= ch, that's OK as long as more detailed explanations follow it.=A0 And s= exiness isn't required. :-)=A0 Indeed, the allegedly "sexy" p= hrase used at the BoF obscured far more than it illuminated.

One or more people then suggested:

For example: "The protocol produced by this working group should = provide a mechanism for authenticating a client to a server, cause a user&#= 39;s avatar to be placed in the virtual world, move the user's avatar, = receive a list of objects in the user's avatar, etc."

I don't think Larry or I formulated the above sentence, and in spit= e of that, I
quite like it... =A0I think it's clear, direct, and con= tains the salient information.


I like the immediate detail= ing of key features here, as it anchors the topic very firmly right from th= e beginning.=A0 However, the choice of words raises questions rather than b= uilding on prior terms and explaining them.=A0 In particular, let's avo= id "placing in a virtual world", since the reader has no notion o= f virtual world at this point, only of regions as simulations.=A0 So, let&#= 39;s stick to the aforementioned "regions" and explain the words = as we go, gently sliding in the notion of services, something like this:
"The protocol provides mechanism= s for access to regions, each of which is a virtual area or space implement= ed through one or more servers.=A0 Access to a region may involve authentic= ation with an authentication service.=A0 Regions provide a 3D simulation of= a shared environment that may contain avatars (3D representations of users= ) and 3D objects of various kinds."

The above starts with "regions", explains what they are= in broad physical terms to aid understanding, and in a short paragraph bri= ngs together all the main elements in the overall picture with the exceptio= n of object behaviours (scripting) and asset services.=A0 We can elaborate = on those later, but first let's build upon the concepts in the precedin= g paragraph and make clear the demarcation between regions and clients in o= ur protocol, because it's fundamental:

"Regions perform spatial or envi= ronmental simulation of avatars and 3D objects, while the graphic rendering= of avatars and 3D objects is performed within users' own client applic= ations, commonly called viewers.=A0 This is a key separation in the = protocol, which distinguishes it from other approaches.=A0 The combination = of spatial simulation in regions and graphic rendering in clients together = provides the illusion of shared virtual spaces that are commonly called = virtual worlds."

Here at last we've defined what we mean by virtual world based on prior terms.=A0 It's not some kind of mandated conscription= of participants into a global federation (:P), but just a natural conseque= nce of interop:=A0 it provides a unified visual mashup between graphic elem= ents from various sources in the user's viewer, driven by the simulatio= n in the region with added input from the user.=A0 We need to say more abou= t objects though to make this clear, and crucially, to say what we mean by = interop:

"The current protocol is an i= nteroperability protocol, in other words it provides communication betw= een end points hosted by more than one party or organization which provide = services.=A0 Typical services include identity, authentication and a= uthorization, region simulation, avatar and/or asset provision (assets are = the components of objects and avatars), and communication services such as = instant messaging."

"While a given organizatio= n may choose to implement many or all such functions itself, the protocol t= reats all services as decoupled for maximum flexibility.=A0 For example, a = region operated by one provider may be simulating an environment in which a= vatars and objects originate from several different asset providers and are= supplied to the user's viewer from their respective asset services.&qu= ot;

And finally, I think it's worthwhile summarizing what this in= terop protocol aims to do in respect of all the bits of the puzzle that we = have explained above:

"It is = the purpose of the protocol to communicate between the user's client ap= plication and services from diverse providers, in order to deliver the expe= rience of interoperating virtual worlds to the end user."

Hopefully this kind of progressive explanation can provide the de= sired level of readability for the descriptive part of a good charter, whil= e at the same time mentioning all the required elements and defining what w= e mean by interop.

=A0I've purposely left out object behaviours or scripting as it is = a complex topic and would probably detract from an otherwise easily readabl= e charter.


Putting those snippets together, we get the following= description:


"The working group will defi= ne a protocol to support a 3-D virtual world
simulation environment between users and independently operated simulation = regions, and amongst those regions."

"The protocol provides mechanisms fo= r access to regions, each of which is a virtual area or space implemented through one or more servers.=A0 Access to a region may involve authentication with an authentication service.=A0 Regions provide a 3D simulation of a shared environment that may contain avatars (3D representations of users) and 3D objects of various kinds."

"Regions perform spatial or environmental simulation of avatars and 3D objects, while the graphic rendering of avatars and 3D objects is performed within users' own client applications, commonly called viewers.=A0 This is a key separation in the protocol, which distinguishes it from other approaches.=A0 The combination of spatial simulation in regions and graphic rendering in clients together provides the illusion of shared virtual spaces that are commonly called virtual worlds."

"The current protocol is an inter= operability protocol, in other words it provides communication between end points hosted by more than one party or organization which provide services= .=A0 Typical services include identity, authentication and authorization, region simulation, avatar and/or asset provision (assets are the components of objects and avatars), and communication services such as instant messaging."

"While a given organization may choo= se to implement many or all such functions itself, the protocol treats all services as decoupled for maximum flexibility.=A0 For example, a region operated by one provider may be simulating an environment in which avatars and objects originate from several different asset providers and are supplied to the user's viewer from their respective asset services."

"It is the purpose of the protocol t= o communicate between the user's client application and services from diverse providers, in order to deliver the experience of interoperating virtual worlds to the end user."


For the high complexity of what we're trying to achieve, that s= eems to combine good coverage and readability, defines interop, and limits = the scope to our particular worlds model.=A0 Comments?


Morgaine.=

=A0




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Sun, Aug 2, 2009 at 2:54 AM, Dave CROCKER <dhc@dcrocker.net> wrote:
>
> Joshua,
&= gt;
> g'day.
>
>
> This latest draft is indeed very mu= ch better!
>
>
> Joshua Bell wrote:
>>
>&g= t; 1. Include a succinct but realistic summary of what the problem space an= d protocol are. At the BOF, Chris Newman made the comment "The impress= ion I've got is this is a 3-D multi-vendor Facebook. I think that's= really cool." (thanks, Chris!). This really helped BOF participants u= nfamiliar with VWs understand what the heck we were talking about.
>>
>> Can mailing list participants come up with something s= hort, accurate, educational, and catchy?
>
> =A0 "The work= ing group will define a protocol to support a 3-D virtual world
> sim= ulation environment between users and independently operated simulation
> regions, and amongst those regions."
>
> This is neit= her as concise nor as sexy as Chris' summary, but it also lacks the
= > proprietary reference. =A0(Perhaps the social networking usage aspect,= however, needs to be included? But then, I'm not clear how the protoco= l work mandates that usage.) =A0I think is also describes the core technica= l activity, as I understand the goal. =A0That presumes that I understand it= correctly...
>
>
>> =A0 For example: "The protocol produced by th= is working group should provide a mechanism for authenticating a client to = a server, cause a user's avatar to be placed in the virtual world, move= the user's avatar, receive a list of objects in the user's avatar,= etc."
>
> I don't think Larry or I formulated the above sentence, an= d in spite of that, I
> quite like it... =A0I think it's clear, d= irect, and contains the salient information.
>
>
>> 3.= The text of the charter should have a clear list of working group delivera= bles.
>
> The current draft does not specify what existing documents it = is drawing from,
> what it will/might/must do with them, nor what the= limits on modification to those documents are -- if any.
>
>&g= t; The "what is needed" slide from the OGPX Draft Charter Issues = presentation ( http://www.ietf.org/proceedings/75/slides/ogpx-2.pdf) was mentione= d as a possible source for this list for both (2) and (3), but needs massag= ing:
>>
>> (a) a security model describing trust relationships be= tween hosts,
>> (b) guidelines for the use of existing authenticat= ion & confidentiality mechanisms,
>> (c) mechanisms for:
>> =A0(i) establishing the user's presence in the virtual world>> =A0(ii) moving a user's presence from one authoritative host= to another,
>> =A0(iii) for identifying agents, and requesting in= formation about them.
>> (d) format descriptions for objects and avatars in a virtual world= ,
>
> For c.ii should it really be 'host' or is it actu= ally 'region'? =A0Also, the use of 'authoritative' implies = there can non-authoritative hosts. =A0Is that correct?
>
> As for what might be missing, I'm not seeing any semantics= cited for any actions other than defining and moving users. =A0Nothing abo= ut simulation activity.
>
>
>> Are there any other sug= gestions, preferences, or vetos? Does the proposed protocol name need to be= reflected in a revised Working Group name?
>
> They certainly don't have to be the same, but they do need= to be useful, of course.
>
>> 7. Explicitly list extant dra= fts which will be the starting point for the WG effort:
>>
>> * h= ttp://tools.ietf.org/html/draft-hamrick-ogp-intro
>> * http://tools.ietf.org= /html/draft-hamrick-llsd-00
>> * ht= tp://tools.ietf.org/html/draft-hamrick-ogp-auth
>> * http://tools.ietf.= org/html/draft-hamrick-ogp-launch
>> * = http://tools.ietf.org/html/draft-lentczner-ogp-base
>> * http://tools.i= etf.org/html/draft-levine-ogp-clientcap
>> * http://tools.ietf.org/html/draft-levine-ogp-layering
>>
&g= t;> Is this list complete and accurate?
>
> Since these docu= ment represent a substantial history, it really is important for the charte= r to cite them explicitly and specify how maleable their content is. "= Starting point" could mean that the final result has no visible relati= onship to these documents and that they merely used for initial discussion.= As I've noted earlier, I am pretty sure you folks want more constraint= s than that. =A0Whatever you choose, it's likely to be a point of negot= iation with the IESG, but you should state what role these docs are expecte= d/required to play.
>
>
>> 8. The protocols are intended to provide a clear s= eperation of concerns between mechanisms =A0used to access resources and po= licies controlling use of those mechanisms. Many deployment choices will be= defined by policy, not protocol. This needs to be clear in the charter. >
> yup!
>
>
>> 9. Ensure that while the char= ter scopes down the Virtual World problem space, it does it in an inclusive= way rather than focusing on what is out of scope and thus indecipherable t= o non-subject matter experts. It is expected that output of the WG may be u= seful in scenarios beyond those specifically under consideration, much as R= FC 2068 is not simply used for hypertext.
>
> This type of goal is often present, but I'm pretty sure I&= #39;ve never seen any chartering text about it that had any meaning or any = impact. =A0For example, what objective criteria could the IESG apply during= document approval, to tell whether the goal has been satisfied?
>
>
>> 10. Remove references to "wire" in "= ;wire protocol"; this is implicit in the scope of work for IETF. The p= hrase "application-layer protocol" (as distinct from a novel tran= sport-layer protocol) is accurate and sufficient.
>
> Yes, but I'll also vote for removing "application-lay= er". =A0I now understand that it's meant to imply that it's ab= ove transport, but there's already specific language about using transp= orts.
>
> No, this isn't a big deal, but in spite of primarily being= as apps guy, I think removing the phrase makes the text cleaner, with no l= oss of meaning.
>
>
>> 11. Add text specifying: The WG= will define interfaces for a set of HTTP-based services ("web service= s") but not provide language specific bindings ("API") onto = those services.
>
> Huh? =A0What's this about? =A0Sounds like the working grou= p is going to do web enhancements, rather than virtual world simulation.>
>
>> 12. Clarify the charter that we're explicitly= targetting HTTP as the default transport.
>>
>> A concern was raised that reusing HTTP will lead to un= necessary and tight coupling with that protocol's capabilities and sema= ntics; a suggestion was made that if we wish to state that the protocols wi= ll be transport-neutral, the WG will investigate at least one other transpo= rt. Should we just target HTTP, or make the effort?
>
> If transport-independence is claimed, the claim won't real= ly be meaningful unless at least two different transport mappings are provi= ded.
>
> d/
> --
>
> =A0Dave Crocker
> = =A0Brandenburg InternetWorking
> =A0bbiw.net
>
> __________= _____________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/o= gpx

--0015174c190e51450d047155f9a0-- From alexey.melnikov@isode.com Mon Aug 17 07:31:40 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F7C3A6E28 for ; Mon, 17 Aug 2009 07:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9laLAbWZ94C for ; Mon, 17 Aug 2009 07:31:39 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 7C5913A6853 for ; Mon, 17 Aug 2009 07:31:39 -0700 (PDT) Received: from [172.16.2.123] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 17 Aug 2009 15:31:43 +0100 Message-ID: <4A8969BB.7010603@isode.com> Date: Mon, 17 Aug 2009 15:31:23 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Infinity Linden References: <4A74F1E4.8080209@dcrocker.net> <3a880e2c0908031112g4813a46bx3e4edfdb76119926@mail.gmail.com> In-Reply-To: <3a880e2c0908031112g4813a46bx3e4edfdb76119926@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org, dcrocker@bbiw.net Subject: Re: [ogpx] Next Steps for OGPX WG Charter X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 14:31:40 -0000 Infinity Linden wrote: >On Sat, Aug 1, 2009 at 6:54 PM, Dave CROCKER wrote: > >[stuff removed] > > [even more stuff removed] >>>3. The text of the charter should have a clear list of working group >>>deliverables. >>> >>The current draft does not specify what existing documents it is drawing >>from, >>what it will/might/must do with them, nor what the limits on modification to >>those documents are -- if any. >> >> > >hmm... i had thought i had some advice from someone to remove the list >of drafts we're basing the current definition of "the protocol >formerly known as OGP." but for the record... we have two sets of >documents: first, the internet drafts that have been circulating over >the last 6 months or so. the list of these drafts is on the mailing >list and at http://wiki.secondlife.com/wiki/User:Infinity_Linden/IETF_Drafts_and_Meetings >. second, are the previous wiki pages from last summer's interop work. >the IETF drafts were distillations of what we learned from the work >last summer. they're supposed to reflect the state of the protocol >that was actually deployed last summer. > Frequently WG Charters contain a list of documents used as the starting point. This helps to emphasize that you are not starting from scratch. >also... are we really going to have the "what are the limits on IETF >modification?" discussion again? > I don't think we need to have this discussion again, we just need to document what you and others said several times. This is one of the things that both IESG and IAB will be asking about, because disagreement on which changes can and can't be done lead to failure of multiple WGs that tried to bring in work to IETF. [...] >>>9. Ensure that while the charter scopes down the Virtual World problem >>>space, it does it in an inclusive way rather than focusing on what is out of >>>scope and thus indecipherable to non-subject matter experts. It is expected >>>that output of the WG may be useful in scenarios beyond those specifically >>>under consideration, much as RFC 2068 is not simply used for hypertext. >>> >>This type of goal is often present, but I'm pretty sure I've never seen any >>chartering text about it that had any meaning or any impact. For example, >>what objective criteria could the IESG apply during document approval, to >>tell whether the goal has been satisfied? >> >hmm. are you implying that the IESG will get upset if our work product >is used for something other than virtual world simulation? > To answer this specific question: unlikely. >i don't >think you are. i fear that turning the charter into a feature list of >virtual worlds isn't the answer either (though it would make it easier >to verify.) > > IESG is frequently looking at charters to verify if WGs produced what they promised to produce. A mismatch between the charter text and end result might be a symptom of a trouble. Of course it doesn't mean that the charter needs to document every restriction. The group might not know or might not agree on them before starting work. Does this help? From meadhbh.siobhan@gmail.com Mon Aug 17 07:41:00 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC853A6F0C for ; Mon, 17 Aug 2009 07:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8ATpkFYZEGv for ; Mon, 17 Aug 2009 07:40:58 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id E34B73A6DAF for ; Mon, 17 Aug 2009 07:40:56 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so874453anc.4 for ; Mon, 17 Aug 2009 07:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zycnoCybyPYH9xce1uhQ48BkTvgqH40k6H0B7Fj3B4o=; b=Tgu/kg2dNxdtD0IqIT3GTWjxCJCdy6QAVQAQ1a+Jbz5CATRnpdUeHzl3fLS2p+8UcL ruSYYeYCDXQ1qZI7XvQiiYQO+76psTrSUWMk8GsL82NfWiy71XAO4bKxtJxlGQ+pVMxV QbWSQ2zi6CopaWlpv05lc5G5xXOefIFWmNw6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LdEtOxiz0HemTVDkXjr5CiOCxEmEczr6J/GI7zr6/kstBZzdRZz7X0+tN2bzLtUVQQ TbqgozgzBTsv27pFFb29wDQQ58U6aTLMeQxNL0GAaBpbuNr2hKksDxrAUghBy8M1ZnO7 TRROFua31hFaldP0xSNKg9ORz3R9LDi9gocoI= MIME-Version: 1.0 Received: by 10.100.192.10 with SMTP id p10mr3421831anf.164.1250520055395; Mon, 17 Aug 2009 07:40:55 -0700 (PDT) In-Reply-To: <4A8969BB.7010603@isode.com> References: <4A74F1E4.8080209@dcrocker.net> <3a880e2c0908031112g4813a46bx3e4edfdb76119926@mail.gmail.com> <4A8969BB.7010603@isode.com> Date: Mon, 17 Aug 2009 07:40:55 -0700 Message-ID: From: Meadhbh Siobhan To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Infinity Linden , ogpx@ietf.org, dcrocker@bbiw.net Subject: Re: [ogpx] Next Steps for OGPX WG Charter X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 14:41:00 -0000 k. thx for the info. especially the last bit about people comparing goals and achievements. On Mon, Aug 17, 2009 at 7:31 AM, Alexey Melnikov wrote: > Infinity Linden wrote: > >> On Sat, Aug 1, 2009 at 6:54 PM, Dave CROCKER wrote: >> >> [stuff removed] >> > > [even more stuff removed] > >>>> 3. The text of the charter should have a clear list of working group >>>> deliverables. >>> >>> The current draft does not specify what existing documents it is drawin= g >>> from, >>> what it will/might/must do with them, nor what the limits on modificati= on >>> to >>> those documents are -- if any. >>> >> >> hmm... i had thought i had some advice from someone to remove the list >> of drafts we're basing the current definition of "the protocol >> formerly known as OGP." but for the record... we have two sets of >> documents: first, the internet drafts that have been circulating over >> the last 6 months or so. the list of these drafts is on the mailing >> list and at >> http://wiki.secondlife.com/wiki/User:Infinity_Linden/IETF_Drafts_and_Mee= tings >> . second, are the previous wiki pages from last summer's interop work. >> the IETF drafts were distillations of what we learned from the work >> last summer. they're supposed to reflect the state of the protocol >> that was actually deployed last summer. >> > Frequently WG Charters contain a list of documents used as the starting > point. This helps to emphasize that you are not starting from scratch. > >> also... are we really going to have the "what are the limits on IETF >> modification?" discussion again? >> > I don't think we need to have this discussion again, we just need to > document what you and others said several times. > > This is one of the things that both IESG and IAB will be asking about, > because disagreement on which changes can and can't be done lead to failu= re > of multiple WGs that tried to bring in work to IETF. > [...] > >>>> 9. Ensure that while the charter scopes down the Virtual World problem >>>> space, it does it in an inclusive way rather than focusing on what is >>>> out of >>>> scope and thus indecipherable to non-subject matter experts. It is >>>> expected >>>> that output of the WG may be useful in scenarios beyond those >>>> specifically >>>> under consideration, much as RFC 2068 is not simply used for hypertext= . >>>> >>> >>> This type of goal is often present, but I'm pretty sure I've never seen >>> any >>> chartering text about it that had any meaning or any impact. =A0For >>> example, >>> what objective criteria could the IESG apply during document approval, = to >>> tell whether the goal has been satisfied? >>> >> hmm. are you implying that the IESG will get upset if our work product >> is used for something other than virtual world simulation? >> > To answer this specific question: unlikely. > >> i don't >> think you are. i fear that turning the charter into a feature list of >> virtual worlds isn't the answer either (though it would make it easier >> to verify.) >> > > IESG is frequently looking at charters to verify if WGs produced what the= y > promised to produce. > A mismatch between the charter text and end result might be a symptom of = a > trouble. > > Of course it doesn't mean that the charter needs to document every > restriction. The group might not know or might not agree on them before > starting work. > > Does this help? > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From yesha.sivan@gmail.com Mon Aug 17 08:17:11 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB54E3A6961 for ; Mon, 17 Aug 2009 08:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.117 X-Spam-Level: X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W81C7j6Yw7PI for ; Mon, 17 Aug 2009 08:17:10 -0700 (PDT) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by core3.amsl.com (Postfix) with ESMTP id 6EE353A672E for ; Mon, 17 Aug 2009 08:17:10 -0700 (PDT) Received: by bwz2 with SMTP id 2so2226181bwz.43 for ; Mon, 17 Aug 2009 08:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=HIdt78MIC5bFZCU8NtEuRIXSgdkbq9LKKOrPAj6VqcM=; b=W0mJk+pubnhgPBZHz54r6ldQhYfLusdKZwXrTnA/uZmL5S0tJ/jBY5Efz0KHl2yOmr hEo7qxPlA9gPsIDj1Ww2x8FD4h/p+qUnSmtLvrgapUNUGFrvIIc9ASPA8FmHsRWzIgIj JhnUEYsMSZMXDOkupNKwnrsZL796bfvxB8Vxs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=w++NZCZWSv6iUISekCKKr0sYgZDCmOY/u4YI8Tu5z4P8o3KPmupwGLfxU9IzPz22YT PfrSqH+NhIjsD6rl/z1nEO65oR+BmefV4aMtFspvrJWExOccx6EbiF6xLv/1LOwjIWZ5 5yzS6SN7UtRQs9pFStp8gNWtT7q8M1okIT/Zg= MIME-Version: 1.0 Sender: yesha.sivan@gmail.com Received: by 10.103.50.22 with SMTP id c22mr1370472muk.54.1250522230136; Mon, 17 Aug 2009 08:17:10 -0700 (PDT) In-Reply-To: <20090730.000748.17075.0@webmail02.vgs.untd.com> References: <20090730.000748.17075.0@webmail02.vgs.untd.com> From: Yesha Sivan Date: Mon, 17 Aug 2009 11:16:50 -0400 X-Google-Sender-Auth: b2066ef572acbc01 Message-ID: <3e3ef2f00908170816v20cc5567n5b5f503d45a69534@mail.gmail.com> To: "dyerbrookme@juno.com" Content-Type: multipart/alternative; boundary=0016e659f4024f9ec0047157e56a Cc: infinity@lindenlab.com, ogpx@ietf.org, dcrocker@bbiw.net Subject: Re: [ogpx] the term 'grid' X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 15:17:11 -0000 --0016e659f4024f9ec0047157e56a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you want to use "grid" ... then use "cloud" grid is so 2007.... [ this will connect this with the latest trends... which will be appealing for CXO level decisions) and good work Infinity on presenting in SLCC --Yesha Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Virtual Worlds. On Thu, Jul 30, 2009 at 12:07 AM, dyerbrookme@juno.com wrote: > Linden Lab has trademarked the term "Second Life Grid". > http://secondlife.com/corporate/brand/trademark/tm_chart.php > > Second Life Grid=E2=84=A2 > SL Grid=E2=84=A2 > Second Life Grid logo=E2=84=A2 > > and noted that the generic nouns are: > > development platform > platform > technology > > Prokofy Neva > > ____________________________________________________________ > Massage Therapy Schools > Find schools near you offering Massage Therapy programs - fast! > > http://thirdpartyoffers.juno.com/TGL2141/c?cp=3D8gNe58JXrvpPUxECXTyMLgAAJ= 1BAkQUOY6racJgsKTPwXVdzAAUAAAAAAAAAAL4wWT2wNKEGB0jW5tSexiXGVqQqAAAAAA=3D=3D > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0016e659f4024f9ec0047157e56a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you want to use "grid" ... then use "cloud" =C2=A0gr= id is so 2007.... [ this will connect this with the latest trends... which = will be=C2=A0appealing=C2=A0for CXO level decisions)

and= good work Infinity on=C2=A0presenting=C2=A0in SLCC

--Yesha
Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Vi= rtual Worlds.


On Thu, Jul 30, 2009 at 12:07 AM, dyerbrookme@juno.com <dyerbrookme@juno.com><= /span> wrote:
Linden Lab has trademarked the term "S= econd Life Grid".
http://secondlife.com/corporate/brand/trademark/tm_chart.ph= p

Second Life Grid=E2=84=A2
SL Grid=E2=84=A2
Second Life Grid logo=E2=84=A2

and noted that the generic nouns are:

development platform
platform
technology

Prokofy Neva

____________________________________________________________
Massage Therapy Schools
Find schools near you offering Massage Therapy programs - fast!
http://thirdpartyoffers.juno.com/TGL2141/c?cp= =3D8gNe58JXrvpPUxECXTyMLgAAJ1BAkQUOY6racJgsKTPwXVdzAAUAAAAAAAAAAL4wWT2wNKEG= B0jW5tSexiXGVqQqAAAAAA=3D=3D
_________________________________________= ______
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--0016e659f4024f9ec0047157e56a-- From infinity@lindenlab.com Mon Aug 17 09:11:11 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5A63A68D2 for ; Mon, 17 Aug 2009 09:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUc9wXo+qozn for ; Mon, 17 Aug 2009 09:11:10 -0700 (PDT) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by core3.amsl.com (Postfix) with ESMTP id 76BA33A69CB for ; Mon, 17 Aug 2009 09:11:10 -0700 (PDT) Received: by fxm22 with SMTP id 22so2754799fxm.9 for ; Mon, 17 Aug 2009 09:11:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.145.3 with SMTP id b3mr900835fav.67.1250525472748; Mon, 17 Aug 2009 09:11:12 -0700 (PDT) In-Reply-To: <3e3ef2f00908170816v20cc5567n5b5f503d45a69534@mail.gmail.com> References: <20090730.000748.17075.0@webmail02.vgs.untd.com> <3e3ef2f00908170816v20cc5567n5b5f503d45a69534@mail.gmail.com> Date: Mon, 17 Aug 2009 09:11:12 -0700 Message-ID: <3a880e2c0908170911s2d655cf5m69fac6e8d8a0e2e1@mail.gmail.com> From: Infinity Linden To: Yesha Sivan Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org, dcrocker@bbiw.net, "dyerbrookme@juno.com" Subject: Re: [ogpx] the term 'grid' X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 16:11:11 -0000 fwiw... a little history on the term "grid." inside linden it's used to define the geometry of the virtual world and the collection of machines it's deployed on. "cloud" wasn't yet popular when second life was launched, so you got the name "grid." when the interop work last summer kicked off, the people participating were serious SL-heads (meaning second life was the virtual world we had foremost in our minds.) so when the "Open Grid Protocol" got it's name, the emphasis was on "open" and not "grid." after all... in that community, we all knew what "grid" implied. but now we're hoping to move beyond that community, so yeah, we have to take into account the fact that there are people out there that haven't been eating and sleeping SL-style virtual worlds for the last five-six years, and might have a different understanding of the terms "grid" and "cloud." ultimately, the protocol we're defining could be deployed on a grid, a cluster, in a cloud, or on a single host (thought the latter would probably be a small world.) can i ask though.. can we simply agree that we need more discussion on the name, and delay discussion until the substantive issues of the draft charter are resolved? in other words, as we start pushing charter drafts out, please don't freak out if we still have OGPX and OGP in them. they're just placeholders for whatever name we all agree on in the future. -cheers -meadhbh On Mon, Aug 17, 2009 at 8:16 AM, Yesha Sivan wrote: > If you want to use "grid" ... then use "cloud" =A0grid is so 2007.... [ t= his > will connect this with the latest trends... which will be=A0appealing=A0f= or CXO > level decisions) > and good work Infinity on=A0presenting=A0in SLCC > --Yesha > Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Virtual > Worlds. > > > On Thu, Jul 30, 2009 at 12:07 AM, dyerbrookme@juno.com > wrote: >> >> Linden Lab has trademarked the term "Second Life Grid". >> http://secondlife.com/corporate/brand/trademark/tm_chart.php >> >> Second Life Grid=99 >> SL Grid=99 >> Second Life Grid logo=99 >> >> and noted that the generic nouns are: >> >> development platform >> platform >> technology >> >> Prokofy Neva >> >> ____________________________________________________________ >> Massage Therapy Schools >> Find schools near you offering Massage Therapy programs - fast! >> >> http://thirdpartyoffers.juno.com/TGL2141/c?cp=3D8gNe58JXrvpPUxECXTyMLgAA= J1BAkQUOY6racJgsKTPwXVdzAAUAAAAAAAAAAL4wWT2wNKEGB0jW5tSexiXGVqQqAAAAAA=3D= =3D >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > From meadhbh.siobhan@gmail.com Mon Aug 17 09:44:58 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E42628C1B4 for ; Mon, 17 Aug 2009 09:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oehJcFU4+F5q for ; Mon, 17 Aug 2009 09:44:57 -0700 (PDT) Received: from mail-yx0-f173.google.com (mail-yx0-f173.google.com [209.85.210.173]) by core3.amsl.com (Postfix) with ESMTP id 2B0A628C2AA for ; Mon, 17 Aug 2009 09:44:36 -0700 (PDT) Received: by yxe3 with SMTP id 3so4073290yxe.29 for ; Mon, 17 Aug 2009 09:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kUGgQNXZCBkb9lhAOmCnzzVu47CuB3JZ9v5czZ74des=; b=a+e3IUrUEBhNrIj1D7/JjP4hcKvW23A5wKLQtRlW02OFSuPBMwoK57DtRZCsagvuYV +fA8Bj2LVD9MmwIdjzLIs0b1rtlTQA1PI6PVx1adGMABawZQXO1t19ZjoKm/ZcxEsBhp MU276ZTCbRo8F02zwvg3cE88ZsdkA3pY/+Pv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PF/lvpG5m7wyiNitq0cnK1eSU6FFiEDgAvIqnBLlDMnGOBOUcH4pppRWcupef2/IPX US5PayuddrznqZmgBGIpTz92Oo5vV+iQ6XFlu9k90KOwnCCWv/raDQR0qvq/P/EO379P IF/1hFpOrFan5RvhichXBn8uN5HDIMIpI9bZw= MIME-Version: 1.0 Received: by 10.101.55.7 with SMTP id h7mr3629957ank.116.1250527478289; Mon, 17 Aug 2009 09:44:38 -0700 (PDT) In-Reply-To: References: <3a880e2c0908121753s34bacba7k59fae708752d3d6a@mail.gmail.com> Date: Mon, 17 Aug 2009 09:44:38 -0700 Message-ID: From: Meadhbh Siobhan To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] HTTP(S) and XMPP as transports of OGP application layer messages X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 16:44:58 -0000 On Thu, Aug 13, 2009 at 9:54 AM, Morgaine w= rote: > On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden > wrote: >> >> Original work with OGP used HTTP(S) to carry application messages. >> There's been enough talk about alternate transports that it feels very >> bad to dismiss them without discussion. However, I'm wondering if >> there's anyone out there planning on implementing OGP over XMPP? > > > Asking the question in this form creates a bit of a false dichotomy. > HTTP(S) and XMPP cover different areas of the solution space, so they are > not simple alternatives.=A0 It's better to first disentangle the requirem= ents, > and then see what is applicable to each part. mmm.. i hate to say it morgaine, but i disagree. both HTTP(S) and XMPP can be used to carry application state changes. but i do agree we need to be clear about the messaging requirements. > > OGP networking requirements (as far as we know them) comprise at least th= ree > different types of functionality, although the 3rd is a matter of some > debate: > > HTTP(S) client-server request/response calls to OGP services. > Server-client streaming object updates, over an unspecified reliable > transport. > HTTP(S) server-client request/response calls to client-side services. this list presupposes HTTP(S). i would list them as being a little more gen= eral: 1. the client makes a non-real-time request of the server. 2. the server makes a non-real-time request of another server. 3. the client makes a real-time request of the server. 4. the server sends a real-time update to the client. 5. the server makes a non-real-time request of the client. * all messages SHOULD have the ability to carry meta-data important to the carrying protocol. * all messages SHOULD have clear semantics for describing endpoints of mess= ages an example of 1 would be fetching a texture from an asset server. there is a proud history of using HTTP to fetch images, which is why i think there's consensus behind using it for this purpose. an example of 2 would be an agent host making a request of a simulator. like the first example, this is a request-response pattern. an example of 3 would be the user presses the 'up' arrow on the keyboard and expects a change in the avatar's shared state (like it moves forward.) i would call this a "weak" request response, meaning, it would be nice if after you pressed the up arrow and the client sent the "hey, my user just pressed the up arrow" message to the server, if you would get a response. but... if you wind up not getting a response for each request, it's not the end of the world. maybe responses could be acknowledged in a batch response, or the response could be eliminated all together if the semantics of the message do not REQUIRE reliable delivery. an example of 4 would be the simulator sending object update messages to the client. these messages MAY have real-time semantics, meaning if a message is late, it's useless (think VoIP.) so imagine a world, where the simulator sends each client messages like "object is now at location " or ".. is now rotated ." if we applied real-time semantics to these messages, the client would likely be constructed to update the position (or other physical characteristics) of an object at a low frame rate, and the experience would be that those objects would potentially look jerky. if we didn't apply real-time semantics, the client could have some messages delayed, then applied rapidly; like maybe five seconds worth of avatar movement is compressed into two seconds. these are two extremes, and there are probably a great number of tricks the client could pull to make the experience look a little nicer. i think this is where RTP and XMPP would shine. RTP if we want real-time semantics, XMPP if we don't. ultimately, however, given the event queue and long poll techniques, non-real-time messaging from the server to the client COULD be implemented with HTTP. an example of 5 is a server needs to access a sensitive resource maintained by the client. (reference previous discussions about client side capabilities.) this is another place where XMPP would likely be more efficient than HTTP(S), but again, we have an event queue, long poll and someday might have a standard for bi-directional HTTP. ultimately, i think the thinking here is that it's easier to think of OGP as an application protocol that CAN go over multiple protocols, then define how it goes over each protocol, then allow the deployer to choose which protocol it wants to layer OGP messages over modulo some fixed number of well defined interoperability profiles. i think that REQUIRING some messages to go over HTTP (and only over HTTP) while REQUIRING other messages to go over RTP (and only over RTP) and yet a third class of messages to go over XMPP (and only over XMPP) is a recipe for disaster in a protocol. such a beast would be extremely difficult to implement as it would require implementers and deployers to integrate multiple transports. in practice, this might mean integrating apache with ejabberd and with a custom RTP application. it's not impossible to do, but it would DEFINITELY be more difficult. > > Type 1 is wonderfully served by HTTP(S), while XMPP leaves a lot to be > desired in this role, for which it was not designed. > > Type 2 is not served naturally by HTTP(S) at all, but because this > requirement is so common in many types of applications, the "web everywhe= re" > fraternity has tried to shoehorn this type into HTTP as well, using a > variety of proposed strategies ranging from COMET's Long Poll and Streame= d > Response through to the latest WebSockets, with debateable success.=A0 XM= PP > was designed to serve this type of networking functionality, although its > targetted application area is somewhat different to that of VWs.=A0 Wheth= er it > would be able to carry object updates with sufficient efficiency would > require analysis and testing. > > Type 3 is poorly specified at present, and it may turn out to be a > non-existent requirement stemming only from a misguided attempt to poll > clients instead of receiving streamed asynchronous updates from them.=A0 = On > the other hand it may turn out to be an essential networking facility for > providing symmetry between clients and servers, for instance when decoupl= ed > OGP services run on the client --- this will need much more discussion. > Assuming for now that there is indeed such a requirement, HTTP may serve = it > adequately when run over Reverse HTTP, whereas XMPP would leave a lot to = be > desired in this role for which it was not designed. > > The above is confusing and fragmented enough, but it gets worse. > > There is yet another networking type common to VWs which has not even bee= n > mentioned in our two years of AWG and the 6 months of MMOX deliberations, > yet is an essential type with its own properties: =A0 streaming of input > events and objects from client to server.=A0 This is (roughly) lumped in = with > Type 2 in current SL and Opensim=A0 implementations, and it appears to be > destined to be lumped in with Type 1 in OGP, where it fits poorly for > reasons of latency on realtime inputs.=A0 Neither HTTP(S) nor XMPP seem i= deal > for this, although XMPP has a much closer semantic fit owing to its Jabbe= r > heritage. > > So where does this leave us?=A0 Well the first thing that should be clear= is > that we are not facing a simple question of=A0 "Should we do it all over = HTTP > alone, or also allow for implementation over XMPP?".=A0 The design > requirements aren't like that at all.=A0 In particular, HTTP(S) just does= n't > fit the Type 2 semantic requirement, and XMPP may not either. > > Given that our current task is only to define the charter and not to > constrain the solutions, I think that any form of wording that suggests t= hat > HTTP(S) alone is sufficient should be avoided, because it is not sufficie= nt > for Type 2 based on our existing experience in virtual worlds.=A0 To put = it > bluntly, it's too slow, and the polling model has inadequate latency > properties. > > I suggest therefore that this question of "HTTP(S) and/or XMPP" not be > addressed in the charter, because the requirements have not yet been > examined in sufficient detail to be able to make that call.=A0 Indeed, Ty= pe 2 > may require a different protocol altogether. so i respectfully disagree with your assertion that identifying a standard transport for messages is not useful. > > > Morgaine. > > > > > > > > On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden > wrote: >> >> Hey people! >> >> So... looping back around to some of the comments from the f2f BoF >> meeting... >> >> Original work with OGP used HTTP(S) to carry application messages. >> There's been enough talk about alternate transports that it feels very >> bad to dismiss them without discussion. However, I'm wondering if >> there's anyone out there planning on implementing OGP over XMPP? >> >> The reason I ask is that a number of us who worked on the early >> pre-IETF interop trials are heavily invested in HTTP(S). Though i >> can't speak for everyone involved, i would anticipate resistance to >> mandating a new transport. HTTP(S) has it's weaknesses as a transport, >> to be sure, but it's a well deployed and well understood protocol with >> a mature tool chain. This makes it attractive to many people. >> >> On the other hand, if someone else thinks they want to produce an OGP >> implementation over XMPP, that seems really cool. But if no one's >> going to implement it, an argument could be made that putting the >> effort into specifying it would be a waste of time. On yet another >> hand, going through the exercise of figuring out what aspects of HTTP >> are required to transport OGP messages might reveal subtle >> dependencies between components. Back on the other hand again, can we >> do this without re-writing BCP56? >> >> So I was thinking of this as a proposal: >> >> If there is strong interest in implementing OGP over XMPP, let's >> mention that it's an "officially supported" transport in the charter. >> (for some definition of the words "officially supported.") >> >> If there's not strong interest in implementing OGP over XMPP, let's >> not put it in the charter. >> >> In either case, I think there's sufficient justification for >> describing the set of requirements OGP makes on it's transport. For >> instance, does it REQUIRE request/response semantics? (i.e. - if i'm >> writing a compliant server layering OGP over XMPP, and i receive an >> OGP "request" in an XML stanza, am i REQUIRED to send a response?) >> Or... does it REQUIRE specific content negotiation semantics? (i.e. - >> do we need to explicitly describe or reference a technique for >> identifying the content type of a response in XMPP?) Or... does the >> protocol explicitly depend on caching behavior of some HTTP proxies? >> if so, how? etc. etc. >> >> -sincerely >> -meadhbh >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From dwl@us.ibm.com Mon Aug 17 10:06:37 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CB328C1B0; Mon, 17 Aug 2009 10:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=-2.410, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovp5kk4Zg6Ax; Mon, 17 Aug 2009 10:06:35 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 7F7AE3A69A7; Mon, 17 Aug 2009 10:06:35 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e9.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7HH5RhU022090; Mon, 17 Aug 2009 13:05:27 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7HH6Wc9220100; Mon, 17 Aug 2009 13:06:32 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7HH6W6Y031441; Mon, 17 Aug 2009 13:06:32 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7HH6WOB031422; Mon, 17 Aug 2009 13:06:32 -0400 MIME-Version: 1.0 In-Reply-To: <3a880e2c0908170911s2d655cf5m69fac6e8d8a0e2e1@mail.gmail.com> References: <20090730.000748.17075.0@webmail02.vgs.untd.com> <3e3ef2f00908170816v20cc5567n5b5f503d45a69534@mail.gmail.com> <3a880e2c0908170911s2d655cf5m69fac6e8d8a0e2e1@mail.gmail.com> To: Infinity Linden X-KeepSent: 5A5C5AB3:202128D4-85257615:005DF1E4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Mon, 17 Aug 2009 13:06:31 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 08/17/2009 13:06:31, Serialize complete at 08/17/2009 13:06:31 Content-Type: multipart/alternative; boundary="=_alternative 005DFB6485257615_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org, dcrocker@bbiw.net, "dyerbrookme@juno.com" Subject: Re: [ogpx] the term 'grid' X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 17:06:37 -0000 This is a multipart message in MIME format. --=_alternative 005DFB6485257615_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 TWlnaHQgSSBhZGQsIGluIGFkZGl0aW9uLCB0aGF0LCB0aGUgcHJvZ3Jlc3Npb24gb2YgIHRlcm1z IGZyb20gIkdyaWQiIGluIA0KMjAwNiB0byAiQ2xvdWQiIGluIDIwMDksIGluIHRlcm1zIG9mDQpj dXJyZW50IHRyZW5keSB0ZWNobm8gYnV6endvcmQgZm9yICJXZWIgc2NhbGUgZGlzdHJpYnV0ZWQg Y29tcHV0aW5nIGZhYnJpYyANCndpdGggaGlnaCBjdXJiICBhcHBlYWwgdG8gQ0lPcyIgDQppbXBs aWVzIHRoYXQgd2Ugc2hvdWxkIHBpY2sgYSBkZWNlbnQsIHRlY2huaWNhbGx5IGNvcnJlY3QgcGhy YXNlLCBhbmQgbm90IA0Kd29ycnkgdG9vIG11Y2guICBJJ3ZlIG5vIGRvdWJ0DQp0aGF0IGluIHRo ZSBuZXh0IHllYXIgb3IgdHdvLCB5ZXQgYW5vdGhlciBwaHJhc2Ugd2lsbCBiZSBhbm9pbnRlZCB0 byBmaWxsIA0KdGhlIHJvbGUuIA0KDQotIERhdmlkDQp+IFpoYQ0KDQoNCm9ncHgtYm91bmNlc0Bp ZXRmLm9yZyB3cm90ZSBvbiAwOC8xNy8yMDA5IDEyOjExOjEyIFBNOg0KDQo+IEluZmluaXR5IExp bmRlbiA8aW5maW5pdHlAbGluZGVubGFiLmNvbT4gDQo+IFNlbnQgYnk6IG9ncHgtYm91bmNlc0Bp ZXRmLm9yZw0KPiANCj4gMDgvMTcvMjAwOSAxMjoxMSBQTQ0KPiANCj4gVG8NCj4gDQo+IFllc2hh IFNpdmFuIDx5ZXNoYS5zaXZhbkBtZXRhdmVyc2UtbGFicy5jb20+DQo+IA0KPiBjYw0KPiANCj4g b2dweEBpZXRmLm9yZywgZGNyb2NrZXJAYmJpdy5uZXQsICJkeWVyYnJvb2ttZUBqdW5vLmNvbSIg DQo+IDxkeWVyYnJvb2ttZUBqdW5vLmNvbT4NCj4gDQo+IFN1YmplY3QNCj4gDQo+IFJlOiBbb2dw eF0gdGhlIHRlcm0gJ2dyaWQnDQo+IA0KPiBmd2l3Li4uIGEgbGl0dGxlIGhpc3Rvcnkgb24gdGhl IHRlcm0gImdyaWQuIg0KPiANCj4gaW5zaWRlIGxpbmRlbiBpdCdzIHVzZWQgdG8gZGVmaW5lIHRo ZSBnZW9tZXRyeSBvZiB0aGUgdmlydHVhbCB3b3JsZA0KPiBhbmQgdGhlIGNvbGxlY3Rpb24gb2Yg bWFjaGluZXMgaXQncyBkZXBsb3llZCBvbi4gImNsb3VkIiB3YXNuJ3QgeWV0DQo+IHBvcHVsYXIg d2hlbiBzZWNvbmQgbGlmZSB3YXMgbGF1bmNoZWQsIHNvIHlvdSBnb3QgdGhlIG5hbWUgImdyaWQu Ig0KPiANCj4gd2hlbiB0aGUgaW50ZXJvcCB3b3JrIGxhc3Qgc3VtbWVyIGtpY2tlZCBvZmYsIHRo ZSBwZW9wbGUgcGFydGljaXBhdGluZw0KPiB3ZXJlIHNlcmlvdXMgU0wtaGVhZHMgKG1lYW5pbmcg c2Vjb25kIGxpZmUgd2FzIHRoZSB2aXJ0dWFsIHdvcmxkIHdlDQo+IGhhZCBmb3JlbW9zdCBpbiBv dXIgbWluZHMuKSBzbyB3aGVuIHRoZSAiT3BlbiBHcmlkIFByb3RvY29sIiBnb3QgaXQncw0KPiBu YW1lLCB0aGUgZW1waGFzaXMgd2FzIG9uICJvcGVuIiBhbmQgbm90ICJncmlkLiIgYWZ0ZXIgYWxs Li4uIGluIHRoYXQNCj4gY29tbXVuaXR5LCB3ZSBhbGwga25ldyB3aGF0ICJncmlkIiBpbXBsaWVk Lg0KPiANCj4gYnV0IG5vdyB3ZSdyZSBob3BpbmcgdG8gbW92ZSBiZXlvbmQgdGhhdCBjb21tdW5p dHksIHNvIHllYWgsIHdlIGhhdmUNCj4gdG8gdGFrZSBpbnRvIGFjY291bnQgdGhlIGZhY3QgdGhh dCB0aGVyZSBhcmUgcGVvcGxlIG91dCB0aGVyZSB0aGF0DQo+IGhhdmVuJ3QgYmVlbiBlYXRpbmcg YW5kIHNsZWVwaW5nIFNMLXN0eWxlIHZpcnR1YWwgd29ybGRzIGZvciB0aGUgbGFzdA0KPiBmaXZl LXNpeCB5ZWFycywgYW5kIG1pZ2h0IGhhdmUgYSBkaWZmZXJlbnQgdW5kZXJzdGFuZGluZyBvZiB0 aGUgdGVybXMNCj4gImdyaWQiIGFuZCAiY2xvdWQuIiB1bHRpbWF0ZWx5LCB0aGUgcHJvdG9jb2wg d2UncmUgZGVmaW5pbmcgY291bGQgYmUNCj4gZGVwbG95ZWQgb24gYSBncmlkLCBhIGNsdXN0ZXIs IGluIGEgY2xvdWQsIG9yIG9uIGEgc2luZ2xlIGhvc3QNCj4gKHRob3VnaHQgdGhlIGxhdHRlciB3 b3VsZCBwcm9iYWJseSBiZSBhIHNtYWxsIHdvcmxkLikNCj4gDQo+IGNhbiBpIGFzayB0aG91Z2gu LiBjYW4gd2Ugc2ltcGx5IGFncmVlIHRoYXQgd2UgbmVlZCBtb3JlIGRpc2N1c3Npb24gb24NCj4g dGhlIG5hbWUsIGFuZCBkZWxheSBkaXNjdXNzaW9uIHVudGlsIHRoZSBzdWJzdGFudGl2ZSBpc3N1 ZXMgb2YgdGhlDQo+IGRyYWZ0IGNoYXJ0ZXIgYXJlIHJlc29sdmVkPw0KPiANCj4gaW4gb3RoZXIg d29yZHMsIGFzIHdlIHN0YXJ0IHB1c2hpbmcgY2hhcnRlciBkcmFmdHMgb3V0LCBwbGVhc2UgZG9u J3QNCj4gZnJlYWsgb3V0IGlmIHdlIHN0aWxsIGhhdmUgT0dQWCBhbmQgT0dQIGluIHRoZW0uIHRo ZXkncmUganVzdA0KPiBwbGFjZWhvbGRlcnMgZm9yIHdoYXRldmVyIG5hbWUgd2UgYWxsIGFncmVl IG9uIGluIHRoZSBmdXR1cmUuDQo+IA0KPiAtY2hlZXJzDQo+IC1tZWFkaGJoDQo+IA0KPiANCj4g T24gTW9uLCBBdWcgMTcsIDIwMDkgYXQgODoxNiBBTSwgWWVzaGENCj4gU2l2YW48eWVzaGEuc2l2 YW5AbWV0YXZlcnNlLWxhYnMuY29tPiB3cm90ZToNCj4gPiBJZiB5b3Ugd2FudCB0byB1c2UgImdy aWQiIC4uLiB0aGVuIHVzZSAiY2xvdWQiICBncmlkIGlzIHNvIDIwMDcuLi4uIFsgDQp0aGlzDQo+ ID4gd2lsbCBjb25uZWN0IHRoaXMgd2l0aCB0aGUgbGF0ZXN0IHRyZW5kcy4uLiB3aGljaCB3aWxs IA0KYmUgYXBwZWFsaW5nIGZvciBDWE8NCj4gPiBsZXZlbCBkZWNpc2lvbnMpDQo+ID4gYW5kIGdv b2Qgd29yayBJbmZpbml0eSBvbiBwcmVzZW50aW5nIGluIFNMQ0MNCj4gPiAtLVllc2hhDQo+ID4g RHIuIFllc2hhIFkuIFNpdmFuLCBodHRwOi8vd3d3LmRyeWVzaGEuY29tOyBDb25uZWN0aW5nIFJl YWwgYW5kIA0KVmlydHVhbA0KPiA+IFdvcmxkcy4NCj4gPg0KPiA+DQo+ID4gT24gVGh1LCBKdWwg MzAsIDIwMDkgYXQgMTI6MDcgQU0sIGR5ZXJicm9va21lQGp1bm8uY29tDQo+ID4gPGR5ZXJicm9v a21lQGp1bm8uY29tPiB3cm90ZToNCj4gPj4NCj4gPj4gTGluZGVuIExhYiBoYXMgdHJhZGVtYXJr ZWQgdGhlIHRlcm0gIlNlY29uZCBMaWZlIEdyaWQiLg0KPiA+PiBodHRwOi8vc2Vjb25kbGlmZS5j b20vY29ycG9yYXRlL2JyYW5kL3RyYWRlbWFyay90bV9jaGFydC5waHANCj4gPj4NCj4gPj4gU2Vj b25kIExpZmUgR3JpZOKEog0KPiA+PiBTTCBHcmlk4oSiDQo+ID4+IFNlY29uZCBMaWZlIEdyaWQg bG9nb+KEog0KPiA+Pg0KPiA+PiBhbmQgbm90ZWQgdGhhdCB0aGUgZ2VuZXJpYyBub3VucyBhcmU6 DQo+ID4+DQo+ID4+IGRldmVsb3BtZW50IHBsYXRmb3JtDQo+ID4+IHBsYXRmb3JtDQo+ID4+IHRl Y2hub2xvZ3kNCj4gPj4NCj4gPj4gUHJva29meSBOZXZhDQo+ID4+DQo+ID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBN YXNzYWdlIFRoZXJhcHkgU2Nob29scw0KPiA+PiBGaW5kIHNjaG9vbHMgbmVhciB5b3Ugb2ZmZXJp bmcgTWFzc2FnZSBUaGVyYXB5IHByb2dyYW1zIC0gZmFzdCENCj4gPj4NCj4gPj4gaHR0cDovL3Ro aXJkcGFydHlvZmZlcnMuanVuby5jb20vVEdMMjE0MS9jPw0KPiANCmNwPThnTmU1OEpYcnZwUFV4 RUNYVHlNTGdBQUoxQkFrUVVPWTZyYWNKZ3NLVFB3WFZkekFBVUFBQUFBQUFBQUFMNHdXVDJ3TktF R0Iwalc1dFNleGlYR1ZxUXFBQUFBQUE9PQ0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBvZ3B4IG1haWxpbmcgbGlzdA0KPiA+PiBvZ3B4 QGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2dw eA0KPiA+DQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gb2dweCBtYWlsaW5nIGxpc3QNCj4gb2dweEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29ncHgNCg0K --=_alternative 005DFB6485257615_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk1pZ2h0IEkgYWRkLCBpbiBhZGRp dGlvbiwgdGhhdCwgdGhlDQpwcm9ncmVzc2lvbiBvZiAmbmJzcDt0ZXJtcyBmcm9tICZxdW90O0dy aWQmcXVvdDsgaW4gMjAwNiB0byAmcXVvdDtDbG91ZCZxdW90Ow0KaW4gMjAwOSwgaW4gdGVybXMg b2Y8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmN1cnJlbnQgdHJl bmR5IHRlY2hubyBidXp6d29yZCBmb3IgJnF1b3Q7V2ViDQpzY2FsZSBkaXN0cmlidXRlZCBjb21w dXRpbmcgZmFicmljIHdpdGggaGlnaCBjdXJiICZuYnNwO2FwcGVhbCB0byBDSU9zJnF1b3Q7DQo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmltcGxpZXMgdGhhdCB3 ZSBzaG91bGQgcGljayBhIGRlY2VudCwNCnRlY2huaWNhbGx5IGNvcnJlY3QgcGhyYXNlLCBhbmQg bm90IHdvcnJ5IHRvbyBtdWNoLiAmbmJzcDtJJ3ZlIG5vIGRvdWJ0PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGF0IGluIHRoZSBuZXh0IHllYXIgb3IgdHdvLCB5 ZXQgYW5vdGhlcg0KcGhyYXNlIHdpbGwgYmUgYW5vaW50ZWQgdG8gZmlsbCB0aGUgcm9sZS4gPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4tIERhdmlkPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5+IFpoYTwvZm9udD4NCjxi cj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPm9ncHgtYm91bmNlc0BpZXRmLm9yZyB3cm90 ZSBvbiAwOC8xNy8yMDA5IDEyOjExOjEyDQpQTTo8YnI+DQo8YnI+DQomZ3Q7IEluZmluaXR5IExp bmRlbiAmbHQ7aW5maW5pdHlAbGluZGVubGFiLmNvbSZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IFNlbnQgYnk6IG9ncHgtYm91bmNlc0BpZXRmLm9yZzxicj4NCiZn dDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDA4LzE3LzIwMDkgMTI6 MTEgUE08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBU bzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFllc2hh IFNpdmFuICZsdDt5ZXNoYS5zaXZhbkBtZXRhdmVyc2UtbGFicy5jb20mZ3Q7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgY2M8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBvZ3B4QGlldGYub3JnLCBkY3JvY2tl ckBiYml3Lm5ldCwgJnF1b3Q7ZHllcmJyb29rbWVAanVuby5jb20mcXVvdDsNCjxicj4NCiZndDsg Jmx0O2R5ZXJicm9va21lQGp1bm8uY29tJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFN1YmplY3Q8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBSZTogW29ncHhdIHRoZSB0ZXJtICdncmlkJzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IGZ3aXcuLi4gYSBsaXR0 bGUgaGlzdG9yeSBvbiB0aGUgdGVybSAmcXVvdDtncmlkLiZxdW90Ozxicj4NCiZndDsgPGJyPg0K Jmd0OyBpbnNpZGUgbGluZGVuIGl0J3MgdXNlZCB0byBkZWZpbmUgdGhlIGdlb21ldHJ5IG9mIHRo ZSB2aXJ0dWFsIHdvcmxkPGJyPg0KJmd0OyBhbmQgdGhlIGNvbGxlY3Rpb24gb2YgbWFjaGluZXMg aXQncyBkZXBsb3llZCBvbi4gJnF1b3Q7Y2xvdWQmcXVvdDsNCndhc24ndCB5ZXQ8YnI+DQomZ3Q7 IHBvcHVsYXIgd2hlbiBzZWNvbmQgbGlmZSB3YXMgbGF1bmNoZWQsIHNvIHlvdSBnb3QgdGhlIG5h bWUgJnF1b3Q7Z3JpZC4mcXVvdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgd2hlbiB0aGUgaW50ZXJv cCB3b3JrIGxhc3Qgc3VtbWVyIGtpY2tlZCBvZmYsIHRoZSBwZW9wbGUgcGFydGljaXBhdGluZzxi cj4NCiZndDsgd2VyZSBzZXJpb3VzIFNMLWhlYWRzIChtZWFuaW5nIHNlY29uZCBsaWZlIHdhcyB0 aGUgdmlydHVhbCB3b3JsZCB3ZTxicj4NCiZndDsgaGFkIGZvcmVtb3N0IGluIG91ciBtaW5kcy4p IHNvIHdoZW4gdGhlICZxdW90O09wZW4gR3JpZCBQcm90b2NvbCZxdW90Ow0KZ290IGl0J3M8YnI+ DQomZ3Q7IG5hbWUsIHRoZSBlbXBoYXNpcyB3YXMgb24gJnF1b3Q7b3BlbiZxdW90OyBhbmQgbm90 ICZxdW90O2dyaWQuJnF1b3Q7DQphZnRlciBhbGwuLi4gaW4gdGhhdDxicj4NCiZndDsgY29tbXVu aXR5LCB3ZSBhbGwga25ldyB3aGF0ICZxdW90O2dyaWQmcXVvdDsgaW1wbGllZC48YnI+DQomZ3Q7 IDxicj4NCiZndDsgYnV0IG5vdyB3ZSdyZSBob3BpbmcgdG8gbW92ZSBiZXlvbmQgdGhhdCBjb21t dW5pdHksIHNvIHllYWgsIHdlIGhhdmU8YnI+DQomZ3Q7IHRvIHRha2UgaW50byBhY2NvdW50IHRo ZSBmYWN0IHRoYXQgdGhlcmUgYXJlIHBlb3BsZSBvdXQgdGhlcmUgdGhhdDxicj4NCiZndDsgaGF2 ZW4ndCBiZWVuIGVhdGluZyBhbmQgc2xlZXBpbmcgU0wtc3R5bGUgdmlydHVhbCB3b3JsZHMgZm9y IHRoZSBsYXN0PGJyPg0KJmd0OyBmaXZlLXNpeCB5ZWFycywgYW5kIG1pZ2h0IGhhdmUgYSBkaWZm ZXJlbnQgdW5kZXJzdGFuZGluZyBvZiB0aGUgdGVybXM8YnI+DQomZ3Q7ICZxdW90O2dyaWQmcXVv dDsgYW5kICZxdW90O2Nsb3VkLiZxdW90OyB1bHRpbWF0ZWx5LCB0aGUgcHJvdG9jb2wgd2UncmUN CmRlZmluaW5nIGNvdWxkIGJlPGJyPg0KJmd0OyBkZXBsb3llZCBvbiBhIGdyaWQsIGEgY2x1c3Rl ciwgaW4gYSBjbG91ZCwgb3Igb24gYSBzaW5nbGUgaG9zdDxicj4NCiZndDsgKHRob3VnaHQgdGhl IGxhdHRlciB3b3VsZCBwcm9iYWJseSBiZSBhIHNtYWxsIHdvcmxkLik8YnI+DQomZ3Q7IDxicj4N CiZndDsgY2FuIGkgYXNrIHRob3VnaC4uIGNhbiB3ZSBzaW1wbHkgYWdyZWUgdGhhdCB3ZSBuZWVk IG1vcmUgZGlzY3Vzc2lvbg0Kb248YnI+DQomZ3Q7IHRoZSBuYW1lLCBhbmQgZGVsYXkgZGlzY3Vz c2lvbiB1bnRpbCB0aGUgc3Vic3RhbnRpdmUgaXNzdWVzIG9mIHRoZTxicj4NCiZndDsgZHJhZnQg Y2hhcnRlciBhcmUgcmVzb2x2ZWQ/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGluIG90aGVyIHdvcmRz LCBhcyB3ZSBzdGFydCBwdXNoaW5nIGNoYXJ0ZXIgZHJhZnRzIG91dCwgcGxlYXNlIGRvbid0PGJy Pg0KJmd0OyBmcmVhayBvdXQgaWYgd2Ugc3RpbGwgaGF2ZSBPR1BYIGFuZCBPR1AgaW4gdGhlbS4g dGhleSdyZSBqdXN0PGJyPg0KJmd0OyBwbGFjZWhvbGRlcnMgZm9yIHdoYXRldmVyIG5hbWUgd2Ug YWxsIGFncmVlIG9uIGluIHRoZSBmdXR1cmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC1jaGVlcnM8 YnI+DQomZ3Q7IC1tZWFkaGJoPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gTW9u LCBBdWcgMTcsIDIwMDkgYXQgODoxNiBBTSwgWWVzaGE8YnI+DQomZ3Q7IFNpdmFuJmx0O3llc2hh LnNpdmFuQG1ldGF2ZXJzZS1sYWJzLmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IElmIHlv dSB3YW50IHRvIHVzZSAmcXVvdDtncmlkJnF1b3Q7IC4uLiB0aGVuIHVzZSAmcXVvdDtjbG91ZCZx dW90Ow0KJm5ic3A7Z3JpZCBpcyBzbyAyMDA3Li4uLiBbIHRoaXM8YnI+DQomZ3Q7ICZndDsgd2ls bCBjb25uZWN0IHRoaXMgd2l0aCB0aGUgbGF0ZXN0IHRyZW5kcy4uLiB3aGljaCB3aWxsIGJlJm5i c3A7YXBwZWFsaW5nJm5ic3A7Zm9yDQpDWE88YnI+DQomZ3Q7ICZndDsgbGV2ZWwgZGVjaXNpb25z KTxicj4NCiZndDsgJmd0OyBhbmQgZ29vZCB3b3JrIEluZmluaXR5IG9uJm5ic3A7cHJlc2VudGlu ZyZuYnNwO2luIFNMQ0M8YnI+DQomZ3Q7ICZndDsgLS1ZZXNoYTxicj4NCiZndDsgJmd0OyBEci4g WWVzaGEgWS4gU2l2YW4sIDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cDovL3d3dy5kcnllc2hhLmNv bS8+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vd3d3LmRyeWVzaGEuY29tPC9mb250PjwvdHQ+PC9h Pjx0dD48Zm9udCBzaXplPTI+Ow0KQ29ubmVjdGluZyBSZWFsIGFuZCBWaXJ0dWFsPGJyPg0KJmd0 OyAmZ3Q7IFdvcmxkcy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgT24gVGh1LCBKdWwgMzAsIDIwMDkgYXQgMTI6MDcgQU0sIGR5ZXJicm9va21lQGp1bm8uY29t PGJyPg0KJmd0OyAmZ3Q7ICZsdDtkeWVyYnJvb2ttZUBqdW5vLmNvbSZndDsgd3JvdGU6PGJyPg0K Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgTGluZGVuIExhYiBoYXMgdHJhZGVtYXJr ZWQgdGhlIHRlcm0gJnF1b3Q7U2Vjb25kIExpZmUgR3JpZCZxdW90Oy48YnI+DQomZ3Q7ICZndDsm Z3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cDovL3NlY29uZGxpZmUuY29tL2NvcnBvcmF0ZS9i cmFuZC90cmFkZW1hcmsvdG1fY2hhcnQucGhwPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL3NlY29u ZGxpZmUuY29tL2NvcnBvcmF0ZS9icmFuZC90cmFkZW1hcmsvdG1fY2hhcnQucGhwPC9mb250Pjwv dHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsgU2Vjb25kIExpZmUgR3JpZOKEojxicj4NCiZndDsgJmd0OyZndDsgU0wgR3JpZOKEojxi cj4NCiZndDsgJmd0OyZndDsgU2Vjb25kIExpZmUgR3JpZCBsb2dv4oSiPGJyPg0KJmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgYW5kIG5vdGVkIHRoYXQgdGhlIGdlbmVyaWMgbm91bnMg YXJlOjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IGRldmVsb3BtZW50IHBs YXRmb3JtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBwbGF0Zm9ybTxicj4NCiZndDsgJmd0OyZndDsgdGVj aG5vbG9neTxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IFByb2tvZnkgTmV2 YTxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0 OyZndDsgTWFzc2FnZSBUaGVyYXB5IFNjaG9vbHM8YnI+DQomZ3Q7ICZndDsmZ3Q7IEZpbmQgc2No b29scyBuZWFyIHlvdSBvZmZlcmluZyBNYXNzYWdlIFRoZXJhcHkgcHJvZ3JhbXMgLQ0KZmFzdCE8 YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8L2ZvbnQ+PC90dD48YSBocmVm PWh0dHA6Ly90aGlyZHBhcnR5b2ZmZXJzLmp1bm8uY29tL1RHTDIxNDEvYz8+PHR0Pjxmb250IHNp emU9Mj5odHRwOi8vdGhpcmRwYXJ0eW9mZmVycy5qdW5vLmNvbS9UR0wyMTQxL2M/PC9mb250Pjwv dHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyBjcD04Z05lNThKWHJ2cFBVeEVDWFR5 TUxnQUFKMUJBa1FVT1k2cmFjSmdzS1RQd1hWZHpBQVVBQUFBQUFBQUFBTDR3V1Qyd05LRUdCMGpX NXRTZXhpWEdWcVFxQUFBQUFBPT08YnI+DQomZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBvZ3B4IG1h aWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZndDsgb2dweEBpZXRmLm9yZzxicj4NCiZndDsgJmd0 OyZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29ncHg+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29ncHg8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBvZ3B4IG1haWxpbmcgbGlzdDxicj4NCiZn dDsgb2dweEBpZXRmLm9yZzxicj4NCiZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29ncHg+PHR0Pjxmb250IHNpemU9Mj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29ncHg8L2ZvbnQ+PC90dD48L2E+PHR0Pjxm b250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 005DFB6485257615_=-- From tk@research.att.com Tue Aug 18 07:01:19 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DE13A6DE7 for ; Tue, 18 Aug 2009 07:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ws1kEL2rmxC for ; Tue, 18 Aug 2009 07:01:17 -0700 (PDT) Received: from mail-yellow.research.att.com (mail-dark.research.att.com [192.20.225.112]) by core3.amsl.com (Postfix) with ESMTP id 3B59A3A6B33 for ; Tue, 18 Aug 2009 07:01:17 -0700 (PDT) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.176.254]) by mail-blue.research.att.com (Postfix) with ESMTP id B5F4EF106E; Tue, 18 Aug 2009 07:51:33 -0400 (EDT) Received: from crucible.research.att.com (crucible.client.research.att.com [135.207.174.50]) by unixmail.research.att.com (8.13.7+Sun/8.13.7) with ESMTP id n7IBpW4w025463; Tue, 18 Aug 2009 07:51:32 -0400 (EDT) Received: by crucible.research.att.com (Postfix, from userid 58282) id C97AC53C488; Tue, 18 Aug 2009 07:51:12 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=unknown Content-Transfer-Encoding: quoted-printable Message-ID: <19082.38320.554039.749475@crucible.client.research.att.com> Date: Tue, 18 Aug 2009 07:51:12 -0400 From: thomas kirk To: Meadhbh Siobhan In-Reply-To: References: <3a880e2c0908121753s34bacba7k59fae708752d3d6a@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 23.1.1 Cc: ogpx@ietf.org Subject: Re: [ogpx] HTTP(S) and XMPP as transports of OGP application layer messages X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tk@research.att.com List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 14:01:19 -0000 in favor of leaving open the possibility of alternative transports, so even if HTTP(S) is the preferred mapping, it would be worthwhile to=20 define a core OGP protocol that's independent of a concrete transport,=20= and specify the HTTP(S) mapping separately, in the manner that=20 BEEP (for example) makes this distinction (rfc3080, 3081). The core protocol can express requirements and assumptions about=20 the transport abstractly; separating its specification leaves=20 open the possibility of future mappings, and makes explicit=20 (and probably simplifies) the ways that OGP depends on underlying=20 service. Given the historical bias, seems reasonable to propose=20 at least an HTTP mapping, but without precluding others. > On Thu, Aug 13, 2009 at 9:54 AM, Morgaine wrote: > > On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden > > wrote: > >> > >> Original work with OGP used HTTP(S) to carry application messages= =2E > >> There's been enough talk about alternate transports that it feels= very > >> bad to dismiss them without discussion. However, I'm wondering if= > >> there's anyone out there planning on implementing OGP over XMPP=3F= > > > > > > Asking the question in this form creates a bit of a false dichotom= y. > > HTTP(S) and XMPP cover different areas of the solution space, so t= hey are > > not simple alternatives.=A0 It's better to first disentangle the r= equirements, > > and then see what is applicable to each part. >=20 > mmm.. i hate to say it morgaine, but i disagree. both HTTP(S) and XM= PP > can be used to carry application state changes. >=20 > but i do agree we need to be clear about the messaging requirements.= >=20 >=20 > > > > OGP networking requirements (as far as we know them) comprise at l= east three > > different types of functionality, although the 3rd is a matter of = some > > debate: > > > > HTTP(S) client-server request/response calls to OGP services. > > Server-client streaming object updates, over an unspecified reliab= le > > transport. > > HTTP(S) server-client request/response calls to client-side servic= es. >=20 > this list presupposes HTTP(S). i would list them as being a little m= ore general: >=20 > 1. the client makes a non-real-time request of the server. > 2. the server makes a non-real-time request of another server. > 3. the client makes a real-time request of the server. > 4. the server sends a real-time update to the client. > 5. the server makes a non-real-time request of the client. >=20 > * all messages SHOULD have the ability to carry meta-data important = to > the carrying protocol. > * all messages SHOULD have clear semantics for describing endpoints = of messages >=20 > an example of 1 would be fetching a texture from an asset server. > there is a proud history of using HTTP to fetch images, which is why= i > think there's consensus behind using it for this purpose. >=20 > an example of 2 would be an agent host making a request of a > simulator. like the first example, this is a request-response patter= n. >=20 > an example of 3 would be the user presses the 'up' arrow on the > keyboard and expects a change in the avatar's shared state (like it > moves forward.) i would call this a "weak" request response, meaning= , > it would be nice if after you pressed the up arrow and the client se= nt > the "hey, my user just pressed the up arrow" message to the server, = if > you would get a response. but... if you wind up not getting a respon= se > for each request, it's not the end of the world. maybe responses cou= ld > be acknowledged in a batch response, or the response could be > eliminated all together if the semantics of the message do not REQUI= RE > reliable delivery. >=20 > an example of 4 would be the simulator sending object update message= s > to the client. these messages MAY have real-time semantics, meaning = if > a message is late, it's useless (think VoIP.) so imagine a world, > where the simulator sends each client messages like "object is= > now at location " or ".. is now rotated ." if we applie= d > real-time semantics to these messages, the client would likely be > constructed to update the position (or other physical characteristic= s) > of an object at a low frame rate, and the experience would be that > those objects would potentially look jerky. if we didn't apply > real-time semantics, the client could have some messages delayed, th= en > applied rapidly; like maybe five seconds worth of avatar movement is= > compressed into two seconds. these are two extremes, and there are > probably a great number of tricks the client could pull to make the > experience look a little nicer. >=20 > i think this is where RTP and XMPP would shine. RTP if we want > real-time semantics, XMPP if we don't. ultimately, however, given th= e > event queue and long poll techniques, non-real-time messaging from t= he > server to the client COULD be implemented with HTTP. >=20 > an example of 5 is a server needs to access a sensitive resource > maintained by the client. (reference previous discussions about clie= nt > side capabilities.) this is another place where XMPP would likely be= > more efficient than HTTP(S), but again, we have an event queue, long= > poll and someday might have a standard for bi-directional HTTP. >=20 > ultimately, i think the thinking here is that it's easier to think o= f > OGP as an application protocol that CAN go over multiple protocols, > then define how it goes over each protocol, then allow the deployer = to > choose which protocol it wants to layer OGP messages over modulo som= e > fixed number of well defined interoperability profiles. >=20 > i think that REQUIRING some messages to go over HTTP (and only over > HTTP) while REQUIRING other messages to go over RTP (and only over > RTP) and yet a third class of messages to go over XMPP (and only ove= r > XMPP) is a recipe for disaster in a protocol. such a beast would be > extremely difficult to implement as it would require implementers an= d > deployers to integrate multiple transports. in practice, this might > mean integrating apache with ejabberd and with a custom RTP > application. it's not impossible to do, but it would DEFINITELY be > more difficult. >=20 > > > > Type 1 is wonderfully served by HTTP(S), while XMPP leaves a lot t= o be > > desired in this role, for which it was not designed. > > > > Type 2 is not served naturally by HTTP(S) at all, but because this= > > requirement is so common in many types of applications, the "web e= verywhere" > > fraternity has tried to shoehorn this type into HTTP as well, usin= g a > > variety of proposed strategies ranging from COMET's Long Poll and = Streamed > > Response through to the latest WebSockets, with debateable success= .=A0 XMPP > > was designed to serve this type of networking functionality, altho= ugh its > > targetted application area is somewhat different to that of VWs.=A0= Whether it > > would be able to carry object updates with sufficient efficiency w= ould > > require analysis and testing. > > > > Type 3 is poorly specified at present, and it may turn out to be a= > > non-existent requirement stemming only from a misguided attempt to= poll > > clients instead of receiving streamed asynchronous updates from th= em.=A0 On > > the other hand it may turn out to be an essential networking facil= ity for > > providing symmetry between clients and servers, for instance when = decoupled > > OGP services run on the client --- this will need much more discus= sion. > > Assuming for now that there is indeed such a requirement, HTTP may= serve it > > adequately when run over Reverse HTTP, whereas XMPP would leave a = lot to be > > desired in this role for which it was not designed. > > > > The above is confusing and fragmented enough, but it gets worse. > > > > There is yet another networking type common to VWs which has not e= ven been > > mentioned in our two years of AWG and the 6 months of MMOX deliber= ations, > > yet is an essential type with its own properties: =A0 streaming of= input > > events and objects from client to server.=A0 This is (roughly) lum= ped in with > > Type 2 in current SL and Opensim=A0 implementations, and it appear= s to be > > destined to be lumped in with Type 1 in OGP, where it fits poorly = for > > reasons of latency on realtime inputs.=A0 Neither HTTP(S) nor XMPP= seem ideal > > for this, although XMPP has a much closer semantic fit owing to it= s Jabber > > heritage. > > > > So where does this leave us=3F=A0 Well the first thing that should= be clear is > > that we are not facing a simple question of=A0 "Should we do it al= l over HTTP > > alone, or also allow for implementation over XMPP=3F".=A0 The desi= gn > > requirements aren't like that at all.=A0 In particular, HTTP(S) ju= st doesn't > > fit the Type 2 semantic requirement, and XMPP may not either. > > > > Given that our current task is only to define the charter and not = to > > constrain the solutions, I think that any form of wording that sug= gests that > > HTTP(S) alone is sufficient should be avoided, because it is not s= ufficient > > for Type 2 based on our existing experience in virtual worlds.=A0 = To put it > > bluntly, it's too slow, and the polling model has inadequate laten= cy > > properties. > > > > I suggest therefore that this question of "HTTP(S) and/or XMPP" no= t be > > addressed in the charter, because the requirements have not yet be= en > > examined in sufficient detail to be able to make that call.=A0 Ind= eed, Type 2 > > may require a different protocol altogether. >=20 > so i respectfully disagree with your assertion that identifying a > standard transport for messages is not useful. >=20 > > > > > > Morgaine. > > > > > > > > > > > > > > > > On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden > > wrote: > >> > >> Hey people! > >> > >> So... looping back around to some of the comments from the f2f Bo= F > >> meeting... > >> > >> Original work with OGP used HTTP(S) to carry application messages= =2E > >> There's been enough talk about alternate transports that it feels= very > >> bad to dismiss them without discussion. However, I'm wondering if= > >> there's anyone out there planning on implementing OGP over XMPP=3F= > >> > >> The reason I ask is that a number of us who worked on the early > >> pre-IETF interop trials are heavily invested in HTTP(S). Though i= > >> can't speak for everyone involved, i would anticipate resistance = to > >> mandating a new transport. HTTP(S) has it's weaknesses as a trans= port, > >> to be sure, but it's a well deployed and well understood protocol= with > >> a mature tool chain. This makes it attractive to many people. > >> > >> On the other hand, if someone else thinks they want to produce an= OGP > >> implementation over XMPP, that seems really cool. But if no one's= > >> going to implement it, an argument could be made that putting the= > >> effort into specifying it would be a waste of time. On yet anothe= r > >> hand, going through the exercise of figuring out what aspects of = HTTP > >> are required to transport OGP messages might reveal subtle > >> dependencies between components. Back on the other hand again, ca= n we > >> do this without re-writing BCP56=3F > >> > >> So I was thinking of this as a proposal: > >> > >> If there is strong interest in implementing OGP over XMPP, let's > >> mention that it's an "officially supported" transport in the char= ter. > >> (for some definition of the words "officially supported.") > >> > >> If there's not strong interest in implementing OGP over XMPP, let= 's > >> not put it in the charter. > >> > >> In either case, I think there's sufficient justification for > >> describing the set of requirements OGP makes on it's transport. F= or > >> instance, does it REQUIRE request/response semantics=3F (i.e. - i= f i'm > >> writing a compliant server layering OGP over XMPP, and i receive = an > >> OGP "request" in an XML stanza, am i REQUIRED to send a response=3F= ) > >> Or... does it REQUIRE specific content negotiation semantics=3F (= i.e. - > >> do we need to explicitly describe or reference a technique for > >> identifying the content type of a response in XMPP=3F) Or... does= the > >> protocol explicitly depend on caching behavior of some HTTP proxi= es=3F > >> if so, how=3F etc. etc. > >> > >> -sincerely > >> -meadhbh > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > >> ogpx mailing list > >> ogpx@ietf.org > >> https://www.ietf.org/mailman/listinfo/ogpx > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx From dwl@us.ibm.com Tue Aug 18 07:06:30 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717D13A6A9E; Tue, 18 Aug 2009 07:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.375 X-Spam-Level: X-Spam-Status: No, score=-5.375 tagged_above=-999 required=5 tests=[AWL=1.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8i7kx7jOUxO; Tue, 18 Aug 2009 07:06:28 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 817D13A689D; Tue, 18 Aug 2009 07:06:27 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7IE0VWf002225; Tue, 18 Aug 2009 10:00:31 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7IE6O96241592; Tue, 18 Aug 2009 10:06:29 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7IE3Utl015425; Tue, 18 Aug 2009 10:03:30 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7IE2imF009913; Tue, 18 Aug 2009 10:02:44 -0400 In-Reply-To: <19082.38320.554039.749475@crucible.client.research.att.com> References: <3a880e2c0908121753s34bacba7k59fae708752d3d6a@mail.gmail.com> <19082.38320.554039.749475@crucible.client.research.att.com> To: tk@research.att.com MIME-Version: 1.0 X-KeepSent: AD2F5035:074062AB-85257616:004D296F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Tue, 18 Aug 2009 10:05:31 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 08/18/2009 10:05:37, Serialize complete at 08/18/2009 10:05:37 Content-Type: multipart/alternative; boundary="=_alternative 004D693D85257616_=" Cc: Meadhbh Siobhan , ogpx@ietf.org, ogpx-bounces@ietf.org Subject: Re: [ogpx] HTTP(S) and XMPP as transports of OGP application layer messages X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 14:06:30 -0000 This is a multipart message in MIME format. --=_alternative 004D693D85257616_= Content-Type: text/plain; charset="US-ASCII" That matches my thinking. We want to be saying "Here is a formatted request./response sequence" "Here is how you move it on http(s)" and expect that, down the road someone may say "Here is how you move it on xmpp" We need a parallel construct to map "update stream" like messages. We don't want to tie permanently to a single transport, but, we need to show it on specific ones, and http(s) gets first dibs on that. - David ~ Zha ogpx-bounces@ietf.org wrote on 08/18/2009 07:51:12 AM: > thomas kirk > Sent by: ogpx-bounces@ietf.org > > 08/18/2009 07:51 AM > > Please respond to > tk@research.att.com > > To > > Meadhbh Siobhan > > cc > > ogpx@ietf.org > > Subject > > Re: [ogpx] HTTP(S) and XMPP as transports of OGP application layer messages > > in favor of leaving open the possibility of alternative transports, so > even if HTTP(S) is the preferred mapping, it would be worthwhile to > define a core OGP protocol that's independent of a concrete transport, > and specify the HTTP(S) mapping separately, in the manner that > BEEP (for example) makes this distinction (rfc3080, 3081). > > The core protocol can express requirements and assumptions about > the transport abstractly; separating its specification leaves > open the possibility of future mappings, and makes explicit > (and probably simplifies) the ways that OGP depends on underlying > service. Given the historical bias, seems reasonable to propose > at least an HTTP mapping, but without precluding others. > > > > On Thu, Aug 13, 2009 at 9:54 AM, > Morgaine wrote: > > > On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden > > > wrote: > > >> > > >> Original work with OGP used HTTP(S) to carry application messages. > > >> There's been enough talk about alternate transports that it feels very > > >> bad to dismiss them without discussion. However, I'm wondering if > > >> there's anyone out there planning on implementing OGP over XMPP? > > > > > > > > > Asking the question in this form creates a bit of a false dichotomy. > > > HTTP(S) and XMPP cover different areas of the solution space, so they are > > > not simple alternatives. It's better to first disentangle the > requirements, > > > and then see what is applicable to each part. > > > > mmm.. i hate to say it morgaine, but i disagree. both HTTP(S) and XMPP > > can be used to carry application state changes. > > > > but i do agree we need to be clear about the messaging requirements. > > > > > > > > > > OGP networking requirements (as far as we know them) comprise > at least three > > > different types of functionality, although the 3rd is a matter of some > > > debate: > > > > > > HTTP(S) client-server request/response calls to OGP services. > > > Server-client streaming object updates, over an unspecified reliable > > > transport. > > > HTTP(S) server-client request/response calls to client-side services. > > > > this list presupposes HTTP(S). i would list them as being a > little more general: > > > > 1. the client makes a non-real-time request of the server. > > 2. the server makes a non-real-time request of another server. > > 3. the client makes a real-time request of the server. > > 4. the server sends a real-time update to the client. > > 5. the server makes a non-real-time request of the client. > > > > * all messages SHOULD have the ability to carry meta-data important to > > the carrying protocol. > > * all messages SHOULD have clear semantics for describing > endpoints of messages > > > > an example of 1 would be fetching a texture from an asset server. > > there is a proud history of using HTTP to fetch images, which is why i > > think there's consensus behind using it for this purpose. > > > > an example of 2 would be an agent host making a request of a > > simulator. like the first example, this is a request-response pattern. > > > > an example of 3 would be the user presses the 'up' arrow on the > > keyboard and expects a change in the avatar's shared state (like it > > moves forward.) i would call this a "weak" request response, meaning, > > it would be nice if after you pressed the up arrow and the client sent > > the "hey, my user just pressed the up arrow" message to the server, if > > you would get a response. but... if you wind up not getting a response > > for each request, it's not the end of the world. maybe responses could > > be acknowledged in a batch response, or the response could be > > eliminated all together if the semantics of the message do not REQUIRE > > reliable delivery. > > > > an example of 4 would be the simulator sending object update messages > > to the client. these messages MAY have real-time semantics, meaning if > > a message is late, it's useless (think VoIP.) so imagine a world, > > where the simulator sends each client messages like "object is > > now at location " or ".. is now rotated ." if we applied > > real-time semantics to these messages, the client would likely be > > constructed to update the position (or other physical characteristics) > > of an object at a low frame rate, and the experience would be that > > those objects would potentially look jerky. if we didn't apply > > real-time semantics, the client could have some messages delayed, then > > applied rapidly; like maybe five seconds worth of avatar movement is > > compressed into two seconds. these are two extremes, and there are > > probably a great number of tricks the client could pull to make the > > experience look a little nicer. > > > > i think this is where RTP and XMPP would shine. RTP if we want > > real-time semantics, XMPP if we don't. ultimately, however, given the > > event queue and long poll techniques, non-real-time messaging from the > > server to the client COULD be implemented with HTTP. > > > > an example of 5 is a server needs to access a sensitive resource > > maintained by the client. (reference previous discussions about client > > side capabilities.) this is another place where XMPP would likely be > > more efficient than HTTP(S), but again, we have an event queue, long > > poll and someday might have a standard for bi-directional HTTP. > > > > ultimately, i think the thinking here is that it's easier to think of > > OGP as an application protocol that CAN go over multiple protocols, > > then define how it goes over each protocol, then allow the deployer to > > choose which protocol it wants to layer OGP messages over modulo some > > fixed number of well defined interoperability profiles. > > > > i think that REQUIRING some messages to go over HTTP (and only over > > HTTP) while REQUIRING other messages to go over RTP (and only over > > RTP) and yet a third class of messages to go over XMPP (and only over > > XMPP) is a recipe for disaster in a protocol. such a beast would be > > extremely difficult to implement as it would require implementers and > > deployers to integrate multiple transports. in practice, this might > > mean integrating apache with ejabberd and with a custom RTP > > application. it's not impossible to do, but it would DEFINITELY be > > more difficult. > > > > > > > > Type 1 is wonderfully served by HTTP(S), while XMPP leaves a lot to be > > > desired in this role, for which it was not designed. > > > > > > Type 2 is not served naturally by HTTP(S) at all, but because this > > > requirement is so common in many types of applications, the > "web everywhere" > > > fraternity has tried to shoehorn this type into HTTP as well, using a > > > variety of proposed strategies ranging from COMET's Long Poll > and Streamed > > > Response through to the latest WebSockets, with debateable success. XMPP > > > was designed to serve this type of networking functionality, although its > > > targetted application area is somewhat different to that of > VWs. Whether it > > > would be able to carry object updates with sufficient efficiency would > > > require analysis and testing. > > > > > > Type 3 is poorly specified at present, and it may turn out to be a > > > non-existent requirement stemming only from a misguided attempt to poll > > > clients instead of receiving streamed asynchronous updates fromthem. On > > > the other hand it may turn out to be an essential networking facility for > > > providing symmetry between clients and servers, for instance > when decoupled > > > OGP services run on the client --- this will need much more discussion. > > > Assuming for now that there is indeed such a requirement, HTTP > may serve it > > > adequately when run over Reverse HTTP, whereas XMPP would leave > a lot to be > > > desired in this role for which it was not designed. > > > > > > The above is confusing and fragmented enough, but it gets worse. > > > > > > There is yet another networking type common to VWs which has > not even been > > > mentioned in our two years of AWG and the 6 months of MMOX deliberations, > > > yet is an essential type with its own properties: streaming of input > > > events and objects from client to server. This is (roughly) > lumped in with > > > Type 2 in current SL and Opensim implementations, and it appears to be > > > destined to be lumped in with Type 1 in OGP, where it fits poorly for > > > reasons of latency on realtime inputs. Neither HTTP(S) nor > XMPP seem ideal > > > for this, although XMPP has a much closer semantic fit owing toits Jabber > > > heritage. > > > > > > So where does this leave us? Well the first thing that should > be clear is > > > that we are not facing a simple question of "Should we do it > all over HTTP > > > alone, or also allow for implementation over XMPP?". The design > > > requirements aren't like that at all. In particular, HTTP(S) > just doesn't > > > fit the Type 2 semantic requirement, and XMPP may not either. > > > > > > Given that our current task is only to define the charter and not to > > > constrain the solutions, I think that any form of wording that > suggests that > > > HTTP(S) alone is sufficient should be avoided, because it is > not sufficient > > > for Type 2 based on our existing experience in virtual worlds. To put it > > > bluntly, it's too slow, and the polling model has inadequate latency > > > properties. > > > > > > I suggest therefore that this question of "HTTP(S) and/or XMPP" not be > > > addressed in the charter, because the requirements have not yet been > > > examined in sufficient detail to be able to make that call. > Indeed, Type 2 > > > may require a different protocol altogether. > > > > so i respectfully disagree with your assertion that identifying a > > standard transport for messages is not useful. > > > > > > > > > > > Morgaine. > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden > > > wrote: > > >> > > >> Hey people! > > >> > > >> So... looping back around to some of the comments from the f2f BoF > > >> meeting... > > >> > > >> Original work with OGP used HTTP(S) to carry application messages. > > >> There's been enough talk about alternate transports that it feels very > > >> bad to dismiss them without discussion. However, I'm wondering if > > >> there's anyone out there planning on implementing OGP over XMPP? > > >> > > >> The reason I ask is that a number of us who worked on the early > > >> pre-IETF interop trials are heavily invested in HTTP(S). Though i > > >> can't speak for everyone involved, i would anticipate resistance to > > >> mandating a new transport. HTTP(S) has it's weaknesses as a transport, > > >> to be sure, but it's a well deployed and well understood protocol with > > >> a mature tool chain. This makes it attractive to many people. > > >> > > >> On the other hand, if someone else thinks they want to produce an OGP > > >> implementation over XMPP, that seems really cool. But if no one's > > >> going to implement it, an argument could be made that putting the > > >> effort into specifying it would be a waste of time. On yet another > > >> hand, going through the exercise of figuring out what aspects of HTTP > > >> are required to transport OGP messages might reveal subtle > > >> dependencies between components. Back on the other hand again, can we > > >> do this without re-writing BCP56? > > >> > > >> So I was thinking of this as a proposal: > > >> > > >> If there is strong interest in implementing OGP over XMPP, let's > > >> mention that it's an "officially supported" transport in the charter. > > >> (for some definition of the words "officially supported.") > > >> > > >> If there's not strong interest in implementing OGP over XMPP, let's > > >> not put it in the charter. > > >> > > >> In either case, I think there's sufficient justification for > > >> describing the set of requirements OGP makes on it's transport. For > > >> instance, does it REQUIRE request/response semantics? (i.e. - if i'm > > >> writing a compliant server layering OGP over XMPP, and i receive an > > >> OGP "request" in an XML stanza, am i REQUIRED to send a response?) > > >> Or... does it REQUIRE specific content negotiation semantics? (i.e. - > > >> do we need to explicitly describe or reference a technique for > > >> identifying the content type of a response in XMPP?) Or... does the > > >> protocol explicitly depend on caching behavior of some HTTP proxies? > > >> if so, how? etc. etc. > > >> > > >> -sincerely > > >> -meadhbh > > >> _______________________________________________ > > >> ogpx mailing list > > >> ogpx@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ogpx > > > > > > > > > _______________________________________________ > > > ogpx mailing list > > > ogpx@ietf.org > > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 004D693D85257616_= Content-Type: text/html; charset="US-ASCII"
That matches my thinking. We want to be saying  "Here is a formatted request./response sequence" "Here is how you move it on http(s)" and expect that, down the road someone may say "Here is how you move it on xmpp" We need a parallel
construct to map "update stream" like messages. We don't want to tie permanently to a single transport,  but, we need to show it on specific ones, and http(s) gets first dibs on that.

- David
~ Zha


ogpx-bounces@ietf.org wrote on 08/18/2009 07:51:12 AM:

> thomas kirk <tk@research.att.com>
> Sent by: ogpx-bounces@ietf.org
>
> 08/18/2009 07:51 AM
>
> Please respond to
> tk@research.att.com
>
> To
>
> Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
>
> cc
>
> ogpx@ietf.org
>
> Subject
>
> Re: [ogpx] HTTP(S) and XMPP as transports of OGP application layer messages
>
> in favor of leaving open the possibility of alternative transports, so
> even if HTTP(S) is the preferred mapping, it would be worthwhile to
> define a core OGP protocol that's independent of a concrete transport,
> and specify the HTTP(S) mapping separately, in the manner that
> BEEP (for example) makes this distinction (rfc3080, 3081).
>
> The core protocol can express requirements and assumptions about
> the transport abstractly; separating its specification leaves
> open the possibility of future mappings, and makes explicit
> (and probably simplifies) the ways that OGP depends on underlying
> service. Given the historical bias, seems reasonable to propose
> at least an HTTP mapping, but without precluding others.
>
>
>  > On Thu, Aug 13, 2009 at 9:54 AM,
> Morgaine<morgaine.dinova@googlemail.com> wrote:
>  > > On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden <infinity@lindenlab.com>
>  > > wrote:
>  > >>
>  > >> Original work with OGP used HTTP(S) to carry application messages.
>  > >> There's been enough talk about alternate transports that it feels very
>  > >> bad to dismiss them without discussion. However, I'm wondering if
>  > >> there's anyone out there planning on implementing OGP over XMPP?
>  > >
>  > >
>  > > Asking the question in this form creates a bit of a false dichotomy.
>  > > HTTP(S) and XMPP cover different areas of the solution space, so they are
>  > > not simple alternatives.  It's better to first disentangle the
> requirements,
>  > > and then see what is applicable to each part.
>  >
>  > mmm.. i hate to say it morgaine, but i disagree. both HTTP(S) and XMPP
>  > can be used to carry application state changes.
>  >
>  > but i do agree we need to be clear about the messaging requirements.
>  >
>  >
>  > >
>  > > OGP networking requirements (as far as we know them) comprise
> at least three
>  > > different types of functionality, although the 3rd is a matter of some
>  > > debate:
>  > >
>  > > HTTP(S) client-server request/response calls to OGP services.
>  > > Server-client streaming object updates, over an unspecified reliable
>  > > transport.
>  > > HTTP(S) server-client request/response calls to client-side services.
>  >
>  > this list presupposes HTTP(S). i would list them as being a
> little more general:
>  >
>  > 1. the client makes a non-real-time request of the server.
>  > 2. the server makes a non-real-time request of another server.
>  > 3. the client makes a real-time request of the server.
>  > 4. the server sends a real-time update to the client.
>  > 5. the server makes a non-real-time request of the client.
>  >
>  > * all messages SHOULD have the ability to carry meta-data important to
>  > the carrying protocol.
>  > * all messages SHOULD have clear semantics for describing
> endpoints of messages
>  >
>  > an example of 1 would be fetching a texture from an asset server.
>  > there is a proud history of using HTTP to fetch images, which is why i
>  > think there's consensus behind using it for this purpose.
>  >
>  > an example of 2 would be an agent host making a request of a
>  > simulator. like the first example, this is a request-response pattern.
>  >
>  > an example of 3 would be the user presses the 'up' arrow on the
>  > keyboard and expects a change in the avatar's shared state (like it
>  > moves forward.) i would call this a "weak" request response, meaning,
>  > it would be nice if after you pressed the up arrow and the client sent
>  > the "hey, my user just pressed the up arrow" message to the server, if
>  > you would get a response. but... if you wind up not getting a response
>  > for each request, it's not the end of the world. maybe responses could
>  > be acknowledged in a batch response, or the response could be
>  > eliminated all together if the semantics of the message do not REQUIRE
>  > reliable delivery.
>  >
>  > an example of 4 would be the simulator sending object update messages
>  > to the client. these messages MAY have real-time semantics, meaning if
>  > a message is late, it's useless (think VoIP.) so imagine a world,
>  > where the simulator sends each client messages like "object <foo> is
>  > now at location <bar>" or ".. is now rotated <thusly>." if we applied
>  > real-time semantics to these messages, the client would likely be
>  > constructed to update the position (or other physical characteristics)
>  > of an object at a low frame rate, and the experience would be that
>  > those objects would potentially look jerky. if we didn't apply
>  > real-time semantics, the client could have some messages delayed, then
>  > applied rapidly; like maybe five seconds worth of avatar movement is
>  > compressed into two seconds. these are two extremes, and there are
>  > probably a great number of tricks the client could pull to make the
>  > experience look a little nicer.
>  >
>  > i think this is where RTP and XMPP would shine. RTP if we want
>  > real-time semantics, XMPP if we don't. ultimately, however, given the
>  > event queue and long poll techniques, non-real-time messaging from the
>  > server to the client COULD be implemented with HTTP.
>  >
>  > an example of 5 is a server needs to access a sensitive resource
>  > maintained by the client. (reference previous discussions about client
>  > side capabilities.) this is another place where XMPP would likely be
>  > more efficient than HTTP(S), but again, we have an event queue, long
>  > poll and someday might have a standard for bi-directional HTTP.
>  >
>  > ultimately, i think the thinking here is that it's easier to think of
>  > OGP as an application protocol that CAN go over multiple protocols,
>  > then define how it goes over each protocol, then allow the deployer to
>  > choose which protocol it wants to layer OGP messages over modulo some
>  > fixed number of well defined interoperability profiles.
>  >
>  > i think that REQUIRING some messages to go over HTTP (and only over
>  > HTTP) while REQUIRING other messages to go over RTP (and only over
>  > RTP) and yet a third class of messages to go over XMPP (and only over
>  > XMPP) is a recipe for disaster in a protocol. such a beast would be
>  > extremely difficult to implement as it would require implementers and
>  > deployers to integrate multiple transports. in practice, this might
>  > mean integrating apache with ejabberd and with a custom RTP
>  > application. it's not impossible to do, but it would DEFINITELY be
>  > more difficult.
>  >
>  > >
>  > > Type 1 is wonderfully served by HTTP(S), while XMPP leaves a lot to be
>  > > desired in this role, for which it was not designed.
>  > >
>  > > Type 2 is not served naturally by HTTP(S) at all, but because this
>  > > requirement is so common in many types of applications, the
> "web everywhere"
>  > > fraternity has tried to shoehorn this type into HTTP as well, using a
>  > > variety of proposed strategies ranging from COMET's Long Poll
> and Streamed
>  > > Response through to the latest WebSockets, with debateable success.  XMPP
>  > > was designed to serve this type of networking functionality, although its
>  > > targetted application area is somewhat different to that of
> VWs.  Whether it
>  > > would be able to carry object updates with sufficient efficiency would
>  > > require analysis and testing.
>  > >
>  > > Type 3 is poorly specified at present, and it may turn out to be a
>  > > non-existent requirement stemming only from a misguided attempt to poll
>  > > clients instead of receiving streamed asynchronous updates fromthem.  On
>  > > the other hand it may turn out to be an essential networking facility for
>  > > providing symmetry between clients and servers, for instance
> when decoupled
>  > > OGP services run on the client --- this will need much more discussion.
>  > > Assuming for now that there is indeed such a requirement, HTTP
> may serve it
>  > > adequately when run over Reverse HTTP, whereas XMPP would leave
> a lot to be
>  > > desired in this role for which it was not designed.
>  > >
>  > > The above is confusing and fragmented enough, but it gets worse.
>  > >
>  > > There is yet another networking type common to VWs which has
> not even been
>  > > mentioned in our two years of AWG and the 6 months of MMOX deliberations,
>  > > yet is an essential type with its own properties:   streaming of input
>  > > events and objects from client to server.  This is (roughly)
> lumped in with
>  > > Type 2 in current SL and Opensim  implementations, and it appears to be
>  > > destined to be lumped in with Type 1 in OGP, where it fits poorly for
>  > > reasons of latency on realtime inputs.  Neither HTTP(S) nor
> XMPP seem ideal
>  > > for this, although XMPP has a much closer semantic fit owing toits Jabber
>  > > heritage.
>  > >
>  > > So where does this leave us?  Well the first thing that should
> be clear is
>  > > that we are not facing a simple question of  "Should we do it
> all over HTTP
>  > > alone, or also allow for implementation over XMPP?".  The design
>  > > requirements aren't like that at all.  In particular, HTTP(S)
> just doesn't
>  > > fit the Type 2 semantic requirement, and XMPP may not either.
>  > >
>  > > Given that our current task is only to define the charter and not to
>  > > constrain the solutions, I think that any form of wording that
> suggests that
>  > > HTTP(S) alone is sufficient should be avoided, because it is
> not sufficient
>  > > for Type 2 based on our existing experience in virtual worlds. To put it
>  > > bluntly, it's too slow, and the polling model has inadequate latency
>  > > properties.
>  > >
>  > > I suggest therefore that this question of "HTTP(S) and/or XMPP" not be
>  > > addressed in the charter, because the requirements have not yet been
>  > > examined in sufficient detail to be able to make that call. 
> Indeed, Type 2
>  > > may require a different protocol altogether.
>  >
>  > so i respectfully disagree with your assertion that identifying a
>  > standard transport for messages is not useful.
>  >
>  > >
>  > >
>  > > Morgaine.
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > On Thu, Aug 13, 2009 at 1:53 AM, Infinity Linden <infinity@lindenlab.com>
>  > > wrote:
>  > >>
>  > >> Hey people!
>  > >>
>  > >> So... looping back around to some of the comments from the f2f BoF
>  > >> meeting...
>  > >>
>  > >> Original work with OGP used HTTP(S) to carry application messages.
>  > >> There's been enough talk about alternate transports that it feels very
>  > >> bad to dismiss them without discussion. However, I'm wondering if
>  > >> there's anyone out there planning on implementing OGP over XMPP?
>  > >>
>  > >> The reason I ask is that a number of us who worked on the early
>  > >> pre-IETF interop trials are heavily invested in HTTP(S). Though i
>  > >> can't speak for everyone involved, i would anticipate resistance to
>  > >> mandating a new transport. HTTP(S) has it's weaknesses as a transport,
>  > >> to be sure, but it's a well deployed and well understood protocol with
>  > >> a mature tool chain. This makes it attractive to many people.
>  > >>
>  > >> On the other hand, if someone else thinks they want to produce an OGP
>  > >> implementation over XMPP, that seems really cool. But if no one's
>  > >> going to implement it, an argument could be made that putting the
>  > >> effort into specifying it would be a waste of time. On yet another
>  > >> hand, going through the exercise of figuring out what aspects of HTTP
>  > >> are required to transport OGP messages might reveal subtle
>  > >> dependencies between components. Back on the other hand again, can we
>  > >> do this without re-writing BCP56?
>  > >>
>  > >> So I was thinking of this as a proposal:
>  > >>
>  > >> If there is strong interest in implementing OGP over XMPP, let's
>  > >> mention that it's an "officially supported" transport in the charter.
>  > >> (for some definition of the words "officially supported.")
>  > >>
>  > >> If there's not strong interest in implementing OGP over XMPP, let's
>  > >> not put it in the charter.
>  > >>
>  > >> In either case, I think there's sufficient justification for
>  > >> describing the set of requirements OGP makes on it's transport. For
>  > >> instance, does it REQUIRE request/response semantics? (i.e. - if i'm
>  > >> writing a compliant server layering OGP over XMPP, and i receive an
>  > >> OGP "request" in an XML stanza, am i REQUIRED to send a response?)
>  > >> Or... does it REQUIRE specific content negotiation semantics? (i.e. -
>  > >> do we need to explicitly describe or reference a technique for
>  > >> identifying the content type of a response in XMPP?) Or... does the
>  > >> protocol explicitly depend on caching behavior of some HTTP proxies?
>  > >> if so, how? etc. etc.
>  > >>
>  > >> -sincerely
>  > >> -meadhbh
>  > >> _______________________________________________
>  > >> ogpx mailing list
>  > >> ogpx@ietf.org
>  > >> https://www.ietf.org/mailman/listinfo/ogpx
>  > >
>  > >
>  > > _______________________________________________
>  > > ogpx mailing list
>  > > ogpx@ietf.org
>  > > https://www.ietf.org/mailman/listinfo/ogpx
>  > >
>  > >
>  > _______________________________________________
>  > ogpx mailing list
>  > ogpx@ietf.org
>  > https://www.ietf.org/mailman/listinfo/ogpx
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
 --=_alternative 004D693D85257616_=-- From alexey.melnikov@isode.com Tue Aug 18 09:52:53 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B665E28C2F0 for ; Tue, 18 Aug 2009 09:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HX2bY+9S0zB for ; Tue, 18 Aug 2009 09:52:53 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5C2CD28C28E for ; Tue, 18 Aug 2009 09:52:50 -0700 (PDT) Received: from [172.16.2.109] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 18 Aug 2009 17:52:54 +0100 Message-ID: <4A8ADC4D.3080900@isode.com> Date: Tue, 18 Aug 2009 17:52:29 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: tk@research.att.com References: <3a880e2c0908121753s34bacba7k59fae708752d3d6a@mail.gmail.com> <19082.38320.554039.749475@crucible.client.research.att.com> In-Reply-To: <19082.38320.554039.749475@crucible.client.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Meadhbh Siobhan , ogpx@ietf.org Subject: Re: [ogpx] HTTP(S) and XMPP as transports of OGP application layer messages X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 16:52:53 -0000 thomas kirk wrote: >in favor of leaving open the possibility of alternative transports, so >even if HTTP(S) is the preferred mapping, it would be worthwhile to >define a core OGP protocol that's independent of a concrete transport, >and specify the HTTP(S) mapping separately, in the manner that >BEEP (for example) makes this distinction (rfc3080, 3081). > As well as EPP and several others. >The core protocol can express requirements and assumptions about >the transport abstractly; separating its specification leaves >open the possibility of future mappings, and makes explicit >(and probably simplifies) the ways that OGP depends on underlying >service. Given the historical bias, seems reasonable to propose >at least an HTTP mapping, but without precluding others. > I agree that this is a good idea. From josh@lindenlab.com Wed Aug 19 12:06:08 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF9E3A6ADD for ; Wed, 19 Aug 2009 12:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMECUSr0d1na for ; Wed, 19 Aug 2009 12:06:07 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id D478A3A6A25 for ; Wed, 19 Aug 2009 12:06:06 -0700 (PDT) Received: by vws34 with SMTP id 34so4140463vws.31 for ; Wed, 19 Aug 2009 12:06:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.103.197 with SMTP id l5mr9438400vco.34.1250708769117; Wed, 19 Aug 2009 12:06:09 -0700 (PDT) Date: Wed, 19 Aug 2009 12:06:09 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2009 19:06:08 -0000 Howdy, folks. Please find attached the latest draft of the proposed OGPX working group charter. It incorporates feedback from many list and face-to-face meeting participants. I think it's much closer to a document that reflects the group consensus. There are a few points, we may want to comment on separately: 1. The Name. We're still using the name OGPX in this draft. There has been much discussion about other names, but we're not at consensus yet. When we have agreement on a new name, it's easy enough to do a search and replace in the document before submitting it for consideration. 2. The Mailing List. Since we're not at consensus on a name yet, I recommend we continue to us the ogpx@ietf.org mailing list for the time being. When we've selected a new name, and after a working group is approved, we can request a mailing list with the same name as the working group. Again, we can just simply do a search and replace after we have consensus on the name. 3. Description of the Group's Work. The first two paragraphs in the description outline the scope of the working group's efforts. The intent is to briefly describe the group's work to people outside the working group and to "draw a line in the sand" regarding the group's focus (so we don't experience scope creep.) This revision defines terms as they are introduced. It was thought that this approach made for easier reading than having a separate glossary section. 4. Previous Work. Several people have commented that the charter should be explicit regarding what documents we think we're starting from. There is a list of related internet drafts in this draft to meet this requirement. 5. Selecting a Transport. We added verbiage supporting the idea that OGP is transport agnostic, and that we should somewhere describe how OGP uses it's transports and which features it needs. It also lists HTTP(S) as the protocol of choice for OGP messages. 6. Objectives. There is a list of specific objectives, defined in terms of the problem domain. This list is thought to be roughly complete at the moment. The process of adding objectives or refactoring them after working group formation is non-trivial, but not impossible. But, we should have agreement that the objectives are an honest assessment of what we think we need to be working on. 7. Milestone Dates. The dates listed below may be a touch optimistic. They may need to be massaged before the charter is submitted to the IESG. Here is the draft charter... Working Group Name: =C2=A0Open Grid Protocol (OGPX) Chairs: =C2=A0TBD Area and Area Directors: =C2=A0Applications Area =C2=A0Lisa Dusseault =C2=A0Alexey Melnikov Responsible Area Director: =C2=A0TBD Mailing List: =C2=A0ogpx@ietf.org =C2=A0http://www.ietf.org/mailman/listinfo/ogpx Description of Working Group: The working group will define the Open Grid Protocol (OGP) for collaborativ= e 3-dimensional virtual =C2=A0worlds. The protocol =C2=A0permits users to =C2= =A0interact with each other while represented as "avatars," or digital representations of th= e user. Within a =C2=A0single virtual world, avatars exist in =C2=A0at most o= ne location in a shared =C2=A0virtual space. Conforming client applications =C2=A0use t= he protocol to =C2=A0manipulate and move =C2=A0the user's =C2=A0avatar, create =C2=A0ob= jects in =C2=A0the virtual world, =C2=A0interact with =C2=A0other users =C2=A0and their =C2=A0surround= ings and =C2=A0consume and create media and =C2=A0information from sources inside and =C2=A0outside th= eir virtual world. Adjacent =C2=A0locations in =C2=A0virtual worlds =C2=A0accessible by =C2=A0= this protocol =C2=A0may be explicitly partitioned =C2=A0into "regions" =C2=A0to facilitate the =C2=A0c= omputational and communication =C2=A0 load =C2=A0 balancing =C2=A0 =C2=A0required =C2=A0 to = =C2=A0 simulate =C2=A0 the =C2=A0 virtual environment. =C2=A0Such virtual =C2=A0worlds may =C2=A0consist of =C2=A0reg= ions =C2=A0administered by distinct organizations. Though these virtual worlds may be partitioned, the= y remain "un-sharded;" all inhabitants and objects in a particular location i= n the virtual =C2=A0world may initiate =C2=A0interaction with all other =C2= =A0inhabitants and objects in that =C2=A0location; and, service endpoint addresses =C2=A0refer= to at most one location. =C2=A0The state of the =C2=A0virtual world is independent =C2= =A0of the client applications that access it and may persist between user sessions. The protocol defined by this =C2=A0group will carry information about the v= irtual environment, its =C2=A0contents and its =C2=A0inhabitants. It is an =C2=A0a= pplication layer protocol, =C2=A0independent of =C2=A0transport, =C2=A0based partially =C2= =A0on these =C2=A0previously published internet drafts: =C2=A0* http://tools.ietf.org/html/draft-hamrick-ogp-intro =C2=A0* http://tools.ietf.org/html/draft-hamrick-llsd =C2=A0* http://tools.ietf.org/html/draft-hamrick-ogp-auth =C2=A0* http://tools.ietf.org/html/draft-hamrick-ogp-launch =C2=A0* http://tools.ietf.org/html/draft-lentczner-ogp-base =C2=A0* http://tools.ietf.org/html/draft-levine-ogp-clientcap =C2=A0* http://tools.ietf.org/html/draft-levine-ogp-layering The protocol should describe interaction semantics for these virtual worlds= , independent of transport, leveraging =C2=A0existing standards where practic= al. It should =C2=A0 define =C2=A0 interoperability =C2=A0expectations =C2=A0 for = =C2=A0 server =C2=A0to =C2=A0 server interactions as =C2=A0well as client-server interactions. Though =C2=A0the = protocol is independent =C2=A0of transport, =C2=A0early interoperability =C2=A0trials u= sed =C2=A0HTTP(S) for non-real-time messages. The working group will define specific features tha= t must be replicated in other transports and will define the use of HTTP(S) a= s a transport of protocol messages. Foundational components of the protocol include the publication of: =C2=A0* an =C2=A0abstract =C2=A0type =C2=A0system, =C2=A0suitable =C2=A0for= =C2=A0describing =C2=A0the =C2=A0application =C2=A0 =C2=A0protocol in an implementation neutral manner, =C2=A0* a =C2=A0security model describing =C2=A0trust relationships =C2=A0b= etween participating =C2=A0 =C2=A0entities, =C2=A0* guidelines for =C2=A0the use =C2=A0of existing authentication =C2= =A0and confidentiality =C2=A0 =C2=A0mechanisms, =C2=A0* an application-layer protocol for =C2=A0establishing the user's ava= tar in the =C2=A0 =C2=A0virtual world, =C2=A0* an =C2=A0application-layer =C2=A0protocol =C2=A0for =C2=A0moving = =C2=A0a =C2=A0user's =C2=A0avatar =C2=A0between =C2=A0 =C2=A0adjacent and remote locations in the virtual world, =C2=A0* format descriptions for objects and avatars in a virtual world, and =C2=A0* an =C2=A0application-layer protocol =C2=A0for identifying =C2=A0age= nts, =C2=A0and requesting =C2=A0 =C2=A0information about them. Goals and Milestones: =C2=A0* October 2009 =C2=A0"Introduction and Goals" =C2=A0to the IESG as = =C2=A0an Informational =C2=A0 =C2=A0RFC =C2=A0* October =C2=A02009 "Abstract =C2=A0Type =C2=A0System for =C2=A0the = =C2=A0Transmission of =C2=A0Dynamic =C2=A0 =C2=A0Structured Data" to the IESG as Proposed Standard =C2=A0* October 2010 =C2=A0"Foundational Concepts and Transport =C2=A0Expec= tations" to the =C2=A0 =C2=A0IESG as Proposed Standard =C2=A0* February 2010 =C2=A0"Guidelines for =C2=A0Host Authentication" to = =C2=A0the IESG =C2=A0as an =C2=A0 =C2=A0Informational RFC =C2=A0* February 2010 "Service Establishment" to the IESG as Proposed Stand= ard =C2=A0* February =C2=A02010 "Client =C2=A0Application Launch =C2=A0Message"= =C2=A0to the =C2=A0IESG as =C2=A0an =C2=A0 Informational RFC =C2=A0* February 2010 "Simulation Presence Establishment" to the IESG as Pr= oposed =C2=A0 Standard =C2=A0* June 2010 "Primitive Object Format" to the IESG as Proposed Standar= d =C2=A0* June 2010 "Digital Asset Access" to the IESG as Proposed Standard =C2=A0* June 2010 "Entity Identifiers" to the IESG as Proposed standard From morgaine.dinova@googlemail.com Wed Aug 19 17:05:20 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275F93A6AF3 for ; Wed, 19 Aug 2009 17:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfm809OzNNq9 for ; Wed, 19 Aug 2009 17:05:18 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 74A083A6D63 for ; Wed, 19 Aug 2009 17:05:17 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so1106712eye.31 for ; Wed, 19 Aug 2009 17:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=M1YcNxd4AK+3WxJ8AshP8/CMXRoqw6we+KR7No2AiJs=; b=vLFoTqRx9SIldBibYK/hECZNxbc64QUewVI38ObamMLzzaqn5xpmT75hdTLHMtmOEY uj6jkKv3nOQN+eUeZ2SkYhElQhJRAxrqF9lVEqQZfe7flGONiW2xHhVN07L8uhybM2yA mmIIWFI2s7OpCdWLMU9LCjWh3Yk2pBLccc75E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vMr4OQbmXGUCIpH504LU4m6JPnXzxU8Dmkt2Wf7CDag+/BpSy2GLv2Joe5PQ2vvvSZ DbM3db+VnCiTyABtG75WGEKKesoEktlV3NwRxV++WNwDFAzLRoqV6sh0Snyp0PaxOC+h JHf0iMwbX2GsusZv1zF9DMiYunxXhywoj+lN4= MIME-Version: 1.0 Received: by 10.210.137.4 with SMTP id k4mr6258239ebd.89.1250726718595; Wed, 19 Aug 2009 17:05:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Aug 2009 01:05:17 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174c1820c5ed440471878152 Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 00:05:20 -0000 --0015174c1820c5ed440471878152 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Joshua, This latest draft of the charter reads quite well, but it seems to be missing an opening paragraph without which it is easy to misinterpret the purpose of the workgroup and of the protocol. That opening paragraph should be something like this: "This following work is aimed at defining a protocol for the integration of individual regions into a single virtual world, and providing client applications with access to these. Interoperation between such a virtual world and any other virtual world is outside of the scope of this protocol." Without this introduction, it is easy to mistake OGPX for a VW interop group. After all, it follows nearly two years of discussions about interop between worlds in the Architecture Working Group within Second Life, and it follows 6 months of work in the IETF MMOX group which was specifically targetting interoperation between virtual worlds, and it follows a MMOX BoF in which numerous participants (of which Lindens were only one) discussed interop between worlds, and finally, it follows a decision to partition off a new workgroup from MMOX so that its scope can be limited to interoperation between SL-like worlds alone. As it turns out, this new workgroup is not intending to address interop between SL-like worlds at all, but only to integrate individual regions into an existing world, which is extremely different. As the new draft charter describes well, OGPX is dedicated to growing walled gardens by addition of new regions, and it is not concerned with interoperation between such walled gardens. That should be made immediately clear in the introduction --- it is I think this group's main statement of scope, and I assume that our Area Directors will encourage such clarity. I recommend my opening paragraph above to accomplish this. On a more general note ... In addition to making the above clear, what's going to be done about interop between SL-like worlds? There are already many SL-compatible Opensim-based grids, and they currently believe that Linden Lab is defining OGP to interoperate with them. Clearly they are badly mistaken, but their need for interop still remains. Morgaine. ============================ On Wed, Aug 19, 2009 at 8:06 PM, Joshua Bell wrote: > Howdy, folks. > > Please find attached the latest draft of the proposed OGPX working > group charter. It incorporates feedback from many list and > face-to-face meeting participants. I think it's much closer to a > document that reflects the group consensus. There are a few points, we > may want to comment on separately: > > 1. The Name. We're still using the name OGPX in this draft. There has > been much discussion about other names, but we're not at consensus > yet. When we have agreement on a new name, it's easy enough to do a > search and replace in the document before submitting it for > consideration. > > 2. The Mailing List. Since we're not at consensus on a name yet, I > recommend we continue to us the ogpx@ietf.org mailing list for the > time being. When we've selected a new name, and after a working group > is approved, we can request a mailing list with the same name as the > working group. Again, we can just simply do a search and replace after > we have consensus on the name. > > 3. Description of the Group's Work. The first two paragraphs in the > description outline the scope of the working group's efforts. The > intent is to briefly describe the group's work to people outside the > working group and to "draw a line in the sand" regarding the > group's focus (so we don't experience scope creep.) This revision > defines terms as they are introduced. It was thought that this > approach made for easier reading than having a separate glossary > section. > > 4. Previous Work. Several people have commented that the charter > should be explicit regarding what documents we think we're starting > from. There is a list of related internet drafts in this draft to meet > this requirement. > > 5. Selecting a Transport. We added verbiage supporting the idea that > OGP is transport agnostic, and that we should somewhere describe how > OGP uses it's transports and which features it needs. It also lists > HTTP(S) as the protocol of choice for OGP messages. > > 6. Objectives. There is a list of specific objectives, defined in > terms of the problem domain. This list is thought to be roughly > complete at the moment. The process of adding objectives or > refactoring them after working group formation is non-trivial, but not > impossible. But, we should have agreement that the objectives are an > honest assessment of what we think we need to be working on. > > 7. Milestone Dates. The dates listed below may be a touch optimistic. > They may need to be massaged before the charter is submitted to the > IESG. > > Here is the draft charter... > > > Working Group Name: > > Open Grid Protocol (OGPX) > > Chairs: > > TBD > > Area and Area Directors: > > Applications Area > > Lisa Dusseault > Alexey Melnikov > > Responsible Area Director: > > TBD > > Mailing List: > > ogpx@ietf.org > http://www.ietf.org/mailman/listinfo/ogpx > > Description of Working Group: > > The working group will define the Open Grid Protocol (OGP) for collaborative > 3-dimensional virtual worlds. The protocol permits users to interact with > each other while represented as "avatars," or digital representations of the > user. Within a single virtual world, avatars exist in at most one location > in a shared virtual space. Conforming client applications use the protocol > to manipulate and move the user's avatar, create objects in the virtual > world, interact with other users and their surroundings and consume and > create media and information from sources inside and outside their virtual > world. > > Adjacent locations in virtual worlds accessible by this protocol may be > explicitly partitioned into "regions" to facilitate the computational and > communication load balancing required to simulate the virtual > environment. Such virtual worlds may consist of regions administered by > distinct organizations. Though these virtual worlds may be partitioned, they > remain "un-sharded;" all inhabitants and objects in a particular location in > the virtual world may initiate interaction with all other inhabitants and > objects in that location; and, service endpoint addresses refer to at most > one location. The state of the virtual world is independent of the client > applications that access it and may persist between user sessions. > > The protocol defined by this group will carry information about the virtual > environment, its contents and its inhabitants. It is an application layer > protocol, independent of transport, based partially on these previously > published internet drafts: > > * http://tools.ietf.org/html/draft-hamrick-ogp-intro > * http://tools.ietf.org/html/draft-hamrick-llsd > * http://tools.ietf.org/html/draft-hamrick-ogp-auth > * http://tools.ietf.org/html/draft-hamrick-ogp-launch > * http://tools.ietf.org/html/draft-lentczner-ogp-base > * http://tools.ietf.org/html/draft-levine-ogp-clientcap > * http://tools.ietf.org/html/draft-levine-ogp-layering > > The protocol should describe interaction semantics for these virtual worlds, > independent of transport, leveraging existing standards where practical. It > should define interoperability expectations for server to server > interactions as well as client-server interactions. Though the protocol is > independent of transport, early interoperability trials used HTTP(S) for > non-real-time messages. The working group will define specific features that > must be replicated in other transports and will define the use of HTTP(S) as > a transport of protocol messages. > > Foundational components of the protocol include the publication of: > > * an abstract type system, suitable for describing the application > protocol in an implementation neutral manner, > > * a security model describing trust relationships between participating > entities, > > * guidelines for the use of existing authentication and confidentiality > mechanisms, > > * an application-layer protocol for establishing the user's avatar in the > virtual world, > > * an application-layer protocol for moving a user's avatar between > adjacent and remote locations in the virtual world, > > * format descriptions for objects and avatars in a virtual world, and > > * an application-layer protocol for identifying agents, and requesting > information about them. > > Goals and Milestones: > > * October 2009 "Introduction and Goals" to the IESG as an Informational > RFC > > * October 2009 "Abstract Type System for the Transmission of Dynamic > Structured Data" to the IESG as Proposed Standard > > * October 2010 "Foundational Concepts and Transport Expectations" to the > IESG as Proposed Standard > > * February 2010 "Guidelines for Host Authentication" to the IESG as an > Informational RFC > > * February 2010 "Service Establishment" to the IESG as Proposed Standard > > * February 2010 "Client Application Launch Message" to the IESG as an > Informational RFC > > * February 2010 "Simulation Presence Establishment" to the IESG as Proposed > Standard > > * June 2010 "Primitive Object Format" to the IESG as Proposed Standard > > * June 2010 "Digital Asset Access" to the IESG as Proposed Standard > > * June 2010 "Entity Identifiers" to the IESG as Proposed standard > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0015174c1820c5ed440471878152 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Joshua,

This latest draft of the charter reads quite well, but it se= ems to be missing an opening paragraph without which it is easy to misinter= pret the purpose of the workgroup and of the protocol. =A0That opening para= graph should be something like this:

"This following work is aimed at= defining a protocol for the integration of individual regions into a singl= e virtual world, and providing client applications with access to these.=A0= Interoperation between such a virtual world and any other virtual world is= outside of the scope of this protocol."


Without this introduction, it is easy to mistake OGPX for a V= W interop group.

After all, it follows nearly two years of discussio= ns about interop between worlds in the Architecture Working Group within Se= cond Life, and it follows 6 months of work in the IETF MMOX group which was= specifically targetting interoperation between virtual worlds, and it foll= ows a MMOX BoF in which numerous participants (of which Lindens were only o= ne) discussed interop between worlds, and finally, it follows a decision to= partition off a new workgroup from MMOX so that its scope can be limited t= o interoperation between SL-like worlds alone.

As it turns out, this new workgroup is not intending to address interop= between SL-like worlds at all, but only to integrate individual regions in= to an existing world, which is extremely different.=A0 As the new draft cha= rter describes well, OGPX is dedicated to growing walled gardens by additio= n of new regions, and it is not concerned with interoperation between such = walled gardens.

That should be made immediately clear in the introduction --- it is I t= hink this group's main statement of scope, and I assume that our Area D= irectors will encourage such clarity.=A0 I recommend my opening paragraph a= bove to accomplish this.

On a more general note ...

In addition to making the above clear= , what's going to be done about interop between SL-like worlds?=A0 Ther= e are already many SL-compatible Opensim-based grids, and they currently be= lieve that Linden Lab is defining OGP to interoperate with them.=A0 Clearly= they are badly mistaken, but their need for interop still remains.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Wed, Aug 19, = 2009 at 8:06 PM, Joshua Bell<josh@= lindenlab.com> wrote:
> Howdy, folks.
>
> Please find attached the latest draft of the proposed OGPX working
= > group charter. It incorporates feedback from many list and
> fac= e-to-face meeting participants. I think it's much closer to a
> d= ocument that reflects the group consensus. There are a few points, we
> may want to comment on separately:
>
> 1. The Name. We'= ;re still using the name OGPX in this draft. There has
> been much di= scussion about other names, but we're not at consensus
> yet. Whe= n we have agreement on a new name, it's easy enough to do a
> search and replace in the document before submitting it for
> co= nsideration.
>
> 2. The Mailing List. Since we're not at co= nsensus on a name yet, I
> recommend we continue to us the ogpx@ietf.org mailing list for the
> time being. When we've selected a new name, and after a working gr= oup
> is approved, we can request a mailing list with the same name a= s the
> working group. Again, we can just simply do a search and repl= ace after
> we have consensus on the name.
>
> 3. Description of the G= roup's Work. The first two paragraphs in the
> description outlin= e the scope of the working group's efforts. The
> intent is to br= iefly describe the group's work to people outside the
> working group and to "draw a line in the sand" regarding the=
> group's focus (so we don't experience scope creep.) This r= evision
> defines terms as they are introduced. It was thought that t= his
> approach made for easier reading than having a separate glossary
&g= t; section.
>
> 4. Previous Work. Several people have commented= that the charter
> should be explicit regarding what documents we th= ink we're starting
> from. There is a list of related internet drafts in this draft to meet=
> this requirement.
>
> 5. Selecting a Transport. We add= ed verbiage supporting the idea that
> OGP is transport agnostic, and= that we should somewhere describe how
> OGP uses it's transports and which features it needs. It also list= s
> HTTP(S) as the protocol of choice for OGP messages.
>
&g= t; 6. Objectives. There is a list of specific objectives, defined in
> terms of the problem domain. This list is thought to be roughly
>= ; complete at the moment. The process of adding objectives or
> refac= toring them after working group formation is non-trivial, but not
> i= mpossible. But, we should have agreement that the objectives are an
> honest assessment of what we think we need to be working on.
>> 7. Milestone Dates. The dates listed below may be a touch optimistic= .
> They may need to be massaged before the charter is submitted to t= he
> IESG.
>
> Here is the draft charter...
>
>
= > Working Group Name:
>
> =A0Open Grid Protocol (OGPX)
&g= t;
> Chairs:
>
> =A0TBD
>
> Area and Area Dir= ectors:
>
> =A0Applications Area
>
> =A0Lisa Dusseault <lisa.dusseault@gmail.com>> =A0Alexey Melnikov <= alexey.melnikov@isode.com>
>
> Responsible Area Director:
>
> =A0TBD
>
&= gt; Mailing List:
>
> =A0ogpx@= ietf.org
> =A0http://www.ietf.org/mailman/listinfo/ogpx
>
> Description of Working Group:
>
> The working grou= p will define the Open Grid Protocol (OGP) for collaborative
> 3-dime= nsional virtual =A0worlds. The protocol =A0permits users to =A0interact wit= h
> each other while represented as "avatars," or digital repres= entations of the
> user. Within a =A0single virtual world, avatars ex= ist in =A0at most one location
> in a shared =A0virtual space. Confor= ming client applications =A0use the protocol
> to =A0manipulate and move =A0the user's =A0avatar, create =A0objec= ts in =A0the virtual
> world, =A0interact with =A0other users =A0and = their =A0surroundings and =A0consume and
> create media and =A0inform= ation from sources inside and =A0outside their virtual
> world.
>
> Adjacent =A0locations in =A0virtual worlds =A0a= ccessible by =A0this protocol =A0may be
> explicitly partitioned =A0i= nto "regions" =A0to facilitate the =A0computational and
> c= ommunication =A0 load =A0 balancing =A0 =A0required =A0 to =A0 simulate =A0= the =A0 virtual
> environment. =A0Such virtual =A0worlds may =A0consist of =A0regions = =A0administered by
> distinct organizations. Though these virtual wor= lds may be partitioned, they
> remain "un-sharded;" all inh= abitants and objects in a particular location in
> the virtual =A0world may initiate =A0interaction with all other =A0inh= abitants and
> objects in that =A0location; and, service endpoint add= resses =A0refer to at most
> one location. =A0The state of the =A0vir= tual world is independent =A0of the client
> applications that access it and may persist between user sessions.
= >
> The protocol defined by this =A0group will carry information a= bout the virtual
> environment, its =A0contents and its =A0inhabitant= s. It is an =A0application layer
> protocol, =A0independent of =A0transport, =A0based partially =A0on the= se =A0previously
> published internet drafts:
>
> =A0* http://tools.i= etf.org/html/draft-hamrick-ogp-intro
> =A0* http://= tools.ietf.org/html/draft-hamrick-llsd
> =A0* http://tools.ietf.org/html/draft= -hamrick-ogp-auth
> =A0* h= ttp://tools.ietf.org/html/draft-hamrick-ogp-launch
> =A0* http://tools.ietf.= org/html/draft-lentczner-ogp-base
> =A0* http://tools.ietf.org/html/draft-levine-ogp-clientcap
> =A0* http://tools.= ietf.org/html/draft-levine-ogp-layering
>
> The protocol should describe interaction semantics for these v= irtual worlds,
> independent of transport, leveraging =A0existing sta= ndards where practical. It
> should =A0 define =A0 interoperability = =A0expectations =A0 for =A0 server =A0to =A0 server
> interactions as =A0well as client-server interactions. Though =A0the p= rotocol is
> independent =A0of transport, =A0early interoperability = =A0trials used =A0HTTP(S) for
> non-real-time messages. The working g= roup will define specific features that
> must be replicated in other transports and will define the use of HTTP= (S) as
> a transport of protocol messages.
>
> Foundation= al components of the protocol include the publication of:
>
> = =A0* an =A0abstract =A0type =A0system, =A0suitable =A0for =A0describing =A0= the =A0application
> =A0 =A0protocol in an implementation neutral manner,
>
> = =A0* a =A0security model describing =A0trust relationships =A0between parti= cipating
> =A0 =A0entities,
>
> =A0* guidelines for =A0th= e use =A0of existing authentication =A0and confidentiality
> =A0 =A0mechanisms,
>
> =A0* an application-layer protocol = for =A0establishing the user's avatar in the
> =A0 =A0virtual wor= ld,
>
> =A0* an =A0application-layer =A0protocol =A0for =A0movi= ng =A0a =A0user's =A0avatar =A0between
> =A0 =A0adjacent and remote locations in the virtual world,
>
= > =A0* format descriptions for objects and avatars in a virtual world, a= nd
>
> =A0* an =A0application-layer protocol =A0for identifying= =A0agents, =A0and requesting
> =A0 =A0information about them.
>
> Goals and Milestones:>
> =A0* October 2009 =A0"Introduction and Goals" =A0t= o the IESG as =A0an Informational
> =A0 =A0RFC
>
> =A0* O= ctober =A02009 "Abstract =A0Type =A0System for =A0the =A0Transmission = of =A0Dynamic
> =A0 =A0Structured Data" to the IESG as Proposed Standard
><= br>> =A0* October 2010 =A0"Foundational Concepts and Transport =A0E= xpectations" to the
> =A0 =A0IESG as Proposed Standard
>> =A0* February 2010 =A0"Guidelines for =A0Host Authentication&qu= ot; to =A0the IESG =A0as an
> =A0 =A0Informational RFC
>
> =A0* February 2010 "Serv= ice Establishment" to the IESG as Proposed Standard
>
> = =A0* February =A02010 "Client =A0Application Launch =A0Message" = =A0to the =A0IESG as =A0an
> =A0 Informational RFC
>
> =A0* February 2010 "Simulat= ion Presence Establishment" to the IESG as Proposed
> =A0 Standa= rd
>
> =A0* June 2010 "Primitive Object Format" to th= e IESG as Proposed Standard
>
> =A0* June 2010 "Digital Asset Access" to the IESG as= Proposed Standard
>
> =A0* June 2010 "Entity Identifiers&= quot; to the IESG as Proposed standard
> ____________________________= ___________________
> ogpx mailing list
> ogpx@ietf.o= rg
> https= ://www.ietf.org/mailman/listinfo/ogpx
>

--0015174c1820c5ed440471878152-- From infinity@lindenlab.com Wed Aug 19 17:38:02 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 434EE28C120 for ; Wed, 19 Aug 2009 17:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.785 X-Spam-Level: X-Spam-Status: No, score=-1.785 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IBREi6teBsn for ; Wed, 19 Aug 2009 17:38:01 -0700 (PDT) Received: from mail-px0-f175.google.com (mail-px0-f175.google.com [209.85.216.175]) by core3.amsl.com (Postfix) with ESMTP id 0B8E33A689B for ; Wed, 19 Aug 2009 17:38:01 -0700 (PDT) Received: by pxi5 with SMTP id 5so2974678pxi.6 for ; Wed, 19 Aug 2009 17:38:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.248.6 with SMTP id v6mr1428087wfh.348.1250728684459; Wed, 19 Aug 2009 17:38:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Aug 2009 17:38:04 -0700 Message-ID: <3a880e2c0908191738x69235df3t4a42cdd5193ef5f7@mail.gmail.com> From: Infinity Linden To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 00:38:02 -0000 hunh? if it makes sense for Linden to interoperate with OSGrid, and both parties want to do it, i think it will happen irrespective of the language in the charter. this work is not intended to be exclusively "the protocol that people use to communicate with Second Life." it is the protocol systems use to participate in a virtual world simulation. it makes no statement about which virtual world participating systems interact with. by their nature, open protocols do not limit participation to fixed systems. adding language to the charter that implies this is the case is inappropriate and inaccurate. On Wed, Aug 19, 2009 at 5:05 PM, Morgaine w= rote: > Joshua, > > This latest draft of the charter reads quite well, but it seems to be > missing an opening paragraph without which it is easy to misinterpret the > purpose of the workgroup and of the protocol. =A0That opening paragraph s= hould > be something like this: > > "This following work is aimed at defining a protocol for the integration = of > individual regions into a single virtual world, and providing client > applications with access to these.=A0 Interoperation between such a virtu= al > world and any other virtual world is outside of the scope of this protoco= l." > > > Without this introduction, it is easy to mistake OGPX for a VW interop > group. > > After all, it follows nearly two years of discussions about interop betwe= en > worlds in the Architecture Working Group within Second Life, and it follo= ws > 6 months of work in the IETF MMOX group which was specifically targetting > interoperation between virtual worlds, and it follows a MMOX BoF in which > numerous participants (of which Lindens were only one) discussed interop > between worlds, and finally, it follows a decision to partition off a new > workgroup from MMOX so that its scope can be limited to interoperation > between SL-like worlds alone. > > As it turns out, this new workgroup is not intending to address interop > between SL-like worlds at all, but only to integrate individual regions i= nto > an existing world, which is extremely different.=A0 As the new draft char= ter > describes well, OGPX is dedicated to growing walled gardens by addition o= f > new regions, and it is not concerned with interoperation between such wal= led > gardens. > > That should be made immediately clear in the introduction --- it is I thi= nk > this group's main statement of scope, and I assume that our Area Director= s > will encourage such clarity.=A0 I recommend my opening paragraph above to > accomplish this. > > On a more general note ... > > In addition to making the above clear, what's going to be done about inte= rop > between SL-like worlds?=A0 There are already many SL-compatible Opensim-b= ased > grids, and they currently believe that Linden Lab is defining OGP to > interoperate with them.=A0 Clearly they are badly mistaken, but their nee= d for > interop still remains. > > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > On Wed, Aug 19, 2009 at 8:06 PM, Joshua Bell wrote: >> Howdy, folks. >> >> Please find attached the latest draft of the proposed OGPX working >> group charter. It incorporates feedback from many list and >> face-to-face meeting participants. I think it's much closer to a >> document that reflects the group consensus. There are a few points, we >> may want to comment on separately: >> >> 1. The Name. We're still using the name OGPX in this draft. There has >> been much discussion about other names, but we're not at consensus >> yet. When we have agreement on a new name, it's easy enough to do a >> search and replace in the document before submitting it for >> consideration. >> >> 2. The Mailing List. Since we're not at consensus on a name yet, I >> recommend we continue to us the ogpx@ietf.org mailing list for the >> time being. When we've selected a new name, and after a working group >> is approved, we can request a mailing list with the same name as the >> working group. Again, we can just simply do a search and replace after >> we have consensus on the name. >> >> 3. Description of the Group's Work. The first two paragraphs in the >> description outline the scope of the working group's efforts. The >> intent is to briefly describe the group's work to people outside the >> working group and to "draw a line in the sand" regarding the >> group's focus (so we don't experience scope creep.) This revision >> defines terms as they are introduced. It was thought that this >> approach made for easier reading than having a separate glossary >> section. >> >> 4. Previous Work. Several people have commented that the charter >> should be explicit regarding what documents we think we're starting >> from. There is a list of related internet drafts in this draft to meet >> this requirement. >> >> 5. Selecting a Transport. We added verbiage supporting the idea that >> OGP is transport agnostic, and that we should somewhere describe how >> OGP uses it's transports and which features it needs. It also lists >> HTTP(S) as the protocol of choice for OGP messages. >> >> 6. Objectives. There is a list of specific objectives, defined in >> terms of the problem domain. This list is thought to be roughly >> complete at the moment. The process of adding objectives or >> refactoring them after working group formation is non-trivial, but not >> impossible. But, we should have agreement that the objectives are an >> honest assessment of what we think we need to be working on. >> >> 7. Milestone Dates. The dates listed below may be a touch optimistic. >> They may need to be massaged before the charter is submitted to the >> IESG. >> >> Here is the draft charter... >> >> >> Working Group Name: >> >> =A0Open Grid Protocol (OGPX) >> >> Chairs: >> >> =A0TBD >> >> Area and Area Directors: >> >> =A0Applications Area >> >> =A0Lisa Dusseault >> =A0Alexey Melnikov >> >> Responsible Area Director: >> >> =A0TBD >> >> Mailing List: >> >> =A0ogpx@ietf.org >> =A0http://www.ietf.org/mailman/listinfo/ogpx >> >> Description of Working Group: >> >> The working group will define the Open Grid Protocol (OGP) for >> collaborative >> 3-dimensional virtual =A0worlds. The protocol =A0permits users to =A0int= eract >> with >> each other while represented as "avatars," or digital representations of >> the >> user. Within a =A0single virtual world, avatars exist in =A0at most one >> location >> in a shared =A0virtual space. Conforming client applications =A0use the >> protocol >> to =A0manipulate and move =A0the user's =A0avatar, create =A0objects in = =A0the >> virtual >> world, =A0interact with =A0other users =A0and their =A0surroundings and = =A0consume >> and >> create media and =A0information from sources inside and =A0outside their >> virtual >> world. >> >> Adjacent =A0locations in =A0virtual worlds =A0accessible by =A0this prot= ocol =A0may >> be >> explicitly partitioned =A0into "regions" =A0to facilitate the =A0computa= tional >> and >> communication =A0 load =A0 balancing =A0 =A0required =A0 to =A0 simulate= =A0 the >> virtual >> environment. =A0Such virtual =A0worlds may =A0consist of =A0regions =A0a= dministered >> by >> distinct organizations. Though these virtual worlds may be partitioned, >> they >> remain "un-sharded;" all inhabitants and objects in a particular locatio= n >> in >> the virtual =A0world may initiate =A0interaction with all other =A0inhab= itants >> and >> objects in that =A0location; and, service endpoint addresses =A0refer to= at >> most >> one location. =A0The state of the =A0virtual world is independent =A0of = the >> client >> applications that access it and may persist between user sessions. >> >> The protocol defined by this =A0group will carry information about the >> virtual >> environment, its =A0contents and its =A0inhabitants. It is an =A0applica= tion >> layer >> protocol, =A0independent of =A0transport, =A0based partially =A0on these >> =A0previously >> published internet drafts: >> >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-intro >> =A0* http://tools.ietf.org/html/draft-hamrick-llsd >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-auth >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-launch >> =A0* http://tools.ietf.org/html/draft-lentczner-ogp-base >> =A0* http://tools.ietf.org/html/draft-levine-ogp-clientcap >> =A0* http://tools.ietf.org/html/draft-levine-ogp-layering >> >> The protocol should describe interaction semantics for these virtual >> worlds, >> independent of transport, leveraging =A0existing standards where practic= al. >> It >> should =A0 define =A0 interoperability =A0expectations =A0 for =A0 serve= r =A0to >> server >> interactions as =A0well as client-server interactions. Though =A0the pro= tocol >> is >> independent =A0of transport, =A0early interoperability =A0trials used = =A0HTTP(S) >> for >> non-real-time messages. The working group will define specific features >> that >> must be replicated in other transports and will define the use of HTTP(S= ) >> as >> a transport of protocol messages. >> >> Foundational components of the protocol include the publication of: >> >> =A0* an =A0abstract =A0type =A0system, =A0suitable =A0for =A0describing = =A0the >> =A0application >> =A0 =A0protocol in an implementation neutral manner, >> >> =A0* a =A0security model describing =A0trust relationships =A0between >> participating >> =A0 =A0entities, >> >> =A0* guidelines for =A0the use =A0of existing authentication =A0and >> confidentiality >> =A0 =A0mechanisms, >> >> =A0* an application-layer protocol for =A0establishing the user's avatar= in >> the >> =A0 =A0virtual world, >> >> =A0* an =A0application-layer =A0protocol =A0for =A0moving =A0a =A0user's= =A0avatar >> =A0between >> =A0 =A0adjacent and remote locations in the virtual world, >> >> =A0* format descriptions for objects and avatars in a virtual world, and >> >> =A0* an =A0application-layer protocol =A0for identifying =A0agents, =A0a= nd >> requesting >> =A0 =A0information about them. >> >> Goals and Milestones: >> >> =A0* October 2009 =A0"Introduction and Goals" =A0to the IESG as =A0an >> Informational >> =A0 =A0RFC >> >> =A0* October =A02009 "Abstract =A0Type =A0System for =A0the =A0Transmiss= ion of >> =A0Dynamic >> =A0 =A0Structured Data" to the IESG as Proposed Standard >> >> =A0* October 2010 =A0"Foundational Concepts and Transport =A0Expectation= s" to >> the >> =A0 =A0IESG as Proposed Standard >> >> =A0* February 2010 =A0"Guidelines for =A0Host Authentication" to =A0the = IESG =A0as >> an >> =A0 =A0Informational RFC >> >> =A0* February 2010 "Service Establishment" to the IESG as Proposed Stand= ard >> >> =A0* February =A02010 "Client =A0Application Launch =A0Message" =A0to th= e =A0IESG as >> =A0an >> =A0 Informational RFC >> >> =A0* February 2010 "Simulation Presence Establishment" to the IESG as >> Proposed >> =A0 Standard >> >> =A0* June 2010 "Primitive Object Format" to the IESG as Proposed Standar= d >> >> =A0* June 2010 "Digital Asset Access" to the IESG as Proposed Standard >> >> =A0* June 2010 "Entity Identifiers" to the IESG as Proposed standard >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From morgaine.dinova@googlemail.com Wed Aug 19 19:14:47 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10A03A681E for ; Wed, 19 Aug 2009 19:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RzerKvcwcd8 for ; Wed, 19 Aug 2009 19:14:45 -0700 (PDT) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by core3.amsl.com (Postfix) with ESMTP id 65D663A6C87 for ; Wed, 19 Aug 2009 19:14:44 -0700 (PDT) Received: by ewy2 with SMTP id 2so1593746ewy.43 for ; Wed, 19 Aug 2009 19:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=UM/DZaCdEiQ8WZHyjekWy5kupx1bQggbvSb1n/oe5Dw=; b=byNTNEZP+8I/NFwNTCaymJ5gadn+9igOsVWMq9pJ2aXlFlJ+rCLc9SFBeoXbpn2KZa /fpUplrMbFPIRZ15dS3DENPa0WKX6i0x+Fkh8QfJKdDBQgU6UXIAnK5gTBR0pScbcRc0 A0oLLSg6VOkvF5O2HSS5e8s/GTJWuhweU0cTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=gWorntLaoqOupUP9VDtUoZwkuw0/+g477n0Fqy3GjMABswdQrV73eOIipd38sPjxUh AZ1j+9jnbYlreLCT0bbdACrE5EdAoUT7Jhabob8CHepr+AQQ1G6PbuvagbLgbEYTc7oY ZSLaTzmjqH0xbj8TGevbChWYMgMpQFShAbnv0= MIME-Version: 1.0 Received: by 10.210.27.4 with SMTP id a4mr6406008eba.76.1250734486266; Wed, 19 Aug 2009 19:14:46 -0700 (PDT) In-Reply-To: <3a880e2c0908191738x69235df3t4a42cdd5193ef5f7@mail.gmail.com> References: <3a880e2c0908191738x69235df3t4a42cdd5193ef5f7@mail.gmail.com> Date: Thu, 20 Aug 2009 03:14:45 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174bde4cc325d30471895071 Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 02:14:47 -0000 --0015174bde4cc325d30471895071 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Infinity, Linden Lab's interoperation with OSgrid is a matter of company * policy* which is not our business here. We are involved only with defining protocols, which are *mechanisms* that can be used to implement many different policies. You are suggesting that OGP provides no barrier to interop apart from your own local policy, when this is clearly not true. The OGP protocol is not being defined to permit any kind of interop between virtual worlds *at all*. As Joshua's latest charter describes clearly, it is concerned only with the addition of single regions to a given virtual world. It does not address interop between two or more such virtual worlds in any shape or form. Your response therefore completely misses the point that OGP does not provide any means for interop between worlds whatsoever, even when the world operators desire it. It is not a protocol for interoperation between virtual worlds, even when these worlds are identical in architecture. Being clear is important in standards work. Your last comment rejecting clarity in language escapes me at this time. If OGPX does not intend to address interop between virtual worlds, that's a conscious decision and is not something to hide. A protocol that grows a world by adding regions is still a useful protocol, despite providing no interop between worlds. Stating the goal clearly is to everyone's benefit. Morgaine. On Thu, Aug 20, 2009 at 1:38 AM, Infinity Linden wrote: > hunh? if it makes sense for Linden to interoperate with OSGrid, and > both parties want to do it, i think it will happen irrespective of the > language in the charter. this work is not intended to be exclusively > "the protocol that people use to communicate with Second Life." it is > the protocol systems use to participate in a virtual world simulation. > it makes no statement about which virtual world participating systems > interact with. > > by their nature, open protocols do not limit participation to fixed > systems. adding language to the charter that implies this is the case > is inappropriate and inaccurate. > > On Wed, Aug 19, 2009 at 5:05 PM, Morgaine > wrote: > > Joshua, > > > > This latest draft of the charter reads quite well, but it seems to be > > missing an opening paragraph without which it is easy to misinterpret the > > purpose of the workgroup and of the protocol. That opening paragraph > should > > be something like this: > > > > "This following work is aimed at defining a protocol for the integration > of > > individual regions into a single virtual world, and providing client > > applications with access to these. Interoperation between such a virtual > > world and any other virtual world is outside of the scope of this > protocol." > > > > > > Without this introduction, it is easy to mistake OGPX for a VW interop > > group. > > > > After all, it follows nearly two years of discussions about interop > between > > worlds in the Architecture Working Group within Second Life, and it > follows > > 6 months of work in the IETF MMOX group which was specifically targetting > > interoperation between virtual worlds, and it follows a MMOX BoF in which > > numerous participants (of which Lindens were only one) discussed interop > > between worlds, and finally, it follows a decision to partition off a new > > workgroup from MMOX so that its scope can be limited to interoperation > > between SL-like worlds alone. > > > > As it turns out, this new workgroup is not intending to address interop > > between SL-like worlds at all, but only to integrate individual regions > into > > an existing world, which is extremely different. As the new draft > charter > > describes well, OGPX is dedicated to growing walled gardens by addition > of > > new regions, and it is not concerned with interoperation between such > walled > > gardens. > > > > That should be made immediately clear in the introduction --- it is I > think > > this group's main statement of scope, and I assume that our Area > Directors > > will encourage such clarity. I recommend my opening paragraph above to > > accomplish this. > > > > On a more general note ... > > > > In addition to making the above clear, what's going to be done about > interop > > between SL-like worlds? There are already many SL-compatible > Opensim-based > > grids, and they currently believe that Linden Lab is defining OGP to > > interoperate with them. Clearly they are badly mistaken, but their need > for > > interop still remains. > > > > > > Morgaine. > > > > > > > > > > > > ============================ > > > > On Wed, Aug 19, 2009 at 8:06 PM, Joshua Bell wrote: > >> Howdy, folks. > >> > >> Please find attached the latest draft of the proposed OGPX working > >> group charter. It incorporates feedback from many list and > >> face-to-face meeting participants. I think it's much closer to a > >> document that reflects the group consensus. There are a few points, we > >> may want to comment on separately: > >> > >> 1. The Name. We're still using the name OGPX in this draft. There has > >> been much discussion about other names, but we're not at consensus > >> yet. When we have agreement on a new name, it's easy enough to do a > >> search and replace in the document before submitting it for > >> consideration. > >> > >> 2. The Mailing List. Since we're not at consensus on a name yet, I > >> recommend we continue to us the ogpx@ietf.org mailing list for the > >> time being. When we've selected a new name, and after a working group > >> is approved, we can request a mailing list with the same name as the > >> working group. Again, we can just simply do a search and replace after > >> we have consensus on the name. > >> > >> 3. Description of the Group's Work. The first two paragraphs in the > >> description outline the scope of the working group's efforts. The > >> intent is to briefly describe the group's work to people outside the > >> working group and to "draw a line in the sand" regarding the > >> group's focus (so we don't experience scope creep.) This revision > >> defines terms as they are introduced. It was thought that this > >> approach made for easier reading than having a separate glossary > >> section. > >> > >> 4. Previous Work. Several people have commented that the charter > >> should be explicit regarding what documents we think we're starting > >> from. There is a list of related internet drafts in this draft to meet > >> this requirement. > >> > >> 5. Selecting a Transport. We added verbiage supporting the idea that > >> OGP is transport agnostic, and that we should somewhere describe how > >> OGP uses it's transports and which features it needs. It also lists > >> HTTP(S) as the protocol of choice for OGP messages. > >> > >> 6. Objectives. There is a list of specific objectives, defined in > >> terms of the problem domain. This list is thought to be roughly > >> complete at the moment. The process of adding objectives or > >> refactoring them after working group formation is non-trivial, but not > >> impossible. But, we should have agreement that the objectives are an > >> honest assessment of what we think we need to be working on. > >> > >> 7. Milestone Dates. The dates listed below may be a touch optimistic. > >> They may need to be massaged before the charter is submitted to the > >> IESG. > >> > >> Here is the draft charter... > >> > >> > >> Working Group Name: > >> > >> Open Grid Protocol (OGPX) > >> > >> Chairs: > >> > >> TBD > >> > >> Area and Area Directors: > >> > >> Applications Area > >> > >> Lisa Dusseault > >> Alexey Melnikov > >> > >> Responsible Area Director: > >> > >> TBD > >> > >> Mailing List: > >> > >> ogpx@ietf.org > >> http://www.ietf.org/mailman/listinfo/ogpx > >> > >> Description of Working Group: > >> > >> The working group will define the Open Grid Protocol (OGP) for > >> collaborative > >> 3-dimensional virtual worlds. The protocol permits users to interact > >> with > >> each other while represented as "avatars," or digital representations of > >> the > >> user. Within a single virtual world, avatars exist in at most one > >> location > >> in a shared virtual space. Conforming client applications use the > >> protocol > >> to manipulate and move the user's avatar, create objects in the > >> virtual > >> world, interact with other users and their surroundings and consume > >> and > >> create media and information from sources inside and outside their > >> virtual > >> world. > >> > >> Adjacent locations in virtual worlds accessible by this protocol > may > >> be > >> explicitly partitioned into "regions" to facilitate the computational > >> and > >> communication load balancing required to simulate the > >> virtual > >> environment. Such virtual worlds may consist of regions > administered > >> by > >> distinct organizations. Though these virtual worlds may be partitioned, > >> they > >> remain "un-sharded;" all inhabitants and objects in a particular > location > >> in > >> the virtual world may initiate interaction with all other inhabitants > >> and > >> objects in that location; and, service endpoint addresses refer to at > >> most > >> one location. The state of the virtual world is independent of the > >> client > >> applications that access it and may persist between user sessions. > >> > >> The protocol defined by this group will carry information about the > >> virtual > >> environment, its contents and its inhabitants. It is an application > >> layer > >> protocol, independent of transport, based partially on these > >> previously > >> published internet drafts: > >> > >> * http://tools.ietf.org/html/draft-hamrick-ogp-intro > >> * http://tools.ietf.org/html/draft-hamrick-llsd > >> * http://tools.ietf.org/html/draft-hamrick-ogp-auth > >> * http://tools.ietf.org/html/draft-hamrick-ogp-launch > >> * http://tools.ietf.org/html/draft-lentczner-ogp-base > >> * http://tools.ietf.org/html/draft-levine-ogp-clientcap > >> * http://tools.ietf.org/html/draft-levine-ogp-layering > >> > >> The protocol should describe interaction semantics for these virtual > >> worlds, > >> independent of transport, leveraging existing standards where > practical. > >> It > >> should define interoperability expectations for server to > >> server > >> interactions as well as client-server interactions. Though the > protocol > >> is > >> independent of transport, early interoperability trials used HTTP(S) > >> for > >> non-real-time messages. The working group will define specific features > >> that > >> must be replicated in other transports and will define the use of > HTTP(S) > >> as > >> a transport of protocol messages. > >> > >> Foundational components of the protocol include the publication of: > >> > >> * an abstract type system, suitable for describing the > >> application > >> protocol in an implementation neutral manner, > >> > >> * a security model describing trust relationships between > >> participating > >> entities, > >> > >> * guidelines for the use of existing authentication and > >> confidentiality > >> mechanisms, > >> > >> * an application-layer protocol for establishing the user's avatar in > >> the > >> virtual world, > >> > >> * an application-layer protocol for moving a user's avatar > >> between > >> adjacent and remote locations in the virtual world, > >> > >> * format descriptions for objects and avatars in a virtual world, and > >> > >> * an application-layer protocol for identifying agents, and > >> requesting > >> information about them. > >> > >> Goals and Milestones: > >> > >> * October 2009 "Introduction and Goals" to the IESG as an > >> Informational > >> RFC > >> > >> * October 2009 "Abstract Type System for the Transmission of > >> Dynamic > >> Structured Data" to the IESG as Proposed Standard > >> > >> * October 2010 "Foundational Concepts and Transport Expectations" to > >> the > >> IESG as Proposed Standard > >> > >> * February 2010 "Guidelines for Host Authentication" to the IESG as > >> an > >> Informational RFC > >> > >> * February 2010 "Service Establishment" to the IESG as Proposed > Standard > >> > >> * February 2010 "Client Application Launch Message" to the IESG as > >> an > >> Informational RFC > >> > >> * February 2010 "Simulation Presence Establishment" to the IESG as > >> Proposed > >> Standard > >> > >> * June 2010 "Primitive Object Format" to the IESG as Proposed Standard > >> > >> * June 2010 "Digital Asset Access" to the IESG as Proposed Standard > >> > >> * June 2010 "Entity Identifiers" to the IESG as Proposed standard > >> _______________________________________________ > >> ogpx mailing list > >> ogpx@ietf.org > >> https://www.ietf.org/mailman/listinfo/ogpx > >> > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --0015174bde4cc325d30471895071 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Infinity, Linden Lab's interoperation with OSgrid is a matter of compan= y policy which is not our business here.=A0 We are involved only wit= h defining protocols, which are mechanisms that can be used to imple= ment many different policies.=A0 You are suggesting that OGP provides no ba= rrier to interop apart from your own local policy, when this is clearly not= true.

The OGP protocol is not being defined to permit any kind of interop bet= ween virtual worlds at all.=A0 As Joshua's latest charter descri= bes clearly, it is concerned only with the addition of single regions to a = given virtual world.=A0 It does not address interop between two or more suc= h virtual worlds in any shape or form.

Your response therefore completely misses the point that OGP does not p= rovide any means for interop between worlds whatsoever, even when the world= operators desire it.=A0 It is not a protocol for interoperation between vi= rtual worlds, even when these worlds are identical in architecture.=A0 Bein= g clear is important in standards work.

Your last comment rejecting clarity in language escapes me at this time= .

If OGPX does not intend to address interop between virtual worlds,= that's a conscious decision and is not something to hide.=A0 A protoco= l that grows a world by adding regions is still a useful protocol, despite = providing no interop between worlds.=A0 Stating the goal clearly is to ever= yone's benefit.


Morgaine.








On Thu, Aug 20, 2009 at 1:38 AM, Infinity Linden <= ;infinity@lindenlab.com> wrote:
hunh? if it makes= sense for Linden to interoperate with OSGrid, and
both parties want to do it, i think it will happen irrespective of the
language in the charter. this work is not intended to be exclusively
"the protocol that people use to communicate with Second Life." i= t is
the protocol systems use to participate in a virtual world simulation.
it makes no statement about which virtual world participating systems
interact with.

by their nature, open protocols do not limit participation to fixed
systems. adding language to the charter that implies this is the case
is inappropriate and inaccurate.

On Wed, Aug 19, 2009 at 5:05 PM, Morgaine<morgaine.dinova@googlemail.com> wrote:
> Joshua,
>
> This latest draft of the charter reads quite well, but it seems to be<= br> > missing an opening paragraph without which it is easy to misinterpret = the
> purpose of the workgroup and of the protocol. =A0That opening paragrap= h should
> be something like this:
>
> "This following work is aimed at defining a protocol for the inte= gration of
> individual regions into a single virtual world, and providing client > applications with access to these.=A0 Interoperation between such a vi= rtual
> world and any other virtual world is outside of the scope of this prot= ocol."
>
>
> Without this introduction, it is easy to mistake OGPX for a VW interop=
> group.
>
> After all, it follows nearly two years of discussions about interop be= tween
> worlds in the Architecture Working Group within Second Life, and it fo= llows
> 6 months of work in the IETF MMOX group which was specifically targett= ing
> interoperation between virtual worlds, and it follows a MMOX BoF in wh= ich
> numerous participants (of which Lindens were only one) discussed inter= op
> between worlds, and finally, it follows a decision to partition off a = new
> workgroup from MMOX so that its scope can be limited to interoperation=
> between SL-like worlds alone.
>
> As it turns out, this new workgroup is not intending to address intero= p
> between SL-like worlds at all, but only to integrate individual region= s into
> an existing world, which is extremely different.=A0 As the new draft c= harter
> describes well, OGPX is dedicated to growing walled gardens by additio= n of
> new regions, and it is not concerned with interoperation between such = walled
> gardens.
>
> That should be made immediately clear in the introduction --- it is I = think
> this group's main statement of scope, and I assume that our Area D= irectors
> will encourage such clarity.=A0 I recommend my opening paragraph above= to
> accomplish this.
>
> On a more general note ...
>
> In addition to making the above clear, what's going to be done abo= ut interop
> between SL-like worlds?=A0 There are already many SL-compatible Opensi= m-based
> grids, and they currently believe that Linden Lab is defining OGP to > interoperate with them.=A0 Clearly they are badly mistaken, but their = need for
> interop still remains.
>
>
> Morgaine.
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
>
> On Wed, Aug 19, 2009 at 8:06 PM, Joshua Bell<josh@lindenlab.com> wrote:
>> Howdy, folks.
>>
>> Please find attached the latest draft of the proposed OGPX working=
>> group charter. It incorporates feedback from many list and
>> face-to-face meeting participants. I think it's much closer to= a
>> document that reflects the group consensus. There are a few points= , we
>> may want to comment on separately:
>>
>> 1. The Name. We're still using the name OGPX in this draft. Th= ere has
>> been much discussion about other names, but we're not at conse= nsus
>> yet. When we have agreement on a new name, it's easy enough to= do a
>> search and replace in the document before submitting it for
>> consideration.
>>
>> 2. The Mailing List. Since we're not at consensus on a name ye= t, I
>> recommend we continue to us the o= gpx@ietf.org mailing list for the
>> time being. When we've selected a new name, and after a workin= g group
>> is approved, we can request a mailing list with the same name as t= he
>> working group. Again, we can just simply do a search and replace a= fter
>> we have consensus on the name.
>>
>> 3. Description of the Group's Work. The first two paragraphs i= n the
>> description outline the scope of the working group's efforts. = The
>> intent is to briefly describe the group's work to people outsi= de the
>> working group and to "draw a line in the sand" regarding= the
>> group's focus (so we don't experience scope creep.) This r= evision
>> defines terms as they are introduced. It was thought that this
>> approach made for easier reading than having a separate glossary >> section.
>>
>> 4. Previous Work. Several people have commented that the charter >> should be explicit regarding what documents we think we're sta= rting
>> from. There is a list of related internet drafts in this draft to = meet
>> this requirement.
>>
>> 5. Selecting a Transport. We added verbiage supporting the idea th= at
>> OGP is transport agnostic, and that we should somewhere describe h= ow
>> OGP uses it's transports and which features it needs. It also = lists
>> HTTP(S) as the protocol of choice for OGP messages.
>>
>> 6. Objectives. There is a list of specific objectives, defined in<= br> >> terms of the problem domain. This list is thought to be roughly >> complete at the moment. The process of adding objectives or
>> refactoring them after working group formation is non-trivial, but= not
>> impossible. But, we should have agreement that the objectives are = an
>> honest assessment of what we think we need to be working on.
>>
>> 7. Milestone Dates. The dates listed below may be a touch optimist= ic.
>> They may need to be massaged before the charter is submitted to th= e
>> IESG.
>>
>> Here is the draft charter...
>>
>>
>> Working Group Name:
>>
>> =A0Open Grid Protocol (OGPX)
>>
>> Chairs:
>>
>> =A0TBD
>>
>> Area and Area Directors:
>>
>> =A0Applications Area
>>
>> =A0Lisa Dusseault <= lisa.dusseault@gmail.com>
>> =A0Alexey Melnikov <alexey.melnikov@isode.com>
>>
>> Responsible Area Director:
>>
>> =A0TBD
>>
>> Mailing List:
>>
>> =A0ogpx@ietf.org
>> =A0http://www.ietf.org/mailman/listinfo/ogpx
>>
>> Description of Working Group:
>>
>> The working group will define the Open Grid Protocol (OGP) for
>> collaborative
>> 3-dimensional virtual =A0worlds. The protocol =A0permits users to = =A0interact
>> with
>> each other while represented as "avatars," or digital re= presentations of
>> the
>> user. Within a =A0single virtual world, avatars exist in =A0at mos= t one
>> location
>> in a shared =A0virtual space. Conforming client applications =A0us= e the
>> protocol
>> to =A0manipulate and move =A0the user's =A0avatar, create =A0o= bjects in =A0the
>> virtual
>> world, =A0interact with =A0other users =A0and their =A0surrounding= s and =A0consume
>> and
>> create media and =A0information from sources inside and =A0outside= their
>> virtual
>> world.
>>
>> Adjacent =A0locations in =A0virtual worlds =A0accessible by =A0thi= s protocol =A0may
>> be
>> explicitly partitioned =A0into "regions" =A0to facilitat= e the =A0computational
>> and
>> communication =A0 load =A0 balancing =A0 =A0required =A0 to =A0 si= mulate =A0 the
>> virtual
>> environment. =A0Such virtual =A0worlds may =A0consist of =A0region= s =A0administered
>> by
>> distinct organizations. Though these virtual worlds may be partiti= oned,
>> they
>> remain "un-sharded;" all inhabitants and objects in a pa= rticular location
>> in
>> the virtual =A0world may initiate =A0interaction with all other = =A0inhabitants
>> and
>> objects in that =A0location; and, service endpoint addresses =A0re= fer to at
>> most
>> one location. =A0The state of the =A0virtual world is independent = =A0of the
>> client
>> applications that access it and may persist between user sessions.=
>>
>> The protocol defined by this =A0group will carry information about= the
>> virtual
>> environment, its =A0contents and its =A0inhabitants. It is an =A0a= pplication
>> layer
>> protocol, =A0independent of =A0transport, =A0based partially =A0on= these
>> =A0previously
>> published internet drafts:
>>
>> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-intro<= br> >> =A0* http://tools.ietf.org/html/draft-hamrick-llsd
>> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-auth >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-launch
>> =A0* http://tools.ietf.org/html/draft-lentczner-ogp-base
>> =A0* http://tools.ietf.org/html/draft-levine-ogp-clientca= p
>> =A0* http://tools.ietf.org/html/draft-levine-ogp-layering<= /a>
>>
>> The protocol should describe interaction semantics for these virtu= al
>> worlds,
>> independent of transport, leveraging =A0existing standards where p= ractical.
>> It
>> should =A0 define =A0 interoperability =A0expectations =A0 for =A0= server =A0to
>> server
>> interactions as =A0well as client-server interactions. Though =A0t= he protocol
>> is
>> independent =A0of transport, =A0early interoperability =A0trials u= sed =A0HTTP(S)
>> for
>> non-real-time messages. The working group will define specific fea= tures
>> that
>> must be replicated in other transports and will define the use of = HTTP(S)
>> as
>> a transport of protocol messages.
>>
>> Foundational components of the protocol include the publication of= :
>>
>> =A0* an =A0abstract =A0type =A0system, =A0suitable =A0for =A0descr= ibing =A0the
>> =A0application
>> =A0 =A0protocol in an implementation neutral manner,
>>
>> =A0* a =A0security model describing =A0trust relationships =A0betw= een
>> participating
>> =A0 =A0entities,
>>
>> =A0* guidelines for =A0the use =A0of existing authentication =A0an= d
>> confidentiality
>> =A0 =A0mechanisms,
>>
>> =A0* an application-layer protocol for =A0establishing the user= 9;s avatar in
>> the
>> =A0 =A0virtual world,
>>
>> =A0* an =A0application-layer =A0protocol =A0for =A0moving =A0a =A0= user's =A0avatar
>> =A0between
>> =A0 =A0adjacent and remote locations in the virtual world,
>>
>> =A0* format descriptions for objects and avatars in a virtual worl= d, and
>>
>> =A0* an =A0application-layer protocol =A0for identifying =A0agents= , =A0and
>> requesting
>> =A0 =A0information about them.
>>
>> Goals and Milestones:
>>
>> =A0* October 2009 =A0"Introduction and Goals" =A0to the = IESG as =A0an
>> Informational
>> =A0 =A0RFC
>>
>> =A0* October =A02009 "Abstract =A0Type =A0System for =A0the = =A0Transmission of
>> =A0Dynamic
>> =A0 =A0Structured Data" to the IESG as Proposed Standard
>>
>> =A0* October 2010 =A0"Foundational Concepts and Transport =A0= Expectations" to
>> the
>> =A0 =A0IESG as Proposed Standard
>>
>> =A0* February 2010 =A0"Guidelines for =A0Host Authentication&= quot; to =A0the IESG =A0as
>> an
>> =A0 =A0Informational RFC
>>
>> =A0* February 2010 "Service Establishment" to the IESG a= s Proposed Standard
>>
>> =A0* February =A02010 "Client =A0Application Launch =A0Messag= e" =A0to the =A0IESG as
>> =A0an
>> =A0 Informational RFC
>>
>> =A0* February 2010 "Simulation Presence Establishment" t= o the IESG as
>> Proposed
>> =A0 Standard
>>
>> =A0* June 2010 "Primitive Object Format" to the IESG as = Proposed Standard
>>
>> =A0* June 2010 "Digital Asset Access" to the IESG as Pro= posed Standard
>>
>> =A0* June 2010 "Entity Identifiers" to the IESG as Propo= sed standard
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

--0015174bde4cc325d30471895071-- From infinity@lindenlab.com Wed Aug 19 19:25:03 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC0E3A6CF7 for ; Wed, 19 Aug 2009 19:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2qlXn5tf6+6 for ; Wed, 19 Aug 2009 19:25:02 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 61F3F3A693B for ; Wed, 19 Aug 2009 19:25:02 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so1260321rvb.49 for ; Wed, 19 Aug 2009 19:25:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.208.18 with SMTP id f18mr1259161wfg.296.1250735106261; Wed, 19 Aug 2009 19:25:06 -0700 (PDT) In-Reply-To: References: <3a880e2c0908191738x69235df3t4a42cdd5193ef5f7@mail.gmail.com> Date: Wed, 19 Aug 2009 19:25:06 -0700 Message-ID: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> From: Infinity Linden To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 02:25:04 -0000 morgaine. i am not rejecting language that increases clarity, but language that enforces a false requirement. none of the implementers involved in developing the draft charter share your belief that deployers MUST NOT use OGP for interoperability between virtual worlds. rather, it would be a policy decision, and not a protocol decision. On Wed, Aug 19, 2009 at 7:14 PM, Morgaine w= rote: > Infinity, Linden Lab's interoperation with OSgrid is a matter of company > policy which is not our business here.=A0 We are involved only with defin= ing > protocols, which are mechanisms that can be used to implement many differ= ent > policies.=A0 You are suggesting that OGP provides no barrier to interop a= part > from your own local policy, when this is clearly not true. > > The OGP protocol is not being defined to permit any kind of interop betwe= en > virtual worlds at all.=A0 As Joshua's latest charter describes clearly, i= t is > concerned only with the addition of single regions to a given virtual > world.=A0 It does not address interop between two or more such virtual wo= rlds > in any shape or form. > > Your response therefore completely misses the point that OGP does not > provide any means for interop between worlds whatsoever, even when the wo= rld > operators desire it.=A0 It is not a protocol for interoperation between > virtual worlds, even when these worlds are identical in architecture.=A0 = Being > clear is important in standards work. > > Your last comment rejecting clarity in language escapes me at this time. > > If OGPX does not intend to address interop between virtual worlds, that's= a > conscious decision and is not something to hide.=A0 A protocol that grows= a > world by adding regions is still a useful protocol, despite providing no > interop between worlds.=A0 Stating the goal clearly is to everyone's bene= fit. > > > Morgaine. > > > > > > > > > On Thu, Aug 20, 2009 at 1:38 AM, Infinity Linden > wrote: >> >> hunh? if it makes sense for Linden to interoperate with OSGrid, and >> both parties want to do it, i think it will happen irrespective of the >> language in the charter. this work is not intended to be exclusively >> "the protocol that people use to communicate with Second Life." it is >> the protocol systems use to participate in a virtual world simulation. >> it makes no statement about which virtual world participating systems >> interact with. >> >> by their nature, open protocols do not limit participation to fixed >> systems. adding language to the charter that implies this is the case >> is inappropriate and inaccurate. >> >> On Wed, Aug 19, 2009 at 5:05 PM, Morgaine >> wrote: >> > Joshua, >> > >> > This latest draft of the charter reads quite well, but it seems to be >> > missing an opening paragraph without which it is easy to misinterpret >> > the >> > purpose of the workgroup and of the protocol. =A0That opening paragrap= h >> > should >> > be something like this: >> > >> > "This following work is aimed at defining a protocol for the integrati= on >> > of >> > individual regions into a single virtual world, and providing client >> > applications with access to these.=A0 Interoperation between such a >> > virtual >> > world and any other virtual world is outside of the scope of this >> > protocol." >> > >> > >> > Without this introduction, it is easy to mistake OGPX for a VW interop >> > group. >> > >> > After all, it follows nearly two years of discussions about interop >> > between >> > worlds in the Architecture Working Group within Second Life, and it >> > follows >> > 6 months of work in the IETF MMOX group which was specifically >> > targetting >> > interoperation between virtual worlds, and it follows a MMOX BoF in >> > which >> > numerous participants (of which Lindens were only one) discussed inter= op >> > between worlds, and finally, it follows a decision to partition off a >> > new >> > workgroup from MMOX so that its scope can be limited to interoperation >> > between SL-like worlds alone. >> > >> > As it turns out, this new workgroup is not intending to address intero= p >> > between SL-like worlds at all, but only to integrate individual region= s >> > into >> > an existing world, which is extremely different.=A0 As the new draft >> > charter >> > describes well, OGPX is dedicated to growing walled gardens by additio= n >> > of >> > new regions, and it is not concerned with interoperation between such >> > walled >> > gardens. >> > >> > That should be made immediately clear in the introduction --- it is I >> > think >> > this group's main statement of scope, and I assume that our Area >> > Directors >> > will encourage such clarity.=A0 I recommend my opening paragraph above= to >> > accomplish this. >> > >> > On a more general note ... >> > >> > In addition to making the above clear, what's going to be done about >> > interop >> > between SL-like worlds?=A0 There are already many SL-compatible >> > Opensim-based >> > grids, and they currently believe that Linden Lab is defining OGP to >> > interoperate with them.=A0 Clearly they are badly mistaken, but their = need >> > for >> > interop still remains. >> > >> > >> > Morgaine. >> > >> > >> > >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> > >> > On Wed, Aug 19, 2009 at 8:06 PM, Joshua Bell wrote= : >> >> Howdy, folks. >> >> >> >> Please find attached the latest draft of the proposed OGPX working >> >> group charter. It incorporates feedback from many list and >> >> face-to-face meeting participants. I think it's much closer to a >> >> document that reflects the group consensus. There are a few points, w= e >> >> may want to comment on separately: >> >> >> >> 1. The Name. We're still using the name OGPX in this draft. There has >> >> been much discussion about other names, but we're not at consensus >> >> yet. When we have agreement on a new name, it's easy enough to do a >> >> search and replace in the document before submitting it for >> >> consideration. >> >> >> >> 2. The Mailing List. Since we're not at consensus on a name yet, I >> >> recommend we continue to us the ogpx@ietf.org mailing list for the >> >> time being. When we've selected a new name, and after a working group >> >> is approved, we can request a mailing list with the same name as the >> >> working group. Again, we can just simply do a search and replace afte= r >> >> we have consensus on the name. >> >> >> >> 3. Description of the Group's Work. The first two paragraphs in the >> >> description outline the scope of the working group's efforts. The >> >> intent is to briefly describe the group's work to people outside the >> >> working group and to "draw a line in the sand" regarding the >> >> group's focus (so we don't experience scope creep.) This revision >> >> defines terms as they are introduced. It was thought that this >> >> approach made for easier reading than having a separate glossary >> >> section. >> >> >> >> 4. Previous Work. Several people have commented that the charter >> >> should be explicit regarding what documents we think we're starting >> >> from. There is a list of related internet drafts in this draft to mee= t >> >> this requirement. >> >> >> >> 5. Selecting a Transport. We added verbiage supporting the idea that >> >> OGP is transport agnostic, and that we should somewhere describe how >> >> OGP uses it's transports and which features it needs. It also lists >> >> HTTP(S) as the protocol of choice for OGP messages. >> >> >> >> 6. Objectives. There is a list of specific objectives, defined in >> >> terms of the problem domain. This list is thought to be roughly >> >> complete at the moment. The process of adding objectives or >> >> refactoring them after working group formation is non-trivial, but no= t >> >> impossible. But, we should have agreement that the objectives are an >> >> honest assessment of what we think we need to be working on. >> >> >> >> 7. Milestone Dates. The dates listed below may be a touch optimistic. >> >> They may need to be massaged before the charter is submitted to the >> >> IESG. >> >> >> >> Here is the draft charter... >> >> >> >> >> >> Working Group Name: >> >> >> >> =A0Open Grid Protocol (OGPX) >> >> >> >> Chairs: >> >> >> >> =A0TBD >> >> >> >> Area and Area Directors: >> >> >> >> =A0Applications Area >> >> >> >> =A0Lisa Dusseault >> >> =A0Alexey Melnikov >> >> >> >> Responsible Area Director: >> >> >> >> =A0TBD >> >> >> >> Mailing List: >> >> >> >> =A0ogpx@ietf.org >> >> =A0http://www.ietf.org/mailman/listinfo/ogpx >> >> >> >> Description of Working Group: >> >> >> >> The working group will define the Open Grid Protocol (OGP) for >> >> collaborative >> >> 3-dimensional virtual =A0worlds. The protocol =A0permits users to =A0= interact >> >> with >> >> each other while represented as "avatars," or digital representations >> >> of >> >> the >> >> user. Within a =A0single virtual world, avatars exist in =A0at most o= ne >> >> location >> >> in a shared =A0virtual space. Conforming client applications =A0use t= he >> >> protocol >> >> to =A0manipulate and move =A0the user's =A0avatar, create =A0objects = in =A0the >> >> virtual >> >> world, =A0interact with =A0other users =A0and their =A0surroundings a= nd >> >> =A0consume >> >> and >> >> create media and =A0information from sources inside and =A0outside th= eir >> >> virtual >> >> world. >> >> >> >> Adjacent =A0locations in =A0virtual worlds =A0accessible by =A0this p= rotocol >> >> =A0may >> >> be >> >> explicitly partitioned =A0into "regions" =A0to facilitate the >> >> =A0computational >> >> and >> >> communication =A0 load =A0 balancing =A0 =A0required =A0 to =A0 simul= ate =A0 the >> >> virtual >> >> environment. =A0Such virtual =A0worlds may =A0consist of =A0regions >> >> =A0administered >> >> by >> >> distinct organizations. Though these virtual worlds may be partitione= d, >> >> they >> >> remain "un-sharded;" all inhabitants and objects in a particular >> >> location >> >> in >> >> the virtual =A0world may initiate =A0interaction with all other >> >> =A0inhabitants >> >> and >> >> objects in that =A0location; and, service endpoint addresses =A0refer= to at >> >> most >> >> one location. =A0The state of the =A0virtual world is independent =A0= of the >> >> client >> >> applications that access it and may persist between user sessions. >> >> >> >> The protocol defined by this =A0group will carry information about th= e >> >> virtual >> >> environment, its =A0contents and its =A0inhabitants. It is an =A0appl= ication >> >> layer >> >> protocol, =A0independent of =A0transport, =A0based partially =A0on th= ese >> >> =A0previously >> >> published internet drafts: >> >> >> >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-intro >> >> =A0* http://tools.ietf.org/html/draft-hamrick-llsd >> >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-auth >> >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-launch >> >> =A0* http://tools.ietf.org/html/draft-lentczner-ogp-base >> >> =A0* http://tools.ietf.org/html/draft-levine-ogp-clientcap >> >> =A0* http://tools.ietf.org/html/draft-levine-ogp-layering >> >> >> >> The protocol should describe interaction semantics for these virtual >> >> worlds, >> >> independent of transport, leveraging =A0existing standards where >> >> practical. >> >> It >> >> should =A0 define =A0 interoperability =A0expectations =A0 for =A0 se= rver =A0to >> >> server >> >> interactions as =A0well as client-server interactions. Though =A0the >> >> protocol >> >> is >> >> independent =A0of transport, =A0early interoperability =A0trials used >> >> =A0HTTP(S) >> >> for >> >> non-real-time messages. The working group will define specific featur= es >> >> that >> >> must be replicated in other transports and will define the use of >> >> HTTP(S) >> >> as >> >> a transport of protocol messages. >> >> >> >> Foundational components of the protocol include the publication of: >> >> >> >> =A0* an =A0abstract =A0type =A0system, =A0suitable =A0for =A0describi= ng =A0the >> >> =A0application >> >> =A0 =A0protocol in an implementation neutral manner, >> >> >> >> =A0* a =A0security model describing =A0trust relationships =A0between >> >> participating >> >> =A0 =A0entities, >> >> >> >> =A0* guidelines for =A0the use =A0of existing authentication =A0and >> >> confidentiality >> >> =A0 =A0mechanisms, >> >> >> >> =A0* an application-layer protocol for =A0establishing the user's ava= tar in >> >> the >> >> =A0 =A0virtual world, >> >> >> >> =A0* an =A0application-layer =A0protocol =A0for =A0moving =A0a =A0use= r's =A0avatar >> >> =A0between >> >> =A0 =A0adjacent and remote locations in the virtual world, >> >> >> >> =A0* format descriptions for objects and avatars in a virtual world, = and >> >> >> >> =A0* an =A0application-layer protocol =A0for identifying =A0agents, = =A0and >> >> requesting >> >> =A0 =A0information about them. >> >> >> >> Goals and Milestones: >> >> >> >> =A0* October 2009 =A0"Introduction and Goals" =A0to the IESG as =A0an >> >> Informational >> >> =A0 =A0RFC >> >> >> >> =A0* October =A02009 "Abstract =A0Type =A0System for =A0the =A0Transm= ission of >> >> =A0Dynamic >> >> =A0 =A0Structured Data" to the IESG as Proposed Standard >> >> >> >> =A0* October 2010 =A0"Foundational Concepts and Transport =A0Expectat= ions" to >> >> the >> >> =A0 =A0IESG as Proposed Standard >> >> >> >> =A0* February 2010 =A0"Guidelines for =A0Host Authentication" to =A0t= he IESG >> >> =A0as >> >> an >> >> =A0 =A0Informational RFC >> >> >> >> =A0* February 2010 "Service Establishment" to the IESG as Proposed >> >> Standard >> >> >> >> =A0* February =A02010 "Client =A0Application Launch =A0Message" =A0to= the =A0IESG >> >> as >> >> =A0an >> >> =A0 Informational RFC >> >> >> >> =A0* February 2010 "Simulation Presence Establishment" to the IESG as >> >> Proposed >> >> =A0 Standard >> >> >> >> =A0* June 2010 "Primitive Object Format" to the IESG as Proposed Stan= dard >> >> >> >> =A0* June 2010 "Digital Asset Access" to the IESG as Proposed Standar= d >> >> >> >> =A0* June 2010 "Entity Identifiers" to the IESG as Proposed standard >> >> _______________________________________________ >> >> ogpx mailing list >> >> ogpx@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ogpx >> >> >> > >> > >> > _______________________________________________ >> > ogpx mailing list >> > ogpx@ietf.org >> > https://www.ietf.org/mailman/listinfo/ogpx >> > >> > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From morgaine.dinova@googlemail.com Wed Aug 19 20:03:52 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C1E28C462 for ; Wed, 19 Aug 2009 20:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uthg8jELbs4h for ; Wed, 19 Aug 2009 20:03:50 -0700 (PDT) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by core3.amsl.com (Postfix) with ESMTP id 4B93B28C0D0 for ; Wed, 19 Aug 2009 20:03:49 -0700 (PDT) Received: by ewy2 with SMTP id 2so1612336ewy.43 for ; Wed, 19 Aug 2009 20:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=uN0K7HXdQ1suXwSoEKUmcFN5DoUm1CmIaha3RqFpHTE=; b=Qy+WamEt7W5pCX5rCIVWbJ1U1qPa1tCABn26GgNKh8ZlK0jCijCyEWv4SUOaJDxO4T fFrpyM7Wxx5VJ4uKyYL18R8e9EzSjTe2GvYpZDlTTWgrbfgi/Mw5DwPj50n1N2c+KG6U fKtrXoQF8Y8rueF2GzC5R8kq5gje9+Q808fvY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=kcpfYtHRApxQgfjCNVaXTYjcFqI5bRe/Bu65NFFQuqs7UwIxqHtKiZ4uldmvx4rggr 31a5IIgaymEXLXlLy8mBi35uWS8NAuZo+TlgcN1ErAq8xWGRRT8uhyQ2Pyoe5Keypz0i iiGhZ3d35/SqWdkYMaXsuUC0fLRTqRuKofsgk= MIME-Version: 1.0 Received: by 10.210.12.13 with SMTP id 13mr6530145ebl.12.1250737425298; Wed, 19 Aug 2009 20:03:45 -0700 (PDT) In-Reply-To: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> References: <3a880e2c0908191738x69235df3t4a42cdd5193ef5f7@mail.gmail.com> <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> Date: Thu, 20 Aug 2009 04:03:45 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174be270f1372f047189ffe8 Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 03:03:52 -0000 --0015174be270f1372f047189ffe8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Aug 20, 2009 at 3:25 AM, Infinity Linden wrote: > none of the implementers involved in developing the draft charter share > your belief that *deployers MUST NOT use OGP* for interoperability between > virtual worlds. rather, it would be a policy decision, and not a protocol > decision. > > Who wrote "*deployers MUST NOT use OGP"* which you then proceed to reject? I did not, and straw men misrepresentations do not help in this discussion. More importantly, you are avoiding the central point that *OGP cannot be used* to provide interoperability between virtual worlds, because it does not define this case. It defines only how a separate region can be added to a given virtual world, and not how two such worlds can interoperate. The claim "*it would be a policy decision, and not a protocol decision*" is false, because OGP does not provide for any alternative. Morgaine. On Thu, Aug 20, 2009 at 3:25 AM, Infinity Linden wrote: > morgaine. i am not rejecting language that increases clarity, but > language that enforces a false requirement. none of the implementers > involved in developing the draft charter share your belief that > deployers MUST NOT use OGP for interoperability between virtual > worlds. rather, it would be a policy decision, and not a protocol > decision. > > > On Wed, Aug 19, 2009 at 7:14 PM, Morgaine > wrote: > > Infinity, Linden Lab's interoperation with OSgrid is a matter of company > > policy which is not our business here. We are involved only with > defining > > protocols, which are mechanisms that can be used to implement many > different > > policies. You are suggesting that OGP provides no barrier to interop > apart > > from your own local policy, when this is clearly not true. > > > > The OGP protocol is not being defined to permit any kind of interop > between > > virtual worlds at all. As Joshua's latest charter describes clearly, it > is > > concerned only with the addition of single regions to a given virtual > > world. It does not address interop between two or more such virtual > worlds > > in any shape or form. > > > > Your response therefore completely misses the point that OGP does not > > provide any means for interop between worlds whatsoever, even when the > world > > operators desire it. It is not a protocol for interoperation between > > virtual worlds, even when these worlds are identical in architecture. > Being > > clear is important in standards work. > > > > Your last comment rejecting clarity in language escapes me at this time. > > > > If OGPX does not intend to address interop between virtual worlds, that's > a > > conscious decision and is not something to hide. A protocol that grows a > > world by adding regions is still a useful protocol, despite providing no > > interop between worlds. Stating the goal clearly is to everyone's > benefit. > > > > > > Morgaine. > > > > > > > > > > > > > > > > > > On Thu, Aug 20, 2009 at 1:38 AM, Infinity Linden > > > wrote: > >> > >> hunh? if it makes sense for Linden to interoperate with OSGrid, and > >> both parties want to do it, i think it will happen irrespective of the > >> language in the charter. this work is not intended to be exclusively > >> "the protocol that people use to communicate with Second Life." it is > >> the protocol systems use to participate in a virtual world simulation. > >> it makes no statement about which virtual world participating systems > >> interact with. > >> > >> by their nature, open protocols do not limit participation to fixed > >> systems. adding language to the charter that implies this is the case > >> is inappropriate and inaccurate. > >> > >> On Wed, Aug 19, 2009 at 5:05 PM, Morgaine< > morgaine.dinova@googlemail.com> > >> wrote: > >> > Joshua, > >> > > >> > This latest draft of the charter reads quite well, but it seems to be > >> > missing an opening paragraph without which it is easy to misinterpret > >> > the > >> > purpose of the workgroup and of the protocol. That opening paragraph > >> > should > >> > be something like this: > >> > > >> > "This following work is aimed at defining a protocol for the > integration > >> > of > >> > individual regions into a single virtual world, and providing client > >> > applications with access to these. Interoperation between such a > >> > virtual > >> > world and any other virtual world is outside of the scope of this > >> > protocol." > >> > > >> > > >> > Without this introduction, it is easy to mistake OGPX for a VW interop > >> > group. > >> > > >> > After all, it follows nearly two years of discussions about interop > >> > between > >> > worlds in the Architecture Working Group within Second Life, and it > >> > follows > >> > 6 months of work in the IETF MMOX group which was specifically > >> > targetting > >> > interoperation between virtual worlds, and it follows a MMOX BoF in > >> > which > >> > numerous participants (of which Lindens were only one) discussed > interop > >> > between worlds, and finally, it follows a decision to partition off a > >> > new > >> > workgroup from MMOX so that its scope can be limited to interoperation > >> > between SL-like worlds alone. > >> > > >> > As it turns out, this new workgroup is not intending to address > interop > >> > between SL-like worlds at all, but only to integrate individual > regions > >> > into > >> > an existing world, which is extremely different. As the new draft > >> > charter > >> > describes well, OGPX is dedicated to growing walled gardens by > addition > >> > of > >> > new regions, and it is not concerned with interoperation between such > >> > walled > >> > gardens. > >> > > >> > That should be made immediately clear in the introduction --- it is I > >> > think > >> > this group's main statement of scope, and I assume that our Area > >> > Directors > >> > will encourage such clarity. I recommend my opening paragraph above > to > >> > accomplish this. > >> > > >> > On a more general note ... > >> > > >> > In addition to making the above clear, what's going to be done about > >> > interop > >> > between SL-like worlds? There are already many SL-compatible > >> > Opensim-based > >> > grids, and they currently believe that Linden Lab is defining OGP to > >> > interoperate with them. Clearly they are badly mistaken, but their > need > >> > for > >> > interop still remains. > >> > > >> > > >> > Morgaine. > >> > > >> > > >> > > >> > > >> > > >> > ============================ > >> > > >> > On Wed, Aug 19, 2009 at 8:06 PM, Joshua Bell > wrote: > >> >> Howdy, folks. > >> >> > >> >> Please find attached the latest draft of the proposed OGPX working > >> >> group charter. It incorporates feedback from many list and > >> >> face-to-face meeting participants. I think it's much closer to a > >> >> document that reflects the group consensus. There are a few points, > we > >> >> may want to comment on separately: > >> >> > >> >> 1. The Name. We're still using the name OGPX in this draft. There has > >> >> been much discussion about other names, but we're not at consensus > >> >> yet. When we have agreement on a new name, it's easy enough to do a > >> >> search and replace in the document before submitting it for > >> >> consideration. > >> >> > >> >> 2. The Mailing List. Since we're not at consensus on a name yet, I > >> >> recommend we continue to us the ogpx@ietf.org mailing list for the > >> >> time being. When we've selected a new name, and after a working group > >> >> is approved, we can request a mailing list with the same name as the > >> >> working group. Again, we can just simply do a search and replace > after > >> >> we have consensus on the name. > >> >> > >> >> 3. Description of the Group's Work. The first two paragraphs in the > >> >> description outline the scope of the working group's efforts. The > >> >> intent is to briefly describe the group's work to people outside the > >> >> working group and to "draw a line in the sand" regarding the > >> >> group's focus (so we don't experience scope creep.) This revision > >> >> defines terms as they are introduced. It was thought that this > >> >> approach made for easier reading than having a separate glossary > >> >> section. > >> >> > >> >> 4. Previous Work. Several people have commented that the charter > >> >> should be explicit regarding what documents we think we're starting > >> >> from. There is a list of related internet drafts in this draft to > meet > >> >> this requirement. > >> >> > >> >> 5. Selecting a Transport. We added verbiage supporting the idea that > >> >> OGP is transport agnostic, and that we should somewhere describe how > >> >> OGP uses it's transports and which features it needs. It also lists > >> >> HTTP(S) as the protocol of choice for OGP messages. > >> >> > >> >> 6. Objectives. There is a list of specific objectives, defined in > >> >> terms of the problem domain. This list is thought to be roughly > >> >> complete at the moment. The process of adding objectives or > >> >> refactoring them after working group formation is non-trivial, but > not > >> >> impossible. But, we should have agreement that the objectives are an > >> >> honest assessment of what we think we need to be working on. > >> >> > >> >> 7. Milestone Dates. The dates listed below may be a touch optimistic. > >> >> They may need to be massaged before the charter is submitted to the > >> >> IESG. > >> >> > >> >> Here is the draft charter... > >> >> > >> >> > >> >> Working Group Name: > >> >> > >> >> Open Grid Protocol (OGPX) > >> >> > >> >> Chairs: > >> >> > >> >> TBD > >> >> > >> >> Area and Area Directors: > >> >> > >> >> Applications Area > >> >> > >> >> Lisa Dusseault > >> >> Alexey Melnikov > >> >> > >> >> Responsible Area Director: > >> >> > >> >> TBD > >> >> > >> >> Mailing List: > >> >> > >> >> ogpx@ietf.org > >> >> http://www.ietf.org/mailman/listinfo/ogpx > >> >> > >> >> Description of Working Group: > >> >> > >> >> The working group will define the Open Grid Protocol (OGP) for > >> >> collaborative > >> >> 3-dimensional virtual worlds. The protocol permits users to > interact > >> >> with > >> >> each other while represented as "avatars," or digital representations > >> >> of > >> >> the > >> >> user. Within a single virtual world, avatars exist in at most one > >> >> location > >> >> in a shared virtual space. Conforming client applications use the > >> >> protocol > >> >> to manipulate and move the user's avatar, create objects in the > >> >> virtual > >> >> world, interact with other users and their surroundings and > >> >> consume > >> >> and > >> >> create media and information from sources inside and outside their > >> >> virtual > >> >> world. > >> >> > >> >> Adjacent locations in virtual worlds accessible by this protocol > >> >> may > >> >> be > >> >> explicitly partitioned into "regions" to facilitate the > >> >> computational > >> >> and > >> >> communication load balancing required to simulate the > >> >> virtual > >> >> environment. Such virtual worlds may consist of regions > >> >> administered > >> >> by > >> >> distinct organizations. Though these virtual worlds may be > partitioned, > >> >> they > >> >> remain "un-sharded;" all inhabitants and objects in a particular > >> >> location > >> >> in > >> >> the virtual world may initiate interaction with all other > >> >> inhabitants > >> >> and > >> >> objects in that location; and, service endpoint addresses refer to > at > >> >> most > >> >> one location. The state of the virtual world is independent of the > >> >> client > >> >> applications that access it and may persist between user sessions. > >> >> > >> >> The protocol defined by this group will carry information about the > >> >> virtual > >> >> environment, its contents and its inhabitants. It is an > application > >> >> layer > >> >> protocol, independent of transport, based partially on these > >> >> previously > >> >> published internet drafts: > >> >> > >> >> * http://tools.ietf.org/html/draft-hamrick-ogp-intro > >> >> * http://tools.ietf.org/html/draft-hamrick-llsd > >> >> * http://tools.ietf.org/html/draft-hamrick-ogp-auth > >> >> * http://tools.ietf.org/html/draft-hamrick-ogp-launch > >> >> * http://tools.ietf.org/html/draft-lentczner-ogp-base > >> >> * http://tools.ietf.org/html/draft-levine-ogp-clientcap > >> >> * http://tools.ietf.org/html/draft-levine-ogp-layering > >> >> > >> >> The protocol should describe interaction semantics for these virtual > >> >> worlds, > >> >> independent of transport, leveraging existing standards where > >> >> practical. > >> >> It > >> >> should define interoperability expectations for server to > >> >> server > >> >> interactions as well as client-server interactions. Though the > >> >> protocol > >> >> is > >> >> independent of transport, early interoperability trials used > >> >> HTTP(S) > >> >> for > >> >> non-real-time messages. The working group will define specific > features > >> >> that > >> >> must be replicated in other transports and will define the use of > >> >> HTTP(S) > >> >> as > >> >> a transport of protocol messages. > >> >> > >> >> Foundational components of the protocol include the publication of: > >> >> > >> >> * an abstract type system, suitable for describing the > >> >> application > >> >> protocol in an implementation neutral manner, > >> >> > >> >> * a security model describing trust relationships between > >> >> participating > >> >> entities, > >> >> > >> >> * guidelines for the use of existing authentication and > >> >> confidentiality > >> >> mechanisms, > >> >> > >> >> * an application-layer protocol for establishing the user's avatar > in > >> >> the > >> >> virtual world, > >> >> > >> >> * an application-layer protocol for moving a user's avatar > >> >> between > >> >> adjacent and remote locations in the virtual world, > >> >> > >> >> * format descriptions for objects and avatars in a virtual world, > and > >> >> > >> >> * an application-layer protocol for identifying agents, and > >> >> requesting > >> >> information about them. > >> >> > >> >> Goals and Milestones: > >> >> > >> >> * October 2009 "Introduction and Goals" to the IESG as an > >> >> Informational > >> >> RFC > >> >> > >> >> * October 2009 "Abstract Type System for the Transmission of > >> >> Dynamic > >> >> Structured Data" to the IESG as Proposed Standard > >> >> > >> >> * October 2010 "Foundational Concepts and Transport Expectations" > to > >> >> the > >> >> IESG as Proposed Standard > >> >> > >> >> * February 2010 "Guidelines for Host Authentication" to the IESG > >> >> as > >> >> an > >> >> Informational RFC > >> >> > >> >> * February 2010 "Service Establishment" to the IESG as Proposed > >> >> Standard > >> >> > >> >> * February 2010 "Client Application Launch Message" to the IESG > >> >> as > >> >> an > >> >> Informational RFC > >> >> > >> >> * February 2010 "Simulation Presence Establishment" to the IESG as > >> >> Proposed > >> >> Standard > >> >> > >> >> * June 2010 "Primitive Object Format" to the IESG as Proposed > Standard > >> >> > >> >> * June 2010 "Digital Asset Access" to the IESG as Proposed Standard > >> >> > >> >> * June 2010 "Entity Identifiers" to the IESG as Proposed standard > >> >> _______________________________________________ > >> >> ogpx mailing list > >> >> ogpx@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/ogpx > >> >> > >> > > >> > > >> > _______________________________________________ > >> > ogpx mailing list > >> > ogpx@ietf.org > >> > https://www.ietf.org/mailman/listinfo/ogpx > >> > > >> > > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --0015174be270f1372f047189ffe8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Aug 20, 2009 at 3:25 AM, Infinity Linden <infinity@lindenlab.com>= wrote:
none of the implementers involved in developing the draft charter share you= r belief that deployers MUST NOT use OGP for interoperability betwee= n virtual worlds. rather, it would be a policy decision, and not a protocol= decision.


Who wrote "= deployers MUST NOT use OGP" which you then proceed to reject?=A0 I= did not, and straw men misrepresentations do not help in this discussion.<= br>
More importantly, you are avoiding the central point that OGP cannot= be used to provide interoperability between virtual worlds, because it= does not define this case.=A0 It defines only how a separate region can be= added to a given virtual world, and not how two such worlds can interopera= te.

The claim "it would be a policy decision, and not a protocol de= cision" is false, because OGP does not provide for any alternative= .


Morgaine.








On Thu, Aug 20, 2009 at 3:25 AM, Infinity Linden <infinity@lindenlab.com>= wrote:
morgaine. i am not rejecting language that increases clarity, but
language that enforces a false requirement. none of the implementers
involved in developing the draft charter share your belief that
deployers MUST NOT use OGP for interoperability between virtual
worlds. rather, it would be a policy decision, and not a protocol
decision.


On Wed, Aug 19, 2009 at 7:14 PM, Morgaine<morgaine.dinova@googlemail.com> wrote:
> Infinity, Linden Lab's interoperation with OSgrid is a matter of c= ompany
> policy which is not our business here.=A0 We are involved only with de= fining
> protocols, which are mechanisms that can be used to implement many dif= ferent
> policies.=A0 You are suggesting that OGP provides no barrier to intero= p apart
> from your own local policy, when this is clearly not true.
>
> The OGP protocol is not being defined to permit any kind of interop be= tween
> virtual worlds at all.=A0 As Joshua's latest charter describes cle= arly, it is
> concerned only with the addition of single regions to a given virtual<= br> > world.=A0 It does not address interop between two or more such virtual= worlds
> in any shape or form.
>
> Your response therefore completely misses the point that OGP does not<= br> > provide any means for interop between worlds whatsoever, even when the= world
> operators desire it.=A0 It is not a protocol for interoperation betwee= n
> virtual worlds, even when these worlds are identical in architecture.= =A0 Being
> clear is important in standards work.
>
> Your last comment rejecting clarity in language escapes me at this tim= e.
>
> If OGPX does not intend to address interop between virtual worlds, tha= t's a
> conscious decision and is not something to hide.=A0 A protocol that gr= ows a
> world by adding regions is still a useful protocol, despite providing = no
> interop between worlds.=A0 Stating the goal clearly is to everyone'= ;s benefit.
>
>
> Morgaine.
>
>
>
>
>
>
>
>
> On Thu, Aug 20, 2009 at 1:38 AM, Infinity Linden <infinity@lindenlab.com>
> wrote:
>>
>> hunh? if it makes sense for Linden to interoperate with OSGrid, an= d
>> both parties want to do it, i think it will happen irrespective of= the
>> language in the charter. this work is not intended to be exclusive= ly
>> "the protocol that people use to communicate with Second Life= ." it is
>> the protocol systems use to participate in a virtual world simulat= ion.
>> it makes no statement about which virtual world participating syst= ems
>> interact with.
>>
>> by their nature, open protocols do not limit participation to fixe= d
>> systems. adding language to the charter that implies this is the c= ase
>> is inappropriate and inaccurate.
>>
>> On Wed, Aug 19, 2009 at 5:05 PM, Morgaine<morgaine.dinova@googlemail.com>
>> wrote:
>> > Joshua,
>> >
>> > This latest draft of the charter reads quite well, but it see= ms to be
>> > missing an opening paragraph without which it is easy to misi= nterpret
>> > the
>> > purpose of the workgroup and of the protocol. =A0That opening= paragraph
>> > should
>> > be something like this:
>> >
>> > "This following work is aimed at defining a protocol for= the integration
>> > of
>> > individual regions into a single virtual world, and providing= client
>> > applications with access to these.=A0 Interoperation between = such a
>> > virtual
>> > world and any other virtual world is outside of the scope of = this
>> > protocol."
>> >
>> >
>> > Without this introduction, it is easy to mistake OGPX for a V= W interop
>> > group.
>> >
>> > After all, it follows nearly two years of discussions about i= nterop
>> > between
>> > worlds in the Architecture Working Group within Second Life, = and it
>> > follows
>> > 6 months of work in the IETF MMOX group which was specificall= y
>> > targetting
>> > interoperation between virtual worlds, and it follows a MMOX = BoF in
>> > which
>> > numerous participants (of which Lindens were only one) discus= sed interop
>> > between worlds, and finally, it follows a decision to partiti= on off a
>> > new
>> > workgroup from MMOX so that its scope can be limited to inter= operation
>> > between SL-like worlds alone.
>> >
>> > As it turns out, this new workgroup is not intending to addre= ss interop
>> > between SL-like worlds at all, but only to integrate individu= al regions
>> > into
>> > an existing world, which is extremely different.=A0 As the ne= w draft
>> > charter
>> > describes well, OGPX is dedicated to growing walled gardens b= y addition
>> > of
>> > new regions, and it is not concerned with interoperation betw= een such
>> > walled
>> > gardens.
>> >
>> > That should be made immediately clear in the introduction ---= it is I
>> > think
>> > this group's main statement of scope, and I assume that o= ur Area
>> > Directors
>> > will encourage such clarity.=A0 I recommend my opening paragr= aph above to
>> > accomplish this.
>> >
>> > On a more general note ...
>> >
>> > In addition to making the above clear, what's going to be= done about
>> > interop
>> > between SL-like worlds?=A0 There are already many SL-compatib= le
>> > Opensim-based
>> > grids, and they currently believe that Linden Lab is defining= OGP to
>> > interoperate with them.=A0 Clearly they are badly mistaken, b= ut their need
>> > for
>> > interop still remains.
>> >
>> >
>> > Morgaine.
>> >
>> >
>> >
>> >
>> >
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
>> >
>> > On Wed, Aug 19, 2009 at 8:06 PM, Joshua Bell<josh@lindenlab.com> wrote:
>> >> Howdy, folks.
>> >>
>> >> Please find attached the latest draft of the proposed OGP= X working
>> >> group charter. It incorporates feedback from many list an= d
>> >> face-to-face meeting participants. I think it's much = closer to a
>> >> document that reflects the group consensus. There are a f= ew points, we
>> >> may want to comment on separately:
>> >>
>> >> 1. The Name. We're still using the name OGPX in this = draft. There has
>> >> been much discussion about other names, but we're not= at consensus
>> >> yet. When we have agreement on a new name, it's easy = enough to do a
>> >> search and replace in the document before submitting it f= or
>> >> consideration.
>> >>
>> >> 2. The Mailing List. Since we're not at consensus on = a name yet, I
>> >> recommend we continue to us the ogpx@ietf.org mailing list for the
>> >> time being. When we've selected a new name, and after= a working group
>> >> is approved, we can request a mailing list with the same = name as the
>> >> working group. Again, we can just simply do a search and = replace after
>> >> we have consensus on the name.
>> >>
>> >> 3. Description of the Group's Work. The first two par= agraphs in the
>> >> description outline the scope of the working group's = efforts. The
>> >> intent is to briefly describe the group's work to peo= ple outside the
>> >> working group and to "draw a line in the sand" = regarding the
>> >> group's focus (so we don't experience scope creep= .) This revision
>> >> defines terms as they are introduced. It was thought that= this
>> >> approach made for easier reading than having a separate g= lossary
>> >> section.
>> >>
>> >> 4. Previous Work. Several people have commented that the = charter
>> >> should be explicit regarding what documents we think we&#= 39;re starting
>> >> from. There is a list of related internet drafts in this = draft to meet
>> >> this requirement.
>> >>
>> >> 5. Selecting a Transport. We added verbiage supporting th= e idea that
>> >> OGP is transport agnostic, and that we should somewhere d= escribe how
>> >> OGP uses it's transports and which features it needs.= It also lists
>> >> HTTP(S) as the protocol of choice for OGP messages.
>> >>
>> >> 6. Objectives. There is a list of specific objectives, de= fined in
>> >> terms of the problem domain. This list is thought to be r= oughly
>> >> complete at the moment. The process of adding objectives = or
>> >> refactoring them after working group formation is non-tri= vial, but not
>> >> impossible. But, we should have agreement that the object= ives are an
>> >> honest assessment of what we think we need to be working = on.
>> >>
>> >> 7. Milestone Dates. The dates listed below may be a touch= optimistic.
>> >> They may need to be massaged before the charter is submit= ted to the
>> >> IESG.
>> >>
>> >> Here is the draft charter...
>> >>
>> >>
>> >> Working Group Name:
>> >>
>> >> =A0Open Grid Protocol (OGPX)
>> >>
>> >> Chairs:
>> >>
>> >> =A0TBD
>> >>
>> >> Area and Area Directors:
>> >>
>> >> =A0Applications Area
>> >>
>> >> =A0Lisa Dusseault <lisa.dusseault@gmail.com>
>> >> =A0Alexey Melnikov <alexey.melnikov@isode.com>
>> >>
>> >> Responsible Area Director:
>> >>
>> >> =A0TBD
>> >>
>> >> Mailing List:
>> >>
>> >> =A0ogpx@ietf.org
>> >> =A0http://www.ietf.org/mailman/listinfo/ogpx
>> >>
>> >> Description of Working Group:
>> >>
>> >> The working group will define the Open Grid Protocol (OGP= ) for
>> >> collaborative
>> >> 3-dimensional virtual =A0worlds. The protocol =A0permits = users to =A0interact
>> >> with
>> >> each other while represented as "avatars," or d= igital representations
>> >> of
>> >> the
>> >> user. Within a =A0single virtual world, avatars exist in = =A0at most one
>> >> location
>> >> in a shared =A0virtual space. Conforming client applicati= ons =A0use the
>> >> protocol
>> >> to =A0manipulate and move =A0the user's =A0avatar, cr= eate =A0objects in =A0the
>> >> virtual
>> >> world, =A0interact with =A0other users =A0and their =A0su= rroundings and
>> >> =A0consume
>> >> and
>> >> create media and =A0information from sources inside and = =A0outside their
>> >> virtual
>> >> world.
>> >>
>> >> Adjacent =A0locations in =A0virtual worlds =A0accessible = by =A0this protocol
>> >> =A0may
>> >> be
>> >> explicitly partitioned =A0into "regions" =A0to = facilitate the
>> >> =A0computational
>> >> and
>> >> communication =A0 load =A0 balancing =A0 =A0required =A0 = to =A0 simulate =A0 the
>> >> virtual
>> >> environment. =A0Such virtual =A0worlds may =A0consist of = =A0regions
>> >> =A0administered
>> >> by
>> >> distinct organizations. Though these virtual worlds may b= e partitioned,
>> >> they
>> >> remain "un-sharded;" all inhabitants and object= s in a particular
>> >> location
>> >> in
>> >> the virtual =A0world may initiate =A0interaction with all= other
>> >> =A0inhabitants
>> >> and
>> >> objects in that =A0location; and, service endpoint addres= ses =A0refer to at
>> >> most
>> >> one location. =A0The state of the =A0virtual world is ind= ependent =A0of the
>> >> client
>> >> applications that access it and may persist between user = sessions.
>> >>
>> >> The protocol defined by this =A0group will carry informat= ion about the
>> >> virtual
>> >> environment, its =A0contents and its =A0inhabitants. It i= s an =A0application
>> >> layer
>> >> protocol, =A0independent of =A0transport, =A0based partia= lly =A0on these
>> >> =A0previously
>> >> published internet drafts:
>> >>
>> >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-i= ntro
>> >> =A0* http://tools.ietf.org/html/draft-hamrick-llsd >> >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-au= th
>> >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-= launch
>> >> =A0* http://tools.ietf.org/html/draft-lentczner-og= p-base
>> >> =A0* http://tools.ietf.org/html/draft-levine-ogp= -clientcap
>> >> =A0* http://tools.ietf.org/html/draft-levine-ogp-= layering
>> >>
>> >> The protocol should describe interaction semantics for th= ese virtual
>> >> worlds,
>> >> independent of transport, leveraging =A0existing standard= s where
>> >> practical.
>> >> It
>> >> should =A0 define =A0 interoperability =A0expectations = =A0 for =A0 server =A0to
>> >> server
>> >> interactions as =A0well as client-server interactions. Th= ough =A0the
>> >> protocol
>> >> is
>> >> independent =A0of transport, =A0early interoperability = =A0trials used
>> >> =A0HTTP(S)
>> >> for
>> >> non-real-time messages. The working group will define spe= cific features
>> >> that
>> >> must be replicated in other transports and will define th= e use of
>> >> HTTP(S)
>> >> as
>> >> a transport of protocol messages.
>> >>
>> >> Foundational components of the protocol include the publi= cation of:
>> >>
>> >> =A0* an =A0abstract =A0type =A0system, =A0suitable =A0for= =A0describing =A0the
>> >> =A0application
>> >> =A0 =A0protocol in an implementation neutral manner,
>> >>
>> >> =A0* a =A0security model describing =A0trust relationship= s =A0between
>> >> participating
>> >> =A0 =A0entities,
>> >>
>> >> =A0* guidelines for =A0the use =A0of existing authenticat= ion =A0and
>> >> confidentiality
>> >> =A0 =A0mechanisms,
>> >>
>> >> =A0* an application-layer protocol for =A0establishing th= e user's avatar in
>> >> the
>> >> =A0 =A0virtual world,
>> >>
>> >> =A0* an =A0application-layer =A0protocol =A0for =A0moving= =A0a =A0user's =A0avatar
>> >> =A0between
>> >> =A0 =A0adjacent and remote locations in the virtual world= ,
>> >>
>> >> =A0* format descriptions for objects and avatars in a vir= tual world, and
>> >>
>> >> =A0* an =A0application-layer protocol =A0for identifying = =A0agents, =A0and
>> >> requesting
>> >> =A0 =A0information about them.
>> >>
>> >> Goals and Milestones:
>> >>
>> >> =A0* October 2009 =A0"Introduction and Goals" = =A0to the IESG as =A0an
>> >> Informational
>> >> =A0 =A0RFC
>> >>
>> >> =A0* October =A02009 "Abstract =A0Type =A0System for= =A0the =A0Transmission of
>> >> =A0Dynamic
>> >> =A0 =A0Structured Data" to the IESG as Proposed Stan= dard
>> >>
>> >> =A0* October 2010 =A0"Foundational Concepts and Tran= sport =A0Expectations" to
>> >> the
>> >> =A0 =A0IESG as Proposed Standard
>> >>
>> >> =A0* February 2010 =A0"Guidelines for =A0Host Authen= tication" to =A0the IESG
>> >> =A0as
>> >> an
>> >> =A0 =A0Informational RFC
>> >>
>> >> =A0* February 2010 "Service Establishment" to t= he IESG as Proposed
>> >> Standard
>> >>
>> >> =A0* February =A02010 "Client =A0Application Launch = =A0Message" =A0to the =A0IESG
>> >> as
>> >> =A0an
>> >> =A0 Informational RFC
>> >>
>> >> =A0* February 2010 "Simulation Presence Establishmen= t" to the IESG as
>> >> Proposed
>> >> =A0 Standard
>> >>
>> >> =A0* June 2010 "Primitive Object Format" to the= IESG as Proposed Standard
>> >>
>> >> =A0* June 2010 "Digital Asset Access" to the IE= SG as Proposed Standard
>> >>
>> >> =A0* June 2010 "Entity Identifiers" to the IESG= as Proposed standard
>> >> _______________________________________________
>> >> ogpx mailing list
>> >> ogpx@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/ogpx
>> >>
>> >
>> >
>> > _______________________________________________
>> > ogpx mailing list
>> > ogpx@ietf.org
>> > https://www.ietf.org/mailman/listinfo/ogpx
>> >
>> >
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

--0015174be270f1372f047189ffe8-- From carlo@alinoe.com Thu Aug 20 07:06:48 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1CA73A6808 for ; Thu, 20 Aug 2009 07:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrL-krNvvqfr for ; Thu, 20 Aug 2009 07:06:48 -0700 (PDT) Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id A0BBF3A67FE for ; Thu, 20 Aug 2009 07:06:47 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090820140649.TTGL9540.viefep16-int.chello.at@edge05.upc.biz>; Thu, 20 Aug 2009 16:06:49 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id We6o1c01b0FlQed05e6p04; Thu, 20 Aug 2009 16:06:49 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Me8If-0007i1-4o; Thu, 20 Aug 2009 16:07:33 +0200 Date: Thu, 20 Aug 2009 16:07:33 +0200 From: Carlo Wood To: Joshua Bell Message-ID: <20090820140733.GA28751@alinoe.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 14:06:49 -0000 On Wed, Aug 19, 2009 at 12:06:09PM -0700, Joshua Bell wrote: > Foundational components of the protocol include the publication of: > >  * an  abstract  type  system,  suitable  for  describing  the  application >    protocol in an implementation neutral manner, > >  * a  security model describing  trust relationships  between participating >    entities, > >  * guidelines for  the use  of existing authentication  and confidentiality >    mechanisms, > >  * an application-layer protocol for  establishing the user's avatar in the >    virtual world, > >  * an  application-layer  protocol  for  moving  a  user's  avatar  between >    adjacent and remote locations in the virtual world, > >  * format descriptions for objects and avatars in a virtual world, and > >  * an  application-layer protocol  for identifying  agents,  and requesting >    information about them. This speaks of "a virtual world", which refering back to the introduction seems to define that there are more than one virtual world possible, and hence the phrase "the virtual world" seems to refer to a single virtual world like Second Life (explicitely excluding open grid virtual worlds), or vica versa. Therefore, the "foundational component": * an  application-layer  protocol  for  moving  a  user's  avatar  between adjacent and remote locations in the virtual world, states that support will be provided for "teleporting" between regions of a single virtual world, but explicitely omits "teleporting" between different virtual worlds. I'd like to know, too, why there is no mention of support for interop like teleporting (and sharing inventory) between DIFFERENT virtual worlds. Someone very clearly has to state what is the intent here. Thanks, -- Carlo Wood From carlo@alinoe.com Thu Aug 20 07:18:07 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36733A6EF6 for ; Thu, 20 Aug 2009 07:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLvaiVsWfWif for ; Thu, 20 Aug 2009 07:18:07 -0700 (PDT) Received: from viefep12-int.chello.at (viefep12-int.chello.at [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id 886E73A6BAB for ; Thu, 20 Aug 2009 07:18:06 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep12-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090820141752.QBJM6129.viefep12-int.chello.at@edge05.upc.biz>; Thu, 20 Aug 2009 16:17:52 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id WeHq1c04m0FlQed05eHrGn; Thu, 20 Aug 2009 16:17:52 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Me8TL-0007se-Ce; Thu, 20 Aug 2009 16:18:35 +0200 Date: Thu, 20 Aug 2009 16:18:35 +0200 From: Carlo Wood To: Morgaine Message-ID: <20090820141835.GB28751@alinoe.com> References: <3a880e2c0908191738x69235df3t4a42cdd5193ef5f7@mail.gmail.com> <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 14:18:07 -0000 I think that what Morgaine is trying to say is that if Linden Lab's official (or hidden) policy is to NOT interop with other virtual worlds, then they are not the right party to trust when it comes to defining a protocol that most, if not all, other parties DO want to support interop. Since it seems, at this point, that the policy of LL will prohibit interop in the future between SL and other grids, there is a lack of trust right now; and as a result of that lack of trust, a very clear statement about the intent of the OGPX (as opposed to LL) about interop MUST be part of this draft. Personally, I will reject any protocol that doesn't make it a priority to concentrate on interoperability (such as sharing LM's and teleporting). So, instead of adding a paragraph that clearly states that the objective of OGPX is to not support interop, I'd rather see a paragraph added that clearly states that it IS to support interop. The keyword here being "clearly". That is certainly not the case at the moment. -- Carlo Wood From meadhbh.siobhan@gmail.com Thu Aug 20 10:54:42 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651503A6F96 for ; Thu, 20 Aug 2009 10:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG3gyRGh7pUA for ; Thu, 20 Aug 2009 10:54:41 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by core3.amsl.com (Postfix) with ESMTP id 52CE73A6853 for ; Thu, 20 Aug 2009 10:54:28 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so26148anc.4 for ; Thu, 20 Aug 2009 10:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GjfNTWBrikpoQFuKPSMN+yiyJcMIb6GCscSDMh91K0Q=; b=F53yWxcFHLkOPjp5A9OWs5FNIT1QGb9UcVm9eiWx0G5ACQgHYLTfEWhIYTB+zLV5JX smdk1o/7/kEQZg9u3RTGZGbhScRakJfUetKcF0cz2QEx3+2/D0RItkNrwMXu/e5IHs/4 kml2RPiBmk6q4ASO0dL592h9OXGQO6vQsVo8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=r0nQwjKJmKac/JcP+PeryevHVunOBHqhGYiTo8biYggHd8iC8qtmndxM09sjjLlu3A ck7drOSuGSbVkjqsu37rDsDF2P33dCSTrgc3dDjtdHCRAIynplv6241bvQmP7wM0REIe SDHU5mdaLAOWu2amb9qAP/XIikq8y4UbhbArU= MIME-Version: 1.0 Received: by 10.101.126.10 with SMTP id d10mr77935ann.147.1250790868513; Thu, 20 Aug 2009 10:54:28 -0700 (PDT) In-Reply-To: <20090820141835.GB28751@alinoe.com> References: <3a880e2c0908191738x69235df3t4a42cdd5193ef5f7@mail.gmail.com> <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> Date: Thu, 20 Aug 2009 10:54:28 -0700 Message-ID: From: Meadhbh Siobhan To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 17:54:42 -0000 Are you seriously suggesting that Linden Lab should not participate in the development of an open virtual worlds protocol? wha? We originally wanted to have a working group where we could resolve issues that separate different virtual worlds protocols. That group was MMOX, and at the BoF we couldn't even get agreement as to what the term "interoperable" meant. Because we could not get agreement, this effort (OGPX) was initiated. Our objective is NOT to define a protocol that encompasses every existent virtual world. It is to produce a protocol that may be used by deployers to produce one, two or many distinct virtual worlds. Deployers would then get to decide which virtual worlds they wish to interact with. They may also choose to provide access to some or all of their "virtual real estate" to other participants through a federation scheme. This latter use case is considered the most common use case, because it allows virtual worlds deployers to share part of their world without requiring them to share ALL of their world. Morgaine has several times mentioned she does not agree with the approach we are taking. I do not apologize that those of us who organized the MMOX and OGPX BoFs have requirements different from hers. Nor do I apologize for taking the "let's boil the ocean one thimble at a time," approach. At the end of the day, there are people interested in deploying open virtual worlds, that are implemented using an open protocol. If people wish to participate constructively in this effort with us, we will participate with them. If people wish to discount the experience of over six years of deploying virtual worlds, and a business model that DEPENDS on providing services to others, they can participate in other standardization efforts. -Cheers -Meadhbh / Infinity On Thu, Aug 20, 2009 at 7:18 AM, Carlo Wood wrote: > > I think that what Morgaine is trying to say is that > if Linden Lab's official (or hidden) policy is to NOT > interop with other virtual worlds, then they are not > the right party to trust when it comes to defining > a protocol that most, if not all, other parties DO > want to support interop. > > Since it seems, at this point, that the policy of > LL will prohibit interop in the future between > SL and other grids, there is a lack of trust right now; > and as a result of that lack of trust, a very clear > statement about the intent of the OGPX (as opposed to LL) > about interop MUST be part of this draft. > > Personally, I will reject any protocol that doesn't > make it a priority to concentrate on interoperability > (such as sharing LM's and teleporting). So, instead > of adding a paragraph that clearly states that the > objective of OGPX is to not support interop, I'd rather > see a paragraph added that clearly states that it > IS to support interop. > > The keyword here being "clearly". That is certainly > not the case at the moment. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From meadhbh.siobhan@gmail.com Thu Aug 20 11:01:05 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BCDC28C0FC for ; Thu, 20 Aug 2009 11:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIWqC3zvrW1O for ; Thu, 20 Aug 2009 11:01:04 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id A52163A6B87 for ; Thu, 20 Aug 2009 11:01:04 -0700 (PDT) Received: by ywh26 with SMTP id 26so97773ywh.5 for ; Thu, 20 Aug 2009 11:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7jCfkW9SnksR0PwK68bnDVNUpzZpAPB+AO5xuUXx/xs=; b=TCT/YGQAaArj8iRNKUwY37DG6WwlEylx2N6VW2mkmW7/d38SfscuzdXIpetyv0L0VF 1b9dmKY1WyP5z5QWeVD1F6/iNGYmhVMPY12sL+gO/CS0H33Dp8CaVZqoGL/bpF4GlJzR Zt/giX8DWUYko+BEmBbVSVOuV7UgvQObkUI/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pg6LPKN9C4MD7DNZGnUQl5eoHBQc39cYZcrdVxf1FqQFWu0XUcZcoT/KNislsDU0sE MqKx5g7kuoboQ4SQtuhuN3WhvfJG3IcJRqhdZJamSH+BH7yvsL7hJ/jE3dfdQGodpH2F DOOc/7igD8QtcqqewGsnnNs0SSwqsaV4vQFhA= MIME-Version: 1.0 Received: by 10.101.109.18 with SMTP id l18mr130193anm.52.1250791266720; Thu, 20 Aug 2009 11:01:06 -0700 (PDT) In-Reply-To: <20090820141835.GB28751@alinoe.com> References: <3a880e2c0908191738x69235df3t4a42cdd5193ef5f7@mail.gmail.com> <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> Date: Thu, 20 Aug 2009 11:01:06 -0700 Message-ID: From: Meadhbh Siobhan To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 18:01:05 -0000 and to your point about landmarks and teleport. teleporting between points in the virtual world, even if the origin and destination are managed by different administrative domains has always been part of the protocol proposal. we're not taking that out. sharable landmarks haven't been explicitly mentioned, but we do require a way to uniquely address locations in a virtual world (otherwise how do you represent where you're teleporting too?) there's been a lot of discussion about using URLs to uniquely identify regions. If you added an offset from the middle of the region to the region's URL, that would be the beginning of a landmark. hmm... i don't think we've explicitly mentioned that regions have a bounding surface and an origin, but lemme put that on the list of things to add to the spec. -cheers -meadhbh On Thu, Aug 20, 2009 at 7:18 AM, Carlo Wood wrote: > > I think that what Morgaine is trying to say is that > if Linden Lab's official (or hidden) policy is to NOT > interop with other virtual worlds, then they are not > the right party to trust when it comes to defining > a protocol that most, if not all, other parties DO > want to support interop. > > Since it seems, at this point, that the policy of > LL will prohibit interop in the future between > SL and other grids, there is a lack of trust right now; > and as a result of that lack of trust, a very clear > statement about the intent of the OGPX (as opposed to LL) > about interop MUST be part of this draft. > > Personally, I will reject any protocol that doesn't > make it a priority to concentrate on interoperability > (such as sharing LM's and teleporting). So, instead > of adding a paragraph that clearly states that the > objective of OGPX is to not support interop, I'd rather > see a paragraph added that clearly states that it > IS to support interop. > > The keyword here being "clearly". That is certainly > not the case at the moment. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From meadhbh.siobhan@gmail.com Thu Aug 20 11:11:25 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76F928C1AC for ; Thu, 20 Aug 2009 11:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb3sIu4b-0X2 for ; Thu, 20 Aug 2009 11:11:24 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 8A6DA28C1AA for ; Thu, 20 Aug 2009 11:11:24 -0700 (PDT) Received: by ywh26 with SMTP id 26so106283ywh.5 for ; Thu, 20 Aug 2009 11:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=snVxrAILaRXYFS365kDx4slJ0I4b77QLSMxoH6W0wV8=; b=tS4ptMuq+ZseeTkccQNLpWyH/0k1MD6YRH5esSdVS1UovyDklcDajl41buyn08wdnY +XUD20D5pVEGDIqn01RgfjUYWO8N7Q7+cY+mdlcy7LCu/TDIdnFKKXGZrfkC+1Nst45N UTfPoJm205gYe95IBHJHLLReeU8v9kpfJKg7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=v0KTc1bxF8Luy7EY/ctKg+FZGbrwVJNUFdoX2l4OuxR3+rhY5PBITMOTNIESLBz4JS kMN3NbG7Avvc+130vXmgXgJXiVqtP1S3xZrFcszZXZPzMcdqoZg/oD35yFyRurGnZqms HENqLGIfMkid8HkJblgP/WLVFt0rCLUcrm1cg= MIME-Version: 1.0 Received: by 10.100.40.17 with SMTP id n17mr83633ann.187.1250791886584; Thu, 20 Aug 2009 11:11:26 -0700 (PDT) In-Reply-To: <20090820140733.GA28751@alinoe.com> References: <20090820140733.GA28751@alinoe.com> Date: Thu, 20 Aug 2009 11:11:26 -0700 Message-ID: From: Meadhbh Siobhan To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 18:11:26 -0000 right. we're supposed to be using "a" virtual world instead of "the" virtual world. lemme change that. i don't know if we're supporting teleporting between radically different virtual worlds like WoW and Second Life. But teleporting between two virtual worlds that are both using OGP is not outside the realm of possibility, and is a use case that has recently been brought up in discussions about solutions like Sametime 3d and Linden's yet to be named "behind the firewall" solution. However... the protocol assumes the existence of a virtual world whose different simulation regions MAY be administered by distinct organization entities. That is, you might have one virtual world where half the land is managed by IBM and the other half by Linden. Or, you might have a virtual world where each region is administered by an individual. Or, you might have a virtual world where you own all the land. We're not defining the ownership / administration policy in terms of who owns what, but to say "it's possible for each region and each agent host to be owned / operated by a different organization/individual, so don't make ANY assumptions that the peer you're talking too is implicitly trusted." Which is my way of saying... teleporting AND region crossings are supposed to be covered by the protocol. We put it in the charter in with the text: "Such virtual worlds may consist of regions administered by distinct organizations." If the implications of that sentence aren't clear, let's make it clearer. do you think we should add something like "and avatars can walk across administrative boundaries or teleport across them." ? On Thu, Aug 20, 2009 at 7:07 AM, Carlo Wood wrote: > On Wed, Aug 19, 2009 at 12:06:09PM -0700, Joshua Bell wrote: >> Foundational components of the protocol include the publication of: >> >> =A0* an =A0abstract =A0type =A0system, =A0suitable =A0for =A0describing = =A0the =A0application >> =A0 =A0protocol in an implementation neutral manner, >> >> =A0* a =A0security model describing =A0trust relationships =A0between pa= rticipating >> =A0 =A0entities, >> >> =A0* guidelines for =A0the use =A0of existing authentication =A0and conf= identiality >> =A0 =A0mechanisms, >> >> =A0* an application-layer protocol for =A0establishing the user's avatar= in the >> =A0 =A0virtual world, >> >> =A0* an =A0application-layer =A0protocol =A0for =A0moving =A0a =A0user's= =A0avatar =A0between >> =A0 =A0adjacent and remote locations in the virtual world, >> >> =A0* format descriptions for objects and avatars in a virtual world, and >> >> =A0* an =A0application-layer protocol =A0for identifying =A0agents, =A0a= nd requesting >> =A0 =A0information about them. > > This speaks of "a virtual world", which refering back to the introduction > seems to define that there are more than one virtual world possible, > and hence the phrase "the virtual world" seems to refer to a single virtu= al > world like Second Life (explicitely excluding open grid virtual worlds), > or vica versa. > > Therefore, the "foundational component": > > * an =A0application-layer =A0protocol =A0for =A0moving =A0a =A0user's =A0= avatar =A0between > =A0adjacent and remote locations in the virtual world, > > states that support will be provided for "teleporting" between regions > of a single virtual world, but explicitely omits "teleporting" between > different virtual worlds. > > I'd like to know, too, why there is no mention of support for > interop like teleporting (and sharing inventory) between DIFFERENT > virtual worlds. > > Someone very clearly has to state what is the intent here. > Thanks, > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From morgaine.dinova@googlemail.com Thu Aug 20 13:20:09 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75353A6DA4 for ; Thu, 20 Aug 2009 13:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5iLJs6wnqoN for ; Thu, 20 Aug 2009 13:20:08 -0700 (PDT) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by core3.amsl.com (Postfix) with ESMTP id EDBDE3A68C4 for ; Thu, 20 Aug 2009 13:20:07 -0700 (PDT) Received: by ewy2 with SMTP id 2so199626ewy.43 for ; Thu, 20 Aug 2009 13:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=kBd3gSSdP8QT3ILs/sR5aEaSBznT4NQll+RVH7a57lQ=; b=rH+UUHInq2rpV/y6pO1WHKtwa5kwK2WpFCS+I12L/7HXIrhLFdmYgmpd7i7GH6Ef12 tn9GXA7zPusyDmoTZ+iCpp/vhbsuwimT9YLxwsbyb3y83TKybUpv06R8Vml2JH4YGJHZ Wo9sWZFJ0TAKkC71Wj+QEebkVTxRcxcqvIAzM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=o3uvBOOM9Sd6uIcTW74F92PiXfS1B/KrXcsKz2v7ICGZ/5mN8OQWnh0ps7PK2yOzZP d/l8PmMNbaF0ma2OY+SvCn1Is8kUdCe14NArOXDdBK7BdrZGvjckTKW8oGLed1jRBIQt M2pY60AIXluW7NsVFG24I04C37M/8L9Uzq1xw= MIME-Version: 1.0 Received: by 10.210.119.16 with SMTP id r16mr250188ebc.49.1250799594647; Thu, 20 Aug 2009 13:19:54 -0700 (PDT) In-Reply-To: References: <3a880e2c0908191738x69235df3t4a42cdd5193ef5f7@mail.gmail.com> <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> Date: Thu, 20 Aug 2009 21:19:54 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00151748de6c862eda047198796c Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 20:20:09 -0000 --00151748de6c862eda047198796c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Meadhbh is once again misrepresenting people: On Thu, Aug 20, 2009 at 6:54 PM, Meadhbh Siobhan wrote, in answer to Carlo: > Are you seriously suggesting that Linden Lab should not participate in > the development of an open virtual worlds protocol? wha? > No, Carlo did not suggest that. Carlo simply asked for an answer on whether OGP would also cover interop between more than one virtual world. Joshua's latest group charter does not list such communication in the scope of OGPX, and therefore Carlo's question is a good one. I have also been misrepresented, but that is of no matter compared to getting the scope of OGPX clarified cleanly and openly, so that we know exactly what the protocol will be specified to do and what it will not address. Morgaine. On Thu, Aug 20, 2009 at 6:54 PM, Meadhbh Siobhan wrote: > Are you seriously suggesting that Linden Lab should not participate in > the development of an open virtual worlds protocol? wha? > > We originally wanted to have a working group where we could resolve > issues that separate different virtual worlds protocols. That group > was MMOX, and at the BoF we couldn't even get agreement as to what the > term "interoperable" meant. > > Because we could not get agreement, this effort (OGPX) was initiated. > Our objective is NOT to define a protocol that encompasses every > existent virtual world. It is to produce a protocol that may be used > by deployers to produce one, two or many distinct virtual worlds. > Deployers would then get to decide which virtual worlds they wish to > interact with. They may also choose to provide access to some or all > of their "virtual real estate" to other participants through a > federation scheme. This latter use case is considered the most common > use case, because it allows virtual worlds deployers to share part of > their world without requiring them to share ALL of their world. > > Morgaine has several times mentioned she does not agree with the > approach we are taking. I do not apologize that those of us who > organized the MMOX and OGPX BoFs have requirements different from > hers. Nor do I apologize for taking the "let's boil the ocean one > thimble at a time," approach. At the end of the day, there are people > interested in deploying open virtual worlds, that are implemented > using an open protocol. If people wish to participate constructively > in this effort with us, we will participate with them. If people wish > to discount the experience of over six years of deploying virtual > worlds, and a business model that DEPENDS on providing services to > others, they can participate in other standardization efforts. > > -Cheers > -Meadhbh / Infinity > > > > > On Thu, Aug 20, 2009 at 7:18 AM, Carlo Wood wrote: > > > > I think that what Morgaine is trying to say is that > > if Linden Lab's official (or hidden) policy is to NOT > > interop with other virtual worlds, then they are not > > the right party to trust when it comes to defining > > a protocol that most, if not all, other parties DO > > want to support interop. > > > > Since it seems, at this point, that the policy of > > LL will prohibit interop in the future between > > SL and other grids, there is a lack of trust right now; > > and as a result of that lack of trust, a very clear > > statement about the intent of the OGPX (as opposed to LL) > > about interop MUST be part of this draft. > > > > Personally, I will reject any protocol that doesn't > > make it a priority to concentrate on interoperability > > (such as sharing LM's and teleporting). So, instead > > of adding a paragraph that clearly states that the > > objective of OGPX is to not support interop, I'd rather > > see a paragraph added that clearly states that it > > IS to support interop. > > > > The keyword here being "clearly". That is certainly > > not the case at the moment. > > > > -- > > Carlo Wood > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > --00151748de6c862eda047198796c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Meadhbh is once again misrepresenting people:

On Thu, Aug 20, 2009 a= t 6:54 PM, Meadhbh Siobhan <meadhbh.siobhan@gmail.com> wrote, in answe= r to Carlo:
Are you seriously= suggesting that Linden Lab should not participate in
the development of an open virtual worlds protocol? wha?

No, Carlo did not suggest that.=A0 Carlo simply asked= for an answer on whether OGP would also cover interop between more than on= e virtual world.=A0 Joshua's latest group charter does not list such co= mmunication in the scope of OGPX, and therefore Carlo's question is a g= ood one.

=A0I have also been misrepresented, but that is of no matter= compared to getting the scope of OGPX clarified cleanly and openly, so tha= t we know exactly what the protocol will be specified to do and what it wil= l not address.


Morgaine.









On Thu, Aug 20, 2009 at 6:54 PM, Meadhbh Siobhan <meadhbh.siobhan@g= mail.com> wrote:
Are you seriously= suggesting that Linden Lab should not participate in
the development of an open virtual worlds protocol? wha?

We originally wanted to have a working group where we could resolve
issues that separate different virtual worlds protocols. That group
was MMOX, and at the BoF we couldn't even get agreement as to what the<= br> term "interoperable" meant.

Because we could not get agreement, this effort (OGPX) was initiated.
Our objective is NOT to define a protocol that encompasses every
existent virtual world. It is to produce a protocol that may be used
by deployers to produce one, two or many distinct virtual worlds.
Deployers would then get to decide which virtual worlds they wish to
interact with. They may also choose to provide access to some or all
of their "virtual real estate" to other participants through a federation scheme. This latter use case is considered the most common
use case, because it allows virtual worlds deployers to share part of
their world without requiring them to share ALL of their world.

Morgaine has several times mentioned she does not agree with the
approach we are taking. I do not apologize that those of us who
organized the MMOX and OGPX BoFs have requirements different from
hers. Nor do I apologize for taking the "let's boil the ocean one<= br> thimble at a time," approach. At the end of the day, there are people<= br> interested in deploying open virtual worlds, that are implemented
using an open protocol. If people wish to participate constructively
in this effort with us, we will participate with them. If people wish
to discount the experience of over six years of deploying virtual
worlds, and a business model that DEPENDS on providing services to
others, they can participate in other standardization efforts.

-Cheers
-Meadhbh / Infinity




On Thu, Aug 20, 2009 at 7:18 AM, Carlo Wood<carlo@alinoe.com> wrote:
>
> I think that what Morgaine is trying to say is that
> if Linden Lab's official (or hidden) policy is to NOT
> interop with other virtual worlds, then they are not
> the right party to trust when it comes to defining
> a protocol that most, if not all, other parties DO
> want to support interop.
>
> Since it seems, at this point, that the policy of
> LL will prohibit interop in the future between
> SL and other grids, there is a lack of trust right now;
> and as a result of that lack of trust, a very clear
> statement about the intent of the OGPX (as opposed to LL)
> about interop MUST be part of this draft.
>
> Personally, I will reject any protocol that doesn't
> make it a priority to concentrate on interoperability
> (such as sharing LM's and teleporting). So, instead
> of adding a paragraph that clearly states that the
> objective of OGPX is to not support interop, I'd rather
> see a paragraph added that clearly states that it
> IS to support interop.
>
> The keyword here being "clearly". That is certainly
> not the case at the moment.
>
> --
> Carlo Wood <carlo@alinoe.com>

--00151748de6c862eda047198796c-- From infinity@lindenlab.com Thu Aug 20 13:42:11 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913CE28C123 for ; Thu, 20 Aug 2009 13:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17rKk+N9PfGZ for ; Thu, 20 Aug 2009 13:42:10 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id B13203A6CF5 for ; Thu, 20 Aug 2009 13:42:10 -0700 (PDT) Received: by pxi1 with SMTP id 1so3873601pxi.31 for ; Thu, 20 Aug 2009 13:42:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.138.7 with SMTP id q7mr17898wfn.314.1250800934547; Thu, 20 Aug 2009 13:42:14 -0700 (PDT) In-Reply-To: References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> Date: Thu, 20 Aug 2009 13:42:14 -0700 Message-ID: <3a880e2c0908201342n50dd18e0o19a30722fc1847dd@mail.gmail.com> From: Infinity Linden To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 20:42:11 -0000 morgaine, let's let carlo speak for carlo. -thx On Thu, Aug 20, 2009 at 1:19 PM, Morgaine w= rote: > Meadhbh is once again misrepresenting people: > > On Thu, Aug 20, 2009 at 6:54 PM, Meadhbh Siobhan > wrote, in answer to Carlo: >> >> Are you seriously suggesting that Linden Lab should not participate in >> the development of an open virtual worlds protocol? wha? > > No, Carlo did not suggest that.=A0 Carlo simply asked for an answer on wh= ether > OGP would also cover interop between more than one virtual world.=A0 Josh= ua's > latest group charter does not list such communication in the scope of OGP= X, > and therefore Carlo's question is a good one. > > =A0I have also been misrepresented, but that is of no matter compared to > getting the scope of OGPX clarified cleanly and openly, so that we know > exactly what the protocol will be specified to do and what it will not > address. > > > Morgaine. > > > > > > > > > > On Thu, Aug 20, 2009 at 6:54 PM, Meadhbh Siobhan > wrote: >> >> Are you seriously suggesting that Linden Lab should not participate in >> the development of an open virtual worlds protocol? wha? >> >> We originally wanted to have a working group where we could resolve >> issues that separate different virtual worlds protocols. That group >> was MMOX, and at the BoF we couldn't even get agreement as to what the >> term "interoperable" meant. >> >> Because we could not get agreement, this effort (OGPX) was initiated. >> Our objective is NOT to define a protocol that encompasses every >> existent virtual world. It is to produce a protocol that may be used >> by deployers to produce one, two or many distinct virtual worlds. >> Deployers would then get to decide which virtual worlds they wish to >> interact with. They may also choose to provide access to some or all >> of their "virtual real estate" to other participants through a >> federation scheme. This latter use case is considered the most common >> use case, because it allows virtual worlds deployers to share part of >> their world without requiring them to share ALL of their world. >> >> Morgaine has several times mentioned she does not agree with the >> approach we are taking. I do not apologize that those of us who >> organized the MMOX and OGPX BoFs have requirements different from >> hers. Nor do I apologize for taking the "let's boil the ocean one >> thimble at a time," approach. At the end of the day, there are people >> interested in deploying open virtual worlds, that are implemented >> using an open protocol. If people wish to participate constructively >> in this effort with us, we will participate with them. If people wish >> to discount the experience of over six years of deploying virtual >> worlds, and a business model that DEPENDS on providing services to >> others, they can participate in other standardization efforts. >> >> -Cheers >> -Meadhbh / Infinity >> >> >> >> >> On Thu, Aug 20, 2009 at 7:18 AM, Carlo Wood wrote: >> > >> > I think that what Morgaine is trying to say is that >> > if Linden Lab's official (or hidden) policy is to NOT >> > interop with other virtual worlds, then they are not >> > the right party to trust when it comes to defining >> > a protocol that most, if not all, other parties DO >> > want to support interop. >> > >> > Since it seems, at this point, that the policy of >> > LL will prohibit interop in the future between >> > SL and other grids, there is a lack of trust right now; >> > and as a result of that lack of trust, a very clear >> > statement about the intent of the OGPX (as opposed to LL) >> > about interop MUST be part of this draft. >> > >> > Personally, I will reject any protocol that doesn't >> > make it a priority to concentrate on interoperability >> > (such as sharing LM's and teleporting). So, instead >> > of adding a paragraph that clearly states that the >> > objective of OGPX is to not support interop, I'd rather >> > see a paragraph added that clearly states that it >> > IS to support interop. >> > >> > The keyword here being "clearly". That is certainly >> > not the case at the moment. >> > >> > -- >> > Carlo Wood >> > _______________________________________________ >> > ogpx mailing list >> > ogpx@ietf.org >> > https://www.ietf.org/mailman/listinfo/ogpx >> > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From morgaine.dinova@googlemail.com Thu Aug 20 13:43:01 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2083A6F77 for ; Thu, 20 Aug 2009 13:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7wnt+Eigrqf for ; Thu, 20 Aug 2009 13:42:57 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id E0CEC3A6F6B for ; Thu, 20 Aug 2009 13:42:51 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so85134eye.31 for ; Thu, 20 Aug 2009 13:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=WmqObAjo3TbrLMRGEr6HrmQGPmDd7jRjRKNPKA6XozE=; b=lF6nsXmroOxCNsouuQc0lzhA+IzoIeYcy+LWPkXTNGwwcwEp9L8aT78ZhZWVrSBo04 h751Xh96x/NpAnwb3cmWlJdBWDxqlyKdRHwuJxE+jg4jLb97dmVXdkxOgTsouzVRtqdf 7KdC095q4FhYxpjvSnkiE6bx+Zh9qlaRPq8KM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=k+I+oZ6H/YssD8f2F20pJw9/8F+HHhL10iztmuT/T33oFk6bx6mN/in54riAy38kj6 gj9UX1/waP+2iUoeepl7OQmIL69YgZHpb06nZH8pJxzznXzcJSmICMKSOScW8AhNj1dm +NMA5+cbiL/FVl6mFTCjvgIWL7G3iRHXSCZrk= MIME-Version: 1.0 Received: by 10.210.11.17 with SMTP id 17mr237877ebk.96.1250800973752; Thu, 20 Aug 2009 13:42:53 -0700 (PDT) In-Reply-To: References: <3a880e2c0908191738x69235df3t4a42cdd5193ef5f7@mail.gmail.com> <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> Date: Thu, 20 Aug 2009 21:42:53 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174be630b9a95b047198cb21 Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 20:43:01 -0000 --0015174be630b9a95b047198cb21 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan wrote, in answer to Carlo Wood: and to your point about landmarks and teleport. > > teleporting between points in the virtual world, even if the origin > and destination are managed by different administrative domains has > always been part of the protocol proposal. we're not taking that out. > That was not Carlo's point. Carlo asked about landmarks and teleports *between virtual worlds*, so stating that you're not taking them out from within a single world is not answering his question. The question being asked is a very simple one. I do not understand why a clear answer is not being given. This is a matter of huge importance to the large number of SL-compatible open grids that already exist, with more appearing regularly. It needs to be clearly stated whether mechanisms for interop between SL-compatible worlds will be within the scope of the OGPX group, or not. Defining our scope is our primary task at this time. This question cannot be dodged. Morgaine. On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan wrote: > and to your point about landmarks and teleport. > > teleporting between points in the virtual world, even if the origin > and destination are managed by different administrative domains has > always been part of the protocol proposal. we're not taking that out. > > sharable landmarks haven't been explicitly mentioned, but we do > require a way to uniquely address locations in a virtual world > (otherwise how do you represent where you're teleporting too?) there's > been a lot of discussion about using URLs to uniquely identify > regions. If you added an offset from the middle of the region to the > region's URL, that would be the beginning of a landmark. > > hmm... i don't think we've explicitly mentioned that regions have a > bounding surface and an origin, but lemme put that on the list of > things to add to the spec. > > -cheers > -meadhbh > > On Thu, Aug 20, 2009 at 7:18 AM, Carlo Wood wrote: > > > > I think that what Morgaine is trying to say is that > > if Linden Lab's official (or hidden) policy is to NOT > > interop with other virtual worlds, then they are not > > the right party to trust when it comes to defining > > a protocol that most, if not all, other parties DO > > want to support interop. > > > > Since it seems, at this point, that the policy of > > LL will prohibit interop in the future between > > SL and other grids, there is a lack of trust right now; > > and as a result of that lack of trust, a very clear > > statement about the intent of the OGPX (as opposed to LL) > > about interop MUST be part of this draft. > > > > Personally, I will reject any protocol that doesn't > > make it a priority to concentrate on interoperability > > (such as sharing LM's and teleporting). So, instead > > of adding a paragraph that clearly states that the > > objective of OGPX is to not support interop, I'd rather > > see a paragraph added that clearly states that it > > IS to support interop. > > > > The keyword here being "clearly". That is certainly > > not the case at the moment. > > > > -- > > Carlo Wood > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > --0015174be630b9a95b047198cb21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan= <meadhbh= .siobhan@gmail.com> wrote, in answer to Carlo Wood:

and to your point about landmarks and teleport.

teleporting between points in the virtual world, even if the origin
and destination are managed by different administrative domains has
always been part of the protocol proposal. we're not taking that out.


That was not Carlo's point.=A0 Carlo asked ab= out landmarks and teleports between=A0 virtual worlds, so stating th= at you're not taking them out from within a single world is not answeri= ng his question.

The question being asked is a very simple one.=A0 I do not understand w= hy a clear answer is not being given.

This is a matter of huge impor= tance to the large number of SL-compatible open grids that already exist, w= ith more appearing regularly.=A0 It needs to be clearly stated whether mech= anisms for interop between SL-compatible worlds will be within the scope of= the OGPX group, or not.

Defining our scope is our primary task at this time.=A0 This question c= annot be dodged.


Morgaine.






On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh S= iobhan <m= eadhbh.siobhan@gmail.com> wrote:
and to your point= about landmarks and teleport.

teleporting between points in the virtual world, even if the origin
and destination are managed by different administrative domains has
always been part of the protocol proposal. we're not taking that out.
sharable landmarks haven't been explicitly mentioned, but we do
require a way to uniquely address locations in a virtual world
(otherwise how do you represent where you're teleporting too?) there= 9;s
been a lot of discussion about using URLs to uniquely identify
regions. If you added an offset from the middle of the region to the
region's URL, that would be the beginning of a landmark.

hmm... i don't think we've explicitly mentioned that regions have a=
bounding surface and an origin, but lemme put that on the list of
things to add to the spec.

-cheers
-meadhbh

On Thu, Aug 20, 2009 at 7:18 AM, Carlo Wood<carlo@alinoe.com> wrote:
>
> I think that what Morgaine is trying to say is that
> if Linden Lab's official (or hidden) policy is to NOT
> interop with other virtual worlds, then they are not
> the right party to trust when it comes to defining
> a protocol that most, if not all, other parties DO
> want to support interop.
>
> Since it seems, at this point, that the policy of
> LL will prohibit interop in the future between
> SL and other grids, there is a lack of trust right now;
> and as a result of that lack of trust, a very clear
> statement about the intent of the OGPX (as opposed to LL)
> about interop MUST be part of this draft.
>
> Personally, I will reject any protocol that doesn't
> make it a priority to concentrate on interoperability
> (such as sharing LM's and teleporting). So, instead
> of adding a paragraph that clearly states that the
> objective of OGPX is to not support interop, I'd rather
> see a paragraph added that clearly states that it
> IS to support interop.
>
> The keyword here being "clearly". That is certainly
> not the case at the moment.
>
> --
> Carlo Wood <carlo@alinoe.com>

--0015174be630b9a95b047198cb21-- From infinity@lindenlab.com Thu Aug 20 14:06:50 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05BF13A6F48 for ; Thu, 20 Aug 2009 14:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+q7WrSx2VCD for ; Thu, 20 Aug 2009 14:06:49 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 0A6C53A6DCB for ; Thu, 20 Aug 2009 14:06:49 -0700 (PDT) Received: by pzk4 with SMTP id 4so17633pzk.29 for ; Thu, 20 Aug 2009 14:06:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.61.33 with SMTP id j33mr42970wfa.236.1250802410627; Thu, 20 Aug 2009 14:06:50 -0700 (PDT) In-Reply-To: References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> Date: Thu, 20 Aug 2009 14:06:50 -0700 Message-ID: <3a880e2c0908201406j5a2995ccjb0ec529c22540189@mail.gmail.com> From: Infinity Linden To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 21:06:50 -0000 morgaine. flip back up in the thread where we talk about teleport and landmarks. it's the message that begins with "and to your point about landmarks and teleport" i think we've also very clearly responded to the question, "do you support interaction between virtual worlds in addition to interactions within a single virtual world?" the answer is yes, because the protocol defines the mechanism for communicating between hosts, not the policy of "you should only communicate between hosts supporting the same virtual world." we do not explicitly call it out as being supported for the same reason we do not explicitly say "you can only have red avatars on the 'red avatars only grid.'" that is, this is a POLICY decision. the same protocol can carry information about the "red avatars only grid" as well as other virtual worlds. i would argue that intentionally calling out detailed use cases in the charter; use cases that do not violate the wording of the charter, may imply that use cases that are not detailed in the charter are explicitly out of scope. Further, if we started enumerating use cases in the charter, some might feel it was appropriate to introduce prohibitions against other use cases in the protocol itself. the intent of this group is to work on a protocol that will enable open virtual worlds. the primary focus is to define the interaction between components in the same virtual world and between external data sources and the virtual world, but it does not preclude work on world-to-world interactions where group participants believe such use cases are important and practical. we do not explicitly call out this focus because it is one of policy; our job is to define the protocol and processing expectations, not tell deployers what features their virtual world should support or who should be allowed to participate. -cheers -meadhbh On Thu, Aug 20, 2009 at 1:42 PM, Morgaine w= rote: > On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan > wrote, in answer to Carlo Wood: > >> and to your point about landmarks and teleport. >> >> teleporting between points in the virtual world, even if the origin >> and destination are managed by different administrative domains has >> always been part of the protocol proposal. we're not taking that out. > > > That was not Carlo's point.=A0 Carlo asked about landmarks and teleports > between=A0 virtual worlds, so stating that you're not taking them out fro= m > within a single world is not answering his question. > > The question being asked is a very simple one.=A0 I do not understand why= a > clear answer is not being given. > > This is a matter of huge importance to the large number of SL-compatible > open grids that already exist, with more appearing regularly.=A0 It needs= to > be clearly stated whether mechanisms for interop between SL-compatible > worlds will be within the scope of the OGPX group, or not. > > Defining our scope is our primary task at this time.=A0 This question can= not > be dodged. > > > Morgaine. > > > > > > > > On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan > wrote: >> >> and to your point about landmarks and teleport. >> >> teleporting between points in the virtual world, even if the origin >> and destination are managed by different administrative domains has >> always been part of the protocol proposal. we're not taking that out. >> >> sharable landmarks haven't been explicitly mentioned, but we do >> require a way to uniquely address locations in a virtual world >> (otherwise how do you represent where you're teleporting too?) there's >> been a lot of discussion about using URLs to uniquely identify >> regions. If you added an offset from the middle of the region to the >> region's URL, that would be the beginning of a landmark. >> >> hmm... i don't think we've explicitly mentioned that regions have a >> bounding surface and an origin, but lemme put that on the list of >> things to add to the spec. >> >> -cheers >> -meadhbh >> >> On Thu, Aug 20, 2009 at 7:18 AM, Carlo Wood wrote: >> > >> > I think that what Morgaine is trying to say is that >> > if Linden Lab's official (or hidden) policy is to NOT >> > interop with other virtual worlds, then they are not >> > the right party to trust when it comes to defining >> > a protocol that most, if not all, other parties DO >> > want to support interop. >> > >> > Since it seems, at this point, that the policy of >> > LL will prohibit interop in the future between >> > SL and other grids, there is a lack of trust right now; >> > and as a result of that lack of trust, a very clear >> > statement about the intent of the OGPX (as opposed to LL) >> > about interop MUST be part of this draft. >> > >> > Personally, I will reject any protocol that doesn't >> > make it a priority to concentrate on interoperability >> > (such as sharing LM's and teleporting). So, instead >> > of adding a paragraph that clearly states that the >> > objective of OGPX is to not support interop, I'd rather >> > see a paragraph added that clearly states that it >> > IS to support interop. >> > >> > The keyword here being "clearly". That is certainly >> > not the case at the moment. >> > >> > -- >> > Carlo Wood >> > _______________________________________________ >> > ogpx mailing list >> > ogpx@ietf.org >> > https://www.ietf.org/mailman/listinfo/ogpx >> > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From infinity@lindenlab.com Thu Aug 20 14:19:54 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239593A6DCA for ; Thu, 20 Aug 2009 14:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8luwYzTm6or for ; Thu, 20 Aug 2009 14:19:53 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 28FC93A6C23 for ; Thu, 20 Aug 2009 14:19:53 -0700 (PDT) Received: by pxi1 with SMTP id 1so3894905pxi.31 for ; Thu, 20 Aug 2009 14:19:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.1.9 with SMTP id 9mr21965wfa.102.1250803196852; Thu, 20 Aug 2009 14:19:56 -0700 (PDT) Date: Thu, 20 Aug 2009 14:19:56 -0700 Message-ID: <3a880e2c0908201419p4d47fc1chddc59037a6427f47@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ogpx] OGPX Draft Charter : 2009 08 20 X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 21:19:54 -0000 Okay... i modified the charter to remove extraneous "the" references, to underscore the idea that we're talking about a future with multiple virtual worlds. Working Group Name: Open Grid Protocol (OGPX) Chairs: TBD Area and Area Directors: Applications Area Lisa Dusseault Alexey Melnikov Responsible Area Director: TBD Mailing List: ogpx@ietf.org http://www.ietf.org/mailman/listinfo/ogpx Description of Working Group: The working group will define the Open Grid Protocol (OGP) for collaborative 3-dimensional virtual worlds. The protocol permits users to interact with each other while represented as "avatars," or digital representations of the user. Within a single virtual world, avatars exist in at most one location in a shared virtual space. Conforming client applications use the protocol to manipulate and move the user's avatar, create objects in a virtual world, interact with other users and their surroundings and consume and create media and information from sources inside and outside their virtual world. Adjacent locations in virtual worlds accessible by this protocol may be explicitly partitioned into "regions" to facilitate the computational and communication load balancing required to simulate the virtual environment. Such virtual worlds may consist of regions administered by distinct organizations. Though these virtual worlds may be partitioned, they remain "un-sharded;" all inhabitants and objects in a particular location in a virtual world may initiate interaction with all other inhabitants and objects in that location; and, service endpoint addresses refer to at most one location. The state of a virtual world is independent of the client applications that access it and may persist between user sessions. The protocol defined by this group will carry information about the virtual environment, its contents and its inhabitants. It is an application layer protocol, independent of transport, based partially on these previously published internet drafts: * http://tools.ietf.org/html/draft-hamrick-ogp-intro * http://tools.ietf.org/html/draft-hamrick-llsd * http://tools.ietf.org/html/draft-hamrick-ogp-auth * http://tools.ietf.org/html/draft-hamrick-ogp-launch * http://tools.ietf.org/html/draft-lentczner-ogp-base * http://tools.ietf.org/html/draft-levine-ogp-clientcap * http://tools.ietf.org/html/draft-levine-ogp-layering The protocol should describe interaction semantics for these virtual worlds, independent of transport, leveraging existing standards where practical. It should define interoperability expectations for server to server interactions as well as client-server interactions. Though the protocol is independent of transport, early interoperability trials used HTTP(S) for non-real-time messages. The working group will define specific features that must be replicated in other transports and will define the use of HTTP(S) as a transport of protocol messages. Foundational components of the protocol include the publication of: * an abstract type system, suitable for describing the application protocol in an implementation neutral manner, * a security model describing trust relationships between participating entities, * guidelines for the use of existing authentication and confidentiality mechanisms, * an application-layer protocol for establishing the user's avatar in a virtual world, * an application-layer protocol for moving a user's avatar between adjacent and remote locations in a virtual world, * format descriptions for objects and avatars in a virtual world, and * an application-layer protocol for identifying agents, and requesting information about them. Goals and Milestones: * October 2009 "Introduction and Goals" to the IESG as an Informational RFC * October 2009 "Abstract Type System for the Transmission of Dynamic Structured Data" to the IESG as Proposed Standard * October 2010 "Foundational Concepts and Transport Expectations" to the IESG as Proposed Standard * February 2010 "Guidelines for Host Authentication" to the IESG as an Informational RFC * February 2010 "Service Establishment" to the IESG as Proposed Standard * February 2010 "Client Application Launch Message" to the IESG as an Informational RFC * February 2010 "Simulation Presence Establishment" to the IESG as Proposed Standard * June 2010 "Primitive Object Format" to the IESG as Proposed Standard * June 2010 "Digital Asset Access" to the IESG as Proposed Standard * June 2010 "Entity Identifiers" to the IESG as Proposed standard From josh@lindenlab.com Thu Aug 20 15:59:25 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E11743A6D9C for ; Thu, 20 Aug 2009 15:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.373 X-Spam-Level: X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIyv2+k+Hk+5 for ; Thu, 20 Aug 2009 15:59:24 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 1D3183A6DBA for ; Thu, 20 Aug 2009 15:59:13 -0700 (PDT) Received: by ywh26 with SMTP id 26so346448ywh.5 for ; Thu, 20 Aug 2009 15:59:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.18.20 with SMTP id 20mr474287anr.141.1250809153280; Thu, 20 Aug 2009 15:59:13 -0700 (PDT) In-Reply-To: References: <20090820140733.GA28751@alinoe.com> Date: Thu, 20 Aug 2009 15:59:13 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016e6470bdc435b6604719ab324 Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 22:59:26 -0000 --0016e6470bdc435b6604719ab324 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Thu, Aug 20, 2009 at 7:07 AM, Carlo Wood wrote: > > This speaks of "a virtual world", which refering back to the introduction > seems to define that there are more than one virtual world possible, > and hence the phrase "the virtual world" seems to refer to a single virtual > world like Second Life (explicitely excluding open grid virtual worlds), > or vica versa. Ah, here's the crux of the problem - terminology. The protocol suite we're envisioning talks about agents and regions, not about world or worlds. If you think of a set of regions under the control of one administrative domain as being a "world", then depending on the policy, then you could see the protocol as enabling interop between "worlds". However, we (the folks banging on the charter) don't believe (at this point!) that such a deployment pattern concept needs to be either explicitly described in the charter or is implicit in the protocol itself. Once you have an agent domain/region domain split, the concept of "world" is much fuzzier. If "world" is the set of all locations an avatar can visit, then multiple region domains create the "world" and thus it is conceivable (modulo policy) that all services that implement OGP region services are part of one big "world". By analogy, the set of all publicly available sites that implement HTTP could be called "the Web" - there is only one "web" even though parts are blocked from access by policy (site policy, user policy, government policy, etc). That doesn't preclude intranets. The analogy isn't perfect by any means, however. And I don't think we're trying to say "world" is the same as "web" intentionally - it just means that at a protocol level, "world" isn't well defined. I believe (but I'm not an active user), that in "Grid" mode, a collection of OpenSims under distinct administrative control play together to form a coherent "world"; they share some services but not others, and users have a relatively seamless experience. (Please jump in and correct me, OpenSim peeps!) Another wrinkle in the terminology: it's easy to imagine that a large VW provider like Linden Lab could, purely for administrative purposes, split the VW service across both multiple agent and region domains. I can imagine separate region domains being used purely for scale (e.g. limiting the number of hosts per region domain), real-world geography (e.g. region domains don't span colos), and so forth. Similar divisions might occur for agent domains. Policy would dictate access; in the cases listed above, I would imagine that it would be completely transparent to users which agent domain/region domain they associated with or in. In this scenario, referring to the collection of multiple region domains as multiple "worlds" would be confusing to the end user. So... I wouldn't get hung up on it. From a protocol level, we need to support interop between regions under distinct administrative control, but we don't need to be explicit about it. That said, Zha's take on deployment patterns will be critical for making sure we're addressing the real world scenarios. Now that I've said all of this - does anyone have concrete suggestions for refining the charter text? --0016e6470bdc435b6604719ab324 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On Thu, Aug 20, 2009 at 7:07 AM, Carlo Wood<carlo@alinoe.com> wrote:
>
> This speaks of "a virtual world", which refering back to the introduction
> seems to define that there are more than one virtual world possible,
> and hence the phrase "the virtual world" seems to refer to a single virtual
> world like Second Life (explicitely excluding open grid virtual worlds),
> or vica versa.

Ah, here's the crux of the problem - terminology. The protocol suite
we're envisioning talks about agents and regions, not about world or
worlds.

If you think of a set of regions under the control of one
administrative domain as being a "world", then depending on the
policy, then you could see the protocol as enabling interop between
"worlds".

However, we (the folks banging on the charter) don't believe (at this
point!) that such a deployment pattern concept needs to be either
explicitly described in the charter or is implicit in the protocol
itself.

Once you have an agent domain/region domain split, the concept of
"world" is much fuzzier. If "world" is the set of all locations an
avatar can visit, then multiple region domains create the "world" and
thus it is conceivable (modulo policy) that all services that
implement OGP region services are part of one big "world".

By analogy, the set of all publicly available sites that implement
HTTP could be called "the Web" - there is only one "web" even though
parts are blocked from access by policy (site policy, user policy,
government policy, etc). That doesn't preclude intranets. The analogy
isn't perfect by any means, however. And I don't think we're trying to
say "world" is the same as "web" intentionally - it just means that at
a protocol level, "world" isn't well defined.

I believe (but I'm not an active user), that in "Grid" mode, a
collection of OpenSims under distinct administrative control play
together to form a coherent "world"; they share some services but not
others, and users have a relatively seamless experience. (Please jump
in and correct me, OpenSim peeps!)

Another wrinkle in the terminology: it's easy to imagine that a large
VW provider like Linden Lab could, purely for administrative purposes,
split the VW service across both multiple agent and region domains. I
can imagine separate region domains being used purely for scale (e.g.
limiting the number of hosts per region domain), real-world geography
(e.g. region domains don't span colos), and so forth. Similar
divisions might occur for agent domains. Policy would dictate access;
in the cases listed above, I would imagine that it would be completely
transparent to users which agent domain/region domain they associated
with or in. In this scenario, referring to the collection of multiple
region domains as multiple "worlds" would be confusing to the end
user.

So... I wouldn't get hung up on it. From a protocol level, we need to
support interop between regions under distinct administrative control,
but we don't need to be explicit about it. That said, Zha's take on
deployment patterns will be critical for making sure we're addressing
the real world scenarios.

Now that I've said all of this - does anyone have concrete suggestions
for refining the charter text?

--0016e6470bdc435b6604719ab324-- From josh@lindenlab.com Thu Aug 20 15:59:39 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379E73A6DA1 for ; Thu, 20 Aug 2009 15:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S70dBU2+4MPL for ; Thu, 20 Aug 2009 15:59:38 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 218E83A6916 for ; Thu, 20 Aug 2009 15:59:38 -0700 (PDT) Received: by mail-yw0-f188.google.com with SMTP id 26so346448ywh.5 for ; Thu, 20 Aug 2009 15:59:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.180.16 with SMTP id c16mr346520agf.15.1250809183832; Thu, 20 Aug 2009 15:59:43 -0700 (PDT) In-Reply-To: References: <20090820140733.GA28751@alinoe.com> Date: Thu, 20 Aug 2009 15:59:43 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016362848ee158bf604719ab584 Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 22:59:39 -0000 --0016362848ee158bf604719ab584 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Re-reading my post, let me clarify something: * We haven't been explicit about a definition of "world" or "worlds" and how that maps to regions and administrative domains, and I do not think we need to. Even stronger, I think doing so would have negative consequences. * We should be explicit in the charter that we're talking about protocol use that may span administrative domains. If that isn't clear enough, we should update the charter text. Suggestions welcome. --0016362848ee158bf604719ab584 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Re-reading my post, let me clarify something:

* We haven't been explicit about a definition of "world" or "worlds"
and how that maps to regions and administrative domains, and I do not
think we need to. Even stronger, I think doing so would have negative
consequences.

* We should be explicit in the charter that we're talking about
protocol use that may span administrative domains. If that isn't clear
enough, we should update the charter text. Suggestions welcome.

--0016362848ee158bf604719ab584-- From josh@lindenlab.com Thu Aug 20 16:00:33 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15EA3A6CEF for ; Thu, 20 Aug 2009 16:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvZZv3Zl6qFM for ; Thu, 20 Aug 2009 16:00:32 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 7E7013A6D28 for ; Thu, 20 Aug 2009 16:00:32 -0700 (PDT) Received: by ywh26 with SMTP id 26so347652ywh.5 for ; Thu, 20 Aug 2009 16:00:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.154.4 with SMTP id g4mr329963ago.60.1250809233624; Thu, 20 Aug 2009 16:00:33 -0700 (PDT) In-Reply-To: References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> Date: Thu, 20 Aug 2009 16:00:33 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016e64608540d517d04719ab85a Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 23:00:33 -0000 --0016e64608540d517d04719ab85a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Ugh, I just realized that my last several posts were private replies, not reply-all messages. D'oh. Resending, but some context may be lost. On Thu, Aug 20, 2009 at 1:42 PM, Morgaine wrote: > On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan < > meadhbh.siobhan@gmail.com> wrote, in answer to Carlo Wood: > > and to your point about landmarks and teleport. >> >> teleporting between points in the virtual world, even if the origin >> and destination are managed by different administrative domains has >> always been part of the protocol proposal. we're not taking that out. >> > > > That was not Carlo's point. Carlo asked about landmarks and teleports *between > virtual worlds*, so stating that you're not taking them out from within a > single world is not answering his question. > > The question being asked is a very simple one. I do not understand why a > clear answer is not being given. > I think we all agree (ahem, have rough consensus) on this statement: * OGP should support teleports between regions that are part of different administrative domains, when policy permits. I think the hard part is that "world" is not a well defined concept in OGP. We can't say "OGP should support teleports between different worlds" when we can't define "world". I maintain that "world" is not a technical term, just as the HTTP RFCs do not define "web". (The term is used in the preamble, but not defined.) Personally, I think the term "world" will come to mean something I'll hand-wavily call policy-clusters-of-agent/region-domains, meaning groups of places avatars can easily (not necessarily freely) traverse; some "worlds" will span multiple administrative domains, some won't. But I don't want to try and define that now! This is a matter of huge importance to the large number of SL-compatible > open grids that already exist, with more appearing regularly. It needs to > be clearly stated whether mechanisms for interop between SL-compatible > worlds will be within the scope of the OGPX group, or not. > Would it help if we added a parenthetical "(which may be described as one or more virtual worlds)" or something somewhere in the charter? IMHO, it does not add technical detail to the charter, but if it makes it more appealing or comprehensible to those not embedded in the process, it's worthwhile. > Defining our scope is our primary task at this time. This question cannot > be dodged. > Agreed. And it may be that we're being too precise/pedantic in the charter text. --0016e64608540d517d04719ab85a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ugh, I just realized that my last several posts were private replies, not r= eply-all messages. D'oh. Resending, but some context may be lost.


On Thu, Aug 20, 2009 at 1:42 PM, Morgaine <morgaine.dinova@go= oglemail.com> wrote:
On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan= <meadhbh.siobhan@gmail.com> wrote, in answer to Ca= rlo Wood:


and to your point about landmarks and teleport.

teleporting between points in the virtual world, even if the origin
and destination are managed by different administrative domains has
always been part of the protocol proposal. we're not taking that out.


That was not Carlo's point.=C2=A0 Carlo= asked about landmarks and teleports between=C2=A0 virtual worlds, s= o stating that you're not taking them out from within a single world is= not answering his question.

The question being asked is a very simple one.=C2=A0 I do not understan= d why a clear answer is not being given.
=

I think we all agree (ahem, have rough consensus) on this statemen= t:

* OGP should support teleports between regions that are part of differe= nt administrative domains, when policy permits.

I think the hard par= t is that "world" is not a well defined concept in OGP. We can= 9;t say "OGP should support teleports between different worlds" w= hen we can't define "world". I maintain that "world"= ; is not a technical term, just as the HTTP RFCs do not define "web&qu= ot;. (The term is used in the preamble, but not defined.) Personally, I thi= nk the term "world" will come to mean something I'll hand-wav= ily call policy-clusters-of-agent/region-domains, meaning groups of places = avatars can easily (not necessarily freely) traverse; some "worlds&quo= t; will span multiple administrative domains, some won't. But I don'= ;t want to try and define that now!

This is a matter of huge importa= nce to the large number of SL-compatible open grids that already exist, wit= h more appearing regularly.=C2=A0 It needs to be clearly stated whether mec= hanisms for interop between SL-compatible worlds will be within the scope o= f the OGPX group, or not.

Would it help if we added a parenthetical= "(which may be described as one or more virtual worlds)" or some= thing somewhere in the charter? IMHO, it does not add technical detail to t= he charter, but if it makes it more appealing or comprehensible to those no= t embedded in the process, it's worthwhile.
=C2=A0
Defining our scope is our prim= ary task at this time.=C2=A0 This question cannot be dodged.

Agreed. And it may be that we'= re being too precise/pedantic in the charter text.


--0016e64608540d517d04719ab85a-- From meadhbh.siobhan@gmail.com Thu Aug 20 16:09:36 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325B93A6A59 for ; Thu, 20 Aug 2009 16:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoHefoIlZIcP for ; Thu, 20 Aug 2009 16:09:35 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 1778F3A6916 for ; Thu, 20 Aug 2009 16:09:35 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so201480qwi.31 for ; Thu, 20 Aug 2009 16:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tSTYB5p9SGoYAbaJU7Q5/dQ9Gr/6U38efnB81w+ALBI=; b=E6Fh5RT4y40w/1vI2e8dtx++UdV8XAf5zdJiEQE1GgnbJZ4sd4KvliX4WTJJxq7Bho fCHnLlhWB+s2PPCwtD12sqakjtffJTfvpP3oRdneuv0Qn++C+2xdj/BCODhAXQjZ2u5p 1yjMDpgYjaL/idrQwCxXXdICJi669Izn5oU0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=al4wtIEqu40l8jpDR7t2FJ3GAJmWGEOhIxoj1Vt1hG7Bc95qe08c4vjg+bTgyj9dLA aW3WUPYD0bEhqFQGuxYoWN6R1s04knIlCyKPmSZZWDxUieuwM1e7MiMvYeyxL0aNrpA/ M8PcqMkW8uIkPibQfLJ1RfvaMsdZ8AAS2czoE= MIME-Version: 1.0 Received: by 10.229.34.143 with SMTP id l15mr71027qcd.80.1250809778631; Thu, 20 Aug 2009 16:09:38 -0700 (PDT) In-Reply-To: References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> Date: Thu, 20 Aug 2009 16:09:38 -0700 Message-ID: From: Meadhbh Siobhan To: Joshua Bell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 23:09:36 -0000 the charter already says "Such virtual worlds may consist of regions administered by distinct organizations." i think we used the term "virtual world(s)" to help contextualize the effort. if the term is confusing, we could use "region" and "region domain" and "region host / simulator" in the body of the charter. though i would argue that the term "virtual world" should appear somewhere early in the description of the working group so people reading the charter will have some context. (Dave C. and others have argued persuasively out that peeps from outside the VW/OGP community won't automatically know that "OGP" means "virtual worlds protocol." consequently, i think "region domain" won't automatically translate to "part of a virtual world" unless explicitly mentioned.) -cheers -meadhbh On Thu, Aug 20, 2009 at 4:00 PM, Joshua Bell wrote: > Ugh, I just realized that my last several posts were private replies, not > reply-all messages. D'oh. Resending, but some context may be lost. > > > On Thu, Aug 20, 2009 at 1:42 PM, Morgaine > wrote: >> >> On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan >> wrote, in answer to Carlo Wood: >> >>> and to your point about landmarks and teleport. >>> >>> teleporting between points in the virtual world, even if the origin >>> and destination are managed by different administrative domains has >>> always been part of the protocol proposal. we're not taking that out. >> >> >> That was not Carlo's point.=A0 Carlo asked about landmarks and teleports >> between=A0 virtual worlds, so stating that you're not taking them out fr= om >> within a single world is not answering his question. >> >> The question being asked is a very simple one.=A0 I do not understand wh= y a >> clear answer is not being given. > > I think we all agree (ahem, have rough consensus) on this statement: > > * OGP should support teleports between regions that are part of different > administrative domains, when policy permits. > > I think the hard part is that "world" is not a well defined concept in OG= P. > We can't say "OGP should support teleports between different worlds" when= we > can't define "world". I maintain that "world" is not a technical term, ju= st > as the HTTP RFCs do not define "web". (The term is used in the preamble, = but > not defined.) Personally, I think the term "world" will come to mean > something I'll hand-wavily call policy-clusters-of-agent/region-domains, > meaning groups of places avatars can easily (not necessarily freely) > traverse; some "worlds" will span multiple administrative domains, some > won't. But I don't want to try and define that now! > >> This is a matter of huge importance to the large number of SL-compatible >> open grids that already exist, with more appearing regularly.=A0 It need= s to >> be clearly stated whether mechanisms for interop between SL-compatible >> worlds will be within the scope of the OGPX group, or not. > > Would it help if we added a parenthetical "(which may be described as one= or > more virtual worlds)" or something somewhere in the charter? IMHO, it doe= s > not add technical detail to the charter, but if it makes it more appealin= g > or comprehensible to those not embedded in the process, it's worthwhile. > >> >> Defining our scope is our primary task at this time.=A0 This question ca= nnot >> be dodged. > > Agreed. And it may be that we're being too precise/pedantic in the charte= r > text. > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From josh@lindenlab.com Thu Aug 20 16:36:22 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D0B3A6AC4 for ; Thu, 20 Aug 2009 16:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPH3CmIcFK-A for ; Thu, 20 Aug 2009 16:36:20 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 33B073A6A0E for ; Thu, 20 Aug 2009 16:36:20 -0700 (PDT) Received: by gxk17 with SMTP id 17so403573gxk.19 for ; Thu, 20 Aug 2009 16:36:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.18.35 with SMTP id 35mr375602agr.3.1250811380874; Thu, 20 Aug 2009 16:36:20 -0700 (PDT) In-Reply-To: References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> Date: Thu, 20 Aug 2009 16:36:20 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00163631095709beb704719b38da Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 23:36:22 -0000 --00163631095709beb704719b38da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Right - and I'm not opposed to using "virtual world(s)" terminology at all, and agree it's critical to use that phrase so people outside the current effort can make sense of what we're talking about. So... I guess we come back to: given the current draft (and specifically phrasing such as what Meadhbh higlights below), and without rigorously defining what a "world" for all time... are we missing something to make it clear that crafting something that enables teleporting from Foo's World to Bar's World (policy permitting) is entirely within the goals of this effort? On Thu, Aug 20, 2009 at 4:09 PM, Meadhbh Siobhan wrote: > the charter already says "Such virtual worlds may consist of regions > administered by distinct organizations." > > i think we used the term "virtual world(s)" to help contextualize the > effort. if the term is confusing, we could use "region" and "region > domain" and "region host / simulator" in the body of the charter. > > though i would argue that the term "virtual world" should appear > somewhere early in the description of the working group so people > reading the charter will have some context. (Dave C. and others have > argued persuasively out that peeps from outside the VW/OGP community > won't automatically know that "OGP" means "virtual worlds protocol." > consequently, i think "region domain" won't automatically translate to > "part of a virtual world" unless explicitly mentioned.) > > -cheers > -meadhbh > > > On Thu, Aug 20, 2009 at 4:00 PM, Joshua Bell wrote: > > Ugh, I just realized that my last several posts were private replies, not > > reply-all messages. D'oh. Resending, but some context may be lost. > > > > > > On Thu, Aug 20, 2009 at 1:42 PM, Morgaine < > morgaine.dinova@googlemail.com> > > wrote: > >> > >> On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan > >> wrote, in answer to Carlo Wood: > >> > >>> and to your point about landmarks and teleport. > >>> > >>> teleporting between points in the virtual world, even if the origin > >>> and destination are managed by different administrative domains has > >>> always been part of the protocol proposal. we're not taking that out. > >> > >> > >> That was not Carlo's point. Carlo asked about landmarks and teleports > >> between virtual worlds, so stating that you're not taking them out from > >> within a single world is not answering his question. > >> > >> The question being asked is a very simple one. I do not understand why > a > >> clear answer is not being given. > > > > I think we all agree (ahem, have rough consensus) on this statement: > > > > * OGP should support teleports between regions that are part of different > > administrative domains, when policy permits. > > > > I think the hard part is that "world" is not a well defined concept in > OGP. > > We can't say "OGP should support teleports between different worlds" when > we > > can't define "world". I maintain that "world" is not a technical term, > just > > as the HTTP RFCs do not define "web". (The term is used in the preamble, > but > > not defined.) Personally, I think the term "world" will come to mean > > something I'll hand-wavily call policy-clusters-of-agent/region-domains, > > meaning groups of places avatars can easily (not necessarily freely) > > traverse; some "worlds" will span multiple administrative domains, some > > won't. But I don't want to try and define that now! > > > >> This is a matter of huge importance to the large number of SL-compatible > >> open grids that already exist, with more appearing regularly. It needs > to > >> be clearly stated whether mechanisms for interop between SL-compatible > >> worlds will be within the scope of the OGPX group, or not. > > > > Would it help if we added a parenthetical "(which may be described as one > or > > more virtual worlds)" or something somewhere in the charter? IMHO, it > does > > not add technical detail to the charter, but if it makes it more > appealing > > or comprehensible to those not embedded in the process, it's worthwhile. > > > >> > >> Defining our scope is our primary task at this time. This question > cannot > >> be dodged. > > > > Agreed. And it may be that we're being too precise/pedantic in the > charter > > text. > > > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --00163631095709beb704719b38da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right - and I'm not opposed to using "virtual world(s)" termi= nology at all, and agree it's critical to use that phrase so people out= side the current effort can make sense of what we're talking about.

So... I guess we come back to: given the current draft (and specificall= y phrasing such as what Meadhbh higlights below), and without rigorously de= fining what a "world" for all time... are we missing something to= make it clear that crafting something that enables teleporting from Foo= 9;s World to Bar's World (policy permitting) is entirely within the goa= ls of this effort?

On Thu, Aug 20, 2009 at 4:09 PM, Meadhbh Sio= bhan <mea= dhbh.siobhan@gmail.com> wrote:
the charter already says "Such virtual worlds may consist of regions administered by distinct organizations."

i think we used the term "virtual world(s)" to help contextualize= the
effort. if the term is confusing, we could use "region" and "= ;region
domain" and "region host / simulator" in the body of the cha= rter.

though i would argue that the term "virtual world" should appear<= br> somewhere early in the description of the working group so people
reading the charter will have some context. (Dave C. and others have
argued persuasively out that peeps from outside the VW/OGP community
won't automatically know that "OGP" means "virtual world= s protocol."
consequently, i think "region domain" won't automatically tra= nslate to
"part of a virtual world" unless explicitly mentioned.)

-cheers
-meadhbh


On Thu, Aug 20, 2009 at 4:00 PM, Joshua Bell<josh@lindenlab.com> wrote:
> Ugh, I just realized that my last several posts were private replies, = not
> reply-all messages. D'oh. Resending, but some context may be lost.=
>
>
> On Thu, Aug 20, 2009 at 1:42 PM, Morgaine <morgaine.dinova@googlemail.com>
> wrote:
>>
>> On Thu, Aug 20, 2009 at 7:01 PM, Meadhbh Siobhan
>> <meadhbh.siobhan@g= mail.com> wrote, in answer to Carlo Wood:
>>
>>> and to your point about landmarks and teleport.
>>>
>>> teleporting between points in the virtual world, even if the o= rigin
>>> and destination are managed by different administrative domain= s has
>>> always been part of the protocol proposal. we're not takin= g that out.
>>
>>
>> That was not Carlo's point.=C2=A0 Carlo asked about landmarks = and teleports
>> between=C2=A0 virtual worlds, so stating that you're not takin= g them out from
>> within a single world is not answering his question.
>>
>> The question being asked is a very simple one.=C2=A0 I do not unde= rstand why a
>> clear answer is not being given.
>
> I think we all agree (ahem, have rough consensus) on this statement: >
> * OGP should support teleports between regions that are part of differ= ent
> administrative domains, when policy permits.
>
> I think the hard part is that "world" is not a well defined = concept in OGP.
> We can't say "OGP should support teleports between different = worlds" when we
> can't define "world". I maintain that "world" = is not a technical term, just
> as the HTTP RFCs do not define "web". (The term is used in t= he preamble, but
> not defined.) Personally, I think the term "world" will come= to mean
> something I'll hand-wavily call policy-clusters-of-agent/region-do= mains,
> meaning groups of places avatars can easily (not necessarily freely) > traverse; some "worlds" will span multiple administrative do= mains, some
> won't. But I don't want to try and define that now!
>
>> This is a matter of huge importance to the large number of SL-comp= atible
>> open grids that already exist, with more appearing regularly.=C2= =A0 It needs to
>> be clearly stated whether mechanisms for interop between SL-compat= ible
>> worlds will be within the scope of the OGPX group, or not.
>
> Would it help if we added a parenthetical "(which may be describe= d as one or
> more virtual worlds)" or something somewhere in the charter? IMHO= , it does
> not add technical detail to the charter, but if it makes it more appea= ling
> or comprehensible to those not embedded in the process, it's worth= while.
>
>>
>> Defining our scope is our primary task at this time.=C2=A0 This qu= estion cannot
>> be dodged.
>
> Agreed. And it may be that we're being too precise/pedantic in the= charter
> text.
>
>
>
> ________________________= _______________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

--00163631095709beb704719b38da-- From carlo@alinoe.com Thu Aug 20 16:50:05 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C9228C0DD for ; Thu, 20 Aug 2009 16:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeLh-U5sKR-0 for ; Thu, 20 Aug 2009 16:50:04 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id C854A3A6B0E for ; Thu, 20 Aug 2009 16:50:03 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090820235007.XUDU25702.viefep18-int.chello.at@edge01.upc.biz>; Fri, 21 Aug 2009 01:50:07 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id Wnq51c0320FlQed01nq6QW; Fri, 21 Aug 2009 01:50:07 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MeHP9-0006E4-PZ; Fri, 21 Aug 2009 01:50:51 +0200 Date: Fri, 21 Aug 2009 01:50:51 +0200 From: Carlo Wood To: Meadhbh Siobhan Message-ID: <20090820235051.GA21280@alinoe.com> References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 23:50:05 -0000 I'm feeling a bit dizzy of all the terminology :p And, I'm still not sure if I understand it: it's still unclear. Perhaps we'll just have to use hard examples on this mailinglist first to make things clear, and only then we can think about ways to achieve the same clearness in more abstract terms. --- 1) Right now, there is 'Second Life', and there are several opensim worlds that are very very like Second Life. Never I am refering to or even thinking about WoW. 2) Right now, therefore, we can call those entirely separated administrative domains, different "worlds", as has been done in the past several years. We might want to change that terminology, but let me use "world" to refer the currently existing different worlds, where "Second Life" is one of them and -say- "opengrid X" is another. 3) These worlds are separated in EVERY way: - You cannot teleport bewteen them. - There is no notion of Landmarks that refer outside a given world. - You cannot send IM's to avatars in the other world. - You cannot access any asset (or inventory) of another world. 4) I thought that the OGPX effort had as goal to change this *complete* separation. However, if we want to make these limitations vanish then they cannot be used to DEFINE what (separate) world mean... Hence, the term becomes undefined and unclear (in the future). But-- there are things that define the "worlds" that do NOT want to change: * The administration is entirely different: - A TOS only applies to one world. - An Abuse Report only has effect within one virtual world. - A ban by such an administration only affects their own world. I think that most ideal situation would be when it is entirely and only the user that decides if they want to visit another world, completely independent of which world that is (as they can now by simply logging out, and logging in elsewhere). This CAN be supported; but it would mean to both region domain AND agent domain (in order to switch completely between administrations etc). Of course, viewers could simply support a seemless logout and login elsewhere, but we (the users) want support for this in the format of LandMarks, so that it is relatively easy to invite someone to that other place, in another world. Trivially, however, two major annoyances arrise with such a simple sheme: * The need to create a new account (avatar name / password) * Complete loss of access to inventory: - loss of shape, skin, clothes and attachments during teleport - loss of everything else in the inventory If I'm correct then the latter has everything to do with the agent domain; thus, if someone would stay in the same agent domain (ie, one run by Linden Lab), then one would not need to create a new account, would not need to logout and re-login, would not lose appearance or inventory. The question remains now: how will that affect the ideal solution? Because to the user those worlds will suddenly appear to be a single world. What if a griefer logins in with LL, teleports to opengrid X and halts a sim there by running 10,000 scripts in attachments. Whose TOS determines if that is allowed? I'd say opengrid X's tos. And if opengrid X's TOS does not allow halting a sim, then where does an Abuse Report go to? I'd say... still to opengrid X's administration. And when they decide to ban this person, will it be possible to ban that (LL) account from opengrid X? These questions are not trivial, but of utmost importance (yes, also for the protocol): any and all administrative issues should be a case of the administration of the *region* one is in, and never of the agent domain someone belongs to. As a result, an agent domain shouldn't care less where someone wants to go, because they are never responsible, and therefore it should NOT be a matter of policy where someone can or cannot teleport while keeping their inventory: it should simply be possible, because the address is given in the LandMark. -- Carlo Wood From carlo@alinoe.com Thu Aug 20 16:56:10 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF9828C10C for ; Thu, 20 Aug 2009 16:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLIISN+98xcd for ; Thu, 20 Aug 2009 16:56:09 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id 40A7328C12E for ; Thu, 20 Aug 2009 16:56:09 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090820235613.XXRK25702.viefep18-int.chello.at@edge01.upc.biz>; Fri, 21 Aug 2009 01:56:13 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id WnwB1c04G0FlQed01nwCYw; Fri, 21 Aug 2009 01:56:13 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MeHV3-0006IH-SP; Fri, 21 Aug 2009 01:56:57 +0200 Date: Fri, 21 Aug 2009 01:56:57 +0200 From: Carlo Wood To: Meadhbh Siobhan Message-ID: <20090820235657.GB21280@alinoe.com> References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> <20090820235051.GA21280@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090820235051.GA21280@alinoe.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2009 23:56:10 -0000 On Fri, Aug 21, 2009 at 01:50:51AM +0200, Carlo Wood wrote: > As a result, an agent domain shouldn't care less where someone > wants to go, because they are never responsible, and therefore > it should NOT be a matter of policy where someone can or cannot > teleport while keeping their inventory: it should simply be > possible, because the address is given in the LandMark. What I guess is my main point, is that I think that we can keep using "virtual world" (or just world in short) and that that should refer to a (group of) region(s) under one administration, and not to the agent domain; where the world can (therefore) have a different TOS, has world-wide bans issued by said administration, deals with every Abuse Report against avatars in their region, and which even could run on machines in a country with different laws than the worlds of other administrations. -- Carlo Wood From josh@lindenlab.com Thu Aug 20 17:12:20 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B4D23A677E for ; Thu, 20 Aug 2009 17:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF33UsbGCyVI for ; Thu, 20 Aug 2009 17:12:19 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 736E93A6949 for ; Thu, 20 Aug 2009 17:12:19 -0700 (PDT) Received: by ywh26 with SMTP id 26so406029ywh.5 for ; Thu, 20 Aug 2009 17:12:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.143.18 with SMTP id v18mr375626agn.71.1250813541008; Thu, 20 Aug 2009 17:12:21 -0700 (PDT) In-Reply-To: <20090820235051.GA21280@alinoe.com> References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> <20090820235051.GA21280@alinoe.com> Date: Thu, 20 Aug 2009 17:12:20 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016e643559acac43a04719bb8d9 Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 00:12:20 -0000 --0016e643559acac43a04719bb8d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > > However, if we want to make these limitations vanish then they > cannot be used to DEFINE what (separate) world mean... Hence, > the term becomes undefined and unclear (in the future). > Agreed (with this and preceding points) > > But-- there are things that define the "worlds" that do NOT > want to change: > > * The administration is entirely different: > - A TOS only applies to one world. > - An Abuse Report only has effect within one virtual world. > - A ban by such an administration only affects their own world. Here I think you're projecting from the way things are now too directly. As you mention later on... how will that affect the ideal solution? Because to the user those > worlds will suddenly appear to be a single world. > Agreed, and your examples are good ones: > What if a griefer logins in with LL, teleports to opengrid X and > halts a sim there by running 10,000 scripts in attachments. > > Whose TOS determines if that is allowed? I'd say opengrid X's tos. > And if opengrid X's TOS does not allow halting a sim, then where does > an Abuse Report go to? I'd say... still to opengrid X's administration. > And when they decide to ban this person, will it be possible to > ban that (LL) account from opengrid X? > I don't think we know the answers to those questions yet. We need actual implementers to speak up and describe how they'd want their systems to work (on their own and with partners) and it should be within the working group's charter to ensure the protocols support those administrative needs and scenarios. As a result, an agent domain shouldn't care less where someone > wants to go, because they are never responsible, and therefore > it should NOT be a matter of policy where someone can or cannot > teleport while keeping their inventory: it should simply be > possible, because the address is given in the LandMark. > I disagree with that. As a corporation providing tools to my employees, I may dictate policy about where my employees may go using those tools - e.g. they may teleport to and bring inventory with corporate content to partner company worlds where the companies have signed NDAs, to have meetings to discuss shared interests. It is entirely a matter of policy. This is no different than having corporate firewalls that block access to certain sites or content. That may not be the primary use case (again, see the Web) but we can't discard it. Joshua --0016e643559acac43a04719bb8d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

However, if we want to make these limitations vanish then they
cannot be used to DEFINE what (separate) world mean... Hence,
the term becomes undefined and unclear (in the future).

Agreed (with this and preceding points)
=C2=A0

But-- there are things that define the "worlds" that do NOT
want to change:

* The administration is entirely different:
=C2=A0- A TOS only applies to one world.
=C2=A0- An Abuse Report only has effect within one virtual world.
=C2=A0- A ban by such an administration only affects their own world.

Here I think you're projecting from the way things are= now too directly. As you mention later on...

how will that affect the ideal solution? Because to the user those
worlds will suddenly appear to be a single world.

Agreed, and your examples are good ones:
=C2=A0
What if a griefer logins in with LL, teleports to opengrid X and
halts a sim there by running 10,000 scripts in attachments.

Whose TOS determines if that is allowed? I'd say opengrid X's tos.<= br> And if opengrid X's TOS does not allow halting a sim, then where does an Abuse Report go to? I'd say... still to opengrid X's administrat= ion.
And when they decide to ban this person, will it be possible to
ban that (LL) account from opengrid X?

I don't think we know the answers to those questi= ons yet. We need actual implementers to speak up and describe how they'= d want their systems to work (on their own and with partners) and it should= be within the working group's charter to ensure the protocols support = those administrative needs and scenarios.

As a re= sult, an agent domain shouldn't care less where someone
wants to go, because they are never responsible, and therefore
it should NOT be a matter of policy where someone can or cannot
teleport while keeping their inventory: it should simply be
possible, because the address is given in the LandMark.

I disagree with that. As a corporation providing tools to my employe= es, I may dictate policy about where my employees may go using those tools = - e.g. they may teleport to and bring inventory with corporate content to p= artner company worlds where the companies have signed NDAs, to have meeting= s to discuss shared interests. It is entirely a matter of policy. This is n= o different than having corporate firewalls that block access to certain si= tes or content.

That may not be the primary use case (again, see the Web) but we can= 9;t discard it.

Joshua

--0016e643559acac43a04719bb8d9-- From josh@lindenlab.com Thu Aug 20 17:16:09 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1073A6D30 for ; Thu, 20 Aug 2009 17:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BBj3QRXYfPE for ; Thu, 20 Aug 2009 17:16:08 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id B90203A6EFF for ; Thu, 20 Aug 2009 17:16:03 -0700 (PDT) Received: by gxk17 with SMTP id 17so438681gxk.19 for ; Thu, 20 Aug 2009 17:16:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.143.18 with SMTP id v18mr378317agn.71.1250813766776; Thu, 20 Aug 2009 17:16:06 -0700 (PDT) In-Reply-To: <20090820235657.GB21280@alinoe.com> References: <20090820141835.GB28751@alinoe.com> <20090820235051.GA21280@alinoe.com> <20090820235657.GB21280@alinoe.com> Date: Thu, 20 Aug 2009 17:16:06 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016e643559a3fb67204719bc69d Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 00:16:09 -0000 --0016e643559a3fb67204719bc69d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Thu, Aug 20, 2009 at 4:56 PM, Carlo Wood wrote: > On Fri, Aug 21, 2009 at 01:50:51AM +0200, Carlo Wood wrote: > > As a result, an agent domain shouldn't care less where someone > > wants to go, because they are never responsible, and therefore > > it should NOT be a matter of policy where someone can or cannot > > teleport while keeping their inventory: it should simply be > > possible, because the address is given in the LandMark. > > What I guess is my main point, is that I think that we can > keep using "virtual world" (or just world in short) and > that that should refer to a (group of) region(s) under > one administration, and not to the agent domain; where > the world can (therefore) have a different TOS, has > world-wide bans issued by said administration, deals with > every Abuse Report against avatars in their region, > and which even could run on machines in a country with > different laws than the worlds of other administrations. > I'm a fan of that loose definition of "world" myself. I think I alluded to something similar earlier, but to try and rephrase to cover our shared thinking: the boundaries of a "world" are where a user notices (or should notice) a difference due to policy or behavior. Like "web site" it isn't clear that that's a technical term; it shouldn't keep us from using the term (since we have roughly shared understanding of the meaning) but on the other hand we shouldn't fixate on a rigorous technical definition since it doesn't seem to be a first-class entity within the drafts we're focusing on right now. Huzzah, convergence! --0016e643559a3fb67204719bc69d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 20, 2009 at 4:56 PM, Carlo Wood <carlo@alinoe.com&= gt; wrote:
On Fri, Aug 21, 2009 at 01:50:51AM +0200, Carlo Wood wrot= e:
> As a result, an agent domain shouldn't care less where someone
> wants to go, because they are never responsible, and therefore
> it should NOT be a matter of policy where someone can or cannot
> teleport while keeping their inventory: it should simply be
> possible, because the address is given in the LandMark.

What I guess is my main point, is that I think that we can
keep using "virtual world" (or just world in short) and
that that should refer to a (group of) region(s) under
one administration, and not to the agent domain; where
the world can (therefore) have a different TOS, has
world-wide bans issued by said administration, deals with
every Abuse Report against avatars in their region,
and which even could run on machines in a country with
different laws than the worlds of other administrations.

I'm a fan of that loose definition of "world" myself.= I think I alluded to something similar earlier, but to try and rephrase to= cover our shared thinking: the boundaries of a "world" are where= a user notices (or should notice) a difference due to policy or behavior.<= br>
Like "web site" it isn't clear that that's a technica= l term; it shouldn't keep us from using the term (since we have roughly= shared understanding of the meaning) but on the other hand we shouldn'= t fixate on a rigorous technical definition since it doesn't seem to be= a first-class entity within the drafts we're focusing on right now.
Huzzah, convergence!
--0016e643559a3fb67204719bc69d-- From meadhbh.siobhan@gmail.com Thu Aug 20 17:16:10 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187893A6F31 for ; Thu, 20 Aug 2009 17:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh7VyuY7LZzZ for ; Thu, 20 Aug 2009 17:16:09 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id D02F23A6F24 for ; Thu, 20 Aug 2009 17:16:06 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so226995qwi.31 for ; Thu, 20 Aug 2009 17:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/l35BlAUo8jNmpNaVHWqY8YEUoaHpfg6w1eX2bheRm0=; b=KpnuKCYecrqamQz69F6khObm7CZjsBaYecm6pOF02sjNpIjNFpzQ7c1qmKWWHV32qH CTEcTR2ZS71AHc0AfZUEGNpEF1XaKHZPuKaennpVYfjbTmOjm2b/4X6yOI/UTpaHdtHb 3w3QJ4+vWn9GzH8MMrb3JZ+jNnaELY4mIRBf4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=E+kQaALjyC2fz0wMsChXN9M8hwuoGCAOldqPmq/6FIhBBBYidRQBC0SsAVxP9odBaZ 4iBCiUUjePCeseBE10roNgb732XgkdRrT5vZTHuyq5bVjoSW/ryBQ6KmwPMudVSNJljs Fzc8ekiLxeIYtkKzOucUvzKqtknlkMglNJX74= MIME-Version: 1.0 Received: by 10.229.111.195 with SMTP id t3mr80934qcp.44.1250813769987; Thu, 20 Aug 2009 17:16:09 -0700 (PDT) In-Reply-To: <20090820235051.GA21280@alinoe.com> References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> <20090820235051.GA21280@alinoe.com> Date: Thu, 20 Aug 2009 17:16:09 -0700 Message-ID: From: Meadhbh Siobhan To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 00:16:10 -0000 carlo. i think we're on the same page here with respect to the definition of the term "world." part of the confusion may stem from the fact that radically similar discussions came up in the MMOX effort. one of the objectives of the OGP protocol is to allow a virtual world to be constructed from regions, agent hosts and asset servers from different administrative domains. in order to do that, one of the things we think we need to do is to have a scheme by which regions are unambiguously identified with a URL. we don't currently list "unambiguous landmarks" in the charter because we don't talk about landmarks at all in the charter. it's also unclear whether a landmark format will be defined as part of this effort. that being said, if you have an unambiguous URL that addresses a region, you could use that as the basis for a landmark quite easily. remember that we're only specifying the protocol in this effort, not the application that uses it. protocol messages that carry landmarks aren't in-scope because we're not defining a service that will produce or consume them. however... i think you bring up a good point, we could be more explicit about including the "unambiguous URL defines a region" thing in the charter. This would put it in-scope and would allow app developers to define their own landmark format that leverages it. so i guess what i'm saying is that if we listed "a format for unambiguous landmarks" in the charter, shouldn't we also list other Second-Life-like features like the C/M/T permissions system? the unambiguous URL representing a region is required for proper operation of teleport, which IS in scope, but the unambiguous landmark format is not required as landmarks are concepts more appropriately manipulated by client applications. so, is it enough to add verbiage to the charter indicating that the protocol requires regions to be addressable by unambiguous URLs, but not explicitly constrain their use in the charter? -cheers -meadhbh On Thu, Aug 20, 2009 at 4:50 PM, Carlo Wood wrote: > I'm feeling a bit dizzy of all the terminology :p > And, I'm still not sure if I understand it: it's still unclear. > > Perhaps we'll just have to use hard examples on this mailinglist > first to make things clear, and only then we can think about > ways to achieve the same clearness in more abstract terms. > > --- > > 1) Right now, there is 'Second Life', and there are several > =A0 opensim worlds that are very very like Second Life. Never I > =A0 am refering to or even thinking about WoW. > > 2) Right now, therefore, we can call those entirely separated > =A0 administrative domains, different "worlds", as has been > =A0 done in the past several years. > > =A0 We might want to change that terminology, but let me use > =A0 "world" to refer the currently existing different worlds, > =A0 where "Second Life" is one of them and -say- "opengrid X" is > =A0 another. > > 3) These worlds are separated in EVERY way: > =A0 - You cannot teleport bewteen them. > =A0 - There is no notion of Landmarks that refer outside a given world. > =A0 - You cannot send IM's to avatars in the other world. > =A0 - You cannot access any asset (or inventory) of another world. > > 4) I thought that the OGPX effort had as goal to change this > =A0 *complete* separation. > > However, if we want to make these limitations vanish then they > cannot be used to DEFINE what (separate) world mean... Hence, > the term becomes undefined and unclear (in the future). > > But-- there are things that define the "worlds" that do NOT > want to change: > > * The administration is entirely different: > =A0- A TOS only applies to one world. > =A0- An Abuse Report only has effect within one virtual world. > =A0- A ban by such an administration only affects their own world. > > I think that most ideal situation would be when it is entirely > and only the user that decides if they want to visit another world, > completely independent of which world that is (as they can now > by simply logging out, and logging in elsewhere). > > This CAN be supported; but it would mean to both region domain > AND agent domain (in order to switch completely between administrations e= tc). > > Of course, viewers could simply support a seemless logout and login > elsewhere, but we (the users) want support for this in the format > of LandMarks, so that it is relatively easy to invite someone to > that other place, in another world. > > Trivially, however, two major annoyances arrise with such a simple sheme: > > * The need to create a new account (avatar name / password) > * Complete loss of access to inventory: > =A0- loss of shape, skin, clothes and attachments during teleport > =A0- loss of everything else in the inventory > > If I'm correct then the latter has everything to do with the > agent domain; thus, if someone would stay in the same agent domain > (ie, one run by Linden Lab), then one would not need to create a > new account, would not need to logout and re-login, would not > lose appearance or inventory. > > The question remains now: > > how will that affect the ideal solution? Because to the user those > worlds will suddenly appear to be a single world. > > What if a griefer logins in with LL, teleports to opengrid X and > halts a sim there by running 10,000 scripts in attachments. > > Whose TOS determines if that is allowed? I'd say opengrid X's tos. > And if opengrid X's TOS does not allow halting a sim, then where does > an Abuse Report go to? I'd say... still to opengrid X's administration. > And when they decide to ban this person, will it be possible to > ban that (LL) account from opengrid X? > > These questions are not trivial, but of utmost importance (yes, > also for the protocol): any and all administrative issues should > be a case of the administration of the *region* one is in, and > never of the agent domain someone belongs to. > > As a result, an agent domain shouldn't care less where someone > wants to go, because they are never responsible, and therefore > it should NOT be a matter of policy where someone can or cannot > teleport while keeping their inventory: it should simply be > possible, because the address is given in the LandMark. > > -- > Carlo Wood > From meadhbh.siobhan@gmail.com Thu Aug 20 17:25:25 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7441D3A6F24 for ; Thu, 20 Aug 2009 17:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVIEVPsGk47w for ; Thu, 20 Aug 2009 17:25:24 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 3EDEC3A6949 for ; Thu, 20 Aug 2009 17:25:20 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so230440qwi.31 for ; Thu, 20 Aug 2009 17:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EwRfe5whbPu7G10QyPMcipek3DaJgZFGrZO4PGX6/FM=; b=qhJtOhdppvscMVAGrIK9T+4FyV+dLMEgTAl0SqU2hPAjDLSPv0o2Et7+Vge+b/Ewab SMRmCLzWXiwEd5jZNCPZM2+UQ+6rA1H9/6orXzzjBJWm1Ujz/xncnU3WAM1Trux7brrE lFM35VP9RJKCtQHy4wN/BIx1Mkm4uJpU3YaOk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SCyxDfXtJ8CEvDgpzXM86m4tT/LeXBYqTqDeK8v5SgiHQtTqevPMP+IloTPczWOED8 mVTHmWVQfOzm/q8htldwogAD7BIlAA4PJdHfDLWz9sI4lv6PrvW+OCh84cAAMRHAEOY8 De5x/Q/J7siXxbwBHNzawP2qd+WNtNbkYpCWE= MIME-Version: 1.0 Received: by 10.229.41.74 with SMTP id n10mr85385qce.13.1250814321860; Thu, 20 Aug 2009 17:25:21 -0700 (PDT) In-Reply-To: References: <20090820141835.GB28751@alinoe.com> <20090820235051.GA21280@alinoe.com> <20090820235657.GB21280@alinoe.com> Date: Thu, 20 Aug 2009 17:25:21 -0700 Message-ID: From: Meadhbh Siobhan To: Joshua Bell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 00:25:25 -0000 but upon reflection, we should take landmarks as a use case and work backwards to ensure the things we're doing don't preclude landmarks being defined. i'm still a little on the fence about whether we need to say "each region should be individually addressable with a unique URL" in the charter. it would go a long way to make sure that cross-world landmarks could be implemented and i think we should say it, i just don't know if it needs to go in the charter. (the charter which is supposed to be a definition of the problem domain, not the solution domain.) On Thu, Aug 20, 2009 at 5:16 PM, Joshua Bell wrote: > On Thu, Aug 20, 2009 at 4:56 PM, Carlo Wood wrote: >> >> On Fri, Aug 21, 2009 at 01:50:51AM +0200, Carlo Wood wrote: >> > As a result, an agent domain shouldn't care less where someone >> > wants to go, because they are never responsible, and therefore >> > it should NOT be a matter of policy where someone can or cannot >> > teleport while keeping their inventory: it should simply be >> > possible, because the address is given in the LandMark. >> >> What I guess is my main point, is that I think that we can >> keep using "virtual world" (or just world in short) and >> that that should refer to a (group of) region(s) under >> one administration, and not to the agent domain; where >> the world can (therefore) have a different TOS, has >> world-wide bans issued by said administration, deals with >> every Abuse Report against avatars in their region, >> and which even could run on machines in a country with >> different laws than the worlds of other administrations. > > I'm a fan of that loose definition of "world" myself. I think I alluded to > something similar earlier, but to try and rephrase to cover our shared > thinking: the boundaries of a "world" are where a user notices (or should > notice) a difference due to policy or behavior. > > Like "web site" it isn't clear that that's a technical term; it shouldn't > keep us from using the term (since we have roughly shared understanding of > the meaning) but on the other hand we shouldn't fixate on a rigorous > technical definition since it doesn't seem to be a first-class entity within > the drafts we're focusing on right now. > > Huzzah, convergence! > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From morgaine.dinova@googlemail.com Thu Aug 20 19:16:51 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375B73A68D0 for ; Thu, 20 Aug 2009 19:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btiXksIDoryO for ; Thu, 20 Aug 2009 19:16:49 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 4B6223A6B4F for ; Thu, 20 Aug 2009 19:16:49 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so121473eye.31 for ; Thu, 20 Aug 2009 19:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=wMLJspVUy8IWSY4AlgxliZr3AIgM3m+A5T8In7nAqYI=; b=FPwXpN4QSUTFwsW+0V0fKGjgH8frr/oRycLznFv/t52R3nmDhnL5I3gdPA3wdK88+N IqNoefwAPhPQS4ItW24bKFadee9wHbsDt7YzhtMFYi3I4BNxKy4dak3W7Seq5O7Ke+er AHtGW4zKsfKqCLnzSGhRoRwLNdEPFYnUF6aws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=QngR4yDMO7fryZqyzqR0A0aAT5fIHyTdbgVO8ouw0QHyOVJz5XYurf9dCs5OgDPfa2 as4McjPdz1lc3/v/tePjBDo9dy/mHo3eYez/PViuHmDt4WeobqRsafXZgamoKSVzLeT8 8eqm9Y572DdF4AOPnGA7dB8V0i3ubbXNT/Ri4= MIME-Version: 1.0 Received: by 10.210.117.4 with SMTP id p4mr661065ebc.7.1250821006904; Thu, 20 Aug 2009 19:16:46 -0700 (PDT) In-Reply-To: <20090820235051.GA21280@alinoe.com> References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> <20090820235051.GA21280@alinoe.com> Date: Fri, 21 Aug 2009 03:16:46 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174c336ecb4f5804719d75ef Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 02:16:51 -0000 --0015174c336ecb4f5804719d75ef Content-Type: text/plain; charset=ISO-8859-1 Carlo has expressed the issue perfectly in his post. This isn't merely about a choice of words, it's a matter of actual functionality. Given two SL-compatible virtual worlds each comprising multiple regions, either OGP provides a mechanism for teleporting from a region in the first world to a region in the second world, or it doesn't. Many things go along with cross-world teleports of course. Cross-world landmarks is one issue, continuity of inventory while in compatible worlds is another, and so on. While the details are of course complex to work out, at the heart of it is a very simple question about goals, and it deserves a clear answer. Will OGP provide interop between SL-compatible virtual worlds, or is that not intended OGP functionality? We need to know what is in scope for OGPX, because that scope determines our discussions, our implementations, our deliverables and our timelines. Morgaine. On Fri, Aug 21, 2009 at 12:50 AM, Carlo Wood wrote: > I'm feeling a bit dizzy of all the terminology :p > And, I'm still not sure if I understand it: it's still unclear. > > Perhaps we'll just have to use hard examples on this mailinglist > first to make things clear, and only then we can think about > ways to achieve the same clearness in more abstract terms. > > --- > > 1) Right now, there is 'Second Life', and there are several > opensim worlds that are very very like Second Life. Never I > am refering to or even thinking about WoW. > > 2) Right now, therefore, we can call those entirely separated > administrative domains, different "worlds", as has been > done in the past several years. > > We might want to change that terminology, but let me use > "world" to refer the currently existing different worlds, > where "Second Life" is one of them and -say- "opengrid X" is > another. > > 3) These worlds are separated in EVERY way: > - You cannot teleport bewteen them. > - There is no notion of Landmarks that refer outside a given world. > - You cannot send IM's to avatars in the other world. > - You cannot access any asset (or inventory) of another world. > > 4) I thought that the OGPX effort had as goal to change this > *complete* separation. > > However, if we want to make these limitations vanish then they > cannot be used to DEFINE what (separate) world mean... Hence, > the term becomes undefined and unclear (in the future). > > But-- there are things that define the "worlds" that do NOT > want to change: > > * The administration is entirely different: > - A TOS only applies to one world. > - An Abuse Report only has effect within one virtual world. > - A ban by such an administration only affects their own world. > > I think that most ideal situation would be when it is entirely > and only the user that decides if they want to visit another world, > completely independent of which world that is (as they can now > by simply logging out, and logging in elsewhere). > > This CAN be supported; but it would mean to both region domain > AND agent domain (in order to switch completely between administrations > etc). > > Of course, viewers could simply support a seemless logout and login > elsewhere, but we (the users) want support for this in the format > of LandMarks, so that it is relatively easy to invite someone to > that other place, in another world. > > Trivially, however, two major annoyances arrise with such a simple sheme: > > * The need to create a new account (avatar name / password) > * Complete loss of access to inventory: > - loss of shape, skin, clothes and attachments during teleport > - loss of everything else in the inventory > > If I'm correct then the latter has everything to do with the > agent domain; thus, if someone would stay in the same agent domain > (ie, one run by Linden Lab), then one would not need to create a > new account, would not need to logout and re-login, would not > lose appearance or inventory. > > The question remains now: > > how will that affect the ideal solution? Because to the user those > worlds will suddenly appear to be a single world. > > What if a griefer logins in with LL, teleports to opengrid X and > halts a sim there by running 10,000 scripts in attachments. > > Whose TOS determines if that is allowed? I'd say opengrid X's tos. > And if opengrid X's TOS does not allow halting a sim, then where does > an Abuse Report go to? I'd say... still to opengrid X's administration. > And when they decide to ban this person, will it be possible to > ban that (LL) account from opengrid X? > > These questions are not trivial, but of utmost importance (yes, > also for the protocol): any and all administrative issues should > be a case of the administration of the *region* one is in, and > never of the agent domain someone belongs to. > > As a result, an agent domain shouldn't care less where someone > wants to go, because they are never responsible, and therefore > it should NOT be a matter of policy where someone can or cannot > teleport while keeping their inventory: it should simply be > possible, because the address is given in the LandMark. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0015174c336ecb4f5804719d75ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Carlo has expressed the issue perfectly in his post.

This isn't = merely about a choice of words, it's a matter of actual functionality.= =A0 Given two SL-compatible virtual worlds each comprising multiple regions= , either OGP provides a mechanism for teleporting from a region in the firs= t world to a region in the second world, or it doesn't.

Many things go along with cross-world teleports of course.=A0 Cross-wor= ld landmarks is one issue, continuity of inventory while in compatible worl= ds is another, and so on.

While the details are of course complex to= work out, at the heart of it is a very simple question about goals, and it= deserves a clear answer.=A0 Will OGP provide interop between SL-compatible= virtual worlds, or is that not intended OGP functionality?

=A0We need to know what is in scope for OGPX, because that scope determ= ines our discussions, our implementations, our deliverables and our timelin= es.
=A0
Morgaine.








On Fri, Aug 21, 2009 at 12:50 AM, Carlo Wood <carlo@alinoe.com> wrote:
I'm feeling a bit dizzy of all the terminology :p
And, I'm still not sure if I understand it: it's still unclear.

Perhaps we'll just have to use hard examples on this mailinglist
first to make things clear, and only then we can think about
ways to achieve the same clearness in more abstract terms.

---

1) Right now, there is 'Second Life', and there are several
=A0 opensim worlds that are very very like Second Life. Never I
=A0 am refering to or even thinking about WoW.

2) Right now, therefore, we can call those entirely separated
=A0 administrative domains, different "worlds", as has been
=A0 done in the past several years.

=A0 We might want to change that terminology, but let me use
=A0 "world" to refer the currently existing different worlds, =A0 where "Second Life" is one of them and -say- "opengrid = X" is
=A0 another.

3) These worlds are separated in EVERY way:
=A0 - You cannot teleport bewteen them.
=A0 - There is no notion of Landmarks that refer outside a given world. =A0 - You cannot send IM's to avatars in the other world.
=A0 - You cannot access any asset (or inventory) of another world.

4) I thought that the OGPX effort had as goal to change this
=A0 *complete* separation.

However, if we want to make these limitations vanish then they
cannot be used to DEFINE what (separate) world mean... Hence,
the term becomes undefined and unclear (in the future).

But-- there are things that define the "worlds" that do NOT
want to change:

* The administration is entirely different:
=A0- A TOS only applies to one world.
=A0- An Abuse Report only has effect within one virtual world.
=A0- A ban by such an administration only affects their own world.

I think that most ideal situation would be when it is entirely
and only the user that decides if they want to visit another world,
completely independent of which world that is (as they can now
by simply logging out, and logging in elsewhere).

This CAN be supported; but it would mean to both region domain
AND agent domain (in order to switch completely between administrations etc= ).

Of course, viewers could simply support a seemless logout and login
elsewhere, but we (the users) want support for this in the format
of LandMarks, so that it is relatively easy to invite someone to
that other place, in another world.

Trivially, however, two major annoyances arrise with such a simple sheme:
* The need to create a new account (avatar name / password)
* Complete loss of access to inventory:
=A0- loss of shape, skin, clothes and attachments during teleport
=A0- loss of everything else in the inventory

If I'm correct then the latter has everything to do with the
agent domain; thus, if someone would stay in the same agent domain
(ie, one run by Linden Lab), then one would not need to create a
new account, would not need to logout and re-login, would not
lose appearance or inventory.

The question remains now:

how will that affect the ideal solution? Because to the user those
worlds will suddenly appear to be a single world.

What if a griefer logins in with LL, teleports to opengrid X and
halts a sim there by running 10,000 scripts in attachments.

Whose TOS determines if that is allowed? I'd say opengrid X's tos.<= br> And if opengrid X's TOS does not allow halting a sim, then where does an Abuse Report go to? I'd say... still to opengrid X's administrat= ion.
And when they decide to ban this person, will it be possible to
ban that (LL) account from opengrid X?

These questions are not trivial, but of utmost importance (yes,
also for the protocol): any and all administrative issues should
be a case of the administration of the *region* one is in, and
never of the agent domain someone belongs to.

As a result, an agent domain shouldn't care less where someone
wants to go, because they are never responsible, and therefore
it should NOT be a matter of policy where someone can or cannot
teleport while keeping their inventory: it should simply be
possible, because the address is given in the LandMark.

--
Carlo Wood <carlo@alinoe.com>
___________________________________= ____________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--0015174c336ecb4f5804719d75ef-- From dyerbrookme@juno.com Thu Aug 20 21:34:59 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FAAF3A696A for ; Thu, 20 Aug 2009 21:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlW6U4Yab74e for ; Thu, 20 Aug 2009 21:34:58 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id A60A13A6C67 for ; Thu, 20 Aug 2009 21:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1250829267; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=X-UNTD-OriginStamp:From:Date:To:Cc:Subject:Message-Id: Content-Type; b=fkn1kqjE0+Cm/BLKLDn2o+aYapHxjZR4rIKt2XLY/P6LU9svDYTUqXWlhO96MFCq4 CxrqYARhquxi272ggN5MMRixriNXY6dUMCZHA/EB/E/MPc+VMTBLm1Fu7XlQ3Cylm6 EtRr+sm2tYe0VHgKALBQBXxSlfp6jtp/Nsxykr48= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail14.vgs.untd.com [10.181.12.154]) by smtpout02.vgs.untd.com with SMTP id AABFJ6J8PAVZ8FNA for (sender ); Thu, 20 Aug 2009 21:34:21 -0700 (PDT) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucfxt0SOiKypRtSLbY5+l/Fs5fKBdEF6Gog== Received: (from dyerbrookme@juno.com) by webmail14.vgs.untd.com (jqueuemail) id PQGAR5DE; Thu, 20 Aug 2009 21:33:50 PDT Received: from [141.149.49.73] by webmail14.vgs.untd.com with HTTP: Fri, 21 Aug 2009 04:32:57 GMT X-Originating-IP: [141.149.49.73] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Fri, 21 Aug 2009 04:32:57 GMT To: morgaine.dinova@googlemail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090821.003257.11146.0@webmail14.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 3:5:2208402381 X-UNTD-Peer-Info: 10.181.12.154|webmail14.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 04:34:59 -0000 What is deeply, deeply, profoundly unjust and undemocratic about this en= tire OGPX exercise is that you guys are feigning to be a "mere technical= group" and deal "only" with technical matters of interoperability, but = in fact you are pre-deciding, prejudicing, and hijacking the governance = questions of worlds that you should not be allowed to pre-decide because= you are only coders, only the people who showed up and grabbed this arc= ane standards group, and not the citizenry of these worlds. >Re: Whose TOS determines if that is allowed? I'd say opengrid X's tos. And if opengrid X's TOS does not allow halting a sim, then where does an Abuse Report go to? I'd say... still to opengrid X's administration. And when they decide to ban this person, will it be possible to ban that (LL) account from opengrid X? This is the sort of question that you ought not to decide. Because you w= ill either wind up making it easy for a few platform providers to mass-b= an and ban-link people they don't like, and collude on blacklists OR (mo= re likely given LL's tolerance of griefers like Woodbury University)defa= ult to letting everyone go everywhere with no civilization and make ban = capacity a plug-in. It's why people keep coming back to the truth of this situation: that no= one needs interoperability but you, because most people can log on just= fine in a few steps, and make a separate account for another world and = not fret that they can't steal other people's content to bring with them= . You tell us you have to stay out of the content permissions issues becau= se it is "impossible" technically (merely a political question, of cours= e, as it is possible once there is political will as we see on JIRA prop= osals and in the Content Roadmap references to *obstacles*). But suddenly, you have to get into the fine-tuning of governance systems= that ought not to be baked into tools in this fashion. This will end badly. ____________________________________________________________ Click now for prescreened plumbing contractors. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTRHI8EaXHEFrOWxHVHVcqn= fmzy553lp5E4X5RJ4PAr1cDVB5WlfXa/ From dwl@us.ibm.com Fri Aug 21 06:54:59 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7046D3A6926; Fri, 21 Aug 2009 06:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=1.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5JbU7-XNcPc; Fri, 21 Aug 2009 06:54:58 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 7E5CB3A6E11; Fri, 21 Aug 2009 06:54:51 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7LDkp3n002906; Fri, 21 Aug 2009 09:46:51 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7LDsu0a248198; Fri, 21 Aug 2009 09:54:56 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7LDspQB016090; Fri, 21 Aug 2009 09:54:56 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7LDsoPr015992; Fri, 21 Aug 2009 09:54:51 -0400 In-Reply-To: References: <20090820141835.GB28751@alinoe.com> <20090820235051.GA21280@alinoe.com> <20090820235657.GB21280@alinoe.com> To: Meadhbh Siobhan MIME-Version: 1.0 X-KeepSent: 048CEB61:3E58783F-85257619:004946AA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Fri, 21 Aug 2009 09:54:45 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 08/21/2009 09:54:50, Serialize complete at 08/21/2009 09:54:50 Content-Type: multipart/alternative; boundary="=_alternative 004C6C7885257619_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 13:54:59 -0000 This is a multipart message in MIME format. --=_alternative 004C6C7885257619_= Content-Type: text/plain; charset="US-ASCII" I am going to suggest inserting a very concise paragraph after the second paragraph. >>> Insert Regions and Services implemented according to the specifications may be assembled into multiple virtual worlds. These worlds may embody multiple domains of trust. Deployed virtual worlds may support different policies of use. Constrained by these policies, the protocols will permit interoperation across OGPX virtual worlds with compatible policies and trust models. >>> end insert I poersonally think this is implicit, but making it explicit doesn't hurt. I think this preserves the separation of concern we desire. Mechanisms are defined at the protocol level. Policy is defined separate from mechanism. It should be possible to deploy everything from highly constrained walled gardens to very open grids. The degree of avatar, agent, service and digital goods flow between specific virtual worlds will vary according to the policies, and trust boundaries established by deployers. Nothing in the specifications dictates specific policies This follows the existing practices of the web and internet.The core protocols and formats of the internet permit interoperation, but deployers routinely constrain the accessibility and reach of services based on policy. - David W. Levine ~ Zha Ewry (ISL) --=_alternative 004C6C7885257619_= Content-Type: text/html; charset="US-ASCII"
I am going to suggest inserting a very  concise paragraph after the second paragraph.

>>> Insert

Regions and Services implemented according to the specifications may be assembled into
multiple virtual worlds. These worlds may embody multiple domains of trust. Deployed virtual
worlds may support different policies of use. Constrained by these policies, the protocols will
permit interoperation across OGPX  virtual worlds with compatible policies and trust models.

>>> end insert

I poersonally think this is implicit, but making it explicit doesn't hurt.

I think this preserves the separation of concern we desire. Mechanisms are defined at the
protocol level. Policy is defined separate from mechanism. It should be possible to deploy
everything from highly constrained walled gardens to very open grids. The degree of
avatar, agent, service and digital goods flow between specific virtual worlds will vary according
to the policies, and trust boundaries established by deployers. Nothing in the specifications
dictates specific policies

This follows the existing  practices of the web and internet.The core protocols
and formats of the internet permit interoperation, but deployers routinely constrain
the accessibility and reach of services based on policy.


- David W. Levine
~ Zha Ewry (ISL)


--=_alternative 004C6C7885257619_=-- From infinity@lindenlab.com Fri Aug 21 07:33:05 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2C13A6A64; Fri, 21 Aug 2009 07:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfY3y09E9NEk; Fri, 21 Aug 2009 07:33:04 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 8E0473A6909; Fri, 21 Aug 2009 07:33:04 -0700 (PDT) Received: by pxi1 with SMTP id 1so4427156pxi.31 for ; Fri, 21 Aug 2009 07:33:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.25.38 with SMTP id c38mr57811wfj.253.1250865188682; Fri, 21 Aug 2009 07:33:08 -0700 (PDT) In-Reply-To: References: <20090820235051.GA21280@alinoe.com> <20090820235657.GB21280@alinoe.com> Date: Fri, 21 Aug 2009 07:33:08 -0700 Message-ID: <3a880e2c0908210733v5e2b53a0x889f0f564a573461@mail.gmail.com> From: Infinity Linden To: David W Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Meadhbh Siobhan , ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 14:33:05 -0000 i would argue that we shouldn't be introducing a term into the charter that we can't define. the term "virtual world" is more appropriate for the MMOX effort. OGP has an intentionally loose definition of the term "virtual world," and it means (roughly) "the set of places you can teleport or walk to." this is NOT a feature that is defined by protocol, but by trust. there is absolutely nothing in the protocol that requires region operator 'A' to trust region operator 'B' or agent domain operator 'C'. we do, however, define message formats and techniques to carry artifacts of this trust. there is nothing in the PROTOCOL that defines who trusts who. this is EXACTLY the issue that torpedoed PEM and led to MOSS and later S/MIME. the protocols MUST NOT define trust relationships for operators. they MUST be deferred to deployers. because we cannot define trust in the protocol, it is inappropriate to insert language in the charter based on that assumption. if you define the term "virtual world" as "the set of places you can teleport to" then this term CAN'T have meaning because it depends on local policy that is out of the control of the protocol specifiers. this is why the term is not used. this is why we define the protocol in terms of things we CAN make some assumptions about: the required parties in a protocol transaction. in the case of teleport, this includes the originating region, the target region and the agent domain. this is the moral equivalent to saying the following in the ssh specification "every ssh server must define a user called 'root', and that user must have full permissions over the server." as it happens, a great number of ssh servers have a superuser named root, but some don't. there's no reason to define it in the protocol because it's a matter of local policy. when we say "there are things called virtual worlds, and they're defined as the set of all places you can teleport to," what does that give us? from a protocol perspective, it gives us nothing, because we will never user it. as part of the introduction, we may want to say "this protocol can be used to construct a set of connected regions that MAY be rendered by a client application in a form that appears as a virtual world." but this gets us what? -cheers -meadhbh On Fri, Aug 21, 2009 at 6:54 AM, David W Levine wrote: > > I am going to suggest inserting a very =A0concise paragraph after the sec= ond > paragraph. > >>>> Insert > > Regions and Services implemented according to the specifications may be > assembled into > multiple virtual worlds. These worlds may embody multiple domains of trus= t. > Deployed virtual > worlds may support different policies of use. Constrained by these polici= es, > the protocols will > permit interoperation across OGPX =A0virtual worlds with compatible polic= ies > and trust models. > >>>> end insert > > I poersonally think this is implicit, but making it explicit doesn't hurt= . > > I think this preserves the separation of concern we desire. Mechanisms ar= e > defined at the > protocol level. Policy is defined separate from mechanism. It should be > possible to deploy > everything from highly constrained walled gardens to very open grids. The > degree of > avatar, agent, service and digital goods flow between specific virtual > worlds will vary according > to the policies, and trust boundaries established by deployers. Nothing i= n > the specifications > dictates specific policies > > This follows the existing =A0practices of the web and internet.The core > protocols > and formats of the internet permit interoperation, but deployers routinel= y > constrain > the accessibility and reach of services based on policy. > > > - David W. Levine > ~ Zha Ewry (ISL) > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From dwl@us.ibm.com Fri Aug 21 09:01:16 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778FE3A6D2A; Fri, 21 Aug 2009 09:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCdD6wlI688r; Fri, 21 Aug 2009 09:01:15 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id D7B6B28C1F4; Fri, 21 Aug 2009 09:01:14 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7LG5H3C020000; Fri, 21 Aug 2009 12:05:17 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7LG1CdU161314; Fri, 21 Aug 2009 12:01:12 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7LG1CSE024793; Fri, 21 Aug 2009 12:01:12 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7LG18x0024395; Fri, 21 Aug 2009 12:01:09 -0400 In-Reply-To: <3a880e2c0908210733v5e2b53a0x889f0f564a573461@mail.gmail.com> References: <20090820235051.GA21280@alinoe.com> <20090820235657.GB21280@alinoe.com> <3a880e2c0908210733v5e2b53a0x889f0f564a573461@mail.gmail.com> To: Infinity Linden MIME-Version: 1.0 X-KeepSent: BD0DCC89:9430E59E-85257619:0056B4DE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Fri, 21 Aug 2009 12:01:05 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 08/21/2009 12:01:08, Serialize complete at 08/21/2009 12:01:08 Content-Type: multipart/alternative; boundary="=_alternative 0057FD2285257619_=" Cc: Meadhbh Siobhan , ogpx@ietf.org, ogpx-bounces@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 16:01:16 -0000 This is a multipart message in MIME format. --=_alternative 0057FD2285257619_= Content-Type: text/plain; charset="US-ASCII" Fair enough. So.. Let me try an even crisper wording. >>> Regions and Services implemented according to the specifications may be deployed by separate organization with varying policies and trust domains. The OGPX protocols will provide the mechanisms for these services to interoperate, when permitted by policy and shared trust domains. >>> Infinity Linden 08/21/2009 10:33 AM To David W Levine/Watson/IBM@IBMUS cc Meadhbh Siobhan , ogpx-bounces@ietf.org, ogpx@ietf.org Subject Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision i would argue that we shouldn't be introducing a term into the charter that we can't define. the term "virtual world" is more appropriate for the MMOX effort. OGP has an intentionally loose definition of the term "virtual world," and it means (roughly) "the set of places you can teleport or walk to." this is NOT a feature that is defined by protocol, but by trust. there is absolutely nothing in the protocol that requires region operator 'A' to trust region operator 'B' or agent domain operator 'C'. we do, however, define message formats and techniques to carry artifacts of this trust. there is nothing in the PROTOCOL that defines who trusts who. this is EXACTLY the issue that torpedoed PEM and led to MOSS and later S/MIME. the protocols MUST NOT define trust relationships for operators. they MUST be deferred to deployers. because we cannot define trust in the protocol, it is inappropriate to insert language in the charter based on that assumption. if you define the term "virtual world" as "the set of places you can teleport to" then this term CAN'T have meaning because it depends on local policy that is out of the control of the protocol specifiers. this is why the term is not used. this is why we define the protocol in terms of things we CAN make some assumptions about: the required parties in a protocol transaction. in the case of teleport, this includes the originating region, the target region and the agent domain. this is the moral equivalent to saying the following in the ssh specification "every ssh server must define a user called 'root', and that user must have full permissions over the server." as it happens, a great number of ssh servers have a superuser named root, but some don't. there's no reason to define it in the protocol because it's a matter of local policy. when we say "there are things called virtual worlds, and they're defined as the set of all places you can teleport to," what does that give us? from a protocol perspective, it gives us nothing, because we will never user it. as part of the introduction, we may want to say "this protocol can be used to construct a set of connected regions that MAY be rendered by a client application in a form that appears as a virtual world." but this gets us what? -cheers -meadhbh On Fri, Aug 21, 2009 at 6:54 AM, David W Levine wrote: > > I am going to suggest inserting a very concise paragraph after the second > paragraph. > >>>> Insert > > Regions and Services implemented according to the specifications may be > assembled into > multiple virtual worlds. These worlds may embody multiple domains of trust. > Deployed virtual > worlds may support different policies of use. Constrained by these policies, > the protocols will > permit interoperation across OGPX virtual worlds with compatible policies > and trust models. > >>>> end insert > > I poersonally think this is implicit, but making it explicit doesn't hurt. > > I think this preserves the separation of concern we desire. Mechanisms are > defined at the > protocol level. Policy is defined separate from mechanism. It should be > possible to deploy > everything from highly constrained walled gardens to very open grids. The > degree of > avatar, agent, service and digital goods flow between specific virtual > worlds will vary according > to the policies, and trust boundaries established by deployers. Nothing in > the specifications > dictates specific policies > > This follows the existing practices of the web and internet.The core > protocols > and formats of the internet permit interoperation, but deployers routinely > constrain > the accessibility and reach of services based on policy. > > > - David W. Levine > ~ Zha Ewry (ISL) > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --=_alternative 0057FD2285257619_= Content-Type: text/html; charset="US-ASCII"
Fair enough. So.. Let me try an even crisper wording.

>>>
Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains.
The OGPX protocols will provide the mechanisms for these services to interoperate,
when permitted by policy and shared trust domains.
>>>




Infinity Linden <infinity@lindenlab.com>

08/21/2009 10:33 AM

To
David W Levine/Watson/IBM@IBMUS
cc
Meadhbh Siobhan <meadhbh.siobhan@gmail.com>, ogpx-bounces@ietf.org, ogpx@ietf.org
Subject
Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision





i would argue that we shouldn't be introducing a term into the charter
that we can't define. the term "virtual world" is more appropriate for
the MMOX effort. OGP has an intentionally loose definition of the term
"virtual world," and it means (roughly) "the set of places you can
teleport or walk to." this is NOT a feature that is defined by
protocol, but by trust.

there is absolutely nothing in the protocol that requires region
operator 'A' to trust region operator 'B' or agent domain operator
'C'. we do, however, define message formats and techniques to carry
artifacts of this trust. there is nothing in the PROTOCOL that defines
who trusts who.

this is EXACTLY the issue that torpedoed PEM and led to MOSS and later
S/MIME. the protocols MUST NOT define trust relationships for
operators. they MUST be deferred to deployers. because we cannot
define trust in the protocol, it is inappropriate to insert language
in the charter based on that assumption.

if you define the term "virtual world" as "the set of places you can
teleport to" then this term CAN'T have meaning because it depends on
local policy that is out of the control of the protocol specifiers.
this is why the term is not used. this is why we define the protocol
in terms of things we CAN make some assumptions about: the required
parties in a protocol transaction. in the case of teleport, this
includes the originating region, the target region and the agent
domain.

this is the moral equivalent to saying the following in the ssh
specification "every ssh server must define a user called 'root', and
that user must have full permissions over the server." as it happens,
a great number of ssh servers have a superuser named root, but some
don't. there's no reason to define it in the protocol because it's a
matter of local policy.

when we say "there are things called virtual worlds, and they're
defined as the set of all places you can teleport to," what does that
give us? from a protocol perspective, it gives us nothing, because we
will never user it.

as part of the introduction, we may want to say "this protocol can be
used to construct a set of connected regions that MAY be rendered by a
client application in a form that appears as a virtual world." but
this gets us what?

-cheers
-meadhbh

On Fri, Aug 21, 2009 at 6:54 AM, David W Levine<dwl@us.ibm.com> wrote:
>
> I am going to suggest inserting a very  concise paragraph after the second
> paragraph.
>
>>>> Insert
>
> Regions and Services implemented according to the specifications may be
> assembled into
> multiple virtual worlds. These worlds may embody multiple domains of trust.
> Deployed virtual
> worlds may support different policies of use. Constrained by these policies,
> the protocols will
> permit interoperation across OGPX  virtual worlds with compatible policies
> and trust models.
>
>>>> end insert
>
> I poersonally think this is implicit, but making it explicit doesn't hurt.
>
> I think this preserves the separation of concern we desire. Mechanisms are
> defined at the
> protocol level. Policy is defined separate from mechanism. It should be
> possible to deploy
> everything from highly constrained walled gardens to very open grids. The
> degree of
> avatar, agent, service and digital goods flow between specific virtual
> worlds will vary according
> to the policies, and trust boundaries established by deployers. Nothing in
> the specifications
> dictates specific policies
>
> This follows the existing  practices of the web and internet.The core
> protocols
> and formats of the internet permit interoperation, but deployers routinely
> constrain
> the accessibility and reach of services based on policy.
>
>
> - David W. Levine
> ~ Zha Ewry (ISL)
>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
--=_alternative 0057FD2285257619_=-- From josh@lindenlab.com Fri Aug 21 09:10:32 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D628D28C1C7 for ; Fri, 21 Aug 2009 09:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS78Hr3f0hCd for ; Fri, 21 Aug 2009 09:10:31 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 6CCE428C14C for ; Fri, 21 Aug 2009 09:10:31 -0700 (PDT) Received: by pxi1 with SMTP id 1so4483060pxi.31 for ; Fri, 21 Aug 2009 09:10:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.60.3 with SMTP id i3mr67495wfa.294.1250871035274; Fri, 21 Aug 2009 09:10:35 -0700 (PDT) In-Reply-To: References: <20090820235051.GA21280@alinoe.com> <20090820235657.GB21280@alinoe.com> <3a880e2c0908210733v5e2b53a0x889f0f564a573461@mail.gmail.com> Date: Fri, 21 Aug 2009 09:10:35 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00504502ad14b7a4900471a91b40 Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 16:10:32 -0000 --00504502ad14b7a4900471a91b40 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I do think this is one of the places in the charter where using "virtual world(s)" is justified; the crisper wording may not imply much about the intent to folks outside the effort, and (to Morgaine's point) seems very abstract even to those inside the effort. Much of the draft charter feedback we've gotten is that "concrete is a good thing"! How about a tweak: Regions and Services implemented according to the specifications may be deployed by separate organization with varying policies and trust domains. The OGPX protocols will provide the mechanisms for these virtual world services to interoperate, when permitted by policy and shared trust domains. Or: Regions and Services implemented according to the specifications may be deployed by separate organization with varying policies and trust domains. The OGPX protocols will provide the mechanisms for these services to interoperate, when permitted by policy and shared trust domains, enabling the creation of interoperating virtual worlds. (This rather short paragraph repeats "interoperate", "trust domain" and "policy" twice, alas.) On Fri, Aug 21, 2009 at 9:01 AM, David W Levine wrote: > > Fair enough. So.. Let me try an even crisper wording. > > >>> > Regions and Services implemented according to the specifications may be > deployed by separate organization with varying policies and trust domains. > The OGPX protocols will provide the mechanisms for these services to > interoperate, > when permitted by policy and shared trust domains. > >>> > > > > > *Infinity Linden * > > 08/21/2009 10:33 AM > To > David W Levine/Watson/IBM@IBMUS cc > Meadhbh Siobhan , ogpx-bounces@ietf.org, > ogpx@ietf.org Subject > Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision > > > > > i would argue that we shouldn't be introducing a term into the charter > that we can't define. the term "virtual world" is more appropriate for > the MMOX effort. OGP has an intentionally loose definition of the term > "virtual world," and it means (roughly) "the set of places you can > teleport or walk to." this is NOT a feature that is defined by > protocol, but by trust. > > there is absolutely nothing in the protocol that requires region > operator 'A' to trust region operator 'B' or agent domain operator > 'C'. we do, however, define message formats and techniques to carry > artifacts of this trust. there is nothing in the PROTOCOL that defines > who trusts who. > > this is EXACTLY the issue that torpedoed PEM and led to MOSS and later > S/MIME. the protocols MUST NOT define trust relationships for > operators. they MUST be deferred to deployers. because we cannot > define trust in the protocol, it is inappropriate to insert language > in the charter based on that assumption. > > if you define the term "virtual world" as "the set of places you can > teleport to" then this term CAN'T have meaning because it depends on > local policy that is out of the control of the protocol specifiers. > this is why the term is not used. this is why we define the protocol > in terms of things we CAN make some assumptions about: the required > parties in a protocol transaction. in the case of teleport, this > includes the originating region, the target region and the agent > domain. > > this is the moral equivalent to saying the following in the ssh > specification "every ssh server must define a user called 'root', and > that user must have full permissions over the server." as it happens, > a great number of ssh servers have a superuser named root, but some > don't. there's no reason to define it in the protocol because it's a > matter of local policy. > > when we say "there are things called virtual worlds, and they're > defined as the set of all places you can teleport to," what does that > give us? from a protocol perspective, it gives us nothing, because we > will never user it. > > as part of the introduction, we may want to say "this protocol can be > used to construct a set of connected regions that MAY be rendered by a > client application in a form that appears as a virtual world." but > this gets us what? > > -cheers > -meadhbh > > On Fri, Aug 21, 2009 at 6:54 AM, David W Levine wrote: > > > > I am going to suggest inserting a very concise paragraph after the > second > > paragraph. > > > >>>> Insert > > > > Regions and Services implemented according to the specifications may be > > assembled into > > multiple virtual worlds. These worlds may embody multiple domains of > trust. > > Deployed virtual > > worlds may support different policies of use. Constrained by these > policies, > > the protocols will > > permit interoperation across OGPX virtual worlds with compatible > policies > > and trust models. > > > >>>> end insert > > > > I poersonally think this is implicit, but making it explicit doesn't > hurt. > > > > I think this preserves the separation of concern we desire. Mechanisms > are > > defined at the > > protocol level. Policy is defined separate from mechanism. It should be > > possible to deploy > > everything from highly constrained walled gardens to very open grids. The > > degree of > > avatar, agent, service and digital goods flow between specific virtual > > worlds will vary according > > to the policies, and trust boundaries established by deployers. Nothing > in > > the specifications > > dictates specific policies > > > > This follows the existing practices of the web and internet.The core > > protocols > > and formats of the internet permit interoperation, but deployers > routinely > > constrain > > the accessibility and reach of services based on policy. > > > > > > - David W. Levine > > ~ Zha Ewry (ISL) > > > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00504502ad14b7a4900471a91b40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I do think this is one of the places in the charter where using "virtu= al world(s)" is justified; the crisper wording may not imply much abou= t the intent to folks outside the effort, and (to Morgaine's point) see= ms very abstract even to those inside the effort. Much of the draft charter= feedback we've gotten is that "concrete is a good thing"!
How about a tweak:

Regions and Services implemented according to= the specifications may be
deployed by separate organization with varyin= g policies and trust domains.
The OGPX protocols will provide the mechan= isms for these virtual world
services to interoperate, when permitted by policy and shared trust domains= .

Or:

Regions and Services implemented according to the speci= fications may be
deployed by separate organization with varying policies and trust domains.<= br> The OGPX protocols will provide the mechanisms for these services to
in= teroperate, when permitted by policy and shared trust domains, enabling
= the creation of interoperating virtual worlds.

(This rather short paragraph repeats "interoperate", "tr= ust domain" and "policy" twice, alas.)

On Fri, Aug 21, 2009 at 9:01 AM, David W Levine <dwl@us.ibm.com> wro= te:

Fair enough. So.. Let me try an ev= en crisper wording.

>>>
Regions and Services implemented according to the specifications may be
deployed by separate organization with varyi= ng policies and trust domains.
The OGPX protocols will provide the mechanisms for these services to interoperate,
when permitted by policy and shared trust domains.
>>>




Infinity Linden <infinity@lindenlab.com>

08/21/2009 10:33 AM

To
David W Levine/Watson/IBM@IBM= US
cc
Meadhbh Siobhan <meadhbh.siobhan@gma= il.com>, ogpx-bounces@iet= f.org, ogpx@ietf.org=
Subject
Re: [ogpx] OGPX WG draft char= ter, 2009-08-19 revision





i would argue that we shouldn't be introducing= a term into the charter
that we can't define. the term "virtual world" is more approp= riate for
the MMOX effort. OGP has an intentionally loose definition of the term
"virtual world," and it means (roughly) "the set of places you can
teleport or walk to." this is NOT a feature that is defined by
protocol, but by trust.

there is absolutely nothing in the protocol that requires region
operator 'A' to trust region operator 'B' or agent domain o= perator
'C'. we do, however, define message formats and techniques to carry=
artifacts of this trust. there is nothing in the PROTOCOL that defines
who trusts who.

this is EXACTLY the issue that torpedoed PEM and led to MOSS and later
S/MIME. the protocols MUST NOT define trust relationships for
operators. they MUST be deferred to deployers. because we cannot
define trust in the protocol, it is inappropriate to insert language
in the charter based on that assumption.

if you define the term "virtual world" as "the set of places you can
teleport to" then this term CAN'T have meaning because it depends on
local policy that is out of the control of the protocol specifiers.
this is why the term is not used. this is why we define the protocol
in terms of things we CAN make some assumptions about: the required
parties in a protocol transaction. in the case of teleport, this
includes the originating region, the target region and the agent
domain.

this is the moral equivalent to saying the following in the ssh
specification "every ssh server must define a user called 'root= 9;, and
that user must have full permissions over the server." as it happens,<= br> a great number of ssh servers have a superuser named root, but some
don't. there's no reason to define it in the protocol because it= 9;s a
matter of local policy.

when we say "there are things called virtual worlds, and they're defined as the set of all places you can teleport to," what does that<= br> give us? from a protocol perspective, it gives us nothing, because we
will never user it.

as part of the introduction, we may want to say "this protocol can be
used to construct a set of connected regions that MAY be rendered by a
client application in a form that appears as a virtual world." but
this gets us what?

-cheers
-meadhbh

On Fri, Aug 21, 2009 at 6:54 AM, David W Levine<dwl@us.ibm.com> wrote:
>
> I am going to suggest inserting a very =C2=A0concise paragraph after the second
> paragraph.
>
>>>> Insert
>
> Regions and Services implemented according to the specifications may be
> assembled into
> multiple virtual worlds. These worlds may embody multiple domains of trust.
> Deployed virtual
> worlds may support different policies of use. Constrained by these policies,
> the protocols will
> permit interoperation across OGPX =C2=A0virtual worlds with compatible policies
> and trust models.
>
>>>> end insert
>
> I poersonally think this is implicit, but making it explicit doesn'= ;t hurt.
>
> I think this preserves the separation of concern we desire. Mechanisms are
> defined at the
> protocol level. Policy is defined separate from mechanism. It should be
> possible to deploy
> everything from highly constrained walled gardens to very open grids. The
> degree of
> avatar, agent, service and digital goods flow between specific virtual=
> worlds will vary according
> to the policies, and trust boundaries established by deployers. Nothin= g in
> the specifications
> dictates specific policies
>
> This follows the existing =C2=A0practices of the web and internet.The core
> protocols
> and formats of the internet permit interoperation, but deployers routi= nely
> constrain
> the accessibility and reach of services based on policy.
>
>
> - David W. Levine
> ~ Zha Ewry (ISL)
>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/o= gpx
>
>

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00504502ad14b7a4900471a91b40-- From infinity@lindenlab.com Fri Aug 21 09:14:56 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA573A6E1C for ; Fri, 21 Aug 2009 09:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtkaSoAhraV3 for ; Fri, 21 Aug 2009 09:14:55 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 17BFD3A6359 for ; Fri, 21 Aug 2009 09:14:55 -0700 (PDT) Received: by pzk4 with SMTP id 4so95399pzk.29 for ; Fri, 21 Aug 2009 09:14:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.4.38 with SMTP id 38mr96629wfd.119.1250871293427; Fri, 21 Aug 2009 09:14:53 -0700 (PDT) In-Reply-To: References: <20090820235051.GA21280@alinoe.com> Date: Fri, 21 Aug 2009 09:14:53 -0700 Message-ID: <3a880e2c0908210914j68d21406pb7a5b4a678030316@mail.gmail.com> From: Infinity Linden To: Joshua Bell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 16:14:56 -0000 works for me. On Fri, Aug 21, 2009 at 9:10 AM, Joshua Bell wrote: > I do think this is one of the places in the charter where using "virtual > world(s)" is justified; the crisper wording may not imply much about the > intent to folks outside the effort, and (to Morgaine's point) seems very > abstract even to those inside the effort. Much of the draft charter feedb= ack > we've gotten is that "concrete is a good thing"! > > How about a tweak: > > Regions and Services implemented according to the specifications may be > deployed by separate organization with varying policies and trust domains= . > The OGPX protocols will provide the mechanisms for these virtual world > services to interoperate, when permitted by policy and shared trust domai= ns. > > Or: > > Regions and Services implemented according to the specifications may be > deployed by separate organization with varying policies and trust domains= . > The OGPX protocols will provide the mechanisms for these services to > interoperate, when permitted by policy and shared trust domains, enabling > the creation of interoperating virtual worlds. > > (This rather short paragraph repeats "interoperate", "trust domain" and > "policy" twice, alas.) > > On Fri, Aug 21, 2009 at 9:01 AM, David W Levine wrote: >> >> Fair enough. So.. Let me try an even crisper wording. >> >> >>> >> Regions and Services implemented according to the specifications may be >> deployed by separate organization with varying policies and trust domain= s. >> The OGPX protocols will provide the mechanisms for these services to >> interoperate, >> when permitted by policy and shared trust domains. >> >>> >> >> >> >> >> Infinity Linden >> >> 08/21/2009 10:33 AM >> >> To >> David W Levine/Watson/IBM@IBMUS >> cc >> Meadhbh Siobhan , ogpx-bounces@ietf.org, >> ogpx@ietf.org >> Subject >> Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision >> >> >> >> >> i would argue that we shouldn't be introducing a term into the charter >> that we can't define. the term "virtual world" is more appropriate for >> the MMOX effort. OGP has an intentionally loose definition of the term >> "virtual world," and it means (roughly) "the set of places you can >> teleport or walk to." this is NOT a feature that is defined by >> protocol, but by trust. >> >> there is absolutely nothing in the protocol that requires region >> operator 'A' to trust region operator 'B' or agent domain operator >> 'C'. we do, however, define message formats and techniques to carry >> artifacts of this trust. there is nothing in the PROTOCOL that defines >> who trusts who. >> >> this is EXACTLY the issue that torpedoed PEM and led to MOSS and later >> S/MIME. the protocols MUST NOT define trust relationships for >> operators. they MUST be deferred to deployers. because we cannot >> define trust in the protocol, it is inappropriate to insert language >> in the charter based on that assumption. >> >> if you define the term "virtual world" as "the set of places you can >> teleport to" then this term CAN'T have meaning because it depends on >> local policy that is out of the control of the protocol specifiers. >> this is why the term is not used. this is why we define the protocol >> in terms of things we CAN make some assumptions about: the required >> parties in a protocol transaction. in the case of teleport, this >> includes the originating region, the target region and the agent >> domain. >> >> this is the moral equivalent to saying the following in the ssh >> specification "every ssh server must define a user called 'root', and >> that user must have full permissions over the server." as it happens, >> a great number of ssh servers have a superuser named root, but some >> don't. there's no reason to define it in the protocol because it's a >> matter of local policy. >> >> when we say "there are things called virtual worlds, and they're >> defined as the set of all places you can teleport to," what does that >> give us? from a protocol perspective, it gives us nothing, because we >> will never user it. >> >> as part of the introduction, we may want to say "this protocol can be >> used to construct a set of connected regions that MAY be rendered by a >> client application in a form that appears as a virtual world." but >> this gets us what? >> >> -cheers >> -meadhbh >> >> On Fri, Aug 21, 2009 at 6:54 AM, David W Levine wrote: >> > >> > I am going to suggest inserting a very =A0concise paragraph after the >> > second >> > paragraph. >> > >> >>>> Insert >> > >> > Regions and Services implemented according to the specifications may b= e >> > assembled into >> > multiple virtual worlds. These worlds may embody multiple domains of >> > trust. >> > Deployed virtual >> > worlds may support different policies of use. Constrained by these >> > policies, >> > the protocols will >> > permit interoperation across OGPX =A0virtual worlds with compatible >> > policies >> > and trust models. >> > >> >>>> end insert >> > >> > I poersonally think this is implicit, but making it explicit doesn't >> > hurt. >> > >> > I think this preserves the separation of concern we desire. Mechanisms >> > are >> > defined at the >> > protocol level. Policy is defined separate from mechanism. It should b= e >> > possible to deploy >> > everything from highly constrained walled gardens to very open grids. >> > The >> > degree of >> > avatar, agent, service and digital goods flow between specific virtual >> > worlds will vary according >> > to the policies, and trust boundaries established by deployers. Nothin= g >> > in >> > the specifications >> > dictates specific policies >> > >> > This follows the existing =A0practices of the web and internet.The cor= e >> > protocols >> > and formats of the internet permit interoperation, but deployers >> > routinely >> > constrain >> > the accessibility and reach of services based on policy. >> > >> > >> > - David W. Levine >> > ~ Zha Ewry (ISL) >> > >> > >> > >> > _______________________________________________ >> > ogpx mailing list >> > ogpx@ietf.org >> > https://www.ietf.org/mailman/listinfo/ogpx >> > >> > >> >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From dwl@us.ibm.com Fri Aug 21 09:17:48 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CAC43A6E09; Fri, 21 Aug 2009 09:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.724 X-Spam-Level: X-Spam-Status: No, score=-5.724 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZvFugiQ4G2U; Fri, 21 Aug 2009 09:17:46 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 2C93B3A6359; Fri, 21 Aug 2009 09:17:46 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7LGLuDm015768; Fri, 21 Aug 2009 12:21:56 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7LGHpTJ161374; Fri, 21 Aug 2009 12:17:51 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7LGHpgx015911; Fri, 21 Aug 2009 12:17:51 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7LGHpAI015906; Fri, 21 Aug 2009 12:17:51 -0400 In-Reply-To: References: <20090820235051.GA21280@alinoe.com> <20090820235657.GB21280@alinoe.com> <3a880e2c0908210733v5e2b53a0x889f0f564a573461@mail.gmail.com> To: Joshua Bell MIME-Version: 1.0 X-KeepSent: 63080364:5C8B8CC8-85257619:00594CD7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Fri, 21 Aug 2009 12:17:50 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 08/21/2009 12:17:50, Serialize complete at 08/21/2009 12:17:50 Content-Type: multipart/alternative; boundary="=_alternative 005985DE85257619_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 16:17:48 -0000 This is a multipart message in MIME format. --=_alternative 005985DE85257619_= Content-Type: text/plain; charset="US-ASCII" Either of those is fine with me. I think the former is crisper, the later slightly more elegant. (And yeah the repeat's annoying, but its hard to avoid) I think, we're about ready to say "last call" on comments. - David W. Levine Joshua Bell Sent by: ogpx-bounces@ietf.org 08/21/2009 12:10 PM To ogpx@ietf.org cc Subject Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision I do think this is one of the places in the charter where using "virtual world(s)" is justified; the crisper wording may not imply much about the intent to folks outside the effort, and (to Morgaine's point) seems very abstract even to those inside the effort. Much of the draft charter feedback we've gotten is that "concrete is a good thing"! How about a tweak: Regions and Services implemented according to the specifications may be deployed by separate organization with varying policies and trust domains. The OGPX protocols will provide the mechanisms for these virtual world services to interoperate, when permitted by policy and shared trust domains. Or: Regions and Services implemented according to the specifications may be deployed by separate organization with varying policies and trust domains. The OGPX protocols will provide the mechanisms for these services to interoperate, when permitted by policy and shared trust domains, enabling the creation of interoperating virtual worlds. (This rather short paragraph repeats "interoperate", "trust domain" and "policy" twice, alas.) On Fri, Aug 21, 2009 at 9:01 AM, David W Levine wrote: Fair enough. So.. Let me try an even crisper wording. >>> Regions and Services implemented according to the specifications may be deployed by separate organization with varying policies and trust domains. The OGPX protocols will provide the mechanisms for these services to interoperate, when permitted by policy and shared trust domains. >>> Infinity Linden 08/21/2009 10:33 AM To David W Levine/Watson/IBM@IBMUS cc Meadhbh Siobhan , ogpx-bounces@ietf.org, ogpx@ietf.org Subject Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision i would argue that we shouldn't be introducing a term into the charter that we can't define. the term "virtual world" is more appropriate for the MMOX effort. OGP has an intentionally loose definition of the term "virtual world," and it means (roughly) "the set of places you can teleport or walk to." this is NOT a feature that is defined by protocol, but by trust. there is absolutely nothing in the protocol that requires region operator 'A' to trust region operator 'B' or agent domain operator 'C'. we do, however, define message formats and techniques to carry artifacts of this trust. there is nothing in the PROTOCOL that defines who trusts who. this is EXACTLY the issue that torpedoed PEM and led to MOSS and later S/MIME. the protocols MUST NOT define trust relationships for operators. they MUST be deferred to deployers. because we cannot define trust in the protocol, it is inappropriate to insert language in the charter based on that assumption. if you define the term "virtual world" as "the set of places you can teleport to" then this term CAN'T have meaning because it depends on local policy that is out of the control of the protocol specifiers. this is why the term is not used. this is why we define the protocol in terms of things we CAN make some assumptions about: the required parties in a protocol transaction. in the case of teleport, this includes the originating region, the target region and the agent domain. this is the moral equivalent to saying the following in the ssh specification "every ssh server must define a user called 'root', and that user must have full permissions over the server." as it happens, a great number of ssh servers have a superuser named root, but some don't. there's no reason to define it in the protocol because it's a matter of local policy. when we say "there are things called virtual worlds, and they're defined as the set of all places you can teleport to," what does that give us? from a protocol perspective, it gives us nothing, because we will never user it. as part of the introduction, we may want to say "this protocol can be used to construct a set of connected regions that MAY be rendered by a client application in a form that appears as a virtual world." but this gets us what? -cheers -meadhbh On Fri, Aug 21, 2009 at 6:54 AM, David W Levine wrote: > > I am going to suggest inserting a very concise paragraph after the second > paragraph. > >>>> Insert > > Regions and Services implemented according to the specifications may be > assembled into > multiple virtual worlds. These worlds may embody multiple domains of trust. > Deployed virtual > worlds may support different policies of use. Constrained by these policies, > the protocols will > permit interoperation across OGPX virtual worlds with compatible policies > and trust models. > >>>> end insert > > I poersonally think this is implicit, but making it explicit doesn't hurt. > > I think this preserves the separation of concern we desire. Mechanisms are > defined at the > protocol level. Policy is defined separate from mechanism. It should be > possible to deploy > everything from highly constrained walled gardens to very open grids. The > degree of > avatar, agent, service and digital goods flow between specific virtual > worlds will vary according > to the policies, and trust boundaries established by deployers. Nothing in > the specifications > dictates specific policies > > This follows the existing practices of the web and internet.The core > protocols > and formats of the internet permit interoperation, but deployers routinely > constrain > the accessibility and reach of services based on policy. > > > - David W. Levine > ~ Zha Ewry (ISL) > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 005985DE85257619_= Content-Type: text/html; charset="US-ASCII"
Either of those is fine with me. I think the former is crisper, the later slightly
more elegant. (And yeah the repeat's annoying, but its hard to avoid)


I think, we're about ready to say "last call" on comments.

- David W. Levine


Joshua Bell <josh@lindenlab.com>
Sent by: ogpx-bounces@ietf.org

08/21/2009 12:10 PM

To
ogpx@ietf.org
cc
Subject
Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision





I do think this is one of the places in the charter where using "virtual world(s)" is justified; the crisper wording may not imply much about the intent to folks outside the effort, and (to Morgaine's point) seems very abstract even to those inside the effort. Much of the draft charter feedback we've gotten is that "concrete is a good thing"!

How about a tweak:

Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains.
The OGPX protocols will provide the mechanisms for these virtual world
services to interoperate, when permitted by policy and shared trust domains.

Or:

Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains.
The OGPX protocols will provide the mechanisms for these services to
interoperate, when permitted by policy and shared trust domains, enabling
the creation of interoperating virtual worlds.

(This rather short paragraph repeats "interoperate", "trust domain" and "policy" twice, alas.)
On Fri, Aug 21, 2009 at 9:01 AM, David W Levine <dwl@us.ibm.com> wrote:

Fair enough. So.. Let me try an even crisper wording.

>>>
Regions and Services implemented according to the specifications may be
deployed by separate organization with varying policies and trust domains.
The OGPX protocols will provide the mechanisms for these services to interoperate,
when permitted by policy and shared trust domains.
>>>



Infinity Linden <infinity@lindenlab.com>

08/21/2009 10:33 AM


To
David W Levine/Watson/IBM@IBMUS
cc
Meadhbh Siobhan <meadhbh.siobhan@gmail.com>, ogpx-bounces@ietf.org, ogpx@ietf.org
Subject
Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision







i would argue that we shouldn't be introducing a term into the charter
that we can't define. the term "virtual world" is more appropriate for
the MMOX effort. OGP has an intentionally loose definition of the term
"virtual world," and it means (roughly) "the set of places you can
teleport or walk to." this is NOT a feature that is defined by
protocol, but by trust.

there is absolutely nothing in the protocol that requires region
operator 'A' to trust region operator 'B' or agent domain operator
'C'. we do, however, define message formats and techniques to carry
artifacts of this trust. there is nothing in the PROTOCOL that defines
who trusts who.

this is EXACTLY the issue that torpedoed PEM and led to MOSS and later
S/MIME. the protocols MUST NOT define trust relationships for
operators. they MUST be deferred to deployers. because we cannot
define trust in the protocol, it is inappropriate to insert language
in the charter based on that assumption.

if you define the term "virtual world" as "the set of places you can
teleport to" then this term CAN'T have meaning because it depends on
local policy that is out of the control of the protocol specifiers.
this is why the term is not used. this is why we define the protocol
in terms of things we CAN make some assumptions about: the required
parties in a protocol transaction. in the case of teleport, this
includes the originating region, the target region and the agent
domain.

this is the moral equivalent to saying the following in the ssh
specification "every ssh server must define a user called 'root', and
that user must have full permissions over the server." as it happens,
a great number of ssh servers have a superuser named root, but some
don't. there's no reason to define it in the protocol because it's a
matter of local policy.

when we say "there are things called virtual worlds, and they're
defined as the set of all places you can teleport to," what does that
give us? from a protocol perspective, it gives us nothing, because we
will never user it.

as part of the introduction, we may want to say "this protocol can be
used to construct a set of connected regions that MAY be rendered by a
client application in a form that appears as a virtual world." but
this gets us what?

-cheers
-meadhbh

On Fri, Aug 21, 2009 at 6:54 AM, David W Levine<dwl@us.ibm.com> wrote:
>
> I am going to suggest inserting a very  concise paragraph after the second
> paragraph.
>
>>>> Insert
>
> Regions and Services implemented according to the specifications may be
> assembled into
> multiple virtual worlds. These worlds may embody multiple domains of trust.
> Deployed virtual
> worlds may support different policies of use. Constrained by these policies,
> the protocols will
> permit interoperation across OGPX  virtual worlds with compatible policies
> and trust models.
>
>>>> end insert
>
> I poersonally think this is implicit, but making it explicit doesn't hurt.
>
> I think this preserves the separation of concern we desire. Mechanisms are
> defined at the
> protocol level. Policy is defined separate from mechanism. It should be
> possible to deploy
> everything from highly constrained walled gardens to very open grids. The
> degree of
> avatar, agent, service and digital goods flow between specific virtual
> worlds will vary according
> to the policies, and trust boundaries established by deployers. Nothing in
> the specifications
> dictates specific policies
>
> This follows the existing  practices of the web and internet.The core
> protocols
> and formats of the internet permit interoperation, but deployers routinely
> constrain
> the accessibility and reach of services based on policy.
>
>
> - David W. Levine
> ~ Zha Ewry (ISL)
>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 005985DE85257619_=-- From mike.dickson@hp.com Fri Aug 21 09:19:35 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7907A3A6E45 for ; Fri, 21 Aug 2009 09:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx5tf42K58U6 for ; Fri, 21 Aug 2009 09:19:34 -0700 (PDT) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by core3.amsl.com (Postfix) with ESMTP id 0A7353A6359 for ; Fri, 21 Aug 2009 09:19:05 -0700 (PDT) Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0026.austin.hp.com (Postfix) with ESMTPS id 6D12FC422; Fri, 21 Aug 2009 16:19:11 +0000 (UTC) Received: from G3W0628.americas.hpqcorp.net (16.233.58.53) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 21 Aug 2009 16:18:40 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.147]) by G3W0628.americas.hpqcorp.net ([16.233.58.53]) with mapi; Fri, 21 Aug 2009 16:18:40 +0000 From: "Dickson, Mike (ISS Software)" To: Joshua Bell , "ogpx@ietf.org" Date: Fri, 21 Aug 2009 16:17:42 +0000 Thread-Topic: [ogpx] OGPX WG draft charter, 2009-08-19 revision Thread-Index: Acoiee4W10H7rJQvRyyFOs606TbAswAAILeQ Message-ID: <4646639E08F58B42836FAC24C94624DD6FE715D68A@GVW0433EXB.americas.hpqcorp.net> References: <20090820235051.GA21280@alinoe.com> <20090820235657.GB21280@alinoe.com> <3a880e2c0908210733v5e2b53a0x889f0f564a573461@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD6FE715D68AGVW0433EXBame_" MIME-Version: 1.0 Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 16:19:35 -0000 --_000_4646639E08F58B42836FAC24C94624DD6FE715D68AGVW0433EXBame_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogb2dweC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2dweC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSm9zaHVhIEJlbGwNClNlbnQ6IEZyaWRheSwgQXVndXN0IDIxLCAyMDA5 IDExOjExIEFNDQpUbzogb2dweEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtvZ3B4XSBPR1BYIFdH IGRyYWZ0IGNoYXJ0ZXIsIDIwMDktMDgtMTkgcmV2aXNpb24NCg0KDQpIb3cgYWJvdXQgYSB0d2Vh azoNCg0KUmVnaW9ucyBhbmQgU2VydmljZXMgaW1wbGVtZW50ZWQgYWNjb3JkaW5nIHRvIHRoZSBz cGVjaWZpY2F0aW9ucyBtYXkgYmUNCmRlcGxveWVkIGJ5IHNlcGFyYXRlIG9yZ2FuaXphdGlvbiB3 aXRoIHZhcnlpbmcgcG9saWNpZXMgYW5kIHRydXN0IGRvbWFpbnMuDQpUaGUgT0dQWCBwcm90b2Nv bHMgd2lsbCBwcm92aWRlIHRoZSBtZWNoYW5pc21zIGZvciB0aGVzZSB2aXJ0dWFsIHdvcmxkDQpz ZXJ2aWNlcyB0byBpbnRlcm9wZXJhdGUsIHdoZW4gcGVybWl0dGVkIGJ5IHBvbGljeSBhbmQgc2hh cmVkIHRydXN0IGRvbWFpbnMuDQoNCkkgbGlrZSB0aGlzIHNpbmNlIGl0IGRlZmluZXMg4oCcc2Vy dmljZXPigJ0gYXMgdGhvc2UgcmVsYXRlZCB0byBWVyBob3N0aW5nLiAgSXQgYWxzbyB3aWxsIHJl cXVpcmUgdGhhdCB0aGUgcHJvdG9jb2wgYWRkcmVzcyBob3cgaW50ZXJvcGVyYXRpb24gaGFwcGVu cyB3aGVuIHBvbGljeSBkb2VzIHBlcm1pdCBpdC4gIFRoYXTigJlzIGF0IHRoZSBjb3JlIG9mIHdo YXQgSSBzZWUgb3RoZXJzIGFza2luZyBmb3IuICBBbmQgSSBhZ3JlZSB3aXRob3V0IHRoYXQgT0dQ WCBpcyBmYXIgbGVzcyBpbnRlcmVzdGluZy4NCk1pa2UNCg== --_000_4646639E08F58B42836FAC24C94624DD6FE715D68AGVW0433EXBame_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9z ZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24x O30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQog IDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxp bms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbic+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+PGI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsN CmZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IG9ncHgtYm91bmNlc0BpZXRmLm9y Zw0KW21haWx0bzpvZ3B4LWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9z aHVhIEJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMjEsIDIwMDkgMTE6MTEg QU08YnI+DQo8Yj5Ubzo8L2I+IG9ncHhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtvZ3B4XSBPR1BYIFdHIGRyYWZ0IGNoYXJ0ZXIsIDIwMDktMDgtMTkgcmV2aXNpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOg0KMTIu MHB0O21hcmdpbi1sZWZ0Oi41aW4nPjxicj4NCjxicj4NCkhvdyBhYm91dCBhIHR3ZWFrOjxicj4N Cjxicj4NCjxzcGFuIHN0eWxlPSdiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxv dyc+UmVnaW9ucyBhbmQgU2VydmljZXMNCmltcGxlbWVudGVkIGFjY29yZGluZyB0byB0aGUgc3Bl Y2lmaWNhdGlvbnMgbWF5IGJlPGJyPg0KZGVwbG95ZWQgYnkgc2VwYXJhdGUgb3JnYW5pemF0aW9u IHdpdGggdmFyeWluZyBwb2xpY2llcyBhbmQgdHJ1c3QgZG9tYWlucy48YnI+DQpUaGUgT0dQWCBw cm90b2NvbHMgd2lsbCBwcm92aWRlIHRoZSBtZWNoYW5pc21zIGZvciB0aGVzZSB2aXJ0dWFsIHdv cmxkIDxicj4NCnNlcnZpY2VzIHRvIGludGVyb3BlcmF0ZSwgd2hlbiBwZXJtaXR0ZWQgYnkgcG9s aWN5IGFuZCBzaGFyZWQgdHJ1c3QgZG9tYWlucy48L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkkgbGlrZSB0aGlzIHNpbmNlIGl0IGRlZmluZXMg4oCcc2VydmljZXPigJ0NCmFzIHRob3Nl IHJlbGF0ZWQgdG8gVlcgaG9zdGluZy7CoCBJdCBhbHNvIHdpbGwgcmVxdWlyZSB0aGF0IHRoZSBw cm90b2NvbCBhZGRyZXNzDQpob3cgaW50ZXJvcGVyYXRpb24gaGFwcGVucyB3aGVuIHBvbGljeSBk b2VzIHBlcm1pdCBpdC7CoCBUaGF04oCZcyBhdCB0aGUgY29yZSBvZg0Kd2hhdCBJIHNlZSBvdGhl cnMgYXNraW5nIGZvci7CoCBBbmQgSSBhZ3JlZSB3aXRob3V0IHRoYXQgT0dQWCBpcyBmYXIgbGVz cw0KaW50ZXJlc3RpbmcuwqAgPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+TWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvYm9keT4NCg0KPC9o dG1sPg0K --_000_4646639E08F58B42836FAC24C94624DD6FE715D68AGVW0433EXBame_-- From infinity@lindenlab.com Fri Aug 21 09:40:23 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35C03A6B50 for ; Fri, 21 Aug 2009 09:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJK9qqc3fL0v for ; Fri, 21 Aug 2009 09:40:22 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 3A5893A698B for ; Fri, 21 Aug 2009 09:40:22 -0700 (PDT) Received: by pzk4 with SMTP id 4so100275pzk.29 for ; Fri, 21 Aug 2009 09:40:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.139.6 with SMTP id r6mr94336wfn.282.1250872826157; Fri, 21 Aug 2009 09:40:26 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD6FE715D68A@GVW0433EXB.americas.hpqcorp.net> References: <20090820235051.GA21280@alinoe.com> <20090820235657.GB21280@alinoe.com> <4646639E08F58B42836FAC24C94624DD6FE715D68A@GVW0433EXB.americas.hpqcorp.net> Date: Fri, 21 Aug 2009 09:40:26 -0700 Message-ID: <3a880e2c0908210940j65477f1fg15dc8321c219995b@mail.gmail.com> From: Infinity Linden To: "Dickson, Mike (ISS Software)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "ogpx@ietf.org" Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 16:40:23 -0000 that works too. the only nit i have is that "organization" should probably be plural. and, i would use the phrase "the protocol defined by this group" since that's what we use elsewhere in the draft. okay. so that was two nits. and, should Services be capitalized? okay. amongst the nits i have are ... so i think something like: "Regions and services implemented according to the specifications may be deployed by separate organizations with varying policies and trust domains. The protocol defined by this group will provide the mechanisms for these virtual world services to interoperate, when permitted by policy and shared trust domains." -cheers -meadhbh On Fri, Aug 21, 2009 at 9:17 AM, Dickson, Mike (ISS Software) wrote: > From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of > Joshua Bell > Sent: Friday, August 21, 2009 11:11 AM > To: ogpx@ietf.org > > Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision > > How about a tweak: > > Regions and Services implemented according to the specifications may be > deployed by separate organization with varying policies and trust domains= . > The OGPX protocols will provide the mechanisms for these virtual world > services to interoperate, when permitted by policy and shared trust domai= ns. > > I like this since it defines =93services=94 as those related to VW hostin= g.=A0 It > also will require that the protocol address how interoperation happens wh= en > policy does permit it.=A0 That=92s at the core of what I see others askin= g for. > And I agree without that OGPX is far less interesting. > > Mike > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From josh@lindenlab.com Fri Aug 21 10:26:37 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225ED3A6B28 for ; Fri, 21 Aug 2009 10:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.81 X-Spam-Level: X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJzEnT21L-Aw for ; Fri, 21 Aug 2009 10:26:36 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 6D1E73A6922 for ; Fri, 21 Aug 2009 10:26:36 -0700 (PDT) Received: by pzk4 with SMTP id 4so108867pzk.29 for ; Fri, 21 Aug 2009 10:26:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.5.35 with SMTP id 35mr81857wfe.69.1250875600265; Fri, 21 Aug 2009 10:26:40 -0700 (PDT) Date: Fri, 21 Aug 2009 10:26:40 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [ogpx] Proposal: Change OGPX to... X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 17:26:37 -0000 Hey gang, One of the charter issues we identified coming out of Stockholm was the name (for both the group and protocol suite). Open Grid Protocol (OGP)" is historical, used to describe interop trials from 2008, and the name was carried forward to the BoF/mailing list (with an "X" for good measure). Linden Lab employees, OpenSim developers and Second Life residents frequently use the term "grid" to describe the collection of systems responsible for providing virtual world services, even if that set of systems would more accurately be described by the terms "cluster" or "cloud" (or term-of-the-week...), playing off the grid-like organization of regions on a map. We received repeated feedback that "grid" was confusing, both on the list and at Stockholm, in the broader context of the IETF. This was underscored by at least one person who attended the OGPX BoF in Stockholm saying they anticipated hearing a discussion about grid and cloud computing services. A few alternatives to OGP have been offered, such as "Region Access Protocol (RAP)" and "Agent / Region Interaction Protocol (ARIP)". The former discounts the importance of the agent oriented aspects of the protocol, the latter discounts the "access" aspect of the protocol which underscores the RESTful nature of the conceptual objects on either end of a protocol transaction. >From off-list discussions, here are some new suggestions: * "Agent Based Open Virtual Environments (ABOVE)" - (as a group name?) * "Open Virtual Entity and Region (OVER)" - (as a protocol name?) These have the advantage of being concise, fairly accurate, pronounceable, keeping "Virtual" in the name, slightly "cute" but not overly so. They are not humorous or ironic and don't reference pop-culture. They don't overload "IP" (yay) and avoid "P" in the name (the dreaded "ATM machine" syndrome.) Taking these as serious suggestions, could we get rough consensus on either/both of these? Last call for objections/alternatives? (To maintain continuity of discussion, we should keep the OGPX mailing list and other trappings until an actual working group is chartered.) From dwl@us.ibm.com Fri Aug 21 10:44:42 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE3F3A6927; Fri, 21 Aug 2009 10:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.791 X-Spam-Level: X-Spam-Status: No, score=-5.791 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVcdrV5Jg7ax; Fri, 21 Aug 2009 10:44:41 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id DDDCB3A6DFD; Fri, 21 Aug 2009 10:44:14 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n7LHmIOl030293; Fri, 21 Aug 2009 13:48:18 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7LHiBsc217678; Fri, 21 Aug 2009 13:44:13 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7LHiBYu009533; Fri, 21 Aug 2009 13:44:11 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n7LHiBns009527; Fri, 21 Aug 2009 13:44:11 -0400 In-Reply-To: References: To: Joshua Bell MIME-Version: 1.0 X-KeepSent: 1FCFC812:440E05E4-85257619:0060ED39; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Fri, 21 Aug 2009 13:44:10 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_07072009|July 07, 2009) at 08/21/2009 13:44:11, Serialize complete at 08/21/2009 13:44:11 Content-Type: multipart/alternative; boundary="=_alternative 00616D3D85257619_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] Proposal: Change OGPX to... X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 17:44:43 -0000 This is a multipart message in MIME format. --=_alternative 00616D3D85257619_= Content-Type: text/plain; charset="US-ASCII" Comment below ogpx-bounces@ietf.org wrote on 08/21/2009 01:26:40 PM: > Joshua Bell > Sent by: ogpx-bounces@ietf.org > > 08/21/2009 01:26 PM > > To > > ogpx@ietf.org > > cc > > Subject > > [ogpx] Proposal: Change OGPX to... > > Hey gang, > > One of the charter issues we identified coming out of Stockholm was > the name (for both the group and protocol suite). Open Grid Protocol > (OGP)" is historical, used to describe interop trials from 2008, and > the name was carried forward to the BoF/mailing list (with an "X" for > good measure). Linden Lab employees, OpenSim developers and Second > Life residents frequently use the term "grid" to describe the > collection of systems responsible for providing virtual world > services, even if that set of systems would more accurately be > described by the terms "cluster" or "cloud" (or term-of-the-week...), > playing off the grid-like organization of regions on a map. > > We received repeated feedback that "grid" was confusing, both on the > list and at Stockholm, in the broader context of the IETF. This was > underscored by at least one person who attended the OGPX BoF in > Stockholm saying they anticipated hearing a discussion about grid and > cloud computing services. > > A few alternatives to OGP have been offered, such as "Region Access > Protocol (RAP)" and "Agent / Region Interaction Protocol (ARIP)". The > former discounts the importance of the agent oriented aspects of the > protocol, the latter discounts the "access" aspect of the protocol > which underscores the RESTful nature of the conceptual objects on > either end of a protocol transaction. > > From off-list discussions, here are some new suggestions: > > * "Agent Based Open Virtual Environments (ABOVE)" - (as a group name?) > * "Open Virtual Entity and Region (OVER)" - (as a protocol name?) > > These have the advantage of being concise, fairly accurate, > pronounceable, keeping "Virtual" in the name, slightly "cute" but not > overly so. They are not humorous or ironic and don't reference > pop-culture. They don't overload "IP" (yay) and avoid "P" in the name > (the dreaded "ATM machine" syndrome.) > > Taking these as serious suggestions, could we get rough consensus on > either/both of these? Last call for objections/alternatives? Above seems quite good. Over.. OVER.. well... I am dreading having to type: "When we run OVER over XMPP" I have shades of the movie Airplane. "Re: [ABOVE] Running OVER over HTTP under CentOs" That said, quite like Above, and could live with Over. Frankly at this point, I can live with almost any name, as long as it doesn't requires a special keyboard to type it. - David / Zha > > (To maintain continuity of discussion, we should keep the OGPX mailing > list and other trappings until an actual working group is chartered.) +1 > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 00616D3D85257619_= Content-Type: text/html; charset="US-ASCII"
Comment below

ogpx-bounces@ietf.org wrote on 08/21/2009 01:26:40 PM:

> Joshua Bell <josh@lindenlab.com>
> Sent by: ogpx-bounces@ietf.org
>
> 08/21/2009 01:26 PM
>
> To
>
> ogpx@ietf.org
>
> cc
>
> Subject
>
> [ogpx] Proposal: Change OGPX to...
>
> Hey gang,
>
> One of the charter issues we identified coming out of Stockholm was
> the name (for both the group and protocol suite). Open Grid Protocol
> (OGP)" is historical, used to describe interop trials from 2008, and
> the name was carried forward to the BoF/mailing list (with an "X" for
> good measure). Linden Lab employees, OpenSim developers and Second
> Life residents frequently use the term "grid" to describe the
> collection of systems responsible for providing virtual world
> services, even if that set of systems would more accurately be
> described by the terms "cluster" or "cloud" (or term-of-the-week...),
> playing off the grid-like organization of regions on a map.
>
> We received repeated feedback that "grid" was confusing, both on the
> list and at Stockholm, in the broader context of the IETF. This was
> underscored by at least one person who attended the OGPX BoF in
> Stockholm saying they anticipated hearing a discussion about grid and
> cloud computing services.
>
> A few alternatives to OGP have been offered, such as "Region Access
> Protocol (RAP)" and "Agent / Region Interaction Protocol (ARIP)". The
> former discounts the importance of the agent oriented aspects of the
> protocol, the latter discounts the "access" aspect of the protocol
> which underscores the RESTful nature of the conceptual objects on
> either end of a protocol transaction.
>
> From off-list discussions, here are some new suggestions:
>
> * "Agent Based Open Virtual Environments (ABOVE)" - (as a group name?)
> * "Open Virtual Entity and Region (OVER)" - (as a protocol name?)
>
> These have the advantage of being concise, fairly accurate,
> pronounceable, keeping "Virtual" in the name, slightly "cute" but not
> overly so. They are not humorous or ironic and don't reference
> pop-culture. They don't overload "IP" (yay) and avoid "P" in the name
> (the dreaded "ATM machine" syndrome.)
>
> Taking these as serious suggestions, could we get rough consensus on
> either/both of these? Last call for objections/alternatives?

Above seems quite good. Over.. OVER.. well... I am dreading having to type:

"When we run OVER over XMPP"

I have shades of the movie Airplane. "Re: [ABOVE] Running OVER over HTTP under CentOs"

That said,  quite like Above, and could live with Over. Frankly at this point, I can
live with almost any name, as long as it doesn't requires a special keyboard to type it.


- David / Zha


>
> (To maintain continuity of discussion, we should keep the OGPX mailing
> list and other trappings until an actual working group is chartered.)
+1

> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
 --=_alternative 00616D3D85257619_=-- From infinity@lindenlab.com Fri Aug 21 10:53:19 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBA0E3A6927; Fri, 21 Aug 2009 10:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB-Jq9v9NH+V; Fri, 21 Aug 2009 10:53:19 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 0334F3A6B5A; Fri, 21 Aug 2009 10:53:18 -0700 (PDT) Received: by pxi1 with SMTP id 1so4538169pxi.31 for ; Fri, 21 Aug 2009 10:53:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.8.3 with SMTP id 3mr96208wfh.72.1250877202723; Fri, 21 Aug 2009 10:53:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Aug 2009 10:53:22 -0700 Message-ID: <3a880e2c0908211053j3cd81ccq1fd0d519582d1a5@mail.gmail.com> From: Infinity Linden To: David W Levine Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] Proposal: Change OGPX to... X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 17:53:19 -0000 okay.. i'll actually not recommend "anta=C5=AD" as a replacement. but yeah, saying "OVER over HTTP" or "OVER over XMPP" might be a little confusing. and honestly, i like both OVER and ABOVE. i could live with either. maybe we could have ABOVE be both the group name and the protocol? -cheers -meadhbh On Fri, Aug 21, 2009 at 10:44 AM, David W Levine wrote: > > Comment below > > ogpx-bounces@ietf.org wrote on 08/21/2009 01:26:40 PM: > >> Joshua Bell >> Sent by: ogpx-bounces@ietf.org >> >> 08/21/2009 01:26 PM >> >> To >> >> ogpx@ietf.org >> >> cc >> >> Subject >> >> [ogpx] Proposal: Change OGPX to... >> >> Hey gang, >> >> One of the charter issues we identified coming out of Stockholm was >> the name (for both the group and protocol suite). Open Grid Protocol >> (OGP)" is historical, used to describe interop trials from 2008, and >> the name was carried forward to the BoF/mailing list (with an "X" for >> good measure). Linden Lab employees, OpenSim developers and Second >> Life residents frequently use the term "grid" to describe the >> collection of systems responsible for providing virtual world >> services, even if that set of systems would more accurately be >> described by the terms "cluster" or "cloud" (or term-of-the-week...), >> playing off the grid-like organization of regions on a map. >> >> We received repeated feedback that "grid" was confusing, both on the >> list and at Stockholm, in the broader context of the IETF. This was >> underscored by at least one person who attended the OGPX BoF in >> Stockholm saying they anticipated hearing a discussion about grid and >> cloud computing services. >> >> A few alternatives to OGP have been offered, such as "Region Access >> Protocol (RAP)" and "Agent / Region Interaction Protocol (ARIP)". The >> former discounts the importance of the agent oriented aspects of the >> protocol, the latter discounts the "access" aspect of the protocol >> which underscores the RESTful nature of the conceptual objects on >> either end of a protocol transaction. >> >> From off-list discussions, here are some new suggestions: >> >> * "Agent Based Open Virtual Environments (ABOVE)" - (as a group name?) >> * "Open Virtual Entity and Region (OVER)" - (as a protocol name?) >> >> These have the advantage of being concise, fairly accurate, >> pronounceable, keeping "Virtual" in the name, slightly "cute" but not >> overly so. They are not humorous or ironic and don't reference >> pop-culture. They don't overload "IP" (yay) and avoid "P" in the name >> (the dreaded "ATM machine" syndrome.) >> >> Taking these as serious suggestions, could we get rough consensus on >> either/both of these? Last call for objections/alternatives? > > Above seems quite good. Over.. OVER.. well... I am dreading having to typ= e: > > "When we run OVER over XMPP" > > I have shades of the movie Airplane. "Re: [ABOVE] Running OVER over HTTP > under CentOs" > > That said, =C2=A0quite like Above, and could live with Over. Frankly at t= his > point, I can > live with almost any name, as long as it doesn't requires a special keybo= ard > to type it. > > > - David / Zha > > >> >> (To maintain continuity of discussion, we should keep the OGPX mailing >> list and other trappings until an actual working group is chartered.) > +1 > >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From mike.dickson@hp.com Fri Aug 21 10:58:29 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2444D28C1F8 for ; Fri, 21 Aug 2009 10:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpKulHMTrpNC for ; Fri, 21 Aug 2009 10:58:28 -0700 (PDT) Received: from g5t0008.atlanta.hp.com (g5t0008.atlanta.hp.com [15.192.0.45]) by core3.amsl.com (Postfix) with ESMTP id 2CFC23A6B5A for ; Fri, 21 Aug 2009 10:58:28 -0700 (PDT) Received: from G6W0640.americas.hpqcorp.net (g6w0640.atlanta.hp.com [16.230.34.76]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0008.atlanta.hp.com (Postfix) with ESMTPS id 69E1624270; Fri, 21 Aug 2009 17:58:33 +0000 (UTC) Received: from G4W1853.americas.hpqcorp.net (16.234.97.231) by G6W0640.americas.hpqcorp.net (16.230.34.76) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 21 Aug 2009 17:57:50 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.147]) by G4W1853.americas.hpqcorp.net ([16.234.97.231]) with mapi; Fri, 21 Aug 2009 17:57:49 +0000 From: "Dickson, Mike (ISS Software)" To: Joshua Bell , "ogpx@ietf.org" Date: Fri, 21 Aug 2009 17:56:50 +0000 Thread-Topic: [ogpx] Proposal: Change OGPX to... Thread-Index: AcoihI7Fh44hWPAlTmG9nH7vsfSjswABCgFQ Message-ID: <4646639E08F58B42836FAC24C94624DD6FE715D7A9@GVW0433EXB.americas.hpqcorp.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ogpx] Proposal: Change OGPX to... X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 17:58:29 -0000 How about VWGP. "Virtual World Grid Protocol". Mike -----Original Message----- From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of Jos= hua Bell Sent: Friday, August 21, 2009 12:27 PM To: ogpx@ietf.org Subject: [ogpx] Proposal: Change OGPX to... Hey gang, One of the charter issues we identified coming out of Stockholm was the name (for both the group and protocol suite). Open Grid Protocol (OGP)" is historical, used to describe interop trials from 2008, and the name was carried forward to the BoF/mailing list (with an "X" for good measure). Linden Lab employees, OpenSim developers and Second Life residents frequently use the term "grid" to describe the collection of systems responsible for providing virtual world services, even if that set of systems would more accurately be described by the terms "cluster" or "cloud" (or term-of-the-week...), playing off the grid-like organization of regions on a map. We received repeated feedback that "grid" was confusing, both on the list and at Stockholm, in the broader context of the IETF. This was underscored by at least one person who attended the OGPX BoF in Stockholm saying they anticipated hearing a discussion about grid and cloud computing services. A few alternatives to OGP have been offered, such as "Region Access Protocol (RAP)" and "Agent / Region Interaction Protocol (ARIP)". The former discounts the importance of the agent oriented aspects of the protocol, the latter discounts the "access" aspect of the protocol which underscores the RESTful nature of the conceptual objects on either end of a protocol transaction. >From off-list discussions, here are some new suggestions: * "Agent Based Open Virtual Environments (ABOVE)" - (as a group name?) * "Open Virtual Entity and Region (OVER)" - (as a protocol name?) These have the advantage of being concise, fairly accurate, pronounceable, keeping "Virtual" in the name, slightly "cute" but not overly so. They are not humorous or ironic and don't reference pop-culture. They don't overload "IP" (yay) and avoid "P" in the name (the dreaded "ATM machine" syndrome.) Taking these as serious suggestions, could we get rough consensus on either/both of these? Last call for objections/alternatives? (To maintain continuity of discussion, we should keep the OGPX mailing list and other trappings until an actual working group is chartered.) _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx From infinity@lindenlab.com Fri Aug 21 11:09:54 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97413A6DB4 for ; Fri, 21 Aug 2009 11:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1AAFfNphKXN for ; Fri, 21 Aug 2009 11:09:54 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id D023C3A6C19 for ; Fri, 21 Aug 2009 11:09:05 -0700 (PDT) Received: by pzk4 with SMTP id 4so116640pzk.29 for ; Fri, 21 Aug 2009 11:09:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.20.37 with SMTP id x37mr73809wfi.208.1250878148776; Fri, 21 Aug 2009 11:09:08 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD6FE715D7A9@GVW0433EXB.americas.hpqcorp.net> References: <4646639E08F58B42836FAC24C94624DD6FE715D7A9@GVW0433EXB.americas.hpqcorp.net> Date: Fri, 21 Aug 2009 11:09:08 -0700 Message-ID: <3a880e2c0908211109o3fa668e6h27a803a97353074c@mail.gmail.com> From: Infinity Linden To: "Dickson, Mike (ISS Software)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ogpx@ietf.org" Subject: Re: [ogpx] Proposal: Change OGPX to... X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 18:09:54 -0000 'cause we're trying to avoid the word "grid." before the F2F in stockholm, i was one of the most vocal proponents for keeping OGP. we had a fair amount of history with the name, and i thought it made sense to keep the name to avoid the confusion a new name would bring. right before the BoF, i remember Dave Crocker (and maybe others) saying something like "you know... some people are going to think this is not a virtual worlds protocol, but one for provisioning services and managing a grid or cloud." my response was (and i'm paraphrasing here,) "nonsense! everyone reads every word of every working group charter and knows what every other group is working on!" immediately after the BoF, someone came up and said.. "yeah. that was an interesting BoF, but i thought it would be a discussion of managing grids, you know, regular grids." so. yes. i have eaten a bit of crow and am now a convert to the idea that the term "grid" in the group or protocol name is confusing since the protocol we're defining could work on a grid, a cloud, a cluster or even a single host (for a small virtual world.) -cheers -meadhbh On Fri, Aug 21, 2009 at 10:56 AM, Dickson, Mike (ISS Software) wrote: > How about VWGP. =A0"Virtual World Grid Protocol". > > Mike > > -----Original Message----- > From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of J= oshua Bell > Sent: Friday, August 21, 2009 12:27 PM > To: ogpx@ietf.org > Subject: [ogpx] Proposal: Change OGPX to... > > Hey gang, > > One of the charter issues we identified coming out of Stockholm was > the name (for both the group and protocol suite). Open Grid Protocol > (OGP)" is historical, used to describe interop trials from 2008, and > the name was carried forward to the BoF/mailing list (with an "X" for > good measure). Linden Lab employees, OpenSim developers and Second > Life residents frequently use the term "grid" to describe the > collection of systems responsible for providing virtual world > services, even if that set of systems would more accurately be > described by the terms "cluster" or "cloud" (or term-of-the-week...), > playing off the grid-like organization of regions on a map. > > We received repeated feedback that "grid" was confusing, both on the > list and at Stockholm, in the broader context of the IETF. This was > underscored by at least one person who attended the OGPX BoF in > Stockholm saying they anticipated hearing a discussion about grid and > cloud computing services. > > A few alternatives to OGP have been offered, such as "Region Access > Protocol (RAP)" and "Agent / Region Interaction Protocol (ARIP)". The > former discounts the importance of the agent oriented aspects of the > protocol, the latter discounts the "access" aspect of the protocol > which underscores the RESTful nature of the conceptual objects on > either end of a protocol transaction. > > From off-list discussions, here are some new suggestions: > > * "Agent Based Open Virtual Environments (ABOVE)" - (as a group name?) > * "Open Virtual Entity and Region (OVER)" - (as a protocol name?) > > These have the advantage of being concise, fairly accurate, > pronounceable, keeping "Virtual" in the name, slightly "cute" but not > overly so. They are not humorous or ironic and don't reference > pop-culture. They don't overload "IP" (yay) and avoid "P" in the name > (the dreaded "ATM machine" syndrome.) > > Taking these as serious suggestions, could we get rough consensus on > either/both of these? Last call for objections/alternatives? > > (To maintain continuity of discussion, we should keep the OGPX mailing > list and other trappings until an actual working group is chartered.) > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From mike.dickson@hp.com Fri Aug 21 11:13:34 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7733A6A56 for ; Fri, 21 Aug 2009 11:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJEceJ4p1zfs for ; Fri, 21 Aug 2009 11:13:33 -0700 (PDT) Received: from g4t0016.houston.hp.com (g4t0016.houston.hp.com [15.201.24.19]) by core3.amsl.com (Postfix) with ESMTP id C30EF3A6845 for ; Fri, 21 Aug 2009 11:13:33 -0700 (PDT) Received: from G6W0641.americas.hpqcorp.net (g6w0641.atlanta.hp.com [16.230.34.77]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0016.houston.hp.com (Postfix) with ESMTPS id 2DA8A145B0; Fri, 21 Aug 2009 18:13:39 +0000 (UTC) Received: from G3W0629.americas.hpqcorp.net (16.233.58.78) by G6W0641.americas.hpqcorp.net (16.230.34.77) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 21 Aug 2009 18:13:11 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.147]) by G3W0629.americas.hpqcorp.net ([16.233.58.78]) with mapi; Fri, 21 Aug 2009 18:13:10 +0000 From: "Dickson, Mike (ISS Software)" To: Infinity Linden Date: Fri, 21 Aug 2009 18:12:12 +0000 Thread-Topic: [ogpx] Proposal: Change OGPX to... Thread-Index: Acoiinr7RvG1sF8bRaqLSmn25rcLDQAAAXWQ Message-ID: <4646639E08F58B42836FAC24C94624DD6FE715D7D0@GVW0433EXB.americas.hpqcorp.net> References: <4646639E08F58B42836FAC24C94624DD6FE715D7A9@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0908211109o3fa668e6h27a803a97353074c@mail.gmail.com> In-Reply-To: <3a880e2c0908211109o3fa668e6h27a803a97353074c@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ogpx@ietf.org" Subject: Re: [ogpx] Proposal: Change OGPX to... X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 18:13:34 -0000 Well, that's why I qualified it with the VW first. :-) So I actually think the grid part *is* appropriate since SL and the worlds = being modeled are laid out in one. As opposed say to Activeworlds or Croque= t which are more portal based. So I understand wanting to avoid the confusion with the general grid term b= ut in this case I actually think Grid is important. OGP is confusing since= its not descriptive enough. I was hoping with the VWGP thingy you're esse= ntially describing exactly what it is. A virtual world protocol for worlds = laid out in a grid. Mike -----Original Message----- From: Infinity Linden [mailto:infinity@lindenlab.com]=20 Sent: Friday, August 21, 2009 1:09 PM To: Dickson, Mike (ISS Software) Cc: Joshua Bell; ogpx@ietf.org Subject: Re: [ogpx] Proposal: Change OGPX to... 'cause we're trying to avoid the word "grid." before the F2F in stockholm, i was one of the most vocal proponents for keeping OGP. we had a fair amount of history with the name, and i thought it made sense to keep the name to avoid the confusion a new name would bring. right before the BoF, i remember Dave Crocker (and maybe others) saying something like "you know... some people are going to think this is not a virtual worlds protocol, but one for provisioning services and managing a grid or cloud." my response was (and i'm paraphrasing here,) "nonsense! everyone reads every word of every working group charter and knows what every other group is working on!" immediately after the BoF, someone came up and said.. "yeah. that was an interesting BoF, but i thought it would be a discussion of managing grids, you know, regular grids." so. yes. i have eaten a bit of crow and am now a convert to the idea that the term "grid" in the group or protocol name is confusing since the protocol we're defining could work on a grid, a cloud, a cluster or even a single host (for a small virtual world.) -cheers -meadhbh On Fri, Aug 21, 2009 at 10:56 AM, Dickson, Mike (ISS Software) wrote: > How about VWGP. =A0"Virtual World Grid Protocol". > > Mike > > -----Original Message----- > From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of J= oshua Bell > Sent: Friday, August 21, 2009 12:27 PM > To: ogpx@ietf.org > Subject: [ogpx] Proposal: Change OGPX to... > > Hey gang, > > One of the charter issues we identified coming out of Stockholm was > the name (for both the group and protocol suite). Open Grid Protocol > (OGP)" is historical, used to describe interop trials from 2008, and > the name was carried forward to the BoF/mailing list (with an "X" for > good measure). Linden Lab employees, OpenSim developers and Second > Life residents frequently use the term "grid" to describe the > collection of systems responsible for providing virtual world > services, even if that set of systems would more accurately be > described by the terms "cluster" or "cloud" (or term-of-the-week...), > playing off the grid-like organization of regions on a map. > > We received repeated feedback that "grid" was confusing, both on the > list and at Stockholm, in the broader context of the IETF. This was > underscored by at least one person who attended the OGPX BoF in > Stockholm saying they anticipated hearing a discussion about grid and > cloud computing services. > > A few alternatives to OGP have been offered, such as "Region Access > Protocol (RAP)" and "Agent / Region Interaction Protocol (ARIP)". The > former discounts the importance of the agent oriented aspects of the > protocol, the latter discounts the "access" aspect of the protocol > which underscores the RESTful nature of the conceptual objects on > either end of a protocol transaction. > > From off-list discussions, here are some new suggestions: > > * "Agent Based Open Virtual Environments (ABOVE)" - (as a group name?) > * "Open Virtual Entity and Region (OVER)" - (as a protocol name?) > > These have the advantage of being concise, fairly accurate, > pronounceable, keeping "Virtual" in the name, slightly "cute" but not > overly so. They are not humorous or ironic and don't reference > pop-culture. They don't overload "IP" (yay) and avoid "P" in the name > (the dreaded "ATM machine" syndrome.) > > Taking these as serious suggestions, could we get rough consensus on > either/both of these? Last call for objections/alternatives? > > (To maintain continuity of discussion, we should keep the OGPX mailing > list and other trappings until an actual working group is chartered.) > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From infinity@lindenlab.com Fri Aug 21 11:23:50 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B035F3A6E1B for ; Fri, 21 Aug 2009 11:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok2IwcJtVcgB for ; Fri, 21 Aug 2009 11:23:49 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 9A7FD3A6E09 for ; Fri, 21 Aug 2009 11:23:49 -0700 (PDT) Received: by pzk4 with SMTP id 4so119260pzk.29 for ; Fri, 21 Aug 2009 11:23:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.4.38 with SMTP id 38mr102336wfd.119.1250879032063; Fri, 21 Aug 2009 11:23:52 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD6FE715D7D0@GVW0433EXB.americas.hpqcorp.net> References: <4646639E08F58B42836FAC24C94624DD6FE715D7A9@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0908211109o3fa668e6h27a803a97353074c@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD6FE715D7D0@GVW0433EXB.americas.hpqcorp.net> Date: Fri, 21 Aug 2009 11:23:52 -0700 Message-ID: <3a880e2c0908211123j52ba49aar547f4d224190eeef@mail.gmail.com> From: Infinity Linden To: "Dickson, Mike (ISS Software)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ogpx@ietf.org" Subject: Re: [ogpx] Proposal: Change OGPX to... X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 18:23:50 -0000 well.. fwiw... we're not baking the "grid" concept into this protocol. it's appropriate for worlds that are grids, toroids, spheres, cylinders or defined by a tensor field. the only requirement is that the worlds use a 3 dimensional vector to denote locations in the world and that the world is piecewise smooth. but yes. in non-grid cases, both the client and the server would have to agree a priori what the shape of the world is, and all the current participants are only defining grid-based worlds. so your point is definitely valid. at this point i don't know that i care what the name is as long as we can reach consensus and the name isn't confusing. On Fri, Aug 21, 2009 at 11:12 AM, Dickson, Mike (ISS Software) wrote: > Well, that's why I qualified it with the VW first. =A0 :-) > > So I actually think the grid part *is* appropriate since SL and the world= s being modeled are laid out in one. As opposed say to Activeworlds or Croq= uet which are more portal based. > > So I understand wanting to avoid the confusion with the general grid term= but in this case I actually think Grid is important. =A0OGP is confusing s= ince its not descriptive enough. =A0I was hoping with the VWGP thingy you'r= e essentially describing exactly what it is. A virtual world protocol for w= orlds laid out in a grid. > > Mike > > -----Original Message----- > From: Infinity Linden [mailto:infinity@lindenlab.com] > Sent: Friday, August 21, 2009 1:09 PM > To: Dickson, Mike (ISS Software) > Cc: Joshua Bell; ogpx@ietf.org > Subject: Re: [ogpx] Proposal: Change OGPX to... > > 'cause we're trying to avoid the word "grid." > > before the F2F in stockholm, i was one of the most vocal proponents > for keeping OGP. we had a fair amount of history with the name, and i > thought it made sense to keep the name to avoid the confusion a new > name would bring. > > right before the BoF, i remember Dave Crocker (and maybe others) > saying something like "you know... some people are going to think this > is not a virtual worlds protocol, but one for provisioning services > and managing a grid or cloud." > > my response was (and i'm paraphrasing here,) "nonsense! everyone reads > every word of every working group charter and knows what every other > group is working on!" > > immediately after the BoF, someone came up and said.. "yeah. that was > an interesting BoF, but i thought it would be a discussion of managing > grids, you know, regular grids." > > so. yes. i have eaten a bit of crow and am now a convert to the idea > that the term "grid" in the group or protocol name is confusing since > the protocol we're defining could work on a grid, a cloud, a cluster > or even a single host (for a small virtual world.) > > -cheers > -meadhbh > > On Fri, Aug 21, 2009 at 10:56 AM, Dickson, Mike (ISS > Software) wrote: >> How about VWGP. =A0"Virtual World Grid Protocol". >> >> Mike >> >> -----Original Message----- >> From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of = Joshua Bell >> Sent: Friday, August 21, 2009 12:27 PM >> To: ogpx@ietf.org >> Subject: [ogpx] Proposal: Change OGPX to... >> >> Hey gang, >> >> One of the charter issues we identified coming out of Stockholm was >> the name (for both the group and protocol suite). Open Grid Protocol >> (OGP)" is historical, used to describe interop trials from 2008, and >> the name was carried forward to the BoF/mailing list (with an "X" for >> good measure). Linden Lab employees, OpenSim developers and Second >> Life residents frequently use the term "grid" to describe the >> collection of systems responsible for providing virtual world >> services, even if that set of systems would more accurately be >> described by the terms "cluster" or "cloud" (or term-of-the-week...), >> playing off the grid-like organization of regions on a map. >> >> We received repeated feedback that "grid" was confusing, both on the >> list and at Stockholm, in the broader context of the IETF. This was >> underscored by at least one person who attended the OGPX BoF in >> Stockholm saying they anticipated hearing a discussion about grid and >> cloud computing services. >> >> A few alternatives to OGP have been offered, such as "Region Access >> Protocol (RAP)" and "Agent / Region Interaction Protocol (ARIP)". The >> former discounts the importance of the agent oriented aspects of the >> protocol, the latter discounts the "access" aspect of the protocol >> which underscores the RESTful nature of the conceptual objects on >> either end of a protocol transaction. >> >> From off-list discussions, here are some new suggestions: >> >> * "Agent Based Open Virtual Environments (ABOVE)" - (as a group name?) >> * "Open Virtual Entity and Region (OVER)" - (as a protocol name?) >> >> These have the advantage of being concise, fairly accurate, >> pronounceable, keeping "Virtual" in the name, slightly "cute" but not >> overly so. They are not humorous or ironic and don't reference >> pop-culture. They don't overload "IP" (yay) and avoid "P" in the name >> (the dreaded "ATM machine" syndrome.) >> >> Taking these as serious suggestions, could we get rough consensus on >> either/both of these? Last call for objections/alternatives? >> >> (To maintain continuity of discussion, we should keep the OGPX mailing >> list and other trappings until an actual working group is chartered.) >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > From infinity@lindenlab.com Fri Aug 21 11:29:38 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 580553A6AE0 for ; Fri, 21 Aug 2009 11:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTaT-zU5kA8x for ; Fri, 21 Aug 2009 11:29:37 -0700 (PDT) Received: from mail-px0-f175.google.com (mail-px0-f175.google.com [209.85.216.175]) by core3.amsl.com (Postfix) with ESMTP id 538663A6B92 for ; Fri, 21 Aug 2009 11:29:37 -0700 (PDT) Received: by pxi5 with SMTP id 5so4309572pxi.6 for ; Fri, 21 Aug 2009 11:29:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.9.31 with SMTP id 31mr92386wfi.96.1250879381155; Fri, 21 Aug 2009 11:29:41 -0700 (PDT) Date: Fri, 21 Aug 2009 11:29:41 -0700 Message-ID: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2009 18:29:38 -0000 it seems to me we're in the enviable position of having several good name suggestions: ARAP, VWIP, OVER, ABOVE and VWGP. We also have the historical name OGP. would it make sense to go around asking people to rank their name preferences and do Single Transferrable Vote (STV) to find the first, second and third most popular choices? -cheers -meadhbh From carlo@alinoe.com Fri Aug 21 18:02:42 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D1D3A6BA0 for ; Fri, 21 Aug 2009 18:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRjnQtdS3Rnk for ; Fri, 21 Aug 2009 18:02:41 -0700 (PDT) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id 039E33A6B50 for ; Fri, 21 Aug 2009 18:02:40 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep17-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090822010244.RAJA15272.viefep17-int.chello.at@edge05.upc.biz>; Sat, 22 Aug 2009 03:02:44 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id XD2g1c0310FlQed05D2iuZ; Sat, 22 Aug 2009 03:02:44 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mef0z-0007tH-LF; Sat, 22 Aug 2009 03:03:29 +0200 Date: Sat, 22 Aug 2009 03:03:29 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20090822010329.GA29557@alinoe.com> References: <20090820235051.GA21280@alinoe.com> <20090820235657.GB21280@alinoe.com> <4646639E08F58B42836FAC24C94624DD6FE715D68A@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0908210940j65477f1fg15dc8321c219995b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a880e2c0908210940j65477f1fg15dc8321c219995b@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "ogpx@ietf.org" Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 01:02:42 -0000 On Fri, Aug 21, 2009 at 09:40:26AM -0700, Infinity Linden wrote: > "Regions and services implemented according to the specifications may > be deployed by separate organizations with varying policies and trust > domains. The protocol defined by this group will provide the > mechanisms for these virtual world services to interoperate, when > permitted by policy and shared trust domains." Great! This clarifies a lot about the intent of the protocol to me, which should say something about the value of adding this paragraph! ;) -- Carlo Wood From carlo@alinoe.com Fri Aug 21 18:25:02 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86333A6845 for ; Fri, 21 Aug 2009 18:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL2hKxLIgVqz for ; Fri, 21 Aug 2009 18:25:02 -0700 (PDT) Received: from viefep12-int.chello.at (viefep12-int.chello.at [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id 883473A69B5 for ; Fri, 21 Aug 2009 18:25:01 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep12-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090822012449.DJDJ6129.viefep12-int.chello.at@edge05.upc.biz>; Sat, 22 Aug 2009 03:24:49 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id XDQm1c04C0FlQed05DQoi1; Sat, 22 Aug 2009 03:24:49 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MefMO-0008Ae-4j; Sat, 22 Aug 2009 03:25:36 +0200 Date: Sat, 22 Aug 2009 03:25:36 +0200 From: Carlo Wood To: Joshua Bell Message-ID: <20090822012536.GB29557@alinoe.com> References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> <20090820235051.GA21280@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 01:25:02 -0000 On Thu, Aug 20, 2009 at 05:12:20PM -0700, Joshua Bell wrote: > I disagree with that. As a corporation providing tools to my employees, I may > dictate policy about where my employees may go using those tools - e.g. they > may teleport to and bring inventory with corporate content to partner company > worlds where the companies have signed NDAs, to have meetings to discuss shared > interests. It is entirely a matter of policy. This is no different than having > corporate firewalls that block access to certain sites or content. > > That may not be the primary use case (again, see the Web) but we can't discard > it. You're right. I wrote a long story with what I really meant (but formulated wrongly)... and deleted it again :p -- Carlo Wood From carlo@alinoe.com Fri Aug 21 19:12:35 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717DD3A69F0 for ; Fri, 21 Aug 2009 19:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYRa2eYaykYJ for ; Fri, 21 Aug 2009 19:12:34 -0700 (PDT) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id 09F163A69BD for ; Fri, 21 Aug 2009 19:12:33 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090822021237.KFKR21098.viefep19-int.chello.at@edge05.upc.biz>; Sat, 22 Aug 2009 04:12:37 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id XECa1c02X0FlQed05ECbUf; Sat, 22 Aug 2009 04:12:37 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Meg6d-0000Gb-H2; Sat, 22 Aug 2009 04:13:23 +0200 Date: Sat, 22 Aug 2009 04:13:23 +0200 From: Carlo Wood To: Meadhbh Siobhan Message-ID: <20090822021323.GC29557@alinoe.com> References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> <20090820235051.GA21280@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 02:12:35 -0000 On Thu, Aug 20, 2009 at 05:16:09PM -0700, Meadhbh Siobhan wrote: [deleted what I agree with, or just needs no comment] > one of the objectives of the OGP protocol is to allow a virtual world > to be constructed from regions, agent hosts and asset servers from > different administrative domains. in order to do that, one of the Okaaayy... now you're using "a virtual world" again for a collection of regions run by *different* administrations, while I was proposing to keep the fact that currently all different (Second Life like) worlds are run by different administrations. But... I'm not in a hurry to have the meaning of "world" clearly defined, the only thing that is important for me is the intent of the people on this mailinglist and those working for Linden Lab in particular ;) > things we think we need to do is to have a scheme by which regions are > unambiguously identified with a URL. we don't currently list > "unambiguous landmarks" in the charter because we don't talk about > landmarks at all in the charter. it's also unclear whether a landmark > format will be defined as part of this effort. Okay. Note that I only talked about landmarks as example with as goal to get clarity between us, here and now; followed by a search for correct wording of paragraphs. I never thought that "landmark" had to be added to the charter in said paragraphs. > so i guess what i'm saying is that if we listed "a format for > unambiguous landmarks" in the charter, shouldn't we also list other > Second-Life-like features like the C/M/T permissions system? the > unambiguous URL representing a region is required for proper operation > of teleport, which IS in scope, but the unambiguous landmark format is > not required as landmarks are concepts more appropriately manipulated > by client applications. I don't think that even unambiguous URL needs to be mentioned. > so, is it enough to add verbiage to the charter indicating that the > protocol requires regions to be addressable by unambiguous URLs, but > not explicitly constrain their use in the charter? Again, it was just a down-to-earth example, not suitable for the charter. The problem that we're trying to tackle, that I was trying to tackle, is this (going to formulate this VERY explicit, almost embarrashingly so ;). There are people on this list that run (currently) small grids with (obviously) opensim servers. They would very much like it to be possible for people in SL to teleport directly to their grid (and back), preferably (but not necessarily) while keeping access to their inventory and keeping there appearance intact. The reason they want that is simply: the more seamless that is possible, the more people will come; and more people is Good(tm). The likeliness that this is going to happen for them in the future depends mainly on two things: 1) Will the protocol support it at all 2) Will Linden Lab grant those grids whatever access they need Point 2 is policy, and has nothing to do with the efforts of this group. It is my understanding that Morgaine after reading the charter lost all hope to achieve this goal of interoperability, and concluded that with the given formulation (as proposed by you) *apparently* Linden Lab wasn't interested the slightest to have this kind of interoperability with any of the current opensim pioneers; which led to some emotions and rather direct attempt to let you "confess" that LL wasn't interested, and when you said "that doesn't belong in the charter" that was interpreted as "we have a hidden agenda". At this point I believe that all of that has been a misunderstanding, that is directly caused by the confusion that exists about what "virtual world" means. Morgaine (and me) interpreted "world" as "run by a different administration", while you seem use the word for "all regions that one can teleport to". Obviously, the latter says NOTHING about the intent of Linden Lab to interoperate with any opensim grids :p, and I suppose you don't have to tell us if they do. But it's good to know now that the protocol will support this. We're not there yet though: The reason that two grids (or virtual worlds, or different administrations) might decide not to allow teleporting is probably for a large part going to be determined by (not) trusting. Therefore, in order to achieve the goal of teleporting between Second Life and the smaller opensim grids, we'd like a protocol that demands as LITTLE trust as possible. For example, if the protocol would define something like: - in order to teleport, grid A logs into auth services of grid B once and then has access the everything after that (including allowing to teleport); then teleporting would be impossible unless grid B would trust grid A completely. Other shemes are thinkable that require less trust. One result of a "hidden agenda" could be that the protocol would be designed such that ANY operability would only be possible with FULL access to everything, and therefore full trust, and therefore (in practise) no interoperability at all (except between large companies with lawyers and contracts-- not the little pioneers that run opensim grids now). -- Carlo Wood From carlo@alinoe.com Fri Aug 21 19:55:51 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2CC33A682B for ; Fri, 21 Aug 2009 19:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38laq2y-h0r4 for ; Fri, 21 Aug 2009 19:55:51 -0700 (PDT) Received: from viefep12-int.chello.at (viefep12-int.chello.at [62.179.121.32]) by core3.amsl.com (Postfix) with ESMTP id 769A63A67A8 for ; Fri, 21 Aug 2009 19:55:50 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep12-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090822025554.EUYL6129.viefep12-int.chello.at@edge05.upc.biz> for ; Sat, 22 Aug 2009 04:55:54 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id XEvr1c02p0FlQed05Evs6Y; Sat, 22 Aug 2009 04:55:54 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MegmX-0000o0-10 for ogpx@ietf.org; Sat, 22 Aug 2009 04:56:41 +0200 Date: Sat, 22 Aug 2009 04:56:41 +0200 From: Carlo Wood To: ogpx@ietf.org Message-ID: <20090822025641.GD29557@alinoe.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 02:55:51 -0000 On Fri, Aug 21, 2009 at 11:29:41AM -0700, Infinity Linden wrote: > it seems to me we're in the enviable position of having several good > name suggestions: ARAP, VWIP, OVER, ABOVE and VWGP. We also have the > historical name OGP. VWRAP, pronounced as V-wrap. (Virtual World Region/Agent Protocol) From morgaine.dinova@googlemail.com Fri Aug 21 20:22:59 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21FB53A682B for ; Fri, 21 Aug 2009 20:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjbNQeWIhUu1 for ; Fri, 21 Aug 2009 20:22:58 -0700 (PDT) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by core3.amsl.com (Postfix) with ESMTP id 92A493A68EF for ; Fri, 21 Aug 2009 20:22:57 -0700 (PDT) Received: by ewy2 with SMTP id 2so1263294ewy.43 for ; Fri, 21 Aug 2009 20:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=o07u5RXojPkxrr/5RKnk3HsTYTjDOgrVJrBxAmeSHZc=; b=KU8Ad6RZOci/lRC9dBuAr0KLYUmpkx1G0emAmSRwUOlJI4KTDFGbJ51QdTUnjdrl+x +S4A4Ow1PvtbfylC3U78rPpT79OIYPIMxBtHzbxsGwIn14XgYv5SrLeFqIUaTu69NbJw GbF701dnA/eojEG1xLHeD6h3Iel1zImP1fXbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=M81zeIwB3aIZ9/kCim2fSRaVOlr303Ul9xeA2J/Qbyg5VgluZxLkC/L+du2S5EyiYb GDcR2MZOKGjfZszImbuxf59nkojPWRQ85AwmaKZ9vDu3dtce1XIA9JSSRNT/YfYwNc/H 6KWncYF77EF7tiTHBPMxPg3A9wfnCm0yoCppQ= MIME-Version: 1.0 Received: by 10.210.10.4 with SMTP id 4mr2313434ebj.36.1250911376918; Fri, 21 Aug 2009 20:22:56 -0700 (PDT) In-Reply-To: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> Date: Sat, 22 Aug 2009 04:22:56 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174be0544449020471b280ba Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 03:22:59 -0000 --0015174be0544449020471b280ba Content-Type: text/plain; charset=ISO-8859-1 As a general rule, I would recommend *against* using common words such as ABOVE or OVER for the name of the group or protocol, for several reasons: - Not everyone will capitalize ABOVE or OVER when using them in this technical context, so ambiguities will arise in common usage outside of this group. - Discussions about the protocol *held in voice* will incur vocal ambiguity with the corresponding English words, and of course capitalization is not possible in this medium. - Sometimes the words "above" or "over" in their normal English meaning will get CAPITALIZED FOR EMPHASIS, adding yet more confusion to the mix. - New names like SMTP or HTTP extend natural language easily through popular use, but overloaded terms create conflict rather than smooth language extension. - ABOVE or OVER may be cute constructions, but cuteness doesn't help anyone. - But the biggest reason for avoiding common words is given by Google, since the resulting poor quality of search results will benefit neither the workgroup nor the eventual readers of our specifications. I have no particular preferences for the name, apart from the above advice. However, here are some partial phrases that might generate some more ideas: - Virtual Spaces Organization and Access -- avoids "Virtual Worlds" - Region Interoperation Services -- it's what the protocol targets strongly - Virtual Services Interoperation -- alludes to Zha's reformulation - Virtual World Services Protocol -- works well despite "ATM syndrome" - Virtual World State Representation System -- alludes to REST As others have recommended as well, topological terms like "grid" don't really help and may create confusion, so should be discouraged. In contrast, it would be worth encouraging use of a name that references some unique element of this particular proposal, such as Regions, or maybe State Transfer. Morgaine. On Fri, Aug 21, 2009 at 7:29 PM, Infinity Linden wrote: > it seems to me we're in the enviable position of having several good > name suggestions: ARAP, VWIP, OVER, ABOVE and VWGP. We also have the > historical name OGP. > > would it make sense to go around asking people to rank their name > preferences and do Single Transferrable Vote (STV) to find the first, > second and third most popular choices? > > -cheers > -meadhbh > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0015174be0544449020471b280ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a general rule, I would recommend against using common words such= as ABOVE or OVER for the name of the group or protocol, for several reason= s:

  • Not everyone will capitalize ABOVE or OVER when using the= m in this technical context, so ambiguities will arise in common usage outs= ide of this group.
  • Discussions about the protocol held in voice will incur vocal am= biguity with the corresponding English words, and of course capitalization = is not possible in this medium.
  • Sometimes the words "above= " or "over" in their normal English meaning will get CAPITAL= IZED FOR EMPHASIS, adding yet more confusion to the mix.
  • New names like SMTP or HTTP extend natural language easily through popu= lar use, but overloaded terms create conflict rather than smooth language e= xtension.
  • ABOVE or OVER may be cute constructions, but cuteness doe= sn't help anyone.
  • But the biggest reason for avoiding common words is given by Googl= e, since the resulting poor quality of search results will benefit neither = the workgroup nor the eventual readers of our specifications.

I have no particular preferences for the name, apart from the above adv= ice.=A0 However, here are some partial phrases that might generate some mor= e ideas:

  • Virtual Spaces Organization and Access -- avoids &q= uot;Virtual Worlds"
  • Region Interoperation Services -- it's what the protocol targe= ts strongly
  • Virtual Services Interoperation -- alludes to Zha&#= 39;s reformulation
  • Virtual World Services Protocol -- works wel= l despite "ATM syndrome"
  • Virtual World State Representation System -- alludes to REST

    • As others have recommended as well, topological terms like "gri= d" don't really help and may create confusion, so should be discou= raged.=A0 In contrast, it would be worth encouraging use of a name that ref= erences some unique element of this particular proposal, such as Regions, o= r maybe State Transfer.


    Morgaine.









    On Fri, Aug 21, 2009 at 7:29 PM, Infinity Linden <infinity@lindenlab.com&g= t; wrote:
    it seems to me we= 're in the enviable position of having several good
    name suggestions: ARAP, VWIP, OVER, ABOVE and VWGP. We also have the
    historical name OGP.

    would it make sense to go around asking people to rank their name
    preferences and do Single Transferrable Vote (STV) to find the first,
    second and third most popular choices?

    -cheers
    -meadhbh
    _______________________________________________
    ogpx mailing list
    ogpx@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/ogpx

    --0015174be0544449020471b280ba-- From morgaine.dinova@googlemail.com Sat Aug 22 00:47:19 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 833B33A6A0F for ; Sat, 22 Aug 2009 00:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEazGgACHo1p for ; Sat, 22 Aug 2009 00:47:17 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id C547D3A67F5 for ; Sat, 22 Aug 2009 00:47:16 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so331417eye.31 for ; Sat, 22 Aug 2009 00:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Xt1IB6ohjtaqyrGfTYggf82CZou49iVwD6yU2YKJFjw=; b=XynbclmJVjUSs9CrP/Lx3mugMbYdSjz65NnnARVj5eKenLyqoHHAsa+igNWK0ysXNg 6pT8Fv9YfpCZAlzzHnLTrwcq4+dflpaNG4VLlX/x32L2jxQLkUkBJYCjPQssHHgzyFuU EmIDH4FHv8GvpsaGMElxG8Ey5zr4SflOVcQMY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=KUiTlx5JJw5JaRXZPASjjpZtl+r1+K3RYiGQHMGRWBgJbeKKtxaYINslsRSgbawvs4 OHka6YYgGPcC6BNcx1owvQ1WREU4dpC/XyQTELiDmyzRI9KKZgx421EAYoOfvkqP8M6U dkns8lSE44KNAYG0k1yLRh5JYuxSaFw4en5hg= MIME-Version: 1.0 Received: by 10.210.10.4 with SMTP id 4mr2512261ebj.36.1250927237437; Sat, 22 Aug 2009 00:47:17 -0700 (PDT) In-Reply-To: <20090822021323.GC29557@alinoe.com> References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> <20090820235051.GA21280@alinoe.com> <20090822021323.GC29557@alinoe.com> Date: Sat, 22 Aug 2009 08:47:17 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174be054a099260471b631fb Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 07:47:19 -0000 --0015174be054a099260471b631fb Content-Type: text/plain; charset=ISO-8859-1 Carlo Wood has once again done a magnificent job of presenting the key issues. I'll get to this in a minute. I've stayed away from the discussion for a day while you all battled away at defining terms, not because I'm not interested in terminology (I'll be as pedantic as the rest of you once we get to the drafts :P), but because I'm attempting to focus on the end goal without getting distracted by the means to achieve it. The end goal is of course to determine whether the OGP *mechanism* will handle interoperation between SL-type virtual worlds (independent collections of regions), or not. *How* that is achieved, and what terminology is used to describe it, is of no interest whatsoever compared to the actual answer, in this context. I am thrilled that the consensus appears to be moving towards unanimous agreement that such interop via this protocol is indeed the end goal. Some have suggested that it was always the end goal of OGP, but the highly ambiguous and rather eclectic nature of the terminology in the charter easily exposed the workgroup to eventual rejection of such a goal as being "out of scope". The last day's deliberations have been invaluable, because they have ensured that this end goal is indeed in scope for the workgroup and hence cannot be dismissed or minimized. This will have a significant impact on our work and our deliverables. Carlo has again performed a masterful analysis of the situation. I agree with every word, except that my personal impression that "*Linden Lab wasn't interested in the slightest to have this kind of interoperability with any of the current opensim pioneers*" refers to interop policy and hence misses my focus. It should be replaced by "*Linden Lab did not specify this kind of interoperabiliy in the OGPX charter and therefore it is unsafe to assume that this interoperability will be in the OGP protocol"*. These are quite different things, and my interest is in the latter, the mechanism of OGP, since I am focussed on technology. Now that we know that OGP is intended to provide such interoperability (if there is still disagreement about this in any quarter, please speak up now), we can make provision to ensure that the work of OGPX does actually deliver it. There are numerous areas impacted by the decision to provide such interoperation, but the charter is not the place to describe them. However, the charter must provide food and shelter for this area of work, otherwise it delivers a de facto rejection of such interop instead. In other words, such interop must be a deliverable. (I will mention some of the issues that may need addressing to achieve this, not because they are relevant now, but because it demonstrates that the currently listed deliverables do not necessarily cover them. Included are (this is *NOT* exhaustive): interaction between two or more Agent Domains, multi-domain identity handling, symmetric relationships between peer worlds, composition of inventories from multiple agent domains, multi-world addressing or landmarks for cross-world teleports, multi-world currency where available, open trust relationships, and transitive trust relationships. In particular is must be pointed out that full connectivity is not viable in an internet-scale metaverse, and this impacts on the core design.) Without going into the detail at charter time, I hope it is nevertheless clear that delivering cross-world interop is not trivial. In order to ensure that it does not fall victim to accidental (or intended) disinterest, it needs a specific deliverable to be listed among the Goals and Milestones detailing cross-world operation in overview, and it also needs every other deliverable to consider cross-world issues in passing. It should be noted that, if OGP was always intended to support such interop, then *the latter will entail no extra work*. As Carlo said, when we state that cross-world interop is the goal, "We're not there yet". We also have to provide care and feeding for this, to make the goal a genuine one. Morgaine. =================================== On Sat, Aug 22, 2009 at 3:13 AM, Carlo Wood wrote: > On Thu, Aug 20, 2009 at 05:16:09PM -0700, Meadhbh Siobhan wrote: > [deleted what I agree with, or just needs no comment] > > one of the objectives of the OGP protocol is to allow a virtual world > > to be constructed from regions, agent hosts and asset servers from > > different administrative domains. in order to do that, one of the > > Okaaayy... now you're using "a virtual world" again for a collection > of regions run by *different* administrations, while I was proposing > to keep the fact that currently all different (Second Life like) > worlds are run by different administrations. But... I'm not in a hurry > to have the meaning of "world" clearly defined, the only thing > that is important for me is the intent of the people on this mailinglist > and those working for Linden Lab in particular ;) > > > things we think we need to do is to have a scheme by which regions are > > unambiguously identified with a URL. we don't currently list > > "unambiguous landmarks" in the charter because we don't talk about > > landmarks at all in the charter. it's also unclear whether a landmark > > format will be defined as part of this effort. > > Okay. Note that I only talked about landmarks as example with > as goal to get clarity between us, here and now; followed by > a search for correct wording of paragraphs. I never thought that > "landmark" had to be added to the charter in said paragraphs. > > > so i guess what i'm saying is that if we listed "a format for > > unambiguous landmarks" in the charter, shouldn't we also list other > > Second-Life-like features like the C/M/T permissions system? the > > unambiguous URL representing a region is required for proper operation > > of teleport, which IS in scope, but the unambiguous landmark format is > > not required as landmarks are concepts more appropriately manipulated > > by client applications. > > I don't think that even unambiguous URL needs to be mentioned. > > > so, is it enough to add verbiage to the charter indicating that the > > protocol requires regions to be addressable by unambiguous URLs, but > > not explicitly constrain their use in the charter? > > Again, it was just a down-to-earth example, not suitable for the > charter. > > The problem that we're trying to tackle, that I was trying to tackle, > is this (going to formulate this VERY explicit, almost embarrashingly so > ;). > > There are people on this list that run (currently) small grids > with (obviously) opensim servers. They would very much like it > to be possible for people in SL to teleport directly to their > grid (and back), preferably (but not necessarily) while keeping > access to their inventory and keeping there appearance intact. > The reason they want that is simply: the more seamless that is > possible, the more people will come; and more people is Good(tm). > > The likeliness that this is going to happen for them in the > future depends mainly on two things: > > 1) Will the protocol support it at all > 2) Will Linden Lab grant those grids whatever access they need > > Point 2 is policy, and has nothing to do with the efforts of > this group. > > It is my understanding that Morgaine after reading the charter > lost all hope to achieve this goal of interoperability, and > concluded that with the given formulation (as proposed by you) > *apparently* Linden Lab wasn't interested the slightest to > have this kind of interoperability with any of the current > opensim pioneers; which led to some emotions and rather direct > attempt to let you "confess" that LL wasn't interested, and > when you said "that doesn't belong in the charter" that was > interpreted as "we have a hidden agenda". > > At this point I believe that all of that has been a misunderstanding, > that is directly caused by the confusion that exists about what > "virtual world" means. Morgaine (and me) interpreted "world" > as "run by a different administration", while you seem use the > word for "all regions that one can teleport to". Obviously, > the latter says NOTHING about the intent of Linden Lab to > interoperate with any opensim grids :p, and I suppose you > don't have to tell us if they do. But it's good to know now > that the protocol will support this. > > We're not there yet though: > > The reason that two grids (or virtual worlds, or different > administrations) might decide not to allow teleporting is > probably for a large part going to be determined by (not) trusting. > > Therefore, in order to achieve the goal of teleporting between > Second Life and the smaller opensim grids, we'd like a protocol > that demands as LITTLE trust as possible. > > For example, if the protocol would define something like: > - in order to teleport, grid A logs into auth services of grid B > once and then has access the everything after that (including > allowing to teleport); then teleporting would be impossible unless > grid B would trust grid A completely. > > Other shemes are thinkable that require less trust. One result > of a "hidden agenda" could be that the protocol would be designed > such that ANY operability would only be possible with FULL access > to everything, and therefore full trust, and therefore (in practise) > no interoperability at all (except between large companies with > lawyers and contracts-- not the little pioneers that run opensim > grids now). > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0015174be054a099260471b631fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Carlo Wood has once again done a magnificent job of presenting the key issu= es.=A0 I'll get to this in a minute.

    I've stayed away from the discussion for a day while you all battle= d away at defining terms, not because I'm not interested in terminology= (I'll be as pedantic as the rest of you once we get to the drafts :P),= but because I'm attempting to focus on the end goal without getting di= stracted by the means to achieve it.

    The end goal is of course to determine whether the OGP mechanism= will handle interoperation between SL-type virtual worlds (independent col= lections of regions), or not.=A0 How that is achieved, and what term= inology is used to describe it, is of no interest whatsoever compared to th= e actual answer, in this context.

    I am thrilled that the consensus appears to be moving towards unanimous= agreement that such interop via this protocol is indeed the end goal.
    <= br>Some have suggested that it was always the end goal of OGP, but the high= ly ambiguous and rather eclectic nature of the terminology in the charter e= asily exposed the workgroup to eventual rejection of such a goal as being &= quot;out of scope".=A0 The last day's deliberations have been inva= luable, because they have ensured that this end goal is indeed in scope for= the workgroup and hence cannot be dismissed or minimized.=A0 This will hav= e a significant impact on our work and our deliverables.

    Carlo has again performed a masterful analysis of the situation.
    I agree with every word, except that my personal impression that "= Linden Lab wasn't interested in the slightest to have this kind of inte= roperability with any of the current opensim pioneers" refers to i= nterop policy and hence misses my focus.=A0 It should be replaced by "= Linden Lab did not specify this kind of interoperabiliy in the OGPX char= ter and therefore it is unsafe to assume that this interoperability will be= in the OGP protocol".=A0 These are quite different things, and my= interest is in the latter, the mechanism of OGP, since I am focussed on te= chnology.

    Now that we know that OGP is intended to provide such interoperability = (if there is still disagreement about this in any quarter, please speak up = now), we can make provision to ensure that the work of OGPX does actually d= eliver it.

    There are numerous areas impacted by the decision to provide such inter= operation, but the charter is not the place to describe them.=A0 However, t= he charter must provide food and shelter for this area of work, otherwise i= t delivers a de facto rejection of such interop instead.=A0 In other words,= such interop must be a deliverable.

    (I will mention some of the issues that may need addressing to achieve = this, not because they are relevant now, but because it demonstrates that t= he currently listed deliverables do not necessarily cover them.=A0 Included= are (this is NOT exhaustive):=A0 interaction between two or more Ag= ent Domains, multi-domain identity handling, symmetric relationships betwee= n peer worlds, composition of inventories from multiple agent domains, mult= i-world addressing or landmarks for cross-world teleports, multi-world curr= ency where available, open trust relationships, and transitive trust relati= onships.=A0 In particular is must be pointed out that full connectivity is = not viable in an internet-scale metaverse, and this impacts on the core des= ign.)

    Without going into the detail at charter time, I hope it is nevertheles= s clear that delivering cross-world interop is not trivial.=A0 In order to = ensure that it does not fall victim to accidental (or intended) disinterest= , it needs a specific deliverable to be listed among the Goals and Mileston= es detailing cross-world operation in overview, and it also needs every oth= er deliverable to consider cross-world issues in passing.=A0 It should be n= oted that, if OGP was always intended to support such interop, then the = latter will entail no extra work.

    As Carlo said, when we state that cross-world interop is the goal, &quo= t;We're not there yet".=A0 We also have to provide care and feedin= g for this, to make the goal a genuine one.


    Morgaine.




    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    On Sat, Aug 22, 2009 at 3:13 AM, Carlo Wood <carlo@alinoe.com> wrote:
    On Thu, Aug 20, 2009 at 05:16:09PM -0700, Meadhbh Siobhan wrote:
    [deleted what I agree with, or just needs no comment]
    > one of the objectives of the OGP protocol is to allo= w a virtual world
    > to be constructed from regions, agent hosts and asset servers from
    > different administrative domains. in order to do that, one of the

    Okaaayy... now you're using "a virtual world" again for= a collection
    of regions run by *different* administrations, while I was proposing
    to keep the fact that currently all different (Second Life like)
    worlds are run by different administrations. But... I'm not in a hurry<= br> to have the meaning of "world" clearly defined, the only thing that is important for me is the intent of the people on this mailinglist and those working for Linden Lab in particular ;)

    > things we think we need to do is to have a scheme by which regions are=
    > unambiguously identified with a URL. we don't currently list
    > "unambiguous landmarks" in the charter because we don't = talk about
    > landmarks at all in the charter. it's also unclear whether a landm= ark
    > format will be defined as part of this effort.

    Okay. Note that I only talked about landmarks as example with
    as goal to get clarity between us, here and now; followed by
    a search for correct wording of paragraphs. I never thought that
    "landmark" had to be added to the charter in said paragraphs.

    > so i guess what i'm saying is that if we listed "a format for=
    > unambiguous landmarks" in the charter, shouldn't we also list= other
    > Second-Life-like features like the C/M/T permissions system? the
    > unambiguous URL representing a region is required for proper operation=
    > of teleport, which IS in scope, but the unambiguous landmark format is=
    > not required as landmarks are concepts more appropriately manipulated<= br> > by client applications.

    I don't think that even unambiguous URL needs to be mentioned.

    > so, is it enough to add verbiage to the charter indicating that the > protocol requires regions to be addressable by unambiguous URLs, but > not explicitly constrain their use in the charter?

    Again, it was just a down-to-earth example, not suitable for the
    charter.

    The problem that we're trying to tackle, that I was trying to tackle, is this (going to formulate this VERY explicit, almost embarrashingly so ;)= .

    There are people on this list that run (currently) small grids
    with (obviously) opensim servers. They would very much like it
    to be possible for people in SL to teleport directly to their
    grid (and back), preferably (but not necessarily) while keeping
    access to their inventory and keeping there appearance intact.
    The reason they want that is simply: the more seamless that is
    possible, the more people will come; and more people is Good(tm).

    The likeliness that this is going to happen for them in the
    future depends mainly on two things:

    1) Will the protocol support it at all
    2) Will Linden Lab grant those grids whatever access they need

    Point 2 is policy, and has nothing to do with the efforts of
    this group.

    It is my understanding that Morgaine after reading the charter
    lost all hope to achieve this goal of interoperability, and
    concluded that with the given formulation (as proposed by you)
    *apparently* Linden Lab wasn't interested the slightest to
    have this kind of interoperability with any of the current
    opensim pioneers; which led to some emotions and rather direct
    attempt to let you "confess" that LL wasn't interested, and when you said "that doesn't belong in the charter" that was interpreted as "we have a hidden agenda".

    At this point I believe that all of that has been a misunderstanding,
    that is directly caused by the confusion that exists about what
    "virtual world" means. Morgaine (and me) interpreted "world&= quot;
    as "run by a different administration", while you seem use the word for "all regions that one can teleport to". Obviously,
    the latter says NOTHING about the intent of Linden Lab to
    interoperate with any opensim grids :p, and I suppose you
    don't have to tell us if they do. But it's good to know now
    that the protocol will support this.

    We're not there yet though:

    The reason that two grids (or virtual worlds, or different
    administrations) might decide not to allow teleporting is
    probably for a large part going to be determined by (not) trusting.

    Therefore, in order to achieve the goal of teleporting between
    Second Life and the smaller opensim grids, we'd like a protocol
    that demands as LITTLE trust as possible.

    For example, if the protocol would define something like:
    - in order to teleport, grid A logs into auth services of grid B
    once and then has access the everything after that (including
    allowing to teleport); then teleporting would be impossible unless
    grid B would trust grid A completely.

    Other shemes are thinkable that require less trust. One result
    of a "hidden agenda" could be that the protocol would be designed=
    such that ANY operability would only be possible with FULL access
    to everything, and therefore full trust, and therefore (in practise)
    no interoperability at all (except between large companies with
    lawyers and contracts-- not the little pioneers that run opensim
    grids now).

    --
    Carlo Wood <carlo@alinoe.com>
    _______________________________________________
    ogpx mailing list
    ogpx@ietf.org
    ht= tps://www.ietf.org/mailman/listinfo/ogpx

    --0015174be054a099260471b631fb-- From billwindwalker@rocketmail.com Sat Aug 22 04:41:45 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6540F3A6C37 for ; Sat, 22 Aug 2009 04:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.775 X-Spam-Level: X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxCBFRotcYM2 for ; Sat, 22 Aug 2009 04:41:40 -0700 (PDT) Received: from web111207.mail.gq1.yahoo.com (web111207.mail.gq1.yahoo.com [67.195.15.166]) by core3.amsl.com (Postfix) with SMTP id 9AC9D3A6C03 for ; Sat, 22 Aug 2009 04:41:40 -0700 (PDT) Received: (qmail 72140 invoked by uid 60001); 22 Aug 2009 11:41:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rocketmail.com; s=s1024; t=1250941304; bh=vHIhsDNpa1Esp8ag18iP6NGh/e/O1d41Uysr3EPTgrk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=YrGXLAMBg8hAhzi6umyHnIwbJhEfiX3vC1uO7UH0rZi/QVlck959dyju/7IlnD7c46uYiK6xT3h4BcaN6MfJOblx4P9poEEHN9PuWXgY94e6p3hGG49XIN1dv2LMDKtiA9mZ+w5hiUdVd6w9NqyLgIeR/4yI/Jv0Ac5uMO7Sao4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=yU9eTaqbe0F5BooK2T1KbNxzZV1TiXt92zKOlImBf2dWZJ8xSY7012Dh7Yb2ciNE2xHXjlkSW02VbJuCZl/tNDzkRBFKDGr9i8n+1b9zZynEX9qRw3K7gwLEtXqGiXcD62LdsVzYbFA0sL3ngANy+NqGw5koxBGtd1dpJCGDyEA=; Message-ID: <956518.71208.qm@web111207.mail.gq1.yahoo.com> X-YMail-OSG: RrMWH9kVM1k9Yx9CNuyXFeo0ZCvIcr4B4h5roAOYD7iPiwDG99qO7Eadu.GZE.UZ7lPKcFqdnxcJtQaNdLw6vCTzJbKAxL.rxLXCD3y3xWgJSDsVIypyEjkOOl9yybpznQBWgPbX5kMo9qfuwyaikoWdeulfrYJdwCLX5B2M4beyIprm27L0AKQqFxQqPC5bWDK8QfZUOGHFJMVv9llHik5gP4XuISXs19G6au_1rYAzOHcXyHbUgo9K3BQvx43XcV6OAb3Rkc7O9da6MW.B0Wafa3lXg7sJYKlVwpYJi8worAOouy8hkJzH5Ybr1EfdyhflEfD7L0_tHsiboTVOr_3k1FodAxSqHnk0yFMgRVxnI80- Received: from [69.177.23.209] by web111207.mail.gq1.yahoo.com via HTTP; Sat, 22 Aug 2009 04:41:44 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.1 References: <3a880e2c0908191925p506de284w5ebb5cab7d893256@mail.gmail.com> <20090820141835.GB28751@alinoe.com> <20090820235051.GA21280@alinoe.com> <20090822021323.GC29557@alinoe.com> Date: Sat, 22 Aug 2009 04:41:44 -0700 (PDT) From: Bill Windwalker To: ogpx@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-826780924-1250941304=:71208" Subject: Re: [ogpx] OGPX WG draft charter, 2009-08-19 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 11:41:45 -0000 --0-826780924-1250941304=:71208 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Some times even the mega companys have had great programs that they have le= t slip out of there control just to find out in the end some part of it was= very importent.=0Ano one can see how importent some thing can be till they= have lost owner rights to it.=0A=0Axstorm Radek=0A=0A=0A=0A=0A____________= ____________________=0AFrom: Morgaine =0ATo= : ogpx@ietf.org=0ASent: Saturday, August 22, 2009 3:47:17 AM=0ASubject: Re:= [ogpx] OGPX WG draft charter, 2009-08-19 revision=0A=0ACarlo Wood has once= again done a magnificent job of presenting the key issues.=A0 I'll get to = this in a minute.=0A=0AI've stayed away from the discussion for a day while= you all battled away at defining terms, not because I'm not interested in = terminology (I'll be as pedantic as the rest of you once we get to the draf= ts :P), but because I'm attempting to focus on the end goal without getting= distracted by the means to achieve it.=0A=0AThe end goal is of course to d= etermine whether the OGP mechanism will handle interoperation between SL-ty= pe virtual worlds (independent collections of regions), or not.=A0 How that= is achieved, and what terminology is used to describe it, is of no interes= t whatsoever compared to the actual answer, in this context.=0A=0AI am thri= lled that the consensus appears to be moving towards unanimous agreement th= at such interop via this protocol is indeed the end goal.=0A=0ASome have su= ggested that it was always the end goal of OGP, but the highly ambiguous an= d rather eclectic nature of the terminology in the charter easily exposed t= he workgroup to eventual rejection of such a goal as being "out of scope".= =A0 The last day's deliberations have been invaluable, because they have en= sured that this end goal is indeed in scope for the workgroup and hence can= not be dismissed or minimized.=A0 This will have a significant impact on ou= r work and our deliverables.=0A=0ACarlo has again performed a masterful ana= lysis of the situation.=0A=0AI agree with every word, except that my person= al impression that "Linden Lab wasn't interested in the slightest to have t= his kind of interoperability with any of the current opensim pioneers" refe= rs to interop policy and hence misses my focus.=A0 It should be replaced by= "Linden Lab did not specify this kind of interoperabiliy in the OGPX chart= er and therefore it is unsafe to assume that this interoperability will be = in the OGP protocol".=A0 These are quite different things, and my interest = is in the latter, the mechanism of OGP, since I am focussed on technology.= =0A=0ANow that we know that OGP is intended to provide such interoperabilit= y (if there is still disagreement about this in any quarter, please speak u= p now), we can make provision to ensure that the work of OGPX does actually= deliver it.=0A=0AThere are numerous areas impacted by the decision to prov= ide such interoperation, but the charter is not the place to describe them.= =A0 However, the charter must provide food and shelter for this area of wor= k, otherwise it delivers a de facto rejection of such interop instead.=A0 I= n other words, such interop must be a deliverable.=0A=0A(I will mention som= e of the issues that may need addressing to achieve this, not because they = are relevant now, but because it demonstrates that the currently listed del= iverables do not necessarily cover them.=A0 Included are (this is NOT exhau= stive):=A0 interaction between two or more Agent Domains, multi-domain iden= tity handling, symmetric relationships between peer worlds, composition of = inventories from multiple agent domains, multi-world addressing or landmark= s for cross-world teleports, multi-world currency where available, open tru= st relationships, and transitive trust relationships.=A0 In particular is m= ust be pointed out that full connectivity is not viable in an internet-scal= e metaverse, and this impacts on the core design.)=0A=0AWithout going into = the detail at charter time, I hope it is nevertheless clear that delivering= cross-world interop is not trivial.=A0 In order to ensure that it does not= fall victim to accidental (or intended) disinterest, it needs a specific d= eliverable to be listed among the Goals and Milestones detailing cross-worl= d operation in overview, and it also needs every other deliverable to consi= der cross-world issues in passing.=A0 It should be noted that, if OGP was a= lways intended to support such interop, then the latter will entail no extr= a work.=0A=0AAs Carlo said, when we state that cross-world interop is the g= oal, "We're not there yet".=A0 We also have to provide care and feeding for= this, to make the goal a genuine one.=0A=0A=0AMorgaine.=0A=0A=0A=0A=0A=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A=0AOn Sat, Aug 22, 2009 at 3:13 AM, Car= lo Wood wrote:=0A=0AOn Thu, Aug 20, 2009 at 05:16:09PM -= 0700, Meadhbh Siobhan wrote:=0A>[deleted what I agree with, or just needs n= o comment]=0A>=0A>> one of the objectives of the OGP protocol is to allow a= virtual world=0A>> to be constructed from regions, agent hosts and asset s= ervers from=0A>> different administrative domains. in order to do that, one= of the=0A>=0A>Okaaayy... now you're using "a virtual world" again for a co= llection=0A>of regions run by *different* administrations, while I was prop= osing=0A>to keep the fact that currently all different (Second Life like)= =0A>worlds are run by different administrations. But... I'm not in a hurry= =0A>to have the meaning of "world" clearly defined, the only thing=0A>that = is important for me is the intent of the people on this mailinglist=0A>and = those working for Linden Lab in particular ;)=0A>=0A>=0A>> things we think = we need to do is to have a scheme by which regions are=0A>> unambiguously i= dentified with a URL. we don't currently list=0A>> "unambiguous landmarks" = in the charter because we don't talk about=0A>> landmarks at all in the cha= rter. it's also unclear whether a landmark=0A>> format will be defined as p= art of this effort.=0A>=0A>Okay. Note that I only talked about landmarks as= example with=0A>as goal to get clarity between us, here and now; followed = by=0A>a search for correct wording of paragraphs. I never thought that=0A>"= landmark" had to be added to the charter in said paragraphs.=0A>=0A>=0A>> s= o i guess what i'm saying is that if we listed "a format for=0A>> unambiguo= us landmarks" in the charter, shouldn't we also list other=0A>> Second-Life= -like features like the C/M/T permissions system? the=0A>> unambiguous URL = representing a region is required for proper operation=0A>> of teleport, wh= ich IS in scope, but the unambiguous landmark format is=0A>> not required a= s landmarks are concepts more appropriately manipulated=0A>> by client appl= ications.=0A>=0A>I don't think that even unambiguous URL needs to be mentio= ned.=0A>=0A>=0A>> so, is it enough to add verbiage to the charter indicatin= g that the=0A>> protocol requires regions to be addressable by unambiguous = URLs, but=0A>> not explicitly constrain their use in the charter?=0A>=0A>Ag= ain, it was just a down-to-earth example, not suitable for the=0A>charter.= =0A>=0A>The problem that we're trying to tackle, that I was trying to tackl= e,=0A>is this (going to formulate this VERY explicit, almost embarrashingly= so ;).=0A>=0A>There are people on this list that run (currently) small gri= ds=0A>with (obviously) opensim servers. They would very much like it=0A>to = be possible for people in SL to teleport directly to their=0A>grid (and bac= k), preferably (but not necessarily) while keeping=0A>access to their inven= tory and keeping there appearance intact.=0A>The reason they want that is s= imply: the more seamless that is=0A>possible, the more people will come; an= d more people is Good(tm).=0A>=0A>The likeliness that this is going to happ= en for them in the=0A>future depends mainly on two things:=0A>=0A>1) Will t= he protocol support it at all=0A>2) Will Linden Lab grant those grids whate= ver access they need=0A>=0A>Point 2 is policy, and has nothing to do with t= he efforts of=0A>this group.=0A>=0A>It is my understanding that Morgaine af= ter reading the charter=0A>lost all hope to achieve this goal of interopera= bility, and=0A>concluded that with the given formulation (as proposed by yo= u)=0A>*apparently* Linden Lab wasn't interested the slightest to=0A>have th= is kind of interoperability with any of the current=0A>opensim pioneers; wh= ich led to some emotions and rather direct=0A>attempt to let you "confess" = that LL wasn't interested, and=0A>when you said "that doesn't belong in the= charter" that was=0A>interpreted as "we have a hidden agenda".=0A>=0A>At t= his point I believe that all of that has been a misunderstanding,=0A>that i= s directly caused by the confusion that exists about what=0A>"virtual world= " means. Morgaine (and me) interpreted "world"=0A>as "run by a different ad= ministration", while you seem use the=0A>word for "all regions that one can= teleport to". Obviously,=0A>the latter says NOTHING about the intent of Li= nden Lab to=0A>interoperate with any opensim grids :p, and I suppose you=0A= >don't have to tell us if they do. But it's good to know now=0A>that the pr= otocol will support this.=0A>=0A>We're not there yet though:=0A>=0A>The rea= son that two grids (or virtual worlds, or different=0A>administrations) mig= ht decide not to allow teleporting is=0A>probably for a large part going to= be determined by (not) trusting.=0A>=0A>Therefore, in order to achieve the= goal of teleporting between=0A>Second Life and the smaller opensim grids, = we'd like a protocol=0A>that demands as LITTLE trust as possible.=0A>=0A>Fo= r example, if the protocol would define something like:=0A>- in order to te= leport, grid A logs into auth services of grid B=0A>once and then has acces= s the everything after that (including=0A>allowing to teleport); then telep= orting would be impossible unless=0A>grid B would trust grid A completely.= =0A>=0A>Other shemes are thinkable that require less trust. One result=0A>o= f a "hidden agenda" could be that the protocol would be designed=0A>such th= at ANY operability would only be possible with FULL access=0A>to everything= , and therefore full trust, and therefore (in practise)=0A>no interoperabil= ity at all (except between large companies with=0A>lawyers and contracts-- = not the little pioneers that run opensim=0A>grids now).=0A>=0A>--=0A>=0A>Ca= rlo Wood =0A>____________________________________________= ___=0A>ogpx mailing list=0A>ogpx@ietf.org=0A>https://www.ietf.org/mailman/l= istinfo/ogpx=0A>=0A=0A=0A=0A --0-826780924-1250941304=:71208 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
    Some times even the mega companys have had great progr= ams that they have let slip out of there control just to find out in the en= d some part of it was very importent.
    =0A
    no one can see how impor= tent some thing can be till they have lost owner rights to it.
    =0A 
    =0A
    xstorm Radek
    =0A

    =0A
    = =0A
    =0AFrom: Morgaine <morgaine.dinova@googlemail.com><= BR>To: ogpx@ietf.org
    = Sent: Saturday, August 22, 200= 9 3:47:17 AM
    Subject: Re= : [ogpx] OGPX WG draft charter, 2009-08-19 revision

    Carlo Woo= d has once again done a magnificent job of presenting the key issues. = I'll get to this in a minute.

    I've stayed away from the discussion = for a day while you all battled away at defining terms, not because I'm not= interested in terminology (I'll be as pedantic as the rest of you once we = get to the drafts :P), but because I'm attempting to focus on the end goal = without getting distracted by the means to achieve it.

    The end goal = is of course to determine whether the OGP mechanism will handle inte= roperation between SL-type virtual worlds (independent collections of regions), or not.  How that is ach= ieved, and what terminology is used to describe it, is of no interest whats= oever compared to the actual answer, in this context.

    I am thrilled = that the consensus appears to be moving towards unanimous agreement that su= ch interop via this protocol is indeed the end goal.

    Some have sugge= sted that it was always the end goal of OGP, but the highly ambiguous and r= ather eclectic nature of the terminology in the charter easily exposed the = workgroup to eventual rejection of such a goal as being "out of scope".&nbs= p; The last day's deliberations have been invaluable, because they have ens= ured that this end goal is indeed in scope for the workgroup and hence cann= ot be dismissed or minimized.  This will have a significant impact on = our work and our deliverables.

    Carlo has again performed a masterful= analysis of the situation.

    I agree with every word, except that my personal impression that "Linden Lab wasn't interested in the s= lightest to have this kind of interoperability with any of the current open= sim pioneers" refers to interop policy and hence misses my focus. = It should be replaced by "Linden Lab did not specify this kind of inter= operabiliy in the OGPX charter and therefore it is unsafe to assume that th= is interoperability will be in the OGP protocol".  These are quite= different things, and my interest is in the latter, the mechanism of OGP, = since I am focussed on technology.

    Now that we know that OGP is inte= nded to provide such interoperability (if there is still disagreement about= this in any quarter, please speak up now), we can make provision to ensure= that the work of OGPX does actually deliver it.

    There are numerous = areas impacted by the decision to provide such interoperation, but the char= ter is not the place to describe them.  However, the charter must provide food and shelter for this area of work, otherwise it delivers= a de facto rejection of such interop instead.  In other words, such i= nterop must be a deliverable.

    (I will mention some of the issues tha= t may need addressing to achieve this, not because they are relevant now, b= ut because it demonstrates that the currently listed deliverables do not ne= cessarily cover them.  Included are (this is NOT exhaustive):&n= bsp; interaction between two or more Agent Domains, multi-domain identity h= andling, symmetric relationships between peer worlds, composition of invent= ories from multiple agent domains, multi-world addressing or landmarks for = cross-world teleports, multi-world currency where available, open trust rel= ationships, and transitive trust relationships.  In particular is must= be pointed out that full connectivity is not viable in an internet-scale m= etaverse, and this impacts on the core design.)

    Without going into the detail at charter time, I hope it is nevertheless clear that deli= vering cross-world interop is not trivial.  In order to ensure that it= does not fall victim to accidental (or intended) disinterest, it needs a s= pecific deliverable to be listed among the Goals and Milestones detailing c= ross-world operation in overview, and it also needs every other deliverable= to consider cross-world issues in passing.  It should be noted that, = if OGP was always intended to support such interop, then the latter will= entail no extra work.

    As Carlo said, when we state that cross-w= orld interop is the goal, "We're not there yet".  We also have to prov= ide care and feeding for this, to make the goal a genuine one.


    M= orgaine.





    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    =0A<= DIV class=3Dgmail_quote>On Sat, Aug 22, 2009 at 3:13 AM, Carlo Wood <carlo@alinoe.com> wr= ote:
    =0A
    On Thu, Aug= 20, 2009 at 05:16:09PM -0700, Meadhbh Siobhan wrote:
    [deleted what I ag= ree with, or just needs no comment]
    =0A
    > one of the o= bjectives of the OGP protocol is to allow a virtual world
    > to be con= structed from regions, agent hosts and asset servers from
    > different= administrative domains. in order to do that, one of the

    Okaaa= yy... now you're using "a virtual world" again for a collection
    of regio= ns run by *different* administrations, while I was proposing
    to keep the= fact that currently all different (Second Life like)
    worlds are run by = different administrations. But... I'm not in a hurry
    to have the meaning= of "world" clearly defined, the only thing
    that is important for me is = the intent of the people on this mailinglist
    and those working for Linde= n Lab in particular ;)
    =0A

    > things we think we ne= ed to do is to have a scheme by which regions are
    > unambiguously ide= ntified with a URL. we don't currently list
    > "unambiguous landmarks"= in the charter because we don't talk about
    > landmarks at all in the= charter. it's also unclear whether a landmark
    > format will be defin= ed as part of this effort.

    Okay. Note that I only talked about= landmarks as example with
    as goal to get clarity between us, here and n= ow; followed by
    a search for correct wording of paragraphs. I never thou= ght that
    "landmark" had to be added to the charter in said paragraphs.=0A

    > so i guess what i'm saying is that if we list= ed "a format for
    > unambiguous landmarks" in the charter, shouldn't w= e also list other
    > Second-Life-like features like the C/M/T permissi= ons system? the
    > unambiguous URL representing a region is required f= or proper operation
    > of teleport, which IS in scope, but the unambig= uous landmark format is
    > not required as landmarks are concepts more= appropriately manipulated
    > by client applications.

    I d= on't think that even unambiguous URL needs to be mentioned.
    =0A

    > so, is it enough to add verbiage to the charter indicating = that the
    > protocol requires regions to be addressable by unambiguous= URLs, but
    > not explicitly constrain their use in the charter?
    Again, it was just a down-to-earth example, not suitable for thecharter.

    The problem that we're trying to tackle, that I was trying= to tackle,
    is this (going to formulate this VERY explicit, almost embar= rashingly so ;).

    There are people on this list that run (currently) = small grids
    with (obviously) opensim servers. They would very much like = it
    to be possible for people in SL to teleport directly to their
    grid= (and back), preferably (but not necessarily) while keeping
    access to th= eir inventory and keeping there appearance intact.
    The reason they want = that is simply: the more seamless that is
    possible, the more people will= come; and more people is Good(tm).

    The likeliness that this is going to happen for them in the
    future depends mainly on t= wo things:

    1) Will the protocol support it at all
    2) Will Linden = Lab grant those grids whatever access they need

    Point 2 is policy, a= nd has nothing to do with the efforts of
    this group.

    It is my und= erstanding that Morgaine after reading the charter
    lost all hope to achi= eve this goal of interoperability, and
    concluded that with the given for= mulation (as proposed by you)
    *apparently* Linden Lab wasn't interested = the slightest to
    have this kind of interoperability with any of the curr= ent
    opensim pioneers; which led to some emotions and rather direct
    at= tempt to let you "confess" that LL wasn't interested, and
    when you said = "that doesn't belong in the charter" that was
    interpreted as "we have a = hidden agenda".

    At this point I believe that all of that has been a = misunderstanding,
    that is directly caused by the confusion that exists about what
    "virtual world" means. Morgaine (and me) interpreted = "world"
    as "run by a different administration", while you seem use theword for "all regions that one can teleport to". Obviously,
    the latter= says NOTHING about the intent of Linden Lab to
    interoperate with any op= ensim grids :p, and I suppose you
    don't have to tell us if they do. But = it's good to know now
    that the protocol will support this.

    We're = not there yet though:

    The reason that two grids (or virtual worlds, = or different
    administrations) might decide not to allow teleporting isprobably for a large part going to be determined by (not) trusting.
    Therefore, in order to achieve the goal of teleporting between
    Second = Life and the smaller opensim grids, we'd like a protocol
    that demands as= LITTLE trust as possible.

    For example, if the protocol would define= something like:
    - in order to teleport, grid A logs into auth services of grid B
    once and then has access the everything after that (= including
    allowing to teleport); then teleporting would be impossible un= less
    grid B would trust grid A completely.

    Other shemes are think= able that require less trust. One result
    of a "hidden agenda" could be t= hat the protocol would be designed
    such that ANY operability would only = be possible with FULL access
    to everything, and therefore full trust, an= d therefore (in practise)
    no interoperability at all (except between lar= ge companies with
    lawyers and contracts-- not the little pioneers that r= un opensim
    grids now).

    --
    =0A=0A
    =0A
    Carlo Wood <carlo@alinoe.com>
    _____________________________________________= __
    ogpx mailing list
    ogpx@ietf.org
    https://www.ietf.org/mailman/listinfo/ogpx


=0A=0A --0-826780924-1250941304=:71208-- From billwindwalker@rocketmail.com Sat Aug 22 04:47:12 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7653A6C34 for ; Sat, 22 Aug 2009 04:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04VizHyCIffV for ; Sat, 22 Aug 2009 04:47:11 -0700 (PDT) Received: from web111210.mail.gq1.yahoo.com (web111210.mail.gq1.yahoo.com [67.195.15.184]) by core3.amsl.com (Postfix) with SMTP id 79F5D3A6C11 for ; Sat, 22 Aug 2009 04:47:11 -0700 (PDT) Received: (qmail 66118 invoked by uid 60001); 22 Aug 2009 11:47:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rocketmail.com; s=s1024; t=1250941637; bh=iUxHJQ3Sg/RQsiT4dUU8b/81b2im74bSz29f7zOuot4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=JEgWmmIqLAvaP5E+bqFdkx23VrmrQiDfygQqjWyL4UaIBmOKi/fZS6OXahQQEDAxjPAv2KH+s3rM+CK6yH3MWKTbrKvUMSGevHabm591WdjjIc4fjHK64uBX4iIPxA9d/upfTfSMEfCkScBClOGwWeQSaG4kAUd3YY9DJ3Z6h/8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=huVFu8ygrmgbHxXZqpNPF8VRYk2aC7dItLvtSUrOgy8j3o5mLH8TeBetOp9NBDPt4Qyv0+FZwBsi8+1tMpjSK2HGmsVbIyWMeUDsjP2ItYpnVGG+vTIRvZo9CvMJGM6cFI39zmFsk3JszHfJbATc3cWVum6AvAWalYlWjYhHg/0=; Message-ID: <479011.65903.qm@web111210.mail.gq1.yahoo.com> X-YMail-OSG: KeuOY30VM1kxJS.AXH6sFqwRtx7.G4vLpsOO4d3n2chNgc_62RKdyra6193zNYNiBeZB_nadt8_4nRD10JmcTxThY.w_hcrupoDK1kI731szeAJLDThlzcvGVK5jlk9CDrAX14TrH5jN5VxV2tK3qhQ48YPC1Z_00jMqPhnWGQAa1KIeyUbw_biGLJvPzl1SJeYRncrXiD75LxgY670rp5lCXByB.uoimiQd2thGygAKuyntTPvxn8HYcDARo2ekgXcNBVensOIBx_jiJx4l35zlaaIeDxcJtpCMUjMa6rOI_967Gex2KFtiKI55gyd5nRfnBC5q2w0iZuuMkTk1JmWBbD9EW2zx3yk9zhZWpMD3FnM- Received: from [69.177.23.209] by web111210.mail.gq1.yahoo.com via HTTP; Sat, 22 Aug 2009 04:47:17 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.1 References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> Date: Sat, 22 Aug 2009 04:47:17 -0700 (PDT) From: Bill Windwalker To: ogpx@ietf.org In-Reply-To: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-842822646-1250941637=:65903" Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 11:47:12 -0000 --0-842822646-1250941637=:65903 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable If it was me i keep the OGP it has come a long way and sounds like a GOV. w= ord ;-)=0Aany way i started saying some days Oh good programing ;-)=0Aor ev= en how great at times=0A=0A=A0=0A=0A=0A=0A________________________________= =0AFrom: Infinity Linden =0ATo: ogpx@ietf.org=0ASen= t: Friday, August 21, 2009 2:29:41 PM=0ASubject: [ogpx] resolving the name = issue=0A=0Ait seems to me we're in the enviable position of having several = good=0Aname suggestions: ARAP, VWIP, OVER, ABOVE and VWGP. We also have the= =0Ahistorical name OGP.=0A=0Awould it make sense to go around asking people= to rank their name=0Apreferences and do Single Transferrable Vote (STV) to= find the first,=0Asecond and third most popular choices?=0A=0A-cheers=0A-m= eadhbh=0A_______________________________________________=0Aogpx mailing lis= t=0Aogpx@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/ogpx=0A=0A=0A=0A = --0-842822646-1250941637=:65903 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
If it was me i keep the OGP it has come a long way and= sounds like a GOV. word ;-)
=0A
any way i started saying some day= s Oh good programing ;-)
=0A
or even how great at times
=0A
 
=0A

=0A
=0A
=0AFrom: Infinity L= inden <infinity@lindenlab.com>
Sent= : Friday, August 21, 2009 2:29:41 PM
Subject: [ogpx] resolving the name issue
=
it seems to me we're in the enviable position of having several goodname suggestions: ARAP, VWIP, OVER, ABOVE and VWGP. We also have the
hi= storical name OGP.

would it make sense to go around asking people to= rank their name
preferences and do Single Transferrable Vote (STV) to f= ind the first,
second and third most popular choices?

-cheers
= -meadhbh
_______________________________________________
ogpx mailing= list
= ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx

=0A=0A --0-842822646-1250941637=:65903-- From infinity@lindenlab.com Sat Aug 22 13:00:03 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1018C3A6A1C for ; Sat, 22 Aug 2009 13:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.956 X-Spam-Level: X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n49a7-tbXX0J for ; Sat, 22 Aug 2009 13:00:01 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id BF2573A698A for ; Sat, 22 Aug 2009 13:00:01 -0700 (PDT) Received: by pzk4 with SMTP id 4so357491pzk.29 for ; Sat, 22 Aug 2009 13:00:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.26.31 with SMTP id d31mr243773wfj.269.1250971203519; Sat, 22 Aug 2009 13:00:03 -0700 (PDT) Date: Sat, 22 Aug 2009 13:00:03 -0700 Message-ID: <3a880e2c0908221300v2208737fya9aebab75790865b@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ogpx] The Role of Policy and Processing Expectations in Protocol Development X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 20:00:03 -0000 So I too recently wrote a long, rambling narrative in response to Carlo's recent message where I tried to concisely explain how we got to where we are in the definition of terms like "virtual world" and "region domain." But it was pretty long and rambling and took a long time to come to the point. I figured I would just come right out and get to the point. We want to separate mechanism from policy in OGP. A bunch of us have been saying it a lot, but I figured it might be a good idea to clearly explain what I think that means. When I say "mechanism," I mean things like protocol message formats and processing expectations; things like, "if you want to login to such and such a virtual world, you send this message with these fields to some server out on the network. if the server wants to let you on, it will send you this message. if it doesn't, it will send you that message." Here's an auth protocol exchange example from HTTP: client: hey! server! gimme the resource at http://example.org/make/me/a/sandwich.xml server: no can do, client. that resource is protected. fear my 401! client: what if i give you my super secret password that i swear i didn't sniff from another session!? server: okay. in that case, sure... 200! Policy, on the other hand, describes the decision making process protocol participants go through to decide which response to give you. Returning to the example above, when the server gets an auth request, it might have the policy of "I will only let people in who give me a valid avatar or account name and password." Yes! that's policy. It's a valid idea to let people into a virtual world without a username and password; web sites do it all the time. For many applications of virtual worlds, it's a very bad idea, but it's the height of conceit for me, as a protocol developer, to claim to know the mind of every virtual world deployer throughout the world. But, experience tells me that very bad things can happen in some communities when you add anonymity and an audience. But hey, that's _your_ call. It could be that your virtual world is only accessible by two people in the office, so you always have a good idea who the other "anonymous" participant is. Or maybe you work for an old skool company where people would never think to be jerks to their fellow employees in their "behind the firewall" virtual world. The point is... this decision is up to you, the deployer. Other examples of policy (again on auth) might include things like: * i don't trust MD5, so i'll only accept logins that use SHA1 in some way, or * i'll only let you online if i think you've agreed to my "terms of service" document, or * i think i don't want anyone to login between 10PM and 7:30AM because i'm a BOFH and i need my rest. There's another term you hear from time to time: "processing expectations." This is a term I heard first in the SGML / document processing community. I've seen people attempt to give a formal definition of this term. My informal definition is... "I know I can't force you to do this, but everyone sort of expects this is what you're going to do with the data i give you and it would be really nice if you would play along, but if you really, really, really need to do something else with the data, that's cool. KTHXBAI." An example of a processing expectation might be: "when the server receives a message with a SHA1 hashed password, it will compare the hashed password provided with the hashed password stored in the database." As a client there's absolutely no way I can force the server to actually do this, but assuming servers do want to maintain the confidentiality of their users' data, they probably will. Processing Expectations and Policies are protocol developers' ways of saying, "krikey! i have no idea what the deployer will want to do here." or "if the other side wanted to be evil, they could be. look here! we're trusting them to 'do the right thing.'" So why do we care? In the virtual world, one of the things we're really big on is consistency of presentation. It's considered "a good idea" for you to see largely the same thing the avatar next to you is seeing. Otherwise, the utility of the virtual world is diminished. Some virtual worlds allow user developed content and allow the content creator to place copy restrictions on that content. (we're not naming names here, *cough*Second Life*cough*) Operators of these virtual worlds have a strong belief it is in their best interest to maintain those copy restrictions. So... they have a POLICY that says, "when the client sends me the message to copy a digital asset and put it in their virtual pocket, i'm going to check if the creator of that asset says that's okay." The protocol message from the client says "give me a copy, please" and the server has to decide whether this is a good idea. If the server thinks it's a good idea, it will do it. If not, it won't. Other virtual worlds may be pre-stocked with assets and may not allow users to create new ones. (i'm thinking this is what sametime 3d does, but i may be wrong.) Still other virtual worlds may be bastions of free culture coolness and mark everything with a creative commons license that allows copying, but leaves it up to the participants to ensure they're not violating the terms of the license. I think we have general agreement that people who deploy OGP based virtual worlds should be free to implement whatever policy they want to implement. The problem comes when we start talking about allowing avatars to move between region domains in the same virtual world that MAY have different policies. Linden Lab, the makers of Second Life, would want some seriously strong assurances from other region domains that they promise to honor the permissions metadata attached to a digital asset. Our hypothetical free culture region domain operators might want assurances that other region domains will not let assets with a no commercial use CC license be used to create things that are sold. How will we ever resolve this problem? One way people have tried to resolve it in the past is by sitting down and writing up legal agreements. That's because it's a POLICY issue. It's very, very hard for a server to guarantee by technical means that a client is using content only in a way the content's rights-holder allows. So we punt, and just say something like.. "if you sign a contract and let me sue you if you don't honor my policies, i'll let you interact with my systems." As protocol developers all we have to do now is figure a way to tag content and interfaces with sufficient meta-data that systems in peer domains have a good chance of making an informed decision when the client asks to do something that might violate the license. Or, you might just deny access to service interfaces to people you don't think you can trust. But again, it's a POLICY decision. As protocol developers, our responsibility is to specify meta-data sufficient for making informed decisions and for defining processes for identifying trusted peers in the networks. And.. I'm not making an exhaustive list of "policy issues," merely asserting that there are a reasonably small number of them, and that we can identify them using a consensus process. By defining these decisions as "policy issues," it allows us to develop protocol mechanisms that are appropriate for all supported use cases. Thus we can all collaborate on producing a specification that works for all of us, but allows each of us to address our specific needs. I know Prokofy Neva has made statements disagreeing with this approach in the past, and that she would prefer a virtual worlds protocol that mandates all virtual worlds adopt second life's C/M/T permissions model. I believe her justification is that it's too easy for a misunderstanding or misconfiguration to lead to content leakage. My counter argument to this is that by developing the protocol in public, we get more eyeballs looking at the problem domain and we get more edge cases considered. Because there's a higher probability that problematic edge cases will be identified earlier, we'll get a more robust protocol. Is there anyone on the list that takes serious issue with anything i've said here? -cheers -meadhbh From morgaine.dinova@googlemail.com Sat Aug 22 16:27:37 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05A873A6B2B for ; Sat, 22 Aug 2009 16:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.986 X-Spam-Level: X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM3uN8DI+4hi for ; Sat, 22 Aug 2009 16:27:34 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 291193A68F9 for ; Sat, 22 Aug 2009 16:27:33 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so423579eye.31 for ; Sat, 22 Aug 2009 16:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=5aEXlzqlhagN+vdGHryI91YsAG91vcod1+nncAB5Rus=; b=bRxL4q3/p9u5sk/g2rOnv2zh9eKL01nfk2OfNJeUjmzyRZuWyyOyxbGCnzffqThHHC vflSpvwWfeX/GkJhRHcX3c5kr5aAHzrFGb6eNeoOd6OKrt5Qlju3xwH6NZDK1+zOuNan pFmiViWVVFB4vPxhJKDy3gJfnqRaHuLGNzDp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=iNqJzy6V0o74GErCXZq6QNYZdw4Kv+ZIQvPQPqSyV7U1Gmhv+C2NpP9KRefZH/ioCT vHHiFs98MDGs7n/fTWNy5FfP6uZwW3cGqFFviX9X1zhiY9dhGxoyP8OAfFnIk4eaZBzA UrXZE4f+2G2BKpIuxXgIQ5Q2BV6obyTuXLxJg= MIME-Version: 1.0 Received: by 10.210.39.11 with SMTP id m11mr2984923ebm.27.1250983654743; Sat, 22 Aug 2009 16:27:34 -0700 (PDT) In-Reply-To: <3a880e2c0908221300v2208737fya9aebab75790865b@mail.gmail.com> References: <3a880e2c0908221300v2208737fya9aebab75790865b@mail.gmail.com> Date: Sun, 23 Aug 2009 00:27:34 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174c1a225c601b0471c35427 Subject: Re: [ogpx] The Role of Policy and Processing Expectations in Protocol Development X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Aug 2009 23:27:37 -0000 --0015174c1a225c601b0471c35427 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Separation of policy and mechanism is motherhood and apple pie to us here. The problem lies in achieving it, and avoiding any one party imposing their own policy by shackling the mechanism and denying it the ability to implement other policies. Here's an example of it happening as an artifact of design: On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden wrote: I think we have general agreement that people who deploy OGP based virtual worlds should be free to implement whatever policy they want to implement. *The problem comes when we start talking about allowing avatars to move between region domains in the same virtual world that MAY have different policies*. That's a problem of your own making. Carlo and I and every open grid operator understands that all these grids are independent virtual worlds *that have separate policies*. Yet you choose to invent a new meaning for "virtual world" in which *all communicating parties* create a "same virtual world", and then you wonder why you have a problem of varying policies within your fictitious "same virtual world". That's the hub of the matter. It's not the same virtual world. It's two separate virtual worlds with naturally separate policies that are seeking to interoperate. You've created the problem yourself by defining them to be the "same virtual world". The "same virtual world" terminology in the current OGP documents is actually *bleeding policy into mechanism*, the exact opposite of the separation we desire. It expects uniformity of policies across participating worlds using trust relationships as tokens of policy conformity. That's neither feasible on principle (because the grids have distinct policies by design), nor is it feasible technically, because it doesn't scale to Internet sizes in a highly diverse and multi-jurisdictional physical world. Morgaine. ================================ On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden wrote: > So I too recently wrote a long, rambling narrative in response to > Carlo's recent message where I tried to concisely explain how we got > to where we are in the definition of terms like "virtual world" and > "region domain." But it was pretty long and rambling and took a long > time to come to the point. I figured I would just come right out and > get to the point. > > We want to separate mechanism from policy in OGP. > > A bunch of us have been saying it a lot, but I figured it might be a > good idea to clearly explain what I think that means. When I say > "mechanism," I mean things like protocol message formats and > processing expectations; things like, "if you want to login to such > and such a virtual world, you send this message with these fields to > some server out on the network. if the server wants to let you on, it > will send you this message. if it doesn't, it will send you that > message." > > Here's an auth protocol exchange example from HTTP: > > client: hey! server! gimme the resource at > http://example.org/make/me/a/sandwich.xml > server: no can do, client. that resource is protected. fear my 401! > client: what if i give you my super secret password that i swear i > didn't sniff from another session!? > server: okay. in that case, sure... 200! > > Policy, on the other hand, describes the decision making process > protocol participants go through to decide which response to give you. > Returning to the example above, when the server gets an auth request, > it might have the policy of "I will only let people in who give me a > valid avatar or account name and password." Yes! that's policy. It's a > valid idea to let people into a virtual world without a username and > password; web sites do it all the time. For many applications of > virtual worlds, it's a very bad idea, but it's the height of conceit > for me, as a protocol developer, to claim to know the mind of every > virtual world deployer throughout the world. > > But, experience tells me that very bad things can happen in some > communities when you add anonymity and an audience. But hey, that's > _your_ call. It could be that your virtual world is only accessible by > two people in the office, so you always have a good idea who the other > "anonymous" participant is. Or maybe you work for an old skool company > where people would never think to be jerks to their fellow employees > in their "behind the firewall" virtual world. The point is... this > decision is up to you, the deployer. > > Other examples of policy (again on auth) might include things like: > * i don't trust MD5, so i'll only accept logins that use SHA1 in some way, > or > * i'll only let you online if i think you've agreed to my "terms of > service" document, or > * i think i don't want anyone to login between 10PM and 7:30AM > because i'm a BOFH and i need my rest. > > There's another term you hear from time to time: "processing > expectations." This is a term I heard first in the SGML / document > processing community. I've seen people attempt to give a formal > definition of this term. My informal definition is... "I know I can't > force you to do this, but everyone sort of expects this is what you're > going to do with the data i give you and it would be really nice if > you would play along, but if you really, really, really need to do > something else with the data, that's cool. KTHXBAI." > > An example of a processing expectation might be: "when the server > receives a message with a SHA1 hashed password, it will compare the > hashed password provided with the hashed password stored in the > database." As a client there's absolutely no way I can force the > server to actually do this, but assuming servers do want to maintain > the confidentiality of their users' data, they probably will. > > Processing Expectations and Policies are protocol developers' ways of > saying, "krikey! i have no idea what the deployer will want to do > here." or "if the other side wanted to be evil, they could be. look > here! we're trusting them to 'do the right thing.'" > > So why do we care? > > In the virtual world, one of the things we're really big on is > consistency of presentation. It's considered "a good idea" for you to > see largely the same thing the avatar next to you is seeing. > Otherwise, the utility of the virtual world is diminished. > > Some virtual worlds allow user developed content and allow the content > creator to place copy restrictions on that content. (we're not naming > names here, *cough*Second Life*cough*) Operators of these virtual > worlds have a strong belief it is in their best interest to maintain > those copy restrictions. So... they have a POLICY that says, "when the > client sends me the message to copy a digital asset and put it in > their virtual pocket, i'm going to check if the creator of that asset > says that's okay." The protocol message from the client says "give me > a copy, please" and the server has to decide whether this is a good > idea. If the server thinks it's a good idea, it will do it. If not, it > won't. > > Other virtual worlds may be pre-stocked with assets and may not allow > users to create new ones. (i'm thinking this is what sametime 3d does, > but i may be wrong.) Still other virtual worlds may be bastions of > free culture coolness and mark everything with a creative commons > license that allows copying, but leaves it up to the participants to > ensure they're not violating the terms of the license. > > I think we have general agreement that people who deploy OGP based > virtual worlds should be free to implement whatever policy they want > to implement. The problem comes when we start talking about allowing > avatars to move between region domains in the same virtual world that > MAY have different policies. Linden Lab, the makers of Second Life, > would want some seriously strong assurances from other region domains > that they promise to honor the permissions metadata attached to a > digital asset. Our hypothetical free culture region domain operators > might want assurances that other region domains will not let assets > with a no commercial use CC license be used to create things that are > sold. > > How will we ever resolve this problem? One way people have tried to > resolve it in the past is by sitting down and writing up legal > agreements. That's because it's a POLICY issue. It's very, very hard > for a server to guarantee by technical means that a client is using > content only in a way the content's rights-holder allows. So we punt, > and just say something like.. "if you sign a contract and let me sue > you if you don't honor my policies, i'll let you interact with my > systems." > > As protocol developers all we have to do now is figure a way to tag > content and interfaces with sufficient meta-data that systems in peer > domains have a good chance of making an informed decision when the > client asks to do something that might violate the license. Or, you > might just deny access to service interfaces to people you don't think > you can trust. But again, it's a POLICY decision. As protocol > developers, our responsibility is to specify meta-data sufficient for > making informed decisions and for defining processes for identifying > trusted peers in the networks. > > And.. I'm not making an exhaustive list of "policy issues," merely > asserting that there are a reasonably small number of them, and that > we can identify them using a consensus process. By defining these > decisions as "policy issues," it allows us to develop protocol > mechanisms that are appropriate for all supported use cases. Thus we > can all collaborate on producing a specification that works for all of > us, but allows each of us to address our specific needs. > > I know Prokofy Neva has made statements disagreeing with this approach > in the past, and that she would prefer a virtual worlds protocol that > mandates all virtual worlds adopt second life's C/M/T permissions > model. I believe her justification is that it's too easy for a > misunderstanding or misconfiguration to lead to content leakage. > > My counter argument to this is that by developing the protocol in > public, we get more eyeballs looking at the problem domain and we get > more edge cases considered. Because there's a higher probability that > problematic edge cases will be identified earlier, we'll get a more > robust protocol. > > Is there anyone on the list that takes serious issue with anything > i've said here? > > -cheers > -meadhbh > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0015174c1a225c601b0471c35427 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Separation of policy and mechanism is motherhood and apple pie to us here.= =A0 The problem lies in achieving it, and avoiding any one party imposing t= heir own policy by shackling the mechanism and denying it the ability to im= plement other policies.

Here's an example of it happening as an artifact of design:

= On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden <infinity@lindenlab.com>= wrote:

I think we have general agreement tha= t people who deploy OGP based virtual worlds should be free to implement wh= atever policy they want to implement. The problem comes when we start ta= lking about allowing avatars to move between region domains in the same vir= tual world that MAY have different policies.

That's a problem of your own making.=A0 Carlo and I and every= open grid operator understands that all these grids are independent virtua= l worlds that have separate policies.=A0 Yet you choose to invent a = new meaning for "virtual world" in which all communicating par= ties create a "same virtual world", and then you wonder why y= ou have a problem of varying policies within your fictitious "same vir= tual world".

That's the hub of the matter.=A0 It's not the same virtual worl= d.=A0 It's two separate virtual worlds with naturally separate policies= that are seeking to interoperate.=A0 You've created the problem yourse= lf by defining them to be the "same virtual world".

The "same virtual world" terminology in the current OGP docum= ents is actually bleeding policy into mechanism, the exact opposite = of the separation we desire.

It expects uniformity of policies acros= s participating worlds using trust relationships as tokens of policy confor= mity.=A0 That's neither feasible on principle (because the grids have d= istinct policies by design), nor is it feasible technically, because it doe= sn't scale to Internet sizes in a highly diverse and multi-jurisdiction= al physical world.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= div class=3D"gmail_quote">On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden = <infinity@li= ndenlab.com> wrote:
So I too recently= wrote a long, rambling narrative in response to
Carlo's recent message where I tried to concisely explain how we got to where we are in the definition of terms like "virtual world" a= nd
"region domain." But it was pretty long and rambling and took a l= ong
time to come to the point. I figured I would just come right out and
get to the point.

We want to separate mechanism from policy in OGP.

A bunch of us have been saying it a lot, but I figured it might be a
good idea to clearly explain what I think that means. When I say
"mechanism," I mean things like protocol message formats and
processing expectations; things like, "if you want to login to such and such a virtual world, you send this message with these fields to
some server out on the network. if the server wants to let you on, it
will send you this message. if it doesn't, it will send you that
message."

Here's an auth protocol exchange example from HTTP:

client: hey! server! gimme the resource at
htt= p://example.org/make/me/a/sandwich.xml
server: no can do, client. that resource is protected. fear my 401!
client: what if i give you my super secret password that i swear i
didn't sniff from another session!?
server: okay. in that case, sure... 200!

Policy, on the other hand, describes the decision making process
protocol participants go through to decide which response to give you.
Returning to the example above, when the server gets an auth request,
it might have the policy of "I will only let people in who give me a valid avatar or account name and password." Yes! that's policy. It= 's a
valid idea to let people into a virtual world without a username and
password; web sites do it all the time. For many applications of
virtual worlds, it's a very bad idea, but it's the height of concei= t
for me, as a protocol developer, to claim to know the mind of every
virtual world deployer throughout the world.

But, experience tells me that very bad things can happen in some
communities when you add anonymity and an audience. But hey, that's
_your_ call. It could be that your virtual world is only accessible by
two people in the office, so you always have a good idea who the other
"anonymous" participant is. Or maybe you work for an old skool co= mpany
where people would never think to be jerks to their fellow employees
in their "behind the firewall" virtual world. The point is... thi= s
decision is up to you, the deployer.

Other examples of policy (again on auth) might include things like:
=A0* i don't trust MD5, so i'll only accept logins that use SHA1 i= n some way, or
=A0* i'll only let you online if i think you've agreed to my "= ;terms of
service" document, or
=A0* i think i don't want anyone to login between 10PM and 7:30AM
because i'm a BOFH and i need my rest.

There's another term you hear from time to time: "processing
expectations." This is a term I heard first in the SGML / document
processing community. I've seen people attempt to give a formal
definition of this term. My informal definition is... "I know I can= 9;t
force you to do this, but everyone sort of expects this is what you're<= br> going to do with the data i give you and it would be really nice if
you would play along, but if you really, really, really need to do
something else with the data, that's cool. KTHXBAI."

An example of a processing expectation might be: "when the server
receives a message with a SHA1 hashed password, it will compare the
hashed password provided with the hashed password stored in the
database." As a client there's absolutely no way I can force the server to actually do this, but assuming servers do want to maintain
the confidentiality of their users' data, they probably will.

Processing Expectations and Policies are protocol developers' ways of saying, "krikey! i have no idea what the deployer will want to do
here." or "if the other side wanted to be evil, they could be. lo= ok
here! we're trusting them to 'do the right thing.'"

So why do we care?

In the virtual world, one of the things we're really big on is
consistency of presentation. It's considered "a good idea" fo= r you to
see largely the same thing the avatar next to you is seeing.
Otherwise, the utility of the virtual world is diminished.

Some virtual worlds allow user developed content and allow the content
creator to place copy restrictions on that content. (we're not naming names here, *cough*Second Life*cough*) =A0Operators of these virtual
worlds have a strong belief it is in their best interest to maintain
those copy restrictions. So... they have a POLICY that says, "when the=
client sends me the message to copy a digital asset and put it in
their virtual pocket, i'm going to check if the creator of that asset says that's okay." The protocol message from the client says "= ;give me
a copy, please" and the server has to decide whether this is a good idea. If the server thinks it's a good idea, it will do it. If not, it<= br> won't.

Other virtual worlds may be pre-stocked with assets and may not allow
users to create new ones. (i'm thinking this is what sametime 3d does,<= br> but i may be wrong.) Still other virtual worlds may be bastions of
free culture coolness and mark everything with a creative commons
license that allows copying, but leaves it up to the participants to
ensure they're not violating the terms of the license.

I think we have general agreement that people who deploy OGP based
virtual worlds should be free to implement whatever policy they want
to implement. The problem comes when we start talking about allowing
avatars to move between region domains in the same virtual world that
MAY have different policies. Linden Lab, the makers of Second Life,
would want some seriously strong assurances from other region domains
that they promise to honor the permissions metadata attached to a
digital asset. Our hypothetical free culture region domain operators
might want assurances that other region domains will not let assets
with a no commercial use CC license =A0be used to create things that are sold.

How will we ever resolve this problem? One way people have tried to
resolve it in the past is by sitting down and writing up legal
agreements. That's because it's a POLICY issue. It's very, very= hard
for a server to guarantee by technical means that a client is using
content only in a way the content's rights-holder allows. So we punt, and just say something like.. "if you sign a contract and let me sue you if you don't honor my policies, i'll let you interact with my systems."

As protocol developers all we have to do now is figure a way to tag
content and interfaces with sufficient meta-data that systems in peer
domains have a good chance of making an informed decision when the
client asks to do something that might violate the license. Or, you
might just deny access to service interfaces to people you don't think<= br> you can trust. But again, it's a POLICY decision. As protocol
developers, our responsibility is to specify meta-data sufficient for
making informed decisions and for defining processes for identifying
trusted peers in the networks.

And.. I'm not making an exhaustive list of "policy issues," m= erely
asserting that there are a reasonably small number of them, and that
we can identify them using a consensus process. By defining these
decisions as "policy issues," it allows us to develop protocol mechanisms that are appropriate for all supported use cases. Thus we
can all collaborate on producing a specification that works for all of
us, but allows each of us to address our specific needs.

I know Prokofy Neva has made statements disagreeing with this approach
in the past, and that she would prefer a virtual worlds protocol that
mandates all virtual worlds adopt second life's C/M/T permissions
model. I believe her justification is that it's too easy for a
misunderstanding or misconfiguration to lead to content leakage.

My counter argument to this is that by developing the protocol in
public, we get more eyeballs looking at the problem domain and we get
more edge cases considered. Because there's a higher probability that problematic edge cases will be identified earlier, we'll get a more
robust protocol.

Is there anyone on the list that takes serious issue with anything
i've said here?

-cheers
-meadhbh
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--0015174c1a225c601b0471c35427-- From dyerbrookme@juno.com Sat Aug 22 20:23:25 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6963A6930 for ; Sat, 22 Aug 2009 20:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHhPzLbyLufW for ; Sat, 22 Aug 2009 20:23:24 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 626873A67F0 for ; Sat, 22 Aug 2009 20:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1250997806; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=X-UNTD-OriginStamp:From:Date:To:Cc:Subject:Message-Id: Content-Type; b=dHEpWgHsvWU0W/nbthMo8pJAe82Ji+kvhUP8JnegESGEkUjvYDXepHOz4ROj69SJr 8nMK3McB+p/oFk6mfYtc4IU7KzrO5aDZAoaVD9Fsv11MBGdtuLxmu/GK+4+9zDgaDX wsDqm3hdbzM/T8mvKJwxlXRmG1zupvVVvq2FsPns= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail09.vgs.untd.com [10.181.12.149]) by smtpout01.vgs.untd.com with SMTP id AABFKBPSZAR4DAHS for (sender ); Sat, 22 Aug 2009 20:23:03 -0700 (PDT) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucfxt0SOiKypRPDqAIbu4+nw7bgsJsmLNig== Received: (from dyerbrookme@juno.com) by webmail09.vgs.untd.com (jqueuemail) id PQMBGGF2; Sat, 22 Aug 2009 20:22:14 PDT Received: from [141.149.49.73] by webmail09.vgs.untd.com with HTTP: Sun, 23 Aug 2009 03:21:07 GMT X-Originating-IP: [141.149.49.73] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sun, 23 Aug 2009 03:21:07 GMT To: infinity@lindenlab.com X-Mailer: Webmail Version 4.0 Message-Id: <20090822.232107.7540.0@webmail09.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:3:966510202 X-MAIL-INFO: 58f9a53da5b881813958353d5805119ce5e521ecb929b1e501017d012d6d6dd16d493cd8008139ed3d4148b97c3188594d15c55d X-UNTD-Peer-Info: 10.181.12.149|webmail09.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: ogpx@ietf.org Subject: Re: [ogpx] The Role of Policy and Processing Expectations in Protocol Development X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 03:23:25 -0000 There's no need to misrepresent what I've been writing, Infinity. You are engaging in policy prescriptions under the guise of "technology"= . It's the method that's been used on previous iterations of the Interne= t, for example, to try to force-feed the ideology of "Free" to cover up = the cost of coders themselves, for example, on Web 1.0 or force-feed the= ideology that "OMGZORZ walled gardens are evil" and we must have sieves= and hooks and pulleys and interop hops in 2.0 I didn't say all words "have to adopt" SL's c/m/t. I said they had to *r= espect* c/m/t or the items shouldn't *lawfully* leave the SL grid. Very = simple proposition. There is no reason why the simple regime of c/m/t ca= n't be accommodated and respected, and not just with notecards. Not ever= ybody sniffs the supersekrit packets on the previous session; if they do= , you have a record and a crime file. As we know, the OpenSim copies content from SL promiscuously and unlawfu= lly and there are a huge number of documented cases of IP theft. Rezzabl= e, maker and seller of BuilderBot, is saying "oh, we can't put creators'= ID because those avatars aren't on our grids so we strip out the inform= ation". Well...if you have to strip out information because those avata= rs don't exist on your grid, that should tell you that...you have unauth= orized property and if you do accept it -- and SL hands it off -- then y= ou are mechanically violating IP. = For the millionth-and-second time, yeah, we get it that the point then i= s not to prevent this "mechanically impossible" (rolls eyes) operation w= hich of course we totally realize is hackable by evil hackers. No, the p= oint is to *record it* so that you can build a crime file. And there are easy ways to deal with this once you aren't hobbled by ide= ology. You have viewers register, such as on this proposal: http://jira.secondlife.com/browse/VWR-14778 A good example of a practical and moderate proposal that is assaulted by= extremists. Prokofy Neva ____________________________________________________________ Need Money for College? Connect to the top online colleges offering financial aid. Free info! http://thirdpartyoffers.juno.com/TGL2141/c?cp=3DM-KmxEvs7GPBmyPQzTm3mQAA= J1BAkQUOY6racJgsKTPwXVdzAAQAAAAFAAAAAB1a5D0AAAAAAAAAAAAAAAAACYhWAAAAAA=3D= =3D From infinity@lindenlab.com Sun Aug 23 00:55:28 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A743A6B7C for ; Sun, 23 Aug 2009 00:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nod9UGtLCh8L for ; Sun, 23 Aug 2009 00:55:27 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id 82EAE3A6928 for ; Sun, 23 Aug 2009 00:55:27 -0700 (PDT) Received: by pzk4 with SMTP id 4so480489pzk.29 for ; Sun, 23 Aug 2009 00:55:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.247.40 with SMTP id u40mr165454wfh.178.1251014128281; Sun, 23 Aug 2009 00:55:28 -0700 (PDT) In-Reply-To: References: <3a880e2c0908221300v2208737fya9aebab75790865b@mail.gmail.com> Date: Sun, 23 Aug 2009 00:55:28 -0700 Message-ID: <3a880e2c0908230055s4a0fef77sa2891b5d606f83a7@mail.gmail.com> From: Infinity Linden To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] The Role of Policy and Processing Expectations inProtocol Development X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 07:55:29 -0000 morgaine. redefining terms does not make fundamental issues go away. the simple fact of the matter is, many of us are interested in implementing virtual spaces that may be comprised of systems with multiple owners. some virtual land owners / administrators might not like some avatars. some users / agent domains may not like some regions or region domains. whether we define them as all being in the same "virtual world" or distinct virtual worlds, it doesn't matter, deployers still need to manage that policy, implementers need to persist information about policy between protocol interactions and protocol developers need to identify where policy should be applied. -meadhbh / infinity On Sat, Aug 22, 2009 at 4:27 PM, Morgaine w= rote: > Separation of policy and mechanism is motherhood and apple pie to us here= . > The problem lies in achieving it, and avoiding any one party imposing the= ir > own policy by shackling the mechanism and denying it the ability to > implement other policies. > > Here's an example of it happening as an artifact of design: > > On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden > wrote: > > I think we have general agreement that people who deploy OGP based virtua= l > worlds should be free to implement whatever policy they want to implement= . > The problem comes when we start talking about allowing avatars to move > between region domains in the same virtual world that MAY have different > policies. > > That's a problem of your own making.=A0 Carlo and I and every open grid > operator understands that all these grids are independent virtual worlds > that have separate policies.=A0 Yet you choose to invent a new meaning fo= r > "virtual world" in which all communicating parties create a "same virtual > world", and then you wonder why you have a problem of varying policies > within your fictitious "same virtual world". > > That's the hub of the matter.=A0 It's not the same virtual world.=A0 It's= two > separate virtual worlds with naturally separate policies that are seeking= to > interoperate.=A0 You've created the problem yourself by defining them to = be > the "same virtual world". > > The "same virtual world" terminology in the current OGP documents is > actually bleeding policy into mechanism, the exact opposite of the > separation we desire. > > It expects uniformity of policies across participating worlds using trust > relationships as tokens of policy conformity.=A0 That's neither feasible = on > principle (because the grids have distinct policies by design), nor is it > feasible technically, because it doesn't scale to Internet sizes in a hig= hly > diverse and multi-jurisdictional physical world. > > > Morgaine. > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden > wrote: >> >> So I too recently wrote a long, rambling narrative in response to >> Carlo's recent message where I tried to concisely explain how we got >> to where we are in the definition of terms like "virtual world" and >> "region domain." But it was pretty long and rambling and took a long >> time to come to the point. I figured I would just come right out and >> get to the point. >> >> We want to separate mechanism from policy in OGP. >> >> A bunch of us have been saying it a lot, but I figured it might be a >> good idea to clearly explain what I think that means. When I say >> "mechanism," I mean things like protocol message formats and >> processing expectations; things like, "if you want to login to such >> and such a virtual world, you send this message with these fields to >> some server out on the network. if the server wants to let you on, it >> will send you this message. if it doesn't, it will send you that >> message." >> >> Here's an auth protocol exchange example from HTTP: >> >> client: hey! server! gimme the resource at >> http://example.org/make/me/a/sandwich.xml >> server: no can do, client. that resource is protected. fear my 401! >> client: what if i give you my super secret password that i swear i >> didn't sniff from another session!? >> server: okay. in that case, sure... 200! >> >> Policy, on the other hand, describes the decision making process >> protocol participants go through to decide which response to give you. >> Returning to the example above, when the server gets an auth request, >> it might have the policy of "I will only let people in who give me a >> valid avatar or account name and password." Yes! that's policy. It's a >> valid idea to let people into a virtual world without a username and >> password; web sites do it all the time. For many applications of >> virtual worlds, it's a very bad idea, but it's the height of conceit >> for me, as a protocol developer, to claim to know the mind of every >> virtual world deployer throughout the world. >> >> But, experience tells me that very bad things can happen in some >> communities when you add anonymity and an audience. But hey, that's >> _your_ call. It could be that your virtual world is only accessible by >> two people in the office, so you always have a good idea who the other >> "anonymous" participant is. Or maybe you work for an old skool company >> where people would never think to be jerks to their fellow employees >> in their "behind the firewall" virtual world. The point is... this >> decision is up to you, the deployer. >> >> Other examples of policy (again on auth) might include things like: >> =A0* i don't trust MD5, so i'll only accept logins that use SHA1 in some >> way, or >> =A0* i'll only let you online if i think you've agreed to my "terms of >> service" document, or >> =A0* i think i don't want anyone to login between 10PM and 7:30AM >> because i'm a BOFH and i need my rest. >> >> There's another term you hear from time to time: "processing >> expectations." This is a term I heard first in the SGML / document >> processing community. I've seen people attempt to give a formal >> definition of this term. My informal definition is... "I know I can't >> force you to do this, but everyone sort of expects this is what you're >> going to do with the data i give you and it would be really nice if >> you would play along, but if you really, really, really need to do >> something else with the data, that's cool. KTHXBAI." >> >> An example of a processing expectation might be: "when the server >> receives a message with a SHA1 hashed password, it will compare the >> hashed password provided with the hashed password stored in the >> database." As a client there's absolutely no way I can force the >> server to actually do this, but assuming servers do want to maintain >> the confidentiality of their users' data, they probably will. >> >> Processing Expectations and Policies are protocol developers' ways of >> saying, "krikey! i have no idea what the deployer will want to do >> here." or "if the other side wanted to be evil, they could be. look >> here! we're trusting them to 'do the right thing.'" >> >> So why do we care? >> >> In the virtual world, one of the things we're really big on is >> consistency of presentation. It's considered "a good idea" for you to >> see largely the same thing the avatar next to you is seeing. >> Otherwise, the utility of the virtual world is diminished. >> >> Some virtual worlds allow user developed content and allow the content >> creator to place copy restrictions on that content. (we're not naming >> names here, *cough*Second Life*cough*) =A0Operators of these virtual >> worlds have a strong belief it is in their best interest to maintain >> those copy restrictions. So... they have a POLICY that says, "when the >> client sends me the message to copy a digital asset and put it in >> their virtual pocket, i'm going to check if the creator of that asset >> says that's okay." The protocol message from the client says "give me >> a copy, please" and the server has to decide whether this is a good >> idea. If the server thinks it's a good idea, it will do it. If not, it >> won't. >> >> Other virtual worlds may be pre-stocked with assets and may not allow >> users to create new ones. (i'm thinking this is what sametime 3d does, >> but i may be wrong.) Still other virtual worlds may be bastions of >> free culture coolness and mark everything with a creative commons >> license that allows copying, but leaves it up to the participants to >> ensure they're not violating the terms of the license. >> >> I think we have general agreement that people who deploy OGP based >> virtual worlds should be free to implement whatever policy they want >> to implement. The problem comes when we start talking about allowing >> avatars to move between region domains in the same virtual world that >> MAY have different policies. Linden Lab, the makers of Second Life, >> would want some seriously strong assurances from other region domains >> that they promise to honor the permissions metadata attached to a >> digital asset. Our hypothetical free culture region domain operators >> might want assurances that other region domains will not let assets >> with a no commercial use CC license =A0be used to create things that are >> sold. >> >> How will we ever resolve this problem? One way people have tried to >> resolve it in the past is by sitting down and writing up legal >> agreements. That's because it's a POLICY issue. It's very, very hard >> for a server to guarantee by technical means that a client is using >> content only in a way the content's rights-holder allows. So we punt, >> and just say something like.. "if you sign a contract and let me sue >> you if you don't honor my policies, i'll let you interact with my >> systems." >> >> As protocol developers all we have to do now is figure a way to tag >> content and interfaces with sufficient meta-data that systems in peer >> domains have a good chance of making an informed decision when the >> client asks to do something that might violate the license. Or, you >> might just deny access to service interfaces to people you don't think >> you can trust. But again, it's a POLICY decision. As protocol >> developers, our responsibility is to specify meta-data sufficient for >> making informed decisions and for defining processes for identifying >> trusted peers in the networks. >> >> And.. I'm not making an exhaustive list of "policy issues," merely >> asserting that there are a reasonably small number of them, and that >> we can identify them using a consensus process. By defining these >> decisions as "policy issues," it allows us to develop protocol >> mechanisms that are appropriate for all supported use cases. Thus we >> can all collaborate on producing a specification that works for all of >> us, but allows each of us to address our specific needs. >> >> I know Prokofy Neva has made statements disagreeing with this approach >> in the past, and that she would prefer a virtual worlds protocol that >> mandates all virtual worlds adopt second life's C/M/T permissions >> model. I believe her justification is that it's too easy for a >> misunderstanding or misconfiguration to lead to content leakage. >> >> My counter argument to this is that by developing the protocol in >> public, we get more eyeballs looking at the problem domain and we get >> more edge cases considered. Because there's a higher probability that >> problematic edge cases will be identified earlier, we'll get a more >> robust protocol. >> >> Is there anyone on the list that takes serious issue with anything >> i've said here? >> >> -cheers >> -meadhbh >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From infinity@lindenlab.com Sun Aug 23 01:08:06 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B833A690F for ; Sun, 23 Aug 2009 01:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.081 X-Spam-Level: X-Spam-Status: No, score=-1.081 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ-k49uI6q5A for ; Sun, 23 Aug 2009 01:08:04 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id B23133A6801 for ; Sun, 23 Aug 2009 01:08:04 -0700 (PDT) Received: by pzk4 with SMTP id 4so482835pzk.29 for ; Sun, 23 Aug 2009 01:08:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.7.3 with SMTP id 3mr175692wfg.126.1251014887214; Sun, 23 Aug 2009 01:08:07 -0700 (PDT) In-Reply-To: References: <3a880e2c0908221300v2208737fya9aebab75790865b@mail.gmail.com> Date: Sun, 23 Aug 2009 01:08:07 -0700 Message-ID: <3a880e2c0908230108k6c1175ebg8db5bcca87797586@mail.gmail.com> From: Infinity Linden To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] The Role of Policy and Processing Expectations inProtocol Development X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 08:08:06 -0000 morgaine. redefining terms does not make fundamental issues go away. the simple fact of the matter is, many of us are interested in implementing virtual spaces that may be comprised of systems with multiple owners. some virtual land owners / administrators might not like some avatars. some users / agent domains may not like some regions or region domains. whether we define them as all being in the same "virtual world" or distinct virtual worlds, it doesn't matter, deployers still need to manage that policy, implementers need to persist information about policy between protocol interactions and protocol developers need to identify where policy should be applied. -meadhbh / infinity On Sat, Aug 22, 2009 at 4:27 PM, Morgaine wrote: > Separation of policy and mechanism is motherhood and apple pie to us here. > The problem lies in achieving it, and avoiding any one party imposing their > own policy by shackling the mechanism and denying it the ability to > implement other policies. > > Here's an example of it happening as an artifact of design: > > On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden > wrote: > > I think we have general agreement that people who deploy OGP based virtual > worlds should be free to implement whatever policy they want to implement. > The problem comes when we start talking about allowing avatars to move > between region domains in the same virtual world that MAY have different > policies. > > That's a problem of your own making. Carlo and I and every open grid > operator understands that all these grids are independent virtual worlds > that have separate policies. Yet you choose to invent a new meaning for > "virtual world" in which all communicating parties create a "same virtual > world", and then you wonder why you have a problem of varying policies > within your fictitious "same virtual world". > > That's the hub of the matter. It's not the same virtual world. It's two > separate virtual worlds with naturally separate policies that are seeking to > interoperate. You've created the problem yourself by defining them to be > the "same virtual world". > > The "same virtual world" terminology in the current OGP documents is > actually bleeding policy into mechanism, the exact opposite of the > separation we desire. > > It expects uniformity of policies across participating worlds using trust > relationships as tokens of policy conformity. That's neither feasible on > principle (because the grids have distinct policies by design), nor is it > feasible technically, because it doesn't scale to Internet sizes in a highly > diverse and multi-jurisdictional physical world. > > > Morgaine. > > > > > > > ================================ > > On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden > wrote: >> >> So I too recently wrote a long, rambling narrative in response to >> Carlo's recent message where I tried to concisely explain how we got >> to where we are in the definition of terms like "virtual world" and >> "region domain." But it was pretty long and rambling and took a long >> time to come to the point. I figured I would just come right out and >> get to the point. >> >> We want to separate mechanism from policy in OGP. >> >> A bunch of us have been saying it a lot, but I figured it might be a >> good idea to clearly explain what I think that means. When I say >> "mechanism," I mean things like protocol message formats and >> processing expectations; things like, "if you want to login to such >> and such a virtual world, you send this message with these fields to >> some server out on the network. if the server wants to let you on, it >> will send you this message. if it doesn't, it will send you that >> message." >> >> Here's an auth protocol exchange example from HTTP: >> >> client: hey! server! gimme the resource at >> http://example.org/make/me/a/sandwich.xml >> server: no can do, client. that resource is protected. fear my 401! >> client: what if i give you my super secret password that i swear i >> didn't sniff from another session!? >> server: okay. in that case, sure... 200! >> >> Policy, on the other hand, describes the decision making process >> protocol participants go through to decide which response to give you. >> Returning to the example above, when the server gets an auth request, >> it might have the policy of "I will only let people in who give me a >> valid avatar or account name and password." Yes! that's policy. It's a >> valid idea to let people into a virtual world without a username and >> password; web sites do it all the time. For many applications of >> virtual worlds, it's a very bad idea, but it's the height of conceit >> for me, as a protocol developer, to claim to know the mind of every >> virtual world deployer throughout the world. >> >> But, experience tells me that very bad things can happen in some >> communities when you add anonymity and an audience. But hey, that's >> _your_ call. It could be that your virtual world is only accessible by >> two people in the office, so you always have a good idea who the other >> "anonymous" participant is. Or maybe you work for an old skool company >> where people would never think to be jerks to their fellow employees >> in their "behind the firewall" virtual world. The point is... this >> decision is up to you, the deployer. >> >> Other examples of policy (again on auth) might include things like: >> * i don't trust MD5, so i'll only accept logins that use SHA1 in some >> way, or >> * i'll only let you online if i think you've agreed to my "terms of >> service" document, or >> * i think i don't want anyone to login between 10PM and 7:30AM >> because i'm a BOFH and i need my rest. >> >> There's another term you hear from time to time: "processing >> expectations." This is a term I heard first in the SGML / document >> processing community. I've seen people attempt to give a formal >> definition of this term. My informal definition is... "I know I can't >> force you to do this, but everyone sort of expects this is what you're >> going to do with the data i give you and it would be really nice if >> you would play along, but if you really, really, really need to do >> something else with the data, that's cool. KTHXBAI." >> >> An example of a processing expectation might be: "when the server >> receives a message with a SHA1 hashed password, it will compare the >> hashed password provided with the hashed password stored in the >> database." As a client there's absolutely no way I can force the >> server to actually do this, but assuming servers do want to maintain >> the confidentiality of their users' data, they probably will. >> >> Processing Expectations and Policies are protocol developers' ways of >> saying, "krikey! i have no idea what the deployer will want to do >> here." or "if the other side wanted to be evil, they could be. look >> here! we're trusting them to 'do the right thing.'" >> >> So why do we care? >> >> In the virtual world, one of the things we're really big on is >> consistency of presentation. It's considered "a good idea" for you to >> see largely the same thing the avatar next to you is seeing. >> Otherwise, the utility of the virtual world is diminished. >> >> Some virtual worlds allow user developed content and allow the content >> creator to place copy restrictions on that content. (we're not naming >> names here, *cough*Second Life*cough*) Operators of these virtual >> worlds have a strong belief it is in their best interest to maintain >> those copy restrictions. So... they have a POLICY that says, "when the >> client sends me the message to copy a digital asset and put it in >> their virtual pocket, i'm going to check if the creator of that asset >> says that's okay." The protocol message from the client says "give me >> a copy, please" and the server has to decide whether this is a good >> idea. If the server thinks it's a good idea, it will do it. If not, it >> won't. >> >> Other virtual worlds may be pre-stocked with assets and may not allow >> users to create new ones. (i'm thinking this is what sametime 3d does, >> but i may be wrong.) Still other virtual worlds may be bastions of >> free culture coolness and mark everything with a creative commons >> license that allows copying, but leaves it up to the participants to >> ensure they're not violating the terms of the license. >> >> I think we have general agreement that people who deploy OGP based >> virtual worlds should be free to implement whatever policy they want >> to implement. The problem comes when we start talking about allowing >> avatars to move between region domains in the same virtual world that >> MAY have different policies. Linden Lab, the makers of Second Life, >> would want some seriously strong assurances from other region domains >> that they promise to honor the permissions metadata attached to a >> digital asset. Our hypothetical free culture region domain operators >> might want assurances that other region domains will not let assets >> with a no commercial use CC license be used to create things that are >> sold. >> >> How will we ever resolve this problem? One way people have tried to >> resolve it in the past is by sitting down and writing up legal >> agreements. That's because it's a POLICY issue. It's very, very hard >> for a server to guarantee by technical means that a client is using >> content only in a way the content's rights-holder allows. So we punt, >> and just say something like.. "if you sign a contract and let me sue >> you if you don't honor my policies, i'll let you interact with my >> systems." >> >> As protocol developers all we have to do now is figure a way to tag >> content and interfaces with sufficient meta-data that systems in peer >> domains have a good chance of making an informed decision when the >> client asks to do something that might violate the license. Or, you >> might just deny access to service interfaces to people you don't think >> you can trust. But again, it's a POLICY decision. As protocol >> developers, our responsibility is to specify meta-data sufficient for >> making informed decisions and for defining processes for identifying >> trusted peers in the networks. >> >> And.. I'm not making an exhaustive list of "policy issues," merely >> asserting that there are a reasonably small number of them, and that >> we can identify them using a consensus process. By defining these >> decisions as "policy issues," it allows us to develop protocol >> mechanisms that are appropriate for all supported use cases. Thus we >> can all collaborate on producing a specification that works for all of >> us, but allows each of us to address our specific needs. >> >> I know Prokofy Neva has made statements disagreeing with this approach >> in the past, and that she would prefer a virtual worlds protocol that >> mandates all virtual worlds adopt second life's C/M/T permissions >> model. I believe her justification is that it's too easy for a >> misunderstanding or misconfiguration to lead to content leakage. >> >> My counter argument to this is that by developing the protocol in >> public, we get more eyeballs looking at the problem domain and we get >> more edge cases considered. Because there's a higher probability that >> problematic edge cases will be identified earlier, we'll get a more >> robust protocol. >> >> Is there anyone on the list that takes serious issue with anything >> i've said here? >> >> -cheers >> -meadhbh >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From carlo@alinoe.com Sun Aug 23 05:18:46 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19C128C0EA for ; Sun, 23 Aug 2009 05:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHJ1nULfrmeC for ; Sun, 23 Aug 2009 05:18:46 -0700 (PDT) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id AC0FD3A6C65 for ; Sun, 23 Aug 2009 05:18:45 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep17-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090823121848.KXGC15272.viefep17-int.chello.at@edge01.upc.biz>; Sun, 23 Aug 2009 14:18:48 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id XoJm1c01r0FlQed01oJnTN; Sun, 23 Aug 2009 14:18:48 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MfC2t-0007rS-HW; Sun, 23 Aug 2009 14:19:39 +0200 Date: Sun, 23 Aug 2009 14:19:39 +0200 From: Carlo Wood To: "dyerbrookme@juno.com" Message-ID: <20090823121939.GA28003@alinoe.com> References: <20090822.232107.7540.0@webmail09.vgs.untd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090822.232107.7540.0@webmail09.vgs.untd.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: infinity@lindenlab.com, ogpx@ietf.org Subject: Re: [ogpx] The Role of Policy and Processing Expectations in Protocol Development X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 12:18:47 -0000 On Sun, Aug 23, 2009 at 03:21:07AM +0000, dyerbrookme@juno.com wrote: > I didn't say all worlds "have to adopt" SL's c/m/t. /me notes that Prokofy uses the word "World" to have the same meaning as Morgaine and me: regions running under a different administration, but still reachable by "teleport" in theory. > I said they had to *respect* c/m/t or > the items shouldn't *lawfully* leave the SL grid. Very simple proposition. There is no > reason why the simple regime of c/m/t can't be accommodated and respected, and not just > with notecards. Of course the protocol will support the Second Life model. But it is policy whether or not to honour the c/m/t bits. I can imagine that if some world (not the use of the word) refuses to sign a legal paper saying they will honour the c/m/t bit in their policy (within reason: as you say yourself, evil hackers can always get around it anyway) then Linden Lab won't trust them with their assets. At this moment no worlds get ANYTHING from Linden Lab (perfect security regarding the OGP: there IS no OGP yet!). Yet, you see "a huge number of IP theft" or so you say (I believe you). Then where in the protocol could we possibly, ever, prohibit that? > As we know, the OpenSim copies content from SL promiscuously and unlawfully and there > are a huge number of documented cases of IP theft. Rezzable, maker and seller of BuilderBot, > is saying "oh, we can't put creators' ID because those avatars aren't on our grids > so we strip out the information". Well...if you have to strip out information because > those avatars don't exist on your grid, that should tell you that... > you have unauthorized property and if you do accept it -- and SL hands it off -- then > you are mechanically violating IP. I have to disagree here. Adding all kinds of complex attempts to enforce technically what cannot be done (sorry, but it's true), you'd only make the protocol NEEDLESS complex. It is way better to keep things mathematically simple and only enforce what is REALLY enforcable. > For the millionth-and-second time, yeah, we get it that the point then is not to prevent this > "mechanically impossible" (rolls eyes) operation which of course we totally realize is > hackable by evil hackers. No, the point is to *record it* so that you can build a crime file. That is 100% policy and has nothing to do with either the protocol or this list, imho. -- Carlo Wood From carlo@alinoe.com Sun Aug 23 05:23:31 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A6228C129 for ; Sun, 23 Aug 2009 05:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBgoO36o+5MW for ; Sun, 23 Aug 2009 05:23:30 -0700 (PDT) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id 5124C28C10A for ; Sun, 23 Aug 2009 05:23:30 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090823122334.CYOF21098.viefep19-int.chello.at@edge03.upc.biz> for ; Sun, 23 Aug 2009 14:23:34 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upc.biz with edge id XoPZ1c00J0FlQed03oPaWo; Sun, 23 Aug 2009 14:23:34 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MfC7W-0007wr-9r for ogpx@ietf.org; Sun, 23 Aug 2009 14:24:26 +0200 Date: Sun, 23 Aug 2009 14:24:26 +0200 From: Carlo Wood To: ogpx@ietf.org Message-ID: <20090823122426.GA30427@alinoe.com> References: <20090822.232107.7540.0@webmail09.vgs.untd.com> <20090823121939.GA28003@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090823121939.GA28003@alinoe.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [ogpx] The Role of Policy and Processing Expectations in Protocol Development X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 12:23:31 -0000 On Sun, Aug 23, 2009 at 02:19:39PM +0200, Carlo Wood wrote: > On Sun, Aug 23, 2009 at 03:21:07AM +0000, dyerbrookme@juno.com wrote: > > I didn't say all worlds "have to adopt" SL's c/m/t. > > /me notes that Prokofy uses the word "World" to have the same meaning as Morgaine and me: > regions running under a different administration, but still reachable by "teleport" in theory. which follows from the next paragraph: > > I said they had to *respect* c/m/t or > > the items shouldn't *lawfully* leave the SL grid. Very simple proposition. There is no > > reason why the simple regime of c/m/t can't be accommodated and respected, and not just > > with notecards. > I can imagine that if some world (not the use of the word) refuses to sign a legal ... I can imagine that if some world (NOTE the use of the word) refuses to sign a legal ... damn typos. -- Carlo Wood From dyerbrookme@juno.com Sun Aug 23 09:51:21 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714FE3A6B38 for ; Sun, 23 Aug 2009 09:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_50=0.001, DIET_1=0.083, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKymxgYAZfZf for ; Sun, 23 Aug 2009 09:51:20 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id A099D3A67A6 for ; Sun, 23 Aug 2009 09:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1251046285; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=X-UNTD-OriginStamp:From:Date:To:Cc:Subject:Message-Id: Content-Type; b=HUYf05SQfTjZ+zlMVHx40kheCFJkWp+6KxsEZwcWe8MjFTwhrYUPdFVQKTlxN4R+r pm4YsAb0Vmw3/aylnPaSnyhRgPK5LPN5zkvhRUqeKp72k+YFxqwizo1ODlLpjmLkL7 /eDtJnc7QXjYCx6yCUJvwioL1WnACjOWsvCypkug= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail02.vgs.untd.com [10.181.12.142]) by smtpout06.vgs.untd.com with SMTP id AABFKC647AQ8FLUS for (sender ); Sun, 23 Aug 2009 09:50:37 -0700 (PDT) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucfxt0SOiKypRJuO7g8GoEiRK7AYEWCunrg== Received: (from dyerbrookme@juno.com) by webmail02.vgs.untd.com (jqueuemail) id PQNRP3XC; Sun, 23 Aug 2009 09:50:18 PDT Received: from [141.149.49.73] by webmail02.vgs.untd.com with HTTP: Sun, 23 Aug 2009 16:49:33 GMT X-Originating-IP: [141.149.49.73] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sun, 23 Aug 2009 16:49:33 GMT To: carlo@alinoe.com X-Mailer: Webmail Version 4.0 Message-Id: <20090823.124933.2263.0@webmail02.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 3:5:4017270327 X-MAIL-INFO: 24e5cc4c2cf5b89d39119dbc05bcede5bcd8a8a99c7cdd18 X-UNTD-Peer-Info: 10.181.12.142|webmail02.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: infinity@lindenlab.com, ogpx@ietf.org Subject: Re: [ogpx] The Role of Policy and Processing Expectations in Protocol Development X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 16:51:21 -0000 = On Sun, Aug 23, 2009 at 03:21:07AM +0000, dyerbrookme@juno.com wrote: > I didn't say all worlds "have to adopt" SL's c/m/t. /me notes that Prokofy uses the word "World" to have the same meaning as= = Morgaine and me: regions running under a different administration, but still reachable by= = "teleport" in theory. I wouldn't make too much of this, because you're merely interpreting a b= rief email. I don't think it's up to technicians to define what a world is. The peop= le in it, who are going to be a mixture of technicians and other profess= ions, will define it. = Who gets to define Belarus -- Belarus, Poland or Russia? = It's this constant arrogation of the powers of world-making that really = don't belong to you that grate. Who died and made you king, or who elect= ed you? When the users -- the customers with use cases -- show up who need this = interoperability most, they will help define what constitutes "world". So far, what you all are doing is arguing back from the worst possible u= se case -- libsecondlifers and reverse-engineers who mainly just want an= extreme sandbox and the ability to copy content in SL -- and building t= he bridge for their purposes which aren't illustrative of a whole civili= zation, but only a decivilization. ____________________________________________________________ Best Weight Loss Program - Click Here! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTFoYduzP2GbBalVqegWQrQ= dnZJeXtZJ8Xdkj3fjshZ7m2jT9pxNM8/ From dyerbrookme@juno.com Sun Aug 23 09:56:16 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37333A6A5A for ; Sun, 23 Aug 2009 09:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0qGRaUnhozn for ; Sun, 23 Aug 2009 09:56:15 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id C0B383A6A71 for ; Sun, 23 Aug 2009 09:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1251046579; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=X-UNTD-OriginStamp:From:Date:To:Cc:Subject:Message-Id: Content-Type; b=Pejs7pFRlprTQQJqr0qR9QZzdn2PnwXsO1O2Z76XNgzsrUZWfQDF5ArnZbDAod+Po GHoOBpMTWNIHdMYqCXnxLmk1FRKvuEvD24F2sA4sUvxUp4pt/1/SVb12RkQOOJyuap FfEAlBALowIa104yRlmhRPUCULd8CEOVdVQf5mWk= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail02.vgs.untd.com [10.181.12.142]) by smtpout04.vgs.untd.com with SMTP id AABFKC7EQA6LGGNJ for (sender ); Sun, 23 Aug 2009 09:55:42 -0700 (PDT) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucfxt0SOiKypRDjPJf8Vszg56ZgdwzSxNNw== Received: (from dyerbrookme@juno.com) by webmail02.vgs.untd.com (jqueuemail) id PQNRZBS6; Sun, 23 Aug 2009 09:55:21 PDT Received: from [141.149.49.73] by webmail02.vgs.untd.com with HTTP: Sun, 23 Aug 2009 16:54:34 GMT X-Originating-IP: [141.149.49.73] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sun, 23 Aug 2009 16:54:34 GMT To: carlo@alinoe.com X-Mailer: Webmail Version 4.0 Message-Id: <20090823.125434.2263.1@webmail02.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:2:3536681215 X-MAIL-INFO: 5325749d74a179c160bdc18009f5d02194b4c4c45419ed7d118921b5b5842514347d25415591199d71e1a134b5b9b979b54d010da5b9602929c9d0b1d035 X-UNTD-Peer-Info: 10.181.12.142|webmail02.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: infinity@lindenlab.com, ogpx@ietf.org Subject: Re: [ogpx] The Role of Policy and Processing Expectations in Protocol Development X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2009 16:56:16 -0000 Carlo, The debates about c/m/t were already held in exhaustive detail apparentl= y before you tuned into this list, so I won't reiterate them, go back in= the archives. I, for one, find it humourous that you all constantly arrogate policy-fo= rmation to yourselves on a whole host of things, and bake your world-vie= ws with abandon right into the tools so they are merged permanently, but= as soon as a user comes along and says: you need the technology to refl= ect *this* policy, you lift up your skirts and run away and say "OMG noe= s that would be policy that has no place in this group/this grid/this OG= P/blah blah". Of course it does, and that's what user-driven software is= all about. You're still hooked up to an old, discredited model of software where ge= eks decide everything in advance, bake it, and then drop the hapless use= r into the pool and tell them it's user error if they don't swim or if t= he tools drown them and their aspirations. No longer acceptable. http://secondthoughts.typepad.com/second_thoughts/2009/02/socialware-the= -next-stage-of-computing-and-communications-or-here-comes-everybody-exce= pt-clay-shirky.html You will not get anywhere with this OGP for your own internal reasons bu= t also for the larger metaversal ones, whereby you are not living in an = era where you can throw the next iteration of the web your way in isolat= ion anymore. Prokofy Neva ____________________________________________________________ Compare PBX Systems Compare leading PBX systems. Save up to 60% on your next PBX. http://thirdpartyoffers.juno.com/TGL2141/c?cp=3D7pMQjvtbnSqFviydJbdkdQAA= J1BAkQUOY6racJgsKTPwXVdzAAQAAAAFAAAAAFg5ND0AAAAAAAAAAAAAAAAABpc2AAAAAA=3D= =3D From infinity@lindenlab.com Tue Aug 25 14:18:43 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064D828C4CC for ; Tue, 25 Aug 2009 14:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.803 X-Spam-Level: X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Natub2HF+R1X for ; Tue, 25 Aug 2009 14:18:42 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id A781D28C485 for ; Tue, 25 Aug 2009 14:18:41 -0700 (PDT) Received: by ewy3 with SMTP id 3so4137674ewy.42 for ; Tue, 25 Aug 2009 14:18:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.25.144 with SMTP id z16mr1408716wez.179.1251235124377; Tue, 25 Aug 2009 14:18:44 -0700 (PDT) Date: Tue, 25 Aug 2009 14:18:44 -0700 Message-ID: <3a880e2c0908251418h62303ecesefedcab32343dd71@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ogpx] OGPX Draft Charter, 2009 08 25 edition X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 21:18:43 -0000 Working Group Name: Open Grid Protocol (OGPX) Chairs: TBD Area and Area Directors: Applications Area Lisa Dusseault Alexey Melnikov Responsible Area Director: TBD Mailing List: ogpx@ietf.org http://www.ietf.org/mailman/listinfo/ogpx Description of Working Group: The working group will define the Open Grid Protocol (OGP) for collaborative 3-dimensional virtual worlds. The protocol permits users to interact with each other while represented as "avatars," or digital representations of the user. Within a single virtual world, avatars exist in at most one location in a shared virtual space. Conforming client applications use the protocol to manipulate and move the user's avatar, create objects in a virtual world, interact with other users and their surroundings and consume and create media and information from sources inside and outside their virtual world. Adjacent locations in virtual worlds accessible by this protocol may be explicitly partitioned into "regions" to facilitate the computational and communication load balancing required to simulate the virtual environment. Such virtual worlds may consist of regions administered by distinct organizations. Though these virtual worlds may be partitioned, they remain "un-sharded;" all inhabitants and objects in a particular location in a virtual world may initiate interaction with all other inhabitants and objects in that location; and, service endpoint addresses refer to at most one location. The state of a virtual world is independent of the client applications that access it and may persist between user sessions. Regions and Services implemented according to the specifications may be deployed by separate organizations with varying policies and trust domains. The OGPX protocols will provide the mechanisms for these virtual world services to interoperate, when permitted by policy and shared trust domains. The protocol should describe interaction semantics for these virtual worlds, independent of transport, leveraging existing standards where practical. It should define interoperability expectations for server to server interactions as well as client-server interactions. Though the protocol is independent of transport, early interoperability trials used HTTP(S) for non-real-time messages. The working group will define specific features that must be replicated in other transports and will define the use of HTTP(S) as a transport of protocol messages. Foundational components of the protocol include the publication of: * an abstract type system, suitable for describing the application protocol in an implementation neutral manner, * a security model describing trust relationships between participating entities, * guidelines for the use of existing authentication and confidentiality mechanisms, * an application-layer protocol for establishing the user's avatar in a virtual world, * an application-layer protocol for moving a user's avatar between adjacent and remote locations in a virtual world, * format descriptions for objects and avatars in a virtual world, and * an application-layer protocol for identifying agents, and requesting information about them. The protocol defined by this group will carry information about the virtual environment, its contents and its inhabitants. It is an application layer protocol, independent of transport, based partially on these previously published internet drafts: * http://tools.ietf.org/html/draft-hamrick-ogp-intro * http://tools.ietf.org/html/draft-hamrick-llsd * http://tools.ietf.org/html/draft-hamrick-ogp-auth * http://tools.ietf.org/html/draft-hamrick-ogp-launch * http://tools.ietf.org/html/draft-lentczner-ogp-base * http://tools.ietf.org/html/draft-levine-ogp-clientcap * http://tools.ietf.org/html/draft-levine-ogp-layering Goals and Milestones: * October 2009 "Introduction and Goals" to the IESG as an Informational RFC * October 2009 "Abstract Type System for the Transmission of Dynamic Structured Data" to the IESG as Proposed Standard * October 2010 "Foundational Concepts and Transport Expectations" to the IESG as Proposed Standard * February 2010 "Guidelines for Host Authentication" to the IESG as an Informational RFC * February 2010 "Service Establishment" to the IESG as Proposed Standard * February 2010 "Client Application Launch Message" to the IESG as an Informational RFC * February 2010 "Simulation Presence Establishment" to the IESG as Proposed Standard * June 2010 "Primitive Object Format" to the IESG as Proposed Standard * June 2010 "Digital Asset Access" to the IESG as Proposed Standard * June 2010 "Entity Identifiers" to the IESG as Proposed standard From carlo@alinoe.com Thu Aug 27 04:01:00 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8313A68F8 for ; Thu, 27 Aug 2009 04:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoMgFFf+2uFm for ; Thu, 27 Aug 2009 04:00:59 -0700 (PDT) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id AFB903A68D0 for ; Thu, 27 Aug 2009 04:00:58 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090827110102.KCKN21098.viefep19-int.chello.at@edge03.upc.biz>; Thu, 27 Aug 2009 13:01:02 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upc.biz with edge id ZP0z1c04J0FlQed03P10tW; Thu, 27 Aug 2009 13:01:02 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mgcjz-0002Ah-Uq; Thu, 27 Aug 2009 13:02:03 +0200 Date: Thu, 27 Aug 2009 13:02:03 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20090827110203.GA6983@alinoe.com> References: <3a880e2c0908251418h62303ecesefedcab32343dd71@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a880e2c0908251418h62303ecesefedcab32343dd71@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX Draft Charter, 2009 08 25 edition X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 11:01:00 -0000 On Tue, Aug 25, 2009 at 02:18:44PM -0700, Infinity Linden wrote: > Within a single virtual world, avatars > exist in at most one location in a shared virtual space. ... > Adjacent locations in virtual worlds accessible by this protocol may > be explicitly partitioned into "regions" to facilitate the > computational and communication load balancing required to simulate > the virtual environment. Such virtual worlds may consist of regions > administered by distinct organizations. I see you insist on using a definition for "virtual world" that does NOT mean "different administrations", but rather means "all reachable regions". However, > Though these virtual worlds > may be partitioned, they remain "un-sharded;" all inhabitants and > objects in a particular location in a virtual world may initiate > interaction with all other inhabitants and objects in that location; > and, service endpoint addresses refer to at most one location. The > state of a virtual world is independent of the client applications > that access it and may persist between user sessions. this paragraph reveals the actual (or additional?) view of what "a virtual world" is: A virtual world are all regions that collaborate under a single avatar domain. Correct me if I'm wrong, but from this I conclude that your vision of a virtual world is a collection of regions that all use a single point (and administration) for authentication of a users avatar (and inventory). For example, one logs in with the agent domain run by LL and than can move between regions and IM every other avatar in "the virtual world" (using the handle of this agent domain provider). If one would prefer to login with a different agent domain provider, it would not be possible to IM every other avatar, or have other interactions such as 'giving' inventory objects to other avatars, and thus one would not be able to be part of the same virtual world. > Regions and Services implemented according to the specifications may > be deployed by separate organizations with varying policies and trust > domains. The OGPX protocols will provide the mechanisms for these > virtual world services to interoperate, when permitted by policy and > shared trust domains. This paragraph is OK. > The protocol should describe interaction semantics for these virtual > worlds, independent of transport, leveraging existing standards where > practical. It should define interoperability expectations for server > to server interactions as well as client-server interactions. Though > the protocol is independent of transport, early interoperability > trials used HTTP(S) for non-real-time messages. The working group will > define specific features that must be replicated in other transports > and will define the use of HTTP(S) as a transport of protocol > messages. OK > Foundational components of the protocol include the publication of: > > * an abstract type system, suitable for describing the application > protocol in an implementation neutral manner, > > * a security model describing trust relationships between > participating entities, > > * guidelines for the use of existing authentication and > confidentiality mechanisms, > > * an application-layer protocol for establishing the user's avatar > in a virtual world, > > * an application-layer protocol for moving a user's avatar between > adjacent and remote locations in a virtual world, > > * format descriptions for objects and avatars in a virtual world, > and > > * an application-layer protocol for identifying agents, and > requesting information about them. > > The protocol defined by this group will carry information about the > virtual environment, its contents and its inhabitants. It is an > application layer protocol, independent of transport, based partially > on these previously published internet drafts: > > * http://tools.ietf.org/html/draft-hamrick-ogp-intro > * http://tools.ietf.org/html/draft-hamrick-llsd > * http://tools.ietf.org/html/draft-hamrick-ogp-auth > * http://tools.ietf.org/html/draft-hamrick-ogp-launch > * http://tools.ietf.org/html/draft-lentczner-ogp-base > * http://tools.ietf.org/html/draft-levine-ogp-clientcap > * http://tools.ietf.org/html/draft-levine-ogp-layering > > Goals and Milestones: > > * October 2009 "Introduction and Goals" to the IESG as an > Informational RFC > > * October 2009 "Abstract Type System for the Transmission of Dynamic > Structured Data" to the IESG as Proposed Standard > > * October 2010 "Foundational Concepts and Transport Expectations" to > the IESG as Proposed Standard > > * February 2010 "Guidelines for Host Authentication" to the IESG as > an Informational RFC > > * February 2010 "Service Establishment" to the IESG as Proposed > Standard > > * February 2010 "Client Application Launch Message" to the IESG as > an Informational RFC > > * February 2010 "Simulation Presence Establishment" to the IESG as > Proposed Standard > > * June 2010 "Primitive Object Format" to the IESG as Proposed > Standard > > * June 2010 "Digital Asset Access" to the IESG as Proposed Standard > > * June 2010 "Entity Identifiers" to the IESG as Proposed standard > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx -- Carlo Wood From infinity@lindenlab.com Thu Aug 27 08:16:35 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775B63A6E1D for ; Thu, 27 Aug 2009 08:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EODnR97v7BGT for ; Thu, 27 Aug 2009 08:16:34 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 0197F3A6BAE for ; Thu, 27 Aug 2009 08:16:33 -0700 (PDT) Received: by ewy3 with SMTP id 3so1270849ewy.42 for ; Thu, 27 Aug 2009 08:16:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.7.81 with SMTP id 59mr1818423weo.219.1251386182873; Thu, 27 Aug 2009 08:16:22 -0700 (PDT) In-Reply-To: <20090827110203.GA6983@alinoe.com> References: <3a880e2c0908251418h62303ecesefedcab32343dd71@mail.gmail.com> <20090827110203.GA6983@alinoe.com> Date: Thu, 27 Aug 2009 08:16:22 -0700 Message-ID: <3a880e2c0908270816lf24ab0eic712f610f4dd6652@mail.gmail.com> From: Infinity Linden To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX Draft Charter, 2009 08 25 edition X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 15:16:35 -0000 On Thu, Aug 27, 2009 at 4:02 AM, Carlo Wood wrote: > On Tue, Aug 25, 2009 at 02:18:44PM -0700, Infinity Linden wrote: >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Within =A0a = single virtual =A0world, avatars >> exist in =A0at most one location =A0in a shared =A0virtual space. > ... >> Adjacent locations =A0in virtual worlds accessible by =A0this protocol m= ay >> be =A0 explicitly =A0 partitioned =A0into =A0 "regions" =A0 to =A0facili= tate =A0 the >> computational =A0and communication load =A0balancing required =A0to simu= late >> the virtual =A0environment. Such virtual =A0worlds may consist =A0of reg= ions >> administered =A0by distinct organizations. > > I see you insist on using a definition for "virtual world" that does > NOT mean "different administrations", but rather means "all reachable > regions". yes. as discussed earlier, "virtual world" is a non-normative definition, and defined from the user's point of view. this definition also allows us to say that "OSGrid is a single virtual world, and not a collection of adjacent virtual worlds." > > However, > >> Though these =A0virtual worlds >> may =A0be partitioned, =A0they =A0remain "un-sharded;" =A0all inhabitant= s =A0and >> objects =A0in a =A0particular location =A0in =A0a virtual =A0world may = =A0initiate >> interaction with =A0all other inhabitants and objects =A0in that locatio= n; >> and, service =A0endpoint addresses =A0refer to at =A0most one =A0locatio= n. The >> state of =A0a virtual =A0world is independent =A0of the =A0client applic= ations >> that access it and may persist between user sessions. > > this paragraph reveals the actual (or additional?) view of what > "a virtual world" is: > > =A0A virtual world are all regions that collaborate under a single avatar= domain. > > Correct me if I'm wrong, but from this I conclude that your vision of > a virtual world is a collection of regions that all use a single point > (and administration) for authentication of a users avatar (and inventory)= . > > For example, one logs in with the agent domain run by LL and than can > move between regions and IM every other avatar in "the virtual world" > (using the handle of this agent domain provider). If one would prefer > to login with a different agent domain provider, it would not be possible > to IM every other avatar, or have other interactions =A0such as 'giving' > inventory objects to other avatars, and thus one would not be able to > be part of the same virtual world. > yes. kind of. there is no reason a region may limit the number of agent domains it accepts to one. so as i said earlier, you could have agent domain A that is trusted by region domains 1, 2 and 3 and agent domain B that is trusted by region domains 3, 4 and 5. Avatars representing users from agent domain A and agent domain B can meet in region domain 3. so, some might say that region domains 1 through 5 are the same virtual world. others might say that domains 1,2 and 3 and 3, 4 and 5 define distinct virtual worlds. ultimately it doesn't matter to the protocol because the term "virtual world" is not used in the protocol definition. or rather, it's not used in a normative fashion. there is no requirement in the protocol that asset services (inventory) be offered by the same administrative entity that offers the user authentication service. this is to support cable beach (or anyone else who wants to decouple user authentication from asset management.) the protocol does not REQUIRE Linden Lab (or any other region domain provider) to choose only a single agent domain to trust. however, it does not REQUIRE that they trust multiple agent domains. it assumes that the region domain will establish a policy of which agent domains it trusts (or even a permissive policy where it will accept protocol interactions from all agent domains. since this is a policy issue, we don't mention it in the charter. that being said, Linden Lab has a number of policies regarding acceptable behavior in it's virtual world, so i would imagine that by policy, Linden would require a foreign agent domain to agree to enforce those policies as a precondition to allowing avatars defined by those agent domains to rez in regions it administers. but again, it's policy, not protocol. which is why we have the next paragraph. >> Regions and =A0Services implemented according to =A0the specifications m= ay >> be deployed by separate =A0organizations with varying policies and trust >> domains. =A0The OGPX =A0protocols will =A0provide the =A0mechanisms =A0f= or these >> virtual world =A0services to interoperate, when permitted =A0by policy a= nd >> shared trust domains. > > This paragraph is OK. > >> The protocol =A0should describe interaction semantics =A0for these virtu= al >> worlds, independent of =A0transport, leveraging existing standards where >> practical. It =A0should define interoperability =A0expectations for serv= er >> to server =A0interactions as well as =A0client-server interactions. Thou= gh >> the =A0protocol =A0is =A0independent =A0of transport, =A0early =A0intero= perability >> trials used HTTP(S) for non-real-time messages. The working group will >> define specific =A0features that must be replicated =A0in other transpor= ts >> and =A0will =A0define =A0the use =A0of =A0HTTP(S) =A0as =A0a transport = =A0of =A0protocol >> messages. > > OK > >> Foundational components of the protocol include the publication of: >> >> =A0 * an abstract =A0type system, suitable for =A0describing the applica= tion >> =A0 =A0 protocol in an implementation neutral manner, >> >> =A0 * a =A0 security =A0 model =A0 describing =A0trust =A0 relationships= =A0 between >> =A0 =A0 participating entities, >> >> =A0 * guidelines =A0 for =A0 the =A0 use =A0 of =A0existing =A0 authenti= cation =A0 and >> =A0 =A0 confidentiality mechanisms, >> >> =A0 * an application-layer =A0protocol for establishing =A0the user's av= atar >> =A0 =A0 in a virtual world, >> >> =A0 * an application-layer =A0protocol for moving a =A0user's avatar bet= ween >> =A0 =A0 adjacent and remote locations in a virtual world, >> >> =A0 * format descriptions =A0for objects and =A0avatars in a =A0virtual = world, >> =A0 =A0 and >> >> =A0 * an =A0 application-layer =A0protocol =A0 for =A0identifying =A0 ag= ents, =A0and >> =A0 =A0 requesting information about them. >> >> The protocol =A0defined by this =A0group will carry information =A0about= the >> virtual =A0environment, =A0its contents =A0and =A0its =A0inhabitants. = =A0It is =A0an >> application layer protocol, =A0independent of transport, based partially >> on these previously published internet drafts: >> >> =A0 * http://tools.ietf.org/html/draft-hamrick-ogp-intro >> =A0 * http://tools.ietf.org/html/draft-hamrick-llsd >> =A0 * http://tools.ietf.org/html/draft-hamrick-ogp-auth >> =A0 * http://tools.ietf.org/html/draft-hamrick-ogp-launch >> =A0 * http://tools.ietf.org/html/draft-lentczner-ogp-base >> =A0 * http://tools.ietf.org/html/draft-levine-ogp-clientcap >> =A0 * http://tools.ietf.org/html/draft-levine-ogp-layering >> >> Goals and Milestones: >> >> =A0 * October =A02009 =A0 "Introduction =A0and =A0Goals" =A0to =A0the = =A0 IESG =A0as =A0an >> =A0 =A0 Informational RFC >> >> =A0 * October 2009 "Abstract Type System for the Transmission of Dynamic >> =A0 =A0 Structured Data" to the IESG as Proposed Standard >> >> =A0 * October 2010 "Foundational Concepts and Transport Expectations" to >> =A0 =A0 the IESG as Proposed Standard >> >> =A0 * February 2010 "Guidelines for =A0Host Authentication" to the IESG = as >> =A0 =A0 an Informational RFC >> >> =A0 * February =A02010 "Service =A0Establishment" =A0to the =A0IESG as = =A0Proposed >> =A0 =A0 Standard >> >> =A0 * February 2010 =A0"Client Application Launch Message" to =A0the IES= G as >> =A0 =A0 an Informational RFC >> >> =A0 * February 2010 =A0"Simulation Presence Establishment" to =A0the IES= G as >> =A0 =A0 Proposed Standard >> >> =A0 * June =A02010 =A0"Primitive Object =A0Format" =A0to =A0the =A0IESG = as =A0Proposed >> =A0 =A0 Standard >> >> =A0 * June 2010 "Digital Asset Access" to the IESG as Proposed Standard >> >> =A0 * June 2010 "Entity Identifiers" to the IESG as Proposed standard >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > -- > Carlo Wood > From infinity@lindenlab.com Thu Aug 27 08:40:56 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517AD3A6E90 for ; Thu, 27 Aug 2009 08:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KK2v3GVggc5 for ; Thu, 27 Aug 2009 08:40:55 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 0AE3D3A6B25 for ; Thu, 27 Aug 2009 08:40:52 -0700 (PDT) Received: by ewy3 with SMTP id 3so1295512ewy.42 for ; Thu, 27 Aug 2009 08:40:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.36.82 with SMTP id v60mr2040024wea.120.1251387653197; Thu, 27 Aug 2009 08:40:53 -0700 (PDT) In-Reply-To: <20090827110203.GA6983@alinoe.com> References: <3a880e2c0908251418h62303ecesefedcab32343dd71@mail.gmail.com> <20090827110203.GA6983@alinoe.com> Date: Thu, 27 Aug 2009 08:40:53 -0700 Message-ID: <3a880e2c0908270840t25908b41q3bdaaf82acd0ae76@mail.gmail.com> From: Infinity Linden To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX Draft Charter, 2009 08 25 edition X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 15:40:57 -0000 oh, one more point about IM. lemme cut out everything else but your relevant comments on IM. On Thu, Aug 27, 2009 at 4:02 AM, Carlo Wood wrote: > Correct me if I'm wrong, but from this I conclude that your vision of > a virtual world is a collection of regions that all use a single point > (and administration) for authentication of a users avatar (and inventory)= . > > For example, one logs in with the agent domain run by LL and than can > move between regions and IM every other avatar in "the virtual world" > (using the handle of this agent domain provider). If one would prefer > to login with a different agent domain provider, it would not be possible > to IM every other avatar, or have other interactions =A0such as 'giving' > inventory objects to other avatars, and thus one would not be able to > be part of the same virtual world. > the protocol does not describe the policy for where IM messages may flow, but rather the mechanism for how the client establishes an IM or voice connection. it does not REQUIRE systems to operate in the way you define. and, in fact, one of the motivations to describing a globally unique URI for each avatar is to allow user agents and client agent domains a service endpoint to query about agent specific features like "how do i IM you?" i think everyone agrees that the existing, legacy user-to-user and group IM system for second life is sub-optimal, won't scale to the bazillions of users we want to enable with this protocol and shouldn't be used in a new design. many people think we should just use XMPP or IRC and be done with it. and there are some compelling arguments in favor of this approach. the work of this group would be to define the mechanism of establishing, maintaining and closing chat or voice communication sessions, and the format for addresses used to identify the source and destination of messages. this is a very roundabout way of saying, it SHOULD be possible that a group hosted on a Linden Lab agent domain may contain members that are themselves registered by a foreign agent domain (let's say OSGrid.) but before the Linden Lab agent domain would allow messages to flow to (or from) users with accounts on a foreign agent domain, policy may require that foreign agent domain to agree to enforce various bits of Linden's terms of service. so in other words, i think the prevailing thinking is that we define mechanisms that defines how to get a message across the wire and how to identify endpoints so you can use someone's avatar descriptor or group descriptor to resolve the IP address of the system you want to start speaking this protocol to. once that is defined, individual operators will decide what they want to do with regards to letting messages from foreign agent domains into their systems. so, in other words, the "virtual world" is also not defined by the agent domain. it's another reason i kind of dislike the term from a protocol perspective. it is evocative, but clearly non-normative. -cheers -meadhbh From infinity@lindenlab.com Thu Aug 27 09:14:53 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B61C3A6909 for ; Thu, 27 Aug 2009 09:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLsA1CTImSzM for ; Thu, 27 Aug 2009 09:14:52 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 1233A3A68EB for ; Thu, 27 Aug 2009 09:14:51 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so280418eye.51 for ; Thu, 27 Aug 2009 09:14:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.53.12 with SMTP id f12mr1901484wec.72.1251389693568; Thu, 27 Aug 2009 09:14:53 -0700 (PDT) In-Reply-To: <3a880e2c0908251418h62303ecesefedcab32343dd71@mail.gmail.com> References: <3a880e2c0908251418h62303ecesefedcab32343dd71@mail.gmail.com> Date: Thu, 27 Aug 2009 09:14:53 -0700 Message-ID: <3a880e2c0908270914r185e9e93h3fa89b18c4372b8e@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [ogpx] OGPX Draft Charter, 2009 08 25 edition X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 16:14:53 -0000 hmm, so we expanded the single sentence fragment describing the existence of policy into a paragraph and got this... On Tue, Aug 25, 2009 at 2:18 PM, Infinity Linden wr= ote: > > Regions and =A0Services implemented according to =A0the specifications ma= y > be deployed by separate =A0organizations with varying policies and trust > domains. =A0The OGPX =A0protocols will =A0provide the =A0mechanisms =A0fo= r these > virtual world =A0services to interoperate, when permitted =A0by policy an= d > shared trust domains. > should we explicitly say that the work of the group will include defining a non-exhaustive list of places in the protocol where policy may be inserted? so we would get something like this instead: "Regions and services implemented according to the specifications may be deployed by separate organizations with varying policies and trust domains. The OGPX protocols will provide the mechanisms for these virtual world services to interoperate, when permitted by policy and shared trust domains. To support the exegesis of the specifications, the group may define a non-exhaustive set of non-normative policies protocol participants may enforce." so the idea here is that if it makes sense to define a policy for the purpose of explaining the protocol, we will. but just because a policy is described does not mean it must be implemented or that policies other than the ones included in the text are invalid. thoughts? From josh@lindenlab.com Thu Aug 27 09:26:32 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DEB43A6D65 for ; Thu, 27 Aug 2009 09:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACqOH+mwPifF for ; Thu, 27 Aug 2009 09:26:31 -0700 (PDT) Received: from mail-px0-f202.google.com (mail-px0-f202.google.com [209.85.216.202]) by core3.amsl.com (Postfix) with ESMTP id 94AE928C1FB for ; Thu, 27 Aug 2009 09:26:31 -0700 (PDT) Received: by pxi40 with SMTP id 40so1164847pxi.5 for ; Thu, 27 Aug 2009 09:26:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.48.9 with SMTP id a9mr4283077rvk.249.1251390395494; Thu, 27 Aug 2009 09:26:35 -0700 (PDT) In-Reply-To: <479011.65903.qm@web111210.mail.gq1.yahoo.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> Date: Thu, 27 Aug 2009 09:26:35 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cd22bd2ffb1580472220760 Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 16:26:32 -0000 --000e0cd22bd2ffb1580472220760 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit It seems like we're close on draft charter text; the recent discussion has generated some good additions and clarifications to the text. We still need a name, though. Given a lack of consensus on any of the proposals for a protocol name, I suggest we reduce the problem to just a group name, and defer any protocol naming for now. * The working group name is for "casual" use; i.e. it will never be published in an RFC * The working group should have a limited lifetime, and dissolve; so something "eternal" or "ideal" is actually a bad idea * It should be clear how to pronounce and spell, so that it can be communicated in voice * It should be recognizable when seen on an IETF agenda I agree with Morgaine's points earlier on this thread about names, but feel they primarily apply to protocol names, except for the excellent suggestion that this be something relatively unique in Google searches. That is somewhat in (healthy) conflict with the above points, though. Going back to Infinity's suggestion of listing top choices, here are mine from the floated proposals. I don't really have a #3. Again, I'm focusing on proposed working group names only, so in context these would be 1. Agent Based Open Virtual Environments Working Group - ABOVE ("above") 2. Virtual World Region/Agent Protocol Working Group - VWRAP ("v-wrap") If you believe that the latest rev of the draft charter text is acceptable as a basis for forming a working group (and remember, a group can re-charter!), please reply with your top picks. --000e0cd22bd2ffb1580472220760 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It seems like we're close on draft charter text; the recent discussion = has generated some good additions and clarifications to the text. We still = need a name, though.

Given a lack of consensus on any of the proposa= ls for a protocol name, I suggest we reduce the problem to just a group nam= e, and defer any protocol naming for now.

* The working group name is for "casual" use; i.e. it will ne= ver be published in an RFC
* The working group should have a limited lif= etime, and dissolve; so something "eternal" or "ideal" = is actually a bad idea
* It should be clear how to pronounce and spell, so that it can be communic= ated in voice
* It should be recognizable when seen on an IETF agenda
I agree with Morgaine's points earlier on this thread about names= , but feel they primarily apply to protocol names, except for the excellent= suggestion that this be something relatively unique in Google searches. Th= at is somewhat in (healthy) conflict with the above points, though.

Going back to Infinity's suggestion of listing top choices, here ar= e mine from the floated proposals. I don't really have a #3. Again, I&#= 39;m focusing on proposed working group names only, so in context these wou= ld be

1. Agent Based Open Virtual Environments Working Group - ABOVE ("a= bove")
2. Virtual World Region/Agent Protocol Working Group - VWRAP= ("v-wrap")

If you believe that the latest rev of the draf= t charter text is acceptable as a basis for forming a working group (and re= member, a group can re-charter!), please reply with your top picks.

--000e0cd22bd2ffb1580472220760-- From infinity@lindenlab.com Thu Aug 27 09:38:51 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3E33A6C49 for ; Thu, 27 Aug 2009 09:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KG3RwEDu37PS for ; Thu, 27 Aug 2009 09:38:50 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 0A33C28C280 for ; Thu, 27 Aug 2009 09:37:55 -0700 (PDT) Received: by ewy3 with SMTP id 3so1351976ewy.42 for ; Thu, 27 Aug 2009 09:37:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.11.138 with SMTP id 10mr1908246wex.51.1251391077286; Thu, 27 Aug 2009 09:37:57 -0700 (PDT) In-Reply-To: References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> Date: Thu, 27 Aug 2009 09:37:57 -0700 Message-ID: <3a880e2c0908270937j73fe7567t8779d193135d0b5f@mail.gmail.com> From: Infinity Linden To: Joshua Bell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 16:38:51 -0000 hmm.. i fear that if we don't define a protocol name, people will simply call it "the ABOVE protocol," so we'll get a de facto name. and, there are several places in the existing drafts that use the term OGP, replacing that string with "this protocol" or "the protocol defined by ABOVE" would get kind of old. but yeah, i think what i'm saying is while we can separate the protocol name from the group name and we might be able to get away with not mentioning the protocol name in the charter, we'll need a protocol name pretty quick so we can use it in the IDs. -cheers -meadhbh On Thu, Aug 27, 2009 at 9:26 AM, Joshua Bell wrote: > It seems like we're close on draft charter text; the recent discussion has > generated some good additions and clarifications to the text. We still need > a name, though. > > Given a lack of consensus on any of the proposals for a protocol name, I > suggest we reduce the problem to just a group name, and defer any protocol > naming for now. > > * The working group name is for "casual" use; i.e. it will never be > published in an RFC > * The working group should have a limited lifetime, and dissolve; so > something "eternal" or "ideal" is actually a bad idea > * It should be clear how to pronounce and spell, so that it can be > communicated in voice > * It should be recognizable when seen on an IETF agenda > > I agree with Morgaine's points earlier on this thread about names, but feel > they primarily apply to protocol names, except for the excellent suggestion > that this be something relatively unique in Google searches. That is > somewhat in (healthy) conflict with the above points, though. > > Going back to Infinity's suggestion of listing top choices, here are mine > from the floated proposals. I don't really have a #3. Again, I'm focusing on > proposed working group names only, so in context these would be > > 1. Agent Based Open Virtual Environments Working Group - ABOVE ("above") > 2. Virtual World Region/Agent Protocol Working Group - VWRAP ("v-wrap") > > If you believe that the latest rev of the draft charter text is acceptable > as a basis for forming a working group (and remember, a group can > re-charter!), please reply with your top picks. > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From morgaine.dinova@googlemail.com Fri Aug 28 04:16:08 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCA33A6E42 for ; Fri, 28 Aug 2009 04:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8SRBXQkcJHX for ; Fri, 28 Aug 2009 04:16:07 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 815833A6F9E for ; Fri, 28 Aug 2009 04:16:06 -0700 (PDT) Received: by ewy3 with SMTP id 3so321093ewy.42 for ; Fri, 28 Aug 2009 04:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=+EXgoRfDqJcJNqtwviRDnJ5h4H94vDqIZ15BKl9w6bQ=; b=KnRjueQOyB6xDVXIVvPcsU1Iv/fAPskfwk+MYSj0WHB20yrWeoNHcqJoO9Q6Z9IL5/ 6VZcab7238XTRO0YgrL2zzTZIlYZ/VBP5yc9Pj+WlWjHMZJpuOIpullwcBTRsaOg/act ORZe55NVtyT0hQtXDgGf+Xaz/u6fmu2nu6Vk0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=QuqPCrcL/rAIxRtrpvaNjo9Dy13fRytHt8iLEBPKJlm6BstHDmVVGgjCaLIhIy1M/B OOdIhxHeHzIfLvgSUGdfvB3U946svZOeB3Izhbujjf3F43S/fpOfKcRCyDin0OvxcUTY 3xhT+xjMMfomoPk2MwszH7QI/YSHvhh8R7Tm0= MIME-Version: 1.0 Received: by 10.211.147.5 with SMTP id z5mr1062996ebn.87.1251458169083; Fri, 28 Aug 2009 04:16:09 -0700 (PDT) In-Reply-To: References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> Date: Fri, 28 Aug 2009 12:16:09 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636c5b94a9e95b5047231cf66 Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 11:16:08 -0000 --001636c5b94a9e95b5047231cf66 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 27, 2009 at 5:26 PM, Joshua Bell wrote: > > 1. Agent Based Open Virtual Environments Working Group - ABOVE ("above") > 2. Virtual World Region/Agent Protocol Working Group - VWRAP ("v-wrap") > I support the *Region/Agent* part of #2 because it refers to the central idea in this proposal that makes it distinct from other interop protocols. In particular, it distinguishes this work from other proposals that would be in the scope of MMOX. In contrast, the *Virtual World* part of #2 just adds fuel to the problems that have been highlighted here about the redefinition of this phrase in OGP compared to its use by everyone else in this sphere. That issue isn't going away, and will become ever harder as we begin to focus on use cases for cross-world interop. Building upon *Region/Agent*, various other possible constructs for the group name come to mind. Note that the "world[s]" issue can be avoided while retaining *Virtual*: - Region/Agent Domain Interop Group -- RADIG - Virtual Region/Agent Interop Group -- VRAIG - Virtual Region/Agent eXchange group -- VRAX group - Virtual Region/Agent Interop X -- VRAIX, X = {proto, group, apps} - Virtual Region/Agent Domain group -- VRAD group - Virtual Domains Interop Protocol/Group -- VDIP/VDIG - and so on ("Virtual Domains" actually reflects the central idea well) Note that simply dropping "World" from your #2 achieves the same thing and makes it more pronounceable: - Virtual Region/Agent Protocol / Working Group - VRAP ("vrap") As you pointed out, the group name is not as crucial as the eventual protocol name, but as Infinity mentioned, the group name suggests a de facto protocol name so we can't leave the latter dangling for too long. I suspect that a protocol name that differs from the group name will just sow confusion, and doesn't add value. It may be best to go through this ordeal just once. Morgaine. ======================= On Thu, Aug 27, 2009 at 5:26 PM, Joshua Bell wrote: > It seems like we're close on draft charter text; the recent discussion has > generated some good additions and clarifications to the text. We still need > a name, though. > > Given a lack of consensus on any of the proposals for a protocol name, I > suggest we reduce the problem to just a group name, and defer any protocol > naming for now. > > * The working group name is for "casual" use; i.e. it will never be > published in an RFC > * The working group should have a limited lifetime, and dissolve; so > something "eternal" or "ideal" is actually a bad idea > * It should be clear how to pronounce and spell, so that it can be > communicated in voice > * It should be recognizable when seen on an IETF agenda > > I agree with Morgaine's points earlier on this thread about names, but feel > they primarily apply to protocol names, except for the excellent suggestion > that this be something relatively unique in Google searches. That is > somewhat in (healthy) conflict with the above points, though. > > Going back to Infinity's suggestion of listing top choices, here are mine > from the floated proposals. I don't really have a #3. Again, I'm focusing on > proposed working group names only, so in context these would be > > 1. Agent Based Open Virtual Environments Working Group - ABOVE ("above") > 2. Virtual World Region/Agent Protocol Working Group - VWRAP ("v-wrap") > > If you believe that the latest rev of the draft charter text is acceptable > as a basis for forming a working group (and remember, a group can > re-charter!), please reply with your top picks. > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --001636c5b94a9e95b5047231cf66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Aug 27, 2009 at 5:26 PM, Joshua Bell <josh@lindenlab.com> wrote:
=

1. Agent Based Open Virtual Environments Working Group - ABOVE ("a= bove")
2. Virtual World Region/Agent Protocol Working Group - VWRAP= ("v-wrap")
=A0
I support the Region/Agent = part of #2 because it refers to=A0 the central idea in this proposal that m= akes it distinct from other interop protocols.=A0 In particular, it disting= uishes this work from other proposals that would be in the scope of MMOX.
In contrast, the Virtual World part of #2 just adds fuel to the = problems that have been highlighted here about the redefinition of this phr= ase in OGP compared to its use by everyone else in this sphere.=A0 That iss= ue isn't going away, and will become ever harder as we begin to focus o= n use cases for cross-world interop.

Building upon Region/Agent, various other possible constructs fo= r the group name come to mind.=A0 Note that the "world[s]" issue = can be avoided while retaining Virtual:

  • Region/Agent = Domain Interop Group -- RADIG
  • Virtual Region/Agent Interop Group -- VRAIG
  • Virtual Region/Agen= t eXchange group -- VRAX group
  • Virtual Region/Agent Interop X -- VR= AIX, X =3D {proto, group, apps}
  • Virtual Region/Agent Domain gro= up -- VRAD group
  • Virtual Domains Interop Protocol/Group -- VDIP/VDIG
  • and so = on ("Virtual Domains" actually reflects the central idea well)
Note that simply dropping "World" from your #2 achieve= s the same thing and makes it more pronounceable:

  • Virtual Region/Agent Protocol / Working Group - VRAP ("vra= p")

As you pointed out, the group name is not as crucial = as the eventual protocol name, but as Infinity mentioned, the group name su= ggests a de facto protocol name so we can't leave the latter dangling f= or too long.=A0 I suspect that a protocol name that differs from the group = name will just sow confusion, and doesn't add value.

It may be best to go through this ordeal just once.


Morgaine= .





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

On Thu, Aug 27, 200= 9 at 5:26 PM, Joshua Bell <josh@lindenlab.com> wrote:
It seems like we&= #39;re close on draft charter text; the recent discussion has generated som= e good additions and clarifications to the text. We still need a name, thou= gh.

Given a lack of consensus on any of the proposals for a protocol name, = I suggest we reduce the problem to just a group name, and defer any protoco= l naming for now.

* The working group name is for "casual" use; i.e. it will ne= ver be published in an RFC
* The working group should have a limited lif= etime, and dissolve; so something "eternal" or "ideal" = is actually a bad idea
* It should be clear how to pronounce and spell, so that it can be communic= ated in voice
* It should be recognizable when seen on an IETF agenda
I agree with Morgaine's points earlier on this thread about names= , but feel they primarily apply to protocol names, except for the excellent= suggestion that this be something relatively unique in Google searches. Th= at is somewhat in (healthy) conflict with the above points, though.

Going back to Infinity's suggestion of listing top choices, here ar= e mine from the floated proposals. I don't really have a #3. Again, I&#= 39;m focusing on proposed working group names only, so in context these wou= ld be

1. Agent Based Open Virtual Environments Working Group - ABOVE ("a= bove")
2. Virtual World Region/Agent Protocol Working Group - VWRAP= ("v-wrap")

If you believe that the latest rev of the draf= t charter text is acceptable as a basis for forming a working group (and re= member, a group can re-charter!), please reply with your top picks.


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--001636c5b94a9e95b5047231cf66-- From carlo@alinoe.com Fri Aug 28 05:16:22 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4F93A6BF0 for ; Fri, 28 Aug 2009 05:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge1I6FcMdt8w for ; Fri, 28 Aug 2009 05:16:22 -0700 (PDT) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id 87E133A6E9F for ; Fri, 28 Aug 2009 05:16:21 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep17-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090828121627.RPAE15272.viefep17-int.chello.at@edge01.upc.biz>; Fri, 28 Aug 2009 14:16:27 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id ZoGP1c0AF0FlQed01oGRdh; Fri, 28 Aug 2009 14:16:27 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mh0OZ-0005gv-75; Fri, 28 Aug 2009 14:17:31 +0200 Date: Fri, 28 Aug 2009 14:17:31 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20090828121731.GA18068@alinoe.com> References: <3a880e2c0908251418h62303ecesefedcab32343dd71@mail.gmail.com> <3a880e2c0908270914r185e9e93h3fa89b18c4372b8e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a880e2c0908270914r185e9e93h3fa89b18c4372b8e@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX Draft Charter, 2009 08 25 edition X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 12:16:22 -0000 On Thu, Aug 27, 2009 at 09:14:53AM -0700, Infinity Linden wrote: > should we explicitly say that the work of the group will include > defining a non-exhaustive list of places in the protocol where policy > may be inserted? > > so we would get something like this instead: > > "Regions and services implemented according to the specifications > may be deployed by separate organizations with varying policies and > trust domains. The OGPX protocols will provide the mechanisms for > these virtual world services to interoperate, when permitted by > policy and shared trust domains. To support the exegesis of the > specifications, the group may define a non-exhaustive set of > non-normative policies protocol participants may enforce." > > so the idea here is that if it makes sense to define a policy for the > purpose of explaining the protocol, we will. but just because a policy > is described does not mean it must be implemented or that policies > other than the ones included in the text are invalid. > > thoughts? Seems like a good idea. It would clarify things a lot. -- Carlo Wood From morgaine.dinova@googlemail.com Fri Aug 28 06:46:32 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D303A6948 for ; Fri, 28 Aug 2009 06:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.808 X-Spam-Level: X-Spam-Status: No, score=-0.808 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N1pfhKDfu42 for ; Fri, 28 Aug 2009 06:46:29 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id E94473A67D2 for ; Fri, 28 Aug 2009 06:46:28 -0700 (PDT) Received: by ewy6 with SMTP id 6so373285ewy.10 for ; Fri, 28 Aug 2009 06:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=tP76h4FfysIjqtc15MQ81QNUYG4IRGlcj/GpP/7BhJ0=; b=DIU5bATtb2UkTk+8AmcrBrT1auHzEa5tfCZmGyypsyA5IF2lBPEEgbrb+L6wZXYa11 FiJAICwV4RCbt3SLEFOHWRpRoIAtXNypvcUwBRIawSvzqMdo0RuB+mQ9LhXnkKBYrgxX W0rr3CfWjl6nda1q6E4Lm6PYAf2MdpXw0JURA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=HjGXE4SgB76GjyHS1IAiPbfOMyR5x1cAuGj2XNbdAPA7SI/zapGyS8y2sIMBhRRdGP VdMfVBtpA2cOKcO2CKPmuzalugosfAvHZ1Bezrrs6+/NPJVLUqCsYvxLZVr+Fz6ATFK+ rFJZ5EiSG8x+ROmwkVvIfwklxu6XnQ2DHMAXQ= MIME-Version: 1.0 Received: by 10.210.71.2 with SMTP id t2mr323245eba.57.1251467191614; Fri, 28 Aug 2009 06:46:31 -0700 (PDT) In-Reply-To: <3a880e2c0908230108k6c1175ebg8db5bcca87797586@mail.gmail.com> References: <3a880e2c0908221300v2208737fya9aebab75790865b@mail.gmail.com> <3a880e2c0908230108k6c1175ebg8db5bcca87797586@mail.gmail.com> Date: Fri, 28 Aug 2009 14:46:31 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174c371c677cf2047233e982 Subject: Re: [ogpx] The Role of Policy and Processing Expectations inProtocol Development X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 13:46:32 -0000 --0015174c371c677cf2047233e982 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 23, 2009 at 9:08 AM, Infinity Linden wrote: morgaine. redefining terms does not make fundamental issues go away. I couldn't have put it better myself. And this is why the redefinition of cross-world interop as taking place in the "same virtual world" will not make the issues of cross-world interop go away. We have to face those issues anyway. Adding that language achieved nothing and just obscured the intent. Clear intent is important. These problems aren't rocket science, but they do require concentrating on the actual technical details surrounding asset flow between worlds rather than handwaving them away with weak, non-technical, non-scalable, and non-enforceable policy agreements *that are not actual entities in the protocol*. The sooner we start addressing the cross-world details at the protocol level, the closer we will be to an OGP that can actually provide cross-world interop. Every mention of trust agreements just waves a magic wand at this instead of addressing it. Certificate technology is a given. It's great for identifying endpoints and securing sessions, but that's all it does. It doesn't add magic, and it doesn't address cross-world interop at all except at the trivial "no-interop" point. All the hard work still remains to be done. A stronger focus on actual networking protocol elements and less redefinition of non-protocol elements would get us a long way. Morgaine. ================================ On Sun, Aug 23, 2009 at 9:08 AM, Infinity Linden wrote: > morgaine. redefining terms does not make fundamental issues go away. > > the simple fact of the matter is, many of us are interested in > implementing virtual spaces that may be comprised of systems with > multiple owners. some virtual land owners / administrators might not > like some avatars. some users / agent domains may not like some > regions or region domains. whether we define them as all being in the > same "virtual world" or distinct virtual worlds, it doesn't matter, > deployers still need to manage that policy, implementers need to > persist information about policy between protocol interactions and > protocol developers need to identify where policy should be applied. > > -meadhbh / infinity > > On Sat, Aug 22, 2009 at 4:27 PM, Morgaine > wrote: > > Separation of policy and mechanism is motherhood and apple pie to us > here. > > The problem lies in achieving it, and avoiding any one party imposing > their > > own policy by shackling the mechanism and denying it the ability to > > implement other policies. > > > > Here's an example of it happening as an artifact of design: > > > > On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden > > > wrote: > > > > I think we have general agreement that people who deploy OGP based > virtual > > worlds should be free to implement whatever policy they want to > implement. > > The problem comes when we start talking about allowing avatars to move > > between region domains in the same virtual world that MAY have different > > policies. > > > > That's a problem of your own making. Carlo and I and every open grid > > operator understands that all these grids are independent virtual worlds > > that have separate policies. Yet you choose to invent a new meaning for > > "virtual world" in which all communicating parties create a "same virtual > > world", and then you wonder why you have a problem of varying policies > > within your fictitious "same virtual world". > > > > That's the hub of the matter. It's not the same virtual world. It's two > > separate virtual worlds with naturally separate policies that are seeking > to > > interoperate. You've created the problem yourself by defining them to be > > the "same virtual world". > > > > The "same virtual world" terminology in the current OGP documents is > > actually bleeding policy into mechanism, the exact opposite of the > > separation we desire. > > > > It expects uniformity of policies across participating worlds using trust > > relationships as tokens of policy conformity. That's neither feasible on > > principle (because the grids have distinct policies by design), nor is it > > feasible technically, because it doesn't scale to Internet sizes in a > highly > > diverse and multi-jurisdictional physical world. > > > > > > Morgaine. > > > > > > > > > > > > > > ================================ > > > > On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden > > > wrote: > >> > >> So I too recently wrote a long, rambling narrative in response to > >> Carlo's recent message where I tried to concisely explain how we got > >> to where we are in the definition of terms like "virtual world" and > >> "region domain." But it was pretty long and rambling and took a long > >> time to come to the point. I figured I would just come right out and > >> get to the point. > >> > >> We want to separate mechanism from policy in OGP. > >> > >> A bunch of us have been saying it a lot, but I figured it might be a > >> good idea to clearly explain what I think that means. When I say > >> "mechanism," I mean things like protocol message formats and > >> processing expectations; things like, "if you want to login to such > >> and such a virtual world, you send this message with these fields to > >> some server out on the network. if the server wants to let you on, it > >> will send you this message. if it doesn't, it will send you that > >> message." > >> > >> Here's an auth protocol exchange example from HTTP: > >> > >> client: hey! server! gimme the resource at > >> http://example.org/make/me/a/sandwich.xml > >> server: no can do, client. that resource is protected. fear my 401! > >> client: what if i give you my super secret password that i swear i > >> didn't sniff from another session!? > >> server: okay. in that case, sure... 200! > >> > >> Policy, on the other hand, describes the decision making process > >> protocol participants go through to decide which response to give you. > >> Returning to the example above, when the server gets an auth request, > >> it might have the policy of "I will only let people in who give me a > >> valid avatar or account name and password." Yes! that's policy. It's a > >> valid idea to let people into a virtual world without a username and > >> password; web sites do it all the time. For many applications of > >> virtual worlds, it's a very bad idea, but it's the height of conceit > >> for me, as a protocol developer, to claim to know the mind of every > >> virtual world deployer throughout the world. > >> > >> But, experience tells me that very bad things can happen in some > >> communities when you add anonymity and an audience. But hey, that's > >> _your_ call. It could be that your virtual world is only accessible by > >> two people in the office, so you always have a good idea who the other > >> "anonymous" participant is. Or maybe you work for an old skool company > >> where people would never think to be jerks to their fellow employees > >> in their "behind the firewall" virtual world. The point is... this > >> decision is up to you, the deployer. > >> > >> Other examples of policy (again on auth) might include things like: > >> * i don't trust MD5, so i'll only accept logins that use SHA1 in some > >> way, or > >> * i'll only let you online if i think you've agreed to my "terms of > >> service" document, or > >> * i think i don't want anyone to login between 10PM and 7:30AM > >> because i'm a BOFH and i need my rest. > >> > >> There's another term you hear from time to time: "processing > >> expectations." This is a term I heard first in the SGML / document > >> processing community. I've seen people attempt to give a formal > >> definition of this term. My informal definition is... "I know I can't > >> force you to do this, but everyone sort of expects this is what you're > >> going to do with the data i give you and it would be really nice if > >> you would play along, but if you really, really, really need to do > >> something else with the data, that's cool. KTHXBAI." > >> > >> An example of a processing expectation might be: "when the server > >> receives a message with a SHA1 hashed password, it will compare the > >> hashed password provided with the hashed password stored in the > >> database." As a client there's absolutely no way I can force the > >> server to actually do this, but assuming servers do want to maintain > >> the confidentiality of their users' data, they probably will. > >> > >> Processing Expectations and Policies are protocol developers' ways of > >> saying, "krikey! i have no idea what the deployer will want to do > >> here." or "if the other side wanted to be evil, they could be. look > >> here! we're trusting them to 'do the right thing.'" > >> > >> So why do we care? > >> > >> In the virtual world, one of the things we're really big on is > >> consistency of presentation. It's considered "a good idea" for you to > >> see largely the same thing the avatar next to you is seeing. > >> Otherwise, the utility of the virtual world is diminished. > >> > >> Some virtual worlds allow user developed content and allow the content > >> creator to place copy restrictions on that content. (we're not naming > >> names here, *cough*Second Life*cough*) Operators of these virtual > >> worlds have a strong belief it is in their best interest to maintain > >> those copy restrictions. So... they have a POLICY that says, "when the > >> client sends me the message to copy a digital asset and put it in > >> their virtual pocket, i'm going to check if the creator of that asset > >> says that's okay." The protocol message from the client says "give me > >> a copy, please" and the server has to decide whether this is a good > >> idea. If the server thinks it's a good idea, it will do it. If not, it > >> won't. > >> > >> Other virtual worlds may be pre-stocked with assets and may not allow > >> users to create new ones. (i'm thinking this is what sametime 3d does, > >> but i may be wrong.) Still other virtual worlds may be bastions of > >> free culture coolness and mark everything with a creative commons > >> license that allows copying, but leaves it up to the participants to > >> ensure they're not violating the terms of the license. > >> > >> I think we have general agreement that people who deploy OGP based > >> virtual worlds should be free to implement whatever policy they want > >> to implement. The problem comes when we start talking about allowing > >> avatars to move between region domains in the same virtual world that > >> MAY have different policies. Linden Lab, the makers of Second Life, > >> would want some seriously strong assurances from other region domains > >> that they promise to honor the permissions metadata attached to a > >> digital asset. Our hypothetical free culture region domain operators > >> might want assurances that other region domains will not let assets > >> with a no commercial use CC license be used to create things that are > >> sold. > >> > >> How will we ever resolve this problem? One way people have tried to > >> resolve it in the past is by sitting down and writing up legal > >> agreements. That's because it's a POLICY issue. It's very, very hard > >> for a server to guarantee by technical means that a client is using > >> content only in a way the content's rights-holder allows. So we punt, > >> and just say something like.. "if you sign a contract and let me sue > >> you if you don't honor my policies, i'll let you interact with my > >> systems." > >> > >> As protocol developers all we have to do now is figure a way to tag > >> content and interfaces with sufficient meta-data that systems in peer > >> domains have a good chance of making an informed decision when the > >> client asks to do something that might violate the license. Or, you > >> might just deny access to service interfaces to people you don't think > >> you can trust. But again, it's a POLICY decision. As protocol > >> developers, our responsibility is to specify meta-data sufficient for > >> making informed decisions and for defining processes for identifying > >> trusted peers in the networks. > >> > >> And.. I'm not making an exhaustive list of "policy issues," merely > >> asserting that there are a reasonably small number of them, and that > >> we can identify them using a consensus process. By defining these > >> decisions as "policy issues," it allows us to develop protocol > >> mechanisms that are appropriate for all supported use cases. Thus we > >> can all collaborate on producing a specification that works for all of > >> us, but allows each of us to address our specific needs. > >> > >> I know Prokofy Neva has made statements disagreeing with this approach > >> in the past, and that she would prefer a virtual worlds protocol that > >> mandates all virtual worlds adopt second life's C/M/T permissions > >> model. I believe her justification is that it's too easy for a > >> misunderstanding or misconfiguration to lead to content leakage. > >> > >> My counter argument to this is that by developing the protocol in > >> public, we get more eyeballs looking at the problem domain and we get > >> more edge cases considered. Because there's a higher probability that > >> problematic edge cases will be identified earlier, we'll get a more > >> robust protocol. > >> > >> Is there anyone on the list that takes serious issue with anything > >> i've said here? > >> > >> -cheers > >> -meadhbh > >> _______________________________________________ > >> ogpx mailing list > >> ogpx@ietf.org > >> https://www.ietf.org/mailman/listinfo/ogpx > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --0015174c371c677cf2047233e982 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Aug 23, 2009 at 9:08 AM, Infinity Linden <infinity@lindenlab.= com> wrote:

morgaine= . redefining terms does not make fundamental issues go away.

I couldn't have put it better myself.=A0 And this is why the r= edefinition of cross-world interop as taking place in the "same virtua= l world" will not make the issues of cross-world interop go away.=A0 W= e have to face those issues anyway.=A0 Adding that language achieved nothin= g and just obscured the intent.=A0 Clear intent is important.

These problems aren't rocket science, but they do require concentra= ting on the actual technical details surrounding asset flow between worlds = rather than handwaving them away with weak, non-technical, non-scalable, an= d non-enforceable policy agreements that are not actual entities in the = protocol.

The sooner we start addressing the cross-world details at the pro= tocol level, the closer we will be to an OGP that can actually provide cros= s-world interop.=A0 Every mention of trust agreements just waves a magic wa= nd at this instead of addressing it.

Certificate technology is a given.=A0 It's great for identifying en= dpoints and securing sessions, but that's all it does.=A0 It doesn'= t add magic, and it doesn't address cross-world interop at all except a= t the trivial "no-interop" point.=A0 All the hard work still rema= ins to be done.

A stronger focus on actual networking protocol elements and less redefi= nition of non-protocol elements would get us a long way.

Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Sun, Aug 23, 2009 at 9:08 AM, Infinity Linden <infinity@lindenlab.= com> wrote:
morgaine. re= defining terms does not make fundamental issues go away.

the simple fact of the matter is, many of us are interested in
implementing virtual spaces that may be comprised of systems with
multiple owners. some virtual land owners / administrators might not
like some avatars. some users / agent domains may not like some
regions or region domains. whether we define them as all being in the
same "virtual world" or distinct virtual worlds, it doesn't m= atter,
deployers still need to manage that policy, implementers need to
persist information about policy between protocol interactions and
protocol developers need to identify where policy should be applied.

-meadhbh / infinity

On Sat, Aug 22, 2009 at 4:27 PM, Morgaine<morgaine.dinova@googlemail.com>= ; wrote:
> Separation of policy and mechanism is mothe= rhood and apple pie to us here.
> The problem lies in achieving it, and avoiding any one party imposing = their
> own policy by shackling the mechanism and denying it the ability to > implement other policies.
>
> Here's an example of it happening as an artifact of design:
>
> On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden <infinity@lindenlab.com> > wrote:
>
> I think we have general agreement that people who deploy OGP based vir= tual
> worlds should be free to implement whatever policy they want to implem= ent.
> The problem comes when we start talking about allowing avatars to move=
> between region domains in the same virtual world that MAY have differe= nt
> policies.
>
> That's a problem of your own making. =A0Carlo and I and every open= grid
> operator understands that all these grids are independent virtual worl= ds
> that have separate policies. =A0Yet you choose to invent a new meaning= for
> "virtual world" in which all communicating parties create a = "same virtual
> world", and then you wonder why you have a problem of varying pol= icies
> within your fictitious "same virtual world".
>
> That's the hub of the matter. =A0It's not the same virtual wor= ld. =A0It's two
> separate virtual worlds with naturally separate policies that are seek= ing to
> interoperate. =A0You've created the problem yourself by defining t= hem to be
> the "same virtual world".
>
> The "same virtual world" terminology in the current OGP docu= ments is
> actually bleeding policy into mechanism, the exact opposite of the
> separation we desire.
>
> It expects uniformity of policies across participating worlds using tr= ust
> relationships as tokens of policy conformity. =A0That's neither fe= asible on
> principle (because the grids have distinct policies by design), nor is= it
> feasible technically, because it doesn't scale to Internet sizes i= n a highly
> diverse and multi-jurisdictional physical world.
>
>
> Morgaine.
>
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On Sat, Aug 22, 2009 at 9:00 PM, Infinity Linden <infinity@lindenlab.com> > wrote:
>>
>> So I too recently wrote a long, rambling narrative in response to<= br> >> Carlo's recent message where I tried to concisely explain how = we got
>> to where we are in the definition of terms like "virtual worl= d" and
>> "region domain." But it was pretty long and rambling and= took a long
>> time to come to the point. I figured I would just come right out a= nd
>> get to the point.
>>
>> We want to separate mechanism from policy in OGP.
>>
>> A bunch of us have been saying it a lot, but I figured it might be= a
>> good idea to clearly explain what I think that means. When I say >> "mechanism," I mean things like protocol message formats= and
>> processing expectations; things like, "if you want to login t= o such
>> and such a virtual world, you send this message with these fields = to
>> some server out on the network. if the server wants to let you on,= it
>> will send you this message. if it doesn't, it will send you th= at
>> message."
>>
>> Here's an auth protocol exchange example from HTTP:
>>
>> client: hey! server! gimme the resource at
>> http://example.org/make/me/a/sandwich.xml
>> server: no can do, client. that resource is protected. fear my 401= !
>> client: what if i give you my super secret password that i swear i=
>> didn't sniff from another session!?
>> server: okay. in that case, sure... 200!
>>
>> Policy, on the other hand, describes the decision making process >> protocol participants go through to decide which response to give = you.
>> Returning to the example above, when the server gets an auth reque= st,
>> it might have the policy of "I will only let people in who gi= ve me a
>> valid avatar or account name and password." Yes! that's p= olicy. It's a
>> valid idea to let people into a virtual world without a username a= nd
>> password; web sites do it all the time. For many applications of >> virtual worlds, it's a very bad idea, but it's the height = of conceit
>> for me, as a protocol developer, to claim to know the mind of ever= y
>> virtual world deployer throughout the world.
>>
>> But, experience tells me that very bad things can happen in some >> communities when you add anonymity and an audience. But hey, that&= #39;s
>> _your_ call. It could be that your virtual world is only accessibl= e by
>> two people in the office, so you always have a good idea who the o= ther
>> "anonymous" participant is. Or maybe you work for an old= skool company
>> where people would never think to be jerks to their fellow employe= es
>> in their "behind the firewall" virtual world. The point = is... this
>> decision is up to you, the deployer.
>>
>> Other examples of policy (again on auth) might include things like= :
>> =A0* i don't trust MD5, so i'll only accept logins that us= e SHA1 in some
>> way, or
>> =A0* i'll only let you online if i think you've agreed to = my "terms of
>> service" document, or
>> =A0* i think i don't want anyone to login between 10PM and 7:3= 0AM
>> because i'm a BOFH and i need my rest.
>>
>> There's another term you hear from time to time: "process= ing
>> expectations." This is a term I heard first in the SGML / doc= ument
>> processing community. I've seen people attempt to give a forma= l
>> definition of this term. My informal definition is... "I know= I can't
>> force you to do this, but everyone sort of expects this is what yo= u're
>> going to do with the data i give you and it would be really nice i= f
>> you would play along, but if you really, really, really need to do=
>> something else with the data, that's cool. KTHXBAI."
>>
>> An example of a processing expectation might be: "when the se= rver
>> receives a message with a SHA1 hashed password, it will compare th= e
>> hashed password provided with the hashed password stored in the >> database." As a client there's absolutely no way I can fo= rce the
>> server to actually do this, but assuming servers do want to mainta= in
>> the confidentiality of their users' data, they probably will.<= br> >>
>> Processing Expectations and Policies are protocol developers' = ways of
>> saying, "krikey! i have no idea what the deployer will want t= o do
>> here." or "if the other side wanted to be evil, they cou= ld be. look
>> here! we're trusting them to 'do the right thing.'&quo= t;
>>
>> So why do we care?
>>
>> In the virtual world, one of the things we're really big on is=
>> consistency of presentation. It's considered "a good idea= " for you to
>> see largely the same thing the avatar next to you is seeing.
>> Otherwise, the utility of the virtual world is diminished.
>>
>> Some virtual worlds allow user developed content and allow the con= tent
>> creator to place copy restrictions on that content. (we're not= naming
>> names here, *cough*Second Life*cough*) =A0Operators of these virtu= al
>> worlds have a strong belief it is in their best interest to mainta= in
>> those copy restrictions. So... they have a POLICY that says, "= ;when the
>> client sends me the message to copy a digital asset and put it in<= br> >> their virtual pocket, i'm going to check if the creator of tha= t asset
>> says that's okay." The protocol message from the client s= ays "give me
>> a copy, please" and the server has to decide whether this is = a good
>> idea. If the server thinks it's a good idea, it will do it. If= not, it
>> won't.
>>
>> Other virtual worlds may be pre-stocked with assets and may not al= low
>> users to create new ones. (i'm thinking this is what sametime = 3d does,
>> but i may be wrong.) Still other virtual worlds may be bastions of=
>> free culture coolness and mark everything with a creative commons<= br> >> license that allows copying, but leaves it up to the participants = to
>> ensure they're not violating the terms of the license.
>>
>> I think we have general agreement that people who deploy OGP based=
>> virtual worlds should be free to implement whatever policy they wa= nt
>> to implement. The problem comes when we start talking about allowi= ng
>> avatars to move between region domains in the same virtual world t= hat
>> MAY have different policies. Linden Lab, the makers of Second Life= ,
>> would want some seriously strong assurances from other region doma= ins
>> that they promise to honor the permissions metadata attached to a<= br> >> digital asset. Our hypothetical free culture region domain operato= rs
>> might want assurances that other region domains will not let asset= s
>> with a no commercial use CC license =A0be used to create things th= at are
>> sold.
>>
>> How will we ever resolve this problem? One way people have tried t= o
>> resolve it in the past is by sitting down and writing up legal
>> agreements. That's because it's a POLICY issue. It's v= ery, very hard
>> for a server to guarantee by technical means that a client is usin= g
>> content only in a way the content's rights-holder allows. So w= e punt,
>> and just say something like.. "if you sign a contract and let= me sue
>> you if you don't honor my policies, i'll let you interact = with my
>> systems."
>>
>> As protocol developers all we have to do now is figure a way to ta= g
>> content and interfaces with sufficient meta-data that systems in p= eer
>> domains have a good chance of making an informed decision when the=
>> client asks to do something that might violate the license. Or, yo= u
>> might just deny access to service interfaces to people you don'= ;t think
>> you can trust. But again, it's a POLICY decision. As protocol<= br> >> developers, our responsibility is to specify meta-data sufficient = for
>> making informed decisions and for defining processes for identifyi= ng
>> trusted peers in the networks.
>>
>> And.. I'm not making an exhaustive list of "policy issues= ," merely
>> asserting that there are a reasonably small number of them, and th= at
>> we can identify them using a consensus process. By defining these<= br> >> decisions as "policy issues," it allows us to develop pr= otocol
>> mechanisms that are appropriate for all supported use cases. Thus = we
>> can all collaborate on producing a specification that works for al= l of
>> us, but allows each of us to address our specific needs.
>>
>> I know Prokofy Neva has made statements disagreeing with this appr= oach
>> in the past, and that she would prefer a virtual worlds protocol t= hat
>> mandates all virtual worlds adopt second life's C/M/T permissi= ons
>> model. I believe her justification is that it's too easy for a=
>> misunderstanding or misconfiguration to lead to content leakage. >>
>> My counter argument to this is that by developing the protocol in<= br> >> public, we get more eyeballs looking at the problem domain and we = get
>> more edge cases considered. Because there's a higher probabili= ty that
>> problematic edge cases will be identified earlier, we'll get a= more
>> robust protocol.
>>
>> Is there anyone on the list that takes serious issue with anything=
>> i've said here?
>>
>> -cheers
>> -meadhbh
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx
>
>

--0015174c371c677cf2047233e982-- From dhc@dcrocker.net Fri Aug 28 08:17:04 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10EF23A6F88 for ; Fri, 28 Aug 2009 08:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j239BSHjXEKF for ; Fri, 28 Aug 2009 08:17:03 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7148]) by core3.amsl.com (Postfix) with ESMTP id D3C9B3A6E10 for ; Fri, 28 Aug 2009 08:17:02 -0700 (PDT) Received: from [127.0.0.1] (ppp-68-120-198-98.dsl.pltn13.pacbell.net [68.120.198.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n7SFH3fn027888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Aug 2009 08:17:08 -0700 Message-ID: <4A97F4EA.2030803@dcrocker.net> Date: Fri, 28 Aug 2009 08:16:58 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ogpx@ietf.org References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <3a880e2c0908270937j73fe7567t8779d193135d0b5f@mail.gmail.com> In-Reply-To: <3a880e2c0908270937j73fe7567t8779d193135d0b5f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 28 Aug 2009 08:17:08 -0700 (PDT) Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 15:17:04 -0000 Infinity Linden wrote: > but yeah, i think what i'm saying is while we can separate the > protocol name from the group name and we might be able to get away > with not mentioning the protocol name in the charter, we'll need a > protocol name pretty quick so we can use it in the IDs. If the working group were going to deal with a number of independent (but related) specifications, each of which would have their own name, then giving the working group yet-a-different name would make sense. And no, it's not the end of the world one way or the other, but it IS less confusing to have the wg name and the primary specification name match. The comment about a name that is too common a word, like ABOVE, is well-taken. I think vwrap is reasonable. (It also permits flights of analogy and other whimsy. Not essential, of course, but can add some entertainment to a community effort...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From infinity@lindenlab.com Fri Aug 28 08:21:42 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE3B3A6872 for ; Fri, 28 Aug 2009 08:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0dWtdCYQLcz for ; Fri, 28 Aug 2009 08:21:41 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 64ABE3A659C for ; Fri, 28 Aug 2009 08:21:41 -0700 (PDT) Received: by ewy3 with SMTP id 3so511733ewy.42 for ; Fri, 28 Aug 2009 08:21:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.52.76 with SMTP id d54mr264945wec.119.1251472904245; Fri, 28 Aug 2009 08:21:44 -0700 (PDT) In-Reply-To: <4A97F4EA.2030803@dcrocker.net> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <3a880e2c0908270937j73fe7567t8779d193135d0b5f@mail.gmail.com> <4A97F4EA.2030803@dcrocker.net> Date: Fri, 28 Aug 2009 08:21:44 -0700 Message-ID: <3a880e2c0908280821v44782ac7u6deedc7335faae80@mail.gmail.com> From: Infinity Linden To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 15:21:42 -0000 but above is just so cool! On Fri, Aug 28, 2009 at 8:16 AM, Dave CROCKER wrote: > > > Infinity Linden wrote: >> >> but yeah, i think what i'm saying is while we can separate the >> protocol name from the group name and we might be able to get away >> with not mentioning the protocol name in the charter, we'll need a >> protocol name pretty quick so we can use it in the IDs. > > > If the working group were going to deal with a number of independent (but > related) specifications, each of which would have their own name, then > giving the working group yet-a-different name would make sense. =A0And no= , > it's not the end of the world one way or the other, but it IS less confus= ing > to have the wg name and the primary specification name match. > > The comment about a name that is too common a word, like ABOVE, is > well-taken. > > I think vwrap is reasonable. > > (It also permits flights of analogy and other whimsy. =A0Not essential, o= f > course, but can add some entertainment to a community effort...) > > d/ > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From infinity@lindenlab.com Fri Aug 28 08:23:38 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B6D3A6872 for ; Fri, 28 Aug 2009 08:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVEboHYym9dL for ; Fri, 28 Aug 2009 08:23:38 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id CB6CF3A67E9 for ; Fri, 28 Aug 2009 08:23:36 -0700 (PDT) Received: by ewy3 with SMTP id 3so513267ewy.42 for ; Fri, 28 Aug 2009 08:23:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.88.146 with SMTP id a18mr250642wef.56.1251473019125; Fri, 28 Aug 2009 08:23:39 -0700 (PDT) In-Reply-To: <4A97F4EA.2030803@dcrocker.net> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <3a880e2c0908270937j73fe7567t8779d193135d0b5f@mail.gmail.com> <4A97F4EA.2030803@dcrocker.net> Date: Fri, 28 Aug 2009 08:23:39 -0700 Message-ID: <3a880e2c0908280823y564193f2n513c1e16929a4cde@mail.gmail.com> From: Infinity Linden To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 15:23:39 -0000 but seriously, seems like we're getting close. VWRAP seems reasonable, even though it suffers from the ATM Machine problem= . On Fri, Aug 28, 2009 at 8:16 AM, Dave CROCKER wrote: > > > Infinity Linden wrote: >> >> but yeah, i think what i'm saying is while we can separate the >> protocol name from the group name and we might be able to get away >> with not mentioning the protocol name in the charter, we'll need a >> protocol name pretty quick so we can use it in the IDs. > > > If the working group were going to deal with a number of independent (but > related) specifications, each of which would have their own name, then > giving the working group yet-a-different name would make sense. =A0And no= , > it's not the end of the world one way or the other, but it IS less confus= ing > to have the wg name and the primary specification name match. > > The comment about a name that is too common a word, like ABOVE, is > well-taken. > > I think vwrap is reasonable. > > (It also permits flights of analogy and other whimsy. =A0Not essential, o= f > course, but can add some entertainment to a community effort...) > > d/ > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From josh@lindenlab.com Fri Aug 28 08:48:37 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA75528C3F4 for ; Fri, 28 Aug 2009 08:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1CfggNiLqZz for ; Fri, 28 Aug 2009 08:48:36 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 3597328C409 for ; Fri, 28 Aug 2009 08:48:30 -0700 (PDT) Received: by pzk38 with SMTP id 38so2048022pzk.5 for ; Fri, 28 Aug 2009 08:48:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.20.19 with SMTP id x19mr555881rvi.66.1251474513132; Fri, 28 Aug 2009 08:48:33 -0700 (PDT) In-Reply-To: References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> Date: Fri, 28 Aug 2009 08:48:33 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cd1a8fcccfe1f0472359d9e Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 15:48:37 -0000 --000e0cd1a8fcccfe1f0472359d9e Content-Type: text/plain; charset=UTF-8 On Fri, Aug 28, 2009 at 4:16 AM, Morgaine wrote: > On Thu, Aug 27, 2009 at 5:26 PM, Joshua Bell wrote: > >> >> 1. Agent Based Open Virtual Environments Working Group - ABOVE ("above") >> 2. Virtual World Region/Agent Protocol Working Group - VWRAP ("v-wrap") >> > > I support the *Region/Agent* part of #2 because it refers to the central > idea in this proposal that makes it distinct from other interop protocols. > In particular, it distinguishes this work from other proposals that would be > in the scope of MMOX. > > In contrast, the *Virtual World* part of #2 just adds fuel to the problems > that have been highlighted here about the redefinition of this phrase in OGP > compared to its use by everyone else in this sphere. That issue isn't going > away, and will become ever harder as we begin to focus on use cases for > cross-world interop. > That's a healthy concern, but I think we need to bite the bullet and risk the dreaded "Virtual World" phrase in the name. It is *so* evocative to anyone inside and outside the space and leaves little ambiguity about the problem domain. No, it isn't specific enough, hence the qualifiers. MMOX suffered from being far too broad a name (MMO = WoW to most of the planet). VW is still broad, but I think we can handle it. After all, while we're focused on the subset of VWs that share Region/Agent concepts, the protocols may appeal to others. (And it's not limited to the domain, of course; I was trying to evangelize LLSD in Stockholm.) Dropping "World" leaves phrases that only make sense to people in the know. I would expect "Virtual Region" or more so "Virtual Domain" to invite queries from far afield within the IETF ("Virtual domain? is that like DDNS kicked up a notch?") So... like others, I guess I'm putting my voice behind "VWRAP" - kudos to Carlo for the suggestion. Can list participants agree to VWRAP as "not perfect, but good enough" and move past the name issue to real interop work? --000e0cd1a8fcccfe1f0472359d9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 28, 2009 at 4:16 AM, Morgaine <morgaine.= dinova@googlemail.com> wrote:
On Thu, Aug 27, 2009 at 5:26 PM, Joshua Bell <josh@lind= enlab.com> wrote:

1. Agent Based Open Virtual Environments Working Group - ABOVE ("a= bove")
2. Virtual World Region/Agent Protocol Working Group - VWRAP= ("v-wrap")
=C2=A0
I support the Region/A= gent part of #2 because it refers to=C2=A0 the central idea in this pro= posal that makes it distinct from other interop protocols.=C2=A0 In particu= lar, it distinguishes this work from other proposals that would be in the s= cope of MMOX.

In contrast, the Virtual World part of #2 just adds fuel to the = problems that have been highlighted here about the redefinition of this phr= ase in OGP compared to its use by everyone else in this sphere.=C2=A0 That = issue isn't going away, and will become ever harder as we begin to focu= s on use cases for cross-world interop.

That's a healthy concern, but I think we need to= bite the bullet and risk the dreaded "Virtual World" phrase in t= he name. It is *so* evocative to anyone inside and outside the space and le= aves little ambiguity about the problem domain. No, it isn't specific e= nough, hence the qualifiers.

MMOX suffered from being far too broad a name (MMO =3D WoW to most of t= he planet). VW is still broad, but I think we can handle it. After all, whi= le we're focused on the subset of VWs that share Region/Agent concepts,= the protocols may appeal to others. (And it's not limited to the domai= n, of course; I was trying to evangelize LLSD in Stockholm.)

Dropping "World" leaves phrases that only make sense to peopl= e in the know. I would expect "Virtual Region" or more so "V= irtual Domain" to invite queries from far afield within the IETF (&quo= t;Virtual domain? is that like DDNS kicked up a notch?")

So... like others, I guess I'm putting my voice behind "VWRAP&= quot; - kudos to Carlo for the suggestion.

Can list participants ag= ree to VWRAP as "not perfect, but good enough" and move past the = name issue to real interop work?

--000e0cd1a8fcccfe1f0472359d9e-- From dhc@dcrocker.net Fri Aug 28 09:56:36 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0564D3A6E39 for ; Fri, 28 Aug 2009 09:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTpqr2u++b1R for ; Fri, 28 Aug 2009 09:56:35 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7148]) by core3.amsl.com (Postfix) with ESMTP id B54C53A63D3 for ; Fri, 28 Aug 2009 09:56:34 -0700 (PDT) Received: from [127.0.0.1] (ppp-68-120-198-98.dsl.pltn13.pacbell.net [68.120.198.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n7SGuZPe001237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2009 09:56:40 -0700 Message-ID: <4A980C3E.4090909@dcrocker.net> Date: Fri, 28 Aug 2009 09:56:30 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joshua Bell References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 28 Aug 2009 09:56:40 -0700 (PDT) Cc: ogpx@ietf.org Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 16:56:36 -0000 Joshua Bell wrote: > That's a healthy concern, but I think we need to bite the bullet and > risk the dreaded "Virtual World" phrase in the name. It is *so* > evocative to anyone inside and outside the space and leaves little > ambiguity about the problem domain. No, it isn't specific enough, hence > the qualifiers. I've been meaning to comment on this. As someone outside the space, I do find the term helpful as the common label for the space. No one is going to think this is about cloud computing, file transfer, or voice calls... And while it might be nice to have that term extend into a precise technical construct, I'm not sure it's essential. So, the current work becomes an /example/ of virtual world work, but has its own vocabulary. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From morgaine.dinova@googlemail.com Fri Aug 28 10:56:10 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64ECD3A6963 for ; Fri, 28 Aug 2009 10:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T7byFriBLft for ; Fri, 28 Aug 2009 10:56:09 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 5641E3A6821 for ; Fri, 28 Aug 2009 10:56:08 -0700 (PDT) Received: by ewy3 with SMTP id 3so637301ewy.42 for ; Fri, 28 Aug 2009 10:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=AvJLV0ttCMfz2nHlcJptwP0V1Dlpg+axyOkLciijjJM=; b=QRzkGIddiqIgkVuWFQgLmaJ2VlHNEjstPJK6vSGdiZQT4pa//LSB+uKfuIALKnB+Db fc6tH9yeV4C202LW5ndBEKGC0ckdeJJJ2t7GrzhKgX3yy8vvpAr6MERStMwdUNuHkdo7 sKF1DQ0JJKYB/mtJ5PE7MLvAWiUY9ddyciemU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=dIdV/QcbRmuYxcfcAI+f7U5UHCaAIs/bezV/VeiXwGOn6vvCZ1WjebODlPpoZQ+ZV1 xhcBFCJQJ+Guqsvj9ogwwGuLgzCnDXnqsvX+ZG6tNeOi9Jusk0VYSnLwRg/5+uiz6Elp Q+DDjPdnx6waMasVDIPVxrVjqml/nnRfRdnas= MIME-Version: 1.0 Received: by 10.211.154.16 with SMTP id g16mr1634945ebo.19.1251482171987; Fri, 28 Aug 2009 10:56:11 -0700 (PDT) In-Reply-To: References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> Date: Fri, 28 Aug 2009 18:56:11 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00504502c8734dd5ed04723766d4 Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 17:56:10 -0000 --00504502c8734dd5ed04723766d4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 28, 2009 at 4:48 PM, Joshua Bell wrote: > > Can list participants agree to VWRAP as "not perfect, but good enough" and > move past the name issue to real interop work? > I vote +1 for this to move us ahead. The group name doesn't matter too much, and even if a de facto name sticks, it's still got the *Region/Agent* part to it which is very appropriate and distinguishes it from other protocols. Morgaine. --00504502c8734dd5ed04723766d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 28, 2009 at 4:48 PM, Joshua = Bell <josh@linde= nlab.com> wrote:

Can list participants agree to VWRAP as "not perfect, but good eno= ugh" and move past the name issue to real interop work?

I vote +1 for this to move us ahead.

The group= name doesn't matter too much, and even if a de facto name sticks, it&#= 39;s still got the Region/Agent part to it which is very appropriate= and distinguishes it from other protocols.


Morgaine.



--00504502c8734dd5ed04723766d4-- From mike.dickson@hp.com Fri Aug 28 11:20:34 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D523A682E for ; Fri, 28 Aug 2009 11:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSWqs61Tq2uZ for ; Fri, 28 Aug 2009 11:20:31 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by core3.amsl.com (Postfix) with ESMTP id A7BC43A6A67 for ; Fri, 28 Aug 2009 11:20:31 -0700 (PDT) Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0028.austin.hp.com (Postfix) with ESMTPS id 3C9D21C62A; Fri, 28 Aug 2009 18:20:38 +0000 (UTC) Received: from G4W0659.americas.hpqcorp.net (16.234.40.187) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 28 Aug 2009 18:20:22 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G4W0659.americas.hpqcorp.net ([16.234.40.187]) with mapi; Fri, 28 Aug 2009 18:20:22 +0000 From: "Dickson, Mike (ISS Software)" To: Morgaine , "ogpx@ietf.org" Date: Fri, 28 Aug 2009 18:19:10 +0000 Thread-Topic: [ogpx] resolving the name issue Thread-Index: AcooCNisSwX4M2TYTsOMxlwJORIWXgAAxRbA Message-ID: <4646639E08F58B42836FAC24C94624DD6FE8098411@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD6FE8098411GVW0433EXBame_" MIME-Version: 1.0 Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 18:20:35 -0000 --_000_4646639E08F58B42836FAC24C94624DD6FE8098411GVW0433EXBame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 to move the discussion forward. I don't love it but its fine as a worki= ng name. From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of Mor= gaine Sent: Friday, August 28, 2009 12:56 PM To: ogpx@ietf.org Subject: Re: [ogpx] resolving the name issue On Fri, Aug 28, 2009 at 4:48 PM, Joshua Bell > wrote: Can list participants agree to VWRAP as "not perfect, but good enough" and = move past the name issue to real interop work? I vote +1 for this to move us ahead. The group name doesn't matter too much, and even if a de facto name sticks,= it's still got the Region/Agent part to it which is very appropriate and d= istinguishes it from other protocols. Morgaine. --_000_4646639E08F58B42836FAC24C94624DD6FE8098411GVW0433EXBame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 to move the discussion forward.  I don’t love = it but its fine as a working name.

 

From: ogpx-bounces@ietf.org [mailto:ogpx-boun= ces@ietf.org] On Behalf Of Morgaine
Sent: Friday, August 28, 2009 12:56 PM
To: ogpx@ietf.org
Subject: Re: [ogpx] resolving the name issue

 

 



Morgaine.


--_000_4646639E08F58B42836FAC24C94624DD6FE8098411GVW0433EXBame_-- From infinity@lindenlab.com Fri Aug 28 11:27:06 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5533A6AA1 for ; Fri, 28 Aug 2009 11:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIFrtA7Wmzx9 for ; Fri, 28 Aug 2009 11:27:05 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 63A793A6A78 for ; Fri, 28 Aug 2009 11:27:05 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so485118eye.51 for ; Fri, 28 Aug 2009 11:27:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.7.209 with SMTP id 59mr265818wep.213.1251484028295; Fri, 28 Aug 2009 11:27:08 -0700 (PDT) Date: Fri, 28 Aug 2009 11:27:08 -0700 Message-ID: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 18:27:06 -0000 okay... here's what i think we've all agreed to. i've taken the liberty of using the VWRAP name since it seems to me we have consensus around that name. also note that i still have the ogpx@ietf.org email list in the charter text, since we don't have the VWRAP mailing list up yet. but the rest of it should be "correct" based on discussions. please look it over and tell me if i've missed something. -cheers -meadhbh Working Group Name: Virtual Worlds Region Agent Protocol (VWRAP) Chairs: TBD Area and Area Directors: Applications Area Lisa Dusseault Alexey Melnikov Responsible Area Director: TBD Mailing List: ogpx@ietf.org http://www.ietf.org/mailman/listinfo/ogpx Description of Working Group: The working group will define the Virtual Worlds Region Agent Protocol (VWRAP) for collaborative 3-dimensional virtual worlds. The protocol permits users to interact with each other while represented as "avatars," or digital representations of the user. Within a single virtual world, avatars exist in at most one location in a shared virtual space. Conforming client applications use the protocol to manipulate and move the user's avatar, create objects in a virtual world, interact with other users and their surroundings and consume and create media and information from sources inside and outside their virtual world. Adjacent locations in virtual worlds accessible by this protocol may be explicitly partitioned into "regions" to facilitate the computational and communication load balancing required to simulate the virtual environment. Such virtual worlds may consist of regions administered by distinct organizations. Though these virtual worlds may be partitioned, they remain "un-sharded;" all inhabitants and objects in a particular location in a virtual world may initiate interaction with all other inhabitants and objects in that location; and, service endpoint addresses refer to at most one location. The state of a virtual world is independent of the client applications that access it and may persist between user sessions. Regions and services implemented according to the specifications may be deployed by separate organizations with varying policies and trust domains. The OGPX protocols will provide the mechanisms for these virtual world services to interoperate, when permitted by policy and shared trust domains. To support the exegesis of the specifications, the group may define a non-exhaustive set of non-normative policies protocol participants may enforce. The protocol should describe interaction semantics for these virtual worlds, independent of transport, leveraging existing standards where practical. It should define interoperability expectations for server to server interactions as well as client-server interactions. Though the protocol is independent of transport, early interoperability trials used HTTP(S) for non-real-time messages. The working group will define specific features that must be replicated in other transports and will define the use of HTTP(S) as a transport of protocol messages. Foundational components of the protocol include the publication of: * an abstract type system, suitable for describing the application protocol in an implementation neutral manner, * a security model describing trust relationships between participating entities, * guidelines for the use of existing authentication and confidentiality mechanisms, * an application-layer protocol for establishing the user's avatar in a virtual world, * an application-layer protocol for moving a user's avatar between adjacent and remote locations in a virtual world, * format descriptions for objects and avatars in a virtual world, and * an application-layer protocol for identifying agents, and requesting information about them. The protocol defined by this group will carry information about the virtual environment, its contents and its inhabitants. It is an application layer protocol, independent of transport, based partially on these previously published internet drafts: * http://tools.ietf.org/html/draft-hamrick-ogp-intro * http://tools.ietf.org/html/draft-hamrick-llsd * http://tools.ietf.org/html/draft-hamrick-ogp-auth * http://tools.ietf.org/html/draft-hamrick-ogp-launch * http://tools.ietf.org/html/draft-lentczner-ogp-base * http://tools.ietf.org/html/draft-levine-ogp-clientcap * http://tools.ietf.org/html/draft-levine-ogp-layering Goals and Milestones: * October 2009 "Introduction and Goals" to the IESG as an Informational RFC * October 2009 "Abstract Type System for the Transmission of Dynamic Structured Data" to the IESG as Proposed Standard * October 2010 "Foundational Concepts and Transport Expectations" to the IESG as Proposed Standard * February 2010 "Guidelines for Host Authentication" to the IESG as an Informational RFC * February 2010 "Service Establishment" to the IESG as Proposed Standard * February 2010 "Client Application Launch Message" to the IESG as an Informational RFC * February 2010 "Simulation Presence Establishment" to the IESG as Proposed Standard * June 2010 "Primitive Object Format" to the IESG as Proposed Standard * June 2010 "Digital Asset Access" to the IESG as Proposed Standard * June 2010 "Entity Identifiers" to the IESG as Proposed standard From josh@lindenlab.com Fri Aug 28 12:35:47 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500913A6765 for ; Fri, 28 Aug 2009 12:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY0QUqgLZfQu for ; Fri, 28 Aug 2009 12:35:45 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id D47453A682E for ; Fri, 28 Aug 2009 12:35:45 -0700 (PDT) Received: by pzk38 with SMTP id 38so2205498pzk.5 for ; Fri, 28 Aug 2009 12:35:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.248.15 with SMTP id v15mr675628rvh.127.1251488149038; Fri, 28 Aug 2009 12:35:49 -0700 (PDT) In-Reply-To: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> Date: Fri, 28 Aug 2009 12:35:49 -0700 Message-ID: From: Joshua Bell To: Infinity Linden Content-Type: multipart/alternative; boundary=000e0cd11348906966047238cafc Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 19:35:47 -0000 --000e0cd11348906966047238cafc Content-Type: text/plain; charset=UTF-8 Looks like one more find/replace for "OGPX" will be necessary on the text. :) Also, I wonder if we should include a note around the "previously published internet drafts" mentioning that "OGP" was an earlier name used for this effort, to explain why many of the drafts mention OGP. Meh... probably not necessary. On Fri, Aug 28, 2009 at 11:27 AM, Infinity Linden wrote: > okay... here's what i think we've all agreed to. i've taken the > liberty of using the VWRAP name since it seems to me we have consensus > around that name. > > also note that i still have the ogpx@ietf.org email list in the > charter text, since we don't have the VWRAP mailing list up yet. > > but the rest of it should be "correct" based on discussions. please > look it over and tell me if i've missed something. > > -cheers > -meadhbh > > Working Group Name: > > Virtual Worlds Region Agent Protocol (VWRAP) > > Chairs: > > TBD > > Area and Area Directors: > > Applications Area > > Lisa Dusseault > Alexey Melnikov > > Responsible Area Director: > > TBD > > Mailing List: > > ogpx@ietf.org > http://www.ietf.org/mailman/listinfo/ogpx > > Description of Working Group: > > The working group will define the Virtual Worlds Region Agent Protocol > (VWRAP) for collaborative 3-dimensional virtual worlds. The protocol > permits users to interact with each other while represented as > "avatars," or digital representations of the user. Within a single > virtual world, avatars exist in at most one location in a shared > virtual space. Conforming client applications use the protocol to > manipulate and move the user's avatar, create objects in a virtual > world, interact with other users and their surroundings and consume > and create media and information from sources inside and outside their > virtual world. > > Adjacent locations in virtual worlds accessible by this protocol may > be explicitly partitioned into "regions" to facilitate the > computational and communication load balancing required to simulate > the virtual environment. Such virtual worlds may consist of regions > administered by distinct organizations. Though these virtual worlds > may be partitioned, they remain "un-sharded;" all inhabitants and > objects in a particular location in a virtual world may initiate > interaction with all other inhabitants and objects in that location; > and, service endpoint addresses refer to at most one location. The > state of a virtual world is independent of the client applications > that access it and may persist between user sessions. > > Regions and services implemented according to the specifications may > be deployed by separate organizations with varying policies and trust > domains. The OGPX protocols will provide the mechanisms for these > virtual world services to interoperate, when permitted by policy and > shared trust domains. To support the exegesis of the specifications, > the group may define a non-exhaustive set of non-normative policies > protocol participants may enforce. > > The protocol should describe interaction semantics for these virtual > worlds, independent of transport, leveraging existing standards where > practical. It should define interoperability expectations for server > to server interactions as well as client-server interactions. Though > the protocol is independent of transport, early interoperability > trials used HTTP(S) for non-real-time messages. The working group will > define specific features that must be replicated in other transports > and will define the use of HTTP(S) as a transport of protocol > messages. > > Foundational components of the protocol include the publication of: > > * an abstract type system, suitable for describing the application > protocol in an implementation neutral manner, > > * a security model describing trust relationships between > participating entities, > > * guidelines for the use of existing authentication and > confidentiality mechanisms, > > * an application-layer protocol for establishing the user's avatar > in a virtual world, > > * an application-layer protocol for moving a user's avatar between > adjacent and remote locations in a virtual world, > > * format descriptions for objects and avatars in a virtual world, and > > * an application-layer protocol for identifying agents, and > requesting information about them. > > The protocol defined by this group will carry information about the > virtual environment, its contents and its inhabitants. It is an > application layer protocol, independent of transport, based partially > on these previously published internet drafts: > > * http://tools.ietf.org/html/draft-hamrick-ogp-intro > * http://tools.ietf.org/html/draft-hamrick-llsd > * http://tools.ietf.org/html/draft-hamrick-ogp-auth > * http://tools.ietf.org/html/draft-hamrick-ogp-launch > * http://tools.ietf.org/html/draft-lentczner-ogp-base > * http://tools.ietf.org/html/draft-levine-ogp-clientcap > * http://tools.ietf.org/html/draft-levine-ogp-layering > > Goals and Milestones: > > * October 2009 "Introduction and Goals" to the IESG as an > Informational RFC > > * October 2009 "Abstract Type System for the Transmission of Dynamic > Structured Data" to the IESG as Proposed Standard > > * October 2010 "Foundational Concepts and Transport Expectations" to > the IESG as Proposed Standard > > * February 2010 "Guidelines for Host Authentication" to the IESG as > an Informational RFC > > * February 2010 "Service Establishment" to the IESG as Proposed > Standard > > * February 2010 "Client Application Launch Message" to the IESG as > an Informational RFC > > * February 2010 "Simulation Presence Establishment" to the IESG as > Proposed Standard > > * June 2010 "Primitive Object Format" to the IESG as Proposed > Standard > > * June 2010 "Digital Asset Access" to the IESG as Proposed Standard > > * June 2010 "Entity Identifiers" to the IESG as Proposed standard > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --000e0cd11348906966047238cafc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Looks like one more find/replace for "OGPX" will be necessary on = the text. :)

Also, I wonder if we should include a note around the &= quot;previously published internet drafts" mentioning that "OGP&q= uot; was an earlier name used for this effort, to explain why many of the d= rafts mention OGP. Meh... probably not necessary.

On Fri, Aug 28, 2009 at 11:27 AM, Infinity L= inden <infin= ity@lindenlab.com> wrote:
okay... here's what i think we've all agreed to. i've taken the=
liberty of using the VWRAP name since it seems to me we have consensus
around that name.

also note that i still have the ogpx@ietf.= org email list in the
charter text, since we don't have the VWRAP mailing list up yet.

but the rest of it should be "correct" based on discussions. plea= se
look it over and tell me if i've missed something.

-cheers
-meadhbh

Working Group Name:

=C2=A0Virtual Worlds Region Agent Protocol (VWRAP)

Chairs:

=C2=A0TBD

Area and Area Directors:

=C2=A0Applications Area

=C2=A0Lisa Dusseault <lisa.= dusseault@gmail.com>
=C2=A0Alexey Melnikov <ale= xey.melnikov@isode.com>

Responsible Area Director:

=C2=A0TBD

Mailing List:

=C2=A0ogpx@ietf.org
=C2=A0http://www.ietf.org/mailman/listinfo/ogpx

Description of Working Group:

The working group will define the Virtual Worlds Region Agent Protocol
(VWRAP) for =C2=A0collaborative 3-dimensional virtual =C2=A0worlds. The pro= tocol
permits =C2=A0users =C2=A0to =C2=A0interact =C2=A0with =C2=A0each other =C2= =A0while =C2=A0represented =C2=A0as
"avatars," =C2=A0or digital representations =C2=A0of the =C2=A0us= er. Within =C2=A0a single
virtual =C2=A0world, avatars =C2=A0exist in =C2=A0at most =C2=A0one locatio= n =C2=A0in =C2=A0a shared
virtual =C2=A0space. Conforming =C2=A0client =C2=A0applications use =C2=A0t= he protocol =C2=A0to
manipulate and =C2=A0move the =C2=A0user's avatar, create =C2=A0objects= in =C2=A0a virtual
world, interact =C2=A0with other users =C2=A0and their surroundings =C2=A0a= nd consume
and create media and information from sources inside and outside their
virtual world.

Adjacent locations =C2=A0in virtual worlds accessible by =C2=A0this protoco= l may
be =C2=A0 explicitly =C2=A0 partitioned =C2=A0into =C2=A0 "regions&quo= t; =C2=A0 to =C2=A0facilitate =C2=A0 the
computational =C2=A0and communication load =C2=A0balancing required =C2=A0t= o simulate
the virtual =C2=A0environment. Such virtual =C2=A0worlds may consist =C2=A0= of regions
administered =C2=A0by distinct organizations. =C2=A0Though these =C2=A0virt= ual worlds
may =C2=A0be partitioned, =C2=A0they =C2=A0remain "un-sharded;" = =C2=A0all inhabitants =C2=A0and
objects =C2=A0in a =C2=A0particular location =C2=A0in =C2=A0a virtual =C2= =A0world may =C2=A0initiate
interaction with =C2=A0all other inhabitants and objects =C2=A0in that loca= tion;
and, service =C2=A0endpoint addresses =C2=A0refer to at =C2=A0most one =C2= =A0location. The
state of =C2=A0a virtual =C2=A0world is independent =C2=A0of the =C2=A0clie= nt applications
that access it and may persist between user sessions.

Regions and =C2=A0services implemented according to =C2=A0the specification= s may
be deployed by separate =C2=A0organizations with varying policies and trust=
domains. =C2=A0The OGPX =C2=A0protocols will =C2=A0provide the =C2=A0mechan= isms =C2=A0for these
virtual world =C2=A0services to interoperate, when permitted =C2=A0by polic= y and
shared trust =C2=A0domains. To support the exegesis =C2=A0of the specificat= ions,
the group =C2=A0may define a =C2=A0non-exhaustive set of =C2=A0non-normativ= e policies
protocol participants may enforce.

The protocol =C2=A0should describe interaction semantics =C2=A0for these vi= rtual
worlds, independent of =C2=A0transport, leveraging existing standards where=
practical. It =C2=A0should define interoperability =C2=A0expectations for s= erver
to server =C2=A0interactions as well as =C2=A0client-server interactions. T= hough
the =C2=A0protocol =C2=A0is =C2=A0independent =C2=A0of transport, =C2=A0ear= ly =C2=A0interoperability
trials used HTTP(S) for non-real-time messages. The working group will
define specific =C2=A0features that must be replicated =C2=A0in other trans= ports
and =C2=A0will =C2=A0define =C2=A0the use =C2=A0of =C2=A0HTTP(S) =C2=A0as = =C2=A0a transport =C2=A0of =C2=A0protocol
messages.

Foundational components of the protocol include the publication of:

=C2=A0* an abstract =C2=A0type system, suitable for =C2=A0describing the a= pplication
=C2=A0 =C2=A0protocol in an implementation neutral manner,

=C2=A0* a =C2=A0 security =C2=A0 model =C2=A0 describing =C2=A0trust =C2= =A0 relationships =C2=A0 between
=C2=A0 =C2=A0participating entities,

=C2=A0* guidelines =C2=A0 for =C2=A0 the =C2=A0 use =C2=A0 of =C2=A0existi= ng =C2=A0 authentication =C2=A0 and
=C2=A0 =C2=A0confidentiality mechanisms,

=C2=A0* an application-layer =C2=A0protocol for establishing =C2=A0the use= r's avatar
=C2=A0 =C2=A0in a virtual world,

=C2=A0* an application-layer =C2=A0protocol for moving a =C2=A0user's = avatar between
=C2=A0 =C2=A0adjacent and remote locations in a virtual world,

=C2=A0* format descriptions for objects and avatars in a virtual world, an= d

=C2=A0* an =C2=A0 application-layer =C2=A0protocol =C2=A0 for =C2=A0identi= fying =C2=A0 agents, =C2=A0and
=C2=A0 =C2=A0requesting information about them.

The protocol =C2=A0defined by this =C2=A0group will carry information =C2= =A0about the
virtual =C2=A0environment, =C2=A0its contents =C2=A0and =C2=A0its =C2=A0inh= abitants. =C2=A0It is =C2=A0an
application layer protocol, =C2=A0independent of transport, based partially=
on these previously published internet drafts:

=C2=A0* http://tools.ietf.org/html/draft-hamrick-ogp-intro
=C2=A0* http://tools.ietf.org/html/draft-hamrick-llsd
=C2=A0* http://tools.ietf.org/html/draft-hamrick-ogp-auth
=C2=A0* http://tools.ietf.org/html/draft-hamrick-ogp-launch
=C2=A0* http://tools.ietf.org/html/draft-lentczner-ogp-base
=C2=A0* http://tools.ietf.org/html/draft-levine-ogp-clientcap=
=C2=A0* http://tools.ietf.org/html/draft-levine-ogp-layering
Goals and Milestones:

=C2=A0* October =C2=A02009 =C2=A0 "Introduction =C2=A0and =C2=A0Goals= " =C2=A0to =C2=A0the =C2=A0 IESG =C2=A0as =C2=A0an
=C2=A0 =C2=A0Informational RFC

=C2=A0* October 2009 "Abstract Type System for the Transmission of Dy= namic
=C2=A0 =C2=A0Structured Data" to the IESG as Proposed Standard

=C2=A0* October 2010 "Foundational Concepts and Transport Expectation= s" to
=C2=A0 =C2=A0the IESG as Proposed Standard

=C2=A0* February 2010 "Guidelines for =C2=A0Host Authentication"= to the IESG as
=C2=A0 =C2=A0an Informational RFC

=C2=A0* February =C2=A02010 "Service =C2=A0Establishment" =C2=A0= to the =C2=A0IESG as =C2=A0Proposed
=C2=A0 =C2=A0Standard

=C2=A0* February 2010 =C2=A0"Client Application Launch Message" = to =C2=A0the IESG as
=C2=A0 =C2=A0an Informational RFC

=C2=A0* February 2010 =C2=A0"Simulation Presence Establishment" = to =C2=A0the IESG as
=C2=A0 =C2=A0Proposed Standard

=C2=A0* June =C2=A02010 =C2=A0"Primitive Object =C2=A0Format" = =C2=A0to =C2=A0the =C2=A0IESG as =C2=A0Proposed
=C2=A0 =C2=A0Standard

=C2=A0* June 2010 "Digital Asset Access" to the IESG as Proposed= Standard

=C2=A0* June 2010 "Entity Identifiers" to the IESG as Proposed s= tandard
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--000e0cd11348906966047238cafc-- From infinity@lindenlab.com Fri Aug 28 12:46:30 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415313A6BC4 for ; Fri, 28 Aug 2009 12:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B-QIJqJ8bsb for ; Fri, 28 Aug 2009 12:46:29 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id B89AA28C11B for ; Fri, 28 Aug 2009 12:46:28 -0700 (PDT) Received: by ewy3 with SMTP id 3so718808ewy.42 for ; Fri, 28 Aug 2009 12:46:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.13.209 with SMTP id b59mr315448web.44.1251488791438; Fri, 28 Aug 2009 12:46:31 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> Date: Fri, 28 Aug 2009 12:46:31 -0700 Message-ID: <3a880e2c0908281246o6fb7b17fk7f424ce00b6abdb2@mail.gmail.com> From: Infinity Linden To: Joshua Bell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 19:46:30 -0000 nah. i actually kind of like it, cause if you put OGP or OGPX the names in the IDs don't seem alien, and if someone googles these old initialisms, there's a good chance they'll get the VWRAP charter somewhere on the first page of results. so maybe if we changed "The protocol defined by this group will carry information about the virtual environment, its contents and its inhabitants. It is an application layer protocol, independent of transport, based partially on these previously published internet drafts:" to "The protocol defined by this group will carry information about the virtual environment, its contents and its inhabitants. It is an application layer protocol, independent of transport, based partially on previous work under the name "Open Grid Protocol (OGP)" and these internet drafts, previously published in preparation for the OGPX Birds of a Feather session:" On Fri, Aug 28, 2009 at 12:35 PM, Joshua Bell wrote: > Looks like one more find/replace for "OGPX" will be necessary on the text= . > :) > > Also, I wonder if we should include a note around the "previously publish= ed > internet drafts" mentioning that "OGP" was an earlier name used for this > effort, to explain why many of the drafts mention OGP. Meh... probably no= t > necessary. > > On Fri, Aug 28, 2009 at 11:27 AM, Infinity Linden > wrote: >> >> okay... here's what i think we've all agreed to. i've taken the >> liberty of using the VWRAP name since it seems to me we have consensus >> around that name. >> >> also note that i still have the ogpx@ietf.org email list in the >> charter text, since we don't have the VWRAP mailing list up yet. >> >> but the rest of it should be "correct" based on discussions. please >> look it over and tell me if i've missed something. >> >> -cheers >> -meadhbh >> >> Working Group Name: >> >> =A0Virtual Worlds Region Agent Protocol (VWRAP) >> >> Chairs: >> >> =A0TBD >> >> Area and Area Directors: >> >> =A0Applications Area >> >> =A0Lisa Dusseault >> =A0Alexey Melnikov >> >> Responsible Area Director: >> >> =A0TBD >> >> Mailing List: >> >> =A0ogpx@ietf.org >> =A0http://www.ietf.org/mailman/listinfo/ogpx >> >> Description of Working Group: >> >> The working group will define the Virtual Worlds Region Agent Protocol >> (VWRAP) for =A0collaborative 3-dimensional virtual =A0worlds. The protoc= ol >> permits =A0users =A0to =A0interact =A0with =A0each other =A0while =A0rep= resented =A0as >> "avatars," =A0or digital representations =A0of the =A0user. Within =A0a = single >> virtual =A0world, avatars =A0exist in =A0at most =A0one location =A0in = =A0a shared >> virtual =A0space. Conforming =A0client =A0applications use =A0the protoc= ol =A0to >> manipulate and =A0move the =A0user's avatar, create =A0objects in =A0a v= irtual >> world, interact =A0with other users =A0and their surroundings =A0and con= sume >> and create media and information from sources inside and outside their >> virtual world. >> >> Adjacent locations =A0in virtual worlds accessible by =A0this protocol m= ay >> be =A0 explicitly =A0 partitioned =A0into =A0 "regions" =A0 to =A0facili= tate =A0 the >> computational =A0and communication load =A0balancing required =A0to simu= late >> the virtual =A0environment. Such virtual =A0worlds may consist =A0of reg= ions >> administered =A0by distinct organizations. =A0Though these =A0virtual wo= rlds >> may =A0be partitioned, =A0they =A0remain "un-sharded;" =A0all inhabitant= s =A0and >> objects =A0in a =A0particular location =A0in =A0a virtual =A0world may = =A0initiate >> interaction with =A0all other inhabitants and objects =A0in that locatio= n; >> and, service =A0endpoint addresses =A0refer to at =A0most one =A0locatio= n. The >> state of =A0a virtual =A0world is independent =A0of the =A0client applic= ations >> that access it and may persist between user sessions. >> >> Regions and =A0services implemented according to =A0the specifications m= ay >> be deployed by separate =A0organizations with varying policies and trust >> domains. =A0The OGPX =A0protocols will =A0provide the =A0mechanisms =A0f= or these >> virtual world =A0services to interoperate, when permitted =A0by policy a= nd >> shared trust =A0domains. To support the exegesis =A0of the specification= s, >> the group =A0may define a =A0non-exhaustive set of =A0non-normative poli= cies >> protocol participants may enforce. >> >> The protocol =A0should describe interaction semantics =A0for these virtu= al >> worlds, independent of =A0transport, leveraging existing standards where >> practical. It =A0should define interoperability =A0expectations for serv= er >> to server =A0interactions as well as =A0client-server interactions. Thou= gh >> the =A0protocol =A0is =A0independent =A0of transport, =A0early =A0intero= perability >> trials used HTTP(S) for non-real-time messages. The working group will >> define specific =A0features that must be replicated =A0in other transpor= ts >> and =A0will =A0define =A0the use =A0of =A0HTTP(S) =A0as =A0a transport = =A0of =A0protocol >> messages. >> >> Foundational components of the protocol include the publication of: >> >> =A0* an abstract =A0type system, suitable for =A0describing the applicat= ion >> =A0 =A0protocol in an implementation neutral manner, >> >> =A0* a =A0 security =A0 model =A0 describing =A0trust =A0 relationships = =A0 between >> =A0 =A0participating entities, >> >> =A0* guidelines =A0 for =A0 the =A0 use =A0 of =A0existing =A0 authentic= ation =A0 and >> =A0 =A0confidentiality mechanisms, >> >> =A0* an application-layer =A0protocol for establishing =A0the user's ava= tar >> =A0 =A0in a virtual world, >> >> =A0* an application-layer =A0protocol for moving a =A0user's avatar betw= een >> =A0 =A0adjacent and remote locations in a virtual world, >> >> =A0* format descriptions for objects and avatars in a virtual world, and >> >> =A0* an =A0 application-layer =A0protocol =A0 for =A0identifying =A0 age= nts, =A0and >> =A0 =A0requesting information about them. >> >> The protocol =A0defined by this =A0group will carry information =A0about= the >> virtual =A0environment, =A0its contents =A0and =A0its =A0inhabitants. = =A0It is =A0an >> application layer protocol, =A0independent of transport, based partially >> on these previously published internet drafts: >> >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-intro >> =A0* http://tools.ietf.org/html/draft-hamrick-llsd >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-auth >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-launch >> =A0* http://tools.ietf.org/html/draft-lentczner-ogp-base >> =A0* http://tools.ietf.org/html/draft-levine-ogp-clientcap >> =A0* http://tools.ietf.org/html/draft-levine-ogp-layering >> >> Goals and Milestones: >> >> =A0* October =A02009 =A0 "Introduction =A0and =A0Goals" =A0to =A0the =A0= IESG =A0as =A0an >> =A0 =A0Informational RFC >> >> =A0* October 2009 "Abstract Type System for the Transmission of Dynamic >> =A0 =A0Structured Data" to the IESG as Proposed Standard >> >> =A0* October 2010 "Foundational Concepts and Transport Expectations" to >> =A0 =A0the IESG as Proposed Standard >> >> =A0* February 2010 "Guidelines for =A0Host Authentication" to the IESG a= s >> =A0 =A0an Informational RFC >> >> =A0* February =A02010 "Service =A0Establishment" =A0to the =A0IESG as = =A0Proposed >> =A0 =A0Standard >> >> =A0* February 2010 =A0"Client Application Launch Message" to =A0the IESG= as >> =A0 =A0an Informational RFC >> >> =A0* February 2010 =A0"Simulation Presence Establishment" to =A0the IESG= as >> =A0 =A0Proposed Standard >> >> =A0* June =A02010 =A0"Primitive Object =A0Format" =A0to =A0the =A0IESG a= s =A0Proposed >> =A0 =A0Standard >> >> =A0* June 2010 "Digital Asset Access" to the IESG as Proposed Standard >> >> =A0* June 2010 "Entity Identifiers" to the IESG as Proposed standard >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > From infinity@lindenlab.com Fri Aug 28 12:59:55 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0DE53A69BB for ; Fri, 28 Aug 2009 12:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHgzl88Q-MtQ for ; Fri, 28 Aug 2009 12:59:55 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id A7D923A6968 for ; Fri, 28 Aug 2009 12:59:54 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so498413eye.51 for ; Fri, 28 Aug 2009 12:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.70.143 with SMTP id p15mr351554wed.115.1251489598508; Fri, 28 Aug 2009 12:59:58 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD6FE8098411@GVW0433EXB.americas.hpqcorp.net> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <4646639E08F58B42836FAC24C94624DD6FE8098411@GVW0433EXB.americas.hpqcorp.net> Date: Fri, 28 Aug 2009 12:59:58 -0700 Message-ID: <3a880e2c0908281259h3a10cd02mc92eb8331c92f162@mail.gmail.com> From: Infinity Linden To: "Dickson, Mike (ISS Software)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "ogpx@ietf.org" Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2009 19:59:55 -0000 also, i just did a google search for VWRAP and got a whole lot of "not much." ergo, we're not competing with another common name with lots of search results. so from that perspective, i'm starting to get happy about the VWRAP name, even though i thought ABOVE was cooler. i think morgaine's comments about NOT picking a common name are definitely spot on in this regard. -cheers -meadhbh / infinity On Fri, Aug 28, 2009 at 11:19 AM, Dickson, Mike (ISS Software) wrote: > +1 to move the discussion forward.=A0 I don=92t love it but its fine as a > working name. > > > > From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of > Morgaine > Sent: Friday, August 28, 2009 12:56 PM > To: ogpx@ietf.org > Subject: Re: [ogpx] resolving the name issue > > > > > > On Fri, Aug 28, 2009 at 4:48 PM, Joshua Bell wrote: > > Can list participants agree to VWRAP as "not perfect, but good enough" an= d > move past the name issue to real interop work? > > I vote +1 for this to move us ahead. > > The group name doesn't matter too much, and even if a de facto name stick= s, > it's still got the Region/Agent part to it which is very appropriate and > distinguishes it from other protocols. > > Morgaine. > > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From morgaine.dinova@googlemail.com Fri Aug 28 17:49:15 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90D53A69C8 for ; Fri, 28 Aug 2009 17:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77MZTxIHlwIj for ; Fri, 28 Aug 2009 17:49:15 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id F24383A6954 for ; Fri, 28 Aug 2009 17:49:14 -0700 (PDT) Received: by ewy3 with SMTP id 3so875199ewy.42 for ; Fri, 28 Aug 2009 17:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=HND+IGKbWXZ5tjO8aMiFUbwcFmb/w9u8QHGNY0CcUwU=; b=dn9SW3y/UiGzO8Xpd6dBcwur2VIykgk6nunPg0eICCGwYrEHQZ1LvK3eLnq9Oodr3k we2X7gQwaJ+h7obiv7fUd/SnhCZ/XEW6U5ZcjbXJC2RsoMnbXpKn1sV98Ynu56XgjgBu fxi3HCowB/NfAg8H5GvkJl88jP0ovCatsTs28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Iec21zbxr9B4IC0CsOcX5ky4jstubzoajil7miXFD5UXPMpUttJFR+d1R384R0h5wg gLHNTNy2Lo1YcD+4Xq59jGuLOBJj1TSLcVtpxiDYmlOI0f73wL/XFJu7ae5b4h/lcfrS GO5B7SfQAva9Jbr+MEhJd8Ts2yXocXtHAWusc= MIME-Version: 1.0 Received: by 10.210.139.17 with SMTP id m17mr1106314ebd.7.1251506958551; Fri, 28 Aug 2009 17:49:18 -0700 (PDT) In-Reply-To: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> Date: Sat, 29 Aug 2009 01:49:18 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174c177cb2cc4404723d2b83 Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 00:49:16 -0000 --0015174c177cb2cc4404723d2b83 Content-Type: text/plain; charset=ISO-8859-1 > > To support the exegesis of the specifications, the group may define a > non-exhaustive set of non-normative policies protocol participants may > enforce. > I'm not sure whether to laugh or cry at this sentence in the 3rd paragraph, but one thing's certain, it doesn't help at all. In fact, the world would be a far better place without it. ;-) I would normally give reasons, but in this case the sentence is just so far beyond the pale that with a bit of luck it'll just disappear without further ado through universal revulsion. ;-) Morgaine. Plain English Campaign. --0015174c177cb2cc4404723d2b83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0
To support the exegesis =A0of the specifications, the group = =A0may define a=A0 non-exhaustive set of =A0non-normative policies protocol= participants may enforce.

I'm not sure whether to laugh or cry at this sent= ence in the 3rd paragraph, but one thing's certain, it doesn't help= at all.=A0 In fact, the world would be a far better place without it. ;-)<= br>
I would normally give reasons, but in this case the sentence is just so= far beyond the pale that with a bit of luck it'll just disappear witho= ut further ado through universal revulsion. ;-)


Morgaine.

Plain English Campaign.
--0015174c177cb2cc4404723d2b83-- From morgaine.dinova@googlemail.com Fri Aug 28 19:10:05 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883AD3A6993 for ; Fri, 28 Aug 2009 19:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P19Pd-KC0cjN for ; Fri, 28 Aug 2009 19:10:03 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 5980A3A6823 for ; Fri, 28 Aug 2009 19:10:03 -0700 (PDT) Received: by ewy3 with SMTP id 3so905449ewy.42 for ; Fri, 28 Aug 2009 19:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=UJqhj+VOcgLsHgq67EjQdU+H/x7Zaik5KqgfPeAISz8=; b=NgEJJoL61Kk/dtcNXBmMMhZbYG+XKxe4DESiHHAQr/C/J/qcjy0KF5RitS0mTNzK0s nkMM8QSBMTnHmx7fBfudG2N73P3/4MJxToIzVyIIdb1DZhm6ppplblf2IVj7yN2QzwUY ygdjCPnvE43MOMA9c0tbcgdAmk0u9RwmbhGk8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mjsxxaVxK0vQ+NJL6Mam0otpXYtbJLQAZ6vLjSbDZZUzL/zxaIkjF5RjV4rUBxPWCv XvaUQhUkcmCSZKO/13vB5jGK+P2lunBIKvigvjIM+FOLiXDzNo4fpfHBb6Tl+HwGB/xj MnQ/IH9PyFLG/06DAIHBKXoUf6aap6d1RdYtQ= MIME-Version: 1.0 Received: by 10.211.173.6 with SMTP id a6mr2102927ebp.13.1251511806506; Fri, 28 Aug 2009 19:10:06 -0700 (PDT) In-Reply-To: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> Date: Sat, 29 Aug 2009 03:10:06 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00504502ca31a8b77404723e4cbd Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 02:10:05 -0000 --00504502ca31a8b77404723e4cbd Content-Type: text/plain; charset=ISO-8859-1 This charter still does not mention in plain English that the group and the protocol *will* address cross-world interop. It is not enough to claim that cross-world interop is included through lack of explicit exclusion. That can lead to disputes about what was intended to be in scope and what was not. The charter needs to express the group's scope clearly, that is its purpose. What's more, because cross-world interop is the area of greatest complexity in this work, it needs to be prominent as a deliverable. Currently there is not even a hint of it in the deliverables, which is a major and extremely important omission. Among the *Foundational Components* (the bullet list of paragraph 5), we need a clause something like: - A model describing the use of the protocol for interoperation between multiple distinct virtual worlds and involving multiple region/agent domains and services. Unless the many possible scenarios of cross-world interop are carefully considered, the protocol has no hope of working in such scenarios. This is work we must do, or cross-world interop was just lip service after all. Morgaine. ======================= On Fri, Aug 28, 2009 at 7:27 PM, Infinity Linden wrote: > okay... here's what i think we've all agreed to. i've taken the > liberty of using the VWRAP name since it seems to me we have consensus > around that name. > > also note that i still have the ogpx@ietf.org email list in the > charter text, since we don't have the VWRAP mailing list up yet. > > but the rest of it should be "correct" based on discussions. please > look it over and tell me if i've missed something. > > -cheers > -meadhbh > > Working Group Name: > > Virtual Worlds Region Agent Protocol (VWRAP) > > Chairs: > > TBD > > Area and Area Directors: > > Applications Area > > Lisa Dusseault > Alexey Melnikov > > Responsible Area Director: > > TBD > > Mailing List: > > ogpx@ietf.org > http://www.ietf.org/mailman/listinfo/ogpx > > Description of Working Group: > > The working group will define the Virtual Worlds Region Agent Protocol > (VWRAP) for collaborative 3-dimensional virtual worlds. The protocol > permits users to interact with each other while represented as > "avatars," or digital representations of the user. Within a single > virtual world, avatars exist in at most one location in a shared > virtual space. Conforming client applications use the protocol to > manipulate and move the user's avatar, create objects in a virtual > world, interact with other users and their surroundings and consume > and create media and information from sources inside and outside their > virtual world. > > Adjacent locations in virtual worlds accessible by this protocol may > be explicitly partitioned into "regions" to facilitate the > computational and communication load balancing required to simulate > the virtual environment. Such virtual worlds may consist of regions > administered by distinct organizations. Though these virtual worlds > may be partitioned, they remain "un-sharded;" all inhabitants and > objects in a particular location in a virtual world may initiate > interaction with all other inhabitants and objects in that location; > and, service endpoint addresses refer to at most one location. The > state of a virtual world is independent of the client applications > that access it and may persist between user sessions. > > Regions and services implemented according to the specifications may > be deployed by separate organizations with varying policies and trust > domains. The OGPX protocols will provide the mechanisms for these > virtual world services to interoperate, when permitted by policy and > shared trust domains. To support the exegesis of the specifications, > the group may define a non-exhaustive set of non-normative policies > protocol participants may enforce. > > The protocol should describe interaction semantics for these virtual > worlds, independent of transport, leveraging existing standards where > practical. It should define interoperability expectations for server > to server interactions as well as client-server interactions. Though > the protocol is independent of transport, early interoperability > trials used HTTP(S) for non-real-time messages. The working group will > define specific features that must be replicated in other transports > and will define the use of HTTP(S) as a transport of protocol > messages. > > Foundational components of the protocol include the publication of: > > * an abstract type system, suitable for describing the application > protocol in an implementation neutral manner, > > * a security model describing trust relationships between > participating entities, > > * guidelines for the use of existing authentication and > confidentiality mechanisms, > > * an application-layer protocol for establishing the user's avatar > in a virtual world, > > * an application-layer protocol for moving a user's avatar between > adjacent and remote locations in a virtual world, > > * format descriptions for objects and avatars in a virtual world, and > > * an application-layer protocol for identifying agents, and > requesting information about them. > > The protocol defined by this group will carry information about the > virtual environment, its contents and its inhabitants. It is an > application layer protocol, independent of transport, based partially > on these previously published internet drafts: > > * http://tools.ietf.org/html/draft-hamrick-ogp-intro > * http://tools.ietf.org/html/draft-hamrick-llsd > * http://tools.ietf.org/html/draft-hamrick-ogp-auth > * http://tools.ietf.org/html/draft-hamrick-ogp-launch > * http://tools.ietf.org/html/draft-lentczner-ogp-base > * http://tools.ietf.org/html/draft-levine-ogp-clientcap > * http://tools.ietf.org/html/draft-levine-ogp-layering > > Goals and Milestones: > > * October 2009 "Introduction and Goals" to the IESG as an > Informational RFC > > * October 2009 "Abstract Type System for the Transmission of Dynamic > Structured Data" to the IESG as Proposed Standard > > * October 2010 "Foundational Concepts and Transport Expectations" to > the IESG as Proposed Standard > > * February 2010 "Guidelines for Host Authentication" to the IESG as > an Informational RFC > > * February 2010 "Service Establishment" to the IESG as Proposed > Standard > > * February 2010 "Client Application Launch Message" to the IESG as > an Informational RFC > > * February 2010 "Simulation Presence Establishment" to the IESG as > Proposed Standard > > * June 2010 "Primitive Object Format" to the IESG as Proposed > Standard > > * June 2010 "Digital Asset Access" to the IESG as Proposed Standard > > * June 2010 "Entity Identifiers" to the IESG as Proposed standard > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --00504502ca31a8b77404723e4cbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This charter still does not mention in plain English that the group and the= protocol will address cross-world interop.

It is not enough = to claim that cross-world interop is included through lack of explicit excl= usion.=A0 That can lead to disputes about what was intended to be in scope = and what was not.=A0 The charter needs to express the group's scope cle= arly, that is its purpose.

What's more, because cross-world interop is the area of greatest co= mplexity in this work, it needs to be prominent as a deliverable.=A0 Curren= tly there is not even a hint of it in the deliverables, which is a major an= d extremely important omission.

Among the Foundational Components (the bullet list of paragraph = 5), we need a clause something like:

  • A model describing the = use of the protocol for interoperation between multiple distinct virtual wo= rlds and involving multiple region/agent domains and services.

Unless the many possible scenarios of cross-world interop are care= fully considered, the protocol has no hope of working in such scenarios.=A0= This is work we must do, or cross-world interop was just lip service after= all.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On F= ri, Aug 28, 2009 at 7:27 PM, Infinity Linden <infinity@lindenlab.com> wr= ote:
okay... here'= s what i think we've all agreed to. i've taken the
liberty of using the VWRAP name since it seems to me we have consensus
around that name.

also note that i still have the ogpx@ietf.= org email list in the
charter text, since we don't have the VWRAP mailing list up yet.

but the rest of it should be "correct" based on discussions. plea= se
look it over and tell me if i've missed something.

-cheers
-meadhbh

Working Group Name:

=A0Virtual Worlds Region Agent Protocol (VWRAP)

Chairs:

=A0TBD

Area and Area Directors:

=A0Applications Area

=A0Lisa Dusseault <lisa.dus= seault@gmail.com>
=A0Alexey Melnikov <alexey= .melnikov@isode.com>

Responsible Area Director:

=A0TBD

Mailing List:

=A0ogpx@ietf.org
=A0http://www.ietf.org/mailman/listinfo/ogpx

Description of Working Group:

The working group will define the Virtual Worlds Region Agent Protocol
(VWRAP) for =A0collaborative 3-dimensional virtual =A0worlds. The protocol<= br> permits =A0users =A0to =A0interact =A0with =A0each other =A0while =A0repres= ented =A0as
"avatars," =A0or digital representations =A0of the =A0user. Withi= n =A0a single
virtual =A0world, avatars =A0exist in =A0at most =A0one location =A0in =A0a= shared
virtual =A0space. Conforming =A0client =A0applications use =A0the protocol = =A0to
manipulate and =A0move the =A0user's avatar, create =A0objects in =A0a = virtual
world, interact =A0with other users =A0and their surroundings =A0and consum= e
and create media and information from sources inside and outside their
virtual world.

Adjacent locations =A0in virtual worlds accessible by =A0this protocol may<= br> be =A0 explicitly =A0 partitioned =A0into =A0 "regions" =A0 to = =A0facilitate =A0 the
computational =A0and communication load =A0balancing required =A0to simulat= e
the virtual =A0environment. Such virtual =A0worlds may consist =A0of region= s
administered =A0by distinct organizations. =A0Though these =A0virtual world= s
may =A0be partitioned, =A0they =A0remain "un-sharded;" =A0all inh= abitants =A0and
objects =A0in a =A0particular location =A0in =A0a virtual =A0world may =A0i= nitiate
interaction with =A0all other inhabitants and objects =A0in that location;<= br> and, service =A0endpoint addresses =A0refer to at =A0most one =A0location. = The
state of =A0a virtual =A0world is independent =A0of the =A0client applicati= ons
that access it and may persist between user sessions.

Regions and =A0services implemented according to =A0the specifications may<= br> be deployed by separate =A0organizations with varying policies and trust domains. =A0The OGPX =A0protocols will =A0provide the =A0mechanisms =A0for = these
virtual world =A0services to interoperate, when permitted =A0by policy and<= br> shared trust =A0domains. To support the exegesis =A0of the specifications,<= br> the group =A0may define a =A0non-exhaustive set of =A0non-normative policie= s
protocol participants may enforce.

The protocol =A0should describe interaction semantics =A0for these virtual<= br> worlds, independent of =A0transport, leveraging existing standards where practical. It =A0should define interoperability =A0expectations for server<= br> to server =A0interactions as well as =A0client-server interactions. Though<= br> the =A0protocol =A0is =A0independent =A0of transport, =A0early =A0interoper= ability
trials used HTTP(S) for non-real-time messages. The working group will
define specific =A0features that must be replicated =A0in other transports<= br> and =A0will =A0define =A0the use =A0of =A0HTTP(S) =A0as =A0a transport =A0o= f =A0protocol
messages.

Foundational components of the protocol include the publication of:

=A0* an abstract =A0type system, suitable for =A0describing the applicatio= n
=A0 =A0protocol in an implementation neutral manner,

=A0* a =A0 security =A0 model =A0 describing =A0trust =A0 relationships = =A0 between
=A0 =A0participating entities,

=A0* guidelines =A0 for =A0 the =A0 use =A0 of =A0existing =A0 authenticat= ion =A0 and
=A0 =A0confidentiality mechanisms,

=A0* an application-layer =A0protocol for establishing =A0the user's a= vatar
=A0 =A0in a virtual world,

=A0* an application-layer =A0protocol for moving a =A0user's avatar be= tween
=A0 =A0adjacent and remote locations in a virtual world,

=A0* format descriptions for objects and avatars in a virtual world, and
=A0* an =A0 application-layer =A0protocol =A0 for =A0identifying =A0 agent= s, =A0and
=A0 =A0requesting information about them.

The protocol =A0defined by this =A0group will carry information =A0about th= e
virtual =A0environment, =A0its contents =A0and =A0its =A0inhabitants. =A0It= is =A0an
application layer protocol, =A0independent of transport, based partially on these previously published internet drafts:

=A0* http://tools.ietf.org/html/draft-hamrick-ogp-intro
=A0* http://tools.ietf.org/html/draft-hamrick-llsd
=A0* http://tools.ietf.org/html/draft-hamrick-ogp-auth
=A0* http://tools.ietf.org/html/draft-hamrick-ogp-launch
=A0* http://tools.ietf.org/html/draft-lentczner-ogp-base
=A0* http://tools.ietf.org/html/draft-levine-ogp-clientcap =A0* http://tools.ietf.org/html/draft-levine-ogp-layering

Goals and Milestones:

=A0* October =A02009 =A0 "Introduction =A0and =A0Goals" =A0to = =A0the =A0 IESG =A0as =A0an
=A0 =A0Informational RFC

=A0* October 2009 "Abstract Type System for the Transmission of Dynam= ic
=A0 =A0Structured Data" to the IESG as Proposed Standard

=A0* October 2010 "Foundational Concepts and Transport Expectations&q= uot; to
=A0 =A0the IESG as Proposed Standard

=A0* February 2010 "Guidelines for =A0Host Authentication" to th= e IESG as
=A0 =A0an Informational RFC

=A0* February =A02010 "Service =A0Establishment" =A0to the =A0IE= SG as =A0Proposed
=A0 =A0Standard

=A0* February 2010 =A0"Client Application Launch Message" to =A0= the IESG as
=A0 =A0an Informational RFC

=A0* February 2010 =A0"Simulation Presence Establishment" to =A0= the IESG as
=A0 =A0Proposed Standard

=A0* June =A02010 =A0"Primitive Object =A0Format" =A0to =A0the = =A0IESG as =A0Proposed
=A0 =A0Standard

=A0* June 2010 "Digital Asset Access" to the IESG as Proposed St= andard

=A0* June 2010 "Entity Identifiers" to the IESG as Proposed stan= dard
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--00504502ca31a8b77404723e4cbd-- From meadhbh.siobhan@gmail.com Fri Aug 28 19:46:40 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6E73A68C8 for ; Fri, 28 Aug 2009 19:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo9x4WbaZrPv for ; Fri, 28 Aug 2009 19:46:39 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 63B923A659C for ; Fri, 28 Aug 2009 19:46:39 -0700 (PDT) Received: by pzk38 with SMTP id 38so2544503pzk.5 for ; Fri, 28 Aug 2009 19:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eQ8+d+g1nv/UedHQoIRJShJT7E10BsI48sodLXHOO6M=; b=RNg3axYVkLWQZ05LS8XzFkb0PLwzj/CNCkKqlZlGv3g04GZYeNLxurTIrydCjpwxHo KHOrlMJ0vu0dv8jtEmieVmqVZqm54UevE2EMhS9jTpD2VWm6/dR/bsTixAgJozP+tZcu C00e7ueh1alMjqkUcnM3bi1RW9TOzgXsNAvyc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hJ/H6wC8Pb94ZOacUAvdY8uw/rFsugVfxcmcnHoU6KDez9DB1zRCB7IlbQmfBUV/Vh O4guvk4/NlbLTWEGEEGs+tWyIoP0aGbXwKNaGHShvrauXC9gYvpyf8pKjzKtBOGLCxy/ hx9jAlVeo4oVCmpWa4PC0PwGjIP/py1FsScF4= MIME-Version: 1.0 Received: by 10.140.158.3 with SMTP id g3mr974466rve.181.1251514003794; Fri, 28 Aug 2009 19:46:43 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> Date: Fri, 28 Aug 2009 19:46:43 -0700 Message-ID: From: Meadhbh Siobhan To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 02:46:40 -0000 i like where you're going with this, but i have to say, i really think we should use the term "virtual world" only in a non-normative manner. the term is simultaneously evocative as an descriptive term and a lightning rod for disagreement when we attempt to define it. david's work on deployment patterns should definitely be included somewhere. i think it _would_ help people new to the group to understand what we're working on, and it seems like what you're asking is to talk about deployment patterns. some people might shy away from the term "model" (myself included) in favor of "pattern" since the latter admits more abstraction to the process. how 'bout, "Deployment patterns for describing the use of the protocol for interoperation between multiple region/agent domains and services." -cheers -meadhbh On Fri, Aug 28, 2009 at 7:10 PM, Morgaine w= rote: > This charter still does not mention in plain English that the group and t= he > protocol will address cross-world interop. > > It is not enough to claim that cross-world interop is included through la= ck > of explicit exclusion.=A0 That can lead to disputes about what was intend= ed to > be in scope and what was not.=A0 The charter needs to express the group's > scope clearly, that is its purpose. > > What's more, because cross-world interop is the area of greatest complexi= ty > in this work, it needs to be prominent as a deliverable.=A0 Currently the= re is > not even a hint of it in the deliverables, which is a major and extremely > important omission. > > Among the Foundational Components (the bullet list of paragraph 5), we ne= ed > a clause something like: > > A model describing the use of the protocol for interoperation between > multiple distinct virtual worlds and involving multiple region/agent doma= ins > and services. > > Unless the many possible scenarios of cross-world interop are carefully > considered, the protocol has no hope of working in such scenarios.=A0 Thi= s is > work we must do, or cross-world interop was just lip service after all. > > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Fri, Aug 28, 2009 at 7:27 PM, Infinity Linden > wrote: >> >> okay... here's what i think we've all agreed to. i've taken the >> liberty of using the VWRAP name since it seems to me we have consensus >> around that name. >> >> also note that i still have the ogpx@ietf.org email list in the >> charter text, since we don't have the VWRAP mailing list up yet. >> >> but the rest of it should be "correct" based on discussions. please >> look it over and tell me if i've missed something. >> >> -cheers >> -meadhbh >> >> Working Group Name: >> >> =A0Virtual Worlds Region Agent Protocol (VWRAP) >> >> Chairs: >> >> =A0TBD >> >> Area and Area Directors: >> >> =A0Applications Area >> >> =A0Lisa Dusseault >> =A0Alexey Melnikov >> >> Responsible Area Director: >> >> =A0TBD >> >> Mailing List: >> >> =A0ogpx@ietf.org >> =A0http://www.ietf.org/mailman/listinfo/ogpx >> >> Description of Working Group: >> >> The working group will define the Virtual Worlds Region Agent Protocol >> (VWRAP) for =A0collaborative 3-dimensional virtual =A0worlds. The protoc= ol >> permits =A0users =A0to =A0interact =A0with =A0each other =A0while =A0rep= resented =A0as >> "avatars," =A0or digital representations =A0of the =A0user. Within =A0a = single >> virtual =A0world, avatars =A0exist in =A0at most =A0one location =A0in = =A0a shared >> virtual =A0space. Conforming =A0client =A0applications use =A0the protoc= ol =A0to >> manipulate and =A0move the =A0user's avatar, create =A0objects in =A0a v= irtual >> world, interact =A0with other users =A0and their surroundings =A0and con= sume >> and create media and information from sources inside and outside their >> virtual world. >> >> Adjacent locations =A0in virtual worlds accessible by =A0this protocol m= ay >> be =A0 explicitly =A0 partitioned =A0into =A0 "regions" =A0 to =A0facili= tate =A0 the >> computational =A0and communication load =A0balancing required =A0to simu= late >> the virtual =A0environment. Such virtual =A0worlds may consist =A0of reg= ions >> administered =A0by distinct organizations. =A0Though these =A0virtual wo= rlds >> may =A0be partitioned, =A0they =A0remain "un-sharded;" =A0all inhabitant= s =A0and >> objects =A0in a =A0particular location =A0in =A0a virtual =A0world may = =A0initiate >> interaction with =A0all other inhabitants and objects =A0in that locatio= n; >> and, service =A0endpoint addresses =A0refer to at =A0most one =A0locatio= n. The >> state of =A0a virtual =A0world is independent =A0of the =A0client applic= ations >> that access it and may persist between user sessions. >> >> Regions and =A0services implemented according to =A0the specifications m= ay >> be deployed by separate =A0organizations with varying policies and trust >> domains. =A0The OGPX =A0protocols will =A0provide the =A0mechanisms =A0f= or these >> virtual world =A0services to interoperate, when permitted =A0by policy a= nd >> shared trust =A0domains. To support the exegesis =A0of the specification= s, >> the group =A0may define a =A0non-exhaustive set of =A0non-normative poli= cies >> protocol participants may enforce. >> >> The protocol =A0should describe interaction semantics =A0for these virtu= al >> worlds, independent of =A0transport, leveraging existing standards where >> practical. It =A0should define interoperability =A0expectations for serv= er >> to server =A0interactions as well as =A0client-server interactions. Thou= gh >> the =A0protocol =A0is =A0independent =A0of transport, =A0early =A0intero= perability >> trials used HTTP(S) for non-real-time messages. The working group will >> define specific =A0features that must be replicated =A0in other transpor= ts >> and =A0will =A0define =A0the use =A0of =A0HTTP(S) =A0as =A0a transport = =A0of =A0protocol >> messages. >> >> Foundational components of the protocol include the publication of: >> >> =A0* an abstract =A0type system, suitable for =A0describing the applicat= ion >> =A0 =A0protocol in an implementation neutral manner, >> >> =A0* a =A0 security =A0 model =A0 describing =A0trust =A0 relationships = =A0 between >> =A0 =A0participating entities, >> >> =A0* guidelines =A0 for =A0 the =A0 use =A0 of =A0existing =A0 authentic= ation =A0 and >> =A0 =A0confidentiality mechanisms, >> >> =A0* an application-layer =A0protocol for establishing =A0the user's ava= tar >> =A0 =A0in a virtual world, >> >> =A0* an application-layer =A0protocol for moving a =A0user's avatar betw= een >> =A0 =A0adjacent and remote locations in a virtual world, >> >> =A0* format descriptions for objects and avatars in a virtual world, and >> >> =A0* an =A0 application-layer =A0protocol =A0 for =A0identifying =A0 age= nts, =A0and >> =A0 =A0requesting information about them. >> >> The protocol =A0defined by this =A0group will carry information =A0about= the >> virtual =A0environment, =A0its contents =A0and =A0its =A0inhabitants. = =A0It is =A0an >> application layer protocol, =A0independent of transport, based partially >> on these previously published internet drafts: >> >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-intro >> =A0* http://tools.ietf.org/html/draft-hamrick-llsd >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-auth >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-launch >> =A0* http://tools.ietf.org/html/draft-lentczner-ogp-base >> =A0* http://tools.ietf.org/html/draft-levine-ogp-clientcap >> =A0* http://tools.ietf.org/html/draft-levine-ogp-layering >> >> Goals and Milestones: >> >> =A0* October =A02009 =A0 "Introduction =A0and =A0Goals" =A0to =A0the =A0= IESG =A0as =A0an >> =A0 =A0Informational RFC >> >> =A0* October 2009 "Abstract Type System for the Transmission of Dynamic >> =A0 =A0Structured Data" to the IESG as Proposed Standard >> >> =A0* October 2010 "Foundational Concepts and Transport Expectations" to >> =A0 =A0the IESG as Proposed Standard >> >> =A0* February 2010 "Guidelines for =A0Host Authentication" to the IESG a= s >> =A0 =A0an Informational RFC >> >> =A0* February =A02010 "Service =A0Establishment" =A0to the =A0IESG as = =A0Proposed >> =A0 =A0Standard >> >> =A0* February 2010 =A0"Client Application Launch Message" to =A0the IESG= as >> =A0 =A0an Informational RFC >> >> =A0* February 2010 =A0"Simulation Presence Establishment" to =A0the IESG= as >> =A0 =A0Proposed Standard >> >> =A0* June =A02010 =A0"Primitive Object =A0Format" =A0to =A0the =A0IESG a= s =A0Proposed >> =A0 =A0Standard >> >> =A0* June 2010 "Digital Asset Access" to the IESG as Proposed Standard >> >> =A0* June 2010 "Entity Identifiers" to the IESG as Proposed standard >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From morgaine.dinova@googlemail.com Sat Aug 29 04:57:27 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7423A6899 for ; Sat, 29 Aug 2009 04:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6oLjL5rbHMn for ; Sat, 29 Aug 2009 04:57:25 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 11A7D3A693C for ; Sat, 29 Aug 2009 04:57:24 -0700 (PDT) Received: by ewy3 with SMTP id 3so1091611ewy.42 for ; Sat, 29 Aug 2009 04:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=F8J19AkVMa/Y7IiPtiv6iCQe62e0ynhnFaWC225hDcY=; b=jPESk4rsTnF7P33rwzFJ2yZyN5u4T6YHDzsGo6oTSN2eDOAs+gHnNxuSTTCBsUTl0i UYnx5H8g5jqqtR3BGlWwocpy72msT+ynJ3pojgECvMcHO9glY3KkO4Q4aYxV5p2TBf8J M8ZB4pKeQDMhx02j2wrGbEazFirT0LKyZwKHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=UmqBY1mXOSRBWJOi0pMz8IgJAbmbOYeeraau+PDnGZ5OWf1/XfEZ3RQAcTQeN9qJJU R17YR9SrkCvG3DytX5XxOBvizcGOV6NtYAunVw+Txw/KGCZfrM54gFTCbinYuQL6dcQE EJfEayXIXTzuqtXld4mO1RUGQpL8A36F4nEa8= MIME-Version: 1.0 Received: by 10.211.159.13 with SMTP id l13mr2604300ebo.82.1251547047809; Sat, 29 Aug 2009 04:57:27 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> Date: Sat, 29 Aug 2009 12:57:27 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636d347c93454a30472468102 Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 11:57:28 -0000 --001636d347c93454a30472468102 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Aug 29, 2009 at 3:46 AM, Meadhbh Siobhan wrote: > i like where you're going with this, but i have to say, i really think > we should use the term "virtual world" only in a non-normative manner. > the term is simultaneously evocative as an descriptive term and a > lightning rod for disagreement when we attempt to define it. > This has nothing to do with whether "virtual world" is used normatively or not. It has to do with whether our terminology allows us to discuss the problem space, and then later whether it allows us to propose solutions that work within that problem space. Our problem space contains *multiple virtual world*s which need to be able to interoperate, fully independent worlds employing a common VWRAP protocol for interop but differing in absolutely everything else. We need to be able to refer to those worlds because they are first-class entities in our problem space, and your terminology prevents us from doing so. The suggestion that making "virtual world" normative would lead to disagreement misses the point that it is the highly non-standard use of "virtual world" to mean "the communicating parties" that has led to this disagreement in the first place. Indeed, we retained the "VW" in "VWRAP" because we agreed that it has a generally accepted meaning. And it does. In these days of interplanetary travel, the meaning of "world" is quite universal, and communication between worlds is an established physical process. The virtual analogues in "VW" and "VW interop" have exactly the same semantics. There are no disagreements at the implementation level about this because each implementor determines individually whether they are building a virtual world or not. LL knows that SL is a virtual world, and the owners of OSgrid know that OSgrid is a virtual world, and so will GALACTICuniverse and so will DRAGONSworld. The only thing that matters to us is whether those worlds employ VWRAP, and if they do so then interop between them is clearly in scope. Attempting to define "virtual world" prescriptively would of course create disagreement, but that is *neither intended nor required here*. We are not defining what worlds are like, but only how worlds communicate --- the only definition of "virtual world" that is required to enable cross-world interop is *as an endpoint of a communication*. Specifically, our terminology must be able to handle "avatar A teleports from region R1 in world W1 to region R2 in world W2". The virtual worlds W1 and W2 are key entities in our problem space because they are sets of regions and services which can be either disjoint or intersect in one or more elements. Those sets are crucially important to everyone concerned, as they define the identity and flavour and ownership and policies that make each virtual world distinct and interesting in its own right. Your redefinition of "virtual world" no longer allows us to discuss those endpoint worlds as distinct entities. When we cannot talk about world W1 and world W2, this presents a near-total impediment to delivering cross-world interop between them. Perhaps the question should be turned around. Why do the current OGP documents redefine "virtual world" contrary to common usage and seek to bar multiple virtual worlds from the discussion space? Morgaine. ================================ On Sat, Aug 29, 2009 at 3:46 AM, Meadhbh Siobhan wrote: > i like where you're going with this, but i have to say, i really think > we should use the term "virtual world" only in a non-normative manner. > the term is simultaneously evocative as an descriptive term and a > lightning rod for disagreement when we attempt to define it. > > david's work on deployment patterns should definitely be included > somewhere. i think it _would_ help people new to the group to > understand what we're working on, and it seems like what you're asking > is to talk about deployment patterns. some people might shy away from > the term "model" (myself included) in favor of "pattern" since the > latter admits more abstraction to the process. > > how 'bout, "Deployment patterns for describing the use of the protocol > for interoperation between multiple region/agent domains and > services." > > -cheers > -meadhbh > > On Fri, Aug 28, 2009 at 7:10 PM, Morgaine > wrote: > > This charter still does not mention in plain English that the group and > the > > protocol will address cross-world interop. > > > > It is not enough to claim that cross-world interop is included through > lack > > of explicit exclusion. That can lead to disputes about what was intended > to > > be in scope and what was not. The charter needs to express the group's > > scope clearly, that is its purpose. > > > > What's more, because cross-world interop is the area of greatest > complexity > > in this work, it needs to be prominent as a deliverable. Currently there > is > > not even a hint of it in the deliverables, which is a major and extremely > > important omission. > > > > Among the Foundational Components (the bullet list of paragraph 5), we > need > > a clause something like: > > > > A model describing the use of the protocol for interoperation between > > multiple distinct virtual worlds and involving multiple region/agent > domains > > and services. > > > > Unless the many possible scenarios of cross-world interop are carefully > > considered, the protocol has no hope of working in such scenarios. This > is > > work we must do, or cross-world interop was just lip service after all. > > > > > > Morgaine. > > > > > > > > > > > > ======================= > > > > On Fri, Aug 28, 2009 at 7:27 PM, Infinity Linden > > > wrote: > >> > >> okay... here's what i think we've all agreed to. i've taken the > >> liberty of using the VWRAP name since it seems to me we have consensus > >> around that name. > >> > >> also note that i still have the ogpx@ietf.org email list in the > >> charter text, since we don't have the VWRAP mailing list up yet. > >> > >> but the rest of it should be "correct" based on discussions. please > >> look it over and tell me if i've missed something. > >> > >> -cheers > >> -meadhbh > >> > >> Working Group Name: > >> > >> Virtual Worlds Region Agent Protocol (VWRAP) > >> > >> Chairs: > >> > >> TBD > >> > >> Area and Area Directors: > >> > >> Applications Area > >> > >> Lisa Dusseault > >> Alexey Melnikov > >> > >> Responsible Area Director: > >> > >> TBD > >> > >> Mailing List: > >> > >> ogpx@ietf.org > >> http://www.ietf.org/mailman/listinfo/ogpx > >> > >> Description of Working Group: > >> > >> The working group will define the Virtual Worlds Region Agent Protocol > >> (VWRAP) for collaborative 3-dimensional virtual worlds. The protocol > >> permits users to interact with each other while represented as > >> "avatars," or digital representations of the user. Within a single > >> virtual world, avatars exist in at most one location in a shared > >> virtual space. Conforming client applications use the protocol to > >> manipulate and move the user's avatar, create objects in a virtual > >> world, interact with other users and their surroundings and consume > >> and create media and information from sources inside and outside their > >> virtual world. > >> > >> Adjacent locations in virtual worlds accessible by this protocol may > >> be explicitly partitioned into "regions" to facilitate the > >> computational and communication load balancing required to simulate > >> the virtual environment. Such virtual worlds may consist of regions > >> administered by distinct organizations. Though these virtual worlds > >> may be partitioned, they remain "un-sharded;" all inhabitants and > >> objects in a particular location in a virtual world may initiate > >> interaction with all other inhabitants and objects in that location; > >> and, service endpoint addresses refer to at most one location. The > >> state of a virtual world is independent of the client applications > >> that access it and may persist between user sessions. > >> > >> Regions and services implemented according to the specifications may > >> be deployed by separate organizations with varying policies and trust > >> domains. The OGPX protocols will provide the mechanisms for these > >> virtual world services to interoperate, when permitted by policy and > >> shared trust domains. To support the exegesis of the specifications, > >> the group may define a non-exhaustive set of non-normative policies > >> protocol participants may enforce. > >> > >> The protocol should describe interaction semantics for these virtual > >> worlds, independent of transport, leveraging existing standards where > >> practical. It should define interoperability expectations for server > >> to server interactions as well as client-server interactions. Though > >> the protocol is independent of transport, early interoperability > >> trials used HTTP(S) for non-real-time messages. The working group will > >> define specific features that must be replicated in other transports > >> and will define the use of HTTP(S) as a transport of protocol > >> messages. > >> > >> Foundational components of the protocol include the publication of: > >> > >> * an abstract type system, suitable for describing the application > >> protocol in an implementation neutral manner, > >> > >> * a security model describing trust relationships between > >> participating entities, > >> > >> * guidelines for the use of existing authentication and > >> confidentiality mechanisms, > >> > >> * an application-layer protocol for establishing the user's avatar > >> in a virtual world, > >> > >> * an application-layer protocol for moving a user's avatar between > >> adjacent and remote locations in a virtual world, > >> > >> * format descriptions for objects and avatars in a virtual world, and > >> > >> * an application-layer protocol for identifying agents, and > >> requesting information about them. > >> > >> The protocol defined by this group will carry information about the > >> virtual environment, its contents and its inhabitants. It is an > >> application layer protocol, independent of transport, based partially > >> on these previously published internet drafts: > >> > >> * http://tools.ietf.org/html/draft-hamrick-ogp-intro > >> * http://tools.ietf.org/html/draft-hamrick-llsd > >> * http://tools.ietf.org/html/draft-hamrick-ogp-auth > >> * http://tools.ietf.org/html/draft-hamrick-ogp-launch > >> * http://tools.ietf.org/html/draft-lentczner-ogp-base > >> * http://tools.ietf.org/html/draft-levine-ogp-clientcap > >> * http://tools.ietf.org/html/draft-levine-ogp-layering > >> > >> Goals and Milestones: > >> > >> * October 2009 "Introduction and Goals" to the IESG as an > >> Informational RFC > >> > >> * October 2009 "Abstract Type System for the Transmission of Dynamic > >> Structured Data" to the IESG as Proposed Standard > >> > >> * October 2010 "Foundational Concepts and Transport Expectations" to > >> the IESG as Proposed Standard > >> > >> * February 2010 "Guidelines for Host Authentication" to the IESG as > >> an Informational RFC > >> > >> * February 2010 "Service Establishment" to the IESG as Proposed > >> Standard > >> > >> * February 2010 "Client Application Launch Message" to the IESG as > >> an Informational RFC > >> > >> * February 2010 "Simulation Presence Establishment" to the IESG as > >> Proposed Standard > >> > >> * June 2010 "Primitive Object Format" to the IESG as Proposed > >> Standard > >> > >> * June 2010 "Digital Asset Access" to the IESG as Proposed Standard > >> > >> * June 2010 "Entity Identifiers" to the IESG as Proposed standard > >> _______________________________________________ > >> ogpx mailing list > >> ogpx@ietf.org > >> https://www.ietf.org/mailman/listinfo/ogpx > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --001636d347c93454a30472468102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Aug 29, 2009 at 3:46 AM, Meadhbh Siobhan <meadhbh.siobhan@gmail.com><= /span> wrote:
i like where you're going with this, but i have to say, i really think<= br> we should use the term "virtual world" only in a non-normative ma= nner.
the term is simultaneously evocative as an descriptive term and a
lightning rod for disagreement when we attempt to define it.


This has nothing to do with whether "virtual= world" is used normatively or not.=A0 It has to do with whether our t= erminology allows us to discuss the problem space, and then later whether i= t allows us to propose solutions that work within that problem space.

Our problem space contains multiple virtual worlds which need to= be able to interoperate, fully independent worlds employing a common VWRAP= protocol for interop but differing in absolutely everything else.=A0 We ne= ed to be able to refer to those worlds because they are first-class entitie= s in our problem space, and your terminology prevents us from doing so.

The suggestion that making "virtual world" normative would le= ad to disagreement misses the point that it is the highly non-standard use = of "virtual world" to mean "the communicating parties" = that has led to this disagreement in the first place.=A0 Indeed, we retaine= d the "VW"=A0 in "VWRAP" because we agreed that it has = a generally accepted meaning.

And it does.=A0 In these days of interplanetary travel, the meaning of = "world" is quite universal, and communication between worlds is a= n established physical process.=A0 The virtual analogues in "VW" = and "VW interop" have exactly the same semantics.

There are no disagreements at the implementation level about this becau= se each implementor determines individually whether they are building a vir= tual world or not.=A0 LL knows that SL is a virtual world, and the owners o= f OSgrid know that OSgrid is a virtual world, and so will GALACTICuniverse = and so will DRAGONSworld.=A0 The only thing that matters to us is whether t= hose worlds employ VWRAP, and if they do so then interop between them is cl= early in scope.
=A0
Attempting to define "virtual world" prescriptively would = of course create disagreement, but that is neither intended nor required= here.=A0 We are not defining what worlds are like, but only how worlds= communicate --- the only definition of "virtual world" that is r= equired to enable cross-world interop is as an endpoint of a communicati= on.

Specifically, our terminology must be able to handle "avatar A tel= eports from region R1 in world W1 to region R2 in world W2".=A0 The vi= rtual worlds W1 and W2 are key entities in our problem space because they a= re sets of regions and services which can be either disjoint or intersect i= n one or more elements.=A0 Those sets are crucially important to everyone c= oncerned, as they define the identity and flavour and ownership and policie= s that make each virtual world distinct and interesting in its own right.
Your redefinition of "virtual world" no longer allows us to d= iscuss those endpoint worlds as distinct entities.=A0 When we cannot talk a= bout world W1 and world W2, this presents a near-total impediment to delive= ring cross-world interop between them.

Perhaps the question should be turned around.=A0 Why do the current OGP= documents redefine "virtual world" contrary to common usage and = seek to bar multiple virtual worlds from the discussion space?


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= div class=3D"gmail_quote">On Sat, Aug 29, 2009 at 3:46 AM, Meadhbh Siobhan = <meadhbh.= siobhan@gmail.com> wrote:
i like where you&= #39;re going with this, but i have to say, i really think
we should use the term "virtual world" only in a non-normative ma= nner.
the term is simultaneously evocative as an descriptive term and a
lightning rod for disagreement when we attempt to define it.

david's work on deployment patterns should definitely be included
somewhere. i think it _would_ help people new to the group to
understand what we're working on, and it seems like what you're ask= ing
is to talk about deployment patterns. some people might shy away from
the term "model" (myself included) in favor of "pattern"= ; since the
latter admits more abstraction to the process.

how 'bout, "Deployment patterns for describing the use of the prot= ocol
for interoperation between multiple region/agent domains and
services."

-cheers
-meadhbh

On Fri, Aug 28, 2009 at 7:10 PM, Morgaine<morgaine.dinova@googlemail.com> wrote:
> This charter still does not mention in plain English that the group an= d the
> protocol will address cross-world interop.
>
> It is not enough to claim that cross-world interop is included through= lack
> of explicit exclusion.=A0 That can lead to disputes about what was int= ended to
> be in scope and what was not.=A0 The charter needs to express the grou= p's
> scope clearly, that is its purpose.
>
> What's more, because cross-world interop is the area of greatest c= omplexity
> in this work, it needs to be prominent as a deliverable.=A0 Currently = there is
> not even a hint of it in the deliverables, which is a major and extrem= ely
> important omission.
>
> Among the Foundational Components (the bullet list of paragraph 5), we= need
> a clause something like:
>
> A model describing the use of the protocol for interoperation between<= br> > multiple distinct virtual worlds and involving multiple region/agent d= omains
> and services.
>
> Unless the many possible scenarios of cross-world interop are carefull= y
> considered, the protocol has no hope of working in such scenarios.=A0 = This is
> work we must do, or cross-world interop was just lip service after all= .
>
>
> Morgaine.
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= br> >
> On Fri, Aug 28, 2009 at 7:27 PM, Infinity Linden <infinity@lindenlab.com>
> wrote:
>>
>> okay... here's what i think we've all agreed to. i've = taken the
>> liberty of using the VWRAP name since it seems to me we have conse= nsus
>> around that name.
>>
>> also note that i still have the o= gpx@ietf.org email list in the
>> charter text, since we don't have the VWRAP mailing list up ye= t.
>>
>> but the rest of it should be "correct" based on discussi= ons. please
>> look it over and tell me if i've missed something.
>>
>> -cheers
>> -meadhbh
>>
>> Working Group Name:
>>
>> =A0Virtual Worlds Region Agent Protocol (VWRAP)
>>
>> Chairs:
>>
>> =A0TBD
>>
>> Area and Area Directors:
>>
>> =A0Applications Area
>>
>> =A0Lisa Dusseault <= lisa.dusseault@gmail.com>
>> =A0Alexey Melnikov <alexey.melnikov@isode.com>
>>
>> Responsible Area Director:
>>
>> =A0TBD
>>
>> Mailing List:
>>
>> =A0ogpx@ietf.org
>> =A0http://www.ietf.org/mailman/listinfo/ogpx
>>
>> Description of Working Group:
>>
>> The working group will define the Virtual Worlds Region Agent Prot= ocol
>> (VWRAP) for =A0collaborative 3-dimensional virtual =A0worlds. The = protocol
>> permits =A0users =A0to =A0interact =A0with =A0each other =A0while = =A0represented =A0as
>> "avatars," =A0or digital representations =A0of the =A0us= er. Within =A0a single
>> virtual =A0world, avatars =A0exist in =A0at most =A0one location = =A0in =A0a shared
>> virtual =A0space. Conforming =A0client =A0applications use =A0the = protocol =A0to
>> manipulate and =A0move the =A0user's avatar, create =A0objects= in =A0a virtual
>> world, interact =A0with other users =A0and their surroundings =A0a= nd consume
>> and create media and information from sources inside and outside t= heir
>> virtual world.
>>
>> Adjacent locations =A0in virtual worlds accessible by =A0this prot= ocol may
>> be =A0 explicitly =A0 partitioned =A0into =A0 "regions" = =A0 to =A0facilitate =A0 the
>> computational =A0and communication load =A0balancing required =A0t= o simulate
>> the virtual =A0environment. Such virtual =A0worlds may consist =A0= of regions
>> administered =A0by distinct organizations. =A0Though these =A0virt= ual worlds
>> may =A0be partitioned, =A0they =A0remain "un-sharded;" = =A0all inhabitants =A0and
>> objects =A0in a =A0particular location =A0in =A0a virtual =A0world= may =A0initiate
>> interaction with =A0all other inhabitants and objects =A0in that l= ocation;
>> and, service =A0endpoint addresses =A0refer to at =A0most one =A0l= ocation. The
>> state of =A0a virtual =A0world is independent =A0of the =A0client = applications
>> that access it and may persist between user sessions.
>>
>> Regions and =A0services implemented according to =A0the specificat= ions may
>> be deployed by separate =A0organizations with varying policies and= trust
>> domains. =A0The OGPX =A0protocols will =A0provide the =A0mechanism= s =A0for these
>> virtual world =A0services to interoperate, when permitted =A0by po= licy and
>> shared trust =A0domains. To support the exegesis =A0of the specifi= cations,
>> the group =A0may define a =A0non-exhaustive set of =A0non-normativ= e policies
>> protocol participants may enforce.
>>
>> The protocol =A0should describe interaction semantics =A0for these= virtual
>> worlds, independent of =A0transport, leveraging existing standards= where
>> practical. It =A0should define interoperability =A0expectations fo= r server
>> to server =A0interactions as well as =A0client-server interactions= . Though
>> the =A0protocol =A0is =A0independent =A0of transport, =A0early =A0= interoperability
>> trials used HTTP(S) for non-real-time messages. The working group = will
>> define specific =A0features that must be replicated =A0in other tr= ansports
>> and =A0will =A0define =A0the use =A0of =A0HTTP(S) =A0as =A0a trans= port =A0of =A0protocol
>> messages.
>>
>> Foundational components of the protocol include the publication of= :
>>
>> =A0* an abstract =A0type system, suitable for =A0describing the ap= plication
>> =A0 =A0protocol in an implementation neutral manner,
>>
>> =A0* a =A0 security =A0 model =A0 describing =A0trust =A0 relation= ships =A0 between
>> =A0 =A0participating entities,
>>
>> =A0* guidelines =A0 for =A0 the =A0 use =A0 of =A0existing =A0 aut= hentication =A0 and
>> =A0 =A0confidentiality mechanisms,
>>
>> =A0* an application-layer =A0protocol for establishing =A0the user= 's avatar
>> =A0 =A0in a virtual world,
>>
>> =A0* an application-layer =A0protocol for moving a =A0user's a= vatar between
>> =A0 =A0adjacent and remote locations in a virtual world,
>>
>> =A0* format descriptions for objects and avatars in a virtual worl= d, and
>>
>> =A0* an =A0 application-layer =A0protocol =A0 for =A0identifying = =A0 agents, =A0and
>> =A0 =A0requesting information about them.
>>
>> The protocol =A0defined by this =A0group will carry information = =A0about the
>> virtual =A0environment, =A0its contents =A0and =A0its =A0inhabitan= ts. =A0It is =A0an
>> application layer protocol, =A0independent of transport, based par= tially
>> on these previously published internet drafts:
>>
>> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-intro<= br> >> =A0* http://tools.ietf.org/html/draft-hamrick-llsd
>> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-auth >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-launch
>> =A0* http://tools.ietf.org/html/draft-lentczner-ogp-base
>> =A0* http://tools.ietf.org/html/draft-levine-ogp-clientca= p
>> =A0* http://tools.ietf.org/html/draft-levine-ogp-layering<= /a>
>>
>> Goals and Milestones:
>>
>> =A0* October =A02009 =A0 "Introduction =A0and =A0Goals" = =A0to =A0the =A0 IESG =A0as =A0an
>> =A0 =A0Informational RFC
>>
>> =A0* October 2009 "Abstract Type System for the Transmission = of Dynamic
>> =A0 =A0Structured Data" to the IESG as Proposed Standard
>>
>> =A0* October 2010 "Foundational Concepts and Transport Expect= ations" to
>> =A0 =A0the IESG as Proposed Standard
>>
>> =A0* February 2010 "Guidelines for =A0Host Authentication&quo= t; to the IESG as
>> =A0 =A0an Informational RFC
>>
>> =A0* February =A02010 "Service =A0Establishment" =A0to t= he =A0IESG as =A0Proposed
>> =A0 =A0Standard
>>
>> =A0* February 2010 =A0"Client Application Launch Message"= ; to =A0the IESG as
>> =A0 =A0an Informational RFC
>>
>> =A0* February 2010 =A0"Simulation Presence Establishment"= ; to =A0the IESG as
>> =A0 =A0Proposed Standard
>>
>> =A0* June =A02010 =A0"Primitive Object =A0Format" =A0to = =A0the =A0IESG as =A0Proposed
>> =A0 =A0Standard
>>
>> =A0* June 2010 "Digital Asset Access" to the IESG as Pro= posed Standard
>>
>> =A0* June 2010 "Entity Identifiers" to the IESG as Propo= sed standard
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

--001636d347c93454a30472468102-- From carlo@alinoe.com Sat Aug 29 16:06:45 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DF573A6CB5 for ; Sat, 29 Aug 2009 16:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.365 X-Spam-Level: X-Spam-Status: No, score=-1.365 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4gNEv-tDUQh for ; Sat, 29 Aug 2009 16:06:44 -0700 (PDT) Received: from viefep20-int.chello.at (viefep20-int.chello.at [62.179.121.40]) by core3.amsl.com (Postfix) with ESMTP id D89F13A6AA6 for ; Sat, 29 Aug 2009 16:06:43 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep20-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090829230649.EYCP11480.viefep20-int.chello.at@edge02.upc.biz>; Sun, 30 Aug 2009 01:06:49 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upc.biz with edge id aP6n1c00G0FlQed02P6oEl; Sun, 30 Aug 2009 01:06:49 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MhX1a-0005x8-GX; Sun, 30 Aug 2009 01:07:58 +0200 Date: Sun, 30 Aug 2009 01:07:58 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20090829230758.GA22756@alinoe.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <3a880e2c0908270937j73fe7567t8779d193135d0b5f@mail.gmail.com> <4A97F4EA.2030803@dcrocker.net> <3a880e2c0908280821v44782ac7u6deedc7335faae80@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a880e2c0908280821v44782ac7u6deedc7335faae80@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org, dcrocker@bbiw.net Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 23:06:45 -0000 On Fri, Aug 28, 2009 at 08:21:44AM -0700, Infinity Linden wrote: > but above is just so cool! I totally agree with the argument that it's bad if you can't search for it with Google. -- Carlo Wood From carlo@alinoe.com Sat Aug 29 16:13:09 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163A33A694C for ; Sat, 29 Aug 2009 16:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcK1m98kH7Y9 for ; Sat, 29 Aug 2009 16:13:08 -0700 (PDT) Received: from viefep13-int.chello.at (viefep13-int.chello.at [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id D9A8D3A6954 for ; Sat, 29 Aug 2009 16:13:07 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep13-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090829231313.UAV2474.viefep13-int.chello.at@edge02.upc.biz>; Sun, 30 Aug 2009 01:13:13 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upc.biz with edge id aPDB1c05J0FlQed02PDCU2; Sun, 30 Aug 2009 01:13:13 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MhX7n-00063B-GL; Sun, 30 Aug 2009 01:14:23 +0200 Date: Sun, 30 Aug 2009 01:14:23 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20090829231423.GB22756@alinoe.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <3a880e2c0908270937j73fe7567t8779d193135d0b5f@mail.gmail.com> <4A97F4EA.2030803@dcrocker.net> <3a880e2c0908280823y564193f2n513c1e16929a4cde@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a880e2c0908280823y564193f2n513c1e16929a4cde@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org, dcrocker@bbiw.net Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 23:13:09 -0000 On Fri, Aug 28, 2009 at 08:23:39AM -0700, Infinity Linden wrote: > but seriously, seems like we're getting close. > > VWRAP seems reasonable, even though it suffers from the ATM Machine problem. Depends, I'd just say 'ATM' and leave out 'Machine' anyway. I never say HTTP Protocol either, I just say HTTP, SMTP etc. Random conversation: "What protocol shall we use?", "Lets use VWRAP." No problem. You might argue that the WG should have a different name though. If the protocol is VWRAP, or VRAP, then the working group name could be "VRAX Working Group" ? I guess I hereby propose: VRAX WG -- Carlo Wood From carlo@alinoe.com Sat Aug 29 16:20:11 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FCF23A6A1B for ; Sat, 29 Aug 2009 16:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-aQwESRRYlv for ; Sat, 29 Aug 2009 16:20:11 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id 73BAE3A69AD for ; Sat, 29 Aug 2009 16:20:10 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090829232016.WLZL25702.viefep18-int.chello.at@edge05.upc.biz>; Sun, 30 Aug 2009 01:20:16 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id aPLD1c03a0FlQed05PLF9v; Sun, 30 Aug 2009 01:20:16 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MhXEb-0006A0-1e; Sun, 30 Aug 2009 01:21:25 +0200 Date: Sun, 30 Aug 2009 01:21:25 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20090829232125.GC22756@alinoe.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <4646639E08F58B42836FAC24C94624DD6FE8098411@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0908281259h3a10cd02mc92eb8331c92f162@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a880e2c0908281259h3a10cd02mc92eb8331c92f162@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "ogpx@ietf.org" Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2009 23:20:11 -0000 On Fri, Aug 28, 2009 at 12:59:58PM -0700, Infinity Linden wrote: > also, i just did a google search for VWRAP and got a whole lot of "not > much." ergo, we're not competing with another common name with lots of > search results. so from that perspective, i'm starting to get happy > about the VWRAP name, even though i thought ABOVE was cooler. i think > morgaine's comments about NOT picking a common name are definitely > spot on in this regard. Ok, since everyone else that commented so far seems to be happy, ignore my VRAX WG proposal ;). I'm obviously happy with "VWRAP working group". The argument to leave in 'World' in order to make it a lot more clear what the WG/protocol is NOT about is a good one too. -- Carlo Wood From carlo@alinoe.com Sat Aug 29 17:29:46 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB80A3A68DC for ; Sat, 29 Aug 2009 17:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYdGSw2df49U for ; Sat, 29 Aug 2009 17:29:45 -0700 (PDT) Received: from viefep14-int.chello.at (viefep14-int.chello.at [62.179.121.34]) by core3.amsl.com (Postfix) with ESMTP id 456B33A67E5 for ; Sat, 29 Aug 2009 17:29:42 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep14-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090830002947.EJQM29725.viefep14-int.chello.at@edge05.upc.biz>; Sun, 30 Aug 2009 02:29:47 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id aQVj1c05G0FlQed05QVlRs; Sun, 30 Aug 2009 02:29:47 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MhYJr-00071I-G2; Sun, 30 Aug 2009 02:30:55 +0200 Date: Sun, 30 Aug 2009 02:30:55 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20090830003055.GD22756@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 00:29:46 -0000 On Fri, Aug 28, 2009 at 11:27:08AM -0700, Infinity Linden wrote: > Adjacent locations in virtual worlds accessible by this protocol may > be explicitly partitioned into "regions" to facilitate the > computational and communication load balancing required to simulate > the virtual environment. Such virtual worlds may consist of regions > administered by distinct organizations. Though these virtual worlds > may be partitioned, they remain "un-sharded;" all inhabitants and > objects in a particular location in a virtual world may initiate > interaction with all other inhabitants and objects in that location; > and, service endpoint addresses refer to at most one location. The > state of a virtual world is independent of the client applications > that access it and may persist between user sessions. Going with the definition that "virtual world" is from the perspective of the user (every place reachable), I think that using "a virtual world" is less confusing, and I'd rewrite the above paragraph as follows: Adjacent locations in a virtual world accessible by this protocol may be explicitly partitioned into "regions" to facilitate the computational and communication load balancing required to simulate the virtual environment. Such a virtual world may consist of regions administered by distinct organizations. Though virtual worlds may be partitioned, they remain "un-sharded;" all inhabitants and objects in a particular location in a virtual world may initiate interaction with all other inhabitants and objects in that location; and service endpoint addresses refer to at most one location. The state of a virtual world is independent of the client applications that access it and may persist between user sessions. (also removed the comma after 'and'). > Regions and services implemented according to the specifications may > be deployed by separate organizations with varying policies and trust > domains. The OGPX protocols will provide the mechanisms for these s/The OGPX protocols/VWRAP/ > virtual world services to interoperate, when permitted by policy and > shared trust domains. To support the exegesis of the specifications, > the group may define a non-exhaustive set of non-normative policies > protocol participants may enforce. s/protocol/that protocol/ > > The protocol should describe interaction semantics for these virtual > worlds, independent of transport, leveraging existing standards where Idem, in order to not confuse people in thinking that the collection of all reachable regions exists of multiple virtual worlds, I'd use "a virtual world" here. Thus: The protocol should describe interaction semantics for the regions of a virtual world independent of transport, leveraging existing standards where > practical. It should define interoperability expectations for server > to server interactions as well as client-server interactions. Though > the protocol is independent of transport, early interoperability > trials used HTTP(S) for non-real-time messages. The working group will > define specific features that must be replicated in other transports > and will define the use of HTTP(S) as a transport of protocol > messages. > > Foundational components of the protocol include the publication of: > > * an abstract type system, suitable for describing the application > protocol in an implementation neutral manner, > > * a security model describing trust relationships between > participating entities, > > * guidelines for the use of existing authentication and > confidentiality mechanisms, > > * an application-layer protocol for establishing the user's avatar > in a virtual world, > > * an application-layer protocol for moving a user's avatar between > adjacent and remote locations in a virtual world, > > * format descriptions for objects and avatars in a virtual world, and > > * an application-layer protocol for identifying agents, and > requesting information about them. > > The protocol defined by this group will carry information about the > virtual environment, its contents and its inhabitants. It is an > application layer protocol, independent of transport, based partially > on these previously published internet drafts: > > * http://tools.ietf.org/html/draft-hamrick-ogp-intro > * http://tools.ietf.org/html/draft-hamrick-llsd > * http://tools.ietf.org/html/draft-hamrick-ogp-auth > * http://tools.ietf.org/html/draft-hamrick-ogp-launch > * http://tools.ietf.org/html/draft-lentczner-ogp-base > * http://tools.ietf.org/html/draft-levine-ogp-clientcap > * http://tools.ietf.org/html/draft-levine-ogp-layering > > Goals and Milestones: > > * October 2009 "Introduction and Goals" to the IESG as an > Informational RFC > > * October 2009 "Abstract Type System for the Transmission of Dynamic > Structured Data" to the IESG as Proposed Standard > > * October 2010 "Foundational Concepts and Transport Expectations" to > the IESG as Proposed Standard > > * February 2010 "Guidelines for Host Authentication" to the IESG as > an Informational RFC > > * February 2010 "Service Establishment" to the IESG as Proposed > Standard > > * February 2010 "Client Application Launch Message" to the IESG as > an Informational RFC > > * February 2010 "Simulation Presence Establishment" to the IESG as > Proposed Standard > > * June 2010 "Primitive Object Format" to the IESG as Proposed > Standard > > * June 2010 "Digital Asset Access" to the IESG as Proposed Standard > > * June 2010 "Entity Identifiers" to the IESG as Proposed standard However, I remain sceptical about the lack of stressing the importance of making interop possible as much as possible between regions where little overlap in ToS exist, or only partial trust exists. Imho, the whole effort of this group is meaningless unless the end result will make it possible for many independent parties to take part in creating one big virtual world. The more (policy) restrictions are *necessary* for an acceptable interop, the less this effort will have succeeded; hence, it should be an important, of not the most important goal of this working group! -- Carlo Wood From meadhbh.siobhan@gmail.com Sat Aug 29 17:54:04 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBC2D3A6A32 for ; Sat, 29 Aug 2009 17:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm2f9mbmhrC0 for ; Sat, 29 Aug 2009 17:54:04 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id 3CF9B3A6A13 for ; Sat, 29 Aug 2009 17:54:04 -0700 (PDT) Received: by iwn38 with SMTP id 38so1349338iwn.29 for ; Sat, 29 Aug 2009 17:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TztXWfIvo/voZrkY930qoNHY73TUdgJEI+frzUMERJY=; b=xhcrJB83rOxV/uDWptvMv2lMWGEXFJndYBwv4Bv1n1Tu/pFFhWnPddpqAYIiFeyDey v/mu4ko5kJiRnkngdqRdzU2ehMIo2b4Anw6MLW0XEiGbhdTDEVsm0Gbq4XeYtTH0SSQh BTYYRPe/0wct8XDEe0S8y2FvIfj1W5o+DgNvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rsgrCMnadXrFyoawbD8EmcqDmE9COm1bZEtjgtCHBGPTBr5S1mTtvXaFd8/B1NxB/x RVbuYjSDyX64A/1IjSz4oSOGgTBopQHjeA+ici2weLlHrDJp8VBkAiIlZfLAjlfrIYg4 LQ74z5ZpBSrm4Q69MHsC1noj5dKrh+byvm7es= MIME-Version: 1.0 Received: by 10.231.124.227 with SMTP id v35mr3468399ibr.18.1251593648771; Sat, 29 Aug 2009 17:54:08 -0700 (PDT) In-Reply-To: <20090830003055.GD22756@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> Date: Sat, 29 Aug 2009 17:54:08 -0700 Message-ID: From: Meadhbh Siobhan To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Cc: Infinity Linden , ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 00:54:05 -0000 > > Imho, the whole effort of this group is meaningless unless the end result > will make it possible for many independent parties to take part in > creating one big virtual world. The more (policy) restrictions are > *necessary* for an acceptable interop, the less this effort will > have succeeded; hence, it should be an important, of not the most > important goal of this working group! > +1 From morgaine.dinova@googlemail.com Sun Aug 30 02:25:55 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707A53A6767 for ; Sun, 30 Aug 2009 02:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poxNUJt35kOU for ; Sun, 30 Aug 2009 02:25:54 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 1638F3A659A for ; Sun, 30 Aug 2009 02:25:53 -0700 (PDT) Received: by ewy3 with SMTP id 3so1521046ewy.42 for ; Sun, 30 Aug 2009 02:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Z2ar1OGP5KMcJx4DyVFz0P1iA0nAsYTc/gd/l+pKIPM=; b=rS3Dq9bGhlSPnui9aqxIx3S7lPojRXWavN08+vkCsAQcTPN+aC4FCNLMsyavq47JcU uHlKVLfKNNj7H2EV1WZk8Om9rEw4BrXdfK2yDogJBRnQNgbuJoMLqKa13PISGJMNaCso sD2NPsFkd/ZRhwgFMpzpJhiCSZU9coCLNHI14= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=IR5UZe4q6eoSohNlwtyzF/ZhLQMFZquLUZgGlkLpS+EUAQXSyXKhfQjbGylnVl/aio 6BkEb4dJpXUz6FTYlJYJgpVWJylRLpZ8aqXU6lVYoIOw87vpnRsh/Iz8A2xUxL0XuPd7 kQNGOkTwfZkqc+k+0co9VY3VYXNP9nWwyYV1E= MIME-Version: 1.0 Received: by 10.211.165.11 with SMTP id s11mr2781029ebo.33.1251624358928; Sun, 30 Aug 2009 02:25:58 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> Date: Sun, 30 Aug 2009 10:25:58 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174c341a4e60e704725881f2 Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 09:25:55 -0000 --0015174c341a4e60e704725881f2 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 30, 2009 at 1:54 AM, Meadhbh Siobhan wrote: > > > > Imho, the whole effort of this group is meaningless unless the end result > > will make it possible for many independent parties to take part in > > creating one big virtual world. The more (policy) restrictions are > > *necessary* for an acceptable interop, the less this effort will > > have succeeded; hence, it should be an important, of not the most > > important goal of this working group! > > > > +1 That expression of support looks promising. The main barriers preventing us from achieving this are: 1. Our inability to even discuss multiple virtual worlds because the language in the drafts overloads the term with a fictitious new "virtual world" that clashes with the normal usage. 2. The lack of a listed deliverable that would require us to ensure that the proposed protocol does actually deliver interop between distinct virtual worlds that implement VWRAP. I hope we can turn the expressed desire for cross-world interop into something concrete. Morgaine. ========================== On Sun, Aug 30, 2009 at 1:54 AM, Meadhbh Siobhan wrote: > > > > Imho, the whole effort of this group is meaningless unless the end result > > will make it possible for many independent parties to take part in > > creating one big virtual world. The more (policy) restrictions are > > *necessary* for an acceptable interop, the less this effort will > > have succeeded; hence, it should be an important, of not the most > > important goal of this working group! > > > > +1 > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0015174c341a4e60e704725881f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Aug 30, 2009 at 1:54 AM, Meadhbh Siobhan <meadhbh.siobhan@gmail.com><= /span> wrote:
>
> Imho, the whole effort of this group is meaningless unless the end res= ult
> will make it possible for many independent parties to take part in
> creating one big virtual world. The more (policy) restrictions are
> *necessary* for an acceptable interop, the less this effort will
> have succeeded; hence, it should be an important, of not the most
> important goal of this working group!
>

+1


That expression of support looks promising.=A0= The main barriers preventing us from achieving this are:

  1. Ou= r inability to even discuss multiple virtual worlds because the language in= the drafts overloads the term with a fictitious new "virtual world&qu= ot; that clashes with the normal usage.
  2. The lack of a listed deliverable that would require us to ensure that t= he proposed protocol does actually deliver interop between distinct virtual= worlds that implement VWRAP.

I hope we can turn the expressed= desire for cross-world interop into something concrete.

Morgaine.







=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Sun, Aug 30, 2009 at 1:54 AM, Meadhbh Siobhan = <meadhbh.siobhan@gmail.com<= /a>> wrote:
>
> Imho, the whole effort of this group is meaningless unless the end res= ult
> will make it possible for many independent parties to take part in
> creating one big virtual world. The more (policy) restrictions are
> *necessary* for an acceptable interop, the less this effort will
> have succeeded; hence, it should be an important, of not the most
> important goal of this working group!
>

+1

--0015174c341a4e60e704725881f2-- From kari.lippert@gmail.com Sun Aug 30 05:05:29 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F1C28C0F2 for ; Sun, 30 Aug 2009 05:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJTCWXbld0Jj for ; Sun, 30 Aug 2009 05:05:28 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id C04B728C0EB for ; Sun, 30 Aug 2009 05:05:27 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so676991eye.51 for ; Sun, 30 Aug 2009 05:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=A0uDWpZGR8n3xqAVU+fYFC1hCzz4AIIzpFlyngo7c5g=; b=cG2sCcWzpPVIXIZR2v5CrqhvrnIBitqzn9CZg/Bx0lMluHMgJ6fwCG5QCLzbZPy8Fl SDrupTI+RmMZ14RVHsGjzA4oCOA+4ZpbaRYbEkEnr6DUiK83BSOx8MKVrA7DD9YCA4zt IJW72yi0b9qtY1D9DtQJmkRgBQZkQlxlcxUhs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=kxfP3H+70FpUsuzHOfy1B6mupiVATl008O0sk0xIPoaAO5iJ14HDE/DPrPdnYNQgxh jXw+DUOf/e/MUCj57evVhEPuaRtYkYSOJIr1CCFhanunb/A00C3UCS9alRHkiwXbX95l nMOPeo/tXctP1prt0PaYnNoqD5hYrvO4t8q60= MIME-Version: 1.0 Received: by 10.216.55.201 with SMTP id k51mr791852wec.184.1251633932729; Sun, 30 Aug 2009 05:05:32 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> Date: Sun, 30 Aug 2009 08:05:32 -0400 Message-ID: <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> From: Kari Lippert To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 12:05:29 -0000 My two cents.... The first paragraph (where the purpose is being laid out) says: Conforming client applications use the protocol to manipulate and move the user's avatar, create objects in a virtual world, interact with other users and their surroundings and consume and create media and information from sources inside and outside their virtual world. I normally lurk in this group but I have to say this surprised me. This statement says that I will use this protocol within my virtual world, not that I will use this protocol to interface with different virtual worlds. This doesn't speak to what I thought the thrust was - interoperability of worlds for transportability of avatars. While once could argue that the use of the same protocol intra-world would help in the inter-world communication, this is not the case and should not be assumed to be so. I'm actually saddened that you're all thinking of interoperability as achievable only if everyone uses the same intra-world protocol. "Enforcing" the use of a standard intra-world for every world will be impossible and quite possibly viewed as some by an intrusion into their IP, not to mention that it would kill innovation. Transfer between worlds will be lossy: existing worlds are not the same, nor do they have the same types of virtual property associated with them. This standard is going to either have to address the bare minimum, or become obsolete prior to completion with the introduction of a novel virtual world into the virtual universe. I concur with many of the discussions that have been put forth regarding this draft and have the following suggestions: Infinity Linden - good rewording to include OGP history; too confusing to leave in the main body (a reader will think it a typo) Morgaine - agree to remove sentence that begins "To support the exegesis of the specifications..." meadhbh - deployment patterns are very different from models of protocols; deployment patterns may be useful but should not replace a good model Morgaine - agree with the addition of the Foundation Component but argue that it should also be the focus in the first paragraph of the description meadhbh/Morgaine/Carlo - redefinition of virtual world is a bad idea but what you are really talking about is the virtual universe as composed by a variety of virtual worlds - and I like the plain English of Region 1 in VW 1 to Region 2 in VW 2 expression put forth as it is very clear, easily understood, not easily misunderstood, and I believe captures the intent of the standard to be developed Once we figure out the focus (which I take to be inter-world, or cross-world, transfer) then we can begin capturing the requirements for a "successful transfer". From that the model, the deployment pattern(s), the conformance guidelines, and other associated parts of the standard will come. So I ask, what is the focus (purpose) of the working group? Why are you making all this effort? Is it to bring the multitudes of virtual worlds to one protocol or to make transfer between them possible? I posit those are two different standards and only the latter is worth standardization. My two cents anyway.... Kari From carlo@alinoe.com Sun Aug 30 05:23:06 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E16843A688C for ; Sun, 30 Aug 2009 05:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_20=-0.74, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTvxf6hkPS5S for ; Sun, 30 Aug 2009 05:23:06 -0700 (PDT) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id 6A5133A67D7 for ; Sun, 30 Aug 2009 05:23:05 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090830122311.ZFJS793.viefep11-int.chello.at@edge04.upc.biz>; Sun, 30 Aug 2009 14:23:11 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id acP91c05l0FlQed04cPAKW; Sun, 30 Aug 2009 14:23:11 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MhjSI-0007Bz-JZ; Sun, 30 Aug 2009 14:24:22 +0200 Date: Sun, 30 Aug 2009 14:24:22 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20090830122422.GE22756@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090830003055.GD22756@alinoe.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 12:23:07 -0000 On Sun, Aug 30, 2009 at 02:30:55AM +0200, Carlo Wood wrote: > On Fri, Aug 28, 2009 at 11:27:08AM -0700, Infinity Linden wrote: > Going with the definition that "virtual world" is from the perspective > of the user (every place reachable), I think that using "a virtual world" > is less confusing, and I'd rewrite the above paragraph as follows: After reading Morgaine's comments, I have to agree with her ... There is no consensus on the way you defined Virtual World. I'm very unhappy with it. The only argument you gave was that (in the future) a "world" would be perceived by users as all regions reachable and that it would be confusing to talk about multiple worlds for that reason. But that's not really a good argument; "World" and "Planet" are close enough for not seeing any reason not to allow multiple worlds to be reachable without confusing users, after all, you can also travel to different planets. For the working group and our effort however it is, I feel, ESSENTIAL that we come to an agreement on what 'Virtual World' means and everything seems to scream "Second Life" / "OSGrid" / kgrid / DragonsWorld and all-what-not: the currently existing, independent worlds that seek interop. That is what most people think of when you say "a virtual world". In the end we'll have simulators, or regions, partitioned land, for scalability reasons. Simulator: R Some regions will be adjacent, forming one "island", or just "land". Island/Land: RRRRR RRRR RRRRR RR These Regions might be run by different administration, but I'm sure there can be consensus about them being tightly bound in terms of regulations; for example, the same ToS, the same set of accepted Agent Domain Providers, and so on. In fact, so tight that it's not worth mentioning. This is what YOU think of when we talk about "multiple administrations" that form one World. Lets envision this by using an 'r' for a different administration: Island/(main)land/continent: RRRRR RRRR Rrrrr rr But no new word other then "distinct organizations" is needed. Then, of course, there can be more than one island. I have to agree with Morgaine here that it is NOT wise to use the word "World" here, simply because of the major confusion. The charter is full of sentences with the word World used in this way however; so you cannot delay it's definition. Note that there is no need to use more than two "distinct organizations" for a set of islands under one tight regulation, like a single island, like "Second Life" at the moment. Lets call THAT "(virtual) world": Virtual World (W): RRRRR RRRR rr Rrrrr rr RRRR rr R R RRR rrrr rrrrrr rrrrRRRR RRRRRR RRRRR Then finally, we have multiple Worlds, each of which should as much as possible allow to be separated in terms of administration and regulations as much as possible. This will not be anything as tightly coupled as (the administration) of a single island, or a World like "Second Life". Lets call a collection of collaborating Worlds (that have at least SOME interop and (thus) all use VWRAP) "Galaxy" for now: Galaxy: W X Y Z Again (from a previous post), I think that the coupling between these "galaxies" are the real challenge of this group, comprising a very important goal of our task. Special care and attention WILL be needed, as opposed to the coupling of two R's, or even on R and a an 'r': that already exists (ie, Second Life) and it will be easy to write down what protocol is used there, since we can assume any level of trust at *that* level. We need to aware at a very early point that this difference exists, and thanks to Morgaine, we are-- or at least, I am at this point. We NEED a new term, if only for internal use within this group. I propose "Galaxy" (to replace your definition of "Virtual World") and then use the term "Virtual World" for (sets of) Region Domains where we need to concentrate on demanding as little as possible in terms of trust or regulations in order for the protocol to deliver some form of interop. -- Carlo Wood From carlo@alinoe.com Sun Aug 30 05:29:58 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5069B3A69BF for ; Sun, 30 Aug 2009 05:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi2d7xGnebc2 for ; Sun, 30 Aug 2009 05:29:57 -0700 (PDT) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id E9AEF3A6C0E for ; Sun, 30 Aug 2009 05:29:56 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090830123003.EHQU21098.viefep19-int.chello.at@edge04.upc.biz>; Sun, 30 Aug 2009 14:30:03 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id acW21c03y0FlQed04cW3Qg; Sun, 30 Aug 2009 14:30:03 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MhjYx-0007Gs-IE; Sun, 30 Aug 2009 14:31:15 +0200 Date: Sun, 30 Aug 2009 14:31:15 +0200 From: Carlo Wood To: Kari Lippert Message-ID: <20090830123115.GF22756@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 12:29:58 -0000 /me notes that Kari also uses the term "Virtual World" in the same way as Morgaine, and me, and many others. (In fact, so far only Infinity has used it in a different way, that I know of) -- Carlo Wood From carlo@alinoe.com Sun Aug 30 05:34:11 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E00D28C0EB for ; Sun, 30 Aug 2009 05:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.34 X-Spam-Level: X-Spam-Status: No, score=-1.34 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqzxxSJg+3-z for ; Sun, 30 Aug 2009 05:34:10 -0700 (PDT) Received: from viefep20-int.chello.at (viefep20-int.chello.at [62.179.121.40]) by core3.amsl.com (Postfix) with ESMTP id D96653A694C for ; Sun, 30 Aug 2009 05:34:09 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep20-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090830123414.UGCE11480.viefep20-int.chello.at@edge02.upc.biz>; Sun, 30 Aug 2009 14:34:14 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upc.biz with edge id acaD1c0380FlQed02caEA8; Sun, 30 Aug 2009 14:34:14 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mhjd0-0007Jr-Fe; Sun, 30 Aug 2009 14:35:26 +0200 Date: Sun, 30 Aug 2009 14:35:26 +0200 From: Carlo Wood To: Kari Lippert Message-ID: <20090830123526.GG22756@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 12:34:11 -0000 On Sun, Aug 30, 2009 at 08:05:32AM -0400, Kari Lippert wrote: > Morgaine - agree to remove sentence that begins "To support the > exegesis of the specifications..." That was added to allow to avoid confusion that did arise here about the difference between policy and protocol. I think it will make the end-document a lot more clear if we are allowed to give examples that include how policy may be implemented using the protocol, even though the protocol itself will have no notion of policies at all. [...] > the standard will come. So I ask, what is the focus (purpose) of the > working group? Why are you making all this effort? Is it to bring the > multitudes of virtual worlds to one protocol or to make transfer > between them possible? I posit those are two different standards and > only the latter is worth standardization. +1 -- Carlo Wood From barryleiba.mailing.lists@gmail.com Sun Aug 30 05:55:04 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC9B28C0FD for ; Sun, 30 Aug 2009 05:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkoIA6ti+bBC for ; Sun, 30 Aug 2009 05:55:04 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id D951A28C10C for ; Sun, 30 Aug 2009 05:53:53 -0700 (PDT) Received: by ywh4 with SMTP id 4so6709021ywh.17 for ; Sun, 30 Aug 2009 05:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=Nn3MA8VC9+PDlb9O+3xsPeLP+Wjyk31FDYioX565jPk=; b=gg0Rc1vz9dbAH+gcxc+lfzAwiV4ErMSJtcVEfSkulXQtBRb0U6ijg4kljuzAuTc00v VhYpe4/GgKQyKR9vCcjkBrbph0pfoEglBKh6nU99LrKBJBtIBzVxHdhc+eD8JrGgOlFj y0DAPng9u9HTVY7Qzd+wdDG21N0LmPldReehQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=pUYv7y0Sy1JZuhOVfJh2vFHKUFEHRe0oEpBXD8LgJVj0f8LOTXLzimNVxON3hzzOLx IbWo8aJS21fwxT/LkwGTYDjX20z5/4o4ivGIyA3ryOdTTtDU4kpmxNFHQUWvf+W2+lSM Bos3JVMjyLrqd+56fz9K4rsG+m9rOWOPMX4O4= MIME-Version: 1.0 Received: by 10.150.237.9 with SMTP id k9mr6649034ybh.108.1251636838825; Sun, 30 Aug 2009 05:53:58 -0700 (PDT) In-Reply-To: <20090829232125.GC22756@alinoe.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <4646639E08F58B42836FAC24C94624DD6FE8098411@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0908281259h3a10cd02mc92eb8331c92f162@mail.gmail.com> <20090829232125.GC22756@alinoe.com> Date: Sun, 30 Aug 2009 08:53:58 -0400 Message-ID: <6c9fcc2a0908300553x57c76279p9a95c105f0e7e34a@mail.gmail.com> From: Barry Leiba To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 12:55:04 -0000 Sticking my oar in as co-chair of the BOF -- which gives me no extra influence, but affords some minor "moderator" status for the time being: Good: it sounds like VWRAP is, um... a wrap. As I read things, it should stand for Virtual World Region/Agent Protocols (note the final "s"), giving the name the flexibility to cover multiple related protocols (one of which could certainly be called "VWRAP" as well, and would, in that case, have no "s". I think that from an IETF point of view, having "virtual world" in the name is critical. I don't think it makes anyone think that it covers all aspects of virtual worlds, nor does it cut off anyone else who wants some other virtual world work started. It seems to me that we have reasonable consensus on the name... and that we're just about ready with the charter. Excitement reigns. Barry Leiba, OGPX BOF chair From kari.lippert@gmail.com Sun Aug 30 05:58:03 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9738B3A6C79 for ; Sun, 30 Aug 2009 05:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTsolk0Ug1VF for ; Sun, 30 Aug 2009 05:58:03 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id AB19C3A6A44 for ; Sun, 30 Aug 2009 05:58:02 -0700 (PDT) Received: by ewy3 with SMTP id 3so1591048ewy.42 for ; Sun, 30 Aug 2009 05:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EuY/lqcnfV3NcZhoy5oFdQVLxYH5ZZTQ4G+ukH3ycNI=; b=YlzqtNAF+BlDEN5N8TxTDrKQF8Z9DsfyXKfGYYpZupBkl985ZLHiJX0FRDNa/SzZeS budN0MUinaOzsZxnZ+Mu735K6O+gaWS8kbgb2sLj19/chZ+GBni4eT/Ur5ZE/85rarXb u5rCcvL7AdfLsEtfngmq8D2Xz59+DCtlJxf3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=O5pfgVfSctFhNRn8OxU2882WVNF7E/0XpUG/j6xjr1859C+TXHyKnGAAjadqBgXEfM PZA1Jdf2w2iaDezHcJmG+bFc1Lx12FbB7n6kIESbLfcRx8VEraPrEXnOSF1VdFN1QltZ ggNco4cYHhjxpSf1ZeDRTAAzTNwDEZGj46aug= MIME-Version: 1.0 Received: by 10.216.55.201 with SMTP id k51mr802523wec.184.1251637086088; Sun, 30 Aug 2009 05:58:06 -0700 (PDT) In-Reply-To: <20090830123526.GG22756@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <20090830123526.GG22756@alinoe.com> Date: Sun, 30 Aug 2009 08:58:05 -0400 Message-ID: <382d73da0908300558x41a09e84h165f50ef459c87fe@mail.gmail.com> From: Kari Lippert To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 12:58:03 -0000 > I think it will make the end-document a lot more clear if we are > allowed to give examples that include how policy may be implemented > using the protocol, even though the protocol itself will have no > notion of policies at all. Absolutely, I agree. However, I don't think this needs to be stated in the charter. (That makes 4 cents... I'm almost at my daily limit!) Kari From carlo@alinoe.com Sun Aug 30 05:59:30 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B08F28C0EB for ; Sun, 30 Aug 2009 05:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dz2l2CTiSWw3 for ; Sun, 30 Aug 2009 05:59:29 -0700 (PDT) Received: from viefep13-int.chello.at (viefep13-int.chello.at [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id E8D3928C0F5 for ; Sun, 30 Aug 2009 05:59:28 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep13-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090830125935.QMFL2474.viefep13-int.chello.at@edge04.upc.biz>; Sun, 30 Aug 2009 14:59:35 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id aczY1c0840FlQed04czZiS; Sun, 30 Aug 2009 14:59:35 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mhk1V-0007ee-UP; Sun, 30 Aug 2009 15:00:46 +0200 Date: Sun, 30 Aug 2009 15:00:45 +0200 From: Carlo Wood To: barryleiba@computer.org Message-ID: <20090830130045.GA29271@alinoe.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <4646639E08F58B42836FAC24C94624DD6FE8098411@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0908281259h3a10cd02mc92eb8331c92f162@mail.gmail.com> <20090829232125.GC22756@alinoe.com> <6c9fcc2a0908300553x57c76279p9a95c105f0e7e34a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6c9fcc2a0908300553x57c76279p9a95c105f0e7e34a@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 12:59:30 -0000 On Sun, Aug 30, 2009 at 08:53:58AM -0400, Barry Leiba wrote: > As I read things, it should stand for Virtual World Region/Agent > Protocols (note the final "s"), giving the name the flexibility to > cover multiple related protocols (one of which could certainly be > called "VWRAP" as well, and would, in that case, have no "s". Virtual Worlds Region/Agent Protocol(s) no opinion yet on the s behind Protocol, but there should be an 's' behind Worlds. This is already done correctly in the draft. -- Carlo Wood From kari.lippert@gmail.com Sun Aug 30 06:04:40 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA65228C0F5 for ; Sun, 30 Aug 2009 06:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtdEkv-ihUNA for ; Sun, 30 Aug 2009 06:04:40 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id DA38228C10B for ; Sun, 30 Aug 2009 06:04:39 -0700 (PDT) Received: by ewy3 with SMTP id 3so1593699ewy.42 for ; Sun, 30 Aug 2009 06:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=nZL6/shoG6tbNkfFDBb2aIXuDTLiOSDMDp/Dtm7YG7I=; b=SHWWjsCiYi43Jg1StytC/tgd3YMEaCTnPi6N+9V8BOBSXvgi0xzcTPz4g0TkZomNrl bq9fIvJuviCbNMkmTOdUkPsWo9/Cq5FFmuigjOIprL45B96eELzTosXddqTzM94ESLp6 tiTfxz75kUEODATVWVeOj8eBZ3N0of6xNv6ck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Z28+D0MIAi5M5ImMFzWH+5XtDFUkk5vqmFNHvYi/k3fGXGAhlXeccp6InHrPQl46fI oUbAuEh/0Fk0jC4Rq9r8FPMewkNViXPr3G4+q9K6DSd2IlZctnYqUoQq0HmOUeHO1m68 fmbEmexjg6s5HM3sjI/8foTiBTHnx0k5OcrMM= MIME-Version: 1.0 Received: by 10.216.6.213 with SMTP id 63mr781362wen.208.1251637484078; Sun, 30 Aug 2009 06:04:44 -0700 (PDT) In-Reply-To: <20090830130045.GA29271@alinoe.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <4646639E08F58B42836FAC24C94624DD6FE8098411@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0908281259h3a10cd02mc92eb8331c92f162@mail.gmail.com> <20090829232125.GC22756@alinoe.com> <6c9fcc2a0908300553x57c76279p9a95c105f0e7e34a@mail.gmail.com> <20090830130045.GA29271@alinoe.com> Date: Sun, 30 Aug 2009 09:04:44 -0400 Message-ID: <382d73da0908300604x17fa14f2pd5f8291cc61d3298@mail.gmail.com> From: Kari Lippert To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 13:04:40 -0000 > > Virtual Worlds Region/Agent Protocol(s) > +1 From morgaine.dinova@googlemail.com Sun Aug 30 07:12:02 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024763A6ADC for ; Sun, 30 Aug 2009 07:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALjH1bU2Kknj for ; Sun, 30 Aug 2009 07:12:00 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 1729B3A68C0 for ; Sun, 30 Aug 2009 07:11:59 -0700 (PDT) Received: by ewy3 with SMTP id 3so1619442ewy.42 for ; Sun, 30 Aug 2009 07:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ag7AhcG42V5XPpnc8hc8Zmd9K7GcFzuI5xzRD9KXuzc=; b=oUAX6kZqWwtWQXGIyLo8UVK65E8Xqq7FaC/yIS5tV9u2GdWdIbSKmScIvnJoNiD3nJ yU+fAeE2JGXQryJHyubC9ZoGr9kKpZLkMm/VtQRQYfochQpvxkpGgPRAP5GoUDgyogRu joz7oISxzMcatSNtDGyzPQZTleRW+GXIEtQGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=PctDHTgyhE/7SkZKmx3JFTU/sAcCBUC2U/NR4ieiWwnlyR1ktVpLw4tpYtxjAIu34K gZzh7rCEdXfWO6lexlghyGjvraXh/Ik8mSgIHWVBb59udaRukFHxg9MH2nr0VUWkZnx5 u0bDJBZsrwtnuDIZ/QICIef0VXXEqVyLENIjw= MIME-Version: 1.0 Received: by 10.211.143.20 with SMTP id v20mr3939169ebn.76.1251641522987; Sun, 30 Aug 2009 07:12:02 -0700 (PDT) In-Reply-To: <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> Date: Sun, 30 Aug 2009 15:12:02 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00504502d3725d21ae04725c80d4 Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 14:12:02 -0000 --00504502d3725d21ae04725c80d4 Content-Type: text/plain; charset=ISO-8859-1 Kari, that was an excellent review of a long series of subthreads. You have identified something that the rest of us seem to have missed: that OGP / VWRAP conflates the protocol(s) used to implement a single virtual world with the protocol(s) used to implement interop between multiple virtual worlds. No wonder we have a severe problem. That was a very insightful observation, kudos. The protocol used to implement a given virtual world is *an implementation detail* of that world. Is VWRAP intended to be an implementation protocol for a VW, or an *interop protocol* between them? Morgaine. ===================================== On Sun, Aug 30, 2009 at 1:05 PM, Kari Lippert wrote: > My two cents.... > > The first paragraph (where the purpose is being laid out) says: > > Conforming client applications use the protocol to manipulate and > move the user's avatar, create objects in a virtual world, interact > with other users and their surroundings and consume and create > media and information from sources inside and outside their virtual > world. > > I normally lurk in this group but I have to say this surprised me. > This statement says that I will use this protocol within my virtual > world, not that I will use this protocol to interface with different > virtual worlds. This doesn't speak to what I thought the thrust was - > interoperability of worlds for transportability of avatars. While once > could argue that the use of the same protocol intra-world would help > in the inter-world communication, this is not the case and should not > be assumed to be so. I'm actually saddened that you're all thinking of > interoperability as achievable only if everyone uses the same > intra-world protocol. > > "Enforcing" the use of a standard intra-world for every world will be > impossible and quite possibly viewed as some by an intrusion into > their IP, not to mention that it would kill innovation. Transfer > between worlds will be lossy: existing worlds are not the same, nor do > they have the same types of virtual property associated with them. > This standard is going to either have to address the bare minimum, or > become obsolete prior to completion with the introduction of a novel > virtual world into the virtual universe. > > I concur with many of the discussions that have been put forth > regarding this draft and have the following suggestions: > > Infinity Linden - good rewording to include OGP history; too confusing > to leave in the main body (a reader will think it a typo) > > Morgaine - agree to remove sentence that begins "To support the > exegesis of the specifications..." > > meadhbh - deployment patterns are very different from models of > protocols; deployment patterns may be useful but should not replace a > good model > > Morgaine - agree with the addition of the Foundation Component but > argue that it should also be the focus in the first paragraph of the > description > > meadhbh/Morgaine/Carlo - redefinition of virtual world is a bad idea > but what you are really talking about is the virtual universe as > composed by a variety of virtual worlds - and I like the plain English > of Region 1 in VW 1 to Region 2 in VW 2 expression put forth as it is > very clear, easily understood, not easily misunderstood, and I > believe captures the intent of the standard to be developed > > Once we figure out the focus (which I take to be inter-world, or > cross-world, transfer) then we can begin capturing the requirements > for a "successful transfer". From that the model, the deployment > pattern(s), the conformance guidelines, and other associated parts of > the standard will come. So I ask, what is the focus (purpose) of the > working group? Why are you making all this effort? Is it to bring the > multitudes of virtual worlds to one protocol or to make transfer > between them possible? I posit those are two different standards and > only the latter is worth standardization. > > > My two cents anyway.... > > Kari > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --00504502d3725d21ae04725c80d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kari, that was an excellent review of a long series of subthreads.

Y= ou have identified something that the rest of us seem to have missed:=A0 th= at OGP / VWRAP conflates the protocol(s) used to implement a single virtual= world with the protocol(s) used to implement interop between multiple virt= ual worlds.=A0 No wonder we have a severe problem.

That was a very insightful observation, kudos.

The protocol used= to implement a given virtual world is an implementation detail of t= hat world.

Is VWRAP intended to be an implementation protocol for a = VW, or an interop protocol between them?

Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

On Sun, Aug 30, 2009 at 1:05 PM, Kari= Lippert <ka= ri.lippert@gmail.com> wrote:
My two cents....<= br>

The first paragraph (where the purpose is being laid out) says:

Conforming =A0client =A0applications use =A0the protocol =A0to manipulate a= nd
move the =A0user's avatar, create =A0objects in =A0a virtual world, int= eract
=A0with other users =A0and their surroundings =A0and consume and create
media and information from sources inside and outside their virtual
world.

I normally lurk in this group but I have to say this surprised me. This statement says that I will use this protocol within my virtual
world, not that I will use this protocol to interface with different
virtual worlds. This doesn't speak to what I thought the thrust was - interoperability of worlds for transportability of avatars. While once
could argue that the use of the same protocol intra-world would help
in the inter-world communication, this is not the case and should not
be assumed to be so. I'm actually saddened that you're all thinking= of
interoperability as achievable only if everyone uses the same
intra-world protocol.

"Enforcing" the use of a standard intra-world for every world wil= l be
impossible and quite possibly viewed as some by an intrusion into
their IP, not to mention that it would kill innovation. Transfer
between worlds will be lossy: existing worlds are not the same, nor do
they have the same types of virtual property associated with them.
This standard is going to either have to address the bare minimum, or
become obsolete prior to completion with the introduction of a novel
virtual world into the virtual universe.

I concur with many of the discussions that have been put forth
regarding this draft and have the following suggestions:

Infinity Linden - good rewording to include OGP history; too confusing
to leave in the main body (a reader will think it a typo)

Morgaine - agree to remove sentence that begins "To support the
exegesis =A0of the specifications..."

meadhbh - deployment patterns are very different from models of
protocols; deployment patterns may be useful but should not replace a
good model

Morgaine - agree with the addition of the Foundation Component but
argue that it should also be the focus in the first paragraph of the
description

meadhbh/Morgaine/Carlo - redefinition of virtual world is a bad idea
but what you are really talking about is the virtual universe as
composed by a variety of virtual worlds - and I like the plain English
of Region 1 in VW 1 to Region 2 in VW 2 expression put forth as it is
very clear, easily understood, not easily misunderstood, =A0and I
believe captures the intent of the standard to be developed

Once we figure out the focus (which I take to be inter-world, or
cross-world, transfer) then we can begin capturing the requirements
for a "successful transfer". From that the model, the deployment<= br> pattern(s), the conformance guidelines, and other associated parts of
the standard will come. So I ask, what is the focus (purpose) of the
working group? Why are you making all this effort? Is it to bring the
multitudes of virtual worlds to one protocol or to make transfer
between them possible? I posit those are two different standards and
only the latter is worth standardization.

<step off soapbox>
My two cents anyway....

Kari
__________________________________= _____________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--00504502d3725d21ae04725c80d4-- From dhc@dcrocker.net Sun Aug 30 07:41:11 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B823A6852 for ; Sun, 30 Aug 2009 07:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adM6ItvTN-To for ; Sun, 30 Aug 2009 07:41:10 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7148]) by core3.amsl.com (Postfix) with ESMTP id 9F4823A67AD for ; Sun, 30 Aug 2009 07:41:09 -0700 (PDT) Received: from [127.0.0.1] (ppp-68-120-198-98.dsl.pltn13.pacbell.net [68.120.198.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n7UEf8xp020657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Aug 2009 07:41:13 -0700 Message-ID: <4A9A8F7D.6070501@dcrocker.net> Date: Sun, 30 Aug 2009 07:41:01 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Carlo Wood References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> In-Reply-To: <20090830003055.GD22756@alinoe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 30 Aug 2009 07:41:13 -0700 (PDT) Cc: Infinity Linden , ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 14:41:11 -0000 Carlo Wood wrote: > I think that using "a virtual world" > is less confusing, and I'd rewrite the above paragraph as follows: > > Adjacent locations in a virtual world accessible by this protocol may > be explicitly partitioned into "regions" to facilitate the > computational and communication load balancing required to simulate > the virtual environment. Such a virtual world may consist of regions > administered by distinct organizations. Though virtual worlds > may be partitioned, they remain "un-sharded;" all inhabitants and > objects in a particular location in a virtual world may initiate > interaction with all other inhabitants and objects in that location; > and service endpoint addresses refer to at most one location. The > state of a virtual world is independent of the client applications > that access it and may persist between user sessions. This reads well, with two exceptions: Minor: Though virtual worlds may be partitioned -> Though a virtual world may be partitioned Substantial: The meaning and import of "un-sharded" is missing. From the last time I asked about this, I gather the term is familiar in VW circles, but it sure isn't in the IETF or, I believe, anywhere outside /some/ database and /some/ or all VW environs. Note that the language, here, is saying that it is /not/ sharded. Jumping into a negative reference like this suggests that sharding is to be expected. Is it? Why? Is reference to sharding essential for the charter? Why? So, this reduces down to two different issues. One is a concept and the other is a vocabulary term. If the concept is essential, what's some terse text that makes sense for the charter? If the term is essential, marry it to that terse text. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Sun Aug 30 08:40:17 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF2628C142 for ; Sun, 30 Aug 2009 08:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.679 X-Spam-Level: X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nGUJ07tU-ES for ; Sun, 30 Aug 2009 08:40:16 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7148]) by core3.amsl.com (Postfix) with ESMTP id 6A18D28C13B for ; Sun, 30 Aug 2009 08:40:15 -0700 (PDT) Received: from [127.0.0.1] (ppp-68-120-198-98.dsl.pltn13.pacbell.net [68.120.198.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n7UFeHnr023774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 30 Aug 2009 08:40:22 -0700 Message-ID: <4A9A9D5A.9020400@dcrocker.net> Date: Sun, 30 Aug 2009 08:40:10 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ogpx@ietf.org References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> In-Reply-To: <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 30 Aug 2009 08:40:23 -0700 (PDT) Subject: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 15:40:17 -0000 Folks, Pre-game. Confusion and disagreement that includes the term "virtual world" is proving tenacious, in spite of extensive and substantive discussion. Typically, something this persistent means either that some concept(s) lack shared definition or that competing technical paradigms are present. As was noted many message ago, there's a good chance that much of the disagreement is really about the meaning of the term. That is, that apparent disagreements about such things as scope of work is really about scope of this one term. That, at least, is my own reading of the discussions. I think people are using the term differently. If we can get to the point of using it the same way, my sense is that we will find that disagreements about actual work to be done, and its use, are rather small. In other words, I think the persistence of debate that keeps using that term "virtual world" means we have to resolve it before we can make serious progress. These sorts of things never seem to go away without explicit resolution. While much of the earlier attempts to resolve this look like they helped quite a bit, it seems clear that a bit more effort is needed. The wind-up. Since the crux of the challenge keeps coming back to what interoperability will or will not be provided -- with at least one additional point about whether the current work must be used internal to a service or only used /between/ services -- permit me a moment of theft from Internet history and constructs. I think it can be applicable here: Network vs. Internetwork. "A" virtual world vs. Multiple virtual worlds. But hold on. I'm not necessarily going to suggest mapping the two sets as one-to-one directly... Originally, a network was a discrete technical set. X.25. NCP. XNS. Netware. Whatever. Both technology and administration had the same boundary. Your network might use one technology and mine might use another. But even if they used the same technology, one was mine and the other was yours. So I tend to view interaction across administrative boundaries as far more interesting to internetworking than whether different technologies are used: The term Internet has come to mean a single, unified, global service. It crosses administrative boundaries. Does IBM internally operate a 'network' or an 'internetwork'? Either choice is reasonable, depending on what is the focus. I think we don't need to resolve the equivalent question here. There is universal agreement that there is a single global service, comprising many independent smaller services, and that that single, larger thing is "The" Internet. What we tend to forget is that there probably are other Internets that don't (directly) interoperate with the global one. They are off "The Internet" grid and are on their own. They are likely also "an" Internet. These days, they might be running TCP/IP, but they don't have to. For example: Some uses of "virtual world" appear to mean an administrative boundary and others appear to mean a technical boundary. This is the sort of thing we need to resolve. The pitch. I suggest ignoring technical differences within an administrative domain and even across different administrative domains. Simply, VWrap is used to connect together administrative domains running simulations. I'm running one simulation and you are running another. We use VWrap to interoperate. Are we connecting two virtual worlds or is the result a single virtual world? Some other folk might not interoperate with our unified service. They are running their own thing. Are they running a different virtual world or, perhaps, a different set of multiple virtual worlds? The swing. I suggest that: Any set of independent administrative domains that interoperate together, using VWrap, creates a /single/ virtual world. Each independent administrative domain is running /part/ of that single virtual world. (The part might be one Region, or Agent, or it might be many of both or any combination.) Hence, I am suggesting that an integrated VWrap environment has a comparable quality to an integrated internet environment that we call "The" Internet. One service. If you are running a simulation that is not part of an integrated, interoperable VWrap environment, you are in a different virtual world. If you are part of an interoperable VWrap service, you are in a single virtual world. It doesn't matter what you run internally. What matters is integration to the interoperable service using VWrap. Base hit or strikeout? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From meadhbh.siobhan@gmail.com Sun Aug 30 09:37:44 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B30D43A6A8A for ; Sun, 30 Aug 2009 09:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKSf3PsmTHGv for ; Sun, 30 Aug 2009 09:37:43 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id 8D8423A6A1D for ; Sun, 30 Aug 2009 09:37:43 -0700 (PDT) Received: by iwn38 with SMTP id 38so1522269iwn.29 for ; Sun, 30 Aug 2009 09:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LqA8X/XB4etFbXijzNbfQM/zTixcf5WbTYIqVfZOJxM=; b=OmhG/nZA+PvmZuOOLYAzYSZfASeyUuFCbe4LLZptXLGq/tslBItpEQGY+mw4LJe+ij o3l1L7/Wz61FeWyMznI2POk4+7cpM67I5GiLYTfO92ER1mmbprt0xfmpn7Dx5jyM28W1 bRNIgYJGegS4n4j9M0kOOUvFb8N0EbLrpIBxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DaoV7CthM6sbqBqOqgQ2GhzEUozQ/gxeDtv32pQCe0jBBIKKuikZq38Ecofc9IVJXV uJpi2NNLlEMGkCsyzLE+eP8RcXhZ5seRud1mewn088Na/hhZi2Aa9L0KD5wsCO5pghKz T/yWy2mhMbDCAXEUCFdw8szOsB02kwem1enZM= MIME-Version: 1.0 Received: by 10.231.124.22 with SMTP id s22mr5148380ibr.33.1251650182433; Sun, 30 Aug 2009 09:36:22 -0700 (PDT) In-Reply-To: <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> Date: Sun, 30 Aug 2009 09:36:22 -0700 Message-ID: From: Meadhbh Siobhan To: Kari Lippert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 16:37:44 -0000 hey kari. thanks' for chiming in. On Sun, Aug 30, 2009 at 5:05 AM, Kari Lippert wrote= : > My two cents.... > > The first paragraph (where the purpose is being laid out) says: > > Conforming =A0client =A0applications use =A0the protocol =A0to manipulate= and > move the =A0user's avatar, create =A0objects in =A0a virtual world, inter= act > =A0with other users =A0and their surroundings =A0and consume and create > media and information from sources inside and outside their virtual > world. > > I normally lurk in this group but I have to say this surprised me. > This statement says that I will use this protocol within my virtual > world, not that I will use this protocol to interface with different > virtual worlds. This doesn't speak to what I thought the thrust was - > interoperability of worlds for transportability of avatars. While once > could argue that the use of the same protocol intra-world would help > in the inter-world communication, this is not the case and should not > be assumed to be so. I'm actually saddened that you're all thinking of > interoperability as achievable only if everyone uses the same > intra-world protocol. we do not define the term "virtual world." there is considerable disagreement as to what the term means. in the previous effort (MMOX) we attempted to start talking about the term and discovered there was considerable disagreement as to what it meant. part of the reason the OGPX BoF was formed was to illuminate a smaller section of the problem domain. in the part of the problem domain we are choosing to work on, we do not discuss interoperability between "virtual worlds" as this term is not used normatively. instead, we define the terms "region domain" and "simulator" and "agent domain" and a few others and define interoperability expectations and protocol between _them_. morgaine uses the term "virtual world" to mean what we call a "region domain." so if this is your definition, then we are talking about an inter-virtual world protocol. we are shying away from using it in this effort because it's use was so contentious in previous standardization efforts (VWIF, AWG, MMOX.) interoperability of avatar formats is one aspect of this protocol, but not the only one. it should also be noted that we are not attempting to say that our model is the _ONLY_ valid models for virtual worlds. this is one of the reasons that OGPX is a distinct effort from MMOX. MMOX retains the wider focus, and as i understand it, there's no reason someone else can't continue it's work, or define a separate part of the problem domain and form another working group. > > "Enforcing" the use of a standard intra-world for every world will be > impossible and quite possibly viewed as some by an intrusion into > their IP, not to mention that it would kill innovation. Transfer > between worlds will be lossy: existing worlds are not the same, nor do > they have the same types of virtual property associated with them. > This standard is going to either have to address the bare minimum, or > become obsolete prior to completion with the introduction of a novel > virtual world into the virtual universe. unlike MMOX, we are not attempting, in this group, to define a generic protocol to be used by every virtual world. OGPX is intended to provide interoperability, not between worlds, but between hosts that work together to simulate a virtual world. nor are we trying to mandate a virtual world protocol that everyone MUST implement. in the same way that POP3 did nothing to supplant the use of Microsoft's proprietary Exchange protocol, or from the effort to define IMAP, we think that the OGPX/VWRAP effort will cover one part of the problem domain. > > I concur with many of the discussions that have been put forth > regarding this draft and have the following suggestions: > > Infinity Linden - good rewording to include OGP history; too confusing > to leave in the main body (a reader will think it a typo) > > Morgaine - agree to remove sentence that begins "To support the > exegesis =A0of the specifications..." > > meadhbh - deployment patterns are very different from models of > protocols; deployment patterns may be useful but should not replace a > good model are we talking about a processing model? we really want to define a processing model for conforming implementations? > > Morgaine - agree with the addition of the Foundation Component but > argue that it should also be the focus in the first paragraph of the > description > > meadhbh/Morgaine/Carlo - redefinition of virtual world is a bad idea > but what you are really talking about is the virtual universe as > composed by a variety of virtual worlds - and I like the plain English > of Region 1 in VW 1 to Region 2 in VW 2 expression put forth as it is > very clear, easily understood, not easily misunderstood, =A0and I > believe captures the intent of the standard to be developed again. this is one of the reasons we're trying to focus on terms we have agreement on. > > Once we figure out the focus (which I take to be inter-world, or > cross-world, transfer) then we can begin capturing the requirements > for a "successful transfer". From that the model, the deployment > pattern(s), the conformance guidelines, and other associated parts of > the standard will come. So I ask, what is the focus (purpose) of the > working group? Why are you making all this effort? Is it to bring the > multitudes of virtual worlds to one protocol or to make transfer > between them possible? I posit those are two different standards and > only the latter is worth standardization. we've actually been working on a focus for the past six months. first we were broad with MMOX, but couldn't get agreement. then with OGPX we stated a focus on what's come to be called "second life-like" worlds. the focus of the group is to define an interoperability profile and protocol, deployment patterns and processing expectations for these worlds. > > > My two cents anyway.... > > Kari > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From meadhbh.siobhan@gmail.com Sun Aug 30 09:53:49 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B81228C167 for ; Sun, 30 Aug 2009 09:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbYP5SFpRqlP for ; Sun, 30 Aug 2009 09:53:48 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id E9D2528C12D for ; Sun, 30 Aug 2009 09:53:47 -0700 (PDT) Received: by iwn38 with SMTP id 38so1526302iwn.29 for ; Sun, 30 Aug 2009 09:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6NIEyPvU1Uox5vGSIegrQG4ebLDWNA0wgGZLE0tOaMQ=; b=uuxl/gb3ShlW/WOkER4lOXehvtZgNIngI+SZySumwZ1ANrUBOOvUYxQUf3H34a5cK+ VRHC9qKpXrnSku2ME3dfIlSBjbPpKwgL/cPWX9dVppeN1V4pcTEF54GdRBGrspyl1bdx Tsa4EsUT9AKFx3+H4/72MWl0xFYHijBdy1TWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=A0qYjtQ8EfzjD1GrL/CYTxtU2luXBYziDHp7fRx8b7AcezoMGemk9+eeiKnsVmnV7R FLCeer8Poj9rviQpwzbOqq7PRfoX4h7c0LYJFLHlosw3m1t8XeAc4eiYMKiZ6Do4yqZh ZX08UcOnBrD+u8uhZ27SxYykB4M5Vg+LOLZxo= MIME-Version: 1.0 Received: by 10.231.25.29 with SMTP id x29mr5186929ibb.31.1251651231928; Sun, 30 Aug 2009 09:53:51 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> Date: Sun, 30 Aug 2009 09:53:51 -0700 Message-ID: From: Meadhbh Siobhan To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 16:53:49 -0000 morgaine, i don't think this is a consensus view of the protocol implemente= rs. MMOX was the effort to define inter-world interoperability. that effort could not reach consensus in a reasonable time frame. this effort was organized to constrain the problem domain to define interoperability between systems that implement a virtual world, not to define a protocol for inter-world interoperability. the practical consequence of this constrained scope include: a. we're not working on a protocol for interoperability between worlds with radically different operating assumptions. (i.e. - this is not a protocol intended to provide interoperability between WoW, EVE Online and Second Life.) b. we're not working on a protocol that requires all systems that implement it to be part of the same "virtual world" (defined from the perspective of user.) that is, deployers of systems that implement the protocol may, but are not required to interoperate with other deployers. the OGPX effort does not preclude this work, but avoids it because it does not want to repeat the failures of MMOX. -cheers -meadhbh On Sun, Aug 30, 2009 at 7:12 AM, Morgaine w= rote: > Kari, that was an excellent review of a long series of subthreads. > > You have identified something that the rest of us seem to have missed:=A0= that > OGP / VWRAP conflates the protocol(s) used to implement a single virtual > world with the protocol(s) used to implement interop between multiple > virtual worlds.=A0 No wonder we have a severe problem. > > That was a very insightful observation, kudos. > > The protocol used to implement a given virtual world is an implementation > detail of that world. > > Is VWRAP intended to be an implementation protocol for a VW, or an intero= p > protocol between them? > > Morgaine. > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Sun, Aug 30, 2009 at 1:05 PM, Kari Lippert > wrote: >> >> My two cents.... >> >> The first paragraph (where the purpose is being laid out) says: >> >> Conforming =A0client =A0applications use =A0the protocol =A0to manipulat= e and >> move the =A0user's avatar, create =A0objects in =A0a virtual world, inte= ract >> =A0with other users =A0and their surroundings =A0and consume and create >> media and information from sources inside and outside their virtual >> world. >> >> I normally lurk in this group but I have to say this surprised me. >> This statement says that I will use this protocol within my virtual >> world, not that I will use this protocol to interface with different >> virtual worlds. This doesn't speak to what I thought the thrust was - >> interoperability of worlds for transportability of avatars. While once >> could argue that the use of the same protocol intra-world would help >> in the inter-world communication, this is not the case and should not >> be assumed to be so. I'm actually saddened that you're all thinking of >> interoperability as achievable only if everyone uses the same >> intra-world protocol. >> >> "Enforcing" the use of a standard intra-world for every world will be >> impossible and quite possibly viewed as some by an intrusion into >> their IP, not to mention that it would kill innovation. Transfer >> between worlds will be lossy: existing worlds are not the same, nor do >> they have the same types of virtual property associated with them. >> This standard is going to either have to address the bare minimum, or >> become obsolete prior to completion with the introduction of a novel >> virtual world into the virtual universe. >> >> I concur with many of the discussions that have been put forth >> regarding this draft and have the following suggestions: >> >> Infinity Linden - good rewording to include OGP history; too confusing >> to leave in the main body (a reader will think it a typo) >> >> Morgaine - agree to remove sentence that begins "To support the >> exegesis =A0of the specifications..." >> >> meadhbh - deployment patterns are very different from models of >> protocols; deployment patterns may be useful but should not replace a >> good model >> >> Morgaine - agree with the addition of the Foundation Component but >> argue that it should also be the focus in the first paragraph of the >> description >> >> meadhbh/Morgaine/Carlo - redefinition of virtual world is a bad idea >> but what you are really talking about is the virtual universe as >> composed by a variety of virtual worlds - and I like the plain English >> of Region 1 in VW 1 to Region 2 in VW 2 expression put forth as it is >> very clear, easily understood, not easily misunderstood, =A0and I >> believe captures the intent of the standard to be developed >> >> Once we figure out the focus (which I take to be inter-world, or >> cross-world, transfer) then we can begin capturing the requirements >> for a "successful transfer". From that the model, the deployment >> pattern(s), the conformance guidelines, and other associated parts of >> the standard will come. So I ask, what is the focus (purpose) of the >> working group? Why are you making all this effort? Is it to bring the >> multitudes of virtual worlds to one protocol or to make transfer >> between them possible? I posit those are two different standards and >> only the latter is worth standardization. >> >> >> My two cents anyway.... >> >> Kari >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From meadhbh.siobhan@gmail.com Sun Aug 30 10:13:23 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2655D3A6808 for ; Sun, 30 Aug 2009 10:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfeSaf0c5tfN for ; Sun, 30 Aug 2009 10:13:22 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id 36DAA3A6AF4 for ; Sun, 30 Aug 2009 10:13:22 -0700 (PDT) Received: by iwn38 with SMTP id 38so1530798iwn.29 for ; Sun, 30 Aug 2009 10:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=n2GxpoaDLuCvkc4qSP7WqvVVdBNKXL2gWb5mQXyHlao=; b=JDDfXTqS1ysu9rkuzlNQe1cIWxAOdB1knHETJ3Z6BfjuH8YJ2lpnClPAMVfp2z22Ix fp+3A8O+t9NGNU7mh988U1kpZNIbWbRw8uLLY+RoBtEMAxaTk7Ii+Zm6CIx5AtfjrxFV poa+dEfU2K66AqcvIJR2uLC2Oxd6Xj+uoXSgc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nEnkjnDwqe9uip23uB0VIBtoqgRhfJlj8Pytf5t72/c5Z7LazMzKgNOi7yKfcT4+c0 24fTIUJppMcCLkSytXO7xlDMqbUypw0w6aLa/wCIvukek+GCmPMkjqxtvSiGMvFh2JX0 7y/o3DMXRsjGGEfn3SF6hnddJcpgDjmkAkpOk= MIME-Version: 1.0 Received: by 10.231.82.132 with SMTP id b4mr5284494ibl.8.1251652406246; Sun, 30 Aug 2009 10:13:26 -0700 (PDT) In-Reply-To: <4A9A8F7D.6070501@dcrocker.net> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <4A9A8F7D.6070501@dcrocker.net> Date: Sun, 30 Aug 2009 10:13:26 -0700 Message-ID: From: Meadhbh Siobhan To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Infinity Linden , ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 17:13:23 -0000 On Sun, Aug 30, 2009 at 7:41 AM, Dave CROCKER wrote: > > > Carlo Wood wrote: >> >> =A0 I think that using "a virtual world" >> is less confusing, and I'd rewrite the above paragraph as follows: >> >> Adjacent locations in a virtual world accessible by =A0this protocol may >> be =A0 explicitly =A0 partitioned =A0into =A0 "regions" =A0 to =A0facili= tate =A0 the >> computational =A0and communication load =A0balancing required =A0to simu= late >> the virtual =A0environment. Such a virtual world may consist =A0of regio= ns >> administered =A0by distinct organizations. =A0 =A0 =A0 =A0 Though virtua= l worlds >> may =A0be partitioned, =A0they =A0remain "un-sharded;" =A0all inhabitant= s =A0and >> objects =A0in a =A0particular location =A0in =A0a virtual =A0world may = =A0initiate >> interaction with =A0all other inhabitants and objects =A0in that locatio= n; >> and service =A0endpoint addresses =A0refer to at =A0most one =A0location= . =A0The >> state of =A0a virtual =A0world is independent =A0of the =A0client applic= ations >> that access it and may persist between user sessions. > > This reads well, with two exceptions: > > > Minor: > =A0 =A0 Though virtual worlds may be partitioned > =A0 =A0 -> > =A0 =A0 Though a virtual world may =A0be partitioned > > hmm... i thought we had changed that to "Though these virtual worlds may be partitioned" > Substantial: > > =A0 =A0 The meaning and import of "un-sharded" is missing. =A0From the la= st time I > asked about this, I gather the term is familiar in VW circles, but it sur= e > isn't > in the IETF or, I believe, anywhere outside /some/ database and /some/ or > all VW > environs. > the text reads: "Though these virtual worlds may be partitioned, they remain "un-sharded;" all inhabitants and objects in a particular location in a virtual world may initiate interaction with all other inhabitants and objects in that location; and, service endpoint addresses refer to at most one location." the clause after "they remain un-sharded" is the definition we use for sharded worlds. we could change this to: "Though { these virtual worlds | a virtual world } may be partitioned, they remain "un-sharded;" that is, all inhabitants and objects in a particular location in a virtual world may initiate interaction with all other inhabitants and objects in that location; and, service endpoint addresses refer to at most one location." > =A0 =A0 Note that the language, here, is saying that it is /not/ sharded. > Jumping into a negative reference like this suggests that sharding is to = be > expected. =A0Is it? =A0Why? =A0Is reference to sharding essential for the= charter? > =A0Why? we introduce the relationship between VWRAP region partitioning to sharding, because sharding is well understood with a wider audience than region partitioning. the intent is to further define region partitioning. > > =A0 =A0 So, this reduces down to two different issues. =A0One is a concep= t and the > other is a vocabulary term. =A0If the concept is essential, what's some t= erse > text that makes sense for the charter? =A0If the term is essential, marry= it > to that terse text. > > d/ > > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From dhc@dcrocker.net Sun Aug 30 10:37:42 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722213A6808 for ; Sun, 30 Aug 2009 10:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRuVFc6+Q7SK for ; Sun, 30 Aug 2009 10:37:41 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7148]) by core3.amsl.com (Postfix) with ESMTP id 250363A6AC8 for ; Sun, 30 Aug 2009 10:37:40 -0700 (PDT) Received: from [127.0.0.1] (ppp-68-120-198-98.dsl.pltn13.pacbell.net [68.120.198.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n7UHbUKg029849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Aug 2009 10:37:36 -0700 Message-ID: <4A9AB8D3.90207@dcrocker.net> Date: Sun, 30 Aug 2009 10:37:23 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Meadhbh Siobhan References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <4A9A8F7D.6070501@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 30 Aug 2009 10:37:36 -0700 (PDT) Cc: Infinity Linden , ogpx@ietf.org, dcrocker@bbiw.net Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 17:37:42 -0000 Meadhbh Siobhan wrote: >> Minor: >> Though virtual worlds may be partitioned >> -> >> Though a virtual world may be partitioned >> >> > > hmm... i thought we had changed that to "Though these virtual worlds > may be partitioned" I'll admit to the preference expressed in my later note, which is that vwrap talk about exactly one virtual world. That is, the set of interoperable regions that use vwrap to do the interoperating defines a single virtual world. If the group preference is to say something like a virtual world is defined as a cohesively administered domain - of one or more regions -- and that the interoperation of these is multiple virtual worlds, then something like the existing use of plurals is probably better. > the clause after "they remain un-sharded" is the definition we use for > sharded worlds. we could change this to: > > "Though { these virtual worlds | a virtual world } may be > partitioned, they remain "un-sharded;" that is, all inhabitants > and objects in a particular location in a virtual world may > initiate interaction with all other inhabitants and objects in that > location; and, service endpoint addresses refer to at most one > location." Ok. And your point that the term shard is common amongst vw folk also explains the desire to have it in the charter. And I think I understand why the negative reference to it makes sense here. Hmmm. I think what this really means is that the explanatory "that is" sentence is really the focus. So I suggest making it be that: All inhabitants and objects in a particular location in a virtual world can initiate interaction with all other inhabitants and objects in that location. That is, the virtual world can be partitioned, but it remains unsharded. Also, service endpoing addresses refer to at most one location. Further hmmmm... "in that location" doesn't say that the interaction can cross administrative domains or regions. So is the non-sharding within a single administrative environment, or is it across boundaries that use vwrap? (By the way, I'm still not understanding the relationship between a "location" and a "region". The text essentially defines a region, but not location.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From morgaine.dinova@googlemail.com Sun Aug 30 11:05:09 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125D228C1C5 for ; Sun, 30 Aug 2009 11:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHnUWyuzBh7R for ; Sun, 30 Aug 2009 11:05:07 -0700 (PDT) Received: from mail-ew0-f225.google.com (mail-ew0-f225.google.com [209.85.219.225]) by core3.amsl.com (Postfix) with ESMTP id D4CF628C1C0 for ; Sun, 30 Aug 2009 11:05:06 -0700 (PDT) Received: by ewy25 with SMTP id 25so3516565ewy.9 for ; Sun, 30 Aug 2009 11:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=y425659kBk1DcFu2cykLqaRJyW9yAwf+iVPrZhQDTbw=; b=Oc7JuwSG6PjAPUE+rl5qvM1AmrHz+dUZOLTKh632nEXQldReL0YBufxca81ef+h9jr NpM9OH8x1jLYCKuf+rI5jpIbIrMeDGx4NuG9YN8+oWu8SgVjw3wCMLyxdDYCAHFJbrmb i9KYdhJ2gFgPzWZlcgfoqwgHCbCYhiTxt/sM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vgB3ouWn9K6Yvare3Svzjz395TTTPziL5L8qwdBXOW80V+qGPsdRw//OZbcS0bB43q sMGKxA+FW4LqXMt/yVPvHi6jJFAgnLuOGmQS0BmKiIwcELT2fjQLW2GNsXaA2fxAQ0XG vTwcxAgtmg3qgwM3adOfR/PuCYvrnTgILs9UI= MIME-Version: 1.0 Received: by 10.211.147.5 with SMTP id z5mr4161541ebn.87.1251655509754; Sun, 30 Aug 2009 11:05:09 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> Date: Sun, 30 Aug 2009 19:05:09 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636c5b94a0a45a404725fc2c3 Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 18:05:09 -0000 --001636c5b94a0a45a404725fc2c3 Content-Type: text/plain; charset=ISO-8859-1 Meadhbh has misrepresented the points that are being made. On Sun, Aug 30, 2009 at 5:53 PM, Meadhbh Siobhan wrote: > > a. we're not working on a protocol for interoperability between worlds > *with radically different operating assumptions*. (i.e. - this is not a > protocol intended to provide interoperability between *WoW, EVE Online* > and Second Life.) > Nobody has ever referred to anything that might fall under the scope of MMOX here. This discussion has been entirely about interoperation between worlds that implement OGP/VWRAP, and to put it even more strongly, SL-compatible worlds, such as Opensim-based worlds and SL itself. Continually adding an irrelevant detail like "radically different assumptions" and naming "WoW, EVE Online" only to reject them is a plain straw man. It does not help advance the discussion. Morgaine. ==================================== On Sun, Aug 30, 2009 at 5:53 PM, Meadhbh Siobhan wrote: > morgaine, i don't think this is a consensus view of the protocol > implementers. > > MMOX was the effort to define inter-world interoperability. that > effort could not reach consensus in a reasonable time frame. this > effort was organized to constrain the problem domain to define > interoperability between systems that implement a virtual world, not > to define a protocol for inter-world interoperability. > > the practical consequence of this constrained scope include: > > a. we're not working on a protocol for interoperability between worlds > with radically different operating assumptions. (i.e. - this is not a > protocol intended to provide interoperability between WoW, EVE Online > and Second Life.) > > b. we're not working on a protocol that requires all systems that > implement it to be part of the same "virtual world" (defined from the > perspective of user.) that is, deployers of systems that implement the > protocol may, but are not required to interoperate with other > deployers. > > the OGPX effort does not preclude this work, but avoids it because it > does not want to repeat the failures of MMOX. > > -cheers > -meadhbh > > On Sun, Aug 30, 2009 at 7:12 AM, Morgaine > wrote: > > Kari, that was an excellent review of a long series of subthreads. > > > > You have identified something that the rest of us seem to have missed: > that > > OGP / VWRAP conflates the protocol(s) used to implement a single virtual > > world with the protocol(s) used to implement interop between multiple > > virtual worlds. No wonder we have a severe problem. > > > > That was a very insightful observation, kudos. > > > > The protocol used to implement a given virtual world is an implementation > > detail of that world. > > > > Is VWRAP intended to be an implementation protocol for a VW, or an > interop > > protocol between them? > > > > Morgaine. > > > > > > > > > > > > > > ===================================== > > > > On Sun, Aug 30, 2009 at 1:05 PM, Kari Lippert > > wrote: > >> > >> My two cents.... > >> > >> The first paragraph (where the purpose is being laid out) says: > >> > >> Conforming client applications use the protocol to manipulate and > >> move the user's avatar, create objects in a virtual world, interact > >> with other users and their surroundings and consume and create > >> media and information from sources inside and outside their virtual > >> world. > >> > >> I normally lurk in this group but I have to say this surprised me. > >> This statement says that I will use this protocol within my virtual > >> world, not that I will use this protocol to interface with different > >> virtual worlds. This doesn't speak to what I thought the thrust was - > >> interoperability of worlds for transportability of avatars. While once > >> could argue that the use of the same protocol intra-world would help > >> in the inter-world communication, this is not the case and should not > >> be assumed to be so. I'm actually saddened that you're all thinking of > >> interoperability as achievable only if everyone uses the same > >> intra-world protocol. > >> > >> "Enforcing" the use of a standard intra-world for every world will be > >> impossible and quite possibly viewed as some by an intrusion into > >> their IP, not to mention that it would kill innovation. Transfer > >> between worlds will be lossy: existing worlds are not the same, nor do > >> they have the same types of virtual property associated with them. > >> This standard is going to either have to address the bare minimum, or > >> become obsolete prior to completion with the introduction of a novel > >> virtual world into the virtual universe. > >> > >> I concur with many of the discussions that have been put forth > >> regarding this draft and have the following suggestions: > >> > >> Infinity Linden - good rewording to include OGP history; too confusing > >> to leave in the main body (a reader will think it a typo) > >> > >> Morgaine - agree to remove sentence that begins "To support the > >> exegesis of the specifications..." > >> > >> meadhbh - deployment patterns are very different from models of > >> protocols; deployment patterns may be useful but should not replace a > >> good model > >> > >> Morgaine - agree with the addition of the Foundation Component but > >> argue that it should also be the focus in the first paragraph of the > >> description > >> > >> meadhbh/Morgaine/Carlo - redefinition of virtual world is a bad idea > >> but what you are really talking about is the virtual universe as > >> composed by a variety of virtual worlds - and I like the plain English > >> of Region 1 in VW 1 to Region 2 in VW 2 expression put forth as it is > >> very clear, easily understood, not easily misunderstood, and I > >> believe captures the intent of the standard to be developed > >> > >> Once we figure out the focus (which I take to be inter-world, or > >> cross-world, transfer) then we can begin capturing the requirements > >> for a "successful transfer". From that the model, the deployment > >> pattern(s), the conformance guidelines, and other associated parts of > >> the standard will come. So I ask, what is the focus (purpose) of the > >> working group? Why are you making all this effort? Is it to bring the > >> multitudes of virtual worlds to one protocol or to make transfer > >> between them possible? I posit those are two different standards and > >> only the latter is worth standardization. > >> > >> > >> My two cents anyway.... > >> > >> Kari > >> _______________________________________________ > >> ogpx mailing list > >> ogpx@ietf.org > >> https://www.ietf.org/mailman/listinfo/ogpx > > > > > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > > > --001636c5b94a0a45a404725fc2c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Meadhbh has misrepresented the points that are being made.

On Su= n, Aug 30, 2009 at 5:53 PM, Meadhbh Siobhan <meadhbh.siobhan@gmail.com> wrote:

a. we're not working on a protocol for interoperability between worlds<= br> with radically different operating assumptions. (i.e. - this is not = a
protocol intended to provide interoperability between WoW, EVE Online
and Second Life.)


Nobody has ever referred to anyth= ing that might fall under the scope of MMOX here.

This discussion ha= s been entirely about interoperation between worlds that implement OGP/VWRA= P, and to put it even more strongly, SL-compatible worlds, such as Opensim-= based worlds and SL itself.

Continually adding an irrelevant detail like "radically different = assumptions" and naming "WoW, EVE Online" only to reject the= m is a plain straw man.=A0 It does not help advance the discussion.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

On Sun, Aug 30, 2009 at 5:53 PM, Meadhbh= Siobhan <meadhbh.siobhan@gmail.com> wrote:
morgaine, i don&#= 39;t think this is a consensus view of the protocol implementers.

MMOX was the effort to define inter-world interoperability. that
effort could not reach consensus in a reasonable time frame. this
effort was organized to constrain the problem domain to define
interoperability between systems that implement a virtual world, not
to define a protocol for inter-world interoperability.

the practical consequence of this constrained scope include:

a. we're not working on a protocol for interoperability between worlds<= br> with radically different operating assumptions. (i.e. - this is not a
protocol intended to provide interoperability between WoW, EVE Online
and Second Life.)

b. we're not working on a protocol that requires all systems that
implement it to be part of the same "virtual world" (defined from= the
perspective of user.) that is, deployers of systems that implement the
protocol may, but are not required to interoperate with other
deployers.

the OGPX effort does not preclude this work, but avoids it because it
does not want to repeat the failures of MMOX.

-cheers
-meadhbh

On Sun, Aug 30, 2009 at 7:12 AM, Morgaine<morgaine.dinova@googlemail.com> wrote:
> Kari, that was an excellent review of a long series of subthreads.
>
> You have identified something that the rest of us seem to have missed:= =A0 that
> OGP / VWRAP conflates the protocol(s) used to implement a single virtu= al
> world with the protocol(s) used to implement interop between multiple<= br> > virtual worlds.=A0 No wonder we have a severe problem.
>
> That was a very insightful observation, kudos.
>
> The protocol used to implement a given virtual world is an implementat= ion
> detail of that world.
>
> Is VWRAP intended to be an implementation protocol for a VW, or an int= erop
> protocol between them?
>
> Morgaine.
>
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On Sun, Aug 30, 2009 at 1:05 PM, Kari Lippert <kari.lippert@gmail.com>
> wrote:
>>
>> My two cents....
>>
>> The first paragraph (where the purpose is being laid out) says: >>
>> Conforming =A0client =A0applications use =A0the protocol =A0to man= ipulate and
>> move the =A0user's avatar, create =A0objects in =A0a virtual w= orld, interact
>> =A0with other users =A0and their surroundings =A0and consume and c= reate
>> media and information from sources inside and outside their virtua= l
>> world.
>>
>> I normally lurk in this group but I have to say this surprised me.=
>> This statement says that I will use this protocol within my virtua= l
>> world, not that I will use this protocol to interface with differe= nt
>> virtual worlds. This doesn't speak to what I thought the thrus= t was -
>> interoperability of worlds for transportability of avatars. While = once
>> could argue that the use of the same protocol intra-world would he= lp
>> in the inter-world communication, this is not the case and should = not
>> be assumed to be so. I'm actually saddened that you're all= thinking of
>> interoperability as achievable only if everyone uses the same
>> intra-world protocol.
>>
>> "Enforcing" the use of a standard intra-world for every = world will be
>> impossible and quite possibly viewed as some by an intrusion into<= br> >> their IP, not to mention that it would kill innovation. Transfer >> between worlds will be lossy: existing worlds are not the same, no= r do
>> they have the same types of virtual property associated with them.=
>> This standard is going to either have to address the bare minimum,= or
>> become obsolete prior to completion with the introduction of a nov= el
>> virtual world into the virtual universe.
>>
>> I concur with many of the discussions that have been put forth
>> regarding this draft and have the following suggestions:
>>
>> Infinity Linden - good rewording to include OGP history; too confu= sing
>> to leave in the main body (a reader will think it a typo)
>>
>> Morgaine - agree to remove sentence that begins "To support t= he
>> exegesis =A0of the specifications..."
>>
>> meadhbh - deployment patterns are very different from models of >> protocols; deployment patterns may be useful but should not replac= e a
>> good model
>>
>> Morgaine - agree with the addition of the Foundation Component but=
>> argue that it should also be the focus in the first paragraph of t= he
>> description
>>
>> meadhbh/Morgaine/Carlo - redefinition of virtual world is a bad id= ea
>> but what you are really talking about is the virtual universe as >> composed by a variety of virtual worlds - and I like the plain Eng= lish
>> of Region 1 in VW 1 to Region 2 in VW 2 expression put forth as it= is
>> very clear, easily understood, not easily misunderstood, =A0and I<= br> >> believe captures the intent of the standard to be developed
>>
>> Once we figure out the focus (which I take to be inter-world, or >> cross-world, transfer) then we can begin capturing the requirement= s
>> for a "successful transfer". From that the model, the de= ployment
>> pattern(s), the conformance guidelines, and other associated parts= of
>> the standard will come. So I ask, what is the focus (purpose) of t= he
>> working group? Why are you making all this effort? Is it to bring = the
>> multitudes of virtual worlds to one protocol or to make transfer >> between them possible? I posit those are two different standards a= nd
>> only the latter is worth standardization.
>>
>> <step off soapbox>
>> My two cents anyway....
>>
>> Kari
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

--001636c5b94a0a45a404725fc2c3-- From kari.lippert@gmail.com Sun Aug 30 11:19:58 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034E23A6D31 for ; Sun, 30 Aug 2009 11:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY3u0OwegZxe for ; Sun, 30 Aug 2009 11:19:56 -0700 (PDT) Received: from mail-ew0-f225.google.com (mail-ew0-f225.google.com [209.85.219.225]) by core3.amsl.com (Postfix) with ESMTP id 46F263A697E for ; Sun, 30 Aug 2009 11:19:56 -0700 (PDT) Received: by ewy25 with SMTP id 25so3523660ewy.9 for ; Sun, 30 Aug 2009 11:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=uhf+bXNvb34r7caG3Vkc2J14vjgaoQd8Hx2huhcgxJw=; b=Xqf/gD2RLePiOFUPK9atDgmpwetWWIsDtM9T8gQAwfnzqgnVBPhCd9uW/lB9GbDUna Fbajidf5EvHLOLhnJ6MNzHdtFtvF4ahqUePwAKFhx4kFQWZX6OqJ8/FTOtumoLr5Jdh8 vJlzBIbJbMvjaTNcbznaFJeQ0N6wyfs/xDwl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ksuy+qImj6hdzKcltPlmdgEGa9MqYOHzvRNEC2VCcuW8HEk8FXho8J8lF/toejYjw/ F8SdqsLpEaGWxN0EcNI/M4DdMD2B5yY/HNnj5cHCqSLzc+GQb9OaSQ/8lcEGfy3Rm00f 8ZmJCg4uVM2jgPEs7P+b7q4+qR5uk9wEOFvRI= MIME-Version: 1.0 Received: by 10.216.20.74 with SMTP id o52mr929284weo.147.1251656401623; Sun, 30 Aug 2009 11:20:01 -0700 (PDT) In-Reply-To: <4A9A9D5A.9020400@dcrocker.net> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> Date: Sun, 30 Aug 2009 14:20:01 -0400 Message-ID: <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> From: Kari Lippert To: dcrocker@bbiw.net, ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 18:19:58 -0000 The network/internet analogy is great. I vote base hit.... and would like to emphasize that, given current usage of the words, the answer to > Are we connecting two virtual worlds or is the result a single > virtual world? is yes, sort of. As I understand it, VWRAP is designed to connect/allow interoperability between two or more independent/distinct/individual virtual environments/regions/worlds into what appears to the user as a single environment/region/world/universe. This single environment/region/world/universe is in fact multiple independent/distinct/individual virtual environments/regions/worlds whose boundaries could be administrative or technological but the distinction matters not. Is that right? Kari On Sun, Aug 30, 2009 at 11:40 AM, Dave CROCKER wrote: > Folks, > > > Pre-game. > > Confusion and disagreement that includes the term "virtual world" is prov= ing > tenacious, in spite of extensive and substantive discussion. =A0Typically= , > something this persistent means either that some concept(s) lack shared > definition or that competing technical paradigms are present. > > As was noted many message ago, there's a good chance that much of the > disagreement is really about the meaning of the term. =A0That is, that > apparent > disagreements about such things as scope of work is really about scope of > this one term. =A0That, at least, is my own reading of the discussions. = =A0I > think people are using the term differently. =A0If we can get to the poin= t of > using it the same > way, my sense is that we will find that disagreements about actual work t= o > be done, and its use, are rather small. > > In other words, I think the persistence of debate that keeps using that t= erm > "virtual world" means we have to resolve it before we can make serious > progress. These sorts of things never seem to go away without explicit > resolution. =A0While much of the earlier attempts to resolve this look li= ke > they helped quite a bit, it seems clear that a bit more effort is needed. > > > > The wind-up. > > Since the crux of the challenge keeps coming back to what interoperabilit= y > will > or will not be provided -- with at least one additional point about wheth= er > the > current work must be used internal to a service or only used /between/ > services > -- permit me a moment of theft from Internet history and constructs. =A0I > think it > can be applicable here: > > =A0 Network vs. Internetwork. > > =A0 "A" virtual world vs. Multiple virtual worlds. > > But hold on. =A0I'm not necessarily going to suggest mapping the two sets= as > one-to-one directly... > > Originally, a network was a discrete technical set. =A0X.25. =A0NCP. =A0X= NS. > Netware. > Whatever. =A0Both technology and administration had the same boundary. = =A0Your > network might use one technology and mine might use another. =A0But even = if > they > used the same technology, one was mine and the other was yours. =A0So I t= end > to > view interaction across administrative boundaries as far more interesting= to > internetworking than whether different technologies are used: > > =A0 > > The term Internet has come to mean a single, unified, global service. =A0= It > crosses administrative boundaries. =A0Does IBM internally operate a 'netw= ork' > or > an 'internetwork'? =A0Either choice is reasonable, depending on what is t= he > focus. I think we don't need to resolve the equivalent question here. > > There is universal agreement that there is a single global service, > comprising many independent smaller services, and that that single, large= r > thing is "The" Internet. > > What we tend to forget is that there probably are other Internets that do= n't > (directly) interoperate with the global one. =A0They are off "The Interne= t" > grid > and are on their own. =A0They are likely also "an" Internet. =A0These day= s, they > might be running TCP/IP, but they don't have to. =A0For example: > > =A0 > > Some uses of "virtual world" appear to mean an administrative boundary an= d > others appear to mean a technical boundary. This is the sort of thing we > need to resolve. > > > > The pitch. > > I suggest ignoring technical differences within an administrative domain = and > even across different administrative domains. =A0Simply, VWrap is used to > connect together administrative domains running simulations. > > =A0 =A0 I'm running one simulation and you are running another. =A0We use > =A0 =A0 VWrap to interoperate. > > =A0 =A0 Are we connecting two virtual worlds or is the result a single > =A0 =A0 virtual world? > > Some other folk might not interoperate with our unified service. =A0They = are > running their own thing. =A0Are they running a different virtual world or= , > perhaps, a different set of multiple virtual worlds? > > > > The swing. > > I suggest that: > > =A0 =A0 Any set of independent administrative domains that interoperate > =A0 =A0 together, using VWrap, creates a /single/ virtual world. > > =A0 =A0 Each independent administrative domain is running /part/ of that = single > =A0 =A0 virtual world. =A0(The part might be one Region, or Agent, or it = might be > =A0 =A0 many of both or any combination.) > > =A0 =A0 Hence, I am suggesting that an integrated VWrap environment has a > =A0 =A0 comparable quality to an integrated internet environment that we = call > =A0 =A0 "The" Internet. =A0One service. > > If you are running a simulation that is not part of an integrated, > interoperable > VWrap environment, you are in a different virtual world. > > =A0 =A0 If you are part of an interoperable VWrap service, you are in a > =A0 =A0 single virtual world. > > It doesn't matter what you run internally. =A0What matters is integration= to > the > interoperable service using VWrap. > > > > Base hit or strikeout? > > d/ > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From meadhbh.siobhan@gmail.com Sun Aug 30 11:34:14 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF9E3A6B8F for ; Sun, 30 Aug 2009 11:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIajcBRqmn05 for ; Sun, 30 Aug 2009 11:34:13 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id D39D33A6AE1 for ; Sun, 30 Aug 2009 11:34:12 -0700 (PDT) Received: by iwn38 with SMTP id 38so1549296iwn.29 for ; Sun, 30 Aug 2009 11:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H6MjslZ49sogKCozbzg8DrIquth2+TZM6S/Dxpaffm0=; b=FPQY+71t7XiP3nD+eA3aIMtDZs7wOxlFN/N65XaVwnkKEpynuOPuBCFTwxJZUQIlVI HarL0PWl5aWMjPK8Heg3LSMN/Px71VD9TQ4Z8OJEJoojSDxS9C/O6oLyuVGxXPXk4jev ELaZteISSg64N4K4WL2xdTh4XI/K1iyjQTpx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NubHNwbOJvJu0fDYvr28DSLqAHyqLzhyIn+covTeR1tmAoGWQSGCl93VLd6Va+Rw/9 lRglqYfPkDhFwxAjK3tavwnzdWzKfx1oV3bS3BfpW0zkad+ZhG0DTVhEqO/CTbNlb0v2 o6NNu+/5vWQvAzLww4KLprz9EatnXQOsWlIUg= MIME-Version: 1.0 Received: by 10.231.121.99 with SMTP id g35mr5424953ibr.24.1251657258151; Sun, 30 Aug 2009 11:34:18 -0700 (PDT) In-Reply-To: <4A9A9D5A.9020400@dcrocker.net> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> Date: Sun, 30 Aug 2009 11:34:18 -0700 Message-ID: From: Meadhbh Siobhan To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 18:34:14 -0000 so. this is an interesting one. those of us who called for the OGPX BoF are in agreement that the term "virtual world" is informational only. it is evocative of the problem domain, but yeah, difficult to pin down. we explicitly used the terms "region domain" and "agent domain" and "client application" to avoid having to define the term "virtual world." our intent is to define terms that are consensus based, germane to the standards effort and necessary. i think introducing "virtual world" as a normative term would be akin to introducing terms for "the web" or "an intranet" to a protocol document like RFC2616. it is informational, but not a requirement to specifying the protocol. further, defining "the web" or "an intranet" or a "virtual world" may artificially limit future options. for example, when HTTP was first under development, important features of "the web" weren't deployed (like the "behind the firewall" deployment pattern commonly thought to be core to the term "intranet" or the wide-spread use of ECMAscript for enhanced interactivity in web applications.) my feeling is that we're at the same place with "virtual worlds" right now; we're at the beginning of process rather than the end. defining a "virtual world" to be limited to a specific area of the problem domain could be interpreted as precluding this protocol's use in other, yet to be imagined, applications. imagine, for example, that at the time that HTTP just started attracting attention and people started using the term "the web" someone suggested that gopher sites should not be considered part of "the web." this actually did happen... i was actually in a conversation in 1993 where people asked whether it was considered appropriate for legacy gopher services to be accessible while their content was moved to HTTP access. because the ambiguously defined term "the web" was introduced into a formal statement of work, we had to actually spend cycles defining it. ultimately we were able to do this because the term is defined in an ambiguous manner; we were able to argue that the web should be defined in terms of the content accessible to the user, and not in terms of the protocol used to access that content or in the precise manner it is deployed. had the term "the web" been defined at that time to be limited to information accessible via HTTP, there would have been unfortunate and unintended consequences. this is why a number of us are concerned with efforts to define the term in a normative fashion. if we start by saying the virtual world is defined as being "all the places an avatar can go," does this mean that information that comes into the virtual world by way of web protocols, from web sites intended to be used by traditional web browsers is or is not part of the virtual world? or what about two "worlds" that only share a single region? are they simultaneously part of the same "overworld" and part of distinct "subordinate worlds"? but still... part of the reason we came to this forum was to get feedback, and it's starting to sound like we want to have at least a working definition of the term, if for no other reason than to evoke an intuitive understanding of the problem domain. if we want to define a meaning for the term "virtual world," let's be clear that the definition is non-normative. for related reasons, i'm reticent to say that the collection of distinct existent virtual worlds combine to make "the" virtual world. is it possible to move the definition of "virtual world" to the intro document? i would assert we have sufficient interest in the problem domain to establish a working group, and that the definition of the term "virtual world" is orthogonal to this group's initial efforts. (why do we need to get hung up on the definition of the term when the specifications do not use the term in a normative fashion? it's like saying we can't work on HTTP because we can't decide whether resources accessed by GOPHER are part of "the web.") -cheers -meadhbh / infinity On Sun, Aug 30, 2009 at 8:40 AM, Dave CROCKER wrote: > Folks, > > > Pre-game. > > Confusion and disagreement that includes the term "virtual world" is prov= ing > tenacious, in spite of extensive and substantive discussion. =A0Typically= , > something this persistent means either that some concept(s) lack shared > definition or that competing technical paradigms are present. > > As was noted many message ago, there's a good chance that much of the > disagreement is really about the meaning of the term. =A0That is, that > apparent > disagreements about such things as scope of work is really about scope of > this one term. =A0That, at least, is my own reading of the discussions. = =A0I > think people are using the term differently. =A0If we can get to the poin= t of > using it the same > way, my sense is that we will find that disagreements about actual work t= o > be done, and its use, are rather small. > > In other words, I think the persistence of debate that keeps using that t= erm > "virtual world" means we have to resolve it before we can make serious > progress. These sorts of things never seem to go away without explicit > resolution. =A0While much of the earlier attempts to resolve this look li= ke > they helped quite a bit, it seems clear that a bit more effort is needed. > > > > The wind-up. > > Since the crux of the challenge keeps coming back to what interoperabilit= y > will > or will not be provided -- with at least one additional point about wheth= er > the > current work must be used internal to a service or only used /between/ > services > -- permit me a moment of theft from Internet history and constructs. =A0I > think it > can be applicable here: > > =A0 Network vs. Internetwork. > > =A0 "A" virtual world vs. Multiple virtual worlds. > > But hold on. =A0I'm not necessarily going to suggest mapping the two sets= as > one-to-one directly... > > Originally, a network was a discrete technical set. =A0X.25. =A0NCP. =A0X= NS. > Netware. > Whatever. =A0Both technology and administration had the same boundary. = =A0Your > network might use one technology and mine might use another. =A0But even = if > they > used the same technology, one was mine and the other was yours. =A0So I t= end > to > view interaction across administrative boundaries as far more interesting= to > internetworking than whether different technologies are used: > > =A0 > > The term Internet has come to mean a single, unified, global service. =A0= It > crosses administrative boundaries. =A0Does IBM internally operate a 'netw= ork' > or > an 'internetwork'? =A0Either choice is reasonable, depending on what is t= he > focus. I think we don't need to resolve the equivalent question here. > > There is universal agreement that there is a single global service, > comprising many independent smaller services, and that that single, large= r > thing is "The" Internet. > > What we tend to forget is that there probably are other Internets that do= n't > (directly) interoperate with the global one. =A0They are off "The Interne= t" > grid > and are on their own. =A0They are likely also "an" Internet. =A0These day= s, they > might be running TCP/IP, but they don't have to. =A0For example: > > =A0 > > Some uses of "virtual world" appear to mean an administrative boundary an= d > others appear to mean a technical boundary. This is the sort of thing we > need to resolve. > > > > The pitch. > > I suggest ignoring technical differences within an administrative domain = and > even across different administrative domains. =A0Simply, VWrap is used to > connect together administrative domains running simulations. > > =A0 =A0 I'm running one simulation and you are running another. =A0We use > =A0 =A0 VWrap to interoperate. > > =A0 =A0 Are we connecting two virtual worlds or is the result a single > =A0 =A0 virtual world? > > Some other folk might not interoperate with our unified service. =A0They = are > running their own thing. =A0Are they running a different virtual world or= , > perhaps, a different set of multiple virtual worlds? > > > > The swing. > > I suggest that: > > =A0 =A0 Any set of independent administrative domains that interoperate > =A0 =A0 together, using VWrap, creates a /single/ virtual world. > > =A0 =A0 Each independent administrative domain is running /part/ of that = single > =A0 =A0 virtual world. =A0(The part might be one Region, or Agent, or it = might be > =A0 =A0 many of both or any combination.) > > =A0 =A0 Hence, I am suggesting that an integrated VWrap environment has a > =A0 =A0 comparable quality to an integrated internet environment that we = call > =A0 =A0 "The" Internet. =A0One service. > > If you are running a simulation that is not part of an integrated, > interoperable > VWrap environment, you are in a different virtual world. > > =A0 =A0 If you are part of an interoperable VWrap service, you are in a > =A0 =A0 single virtual world. > > It doesn't matter what you run internally. =A0What matters is integration= to > the > interoperable service using VWrap. > > > > Base hit or strikeout? > > d/ > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From kari.lippert@gmail.com Sun Aug 30 11:37:03 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7403A68E1 for ; Sun, 30 Aug 2009 11:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uhmdbJhnLC9 for ; Sun, 30 Aug 2009 11:37:02 -0700 (PDT) Received: from mail-ew0-f225.google.com (mail-ew0-f225.google.com [209.85.219.225]) by core3.amsl.com (Postfix) with ESMTP id 438C63A68B6 for ; Sun, 30 Aug 2009 11:37:02 -0700 (PDT) Received: by ewy25 with SMTP id 25so3531679ewy.9 for ; Sun, 30 Aug 2009 11:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/TAyQ+LmRwGJGeh/CYkOZHNzGKs7Umi+X7jf2+pynXY=; b=IpJ+Lm0dU0v77YwfEe0lUhydaVSgvLP9NNpkLK4XLooXyvr7Jk+7qIBt/meqR/Vf2r vfswJYTAd8qSzFw/gZJQA0z3jOl+LvGRWSUzqSnNl5B4DYVoz1HJ64fi+3RkF12Y4Y8x 8OfEVsbQQIDNpXOiBI8EkCaVo8PMNQQRnRQDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V7gpy+mhCfvtQv0toXRuaQ8jzx+v31dLW99qR9uDJEPxDiftTflzYDvwWQBDfLI4we zfNK6vBGo7XLqmhV9J7iAbNFfcF3FDzrpIuUKxVLGYBzi0C3N4mzBNTpvwsf6jCcQkN9 YFyWlAGQwBr6GzOnUIhwE8XR6R+F9MqObCx00= MIME-Version: 1.0 Received: by 10.216.26.205 with SMTP id c55mr914774wea.1.1251657426482; Sun, 30 Aug 2009 11:37:06 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> Date: Sun, 30 Aug 2009 14:37:06 -0400 Message-ID: <382d73da0908301137v1993441ci15f00c9a4a09e7a5@mail.gmail.com> From: Kari Lippert To: Meadhbh Siobhan Content-Type: text/plain; charset=ISO-8859-1 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 18:37:03 -0000 My bad - I thought this was, in fact, a continuation of the MMOX effort. I stand corrected. In defense of my earlier thoughts.... > > we do not define the term "virtual world." there is considerable > disagreement as to what the term means. Yes, and this is the core of the problem. > in the part of the problem domain we are choosing to work on, > we do not discuss interoperability between "virtual worlds" as this > term is not used normatively. instead, we define the terms "region > domain" and "simulator" and "agent domain" and a few others and define > interoperability expectations and protocol between _them_. Missed the part where those were defined, although I think the group charter should not rely on having to include definitions/redefinitions. I was thrown by the words "region", "domain", and "agent" as they all have pretty strong meaning which didn't quite fit for me. Not that it can't be done this way, it's just going to be hard because you're creating definitions for a terms in a context where they are already used. > inter-virtual world protocol. Awesome! > interoperability of avatar formats is one aspect of this protocol, but > not the only one. So if I have a virtual place that implements the VWRAP protocol I can do more than move avatars - again, awesome. I will refer here to the other email regarding the "subsumption theory of virtual places". > > it should also be noted that we are not attempting to say that our > model is the _ONLY_ valid models for virtual worlds. this is one of > the reasons that OGPX is a distinct effort from MMOX. MMOX retains the > wider focus, and as i understand it, there's no reason someone else > can't continue it's work, or define a separate part of the problem > domain and form another working group. > MMOX is dead (or just resting)? I really did think this group was one and the same. > > unlike MMOX, we are not attempting, in this group, to define a generic > protocol to be used by every virtual world. OGPX is intended to > provide interoperability, not between worlds, but between hosts that > work together to simulate a virtual world. > So it is a generic protocol to be used by every "unit" that wishes to become part of the whole. You will still need enforcement, compliance measures, etc. >> meadhbh - deployment patterns are very different from models of >> protocols; deployment patterns may be useful but should not replace a >> good model > > are we talking about a processing model? we really want to define a > processing model for conforming implementations? I was actually talking about a protocol model, not a process model. A process model is not necessary; definition of what entails conformance will be. > the focus of the group is to define an interoperability profile and > protocol, deployment patterns and processing expectations for these > worlds. > This isn't quite what the charter says, which is what I was getting at. There are a couple of very key points missing which have been more or less fleshed out in these various emails today. Kari From meadhbh.siobhan@gmail.com Sun Aug 30 11:50:44 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C53F3A6A29 for ; Sun, 30 Aug 2009 11:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuV8ISd6Rh7H for ; Sun, 30 Aug 2009 11:50:42 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id B40703A6980 for ; Sun, 30 Aug 2009 11:50:42 -0700 (PDT) Received: by iwn38 with SMTP id 38so1553108iwn.29 for ; Sun, 30 Aug 2009 11:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+oNGHQvfPE/0tcvuN1J2pH/g/f2AInZC4+4TqKBI+SQ=; b=QWnJTPVsMIRHqp9DTK5vcNZSEDIZ9H1/iwTBhnaWCz7EWwWwsfEpgBXd7zYwD44DuE n0V2SFA8d6n+wLZBhStQVBbRnZL2b4TM+2NdplLvm5eox+XvMWInCS17xMtZx4a0XK3l s75HZbCl3iMYkfRiAxtJurr81vPxzP15fy5Ms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RqcMl+X1MQ3ADFCQWTmPmp04QTdXqtTo3vRyA0J2eIW8AB6HefBAskYhXfvQRyaVlM k0xiLQFM6EI4kWN7RANsIKMci/bNg3QNB1aBu+Akwg7dzJlTKX5lZ880RSl0ajKAa89S AxlLitFcyfANTe/ziQjwtPphS2Nzg+I3v6QZU= MIME-Version: 1.0 Received: by 10.231.121.69 with SMTP id g5mr5385113ibr.44.1251658246709; Sun, 30 Aug 2009 11:50:46 -0700 (PDT) In-Reply-To: <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> Date: Sun, 30 Aug 2009 11:50:46 -0700 Message-ID: From: Meadhbh Siobhan To: Kari Lippert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org, dcrocker@bbiw.net Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 18:50:44 -0000 On Sun, Aug 30, 2009 at 11:20 AM, Kari Lippert wrot= e: > The network/internet analogy is great. I vote base hit.... and would > like to emphasize that, given current usage of the words, the answer > to > >> =A0 =A0 Are we connecting two virtual worlds or is the result a single >> =A0 =A0 virtual world? > > is yes, sort of. > > As I understand it, VWRAP is designed to connect/allow > interoperability between two or more independent/distinct/individual > virtual environments/regions/worlds into what appears to the user as a > single environment/region/world/universe. This single > environment/region/world/universe is in fact multiple > independent/distinct/individual virtual environments/regions/worlds > whose boundaries could be administrative or technological but the > distinction matters not. > > Is that right? > > Kari > this is an interesting use case, but not what OGPX/VWRAP was proposed to address. MMOX remains as a venue for the discussion of integrating technically diverse virtual worlds. > > > > > > On Sun, Aug 30, 2009 at 11:40 AM, Dave CROCKER wrote: >> Folks, >> >> >> Pre-game. >> >> Confusion and disagreement that includes the term "virtual world" is pro= ving >> tenacious, in spite of extensive and substantive discussion. =A0Typicall= y, >> something this persistent means either that some concept(s) lack shared >> definition or that competing technical paradigms are present. >> >> As was noted many message ago, there's a good chance that much of the >> disagreement is really about the meaning of the term. =A0That is, that >> apparent >> disagreements about such things as scope of work is really about scope o= f >> this one term. =A0That, at least, is my own reading of the discussions. = =A0I >> think people are using the term differently. =A0If we can get to the poi= nt of >> using it the same >> way, my sense is that we will find that disagreements about actual work = to >> be done, and its use, are rather small. >> >> In other words, I think the persistence of debate that keeps using that = term >> "virtual world" means we have to resolve it before we can make serious >> progress. These sorts of things never seem to go away without explicit >> resolution. =A0While much of the earlier attempts to resolve this look l= ike >> they helped quite a bit, it seems clear that a bit more effort is needed= . >> >> >> >> The wind-up. >> >> Since the crux of the challenge keeps coming back to what interoperabili= ty >> will >> or will not be provided -- with at least one additional point about whet= her >> the >> current work must be used internal to a service or only used /between/ >> services >> -- permit me a moment of theft from Internet history and constructs. =A0= I >> think it >> can be applicable here: >> >> =A0 Network vs. Internetwork. >> >> =A0 "A" virtual world vs. Multiple virtual worlds. >> >> But hold on. =A0I'm not necessarily going to suggest mapping the two set= s as >> one-to-one directly... >> >> Originally, a network was a discrete technical set. =A0X.25. =A0NCP. =A0= XNS. >> Netware. >> Whatever. =A0Both technology and administration had the same boundary. = =A0Your >> network might use one technology and mine might use another. =A0But even= if >> they >> used the same technology, one was mine and the other was yours. =A0So I = tend >> to >> view interaction across administrative boundaries as far more interestin= g to >> internetworking than whether different technologies are used: >> >> =A0 >> >> The term Internet has come to mean a single, unified, global service. = =A0It >> crosses administrative boundaries. =A0Does IBM internally operate a 'net= work' >> or >> an 'internetwork'? =A0Either choice is reasonable, depending on what is = the >> focus. I think we don't need to resolve the equivalent question here. >> >> There is universal agreement that there is a single global service, >> comprising many independent smaller services, and that that single, larg= er >> thing is "The" Internet. >> >> What we tend to forget is that there probably are other Internets that d= on't >> (directly) interoperate with the global one. =A0They are off "The Intern= et" >> grid >> and are on their own. =A0They are likely also "an" Internet. =A0These da= ys, they >> might be running TCP/IP, but they don't have to. =A0For example: >> >> =A0 >> >> Some uses of "virtual world" appear to mean an administrative boundary a= nd >> others appear to mean a technical boundary. This is the sort of thing we >> need to resolve. >> >> >> >> The pitch. >> >> I suggest ignoring technical differences within an administrative domain= and >> even across different administrative domains. =A0Simply, VWrap is used t= o >> connect together administrative domains running simulations. >> >> =A0 =A0 I'm running one simulation and you are running another. =A0We us= e >> =A0 =A0 VWrap to interoperate. >> >> =A0 =A0 Are we connecting two virtual worlds or is the result a single >> =A0 =A0 virtual world? >> >> Some other folk might not interoperate with our unified service. =A0They= are >> running their own thing. =A0Are they running a different virtual world o= r, >> perhaps, a different set of multiple virtual worlds? >> >> >> >> The swing. >> >> I suggest that: >> >> =A0 =A0 Any set of independent administrative domains that interoperate >> =A0 =A0 together, using VWrap, creates a /single/ virtual world. >> >> =A0 =A0 Each independent administrative domain is running /part/ of that= single >> =A0 =A0 virtual world. =A0(The part might be one Region, or Agent, or it= might be >> =A0 =A0 many of both or any combination.) >> >> =A0 =A0 Hence, I am suggesting that an integrated VWrap environment has = a >> =A0 =A0 comparable quality to an integrated internet environment that we= call >> =A0 =A0 "The" Internet. =A0One service. >> >> If you are running a simulation that is not part of an integrated, >> interoperable >> VWrap environment, you are in a different virtual world. >> >> =A0 =A0 If you are part of an interoperable VWrap service, you are in a >> =A0 =A0 single virtual world. >> >> It doesn't matter what you run internally. =A0What matters is integratio= n to >> the >> interoperable service using VWrap. >> >> >> >> Base hit or strikeout? >> >> d/ >> -- >> >> =A0Dave Crocker >> =A0Brandenburg InternetWorking >> =A0bbiw.net >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From meadhbh.siobhan@gmail.com Sun Aug 30 11:54:19 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989153A6949 for ; Sun, 30 Aug 2009 11:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDuV03+-7Ml9 for ; Sun, 30 Aug 2009 11:54:18 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id CB38A3A67D7 for ; Sun, 30 Aug 2009 11:54:18 -0700 (PDT) Received: by iwn38 with SMTP id 38so1553941iwn.29 for ; Sun, 30 Aug 2009 11:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=xu7w2rDNMkJtmgQNxyA6BNCqpO1WOlNcuVvvONn1BKA=; b=G7iYWsHXoQh43c4NxbB1QtWtx0jNm9Crrmah07GQ/T3etA5oyH/hpksX4VUmTHKalK jxRh4u6N7ftGhLJiw9+f0ePdYRqLhAtyPFM4uxGOGr4iDEEYIq3IJxOZIQrKXey4Qxys tgnTlixGq242KuBqfkplZdWVD91XNCV8VVuuA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=x7U8BJcDwyxDqz1UKWdkO+0MlnLUs+f9pj71PdJ7UiGQW+bPi6nhYSWDjzbJicST00 bbyQ/wUwkkA3g9yZLGSV1PebszfjdaQ7+c7TG4bmRmVDoOG2BPp/1TjTvJvwbxvwbM16 cUqEWKxrMSW8JZtVn9z13K0XfGRgxmf/6/nG8= MIME-Version: 1.0 Received: by 10.231.63.197 with SMTP id c5mr5505574ibi.4.1251658465333; Sun, 30 Aug 2009 11:54:25 -0700 (PDT) In-Reply-To: <20090830130045.GA29271@alinoe.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <4646639E08F58B42836FAC24C94624DD6FE8098411@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0908281259h3a10cd02mc92eb8331c92f162@mail.gmail.com> <20090829232125.GC22756@alinoe.com> <6c9fcc2a0908300553x57c76279p9a95c105f0e7e34a@mail.gmail.com> <20090830130045.GA29271@alinoe.com> Date: Sun, 30 Aug 2009 11:54:25 -0700 Message-ID: From: Meadhbh Siobhan To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Cc: barryleiba@computer.org, ogpx@ietf.org Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 18:54:19 -0000 what version of the draft are you looking at? the most recent version uses "protocol" almost exclusively (using "protocols" only in one spot near the initialism OGPX.) i'm not saying this to argue for or against the use of "protocol" over "protocols," only to point out that we might be looking at different revisions of the draft charter. On Sun, Aug 30, 2009 at 6:00 AM, Carlo Wood wrote: > On Sun, Aug 30, 2009 at 08:53:58AM -0400, Barry Leiba wrote: >> As I read things, it should stand for Virtual World Region/Agent >> Protocols (note the final "s"), giving the name the flexibility to >> cover multiple related protocols (one of which could certainly be >> called "VWRAP" as well, and would, in that case, have no "s". > > Virtual Worlds Region/Agent Protocol(s) > > no opinion yet on the s behind Protocol, but there should be > an 's' behind Worlds. > > This is already done correctly in the draft. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From meadhbh.siobhan@gmail.com Sun Aug 30 11:54:47 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7488E28C12D for ; Sun, 30 Aug 2009 11:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F27fN4mznYLT for ; Sun, 30 Aug 2009 11:54:46 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id B93E03A67D7 for ; Sun, 30 Aug 2009 11:54:46 -0700 (PDT) Received: by mail-iw0-f200.google.com with SMTP id 38so1553941iwn.29 for ; Sun, 30 Aug 2009 11:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gOklsvhk/EpRB78ts9hD3jNUClWvFDplT672MbA12xA=; b=hcG/zHS/sr5S9+DP2l3R1q5ooF3rGHf2YBjjqJs78y4QucVRVEctHX+7VHDpU+6bYd Z+Sz8AOqdDISAptDIPsdt7Z1RsuWoEwvG4P0LhmUPiTC3MHcaleTd7/kCQzAi+FOJhd3 EkhOVJZ9XrIO5PkqEvSuvlCoOV9XEEWyBRUeA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=r4HYxUPY2Cygc5/aJR4V1yPvOR8cPM5C2yynjbxfCMM5ArFPlF46rPd5UbaCJQordx PFDHiUO9gFGYn2k0fnVX8AYvT2Gv4eEdYeWMnsixmnf+pz9uY295vZSsW+PZH4jtJmXe DjQtnclG2BUEJBYbH6ENi4qs1kuUGq4lVqaYs= MIME-Version: 1.0 Received: by 10.231.25.29 with SMTP id x29mr5406539ibb.31.1251658496141; Sun, 30 Aug 2009 11:54:56 -0700 (PDT) In-Reply-To: <382d73da0908300604x17fa14f2pd5f8291cc61d3298@mail.gmail.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <4646639E08F58B42836FAC24C94624DD6FE8098411@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0908281259h3a10cd02mc92eb8331c92f162@mail.gmail.com> <20090829232125.GC22756@alinoe.com> <6c9fcc2a0908300553x57c76279p9a95c105f0e7e34a@mail.gmail.com> <20090830130045.GA29271@alinoe.com> <382d73da0908300604x17fa14f2pd5f8291cc61d3298@mail.gmail.com> Date: Sun, 30 Aug 2009 11:54:56 -0700 Message-ID: From: Meadhbh Siobhan To: Kari Lippert Content-Type: text/plain; charset=ISO-8859-1 Cc: ogpx@ietf.org Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 18:54:47 -0000 i +1 kari's +1. On Sun, Aug 30, 2009 at 6:04 AM, Kari Lippert wrote: >> >> Virtual Worlds Region/Agent Protocol(s) >> > > > > +1 > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From kari.lippert@gmail.com Sun Aug 30 11:54:50 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19543A67D7 for ; Sun, 30 Aug 2009 11:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEKZsry901jM for ; Sun, 30 Aug 2009 11:54:49 -0700 (PDT) Received: from mail-ew0-f225.google.com (mail-ew0-f225.google.com [209.85.219.225]) by core3.amsl.com (Postfix) with ESMTP id DF86328C13E for ; Sun, 30 Aug 2009 11:54:48 -0700 (PDT) Received: by ewy25 with SMTP id 25so3539914ewy.9 for ; Sun, 30 Aug 2009 11:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=9Ob1876xLmuggaj3RiXqxR2ChPfS+XpOEb343LwuUsk=; b=MrW2gxe66cKnoeSk/NH5YtHUPqdJqe9/F75/2TkAGEBvsrf9hUWTNyC8i3tfjNhK4S kaQ6uTRQhEAkdWPzXUXkT+9F/prBWIcC2QO7vVPHmQa8Wn2maUOHfA+e/mANsRBomhci Swcq2G/QDialuba7G3OP2NSXyMZpHX2MC4GsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=xLN5Zx8KVKWg4+KucZExbn2GmqCQa0/kcZqTl9y2CsGLLw9sJqhx1CmQCROZnETQ/s RuFZ8pyWZaQvEdp3tsDA6fckv+W6T0EsDP3RcX3Ru/N55QXQQ1DyB5GoAhHG4QSOIR1l IgHTGz6I3g3AEzINrtp80+96T3h075fhk2gTg= MIME-Version: 1.0 Received: by 10.216.86.211 with SMTP id w61mr910217wee.6.1251658490075; Sun, 30 Aug 2009 11:54:50 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> Date: Sun, 30 Aug 2009 14:54:50 -0400 Message-ID: <382d73da0908301154r27368070sccb56d437ebce1d3@mail.gmail.com> From: Kari Lippert To: Meadhbh Siobhan , ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 18:54:50 -0000 > > if we start by saying the virtual world is defined as being "all the > places an avatar can go," does this mean that information that comes > into the virtual world by way of web protocols, from web sites > intended to be used by traditional web browsers is or is not part of > the virtual world? or what about two "worlds" that only share a single > region? are they simultaneously part of the same "overworld" and part > of distinct "subordinate worlds"? Consider the "explosion" of "virtual" 3D "world" spaces such as those associated with http://www.gogofrog.com/. I don't think this is quite what is desired at this point, nor do I think we have to tackle the elephant "all the places an avatar can go". > > but still... part of the reason we came to this forum was to get > feedback, and it's starting to sound like we want to have at least a > working definition of the term, if for no other reason than to evoke > an intuitive understanding of the problem domain. > More than that, to include a term that will be defined later in the charter is inviting discord and misunderstanding. > is it possible to move the definition of "virtual world" to the intro > document? It must be - and a new, less overloaded word (or acronym) could be used instead. I saw some great acronyms earlier (those folk may have a future with the government!) so wondered if the easiest way out is to establish a term that is what we mean. > (why do we need to get hung up on the definition of the term when the > specifications do not use the term in a normative fashion? it's like > saying we can't work on HTTP because we can't decide whether resources > accessed by GOPHER are part of "the web.") IMHO, I think a decision was made when work on HTTP was begun and that was to exclude gopher sites. I don't know if that was done to allow the work to proceed technically or to deal with an issue that could well have been exactly like this. I believe our problem only comes when someone not privy to all the back conversation comes to the charter and misinterprets. I sense a decent consensus within this group but a lack of proper vocabulary to express the concepts. Kari From kari.lippert@gmail.com Sun Aug 30 11:58:06 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9573B28C132 for ; Sun, 30 Aug 2009 11:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2ovMT4szS2P for ; Sun, 30 Aug 2009 11:58:05 -0700 (PDT) Received: from mail-ew0-f225.google.com (mail-ew0-f225.google.com [209.85.219.225]) by core3.amsl.com (Postfix) with ESMTP id A37D43A6949 for ; Sun, 30 Aug 2009 11:58:05 -0700 (PDT) Received: by ewy25 with SMTP id 25so3541532ewy.9 for ; Sun, 30 Aug 2009 11:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=0BpeXOGPWwCkY55txhbqzaq2u36TBooLmsXPMEzJyvs=; b=RQTAtkGGo3y3b7YM945cNfi83oO7JEwm7sfDSHojGziwsJA7l1+Yzyl0/i38GkJYXn PtzhYy10JSkGk864B1AVx80AuYfEFLzBeeDUGewyzGI38kXPof7Jk3B3v04TPUQJB/yV t+Yjnb22Qo0uJN4D21cxupPl9QQB8CK/4xhwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=dQun5hvt36nLBhLkYsLeF8Z5riZsv1nk5bJ+2yBa6Oc5+EDDYHU9Iqb+zNKA5Y8hEN G5T2iaA+vOlL+etWVmFCGIr8ol+FAL+fao/nuj+4hFlg6knGoYCIwZXfvF0jrGX9ZO1I pzU/sNWfbKCO/4e+OWz6BhpYBiRVJOvx9CteY= MIME-Version: 1.0 Received: by 10.216.87.67 with SMTP id x45mr935288wee.18.1251658691424; Sun, 30 Aug 2009 11:58:11 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> Date: Sun, 30 Aug 2009 14:58:11 -0400 Message-ID: <382d73da0908301158y5276835bt9e68ee91c6dae003@mail.gmail.com> From: Kari Lippert To: Meadhbh Siobhan , ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 18:58:06 -0000 On Sun, Aug 30, 2009 at 2:50 PM, Meadhbh Siobhan wrote: > On Sun, Aug 30, 2009 at 11:20 AM, Kari Lippert wr= ote: >> The network/internet analogy is great. I vote base hit.... and would >> like to emphasize that, given current usage of the words, the answer >> to >> >>> =A0 =A0 Are we connecting two virtual worlds or is the result a single >>> =A0 =A0 virtual world? >> >> is yes, sort of. >> >> As I understand it, VWRAP is designed to connect/allow >> interoperability between two or more independent/distinct/individual >> virtual environments/regions/worlds into what appears to the user as a >> single environment/region/world/universe. This single >> environment/region/world/universe is in fact multiple >> independent/distinct/individual virtual environments/regions/worlds >> whose boundaries could be administrative or technological but the >> distinction matters not. >> >> Is that right? >> >> Kari >> > > this is an interesting use case, but not what OGPX/VWRAP was proposed > to address. > > MMOX remains as a venue for the discussion of integrating technically > diverse virtual worlds. > > So OGPX/VWRAP is being proposed to address the problem of the integration of non-technically diverse virtual worlds all implementing the same protocol? Perhaps I should interact with the MMOX group. Since I thought I was, can you point me in their direction? Thanks! Kari From meadhbh.siobhan@gmail.com Sun Aug 30 12:34:21 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE18228C13E for ; Sun, 30 Aug 2009 12:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slBoVMSYgWmY for ; Sun, 30 Aug 2009 12:34:20 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id B63AC3A6CD0 for ; Sun, 30 Aug 2009 12:34:20 -0700 (PDT) Received: by iwn38 with SMTP id 38so1562498iwn.29 for ; Sun, 30 Aug 2009 12:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jDB4YILXW3VsdnrM6yg3p7K3cVgQj6g1ps7+Iol2Ie4=; b=qd5KQDgZJdo7HoR2uvFY3vrfeL2xGba+ZRivcZ13rFH6xZSLPBvJvmC3R54x9q0+KP rFSLquMupEBOdNgOMSB+CKAVogbqiIvthm60cM2bm9Avwt80CBVVlvUInhu+hIiEKgJJ UmYPMtDrfIYWclyKK2JfMXrmybH/iG25JXalA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SSDioQyeyK5ZJJW4dEpck9a0qaGK8OzET9He64joeZeeO/HTYdm3yZwAAR7bV/zajK l88l44czhUgVtidpFimgI+ao+X1fKCL1kwotTCj2QzZx8XV6q0OzwK8HvEeNhnZEsLgP 9eUC6ZGxaifEjtPBpSrLZTqOpGi6ll2c4Mzak= MIME-Version: 1.0 Received: by 10.231.121.99 with SMTP id g35mr5536736ibr.24.1251660864181; Sun, 30 Aug 2009 12:34:24 -0700 (PDT) In-Reply-To: <382d73da0908301154r27368070sccb56d437ebce1d3@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301154r27368070sccb56d437ebce1d3@mail.gmail.com> Date: Sun, 30 Aug 2009 12:34:24 -0700 Message-ID: From: Meadhbh Siobhan To: Kari Lippert Content-Type: text/plain; charset=ISO-8859-1 Cc: ogpx@ietf.org Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 19:34:22 -0000 On Sun, Aug 30, 2009 at 11:54 AM, Kari Lippert wrote: >> >> if we start by saying the virtual world is defined as being "all the >> places an avatar can go," does this mean that information that comes >> into the virtual world by way of web protocols, from web sites >> intended to be used by traditional web browsers is or is not part of >> the virtual world? or what about two "worlds" that only share a single >> region? are they simultaneously part of the same "overworld" and part >> of distinct "subordinate worlds"? > > Consider the "explosion" of "virtual" 3D "world" spaces such as those > associated with http://www.gogofrog.com/. I don't think this is quite > what is desired at this point, nor do I think we have to tackle the > elephant "all the places an avatar can go". > we are not proposing a protocol that will span technically distinct virtual worlds. we are defining a protocol for interoperation between systems that share common assumptions about a virtual world. (which are defined in the intro doc, and were mentioned in the charter until the consensus was to remove them.) MMOX was setup to address the problem interoperability between worlds that do not support the same set of operating assumptions. >> >> but still... part of the reason we came to this forum was to get >> feedback, and it's starting to sound like we want to have at least a >> working definition of the term, if for no other reason than to evoke >> an intuitive understanding of the problem domain. >> > > More than that, to include a term that will be defined later in the > charter is inviting discord and misunderstanding. cool. i think this means we're in agreement. > > > >> is it possible to move the definition of "virtual world" to the intro >> document? > > It must be - and a new, less overloaded word (or acronym) could be > used instead. I saw some great acronyms earlier (those folk may have a > future with the government!) so wondered if the easiest way out is to > establish a term that is what we mean. yeah. i think there was a lot of pairwise discussion about this before and after the BoF in Stockholm. If I remember correctly, a lot of us felt that though the term "virtual world" had baggage, it was so evocative, it's use was warranted. don't know if you saw the previous discussion about reasons how we figured out that the name OGP was sub-optimal for use in the IETF. and. it looks like we're starting to hum on the name, and it includes the term "virtual world." maybe the thing to do would be to use the term "virtual world" in an expressly non-normative manner in the charter and introduce a term like "virtual social space" in the intro to further refine the consensus view of what we're working on. > > >> (why do we need to get hung up on the definition of the term when the >> specifications do not use the term in a normative fashion? it's like >> saying we can't work on HTTP because we can't decide whether resources >> accessed by GOPHER are part of "the web.") > > IMHO, I think a decision was made when work on HTTP was begun and that > was to exclude gopher sites. I don't know if that was done to allow > the work to proceed technically or to deal with an issue that could > well have been exactly like this. sorry. i think i was unclear in my example. i wasn't saying that GOPHER should be considered part of HTTP, but whether the term "the web" should be considered to include information resources accessible by a web browser or simply all resources accessible by HTTP. as it turns out, browsers from that era dutifully spoke GOPHER as well as HTTP. > I believe our problem only comes when someone not privy to all the > back conversation comes to the charter and misinterprets. I sense a > decent consensus within this group but a lack of proper vocabulary to > express the concepts. From meadhbh.siobhan@gmail.com Sun Aug 30 12:48:46 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560433A68BC for ; Sun, 30 Aug 2009 12:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLGrOSSUnabQ for ; Sun, 30 Aug 2009 12:48:45 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id 7A2FE3A6886 for ; Sun, 30 Aug 2009 12:48:45 -0700 (PDT) Received: by iwn38 with SMTP id 38so1565785iwn.29 for ; Sun, 30 Aug 2009 12:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9yUrhGZ5153wnfZ4OFbLsjSmk/aNEScEH/T55ODeJZs=; b=pN/odkSeIpDDdbKq1Rv1xDs8gVFCi7dPsWJlI42Qg6aWgv8kBw5dk5LENruc+Xj+E8 EWADkbeb2p1h0VVlRCWuGX3Zy+Wc6s5AsYS46a9veq8uSoJ+nnPTPPZ9fHMiSwFTGh+7 lJ5iRcmtOO1FRmdjjDXEbu02//MQx//Xwv+nQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cQuesT/juzXmqvyMLsNG404I3XYGIT9SOC1tW7CRcu7fgTIjrm0cDWuRv2NB+T8nb0 5A58BA8VSIueQ9YbdZNr9DOB0HYKmdjwOYOtRkMvvGIK5WveBvcV3bnFwEn1tJCVlrlX kPfV5JrjmPeLq4UXtr7EQ0aKCx6Qu1NDn79y0= MIME-Version: 1.0 Received: by 10.231.124.164 with SMTP id u36mr5535792ibr.21.1251661732136; Sun, 30 Aug 2009 12:48:52 -0700 (PDT) In-Reply-To: <382d73da0908301158y5276835bt9e68ee91c6dae003@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> <382d73da0908301158y5276835bt9e68ee91c6dae003@mail.gmail.com> Date: Sun, 30 Aug 2009 12:48:52 -0700 Message-ID: From: Meadhbh Siobhan To: Kari Lippert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 19:48:46 -0000 OGPX/VWRAP is an effort to define interoperability between systems that implement a virtual world that share a list of common features. these features can be found in the "intro and requirements" document. MMOX was a previous effort to address address interoperability between "virtual worlds." A mailing list exists for MMOX, but currently seems unreachable. It was considered a failure by some because after two months of discussion and a face to face meeting, we were unable to agree even on the definition of the term "interoperability." At the MMOX BoF, we could not reach consensus, but rather than abandoning the effort, a recommendation was made to constrain the scope of the effort to "second life-like" worlds. This was the focus of the OGP interoperability work over the last two years and serves as the basis for the OGPX/VWRAP effort. On Sun, Aug 30, 2009 at 11:58 AM, Kari Lippert wrot= e: > On Sun, Aug 30, 2009 at 2:50 PM, Meadhbh > Siobhan wrote: >> On Sun, Aug 30, 2009 at 11:20 AM, Kari Lippert w= rote: >>> The network/internet analogy is great. I vote base hit.... and would >>> like to emphasize that, given current usage of the words, the answer >>> to >>> >>>> =A0 =A0 Are we connecting two virtual worlds or is the result a single >>>> =A0 =A0 virtual world? >>> >>> is yes, sort of. >>> >>> As I understand it, VWRAP is designed to connect/allow >>> interoperability between two or more independent/distinct/individual >>> virtual environments/regions/worlds into what appears to the user as a >>> single environment/region/world/universe. This single >>> environment/region/world/universe is in fact multiple >>> independent/distinct/individual virtual environments/regions/worlds >>> whose boundaries could be administrative or technological but the >>> distinction matters not. >>> >>> Is that right? >>> >>> Kari >>> >> >> this is an interesting use case, but not what OGPX/VWRAP was proposed >> to address. >> >> MMOX remains as a venue for the discussion of integrating technically >> diverse virtual worlds. >> >> > > So OGPX/VWRAP is being proposed to address the problem of the > integration of non-technically diverse virtual worlds all implementing > the same protocol? > > Perhaps I should interact with the MMOX group. Since I thought I was, > can you point me in their direction? Thanks! > > Kari > From meadhbh.siobhan@gmail.com Sun Aug 30 12:54:40 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962903A6C08 for ; Sun, 30 Aug 2009 12:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5xMTOt3nYfj for ; Sun, 30 Aug 2009 12:54:40 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id 28D723A68BA for ; Sun, 30 Aug 2009 12:54:35 -0700 (PDT) Received: by iwn38 with SMTP id 38so1566963iwn.29 for ; Sun, 30 Aug 2009 12:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kLYRAu+Xf9t1Q2Az4KGYpGjf/bhALKuqsMHIWGVbPzo=; b=eSAMcprUsR29HTpjHUqlU5j5HlHn6o4G+ZqOJEfKMfrpoPuLgT6r+yNGQ/YSTUkRfX /ZQQ8NroB0ej5y1IvnWLQHRFEp1/q7ActyJs+wqhJ0g+hjsDg45V6YYxyk9k2YpT7DUA TJA78ArxiyIxK01MzGxn0JZZU94OOh0s8qxcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IfTtIiJiLb9EpSQ8X9s+CW/iZz6rEh+wb0IFaIdymFPpGrsSqhwJmm4r0u5ywTEnep R2CS8aVzjF6uZyXY1gjQRgYbIRXakIwfsxY5+X+x1eTCuACD9fI5UmH07QGcUG993Ia5 OgWkovpPN9TSgA0Ec4Udl2BaisI7lAlcLVi2Q= MIME-Version: 1.0 Received: by 10.231.124.227 with SMTP id v35mr5561085ibr.18.1251662081882; Sun, 30 Aug 2009 12:54:41 -0700 (PDT) In-Reply-To: <9abf48a60908301209g6ef6ae14ndd380593b4ddf0cb@mail.gmail.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD6FE8098411@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0908281259h3a10cd02mc92eb8331c92f162@mail.gmail.com> <20090829232125.GC22756@alinoe.com> <6c9fcc2a0908300553x57c76279p9a95c105f0e7e34a@mail.gmail.com> <20090830130045.GA29271@alinoe.com> <9abf48a60908301209g6ef6ae14ndd380593b4ddf0cb@mail.gmail.com> Date: Sun, 30 Aug 2009 12:54:41 -0700 Message-ID: From: Meadhbh Siobhan To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Cc: ogpx@ietf.org Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 19:54:40 -0000 thank goodness it was me misunderstanding this. On Sun, Aug 30, 2009 at 12:09 PM, Barry Leiba wrote: >> what version of the draft are you looking at? the most recent version >> uses "protocol" almost exclusively (using "protocols" only in one spot >> near the initialism OGPX.) > > Carlo meant that the draft charter correctly has an "s" in "worlds" > (not in "protocols"). > > Barry > From kari.lippert@gmail.com Sun Aug 30 13:09:04 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F1828C13E for ; Sun, 30 Aug 2009 13:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjXXHIOxWZwP for ; Sun, 30 Aug 2009 13:09:04 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id E247728C103 for ; Sun, 30 Aug 2009 13:09:03 -0700 (PDT) Received: by ewy3 with SMTP id 3so3300ewy.42 for ; Sun, 30 Aug 2009 13:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=8xb/rhJ22T/yV/EwCSi4eaCpwqkb7oOqC1lEIjT0uJk=; b=jZj+Fv5HZXewRcw/9xS/nQ2M5s8ZIOLltiHqiW0u64Q6evvQRfh7yPk1ijQu/M+VJY NUtM82+Xm0rKfGYKLPxL6oxPPwBjeLAGYgT0KFfmXcv1KpSDcgB3E0PHhHrWnw9Gau9L QVbQxSPgvZeYEiPJpXJ7IkWgAMiMJVzVtuPjQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=g7X2rE9iToRNXTwZs1XBVdx4DLUok9+/m6jv3kah112fQvawHZ/5YPpgBCv3RolyCk GzFAx9TqT8FeFh14pfOXuiAa3C1FmRVDHQsNul7uG3yoIFcLXqQlhTX21/4C6sD+hXIY fxBpWq/ZOxT0fvaNQ1YTXb47BdRWSOvLa3ukA= MIME-Version: 1.0 Received: by 10.216.87.77 with SMTP id x55mr894390wee.85.1251662949646; Sun, 30 Aug 2009 13:09:09 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> <382d73da0908301158y5276835bt9e68ee91c6dae003@mail.gmail.com> Date: Sun, 30 Aug 2009 16:09:09 -0400 Message-ID: <382d73da0908301309s23e6636fqb59bd75f3e1d5c1b@mail.gmail.com> From: Kari Lippert To: Meadhbh Siobhan , ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 20:09:05 -0000 > OGPX/VWRAP is an effort to define interoperability between systems > that implement a virtual world that share a list of common features. > these features can be found in the "intro and requirements" document. Super! I think this - perhaps substituting "place" for "world" - is a very good description of the focus of the group. > It was considered a failure by some because after two > months of discussion and a face to face meeting, we were unable to > agree even on the definition of the term "interoperability." Sad (but I had to laugh as the terms we all know so well are the hardest to reach consensus on!). > but rather than abandoning the > effort, a recommendation was made to constrain the scope of the effort > to "second life-like" worlds. This was the focus of the OGP > interoperability work over the last two years and serves as the basis > for the OGPX/VWRAP effort. > Hmmm... and what does one mean by "second life-like worlds"? User content supporting frameworks? Or the physical computing fabric beneath? (This question is driven more by curiosity than anything as it sounds like there is general agreement to restrict the current work to this more manageable subset of the problem space.) Kari From carlo@alinoe.com Sun Aug 30 13:42:39 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DAC828C146 for ; Sun, 30 Aug 2009 13:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeBKKKBI+TeX for ; Sun, 30 Aug 2009 13:42:38 -0700 (PDT) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id 66BF93A6A84 for ; Sun, 30 Aug 2009 13:42:38 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep17-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090830204244.YLHQ15272.viefep17-int.chello.at@edge04.upc.biz>; Sun, 30 Aug 2009 22:42:44 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id akij1c00a0FlQed04kikx2; Sun, 30 Aug 2009 22:42:44 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MhrFl-0004mI-3I; Sun, 30 Aug 2009 22:43:57 +0200 Date: Sun, 30 Aug 2009 22:43:57 +0200 From: Carlo Wood To: Meadhbh Siobhan Message-ID: <20090830204357.GA25320@alinoe.com> References: <3a880e2c0908211129l7d9defa5od81261e3e5805714@mail.gmail.com> <479011.65903.qm@web111210.mail.gq1.yahoo.com> <4646639E08F58B42836FAC24C94624DD6FE8098411@GVW0433EXB.americas.hpqcorp.net> <3a880e2c0908281259h3a10cd02mc92eb8331c92f162@mail.gmail.com> <20090829232125.GC22756@alinoe.com> <6c9fcc2a0908300553x57c76279p9a95c105f0e7e34a@mail.gmail.com> <20090830130045.GA29271@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: barryleiba@computer.org, ogpx@ietf.org Subject: Re: [ogpx] resolving the name issue X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 20:42:39 -0000 I meant Worlds is already done correctly On Sun, Aug 30, 2009 at 11:54:25AM -0700, Meadhbh Siobhan wrote: > what version of the draft are you looking at? the most recent version > uses "protocol" almost exclusively (using "protocols" only in one spot > near the initialism OGPX.) > > i'm not saying this to argue for or against the use of "protocol" over > "protocols," only to point out that we might be looking at different > revisions of the draft charter. > > On Sun, Aug 30, 2009 at 6:00 AM, Carlo Wood wrote: > > On Sun, Aug 30, 2009 at 08:53:58AM -0400, Barry Leiba wrote: > >> As I read things, it should stand for Virtual World Region/Agent > >> Protocols (note the final "s"), giving the name the flexibility to > >> cover multiple related protocols (one of which could certainly be > >> called "VWRAP" as well, and would, in that case, have no "s". > > > > Virtual Worlds Region/Agent Protocol(s) > > > > no opinion yet on the s behind Protocol, but there should be > > an 's' behind Worlds. > > > > This is already done correctly in the draft. > > > > -- > > Carlo Wood > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > -- Carlo Wood From meadhbh.siobhan@gmail.com Sun Aug 30 15:00:33 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84DE3A6C4F for ; Sun, 30 Aug 2009 15:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTRuuobJv-zF for ; Sun, 30 Aug 2009 15:00:33 -0700 (PDT) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by core3.amsl.com (Postfix) with ESMTP id DC1403A6B2A for ; Sun, 30 Aug 2009 15:00:32 -0700 (PDT) Received: by iwn38 with SMTP id 38so1593977iwn.29 for ; Sun, 30 Aug 2009 15:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hgH4YYz+9oFuFJuZ7uV9HhNpS9f3Fmg3tFAn0Kv8y1E=; b=cU8KG6h0NLTgC78SW1N8vg3/agqDagnzoodvZkkdCiNK7MVVBl4mjis/mmY3Zv4uIe YxVUvQB8Zrv7WQikIVweKeOlKh/bpN/IQqWYm4ldtJfThhNZW/2YAcK6lz0gD3ap1wYj l0/xMXXbfgPuDwOD7VkthL5c/wBCy1q4CR1SU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CLelnmiMDTZNEkMNAbRDQjYawUpu187Wt5pFSu5HIF7hsoNPihQqjXsCqViL04rMjn FrH7SqC273LqHU/qw+aFZCl/qRxArhB7iLWlkA8xDZo29wTSlEJi+6LS/DHz0mtAIaOl wFpHY7jSWoZAAMd2YZn5eho7L7u6yezgkdeAs= MIME-Version: 1.0 Received: by 10.231.124.22 with SMTP id s22mr5746132ibr.33.1251669639586; Sun, 30 Aug 2009 15:00:39 -0700 (PDT) In-Reply-To: <382d73da0908301309s23e6636fqb59bd75f3e1d5c1b@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> <382d73da0908301158y5276835bt9e68ee91c6dae003@mail.gmail.com> <382d73da0908301309s23e6636fqb59bd75f3e1d5c1b@mail.gmail.com> Date: Sun, 30 Aug 2009 15:00:39 -0700 Message-ID: From: Meadhbh Siobhan To: Kari Lippert Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 22:00:33 -0000 On Sun, Aug 30, 2009 at 1:09 PM, Kari Lippert wrote= : > > Hmmm... and what does one mean by "second life-like worlds"? User > content supporting frameworks? Or the physical computing fabric > beneath? (This question is driven more by curiosity than anything as > it sounds like there is general agreement to restrict the current work > to this more manageable subset of the problem space.) and i forgot to mention... the definition of "second life-like" worlds is also in the intro definition, which i repeat here: =95 The Virtual World exists independent of the participating clients. =95 Avatars have a single, unique presence in the virtual world. =95 The virtual world contains persistent objects. =95 The virtual world may be partitioned. =95 Presence, state and simulation is managed on authoritative servers. =95 Version skew between simulation hosts be tolerable. =95 The protocol to access the state of hosts participating in the virtual world simulation uses Representational State Transfer (REST) style interaction over HTTP. =95 A persistent, ubiquitous identity accompanies requests between hosts involved in the virtual world simulation. From carlo@alinoe.com Sun Aug 30 16:07:14 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5749A3A6D50 for ; Sun, 30 Aug 2009 16:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qgxQA2YoY9W for ; Sun, 30 Aug 2009 16:07:13 -0700 (PDT) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id EBD813A6835 for ; Sun, 30 Aug 2009 16:07:12 -0700 (PDT) Received: from edge01.upc.biz ([192.168.13.236]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090830230720.QVHT793.viefep11-int.chello.at@edge01.upc.biz>; Mon, 31 Aug 2009 01:07:20 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id an7J1c02n0FlQed01n7KAm; Mon, 31 Aug 2009 01:07:20 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MhtVg-0007AW-Nk; Mon, 31 Aug 2009 01:08:32 +0200 Date: Mon, 31 Aug 2009 01:08:32 +0200 From: Carlo Wood To: Meadhbh Siobhan Message-ID: <20090830230832.GB25364@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <4A9A8F7D.6070501@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Infinity Linden , ogpx@ietf.org, dcrocker@bbiw.net Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 23:07:14 -0000 I think that any effort to work on the final wording should be stopped until we finally agree on what "virtual world" means... I understand that you don't want to define what virtual world means, in which case you shouldn't use it at all in the charter and also not in the protocol name (VWrap). There are several levels of 'locations' in an SL-like whatever: First, the words that are already in use by the community: 1) simulator 2) estate 3) region 4) land 5) island 6) virtual world Then the locations that we need terms for to be able to even TALK about them: A) A smallest partition B) A collection of adjacent A's run by a single administration C) A collection of adjecent B's run by different administrations (which very likely use the same TOS etc) D) A collection of C's that are not adjacent but still fall under the same TOS etc. E) A collection of D's that have totally different administrations and possibly different TOS etc, but which interoperate. F) The whole of all E's that do not interoperate, but still use VWRAP. G) The rest that use the term "virtual world", but do not use VWRAP. MMOX and WoW is part of G. I consider that not relevant as it should be clear by now what is part of G and what not. Meadhbh, do you disagree with my list(s)? Anything you want to add, or change my rough definitions of things? Please don't reply with "we don't want to define this" :p We NEED to define this, or we can't TALK about this! -- Carlo Wood PS I hope it should be clear by now: the problem we are having is that you call 'E' "a virtual world", while Morgaine, Kari, me and others want to call 'D' "virtual world". Moreover, you do as if D or E do not exist, so that we will not be able to talk about them separately later on :/ You might convince me to call 'E' "virtual world", but then we need a well defined term for 'D' in order to communicate about D, too. In my previous post I proposed to use "Galaxy" for E. From carlo@alinoe.com Sun Aug 30 16:24:30 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE83B3A6D50 for ; Sun, 30 Aug 2009 16:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41PAkNHHK9hp for ; Sun, 30 Aug 2009 16:24:30 -0700 (PDT) Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id 2148A3A6C1E for ; Sun, 30 Aug 2009 16:22:55 -0700 (PDT) Received: from edge03.upc.biz ([192.168.13.238]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090830232304.SMJR9540.viefep16-int.chello.at@edge03.upc.biz>; Mon, 31 Aug 2009 01:23:04 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upc.biz with edge id anP21c00U0FlQed03nP3Wb; Mon, 31 Aug 2009 01:23:04 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mhtku-0007OH-Df; Mon, 31 Aug 2009 01:24:16 +0200 Date: Mon, 31 Aug 2009 01:24:16 +0200 From: Carlo Wood To: Meadhbh Siobhan Message-ID: <20090830232416.GC25364@alinoe.com> References: <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> <382d73da0908301158y5276835bt9e68ee91c6dae003@mail.gmail.com> <382d73da0908301309s23e6636fqb59bd75f3e1d5c1b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 23:24:30 -0000 On Sun, Aug 30, 2009 at 03:00:39PM -0700, Meadhbh Siobhan wrote: > • The Virtual World exists independent of the participating clients. > • Avatars have a single, unique presence in the virtual world. > • The virtual world contains persistent objects. > • The virtual world may be partitioned. > • Presence, state and simulation is managed on authoritative servers. > • Version skew between simulation hosts be tolerable. > • The protocol to access the state of hosts participating in the > virtual world simulation uses Representational State Transfer (REST) > style interaction over HTTP. > • A persistent, ubiquitous identity accompanies requests between hosts > involved in the virtual world simulation. Since there is no consensus about the meaning of "virtual world", this list is pretty meaningless. Imho, you mean to say that • Each 'E' exists independent of the participating clients. • Avatars have a single, unique presence in a given 'D'. • Each 'C' contains persistent objects. • Each 'C' may be partitioned. • Presence, state and simulation is managed on authoritative servers. • Version skew between 'A' hosts be tolerable. • The protocol to access the state of hosts participating in 'A' simulation uses Representational State Transfer (REST) style interaction over HTTP. • A persistent, ubiquitous identity accompanies requests between hosts involved in the 'E' simulation. Where I defined 'A', 'C', 'D' and 'E' in my previous post. -- Carlo Wood From cfk@pacbell.net Sun Aug 30 18:19:37 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60F43A6D40 for ; Sun, 30 Aug 2009 18:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijf553y4KJsP for ; Sun, 30 Aug 2009 18:19:36 -0700 (PDT) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id EF11E3A6C93 for ; Sun, 30 Aug 2009 18:19:35 -0700 (PDT) Received: (qmail 27846 invoked by uid 60001); 31 Aug 2009 01:19:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pacbell.net; s=s1024; t=1251681582; bh=m2Ufv4Wf5yrUahjaSt1Rr5dKtIPMaAwWuYGMWy2zS/E=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=4hV4c7FkA18RYYGjkoxZLmJCiFu/93ZwiBfZ849tW+4fnrwYKfT2Ah5YOFAYtjYxYmdX6oONWhqYuMFLASmoKk2uA/w/uvtYief7VmNvQ809IJo6ot7ZbjB+jiQGUDb/O0YrD2/K59fl8IejR9xkR9rU1iB9Q6GHAmVJUwNMbk0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2Cw558F+KkuKZyLlHH+gfKRnhSaLYR26eq4Kho/8DFkA1Ns8q2MyVeI1qb7QbLNs91D6QR9gU/fFCoWQhtQb5h8zRxT3RKTc+vnrLFKwBlAUf/Mtta2HJXUvca8UcdqKDyAqJ+Zo5Yr+ZoqU/qqLQbL0ygp+KhHp9RYtIDKXtTg=; Message-ID: <204765.27116.qm@web82605.mail.mud.yahoo.com> X-YMail-OSG: _0EdqfsVM1kcYs16HuY6iZrldJCzRLtXrpGZprAbqpmeCAZzJIxhdY47WKsJ8qr4BtzyLljTvgUXqSFFZPOgc_h9M25oSj39S18VhTMnV1Lp4y1eJ9hF1NbIm8PMo9dIfw7JDH5funDr2oJQzC4uJJ8bVAG.unorMHA8STZ51QOV3lbT3nZOcDVRGUos1urXKtJDzQxMdjE6l3NodXLPWnJq_.0qc2jhsuDfqYC56L_0QfsFl_fakm7.P0rrmDJy4OYqzeoQVI3w8MyzTQkDpwel70l_wh7k_WxtvaRrn2fEg67BMEe0_7Ln8jP8kQDD83AgDXM.PkpO24HHnFksk9_WBR9JsCnhbKf6G2UuP9XptNoGed3m1WL2n.BWthRmQnU- Received: from [67.120.11.69] by web82605.mail.mud.yahoo.com via HTTP; Sun, 30 Aug 2009 18:19:42 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> Date: Sun, 30 Aug 2009 18:19:42 -0700 (PDT) From: Charles Krinke To: ogpx@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2022138522-1251681582=:27116" Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 01:19:38 -0000 --0-2022138522-1251681582=:27116 Content-Type: text/plain; charset=us-ascii I'm confused with all that is going on and need to ask my two main questions again. "Are we considering interop with virtual worlds running OpenSim which do not run agent domains but rather a similar, but not quite identical notion we call UGAIM (User, Grid, Asset, Inventory, Messaging) servers?" "Are we considering a full handoff? That is, a user on an OpenSim grid may teleport to a SecondLife grid and retain its connection to the OpenSim UGAIM, in an analogous fashion that a user has been demonstrated to teleport from the Betagrid to OSGrid using OGP last year?" Charles ________________________________ From: Meadhbh Siobhan To: Kari Lippert Cc: ogpx@ietf.org; dcrocker@bbiw.net Sent: Sunday, August 30, 2009 11:50:46 AM Subject: Re: [ogpx] one virtual world, or many? On Sun, Aug 30, 2009 at 11:20 AM, Kari Lippert wrote: > The network/internet analogy is great. I vote base hit.... and would > like to emphasize that, given current usage of the words, the answer > to > >> Are we connecting two virtual worlds or is the result a single >> virtual world? > > is yes, sort of. > > As I understand it, VWRAP is designed to connect/allow > interoperability between two or more independent/distinct/individual > virtual environments/regions/worlds into what appears to the user as a > single environment/region/world/universe. This single > environment/region/world/universe is in fact multiple > independent/distinct/individual virtual environments/regions/worlds > whose boundaries could be administrative or technological but the > distinction matters not. > > Is that right? > > Kari > this is an interesting use case, but not what OGPX/VWRAP was proposed to address. MMOX remains as a venue for the discussion of integrating technically diverse virtual worlds. > > > > > > On Sun, Aug 30, 2009 at 11:40 AM, Dave CROCKER wrote: >> Folks, >> >> >> Pre-game. >> >> Confusion and disagreement that includes the term "virtual world" is proving >> tenacious, in spite of extensive and substantive discussion. Typically, >> something this persistent means either that some concept(s) lack shared >> definition or that competing technical paradigms are present. >> >> As was noted many message ago, there's a good chance that much of the >> disagreement is really about the meaning of the term. That is, that >> apparent >> disagreements about such things as scope of work is really about scope of >> this one term. That, at least, is my own reading of the discussions. I >> think people are using the term differently. If we can get to the point of >> using it the same >> way, my sense is that we will find that disagreements about actual work to >> be done, and its use, are rather small. >> >> In other words, I think the persistence of debate that keeps using that term >> "virtual world" means we have to resolve it before we can make serious >> progress. These sorts of things never seem to go away without explicit >> resolution. While much of the earlier attempts to resolve this look like >> they helped quite a bit, it seems clear that a bit more effort is needed. >> >> >> >> The wind-up. >> >> Since the crux of the challenge keeps coming back to what interoperability >> will >> or will not be provided -- with at least one additional point about whether >> the >> current work must be used internal to a service or only used /between/ >> services >> -- permit me a moment of theft from Internet history and constructs. I >> think it >> can be applicable here: >> >> Network vs. Internetwork. >> >> "A" virtual world vs. Multiple virtual worlds. >> >> But hold on. I'm not necessarily going to suggest mapping the two sets as >> one-to-one directly... >> >> Originally, a network was a discrete technical set. X.25. NCP. XNS. >> Netware. >> Whatever. Both technology and administration had the same boundary. Your >> network might use one technology and mine might use another. But even if >> they >> used the same technology, one was mine and the other was yours. So I tend >> to >> view interaction across administrative boundaries as far more interesting to >> internetworking than whether different technologies are used: >> >> >> >> The term Internet has come to mean a single, unified, global service. It >> crosses administrative boundaries. Does IBM internally operate a 'network' >> or >> an 'internetwork'? Either choice is reasonable, depending on what is the >> focus. I think we don't need to resolve the equivalent question here. >> >> There is universal agreement that there is a single global service, >> comprising many independent smaller services, and that that single, larger >> thing is "The" Internet. >> >> What we tend to forget is that there probably are other Internets that don't >> (directly) interoperate with the global one. They are off "The Internet" >> grid >> and are on their own. They are likely also "an" Internet. These days, they >> might be running TCP/IP, but they don't have to. For example: >> >> >> >> Some uses of "virtual world" appear to mean an administrative boundary and >> others appear to mean a technical boundary. This is the sort of thing we >> need to resolve. >> >> >> >> The pitch. >> >> I suggest ignoring technical differences within an administrative domain and >> even across different administrative domains. Simply, VWrap is used to >> connect together administrative domains running simulations. >> >> I'm running one simulation and you are running another. We use >> VWrap to interoperate. >> >> Are we connecting two virtual worlds or is the result a single >> virtual world? >> >> Some other folk might not interoperate with our unified service. They are >> running their own thing. Are they running a different virtual world or, >> perhaps, a different set of multiple virtual worlds? >> >> >> >> The swing. >> >> I suggest that: >> >> Any set of independent administrative domains that interoperate >> together, using VWrap, creates a /single/ virtual world. >> >> Each independent administrative domain is running /part/ of that single >> virtual world. (The part might be one Region, or Agent, or it might be >> many of both or any combination.) >> >> Hence, I am suggesting that an integrated VWrap environment has a >> comparable quality to an integrated internet environment that we call >> "The" Internet. One service. >> >> If you are running a simulation that is not part of an integrated, >> interoperable >> VWrap environment, you are in a different virtual world. >> >> If you are part of an interoperable VWrap service, you are in a >> single virtual world. >> >> It doesn't matter what you run internally. What matters is integration to >> the >> interoperable service using VWrap. >> >> >> >> Base hit or strikeout? >> >> d/ >> -- >> >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --0-2022138522-1251681582=:27116 Content-Type: text/html; charset=us-ascii
I'm confused with all that is going on and need to ask my two main questions again.

"Are we considering interop with virtual worlds running OpenSim which do not run agent domains but rather a similar, but not quite identical notion we call UGAIM (User, Grid, Asset, Inventory, Messaging) servers?"

"Are we considering a full handoff? That is, a user on an OpenSim grid may teleport to a SecondLife grid and retain its connection to the OpenSim UGAIM, in an analogous fashion that a user has been demonstrated to teleport from the Betagrid to OSGrid using OGP last year?"

Charles

From: Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
To: Kari Lippert <kari.lippert@gmail.com>
Cc: ogpx@ietf.org; dcrocker@bbiw.net
Sent: Sunday, August 30, 2009 11:50:46 AM
Subject: Re: [ogpx] one virtual world, or many?

On Sun, Aug 30, 2009 at 11:20 AM, Kari Lippert<kari.lippert@gmail.com> wrote:
> The network/internet analogy is great. I vote base hit.... and would
> like to emphasize that, given current usage of the words, the answer
> to
>
>>     Are we connecting two virtual worlds or is the result a single
>>     virtual world?
>
> is yes, sort of.
>
> As I understand it, VWRAP is designed to connect/allow
> interoperability between two or more independent/distinct/individual
> virtual environments/regions/worlds into what appears to the user as a
> single environment/region/world/universe. This single
> environment/region/world/universe is in fact multiple
> independent/distinct/individual virtual environments/regions/worlds
> whose boundaries could be administrative or technological but the
> distinction matters not.
>
> Is that right?
>
> Kari
>

this is an interesting use case, but not what OGPX/VWRAP was proposed
to address.

MMOX remains as a venue for the discussion of integrating technically
diverse virtual worlds.


>
>
>
>
>
> On Sun, Aug 30, 2009 at 11:40 AM, Dave CROCKER<dhc@dcrocker.net> wrote:
>> Folks,
>>
>>
>> Pre-game.
>>
>> Confusion and disagreement that includes the term "virtual world" is proving
>> tenacious, in spite of extensive and substantive discussion.  Typically,
>> something this persistent means either that some concept(s) lack shared
>> definition or that competing technical paradigms are present.
>>
>> As was noted many message ago, there's a good chance that much of the
>> disagreement is really about the meaning of the term.  That is, that
>> apparent
>> disagreements about such things as scope of work is really about scope of
>> this one term.  That, at least, is my own reading of the discussions.  I
>> think people are using the term differently.  If we can get to the point of
>> using it the same
>> way, my sense is that we will find that disagreements about actual work to
>> be done, and its use, are rather small.
>>
>> In other words, I think the persistence of debate that keeps using that term
>> "virtual world" means we have to resolve it before we can make serious
>> progress. These sorts of things never seem to go away without explicit
>> resolution.  While much of the earlier attempts to resolve this look like
>> they helped quite a bit, it seems clear that a bit more effort is needed.
>>
>>
>>
>> The wind-up.
>>
>> Since the crux of the challenge keeps coming back to what interoperability
>> will
>> or will not be provided -- with at least one additional point about whether
>> the
>> current work must be used internal to a service or only used /between/
>> services
>> -- permit me a moment of theft from Internet history and constructs.  I
>> think it
>> can be applicable here:
>>
>>   Network vs. Internetwork.
>>
>>   "A" virtual world vs. Multiple virtual worlds.
>>
>> But hold on.  I'm not necessarily going to suggest mapping the two sets as
>> one-to-one directly...
>>
>> Originally, a network was a discrete technical set.  X.25.  NCP.  XNS.
>> Netware.
>> Whatever.  Both technology and administration had the same boundary.  Your
>> network might use one technology and mine might use another.  But even if
>> they
>> used the same technology, one was mine and the other was yours.  So I tend
>> to
>> view interaction across administrative boundaries as far more interesting to
>> internetworking than whether different technologies are used:
>>
>>   <http://www.faqs.org/rfcs/rfc1775.html>
>>
>> The term Internet has come to mean a single, unified, global service.  It
>> crosses administrative boundaries.  Does IBM internally operate a 'network'
>> or
>> an 'internetwork'?  Either choice is reasonable, depending on what is the
>> focus. I think we don't need to resolve the equivalent question here.
>>
>> There is universal agreement that there is a single global service,
>> comprising many independent smaller services, and that that single, larger
>> thing is "The" Internet.
>>
>> What we tend to forget is that there probably are other Internets that don't
>> (directly) interoperate with the global one.  They are off "The Internet"
>> grid
>> and are on their own.  They are likely also "an" Internet.  These days, they
>> might be running TCP/IP, but they don't have to.  For example:
>>
>>   <http://www.dtnrg.org/wiki>
>>
>> Some uses of "virtual world" appear to mean an administrative boundary and
>> others appear to mean a technical boundary. This is the sort of thing we
>> need to resolve.
>>
>>
>>
>> The pitch.
>>
>> I suggest ignoring technical differences within an administrative domain and
>> even across different administrative domains.  Simply, VWrap is used to
>> connect together administrative domains running simulations.
>>
>>     I'm running one simulation and you are running another.  We use
>>     VWrap to interoperate.
>>
>>     Are we connecting two virtual worlds or is the result a single
>>     virtual world?
>>
>> Some other folk might not interoperate with our unified service.  They are
>> running their own thing.  Are they running a different virtual world or,
>> perhaps, a different set of multiple virtual worlds?
>>
>>
>>
>> The swing.
>>
>> I suggest that:
>>
>>     Any set of independent administrative domains that interoperate
>>     together, using VWrap, creates a /single/ virtual world.
>>
>>     Each independent administrative domain is running /part/ of that single
>>     virtual world.  (The part might be one Region, or Agent, or it might be
>>     many of both or any combination.)
>>
>>     Hence, I am suggesting that an integrated VWrap environment has a
>>     comparable quality to an integrated internet environment that we call
>>     "The" Internet.  One service.
>>
>> If you are running a simulation that is not part of an integrated,
>> interoperable
>> VWrap environment, you are in a different virtual world.
>>
>>     If you are part of an interoperable VWrap service, you are in a
>>     single virtual world.
>>
>> It doesn't matter what you run internally.  What matters is integration to
>> the
>> interoperable service using VWrap.
>>
>>
>>
>> Base hit or strikeout?
>>
>> d/
>> --
>>
>>  Dave Crocker
>>  Brandenburg InternetWorking
>>  bbiw.net
>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--0-2022138522-1251681582=:27116-- From morgaine.dinova@googlemail.com Sun Aug 30 21:27:03 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD2228C17A for ; Sun, 30 Aug 2009 21:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.568 X-Spam-Level: X-Spam-Status: No, score=-0.568 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqeQEfjNxZ9z for ; Sun, 30 Aug 2009 21:27:02 -0700 (PDT) Received: from mail-ew0-f225.google.com (mail-ew0-f225.google.com [209.85.219.225]) by core3.amsl.com (Postfix) with ESMTP id 98DA03A6B92 for ; Sun, 30 Aug 2009 21:27:01 -0700 (PDT) Received: by ewy25 with SMTP id 25so3788067ewy.9 for ; Sun, 30 Aug 2009 21:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=vMLOm0bX6b3kqTAZhKSO/TjVSZIm24WJigSpirqrh+Y=; b=lhJ1PdTykXM3qKX3sJHI0NNE6sWhmBQhH4+jjx0kBWtJq1ZiN3/rNZ8zfabY+DW/19 9VCfKEk9tp8eRTg+R+QPFrvdqDFsPDIE66BWhWsnL7AKD95c1XFEwGUR8bEhe89GO5Gz 5vE5ypJ5jaBNrM+7TMEeRl8vhZs0eur84NE+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=yEzofkawFRhN3Q7uiG48pQ6DAvcaS2keXRK4AJfYLtFwA5aRr7RIPzPvf5mfZ2HYqy Nrq2fKMu+3ZEXxYJTmmE3ZArjzw9V9NDYGKvel6HUPzqJR9WE+DHjgt5/n5CYwUEdJy0 10QRbqC/0ArYcM8A71khSvjwlP6/ZPkNUA0SI= MIME-Version: 1.0 Received: by 10.211.132.36 with SMTP id j36mr4738666ebn.51.1251692825971; Sun, 30 Aug 2009 21:27:05 -0700 (PDT) In-Reply-To: <20090830230832.GB25364@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <4A9A8F7D.6070501@dcrocker.net> <20090830230832.GB25364@alinoe.com> Date: Mon, 31 Aug 2009 05:27:05 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636b2ad56428c120472687267 Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 04:27:03 -0000 --001636b2ad56428c120472687267 Content-Type: text/plain; charset=ISO-8859-1 I support Carlo's request that we define the terms that we use before we use them. As Carlo's says, undefined terms should not be used in the charter or in the group name --- it introduces uncertainty and confusion. I would add that *even less* should undefined terms appear in our protocol specifications, which are relatively precise documents of interest to implementors. If we don't know what a virtual world is, the term should be abandoned in favour of one that we do understand. Carlo offers one way of defining the topological entities in our problem space, based on size and administration, which sounds quite viable. A meaning of virtual world might be agreed in this way. As an alternative, I propose a simpler and much more flexible approach: define virtual worlds as anything that implements the required endpoints of the VWRAP protocol. We do not need to know anything else about them. This lets the people who actually design the virtual worlds decide what constitutes a virtual world. The only thing that interests us is that these "virtual worlds" implement the VWRAP endpoints. This is highly workable in practice. After all, Linden Lab knows that SL is a virtual world, they don't need it defined. Likewise, the owners of OSgrid know that OSgrid is a virtual world too, they don't need it defined. As a result, a definition of "virtual world" by an IETF workgroup will have little practical effect outside of the specifications, because the implementors will design their worlds as it suits them. If they are to interoperate through VWRAP however, then both LL and OSgrid will ensure that they implement the protocol correctly, no matter their internal differences. Note that this is the approach taken in a large number of IETF protocols: the implementation behind the endpoint is just an *implementation detail*, and is of no consequence as long as it implements the protocol correctly. Precedent suggests that this is the right approach. I believe that this is simpler, more powerful, and much more flexible than defining "virtual world" on the basis of topology. All we need to know is that VWRAP endpoints are available, and not what kind of entity actually implements them. Morgaine. =================================== On Mon, Aug 31, 2009 at 12:08 AM, Carlo Wood wrote: > I think that any effort to work on the final wording > should be stopped until we finally agree on what "virtual world" means... > > I understand that you don't want to define what virtual world means, > in which case you shouldn't use it at all in the charter and also > not in the protocol name (VWrap). > > There are several levels of 'locations' in an SL-like whatever: > > First, the words that are already in use by the community: > > 1) simulator > 2) estate > 3) region > 4) land > 5) island > 6) virtual world > > Then the locations that we need terms for to be able to even > TALK about them: > > A) A smallest partition > B) A collection of adjacent A's run by a single administration > C) A collection of adjecent B's run by different administrations (which > very likely use the same TOS etc) > D) A collection of C's that are not adjacent but still fall under the same > TOS etc. > E) A collection of D's that have totally different administrations and > possibly different TOS etc, but which interoperate. > F) The whole of all E's that do not interoperate, but still use VWRAP. > G) The rest that use the term "virtual world", but do not use VWRAP. > > MMOX and WoW is part of G. I consider that not relevant as it should be > clear by now what is part of G and what not. > > Meadhbh, do you disagree with my list(s)? > Anything you want to add, or change my rough definitions of things? > > Please don't reply with "we don't want to define this" :p > We NEED to define this, or we can't TALK about this! > > -- > Carlo Wood > > PS I hope it should be clear by now: the problem we are having > is that you call 'E' "a virtual world", while Morgaine, Kari, > me and others want to call 'D' "virtual world". Moreover, > you do as if D or E do not exist, so that we will not > be able to talk about them separately later on :/ > > You might convince me to call 'E' "virtual world", but > then we need a well defined term for 'D' in order to > communicate about D, too. > > In my previous post I proposed to use "Galaxy" for E. > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --001636b2ad56428c120472687267 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support Carlo's request that we define the terms that we use before w= e use them.

As Carlo's says, undefined terms should not be used = in the charter or in the group name --- it introduces uncertainty and confu= sion.=A0 I would add that even less should undefined terms ap= pear in our protocol specifications, which are relatively precise documents= of interest to implementors.=A0 If we don't know what a virtual world = is, the term should be abandoned in favour of one that we do understand.
Carlo offers one way of defining the topological entities in our proble= m space, based on size and administration, which sounds quite viable.=A0 A = meaning of virtual world might be agreed in this way.

As an alternat= ive, I propose a simpler and much more flexible approach: define virtual wo= rlds as anything that implements the required endpoints of the VWRAP protoc= ol.=A0 We do not need to know anything else about them.=A0 This lets the pe= ople who actually design the virtual worlds decide what constitutes a virtu= al world.=A0 The only thing that interests us is that these "virtual w= orlds" implement the VWRAP endpoints.

This is highly workable in practice.=A0 After all, Linden Lab knows tha= t SL is a virtual world, they don't need it defined.=A0 Likewise, the o= wners of OSgrid know that OSgrid is a virtual world too, they don't nee= d it defined.=A0 As a result, a definition of "virtual world" by = an IETF workgroup will have little practical effect outside of the specific= ations, because the implementors will design their worlds as it suits them.= =A0 If they are to interoperate through VWRAP however, then both LL and OSg= rid will ensure that they implement the protocol correctly, no matter their= internal differences.

Note that this is the approach taken in a large number of IETF protocol= s:=A0 the implementation behind the endpoint is just an implementation d= etail, and is of no consequence as long as it implements the protocol c= orrectly.=A0 Precedent suggests that this is the right approach.

I believe that this is simpler, more powerful, and much more flexible t= han defining "virtual world" on the basis of topology.=A0 All we = need to know is that VWRAP endpoints are available, and not what kind of en= tity actually implements them.

Morgaine.








=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

On Mon, Aug 31, 2009 at 12:08 AM, = Carlo Wood <carlo@= alinoe.com> wrote:
I think that any = effort to work on the final wording
should be stopped until we finally agree on what "virtual world" = means...

I understand that you don't want to define what virtual world means, in which case you shouldn't use it at all in the charter and also
not in the protocol name (VWrap).

There are several levels of 'locations' in an SL-like whatever:

First, the words that are already in use by the community:

1) simulator
2) estate
3) region
4) land
5) island
6) virtual world

Then the locations that we need terms for to be able to even
TALK about them:

A) A smallest partition
B) A collection of adjacent A's run by a single administration
C) A collection of adjecent B's run by different administrations (which= very likely use the same TOS etc)
D) A collection of C's that are not adjacent but still fall under the s= ame TOS etc.
E) A collection of D's that have totally different administrations and = possibly different TOS etc, but which interoperate.
F) The whole of all E's that do not interoperate, but still use VWRAP.<= br> G) The rest that use the term "virtual world", but do not use VWR= AP.

MMOX and WoW is part of G. I consider that not relevant as it should be
clear by now what is part of G and what not.

Meadhbh, do you disagree with my list(s)?
Anything you want to add, or change my rough definitions of things?

Please don't reply with "we don't want to define this" :p=
We NEED to define this, or we can't TALK about this!

--
Carlo Wood <carlo@alinoe.com>=

PS I hope it should be clear by now: the problem we are having
=A0 is that you call 'E' "a virtual world", while Morgai= ne, Kari,
=A0 me and others want to call 'D' "virtual world". More= over,
=A0 you do as if D or E do not exist, so that we will not
=A0 be able to talk about them separately later on :/

=A0 You might convince me to call 'E' "virtual world", b= ut
=A0 then we need a well defined term for 'D' in order to
=A0 communicate about D, too.

=A0 In my previous post I proposed to use "Galaxy" for E.

_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--001636b2ad56428c120472687267-- From kari.lippert@gmail.com Mon Aug 31 04:52:46 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7C33A6BB8 for ; Mon, 31 Aug 2009 04:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIyH-X6c+lYx for ; Mon, 31 Aug 2009 04:52:45 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id F15153A6BC9 for ; Mon, 31 Aug 2009 04:52:44 -0700 (PDT) Received: by ewy3 with SMTP id 3so446985ewy.42 for ; Mon, 31 Aug 2009 04:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=0C+HfVdfpZhcQm6+Jkmj1Q5PIcEJs4Sk1s2ByjYfxnM=; b=xXAvvMsKiapDik1w0UDjGZj5qlagh9wrot+1R3om4lCZv4O7c1BzWifPlvI4CnviA8 yCnHMzK9Kfp1M/Gh2Y2OxuvAFqt5YYGHMvp4VDbDUDIa97TEzmQ6EHHcD3DCqUVZ+MQ+ 1q3InfxKOey+y5CU/ijAWczBbLpjHNdGXqg+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=S/KdizSGbcTG3Ww+v/PtkrerRU4Qt/sldqzvMkJiFcjbzEf5OCnwHLkquxNlB+3v1w qI7XdprPUeQTEuhwoKhWepXmjQX9z7EeC2eBWR3G22NzZNNhw7z7eAiBhdmtVKOLuGlX mm8DZxb/lbM0c0tPUqlAiIbwvDj4ecYoSZ084= MIME-Version: 1.0 Received: by 10.216.28.66 with SMTP id f44mr1131080wea.28.1251719569838; Mon, 31 Aug 2009 04:52:49 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <4A9A8F7D.6070501@dcrocker.net> <20090830230832.GB25364@alinoe.com> Date: Mon, 31 Aug 2009 07:52:49 -0400 Message-ID: <382d73da0908310452s50afa853qb2950cc26cfa30cb@mail.gmail.com> From: Kari Lippert To: Morgaine , ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 11:52:46 -0000 This sounds like a good plan. Kari On Mon, Aug 31, 2009 at 12:27 AM, Morgaine wrote: > I support Carlo's request that we define the terms that we use before we = use > them. > > As Carlo's says, undefined terms should not be used in the charter or in = the > group name --- it introduces uncertainty and confusion.=A0 I would add th= at > even less should undefined terms appear in our protocol specifications, > which are relatively precise documents of interest to implementors.=A0 If= we > don't know what a virtual world is, the term should be abandoned in favou= r > of one that we do understand. > > Carlo offers one way of defining the topological entities in our problem > space, based on size and administration, which sounds quite viable.=A0 A > meaning of virtual world might be agreed in this way. > > As an alternative, I propose a simpler and much more flexible approach: > define virtual worlds as anything that implements the required endpoints = of > the VWRAP protocol.=A0 We do not need to know anything else about them.= =A0 This > lets the people who actually design the virtual worlds decide what > constitutes a virtual world.=A0 The only thing that interests us is that = these > "virtual worlds" implement the VWRAP endpoints. > > This is highly workable in practice.=A0 After all, Linden Lab knows that = SL is > a virtual world, they don't need it defined.=A0 Likewise, the owners of O= Sgrid > know that OSgrid is a virtual world too, they don't need it defined.=A0 A= s a > result, a definition of "virtual world" by an IETF workgroup will have > little practical effect outside of the specifications, because the > implementors will design their worlds as it suits them.=A0 If they are to > interoperate through VWRAP however, then both LL and OSgrid will ensure t= hat > they implement the protocol correctly, no matter their internal differenc= es. > > Note that this is the approach taken in a large number of IETF protocols: > the implementation behind the endpoint is just an implementation detail, = and > is of no consequence as long as it implements the protocol correctly. > Precedent suggests that this is the right approach. > > I believe that this is simpler, more powerful, and much more flexible tha= n > defining "virtual world" on the basis of topology.=A0 All we need to know= is > that VWRAP endpoints are available, and not what kind of entity actually > implements them. > > Morgaine. > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Mon, Aug 31, 2009 at 12:08 AM, Carlo Wood wrote: >> >> I think that any effort to work on the final wording >> should be stopped until we finally agree on what "virtual world" means..= . >> >> I understand that you don't want to define what virtual world means, >> in which case you shouldn't use it at all in the charter and also >> not in the protocol name (VWrap). >> >> There are several levels of 'locations' in an SL-like whatever: >> >> First, the words that are already in use by the community: >> >> 1) simulator >> 2) estate >> 3) region >> 4) land >> 5) island >> 6) virtual world >> >> Then the locations that we need terms for to be able to even >> TALK about them: >> >> A) A smallest partition >> B) A collection of adjacent A's run by a single administration >> C) A collection of adjecent B's run by different administrations (which >> very likely use the same TOS etc) >> D) A collection of C's that are not adjacent but still fall under the sa= me >> TOS etc. >> E) A collection of D's that have totally different administrations and >> possibly different TOS etc, but which interoperate. >> F) The whole of all E's that do not interoperate, but still use VWRAP. >> G) The rest that use the term "virtual world", but do not use VWRAP. >> >> MMOX and WoW is part of G. I consider that not relevant as it should be >> clear by now what is part of G and what not. >> >> Meadhbh, do you disagree with my list(s)? >> Anything you want to add, or change my rough definitions of things? >> >> Please don't reply with "we don't want to define this" :p >> We NEED to define this, or we can't TALK about this! >> >> -- >> Carlo Wood >> >> PS I hope it should be clear by now: the problem we are having >> =A0 is that you call 'E' "a virtual world", while Morgaine, Kari, >> =A0 me and others want to call 'D' "virtual world". Moreover, >> =A0 you do as if D or E do not exist, so that we will not >> =A0 be able to talk about them separately later on :/ >> >> =A0 You might convince me to call 'E' "virtual world", but >> =A0 then we need a well defined term for 'D' in order to >> =A0 communicate about D, too. >> >> =A0 In my previous post I proposed to use "Galaxy" for E. >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From carlo@alinoe.com Mon Aug 31 05:59:10 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4413428C134 for ; Mon, 31 Aug 2009 05:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.357 X-Spam-Level: X-Spam-Status: No, score=-1.357 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QQhjfmU1T6C for ; Mon, 31 Aug 2009 05:59:07 -0700 (PDT) Received: from viefep18-int.chello.at (viefep18-int.chello.at [62.179.121.38]) by core3.amsl.com (Postfix) with ESMTP id 804D23A6991 for ; Mon, 31 Aug 2009 05:59:06 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep18-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090831125914.ZWES25702.viefep18-int.chello.at@edge05.upc.biz>; Mon, 31 Aug 2009 14:59:14 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id b0zC1c05F0FlQed050zDhm; Mon, 31 Aug 2009 14:59:14 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1Mi6Um-000161-G6; Mon, 31 Aug 2009 15:00:28 +0200 Date: Mon, 31 Aug 2009 15:00:28 +0200 From: Carlo Wood To: Morgaine Message-ID: <20090831130028.GA3067@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <4A9A8F7D.6070501@dcrocker.net> <20090830230832.GB25364@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 12:59:10 -0000 On Mon, Aug 31, 2009 at 05:27:05AM +0100, Morgaine wrote: > As an alternative, I propose a simpler and much more flexible approach: define > virtual worlds as anything that implements the required endpoints of the VWRAP > protocol. We do not need to know anything else about them. This lets the > people who actually design the virtual worlds decide what constitutes a virtual > world. The only thing that interests us is that these "virtual worlds" > implement the VWRAP endpoints. Very smart :) I have just one side note here; if someone creates a 'D' (sorry, can't use "virtual world" until we agree) using VWRAP internally too, again confusion might arise about the exact boundary of that "virtual world" (it could be the 'C's in that case). But you are very correct to realize that one aspect of a region domain run by a "single administration" (could be multiple administrations that work very close together: a 'D' thus) is that for all we care they use a different protocol inter-world (or extensions to VWRAP). Therefore you can replace my definition ("administrative boundary") very well with "VWRAP endpoints", without setting demands on internally used protocol. HOWEVER... the above only applies to server-server protocol, not to server-client protocol: "shared experience" is of utmost importance; part of our standardization efforts is in order to make it possible for viewers to represent "the world"/galaxy as much as possible in a consistent way to different users, which gives rize to the need of a consistent client protocol! Therefore, VWRAP would not only describe the protocol between the end-points of a virtual world ('D') but also the protocol used to communicate with viewers (clients). Though, I guess you can see that interface as an external boundary too. PS. The only way to keep wild growth at bay in the client-server protocol area, where, I expect, different 'D's (virtual worlds) will add extensions and start to release their own viewers to support those, is to add support for protocol negotion in VWRAP. Without support, it will still happen, but out of control, and become a total mess. -- Carlo Wood From kari.lippert@gmail.com Mon Aug 31 06:15:29 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08F2C28C264 for ; Mon, 31 Aug 2009 06:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnhBbWBrhDEt for ; Mon, 31 Aug 2009 06:15:28 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id A0B213A6D8A for ; Mon, 31 Aug 2009 06:15:27 -0700 (PDT) Received: by ewy3 with SMTP id 3so514682ewy.42 for ; Mon, 31 Aug 2009 06:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=J59nbAf1iRjH5cqEsA4ez1q1XYNuXca+iZnLVwgks+4=; b=fGAKm4YziGDbHgqu17zKBs5CPiSAq9obP2/j03ywTvCox5MPhstkOiFBFe6kx60UmM eeKU3+yrHFF2FfBLOrvMCE428rh7McZhpifm5zFoWiOkGDonFbvzwYO2mpXs0sLcJ5Vc 7snH6qzBzcHZRKSIuSoQnKOe8KGZqSvXAdYjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cDUheDRJIgjQHp1wov1N75Vsw8OlvoQt8SumMw6p37YklH9lLXLF4JqWNyN3/9vwCx eOS3BT4RTm/xoXEZOJnx8PPpeMJcqrDpG9LXsnTOXcDo5u+Sb7yl1yMcmHKcogIN8Mhi u5ZjtFYk3+E6El19Z2gD+E/ImeQVc8j2iL1kc= MIME-Version: 1.0 Received: by 10.216.87.66 with SMTP id x44mr1092607wee.96.1251724533617; Mon, 31 Aug 2009 06:15:33 -0700 (PDT) In-Reply-To: <20090831130028.GA3067@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <4A9A8F7D.6070501@dcrocker.net> <20090830230832.GB25364@alinoe.com> <20090831130028.GA3067@alinoe.com> Date: Mon, 31 Aug 2009 09:15:33 -0400 Message-ID: <382d73da0908310615q3c508296w824ba2e11e5b0d2f@mail.gmail.com> From: Kari Lippert To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 13:15:29 -0000 But isn't the client just another endpoint? I didn't see that a distinction was being made referring only to server endpoints. Kari On Mon, Aug 31, 2009 at 9:00 AM, Carlo Wood wrote: > On Mon, Aug 31, 2009 at 05:27:05AM +0100, Morgaine wrote: >> As an alternative, I propose a simpler and much more flexible approach: = define >> virtual worlds as anything that implements the required endpoints of the= VWRAP >> protocol. =A0We do not need to know anything else about them. =A0This le= ts the >> people who actually design the virtual worlds decide what constitutes a = virtual >> world. =A0The only thing that interests us is that these "virtual worlds= " >> implement the VWRAP endpointst. > > Very smart :) > > I have just one side note here; if someone creates a 'D' (sorry, can't us= e > "virtual world" until we agree) using VWRAP internally too, again confusi= on > might arise about the exact boundary of that "virtual world" (it could be > the 'C's in that case). > > But you are very correct to realize that one aspect of a region domain > run by a "single administration" (could be multiple administrations that > work very close together: a 'D' thus) is that for all we care they use > a different protocol inter-world (or extensions to VWRAP). Therefore > you can replace my definition ("administrative boundary") very well > with "VWRAP endpoints", without setting demands on internally used > protocol. > > HOWEVER... > > the above only applies to server-server protocol, not to server-client > protocol: "shared experience" is of utmost importance; part of our > standardization efforts is in order to make it possible for viewers > to represent "the world"/galaxy as much as possible in a consistent > way to different users, which gives rize to the need of a consistent > client protocol! > > Therefore, VWRAP would not only describe the protocol between the > end-points of a virtual world ('D') but also the protocol used to > communicate with viewers (clients). Though, I guess you can see > that interface as an external boundary too. > > PS. The only way to keep wild growth at bay in the client-server protocol > area, where, I expect, different 'D's (virtual worlds) will add extension= s > and start to release their own viewers to support those, is to add > support for protocol negotion in VWRAP. Without support, it will still > happen, but out of control, and become a total mess. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From morgaine.dinova@googlemail.com Mon Aug 31 06:59:14 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C02C3A69EF for ; Mon, 31 Aug 2009 06:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzHxfTz3y3dG for ; Mon, 31 Aug 2009 06:59:12 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 062B73A6E05 for ; Mon, 31 Aug 2009 06:57:00 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so834266eye.51 for ; Mon, 31 Aug 2009 06:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=qRO19jWESdoGcTcCoVk06xoZPavHX0VoXHOuEfyaaeA=; b=DuqOFV6dExexIByFWxPNCRSu3OwQ5Rv9UrkgO8PHho1z4ka4U34sHF/NuSp/YJWZ1t NO9S8rzHR4HY9RIPkWLJhaO3jgGwDFk5DHmLhMzytIEDQ3cqPziic8+c1WIDIPMTuRGS WPLiTG1KoS5Te4keiYKnrd239CBbBFUkcq0ec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=JktYNqsUxgDZAT7fLpu4tZP1QRDkAZDU9nWdPtkXOrsNj7uFdgusSHDC0abSnib3Vi JeDT1Ii7zP4pIb+J7zvfeOy728gj5L3l2bFnR/xbjq3O53Pz3XJfP0o3jSZAzmU95dDm s+nXukMctZKFlPEjBhNAfwwszojOALXeDSv9g= MIME-Version: 1.0 Received: by 10.210.43.17 with SMTP id q17mr4552291ebq.0.1251727028030; Mon, 31 Aug 2009 06:57:08 -0700 (PDT) In-Reply-To: <382d73da0908310615q3c508296w824ba2e11e5b0d2f@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <4A9A8F7D.6070501@dcrocker.net> <20090830230832.GB25364@alinoe.com> <20090831130028.GA3067@alinoe.com> <382d73da0908310615q3c508296w824ba2e11e5b0d2f@mail.gmail.com> Date: Mon, 31 Aug 2009 14:57:07 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174bf242dc8f85047270685e Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 13:59:14 -0000 --0015174bf242dc8f85047270685e Content-Type: text/plain; charset=ISO-8859-1 Yes indeed, the client is just another protocol endpoint. Notice that many alternative implementations of the SL viewer exist because the only requirement is adherence to the protocol at the endpoint, with no specific implementation or client structure being mandated. This results in great flexibility. Also, it is common among the developer community to place a proxy in front of the normal viewer, either to extend the client functionality with Jabber IM support or to assist in protocol debugging. This is possible because the protocols do not mandate any particular client-side implementation, so the proxy takes on the role of the client endpoint at one or more levels. The ideal network protocol is one which is wholly independent of the architecture behind its endpoints, at both client and server ends. This provides the greatest room for developing more efficient and scalable implementations. Given the importance of scalability in this area, I believe we should strive to give VWRAP these well known benefits too. Morgaine. =================================== On Mon, Aug 31, 2009 at 2:15 PM, Kari Lippert wrote: > But isn't the client just another endpoint? I didn't see that a > distinction was being made referring only to server endpoints. > > Kari > > On Mon, Aug 31, 2009 at 9:00 AM, Carlo Wood wrote: > > On Mon, Aug 31, 2009 at 05:27:05AM +0100, Morgaine wrote: > >> As an alternative, I propose a simpler and much more flexible approach: > define > >> virtual worlds as anything that implements the required endpoints of the > VWRAP > >> protocol. We do not need to know anything else about them. This lets > the > >> people who actually design the virtual worlds decide what constitutes a > virtual > >> world. The only thing that interests us is that these "virtual worlds" > >> implement the VWRAP endpointst. > > > > Very smart :) > > > > I have just one side note here; if someone creates a 'D' (sorry, can't > use > > "virtual world" until we agree) using VWRAP internally too, again > confusion > > might arise about the exact boundary of that "virtual world" (it could be > > the 'C's in that case). > > > > But you are very correct to realize that one aspect of a region domain > > run by a "single administration" (could be multiple administrations that > > work very close together: a 'D' thus) is that for all we care they use > > a different protocol inter-world (or extensions to VWRAP). Therefore > > you can replace my definition ("administrative boundary") very well > > with "VWRAP endpoints", without setting demands on internally used > > protocol. > > > > HOWEVER... > > > > the above only applies to server-server protocol, not to server-client > > protocol: "shared experience" is of utmost importance; part of our > > standardization efforts is in order to make it possible for viewers > > to represent "the world"/galaxy as much as possible in a consistent > > way to different users, which gives rize to the need of a consistent > > client protocol! > > > > Therefore, VWRAP would not only describe the protocol between the > > end-points of a virtual world ('D') but also the protocol used to > > communicate with viewers (clients). Though, I guess you can see > > that interface as an external boundary too. > > > > PS. The only way to keep wild growth at bay in the client-server protocol > > area, where, I expect, different 'D's (virtual worlds) will add > extensions > > and start to release their own viewers to support those, is to add > > support for protocol negotion in VWRAP. Without support, it will still > > happen, but out of control, and become a total mess. > > > > -- > > Carlo Wood > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > > --0015174bf242dc8f85047270685e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes indeed, the client is just another protocol endpoint.

Notice tha= t many alternative implementations of the SL viewer exist because the only = requirement is adherence to the protocol at the endpoint, with no specific = implementation or client structure being mandated.=A0 This results in great= flexibility.

Also, it is common among the developer community to place a proxy in fr= ont of the normal viewer, either to extend the client functionality with Ja= bber IM support or to assist in protocol debugging.=A0 This is possible bec= ause the protocols do not mandate any particular client-side implementation= , so the proxy takes on the role of the client endpoint at one or more leve= ls.

The ideal network protocol is one which is wholly independent of the ar= chitecture behind its endpoints, at both client and server ends.=A0 This p= rovides the greatest room for developing more efficient and scalable implem= entations.=A0 Given the importance of scalability in this area, I believe w= e should strive to give VWRAP these well known benefits too.

Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Mon, Aug 31, 2009 at 2:15 PM, Kari Lippe= rt <kari.lip= pert@gmail.com> wrote:
But isn't the= client just another endpoint? I didn't see that a
distinction was being made referring only to server endpoints.

Kari

On Mon, Aug 31, 2009 at 9:00 AM, Carlo Wood<carlo@alinoe.com> wrote:
> On Mon, Aug 31, 2009 at 05:27:05AM +0100, Morgaine wrote:
>> As an alternative, I propose a simpler and much more flexible appr= oach: define
>> virtual worlds as anything that implements the required endpoints = of the VWRAP
>> protocol. =A0We do not need to know anything else about them. =A0T= his lets the
>> people who actually design the virtual worlds decide what constitu= tes a virtual
>> world. =A0The only thing that interests us is that these "vir= tual worlds"
>> implement the VWRAP endpointst.
>
> Very smart :)
>
> I have just one side note here; if someone creates a 'D' (sorr= y, can't use
> "virtual world" until we agree) using VWRAP internally too, = again confusion
> might arise about the exact boundary of that "virtual world"= (it could be
> the 'C's in that case).
>
> But you are very correct to realize that one aspect of a region domain=
> run by a "single administration" (could be multiple administ= rations that
> work very close together: a 'D' thus) is that for all we care = they use
> a different protocol inter-world (or extensions to VWRAP). Therefore > you can replace my definition ("administrative boundary") ve= ry well
> with "VWRAP endpoints", without setting demands on internall= y used
> protocol.
>
> HOWEVER...
>
> the above only applies to server-server protocol, not to server-client=
> protocol: "shared experience" is of utmost importance; part = of our
> standardization efforts is in order to make it possible for viewers > to represent "the world"/galaxy as much as possible in a con= sistent
> way to different users, which gives rize to the need of a consistent > client protocol!
>
> Therefore, VWRAP would not only describe the protocol between the
> end-points of a virtual world ('D') but also the protocol used= to
> communicate with viewers (clients). Though, I guess you can see
> that interface as an external boundary too.
>
> PS. The only way to keep wild growth at bay in the client-server proto= col
> area, where, I expect, different 'D's (virtual worlds) will ad= d extensions
> and start to release their own viewers to support those, is to add
> support for protocol negotion in VWRAP. Without support, it will still=
> happen, but out of control, and become a total mess.
>
> --
> Carlo Wood <carlo@alinoe.com>

--0015174bf242dc8f85047270685e-- From dhc@dcrocker.net Mon Aug 31 07:39:49 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407693A6BB6 for ; Mon, 31 Aug 2009 07:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWjOW9g5Mx3f for ; Mon, 31 Aug 2009 07:39:48 -0700 (PDT) Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7148]) by core3.amsl.com (Postfix) with ESMTP id DC7153A6911 for ; Mon, 31 Aug 2009 07:39:47 -0700 (PDT) Received: from [127.0.0.1] (ppp-68-120-198-98.dsl.pltn13.pacbell.net [68.120.198.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n7VEdpdp028734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 31 Aug 2009 07:39:56 -0700 Message-ID: <4A9BE0B0.5010508@dcrocker.net> Date: Mon, 31 Aug 2009 07:39:44 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: ogpx@ietf.org References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 31 Aug 2009 07:39:56 -0700 (PDT) Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 14:39:49 -0000 Meadhbh Siobhan wrote: > so. this is an interesting one. > > those of us who called for the OGPX BoF are in agreement that the term > "virtual world" is informational only. This calls for an alternative that hadn't occurred to me. The charter currently has the string "virtual world" thirteen times. And it is used heavily in discussions on this list. That level use of use essentially guarantees that the string is not merely informative. It really does have to have specific technical meaning that folks agree on. But since this latest round suggests, once again, that gaining agreement on consistent technical use of the string will remain problematic, and since you are pointing out that there was an intent to have it NOT BE a technical term... My suggest is to remove all occurrences of the term from the charter, except for the two in the first sentence of the draft charters Description section. In other words, say that vwrap provides a service in virtual world simulation, but then make all other references be in terms of vwrap-specific technical constructs. regions, agents, etc. -- Dave Crocker Brandenburg InternetWorking bbiw.net From josh@lindenlab.com Mon Aug 31 09:05:52 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2708328C35B for ; Mon, 31 Aug 2009 09:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzCVMz7VlLVr for ; Mon, 31 Aug 2009 09:05:51 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 31FEA28C35C for ; Mon, 31 Aug 2009 09:05:51 -0700 (PDT) Received: by pzk38 with SMTP id 38so4061110pzk.5 for ; Mon, 31 Aug 2009 09:05:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.49.16 with SMTP id b16mr1116954rvk.167.1251734757441; Mon, 31 Aug 2009 09:05:57 -0700 (PDT) In-Reply-To: <20090830230832.GB25364@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <4A9A8F7D.6070501@dcrocker.net> <20090830230832.GB25364@alinoe.com> Date: Mon, 31 Aug 2009 09:05:57 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cd24da292028d04727235db Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 16:05:52 -0000 --000e0cd24da292028d04727235db Content-Type: text/plain; charset=UTF-8 On Sun, Aug 30, 2009 at 4:08 PM, Carlo Wood wrote: > I think that any effort to work on the final wording > should be stopped until we finally agree on what "virtual world" means... > Please note that we are attempting to craft a CHARTER at this point that describes the problem space that a working group will tackle. Do you feel that we can't proceed with the creation of a working group until specific terminology is nailed down? I understand that you don't want to define what virtual world means, > in which case you shouldn't use it at all in the charter and also > not in the protocol name (VWrap). > I believe "virtual world" is as well defined as "web site". It should not be used in a normative fashion, but is extremely clear to lay-persons what is under discussion, and is clear enough to distinguish the problem domain from others (i.e. it's not tackling email, IPv6, etc). I assert that this is sufficient for the charter. (And, personally, beyond.) > A) A smallest partition > B) A collection of adjacent A's run by a single administration > C) A collection of adjecent B's run by different administrations (which > very likely use the same TOS etc) > D) A collection of C's that are not adjacent but still fall under the same > TOS etc. > E) A collection of D's that have totally different administrations and > possibly different TOS etc, but which interoperate. > F) The whole of all E's that do not interoperate, but still use VWRAP. > G) The rest that use the term "virtual world", but do not use VWRAP. > If we were to agree that consensus terminology for the above concepts was something we needed to come up with, wouldn't a Working Group be a great place to try and achieve that consensus? Please don't reply with "we don't want to define this" :p > We NEED to define this, or we can't TALK about this! > HTTP can be defined irrespective of a formal definition for "web site". Both technical and marketing terms are extremely valuable, but shouldn't be confused. --000e0cd24da292028d04727235db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 30, 2009 at 4:08 PM, Carlo Wood <carlo@alinoe.com&= gt; wrote:
I think that any effort to work on the final wording
should be stopped until we finally agree on what "virtual world" = means...

Please note that we are attempting to craft a CHARTER= at this point that describes the problem space that a working group will t= ackle. Do you feel that we can't proceed with the creation of a working= group until specific terminology is nailed down?

I understand that you don't want to define what virtual world means, in which case you shouldn't use it at all in the charter and also
not in the protocol name (VWrap).

I believe "virtual world" is as well define= d as "web site". It should not be used in a normative fashion, bu= t is extremely clear to lay-persons what is under discussion, and is clear = enough to distinguish the problem domain from others (i.e. it's not tac= kling email, IPv6, etc).

I assert that this is sufficient for the charter. (And, personally, bey= ond.)
=C2=A0
A) A smallest partition
B) A collection of adjacent A's run by a single administration
C) A collection of adjecent B's run by different administrations (which= very likely use the same TOS etc)
D) A collection of C's that are not adjacent but still fall under the s= ame TOS etc.
E) A collection of D's that have totally different administrations and = possibly different TOS etc, but which interoperate.
F) The whole of all E's that do not interoperate, but still use VWRAP.<= br> G) The rest that use the term "virtual world", but do not use VWR= AP.

If we were to agree that consensus terminology for th= e above concepts was something we needed to come up with, wouldn't a Wo= rking Group be a great place to try and achieve that consensus?

Please don't reply with "we don't want to define this" :p=
We NEED to define this, or we can't TALK about this!

HTTP can be defined irrespect= ive of a formal definition for "web site".

Both technical= and marketing terms are extremely valuable, but shouldn't be confused.=

--000e0cd24da292028d04727235db-- From josh@lindenlab.com Mon Aug 31 09:25:23 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E98828C36A for ; Mon, 31 Aug 2009 09:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qc55fieeEWt1 for ; Mon, 31 Aug 2009 09:25:22 -0700 (PDT) Received: from mail-px0-f181.google.com (mail-px0-f181.google.com [209.85.216.181]) by core3.amsl.com (Postfix) with ESMTP id 46D5A28C375 for ; Mon, 31 Aug 2009 09:25:22 -0700 (PDT) Received: by pxi11 with SMTP id 11so179202pxi.17 for ; Mon, 31 Aug 2009 09:25:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.202.12 with SMTP id z12mr1119480rvf.112.1251735930225; Mon, 31 Aug 2009 09:25:30 -0700 (PDT) In-Reply-To: <204765.27116.qm@web82605.mail.mud.yahoo.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> <204765.27116.qm@web82605.mail.mud.yahoo.com> Date: Mon, 31 Aug 2009 09:25:30 -0700 Message-ID: From: Joshua Bell To: Charles Krinke Content-Type: multipart/alternative; boundary=000e0cd151f87945870472727b09 Cc: ogpx@ietf.org Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 16:25:23 -0000 --000e0cd151f87945870472727b09 Content-Type: text/plain; charset=UTF-8 I apologize for the potentially unclear responses. These are decidedly non-trivial questions being asked, and demand an attempt at rigorous answers. Saying "yes" would imply policy decisions and extensive technical work by independent parties. Saying "no" would incorrectly imply a limitation on the scope of the intended work. On Sun, Aug 30, 2009 at 6:19 PM, Charles Krinke wrote: > I'm confused with all that is going on and need to ask my two main > questions again. > > "Are we considering interop with virtual worlds running OpenSim which do > not run agent domains but rather a similar, but not quite identical notion > we call UGAIM (User, Grid, Asset, Inventory, Messaging) servers?" > It's unclear what you mean by "interop with" in the above sentence. What are the end-points involved? What is the data and/or user experience being shared? And, of course, a protocol specification doesn't dictate implementation in any way. Second Life today doesn't implement the parts of OGP that have been drafted yet, and of course there is a lot more to be drafted! I couldn't say what OpenSim will do in the future! However, I can take a guess at your intent, but let me state my guess: "Will the output of the VWRAP group be protocol definitions that would prove useful for implementing movement of agents between OpenSim instances?" To that question, I'd answer: "Hopefully, yes." > "Are we considering a full handoff? That is, a user on an OpenSim grid may > teleport to a SecondLife grid and retain its connection to the OpenSim > UGAIM, in an analogous fashion that a user has been demonstrated to teleport > from the Betagrid to OSGrid using OGP last year?" > First off, any such interoperation is subject to the whims of policy. I'm unfamiliar with the details of OpenSim UGAIM, but I would posit that the VWRAP group would define protocols that an OpenSim instance would need to implement to support such interop with a VWRAP-implementing non-OpenSim system. I believe UGAIM would be an "implementation detail" hidden behind the protocol facades. This may imply that the properties of UGAIM (again, I'm ignorant of any details) will be beneficial to the specification of the protocols. The worst-case analogy that comes to mind is taking a pre-web server application and slapping a web interface (HTTP+HTML) on it. Depending on the design of the server application, that may be trivial and clean, or may be a hideous hack. In this case, we have the advantage that the server application engineers are active (it's not a defunct legacy system!) and can inform the creation of the protocol to potentially ease the migration. Joshua --000e0cd151f87945870472727b09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I apologize for the potentially unclear response= s. These are decidedly non-trivial questions being asked, and demand an att= empt at rigorous answers. Saying "yes" would imply policy decisio= ns and extensive technical work by independent parties. Saying "no&quo= t; would incorrectly imply a limitation on the scope of the intended work.<= br>
On Sun, Aug 30, 2009 at 6:19 PM, Charles Krinke <<= a href=3D"mailto:cfk@pacbell.net">cfk@pacbell.net> wrote:
=
I'm confused with all that is going on and= need to ask my two main questions again.

"Are we considering i= nterop with virtual worlds running OpenSim which do not run agent domains b= ut rather a similar, but not quite identical notion we call UGAIM (User, Gr= id, Asset, Inventory, Messaging) servers?"

It's unclear what you mean by &= quot;interop with" in the above sentence. What are the end-points invo= lved? What is the data and/or user experience being shared?

And, of= course, a protocol specification doesn't dictate implementation in any= way. Second Life today doesn't implement the parts of OGP that have be= en drafted yet, and of course there is a lot more to be drafted! I couldn&#= 39;t say what OpenSim will do in the future!

However, I can take a guess at your intent, but let me state my guess:<= br>
"Will the output of the VWRAP group be protocol definitions tha= t would prove useful for implementing movement of agents between OpenSim in= stances?"

To that question, I'd answer: "Hopefully, yes."
=C2=A0=
"Are we considering a full handoff? That is, a user on an OpenSim= grid may teleport to a SecondLife grid and retain its connection to the Op= enSim UGAIM, in an analogous fashion that a user has been demonstrated to t= eleport from the Betagrid to OSGrid using OGP last year?"

First off, any such interoperation= is subject to the whims of policy.

I'm unfamiliar with the det= ails of OpenSim UGAIM, but I would posit that the VWRAP group would define = protocols that an OpenSim instance would need to implement to support such = interop with a VWRAP-implementing non-OpenSim system. I believe UGAIM would= be an "implementation detail" hidden behind the protocol facades= . This may imply that the properties of UGAIM (again, I'm ignorant of a= ny details) will be beneficial to the specification of the protocols.

The worst-case analogy that comes to mind is taking a pre-web server ap= plication and slapping a web interface (HTTP+HTML) on it. Depending on the = design of the server application, that may be trivial and clean, or may be = a hideous hack. In this case, we have the advantage that the server applica= tion engineers are active (it's not a defunct legacy system!) and can i= nform the creation of the protocol to potentially ease the migration.

Joshua

--000e0cd151f87945870472727b09-- From carlo@alinoe.com Mon Aug 31 09:47:13 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE73328C1D6 for ; Mon, 31 Aug 2009 09:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNFItMFkN4wp for ; Mon, 31 Aug 2009 09:47:13 -0700 (PDT) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id 78C7628C2C6 for ; Mon, 31 Aug 2009 09:47:12 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090831164720.BDSG793.viefep11-int.chello.at@edge04.upc.biz>; Mon, 31 Aug 2009 18:47:20 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id b4nE1c0070FlQed044nFsy; Mon, 31 Aug 2009 18:47:20 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MiA3S-0004G1-Dc; Mon, 31 Aug 2009 18:48:30 +0200 Date: Mon, 31 Aug 2009 18:48:30 +0200 From: Carlo Wood To: Joshua Bell Message-ID: <20090831164830.GA15637@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <4A9A8F7D.6070501@dcrocker.net> <20090830230832.GB25364@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 16:47:14 -0000 I'm sorry you just ignored my list :( Just quoting it, and then refusing to make an effort to give those concepts a term... As you will have noted... I NEEDED those terms in each and every post of me since I posted this list. So far I used 'A', 'C', 'D' and 'E' in my posts, but I refuse to continue to do that. If there are a few here that refuse to define a few terms for the sake of discussions (on this list) then I will, and I will consistently keep using those terms. On Mon, Aug 31, 2009 at 09:05:57AM -0700, Joshua Bell wrote: > On Sun, Aug 30, 2009 at 4:08 PM, Carlo Wood wrote: > > I think that any effort to work on the final wording > should be stopped until we finally agree on what "virtual world" means... > > > Please note that we are attempting to craft a CHARTER at this point that > describes the problem space that a working group will tackle. Do you feel that > we can't proceed with the creation of a working group until specific > terminology is nailed down? > > > I understand that you don't want to define what virtual world means, > in which case you shouldn't use it at all in the charter and also > not in the protocol name (VWrap). > > > I believe "virtual world" is as well defined as "web site". It should not be > used in a normative fashion, but is extremely clear to lay-persons what is > under discussion, and is clear enough to distinguish the problem domain from > others (i.e. it's not tackling email, IPv6, etc). > > I assert that this is sufficient for the charter. (And, personally, beyond.) >   > > A) A smallest partition > B) A collection of adjacent A's run by a single administration > C) A collection of adjecent B's run by different administrations (which > very likely use the same TOS etc) > D) A collection of C's that are not adjacent but still fall under the same > TOS etc. > E) A collection of D's that have totally different administrations and > possibly different TOS etc, but which interoperate. > F) The whole of all E's that do not interoperate, but still use VWRAP. > G) The rest that use the term "virtual world", but do not use VWRAP. > > > If we were to agree that consensus terminology for the above concepts was > something we needed to come up with, wouldn't a Working Group be a great place > to try and achieve that consensus? > > > Please don't reply with "we don't want to define this" :p > We NEED to define this, or we can't TALK about this! > > > HTTP can be defined irrespective of a formal definition for "web site". > > Both technical and marketing terms are extremely valuable, but shouldn't be > confused. > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx -- Carlo Wood From carlo@alinoe.com Mon Aug 31 09:58:42 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB1E3A6E3B for ; Mon, 31 Aug 2009 09:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8HZX7053AU8 for ; Mon, 31 Aug 2009 09:58:41 -0700 (PDT) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id 2B5863A6D5C for ; Mon, 31 Aug 2009 09:58:40 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep17-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090831165851.LXPZ15272.viefep17-int.chello.at@edge05.upc.biz> for ; Mon, 31 Aug 2009 18:58:51 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id b4yp1c09S0FlQed054yqdE; Mon, 31 Aug 2009 18:58:51 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MiAEg-0004ND-97 for ogpx@ietf.org; Mon, 31 Aug 2009 19:00:06 +0200 Date: Mon, 31 Aug 2009 19:00:06 +0200 From: Carlo Wood To: ogpx@ietf.org Message-ID: <20090831170006.GB15637@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [ogpx] Definitions of terms to be used in my (our?) communication X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 16:58:42 -0000 A) A smallest partition REGION B) A collection of adjacent regions run by a single administration ISLAND or ADJACENT REGIONS C) A collection of adjacent regions's run by different administrations (which very likely use the same TOS etc) LAND, or CONTINENT when larger. D) A collection of continent's that are not adjacent but still fall under the same TOS, likely use the same inter-world protocols and organisation-specific extensions etc (likely, they will have their own website and their own Abuse Report team etc). VIRTUAL WORLD E) A collection of Virtual World's that have totally different administrations and possibly different TOS etc, but which interoperate (ie, you can pass on a Landmark of one VW to a person you meet in another VW). GALAXY F) The whole of all Galaxies that do not interoperate, but still use VWRAP. VWRAP UNIVERSE G) The rest that use the term "virtual world", but do not use VWRAP. MMOX UNIVERSE Please state if * you have problem with me going to use these terms consistently in my posts * you will use these terms with the same meaning * you wish to give these terms a different meaning I understand there is also something called "REGION DOMAIN", but I have no idea which of the above that would be as it's not my term and it was never discussed. -- Carlo Wood From kari.lippert@gmail.com Mon Aug 31 10:34:44 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E44C28C205 for ; Mon, 31 Aug 2009 10:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pgtH-5LfqQK for ; Mon, 31 Aug 2009 10:34:43 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 0994728C20C for ; Mon, 31 Aug 2009 10:34:42 -0700 (PDT) Received: by ewy3 with SMTP id 3so769732ewy.42 for ; Mon, 31 Aug 2009 10:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=sw2ACmvluiSM1AvSH3aTf1Hg293ldUp6zIlMShswQJ4=; b=Ob/h9EMppkzTWCIj6xlLnArDjuNhKScklbq8YIl83HcHT4eTwdqjM+ISlVSL6drzgn wKZvIpdzC1UOnJKEd/QwwbI2eCKuirTXDtcQXbXEuvsy5IJvoiJ3FbBCRR60iSkFHF7+ l5ZhzePtnRXQTNmfFMmUQ1FAsMDswLZdvz+wk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=iKMeWx93snZJ1MWFjGLW25BNqMVzKo7lqZ0ZpkkQxRq5p5yDQVqoUS6of5LCHYVXrV oWWmzCqnd5bj5e9Pka9R/yvu3Y1/6K16zRY3lHD1p/75c1x8M3ouni4nU0+Ts4orp34m a742Bn3oQXDTZmGcW878GSWZ/E67N6G69ECCA= MIME-Version: 1.0 Received: by 10.216.71.83 with SMTP id q61mr1159574wed.14.1251740090296; Mon, 31 Aug 2009 10:34:50 -0700 (PDT) In-Reply-To: <20090831170006.GB15637@alinoe.com> References: <20090831170006.GB15637@alinoe.com> Date: Mon, 31 Aug 2009 13:34:50 -0400 Message-ID: <382d73da0908311034u50baa09fqcdbed2a478df99f8@mail.gmail.com> From: Kari Lippert To: Carlo Wood , ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [ogpx] Definitions of terms to be used in my (our?) communication X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 17:34:44 -0000 Personally I would drop the use of "LAND" and "ADJACENT REGIONS" but I think these terms, as defined here are the right set based on the lengthy conversations I started yesterday morning. Using these terms it should now be rather trivial to restate the Charter in a way that captures the essence of the effort's intent. Kari On Mon, Aug 31, 2009 at 1:00 PM, Carlo Wood wrote: > A) A smallest partition > > =A0REGION > > B) A collection of adjacent regions run by a single administration > > =A0ISLAND or ADJACENT REGIONS > > C) A collection of adjacent regions's run by different administrations > =A0 (which very likely use the same TOS etc) > > =A0LAND, or CONTINENT when larger. > > D) A collection of continent's that are not adjacent but still fall > =A0 under the same TOS, likely use the same inter-world protocols > =A0 and organisation-specific extensions etc (likely, they will > =A0 have their own website and their own Abuse Report team etc). > > =A0VIRTUAL WORLD > > E) A collection of Virtual World's that have totally different > =A0 administrations and possibly different TOS etc, but which > =A0 interoperate (ie, you can pass on a Landmark of one VW to > =A0 a person you meet in another VW). > > =A0GALAXY > > F) The whole of all Galaxies that do not interoperate, but still use VWRA= P. > > =A0VWRAP UNIVERSE > > G) The rest that use the term "virtual world", but do not use VWRAP. > > =A0MMOX UNIVERSE > > > Please state if > * you have problem with me going to use these terms consistently in my po= sts > * you will use these terms with the same meaning > * you wish to give these terms a different meaning > > I understand there is also something called "REGION DOMAIN", but > I have no idea which of the above that would be as it's not my > term and it was never discussed. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From meadhbh.siobhan@gmail.com Mon Aug 31 11:08:06 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9418328C448 for ; Mon, 31 Aug 2009 11:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcCcrP1+JaIR for ; Mon, 31 Aug 2009 11:08:05 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 7D47228C446 for ; Mon, 31 Aug 2009 11:08:05 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id v27so578344wah.5 for ; Mon, 31 Aug 2009 11:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1DymnKFj5JvHJHFmGPXLimPyFeDVKygofMzViYwt3Xw=; b=krQGYpPOcdojJztBIGc0sBDXldo3SZ9qEz50CmmbESGUrJriIXz1wD2/9owgGcBccJ vrrHUQUofIT26IHc/ZgxyQXACiI/L4n8lUj8Cctquyc3h+/yVIfYq7Yh63/qTHwNcFof nmxpzcOiIBC0cDl7MKoRwqrhctz5EPtRY3lwE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kLOQuIZG0/JDjOKd1ioCeLRxj2PMlzB0de8QPziMEckdATbPaS1xx5L+v+mhlQEthr lpGJsTv39rreQLftlY0SqEStr5TyzVoAAN9HvKh0at/4ltM4RCM6O/FySF8pPgMdI031 9vFbNsPDrnUCrGzieP6qQ/Ipz9VlAuF46s0tI= MIME-Version: 1.0 Received: by 10.115.51.16 with SMTP id d16mr2955441wak.165.1251742093767; Mon, 31 Aug 2009 11:08:13 -0700 (PDT) In-Reply-To: <20090831170006.GB15637@alinoe.com> References: <20090831170006.GB15637@alinoe.com> Date: Mon, 31 Aug 2009 11:08:13 -0700 Message-ID: From: Meadhbh Siobhan To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Definitions of terms to be used in my (our?) communication X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 18:08:06 -0000 hey carlo, just as a fyi, we have some _slightly_ different terms/definitions in OGP/VWRAP than in SL. just a reminder, OGP/VWRAP is decidedly not legacy SL protocol. (sorry if i sound like a broken record about that) but before i comment on these terms, let me point out that while this discussion is interesting and germane to the subject of virtual worlds, it is a bit out of scope for a discussion about the charter. so, can we just for right now, just use the terms that have been defined in the way that they're defined and get through the charter bashing? i PROMISE you, that we'll get back to terms in more detail, and honestly, i like your use of the term "universe." in the current OGP/VWRAP documents, the term "island" and "galaxy" aren't u= sed. your use of the term "region" is different than the way it's described in the intro doc. what you call a "region" below, we would call a "region domain." what we call a "region" is the set of data used to represent a collection of adjacent points in the virtual world. i'm hoping that the verbiage in the draft charter makes it clear that services that export information about the region or provide an interface to modify the region's state go through a single region specific URI. the "simulator" is the server process that maintains the region's state and processes service requests. the "simulator host" or "region host" is the machine itself that the simulator process runs on. further, a "domain" is a collection of resources administered by a single entity. thus a "region domain" is a collection of regions that are run by the same entity, and presumably _could_ be governed by the same terms of service, or more importantly to us, could potentially be considered a single end entity in the trust model. we haven't put the term "adjacent region" into the doc, and now that i see you talking about it, i think it was an oversight not to. or rather, maybe just to talk about "adjacency" in general. for people who are unfamiliar with SL, adjacent regions are simply regions that are next to each other in the geometry of the virtual world. in second life, a region communicates with adjacent regions so the original region can tell the client the state of assets it's managing, if the client needs to know about it and policy says the client can access that information. *whew* in SL, the term "island" sometimes means regions that have no adjacent regions (i.e. - they're out in the virtual ocean, all by themselves) or about a virtual landscape that looks like an island. (obviously, the former is more interesting to this group than the latter at this moment.) the terms "land" and "continent" are not defined in the spec. SL uses "continents" for administrative and (some) billing purposes. we are not trying to foist this aspect of SL off on the unsuspecting public. that is, it works well for us to divide things into continents, and if someone other than Linden wants to do this, good on ya. but, requiring that this be a part of the specification is not harmonious with our objective of not having people say bad things about us. "galaxy" is also not defined in the spec, or by any of implementors who worked on OGP over the last 2 years. "virtual world" is defined informally as discussed earlier on this list. i know morgaine frequently uses the term "region domain" to describe what we would call a "virtual world." "VWRAP Universe" is not defined now, and i'm generally loathe to introduce new terms, but i have to admit, i kinda like this one. but let's talk about it more later. about "MMOX Universe.." as far as i can tell, no one is working on MMOX currently, so we might want to say "non-VWRAP universe" to describe universes that are not VWRAPish. On Mon, Aug 31, 2009 at 10:00 AM, Carlo Wood wrote: > A) A smallest partition > > =A0REGION > > B) A collection of adjacent regions run by a single administration > > =A0ISLAND or ADJACENT REGIONS > > C) A collection of adjacent regions's run by different administrations > =A0 (which very likely use the same TOS etc) > > =A0LAND, or CONTINENT when larger. > > D) A collection of continent's that are not adjacent but still fall > =A0 under the same TOS, likely use the same inter-world protocols > =A0 and organisation-specific extensions etc (likely, they will > =A0 have their own website and their own Abuse Report team etc). > > =A0VIRTUAL WORLD > > E) A collection of Virtual World's that have totally different > =A0 administrations and possibly different TOS etc, but which > =A0 interoperate (ie, you can pass on a Landmark of one VW to > =A0 a person you meet in another VW). > > =A0GALAXY > > F) The whole of all Galaxies that do not interoperate, but still use VWRA= P. > > =A0VWRAP UNIVERSE > > G) The rest that use the term "virtual world", but do not use VWRAP. > > =A0MMOX UNIVERSE > > > Please state if > * you have problem with me going to use these terms consistently in my po= sts > * you will use these terms with the same meaning > * you wish to give these terms a different meaning > > I understand there is also something called "REGION DOMAIN", but > I have no idea which of the above that would be as it's not my > term and it was never discussed. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From meadhbh.siobhan@gmail.com Mon Aug 31 11:10:21 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6119C28C45D for ; Mon, 31 Aug 2009 11:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn8cTfrGSL7T for ; Mon, 31 Aug 2009 11:10:20 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id 8506428C451 for ; Mon, 31 Aug 2009 11:10:20 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id v27so578680wah.5 for ; Mon, 31 Aug 2009 11:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dRuPEH1UxUiaUAZIsjenVcPudQ6hGTtVOEXpkpjTu1A=; b=YQLffYfp62rh2r4KWzfgXHe68A3OOtHQtAiEdfJNu8nYvfcBtgAM7UsH9Ylmb54Il3 FqyPlkyOrAm4PYfjgmFGhncBCZsNOarFQD01e20ZfrPCn0e1VGPbTUv+i42DyMRJRQ82 J4DxSm8lthTZmcyyldmV0jWXBMvmWixwgv3EQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Aohf+v/C6V+iDVCdA4bu4NbjwvpAHYpQr6LMpKUWeHcflsIBPqteIHkOfzKuad2Q2U kvpBf4xSkO0da9n7/Wmx1IZw16Gl0Gsq7H/bT9muhZKsRCvP9ASg+3rFTFNIBt1Dv1XS DuP07e4u/SBNOCzsDWrwgAlPJv0DFVf0Opl2w= MIME-Version: 1.0 Received: by 10.115.102.38 with SMTP id e38mr2932161wam.207.1251742229613; Mon, 31 Aug 2009 11:10:29 -0700 (PDT) In-Reply-To: <382d73da0908311034u50baa09fqcdbed2a478df99f8@mail.gmail.com> References: <20090831170006.GB15637@alinoe.com> <382d73da0908311034u50baa09fqcdbed2a478df99f8@mail.gmail.com> Date: Mon, 31 Aug 2009 11:10:29 -0700 Message-ID: From: Meadhbh Siobhan To: Kari Lippert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Definitions of terms to be used in my (our?) communication X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 18:10:21 -0000 i would go further and say that the discussion of adjacency is important, but not required for the charter. we should be able to define the protocol in such a way that adjacency or non-adjacency are covered by the description of the protocol, and not special cases that need to be called out in the charter. -cheers -meadhbh / infinity On Mon, Aug 31, 2009 at 10:34 AM, Kari Lippert wrot= e: > Personally I would drop the use of "LAND" and =A0"ADJACENT REGIONS" but > I think these terms, as defined here are the right set based on the > lengthy conversations I started yesterday morning. Using these terms > it should now be rather trivial to restate the Charter in a way that > captures the essence of the effort's intent. > > Kari > > > On Mon, Aug 31, 2009 at 1:00 PM, Carlo Wood wrote: >> A) A smallest partition >> >> =A0REGION >> >> B) A collection of adjacent regions run by a single administration >> >> =A0ISLAND or ADJACENT REGIONS >> >> C) A collection of adjacent regions's run by different administrations >> =A0 (which very likely use the same TOS etc) >> >> =A0LAND, or CONTINENT when larger. >> >> D) A collection of continent's that are not adjacent but still fall >> =A0 under the same TOS, likely use the same inter-world protocols >> =A0 and organisation-specific extensions etc (likely, they will >> =A0 have their own website and their own Abuse Report team etc). >> >> =A0VIRTUAL WORLD >> >> E) A collection of Virtual World's that have totally different >> =A0 administrations and possibly different TOS etc, but which >> =A0 interoperate (ie, you can pass on a Landmark of one VW to >> =A0 a person you meet in another VW). >> >> =A0GALAXY >> >> F) The whole of all Galaxies that do not interoperate, but still use VWR= AP. >> >> =A0VWRAP UNIVERSE >> >> G) The rest that use the term "virtual world", but do not use VWRAP. >> >> =A0MMOX UNIVERSE >> >> >> Please state if >> * you have problem with me going to use these terms consistently in my p= osts >> * you will use these terms with the same meaning >> * you wish to give these terms a different meaning >> >> I understand there is also something called "REGION DOMAIN", but >> I have no idea which of the above that would be as it's not my >> term and it was never discussed. >> >> -- >> Carlo Wood >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From meadhbh.siobhan@gmail.com Mon Aug 31 11:23:47 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CCB928C466 for ; Mon, 31 Aug 2009 11:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH2HnbCc57iD for ; Mon, 31 Aug 2009 11:23:46 -0700 (PDT) Received: from mail-px0-f181.google.com (mail-px0-f181.google.com [209.85.216.181]) by core3.amsl.com (Postfix) with ESMTP id 23C4128C478 for ; Mon, 31 Aug 2009 11:23:46 -0700 (PDT) Received: by pxi11 with SMTP id 11so243236pxi.17 for ; Mon, 31 Aug 2009 11:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LPC+o2U5U0Ixf811Tvgtd7dUXGP9XRhhKB01l9+C58U=; b=X3HU7CtdPG6YJ6FzfNaudbxPikq1C7/Si6LgoV92YFvLxfJWs7F2bINhSj/kqCbvEl FKavPtqbcuqL+sogKP8VGApxg0z/XnB+/ufLfTMEPmpnD78Uk3Me0hm+JmsspMUwoq6s xSwUF/WQpozlZ9YlIe2nawSavYpxR2QAIEZIA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gST8i04bRopQ3gB9KZoqTcdHvZQckNwtajcGsVG+5sGgQSBWmp0BPkgKQmBWfj14uk XuNE1FLCuWRCW16fanJEhdMO7iL0mv4YLG5cRrV3opE7LsoKT8pc6nzHYi4GH7Db1u1j +7FBf+joYEVOrjCGBTTVwVvl3lF0jCdeKmbBg= MIME-Version: 1.0 Received: by 10.115.51.16 with SMTP id d16mr2976671wak.165.1251743034526; Mon, 31 Aug 2009 11:23:54 -0700 (PDT) In-Reply-To: <20090831164830.GA15637@alinoe.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <4A9A8F7D.6070501@dcrocker.net> <20090830230832.GB25364@alinoe.com> <20090831164830.GA15637@alinoe.com> Date: Mon, 31 Aug 2009 11:23:54 -0700 Message-ID: From: Meadhbh Siobhan To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 18:23:47 -0000 carlo. OGP/VWRAP is the continuation of a standardization effort that has been ongoing for about two years. there is a history of using the terms we have listed, and we even have deployed systems that are based on earlier versions of these specs. if you sense reticence to stop work because people involved in this effort choose to use a different set of definitions than the ones you're promoting, i'm sorry. at the end of the day, there are a number of us who would like to continue working on virtual worlds standardization and feel we can do it without applying a definition to a COMPLETELY non-normative term. i am disappointed that you do not wish to continue working with us, but i believe is speak for many of us when i say that there are much more important things we can talk about. there is NOT consensus to apply a definition to a non-normative term, but there is consensus to continue working on this problem domain. i support your effort to refine a definition of the term "virtual world," but as the term does not appear normatively in any specification produced to date, i have to say, your request to stop all work on this effort until it _is_ defined satisfactorily to all parties seems a bit obstructionist. i am happy to continue to work on a definition with you, but not in this forum and not until the charter is finished. i truly value your contributions, but the reason we are here it to define interoperability protocols, not to quibble about the definition of terms that do not need to be defined. -sincerely -meadhbh hamrick On Mon, Aug 31, 2009 at 9:48 AM, Carlo Wood wrote: > I'm sorry you just ignored my list :( > Just quoting it, and then refusing to make an effort to give > those concepts a term... > > As you will have noted... I NEEDED those terms in each and every > post of me since I posted this list. > > So far I used 'A', 'C', 'D' and 'E' in my posts, but I refuse > to continue to do that. > > If there are a few here that refuse to define a few terms for > the sake of discussions (on this list) then I will, and I will > consistently keep using those terms. > > On Mon, Aug 31, 2009 at 09:05:57AM -0700, Joshua Bell wrote: >> On Sun, Aug 30, 2009 at 4:08 PM, Carlo Wood wrote: >> >> =A0 =A0 I think that any effort to work on the final wording >> =A0 =A0 should be stopped until we finally agree on what "virtual world"= means... >> >> >> Please note that we are attempting to craft a CHARTER at this point that >> describes the problem space that a working group will tackle. Do you fee= l that >> we can't proceed with the creation of a working group until specific >> terminology is nailed down? >> >> >> =A0 =A0 I understand that you don't want to define what virtual world me= ans, >> =A0 =A0 in which case you shouldn't use it at all in the charter and als= o >> =A0 =A0 not in the protocol name (VWrap). >> >> >> I believe "virtual world" is as well defined as "web site". It should no= t be >> used in a normative fashion, but is extremely clear to lay-persons what = is >> under discussion, and is clear enough to distinguish the problem domain = from >> others (i.e. it's not tackling email, IPv6, etc). >> >> I assert that this is sufficient for the charter. (And, personally, beyo= nd.) >> >> >> =A0 =A0 A) A smallest partition >> =A0 =A0 B) A collection of adjacent A's run by a single administration >> =A0 =A0 C) A collection of adjecent B's run by different administrations= (which >> =A0 =A0 very likely use the same TOS etc) >> =A0 =A0 D) A collection of C's that are not adjacent but still fall unde= r the same >> =A0 =A0 TOS etc. >> =A0 =A0 E) A collection of D's that have totally different administratio= ns and >> =A0 =A0 possibly different TOS etc, but which interoperate. >> =A0 =A0 F) The whole of all E's that do not interoperate, but still use = VWRAP. >> =A0 =A0 G) The rest that use the term "virtual world", but do not use VW= RAP. >> >> >> If we were to agree that consensus terminology for the above concepts wa= s >> something we needed to come up with, wouldn't a Working Group be a great= place >> to try and achieve that consensus? >> >> >> =A0 =A0 Please don't reply with "we don't want to define this" :p >> =A0 =A0 We NEED to define this, or we can't TALK about this! >> >> >> HTTP can be defined irrespective of a formal definition for "web site". >> >> Both technical and marketing terms are extremely valuable, but shouldn't= be >> confused. >> > >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From meadhbh.siobhan@gmail.com Mon Aug 31 11:39:39 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0403128C4B3 for ; Mon, 31 Aug 2009 11:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZr0Jdye6vQH for ; Mon, 31 Aug 2009 11:39:37 -0700 (PDT) Received: from mail-px0-f181.google.com (mail-px0-f181.google.com [209.85.216.181]) by core3.amsl.com (Postfix) with ESMTP id 515D128C4AA for ; Mon, 31 Aug 2009 11:37:54 -0700 (PDT) Received: by pxi11 with SMTP id 11so250474pxi.17 for ; Mon, 31 Aug 2009 11:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qj/ACQT47MIWYolM3rrlWz/HSO3LiLZAiJXi9YP8T2I=; b=Z+f5BEOJtjvXZuyJK5EGQsHQEgPupv3jVMgUtxSCACxRVTFxRERETq0hiv7qKaKt5N ojiP42GejpYKbV06T/RrXKTw4Xwx9QkOxJdjpHgcoZf7bgDUK/HIB0cyx6pgsSXuvDcf JlSy32SPdZUB4qS1iP5P3MBV0orJDwulAPWNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EVGtzSOsDJMPX74A9HZnin/54HO4gym6Z986ALblZ01QD76UusJhmMB/L3ZvQYaK7S +JDFq4vHRJh1kvZVDRPQpLN3s40ngxGYslqPjKb7F/J97sa6CmDid/lC5BP6YsFVdVfV +NrENsCVua5aLm0W0jbKuPtChReO52cIWmkZs= MIME-Version: 1.0 Received: by 10.115.4.12 with SMTP id g12mr2971480wai.210.1251743880836; Mon, 31 Aug 2009 11:38:00 -0700 (PDT) In-Reply-To: <204765.27116.qm@web82605.mail.mud.yahoo.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> <204765.27116.qm@web82605.mail.mud.yahoo.com> Date: Mon, 31 Aug 2009 11:38:00 -0700 Message-ID: From: Meadhbh Siobhan To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 18:39:39 -0000 charles, we're not defining interop with respect to any currently defined platform. the SL platform is going to need a lot of re-tooling to implement the protocols we're supporting, and since opensim was originally based no the SL legacy protocols, my guess is that it also will need some retooling. we have, however, deployed patches to opensim to implement a previous version of OGP, so we know it's not impossible. your knowledge of OpenSim deployment patterns is of great interest to me personally; mostly because OpenSim tends to experiment a lot more than SL. and honestly... the OSGrid deployment pattern of "some centralized, some federated" services is one of the things i think all the people working on OGP are interested in. so i think to answer your question precisely, i'd have to invoke Zen and say "mu!" that is, i think it's not _completely_ related. we're not defining the protocol in terms of the current structure of OpenSim, but i think all of us are interested in making it possible to use OGP/VWRAP to define a protocol that is equally useful to Linden as it is to you at OSGrid and zha, et al at IBM as it is to anyone interested in open virtual worlds. so rather than saying "yeah, we're going to support this specific mode of OpenSim," it's probably more appropriate to say, "we're very interested in the operational experiences of people who have used OpenSim in both stand-alone and UGAIM mode. since it's an open standard, we invite Teravus, Adam, JHurliman and yourself to tell us what's easy to do in OpenSim and what's hard to do, and after we get through the chartering process, there's likely to be several more rounds of discussions about what people think can and can't be easily implemented and deployed." but at the end of the day, i think there's going to be code changes for both OpenSim, Linden and all the viewers. -cheers -meadhbh On Sun, Aug 30, 2009 at 6:19 PM, Charles Krinke wrote: > I'm confused with all that is going on and need to ask my two main questi= ons > again. > > "Are we considering interop with virtual worlds running OpenSim which do = not > run agent domains but rather a similar, but not quite identical notion we > call UGAIM (User, Grid, Asset, Inventory, Messaging) servers?" > > "Are we considering a full handoff? That is, a user on an OpenSim grid ma= y > teleport to a SecondLife grid and retain its connection to the OpenSim > UGAIM, in an analogous fashion that a user has been demonstrated to telep= ort > from the Betagrid to OSGrid using OGP last year?" > > Charles > > ________________________________ > From: Meadhbh Siobhan > To: Kari Lippert > Cc: ogpx@ietf.org; dcrocker@bbiw.net > Sent: Sunday, August 30, 2009 11:50:46 AM > Subject: Re: [ogpx] one virtual world, or many? > > On Sun, Aug 30, 2009 at 11:20 AM, Kari Lippert > wrote: >> The network/internet analogy is great. I vote base hit.... and would >> like to emphasize that, given current usage of the words, the answer >> to >> >>> =A0 =A0 Are we connecting two virtual worlds or is the result a single >>> =A0 =A0 virtual world? >> >> is yes, sort of. >> >> As I understand it, VWRAP is designed to connect/allow >> interoperability between two or more independent/distinct/individual >> virtual environments/regions/worlds into what appears to the user as a >> single environment/region/world/universe. This single >> environment/region/world/universe is in fact multiple >> independent/distinct/individual virtual environments/regions/worlds >> whose boundaries could be administrative or technological but the >> distinction matters not. >> >> Is that right? >> >> Kari >> > > this is an interesting use case, but not what OGPX/VWRAP was proposed > to address. > > MMOX remains as a venue for the discussion of integrating technically > diverse virtual worlds. > > >> >> >> >> >> >> On Sun, Aug 30, 2009 at 11:40 AM, Dave CROCKER wrote: >>> Folks, >>> >>> >>> Pre-game. >>> >>> Confusion and disagreement that includes the term "virtual world" is >>> proving >>> tenacious, in spite of extensive and substantive discussion. =A0Typical= ly, >>> something this persistent means either that some concept(s) lack shared >>> definition or that competing technical paradigms are present. >>> >>> As was noted many message ago, there's a good chance that much of the >>> disagreement is really about the meaning of the term. =A0That is, that >>> apparent >>> disagreements about such things as scope of work is really about scope = of >>> this one term. =A0That, at least, is my own reading of the discussions.= =A0I >>> think people are using the term differently. =A0If we can get to the po= int >>> of >>> using it the same >>> way, my sense is that we will find that disagreements about actual work >>> to >>> be done, and its use, are rather small. >>> >>> In other words, I think the persistence of debate that keeps using that >>> term >>> "virtual world" means we have to resolve it before we can make serious >>> progress. These sorts of things never seem to go away without explicit >>> resolution. =A0While much of the earlier attempts to resolve this look = like >>> they helped quite a bit, it seems clear that a bit more effort is neede= d. >>> >>> >>> >>> The wind-up. >>> >>> Since the crux of the challenge keeps coming back to what >>> interoperability >>> will >>> or will not be provided -- with at least one additional point about >>> whether >>> the >>> current work must be used internal to a service or only used /between/ >>> services >>> -- permit me a moment of theft from Internet history and constructs. = =A0I >>> think it >>> can be applicable here: >>> >>> =A0 Network vs. Internetwork. >>> >>> =A0 "A" virtual world vs. Multiple virtual worlds. >>> >>> But hold on. =A0I'm not necessarily going to suggest mapping the two se= ts >>> as >>> one-to-one directly... >>> >>> Originally, a network was a discrete technical set. =A0X.25. =A0NCP. = =A0XNS. >>> Netware. >>> Whatever. =A0Both technology and administration had the same boundary. >>> =A0Your >>> network might use one technology and mine might use another. =A0But eve= n if >>> they >>> used the same technology, one was mine and the other was yours. =A0So I >>> tend >>> to >>> view interaction across administrative boundaries as far more interesti= ng >>> to >>> internetworking than whether different technologies are used: >>> >>> =A0 >>> >>> The term Internet has come to mean a single, unified, global service. = =A0It >>> crosses administrative boundaries. =A0Does IBM internally operate a >>> 'network' >>> or >>> an 'internetwork'? =A0Either choice is reasonable, depending on what is= the >>> focus. I think we don't need to resolve the equivalent question here. >>> >>> There is universal agreement that there is a single global service, >>> comprising many independent smaller services, and that that single, >>> larger >>> thing is "The" Internet. >>> >>> What we tend to forget is that there probably are other Internets that >>> don't >>> (directly) interoperate with the global one. =A0They are off "The Inter= net" >>> grid >>> and are on their own. =A0They are likely also "an" Internet. =A0These d= ays, >>> they >>> might be running TCP/IP, but they don't have to. =A0For example: >>> >>> =A0 >>> >>> Some uses of "virtual world" appear to mean an administrative boundary >>> and >>> others appear to mean a technical boundary. This is the sort of thing w= e >>> need to resolve. >>> >>> >>> >>> The pitch. >>> >>> I suggest ignoring technical differences within an administrative domai= n >>> and >>> even across different administrative domains. =A0Simply, VWrap is used = to >>> connect together administrative domains running simulations. >>> >>> =A0 =A0 I'm running one simulation and you are running another. =A0We u= se >>> =A0 =A0 VWrap to interoperate. >>> >>> =A0 =A0 Are we connecting two virtual worlds or is the result a single >>> =A0 =A0 virtual world? >>> >>> Some other folk might not interoperate with our unified service. =A0The= y >>> are >>> running their own thing. =A0Are they running a different virtual world = or, >>> perhaps, a different set of multiple virtual worlds? >>> >>> >>> >>> The swing. >>> >>> I suggest that: >>> >>> =A0 =A0 Any set of independent administrative domains that interoperate >>> =A0 =A0 together, using VWrap, creates a /single/ virtual world. >>> >>> =A0 =A0 Each independent administrative domain is running /part/ of tha= t >>> single >>> =A0 =A0 virtual world. =A0(The part might be one Region, or Agent, or i= t might >>> be >>> =A0 =A0 many of both or any combination.) >>> >>> =A0 =A0 Hence, I am suggesting that an integrated VWrap environment has= a >>> =A0 =A0 comparable quality to an integrated internet environment that w= e call >>> =A0 =A0 "The" Internet. =A0One service. >>> >>> If you are running a simulation that is not part of an integrated, >>> interoperable >>> VWrap environment, you are in a different virtual world. >>> >>> =A0 =A0 If you are part of an interoperable VWrap service, you are in a >>> =A0 =A0 single virtual world. >>> >>> It doesn't matter what you run internally. =A0What matters is integrati= on >>> to >>> the >>> interoperable service using VWrap. >>> >>> >>> >>> Base hit or strikeout? >>> >>> d/ >>> -- >>> >>> =A0Dave Crocker >>> =A0Brandenburg InternetWorking >>> =A0bbiw.net >>> >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >>> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From suzyque@gmail.com Mon Aug 31 12:07:07 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1743A6EAD for ; Mon, 31 Aug 2009 12:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKmX4Rm0GK58 for ; Mon, 31 Aug 2009 12:07:05 -0700 (PDT) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id DD38D3A6EAE for ; Mon, 31 Aug 2009 12:07:04 -0700 (PDT) Received: by gxk26 with SMTP id 26so3699886gxk.18 for ; Mon, 31 Aug 2009 12:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=CVLgxn/vAmB72ulTNG1S6HReEfxnoT3HJlNLKA7L5Wo=; b=mgMPkVplZdZItcX7wdevqfQtZAgQZVzZg7KgEzyfPRXenI/AcF7Dp8pcesH3N6+fSH 99N6co4hfX5GfYpozZAVK2ZQHkpvwU5ZlTfFLW0rvEBofLKMK1TsCr56ewHgkBknUZoR gHUNWJY1ZQEGxFan6VjPfiOXGgLhhoBM92ksE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=X5o0yZYz9HsHv23Hl7xLprX/x2ybFQlAZUc9jMduIPIcWGMMTvVeOZ61AbJHt9R1+0 +hdUqHcVdhn9FLtoHKeVqL9I+CBpzZAVhNUG/irEtdD/NIHAbYIqQg/r7idan9y9et6K Mw9HxZyAlLTsH6kNNXiPGVewpZs4HiCjqnBWc= MIME-Version: 1.0 Sender: suzyque@gmail.com Received: by 10.150.71.4 with SMTP id t4mr9736405yba.226.1251745629475; Mon, 31 Aug 2009 12:07:09 -0700 (PDT) In-Reply-To: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> Date: Mon, 31 Aug 2009 15:07:09 -0400 X-Google-Sender-Auth: 652dded2c31b8aa5 Message-ID: <2bd5b7f10908311207rdbc7be0ue9d69b8273e6ba4b@mail.gmail.com> From: Suzy Deffeyes To: Infinity Linden Content-Type: multipart/alternative; boundary=000e0cd6d0609811f2047274bdb1 Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: suzyq@pobox.com List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 19:07:07 -0000 --000e0cd6d0609811f2047274bdb1 Content-Type: text/plain; charset=ISO-8859-1 Hi Infinity, I think the Charter looks good, and I support moving forward with submitting this to the IETF. I think it accurately describes the scope of what we want to do, and is clear in its description. I am ready to move to working on the protocol and implementation. Let the interface definitions commence! Suzy Deffeyes / Pixel Gausman IBM On Fri, Aug 28, 2009 at 2:27 PM, Infinity Linden wrote: > okay... here's what i think we've all agreed to. i've taken the > liberty of using the VWRAP name since it seems to me we have consensus > around that name. > > also note that i still have the ogpx@ietf.org email list in the > charter text, since we don't have the VWRAP mailing list up yet. > > but the rest of it should be "correct" based on discussions. please > look it over and tell me if i've missed something. > > -cheers > -meadhbh > > Working Group Name: > > Virtual Worlds Region Agent Protocol (VWRAP) > > Chairs: > > TBD > > Area and Area Directors: > > Applications Area > > Lisa Dusseault > Alexey Melnikov > > Responsible Area Director: > > TBD > > Mailing List: > > ogpx@ietf.org > http://www.ietf.org/mailman/listinfo/ogpx > > Description of Working Group: > > The working group will define the Virtual Worlds Region Agent Protocol > (VWRAP) for collaborative 3-dimensional virtual worlds. The protocol > permits users to interact with each other while represented as > "avatars," or digital representations of the user. Within a single > virtual world, avatars exist in at most one location in a shared > virtual space. Conforming client applications use the protocol to > manipulate and move the user's avatar, create objects in a virtual > world, interact with other users and their surroundings and consume > and create media and information from sources inside and outside their > virtual world. > > Adjacent locations in virtual worlds accessible by this protocol may > be explicitly partitioned into "regions" to facilitate the > computational and communication load balancing required to simulate > the virtual environment. Such virtual worlds may consist of regions > administered by distinct organizations. Though these virtual worlds > may be partitioned, they remain "un-sharded;" all inhabitants and > objects in a particular location in a virtual world may initiate > interaction with all other inhabitants and objects in that location; > and, service endpoint addresses refer to at most one location. The > state of a virtual world is independent of the client applications > that access it and may persist between user sessions. > > Regions and services implemented according to the specifications may > be deployed by separate organizations with varying policies and trust > domains. The OGPX protocols will provide the mechanisms for these > virtual world services to interoperate, when permitted by policy and > shared trust domains. To support the exegesis of the specifications, > the group may define a non-exhaustive set of non-normative policies > protocol participants may enforce. > > The protocol should describe interaction semantics for these virtual > worlds, independent of transport, leveraging existing standards where > practical. It should define interoperability expectations for server > to server interactions as well as client-server interactions. Though > the protocol is independent of transport, early interoperability > trials used HTTP(S) for non-real-time messages. The working group will > define specific features that must be replicated in other transports > and will define the use of HTTP(S) as a transport of protocol > messages. > > Foundational components of the protocol include the publication of: > > * an abstract type system, suitable for describing the application > protocol in an implementation neutral manner, > > * a security model describing trust relationships between > participating entities, > > * guidelines for the use of existing authentication and > confidentiality mechanisms, > > * an application-layer protocol for establishing the user's avatar > in a virtual world, > > * an application-layer protocol for moving a user's avatar between > adjacent and remote locations in a virtual world, > > * format descriptions for objects and avatars in a virtual world, and > > * an application-layer protocol for identifying agents, and > requesting information about them. > > The protocol defined by this group will carry information about the > virtual environment, its contents and its inhabitants. It is an > application layer protocol, independent of transport, based partially > on these previously published internet drafts: > > * http://tools.ietf.org/html/draft-hamrick-ogp-intro > * http://tools.ietf.org/html/draft-hamrick-llsd > * http://tools.ietf.org/html/draft-hamrick-ogp-auth > * http://tools.ietf.org/html/draft-hamrick-ogp-launch > * http://tools.ietf.org/html/draft-lentczner-ogp-base > * http://tools.ietf.org/html/draft-levine-ogp-clientcap > * http://tools.ietf.org/html/draft-levine-ogp-layering > > Goals and Milestones: > > * October 2009 "Introduction and Goals" to the IESG as an > Informational RFC > > * October 2009 "Abstract Type System for the Transmission of Dynamic > Structured Data" to the IESG as Proposed Standard > > * October 2010 "Foundational Concepts and Transport Expectations" to > the IESG as Proposed Standard > > * February 2010 "Guidelines for Host Authentication" to the IESG as > an Informational RFC > > * February 2010 "Service Establishment" to the IESG as Proposed > Standard > > * February 2010 "Client Application Launch Message" to the IESG as > an Informational RFC > > * February 2010 "Simulation Presence Establishment" to the IESG as > Proposed Standard > > * June 2010 "Primitive Object Format" to the IESG as Proposed > Standard > > * June 2010 "Digital Asset Access" to the IESG as Proposed Standard > > * June 2010 "Entity Identifiers" to the IESG as Proposed standard > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --000e0cd6d0609811f2047274bdb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Infinity,

I think the Charter looks good, and I support movin= g forward with submitting this to the IETF.=A0 I think it accurately descri= bes the scope of what we want to do, and is clear in its description.

I am ready to move to working on the protocol and implementation. Let t= he interface definitions commence!

Suzy Deffeyes / Pixel Gausman
= IBM


On Fri, Aug 28, 2009 at 2:27 PM, = Infinity Linden <infinity@lindenlab.com> wrote:
okay... here'= s what i think we've all agreed to. i've taken the
liberty of using the VWRAP name since it seems to me we have consensus
around that name.

also note that i still have the ogpx@ietf.= org email list in the
charter text, since we don't have the VWRAP mailing list up yet.

but the rest of it should be "correct" based on discussions. plea= se
look it over and tell me if i've missed something.

-cheers
-meadhbh

Working Group Name:

=A0Virtual Worlds Region Agent Protocol (VWRAP)

Chairs:

=A0TBD

Area and Area Directors:

=A0Applications Area

=A0Lisa Dusseault <lisa.dus= seault@gmail.com>
=A0Alexey Melnikov <alexey= .melnikov@isode.com>

Responsible Area Director:

=A0TBD

Mailing List:

=A0ogpx@ietf.org
=A0http://www.ietf.org/mailman/listinfo/ogpx

Description of Working Group:

The working group will define the Virtual Worlds Region Agent Protocol
(VWRAP) for =A0collaborative 3-dimensional virtual =A0worlds. The protocol<= br> permits =A0users =A0to =A0interact =A0with =A0each other =A0while =A0repres= ented =A0as
"avatars," =A0or digital representations =A0of the =A0user. Withi= n =A0a single
virtual =A0world, avatars =A0exist in =A0at most =A0one location =A0in =A0a= shared
virtual =A0space. Conforming =A0client =A0applications use =A0the protocol = =A0to
manipulate and =A0move the =A0user's avatar, create =A0objects in =A0a = virtual
world, interact =A0with other users =A0and their surroundings =A0and consum= e
and create media and information from sources inside and outside their
virtual world.

Adjacent locations =A0in virtual worlds accessible by =A0this protocol may<= br> be =A0 explicitly =A0 partitioned =A0into =A0 "regions" =A0 to = =A0facilitate =A0 the
computational =A0and communication load =A0balancing required =A0to simulat= e
the virtual =A0environment. Such virtual =A0worlds may consist =A0of region= s
administered =A0by distinct organizations. =A0Though these =A0virtual world= s
may =A0be partitioned, =A0they =A0remain "un-sharded;" =A0all inh= abitants =A0and
objects =A0in a =A0particular location =A0in =A0a virtual =A0world may =A0i= nitiate
interaction with =A0all other inhabitants and objects =A0in that location;<= br> and, service =A0endpoint addresses =A0refer to at =A0most one =A0location. = The
state of =A0a virtual =A0world is independent =A0of the =A0client applicati= ons
that access it and may persist between user sessions.

Regions and =A0services implemented according to =A0the specifications may<= br> be deployed by separate =A0organizations with varying policies and trust domains. =A0The OGPX =A0protocols will =A0provide the =A0mechanisms =A0for = these
virtual world =A0services to interoperate, when permitted =A0by policy and<= br> shared trust =A0domains. To support the exegesis =A0of the specifications,<= br> the group =A0may define a =A0non-exhaustive set of =A0non-normative policie= s
protocol participants may enforce.

The protocol =A0should describe interaction semantics =A0for these virtual<= br> worlds, independent of =A0transport, leveraging existing standards where practical. It =A0should define interoperability =A0expectations for server<= br> to server =A0interactions as well as =A0client-server interactions. Though<= br> the =A0protocol =A0is =A0independent =A0of transport, =A0early =A0interoper= ability
trials used HTTP(S) for non-real-time messages. The working group will
define specific =A0features that must be replicated =A0in other transports<= br> and =A0will =A0define =A0the use =A0of =A0HTTP(S) =A0as =A0a transport =A0o= f =A0protocol
messages.

Foundational components of the protocol include the publication of:

=A0* an abstract =A0type system, suitable for =A0describing the applicatio= n
=A0 =A0protocol in an implementation neutral manner,

=A0* a =A0 security =A0 model =A0 describing =A0trust =A0 relationships = =A0 between
=A0 =A0participating entities,

=A0* guidelines =A0 for =A0 the =A0 use =A0 of =A0existing =A0 authenticat= ion =A0 and
=A0 =A0confidentiality mechanisms,

=A0* an application-layer =A0protocol for establishing =A0the user's a= vatar
=A0 =A0in a virtual world,

=A0* an application-layer =A0protocol for moving a =A0user's avatar be= tween
=A0 =A0adjacent and remote locations in a virtual world,

=A0* format descriptions for objects and avatars in a virtual world, and
=A0* an =A0 application-layer =A0protocol =A0 for =A0identifying =A0 agent= s, =A0and
=A0 =A0requesting information about them.

The protocol =A0defined by this =A0group will carry information =A0about th= e
virtual =A0environment, =A0its contents =A0and =A0its =A0inhabitants. =A0It= is =A0an
application layer protocol, =A0independent of transport, based partially on these previously published internet drafts:

=A0* http://tools.ietf.org/html/draft-hamrick-ogp-intro
=A0* http://tools.ietf.org/html/draft-hamrick-llsd
=A0* http://tools.ietf.org/html/draft-hamrick-ogp-auth
=A0* http://tools.ietf.org/html/draft-hamrick-ogp-launch
=A0* http://tools.ietf.org/html/draft-lentczner-ogp-base
=A0* http://tools.ietf.org/html/draft-levine-ogp-clientcap =A0* http://tools.ietf.org/html/draft-levine-ogp-layering

Goals and Milestones:

=A0* October =A02009 =A0 "Introduction =A0and =A0Goals" =A0to = =A0the =A0 IESG =A0as =A0an
=A0 =A0Informational RFC

=A0* October 2009 "Abstract Type System for the Transmission of Dynam= ic
=A0 =A0Structured Data" to the IESG as Proposed Standard

=A0* October 2010 "Foundational Concepts and Transport Expectations&q= uot; to
=A0 =A0the IESG as Proposed Standard

=A0* February 2010 "Guidelines for =A0Host Authentication" to th= e IESG as
=A0 =A0an Informational RFC

=A0* February =A02010 "Service =A0Establishment" =A0to the =A0IE= SG as =A0Proposed
=A0 =A0Standard

=A0* February 2010 =A0"Client Application Launch Message" to =A0= the IESG as
=A0 =A0an Informational RFC

=A0* February 2010 =A0"Simulation Presence Establishment" to =A0= the IESG as
=A0 =A0Proposed Standard

=A0* June =A02010 =A0"Primitive Object =A0Format" =A0to =A0the = =A0IESG as =A0Proposed
=A0 =A0Standard

=A0* June 2010 "Digital Asset Access" to the IESG as Proposed St= andard

=A0* June 2010 "Entity Identifiers" to the IESG as Proposed stan= dard
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx

--000e0cd6d0609811f2047274bdb1-- From dcolivares@gmail.com Mon Aug 31 12:55:46 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB4B3A68D1 for ; Mon, 31 Aug 2009 12:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yjhrqjASGuY for ; Mon, 31 Aug 2009 12:55:45 -0700 (PDT) Received: from mail-vw0-f177.google.com (mail-vw0-f177.google.com [209.85.212.177]) by core3.amsl.com (Postfix) with ESMTP id 6FA5B3A68B8 for ; Mon, 31 Aug 2009 12:55:44 -0700 (PDT) Received: by vws7 with SMTP id 7so2991672vws.29 for ; Mon, 31 Aug 2009 12:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zHwYnCR+ggsSyYytktfEMFS0ltpFCrhb3NoJUzExPdU=; b=hqvREVX5TmTAHCG16rek6N1ysob9lwZmF2ufhIahWaZGwvOKHpZ7si9xyRGiMGviKZ vrtfPvZtKYk28ohAYA80S32p/oJydFDY4AUnItyt88nReV81C7OtyQ5Tq/HLsGq3sJrO PHwooTyni1iJJNA5AupG1AC1JP/98XkgBXQ0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XXn4JFUaEC9QTbsumXgz59ZTZvlNdjZAK9Ha+/LaDZst/9PyTZk2GPDUGwCYrQ2kjO 2SKDZWjHA5rpCDn6VWst1L6oGeNjQ3/fJkUw58etOLw4qYMYxh1y9dmphUrc9tux7I1X 4EUcr55yjSvYczAsziyJknsJVi44IfZHtLJ9M= MIME-Version: 1.0 Received: by 10.220.17.4 with SMTP id q4mr6994403vca.105.1251748549399; Mon, 31 Aug 2009 12:55:49 -0700 (PDT) In-Reply-To: <2bd5b7f10908311207rdbc7be0ue9d69b8273e6ba4b@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <2bd5b7f10908311207rdbc7be0ue9d69b8273e6ba4b@mail.gmail.com> Date: Mon, 31 Aug 2009 15:55:49 -0400 Message-ID: From: Dan Olivares To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Infinity Linden Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 19:55:46 -0000 Hey there, I think the charter looks reasonable as well. As I said earlier, i'm not entirely convinced the messages should all be 'HTTP' based however, I'm willing to give it a try as a 1st protocol. At this point in time, I'd like to take part in discussions about the future protocols and work with others on implementations of the server side of the protocols so that there is some solid, result based, feedback that can come back to this list. Dan Olivares (OpenSimulator core developer) On Mon, Aug 31, 2009 at 3:07 PM, Suzy Deffeyes wrote: > > Hi Infinity, > > I think the Charter looks good, and I support moving forward with submitt= ing > this to the IETF.=A0 I think it accurately describes the scope of what we= want > to do, and is clear in its description. > > I am ready to move to working on the protocol and implementation. Let the > interface definitions commence! > > Suzy Deffeyes / Pixel Gausman > IBM > > > On Fri, Aug 28, 2009 at 2:27 PM, Infinity Linden > wrote: >> >> okay... here's what i think we've all agreed to. i've taken the >> liberty of using the VWRAP name since it seems to me we have consensus >> around that name. >> >> also note that i still have the ogpx@ietf.org email list in the >> charter text, since we don't have the VWRAP mailing list up yet. >> >> but the rest of it should be "correct" based on discussions. please >> look it over and tell me if i've missed something. >> >> -cheers >> -meadhbh >> >> Working Group Name: >> >> =A0Virtual Worlds Region Agent Protocol (VWRAP) >> >> Chairs: >> >> =A0TBD >> >> Area and Area Directors: >> >> =A0Applications Area >> >> =A0Lisa Dusseault >> =A0Alexey Melnikov >> >> Responsible Area Director: >> >> =A0TBD >> >> Mailing List: >> >> =A0ogpx@ietf.org >> =A0http://www.ietf.org/mailman/listinfo/ogpx >> >> Description of Working Group: >> >> The working group will define the Virtual Worlds Region Agent Protocol >> (VWRAP) for =A0collaborative 3-dimensional virtual =A0worlds. The protoc= ol >> permits =A0users =A0to =A0interact =A0with =A0each other =A0while =A0rep= resented =A0as >> "avatars," =A0or digital representations =A0of the =A0user. Within =A0a = single >> virtual =A0world, avatars =A0exist in =A0at most =A0one location =A0in = =A0a shared >> virtual =A0space. Conforming =A0client =A0applications use =A0the protoc= ol =A0to >> manipulate and =A0move the =A0user's avatar, create =A0objects in =A0a v= irtual >> world, interact =A0with other users =A0and their surroundings =A0and con= sume >> and create media and information from sources inside and outside their >> virtual world. >> >> Adjacent locations =A0in virtual worlds accessible by =A0this protocol m= ay >> be =A0 explicitly =A0 partitioned =A0into =A0 "regions" =A0 to =A0facili= tate =A0 the >> computational =A0and communication load =A0balancing required =A0to simu= late >> the virtual =A0environment. Such virtual =A0worlds may consist =A0of reg= ions >> administered =A0by distinct organizations. =A0Though these =A0virtual wo= rlds >> may =A0be partitioned, =A0they =A0remain "un-sharded;" =A0all inhabitant= s =A0and >> objects =A0in a =A0particular location =A0in =A0a virtual =A0world may = =A0initiate >> interaction with =A0all other inhabitants and objects =A0in that locatio= n; >> and, service =A0endpoint addresses =A0refer to at =A0most one =A0locatio= n. The >> state of =A0a virtual =A0world is independent =A0of the =A0client applic= ations >> that access it and may persist between user sessions. >> >> Regions and =A0services implemented according to =A0the specifications m= ay >> be deployed by separate =A0organizations with varying policies and trust >> domains. =A0The OGPX =A0protocols will =A0provide the =A0mechanisms =A0f= or these >> virtual world =A0services to interoperate, when permitted =A0by policy a= nd >> shared trust =A0domains. To support the exegesis =A0of the specification= s, >> the group =A0may define a =A0non-exhaustive set of =A0non-normative poli= cies >> protocol participants may enforce. >> >> The protocol =A0should describe interaction semantics =A0for these virtu= al >> worlds, independent of =A0transport, leveraging existing standards where >> practical. It =A0should define interoperability =A0expectations for serv= er >> to server =A0interactions as well as =A0client-server interactions. Thou= gh >> the =A0protocol =A0is =A0independent =A0of transport, =A0early =A0intero= perability >> trials used HTTP(S) for non-real-time messages. The working group will >> define specific =A0features that must be replicated =A0in other transpor= ts >> and =A0will =A0define =A0the use =A0of =A0HTTP(S) =A0as =A0a transport = =A0of =A0protocol >> messages. >> >> Foundational components of the protocol include the publication of: >> >> =A0* an abstract =A0type system, suitable for =A0describing the applicat= ion >> =A0 =A0protocol in an implementation neutral manner, >> >> =A0* a =A0 security =A0 model =A0 describing =A0trust =A0 relationships = =A0 between >> =A0 =A0participating entities, >> >> =A0* guidelines =A0 for =A0 the =A0 use =A0 of =A0existing =A0 authentic= ation =A0 and >> =A0 =A0confidentiality mechanisms, >> >> =A0* an application-layer =A0protocol for establishing =A0the user's ava= tar >> =A0 =A0in a virtual world, >> >> =A0* an application-layer =A0protocol for moving a =A0user's avatar betw= een >> =A0 =A0adjacent and remote locations in a virtual world, >> >> =A0* format descriptions for objects and avatars in a virtual world, and >> >> =A0* an =A0 application-layer =A0protocol =A0 for =A0identifying =A0 age= nts, =A0and >> =A0 =A0requesting information about them. >> >> The protocol =A0defined by this =A0group will carry information =A0about= the >> virtual =A0environment, =A0its contents =A0and =A0its =A0inhabitants. = =A0It is =A0an >> application layer protocol, =A0independent of transport, based partially >> on these previously published internet drafts: >> >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-intro >> =A0* http://tools.ietf.org/html/draft-hamrick-llsd >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-auth >> =A0* http://tools.ietf.org/html/draft-hamrick-ogp-launch >> =A0* http://tools.ietf.org/html/draft-lentczner-ogp-base >> =A0* http://tools.ietf.org/html/draft-levine-ogp-clientcap >> =A0* http://tools.ietf.org/html/draft-levine-ogp-layering >> >> Goals and Milestones: >> >> =A0* October =A02009 =A0 "Introduction =A0and =A0Goals" =A0to =A0the =A0= IESG =A0as =A0an >> =A0 =A0Informational RFC >> >> =A0* October 2009 "Abstract Type System for the Transmission of Dynamic >> =A0 =A0Structured Data" to the IESG as Proposed Standard >> >> =A0* October 2010 "Foundational Concepts and Transport Expectations" to >> =A0 =A0the IESG as Proposed Standard >> >> =A0* February 2010 "Guidelines for =A0Host Authentication" to the IESG a= s >> =A0 =A0an Informational RFC >> >> =A0* February =A02010 "Service =A0Establishment" =A0to the =A0IESG as = =A0Proposed >> =A0 =A0Standard >> >> =A0* February 2010 =A0"Client Application Launch Message" to =A0the IESG= as >> =A0 =A0an Informational RFC >> >> =A0* February 2010 =A0"Simulation Presence Establishment" to =A0the IESG= as >> =A0 =A0Proposed Standard >> >> =A0* June =A02010 =A0"Primitive Object =A0Format" =A0to =A0the =A0IESG a= s =A0Proposed >> =A0 =A0Standard >> >> =A0* June 2010 "Digital Asset Access" to the IESG as Proposed Standard >> >> =A0* June 2010 "Entity Identifiers" to the IESG as Proposed standard >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From cfk@pacbell.net Mon Aug 31 13:42:35 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA4228C12F for ; Mon, 31 Aug 2009 13:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi4uj6Zy-YH1 for ; Mon, 31 Aug 2009 13:42:32 -0700 (PDT) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id C293028C56B for ; Mon, 31 Aug 2009 13:42:26 -0700 (PDT) Received: (qmail 8152 invoked by uid 60001); 31 Aug 2009 20:42:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pacbell.net; s=s1024; t=1251751355; bh=ak8SdXS7iFGp+cD2ny/n5f/AVnlRu8hsHUe4+RDsE4s=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=KVT2NT9RXwRUz5UU6YhXL5+Hfr8jRMIhGess2/wJVEGenrrPWjndKieMNE/f2gSy8K0WHIk2Zfv27ND+t5qP5YYNDyqzvuDMI4CMdr9w7PAwy2cB23XT338hjGJj0z096f4bbUDGJ3ZgAnnP0BO9bJycoG3Fhkw1nZdUAsrrxHY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=yu3wnaS9nQRu4aVVi/4/Ke/8gEpByLBicQy2xDAsQJOiUjojIpR8y6JBisZbRjikkI5Kp4fRh46/daZzQPqk6RN2dJ/vKG6zW6WL7okxrbKVvuWP1HU2hpY6u5y6PiZsDr7OLb9Nj7YwNj2p91RJks9yi08bd9YcqDS8BtXs+LE=; Message-ID: <958979.4393.qm@web82605.mail.mud.yahoo.com> X-YMail-OSG: Qf2CRZ8VM1lj2NbmdeYlYKZkSf8X8VBoENEB9P49aMh7Ay_2qOznY4LoMpD0raItJjiozHZDahZqunrova.SiMx.pY_p.sy.ms.pIe1qFDB9zFYLpiasu4Ty4aF9rHKH.Qy_F3097JhwfIbTm8pxU5HdyFfTt5PT60FCBshYYjAWdNnsbNotJTC6dL_DIY1KBgD2dyUGynt3IYfXLboE0nFlJSM1UuWrSEjNi0z8UwhVumEl0DsJ_RdjlTnosFaDpr_HnWTIhWr1z_wRD0FqAEF.UgKv9sI0npjmHFF.nq2YIXj0ARUeTjhAFwsMZeYJpRPRioNwyxe_AMGtu7RWyrocKINCEFf8fZ6EEjPxNHhh7b4KfGnWHigrZ7yiWE1Pkcw- Received: from [67.120.11.69] by web82605.mail.mud.yahoo.com via HTTP; Mon, 31 Aug 2009 13:42:35 PDT X-Mailer: YahooMailRC/1358.27 YahooMailWebService/0.7.338.2 References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> <204765.27116.qm@web82605.mail.mud.yahoo.com> Date: Mon, 31 Aug 2009 13:42:35 -0700 (PDT) From: Charles Krinke To: ogpx@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1229633452-1251751355=:4393" Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 20:42:35 -0000 --0-1229633452-1251751355=:4393 Content-Type: text/plain; charset=us-ascii Dear Infinity: Thank you for your considered answer. I think our hearts are all headed in the same place. For some reason, all this discussion of names has my head spinning. But, ... that aside, as I look at interop between different grids (or virtual worlds, if you wish), I see these as analogous to transitting customs between countries. That is, there will be some things that will connect back to ones home or originating country and some things that are intrinsic to the country one is visiting, to try to draw an analogy. The things connecting back to ones home country (or grid, if we prefer), will most likely be the avatar, inventory and attachments, or at least part of the inventory and all of the avatar and attachments. The things intrinsic to the country one is visiting will most likely be the rules dealing with transactions such as buying and selling objects, permissions of editing, and ability to visit certain parts of the visiting country. To me, as long as that is a reciprocal relationship, that is, a visit from a SecondLife grid to an OpenSim is a mirror image of permissions to a visit from an OpenSim grid citizen to a SecondLife grid, then I think my enthusiasm is still "full speed ahead regardless of whether we call a pear a banana or not". Charles ________________________________ From: Meadhbh Siobhan To: Charles Krinke Cc: ogpx@ietf.org Sent: Monday, August 31, 2009 11:38:00 AM Subject: Re: [ogpx] one virtual world, or many? charles, we're not defining interop with respect to any currently defined platform. the SL platform is going to need a lot of re-tooling to implement the protocols we're supporting, and since opensim was originally based no the SL legacy protocols, my guess is that it also will need some retooling. we have, however, deployed patches to opensim to implement a previous version of OGP, so we know it's not impossible. your knowledge of OpenSim deployment patterns is of great interest to me personally; mostly because OpenSim tends to experiment a lot more than SL. and honestly... the OSGrid deployment pattern of "some centralized, some federated" services is one of the things i think all the people working on OGP are interested in. so i think to answer your question precisely, i'd have to invoke Zen and say "mu!" that is, i think it's not _completely_ related. we're not defining the protocol in terms of the current structure of OpenSim, but i think all of us are interested in making it possible to use OGP/VWRAP to define a protocol that is equally useful to Linden as it is to you at OSGrid and zha, et al at IBM as it is to anyone interested in open virtual worlds. so rather than saying "yeah, we're going to support this specific mode of OpenSim," it's probably more appropriate to say, "we're very interested in the operational experiences of people who have used OpenSim in both stand-alone and UGAIM mode. since it's an open standard, we invite Teravus, Adam, JHurliman and yourself to tell us what's easy to do in OpenSim and what's hard to do, and after we get through the chartering process, there's likely to be several more rounds of discussions about what people think can and can't be easily implemented and deployed." but at the end of the day, i think there's going to be code changes for both OpenSim, Linden and all the viewers. -cheers -meadhbh On Sun, Aug 30, 2009 at 6:19 PM, Charles Krinke wrote: > I'm confused with all that is going on and need to ask my two main questions > again. > > "Are we considering interop with virtual worlds running OpenSim which do not > run agent domains but rather a similar, but not quite identical notion we > call UGAIM (User, Grid, Asset, Inventory, Messaging) servers?" > > "Are we considering a full handoff? That is, a user on an OpenSim grid may > teleport to a SecondLife grid and retain its connection to the OpenSim > UGAIM, in an analogous fashion that a user has been demonstrated to teleport > from the Betagrid to OSGrid using OGP last year?" > > Charles > > ________________________________ > From: Meadhbh Siobhan > To: Kari Lippert > Cc: ogpx@ietf.org; dcrocker@bbiw.net > Sent: Sunday, August 30, 2009 11:50:46 AM > Subject: Re: [ogpx] one virtual world, or many? > > On Sun, Aug 30, 2009 at 11:20 AM, Kari Lippert > wrote: >> The network/internet analogy is great. I vote base hit.... and would >> like to emphasize that, given current usage of the words, the answer >> to >> >>> Are we connecting two virtual worlds or is the result a single >>> virtual world? >> >> is yes, sort of. >> >> As I understand it, VWRAP is designed to connect/allow >> interoperability between two or more independent/distinct/individual >> virtual environments/regions/worlds into what appears to the user as a >> single environment/region/world/universe. This single >> environment/region/world/universe is in fact multiple >> independent/distinct/individual virtual environments/regions/worlds >> whose boundaries could be administrative or technological but the >> distinction matters not. >> >> Is that right? >> >> Kari >> > > this is an interesting use case, but not what OGPX/VWRAP was proposed > to address. > > MMOX remains as a venue for the discussion of integrating technically > diverse virtual worlds. > > >> >> >> >> >> >> On Sun, Aug 30, 2009 at 11:40 AM, Dave CROCKER wrote: >>> Folks, >>> >>> >>> Pre-game. >>> >>> Confusion and disagreement that includes the term "virtual world" is >>> proving >>> tenacious, in spite of extensive and substantive discussion. Typically, >>> something this persistent means either that some concept(s) lack shared >>> definition or that competing technical paradigms are present. >>> >>> As was noted many message ago, there's a good chance that much of the >>> disagreement is really about the meaning of the term. That is, that >>> apparent >>> disagreements about such things as scope of work is really about scope of >>> this one term. That, at least, is my own reading of the discussions. I >>> think people are using the term differently. If we can get to the point >>> of >>> using it the same >>> way, my sense is that we will find that disagreements about actual work >>> to >>> be done, and its use, are rather small. >>> >>> In other words, I think the persistence of debate that keeps using that >>> term >>> "virtual world" means we have to resolve it before we can make serious >>> progress. These sorts of things never seem to go away without explicit >>> resolution. While much of the earlier attempts to resolve this look like >>> they helped quite a bit, it seems clear that a bit more effort is needed. >>> >>> >>> >>> The wind-up. >>> >>> Since the crux of the challenge keeps coming back to what >>> interoperability >>> will >>> or will not be provided -- with at least one additional point about >>> whether >>> the >>> current work must be used internal to a service or only used /between/ >>> services >>> -- permit me a moment of theft from Internet history and constructs. I >>> think it >>> can be applicable here: >>> >>> Network vs. Internetwork. >>> >>> "A" virtual world vs. Multiple virtual worlds. >>> >>> But hold on. I'm not necessarily going to suggest mapping the two sets >>> as >>> one-to-one directly... >>> >>> Originally, a network was a discrete technical set. X.25. NCP. XNS. >>> Netware. >>> Whatever. Both technology and administration had the same boundary. >>> Your >>> network might use one technology and mine might use another. But even if >>> they >>> used the same technology, one was mine and the other was yours. So I >>> tend >>> to >>> view interaction across administrative boundaries as far more interesting >>> to >>> internetworking than whether different technologies are used: >>> >>> >>> >>> The term Internet has come to mean a single, unified, global service. It >>> crosses administrative boundaries. Does IBM internally operate a >>> 'network' >>> or >>> an 'internetwork'? Either choice is reasonable, depending on what is the >>> focus. I think we don't need to resolve the equivalent question here. >>> >>> There is universal agreement that there is a single global service, >>> comprising many independent smaller services, and that that single, >>> larger >>> thing is "The" Internet. >>> >>> What we tend to forget is that there probably are other Internets that >>> don't >>> (directly) interoperate with the global one. They are off "The Internet" >>> grid >>> and are on their own. They are likely also "an" Internet. These days, >>> they >>> might be running TCP/IP, but they don't have to. For example: >>> >>> >>> >>> Some uses of "virtual world" appear to mean an administrative boundary >>> and >>> others appear to mean a technical boundary. This is the sort of thing we >>> need to resolve. >>> >>> >>> >>> The pitch. >>> >>> I suggest ignoring technical differences within an administrative domain >>> and >>> even across different administrative domains. Simply, VWrap is used to >>> connect together administrative domains running simulations. >>> >>> I'm running one simulation and you are running another. We use >>> VWrap to interoperate. >>> >>> Are we connecting two virtual worlds or is the result a single >>> virtual world? >>> >>> Some other folk might not interoperate with our unified service. They >>> are >>> running their own thing. Are they running a different virtual world or, >>> perhaps, a different set of multiple virtual worlds? >>> >>> >>> >>> The swing. >>> >>> I suggest that: >>> >>> Any set of independent administrative domains that interoperate >>> together, using VWrap, creates a /single/ virtual world. >>> >>> Each independent administrative domain is running /part/ of that >>> single >>> virtual world. (The part might be one Region, or Agent, or it might >>> be >>> many of both or any combination.) >>> >>> Hence, I am suggesting that an integrated VWrap environment has a >>> comparable quality to an integrated internet environment that we call >>> "The" Internet. One service. >>> >>> If you are running a simulation that is not part of an integrated, >>> interoperable >>> VWrap environment, you are in a different virtual world. >>> >>> If you are part of an interoperable VWrap service, you are in a >>> single virtual world. >>> >>> It doesn't matter what you run internally. What matters is integration >>> to >>> the >>> interoperable service using VWrap. >>> >>> >>> >>> Base hit or strikeout? >>> >>> d/ >>> -- >>> >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>> >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >>> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0-1229633452-1251751355=:4393 Content-Type: text/html; charset=us-ascii
Dear Infinity:

Thank you for your considered answer. I think our hearts are all headed in the same place. For some reason, all this discussion of names has my head spinning.

But, ... that aside, as I look at interop between different grids (or virtual worlds, if you wish), I see these as analogous to transitting customs between countries.

That is, there will be some things that will connect back to ones home or originating country and some things that are intrinsic to the country one is visiting, to try to draw an analogy.

The things connecting back to ones home country (or grid, if we prefer), will most likely be the avatar, inventory and attachments, or at least part of the inventory and all of the avatar and attachments.

The things intrinsic to the country one is visiting will most likely be the rules dealing with transactions such as buying and selling objects, permissions of editing, and ability to visit certain parts of the visiting country.

To me, as long as that is a reciprocal relationship, that is, a visit from a SecondLife grid to an OpenSim is a mirror image of permissions to a visit from an OpenSim grid citizen to a SecondLife grid, then I think my enthusiasm is still "full speed ahead regardless of whether we call a pear a banana or not".

Charles

From: Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: ogpx@ietf.org
Sent: Monday, August 31, 2009 11:38:00 AM
Subject: Re: [ogpx] one virtual world, or many?

charles,

we're not defining interop with respect to any currently defined platform.

the SL platform is going to need a lot of re-tooling to implement the
protocols we're supporting, and since opensim was originally based no
the SL legacy protocols, my guess is that it also will need some
retooling.

we have, however, deployed patches to opensim to implement a previous
version of OGP, so we know it's not impossible.

your knowledge of OpenSim deployment patterns is of great interest to
me personally; mostly because OpenSim tends to experiment a lot more
than SL. and honestly... the OSGrid deployment pattern of "some
centralized, some federated" services is one of the things i think all
the people working on OGP are interested in.

so i think to answer your question precisely, i'd have to invoke Zen
and say "mu!"

that is, i think it's not _completely_ related. we're not defining the
protocol in terms of the current structure of OpenSim, but i think all
of us are interested in making it possible to use OGP/VWRAP to define
a protocol that is equally useful to Linden as it is to you at OSGrid
and zha, et al at IBM as it is to anyone interested in open virtual
worlds.

so rather than saying "yeah, we're going to support this specific mode
of OpenSim," it's probably more appropriate to say, "we're very
interested in the operational experiences of people who have used
OpenSim in both stand-alone and UGAIM mode. since it's an open
standard, we invite Teravus, Adam, JHurliman and yourself to tell us
what's easy to do in OpenSim and what's hard to do, and after we get
through the chartering process, there's likely to be several more
rounds of discussions about what people think can and can't be easily
implemented and deployed."

but at the end of the day, i think there's going to be code changes
for both OpenSim, Linden and all the viewers.

-cheers
-meadhbh

On Sun, Aug 30, 2009 at 6:19 PM, Charles Krinke<cfk@pacbell.net> wrote:
> I'm confused with all that is going on and need to ask my two main questions
> again.
>
> "Are we considering interop with virtual worlds running OpenSim which do not
> run agent domains but rather a similar, but not quite identical notion we
> call UGAIM (User, Grid, Asset, Inventory, Messaging) servers?"
>
> "Are we considering a full handoff? That is, a user on an OpenSim grid may
> teleport to a SecondLife grid and retain its connection to the OpenSim
> UGAIM, in an analogous fashion that a user has been demonstrated to teleport
> from the Betagrid to OSGrid using OGP last year?"
>
> Charles
>
> ________________________________
> From: Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
> To: Kari Lippert <kari.lippert@gmail.com>
> Cc: ogpx@ietf.org; dcrocker@bbiw.net
> Sent: Sunday, August 30, 2009 11:50:46 AM
> Subject: Re: [ogpx] one virtual world, or many?
>
> On Sun, Aug 30, 2009 at 11:20 AM, Kari Lippert<kari.lippert@gmail.com>
> wrote:
>> The network/internet analogy is great. I vote base hit.... and would
>> like to emphasize that, given current usage of the words, the answer
>> to
>>
>>>     Are we connecting two virtual worlds or is the result a single
>>>     virtual world?
>>
>> is yes, sort of.
>>
>> As I understand it, VWRAP is designed to connect/allow
>> interoperability between two or more independent/distinct/individual
>> virtual environments/regions/worlds into what appears to the user as a
>> single environment/region/world/universe. This single
>> environment/region/world/universe is in fact multiple
>> independent/distinct/individual virtual environments/regions/worlds
>> whose boundaries could be administrative or technological but the
>> distinction matters not.
>>
>> Is that right?
>>
>> Kari
>>
>
> this is an interesting use case, but not what OGPX/VWRAP was proposed
> to address.
>
> MMOX remains as a venue for the discussion of integrating technically
> diverse virtual worlds.
>
>
>>
>>
>>
>>
>>
>> On Sun, Aug 30, 2009 at 11:40 AM, Dave CROCKER<dhc@dcrocker.net> wrote:
>>> Folks,
>>>
>>>
>>> Pre-game.
>>>
>>> Confusion and disagreement that includes the term "virtual world" is
>>> proving
>>> tenacious, in spite of extensive and substantive discussion.  Typically,
>>> something this persistent means either that some concept(s) lack shared
>>> definition or that competing technical paradigms are present.
>>>
>>> As was noted many message ago, there's a good chance that much of the
>>> disagreement is really about the meaning of the term.  That is, that
>>> apparent
>>> disagreements about such things as scope of work is really about scope of
>>> this one term.  That, at least, is my own reading of the discussions.  I
>>> think people are using the term differently.  If we can get to the point
>>> of
>>> using it the same
>>> way, my sense is that we will find that disagreements about actual work
>>> to
>>> be done, and its use, are rather small.
>>>
>>> In other words, I think the persistence of debate that keeps using that
>>> term
>>> "virtual world" means we have to resolve it before we can make serious
>>> progress. These sorts of things never seem to go away without explicit
>>> resolution.  While much of the earlier attempts to resolve this look like
>>> they helped quite a bit, it seems clear that a bit more effort is needed.
>>>
>>>
>>>
>>> The wind-up.
>>>
>>> Since the crux of the challenge keeps coming back to what
>>> interoperability
>>> will
>>> or will not be provided -- with at least one additional point about
>>> whether
>>> the
>>> current work must be used internal to a service or only used /between/
>>> services
>>> -- permit me a moment of theft from Internet history and constructs.  I
>>> think it
>>> can be applicable here:
>>>
>>>   Network vs. Internetwork.
>>>
>>>   "A" virtual world vs. Multiple virtual worlds.
>>>
>>> But hold on.  I'm not necessarily going to suggest mapping the two sets
>>> as
>>> one-to-one directly...
>>>
>>> Originally, a network was a discrete technical set.  X.25.  NCP.  XNS.
>>> Netware.
>>> Whatever.  Both technology and administration had the same boundary.
>>>  Your
>>> network might use one technology and mine might use another.  But even if
>>> they
>>> used the same technology, one was mine and the other was yours.  So I
>>> tend
>>> to
>>> view interaction across administrative boundaries as far more interesting
>>> to
>>> internetworking than whether different technologies are used:
>>>
>>>   <http://www.faqs.org/rfcs/rfc1775.html>
>>>
>>> The term Internet has come to mean a single, unified, global service.  It
>>> crosses administrative boundaries.  Does IBM internally operate a
>>> 'network'
>>> or
>>> an 'internetwork'?  Either choice is reasonable, depending on what is the
>>> focus. I think we don't need to resolve the equivalent question here.
>>>
>>> There is universal agreement that there is a single global service,
>>> comprising many independent smaller services, and that that single,
>>> larger
>>> thing is "The" Internet.
>>>
>>> What we tend to forget is that there probably are other Internets that
>>> don't
>>> (directly) interoperate with the global one.  They are off "The Internet"
>>> grid
>>> and are on their own.  They are likely also "an" Internet.  These days,
>>> they
>>> might be running TCP/IP, but they don't have to.  For example:
>>>
>>>   <http://www.dtnrg.org/wiki>
>>>
>>> Some uses of "virtual world" appear to mean an administrative boundary
>>> and
>>> others appear to mean a technical boundary. This is the sort of thing we
>>> need to resolve.
>>>
>>>
>>>
>>> The pitch.
>>>
>>> I suggest ignoring technical differences within an administrative domain
>>> and
>>> even across different administrative domains.  Simply, VWrap is used to
>>> connect together administrative domains running simulations.
>>>
>>>     I'm running one simulation and you are running another.  We use
>>>     VWrap to interoperate.
>>>
>>>     Are we connecting two virtual worlds or is the result a single
>>>     virtual world?
>>>
>>> Some other folk might not interoperate with our unified service.  They
>>> are
>>> running their own thing.  Are they running a different virtual world or,
>>> perhaps, a different set of multiple virtual worlds?
>>>
>>>
>>>
>>> The swing.
>>>
>>> I suggest that:
>>>
>>>     Any set of independent administrative domains that interoperate
>>>     together, using VWrap, creates a /single/ virtual world.
>>>
>>>     Each independent administrative domain is running /part/ of that
>>> single
>>>     virtual world.  (The part might be one Region, or Agent, or it might
>>> be
>>>     many of both or any combination.)
>>>
>>>     Hence, I am suggesting that an integrated VWrap environment has a
>>>     comparable quality to an integrated internet environment that we call
>>>     "The" Internet.  One service.
>>>
>>> If you are running a simulation that is not part of an integrated,
>>> interoperable
>>> VWrap environment, you are in a different virtual world.
>>>
>>>     If you are part of an interoperable VWrap service, you are in a
>>>     single virtual world.
>>>
>>> It doesn't matter what you run internally.  What matters is integration
>>> to
>>> the
>>> interoperable service using VWrap.
>>>
>>>
>>>
>>> Base hit or strikeout?
>>>
>>> d/
>>> --
>>>
>>>  Dave Crocker
>>>  Brandenburg InternetWorking
>>>  bbiw.net
>>>
>>> _______________________________________________
>>> ogpx mailing list
>>> ogpx@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
--0-1229633452-1251751355=:4393-- From infinity@lindenlab.com Mon Aug 31 14:28:49 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF5B28C24E for ; Mon, 31 Aug 2009 14:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3GMngyYZuFa for ; Mon, 31 Aug 2009 14:28:48 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 4836C28C17A for ; Mon, 31 Aug 2009 14:28:48 -0700 (PDT) Received: by ewy3 with SMTP id 3so923962ewy.42 for ; Mon, 31 Aug 2009 14:28:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.211.130.19 with SMTP id h19mr6050454ebn.54.1251754133628; Mon, 31 Aug 2009 14:28:53 -0700 (PDT) In-Reply-To: <4A9BE0B0.5010508@dcrocker.net> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <4A9BE0B0.5010508@dcrocker.net> Date: Mon, 31 Aug 2009 14:28:53 -0700 Message-ID: <3a880e2c0908311428l3e5fed02v310c3b707268a4e8@mail.gmail.com> From: Infinity Linden To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 21:28:49 -0000 hmm... okay... i think i see what you're saying. i would paraphrase it as "if you're not proposing using the term 'virtual world' to mean something with a specific meaning, maybe use it a couple times in the beginning of the charter to be evocative of the group's intended work, but go through most of the other uses in the charter and see if we can't substitute it's use for a more specific term, one that has less ambiguity." sure. i can sign on to that effort. i think it's probably a good idea. that way we can maintain the term as a more abstract description and use it only when we need to maintain that ambiguity. lemme go fire up the text editor and see what i can come up with. On Mon, Aug 31, 2009 at 7:39 AM, Dave CROCKER wrote: > > > Meadhbh Siobhan wrote: >> >> so. this is an interesting one. >> >> those of us who called for the OGPX BoF are in agreement that the term >> "virtual world" is informational only. > > > This calls for an alternative that hadn't occurred to me. > > The charter currently has the string "virtual world" thirteen times. =A0A= nd it > is used heavily in discussions on this list. > > That level use of use essentially guarantees that the string is not merel= y > informative. =A0It really does have to have specific technical meaning th= at > folks agree on. > > But since this latest round suggests, once again, that gaining agreement = on > consistent technical use of the string will remain problematic, and since > you are pointing out that there was an intent to have it NOT BE a technic= al > term... > > =A0 =A0 My suggest is to remove all occurrences of the term from the char= ter, > =A0 =A0 except for the two in the first sentence of the draft charters > Description > =A0 =A0 section. > > In other words, say that vwrap provides a service in virtual world > simulation, but then make all other references be in terms of vwrap-speci= fic > technical constructs. =A0regions, agents, etc. > > > > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From carlo@alinoe.com Mon Aug 31 15:04:01 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601FE28C258 for ; Mon, 31 Aug 2009 15:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piiTDs6aWIDm for ; Mon, 31 Aug 2009 15:04:00 -0700 (PDT) Received: from viefep11-int.chello.at (viefep11-int.chello.at [62.179.121.31]) by core3.amsl.com (Postfix) with ESMTP id 0FB993A6C69 for ; Mon, 31 Aug 2009 15:03:59 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090831220410.MHSV793.viefep11-int.chello.at@edge04.upc.biz>; Tue, 1 Sep 2009 00:04:10 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id bA451c01b0FlQed04A460j; Tue, 01 Sep 2009 00:04:10 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MiF06-0008AK-7A; Tue, 01 Sep 2009 00:05:22 +0200 Date: Tue, 1 Sep 2009 00:05:22 +0200 From: Carlo Wood To: Kari Lippert Message-ID: <20090831220522.GA29965@alinoe.com> References: <20090831170006.GB15637@alinoe.com> <382d73da0908311034u50baa09fqcdbed2a478df99f8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <382d73da0908311034u50baa09fqcdbed2a478df99f8@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] Definitions of terms to be used in my (our?) communication X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 22:04:01 -0000 On Mon, Aug 31, 2009 at 01:34:50PM -0400, Kari Lippert wrote: > Personally I would drop the use of "LAND" and "ADJACENT REGIONS" but > I think these terms, as defined here are the right set based on the > lengthy conversations I started yesterday morning. Using these terms > it should now be rather trivial to restate the Charter in a way that > captures the essence of the effort's intent. > > Kari thanks and since Infinity didn't give replacement terms in his reply (he only said 'this term is not defined by us in past 2 years') I see no other alternative than to use these terms. > On Mon, Aug 31, 2009 at 1:00 PM, Carlo Wood wrote: > > A) A smallest partition > > > >  REGION > > > > B) A collection of adjacent regions run by a single administration > > > >  ISLAND or ADJACENT REGIONS > > > > C) A collection of adjacent regions's run by different administrations > >   (which very likely use the same TOS etc) > > > >  LAND, or CONTINENT when larger. > > > > D) A collection of continent's that are not adjacent but still fall > >   under the same TOS, likely use the same inter-world protocols > >   and organisation-specific extensions etc (likely, they will > >   have their own website and their own Abuse Report team etc). > > > >  VIRTUAL WORLD > > > > E) A collection of Virtual World's that have totally different > >   administrations and possibly different TOS etc, but which > >   interoperate (ie, you can pass on a Landmark of one VW to > >   a person you meet in another VW). > > > >  GALAXY > > > > F) The whole of all Galaxies that do not interoperate, but still use VWRAP. > > > >  VWRAP UNIVERSE > > > > G) The rest that use the term "virtual world", but do not use VWRAP. > > > >  MMOX UNIVERSE > > > > > > Please state if > > * you have problem with me going to use these terms consistently in my posts > > * you will use these terms with the same meaning > > * you wish to give these terms a different meaning > > > > I understand there is also something called "REGION DOMAIN", but > > I have no idea which of the above that would be as it's not my > > term and it was never discussed. > > > > -- > > Carlo Wood > > _______________________________________________ > > ogpx mailing list > > ogpx@ietf.org > > https://www.ietf.org/mailman/listinfo/ogpx > > -- Carlo Wood From infinity@lindenlab.com Mon Aug 31 15:10:00 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F3A3A6DDB for ; Mon, 31 Aug 2009 15:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9wN92VuMF9M for ; Mon, 31 Aug 2009 15:09:58 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 169603A6BA7 for ; Mon, 31 Aug 2009 15:09:57 -0700 (PDT) Received: by ewy3 with SMTP id 3so945671ewy.42 for ; Mon, 31 Aug 2009 15:10:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.19.7 with SMTP id 7mr5065722ebs.81.1251756603183; Mon, 31 Aug 2009 15:10:03 -0700 (PDT) In-Reply-To: <958979.4393.qm@web82605.mail.mud.yahoo.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <382d73da0908301120n7e93d13j5b96151844df9a84@mail.gmail.com> <204765.27116.qm@web82605.mail.mud.yahoo.com> <958979.4393.qm@web82605.mail.mud.yahoo.com> Date: Mon, 31 Aug 2009 15:10:03 -0700 Message-ID: <3a880e2c0908311510q72432bc9n2cd9907f67ecad37@mail.gmail.com> From: Infinity Linden To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 22:10:00 -0000 yes. i agree with what you say here. and.. i would go a little further when i pick up a virtual banana in Levenhall/192/168/32 (in second life), then pass through "customs" to get to OSGridTest/252/391/22 (on OSGrid) and drop the banana, it should show up as a banana (and not a pear) to other people who are are in the same area. since second life and OSGrid share a number of assumptions about how avatars and assets are defined, this isn't too radical a goal. and it sort of informally defines a minimum interoperability "experience." so just 'cause you can have a banana on both grids, it doesn't mean that you can't do things that are region domain or region specific. one grid might implement the "banana auction" service that the other doesn't. one grid might implement the rule that bananas will always glow green on alternate tuesdays. (and hopefully, the other won't.) and ultimately this is the challenge. can all of us from the OpenSim world and Linden and IBM and whomever else sit in the same room long enough to get general agreement on how to share descriptions of objects, avatars and protocol sufficient to allow for the general migration of fruit from one person's simulator to another. i think we can. and further, doing it in the IETF puts us in an environment where if we say things like "hey! let's re-implement TFTP poorly two and a half times!" we'll hopefully have people who will remind us of our folly. still further, we're all going to probably want to do slightly different things in our worlds. one advantage that OpenSim brings to this party is that it's source is open and if people have a business reason for deploying a sim with the glowing green bananas option, they can. and they might want to do things like attach meta-data that only they can interpret to people's bananas. and that's okay. and i think i'm about to very quickly run out of things to say about glowing green bananas, so let me just say, i think at this point we're really only trying to say, "we all agree we should work on protocols that allow us to move avatars and assets between regions, possibly limited by policy." but we have a little bit of runway left to describe how it needs to be done. On Mon, Aug 31, 2009 at 1:42 PM, Charles Krinke wrote: > Dear Infinity: > > Thank you for your considered answer. I think our hearts are all headed i= n > the same place. For some reason, all this discussion of names has my head > spinning. > > But, ... that aside, as I look at interop between different grids (or > virtual worlds, if you wish), I see these as analogous to transitting > customs between countries. > > That is, there will be some things that will connect back to ones home or > originating country and some things that are intrinsic to the country one= is > visiting, to try to draw an analogy. > > The things connecting back to ones home country (or grid, if we prefer), > will most likely be the avatar, inventory and attachments, or at least pa= rt > of the inventory and all of the avatar and attachments. > > The things intrinsic to the country one is visiting will most likely be t= he > rules dealing with transactions such as buying and selling objects, > permissions of editing, and ability to visit certain parts of the visitin= g > country. > > To me, as long as that is a reciprocal relationship, that is, a visit fro= m a > SecondLife grid to an OpenSim is a mirror image of permissions to a visit > from an OpenSim grid citizen to a SecondLife grid, then I think my > enthusiasm is still "full speed ahead regardless of whether we call a pea= r a > banana or not". > > Charles > > ________________________________ > From: Meadhbh Siobhan > To: Charles Krinke > Cc: ogpx@ietf.org > Sent: Monday, August 31, 2009 11:38:00 AM > Subject: Re: [ogpx] one virtual world, or many? > > charles, > > we're not defining interop with respect to any currently defined platform= . > > the SL platform is going to need a lot of re-tooling to implement the > protocols we're supporting, and since opensim was originally based no > the SL legacy protocols, my guess is that it also will need some > retooling. > > we have, however, deployed patches to opensim to implement a previous > version of OGP, so we know it's not impossible. > > your knowledge of OpenSim deployment patterns is of great interest to > me personally; mostly because OpenSim tends to experiment a lot more > than SL. and honestly... the OSGrid deployment pattern of "some > centralized, some federated" services is one of the things i think all > the people working on OGP are interested in. > > so i think to answer your question precisely, i'd have to invoke Zen > and say "mu!" > > that is, i think it's not _completely_ related. we're not defining the > protocol in terms of the current structure of OpenSim, but i think all > of us are interested in making it possible to use OGP/VWRAP to define > a protocol that is equally useful to Linden as it is to you at OSGrid > and zha, et al at IBM as it is to anyone interested in open virtual > worlds. > > so rather than saying "yeah, we're going to support this specific mode > of OpenSim," it's probably more appropriate to say, "we're very > interested in the operational experiences of people who have used > OpenSim in both stand-alone and UGAIM mode. since it's an open > standard, we invite Teravus, Adam, JHurliman and yourself to tell us > what's easy to do in OpenSim and what's hard to do, and after we get > through the chartering process, there's likely to be several more > rounds of discussions about what people think can and can't be easily > implemented and deployed." > > but at the end of the day, i think there's going to be code changes > for both OpenSim, Linden and all the viewers. > > -cheers > -meadhbh > > On Sun, Aug 30, 2009 at 6:19 PM, Charles Krinke wrote: >> I'm confused with all that is going on and need to ask my two main >> questions >> again. >> >> "Are we considering interop with virtual worlds running OpenSim which do >> not >> run agent domains but rather a similar, but not quite identical notion w= e >> call UGAIM (User, Grid, Asset, Inventory, Messaging) servers?" >> >> "Are we considering a full handoff? That is, a user on an OpenSim grid m= ay >> teleport to a SecondLife grid and retain its connection to the OpenSim >> UGAIM, in an analogous fashion that a user has been demonstrated to >> teleport >> from the Betagrid to OSGrid using OGP last year?" >> >> Charles >> >> ________________________________ >> From: Meadhbh Siobhan >> To: Kari Lippert >> Cc: ogpx@ietf.org; dcrocker@bbiw.net >> Sent: Sunday, August 30, 2009 11:50:46 AM >> Subject: Re: [ogpx] one virtual world, or many? >> >> On Sun, Aug 30, 2009 at 11:20 AM, Kari Lippert >> wrote: >>> The network/internet analogy is great. I vote base hit.... and would >>> like to emphasize that, given current usage of the words, the answer >>> to >>> >>>> =A0 =A0 Are we connecting two virtual worlds or is the result a single >>>> =A0 =A0 virtual world? >>> >>> is yes, sort of. >>> >>> As I understand it, VWRAP is designed to connect/allow >>> interoperability between two or more independent/distinct/individual >>> virtual environments/regions/worlds into what appears to the user as a >>> single environment/region/world/universe. This single >>> environment/region/world/universe is in fact multiple >>> independent/distinct/individual virtual environments/regions/worlds >>> whose boundaries could be administrative or technological but the >>> distinction matters not. >>> >>> Is that right? >>> >>> Kari >>> >> >> this is an interesting use case, but not what OGPX/VWRAP was proposed >> to address. >> >> MMOX remains as a venue for the discussion of integrating technically >> diverse virtual worlds. >> >> >>> >>> >>> >>> >>> >>> On Sun, Aug 30, 2009 at 11:40 AM, Dave CROCKER wrote: >>>> Folks, >>>> >>>> >>>> Pre-game. >>>> >>>> Confusion and disagreement that includes the term "virtual world" is >>>> proving >>>> tenacious, in spite of extensive and substantive discussion. =A0Typica= lly, >>>> something this persistent means either that some concept(s) lack share= d >>>> definition or that competing technical paradigms are present. >>>> >>>> As was noted many message ago, there's a good chance that much of the >>>> disagreement is really about the meaning of the term. =A0That is, that >>>> apparent >>>> disagreements about such things as scope of work is really about scope >>>> of >>>> this one term. =A0That, at least, is my own reading of the discussions= . =A0I >>>> think people are using the term differently. =A0If we can get to the p= oint >>>> of >>>> using it the same >>>> way, my sense is that we will find that disagreements about actual wor= k >>>> to >>>> be done, and its use, are rather small. >>>> >>>> In other words, I think the persistence of debate that keeps using tha= t >>>> term >>>> "virtual world" means we have to resolve it before we can make serious >>>> progress. These sorts of things never seem to go away without explicit >>>> resolution. =A0While much of the earlier attempts to resolve this look >>>> like >>>> they helped quite a bit, it seems clear that a bit more effort is >>>> needed. >>>> >>>> >>>> >>>> The wind-up. >>>> >>>> Since the crux of the challenge keeps coming back to what >>>> interoperability >>>> will >>>> or will not be provided -- with at least one additional point about >>>> whether >>>> the >>>> current work must be used internal to a service or only used /between/ >>>> services >>>> -- permit me a moment of theft from Internet history and constructs. = =A0I >>>> think it >>>> can be applicable here: >>>> >>>> =A0 Network vs. Internetwork. >>>> >>>> =A0 "A" virtual world vs. Multiple virtual worlds. >>>> >>>> But hold on. =A0I'm not necessarily going to suggest mapping the two s= ets >>>> as >>>> one-to-one directly... >>>> >>>> Originally, a network was a discrete technical set. =A0X.25. =A0NCP. = =A0XNS. >>>> Netware. >>>> Whatever. =A0Both technology and administration had the same boundary. >>>> =A0Your >>>> network might use one technology and mine might use another. =A0But ev= en >>>> if >>>> they >>>> used the same technology, one was mine and the other was yours. =A0So = I >>>> tend >>>> to >>>> view interaction across administrative boundaries as far more >>>> interesting >>>> to >>>> internetworking than whether different technologies are used: >>>> >>>> =A0 >>>> >>>> The term Internet has come to mean a single, unified, global service. >>>> =A0It >>>> crosses administrative boundaries. =A0Does IBM internally operate a >>>> 'network' >>>> or >>>> an 'internetwork'? =A0Either choice is reasonable, depending on what i= s >>>> the >>>> focus. I think we don't need to resolve the equivalent question here. >>>> >>>> There is universal agreement that there is a single global service, >>>> comprising many independent smaller services, and that that single, >>>> larger >>>> thing is "The" Internet. >>>> >>>> What we tend to forget is that there probably are other Internets that >>>> don't >>>> (directly) interoperate with the global one. =A0They are off "The >>>> Internet" >>>> grid >>>> and are on their own. =A0They are likely also "an" Internet. =A0These = days, >>>> they >>>> might be running TCP/IP, but they don't have to. =A0For example: >>>> >>>> =A0 >>>> >>>> Some uses of "virtual world" appear to mean an administrative boundary >>>> and >>>> others appear to mean a technical boundary. This is the sort of thing = we >>>> need to resolve. >>>> >>>> >>>> >>>> The pitch. >>>> >>>> I suggest ignoring technical differences within an administrative doma= in >>>> and >>>> even across different administrative domains. =A0Simply, VWrap is used= to >>>> connect together administrative domains running simulations. >>>> >>>> =A0 =A0 I'm running one simulation and you are running another. =A0We = use >>>> =A0 =A0 VWrap to interoperate. >>>> >>>> =A0 =A0 Are we connecting two virtual worlds or is the result a single >>>> =A0 =A0 virtual world? >>>> >>>> Some other folk might not interoperate with our unified service. =A0Th= ey >>>> are >>>> running their own thing. =A0Are they running a different virtual world= or, >>>> perhaps, a different set of multiple virtual worlds? >>>> >>>> >>>> >>>> The swing. >>>> >>>> I suggest that: >>>> >>>> =A0 =A0 Any set of independent administrative domains that interoperat= e >>>> =A0 =A0 together, using VWrap, creates a /single/ virtual world. >>>> >>>> =A0 =A0 Each independent administrative domain is running /part/ of th= at >>>> single >>>> =A0 =A0 virtual world. =A0(The part might be one Region, or Agent, or = it might >>>> be >>>> =A0 =A0 many of both or any combination.) >>>> >>>> =A0 =A0 Hence, I am suggesting that an integrated VWrap environment ha= s a >>>> =A0 =A0 comparable quality to an integrated internet environment that = we >>>> call >>>> =A0 =A0 "The" Internet. =A0One service. >>>> >>>> If you are running a simulation that is not part of an integrated, >>>> interoperable >>>> VWrap environment, you are in a different virtual world. >>>> >>>> =A0 =A0 If you are part of an interoperable VWrap service, you are in = a >>>> =A0 =A0 single virtual world. >>>> >>>> It doesn't matter what you run internally. =A0What matters is integrat= ion >>>> to >>>> the >>>> interoperable service using VWrap. >>>> >>>> >>>> >>>> Base hit or strikeout? >>>> >>>> d/ >>>> -- >>>> >>>> =A0Dave Crocker >>>> =A0Brandenburg InternetWorking >>>> =A0bbiw.net >>>> >>>> _______________________________________________ >>>> ogpx mailing list >>>> ogpx@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ogpx >>>> >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >>> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From carlo@alinoe.com Mon Aug 31 15:28:09 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98203A6961 for ; Mon, 31 Aug 2009 15:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAkgRjsyNb7K for ; Mon, 31 Aug 2009 15:28:08 -0700 (PDT) Received: from viefep14-int.chello.at (viefep14-int.chello.at [62.179.121.34]) by core3.amsl.com (Postfix) with ESMTP id 521723A687F for ; Mon, 31 Aug 2009 15:28:08 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep14-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090831222818.EGEO29725.viefep14-int.chello.at@edge05.upc.biz>; Tue, 1 Sep 2009 00:28:18 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id bAUG1c07E0FlQed05AUJz2; Tue, 01 Sep 2009 00:28:18 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MiFNW-0008Te-3Q; Tue, 01 Sep 2009 00:29:34 +0200 Date: Tue, 1 Sep 2009 00:29:34 +0200 From: Carlo Wood To: Meadhbh Siobhan Message-ID: <20090831222934.GB29965@alinoe.com> References: <20090831170006.GB15637@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] Definitions of terms to be used in my (our?) communication X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 22:28:09 -0000 On Mon, Aug 31, 2009 at 11:08:13AM -0700, Meadhbh Siobhan wrote: > but before i comment on these terms, let me point out that while this > discussion is interesting and germane to the subject of virtual > worlds, it is a bit out of scope for a discussion about the charter. > so, can we just for right now, just use the terms that have been > defined in the way that they're defined and get through the charter > bashing? > > i PROMISE you, that we'll get back to terms in more detail, and > honestly, i like your use of the term "universe." that feels to me ... like pushing it through. > in the current OGP/VWRAP documents, the term "island" and "galaxy" aren't used. great then it won't give rise to confusion > your use of the term "region" is different than the way it's described > in the intro doc. what you call a "region" below, we would call a > "region domain." a "region domain" is the smallest possible partition??? I thought a region is a single 'sim' (in SL those 256x256 m^2 areas) > what we call a "region" is the set of data used to > represent a collection of adjacent points in the virtual world. i'm you lost me there, comparing it with SL (PLEASE! just for clarity!), do you mean something smaller than 256x256 meter or something larger with endless sea as boundary? > hoping that the verbiage in the draft charter makes it clear that > services that export information about the region or provide an > interface to modify the region's state go through a single region > specific URI. the "simulator" is the server process that maintains the > region's state and processes service requests. the "simulator host" or > "region host" is the machine itself that the simulator process runs > on. I thought you just said that was a region domain > further, a "domain" is a collection of resources administered by a > single entity. thus a "region domain" is a collection of regions that > are run by the same entity, and presumably _could_ be governed by the > same terms of service, or more importantly to us, could potentially be > considered a single end entity in the trust model. you said "what we call a "region" is the set of data used to represent a collection of adjacent points in the virtual world" and "a "region domain" is a collection of regions..." Thus a region domain is adjacent? Or not? > we haven't put the term "adjacent region" into the doc, and now that i > see you talking about it, i think it was an oversight not to. or > rather, maybe just to talk about "adjacency" in general. for people > who are unfamiliar with SL, adjacent regions are simply regions that > are next to each other in the geometry of the virtual world. in second > life, a region communicates with adjacent regions so the original see? a region IS a sim! Then that is the smallest partition, no?? (partition as in 'able to run on separate hardware'; definitely not talking about parcels) > region can tell the client the state of assets it's managing, if the > client needs to know about it and policy says the client can access > that information. *whew* in SL, the term "island" sometimes means > regions that have no adjacent regions (i.e. - they're out in the > virtual ocean, all by themselves) or about a virtual landscape that > looks like an island. (obviously, the former is more interesting to > this group than the latter at this moment.) so we have consensus there ((a set of) regions that have no adjacent regions) I just add that it's run by a single administration > the terms "land" and "continent" are not defined in the spec. SL uses > "continents" for administrative and (some) billing purposes. we are > not trying to foist this aspect of SL off on the unsuspecting public. > that is, it works well for us to divide things into continents, and if > someone other than Linden wants to do this, good on ya. but, requiring > that this be a part of the specification is not harmonious with our > objective of not having people say bad things about us. no reason not to use the terms from now on on this list. > "galaxy" is also not defined in the spec, or by any of implementors > who worked on OGP over the last 2 years. no reason not to use it on this list. > "virtual world" is defined informally as discussed earlier on this > list. i know morgaine frequently uses the term "region domain" to > describe what we would call a "virtual world." Yes, Morgaine/Kari/me say: "virtual world" < "region domain", or so we thought. You say: "region domain" < "virtual world", and still there is no need to define these terms more clearly, right? > "VWRAP Universe" is not defined now, and i'm generally loathe to > introduce new terms, but i have to admit, i kinda like this one. but > let's talk about it more later. not important > about "MMOX Universe.." as far as i can tell, no one is working on > MMOX currently, so we might want to say "non-VWRAP universe" to > describe universes that are not VWRAPish. even less important Now please do the reverse: start with my descriptions and then give terms that we can use ON THIS LIST - not in the protocol, or drafts or whatever document - just here - so that we UNDERSTAND eachother! Let me fill in what I THINK you have as term... > > A) A smallest partition I still think you call this 'region': in principle it is possible to run every region on a different host/machine, there is nothing smaller that could be run on a separate machine. > > B) A collection of adjacent regions run by a single administration you have no term... but we need one. Make one up, or lets use 'island' > > C) A collection of adjacent regions's run by different administrations > >   (which very likely use the same TOS etc) idem / 'continent' > > D) A collection of continent's that are not adjacent but still fall > >   under the same TOS, likely use the same inter-world protocols > >   and organisation-specific extensions etc (likely, they will > >   have their own website and their own Abuse Report team etc). *** THIS IS THE REASON THAT WE HAVE A PROBLEM WITH THE CHARTER *** because: you don't HAVE a term for this! That collapses D and E into one, and that is unacceptable. > > E) A collection of Virtual World's that have totally different > >   administrations and possibly different TOS etc, but which > >   interoperate (ie, you can pass on a Landmark of one VW to > >   a person you meet in another VW). You consistently call this 'virtual world' -- Carlo Wood From infinity@lindenlab.com Mon Aug 31 15:30:33 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE9733A6B1E for ; Mon, 31 Aug 2009 15:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBIErPog9oWW for ; Mon, 31 Aug 2009 15:30:33 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 358283A687F for ; Mon, 31 Aug 2009 15:30:31 -0700 (PDT) Received: by ewy3 with SMTP id 3so955469ewy.42 for ; Mon, 31 Aug 2009 15:30:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.71.13 with SMTP id t13mr5160821eba.13.1251757838197; Mon, 31 Aug 2009 15:30:38 -0700 (PDT) In-Reply-To: <20090831220522.GA29965@alinoe.com> References: <20090831170006.GB15637@alinoe.com> <382d73da0908311034u50baa09fqcdbed2a478df99f8@mail.gmail.com> <20090831220522.GA29965@alinoe.com> Date: Mon, 31 Aug 2009 15:30:38 -0700 Message-ID: <3a880e2c0908311530w31841d75o53c273003bb7c19e@mail.gmail.com> From: Infinity Linden To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Definitions of terms to be used in my (our?) communication X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 22:30:33 -0000 we need to have a normative definition of "land?" i would assert that the term "region domain" is sufficient, for the purposes of an interoperability protocol, to define a container for a collection of one or more regions. i further assert that this concept is distinct from the concept that regions from different region domains may or may not be adjacent, and that the manner in which regions geographic relation to one another is described is independent of the number of regions in a region domain. and yes, i did mention the concept of adjacency, and recommended we do not make adjacent regions a special case, but rather define regions in such a way that the positional aspect of regions makes it clear that regions should understand that they need to respond to protocol from other regions that are defined to be adjacent, when they exist. and the proper english usage for a person of my gender is "and since Infinity didn't give replacement terms in her reply (she only said 'this term is not defined by us in past 2 years')." so... to recap... we've survived for two years without a normative definition of "land," and i assert some stuff about why. i think we should define "ADJACENCY" as being an aspect of a "REGION" instead of defining something called an "ADJACENT REGION" that is distinct from a "REGION." My drivers license has an 'F' on it, and not an 'M'. (though honestly, i understand it's difficult sometimes to recognize the uniquely feminine way in which i type.) -cheers -meadhbh On Mon, Aug 31, 2009 at 3:05 PM, Carlo Wood wrote: > On Mon, Aug 31, 2009 at 01:34:50PM -0400, Kari Lippert wrote: >> Personally I would drop the use of "LAND" and =A0"ADJACENT REGIONS" but >> I think these terms, as defined here are the right set based on the >> lengthy conversations I started yesterday morning. Using these terms >> it should now be rather trivial to restate the Charter in a way that >> captures the essence of the effort's intent. >> >> Kari > > thanks > > and since Infinity didn't give replacement terms in his reply > (he only said 'this term is not defined by us in past 2 years') > I see no other alternative than to use these terms. > >> On Mon, Aug 31, 2009 at 1:00 PM, Carlo Wood wrote: >> > A) A smallest partition >> > >> > =A0REGION >> > >> > B) A collection of adjacent regions run by a single administration >> > >> > =A0ISLAND or ADJACENT REGIONS >> > >> > C) A collection of adjacent regions's run by different administrations >> > =A0 (which very likely use the same TOS etc) >> > >> > =A0LAND, or CONTINENT when larger. >> > >> > D) A collection of continent's that are not adjacent but still fall >> > =A0 under the same TOS, likely use the same inter-world protocols >> > =A0 and organisation-specific extensions etc (likely, they will >> > =A0 have their own website and their own Abuse Report team etc). >> > >> > =A0VIRTUAL WORLD >> > >> > E) A collection of Virtual World's that have totally different >> > =A0 administrations and possibly different TOS etc, but which >> > =A0 interoperate (ie, you can pass on a Landmark of one VW to >> > =A0 a person you meet in another VW). >> > >> > =A0GALAXY >> > >> > F) The whole of all Galaxies that do not interoperate, but still use V= WRAP. >> > >> > =A0VWRAP UNIVERSE >> > >> > G) The rest that use the term "virtual world", but do not use VWRAP. >> > >> > =A0MMOX UNIVERSE >> > >> > >> > Please state if >> > * you have problem with me going to use these terms consistently in my= posts >> > * you will use these terms with the same meaning >> > * you wish to give these terms a different meaning >> > >> > I understand there is also something called "REGION DOMAIN", but >> > I have no idea which of the above that would be as it's not my >> > term and it was never discussed. >> > >> > -- >> > Carlo Wood >> > _______________________________________________ >> > ogpx mailing list >> > ogpx@ietf.org >> > https://www.ietf.org/mailman/listinfo/ogpx >> > > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From infinity@lindenlab.com Mon Aug 31 15:32:29 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74A428C46A for ; Mon, 31 Aug 2009 15:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNLPKF-6peXx for ; Mon, 31 Aug 2009 15:32:28 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 5CB6A28C17B for ; Mon, 31 Aug 2009 15:31:32 -0700 (PDT) Received: by ewy3 with SMTP id 3so955929ewy.42 for ; Mon, 31 Aug 2009 15:31:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.65.9 with SMTP id n9mr5263731eba.17.1251757897449; Mon, 31 Aug 2009 15:31:37 -0700 (PDT) In-Reply-To: <3a880e2c0908311530w31841d75o53c273003bb7c19e@mail.gmail.com> References: <20090831170006.GB15637@alinoe.com> <382d73da0908311034u50baa09fqcdbed2a478df99f8@mail.gmail.com> <20090831220522.GA29965@alinoe.com> <3a880e2c0908311530w31841d75o53c273003bb7c19e@mail.gmail.com> Date: Mon, 31 Aug 2009 15:31:37 -0700 Message-ID: <3a880e2c0908311531j14bab252td7c3e49ec884cb3c@mail.gmail.com> From: Infinity Linden To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] Definitions of terms to be used in my (our?) communication X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 22:32:29 -0000 krunk. had i waited a few minutes to send this reply i would have seen that i think we're hurtling 'towards agreement. On Mon, Aug 31, 2009 at 3:30 PM, Infinity Linden wr= ote: > we need to have a normative definition of "land?" i would assert that > the term "region domain" is sufficient, for the purposes of an > interoperability protocol, to define a container for a collection of > one or more regions. i further assert that this concept is distinct > from the concept that regions from different region domains may or may > not be adjacent, and that the manner in which regions geographic > relation to one another is described is independent of the number of > regions in a region domain. > > and yes, i did mention the concept of adjacency, and recommended we do > not make adjacent regions a special case, but rather define regions in > such a way that the positional aspect of regions makes it clear that > regions should understand that they need to respond to protocol from > other regions that are defined to be adjacent, when they exist. > > and the proper english usage for a person of my gender is "and since > Infinity didn't give replacement terms in her reply (she only said > 'this term is not defined by us in past 2 years')." > > so... to recap... we've survived for two years without a normative > definition of "land," and i assert some stuff about why. i think we > should define "ADJACENCY" as being an aspect of a "REGION" instead of > defining something called an "ADJACENT REGION" that is distinct from a > "REGION." My drivers license has an 'F' on it, and not an 'M'. (though > honestly, i understand it's difficult sometimes to recognize the > uniquely feminine way in which i type.) > > -cheers > -meadhbh > > On Mon, Aug 31, 2009 at 3:05 PM, Carlo Wood wrote: >> On Mon, Aug 31, 2009 at 01:34:50PM -0400, Kari Lippert wrote: >>> Personally I would drop the use of "LAND" and =A0"ADJACENT REGIONS" but >>> I think these terms, as defined here are the right set based on the >>> lengthy conversations I started yesterday morning. Using these terms >>> it should now be rather trivial to restate the Charter in a way that >>> captures the essence of the effort's intent. >>> >>> Kari >> >> thanks >> >> and since Infinity didn't give replacement terms in his reply >> (he only said 'this term is not defined by us in past 2 years') >> I see no other alternative than to use these terms. >> >>> On Mon, Aug 31, 2009 at 1:00 PM, Carlo Wood wrote: >>> > A) A smallest partition >>> > >>> > =A0REGION >>> > >>> > B) A collection of adjacent regions run by a single administration >>> > >>> > =A0ISLAND or ADJACENT REGIONS >>> > >>> > C) A collection of adjacent regions's run by different administration= s >>> > =A0 (which very likely use the same TOS etc) >>> > >>> > =A0LAND, or CONTINENT when larger. >>> > >>> > D) A collection of continent's that are not adjacent but still fall >>> > =A0 under the same TOS, likely use the same inter-world protocols >>> > =A0 and organisation-specific extensions etc (likely, they will >>> > =A0 have their own website and their own Abuse Report team etc). >>> > >>> > =A0VIRTUAL WORLD >>> > >>> > E) A collection of Virtual World's that have totally different >>> > =A0 administrations and possibly different TOS etc, but which >>> > =A0 interoperate (ie, you can pass on a Landmark of one VW to >>> > =A0 a person you meet in another VW). >>> > >>> > =A0GALAXY >>> > >>> > F) The whole of all Galaxies that do not interoperate, but still use = VWRAP. >>> > >>> > =A0VWRAP UNIVERSE >>> > >>> > G) The rest that use the term "virtual world", but do not use VWRAP. >>> > >>> > =A0MMOX UNIVERSE >>> > >>> > >>> > Please state if >>> > * you have problem with me going to use these terms consistently in m= y posts >>> > * you will use these terms with the same meaning >>> > * you wish to give these terms a different meaning >>> > >>> > I understand there is also something called "REGION DOMAIN", but >>> > I have no idea which of the above that would be as it's not my >>> > term and it was never discussed. >>> > >>> > -- >>> > Carlo Wood >>> > _______________________________________________ >>> > ogpx mailing list >>> > ogpx@ietf.org >>> > https://www.ietf.org/mailman/listinfo/ogpx >>> > >> >> -- >> Carlo Wood >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > From infinity@lindenlab.com Mon Aug 31 16:07:28 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA98F3A6BDD for ; Mon, 31 Aug 2009 16:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8hk3zp7zdeC for ; Mon, 31 Aug 2009 16:07:27 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 442DC3A6BF0 for ; Mon, 31 Aug 2009 16:06:43 -0700 (PDT) Received: by ewy6 with SMTP id 6so2865637ewy.10 for ; Mon, 31 Aug 2009 16:06:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.101.1 with SMTP id y1mr6154780ebb.67.1251760008340; Mon, 31 Aug 2009 16:06:48 -0700 (PDT) In-Reply-To: <20090831222934.GB29965@alinoe.com> References: <20090831170006.GB15637@alinoe.com> <20090831222934.GB29965@alinoe.com> Date: Mon, 31 Aug 2009 16:06:48 -0700 Message-ID: <3a880e2c0908311606j16d2f75al478fe85345543e55@mail.gmail.com> From: Infinity Linden To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Meadhbh Siobhan , ogpx@ietf.org Subject: Re: [ogpx] Definitions of terms to be used in my (our?) communication X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 23:07:28 -0000 On Mon, Aug 31, 2009 at 3:29 PM, Carlo Wood wrote: > On Mon, Aug 31, 2009 at 11:08:13AM -0700, Meadhbh Siobhan wrote: >> but before i comment on these terms, let me point out that while this >> discussion is interesting and germane to the subject of virtual >> worlds, it is a bit out of scope for a discussion about the charter. >> so, can we just for right now, just use the terms that have been >> defined in the way that they're defined and get through the charter >> bashing? >> >> i PROMISE you, that we'll get back to terms in more detail, and >> honestly, i like your use of the term "universe." > > that feels to me ... like pushing it through. and saying that we don't want to start _any_ work before we all agree on every term seems obstructionist to me. > >> in the current OGP/VWRAP documents, the term "island" and "galaxy" aren'= t used. > > great then it won't give rise to confusion > >> your use of the term "region" is different than the way it's described >> in the intro doc. what you call a "region" below, we would call a >> "region domain." > > a "region domain" is the smallest possible partition??? > I thought a region is a single 'sim' (in SL those 256x256 m^2 areas) yes, a region is the smallest possible partition that is defined in OGP/VWRAP. but OGP/VWRAP regions are not limited to SL's 256x256 geometry. also, we're not trying to force the use of "parcels" and "estates" as part of OGP/VWRAP. they are, of course, an integral part of our billing process, so Linden will still support them, and if people think we need to publicly define the interface and definition of these terms, we probably would. but we don't think it's a requirement for non-second life regions to support our billing infrastructure, so it's probably going to be defined as a distinct set of resources/interfaces available on linden region domain(s). later on if everyone thinks such a thing SHOULD go in the protocol, maybe, but i don't think people will. > >> what we call a "region" is the set of data used to >> represent a collection of adjacent points in the virtual world. i'm > > you lost me there, comparing it with SL (PLEASE! just for clarity!), > do you mean something smaller than 256x256 meter or something larger > with endless sea as boundary? for the purposes of OGP/VWRAP, a region is some data with a couple of well defined interfaces queried by clients (either client applications running on users' systems, other VWRAP servers or other information services (read web applications.) one aspect of a region is it's shape. the region may choose to define their shape as 256x256m if they want, and most currently deployed SL regions will likely retain that shape for the indefinite future. but there's no reason someone else could define a region to be 128x128m or 512x512m or decide to use an arbitrary 3d shape to define the bounds of the region. and though VWRAP will define the concept of a region and SL will define regions to be 256x256m in the near term, this doesn't mean you can't define "sub-regions" or "super-regions" or "sectors" or "map grids" or "stellar cartography instances" in your region domain. > >> hoping that the verbiage in the draft charter makes it clear that >> services that export information about the region or provide an >> interface to modify the region's state go through a single region >> specific URI. the "simulator" is the server process that maintains the >> region's state and processes service requests. the "simulator host" or >> "region host" is the machine itself that the simulator process runs >> on. > > I thought you just said that was a region domain no. a "region" is the object graph. the "simulator" is the process that implements the protocol. the "region domain" is the collection of regions "owned" by one organization. the "region host" or "simulator host" is the machine on which the simulator runs. > >> further, a "domain" is a collection of resources administered by a >> single entity. thus a "region domain" is a collection of regions that >> are run by the same entity, and presumably _could_ be governed by the >> same terms of service, or more importantly to us, could potentially be >> considered a single end entity in the trust model. > > you said "what we call a "region" is the set of data used to > represent a collection of adjacent points in the virtual world" > and "a "region domain" is a collection of regions..." > Thus a region domain is adjacent? Or not? a region domain is a collection of collections. the protocol does not flatten collections. > >> we haven't put the term "adjacent region" into the doc, and now that i >> see you talking about it, i think it was an oversight not to. or >> rather, maybe just to talk about "adjacency" in general. for people >> who are unfamiliar with SL, adjacent regions are simply regions that >> are next to each other in the geometry of the virtual world. in second >> life, a region communicates with adjacent regions so the original > > see? a region IS a sim! Then that is the smallest partition, no?? > (partition as in 'able to run on separate hardware'; definitely not > talking about parcels) huh? a region is a region and a sim is a sim. > >> region can tell the client the state of assets it's managing, if the >> client needs to know about it and policy says the client can access >> that information. *whew* in SL, the term "island" sometimes means >> regions that have no adjacent regions (i.e. - they're out in the >> virtual ocean, all by themselves) or about a virtual landscape that >> looks like an island. (obviously, the former is more interesting to >> this group than the latter at this moment.) > > so we have consensus there ((a set of) regions that have no adjacent regi= ons) > I just add that it's run by a single administration yeah. it's thought that a region will have one root administrator, and may have 0 or more adjacent regions. that being said.. we have to be careful when we define who gets to administer regions in region domains or any subordinate organizations the region or region domain introduces. i don't want to define things in a way that OSGrid has problems. and we're going to retain the feature of our system that estate owners can do things that normal users can't. but we don't want to force everyone to adopt this model, so we're not pushing for it to be in the spec, 'cause we really think there are people out there who don't want to be burdened with artifacts of our billing model. > >> the terms "land" and "continent" are not defined in the spec. SL uses >> "continents" for administrative and (some) billing purposes. we are >> not trying to foist this aspect of SL off on the unsuspecting public. >> that is, it works well for us to divide things into continents, and if >> someone other than Linden wants to do this, good on ya. but, requiring >> that this be a part of the specification is not harmonious with our >> objective of not having people say bad things about us. > > no reason not to use the terms from now on on this list. yes. there are reasons not to use them. they have no normative definition and asking people to accept artifacts of our billing model is asking for trouble. > >> "galaxy" is also not defined in the spec, or by any of implementors >> who worked on OGP over the last 2 years. > > no reason not to use it on this list. why not call it a cartographic set? > >> "virtual world" is defined informally as discussed earlier on this >> list. i know morgaine frequently uses the term "region domain" to >> describe what we would call a "virtual world." > > Yes, Morgaine/Kari/me say: "virtual world" < "region domain", or so > we thought. You say: "region domain" < "virtual world", and still > there is no need to define these terms more clearly, right? yes, but we don't have the need to define the term "virtual world." > >> "VWRAP Universe" is not defined now, and i'm generally loathe to >> introduce new terms, but i have to admit, i kinda like this one. but >> let's talk about it more later. > > not important LOL. i say i like something and you assert it's irrelevant. > >> about "MMOX Universe.." as far as i can tell, no one is working on >> MMOX currently, so we might want to say "non-VWRAP universe" to >> describe universes that are not VWRAPish. > > even less important huh? you are trying to tell me we should define things that are not VWRAP as "non-VWRAP" instead of "MMOX" and i tell you there seems to be no one working on MMOX and you think this is unimportant? really? > > Now please do the reverse: start with my descriptions and then > give terms that we can use ON THIS LIST - not in the protocol, or > drafts or whatever document - just here - so that we UNDERSTAND > eachother! > > Let me fill in what I THINK you have as term... > >> > A) A smallest partition > > I still think you call this 'region': in principle it is > possible to run every region on a different host/machine, > there is nothing smaller that could be run on a separate > machine. i could care less how many machines it's run on. a region has a single URI used to request its services. > >> > B) A collection of adjacent regions run by a single administration > > you have no term... but we need one. > Make one up, or lets use 'island' fine. you can call it an island. it is unimportant for the definition of the protocol. what is important is that regions have 0 or more adjacent regions and that regions are members of a region domain. > >> > C) A collection of adjacent regions's run by different administrations >> > =A0 (which very likely use the same TOS etc) > > idem / 'continent' again. feel free to use whatever terminology you want to use. > >> > D) A collection of continent's that are not adjacent but still fall >> > =A0 under the same TOS, likely use the same inter-world protocols >> > =A0 and organisation-specific extensions etc (likely, they will >> > =A0 have their own website and their own Abuse Report team etc). > > *** THIS IS THE REASON THAT WE HAVE A PROBLEM WITH THE CHARTER *** > because: you don't HAVE a term for this! well. sorry you don't want to play with us. > > That collapses D and E into one, and that is unacceptable. > >> > E) A collection of Virtual World's that have totally different >> > =A0 administrations and possibly different TOS etc, but which >> > =A0 interoperate (ie, you can pass on a Landmark of one VW to >> > =A0 a person you meet in another VW). > > You consistently call this 'virtual world' we do not use the term "virtual world" in a normative fashion. > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From morgaine.dinova@googlemail.com Mon Aug 31 16:19:34 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4829D28C4ED for ; Mon, 31 Aug 2009 16:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8s5Nq0wlvI9 for ; Mon, 31 Aug 2009 16:19:32 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id C85B928C454 for ; Mon, 31 Aug 2009 16:19:27 -0700 (PDT) Received: by ewy6 with SMTP id 6so2871675ewy.10 for ; Mon, 31 Aug 2009 16:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=UKw+/8pMEhKJmvA0Xu84hLEQEUipZubKxqLxpldGnQU=; b=uosluZPhWqX4k52jqMFbbxuVA5r+r20r037DZ0+xbJfI5NsWWvcA9ND4yFTk59N9Uh EoGopJpXy//UwrGnomkLClv/8KnJfSD87OnNB6TIpwaDfBdlZlhdnKSmHxzgSAUWEpIk z4Tq9SpOXW4/C3N6dnVbY8Jtk0kuO5Mpmcddw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=s0kt6vZ2Ue0YWIyVIEf+6EVLvo+xmmERl6gK8PJVSZSeIUNZskUjVBWM4zbGkkCjd5 XnR1RI8XJ/zr8xfjPEEC1HGtuHuQgdjFARZpALhmB0iqhuPioM9jgB0uzp25tMfNmdbK t2LY26lXahJIaRbM20ZVzZH8muNedC4ZFw2pU= MIME-Version: 1.0 Received: by 10.211.139.17 with SMTP id r17mr6038317ebn.88.1251760768728; Mon, 31 Aug 2009 16:19:28 -0700 (PDT) In-Reply-To: <2bd5b7f10908311207rdbc7be0ue9d69b8273e6ba4b@mail.gmail.com> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <2bd5b7f10908311207rdbc7be0ue9d69b8273e6ba4b@mail.gmail.com> Date: Tue, 1 Sep 2009 00:19:28 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=00504502d2b4f7755c0472784333 Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 23:19:34 -0000 --00504502d2b4f7755c0472784333 Content-Type: text/plain; charset=ISO-8859-1 Hi Suzy! On Mon, Aug 31, 2009 at 8:07 PM, Suzy Deffeyes wrote: > > I think the Charter looks good, and I support moving forward with > submitting this to the IETF. I think it *accurately describes the scope > of what we want to do*, and is *clear in its description*. > We've just spent the last 10 days or longer trying to understand the wording and scope, without success. That the charter is "clear in its description" is sadly not a widespread view. This is why several of us are trying to get the terms defined in order to add the missing clarity. Note that this confusion is present despite the very extensive OGP background within the group. For new readers of the charter, its meaning will be even less clear, if not completely obscure. In the absense of this understanding, it is not possible to say that the document "accurately describes the scope of what we want to do", since we don't know what it describes. The scope is currently unknown to a significant number of participants. As the charter is clear to you, perhaps you could assist in the process of clarification by answering some of the recent questions made to the list? I am sure that this would be widely appreciated. Morgaine. ============================== On Mon, Aug 31, 2009 at 8:07 PM, Suzy Deffeyes wrote: > > Hi Infinity, > > I think the Charter looks good, and I support moving forward with > submitting this to the IETF. I think it accurately describes the scope of > what we want to do, and is clear in its description. > > I am ready to move to working on the protocol and implementation. Let the > interface definitions commence! > > Suzy Deffeyes / Pixel Gausman > IBM > > > On Fri, Aug 28, 2009 at 2:27 PM, Infinity Linden wrote: > >> okay... here's what i think we've all agreed to. i've taken the >> liberty of using the VWRAP name since it seems to me we have consensus >> around that name. >> >> also note that i still have the ogpx@ietf.org email list in the >> charter text, since we don't have the VWRAP mailing list up yet. >> >> but the rest of it should be "correct" based on discussions. please >> look it over and tell me if i've missed something. >> >> -cheers >> -meadhbh >> >> Working Group Name: >> >> Virtual Worlds Region Agent Protocol (VWRAP) >> >> Chairs: >> >> TBD >> >> Area and Area Directors: >> >> Applications Area >> >> Lisa Dusseault >> Alexey Melnikov >> >> Responsible Area Director: >> >> TBD >> >> Mailing List: >> >> ogpx@ietf.org >> http://www.ietf.org/mailman/listinfo/ogpx >> >> Description of Working Group: >> >> The working group will define the Virtual Worlds Region Agent Protocol >> (VWRAP) for collaborative 3-dimensional virtual worlds. The protocol >> permits users to interact with each other while represented as >> "avatars," or digital representations of the user. Within a single >> virtual world, avatars exist in at most one location in a shared >> virtual space. Conforming client applications use the protocol to >> manipulate and move the user's avatar, create objects in a virtual >> world, interact with other users and their surroundings and consume >> and create media and information from sources inside and outside their >> virtual world. >> >> Adjacent locations in virtual worlds accessible by this protocol may >> be explicitly partitioned into "regions" to facilitate the >> computational and communication load balancing required to simulate >> the virtual environment. Such virtual worlds may consist of regions >> administered by distinct organizations. Though these virtual worlds >> may be partitioned, they remain "un-sharded;" all inhabitants and >> objects in a particular location in a virtual world may initiate >> interaction with all other inhabitants and objects in that location; >> and, service endpoint addresses refer to at most one location. The >> state of a virtual world is independent of the client applications >> that access it and may persist between user sessions. >> >> Regions and services implemented according to the specifications may >> be deployed by separate organizations with varying policies and trust >> domains. The OGPX protocols will provide the mechanisms for these >> virtual world services to interoperate, when permitted by policy and >> shared trust domains. To support the exegesis of the specifications, >> the group may define a non-exhaustive set of non-normative policies >> protocol participants may enforce. >> >> The protocol should describe interaction semantics for these virtual >> worlds, independent of transport, leveraging existing standards where >> practical. It should define interoperability expectations for server >> to server interactions as well as client-server interactions. Though >> the protocol is independent of transport, early interoperability >> trials used HTTP(S) for non-real-time messages. The working group will >> define specific features that must be replicated in other transports >> and will define the use of HTTP(S) as a transport of protocol >> messages. >> >> Foundational components of the protocol include the publication of: >> >> * an abstract type system, suitable for describing the application >> protocol in an implementation neutral manner, >> >> * a security model describing trust relationships between >> participating entities, >> >> * guidelines for the use of existing authentication and >> confidentiality mechanisms, >> >> * an application-layer protocol for establishing the user's avatar >> in a virtual world, >> >> * an application-layer protocol for moving a user's avatar between >> adjacent and remote locations in a virtual world, >> >> * format descriptions for objects and avatars in a virtual world, and >> >> * an application-layer protocol for identifying agents, and >> requesting information about them. >> >> The protocol defined by this group will carry information about the >> virtual environment, its contents and its inhabitants. It is an >> application layer protocol, independent of transport, based partially >> on these previously published internet drafts: >> >> * http://tools.ietf.org/html/draft-hamrick-ogp-intro >> * http://tools.ietf.org/html/draft-hamrick-llsd >> * http://tools.ietf.org/html/draft-hamrick-ogp-auth >> * http://tools.ietf.org/html/draft-hamrick-ogp-launch >> * http://tools.ietf.org/html/draft-lentczner-ogp-base >> * http://tools.ietf.org/html/draft-levine-ogp-clientcap >> * http://tools.ietf.org/html/draft-levine-ogp-layering >> >> Goals and Milestones: >> >> * October 2009 "Introduction and Goals" to the IESG as an >> Informational RFC >> >> * October 2009 "Abstract Type System for the Transmission of Dynamic >> Structured Data" to the IESG as Proposed Standard >> >> * October 2010 "Foundational Concepts and Transport Expectations" to >> the IESG as Proposed Standard >> >> * February 2010 "Guidelines for Host Authentication" to the IESG as >> an Informational RFC >> >> * February 2010 "Service Establishment" to the IESG as Proposed >> Standard >> >> * February 2010 "Client Application Launch Message" to the IESG as >> an Informational RFC >> >> * February 2010 "Simulation Presence Establishment" to the IESG as >> Proposed Standard >> >> * June 2010 "Primitive Object Format" to the IESG as Proposed >> Standard >> >> * June 2010 "Digital Asset Access" to the IESG as Proposed Standard >> >> * June 2010 "Entity Identifiers" to the IESG as Proposed standard >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --00504502d2b4f7755c0472784333 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Suzy!

On Mon, Aug 31, 2009 at 8:07 PM, Suzy Deffeyes <suzyq@pobox.com>= wrote:

I think the Charter looks good, and I support moving forward with submitting this to the IETF.=A0 I think it accurately describes the scop= e of what we want to do, and is clear in its description.


We've just spent the last 10 days or longer trying= to understand the wording and scope, without success.=A0 That the charter = is "clear in its description" is sadly not a widespread view.=A0 = This is why several of us are trying to get the terms defined in order to a= dd the missing clarity.

Note that this confusion is present despite the very extensive OGP back= ground within the group.=A0 For new readers of the charter, its meaning wil= l be even less clear, if not completely obscure.

In the absense of t= his understanding, it is not possible to say that the document "accura= tely describes the scope of what we want to do", since we don't kn= ow what it describes.=A0 The scope is currently unknown to a significant nu= mber of participants.

As the charter is clear to you, perhaps you could assist in the process= of clarification by answering some of the recent questions made to the lis= t?=A0 I am sure that this would be widely appreciated.


Morgaine.=







=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Aug 31, 2009 at 8:07 PM, Suzy Deffeyes <<= a href=3D"mailto:suzyq@pobox.com">suzyq@pobox.com> wrote:

Hi Infinity,<= br>
I think the Charter looks good, and I support moving forward with su= bmitting this to the IETF.=A0 I think it accurately describes the scope of = what we want to do, and is clear in its description.

I am ready to move to working on the protocol and implementation. Let t= he interface definitions commence!

Suzy Deff= eyes / Pixel Gausman
IBM


On Fri, Aug 28, 2009 at 2:27 PM, Infinity Linden <infinity@lindenlab.= com> wrote:
okay... here's what i think we've all agreed= to. i've taken the
liberty of using the VWRAP name since it seems to me we have consensus
around that name.

also note that i still have the ogpx@ietf.org email list in the
charter text, since we don't have the VWRAP mailing list up yet.

but the rest of it should be "correct" based on discussions. plea= se
look it over and tell me if i've missed something.

-cheers
-meadhbh

Working Group Name:

=A0Virtual Worlds Region Agent Protocol (VWRAP)

Chairs:

=A0TBD

Area and Area Directors:

=A0Applications Area

=A0Lisa Dusseault <lisa.dusseault@gmail.com>
=A0Alexey Melnikov <alexey.melnikov@isode.com>

Responsible Area Director:

=A0TBD

Mailing List:

=A0ogpx@ietf.org =A0http://www.ietf.org/mailman/listinfo/ogpx

Description of Working Group:

The working group will define the Virtual Worlds Region Agent Protocol
(VWRAP) for =A0collaborative 3-dimensional virtual =A0worlds. The protocol<= br> permits =A0users =A0to =A0interact =A0with =A0each other =A0while =A0repres= ented =A0as
"avatars," =A0or digital representations =A0of the =A0user. Withi= n =A0a single
virtual =A0world, avatars =A0exist in =A0at most =A0one location =A0in =A0a= shared
virtual =A0space. Conforming =A0client =A0applications use =A0the protocol = =A0to
manipulate and =A0move the =A0user's avatar, create =A0objects in =A0a = virtual
world, interact =A0with other users =A0and their surroundings =A0and consum= e
and create media and information from sources inside and outside their
virtual world.

Adjacent locations =A0in virtual worlds accessible by =A0this protocol may<= br> be =A0 explicitly =A0 partitioned =A0into =A0 "regions" =A0 to = =A0facilitate =A0 the
computational =A0and communication load =A0balancing required =A0to simulat= e
the virtual =A0environment. Such virtual =A0worlds may consist =A0of region= s
administered =A0by distinct organizations. =A0Though these =A0virtual world= s
may =A0be partitioned, =A0they =A0remain "un-sharded;" =A0all inh= abitants =A0and
objects =A0in a =A0particular location =A0in =A0a virtual =A0world may =A0i= nitiate
interaction with =A0all other inhabitants and objects =A0in that location;<= br> and, service =A0endpoint addresses =A0refer to at =A0most one =A0location. = The
state of =A0a virtual =A0world is independent =A0of the =A0client applicati= ons
that access it and may persist between user sessions.

Regions and =A0services implemented according to =A0the specifications may<= br> be deployed by separate =A0organizations with varying policies and trust domains. =A0The OGPX =A0protocols will =A0provide the =A0mechanisms =A0for = these
virtual world =A0services to interoperate, when permitted =A0by policy and<= br> shared trust =A0domains. To support the exegesis =A0of the specifications,<= br> the group =A0may define a =A0non-exhaustive set of =A0non-normative policie= s
protocol participants may enforce.

The protocol =A0should describe interaction semantics =A0for these virtual<= br> worlds, independent of =A0transport, leveraging existing standards where practical. It =A0should define interoperability =A0expectations for server<= br> to server =A0interactions as well as =A0client-server interactions. Though<= br> the =A0protocol =A0is =A0independent =A0of transport, =A0early =A0interoper= ability
trials used HTTP(S) for non-real-time messages. The working group will
define specific =A0features that must be replicated =A0in other transports<= br> and =A0will =A0define =A0the use =A0of =A0HTTP(S) =A0as =A0a transport =A0o= f =A0protocol
messages.

Foundational components of the protocol include the publication of:

=A0* an abstract =A0type system, suitable for =A0describing the applicatio= n
=A0 =A0protocol in an implementation neutral manner,

=A0* a =A0 security =A0 model =A0 describing =A0trust =A0 relationships = =A0 between
=A0 =A0participating entities,

=A0* guidelines =A0 for =A0 the =A0 use =A0 of =A0existing =A0 authenticat= ion =A0 and
=A0 =A0confidentiality mechanisms,

=A0* an application-layer =A0protocol for establishing =A0the user's a= vatar
=A0 =A0in a virtual world,

=A0* an application-layer =A0protocol for moving a =A0user's avatar be= tween
=A0 =A0adjacent and remote locations in a virtual world,

=A0* format descriptions for objects and avatars in a virtual world, and
=A0* an =A0 application-layer =A0protocol =A0 for =A0identifying =A0 agent= s, =A0and
=A0 =A0requesting information about them.

The protocol =A0defined by this =A0group will carry information =A0about th= e
virtual =A0environment, =A0its contents =A0and =A0its =A0inhabitants. =A0It= is =A0an
application layer protocol, =A0independent of transport, based partially on these previously published internet drafts:

=A0* http://tools.ietf.org/html/draft-hamrick-ogp-intro
=A0* http://tools.ietf.org/html/draft-hamrick-llsd
=A0* http://tools.ietf.org/html/draft-hamrick-ogp-auth
=A0* http://tools.ietf.org/html/draft-hamrick-ogp-launch
=A0* http://tools.ietf.org/html/draft-lentczner-ogp-base
=A0* http://tools.ietf.org/html/draft-levine-ogp-clientcap =A0* http://tools.ietf.org/html/draft-levine-ogp-layering

Goals and Milestones:

=A0* October =A02009 =A0 "Introduction =A0and =A0Goals" =A0to = =A0the =A0 IESG =A0as =A0an
=A0 =A0Informational RFC

=A0* October 2009 "Abstract Type System for the Transmission of Dynam= ic
=A0 =A0Structured Data" to the IESG as Proposed Standard

=A0* October 2010 "Foundational Concepts and Transport Expectations&q= uot; to
=A0 =A0the IESG as Proposed Standard

=A0* February 2010 "Guidelines for =A0Host Authentication" to th= e IESG as
=A0 =A0an Informational RFC

=A0* February =A02010 "Service =A0Establishment" =A0to the =A0IE= SG as =A0Proposed
=A0 =A0Standard

=A0* February 2010 =A0"Client Application Launch Message" to =A0= the IESG as
=A0 =A0an Informational RFC

=A0* February 2010 =A0"Simulation Presence Establishment" to =A0= the IESG as
=A0 =A0Proposed Standard

=A0* June =A02010 =A0"Primitive Object =A0Format" =A0to =A0the = =A0IESG as =A0Proposed
=A0 =A0Standard

=A0* June 2010 "Digital Asset Access" to the IESG as Proposed St= andard

=A0* June 2010 "Entity Identifiers" to the IESG as Proposed stan= dard
_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


_______________________________________________
ogpx mailing list
ogpx@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ogpx


--00504502d2b4f7755c0472784333-- From josh@lindenlab.com Mon Aug 31 16:38:28 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65CF028C27F for ; Mon, 31 Aug 2009 16:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Sxc2BKuVqpv for ; Mon, 31 Aug 2009 16:38:27 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 8FB1F3A6C00 for ; Mon, 31 Aug 2009 16:38:27 -0700 (PDT) Received: by pzk38 with SMTP id 38so4310095pzk.5 for ; Mon, 31 Aug 2009 16:38:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.22.2 with SMTP id z2mr1306964rvi.122.1251761914893; Mon, 31 Aug 2009 16:38:34 -0700 (PDT) In-Reply-To: <4A9BE0B0.5010508@dcrocker.net> References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <20090830003055.GD22756@alinoe.com> <382d73da0908300505t3f804865h629bec91ad59954a@mail.gmail.com> <4A9A9D5A.9020400@dcrocker.net> <4A9BE0B0.5010508@dcrocker.net> Date: Mon, 31 Aug 2009 16:38:34 -0700 Message-ID: From: Joshua Bell To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=000e0cd1a59047d7a504727888f6 Subject: Re: [ogpx] one virtual world, or many? X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 23:38:28 -0000 --000e0cd1a59047d7a504727888f6 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 31, 2009 at 7:39 AM, Dave CROCKER wrote: > > > Meadhbh Siobhan wrote: > >> so. this is an interesting one. >> >> those of us who called for the OGPX BoF are in agreement that the term >> "virtual world" is informational only. >> > > > This calls for an alternative that hadn't occurred to me. > > The charter currently has the string "virtual world" thirteen times. And > it is used heavily in discussions on this list. > > That level use of use essentially guarantees that the string is not merely > informative. It really does have to have specific technical meaning that > folks agree on. > I agree that this is problematic. We should alter uses of "virtual world" in the charter are not necessary. I'll work on this tomorrow with Meadhbh. One is particularly interesting, on review: "Within a single virtual world, avatars exist in at most one location in a shared virtual space." This line actually points at the loose working consensus we seem to share about what a "virtual world" really is - the set of places "you" can "go" as "yourself". This includes both the technological aspects (i.e. services adhering to common protocols; network access) and policy aspects (i.e. permission to access, trust agreements). Again, it seems like we agree on what we're talking about, even if we're loathe to define it precisely. My suggest is to remove all occurrences of the term from the charter, > except for the two in the first sentence of the draft charters > Description > section. > > In other words, say that vwrap provides a service in virtual world > simulation, but then make all other references be in terms of vwrap-specific > technical constructs. regions, agents, etc. > Agreed. We'll probably retain "virtual world" where the description is entirely to evoke the problem space, but avoid it elsewhere. We should have a new draft charter out tomorrow. --000e0cd1a59047d7a504727888f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 31, 2009 at 7:39 AM, Dave CROCKER <dhc@dcrocker.net> wrote:


Meadhbh Siobhan wrote:
so. this is an interesting one.

those of us who called for the OGPX BoF are in agreement that the term
"virtual world" is informational only.


This calls for an alternative that hadn't occurred to me.

The charter currently has the string "virtual world" thirteen tim= es. =C2=A0And it is used heavily in discussions on this list.

That level use of use essentially guarantees that the string is not merely = informative. =C2=A0It really does have to have specific technical meaning t= hat folks agree on.

I agree that this is problematic. We should alter use= s of "virtual world" in the charter are not necessary. I'll w= ork on this tomorrow with Meadhbh.

One is particularly interesting, = on review:

"Within a single virtual world, avatars exist in at most one locat= ion in a shared virtual space."

This line actually points at th= e loose working consensus we seem to share about what a "virtual world= " really is - the set of places "you" can "go" as = "yourself". This includes both the technological aspects (i.e. se= rvices adhering to common protocols; network access) and policy aspects (i.= e. permission to access, trust agreements).

Again, it seems like we agree on what we're talking about, even if = we're loathe to define it precisely.


=C2=A0 =C2=A0 My suggest is to remove all occurrences of the term from the= charter,
=C2=A0 =C2=A0 except for the two in the first sentence of the draft charte= rs Description
=C2=A0 =C2=A0 section.

In other words, say that vwrap provides a service in virtual world simulati= on, but then make all other references be in terms of vwrap-specific techni= cal constructs. =C2=A0regions, agents, etc.<= br>

Agreed. We'll probably retain "virtual worl= d" where the description is entirely to evoke the problem space, but a= void it elsewhere.

We should have a new draft charter out tomorrow.<= br>
--000e0cd1a59047d7a504727888f6-- From suzyque@gmail.com Mon Aug 31 17:32:10 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C60028C1CC for ; Mon, 31 Aug 2009 17:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1p3oiheuc9F for ; Mon, 31 Aug 2009 17:32:09 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.211.174]) by core3.amsl.com (Postfix) with ESMTP id 18DC83A6E2F for ; Mon, 31 Aug 2009 17:32:09 -0700 (PDT) Received: by ywh4 with SMTP id 4so8562629ywh.17 for ; Mon, 31 Aug 2009 17:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=xtwSBcMP+zpFTSeva+mOsLCK2MVcIG7KLj3fqQ+uCDw=; b=AixsTO8rqhDlIOohXH5p+Dxv9A/9ZfdxlUVTJOTqW+ZTmlby2qbXV3PWbYrMa8jZ3l TtI1uEy/mqluJDL9IvEocJN/Jt3lKoBDJ2lWh7qEjh9TlZPCiuFZfxVvEaXfzr1yqMlq aP7Fx290fCmFAmrcabMNpyfArutfwWlDvXqOk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Acicpeu/cE2KxGj8JcJ8oeOOV51aN8KkADiztsVMeBXCnSrCeF5BAVf7Rwnu/YIfS6 v9qosmG7d1TcxJ597YxmYQuoq7g3zzmfvKplhllYCTT7oy3g0KwqYYVa36KdszcRQBu0 LYaPLiwf4B3GLkS3/oJLSWcc0PZIxLqpGraAA= MIME-Version: 1.0 Sender: suzyque@gmail.com Received: by 10.150.71.4 with SMTP id t4mr10271535yba.226.1251765138335; Mon, 31 Aug 2009 17:32:18 -0700 (PDT) In-Reply-To: References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <2bd5b7f10908311207rdbc7be0ue9d69b8273e6ba4b@mail.gmail.com> Date: Mon, 31 Aug 2009 20:32:18 -0400 X-Google-Sender-Auth: 57070bb7882096bc Message-ID: <2bd5b7f10908311732v202a085awf1eecb9f67d332d6@mail.gmail.com> From: Suzy Deffeyes To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ogpx@ietf.org Subject: Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: suzyq@pobox.com List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 00:32:10 -0000 Meow Morgaine! Not sure last email went thru .... We've had some great input to the Charter, and now it feels like some nitting on definitions. =A0I think the people that find the wording clear are probably =A0just being quiet and not posting to the list, so I am unsure I would claim it is a 'widespread' view that the Charter is not clear. For purposes of defining the scope, I think we are there. I've been implementing the existing OGP spec in snowglobe, and I am anxious to get more of the protocol designed. Suzy Deffeyes/Pixel Gausman IBM On Monday, August 31, 2009, Morgaine wrote= : > Hi Suzy! > > On Mon, Aug 31, 2009 at 8:07 PM, Suzy Deffeyes wrote: > > > I > think the Charter looks good, and I support moving forward with > submitting this to the IETF.=A0 I think it accurately describes the scope > of what we want to do, and is clear in its description. > > > > We've just spent the last 10 days or longer trying to understand the word= ing and scope, without success.=A0 That the charter is "clear in its descri= ption" is sadly not a widespread view.=A0 This is why several of us are try= ing to get the terms defined in order to add the missing clarity. > > Note that this confusion is present despite the very extensive OGP backgr= ound within the group.=A0 For new readers of the charter, its meaning will = be even less clear, if not completely obscure. > > In the absense of this understanding, it is not possible to say that the = document "accurately describes the scope of what we want to do", since we d= on't know what it describes.=A0 The scope is currently unknown to a signifi= cant number of participants. > > As the charter is clear to you, perhaps you could assist in the process o= f clarification by answering some of the recent questions made to the list?= =A0 I am sure that this would be widely appreciated. > > > Morgaine. > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > On Mon, Aug 31, 2009 at 8:07 PM, Suzy Deffeyes wrote: > > Hi Infinity, > > I think the Charter looks good, and I support moving forward with submitt= ing this to the IETF.=A0 I think it accurately describes the scope of what = we want to do, and is clear in its description. > > I am ready to move to working on the protocol and implementation. Let the= interface definitions commence! > > Suzy Deffeyes / Pixel Gausman > IBM > > > > On Fri, Aug 28, 2009 at 2:27 PM, Infinity Linden = wrote: > okay... here's what i think we've all agreed to. i've taken the > liberty of using the VWRAP name since it seems to me we have consensus > around that name. > > also note that i still have the ogpx@ietf.org email list in the > charter text, since we don't have the VWRAP mailing list up yet. > > but the rest of it should be "correct" based on discussions. please > look it over and tell me if i've missed something. > > -cheers > -meadhbh > > Working Group Name: > > =A0Virtual Worlds Region Agent Protocol (VWRAP) > > Chairs: > > =A0TBD > > Area and Area Directors: > > =A0Applications Area > > =A0Lisa Dusseault > =A0Alexey Melnikov > > Responsible Area Director: > > =A0TBD > > Mailing List: > > =A0ogpx@ietf.org > =A0http://www.ietf.org/mailman/listinfo/ogpx > > Description of Working Group: > > The working group will define the Virtual Worlds Region Agent Protocol > (VWRAP) for =A0collaborative 3-dimensional virtual =A0worlds. The protoco= l > permits =A0users =A0to =A0interact =A0with =A0each other =A0while =A0repr= esented =A0as > "avatars," =A0or digital representations =A0of the =A0user. Within =A0a s= ingle > virtual =A0world, avatars =A0exist in =A0at most =A0one location =A0in = =A0a shared > virtual =A0space. Conforming =A0client =A0applications use =A0the protoco= l =A0to > manipulate and =A0move the =A0user's avatar, create =A0objects in =A0a vi= rtual > world, interact =A0with other users =A0and their surroundings =A0and cons= ume > and create media and information from sources inside and outside their > virtual world. > > Adjacent locations =A0in virtual worlds accessible by =A0this protocol ma= y > be =A0 explicitly =A0 partitioned =A0into =A0 "regions" =A0 to =A0facilit= ate =A0 the > computational =A0and communication load =A0balancing required =A0to simul= ate > the virtual =A0environment. Such virtual =A0worlds may consist =A0of regi= ons > administered =A0by distinct organizations. =A0Though these =A0virtual wor= lds > may =A0be partitioned, =A0they =A0remain "un-sharded;" =A0all inhabitants= =A0and > objects =A0in a =A0particular location =A0in =A0a virtual =A0world may = =A0initiate > interaction with =A0all other inhabitants and objects =A0in that location= ; > and, service =A0endpoint addresses =A0refer to at =A0most one =A0location= . The > state of =A0a virtual =A0world is independent =A0of the =A0client applica= tions > that access it and may persist between user sessions. > > Regions and =A0services implemented according to =A0the specifications ma= y > be deployed by separate =A0organizations with varying policies and trust > domains. =A0The OGPX =A0protocols will =A0provide the =A0mechanisms =A0fo= r these > virtual world =A0services to interoperate, when permitted =A0by policy an= d > shared trust =A0domains. To support the exegesis =A0of the specifications= , > the group =A0may define a =A0non-exhaustive set of =A0non-normative polic= ies > protocol participants may enforce. > > The protocol =A0should describe interaction semantics =A0for these virtua= l > worlds, independent of =A0transport, leveraging existing standards where > practical. It =A0should define interoperability =A0expectations for serve= r > to server =A0interactions as well as =A0client-server interactions. Thoug= h > the =A0protocol =A0is =A0independent =A0of transport, =A0early =A0interop= erability > trials used HTTP(S) for non-real-time messages. The working group will > define specific =A0features that must be replicated =A0in other transport= s > and =A0will =A0define =A0the use =A0of =A0HTTP(S) =A0as =A0a transport = =A0of =A0protocol > messages. > > Foundational components of the protocol include the publication of: > > =A0* >